Question
Common Data Model - queries
- In the CDM implementation guide, the CDM layer to referred to be fine tuned for MongoDB.
- Is the plan to support CDM layer with No SQL DB instead of SQL DB in the future?
- The current CDM implementations require the built-on/consuming applications to send a distinct value over the "Origin" property the data in the CDM layer can be segregated by applications at the data base level.
- Does that mean the READ calls happening to such database tables can get slower over time even if the application did not generate huge volumes of data?
- How does Pega handle the impact of growing volume on READ and WRITE operations on the tables that support the CDM layer.
- Since multiple applications can generate data into the same layer, can the READ operation performed by users of one application be affected by a huge volume of data generated by another application?
- When it comes to expansion, Pega's recommendation is to create more classes in the Common-LDM-Entity layer to hold more Entity classes on similar lines to Account, Contact, etc.,
- If a client had implemented an entity class (Say, Common-LDM-Entity-Account-Person), would Pega perform the due diligence to ensure the existing data model doesn't get affected when Pega CDM product offers the same class in a future release?
- Would Pega ensure the data model of the new class that is being offered is alignment with the data model of the client?
- What if multiple clients have created the same
- In the CDM implementation guide, the CDM layer to referred to be fine tuned for MongoDB.
- Is the plan to support CDM layer with No SQL DB instead of SQL DB in the future?
- The current CDM implementations require the built-on/consuming applications to send a distinct value over the "Origin" property the data in the CDM layer can be segregated by applications at the data base level.
- Does that mean the READ calls happening to such database tables can get slower over time even if the application did not generate huge volumes of data?
- How does Pega handle the impact of growing volume on READ and WRITE operations on the tables that support the CDM layer.
- Since multiple applications can generate data into the same layer, can the READ operation performed by users of one application be affected by a huge volume of data generated by another application?
- When it comes to expansion, Pega's recommendation is to create more classes in the Common-LDM-Entity layer to hold more Entity classes on similar lines to Account, Contact, etc.,
- If a client had implemented an entity class (Say, Common-LDM-Entity-Account-Person), would Pega perform the due diligence to ensure the existing data model doesn't get affected when Pega CDM product offers the same class in a future release?
- Would Pega ensure the data model of the new class that is being offered is alignment with the data model of the client?
- What if multiple clients have created the same class but with varying data model? How would Pega ensure to not have a negative impact while releasing the same class as part of the product?
- Alternatively, does Pega claim that CDM as a product will not grow beyond it's current state in terms of data model?
- Are the clients expected to create processes, data transforms, activities, properties, validation rules in the Common layer?
- Does this mean that irrespective of the built-on application, the processes are expected to be built in the same layer?
- Would such design make the CDM layer bulky and hard to maintain?
- Why does CDM not support class specialization?
- In case if two built-on applications have the same process with minor deviations,
- A when rule based on "Origin" is expected to be used.
- A circumstanced rule
- Ruleset specialization - The rule is in Common-LDM-Entity-xyz layer but in the Application ruleset.
- Does this mean that irrespective of the built-on application, the processes are expected to be built in the same layer?
Accepted Solution
Updated: 26 Mar 2024 5:20 EDT
Pegasystems Inc.
US
1. Adding indexes and columns to existing OOTB tables is within the scope of an application implementation and is expected.
2.Common- is a class that is shipped OOTB but this does not preclude you from extending from this class. Many examples of extension of OOTB classes in platform and strategic applications exist.
3. Class specialization including directed inheritance and sub-classing is still supported.
4. If leveraging external data you would per best practice replace the OOTB api's with your own. If storing data locally you can extend the CDM patterns to support your data structure. For read operations of objects we are reading the entire blob. For searches we are of course going against report definitions which depend on exposed columns and or declare indexes.
Pegasystems Inc.
US
Currently the model is optimized for a document centric approach which is more NO SQL like but not directly designed for that. No current plans for NoSQL support.
Data volume and scale would follow the same best practices as core platform.
Since the early 8 series platform no longer creates implementation data classes in the new application wizard. You can still create implementation specific data classes but this is not longer required. Ruleset specialization is usually sufficient.
Core entities do support class specialization such as sub-classing.
Areteans Technology Solutions
AU
- Data volume and scale would follow the same best practices as core platform.
- The core platform supports applications to have their own application specific data layer. This allows various applications to have their data maintained in their own set of tables thereby segregating the volumes.
- Given that the data generated by more than 1 application can be captured, maintained and supported from a single common layer, the volume can be a lot more than usual.
- This would mean, Pega developers would want to create DB indexes to improve the performance of the tables underlying the common entities (Both OoTB and newly created DB table entities).
- Is this not considered as Product customization?
- Expanding the OoTB Common- layer would typically be seen as product customization.
- It is almost like making changes to Work-Cover- or Assign- given that Common- is a product class.
- The primary concern is around the impact of upgrade as client would have customised the actual CDM product in their implementation. (More classes, More column in existing tables, New tables, etc)
- If, class specialization is still supported
- Can I create something like MyOrg-App-Entity-Account which inherits from Common-LDM-Entity-Account.
- This is to hold rules like DataTransforms, Flows, etc in the App specific class instead of the Common class to ensure there is no hard dependency over the underlying product as it is expected to evolve.
- CDM recommends the use of REST APIs to perform CRUD operation on the Entities.
- READ is currently supported by Report Definition rules to pull exposed columns.
- How would the unexposed columns and embedded pages/ pagelists be returned?
- Alternatively, are the entity classes expected to be fully flat and exposed?
Accepted Solution
Updated: 26 Mar 2024 5:20 EDT
Pegasystems Inc.
US
1. Adding indexes and columns to existing OOTB tables is within the scope of an application implementation and is expected.
2.Common- is a class that is shipped OOTB but this does not preclude you from extending from this class. Many examples of extension of OOTB classes in platform and strategic applications exist.
3. Class specialization including directed inheritance and sub-classing is still supported.
4. If leveraging external data you would per best practice replace the OOTB api's with your own. If storing data locally you can extend the CDM patterns to support your data structure. For read operations of objects we are reading the entire blob. For searches we are of course going against report definitions which depend on exposed columns and or declare indexes.