Ruleset, class, and circumstance specialization

Among the three specialization techniques in Pega Platform, class specialization offers the most flexibility and potential for reuse through the following benefits:

• Classes provide 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. The Data-Party-Person and Data-Party-Operator classes, for example, override the WorkPartyRetrieve activity. 

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

Rulesets can be effectively used alongside classes to provide more flexibility in rule management and promotion strategies for each specialization.

The Pega Platform leverages ruleset specialization to support localization. Field values are stored in language-specific rulesets. Pega looks at the locale listed at the bottom of a user's Operator record's Profile tab to decide which ruleset to place at the top of the user's Application Profile ruleset stack.

Keep the following in mind when designing your ruleset structure:

• Two rulesets in the same application that define a rule with the same name in the same class mean that the rule in the lowest ruleset within the application stack would never be executed. 
• Ruleset resolution is more coarse-grained than class resolution. There is more flexibility to differentiate security rules, for example, using class specialization compared to ruleset specialization.
• Navigation between rules having the same name within different rulesets can be more confusing than navigation based on the class structure.

You can specialize a rule based on a property or date with circumstancing. Keep in mind that circumstance resolution occurs after class and ruleset resolution. 

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. Use Case Management > Tools > Find Rules > Find By Circumstance to search for circumstanced rules.

A benefit of circumstancing is that it enables you to see the base rule and its circumstanced variations side-by-side. Dev Studio supports viewing circumstanced case type rules this way, as well. 

There are several drawbacks to circumstancing case type rules as opposed to circumstancing other rule types, such as decision rules. Dev Studio displays rules using the requestor-level scope. You typically circumstance case type rules by using a case-related property. As a result, the system resolves circumstanced rules only in the context of a case, which is thread-level scope, run-time, not design-time. 

Due to its requestor-level scope, Dev Studio displays the base versions of circumstanced rules, such as flows. Opening a circumstanced rule from another rule display the base version of that rule. It is necessary to use the Action > View siblings menu option to locate the correct circumstanced variation of the base rule. This process can become tedious for numerous interrelated rules, as is typical for case design. Circumstanced case type rules are not a solution to this drawback.

A framework is a common work-processing foundation that you extend to an implementation. Designing a framework requires knowledge of how more than one implementation uses it.

Without this information, abstracting a model common to both implementations is difficult. Focus on the implementation at the beginning while watching for future specialization.

The following figure shows how Pega Platform supports ruleset and class specialization dimensions. In this example, the center of excellence (COE) team is responsible for locking down the base 01.01.01 MyApp application. The COE is also responsible for developing the next version of the foundation or base MyApp application (for example, 02.01.01):

Production applications, MyAppEU and MyAppUK, remain on MyApp 01.01.01 until they update to MyApp version 02.01.01. This process is similar to updating applications to a newer version of Pega Platform. The purpose of the Application Version axis is to permit the evolution (upgrading and versioning) of the applications, including the foundation application. Note how the production applications use the Ruleset dimension, although both applications do not need to leverage the Class dimension.

Assume that the UK user population is smaller than the non-UK user population and that both user populations remain in the original database. Also, assume that the UK wants to store its case data separately and chooses direct inheritance for its case type classes. The migration of the existing cases of the UK to new case type classes is necessary. Security is necessary to prevent the MyAppEU application from accessing MyAppUK data and vice versa.

From the perspective of the MyApp application, there is no difference between separating MyAppUK users into a new user population or starting with non-UK users first, then adding UK users later but to a UK-specific application. In either case, the MyApp application requires careful management because it supports two sets of users.

The MyAppEU application can use ruleset specialization because there is no need to migrate its user population's cases to different class names. This scenario is true whether the new or split-out user population uses the same or a new database. The only difference is that inheritance and extra security are necessary if the user population uses the same database. If the new user population moves to a new database, there is be no need to use the class dimension, and the ruleset dimension is sufficient. 

Check your knowledge with the following interaction: