Question
Genworth Financial
CA
Last activity: 20 Aug 2025 10:08 EDT
Pega Constellation with CDM - Handling master data management - best approaches
We have a requirement to manage master data which resides in the external SOR with frequent CRUD operations. We have followed 2 approaches below. External Data object consists of top level data as well as embedded data such as list of addresses, list of contacts etc.
- Common data model approach to create a entity class (Common-LDM-Entity-ExternalEntity) and connect the data pages to the external SOR via Rest API. Then create the list view landing page and display data. The record's key is displayed as a link. However when opening the record we get the error as No case id for the given parameter. This is understandable as there is no actual case within Pega for this to be opened.
- Common data model approach to create a data object class (Common-LDM-Data-ExternalEntity) and connect the data pages to the external SOR via Rest API. Then create the list view landing page and display data with ADD button. The record's key is displayed as a link. Opening the data object works fine. However when trying to create/edit the object with embedded data the problem arises. We need to simply add top level data as well as some embedded data such as couple of addresses. We noticed that the embedded data is not passed to the data DX APIs. (Create Data record/ Update Data record.)
What is the best approach to be taken in this scenario? We do not have a need to create a case for each CRUD operation of this master data.
We have a requirement to manage master data which resides in the external SOR with frequent CRUD operations. We have followed 2 approaches below. External Data object consists of top level data as well as embedded data such as list of addresses, list of contacts etc.
- Common data model approach to create a entity class (Common-LDM-Entity-ExternalEntity) and connect the data pages to the external SOR via Rest API. Then create the list view landing page and display data. The record's key is displayed as a link. However when opening the record we get the error as No case id for the given parameter. This is understandable as there is no actual case within Pega for this to be opened.
- Common data model approach to create a data object class (Common-LDM-Data-ExternalEntity) and connect the data pages to the external SOR via Rest API. Then create the list view landing page and display data with ADD button. The record's key is displayed as a link. Opening the data object works fine. However when trying to create/edit the object with embedded data the problem arises. We need to simply add top level data as well as some embedded data such as couple of addresses. We noticed that the embedded data is not passed to the data DX APIs. (Create Data record/ Update Data record.)
What is the best approach to be taken in this scenario? We do not have a need to create a case for each CRUD operation of this master data.
Please suggest a good approach to be followed to handle this master data management within Pega constellation with CDM.
HCA Healthcare
US
Use a Data Object as the primary model, not an “entity/case” class; that’s why you see “No case id.” Split the embedded lists into first-class child Data Objects (Address, Contact) related to the parent by keys in CDM. Create read data pages per object (D_Entity, D_EntityAddresses, D_EntityContacts) sourced by your REST SOR and bind the list view to these. For create/update, avoid the generic Data DX APIs when the source of truth is external; instead use Savable Data Pages that call your REST connector and map one composite payload (parent + children). In the edit form, bind the table/field-group lists to the page-lists and use the “Save (data page)” action so the full JSON (including embedded data) is sent. If the SOR can’t accept composite writes, implement a save plan: write parent, then child objects using the returned id, with rollback/compensation on failures. For navigation, use “Open data object” to the Details/Edit data views, not “Open work…”. Add ETag/version fields for concurrency and enable server-side paging/filtering on list views. If you need audit, log to a history table or raise a lightweight exception case only, not a case per CRUD