skip to main content
Corticon Studio: Rule Modeling Guide : Rule writing techniques and logical equivalents : Filters vs. conditions
 

Try Corticon Now

Filters vs. conditions

The Filters section of a Rulesheet can contain one or more master conditional expressions for that Rulesheet. In other words, other business rules will fire if and only if data a) survives the Filter, and b) shares the same scope as the rules. Using our air cargo example from the previous chapter, we model the following rule:
Figure 63. Rulesheet Using a Filter and Nonconditional Rule
Here, the value of an Aircraft's maxCargoWeight attribute is assigned by column 0 in the Conditions/Actions pane (what we sometimes call a Nonconditional rule because it has no Conditions). The Filter acts as a master conditional expression because only Aircraft that satisfy the Filter - in other words, only those aircraft of aircraftType = ‘747’, successfully pass through to be evaluated by rule column 0, and are assigned a maxCargoWeight of 200,000. This effectively filters out all non-747 aircraft from evaluation by rule column 0.
If this Filter were not present, all Aircraft, regardless of aircraftType, would be assigned a maxCargoWeight of 200,000 kilograms. Using this method, additional Rulesheets may be used to assign different maxCargoWeight values for each aircraftType. The Filter section may be thought of as a convenient way to quickly add the same conditional expression or constraint to all other rules in the same Rulesheet.
We can also achieve the same results without using Filters. The following figure shows how we use a Condition/Action rule to duplicate the results of the previous Rulesheet. The rule is restated as an if-then type of statement: if the aircraftType is 747, then its maxCargoWeight equals 200,000 kilograms.
Figure 64. Rulesheet Using a Conditional Rule
Regardless of how you choose to express logically equivalent rules in a Rulesheet, the results will also be equivalent
Note: While the logical result may be identical, the time required to produce those results may not be. See Optimizing Rulesheets in the Logical Validation chapter of this Guide for details.
That said, there may be times when it is advantageous to choose one way of expressing a rule over another, at least in terms of the visual layout, organization and maintenance of the business rules and Rulesheets. The example discussed in the preceding paragraphs was very simple because only one Action was taken as a result of the Filter or Condition. In cases where there are multiple Actions that depend on the evaluation of one or more Conditions, it may make the most sense to use the Filters section. Conversely, there may be times when using a Condition makes the most sense, such as the case where there are numerous values for the Condition that each require a different Action or set of Actions as a result. In our example above, there are different types of Aircraft in the company's fleet, and each has a different maxCargoWeight value assigned to it by rules. This could easily be expressed on one Rulesheet by using a single row in the Conditions section. It would require many Rulesheet s to express these same rules using the Filters section. This leads us to the next topic of discussion.