Ruleset form
Working with the Versions tab
Use this tab to update any version rules defined for this ruleset, or to create additional versions.
Ruleset version rules identify a three-level version number for a ruleset. You can update these rules to prohibit changes to rules in the version, to record a start date for the version, and to identify any dependencies between this ruleset version and other rulesets.
Note: Branch rulesets can have one version only (by default, 01-01-01). You cannot add versions to a branch ruleset.
Validation mode
Validation modes guarantee that rules referenced are available on the target system and are accessible. Validation is performed at design time or at any time when a rule is saved. The selected validation mode applies to all versions of that ruleset. Application Validation is selected by default for new rulesets. For details on how Application Validation (AV) uses the application definition to determine which rules are valid to reference at design time, see Understanding Application Validation mode.
Mode
|
Description
|
|
Application Validation
|
Rules saved in this ruleset or any of its ruleset versions will use AV mode. You do not need to specify ruleset prerequisites with AV mode because they are implicitly defined by the application stack. Rules can reference any rules in the rulesets defined in the same application, or any of the built-on applications. They cannot reference rules outside the current application stack or above the defining application.
AV does not affect rule resolution at runtime.
 A guardrail warning is displayed at the time you save:
- An application— if any rulesets are using AV, have an unlocked version, and are listed in another application definition.
- An AV ruleset (name or version)— if there is an unlocked version of the ruleset and if the ruleset belongs to more than one application definition.
- An individual rule in an AV ruleset— if it references rules it does not have access to. (An error message explains that the rule cannot be referenced based on the validation settings.)
|
|
Ruleset Validation
|
This option requires that you specify prerequisites. The Required RuleSets and Versions section is enabled for this mode and can be modified or deleted. See Required RuleSets and Versions.
|
You can easily switch between validation modes on the ruleset form, although doing so could lead to invalid rules since AV is less restrictive than ruleset validation. Use the Validation tool to validate that the rules are still valid. See About the Validation tool.
Ruleset Validation (RV) mode requires that you specify prerequisites.
Basics
Field
|
Description
|
|
Secure
|
Identifies a locked or unlocked ruleset version.
Lock the ruleset version to prevent developers from saving new rule instances to this version, or updating or deleting existing instances. All instances using this version must be checked in before the version can be locked. Use the Checked Out column to identify the number of rule instances using this version that are checked out.
Click Lock/Unlock and Save to lock or unlock a version.
As a best practice, use the Guardrails landing page before locking a version of a ruleset, and research each warning message, eliminating those you can. Select  > Application > Development> Checked Out Rules to identify rules that you (or someone else) has checked out in the current application, or in all applications.
Note: As developers work, they may request that you create more ruleset versions and lock (that is, mark as secure) a ruleset version for which development is complete.
Each user or other requestor can access rules in only one major version of a ruleset. For example, access to version 06-10-15 includes access to 06-10-14 and 06-04-11, but not to 05-01-01.
Locking a ruleset version does not prevent:
- Changes to class rules in this ruleset, as a class belongs to a ruleset but not to a version.
- Adding or modifying versions in this ruleset.
- Modifying this ruleset.
To restrict these actions, use the Define Password settings on the Security tab.
|
|
Version
|
The second key part of the rule.
|
|
Description
|
Short description — initially from the Description field in the New or Save As form.
|
|
Approval required
|
Select to require a development approval workflow, identified in the RuleSet Name rule, for check in of rules for this version of this ruleset. See Using the Rule Check-In Flow.
|
|
Rules currently checked out
|
Displays the number of rule instances using this version that are currently checked out. You can click the displayed number to open a window in which you can see the number grouped by rule type. In that window, click the rule type to see the list of checked-out rules for that type, and which operators have them checked out.
|
|
All rules
|
Displays the number of rule instances using this version. If the number is not zero, click to open, in a separate window, a summary report showing counts by rule type. You can drill down from that report to lists of the rules in a type and then open the individual rules.
|
Editing a version
To edit a version, click the Expand icon to view its details. When you complete your updates, click the Save button to save the version. You can also click the Saveon the toolbar to save the ruleset and all versions.
Note: You cannot edit any version if the To Update this RuleSet setting on the Security tab is locked.
Field
|
Description
|
|
Required RuleSets And Versions
|
This section appears if you have Ruleset Validation mode selected. Enter one or more ruleset versions on which this ruleset version depends—that is, requires them as a prerequisite. For example, if you're creating a ruleset version for an application that will use activities and other rules in HomeSales:04-01-01, enter HomeSales:04-01-01. Enter all three pairs of digits in the version; you cannot enter a partial version here.
Typically, your application depends on the entire PRPC product. Enter the highest Pega-ProcessCommander version in your system or include a ruleset that has this ruleset as a prerequisite. This prevents the application from being moved with the Import Archive tool into a PRPC V4 or V5.2 system.
The system assembles a complete required ruleset version list from:
- All ruleset versions that you list in this field.
- All lower-numbered ruleset versions of this ruleset.
- All ruleset versions listed in the Required RuleSets and Versions field for those ruleset versions that you list in this field.
Therefore, if your ruleset depends on Alpha:02-01-01, and Alpha:02-01-01 depends on Beta:02-01-01, only list Alpha:02-01-01. It is not necessary to list Beta:02-01-01 because it is already listed in Alpha:02-01-01.
When developing rules in this ruleset version, developers can reference activities and other rules in any ruleset version in the total ruleset version list. The system also uses this information during the upload function of the Import Archive tool.
Note: Component-type rulesets can only depend on other Component or Shared-type rulesets. Shared-type rulesets can only depend on other Shared-type rulesets. You define Categories on the Categorytab. See Completing the Category tab.
|
|
Effective Start Date
|
This field is reserved for future use.
|
|
Enter Password to Add/Update Version
|
This field appears if you have used either the To Add a RuleSet Version or the To Update a RuleSet Version lock settings on Security tab.
To unlock the version, enter the password that matches the To Add or To Update password settings. The field is replaced by a check box  . Make your changes, save the version, and clear the box to lock it again.
|
| View History
|
Click to display a window containing the history of the ruleset version.
|
Lock and Save
|
Click to lock (or unlock) and save the ruleset version. A pop-up dialog appears. If you are locking the version, enter and confirm the password. if you are unlocking the version, enter the password. Click OK to close the dialog, change the lock status, and save the version.
|
| Save
|
Click to save your edits to the version.
|
| Delete
|
Click to delete a version if there are no rules associated with this version.
Note: Do not delete the version in a branch ruleset and then save the ruleset rule form. After you delete the 01-01-01 version from a branch ruleset and save the update ruleset, you cannot add a version to the branch ruleset. Only delete a branch ruleset's version if you intend to delete the branch ruleset.
|
|
Component Class
|
This field appears when you select Component in the ruleset Type field on the Category tab and is meaningful only for versions of component rulesets.
 The top-level abstract class for the component.
|
Adding versions
Create new versions from the current ruleset form as follows:
- Click
at the bottom of the ruleset version array. A New RuleSet Version form appears in a pop-up dialog. The ruleset name displays in read-only format on the form. The system automatically increments the current version by one patch number.
- Complete the form as described in Completing the Create New or Save As form.
- Click Create to generate the new version.
- Save the ruleset or click Savein the new version's row.
Note: You cannot create a ruleset version in this ruleset if the To Add a RuleSet Version or To Update this RuleSet settings on the Security tab are locked. Clear the settings on the tab and save the rule.
Alternatively, you can add versions to this or other rulesets by clicking New on the toolbar to open the New ruleset Version form. Select a ruleset Name and enter a version in Version field.
Deleting rulesets and versions
If there are no rules associated with a ruleset or version, you can delete the ruleset or version in this form.
- To delete a version, select a ruleset version row in the array and click the Delete button.
- To delete a ruleset, delete all of its versions as described above and click the Delete toolbar action.
Note: If the ruleset has one or more associated rules, use the Ruleset Delete tool. Select > System > Refactor > RuleSets to start the tool.
About Rulesets
Open topic with navigation
