Important Notes
Process design evaluation at runtime:
It is important to understand how process execution is handled at runtime and the order in which rules are applied to a workflow. You may need to perform a GoToActivity in some cases to ensure that migrated process instances reflect the changes correctly after migration.
Consider the sequence of events for an activity when it is instantiated:
- Preceding Rule
- Start Rule
- Escalation Rule (escalation action will only fire of the activity is not completed by the time the escalation time has elapsed)
- Destination Rule
- Activity Actions and Outcomes
- Events (in the same sequence in which they appear in the process design) – wait for events to complete
- Succeeding Rule
- Lines
Depending on where changes have been made to the process definition, it may be necessary to redirect any current process instances to the same activity or to previous activities in a workflow to take advantage of the updated process definition. Note that the SetProcessInstanceVersion method does NOT contain logic to control expiration, redirection or recreation of activities – it is up to the developer to control process flow when the process definition is changed.
Example 1: (note: this scenario does not reflect Best Practice since the destinations are hardcoded, so this example is only for illustrative purposes)
A process definition has a specific user hardcoded as the destination user for an activity. Several instances of the process are created, and worklist items are created for the user. During this time, the original user leaves the organization, and the process definition is updated so that the original user’s replacement is the new destination user for the activity. You can migrate the existing instances of the process to the new definition, but the worklist items will not appear on the new user’s worklist – the reason is that the DESTINATION RULE for the activity in question has already executed.
In order for the worklist items to appear on the new user’s worklist, you will need to perform a GoToActivity call on the existing instances after migrating the existing instances to the new version of the process definition. You will specify the current activity name as the activity to go to – this will force K2 to recreate the activities from scratch, and all the rules will be reapplied to the activity in the sequence mentioned above. Therefore, the new destination rule is executed and the worklist items will appear on the new user’s worklist.
Example 2:
Business rules regarding approvals are changed – instead of 3 approvals being required, only 2 approvals are required. The developer updates the process definition accordingly, by changing the succeeding rule for the activity in question. There are, however, several active instances of the process, which still use the old business rule.
The developer can use the SetProcessInstanceVersion method to force the existing instances to use the updated process definition. Since the SUCCEEDING RULE for the activity has NOT YET executed, it is NOT necessary to perform a GoToActivity call for the migrated instances – the new rule will be applied when each user takes their action on the worklist item.
Example 3:
An additional action and outcome are added to an activity “Activity1” that contains client events.
The developer can use the SetProcessInstanceVersion method to force the existing process instances to use the updated process definition. For all instances that already have an existing instance of the “Activity 1” activity, the developer will need to use the GoToActivity method to force a recreation of the “Activity 1” instance, so that the new actions and outcomes rules are evaluated, the worklist items are recreated and the new actions are made available on the destination users’ tasklists.
Supported and unsupported scenarios for changed process definitions:
Developers should pay careful attention to the list of supported and unsupported changes when migrating between process versions. A rough guide is that REMOVING of items from workflow definitions are NOT supported, while ADDING items to workflow definitions are generally supported. Refer to the following lists for specific items:
Supported Changes:
The following process definition changes are supported when migrating between process versions:
• Adding the following to the process definition:
- Activities
- Activity Escalations
- Lines
- Events
- Data fields
- Xml fields
- Actions
- External assembly references
• Changes to the following:
- Rerunning the wizards with new values.
- Actions and Outcomes
- Code logic
- Destination Users
- Destination Rules
- Updating assembly references
Unsupported Changes:
The following process definition changes are NOT supported when migrating between process versions:
• Removal of the following from the process definition:
- Activities
- Lines
- Events
- Data fields
- Xml fields
- Escalations
- Actions
• Renaming the following within the process definition:
- Activities
- Lines
- Events
- Data fields
- Xml fields
- Escalations
- Actions
• Changes to any of the following:
- Environment Fields (String Tables)
- retroactive Activity Slot count
- retroactive Activity Plan Option’s
- retroactive process escalations
Impact on reporting when migrating instances between different versions of a process definition:
Standard Reporting
The standard K2 blackpearl reports do not support all possible process version migration scenarios. While some reports may reflect the process changes accurately, depending on the changes applied the report may display unexpected information.
Process audit entries and history are still stored in the K2ServerLog database, so it is possible to build custom reports that can display migrated process instances accurately. The ProcInst table links back to the ProcInstRevision table to show that the process instance has run on definition 1, 2 or 3, etc. There is also an additional entry in the ProcInstAudit table to show when the migration happened and who was responsible for the change.
View Flow Reports
The view flow report will ‘overlay’ activities in new process version over the activities from old process versions. The following screenshots illustrate the effect of process migration on the viewflow report:
|
Figure 1. Process Definition Version 1 |
Figure 2. Process Definition Version 2 |
Figure 3. View Flow Report Before Migration |
Figure 4. View Flow Report After Migration |
