RobertoB5433 Member since 2014 5 posts
Posted: March 10, 2016
Last activity: March 21, 2016

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 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


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?



Case Management Low-Code App Development
Moderation Team has archived post
Share this page LinkedIn