Ruleset, class, and circumstance specialization

Code developed according to object-oriented principles is inherently extensible. Pega supports rule specialization by ruleset, class, and circumstance.

Among the three specialization techniques in Pega, class specialization offers the most flexibility and reuse potential. 

• 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 tend to be easier to differentiate and navigate than those separated by rulesets or circumstances alone.

The Data-Party class hierarchy is an example of class specialization. Any rules in the Data-Party class can be reused as well as overridden by derived classes. The Data-Party-Person.and Data-Party-Operator classes, for example, override the WorkPartyRetrieve activity.

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 means 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.

Circumstances allow you to specialize a rule based on a property or a date. Keep in mind that circumstance resolution occurs after class and ruleset resolution. 

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

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

A benefit of circumstancing is that it enables you to see the base rule and its circumstanced variations side-by-side. The Case Designer 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. Case type rules are normally circumstanced using a case-related property. As a result, circumstanced rules are only resolved in the context of a case, which is thread-level scope, run-time not design-time.

Due to its requestor-level scope, the Case Designer always displays the base versions of circumstanced rules, such as flows. Opening a circumstanced rule from another rule will display the base version of that rule. It is necessary to use the rule’s Action > View siblings menu option to locate the correct circumstanced variation of the base rule. For numerous inter-related rules, as is typical for case design, this process can become tedious. Circumstanced case type rules, which can be viewed in the Case Designer, is 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 image shows how the 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 built on MyApp 01.01.01 until they are ready to upgrade to the 02.01.01 version of MyApp. This is similar to upgrading 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 leverage 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 so chooses direct inheritance for its case type classes. It is necessary to migrate UK's existing cases to new case type classes, plus security needs to be in place to prevent the MyAppEU application from accessing MyAppUK data and vice versa.

From the MyApp’s Application perspective, 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 must be carefully managed 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 is true whether the same database or a new database is used for the new or split-out user population. The only difference is that, if the same database is used, inheritance and extra security are necessary. Were the new user population to be moved to a new database, there would be no need to leverage the Class dimension. Ruleset dimension could suffice.