Question
Lanit
RU
Last activity: 16 Jun 2016 9:08 EDT
How to cancel locked assignment?
Hello everyone!
We have such requirement:
- a new assignment is assigned to an operator
- a request is came from other system to cancel the work object processing
- we need to close the work object and remove the assignment
Everything is fine if work object is not locked by operator.
But what can we do, if operator has opened his task already? He must not complete this task, because after this assignment there are some integration connectors. If they will be called, wrong information will go to other systems.
Pegasystems Inc.
FR
Hello,
You can surely remove the lock with an activity and the user will not be able to finish his work. Which PRPC version are you running ?
Pegasystems Inc.
FR
Hello,
The "ReleaseLock" activity would be a good candidate if you can pass the correct lock handle incoming parameter needed:
Updated: 14 Jun 2016 3:49 EDT
Lanit
RU
Hi Marc,
I'm trying to do this:
- Open a WO in one requestor session (operator1)
- Call activity System-Locks.ReleaseLock passing pzInsKey of WO as a parameter in another session (operator2)
Result: form with a message "Lock delete failed."
Error message in tracer: Cannot obtain a lock on instance SB-SBRF-UCLP-WORK SBRF-NCP-16473, as Requestor HB046E06C4415ABC0141DEFA1B52BC739 already has the lock
What am I doing wrong?
Updated: 14 Jun 2016 8:55 EDT
UnitedHealth Group
IN
Hi,
You can delete the lock of any WO from pr_sys_locks table (System-Locks class) using Obj-Delete from an activity by passing InsHandle.
ReleaseLock activity will work only if the lock is not held or current requestor has the lock.
Hope this helped.
Regards,
Prasad
Lanit
RU
Hi Prasad,
This will work only for soft lock - as I understand lock info is stored in DB table pr_sys_locks and in LockCache.
I've tried to delete record from pr_sys_locks, but this does not resolve the problem.
UnitedHealth Group
IN
Hi IIya,
I think you can change your approach to meet this requirement. You need not release the lock. You can ensure that flow does not proceed after Submit and gets cancelled.
Approach:
- Configure Alternate Stage for Cancelling the Assignment
- Create a table to hold WOs entry which are locked and cannot be cancelled.
- Extend/Override FinishAssignment activity to check for an entry in the table for the current WO when the assignment is submitted
- If the record exists in the table, call pxChangeStage activity in the first step of finish assignment to change stage to Alternate Stage (Cancel)
- In cancel stage, delete the entry for current WO from the table and cancel the case
- If record does not exist in the table, flow proceeds ahead
Regards,
Prasad
Pegasystems
US
Here's how I suggest you find the right level of API to be using:
1) In two different browser sessions (make sure it's two different cookies, NOT just two tabs in one browser session!) try to open the same work object, and verify that the second one gives an error saying "work already locked, would you like to kill the other requestor to release the lock?"
2) Before clicking "yes", turn on the pega tracer.
3) Click "yes" and see what API is called for achieving the result.
TWO NOTE:
Also test the case where your two requestors are logged in on different nodes from each other, keeping in mind that in this case, there is necessarily waiting involved, since the system pulse is used for alerting the other node to kill the requestor, and that can take up to an entire minute, depending on how long ago the pulse last ran.
/Eric
Lanit
RU
Hi Eric!
You are describing the same situation as Prasad.
Error like "work already locked, would you like to kill the other requestor to release the lock?" is generated only of two requestors are the same operator.
What I need is to do this with really different operators. This operation (releasing lock from WO) must be performed by service requestor.
Any ideas how to make this?
PEG
GB
Hi Ilya,
I had a look for a way to do this, but unfortunately I've not managed to find a viable solution when using a different requestor.
Essentially this was done using pega.getDatabase().getLockManager then trying to call the unlock method(s). But these all appear to enforce the lock ownership.
Pegasystems
US
You could investigate these possibilities:
1) For the unlock-requestor-on-other-node case, look at what API the other node uses to kill the requestor when it receives a request over the pulse. You could use the same API to kill whatever requestor you want.
2) You may be able to actually convince the existing pulse code to do your bidding for you if you generate a pulse request containing the requestor id you want to kill.
3) SMA has the ability to kill requestors, so you could look at what API it uses for killing them, and use the same API yourself.
/Eric
Lanit
RU
Eric,
The goal is not to kill the requestor. If I kill a requestor, operator will not be able to do anything. And I need only to keep him from performing current flow action.
PEG
GB
Hi Ilya,
Again, I'm afraid that I don't see a way to do this.
The engine code does contain override flags that you can use to remove a lock from a different requester. However, this won't allow you to remove the lock if it is a different operator.
If you trace the SQL that is generated to remove the lock, or set the logging level to DEBUG on com.pega.pegarules.data.internal.access.DBLockProviderImpl, then you should see that this is only trying to remove the lock if you are the owner.
And as you've already discovered simply removing the record from PR_SYS_LOCKS won't work due to the Lock Cache.
Sorry I don't have more promising news in this instance.