Authored by Vidya Menon
Defining case dependencies at run time
Pega Platform™ provides the option to define Wait shapes to handle case dependencies between parent and child cases. These dependencies should be known at design time so that they can be configured in the appropriate Wait shapes. To learn more about using Wait shapes for case dependencies, see How to use the Wait shape to create mid-process dependencies.
Use case examples
No feature is available out of the box to handle dependencies that are known only at run time. Consider a use case of an order fulfillment scenario, in which multiple cases need to be created as child cases to a parent customer order case. Because of dependencies between the cases, a case can start only when another case is resolved. For example, a case related to ‘Installing a part’ can start only after the case related to ‘Ordering and delivering the part’ has completed. In this scenario, the second case needs to wait until the first case is resolved. Further, the dependencies of the cases are maintained in an external catalog application. When a case is created, this dependency information can be made available from the catalog application. This use case can be handled in the manner described in this article.
Creating a page list to store the dependency details
For each case, a page list property can be created to list the dependencies for which the case needs to wait. During case creation, this list can be obtained from any external system that stores this information by using a data page. Each page in the list should contain information such as the ID of the case for which it is waiting, and whether the dependency on that case has been met, i.e. whether or not the case is resolved yet. This is what the case clipboard would look like for a case that is dependent on two other cases to be resolved:
pyWorkPage
Dependency(1).DependentOn = “C-XXX”
Dependency(1).DependencySatisfied = “false”
Dependency(2).DependentOn = “C-XXX”
Dependency(2).DependencySatisfied = “false”
Managing dependencies at run time
When a case is created, the page list should be initialized with the dependency information as shown above. The DependencySatisfied property will be false at initialization. If there are any pages in the page list, then the case should be moved to a dependency stage, which can be an alternate stage in the case design. For more information, see Creating an alternate stage.
An alternate stage can also have an assignment, so that a case waits until it is moved out of the stage programmatically.
Case resolution and updating dependencies
You can create a generic resolution stage for cases. For more information, see Configuring a case resolution.
The resolution stage can contain an activity that finds the top-level case and loops through all of its covered cases, and checks whether the Dependency page list property contains a page that has the ID of the case being resolved in the DependentOn property. If so, the activity sets the DependencySatisfied property to true. The activity then needs to check whether there are any other pages in the list that have DependencySatisfied as false. If there are, the case continues waiting in the alternate stage for some other case to be resolved. If not, the activity moves the case from the dependency stage to the next stage using the pxChangeStage API.
Setting up a queue processor
When a case is being resolved, it needs to open other cases to move through the stages if all dependencies are satisfied. If the case is open and locked by another requestor, then the system cannot obtain a lock to perform a stage change. Therefore, Pega recommends that you use a Queue Processor activity to perform the dependency-related resolution steps detailed in the section above, so that the process can be repeated if a lock scenario is encountered. For more information on setting up queue processors, see Running a background process.