We are working on a project but stuck on a point which is blocking our development.The problem we have is around case locking.
What we are trying to do is to get cases from different applications to our central application via get next work function.
Here is the current status;
For the cases without any parent case, everything looks fine (regardless of the logged in application).
When we are logged in the application which actually creates the cases, next work dose not lock the parent case with the child case. System locks child cases only. This is actually what we want and expect.
When we are logged in our central application get next work locks the parent case with the child case. System puts lock for both parent and child cases. Putting lock on a parent case disables other operators to get any more sub cases from this parent case. This is a situation which we don’t want to happen
We tried to use some locking options on the cases, but it seems that, they have no effect on this.
One additional, interesting note is that, If we do not use the get next work function, and get work from workbaskets, everything looks fine. System locks child cases only.
Two different users can take two separate cases with same parent case and process them. (regardless of the application)
We are bit stuck at this point and cannot proceed. What do you think?
What Pega version are you using? When you trace getnextwork from the two applications, what do you see when it goes through the WorkLock and DetermineLockString steps? In Tracer, enable the Locking and Case type options.
Posted: 2 years ago
Posted: 5 Nov 2019 2:55 EST
Aydin Toprak (topra)
Senior System Architect
We have actually checked the traces it seemed quite ok for us at that time.
I have taken traces again and check the activities you mentioned again and found out the problem. The promblem is that the owning application has specialized DeterminetLockString activity. We didnt know that as we have no idea about the other application.
Once we test the issue again, with some modifications on DetermineLockString activity, we have managed to get what we want.
But, we have a new problem (this might be an old problem ... but just realized).
When we click on GNW button, by two operators at the same time, we get a fail message as follows on OperatorB
PegaRULES Request Status fail, Cannot obtain lock on instance ABCDE, as Requestor PYZQ already has the lock OperatorA.
Actually OperatorA get the case and locks it. This is normal and what we expect.... The problem is that the system should give another case to OperatorB in case of case ABCDE has locked by the OperatorA.
I have asked for the trace of this "failed" case.
Do you know any known issue about this case ?
Posted: 2 years ago
Posted: 5 Nov 2019 13:01 EST
Carissa Wenhardt (CarissaW_GCS)
Senior Principal Engineer, Technical Support, Industry Apps
If you are able to get a trace of the lock error scenario, check the Param.assignmentFound value. I was looking at findAssignmentInWorkbasket and see a while loop that includes a check for this parameter. It would get set to true in the last step of MoveToWorklist. If MoveToWorklist was unable to lock the work object, then I would expect Param.assignmentFound would be false and the while loop would try the next result.