Posted: 4 Mar 2015 3:27 EST Last activity: 16 Jun 2016 9:08 EDT
Propagating Data to Child Cases
I have two question:
1. In PIPFW we are carrying data for individual itemlist to the child class using the MapItem Data Transform. But where is tmpPage created in this application that being used in this Data Transform. Also where is this tmpPage removed.
2. In case I have a data in parent case which is updated/created after the child case is created how can that be propagated. Case Designer does not have this feature.
In the CreateSubCases flow you have a Split-For-Each shape named "Create Orders".
When you configure this shape, you get to name the page "SourcePageParamName" value.
This value is the name of a parameter of type "Page Name" -- all such params also required to be mentioned in Pages&Classes.
So PRPC generates a "Source Page" named "tmpPage" -- since that is what you said to name it. PRPC then calls your transform passing that name as a parameter -- a parameter that you defined as a Page Name parameter.
= = = = = = =
As for your second question - having a child case update a parent case can be done, but has to be done carefully.
If you have not overriden DetermineLockString then the child can directly update pyWorkCover since both cases are managed by a mutual lock.
In a Flow Action post-Activity you can execute Obj-Refresh-And-Lock against pyWorkCover. If that fails (hasMessages) then exit Activity. If not, update pyWorkCover then do Obj-Save against pyWorkCover.
As opposed to "push" you could also devise some way for the parent case to directly "pull" data from a child case.
As a last resort you could have the child case write its data to a stand-alone persisted data class that is not lockable - somewhat like defining your own JMS-like queue. The parent case would read from that table. Once the parent reads the data it would delete the record from the queue.
In Pega 7 there is Optimistic Locking (OL) which potentially eliminates the need to use Obj-Refresh-And-Lock but you might as well use it since you do need a lock before doing an Obj-Save -- the difference is at what time the lock check is made - immediately or later when the update actually occurs.
Also with OL you would not have to override DetermineLockString AFAIK.
That is what makes sense to me in theory anyway.
OL is mentioned multiple times in the 7.1 Lead System Architect course.
You may want to start a new discussion in that forum if you feel the course does not answer your question.