Working with Rules

Rules Package Overview

Rule packages are bundles of rules. Rule packages are used to group, manage, and deploy rules. The rules in a rule package provide a set of functionality (like an iWD solution). The Genesys Rules Authoring Tool (GRAT) allows you to create, edit, and delete rule packages.

Rule packages provide the following capabilities:

• The ability to partition rules and facts so that they are small, well-defined, and apply only to a particular application or use. This makes them easier to debug and understand. The fact model is a description of the data. It contains field names and types which are grouped into tables/classes. Facts are input/output to rule execution and are instances of the tables/classes defined in the fact model.
• The ability to isolate rule packages from one another when executing rules. This also improves performance because the Rules Engine has fewer candidates to examine during the evaluation.
• The ability to update individual rule packages without affecting other deployed packages.
• The ability to import and export an entire rule package containing the rule definitions, business calendars, and also the templates that the rule package is dependent on.
• A rule package contains one or more rules plus the fact model that is needed to support the rules. You deploy rule packages individually to the Rules Engine.

When you select an existing rule package in the Explorer Tree, four tabs are displayed in the Details Panel:

• The General tab displays the basic information for the rule package, such as name, type, and the associated templates.
• The Rules tab allows you to create, edit, and view rules. When you click the rule package node and then the Rules tab, you can create, edit and view rules at the global level for that package. Clicking on the other nodes (which represent various business contexts) enables you to modify the rules defined for that specific business context.
• The Audit Trail tab allows you to view the history of the individual rules, such as when they were updated or deployed, and by whom.
• The Package History tab allows you to view the history of a package and its versions and snapshots, including changes to rules, templates, calendars, test scenarios, imports/exports and deployments. History for all packages across one tenant can also be displayed at the tenant level.

As well as creating a rule package, the GRAT enables you to import and export existing rule packages. This ability enables you, for example, to import a rules package from a test environment to a production environment, or to export a rules package for backup prior to upgrading.

Rules Overview

A business rule is a piece of logic that defines, on a small scale, what a business does. For the Genesys Rules System, a rule is an external piece of logic that can be customized by business analysts, and invoked by applications. This allows you to tune specific business behaviors as needed.

Types of Rule

GRAT allows you to configure two types of rules:

Linear rules follow the following basic format:

WHEN {condition} THEN {action}

When the condition is true, the action will occur. This form of rule is best for simple actions, such as assigning a value to return back to the application. Note, however, that linear rules can have multiple conditions and actions, or only actions with no conditions. The conditions and actions that are available depend upon the rule templates that are included in the rule package.

Decision tables allow you to join a number of Linear Rules with the same set of conditions (when) and actions (then) to be used for a complex (structured) business case. Use decision tables to avoid dozens of linear rules with identical structure in the system.

Order of Execution

You can configure rules for various business contexts (nodes representing the various elements in your business structure hierarchy), or, for global rules, at the rule package level. In the Explorer panel, each business context within the configured business structure is represented at a different node level. The order of execution of rules within a rule package depends on the node level: rules execute first at package/global level, then at each level of the hierarchy in turn.

So if you have defined this hierarchy:

• Package
  • Sales Department
    • Finance

and during execution, you specify “Sales Department” / “Finance”, then the order of execution is:

1. Rules at Package level (according to priority).
2. Rules at Sales Department (according to priority).
3. Rules in Finance (according to priority).

Within a given node, you can modify the order of execution by using the up or down arrows on each rule.

Only rules on a particular node path are executed in any given rules run. The path of execution is determined by input to the Rules Engine on the execution request.

Important

The business structure is defined in Configuration Manager or Genesys Administrator.

Important

Before release 8.5.0, rules in Decision Tables were executed from the bottom up. From release 8.5.0, system administrators can configure rule execution to be "bottom-up" or "top-down". The Rule Evaluation Order indicator at the bottom of the screen shows you which of these is selected, and a ToolTip is available when you hover your cursor over this indicator. Any changes made to this configuration will apply dynamically, but only take effect after a restart or a browser refresh.

Locking of Rules

When you make any modifications to the body of a rule, you "lock" the rule, which prevents others from being able to make changes to the same rule at the same time. The unsaved changes icon will appear on the Rule Summary to alert you that you need to save your changes. For any other user, the Lock icon appears on the rule summary and the Save and Cancel buttons are disabled. In addition, other users are unable to make changes to the rule because it is marked "read only".

You can modify multiple rules at a time, without explicitly saving your changes as you move from one rule to the next. The Rule Summary will indicate whether there are any unsaved changes that need to be saved. Once the rule is saved, it is "unlocked" and other users will be able to modify it. You can also Cancel any unsaved changes, reverting the rule back to the last saved state.

If you log out of your session, you will be prompted if you have unsaved changes. You may then either go back and save your changes, or continue with the logout. In the latter case, the changes you made will be lost and not committed, and the rules will be unlocked.

Audit Trail

The Audit Trail tab allows you to view the history of the individual rules, such as when they were updated or deployed, and by whom. When accessed within a business context (a node on the Explorer Tree), the Audit Trail tab lists the rules that exist for that business context.