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.
Branch rulesets can have one version only (by default, 01-01-01
). You cannot add versions to a branch ruleset.
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:
|
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.
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 Designer Studio > Application > Development> Checked Out Rules to identify rules that you (or someone else) has checked out in the current application, or in all applications. 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:
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. |
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.
You cannot edit any version if the To Update this RuleSet setting on the Security tab is locked.
Field |
Description |
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 Pega Platform 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 Version 4 or Version 5.2 system. The system assembles a complete required ruleset version list from:
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. 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. Do not delete the version in a branch ruleset and then save the ruleset rule form. After you delete the |
Component Class |
This field appears when you select The top-level abstract class for the component. |
Create new versions from the current ruleset form as follows:
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.
If there are no rules associated with a ruleset or version, you can delete the ruleset or version in this form.
If the ruleset has one or more associated rules, use the Ruleset Delete tool. Select Designer Studio> System > Refactor > RuleSets to start the tool.