Upgrading Flows That Are Already In Production
Once an application is in production, developers must take care when updating flow rules already in use. Some developers mistakenly test such changes (in a development system) with only new work objects. Later, when their updated — but poorly-tested —flow rules move to production, the assignments on older, existing work objects fail.
Failure to consider open work objects progressing through updated flows can result in problem flows, stuck work objects, assignments in error, orphaned assignments, and other errors.
This article lists the advantages and disadvantages of four approaches to this design issue. Choose the approach that best fits your needs.
Pega Platform lets you "build for change." This means that existing assignments and work objects in the system automatically pick up many of the latest changes to your flow rules.
For instance, if you update a flow rule to add an additional local action to an assignment shape, users can perform the new local action for existing assignments in the production system, even assignments that were created long before you changed the flow rule.
Each assignment object (such as instances of the Assign-Worklist or Assign-Workbasketclass) records the following information about their parent flow rule:
- pxTaskName— The Visio-generated shape ID of the assignment shape it is linked to.
- pxTaskLabel— The developer-entered text label of the assignment shape.
- pyInterestPageClass - The first key part of the flow rule (pyClassName).
- pyFlowType — The second key part of the flow rule.
As you can see, the pzInsKey of the flow rule, which uniquely identifies the rule, is not stored, by design.
What sorts of changes to a flow can cause problems?
- Removing an assignment shape for which one or more open assignments exist. The old assignments become "orphans".
- Replacing an assignment shape. If you remove an assignment from the flow diagram and later replace it with a new assignment giving it the same name, internally it may have a distinct name. Flow processing relies on an internal, Visio-generated name for each shape.
- Removing or replacing the other wait points in the flow, such as the Subflow shape and the Split-for-each shape. If you examine an embedded flow page of a work object, you'll see that it keeps track of the shape ID in the parent flow.
Approaches to safely changing flows
No approach among the following is always best. Each configuration and business setting is is different and so you must choose the one that best fits your needs.
Approach 1: Create distinct flow rules, either by choosing new flow names or by circumstancing, leaving the old flow ones as they are.
Copy and clear the Creates a new work object check box on the old flow rules, and check the Creates a new work object box on the new flow rules, so that new work objects are based only on the new flows.
If you choose circumstancing, you probably want the default v to be the new flow (in the higher version number), and the circumstanced version to be the older one. You'll probably want to use date circumstancing as opposed to property circumstancing.
After these changes are moved into production, the New Work gadget will then list only the new flow rules, and new work objects will thus execute using the new flows.
|Advantages||This is straightforward to implement, provided your flows aren't too deeply nested with subflows.|
|Drawbacks||After a few releases, your set of flow rules will grow and maintenance may become difficult, especially if a mix of assignments pointing to the various versions is in production. This approach is not recommended if your changes require you to modify 4+-level deep subflows.|
Approach 2: In the updated flow rules, leave all the old flow wait points unchanged. (Assignment, Subprocess, Split-for-each). Drag these shapes off to one side.
To ensure that flow processing does not drop these shapes when the flow rule is saved, add a placeholder ticket that connects to these shapes. Keep their outgoing connectors intact.
This way, new work objects never reach these outdated shapes, but the work objects at older assignments will still follow the same path.
At some point later, you can run a report that checks whether the old assignments are no longer in use. If so, you can then remove the flow wait points in the next version of the flow.
|Advantages:||This allows all your work object to use the same rule names across multiple versions|
|Drawbacks:||This may not be a feasible solution depending upon your configuration changes. This approach produces cluttered Visio diagrams.|
Approach 3: Add tickets in the newly modified flows to control where processing of each type of old assignments is to resume processing. Run a bulk processing job that finds all the outdated assignments in the system. For each assignment, the bulk processing should call Work-.OpenAndLockWork, then call Work-.SetTicket on the work page.
|Advantages:||Leaves your flow rules clean. Best accomplished as an overnight job.|
This approach may be impractical if the set of assignments is too large, or if there is no moment when the background processing is guaranteed to acquire the necessary locks.
Also, an administrator may have to run this bulk processing activity several times until all the assignments are successfully locked and updated.
Approach 4: Revert the user's RuleSet list to the original, lower versions when dealing with the older assignments.
|Advantages:||When the changes between versions go beyond just the flow rules, this is the only sure approach.|
|Drawbacks:||This may easily have unintended consequences, where desirable fixes in the higher RuleSet version aren't executed because the user's RuleSet list is too low to include them.|
Using one or a mixture of these approaches allows you to successfully navigate the challenge of updating flow rules that are already in production.
The most important thing to remember is to always test updated flow rules with existing work objects, not just newly created work objects.
If you do encounter problems and some assignments become problem assignments, utilize the problem assignment list view to make bulk fixes as necessary. In V5.1, you can access the problem assignment list view from the Developer portal. Select View > System >Assignment Errors. ( In older versions you can also access it from the Problem Work link on the Dashboard.)
NOTE: As noted above, if you remove an assignment shape and replace it with a new one but keep the label the same, the internal Visio ID changes. In flow rules first saved before V4.2, the label and Visio ID are often the same, but since V4.2 added assignment shapes have an ID like "ASSIGNMENT51".
So an error message such as "The task ‘Development’ cannot be found in this flow” can be confusing, because you see that the label is unchanged, but the error reports the Visio ID, not the label.
100% found this useful