Error handling approach when you modify work objects by bulk
Hi,
I have created a User Interface in a parent case screen where you can select and include other child cases. When submission, AddToCover Process API is called looping over child case list and things work fine, as long as child cases are not locked by anyone. If anyone is performing child case, that iteration fails, of course. However I want to avoid such situation and guarantee that these selected child cases are to be added to its parent case for sure.
I don't think this is specific to only parent / child use case, but in any situation where activity modifies work objects especially by bulk. How do people handle this situation? What is the standard approach or best practice for such exceptional case?
Thanks,
***Edited by Moderator: Pallavi to update platform capability tags***
Updated: 2 Jun 2020 1:30 EDT
Pegasystems Inc.
IN
Hi Cloe,
Thanks for posting the query.
1. If you are trying to modify multiple work objects then you can use the obj browse method in the activity and loop over the results.
2. As you want to modify the work object information you need to loop over each work object and use the obj-open method.
3. You can select the Lock option and ReleaseOnCommit option which acquires the lock on the work-object which you are trying to modify.
4. After modifying the work object, you need to save the WO information by the Obj-save with the commit operation. Once the commit is done, the lock on the work object gets released as you have selected the ReleaseOnCommit option in the obj-open method.
5. If there are any errors in the commit operation, you need to rollback the data. There is an OOTB activity: Work- commitWithErrorHandling which performs the commit operation and also perform the error handling (Rollback) when there is an error in the commit operation.
6. After obj-save is completed, just call this activity which takes care of the error handling if there is any exception in the commit operation.
Updated: 2 Jun 2020 2:26 EDT
IT Solution Service
SG
In my scenario, if child case is being performed by someone else during the loop activity, the AddToCover Process API fails, because it can't obtain the lock, correct? That should be rolled back if commitWithErrorHandling is used.
But how does that ensure the child case will be added to parent case?