Summary

Choosing the right rule type makes your application smaller, easier to learn, and easier to maintain. This article introduces some less familiar rule types that you may find valuable but might have overlooked.

Suggested Approach

Which rule types do you use most?

Process Commander contains more than 80 rule types (like Rule-Obj-Flow) and 20 administrative data classes (like Data-Admin-Organization).

Some of these rule types, classes, properties, RuleSet names, activities and flows, for examples, are used in every application I've seen built. Others rule types have a special, narrow function and are useful only in settings that match that function. Most developers will never need Rule-Service-COM, but it is there when we do.

This article suggests some "neighbors" of familiar rule types and data classes that you may not use often, but which might offer just the right capability for your need. Choosing the most appropriate rule can:

• Make your application smaller (requiring fewer rules) - even elegant
• Make your application easier to learn and maintain
• Allow you to delegate more responsibility to business users

What's in a Category?

The App Explorer and Rules-by-Type Explorer group rule types and administrative data classes into nine categories: Property, Process, Decision and so on. Categories may include: Rule types that are interrelated. Flow action rules are referenced in flow rules, so both are assigned to the Process category. Rule types that are alternatives. Decision tables provide an alternative to decision tree rules in many situations, so both are in the Decision category. Types used by a common role: For example, administrators maintain all the objects in the Security category.

(Nine Categories)

Relationships come in four kinds

Rules that reference other rules are everywhere. Flows reference decision rules, decision rules reference properties, properties reference HTML property rules, and so on. At runtime, the elaborate and sophisticated rule resolution algorithm looks up the referenced rule dynamically, based on the user's RuleSets, inheritance, and so on.

Likewise, data objects can reference other data objects. Every operator belongs to an organization. In contrast to rules, such static relationships work like ordinary foreign keys in a relational database. If Operator Patricia is linked to the work group named Research, that fact will be true for every application at all times (until she tires of Research and moves to another work group).

Two thought exercises: Can rules reference data objects? Can data objects reference rules? Yes and Yes, but not very commonly. For example, a router activity (rule) typically references a workbasket (data object). A database table instance (Data-Admin-DB-Table) indicates the location of instances of a class (Rule-Obj-Class).

So each of four possible relationships among rule objects and data objects can happen. Knowing which two are common (rule to rule, data to data) and which two are rare (data to rule, rule to data) may help you remember the important differences between data and rule types. Next, more about some neighbors of rules you already know.

(RuleSet and Version)

Skill rules - a neighbor of flow rules

It's easy to overlook Skill rules when designing flows. A neighbor of flow rules in the Process category, skill rules (the Rule-Admin-Skill rule type) just define the name of a skill and a numeric range of allowed proficiency levels. The skill Conversational French might support ratings from 1 to 5, but other skills may be just binary - can you touch your toes, or not?

Matching incoming tasks to team members is a critical but often time-consuming responsibility for many managers of service operations. Who can do this best? Who is qualified? Who is idle or not backlogged? Through skill-based routing, your application can automatically make a good match between the skills needed to perform an assignment, and the skills of operators. Skill rules are referenced in Operator ID data instances and are valuable to routing new assignments. Properties in the assignment can specify both minimum skills needed to complete the assignment and desirable skills. Through functions in the Routing library, the application can find a best match or good match.

(Process Category)

Triggers - An alternative to expressions

Many Declare Expressions rules are evaluated "whenever inputs change." That's great if your application needs to present totals or other derived data to a user for her confirmation or decision.

But depending on how often the inputs change, Declare Expressions rules may do and redo computations that aren't actually needed. Consider Declare Trigger rules to lower the computation-intensity.

Both rule types can implement forward chaining. Because a trigger rule recomputes whenever an object of the Applies To class is saved or deleted (rather than whenever inputs change), it usually executes less often. Derived values stored in a saved work object (such as totals, averages, due dates) are assuredly consistent.   For example, the standard Declare Trigger rule named Work-.SetUpdateFields records information about the update date, time, and operator when a work object is saved. As the date and time are only known when the save occurs, it makes sense to compute them in a trigger rule rather than an expression rule. Because a trigger rule starts an activity, you can accomplish a little more than with an expression rule, though in both cases the computation should be brief. To reduce any impact on user response times, you can specify that the trigger activity run "in parallel", which of course assumes that the computed results are not needed in the user response.

(Decision Category)

Function aliases can simplify decisions

Most rule types in the Technical category require a programming perspective. For example, function rules (Rule-Utility-Function rule type) are very helpful in activities and expressions, but choosing and completing a function call may be challenging for business users. While a developer can easily learn this syntax

=Lib(PegaRULES_ExpressionEvaluators)CompareTwoDateTimes(d1, comparator,d2);

this may be harder for a line manager. A neighboring rule type, Rule-Alias-Function addresses this by providing a context or template for a function that can use the language and perspective of the application. Even a neutral presentation of the CompareTwoDateTimes function is easier to understand:

(Function Alias Rule)

Alias Function rules are visible in various rule types that are often delegated, including decision tree, decision table, map value, constraints, and expression rules.

"Thou shall not..." rules

When is it easier to list the DON'Ts than the DOs?

An overlooked rule type in the Security category is the Rule-Access-Deny-Obj. These rules complement Rule-Access-Role-Objrules by listing those operations (ability to Open, Delete, create rules that Apply To, and so on) that holders of a particular role cannot perform with respect to objects of a particular class. These are worth considering when your application's access control requirements are stated in negative terms rather than positive terms. Cynics may believe that such requirements appear only in written materials from lawyers, accountants, and regulators, but they can appear in any application. The form of a Rule-Access-Deny-Obj rule is similar to the Rule-Access-Role-Obj rule, but the runtime impact is the opposite. Break free from the Orwellian approach "Everything not permitted is forbidden" that normally governs object access in your application.

So if users in your application with Access Role ALPHA:INTAKE can create work objects but not update them, and users with access role ALPHA:WORKOUT can update and resolve work objects but not enter new ones... you can use DON'T and DOs.

Declare Index rules are not in the Decision category because..

Like all four other declarative rule types, Rule-Declare-Index rules execute automatically as soon as they are created. And like all four other declarative rule types, individual Rule-Declare-Index rules are not explicitly referenced by any other rules. They quietly carry out their assigned mission bidding, automatically and as-required. Unlike the other four declarative rule types, Rule-Declare-Index rules are part of the SysAdmin category. That's because they function similar to database views, a concept that system administrators may already understand. Index rules automatically add and delete instances of a concrete class derived from the Index- base class. For example, the standard Rule-Declare-Index rule named Work-.PartyURI writes out instances of Index-WorkPartyURI that support searches by party. On the Process Work panel, the Search for Work Associated with me by party function uses these index instances to rapidly fetch those that reference me as the Originator or Customer or another party. Why can't the system just search through the work objects for these reports? Party details are not at the top level of the work object structure; they are an embedded repeating group structure.

(Search that uses indexes)

Field Value Rules Support Data Entry of Property Values

A neighbor of property rules in the Property category, field value rules look simple, having three key parts and a few text fields. The key parts are familiar:

• Applies To class
• Property name
• Value

However, when referenced on the Table Edit tab of a property rule, field value rulescan limit and enumerate the values of that property. You can reduce the number of keystrokes that users need to enter a valid value. The Field Value approach to Table Edits works with the standard HTML property rule named PromptFieldValue. For example, the standard property Work -.pyRootCause uses this approach to suggest eight possible underlying causes for an exception including that faithful standby User Error. Because these choices are defined through field rules, they can be extended without altering the property rule itself.

(Field Value Rules)

Field value rules are important for applications that are to be localized, presenting the user interface in multiple languages.