Question
Tech Mahindra
US
Last activity: 12 Feb 2021 2:13 EST
Force Save for backend synchronous case creation
Hi All,
Use case: User action on parent case, creates a child case in a synchronous call. However some times during the middle of child case flow, page messages are getting set which is causing the Parent and child case to not save in DB. We need to force DB save of the child case so that if anything fails, the case data will be available as exception handling to debug this issue in PROD.
For force saving the data first time (when pzinskey is blank). I added a Data Transform in the start shape connector in first flow of the first stage of the child case type and tried below options.
- Calling Obj save with write now (gives commit error on submit of parent case)
- Calling persist case (does not save the data in DB)
- Calling Commit with acquireWorkObject (gives commit error on submit of parent case)
Is there any way to force save child case in DB without getting lock or commit errors.
Kind Regards,
Ankush
Pegasystems Inc.
FR
I think I would use an Assignment shape. You can assign to a hidden WorkBasket just to save the record and then resume the flow with an SLA agent to continue the processing.
If it breaks, it will get back back to hidden assignment, you should be fine to work on it from there.
Tech Mahindra
US
Thanks for your reply. Our flow needs to be synchronous and should not stop for SLA to continue processing.
Infosys
NL
@AnkushS8011 : What exactly you mean by synchronous ? Do you want the child case ID details back to your parent case or Do you want the user to see a screen in child case ? I agree with Marc's suggestion of using an assignment/wait shape at start of child case. It would make sure no error in child case processing impact the case creation logic.
Pegasystems Inc.
AU
If the page messages are being added by Pega OOTB rules, then providing a configuration that allows the subcase to continue despite there being errors is dangerous. Subsequent rules invoked have an increased likelihood of failure if the preceding rules failed to complete successfully. This is a clear signal from Pega that the flow should not progress and that the case management should halt.
If the page messages are being added by a custom rule, or a custom rule from the subcase flow is orchestrating the calls to OOTB rules that are putting messages on the page, so long as your custom rule that is invoked from flow processing finishes execution with no messages on the page, Pega's flow processing will continue to move forward. In this case, so long as you
- Gather the page messages and put them somewhere on the case data model;
- Execute the Page-Clear-Messages activity method (assuming you are in an activity) before completion of your rule;
Then the flow will keep moving forward:
If the page messages are being added by Pega OOTB rules, then providing a configuration that allows the subcase to continue despite there being errors is dangerous. Subsequent rules invoked have an increased likelihood of failure if the preceding rules failed to complete successfully. This is a clear signal from Pega that the flow should not progress and that the case management should halt.
If the page messages are being added by a custom rule, or a custom rule from the subcase flow is orchestrating the calls to OOTB rules that are putting messages on the page, so long as your custom rule that is invoked from flow processing finishes execution with no messages on the page, Pega's flow processing will continue to move forward. In this case, so long as you
- Gather the page messages and put them somewhere on the case data model;
- Execute the Page-Clear-Messages activity method (assuming you are in an activity) before completion of your rule;
Then the flow will keep moving forward:
- Once the subcase reaches an assignment and goes idle (or is resolved), control returns to the parent case which proceeds with its flow processing.
- Once the parent case reaches an assignment and goes idle (or is resolved), the Pega engine commits all the deferred saves from that interaction in one block.
Resist the temptation to issue any sort of Commit or Obj-Save/WriteNow from your own rules. Errors that occur after a custom Commit/WriteNow and before an idle point can only roll back to your custom (interim) commit point and the cases will be broken.
Consider in your "catching" of the messages to change to an Alternate Stage which creates an assignment close to its start. The fewer OTB rules you invoke after a failure the better.