Properties define in Data- class and Work- class
I am new to Pega, and I was told it is a good practice to define independent properties in data- class.
For example,
normally I would have define properties like, In-class Org-Div-Work-CaseType as FirstName(text), LastName(text), Phone(phone), EmailID(email)
But it is suggested to define the above properties properly in Org-Div-Data-Customer as FirstName(text), LastName(text), Phone(phone), EmailID(email) and so on for others like
Org-Div-Data-Vehicles, Org-Div-Data-Address. and then defining page group to access these properties.
What is the significance of creating properties in such a way?
How it helps when the complexity of my application increases?
Accepted Solution
Pegasystems Inc.
US
That depends on what you consider complexity. :)
In Pega Platform, each class describes a unique type of object that can be used in an application. Work classes (classes descended from the base class Work-, such as O5FZIM-AMR-Work-Services in your example) describe work objects, or case types. Data classes (classes descended from the base class Data-, such as O5FZIM-AMR-Data-Customer in your example) describe data objects.
Associating properties with a specific class helps to provide context for those properties in your application. For example, consider an automobile accident claim. If the properties first name and last name are defined in the class associated with the case type, there's no context for those properties. Do they correspond to the person submitting the claim? The police officer who arrived on scene and filed the official accident report? Another driver involved in the accident? A witness? You would need to create four unique variations of each property to create unique properties for each party.
Creating a data class allows you to provide that context:
That depends on what you consider complexity. :)
In Pega Platform, each class describes a unique type of object that can be used in an application. Work classes (classes descended from the base class Work-, such as O5FZIM-AMR-Work-Services in your example) describe work objects, or case types. Data classes (classes descended from the base class Data-, such as O5FZIM-AMR-Data-Customer in your example) describe data objects.
Associating properties with a specific class helps to provide context for those properties in your application. For example, consider an automobile accident claim. If the properties first name and last name are defined in the class associated with the case type, there's no context for those properties. Do they correspond to the person submitting the claim? The police officer who arrived on scene and filed the official accident report? Another driver involved in the accident? A witness? You would need to create four unique variations of each property to create unique properties for each party.
Creating a data class allows you to provide that context:
- O5FZIM-AMR-Data-Customer: the insurance policyholder
- O5FZIM-AMR-Data-Witness: a witness to the accident
- O5FZIM-AMR-Data-Officer: the police officer who responded to the accident
- O5FZIM-AMR-Data-Involved: another party involved in the accident
As an aside: since each of these classes uses the first name and last name properties, you can define them for a common class (such as O5FZIM-AMR-Data-), and each of the data classes I just listed would gain access to those properties through the principle of inheritance. So: define once, use four times - much more efficient than creating four sets of identical properties!
Returning to your case, consider how that data would be used:
- A claim is associated with a single customer.
- A claim is associated with a single police officer.
- A claim may be associated with multiple witnesses.
- A claim may be associated with multiple involved parties.
By defining a data class for each type of party, you can then create a page property in the case type for the customer, a page property for the police officer, a page list for the witnesses, and a page list for the involved properties. These properties define how many of each party can be associated with the claim, and the data classes indicate the properties (and other rules) associated with each party.
So, instead of a flat data structure where each property has to be uniquely named, you can create a hierarchical structure where the property names are consistent from one data object to another, and the data objects themselves ensure that each property is considered unique within a case.