Decision Table

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:

Decision Table Structure

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

Yes

Table header, which has the following pattern:

<keyword> <method header>

where <keyword> is either 'Rules' or 'DT' and <method header> is a signature of a method used to access the decision table and provide input parameters.

For example, the table in the preceding diagram can be invoked as follows:

HelloWrapper tableWrapper = new HelloWrapper();

tableWrapper.hello1(15);

where HelloWrapper is the wrapper class of the Excel or Word file. For general information on wrappers, see Wrappers.

Normally, this row is hidden to business users.

2 and 3

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.

Yes

Row consisting of the following cell types:

Type	Description	Examples
Condition column header	Identifies that the column contains rule condition and its parameters. It must start with character 'C' followed by a number.	`C1, C5, C8`
Horizontal condition column header	Identifies that the column contains horizontal rule condition and its parameters. It must start with character 'HC' followed by a number. Horizontal conditions are used in lookup tables only.	`HC1, HC5, HC8`
Action column header	Identifies that the column contains rule actions. It must start with character 'A' followed by a number.	`A1, A2, A5`
Return value column header	Identifies that the column contains values to be returned to the calling program. A table can have multiple return columns, however, only the first fired not blank value is returned.	`RET1`

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.

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:

Cell above	Purpose
Condition column header	Specifies the logical expression of the condition. It can reference parameters in the method header and parameters in cells below. The cell can contain several expressions, but the last expression must return a Boolean value. All condition expressions must be true to execute a rule.
Horizontal condition	The same to Condition column header.
Action column header	Specifies code to be executed if all conditions of the rule are true. The code can reference parameters in the method header and parameters in cells below.
Return value column header	Specifies expression used for calculating the return value. The type of the last expression must match the return value specified in the method header. The explicit return statement is also supported. This cell can reference parameters in the method header and parameters in cells below.

Normally, this row is hidden to business users.

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:

primitive Java types

Java classes visible to the engine

one-dimensional arrays of the above types as described in Working with Arrays

data tables or their attributes as described in Using Advanced Data Tables

Normally, this row is hidden to business users.

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 Tables

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

Implementation Details

(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.

Simple Decision Tables

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.

SimleRules Table

Usual decision table which has simple conditions for each parameter and simple return can be easyly represented as SimpleRules table.

Header format:

SimpleRules <Return type> methodName(<Parameter type 1> parameterName1, (<Parameter type 1> parameterName1,….)

SimpleRules Table Example

Figure 9: SimpleRules table example

SimleLookup Table

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.

Header format:

SimpleLookup <Return type> methodName(<Parameter type 1> parameterName1, (<Parameter type 1> parameterName1,….)

SimpleLookup Table Example

Figure 10: SimpleLookup table example

Decision Table Interpretation

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.

Local Parameters in Decision Table

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.

Simplified declarations

Case#1

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

How it works?

(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.

Case#2

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.

Transposed Decision Tables

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.

Working with Arrays

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

OpenL methods helpers to work with arrays

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.

Representing Date Values

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.

Representing Boolean Values

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.

Ranges types in Openl

In Openl there are 2 types to work with ranges :

IntRange.

DoubleRange.

There are 3 ways to create IntRange:

1.new IntRange(int min_number, int max_number) – it will cover all the numbers between min_number and max_number, including borders.

2.new IntRange(Integer value) – it will cover only given value as the beginning and the end of the range.

3.new IntRange(String rangeExpression).Borders will be parsed by formats of rangeExpression.

The same formats and restrictions are used in DoubleRange.

Supported range formats:

1.“<min_number> - <max_number>” - borders will be included to range.

2.“<min_number> .. <max_number>” – the same as 1.

3.“<min_number> … <max_number>” - borders will not be included to range. Important: using of ".." and "..." requires spaces between numbers and dots.

4.“<<max_number>” – the min_number will be Integer.MIN_VALUE and will be included to range. max_number will be out of the range.

5.“<=<max_number>”- the min_number will be the same as in previous case, max_number will be also included to range.

6.“><min_number>” - max_number in current case will be the Integer.MAX_VALUE and will be included to range. min_number will be out of range.

7.“>=<min_number>” – max_number will be the same as in previous case. min_number will be included to range.

8.“<min_number>+” – The same to “>= <min_number>”

9.“[<min_number>; <max_number>” - mathematic definition for ranges with using of square brackets for including borders and round brackets for not including.

10.“[<min_number> .. <max_number>)” – brackets are used to include or not borders. See 9.

11.“<min_number> and more” – the same to 7.

12.“more than <min_number>” – the same to 6.

13.“less than <max_number>” -the same to 4.

Also numbers can be enhanced with $ sign as prefix and K, M, B as postfix, e.g. $1K = 1000. For using negative values use ‘-’ (minus) sign before number (e.g. -<number>).

Using ranges types in Decision Tables

For example, we have the next Decision table. The column of type IntRange contains code statement of type short. So the cell may contain value of different types. When using IntRange, for user convenience it is possible to have code statement cell of following types:

byte

short

int

Figure 19: Decision table with IntRange

Be careful with using Integer.MAX_VALUE in Decision table. If there is a range with max_number

equal to Integer.MAX_VALUE (e.g. [100; 2147483647]) it won`t be included to range. It is a known issue.

When using DoubleRange, for user convenience it is possible to have code statement cell of following types:

byte

short

int

long

float

double

Using Calculations in Table Cells

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.