Entity design pattern

In the Common Data Model, an entity, such as Account or Contact, is modeled as a Data Object. Data Objects serve as the reusable building blocks of an application's logical data layer.Every well-designed Data Object encapsulates three distinct layers:

• Structure (Fields) -- Properties that define the information captured (for example, Account ID, Name, Status).

• Access (Data Pages) -- Mechanisms that handle how data is retrieved, cached, and mapped. The Common Data Model automatically generates default Data Pages for new Data Objects to support different access scenarios, decoupling the logical data model from the physical System of Record.
• Presentation (Views) -- UI components that define how the object's data is consistently displayed throughout the application, aligned with the Pega design system.

The following figure shows the structure of an example entity, Account.

Key Architectural Patterns

Beyond the three-layer structure, Pega Platform™ several higher-level design patterns for a main data object:

• Enterprise Class Structure (Layer Cake) -- Data Objects should be modeled within the Enterprise Class Structure so that a core Account type can be reused and extended across different lines of business or implementation layers.
• Customer 360 and Composite View -- For a primary entity like Account, a customer should engage with a holistic "360-degree" view that surfaces related parties, preferences, and recent interactions in one centralized location.
• Embedding for Reuse -- Child objects (for example., an Address) should be embedded within the parent Data Object (for example., Account) to promote reuse across the application.

Use the default Data Objects and common information models before building custom objects and leveraging Pega GenAI™ or Pega Blueprint™ to accelerate and validate data model design.

Entities use a design pattern that defines the entity structure and operations for managing data by using Data Pages and Data Transforms. You can view the structure for an entity in the App Explorer. The following figure shows the Account entity:

The Data Model shows the following components:

• Association – An association is a Data Object that represents a primary entity relationship. For example, the Account entity, with properties that include Account ID, Name , and Type relates to the Contact entity, which includes Name, Address, Phone, and Email information.
• Data Page – A rule that determines how to retrieve, cache, and map data to move data between physical data storage and the application.
• Data Transform – A rule that maps data fields in the application to data fields in the source.
• Property – A property defines the information captured (for example, Account ID, Name, Status).

The following sections describe how a primary entity uses Data Pages and Data Transforms.

Data Pages

Data Pages connect the entity to a data source. Each entity has three Data Pages. The following figure shows the Account entity:

• D_Account is a savable Data Page that connects to a data source for accounts. This Data Page gets the details (properties) for a specific account and handles all create, read, update, and delete (CRUD) operations.
• D_AccountList is a list Data Page that powers read-only list views via Insights
• D_Account_List is used to search and select the account records.

In the Common Data Model, Data Pages have the following characteristics:

• Direct Database Saves: All savable Data Pages perform direct database saves, aligning with Pega Blueprint and Pega Platform out-of-the-box behavior.
• Report Definition Backing: All list data pages that enable search and select are backed by Report Definitions, ensuring consistency with Pega Platform put-of-the=box behavior..
• You can configure Data Pages to interact with external APIs to connect to a data source.

By using the Common Data Model, applications can focus on mapping the system of record (SOR) to a logical Data Model (LDM) rather than building infrastructure.

Data Transforms

Data Transforms map data fields in the application to data fields in the source. Entities in the Common Data Model use Report Definitions to store data locally. Each entity has a set of Data Transforms that set Report Definition filters and map data to and from the data source.

Example: Entity record data

Each entity has a savable Data Page to handle data operations. For example, the D_Account Data Page manages the data for the Account entity. The Data Page has the following design pattern:

• Data Page definition
• Data sources
• Data save options

The following figure shows the D_Account Data Page:

The Data Page definition shows that the Account entity is in class Common-LDM-Entity-Account. All entities inherit from Common-LDM-Entity. All entities use a savable Data Page, which includes

• Lookup (Read) – Read from the default database table. In the Account entity, the database is Customer account. Class Common-LDM-Entity-Account is mapped to table data.common_account in the primary database PegaDATA.
• Data Save options – Create, update and delete.
• The default save plan is CreateAccount.
• Each data save option has an ActionType configured. For example, for pyIsPatch, pyActionType is "UPDATE_PATCH". Other Data save options have a similar action types.

This design pattern for the entity details Data Page provides the following benefits:

• You can understand one entity and apply that knowledge to all the others.
• You can extend the Entity Data Model and integrate it with new data sources.

Example: Entity search or retrieval of a list of records

Each entity has one list Data Page to handle getting and managing a list of records. For example, to get a list of records for the Contact entity, you use the D_Contact_List Data Page. The Data Page includes:

• Multiple profiles that fetch a list of records.
• The list Data Page takes a profile as input, accepts filters dynamically, and returns the matching results.

The following figure shows some of the profiles used on the Contacts list Data Page:

In the Data Sources section, each profile calls a Data Transform to process a list of contacts from the Contact database.

For example, the Contact_Search Data Transform in Contact Search Profile (Profile_Con_Search) consists of three primary Data Transforms:

• Pre-search Data transform (Pre_Contact_Search) : This Data Transform sets Report Definition filter parameters using pySearchPageName from the search configuration.

• Data Transform to set Report Definition parameters (SetContactSearchRDParams): This Data Transform sets Report Definition parameters required for report execution.

• Response Data Transform to Map search results after report execution (Con_Summary_Response) : This Data Transform performs any post-processing on result set.

The search Data Page for each entity uses this pattern.