Jump to: navigation, search

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 Grs auth-tool up.gif or down Grs auth-tool down.gif 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 Grs auth-tool unsaved.gif will appear on the Rule Summary to alert you that you need to save your changes. For any other user, the Lock icon Grs auth-tool lock.gif 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.

This page was last edited on May 23, 2014, at 07:38.
Comments or questions about this documentation? Contact us for support!