Authored by Sumanth Polu
This document describes the scenario where an application has several case types that need to form a case hierarchy at run time, but the parent-child relationships are not known at design time. Standard child case types are defined in parent case types and internal validation runs to ensure that a parent-child relationship is defined when creating cases at run time. For an application that can have hundreds of parent and child case types and parent-child relationships are constantly established by external business rules, the parent-child relationships must be dynamic. At run time, based on the configurations made in an external catalog, the relationships need to be established.
Use case for establishing a dynamic parent-child relationship
Consider the customer journey of fulfilling an order for a mobile phone that a customer has purchased. Individual case types required to perform the order fulfillment could be as follows:
- Acquiring the handset device from manufacturer (inhouse inventory management or a vendor order)
- Acquiring the associated accessories
- Assembling the device to a single unit
- Test of device hardware/software functionality
- Activation of inhouse or default services
- Test or troubleshoot of preloaded services
- Billing
- Supporting Vendor child cases (if any)
- Network provisioning (if required)
The above cases can extend or alter as per the order request or different offerings combinations available in the catalog and we cannot define what must or cannot go in a customer order at design time. Few orders might not require the inhouse services or activation of them and hence testing of them is not needed. Few orders might not include the accessories in the order. Other orders might need the network provisioning and hence subcases to reserve any numbers that are needed.
Pega Platform™ provides an option to explicitly define the child cases for a particular case during design time in the Child case types section of the case type rule without which runtime errors occur when users try to create child cases by using pxAddChildWork API.
For the scenario where the parent-child relationship (to be established for smooth processing of the customer order-delivering a mobile phone) is not known (at design time-while modeling the individual case types) as described in this use case, the following approach can be used.
Solution for establishing a dynamic parent-child relationship
Using createworkpage and addwork api together can help in establishing parent-child relationships passing the appropriate instance class and cover page fields to these APIs. These APIs do not perform the validation check to see whether the case is defined as child case in the case type rule.
The order can be as follows:
- CreateWorkPage
- AddWork
- Commit
Configurations and their descriptions for the API are shown in the following images:
PrimaryPageName – Page of a parent case class
PrimaryPageKey – pzInsKey of a parent case
workPage – Primary page of a child case class to be created. Because context issues were noticed during recursive child case creation, making ChildFulfillmentCase page as unique for each creation iteration would help.
ClassName – Class name of a child case instance to be created. This class name has been captured from the fulfillment catalog stored in local.
PropagateCatalogData – Data transform for setting the initial/default values to the child case to be created. This API uses the DT stated in ModelToUse or (if no DT mentioned for this attribute) uses the one from FlowType or of the InsClass.
FlowType – sets to pyFlowName of to be created workPage (ChildFulfillmentCaseXXXXXXX)
To establish parent-child relationships, cover page and cover keys are passed into CoverPage (for createworkpage API) and CoverHandle (for addWork API).
CoverClass is only known at run time, therefore the field above is left blank.
Commit the newly created workPage to persist it to the database.