Show TOC

Background documentationDecision Table Expression

 

A decision table expression is used to compare a given input against a list of predefined combinations of conditions. Each combination has an individual result assigned which is returned as the expression result when the input data matches the particular combination.

Structure

The decision table is built up as a table with the following elements and settings:

  • One or more columns representing the different conditions against which the input data is compared

  • One or more columns used to hold the result that is returned by the expression if all the conditions in a row are satisfied

  • One or more rows that are unique in terms of their combined conditions

Features

General Concept

A decision table expression sequentially processes business rules based on a set of inputs. At runtime, the input data that is supplied to the decision table is compared against the defined conditions, starting with the first row. All cells are evaluated by checking the column value against a number of range comparisons. For each cell, a boolean result is returned. If all cells in a row are evaluated as true, the evaluation stops and the expression returns the result associated with the current conditions. Otherwise, processing continues with the next table row until either a matching set of conditions is found or the end of the table is reached.

Note Note

Due to the sequential processing of the rules defined in the table from top to bottom, we recommend that you define the rules starting with the most specific condition in the first row, followed by rules with a decreasingly specific set of conditions assigned. Otherwise, situations could occur where a given input that satisfies an unspecific condition would lead to the expression result defined for that condition, without giving the system a chance to test whether there is a more specific condition that would match the input data even better.

The check functions of BRFplus can detect many of this kind of sequential arrangement errors and make you aware of the problem. Also, with the Rearrange function you can let the system correct at least the most obvious misarrangements automatically (cells with unspecified values are moved to the bottom of the table).

End of the note.

Example Example

A decision table consists of two condition columns, Region and Country, and a result column Payment Target. For region Europe alone, the payment target is defined as 60 days, while for region Europe and country Germany the payment target is 30 days. The input data is Region = Europe and Country = Germany. If the condition for region only is evaluated before the combination of region and country, then the unspecific region check would already yield a result, and the more specific condition for country and region would never be tested. That is, the payment target for the input with Country = Germany would be erroneously evaluated as 60 days although it should be 30 days.

End of the example.

The decision table data consists of a set of nested expressions for each table cell. With the cells in condition columns, the expressions are typically value ranges or constants, and they use the corresponding column data object as a test parameter. Normally, a condition column is defined by assigning a data object to it. However, condition columns can also be derived from nested expressions. Each cell in a row can be either a single value, an enumeration of distinct values, or a range of values against which the inputs are checked.

Result Columns and Result Data Object

The data structure of the result column is derived from the result data object. A decision table can also have multiple result columns. This can be achieved either by assigning a structure data object as the result data object, or simply by providing several elementary data objects as result columns. In the latter case, the system offers to create a new structure data object containing the selected elements. This structure is then automatically assigned as the decision table's result data object.

For special purposes, it is also possible to define the result column as Action Column. In this case, you define an action for each combination of conditions that shall be triggered if the input data matches the condition defined in a table row.

Note Note

You can use a combination of an action and a data object value in the result column of a decision table. However, there can be no more than one action assigned to the result column.

End of the note.
Modifying Technical Settings

The following sections deal with the various technical settings that you can fine-tune to adapt a decision table's behavior to your use case. These settings include the definition of condition and result columns, as well as many other details that are not needed in everyday's use. To avoid confusion, these settings are therefore hidden by default when you maintain a decision table. You can access the technical settings as follows:

  • When you create a new decision table, the system presents you the technical settings screen so that you can define the necessary features like condition and result columns.

  • When you maintain an already existing decision table, you can access the technical settings by clicking Table Settings (Table Settings) at the rightmost border of the Detail section toolbar.

Note Note

Access to the technical settings of a decision table is subject to the personalization settings in effect. For more information, see Workbench Personalization, section Expression — Decision Table.

In addition, changing the technical settings is disabled as long as a filter restricting the decision table's content is active. This is to prevent unexpected and ambiguous system behavior: For example, if a filter is active so that only rows 5 and 12 are visible out of a total of 25, inserting a new row between rows 5 and 12 would leave the question open where exactly to insert the new row. Therefore, the system consequently disables features that could cause confusion in filter mode.

End of the note.
Single vs. Multiple Match Mode

A decision table can be run in two different modes of operation, depending on the setting of the Return all matches found indicator:

  • Single match mode (Return all matches found = false)

    In single match mode, the input data is tested against the conditions defined in a table row. If the input satisfies all the conditions, the associated result is returned and processing of the decision table stops. In other words, the system returns the result associated with the first matching row. This is the default mode.

  • Multiple match mode (Return all matches found = true)

    In multiple match mode, the input data is tested against the conditions defined in all of the table rows. All matching results are collected in the result data object and returned as the result of the evaluation.

    Note Note

    Since multiple match mode is designed for delivering more than one value as the expression's result, the result data object for a decision table in multiple match mode must always be a data object of type table.

    End of the note.
Handling of Partial Matches

Both single match mode as well as multiple match mode follow the basic principle that only if the input data passed to a decision table matches all of the specific condition values in a row this is considered a match. However, use cases may exist where the input does not match any of the decision table rows, but simply raising an exception is not sufficient. This is where partial match handling comes into play. This processing mode is used to address the following scenario:

  • Context data passed to the decision table does not match any of the condition rows defined in the table.

  • You want to continue processing not only based on the fact that there is no match, but on the information about how near the context data came to a matching result (but still failed to match a condition completely).

For this purpose, you can set the Return exception for partial match flag. Setting this flag has the following effect: While processing the decision table, the system keeps track of the maximum number of matched conditions per row. If the last row in the table has been processed and there is still no matching row, the system raises exception CX_FDT_PARTIAL_MATCH with the highest observed match count passed to attribute CX_FDT_PARTIAL_MATCH->MV_MAX_COND_MATCHED. It is then up to the calling application to handle this exception and implement the desired system behavior based on the maximum number of matched conditions for the given input.

Note Note

Setting the Return exception for partial match flag has a negative impact on system performance. This is due not only to the necessary counter comparison for each row but also to the fact that certain optimization measures cannot be applied during code generation. We therefore recommend to set this flag only if you definitely need to access the maximum number of matched conditions for your use case.

End of the note.
Initial Value

If no matching condition is found for a given input, the decision table raises an exception instead of returning a result. You can override this default behavior by setting the Return initial value if no match is found indicator. If this indicator is set, the decision table returns the initial value that is defined for the type of the result data object. With this setting, it is possible for you to consider the unsuccessful processing as a defined result rather than an error and continue with processing.

Note Note

If you use this option, it may be necessary to take additional measures in order to make sure that further processing steps do not confuse an initial value with a well-defined result. For example, the initial value for a result data object of type number is 0, which could of course be the intended result for a satisfied condition as well.

End of the note.
Table Content Checks

In addition to the standard checks for technical consistency, you can carry out additional checks to ensure that the decision table data is error-free and yields the expected results from a business perspective. For more Information, see Decision Table Content Checks.

Table Optimization

BRFplus offers some tools that help you condense the table content and optimize the table arrangement for better performance. For more information, see Decision Table Optimization.

Optional vs. Mandatory Entry of Condition Data

The default behavior for evaluating a decision table is as follows:

  • The value of an input data field is compared to the value in the corresponding condition column of the table.

  • If the two values match, the condition cell is evaluated as true.

  • This process is repeated for each condition in the table row until either all the conditions are satisfied (row is a match) or until a condition is not satisfied (processing continues with the next table row).

If this default behavior does not fulfill your needs, you can modify it for each condition column individually in the following way:

  • Mandatory input

    With this indicator set, the system forces you to provide a condition value at design time for the respective column in each row that you enter in the table definition. Such a condition can therefore not be used for providing an unspecific empty condition that would be evaluated as true regardless of the input data.

    Example Example

    In the example outlined above with the two condition columns Region and Country, the Region column would be defined as a mandatory entry to make sure that an input must at least match one of the regions provided by the decision table to be further evaluated. As opposed to this, the Country column is not mandatory so that an input with a matching region but an unknown country can still be processed. To accomplish this, you need to provide an additional table row for each region combined with an undefined country.

    End of the example.
Retrieving Table Content

Depending on the use case, decision tables can contain a high number of cells (many thousands of rows, dozens or hundreds of columns). This can make it sometimes difficult to retrieve a particular cell you are interested in. For this purpose, BRFplus offers the following tools that help you navigate through the content of a decision table:

Row Filter

You can define filter criteria that a table row must match to be displayed. For each column, you can define a separate filter that applies to that particular column only. If filters are defined for more than one column, the filter criteria are combined with a logical AND operator before they are evaluated. That is, a row is only displayed if all filter criteria that are currently in effect are satisfied by the affected columns of a row at the same time.

Filter conditions remain in effect either until you explicitly change or reset the conditions, or until you navigate to a different object. It is not possible to permanently associate certain filter conditions to a decision table.

To define a filter for a column, move the mouse cursor over the header cell of the desired column and click on the small triangle in the lower right corner. If a filter is already defined for a column, the system displays a filter symbol on the column header cell.

Find

With this tool, you can search the table content for a string. If the search string exists in the table, the row containing the searched string is highlighted. With the Next and Previous buttons, you can navigate to further occurrences of the search string.

Note Note

For both tools, the following applies: The comparison between the filter condition, or search string, and the actual cell content is done via an implicit content conversion into text form. This means that everything that is displayed in a cell must be taken into account when you define the filter condition. For example, if a cell contains a value range that is displayed as [10..20] and you want to include this cell in a filter, you have to mention the square brackets explicitly in the filter criterion, like [10*. Using 10* as a filter criterion (without the bracket) instead would exclude the cell although the square brackets are not really part of the cell content and only displayed for the sake of giving a visual hint on the fact that the cell contains a value range.

Both tools support wildcards ('+' matches any single character, '*' matches any string). All searches and string comparisons are case-insensitive.

If a search is performed while a filter condition is in effect, the search is restricted to those rows that are included in the folder and therefore visible.

End of the note.
Table Data Export And Import

You can exchange the condition and result data of a decision table with Microsoft Excel. This enables you to share your table data with people who may not have access to BRFplus but might give input from a business perspective. The necessary steps for exporting and importing data are described in Exchanging Decision Table Data With Microsoft Excel.

Column Protection

One of the big advantages of BRFplus is that it makes the criteria for the business decisions in your company transparent and easy to change. While such transparency can be counted as an asset in itself, it can still be inappropriate for certain parts of your business. Here, you may want to decide that the decision criteria for a particular business case shall be protected against unauthorized change or even be completely invisible. You can accomplish this with the help of the Column Accessibility setting, both for condition columns and result columns of a decision table:

  • Full Access (Changes Allowed)

    With this setting, a user can deliberately change the values of the column cells. This is the default.

  • Display Only (No Changes)

    With this setting, a user can see the values in the column cells without being able to make any changes.

  • Hidden

    With this setting, the column is hidden completely in the BRFplus workbench at design time as well as at runtime. Without checking the table settings, a user does not receive any visual indication that the column exists.

Example

The following table illustrates the decision table example given above to determine the payment target for a customer invoice:

Region *

Country

Company

Payment Target (Days)

Americas

USA

Miller Inc.

90

Americas

USA

75

Europe

Germany

30

Europe

France

45

Europe

60

In this table, you see a list of different payment targets being defined to match the different business habits in different places in the world. The Region, Country, and Company columns represent the condition criteria (context data) while the Payment Target (Days) column holds the resulting value to be returned for each of the conditions (result data object). The table reflects the common experience that in Germany customers usually pay their invoices in relatively short time upon invoice receipt, while in other regions or countries this time can be longer. It may also be useful to define special payment targets for individual customers, depending on their assumed financial strength or on your company's experiences with these customers in the past.

Note that the entries in the table are sorted by the amount of specific information available, starting with the most specific entry for an individual company in the USA and ending with a generic entry for all customers based in Europe who do not satisfy the conditions in the more specific rows.

Note Note

Do not confuse this sort order with the alphanumeric sort function known from most table controls. Rather, sorting the entries of a decision table means that you have to manually arrange the entries such that they best match the business case you want to cover. So this is a semantic sort order based on business decisions, not an alphanumeric sorting based on names.

End of the note.

The asterisk (“*”) in the Region * column header indicates that an entry in this column is always required – in other words, at least the customer's region information is needed for the decision table to determine a payment target for a customer.

The decision table entries for the Americas region define only payment targets for customers based in the USA. If, for example, you would supply a customer from Canada or Brazil as input data at runtime, the decision table would raise an exception because neither a specific condition for these countries nor a generic condition for all countries in the Americas region (except USA) has been defined.

More Information

Creating a Decision Table Expression

Decision Table Content Checks

Decision Table Optimization

Exchanging Decision Table Data With Microsoft Excel