Decision Table Introduction

Decision tables provide a way to build complex business rules, by defining threshold value conditions and actions in the cells of the table.

Each row can be thought of as single rule in a table made up of many rules. The individual rules are often straightforward, as shown in the examples below. When built into an EventFlow application, the Decision Table operator allows you to to run your decision table against incoming tuples.

A decision table is made up of columns where where each column represents one condition or one action.

A condition is a predicate test that must evaluate to true for the associated action to be executed. If a decision table rule uses multiple conditions, all conditions for a row must evaluate to true for the action to execute. Condition tests might be looking to match the exact value of an incoming field's value, or might be comparing an incoming value for whether it is greater than, less than, greater than or equal to, or less than or equal to a specified value.

In each rule's row, you define the specific conditions and actions that comprise that rule. For example, if a condition column is Age (comparing to an incoming tuple field of that name), then each row can define a different age range. The action for each row would define what action to take if an incoming tuple contains an Age value within the specified range.

If you add a second condition column called Name, then before the action is taken, the Decision Table operator tests both conditions to see if both the incoming Age and Name field values are within the ranges specified in the rules.

StreamBase decision tables support:

The Decision Table operator supports two types of expression syntax for condition and action columns: StreamBase expression or TIBCO BusinessEvents expression syntax. When editing decision tables with the Decision Table Editor, and you click the Add Column button, you can specify whether to add a Condition or Action column (which use BusinessEvents syntax) or a StreamBase Condition or StreamBase Action column (which use StreamBase syntax).

StreamBase expressions are visually distinguished from BusinessEvents expressions by hover text, and by italics in the condition and action columns:

StreamBase Condition Column Features:

BusinessEvents Condition Column Features:

StreamBase Action Column Features:

BusinessEvents Action Column Features:

The syntax for decision table cell content depends upon the type of column the cell is in, as explained below.

StreamBase Condition Columns:

Cells within StreamBase condition columns can contain arbitrary StreamBase expressions ― with a few limitations ― that evaluate to boolean values. Expressions can reference one or more fields in the decision table operator's input schema. The limitations include:

<stream input="true" name="default.Input" schema="InputSchema">
    <schema name="InputSchema">
        <field description="" name="Name" type="string"/>
        <field description="" name="Age" type="int"/>
        <field description="" name="MyListOfDouble" type="list">
            <element-type type="double"/>
        </field>
        <field description="" name="MyTuple" type="tuple">
            <schema>
                <field description="" name="MyBool" type="bool"/>
                <field description="" name="MyInt" type="int"/>
                <field description="" name="MyString" type="string"/>
                <field description="" name="MyListOfString" type="list">
                    <element-type type="string"/>
                </field>
                <field description="" name="MyTimestamp" type="timestamp"/>
            </schema>
        </field>
    </schema>
</stream>

Note that since the last example rule above shares several conditions with rules that precede it, the rule will fire only if Single Row Execution is disabled.

BusinessEvents Condition Columns:

Cells within BusinessEvents condition columns conform ― with a few limitations ― to the shorthand syntax supported by BusinessEvents in which the left-hand side of the expression is implied from the column name and is there omitted in cell value. Cells can contain a combination of literal values, logical and relational operators, spaces, single and double quotes, and parentheses. The limitations include:

Literal types include:

The valid logical operators include:

The valid relational operators include:

The following table provides alternatives to the examples above using one or more BusinessEvents condition columns:

StreamBase Action Columns:

Cells within StreamBase action columns can contain arbitrary StreamBase expressions that evaluate to the data type of the corresponding field in decision table's action schema. Expressions can reference one or more fields in the decision table operator's input schema. StreamBase action column expressions have the same limitations as StreamBase condition column expressions.

BusinessEvents Action Columns:

Cells within BusinessEvents action columns contain literals whose types match those of the corresponding field in the decision table operator's action schema. See the BusinessEvents Condition Columns section above for a list of the supported literal types. BusinessEvents action column values have the same limitations as BusinessEvents condition column values.

The Decision Table File property of the Decision Table operator can load three decision table file types into the operator, with four different origins, as shown in the following table:

When using EventFlow debugging, stepping into or over a Decision Table operator is not supported. However, you can still set breakpoints anywhere downstream of such operators. If you are stopped at a breakpoint on an arc feeding a Decision Table operator, you must resume to get across the operator.

For debugging a Decision Table operator, consider using the features of the Decision Table Analyzer's Show Coverage feature to get a debug-like view of how the operator responds to different input tuples.

Back to Top ^