Ruleset, class, and circumstance specialization

By using class specialization in Pega Platform, developers can create new classes that inherit properties and methods from existing classes. Class specialization is a powerful tool that enables developers to create new classes that extend existing classes, adding 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 the Party, Assignment, and Work classes:

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 Profile tab of the user's Operator record.

Localization demonstrates Ruleset specialization in isolation. However, most Pega extensibility patterns rely on coordinated specialization across Application, Class, and Ruleset. This approach supports implementation scenarios such as extension point updates and other situational variations in enterprise solutions.

Consider the following when designing your Ruleset structure: 

• If two Rulesets in the same application hold 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 an order management application that has a requirement of defining different pricing levels for customers. A base pricing rule is first established for all customers. The base rule is then qualified by creating circumstanced rules for customers at different buying levels. The property .CustomerType, which is part of the customer order, has values such as "Silver" and "Gold". In this example, a customer has purchased an item priced at $100. Based on this property and its values, circumstanced instances of the base rule are created as follows:

• Base — if .CustomerType = "none", then Price = $100
• Circumstance 1 — if .CustomerType = "Gold", then Price = $100 − 25%
• Circumstance 2 — if .CustomerType = "Silver", then Price = $100 − 10%

When the system processes the order, the value of the CustomerType property determines which rule instance is applied, thereby determining the discount (if any) that the customer receives. 

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.  

Having many circumstanced versions of the same rule creates more complexity than separating rules by class. In Dev Studio, the App Explorer organizes circumstanced rules with expand-and-collapse navigation, which can make them harder to manage. Class-based separation often provides clearer organization and easier maintenance than relying on multiple circumstance variations.

Circumstancing provides the benefit of enabling you to view 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 Rule 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. You can locate the correct circumstanced variation of the base Rule by clicking 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: