skip to main content
Corticon Studio: Rule Modeling Guide : Logical analysis and optimization : Validating and testing Rulesheets in Corticon Studio : The conflict checker
 

Try Corticon Now
The conflict checker
With our two rules expanded into four sub-rules as shown in Expanding Rules to Reveal Components), most of the Cross Product is displayed for us. Click the Check for Conflicts button in the toolbar.
Figure 219. A Conflict Revealed by the Conflict Checker
The mechanics of stepping through and resolving each conflict are described in detail in the Corticon Studio - Basic Tutorial
Note: Refresher on conflict discovery and resolution -- On a Rulesheet, click Check for Conflicts , and then expand the rules by clicking Expand Rules . Expansion shows all of the logical possibilities for each rule. To resolve conflict, either change the rules, or decide that one rule should override another. To do that, in the Overrides row at each column intersection where an override is intended, select the one or more column numbers that will be overridden when that rule fires. Click Check for Conflicts again to confirm that the conflicts are resolved.
In this topic, our intent is to correlate the results of the automatic conflict check with the problems we identified first with the flowchart method, then later with test cases. Sub-rules 1.1 and 2.1, the sub-rules highlighted in pink and yellow in Figure 219, correspond to the intersection of column 1 and row 1 of Rule 2 Expected Outcome or test case #1 in Test Cases Extracted from Cross Product. But note that Corticon Studio does not instruct the rule writer how to resolve the conflict – it simply alerts the rule writer to its presence. The rule writer, ideally someone who knows the business, must decide how to resolve the problem. The rule writer has two basic choices:
1. Change the Action(s) for one or both rules. We could change the Action in sub-rule 1.1 to match 2.1 or vice versa. Or we could introduce a new Action, say riskRating = medium, as the Action for both 1.1 and 2.1. If either method is used, the result will be that the Conditions and Actions of sub-rule 1.1 and 2.1 are identical. This removes the conflict, but introduces redundancy, which, while not a logical problem, can reduce processing performance in deployment. Removing redundancies in Rulesheets is discussed in the Optimization section of this chapter.
2. Use an Override. Think of an override as an exception. To override one rule with another means to instruct the Corticon Server to fire only one rule even when the Conditions of both rules are satisfied. Another way to think about overrides is to refer back to the discussion surrounding the flowchart in Flowchart with 2 Dependent Rules. At the time, we were unclear which decision should execute first – no priority had been declared in our rules. But it made a big difference how we constructed our flowchart and what results it generated. To use an override here, we simply select the number of the sub-rule to be overridden from the drop-down box at the bottom of the column of the overriding sub-rule, as shown circled in the following figure. This is expressed simply as sub-rule 2.1 overrides 1.1. It is incorrect to think of overrides as defining execution sequence. An override does not mean fire rule 2.1 then fire rule 1.1.  It means fire rule 2.1 and do not fire rule 1.1.
Figure 220. Override Entered to Resolve Conflict
An override is essentially another business rule, which should to be expressed somewhere in the Rule Statements section of the Rulesheet. To express this override in plain English, the rule writer might choose to modify the rule statement for the overridden rule:
This modification successfully expresses the effect of the override.
If ever in doubt as to whether you have successfully resolved a conflict, simply click the Check for Conflicts button again. The affected sub-rules should not highlight as you step through any remaining ambiguities. If all ambiguities have been resolved, you will see the following window:
Figure 221. Conflict Resolution Complete
Note: How does one rule override another rule? - To understand overrides, the first concept to learn is condition context. The condition context of a rule is the set of all entities, aliases, and associations that are needed to evaluate all the conditional expressions of a rule. The second concept is the override context. The override context is defined using set algebra. The override context of two rules is the intersection of the two rule’s condition contexts. To evaluate the override, the set of entities that fulfill the overriding rule’s conditions are trimmed to the override context and recorded. Before the conditions of the overridden rule are evaluated, the entities that are part of the override context are tested to determine if they have been recorded; if so, the rule is overridden and processing of the rule with those entities is halted. If the override context is empty, then any execution of the overriding rule will stop all executions of the overridden rule.
Overrides can take effect even if there are no conflicts - Overrides can be used for more than just conflicting rules. While the basic use of overrides is in cases where rules are in conflict to allow the modeler to control execution, it is not the only use. The more advanced usage applies cases where there is a logical dependency -- cases where a rule might modify the data so that another rule can also execute. This type of conflict is not detected by the conflict checker.
Consider a simple Cargo Rulesheet:
When tested, the first rule is triggered and its action sets a value that triggers rule 2:
The Ruletest result shows that the value set in the first rule's action modified the data so that the change in the condition's value triggered the second rule. If this effect is not what is intended, an override can be used. The use of an override here ensures that the modification of data will not trigger execution of the second rule -- they are mutually exclusive (mutex). When an override is set on rule 1 that specifies that, if it fired, it should skip rule 2...
... the rules produce the preferred output:
If these rules were re-ordered, the override would be unnecessary.
* Using overrides to handle conflicts that are logical dependencies