What is recommended approach to expose Aggregate/complex properties under pyWorkPage to a table
Traditionally Declartive rules are used and recommended to save the Pagelist or Page data to a table.
Is this still a recommended approach?
Or
With new 8.4 saveable Data Page concept. ..Are we supposed to use Saveable DataPage appraoch to save all the complex properties to table after every flowaction .
Which is the pega recommendation ? and Pro's and Con's for each.
Pegasystems Inc.
FR
Hello,
Well I guess it depends on how you want to access those data, how you want to report on them as well.
If it has to be stored under pyWorkPage I still believe the Declare Index approach is valid.
HMHS
US
We are using care management framework and these are OOTB pyWorkPage Pagestructure and we need to expose the data of some of the complex properties under pyWorkpage to tables.
Pegasystems Inc.
AU
Performing "Optimize for Reporting" on a property within an embedded Page List property will use a separate table (creating a new one if necessary) and create/update a Declare Index rule that orchestrates saving a copy of the 1-to-many data from within your Page List to the separate table.
Note that optimizing top-level single value properties, as well as properties within an Embedded Single Page property, will be stored on in the same table as the work item. These properties have a 1-to-1 relationship to the work item, and Pega does not need to keep them in a separate table.
The Declare Index will take care of managing the "foreign key" back to the work item, as well as unique identifiers for your 1-to-many data (based on the name of the page list and the list index number). The Declare Index also handles cleaning-up (deleting) your 1-to-many data if you remove elements from the Page List.
Performing "Optimize for Reporting" on a property within an embedded Page List property will use a separate table (creating a new one if necessary) and create/update a Declare Index rule that orchestrates saving a copy of the 1-to-many data from within your Page List to the separate table.
Note that optimizing top-level single value properties, as well as properties within an Embedded Single Page property, will be stored on in the same table as the work item. These properties have a 1-to-1 relationship to the work item, and Pega does not need to keep them in a separate table.
The Declare Index will take care of managing the "foreign key" back to the work item, as well as unique identifiers for your 1-to-many data (based on the name of the page list and the list index number). The Declare Index also handles cleaning-up (deleting) your 1-to-many data if you remove elements from the Page List.
The main advantage is that the data in the table managed by the Declare Index is always synchronized with the content of your work item every time it is saved. You don't have to configure anything specially in Pega once the Optimization wizard is run - it happens for free. This is particularly useful if you have Page Lists within Page Lists and have an intricate set of 1-to-many-to-many relationships [e.g. LoanApplication.Applicants().Addresses()] . Pega's Declare Indexes deal with all of that when it commits saves; you just focus on configuring your case type and let Pega worry about the physical data model needed to support your reporting/retrieval requirements.
If for some reason you need to take full control over storing a copy of your complex type data embedded within your work object, I'd recommend using a Declare Trigger so that what you store for this is synchronized with what is saved from Pega, regardless of what triggers the save. This takes away the need to wire in invocations in your Flow Actions, for there are very many other ways a work item is changed and saved in Pega than just performing Flow Actions. The downside is that everything the Declare Index does for you OOTB (described above), you have to configure and test yourself. This is proven Pega capability - leave Pega to do it.
Savable Data Pages are more for saving changes to related non-case data back to the System of Record from where they were retrieved (be it Pega or something else) at certain points in your case lifecycle where that related data is known to have changed and is ready to store. I don't think Savable Data Pages are a fit here, for as you've alluded to, you need to explicitly invoke the Save operation when this data is known to be good, and the typical usage is to couple them to Flow Actions or Flows.
Something to think about though ... if your goal was to store the work item's embedded complex data in the relational database of a different system, having Savable Data Pages represent your data types that are stored externally and wiring them into a Declare Trigger activity on your Case Type would be the right mix of storing external data and ensuring this occurs on every work item save.