State the Rule Resolution Process

Rule resolution follows 10 basic steps when determining which rule to use:

1. Check the rule cache. If the rule is present in the cache, go to Step 8.
2. Choose all instances with the correct purpose.
3. Discard rules where Availability is set to No/Draft.
4. Discard inapplicable rulesets and versions.
5. Discard all candidates not defined on a class in the ancestor tree.
6. Rank remaining candidates by:
a. Class
b. Ruleset
c. Circumstance
d. Circumstance Date
e. Date/Time
Remove all candidates that are withdrawn or hidden by other withdrawn candidates. Select the
first default rule encountered and discard the candidates in the remainder of the list.

Set the cache.

Find the best instance (and check to make sure there is not a duplicate rule).

Check that the Availability is not set to BLOCKED.

Security Verify that the user is authorized to see the rule.

Lets take a closer look at each of these steps.

Step 1: Check the Rule Cache

During this step, the system checks to see if Rule Resolution has already been run for this rule.
If it has, the cache will have a list of all possible candidates for this rule. By using this list, the
system can avoid the need to query the database for rules every time they are executed.
It is not necessary to cover exactly how caches work at this time. There will be separate lessons
that describe the various caches in the system. However, it is important to note that that cache
exists and is used for this step. The keys for this cache are covered when we examine step 7.
If a list is found in the cache, the system uses the candidates from the list and proceeds to step

8, where the list is evaluated. If it is not found, the system proceeds to build the list.

Example:

Lets walk through how the system finds the section CreateRequest shown below while
performing a PurchaseRequest:
First the system checks the cache for a previous Rule Resolution of the Section rule
CreateRequest that used the same parameters as this current request. Since this is our first
time running this rule, the rule is not found in the cache so the system proceeds to the next step.

Step 2: Choose all instances with the correct purpose.

During this step, the system gathers a list of all rules that match the purpose. Though often used
interchangeably, the purpose is more than just the rule name. It is the combination of all keys to
a rule, except the class on which the rule is defined (known as the AppliesTo class). At a
minimum, this will be the Rule Type and the Rule Name, with additional keys as needed
depending on the rule type.

Example:

The system needs to find all instances of a Rule-HTML-Section called CreateRequest. It

doesnt do any other filtering at this time, which still provides us a pretty lengthy list:

Step 3: Discard rules where Availability = No/Draft.

During this step, the system filters the list of candidates and removes any rules where the
Availability is set to either No or Draft.
Availability is defined on a rule to control how this rule should be treated during Rule Resolution.
An availability of No or Draft indicates that this rule is not able to be executed and should not
be considered for Rule Resolution.

Example:

Continuing with our example above, there are only three candidates that have their Availability
set to No as indicated by the shaded lines below.

These rules are removed from the list of candidates.

Step 4: Discard inapplicable Rulesets and Versions.

During this step, the system looks at the operators ruleset list (known as the Ruleset Stack). The
Ruleset Stack is covered in a different lesson. For this lesson, it is only important to know that
the Ruleset Stack defines the list of available rulesets for this operator and that the rules in those
rulesets must have the same Major version number and must be lower than or equal to the

specified Minor version number.

Example:

In our example, our operators list is defined as:

Purchasing:02-01
ADV:03-01
This removes eleven candidates from our list:

The three candidates from XYZ and Quoting are removed because their rulesets are not defined
in our Ruleset Stack. This makes sense because they belong to a completely different
application.
Within Purchasing, the three candidates from the 01-01-01 versions have been removed
because they dont match our current Major version of 02. The candidate from 02-02-01
matches the current Major version, but is still removed since its Minor version of 02 is higher than
our current Minor version of 01.
Within ADV, only one candidate matched our current Major version of 03. All the others have
been discarded.

Step 5: Discard all candidates not defined on a class in the ancestor tree.

The ancestor tree refers to a rules inheritance. Inheritance is defined in more detail in another
lesson. For this lesson, it is only important to remember that a class can inherit from other
classes, which allows for the reuse of rules.
This step is the first time that the system examines the AppliesTo class of the candidates. If the
AppliesTo class does not match the current class, or one of the current classes parents, then
those candidates are discarded.

Example:

In our example, we were currently executing a Purchase Request. There is only candidate that
is not in the ancestor tree of the Purchase Request:

Therefore, the candidate defined on ADV-Purchasing-Work-PurchaseOrder gets removed from

the list.

Step 6: Rank remaining candidates.

At this point, the system is trying to determine the order in which the candidates are the most
correct. A lot happens during the ranking step, three different sub steps actually occur.
1. First, the system sorts the candidates according to:

1. Class
2. Ruleset
3. Circumstance
4. Circumstance Date
5. Date/Time Range
6. Version
The first two ranks Class and Ruleset provide the basics of Rule Resolution. The closer the
candidate is to the class where it executes and the higher it is in the ruleset stack determine
which is the default rule.
The next three ranks Circumstance, Circumstance Date, and Date/Time Range are qualifiers
to those basics. They allow us to specialize even further to address all the possible outlier
cases. The exact details of these qualifiers and an in depth look at this portion of Rule
Resolution is covered in the Circumstancing lesson in this course.
Finally, the last rank Version ranks the candidates by the ruleset version that contains them.
This ensures that circumstanced rules are not automatically overridden if the base rule is
updated in a more recent ruleset version.

During the ranking process, the system evaluates any of the candidates that have their
Availability set to Withdrawn. Withdrawn is a special Availability that lets us skip over
some candidates. When a rule is marked as Withdrawn, it is removed from the list of
candidates as well as any additional candidates that match all of the following:
a. The same AppliesTo Class
b. The same Ruleset Name
c. The same Ruleset Major version
d. The same Purpose
e. The same Qualifiers

This is the definition of how to match a Withdrawn rule. However, during Rule Resolution, the
incompatible Major versions and Purposes have already been discarded in the preceding steps.
At this point, were only concerned with the rule being in the same class, in the same RuleSet
and having the same qualifiers.

The last thing the system does is determine the default candidate. A default candidate is
the first candidate (highest ranked) that has no qualifiers. This default candidate is the
last possible rule to be executed as it will always be a match to any additional requests
for this rule. Additional candidates ranked below this one are discarded.

Once these three steps of ranking are complete, the only candidates remaining will either have
some kind of qualifier and there will be a single non-qualified candidate.

Example:

Continuing our example, well first rank the results. Conveniently, our list is already in the correct
order that in which it was ranked.

Next, we see that there is a Withdrawn candidate defined on ADV-Purchasing-WorkPurchaseRequest in the Purchasing ruleset and there are no qualifiers. Well remove all
candidates on that same Class and ruleset that also have no qualifiers.

Once those have been removed, we look for the first candidate that does not have any
qualifiers. We find that ADV-Purchasing-Work in the Purchasing ruleset, Version 02-01-05 meets
this criteria, so the remainder of the list is removed.

This leaves us with only three candidates, two that have a qualifier and the default candidate.

Step 7: Set the cache.

This list is then stored in the cache for future Rule Resolution requests to leverage (in Step 1).
The system caches all the possible qualified combinations in a single list in order to improve its
reuse. If it only stored the exact match, there would have to be a new cache for every possible
scenario. This cache is keyed by the Ruleset Stack and the class that was being executed.

Example:

In our example, the result is that all the candidates are from ADV-Purchasing-Work.
However, since we were executing a Purchase Request, the key used when putting this list in the
cache is ADV-Purchasing-Work-PurchaseRequest.

Step 8: Find the best instance.

This is the final step that determines which candidate is the most likely one to be executed. Each
of the qualifiers is examined to see if there is a match. The system stops on the first match thats
available or the default if none of the qualifiers match. This allows us to use the qualifiers, such
as Circumstance, to specify the outlier processes while still maintaining a base default rule for
the majority of cases.

Example:

In our example, we have three possible candidates that are evaluated.

First PRPC evaluates if the condition for the Circumstance was met. Lets say the Circumstance
was Supplier=Restricted. If the value of Supplier equals Restricted then the system uses
the first candidate. Our Supplier is set to Open so we dont match and the system moves to

the next evaluation.

Now it evaluates a DateTime range. If the range on the candidate is specified as Before June
1st, 2000 and were executing this rule now, we dont match the date range, so the system
moves to the next evaluation.
The candidate does not have any qualifiers, so the system automatically chooses this candidate.
We now know which rule to execute.

Step 9: Check that Availability does not show Blocked.

Even though the systems narrowed down the selection to a single rule, Rule Resolution doesnt
stop there. There are still a couple more things to do. The system is going to check to see if the
Availability is set to Blocked. Like the other Availability settings, Blocked is used to instruct the
Rule Resolution process. In this case, a candidate that is Blocked tells the system that the rule
cannot be run. This is different than the No Availability. Where No says Dont pick me, pick
another rule, Blocked says You have the right rule but I dont want you to run.
To summarize the Availability settings:

Yes = Im OK to be executed.

No = Im not OK to be executed, pick someone else.

Withdrawn = Im not OK to be executed and neither are any of my earlier versions. Pick
someone else.

Blocked = Im not OK to be executed, but do not pick anyone else. Just dont execute.
Example:

In our example, the chosen candidate has Availability set to Yes, so this rule is not blocked and
is available to run.
If you remember, we did have a blocked rule in the original list of candidates, but that candidate
was discarded in Step 4.

Step 10: Security Verify that the user is authorized to see the rule.

The final piece of Rule Resolution is to check that the user has the correct authorization to
execute the rule. If the user does not have the correct authorization they are prevented from
executing. The features of security and how to configure them are covered in a different lesson
in this course.

Example:

In our example, the user has the correct authorization, so the section displays.

Rule availability options

Source: https://pdn.pega.com/reuse-and-version-management/rule-availability-options
As you create an application, you may wish to control how other developers can copy or change those
rules. For example, there may be a rule which must be used as is and cannot be changed (perhaps
for legal reasons), or there may be a rule which is now out-of-date and should not be considered
during rule resolution.
The Availability option on a rule allows you to prevent rules from being copied, or turn off rules which
had been in use (if they are no longer applicable, or a different rule was put in place), as a safeguard.
For example, you might create a new activity (ShowData) to replace an existing activity (Display).
As part of putting this new activity in place, you would have to change all references to the replaced
activity with the new activity, as this new activity has a different name (and presumably different
functionality).
If you left the replaced Activity in the system, then you could not be sure whether all instances of this
functionality had been replaced, because it would be used in processing; you might not see that the
wrong activity had been used until you got different results than you were expecting. However, if you
changed the Availability setting to Blockedfor the replaced activity, then if there were unchanged
references to that Activity in other places in the system, you would see errors when they were called
and know more changes were required. The Availability option guarantees that the system will not
accidentally use a decommissioned Rule.

The valid values for Availability are:

Yes

No

Blocked

Final

Withdrawn

Yes
If the Availability of a rule is marked as Yes, then that rule may be used for all processing work,
editing, saving, etc. You may copy and save this rule into any open RuleSet.
Final
Use the Availability value of Final to signal that this rule is the final version and should not be
changed. If the Availability of a rule is set to Final, that means that you may use this version of the
Rule, but you cannot save it into the same RuleSet, or a different RuleSet, unless you change its
name. Normally, if you wish to change a rule in a locked RuleSet version (the activity Display), you
would perform a Save As of that Rule into your application RuleSet, with the same name, and make
your changes. If the rule is marked Final, however, you may only do a Save As and copy it with a
different name (activity DisplayInvoice).
When rule resolution determines which rule to use, one of the keys that rule resolution sorts on is the
purpose the rule name. If you save a Final rule to another RuleSet and renamed, that changes its
purpose: When rule resolution looks for activities namedDisplay, then it does not not
find DisplayInvoice.
You can save final rule into a higher version of the same RuleSet, if the higher version is not locked.
This new version of the original rule also has Final availability
For the purposes of rule resolution, a rule with the Availability value Final is equivalent to the
value Yes.
No/Draft
When a rule is marked No/Draft, the system treats it as though it were not present at all; the system
ignores the rule and uses other rules. The Not Available label applies toone rule only. When the
system is gathering all the rules to consider for a rule resolution, any rule marked Not Available is
simply discarded.
This availability is sometimes referred to as the draft availability, as it can be used to test draft rules
before actually putting them into production. You can create a copy of a rule you wish to change,

make the change, and set availability to No/Draft in the main system, so the system will ignore that
rule. You can then check out the rule into your personal RuleSet and change the Availability to Yes
to test your change locally. This allows you to verify that the rule displays the behavior you want,
before setting the Availability of the changed rule to Yes for all users.
As an example, suppose there is an activity called Display, which is defined on classes at several
levels in the database:

Acme-Auto-ClaimsEntry-Accident

Acme-Auto-ClaimsEntry.DISPLAY

Acme-Auto

Acme-.DISPLAY
In the course of normal Rule Resolution, if the system needs the activity Display on the class AcmeAuto-ClaimsEntry-Accident, it will search that class first, and then the other three in the order listed. It
will find the Display activity defined on Acme-Auto-ClaimsEntry and use that one.

Acme-Auto-ClaimsEntry-Accident

Acme-Auto-ClaimsEntry.DISPLAY

(chosen rule)

If the Display activity on the class Acme-Auto-ClaimsEntry is set to have availability ofNo/Draft , the
Rule Resolution process will just flow around it, and the Display activity defined on Acme- will still be
used.

Acme-Auto-ClaimsEntry-Accident

Acme-Auto-ClaimsEntry.DISPLAY

Acme-Auto-

Acme-.DISPLAY

NOT AVAILABLE

(chosen rule)

Blocked
Unlike rules marked No, rules marked Blocked are still considered by rule resolution. If the rule
resolution process completes, and the one rule that is the final result of that process is marked
Blocked, then the process returns not found.

You can think of Blocked as blocking not just the rule, but the process. Since it will give an error at
the end of processing and stops the requestor, it is not an optimal solution, but a rule can be changed
immediately to take care of a crisis, and then a smoother handling of the situation may be
implemented later.
For example, a tornado could not only temporarily shut down an airport, but could render it unusable
for some unknown amount of time. The airlines would need to stop selling tickets or printing boarding
passes immediately to and from that destination.
If they were using a Process Commander application, they could just block the appropriate rules;
many errors would be thrown, but the processes would stop, and no tickets would be sold in error.
After the confused situation became clearer, and the airlines knew when the airport would be back in
service, the rules of the application could be rewritten to gracefully handle not selling during the outof-service period (instead of throwing an error and stopping the process), and then process normally
any requests for after the out-of-service period.
Using the example from the previous section, the rule resolution would function as follows:

Acme-Auto-ClaimsEntry-Accident

Acme-Auto-ClaimsEntry.DISPLAY

Acme-Auto

Acme-.DISPLAY

BLOCKED

Since Acme-Auto-ClaimsEntry.DISPLAY is the most accurate Rule for the purpose, it will be chosen;
but since it is marked BLOCKED, the process stops and returns not found. The system
does not continue looking at additional rules, and does not find the DISPLAY defined on the Acmeclass.
NOTE: It is possible to Block a circumstance-qualified rule. For example, suppose a rule was
circumstanced by the CustomerStatus property, with values of Gold Silver and Bronze. A
problem arose with the Gold rule (the discount was specified at 100% instead of 10%!), so
processing of the Gold customers needed to stop immediately. The company could simply change
the rule, but wouldnt know how many incorrectly-discounted orders were already in the system, so
they wanted to highlight them quickly. The Gold circumstanced rule was changed to have
availability Blocked.

In this case, processing for the Gold customers only would display the not found message. Other
users, who would not use that particular qualified Rule (CustomerStatus = Bronze), or the default
with no Customer Status value, are not affected.
Blocked vs. No
When the system is determining which rule to use, the Availability values of BLOCKED vs. NO will
change what rule is chosen.
If there were two versions of the activity DISPLAY:

Acme-.DISPLAY

AcmeCo:05-02

Acme-.DISPLAY

AcmeCo:05-01

if the 05-02 version of the rule were set to NO, the system would use the 05-01 version. if the 05-02
version of the rule were set to BLOCKED, the system would not use the 05-01 version, but would
return not found.
Withdrawn
Occasionally, you need to delete a rule from an application. If the incorrect rule is stored in an
unlocked RuleSet version, you can easily delete it. However, if the application has been moved to
other systems, however, or the rule is in a locked RuleSet version, it is no longer possible to change
or delete that rule. Instead, you can withdraw the rule.
The following are the most common situations where a withdrawn rule is useful:

You created a rule in a more specific RuleSet which overrode a rule in a base RuleSet,
because the rule in the base RuleSet didnt have desired functionality. (Example: You saved a rule
from the Pega-RULES RuleSet into your AcmeBank RuleSet.) However, a later release of the base
RuleSet does have the desired functionality, making the rule in your specific RuleSet no longer
necessary. (The next release of Process Commander had the functionality that AcmeBank wanted,
so you no longer need to override it in the AcmeBank RuleSet.)

You created a rule in an incorrect RuleSet, and must define it in a less-specific (lower)
RuleSet. (Example: You created a rule in the RuleSet AcmeBankMortgage, which is built on top of
the RuleSet AcmeBank. You realize that the rule should have been created in the AcmeBank
RuleSet, so that rule may be used by both the AcmeBankMortgage application, and the AcmeBank
CreditCard application.)

You created a rule in an incorrect class, and must define it in a less-specific (higher in the
hierarchy) class. Example: You created a rule in PegaSample-Task, and you now realize that it
should be created in PegaSample (so that other classes under PegaSample besides Task - may
use it.)

You must remove one circumstanced rule. Example: You created a rule which includes a
circumstanced version for states. Not all the states have specific versions, but you have at least 20
circumstanced versions of this rule. The NY version of the rule should be removed; in order to do
this prior to the withdrawnfunctionality, the rule would have to be copied to a higher RuleSet, and all
of the circumstanced versions except NY would also have to be moved.
If the Availability of a rule is set to Withdrawn, then those rules are removed from consideration during
the rule resolution process.

System Management Application (SMA)

Source: https://pdn.pega.com/products/system-management-application
SMA is built on Java Management Extensions (JMX) interface and is instrumented using
JMX objects called Managed Beans (MBeans), which expose their management interfaces
to the SMA applications through a JMX agent. JMX provides a standard API to monitor and
manage resources either locally or via remote access.
There are two sets of utilities in SMA, a standard set with functionality suitable for all
administrative and support users, and an advanced set with functions that are intended for
developers as they build and debug new applications. The advanced tools might also be
used under the guidance of Pegasystems support.
SMA can be accessed through PegaRULES Process Commander, the application servers
administration page, or directly through a browser.

Key Features

Listener Management: Displays information on running listeners; can be used to

start, stop, and restart listeners

Memory Management: Provides the counts and KB size in memory of active

requestors, system caches, and classes

Requestor Management: Displays information on requestors; can be used to interrupt

or stop requestors; provides access to the Profiler and Tracer tools

System Management: Displays information on the selected nodes system, requestor

counts, JVM, and build

Administration: Provides tools for monitoring aspects of the PRPC configuration

Agent Management: Displays information on running agents; can be used to start

and stop agents

Logging and Tracing: Displays information on garbage collection and log data

Ten Guardrails to Success

The Ten Guardrails to Success are design guidelines and recommended best practices for
Process Commander Implementations.
Following the fundamental principles promoted in the Ten Guardrails to Success leads to
rules-based applications that are well designed, straightforward to maintain, and architected
to build for Change. They are your keys to success with Process Commander.

Adopt an Iterative Approach

Define an initial project scope that can be delivered and provide business benefit
within 60-90 days from design to implementation.

Document five concrete use case scenarios up front and evaluate them at the end to
calibrate benefits.

Use your scenarios as story boards and ensure that each delivers a measurable
business benefit.

2. Establish a Robust Foundation

Design your class structure complying with the recommended class pattern.

It should be understandable, be easy to extend, and utilize the standard work and
data classes appropriately.

Use your organization entities as a starting pattern, and then proceed with class
groups.

Lead with work objects. Create the class structure and completed work objects
early.

Position rules correctly by class and/or RuleSet.

Actively use inheritance to prevent rule redundancy.

3. Do Nothing That is Hard

Use out of the box functionality as much as possible, especially in the initial project
release.

Avoid creating custom HTML screens or adding buttons.

Always use the Auto Generated HTML feature for harness sections and flow
actions.

Always use the standard rules, objects, and properties. Reporting, Urgency, Work
Status, and other built-in behaviors rely on standard properties.

Never add a property to control typical work or for managing the status or timing of
work.

4. Limit Custom Java

Avoid Java steps in activities when standard Process Commander rule types, library
functions, or activity methods are available.

Reserve your valuable time and Java skills for implementing things that do not
already exist.

5. Build for Change

Identify and define 10-100 specific rules that business users own and will maintain.

Activities should not be on this list. Use other rule types for business-maintained
logic.

6. Design Intent-driven Processes

Your application control structure must consist of flows and declarative rules, calling
activities only as needed.

Use flow actions to prompt a user for input.

Present fewer than five connector flow actions for any individual assignment. If you
need more than that, you need to redesign the process.

Create activity rules that implement only a single purpose to maximize reuse.

7. Create Easy-to-Read Flows

Your flows must fit on one page and must not contain more than 15 SmartShapes
(excluding Routers, Notify shapes and Connectors) per page.

If a flow has more than 15 SmartShapes:

o

Create a subflow.

Use parallel flows to perform additional functions

8. Monitor Performance Regularly

Evaluate and tune application performance at least weekly using Performance

Analyzer (PAL) to check rule and activity efficiency.

Use PAL early to establish benchmarks. Compare these readings to follow on

readings; correct application as required.

9. Calculate and Edit Declaratively, Not Procedurally

Whenever the value of a property is calculated or validated, you must use declarative
rules wherever appropriate.

Create a Declare Expressions rule instead of using a Property-Set method in an

activity.

Use a Declare Constraints rule instead of a Validation rule.

10. Keep Security Object-Oriented, Too

Your security design must be rule-based and role-driven based on who should have
access to each type of work.

Never code security controls in an activity.

Use the standard access roles that ship with Process Commander only as a starting
point.

Use RuleSets to segment related work for the purpose of introducing rule changes to
the business, not as a security measure.