Inclusive and exclusive queries
Scenario
Suppose a case needs to be reviewed by multiple independent reviewers. It can be solved in the following ways:
- Create a child case for each reviewer
- Create the same case with Split For Each for each reviewer
Assumption: When a review work queue assignment is fetched and moved to the reviewer’s worklist, the reviewer is immediately persisted as the child case’s reviewer work party, for example, pyWorkParty (Reviewer).
The parent of the case that the work queue assignment references should not match any parent of a child case that the reviewer has previously fetched.
- A child case is created for each of the N-required reviewers. The initial assignment in each child case is a work queue assignment. Each reviewer asks the system to pull a Review work queue assignment into their worklist.
The figure illustrates the how the case, child case and reviewers are linked. It also depicts that when a reviewer pulls the child case, it moves to his worklist and he becomes the workparty of the case.
- In other words, if sub-flows are created by using Split-For-Each instead of spinning off child cases, the following query prevents the same reviewer from using GetNextWork to pull work queue assignments for a case that the reviewer has already.
The figure illustrates the how the case, sub process assignments created by split for each and reviewers are linked. It also depicts that when a reviewer pulls an assignment from work queue using Get Next Work, it moves to his worklist and he becomes the workparty.
Solution design
|
select pzInsKey from |
Suppose that the case is two levels above the case to be fetched by a reviewer. Cases do not possess a pxCoverCoverInsKey property. Still, you can define that property but use a more meaningful property name. If the case to be reviewed is a Claim, you want to define a work pool-level property named ClaimKey. The parent and grandparent Claim case sets ClaimKey equal to its pzInsKey and propagates ClaimKey property to its child cases. Likewise, those child cases also propagate the ClaimKey property to their child cases.
Propagation of data assumed to remain static also simply the definition of Access When rules. Care must be taken with this approach as it is possible, however unlikely, that the information can become stale or inaccurate. For example, the parent case of a child case can be altered when the pxMove activity is invoked. This scenario is an example where a data integrity violation can potentially occur.
An alternative is to perform what is known as a hierarchical or recursive query, which each database vendor implements differently but is not supported by the Report Definition rule.
Interestingly if the goal is to avoid the same person reviewing the same case twice, and the case design does not involve child cases, the query above works just as well if the word Cover is removed. If subflows are created using Split-For-Each instead of spinning off child cases, the following query prevents the same reviewer, using GetNextWorkFrom pulling a work queues assignment for a case that the reviewer has already reviewed.
| select pzInsKey from {Assign-WorkBasket} WB, {Org-App-Work-Review} REV where WB.pxAssignedOperatorID = [workqueue] and WB.pxRefObjectKey = REV.pzInsKey and REV.pxInsKey not in (select REV2.pxInsKey from {Org-App-Work-Review} REV2, {Index-WorkPartyUri} WP where WP.pxInsIndexedKey = REV2.pzInsKey and WP.pxPartyRole = "Reviewer" and WP.pyPartyIdentifier = OperatorID.pyUserIdentifier); |
This Topic is available in the following Module:
If you are having problems with your training, please review the Pega Academy Support FAQs.
Want to help us improve this content?