Rules Overview
Contents
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
- Sales Department
and during execution, you specify “Sales Department” / “Finance”, then the order of execution is:
- Rules at Package level (according to priority).
- Rules at Sales Department (according to priority).
- 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.
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.