Case locking issue while we use Get Next Work function.

Dear all,

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?

Thank you



Keep up to date on this post and subscribe to comments

November 1, 2019 - 10:35am

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.

November 5, 2019 - 2:55am
Response to CarissaW_GCS

Hi Carissa,

We are running 7.1.7.

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 ? 

Thank you

November 5, 2019 - 1:01pm

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.