Sync on Change Request Submit
Each of the following robots has been converted to an object event synchronization robot as described below:
|
Template
|
Robot
|
|
Change Investigation Process
|
Sync on Request Submit
|
|
Change Analysis Process
|
Sync on Request Submit
|
|
Change Proposal Process
|
Sync on Request Submit
|
|
Change Order Process
|
Sync on Request Submit
|
|
Change Activity Process
|
Sync on Request Submit
|
Before Release 5.1, the expression logic performed the following actions:
1. Determine the parent change request by navigating one or two levels of associations based on the change object:
◦ For a change investigation or change proposal, navigate the ResearchedBy association.
◦ For a change order, navigate the AddressedBy2 association.
◦ For an analysis activity, first navigate the DetailedBy association to obtain a change investigation or change proposal, then navigate the ResearchedBy association.
◦ For a change activity, first navigate the IncludedIn2 association to obtain a change order, then navigate the AddressedBy2 association.
2. Determine the current life cycle state of the change request.
3. Determine the current value stored in the Complexity attribute (for Sync on Request Submit only).
4. Based on the results of step 2 and step 3, either continue holding or move on to one of several possible activities that follow in the workflow.
The following changes have been made to this logic:
• A new process variable named parentChangeRequest has been introduced in each workflow. It holds the parent request and is initialized when the workflow begins through a transition expression on the process Start transition.
• The following figure shows the expression synchronization robot as it existed before Release 5.1.
This robot has been replaced with a conditional router followed by the sync robot. The new robot, which has been changed to an object event synchronization robot, is shown in the following figure.
The object is the new change request process variable just described. The event is STATE CHANGE in each case. The conditional router contains exactly the same logic as the expression in the object event subscription robot. The purpose for this conditional router is to immediately check whether the state has already been reached. This helps avoid the race condition of the state being achieved prior to the instantiation of the synchronization robot. (In both figures, the parentChangeRequest variable is assumed to be initialized already.)
• The expression in the object event synchronization robot and conditional has been changed to use the workflow variable parentChangeRequest directly, rather than access the database repeatedly to determine the parent change request.
These changes resulted in the following performance improvements:
• Lookup time during each execution of the synchronization expression has been shortened as a result of saving the change request in a workflow variable.
• The synchronization expression executes only after the state of the change request has changed. As a result, there is a very good chance the proper state has been reached each time the expression runs.