As we know pega has introduced the concept of split schema, which is RULES schema and Data schema. What will be stored in that schema?
PegaRULES DB:
When we create any application the ultimate built on the application would be the PegaRULES application.
Pega will store Rules and system information about the Pega application in PegaRULES DB.
We can see some of the database tables mapped to the PegaRULES database.
For example, All our sections are instances of Rule-HTML-Section, and Rule-HTML-Section is pointed to the pr4_rule_section database table in the PegaRULES database, which means all exciting sections and created section rules will be stored in this table.
Properties (Rule-Obj-Property)created or already in the system will be in the pr4_rule_proeprty database table in the PegaRULES database.
PegaDATA DB:
All the information related to cases, assignments, and case history will be stored in the PegaDATA database.
We know assignments are the instances of a concrete class derived from the Assign- base class.
Assign-Worklist has mapped to the pc_assign_worklist stores all the assignments on the worklist.
Assign-Workbasket has mapped to pc_assign_workbasket stores all the assignments in the workbaskets.
Assign- is also mapped to pc_assign_worklist and stores external assignments and all other types of assignment but pxObjClass for these assignments is Assign-External
Click to see what is Worklist, workbasket and other Work-related terms Work terms
Click to see more on Assignment tables in Pega
Click to see more on standard pega tables
Why Pega splits the schema
- Upgrades and deployments: rules can be replaced during an upgrade or a release without touching the case data.
- Backup and restore: the rules schema is small and changes slowly. The data schema is large and changes every second, so the two are backed up differently.
- Performance and sizing: each schema can live on its own database or storage tier.
- Separation of duties: developers work on rules, while operations teams care for the data.
Quick reference
| Stored in | What | Examples |
|---|---|---|
| Rules schema (PegaRULES) | Rules and system information | Sections, properties, activities, flows |
| Data schema (PegaDATA) | Cases, assignments, history and other runtime data | Work objects, worklist and workbasket assignments, audit history |
A worked example
A bank promotes a new version of the Loan application. The release package holds a new section, three changed properties and a modified flow. Those all go into the rules schema. The thousands of open loan cases and their assignments live in the data schema, and are untouched by the deployment. After the release, the same cases simply run using the new rules.
Tips
- Check the database table mapping before creating a new data class. It tells you which schema the records will go to.
- Give the two schemas separate database users with the least privilege each needs.
- Size and monitor them separately. The data schema is the one that grows.
Interview tip
State the split in one line, rules and system information in PegaRULES and cases and history in PegaDATA, then give the release example and the two or three reasons for splitting. Related: in-place vs out-of-place upgrade.
No comments:
Post a Comment