If you are comfortable with the limiting and full behaviors of a Filter expression, then its precondition behavior is even easier to understand. While reading this section, keep in mind that filters always act as either limiting or full filters, but they can also act as preconditions if you enable that behavior as described in this section. If you think of filtering as a mandatory behavior but a precondition as an optional behavior, then you will be in good shape later. Also, it may be helpful to think of the precondition behavior, if enabled, as taking effect after the filtering step is complete.

Precondition behavior of a filter ensures that execution of a Rulesheet stops unless at least one piece of data survives the filter. If execution of a Rulesheet stops because no data survived the filter, then execution moves on to the next Rulesheet (in the case where the Rulesheet is part of a Ruleflow). If no more Rulesheets exist in the Ruleflow, then execution of the entire Ruleflow is complete.

In effect, a filter with precondition behavior enabled acts as a gatekeeper for the entire Rulesheet - if no data survived the filter, then the Rulesheet's gate stays closed and no additional rules on that Rulesheet will be evaluated or executed.

If, however, data survived the filter, then the gate opens, and the surviving data can be used in the evaluation and execution of other rules on the same Rulesheet.

The precondition behavior of a filter is significant because it allows you to control Rulesheet execution regardless of the scope used in the rules. Take, for example, the Rulesheet shown in the following figure. The filter in row 1 is acting in its standard default mode of full filter. This means that Driver entities in the collection named drivers and the collection's parent entity Policy are both affected by this filter. Only those elements of drivers older than 16 survive, and at least one must survive for the parent Policy also to survive.

Figure 1. Input Rulesheet for Precondition

But, how does this affect the Claim in nonconditional row A (rule column 0)? Claim, as a root-level entity, is safely outside of the scope of the filter, and therefore unaffected by it. Nothing the filter does (or does not do) has any effect on what happens in Action row A—the two logical expressions are independent and unrelated. As a result, Claim.validClaim will always be false, even when none of the elements in drivers are older than 16. A quick Ruletest verifies this prediction:

Figure 2. Rulesheet for an action unaffected by a filter

But, what if the business intent of our rule is to update Claim based on the evaluation of Policy and its collection of Drivers? What if the business intent requires that the Policy and Claim really be related in some way? How do you model this?

Using the same example, right-click on Filters row 1 and select Precondition.

Figure 3. Selecting precondition behavior from the filter menu

Note that the two options, Precondition and Limiting Filter, are mutually exclusive: turning one on turns the other off. A filter cannot be both a precondition and a limiting filter because at least one piece of data always survives a limiting filter, so a precondition never stops execution.

Selecting Precondition causes the following:

  • The yellow funnel icon in the Filter window receives a small red circle symbol
  • The yellow funnel icons in the Scope window receive small red circle symbols

The following figure shows a filter in Precondition mode.

Figure 4. A Filter in Precondition Mode

As described before, the precondition behavior of the filter causes Rulesheet execution to stop whenever no data survives the filter. So, in the original case where Policy and Claim were unassociated, a filter in Precondition mode accomplishes the business intent without artificially changing the Vocabulary or underlying data model, as shown:

Figure 5. Rulesheet with a filter in Precondition mode

A final proof is provided in the following figure:

Figure 6. Testsheet for a filter in Precondition mode