Suppose there is a scenario that a user fills in a form and then submits it for it to be approved by say 3 reviewers who has a view of what has been filled in and approve/reject the case independently and based on the approval/rejection status ,the case will follow a specific path down the line.
From a PEGA best practice point of view , what approach should be taken to implement such a scenario?
I could think of doing it in two ways but from a Best practice perspective, I am not sure which one is the better option or if there is another efficient way of doing it.
a)Use split-for each to spin off three assignments on the pyWorkParty property defined for the reviewers and set the pyApproval property depending on whether the reviewer has approved or rejected the form.Once the main flow is resumed, check the pyApproval property on the pyWorkParty based on pxPartyRole=Reviewer and route the main case accordingly.The issue with this approach is that no two reviewers can work on the case at the same time.
b)Spin off sub cases which will route to the reviewers and override DetermineLockString to take care of the locking contention issue. But how do we propagate the result of the reviewer to the main case as approval/rejection isn't an aggregate property.Hence we would need to create two properties approval count and rejection count and propagate them upstream depending upon the reviewers' decision.Also does it warrant creating a sub case which will only take care of an approval process?
For using OOTB flows such as PartyApprovalMajority, are you suggesting to use them via sub case or from the main case? If the flow is used in the main case,then no 2 reviewers can work on the same case at the same time.And if used from a sub case, how do we tackle the up stream data propagation of the decision without creating new properties?
are you suggesting to use them via sub case or from the main case?
Main case itself...
If the flow is used in the main case,then no 2 reviewers can work on the same case at the same time
true... need to acquire lock on access...
if used from a sub case, how do we tackle the up stream data propagation of the decision without creating new properties?
a property will be required to save the majority count and the approver comments. can we try these from calculations tab of case type rule....? as you said, we need to either use optimistic lock or override DetermineLockstring (which is now in Pega 7 can be configured from case type rule)
From PEGA best practice perspective, which approach should be followed?
Also, in order to get around the locking contention does it make sense to create a sub case in which the only thing being performed is an approval step with regards to the scenario that I stated above?
IMHO there is no "size minimum" for subcases on the condition that small special-purpose cases be designed for reuse - either encapsulating special-purpose functionality in a "component" ruleset or implemented within an enterprise-level ruleset.
Suppose a special ruleset that provides a way to edit an Attach-and-Hold email prior to it either being sent at a scheduled time in the future or sent immediately after editing? That functionality could be used in a subcase. After the email is sent the subcase resolves. The parent case could be configured to have an AllCoveredResolved Ticket resume the parent case's flow.
Best Practice is reusability. Reusable code makes other code easier to develop and maintain.