Question
Reply
IT
Last activity: 21 Mar 2016 6:11 EDT
Overriding Locking Strategy for children cases
I have a scenario where a Case A can have 3 children: case B, C and D.
Case A locking strategy is defined as Default so every covered case will inherit the same locking stragegy. My requirement is to have Case B configured with Optimistic locking while still being covered by Case A, while Case C and D should retain Default locking strategy. As far as i know this is not possible (at least up to pega 7.1.7) which is the version we are running.
I found a possible workaround which, i fear, is not exactly pega compliant but it's not that bad either.
Here it goes:
Let's suppose we have Case A instanced with all the 3 child Cases. We have something like that:
- CASE A
|_CASE B
|_CASE C
|_CASE D
When an operator tries to open a Case the acquireWorkObject API is called, in the contest of the execution the locking strategy is determined by pzGetLockingMode activity:
Said activity basically consists of a java step that checks for the locking strategy of the topmost case (A in our example) by reading pyDefault rule (of type Rule-Obj-CaseType)
Knowing that pzGetLockingMode has pyWorkPage as a Primary page i wondered if i could save a circumstanced instance of pyDefault to be read only when Case B is being locked
I have a scenario where a Case A can have 3 children: case B, C and D.
Case A locking strategy is defined as Default so every covered case will inherit the same locking stragegy. My requirement is to have Case B configured with Optimistic locking while still being covered by Case A, while Case C and D should retain Default locking strategy. As far as i know this is not possible (at least up to pega 7.1.7) which is the version we are running.
I found a possible workaround which, i fear, is not exactly pega compliant but it's not that bad either.
Here it goes:
Let's suppose we have Case A instanced with all the 3 child Cases. We have something like that:
- CASE A
|_CASE B
|_CASE C
|_CASE D
When an operator tries to open a Case the acquireWorkObject API is called, in the contest of the execution the locking strategy is determined by pzGetLockingMode activity:
Said activity basically consists of a java step that checks for the locking strategy of the topmost case (A in our example) by reading pyDefault rule (of type Rule-Obj-CaseType)
Knowing that pzGetLockingMode has pyWorkPage as a Primary page i wondered if i could save a circumstanced instance of pyDefault to be read only when Case B is being locked
Having saved a circumstanced rule i tried to modify the logging strategy but the advanced tab of the circumstanced rule wasn't editable.
Still, by checking the xml structure of the rule (Actions->View XML), the locking strategy is presend with "Default" value
<pyLockingMode>Default</pyLockingMode>
So what i did is:
1- delete the circumstance rule
2- Edit pyDefault rule (in Case A) setting locking strategy to Optimistic
3- Save a new circumstanced rule as defined above. Advanced tab is still not editable but pyLockingMode is set to Optimistic
4- Revert pyDefault rule (in Case A) back to Default locking strategy
5- Circumstanced rule is still set to Optimistic locking
Now i can instantiate a case structure with the following locking strategies
- CASE A (Default)
|_CASE B (Optimistic)
|_CASE C (Default)
|_CASE D (Default)
I've run a few test and it seems to be stable enough, but still i've no idea of possible side effects.
Have you already faced a similar problem? Did you find another solution?
Thanks
Roberto
Accepted Solution
Reply
IT
Hi Eric!
The advanced tab is editable for base versions but not available for circumstanced one. My guess is that it's a safeguard implemented by Pega to avoid doing what i just did, which is dynamically change the locking policy. While Rule-Obj-CaseType are editable in base version you'll probably not supposed to directl modify them. You should work in Case Designer and not on the rule. But that's my guess.
I can see your point about Optimistic locking but it works well for our process. Our istance of CASE B is mostly a "monitoring one" where the user doesn't have to input a lot of stuff. They just have to press a button and say "ok, i've done this". The thing is that an external event may advance the process too. And we need it to manage the event and advance the process even if it's locked by the user. So Optimistic locking really works for us in this scenario
Pegasystems
US
I have not tried this, and I don't understand why your advanced tab wasn't editable. Do you ? Is it merely not editable for circumstanced versions, or are base versions also not editable ?
I have to say, though, that I never like optimistic locking. Perhaps I'm pessimistic, but it seems to me that with that kind of locking, the user might spend a lot of time typing in a whole bunch of fields, and then when they click "submit" they get an error saying "sorry, someone else already changed the object". What does the user do now ? How do they save and re-do all their typing ?
With regular locking, they don't run into that problem since they won't even be allowed to start typing into the fields until the lock is obtained.
/Eric
Accepted Solution
Reply
IT
Hi Eric!
The advanced tab is editable for base versions but not available for circumstanced one. My guess is that it's a safeguard implemented by Pega to avoid doing what i just did, which is dynamically change the locking policy. While Rule-Obj-CaseType are editable in base version you'll probably not supposed to directl modify them. You should work in Case Designer and not on the rule. But that's my guess.
I can see your point about Optimistic locking but it works well for our process. Our istance of CASE B is mostly a "monitoring one" where the user doesn't have to input a lot of stuff. They just have to press a button and say "ok, i've done this". The thing is that an external event may advance the process too. And we need it to manage the event and advance the process even if it's locked by the user. So Optimistic locking really works for us in this scenario