Skip to main content
Back to all events

Webinar

90 Mins

CLSA Community: Common Data Model

This event originally took place on February 26, 2024

Replay

CLSA Community Meetup - Common Data Model 20240305
Video duration: 1:38:47

Overview

In our first online event for 2024, learn about the Common Data Model (CDM), which provides a unified and prescriptive approach for structuring the entities and relationships most commonly used by Pega's strategic applications and client Platform applications.

This event explores the types of data and relationships included and the technical design patterns implemented for saving, refreshing, and searching data, as well as integrating with other systems of record. The sessions also discuss how to extend the Common Data Model, and include demonstrations of the CDM in action and suggest the opportunities to adopt the CDM into Platform applications going forward.

Presenters

Bill Hanigan Senior Product Manager: Data & Integration
Matt Lewis Senior Director: CRM Architecture
M Karthik Prasad Product Manager: Application Data & Integration
Sarron Mohapatra Senior Manager, Application Engineering: Application Data & Integration
Raghavendra Talegaonkar Manager, Application Engineering: Application Data & Integration

Downloadable slides

 

Demo videos

Videos from the webinar showing Common Data Model capabilities in action:

Composing a case type with the Common Data Model

 

Extending the Common Data Model with client-specific attributes

 

Connecting Common Data Model entities to external systems of record

 

Adding a new Reference Data category to Common Data Model

 

End-to-end usage of client-specific entities, systems of records and reference data

 

Questions and Answers

Below are the different groups of Q&A from the webinar; use the links to jump to the section of your interest.

About CDM

Question Answer
Does this mean we are going away from the Industry Foundation for Financial Services and we should adopt to Common For Financial Services? Common [Data Model] for Financial Services is the successor data model from Pegasystems for Financial Services. For Constellation-based applications, Common Data Model is the default.
Is the Common Data Model part of Pega Infinity 23 or 24? Common Data Model (CDM) was GA'd in Pega 8.8.1 and is available onwards.
How do I get CDM? Common Data Model is a separate download from the Pega Platform. If on cloud, CDM can be requested as a cloud install. If on prem, CDM can be downloaded from https://my.pega.com in the software section.
How do I learn more about CDM?

In addition to this webinar content, check out the following resources:

Will this pattern be adopted by all the strategic apps? The Constellation version for Pega's strategic apps will be based on CDM or an industry version of CDM.

CDM Features

Question Answer
Is CDM is hosted on a [separate] Pega instance, which is then acting as a central source of data for all other installations like Customer Service, Sales Automation, [Platform] applications, and external systems? The Common Data Model supports different deployment options. It can be on the same instance or a different instance to the consuming application.
Does the Common Data Model map to a relational table for each entity or are these entities will abstract that can be part of case binary data? Core top level entities all point to a dedicated table. Embedded / composited data on these top level entities do not have separate tables.
Is the CDM backwards compatible? Do we need to do a migration from the old OOTB data model (like person and organization) to the CDM or does it largely overlap with the old data model? It will depend on you implementation specifics. We will have documentation and certain utilities to help moving from one model to another as part of Constellation modernization.
How is error handling implemented in CDM? Yes we have several error handling techniques in the model. 
How does this savable data page use rest connector when it is a new record? We have a pattern for that. We pass a parameter of "CREATE".
If all the CRUD operations are handled in a single Data Page, will this impact the performance in applications with larger data?  No. It's a single logical data page but with different parameters thus you will get multiple instances based on different parameters.
Will the refresh data page logic work in Theme Cosmos or UI Kit-built applications? You can use the same pattern if you use Common with UI Kit or Theme Cosmos. The only difference will be the Constellation UI API for clearing off the client side cache will not be applicable in non-Constellation apps.
Are all the properties of each entity in CDM all exposed?  Not all properties are exposed OOTB. Properties can be exposed as needed in your implementation.
How is data integrity managed when data is opened with multiple users at same time? The Common Data Model, as all Platform applications built on top of Constellation, leverages optimistic locking.
How does this implementation integrate with Generative AI? You will be able to use Pega Gen AI to generate the mapping for any external integration.
Are there any new Custom Warnings that are recommended for the Telecommunication or Financial applications, so that CDM guidelines are followed? This is a good question. As of now, we don't throw warnings when pattern is not followed as we understand for existing applications it might take some time to shift to new model.  But, the patterns shipped makes the life of a developer so easy that we expect they would love to follow to reap the benefits of all infrastructure available for free if they do follow these patterns.
Are there any common points to extend or override using the CDM structure OOTB for security and error handling? As it follows the Inversion of Control pattern, all error handling /logging etc can be added at the single entry/exit point as well as in your entity extensions that are available
Anything specific for CDM in regards to caching and persistence? It follows the same mechanism as what Constellation recommends. All the entity Data Pages are cached at the requestor level and drop down data (Reference Data Pages) are cached at a node level, unless there is need of a cascade dropdown to be dynamically populated.
Does CDM support single transaction across multiple entities? For example, can I ensure currently that customer, account both get saved or rollback happens if neither gets saved where say customer: account is 1:n?  Yes. For example, when you create a contact in CDM, you also create an account and associate with contact in the same transaction. If one of the operations fails, the transaction rolls back and doesn't commit. This works OOTB.
Are these specific data types on data layer ? Does it have dedicated data tables? The primary [data] entities do have dedicated tables. The embedded data like addresslist, phonelist etc. do not.
Can we now import to update sample PegaFS or PegaHC data for strategic apps such as Smart Disputes and Pega Care Mangement respectively? Is this available starting SD'23? Common Data Model and industry extensions are the successor to the Industry Foundations. All applications going forward for the Constellation versions including Care Management and Smart Dispute will be based on top of the Common Data Model and thus sample data management and import will apply across all applications.
Can CDM be recommended for a pure low-code applications developed by citizen developers? Yes. The model is design pattern driven and is low-code friendly. We are constantly working to lower the bar on leveraging thus such as wizards that will help with external integration in the future.
What performance benchmark testing results can you share? We have tested with over 10 million accounts, contacts and our response time for APIs have been around 100-200 ms for 120 throughput and we haven't seen a major dip beyond that if infra supports.

Implementing CDM

Question Answer
How are we going to handle attribute conflicts? For example, in one industry, a field may be a text, in another it is may be an integer, and in another it may be a double. Rule resolution would still apply to those respective classes.
Can we use this model also for old design systems like UI Kit and Theme-Cosmos? You can use this model even for Theme-Cosmos or UI-kit builds when building on top of platform. CDM is the go forward model for all strategic constellation applications.
How easy/difficult it is to migrate the legacy applications built on earlier versions when the platform is upgrading to the latest versions of Pega? This will vary depending on the application.  I would recommend downloading and doing some gap analysis. Keep in mind that migration to this is not required or being promoted. It's an option especially for net new applications.
Is CDM a standalone application that will be shipped with all the Data Models, and do we need to create our application on top of this application stack based on the domain? Common Data Model and industry variations are freely available to download as long as a customer has a platform license. All strategic applications on Constellation will have this in the built on stack.
When rolling out a new application, are we also expected to implement a CDM application and expose it via APIs where our own implementation application will communicate to refer data for CRUD operations? When rolling out a new application, are we also expected to implement a CDM application and expose it via APIs where our own implementation application will communicate to refer data for CRUD operations?
Is it possible to source data from real time streaming sources like data sets do to support data model which is an extended with customer specific attributes ? Or do we support only REST for now? You can add any integration type that is supported in core Pega Platform.
Extending the CDM: What would happen if I create a class under Common- hierarchy to extend the data model? If Pega decides to create a same class later on in future versions, it might cause trouble for upgrade etc. How do take care of this?  This would be the same as any existing class conflict. We try to limit the number of top level entity classes that have direct table mappings. All embedded classes are not bound to tables and should not cause a conflict.
It looks like we no longer need to extend the OOTB (CDM) data classes/tables in client implementations. If clients have a need to define additional keys for data objects, the OOTB data tables mapped to the CDM data classes would have to be modified. Is that recommended?  The keys for the classes can actually be changed on the Data Pages themselves using the option "is this page used for alternate key storage" on the parameters tab of Data Pages. This allows defining the keys for external data. For locally stored data, changes to the key structure would require an implementation specific class that inherits. At some point in the future, we would like to externalize this fully out of the class definition.
Are ways to track the invocation of the API called by the Data Pages, in a log or a table to make easy reconstruct the sequence of Data Page calls? This could be an extension. With the inversion of control pattern we have some centralized global extension points where this could be added in once and apply to all interfaces/data pages.
How this will impact the sizing, especially for inhouse customers? Do we need to think about more hardware while upgrading? We have not seen a performance impact above and beyond normal integration patterns or logical data models.
How should we design our Common Data Model which are common across modular apps? If you have multiple apps to be built on Common Data Model and have common extensions that you want to build that you want to use in all 3 modular apps, you can build your common app on top of common application shipped, wherein you can define your common extensions and then have the other 3 apps on top of that. If you have vertical flavors for any of the verticals shipped- insurance, financial services, government, healthcare, communications, then you can build your implementation app on top of those [apps].
How do we handle inflight cases if we switch from traditional data model to CDM? As with any major change, it's often that in flight cases are completed in the existing application.
If we have to use a new API for the implementation at the organization/application layer, do we consume the API and configure it in the CDM Data Page with the updated request and response Data Transforms and refer to it? Is it possible to configure various connectors from App Studio? If you have your own APIs, you would plug those into our OOTB Data Pages. Your Data Transforms would follow the same naming conventions as the OOTB. In App Studio it is not currently possible to configure multiple connectors for a Data Page.
How does CDM work with Process Fabric where we do have many extension connectors? Is there any best practice around this? The pattern uses connectorname_methodname_request and connectorname_methodname_response. 
Can we change the scope of the Data Page when we are extending it to implementation layers? You can change the scope. We support Dynamic Class Referencing throughout.
What if data is stored in Enterprise Customer information, which is outside Pega? You would be able to plug in your connector or integration source to the same data page following the exact similar pattern . We have tested this with various external connectors and it does work seamlessly.
Has CDM been successfully implemented in any global clients of Pega? If so, what are the main implementation challenges and complexities? Yes we have quite a few early adopters on Customer Service app built on Common Data Model since 8.8.1 . We also have customers who have taken CDM with Platform and have implemented their mortgage application.
Is there any guidance for future upgrades, particularly regarding class specialization, considering potential issues with inheritance? The guidance is to use ruleset specialization for extension where in all patterns seamlessly work and we will see more of it in demo. For very specific need where we want to subclass and have ABAC for specialized classes ,for e.g. We want to have Household, Business and Consumer accounts ,we have shipped a pattern to subclass and this could be followed.

 

Did you find this content helpful?

We'd prefer it if you saw us at our best.

Pega Community has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice