Chapter 10. Real-time verification and validation of guided decision tables
Business Central provides a real-time verification and validation feature for guided decision tables to ensure that your tables are complete and error free. Guided decision tables are validated after each cell change. If a problem in logic is detected, an error notification appears and describes the problem.
10.1. Types of problems in guided decision tables
The validation and verification feature detects the following types of problems:
- Redundancy occurs when two rows in a decision table execute the same consequences for the same set of facts. For example, two rows checking a client’s birthday and providing a birthday discount may result in double discount.
Subsumption is similar to redundancy and occurs when two rules execute the same consequences, but one executes on a subset of facts of the other. For example, consider these two rules:
- when Person age > 10 then Increase Counter
- when Person age > 20 then Increase Counter
In this case, if a person is 15 years old, only one rule fires and if a person is 20 years old, both rules fire. Such cases cause similar trouble during runtime as redundancy.
A conflicting situation occurs when two similar conditions have different consequences. Conflicts can occur between two rows (rules) or two cells in a decision table.
The following example illustrates conflict between two rows in a decision table:
- when Deposit > 20000 then Approve Loan
- when Deposit > 20000 then Refuse Loan
In this case, there is no way to know if the loan will be approved or not.
The following example illustrates conflict between two cells in a decision table:
- when Age > 25
- when Age < 25
A row with conflicting cells never executes.
- Broken Unique Hit Policy
When the Unique Hit policy is applied to a decision table, only one row at a time can be executed and each row must be unique, with no overlap of conditions being met. If more than one row is executed, then the verification report identifies the broken hit policy. For example, consider the following conditions in a table that determines eligibility for a price discount:
- when Is Student = true
- when Is Military = true
If a customer is both a student and in the military, both conditions apply and break the Unique Hit policy. Rows in this type of table must therefore be created in a way that does not allow multiple rules to fire at one time. For details about hit policies, see Chapter 5, Hit policies for guided decision tables.
Deficiency is similar to a conflict and occurs the logic of a rule in a decision table is incomplete. For example, consider the following two deficient rules:
- when Age > 20 then Approve Loan
- when Deposit < 20000 then Refuse Loan
These two rules may lead to confusion for a person who is over 20 years old and has deposited less than 20000. You can add more constraints to avoid the conflict.
- Missing Columns
- When deleted columns result in incomplete or incorrect logic, rules cannot fire properly. This is detected so that you can address the missing columns, or adjust the logic to not rely on intentionally deleted conditions or actions.
- Incomplete Ranges
- Ranges of field values are incomplete if a table contains constraints against possible field values but does not define all possible values. The verification report identifies any incomplete ranges provided. For example, if your table has a check for if an application is approved, the verification report reminds you to make sure you also handle situations where the application was not approved.
10.2. Types of notifications
The verification and validation feature uses three types of notifications:
- Error: A serious problem that may lead to the guided decision table failing to work as designed at run time. Conflicts, for example, are reported as errors.
- Warning: Likely a serious problem that may not prevent the guided decision table from working but requires attention. Subsumptions, for example, are reported as warnings.
- Information: A moderate or minor problem that may not prevent the guided decision table from working but requires attention. Missing columns, for example, are reported as information.
Business Central verification and validation does not prevent you from saving an incorrect change. The feature only reports issues while editing and you can still continue to overlook those and save your changes.
10.3. Disabling verification and validation of guided decision tables
The decision table verification and validation feature of Business Central is enabled by default. You can disable it by setting the
org.kie.verification.disable-dtable-realtime-verification system property value to
true in your Red Hat JBoss EAP directory.
$EAP_HOME/standalone/configuration/standalone-full.xml and add the following system property:
<property name="org.kie.verification.disable-dtable-realtime-verification" value="true"/>