View source for Establishing parent-child relationships of cases at run time

Establishing parent-child relationships of cases at run time / ← Establish parent-child relationships on case types at run time

You do not have permission to edit this page, for the following reasons:

• The action you have requested is limited to users in one of the groups: Users, editor, pegaemployee.
• The action you have requested is limited to users in one of the groups: pegaemployee, editor, Administrators.

---

You can view and copy the source of this page.

{{Design pattern|Title=Establish parent-child relationships on case types at run time|Description=Use case for establishing parent-child relationships on case types at run time|Version=8.x|Applications=Platform|Capability Area=Case Management|Owner=Sumanth Polu}} == Implementing a dynamic parent-child case relationship at run time == 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.[[File:Page for child case.png|thumb|page for child case to be created|Unique workpage for child case]] * '''Unique workpage for child case''' [[File:CreateWorkPage.png|thumb|CreateWorkPage]] ''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. * '''CreateWorkPage/AddWork''' [[File:AddWork.png|thumb|AddWork]] ''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''' ''Commit'' the newly created ''workPage'' to persist it to the database. == Related information == [https://community.pega.com/knowledgebase/articles/case-management/85/understanding-case-hierarchy Understanding case hierarchy] [https://community.pega.com/knowledgebase/articles/case-management/85/case-types Case type] [https://community.pega.com/knowledgebase/articles/case-management/85/creating-top-level-case-type Creating a top-level case type] [https://community.pega.com/knowledgebase/articles/case-management/85/creating-child-case-type Creating a child case type]

Return to Establish parent-child relationships on case types at run time.