Duplication of data should be avoided. The main risk here is that the maintainers of applications that use this technique easily become confused as to which of the copies of the same data is the “source of truth”. This inevitably leads to data loss when a data capture feature is implemented on the duplication target, only for that data to be overwritten when duplication engages.
Where a single member of embedded data from within a List/Group structure (which would otherwise use a Declare Index for reporting usage) needs to be available from the top level (for example, .pyWorkParty(Customer).pyEmail1), it would be better to implement a top-level property (such as .CustomerPartyEmailCopy) as a Declare Expression that is always synchronized with the source of truth. For Properties bound to Declare Expressions:
Activities that reference them as a Property-Set target do not save;
Data Transforms that reference them as a Step Target save, but with a Moderate Guardrail warning;
Sections allow editable controls to be bound to them.
As such, be clear in your property name that the top-level data has a different source of truth. For example, .CustomerPartyEmailCopy instead of just .CustomerPartyEmail.
Duplication is sometimes needed, so by ensuring the duplicate is declaratively synchronized with the source of truth and naming conventions are used that discourage editing the duplicate, they are better assured to always match.
Avoid duplicating large pages of data, consider the following techniques to ensure that only one copy of the page is persisted even when it needs to be duplicated on the clipboard:
Use a “Refer to Data Page” Auto-populate property to gather that page of data by reference; OR
Experiment with the “Do not save property data” option on the Advanced tab of the top-level property.
NOTE: If you optimize an embedded page property that has a 1-to-1 relationship with the top-level (for example, .Income.SpouseIncome.TotalAmount), the column will still be created in the same table as the top-level class. These are just as easily referenceable for reporting as optimized top-level properties, and don’t require a top-level duplicate.
Discussion on this topic was sought from theLSA Data Excellence (Pega 8.4) webinarconducted in July 2020. The webinar and its full set of discussions that arose from it are available atLSA Data Excellence: Webinar, Questions & Answers.
I would like to suggest/add one more technique for “Techniques to surface embedded page data on the top-level page”
Avoid duplicating large pages of data, consider the following techniques to ensure that only one copy of the page is persisted even when it needs to be duplicated on the clipboard: (apart from the two suggested above)
Use Property-Ref method in activity: As both properties refer to the same memory location, changing value of any one of them automatically changes value of the other property. The referenced property just refers to the address of the original property without saving the data twice.
Procedure:
In LHS, use a reference property
In RHS, use a non-reference property
Target property should be configured as reference property in the advanced tab.
Pega will maintain this link forever unless you change it manually. This reference will be maintained throughout the case life cycle.
Both point to the same memory location so if you change any one of them, automatically other reference will be changed. It is like call by reference.
There is also a public API called reset reference information that helps to reset/remove the linkage between reference and non-reference property.
Use: By doing a reference, data loaded at one place can be referred at other places without wasting memory.
In my experience, I have found that Property-Ref does everything you hope it would, but publishes a lot of warnings in the logs. I never got a definitive position out of GCS or Product on whether this was an issue. As such I have not used it since about 7.2.
Do you continue to use Property-Ref in Pega Infinity? What has been your experience with warnings that are logged?
@bogga , Subsequent to the introduction of auto-loaded properties, I’m curious to know of any common use cases where Property-Ref is beneficial and necessary?
I offer a strong opinion that Property-Ref is overall a Bad Idea. If they were writing Pega from the ground up today and someone thought this was useful in limited situations, my bet is they would hide it inside the Java API. No way would they expose it to Activities.
Sure, it is still a fully-supported feature, and the doc doesn’t discourage its use. Nevertheless, how does Property-Ref not constitute property configuration that lurks inside procedural code? It’s an on-the-fly data definition.
It must be “manually” activated/deactivated by running the code. What sort of guarantees do you have about what state you’re in as the program executes?
It only works if the source page is present. So what next? You likely turn that old freestanding source page into a Data Page. Well then, why not use an autoloaded property for the target?
As a good programming practice, why avoid spelling out all these relationships and data loading within class structures and data dictionaries?
Sure, maybe there is a special case where this is helpful to work around a platform limitation or deal with an issue, but is it wise to use Property-Ref as a general-purpose data management technique?
