The consistency analysis mechanism finds semantically conflicting
rules such as rules that are never selected, rules that never apply,
equivalent rules, redundant rules, conflicting rules, and conflicts
between decision tables or decision trees.
Consistency checking is a mechanism for checking whether rules
do not contain semantically conflicting elements.
Ambiguities can be found either in a single rule or in a set of
rules. For example:
Consistency checking goes beyond syntax aspects to consider semantics
as well. That is, how the rule behaves during execution. Using Rule
Designer ,
you can choose which checks are carried out.
Consistency checks belong to one of the following categories:
Checks that analyze an individual rule. These checks are activated
when you build the rule and when you run the Consistency checking
analysis:
Checks that analyze rules in relation to other rules. These
checks are activated only when you run the Consistency checking analysis.
Consistency checking reports problems on rules:
- If there is a ruleflow in your rule project, the consistency checking
mechanism reports problems on the rules that are included in a rule
task and that might be selected at run time.
The mechanism compares
only rules that could be in the same task. In the case of a rule task
with dynamic selection filtering, the mechanism takes into account
the rules that are potentially selected by this task. A rule is considered
potentially selectable when it cannot be established that it definitely
cannot be selected.
- If there is no ruleflow in your rule project, all the rules in
the project are likely to be selected.
For more information, see Runtime rule selection and Rule overriding.
Note: Consistency checking gives an indication of the consistency
of your rules but cannot identify all potential problems. An empty
consistency checking report is therefore not a guarantee that there
are no problems in the analyzed rules.
Rules that are never selected
Rules
are reported as "never selected" when they are not part of a
rule task and cannot be selected at run time. For more information,
see Runtime rule selection and Rule overriding.
Rules
that never apply
A rule is analyzed as never applicable
when its conditions can never be met.
Typically, the syntax
of such rules is correct but the rules contain common logic errors.
For example:
The wrong operator is used to combine condition statements,
for example and instead
of or: the category of the customer is Gold and
the category of the customer is Platinum.
Values are inverted, for example, in the following rule: the age of the customer is between 70 and
50.
Values in the conditions are not within the permitted range.
Rules
with range violation
In order to reduce the risk of errors,
some members can only be assigned values within a specified range.
For example, the yearly interest rate on a loan might be limited to
values between 0 and 10.
If a rule contains an action that tries
to assign a value that is not within the permitted range, Rule
Designer displays
a range violation error in the report and in the Rule Editor.
Rules
with equivalent conditions
The consistency checking mechanism
also reports rules in which the condition parts have the same meaning,
and where the action parts are different but not in conflict.
Rules
with equivalent conditions do not necessarily represent an error situation,
but they could be good candidates to be merged.
Equivalent
rules
Equivalent rules are reported when both their conditions
and actions are the same.
In the following example, Rule1 and Rule2 are
equivalent:
Rule1
definitions
set minDiscount to 5
set ageDiscount to 10
if
the age of the borrower is more than 65
then
set the discount to minDiscount + ageDiscount
Rule2
if
the age of the borrower is at least 66
then
set the discount to 15
Although the syntax of these two
rules is different, rule analysis evaluates the numeric expressions
and reports that the rules are equivalent. You can therefore delete
one of them.
Note: Equivalent rules often arise between a decision
table that you create and an existing rule.
Redundant
rules
When two rules have the same actions, one of them
becomes redundant when its conditions are included in the conditions
of the other.
In the following example, the Else part of Rule2 makes Rule1 redundant:
Rule1
if
the category of the customer is Gold
then
set the discount to 10
Rule2
if
the category of the customer is Platinum
then
set the discount to 15
else
set the discount to 10
Although Rule1 is correct,
it is redundant and can therefore be deleted.
Note: Redundant
rules often arise between a decision table that you create and an
existing rule.
Conflicting
and self-conflicting rules
Rules conflict when the
actions of two different rules set a different value for the same
business term (member). Conflicts occur between two rules when the
conditions are equivalent or cover the same values. For example, consider
the following two rules:
Rule1
if
the loan report is approved
and the amount of the loan is at least 300 000
then
set the category of the borrower to Gold
Rule2
if
the age of the latest bankruptcy of the borrower is less than 1
and the category of the borrower is not Platinum
then
set the category of the borrower to No Category
Rule1 and Rule2 conflict
when the following situation arises:
The loan report is approved.
The amount of the loan is 300 000 or more.
The borrower has not had a bankruptcy in the last year.
And the category is anything but Platinum.
In these specific circumstances, the rules sets the category
of the borrower to different values. You can correct conflicting rules
by changing the conditions, deleting one of the rules, or setting
different priorities on the rules.
A rule is self-conflicting when
two executions of a rule assign different values to the same member.
For example, a rule that can apply twice on a given working memory
(and ruleset parameters) and sets different values to a common attribute
is self-conflicting. For example:
if
the customer category is Gold
then
set the discount of the cart to the bonus points of the customer
With
this rule, if there are two customer objects
with different bonus points in
the working memory, the rule is executed twice and a conflict occurs
because the two executions of the rule set different values to the discount of the cart.
Decision
table conflicts
To
check decision tables and decision trees, you must enable the option Include
decision tables and decision trees in the inter-rule checks.
When
this option is enabled, you can check rules between and within decision
tables or decision trees. The rule analyzer checks for conflicts,
redundancies, and equivalences between the following elements:
Two rows of the same decision table
Two rows of two different decision tables
Two leaves of the same decision tree
Two leaves of two different decision trees
A row of a decision table and a leaf of a decision tree
A row of a decision table and an action rule
A leaf of a decision tree and an action rule
When this option is disabled, these checks are not performed
on decision tables and decision trees, but only on action rules.
However,
decision tables and decision trees are checked for never-applicable
rules and rules with domain violation even if the option is disabled.
This option does not impact overlapping and gap checks which are
detected when you write the rules.