Basics of the Common Data Model
The Pega Common Application consists of the Common Data Model (CDM) and Business Components. The Common Data Model consists of different entities that can be reused across enterprise apps to accelerate client implementations and simplify integrations. The business components layers are reusable across different industries. For example, in Event Driven Architecture, Voice AI, and so on.
Pega Platform™ includes a Data Model that has been used for many years. The Data Model has evolved through a hierarchy of Classes, beginning with the standard Pega Class and, later, with the PegaData Classes as the product developed. As the needs of users continuously evolve, additional elements and attributes are added to the Data Model.
Every Lead System Architect (LSA) is responsible for creating a robust and scalable Data Model that is tailored to their enterprise application. LSAs also create APIs to retrieve or persist data in local or external systems. However, their approach often varies, based on the individual LSA's perspective, and this leads to a lack of standardized methodology and tools in data modeling. This is where the Common Data Model has the advantage.
The Common Data Model provides a foundational framework for developing Data Models for use in enterprise applications. By providing pre-configured entities, the CDM reduces development time and promotes the reuse of data, thereby improving efficiency and consistency across applications.
Structure of the Common Data Model
The Common Data Model is structured with Entity as Case Type objects, Data Objects (including relations and reference data). The Common Data Model is part of the Common Application, which you must obtain from Pega and import into your own instance of Pega Platform.
The primary components of the Common Data Model are entities. An entity serves as a template that defines the structure of an object. In this context, an object represents any element that your enterprise application processes as part of its business requirements. When defining an entity, the CDM specifies the necessary fields that an object must contain and identifies any additional related data items required for the object to complete a business activity. For example, a customer's account number is considered to be an entity.
The Common Data Model also facilitates the grouping of logically related data, which enables easy retrieval of the fields needed for an entity. A group of logically related data elements is known as a Data Object. An entity can incorporate multiple Data Objects within its definition.
The Common Data Model also provides Data Pages that use connectors as their source for operations. These Data Pages connect to the API layer, which acts as a bridge between the Common Data Model and client applications. The API layer facilitates basic Create, Read, Update, Delete (CRUD) operations with data in local storage.
A data portal is included as part of the Common Application, enabling you to view all available entities and Data Objects. The data portal also enables you to examine the relationships between Data Objects.
The following figure provides an overview of the components of the Common Data Model and how they are arranged. The outer layer represents the data portal, which enables you to view and manage entities and Data Objects. Each entity is a template that defines the structure of an object. Objects represents any element that is processed. The inner layer of Case Types defines the workflows that incorporate those processes. Instances are retrieved or persisted by default in local data storage, and a Data Page is used to connect to the API layer, through which client applications can connect to the Common Data Model.
Check your knowledge with the following interaction: