Question
Cognizant
GB
Last activity: 8 May 2024 11:09 EDT
What are the key points to design a System Of Record Application in Pega
Lets say we are going to create a PEGA application, which will act like a database. Other applications would read or write(publish) data into that application. Data could be saved as draft and final mode. And also there should an archival logic.
What are the things one should consider while designing such PEGA application to get a most optimized solution.
(Case type, Datatype, Integrations and access control wise)
Accepted Solution
Updated: 8 May 2024 11:09 EDT
Aaseya IT Solutions
IN
Assuming you are catering to a typical RDBMS style structure. Case Type Wise:
- Ensure you understand the volumes in advance. If you are dealing with 1000s of records then designing a case type is good, but if you are crossing millions - you need to consider your licensing restrictions.
- Inserts / Updates / Delete - can be handled through a case type, but better to avoid Case types for read operations.
- You can create a generic case type to deal with multiple data types to reduce rework.
Data Type Wise:
- Avoid Blob columns for your data types as it will make integration or bulk data handling easier. Ex:- you can export data from DB directly if needed.
- Focus on audit history for your data types.
- Lot of times- you might need to understand the difference in data record update such as which fields got modified and previous / current value etc .
- You need to build logic to enable relationship between your records is managed consistenly as we don't use referential integrity by default.
Managing related records can become really messy and complex. Your access controls should be as granular as possible and extensible. You don't want to reinvent the wheel for each data type.
Assuming you are catering to a typical RDBMS style structure. Case Type Wise:
- Ensure you understand the volumes in advance. If you are dealing with 1000s of records then designing a case type is good, but if you are crossing millions - you need to consider your licensing restrictions.
- Inserts / Updates / Delete - can be handled through a case type, but better to avoid Case types for read operations.
- You can create a generic case type to deal with multiple data types to reduce rework.
Data Type Wise:
- Avoid Blob columns for your data types as it will make integration or bulk data handling easier. Ex:- you can export data from DB directly if needed.
- Focus on audit history for your data types.
- Lot of times- you might need to understand the difference in data record update such as which fields got modified and previous / current value etc .
- You need to build logic to enable relationship between your records is managed consistenly as we don't use referential integrity by default.
Managing related records can become really messy and complex. Your access controls should be as granular as possible and extensible. You don't want to reinvent the wheel for each data type.
Hope this helps.