Decision Table Content Checks

In addition to the checks for technical correctness that are available for all BRFplus object types, you can perform some content-oriented checks for a decision table. These checks are used to ensure that the decision table definition is error-free and yields the expected results from a business perspective. Unlike the more technical checks, you can explicitly perform these checks with the respective commands assembled under the Additional Actions menu. These checks are:

Completeness Check
With the completeness check, or gap check, the system verifies that the values of a particular condition column are defined as a continuous sequence of values with no gaps in between. With gaps in the sequence of values, it could happen that an input value could not be processed although, from a business point of view, all possible values within a given range must be processed by the decision table.

Once the check has finished and value gaps have been determined, the system tries to make a suggestion for additional table rows that would close the gaps. This is an easy way for you to make sure that the table returns a defined result for the value combinations that are not yet covered. However, in certain situations, these row suggestions lead to a state of formal completeness only that may still need further manual refinement to meet your business requirements.

Example
A decision table has, among others, a Travel Class condition column with a data object assigned that is bound to a list of three domain values, namely Economy Class, Business Class, First Class. During the completeness check, the system detects that for a particular combination of conditions, only Business Class and First Class are taken into consideration, but there is no table row for Economy Class. The check would then notify you of this potential gap so that you can decide whether the missing value has been omitted intentionally or not.

End of the example.
Overlap Check
With the overlap check, the system detects whether the value ranges assigned to the condition columns are distinct and free of overlappings. With overlapping ranges, the system would not be able to handle correctly an input value that falls into the overlapping zone.

Example
A decision table has an Invoice Total condition column with value ranges defined as 500...1000 in one row and 750...1500 in another row. With an invoice total of 900 as input, it would be impossible for the decision table to determine which of the two rows is the correct one. The system would simply choose the first matching row, regardless of whether this is, from a business point of view, the intended decision or not.

End of the example.

The checks described above are always carried out by the system when you explicitly force the system to do the check, or as an implicit check when you activate the decision table. However, since these checks are focused on correctness in terms of business adequacy, not on technical consistency, you can decide how the system shall behave if one of the checks detects a problem. In the Table Settings dialog, you can choose from the following options:

System Default
In case of a problem, the system sends the corresponding message with the message type as defined in the backend system (in most cases, message type 'warning' is used).
Show Messages as Error
This forces you to solve the problem in the table definition. Otherwise, the decision table cannot be activated.
Show Messages as Warning
The system makes you aware of the problem but still lets you activate the decision table.
Do not show any messages
Although the problem was detected, the system does not make you aware of it. Activation of the decision table is possible.

Note Note

The table content checks are performance-critical because they partially imply operations where each cell in the table must be compared with all other cells. To avoid overloading the system, the checks can only be executed as long as certain fixed limitations are not exceeded. For example, the completeness check can only be performed with tables that have no more than 10000 rows.

End of the note.