Discussion

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?

**Moderation Team has archived post**

This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.

Comments

Keep up to date on this post and subscribe to comments

Pega
November 20, 2015 - 12:57pm

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

November 20, 2015 - 1:07pm

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?

 

Pega
November 20, 2015 - 2:27pm

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)

Pega
November 20, 2015 - 3:59pm

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. 

 

May 5, 2017 - 6:51pm
Response to PEDEL

Nice Idea..Save my time.

November 20, 2015 - 4:05pm

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?

 

 

Pega
November 20, 2015 - 7:15pm

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.

Pega
November 21, 2015 - 12:03am

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...

Pega
November 21, 2015 - 8:17am

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.

 

 

November 21, 2015 - 10:40am

Thanks for your inputs guys.. Much appreciated  :)