Back Forward Ruleset form
Working with the Versions tab
  1. About 
  2. New 
  3. Versions 
  4. Security 
  5. Category 
  6. History 
  7. More... 

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 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-Based Validation (ABV) uses the application definition to determine which rules are valid to reference at design time, see Understanding Application-Based Validation mode.

Mode

Description

Application Validation

Rules saved in this ruleset or any of its ruleset versions will use ABV. You do not need to specify ruleset prerequisites with ABV 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.

ABV does not affect rule resolution at runtime.

Caution A guardrail warning is displayed at the time you save:

  • An application—if any rulesets are using ABV, have an unlocked version, and are listed in another application definition.
  • An ABV 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 ABV 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 ABV is less restrictive than ruleset validation. Use the Validation tool to validate that the rules are still valid.   About the Validation tool.

Ruleset Prerequisite-Based Validation (RSP) 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 the Lock/Unlock and Save button to lock or unlock a version.

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

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

CautionLocking 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 Save on 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

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 version 4 or 5.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. There's no need 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 Category tab. See Completing the Category tab.

Effective Start Date

Advanced featureOptional. Enter an effective date for the rules in this ruleset version to support historical processing. Use the format YYYYMMDD or click the calendar icon () to choose a date.

This value does not affect normal system operation; rules in this ruleset version are available before and after the date.

If you leave this field blank and save the Version form, the system enters in this field the date that this version rule was created.

The Effective Starting value affects processing only for requestor sessions that execute the PublicAPI method setRuleSets() to establish a cutoff date for rulesets. This function revises the requestor session ruleset list to exclude rulesets with an effective date later than a supplied date. To negate or turn off historical processing, call restoreRuleSetList().Your activity can call setRuleSets() multiple times with successively earlier dates, but you can't advance the date. So, to turn on 2005 processing after previously turning on 2003 processing, return to the current date with restoreRuleSetList() first.

Such historical processing allows only "as-was" rules to apply (when this field is completed accurately and the setRuleSets() capability is enabled). For example, tax processing performed in 2005 may apply the tax rules in force as of January 1, 2003, if properly configured.

NoteDon't enter a future date in this field. A future date does not prevent the rules in this ruleset version from being found by rule resolution.

See Contrasting time-qualified rules, date-time circumstances, and historical processing.

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

SmartPromptThe top-level abstract class for the component.

Adding versions

Create new versions from the current ruleset form as follows:

  1. 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.
  2. Complete the form as described in Completing the Create New or Save As form.
  3. Click Create to generate the new version.
  4. Save the ruleset or click Save in the new version's row.

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.

If the ruleset has one or more associated rules, use the Ruleset Delete tool. Select > System > Tools > Refactor RuleSets > Delete a ruleset to start the tool.

Definitions

check in, checkout, delegated rules, personal ruleset
Related topics About the Ruleset Delete tool
Related topics Understanding Application-Based Validation mode
Standard rules Atlas — Standard Ruleset Names

Up About Rulesets