Continuous improvement and considerations for incremental Deployments

<< Click to Display Table of Contents >>

Navigation:  Automation Server > Automation Server configuration and administration guide > System maintenance and monitoring >

Continuous improvement and considerations for incremental Deployments

Overview

As part of continuous process improvement, Bizagi allows the evolution of your processes as your business evolves.

Sometimes this involves making changes to business data, business rules, or interfaces, or even changing the flow of the Process itself.

 

Depending on the necessary changes, we recommend that you generate new versions of processes when they have been already deployed to Production.

This is a safe way to make changes without compromising the information of the current cases being executed in the Production environment.

 

However, publishing minor modifications to existing processes is also possible, so that the current cases can take advantage of those changes and adjustments.

This section describes when it is best to create new versions for existing processes, and how to handle minor changes when required for an existing process.

 

Continuous improvement

Note that you always make changes in the Development environment to a process that is already in the Production environment, and then move the changes to Production, once they are satisfactory by executing a deployment.

 

Changes you must do in the Development environment include: new workflow Tasks or transitions, form additions or changes to existing forms, business rules changes, and new performers or integration definitions.

Model_Automate_ExecuteEN1

 

You can carry out changes to management tasks and configurations directly in the Production Work Portal. Such management tasks include: editing business policies, users administration tasks and authorization configuration, and administration for the SMTP server or ECM systems.

 

We recommend that you always make use of the Test environment to deploy and test your updated processes before deploying them to Production.

This way, you can check and adjust your processes so that they perform as you need them to.

 

Incremental deployments

For continuous improvement of your processes and for deployments to an existing Production environment, take into account the following considerations in your Development environment:

 

1. Objects in Production must remain in Development

Once a process is deployed to the Production environment (or is currently marked as a Release Candidate in the Test environment), do not delete any objects used by that process version in the Development environment.

 

This covers: entities, attributes and relationships, forms, business rules, performer assignments (assignment rules), systems, and organization definitions.

 

Similarly, it is not possible to modify the Name property of objects already used in Production.

This behavior is restricted to guarantee the stability of the Production environment in a subsequent deployment.

 

LockedObjects

 

 

2. Synchronizing data from another environment

It is a common and recommended practice to create users and use cases in your authoring environment. If you have done so, and the information you have used in the development environment is real data that you need to have in your target environment, the easiest way to transfer that information without having to create it once again is to perform a Data Synchronization. In such procedure, you can handpick which data elements to export into a .bdex file which can then be imported into your target environment.

 

ExportData_01

 

The data elements that can be considered are Parameter entities managed in production, and Users with their associations.

 

3. Versioning processes

Once a process is deployed to the Production environment (or is currently marked as Release Candidate in the Test environment), its current version is locked so that it is not possible to edit the workflow model for that specific version.

 

The process' version cannot be edited using the process Wizard's step 1 (addition, edition or deletion of shapes or transitions is not possible).

 

If you wish to make this type of major changes to a workflow model, create a new version of the process (and its sub-processes).

 

NewVersion

 

On the other hand, you may choose not to create a new version of the process if the required changes are minor:

 

Adding a new attribute or entity.

Adding or editing current business rules (Action Events, performers assignments, Web or REST services' invocations).

Creating a new query form or entity query.

 

A new version is not required if changes can be made through the process Wizard from steps 2 and later. Editing possibilities for existing objects using process Wizard steps 2 and later are detailed in the next section.

 

note_pin

Changes made in the current version (without creating a new one), would apply in the Production environment to existing cases.

Thus it is important to carry out proper tests and proceed cautiously for both new cases and existing ones; to avoid consistency errors for the deployed processes.

 

View further information about the guidelines and recommendations for a new version of a process.

 

4. Editing options for objects in Production

Once a process is deployed to the Production environment or is currently marked as Release Candidate in the Test environment, Bizagi Studio (the Development environment) limits the editing possibilities for the objects used by that process version.

This is restricted in order to guarantee the stability of the Production environment in a subsequent deployment.

 

This means that for a process version already deployed in a Production environment or marked as a Release Candidate, the best practice is to create a new process version to address new requirements and adjustments (oriented to continuous improvement), if the modifications required are "big changes".

 

However, you can make minor changes to processes (and their objects) which are already in Production (and have the existing cases take those changes).  To edit objects which are already being used in Production, refer to the possible options in the table below:

 

OBJECT

OPTIONS

Entities and Attributes

Entities and attributes (including relationships) are not editable in their: name, type, or source.

Only their display name can be edited.

Forms

Forms may not be edited (adding, modifying or deleting fields, or those fields' expressions, validations or actions is not possible).

However, forms may be cloned or versioned, and you can define which form version is the current form for an Activity.

Expressions (Boolean and scripting type)

The code may be edited (along with the display name or description property).

Proper cautions should be taken as you are dealing with "live code".

Custom Functions

The code and description property may be edited.

Widgets

The code and description property may be edited.

Performer Definitions (Assignation Rules)

All properties and definitions are editable for Work allocation (assignment rules of Tasks may be changed).

Organization Definitions

Only the display name of the elements defined for the organization may be edited (e.g., display name for existing Areas, Roles, Skills, User groups).

Holiday Schemas

Only the description of the defined holiday schemas may be edited.

Security settings

Changes for Authentication and LDAP should be done directly in the Production environment through the Management Console.

Changes done in development regarding Authorization settings will always be taken to the Production environment, and overwrite the Production environment's configuration.

Email messages

New messages (using the multiple messages feature) in an e-mail message configuration may be included.

Existing messages in the multiple messages feature cannot be removed.

In a message, its subject, recipient ("To", "CC", and "BCC"), and body content may be edited.

The conditions to send an e-mail may be edited but not deleted.

Letters

The contents may be edited.

Interface invocations

Web services invocations may be reconfigured through the interfaces wizard.

Minor changes in an existing interface (those which do not require new mappings) can be done directly in the Production environment through the Management Console.

Dimensions

All properties exept the Name may be edited.

Component Library

 

The registered assembly/jar file can be changed.

Custom Jobs

 

Only new Job Steps and Schedules may be added to an existing Custom Job.

 

For any other change which is not possible for an existing object in Production, creating a new process version and using a new object will be necessary.

 

5. New business keys

When defining new business keys, make sure that the data in Production complies with the new restriction. Otherwise, applying the business key in Production will throw an error during the deployment procedure (to protect your Production environment and make sure its data integrity).

For example, if you have an entity called "Product", do not define that its column ProductName as a business key if you see that in the Production environment there is more than one Product record which has the same ProductName.  If, for instance, the ProductName column has multiple instances of the value "Credit" its values are not unique. The column cannot be used as a business key.

Click for more information about Predefining business keys.

 

6. Previous configurations must remain compatible

Do not alter any of the required configurations involved in your previous deployments.

 

This means that your database instance should not change its collation (applies to SQL Server) or the configured character set (applies to Oracle).

 

If you need to move your Production server to a different server, do so by using the Server management options presented by Bizagi in its Management Console.

Click for more information about Server management through the Management Console.