Pega8.5 Case design patterns
Hi
Can anyone please help me in understanding the case design patterns mentioned in pega8.5 with real-time examples or implementation.Thanks.
- Divide and Conquer (most common)
- Enrollment/Add a Task to a TODO list.
- Data Instance First
- Limited Availability and concurrency
- Sibling cases, one updating the other
Pegasystems Inc.
IN
Please refer the CLSA architecture mission 8.5 , for detailed explanation with examples
Infosys Limited
US
@AneeshaG Thank you. I've gone through this. It doesn't have any realtime implementation scenario for TODOList ,Data Instance first & LimitedAvailability&Concurrency . Want to understand more on the scenarios where these patterns can be chosen.
Updated: 5 Oct 2021 9:57 EDT
Pegasystems Inc.
IN
Enrollment/Add a Task to a TODO list.
Eg: Case types like Issue an Accreditation for Organization. There can be several checklist items to be evaluated and confirmed for Accreditation. Not all checklist items require a child case. All we need to do then is create a data instance for these checklist items. Say 5 checklist items are corresponding to a site visit, combine them and show them in one assignment. The next 5 checklist items are related to Finance, group them to another assignment. These checklist items are TO-DO items and all the user has to do is mark them complete.
Data Instance First
Eg: Consider a service request to Register a new member. If we leverage mashup with Create New Case, for every request we will end up creating a Registration case. Instead, it may be important to validate whether all information is accurate. If the user record already exists. It is good practice to create a data instance first and then process them to create a case. Also, you will have an advantage over the genuine number of requests.
Limited Availability and concurrency
Eg: Consider train reservations. The concurrent requests during holidays could be higher than usual. Capturing every request as a data instance, and keep allocating seats incrementally whilst the rest are in a waiting period solves the problem of over-booking.
Morgan Stanley
IN
I have a query regarding Enrollment/Add a Task to a TODO list.
The description mentions that,
A major benefit of this design pattern is that locking issues are avoided. For example, a data instance can be created that references an existing case instead of making a child case of the current case. Data is inserted; nothing is updated.
But how can one update the data instance which is tagged to the work object without taking a lock on the work object.
Also, how can SLA be tagged to data instance.
Can you please mention a better scenario of how to design such a application.
Updated: 7 Mar 2022 11:20 EST
Pegasystems Inc.
US
When a data instance that references a case is inserted into the database there is no need to lock the case. The foreign key to the case, its pzInsky or pyID - whichever you prefer, is just a value. The case being referenced does not need to be updated.
There is no reason to define an SLA for a data instance. It is possible to do that since the ORG class extends Work-Cover but, again, no reason for the data instance to have its own SLA.
Guessing you are wondering how a case COULD BE updated after a data instance is inserted into the database.
At the same time that a data instance is committed, a Queue Processor could also be committed that uses the data instance as it step page when the Queue Processor (QP) "wakes up". The QP could attempt to lock the referenced case then ether update the case or tell the case to perform an action.
The LSA course mentions and includes in its sample solution a Work Queue Approval component. Suppose a newer version of that component.
Currently the Work Queue Approval component uses an embedded .Approvers page list.
When a data instance that references a case is inserted into the database there is no need to lock the case. The foreign key to the case, its pzInsky or pyID - whichever you prefer, is just a value. The case being referenced does not need to be updated.
There is no reason to define an SLA for a data instance. It is possible to do that since the ORG class extends Work-Cover but, again, no reason for the data instance to have its own SLA.
Guessing you are wondering how a case COULD BE updated after a data instance is inserted into the database.
At the same time that a data instance is committed, a Queue Processor could also be committed that uses the data instance as it step page when the Queue Processor (QP) "wakes up". The QP could attempt to lock the referenced case then ether update the case or tell the case to perform an action.
The LSA course mentions and includes in its sample solution a Work Queue Approval component. Suppose a newer version of that component.
Currently the Work Queue Approval component uses an embedded .Approvers page list.
Suppose instead each Approver page is persisted as a data instance that references the case being approved. A Queue Processor initiated at the same time that the data instance is persisted could lock the case then ask it to see if any threshold, approval or rejection, has been met. If the approval threshold is met, the case would move forward; if rejected the case would move to an alternate Rejection stage.
Suppose two approvals, neither locking each other when data is entered, are submitted at the exactly the same time.
The first background process to lock the case "wins". The second background process has to retry. By the time that the second background process retries, the case may have moved on. The second background process can then simply exit without doing anything.