When to create shared RuleSets
Summary
Beginning in Version 5.4, you may designate a RuleSet as type Shared.
This designation has a specific meaning, and may not apply to all RuleSets which are used by more than one application.
Suggested Approach
The ability to reuse already-built structures is a key advantage of Process Commander, saving development time and effort. Among other objects, RuleSets may be designed to be used by more than one application.
Beginning in V5.4, you can designate a RuleSet Type in the RuleSet Name rule form:
One of the RuleSet Type values is Shared. (For details on the other RuleSet Types, reference the Application Developer Help.)
A RuleSet of type Shared should contain rules which may be shared across multiple applications in the organization. These RuleSets should not contain encapsulated functionality, but individual or small groups of rules that contain data like the corporate logo or templates for company memos.
Shared RuleSets are not intended to be independent RuleSets (like Component RuleSets – see About Components). Instead, they are meant to contain low-level rules which are shared across all applications. Unlike Components, which have their own component class, Shared RuleSets should not contain classes.
Applications built in prior versions of Process Commander may have had RuleSets or classes which everybody referred to as “shared.” Enterprise customers built frameworks, which would then be used as the basis to create different applications for their divisions. (For example, a loan framework might be used to build the MortgageLoan, CarLoan, and LuxuryItemsLoan applications.) If an enterprise customer had multiple frameworks, there might be some rules which they wanted to share across frameworks – activities or properties defined on the Work- class, for example.
In these prior versions, it was not possible to save rules defined on Work-
(such as new activities or properties) to your RuleSet; a “Shared-Work” class was necessary to save these rules, so they would be available to all the frameworks. Beginning in Version 5.4, however, you can save rules defined on the Work- class in your RuleSets; the “Shared-Work” class is no longer necessary.
You may have RuleSets which are used in more than one application, which you also called “shared.” These should not necessarily be immediately marked as type Shared, since this RuleSet Type is now a much tighter definition than just “used in more than one application” – the definition of type Shared includes no classes, and very low-level rules.
Another important feature of Shared RuleSets, which distinguishes them from RuleSets “used in more than one application,” is the fact that Shared and Component RuleSets will sort to the bottom of an application RuleSet List – only the Process Commander RuleSets are lower in the list. (See Example below.) This means that the rules in a Shared RuleSet cannot depend upon functionality from any other RuleSets except for Process Commander RuleSets – including other Shared or Component RuleSets (since they may be listed in a different order in different application rule definitions).
If you have functionality in a RuleSet which is included in several applications, and you think this RuleSet should be designated as type Shared, look at where that RuleSet is in the current application RuleSet List. If this RuleSet contains classes, or if it depends upon other RuleSets which are lower in the list, then it cannot be marked as type Shared, even if you consider this a “shared” RuleSet. This RuleSet must be defined as type Standard, and listed under the Application RuleSets section of the application rule.
Example: AcmeMortgage
The AcmeMortgage application rule is shown above. In order for AcmeMortgage to run in the system, it requires the AcmeBank application. The AcmeMortgage application contains the following RuleSets:
Override RuleSets: none
Production RuleSets:
- MortgageManagers:01-03
Application RuleSets:
- GovernmentReporting:02-02
- Underwriting:02-02
- DocumentManagement:02-02
- Mortgage:02-02
Component/Shared RuleSets:
- CreditRatingRS:01-01-01 (component)
- AcmeLogos:03-01-01 (shared)
AcmeMortgage is built on the AcmeBank application. The AcmeBank application contains the following RuleSets:
Override RuleSets:
- AcmeBankOverrides:01-01
Production RuleSets:
- AcmeBank:04-02
Application RuleSets:
- CreditScoring:04-01
- GeneralLedgerInterface:04-01
- AcmeBank:04-01
Component/Shared RuleSets:
- GoogleSearch:01-03-02 (component)
- AcmeLogos:02-10-04 (shared)
In turn, this application is built on the PegaFinance application.
PegaFinance includes:
Override RuleSets: none
Production RuleSets: none
Application RuleSets:
- SwiftNetE-I:05-03
- PegaComBanking:05-03
- PegaAppCorr:05-03
- PegaAppFin:05-03
Component/Shared RuleSets:
- Finance:05-03
This app is built on the PegaRULES application, which contains:
Override RuleSets: none
Production RuleSets: none
Application RuleSets:
- Pega-ProCom:05-04
- Pega-IntSvcs:05-04
- Pega-WB:05-04
- Pega-RULES:05-04
Component/Shared RuleSets: none
Thus, the full RuleSet List for the AcmeMortgage application, in order, would include:
- MortgageManagers:01-03 (production)
- GovernmentReporting:02-02
- Underwriting:02-02 AcmeMortgage app
- DocumentManagement:02-02
- Mortgage:02-02
- CreditScoring:04-01
- GeneralLedgerInterface:04-01 AcmeBank prerequisite app
- AcmeBank:04-01
- SwiftNetE-I:05-03
- PegaComBanking:05-03 PegaFinance prerequisite app
- PegaAppCorr:05-03
- PegaAppFin:05-03
- CreditRatingRS:01-01-01 (component)
- AcmeLogos:03-01-01 (shared) component and shared RuleSets
- GoogleSearch:01-03-02 (component)
- Finance:05-03 (shared)
- Pega-ProCom:05-04
- Pega-IntSvcs:05-04 PegaRULES application
- Pega-WB:05-04
- Pega-RULES:05-04
Note that the Component and Shared RuleSets for not only the “main” application (AcmeMortgage) but also for the “built-on” applications are all sorted to the bottom of the list, with only the PegaRULES base application below them. This is why Shared RuleSets may depend upon rules from the PegaRULES RuleSets, but not on any other RuleSets. They even cannot depend upon the functionality in any other Shared RuleSets, or in any Components, as these may be defined in a different order for different applications.
Note also that if the main Application rule (in this example, AcmeMortgage) specifies a shared RuleSet which is also contained in the prerequisite application, then the definition specified in the main application supercedes the information in the prerequisite – even if the RuleSet in the prerequisite application is a higher version than the RuleSet in the main application.
As an example, suppose the AcmeMortgage application includes the following component and shared RuleSets:
- CreditRatingRS:01-01-01
- AcmeLogos:02-03-01
The prerequisite AcmeBank application contains the following RuleSets:
- GoogleSearch:01-03-02
- AcmeLogos:03-01-01
Combining these RuleSets would give:
- CreditRatingRS:01-01-01
- AcmeLogos:02-03-01
- GoogleSearch:01-03-02
- AcmeLogos:03-01-01
Because the definition for AcmeMortgage overrides the prerequisite application, the AcmeLogos RuleSet which is lower in the list would be discarded, even though it has a higher RuleSet Version. Therefore, the shared and component RuleSets for AcmeMortgage would include, in order:
- CreditRatingRS:01-01-01
- AcmeLogos:02-03-01
- GoogleSearch:01-03-02