A decision table contains a set of rules describing decision situations where the state of a number of conditions determines the execution of a set of actions. It is the basic table type used in OpenL Tablets decision making.
The following topics are included in this section:
The following is an example of a decision table:
Figure 6: Decision table
The following table describes its structure:
Decision table structure |
|||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Row number |
Mandatory |
Description |
|||||||||||||||
1 |
Yes |
Table header, which has the following pattern:
where For example, the table in the preceding diagram can be invoked as follows:
where Normally, this row is hidden to business users. |
|||||||||||||||
2 and 3 |
No |
Rows containing table properties. Each application using OpenL Tablets rules can utilize properties for different purposes. For example, a predefined table property 'name' is used to specify business user oriented name of the table displayed in OpenL Web Studio. Although the provided decision table example contains two property rows, there can be any number of property rows in a table. Normally, property rows are hidden to business users. |
|||||||||||||||
4 |
Yes |
Row consisting of the following cell types:
All other cells in this row are ignored and can be used as comments. If a table contains action columns, the engine executes actions for all rules whose conditions are true. If a table has a return column, the engine stops processing rules after the first executed rule. If a return column has a blank cell and the rule is executed, the engine does not stop but continues checking rules in the table. Normally, this row is hidden to business users. |
|||||||||||||||
5 |
Yes |
Row containing cells with code statements for condition, action, and return value column headers. OpenL Tablets supports Java grammar enhanced with OpenL Business Expression (BEX) grammar features. For information on the BEX language, see Appendix A: BEX Language Overview. Code in these cells can use any Java objects and methods visible to the OpenL Tablets engine. For information on enabling the OpenL Tablets engine to use custom Java packages, see Configuration Table. Purpose of each cell in this row depends on the cell above it as follows:
Normally, this row is hidden to business users. |
|||||||||||||||
6 |
Yes |
Row containing parameter definition cells. Each cell in this row specifies the type and name of parameters in cells below it. Parameter name must be one word corresponding to Java identification rules. Parameter type must be one of the following:
Normally, this row is hidden to business users. |
|||||||||||||||
7 |
Yes |
Descriptive column titles. The rule engine does not use them in calculations but they are intended for business users working with the table. Cells in this row can contain any arbitrary text and be of any layout that does not correspond to other table parts. The height of the row is determined by the first cell in the row. |
|||||||||||||||
8 and below |
Yes |
Concrete parameter values. |
Lookup table is a special modification of Decision table which simultaneously contains vertical and horizontal conditions and returns value on crossroads of matching condition values.
That means condition values could appear either on the left of the lookup table or on the top of it. The values on the left are called "vertical" and values on the top are called "horizontal".
The Horizontal Conditions are marked as HC1, HC2, etc. Every lookup matrix should starts from HC or RET column. The first HC or RET column should go after all vertical conditions (C, Rule, comment, etc columns). RET section can be placed in any place of lookup headers row .HC columns do not have Titles section.
Lookup table must have:
at least one vertical condition (C)
at least one horizontal condition (HC)
exactly one return column (RET)
Lookup table can have:
Rule column
Lookup table cannot have comment column!
Advanced usage:
Lookup table (in theory) might have vertical Actions which will be processed the same way as vertical conditions.
Figure 7: A lookup table example
Colors identify how values are related to conditions. The same table represented as a simple decision table follows:
Figure 8: Lookup table representation as a simple decision table
(Just for your information. This passage can be interesting to understand internal OpenL Tablets logic.)
At first the table goes through parsing and validation. On parsing all parts of the table such as header, columns headers, vertical conditions, horizontal conditions, return column and their values are extracted. On validation OpenL checks if the table structure is proper.
To work with this kind of table TransformedGridTable
object is created as constructor parameters it has an original grid
table of lookup table (without header) and the
CoordinatesTransformer
that converts table coordinates to work with both vertical and
horizontal
conditions.
As theresult we get a GridTable
and works with it as a simple decision table structure, all coordinates
transformations with lookup structure goes inside. Work with
columns/rows is based on physical (not logical) structure of the
table.
Practice shows that most of decision tables have simple structure: there are conditions for each input parameter of decision table (that check equality of input and condition values) and return column. Because of this fact, OpenL Tablets have simplified decision table representation. Simple decision table allows skipping condition and return columns declarations and table will consist of header, properties (optional), column titles and condition/return values. The only restriction for simple decision table is that condition values must be of the same type as input parameters and return values must have type of return type from decision table header.
Usual decision table which has simple conditions for each parameter and simple return can be easyly represented as SimpleRules table.
SimpleRules <Return type> methodName(<Parameter type 1> parameterName1, (<Parameter type 1> parameterName1, .)
Figure 9: SimpleRules table example
Usual lookup decision table with simple conditions that check equality of input parameter and condition value and simple return can be easy represented as SimpleLookup table. This table is similar to SimpleRules table but has horizontal conditions. Number of parameters that will be associated with horizontal conditions is determined by height of the first column title cell.
SimpleLookup <Return type> methodName(<Parameter type 1> parameterName1, (<Parameter type 1> parameterName1, .)
Figure 10: SimpleLookup table example
Rules inside decision tables are processed one by one in the order they are placed in the table. A rule is executed only when all its conditions are true. If at least one condition returns false, all other conditions in the same row are ignored. Absence of a parameter in a condition cell is interpreted as a true value. Blank action and return value cells are ignored.
When declaring Decision table users have to put next info in header: column type, code snippet, declarations of parameters, titles.
Recent experience shows that in 95% of cases users put very simple logic in code snippet such as just access to some field from input parameters. In this case the parameters declarations for the column are overhead and are useless.
The following image represents situation when user should provide expression and simple equal operation for condition declaration.
Figure 11: Decision Table where user should provide expression and simple equal operation for condition declaration
This is code snippet can be simplified as shown on the next image.
Figure 12: Simplified Decision Table
(Just for your information. This passage can be interesting to understand internal OpenL Tablets logic.)
OpenL engine creates required parameter automatically when user omits parameter declaration with the following information:
parameter name will be "P1", where 1 is index of parameter
type of parameter will be the same as expression type (in our case it will be boolean)
In the next step OpenL will create appropriate condition evaluator.
The following image represents situation when user can omit parameter name in declaration.
Figure 13: Decision Table where user can omit name in declaration
As mentioned in previous case OpenL engine generates parameter name and user can use it in expression but in this case user must provide local parameter type because expression type has different type than parameter.
Sometimes decision tables look more convenient in transposed format where columns become rows and rows become columns. For example, a transposed version of the previously shown decision table resembles the following:
Figure 14: Transposed decision table
OpenL Tablets automatically detects transposed tables and is able to process them correctly.
Arrays can be defined as follows for all tables that have properties of
the
enum[]
type and for data tables with fields of the array type:
horizontally
vertically
comma separated arrays
The first option is to arrange array values horizontally using multiple subcolumns. The following is an example of this approach:
Figure 15: Arranging array values horizontally
In this example, the contents of the set
variable for the first rule are [1,3,5,7,9]
and for the second rule [2,4,6,8]
. Values are read from left to right.
The second option is to present parameter values vertically as follows:
Figure 16: Arranging array values vertically
In the second case, the boundaries between rules are determined by the height of the leftmost cell. Therefore, an additional column must be added to the table to specify boundaries between arrays.
In both cases, empty cells are not added to the array.
The third option is to define an array separating values by a comma. If
the value itself contains a comma, it must be escaped using back slash
symbol
\
putting it before the comma.
Figure 17: Array values separated by comma
In this example, the array consists of the following values:
test 1
test 3, 4
test 2
Figure 17: Array values separated by comma. The second example
In this example, the array consists of the following values:
value1
value2
value3
To facilitate work with arrays, OpenL Tablets provides two methods, one of them determines whether a particular element is included in an array:
contains(Object[] ary, Object ojb)
The other one checks if one array contains all elements from the other:
contains(Object[] ary1, Object[] ary2)
These methods work with Java objects, also there are methods with same
functionality for all primitive types. The following example displays a
table using the
contains
method:
Figure 18: Checking arrays in conditions
In this example, the contents of the set variable for the first rule are [1,3,5,7,9] and for the second rule [2,4,6,8]. Values are read from left to right.
To represent date values in table cells, the following format must be used:
'<month>/<date>/<year>
The value must always be preceded with an apostrophe. Excel treats these values as plain text and does not convert to any specific date format.
The following are valid date value examples:
'5/7/1981
'10/20/2002
OpenL Tablets also recognizes the native Excel date format.
OpenL Tablets supports the following formats of Boolean values:
True, TRUE, Yes, YES
False, FALSE, No, NO
OpenL Tablets also recognizes the Excel Boolean value, such as native Excel Boolean
value TRUE or FALSE. For more information on Excel Boolean values, see
Excel
help.
OpenL Tablets can perform mathematical calculations involving method input parameters
in table cells. For example, instead of returning a concrete number, a
rule can return a result of a calculation involving one of the input
parameters. Calculation result type must match the type of the cell.
Text in cells containing calculations must start with an apostrophe
followed by =. Excel treats such values as plain text. Alternatively,
OpenL Tablets code can be enclosed by {
}
.
The following decision table demonstrates calculations in table cells:
Figure 19: Decision table with calculations
The table transforms a 12 hour time format into a 24 hour time format.
The column
RET1
contains two cells that perform calculations with the input parameter ampmHr
.
Calculations use regular Java syntax, similar to what is used in conditions and actions.
Note: Excel formulas are not supported by OpenL Tablets. They are used as precalculated values.