My requirement is to use the Get Next Work feature in a Constellation Application, but I do not want to move the assignment to the worklist of the operator. The assignment should remain in the work queue. If the operator just closes the case or if his lock expires everyone with access to the work queue should be able to open the case again.
As I understand the documentation (Get Next Work customization), this should be possible by setting the Application setting GetNextWork_MoveAssignmentToWorklist to false. However using Pega Constellation (Pega Infinity Version 24.2.3) this does not work as expected; the assignment is always routed to the worklist of the Operator.
I investigated why this is the case and stumbled upon the MoveToWorklist (Assign-, Pega-ProcessEngine) Activity where this setting is called. I noticed that it only takes effect if the Requestor is not stateless, which is also mentioned in the description of step 1, otherwise Local.MoveToWorklist is always set to true. Since Requestors are stateless for Constellation applications this setting seems to be not supported. Is this a known limitation? Is there any workaround to fulfill my requirement?
Out of curiosity I simply set Local.Stateless to false in a private edit of the MoveToWorklist Activity and with that the Get Next Work feature works indeed as we would need it, but since the MoveToWorklist Rule is final I cannot use this as a workaround.
There is a function pzOpenAssignmentForGetNextWork that is being referred in the findAssignmentInWorklist and findAssignmentInWorkbasket activities to retrieve the next work item. Inside this function, the MoveToWorklist activity is called. Adding a condition before calling MoveToWorklist might resolve the issue, but since this is a final rule, it cannot be modified as a workaround.
One possible approach I could think is to create a custom function similar to pzOpenAssignmentForGetNextWork, where you either conditionally call MoveToWorklist or remove that call entirely. Then, update the findAssignmentInWorklist and findAssignmentInWorkbasket activities to reference your new function instead of pzOpenAssignmentForGetNextWork, as these activities are available for modification.
When you read the documentation for the system setting GetNextWork_MoveAssignmentToWorklist you will notice it says “Disabling this Rule does so and introduces an additional JOIN on the system locks table to ensure that the Assignment that you are performing is not locked by any other user (which otherwise would be a major performance problem due to lock contention.)”.
What this means is that all of your casetypes should use pessimistic locking if you plan to leave assignments in the queue. If the top assignment in the queue is tied to an optimistic locking case, then everyone pressing the Get Most Urgent button in a short window of time will get the same assignment. Then, whoever submits first “wins”, and the rest get an error. Moving the assignment to a person’s worklist solves this problem for optimistic use cases.
Originally, the DX APIs did not support pessimistic locking, hence the check in MoveToWorklist regarding stateless. So even if the casetype was set to pessimistic, it would not be honored. Now that the Constellation DX APIs (but not the Traditional) do, this will be addressed in a future release.