Extending Organisation Data Class
When extending a data class is discussed, there are different approaches and would like to discuss the pros and cons of it.
Scenario 1 - ABC is a hotel chain running royalty program and need to get started with the redemption process on Pega. With any redemption, the first step is to collect customer data and customer need to be a work party throughout the case lifecycle for confirmation or rejection notifications and all that.
Choice 1 - Create a Customer class on organisation level( ABC-Data-Customer) directly inheriting from (Data-party-Customer).
Choice 2 - Create a Custome class as subclass ( Data-Party-Person-Customer) .
Which would be a better choice in your opinion? In my view, choice 1 seems to be better as class name is generic, pattern inheriting from the organization and cleaner. Doesn't have "party" tagged to it all along but can be reused as a party. what is your view?
Scenario 2 - During redemption case, we need to capture customer information.
Choice 1 - Section would reside in organization customer class and in organization ruleset.
Choice 2 - Use organization customer class but save them in implementation ruleset (assuming no framework)?
Choice 3 - Create an implementation customer class extending organization class ( e.g ABC-Redemption-Data-Customer) and create a section in this class and in implementation rulesets.
When extending a data class is discussed, there are different approaches and would like to discuss the pros and cons of it.
Scenario 1 - ABC is a hotel chain running royalty program and need to get started with the redemption process on Pega. With any redemption, the first step is to collect customer data and customer need to be a work party throughout the case lifecycle for confirmation or rejection notifications and all that.
Choice 1 - Create a Customer class on organisation level( ABC-Data-Customer) directly inheriting from (Data-party-Customer).
Choice 2 - Create a Custome class as subclass ( Data-Party-Person-Customer) .
Which would be a better choice in your opinion? In my view, choice 1 seems to be better as class name is generic, pattern inheriting from the organization and cleaner. Doesn't have "party" tagged to it all along but can be reused as a party. what is your view?
Scenario 2 - During redemption case, we need to capture customer information.
Choice 1 - Section would reside in organization customer class and in organization ruleset.
Choice 2 - Use organization customer class but save them in implementation ruleset (assuming no framework)?
Choice 3 - Create an implementation customer class extending organization class ( e.g ABC-Redemption-Data-Customer) and create a section in this class and in implementation rulesets.
In my view, Choice2 seems better. with choice 1, If all implementations start putting their data capture screens in organization ruleset, it will become dirty. Choice 3 is introducing redundant layering that might be skipped. What is your view?
Cognizant Technology Solutions
US
<<Correction >>
Choice 1 - Create a Customer class on organization level( ABC-Data-Customer) directly inheriting from (Data-party-Person).
Pegasystems Inc.
US
As much as extending Data-Party(-Person) would benefit from reuse, if you decide to use the CustomerData schema to persist data as opposed to the PegaDATA schema, that decision would result in using Property names that begin with "py" which can lead to warnings and difficulties .
It is logical that customer or contact data would be stored in an enterprise-hosted system that Pega accesses by Integration. This is the expectation within the Customer Service application, i.e., Pega would not be expected to be SOR for all customer/contact information within the enterprise. For a smaller, special-purpose application using Pega as the customer/contact SOR for that particular application would be acceptable.
In Pega Infinity, a citizen developer can use App Studio's Data view to interface the enterprise-hosted Customer Data system. The response from that system can, in turn, be mapped visually to the Customer Service application's PegaCA-Interface-Contact class.
FYI: A just-released Pega Academy lesson demonstrates this, namely, Integrating External Data Version: 8.2
The question becomes, do you want your Org-Data-Customer class to extend Data-Party(-Person) or PegaCA-Interface-Contact? Depends on the application you are built on, i.e., Customer Service or core Pega.
Cognizant Technology Solutions
US
@pedel thanks for your response.
On the second part, say I have an organization application/ruleset to build upon and reuse. It has customer data classes and corresponding basic data entry screens/forms. My implementation want a different data capture screen. In this scenario we have two option . First to build/override those screens in Org-Data-Customer class but save in Implementation ruleset. Second is to create customer class in implementation inheriting organization customer class and override these sections in implementation class and implementation ruleset. What is best recommendations on that and what should be the thought process?
Pegasystems Inc.
US
What you are asking is whether to (1) use ruleset specialization or (2) create a new class that inherits your enterprise-defined class, the new class created in a new ruleset.
For Data classes Pega tends to use pattern-inheritance within the same layer and direct inheritance when a Data class is extended to the new layer. A new layer is typically application-specific.
Hence: Org-App-Data-Customer directly extends Org-Data-Customer
In other words, (2).