Ruleset, class, and circumstance specialization

In Pega Platform, class specialization is a concept that enables developers to create new classes that inherit properties and methods from existing classes. Class specialization is a powerful tool that enables developers to create new classes similar to existing classes, but with additional or modified functionality. 

Class specialization in Pega Platform offers the most flexibility and potential for reuse among the three specialization techniques, by providing the following benefits: 

• Classes offer the most out-of-the-box security flexibility. 
• Classes provide the most flexibility for persistence options. 
• Classes take precedence during rule resolution. 
• Rules separated by classes are easier to differentiate and navigate than those separated by rulesets or circumstances alone. 

The Data-Party class hierarchy is an example of class specialization. You can reuse any rules in the Data-Party class, and derived classes can override the rules. For instance, the WorkPartyRetrieve activity is overridden by the Data-Party-Person and Data-Party-Operator classes. 

The following table shows the class hierarchy of Party class, Assignment class and Work class

Rulesets can effectively complement classes to provide more flexibility in managing rules and promoting strategies for each specialization.

Pega Platform uses ruleset specialization to support localization. Field values are stored in language-specific rulesets. Pega Platform determines which ruleset to place at the top of the user's Application Profile ruleset stack by looking at the locale listed at the bottom of the user's Operator record's Profile tab. 

Consider the following when designing your ruleset structure: 

• If two rulesets in the same application define a rule with the same name in the same class, the rule in the lowest ruleset within the application stack will never be run. 
• Ruleset resolution is less precise than class resolution. There is more flexibility to differentiate security rules, for example, by using class specialization compared to ruleset specialization. 
• Navigation between rules with the same name in different rulesets can be more confusing than navigation based on the class structure.

Circumstance specialization is a technique to create variations of a rule based on specific conditions or properties. It helps manage different scenarios without changing the core logic of the application. You can specialize a rule based on a property or date by using circumstancing. Keep in mind that circumstance resolution occurs after class and ruleset resolution. 

For instance, consider a loan approval application that offers different interest rates based on the customer's credit score. Instead of creating separate rules for each credit score range, you can use circumstance specialization to create variations of the base rule. 

Create a base rule that calculates the interest rate for a loan. Circumstance the base rule by using the property CreditScore. Create specialized rules for different credit score ranges, such as: 

• Circumstance 1: If 'CreditScore' is between 300 and 579, set the interest rate to 10%. 
• Circumstance 2: If 'CreditScore' is between 580 and 669, set the interest rate to 8%. 
• Circumstance 3: If CreditScore is between 670 and 739, set the interest rate to 6%. 

At runtime, the system evaluates the CreditScore property and selects the appropriate specialized rule to calculate the interest rate. This approach simplifies the application logic and makes it easier to maintain. 

Security across circumstances does not exist. For example, without customizing security rules, you cannot control read/write access to rules in the same class and ruleset with different circumstances.  

Also, having many circumstance versions of the same rule can be more difficult to navigate than having rules that are separated by classes. Dev Studio displays circumstanced rules through expand-and-collapse navigation in the App Explorer. To search for circumstanced rules, click Case Management > Tools > Find Rules > Find By Circumstance. 

Circumstancing provides the benefit of enabling you to see the base rule and its circumstanced variations side-by-side. Dev Studio also supports viewing circumstanced case type rules in this way. 

Circumstancing case type rules has several drawbacks compared to circumstancing other rule types, such as decision rules. Dev Studio displays rules in the requestor-level scope. Case type rules are typically circumstanced using a case-related property, which results in the system resolving circumstanced rules only in the context of a case. This is thread-level scope at run-time, not design time. 

Dev Studio displays the base versions of circumstanced rules, such as flows, because of the requestor-level scope. When opening a circumstanced rule from another rule, the base version of that rule is displayed. To locate the correct circumstanced variation of the base rule, it is necessary to click the Action > View siblings menu. This process can become tedious for numerous interrelated rules, which is typical of case design. Circumstanced case type rules do not solve this drawback.

Check your knowledge with the following interaction: