Skimming collects the highest version of every rule in the RuleSet (except as noted below) and copies them to a new major or minor version of that RuleSet on the same system, with patch version 01. Skimming applies mainly to rule resolved rules, and there are exceptions to what gets skimmed based on the availability of the rule as well as the type of skim being performed.

Traditionally, there are two types of Skims, Major and Minor. These reflect the tri-partite naming convention for ruleset versions, Major-Minor-Patch. During a Minor skim, rules are stored in a higher Minor version, and during a Major skim, rules are stored in a higher Major version.

Examples

Major: Skimming rules in 06-05-01 through 06-09-25 into 07-01-01

Minor: Skimming rules in 06-05-01 through 06-09-25 into 06-10-01

Major Skim

During a major skim, rules with Availability of 'Yes', 'Blocked', and 'Final' are carried forward. Rules with availability of 'No' (not available) or 'Withdrawn' are filtered out. Blocked rules are carried forward because a Blocked rule can block rules in other rulesets, and that relationship should be maintained if it exists.

Minor Skim

During a minor skim, rules with Availability of 'Yes', 'Blocked', 'Withdrawn' and 'Final' are carried forward. Rules with availability of 'No' (shown as 'Not Available' in the table below) are filtered out.

Table of rules carried forward

The following table displays which rules are carried forward, based on availability.

Preparations

Before performing the operation, complete these steps:

1. Select Dev Studio > Application > Development > Checked Out Rules. Complete the parameters and click Run. Review the resulting report to confirm that no rules from that RuleSet version are checked out. Confirm that none of the rules to be skimmed are checked out.
2. If desired, secure each version below the new version, so the rules associated with that version cannot later be modified or deleted.
3. Select Dev Studio > System > Refactor> RuleSets > Skim a RuleSet to begin the skim operation.
4. After the operation completes, update application rules, the Requires RuleSets and Versions prerequisites array in RuleSet version rules, and access groups to reference the new major version.
5. Log off and log in to access the new version.

Completing the form

To skim to a new version:

1. Select a radio button to indicate whether the newly created version is to be a major version (NN-01-01) or a minor version (NN-MM-01).
2. Select a RuleSet to be skimmed in the RuleSet field. You can skim only RuleSets appearing on your RuleSet list.
3. Select an existing major version in the From Major Version field.
4. Select a version in the Starting Version and Ending Version fields.
5. Enter the version number to be created, consistent with the radio button you selected in Step 1.
6. Click Skim to begin processing. This may take several minutes.
7. The system creates a new RuleSet version and begins copying rules. A status area shows progress and the results of the skim.
8. If errors occur, click the Total Number of Errors link in the lower right corner of the display form to see any error messages. This list can't easily be accessed after you close the form; print the list so you can research and address the errors.
9. Click Close to exit.

A "No records found" message indicates that the rules associated with the RuleSet have no version and so were not altered.

Follow-up tasks

After the skim operation completes, these steps may be useful:

1. Research and resolve errors reported by the skim operation.
2. Update access groups or application rules to make the new major version available to appropriate users.
3. To ensure that all users access only the new major version, delete rules in the lower major version

See below: Class rules do not have a version. Do not delete Class rules (or other rules that have no version). In some organizations, policies may prohibit deleting old rules, even if they are not in use.

4. Optionally, delete rules after skimming

Skimming does not delete any rules; the rules it copies to make the new version remain unaltered.

When the skim operation completes, update each existing RuleSet Version that was skimmed to secure it by checking the Lock this Version? field on the Security tab. This ensures that from then on, developers can add or update rules only in the newly created version.

In addition to locking the RuleSet versions, in some organizations, administrators prefer to delete the rules in lower versions after the versions are skimmed. Deleting no-longer-used rules can benefit performance, because rule resolution has fewer rules to search through.

Of course, do not delete any class rules or library rules; rules of these two types (and others listed below) don't belong to a version and are needed while any version is in use. Use the Export Archive tool to back up a RuleSet version before deleting it.

In some organizations, compliance and audit requirements prohibit deleting rules, even those no longer in use.

Notes

Blocked rules are always skimmed. Withdrawn rules are skimmed during a minor skim, but not a major skim.

Rules in major versions below the major version you enter are not copied. For example, if you skim 02-ZZ-ZZ into 03-01-01, any rules in version 01-ZZ-ZZ are ignored.

Rules of these types do not have versions and therefore are unaffected by skim processing:

Skimming does not delete any rules. Skimming copies but does not update or delete rules in the source versions.

Skimming does not validate the copied rules, nor compile any Java. For rules of rule types that produce compiled Java, compilation occurs when the rule is first assembled and executed.

The Skim option is available only to users who have access to the zipMoveSkim privilege. The standard access role PegaRULES:SysAdm4 provides this privilege.

The update history of the new, skimmed rule contains only one instance, reflecting the date and time it was created through the skim operation. The history of the source rule remains available and unchanged.