Prerequisites and profile RuleSet lists are both lists of RuleSets and versions, but they have greatly different uses.
Both create a list of RuleSet versions, but
Two kinds of RuleSet lists are defined in different places for different purposes, and there is no relationship between the two.
NOTE: The Rule Resolution process does not cross major versions for rule searches. Thus, for Profile RuleSets, if the RuleSet isPega-RULES:03-02, then the user will not be able to see or use any rules from the RuleSet Pega-RULES:02-02, even though this version is less than the version 03-02. For the prerequisite RuleSet, a Prerequisite of major version 02 (RuleSet 02-02-01) would not be found if the major version 03 (03-01-01) is on the system.
Prerequisites are the list of RuleSets and their versions which must be present for a new rule created in an existing RuleSet to be validated upon creation, or for the rules in a new RuleSet to be validated properly (see Example #1).
The RuleSet and Version that is entered into the Prerequisite field of a RuleSet Version definition is an upper limit. If the Prerequisite for a particular RuleSet is Pega-ProCom:04-02-01, then any RuleSets in that major version (04) but below the specified version will be used: 04-01-24, 04-01-50, etc.
The system needs to contain the RuleSet and version specified in the Prerequisite RuleSet list. Due to the nature of upgrading RuleSets, all versions of a RuleSet within a major version will be present. If a customer receives PegaRULES RuleSet version 04-03-01, because of the way RuleSets are shipped, they will also receive versions 04-02-01 and 04-01-01. Thus, if the Prerequisite references Pega-ProCom version 04-01-01, and the overall system version of Pega-ProCom is version 04- 03 -01, new rules will still be validated, as long as all the rules referenced by a newly-created rule are present in a 04-01-01 version, to satisfy the Prerequisites. If some of the rules referenced by the new rule are present only in the 04-03-01 version, the validation will fail.(This should not happen with Pega- RuleSets; it may be an issue if you have many RuleSets that are frequently moved between systems.)
Prerequisites are specified in the appropriate instance of the Rule-RuleSet-Version class:
In the above example, the ACME RuleSet, version 01-01-01, is dependent upon the Pega-ProCom RuleSet, version 04-01-01. Pega-ProCom version 04-01-01 itself has a prerequisite:
Therefore, the ACME RuleSet has both Pega-ProCom 04-01-01 and Pega-RULES 04-01-01 as prerequisites, because Pega-ProCom 04-01-01 requires Pega-RULES 04-01-01.
Whenever a new rule that is subject to rule resolution is created (an Activity, a Flow, a When, etc.), it is defined on a class , and saved into a particular RuleSet and Version. If the class of the rule being created is not in the same RuleSet as the new rule, it is necessary that the RuleSet of the class be a prerequisite of the RuleSet of the new rule being validated; otherwise, the system will not be able to find the class, and errors will result. (See Example #2.)
When you save a new rule into a RuleSet, two validations occur:
First Validation - Is the RuleSet of the new rule valid?
In addition to their use when saving rules, prerequisites are used for validation when importing an entire RuleSet, or creating a new RuleSet. A RuleSet can only be imported into a system that contains all the RuleSets/versions that are listed in its Prerequisites. This guarantees that the moved rules reference only rules that the target system contains.
Thus, when developing a patch for an older version of a RuleSet, the Prerequisite RuleSet list would specify a dependency on the version of the rules that the organization has on-site. For example, Pegasystems or a partner may want to create a new RuleSet Version instance for a patch for an organization. The organization has version 04-01-01, but the current version that Pegasystems is working on is version 04-04-01. To prevent the developers from building on rules that were introduced in version 04-02, that the organization doesn't have, the prerequisite RuleSet list is set to 04-01-01, so we can be sure that the new patch will work on the organization's version.
Issue with Restricting RuleSets
A third issue may arise with saving a new rule into a RuleSet, from restrictions that are placed on the class itself. In the Class form, there is a field labeled Limit Rules Applied to This Class To These RuleSets:
If this field is left blank, then there are no restrictions on what RuleSets may extend this class - i.e., it is possible to define properties, activities, etc. on this class and save it into any RuleSet.
However, if one or more RuleSets are listed under the Limit Rules Applied field, then only those RuleSets may be used to extend the class (save objects on this class). This class is thus immediately limited to only those RuleSets that are listed in this field.
Profile RuleSet Lists
While prerequisite RuleSet lists govern the creation of new rules, profile RuleSet lists govern rule execution at runtime. The Profile RuleSet list is the list of RuleSets and their versions which must be present for the system to be able to choose and execute the correct rule (according to rule resolution) for actions at run-time. Profile RuleSets are specified through Access Groups, Organization, and Divisions, and show up in a user's Profile, as the user's RuleSets.
For whatever version of a RuleSet is displayed in the Profile RuleSet list, users will be able to see and use rules in RuleSets which are equal to or less than that version number. So if the user's Profile RuleSet includes Pega-RULES:04-02 , then the user will see any rules from that RuleSet that were saved in version 04-02 or 04-01. Rules that exist in the database at higher versions (04-04) will effectively be invisible. Again, these rules are only within a major version - if there are rules in version 03-12 on the system, the user will not see these, even though they are in a version less than the 04-02 version in the profile.