Discussion
Cognizant
GB
Last activity: 5 May 2017 18:51 EDT
Same case vs Sub case parallelism
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?
Pegasystems Inc.
IN
please refer OOTB flow implementation if we could leverage...
RULE-OBJ-FLOW WORK- STANDARDREQUEST
esp: RULE-OBJ-FLOW DATA-PARTY PARTYAPPROVALMAJORITY
1. split join is also other option...
2. DWA
3. Email work driven process
4. Workgroup manger manually routing the assignment to individual approvers
Cognizant
GB
Hi,
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?
Pegasystems Inc.
IN
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)
Pegasystems Inc.
US
In 7.1 you do not need to override DetermineLockString.
Click on a subcase in the Case Designer then click on "Locking".
Check the box labeled "Do not lock the parent case when the child case is opened".
One way to avoid locking issues entirely is to use "Calculations" within the Case Designer.
You could define Integer ".ApprovalCount" and ".RejectionCount" Properties that are pattern-inherited by both the parent case and the subcase where voting is performed.
The parent case would define ".ApprovalCount" as the sum of the the subcase's ".ApprovalCount" values and".RejectionCount" as the sum of the subcase's ".RejectionCount" values
If Approve is selected, ".ApprovalCount" would be incremented, otherwise ".RejectionCount" would be incremented.
In 7.1 you do not need to override DetermineLockString.
Click on a subcase in the Case Designer then click on "Locking".
Check the box labeled "Do not lock the parent case when the child case is opened".
One way to avoid locking issues entirely is to use "Calculations" within the Case Designer.
You could define Integer ".ApprovalCount" and ".RejectionCount" Properties that are pattern-inherited by both the parent case and the subcase where voting is performed.
The parent case would define ".ApprovalCount" as the sum of the the subcase's ".ApprovalCount" values and".RejectionCount" as the sum of the subcase's ".RejectionCount" values
If Approve is selected, ".ApprovalCount" would be incremented, otherwise ".RejectionCount" would be incremented.
Note that the Case Designer.supports an "Approval" step type that allows you to change stage based on the Approve/Reject decision.
Cognizant
GB
Thanks for your response Phani and Lee
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?
Pegasystems Inc.
US
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.
Pegasystems Inc.
IN
if we can foresee that approver functionality could grow ... we can build the functionality using sub cases.
if it is just to record a comment & count the decision ... we can manage it within the main flow...
@pedel - could you please share your thoughts...
Pegasystems Inc.
US
If the main case merely waits for the voting process to complete - no work needing to be performed in parallel - plus the vote is not something each user would dwell over - fine.
Still user experience is affected by locking constraints. Some users may be annoyed by a "case is currently locked, try again later" error message.