Decision Tables—Examples

Important

Decision Tables can have a maximum of 30 columns.

Example 1—Pre–8.5.0

Decision tables allow you to create a number of rules that have the same set of conditions (WHEN) and actions (THEN) that are to be used for a complex (structured) business case. Use decision tables to avoid dozens of linear rules that have an identical structure in the system.

Choices in decision tables must be mutually exclusive to avoid ambiguity. This ensures that there is only one outcome per evaluation. If the choices are not mutually exclusive, multiple rows may be executed in no guaranteed order. The last row that is executed will determine the final result.

Sample Decision

When you are editing rules, be careful not to clear your cookie data, as this might cause the rule to become stuck in a locked state until the session times out (the default is 30 minutes). Consult the documentation for the browser that you are using for more information about how to prevent a user from clearing cookie data.

Example 2—Post–8.5.0 Rule Evaluation Order

By default, up to release 8.5.0, rules were executed from the bottom up (a DROOLS constraint). In 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. A new configuration option (evaluate-decision-table-rows-top-down) allows the administrator to set the order of evaluation (top to bottom or bottom to top).

Decision Table with Rule Evaluation Order

Configuration Info

The evaluate-decision-table-rows-top-down configuration option controls this behavior. This determines the order that the Decision Table rows are written out to the DRL. If you changes this default option, you will see a change in behavior immediately when using GRAT's Test Scenario feature, but will need to re-deploy the rule package in order for the change to be observed in GRE.

• Section: settings
• Option Name: evaluate-decision-table-rows-top-down
• Values: true, false
• Default: false (to maintain backwards compatibility)

Example 3—Wildcards

In release 8.5.001.00, you can now use a wildcard symbol (*) in row data in a decision table (if the feature is configured by administrators). The wild card indicates that, for this row, the value for the parameter where it is used is unimportant and not to be evaluated. A wildcard selection now appears at the top of all lists, regardless of whether they are enumerations, business attributes, Configuration Server, database, and so on. In the case of numeric parameters, you must type in the wildcard value—GRAT now accepts that as a valid number field. For any condition that contains one or more wildcards, its evaluation will not be considered in the rule logic. There are some restrictions:

• The wildcard values will work only for strings and numeric fields—fields of type date, time and Boolean are not supported.
• Wildcard values are "all or nothing" for conditions with multiple parameters. For example:

Customer age is between 40 and 60

is ONE condition, and it will be excluded for that row if one or more of the fields contains a wildcard value.

Decision Table with Wildcards