From Business Process Management, BPM and Workflow Automation Wiki | BizAgi BPMS

Jump to: navigation, search

<keywords content="keywords"> process improvement, after production, development, new version, continuous improvement, process development, after deployment, subsequent deployment, subsequent deployments, deployment, process version, versioning, recommendations </keywords>

Continuous improvement and development after a deployment

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, interfaces or even changing the flow of the process itself.

Depending on the necessary changes, it is advisable to generate a new version of the process. This is a safe way to make changes without compromising the information of the current cases that are already in Production.

Changes that have to be performed to a process that is already in the Production environment, should always be performed in the Development environment (and taken to Production by making a new deployment). Keep in mind that it is always recommended to make use of the Test environment to perform deployments of your processes versions before deploying them to Production.
This way, you can always check and adjust your processes so that they cover the expected behaviour (as it will be applied in Production).

Alert: Never restore databases backups of other environments over the Production environment. Always use Bizagi's deployment procedure to apply changes of your project into another environment.
The deployment executed by Bizagi will ensure that all the business information in the Production environment is kept consistently.
Backups of your environments' databases can be taken (and should be taken) only as a contingency measure.

For continuous improvement of your Production processes and subsequent deployments, take into account the following facts:

1. Objects in Production must remain in Development

Once a process is deployed to the Production environment or is currently marked as Release Candidate in the Test environment, it is not possible to delete any of those objects used by that process version in the Development environment.
Objects include: entities, attributes and relationships, forms, business rules or policies, performers assignments ("assignation rules"), user fields, systems, organization definitions, amongst others.

Similarly, it is not possible to modify the "Name" property of these all the objects used in Production (that is, changing their name).
This is restricted in order to guarantee the stability of the Production environment in a subsequent deployment.

2. Edition in Development of 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) will control the edition possibilities for those 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 Production environment or marked as Release Candidate, Bizagi Studio keeps the following edition options for its used objects in the Development environment, as detailed in the table below:

Object	Options
Entities and Attributes.	Entities and attributes-relationships will not be 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, behaviours, validations or actions will not be possible). Forms may be cloned, and also it will be possible to define which form is the current form for an activity.
Userfields.	Only its code may be edited (and its description property).
Custom Functions.	Only its code may be edited (and its description property).
Expressions (boolean, scripting).	Its code may be edited (and its display name or description property).
Performers Assignments ("Assignation Rules").	All properties and definitions for the assignation rule of a task may be edited.
Interfaces invocations	Web services invocations may be configured again through the interfaces wizard.
Dimensions	All its properties may be edited (except its Name).
E-mail 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 for its sending off may be edited as well but not deleted.
Letters.	Its content may be edited.
Organization definitions.	Only the display name of the elements defined for the organization may be edited (e.g., Areas, Roles, Skills, User groups, etc.).
Holiday Schemas	Only the description of the defined holiday schemas may be edited.
Custom Jobs (applies for the Enterprise editions)	Only new "Job Steps" and "Schedules" may be added to an existing Custom Job.
Component Library (applies for the Enterprise editions)	Its registered assembly can be changed.
Authorization and Security	Changes can be performed in the production environment through the Management Console. Changes in development will always be taken to the production environment overwritting the production configuration.

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 process is locked so that it is not possible to edit the workflow model for that specific version.
This implies that the process' version cannot be edited by using the Process Wizard's step 1 (addition, edition or deletion of shapes or transitions is not possible).
If you wish to make these type of changes to the workflow model, then you must create a new version of that process (and its subprocesses).
On the other hand, it is possible to choose not to create a new version of the process if the required changes are somewhat:

Adding a new attribute or entity.
Adding or editing business rules (action events, performers assignments, web services' invocations).
Creating a new query form.

In other words, a new version is not required if changes can be made through the Process Wizard from steps 2 and later.

Take into account that changes in the current version (without creating a new one) would apply in the Production environment, directly to the existing cases.
Thus, in this scenario it is even more important that proper tests and cautions are taken into consideration in order to avoid consistency errors for those existing cases.
View further information about the guidelines and recommendations for a new version of a process.

4. New business keys

When creating new business keys, it is recommended to ensure that the data in Production complies with this new restriction, otherwise the business key will show an error during the deployment procedure (in order to protect your Production environment and ensure its stability).
For example, if you have an entity called "Product", do not define that its column "ProductName" should be a business key if you see that in the Production environment there is more than one Product record which has "Credit" as its ProductName.

5. Database collation un-altered

Do not alter any of the database or database servers' collation. For your Bizagi projects, the server's collation and the database's collation must match (in order to make deployments), as well as the collation of the database servers in each of the project's environments.
This is a requirement that should be met from the moment the database server is installed and its databases are created.
Altering the collation of a database is not a good practice and can also corrupt the business information within the database.

Personal tools

Views

Process Development After Deployment

From Business Process Management, BPM and Workflow Automation Wiki | BizAgi BPMS

Contents

Continuous improvement and development after a deployment

1. Objects in Production must remain in Development

2. Edition in Development of objects in Production

3. Versioning processes

4. New business keys

5. Database collation un-altered

Related Articles

Search

Navigation

Toolbox