If you're 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 extra, optional behavior, then you will be in good shape later. Also, it may be helpful to think of the precondition behavior, if enabled, 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 no matter what.
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 us 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 will survive, and at least one must survive for the parent Policy also to survive.
Figure 174. Input Rulesheet for Precondition
But how does this affect the Claim in Nonconditional row A (of rule column 0)? Claim, as a root-level entity, is safely outside of the scope of our Filter, and therefore unaffected by it. Nothing the Filter does (or doesn't do) has any effect on what happens in Action row A – the two logical expressions are completely 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 175. 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 we model this?
Before true precondition behavior was introduced in Studio 4.0, our only practical option was to mandate an actual physical association between Policy and Claim, then incorporate that association into the scope of our Filter and rules. For example:
Figure 176. Rulesheet for Precondition
Notice that Claim is no longer a root-level entity – we have associated it with Policy and given the associatedClaim an alias aClaim. It is the alias, not the root-level entity, that's used in Nonconditional row A. So, when no elements of drivers are older than 16, the full filter ensures the parent Policy entity does not survive. And since the Policy does not survive the filter, its associated Claim does not survive, either. Here's an example of this:
Figure 177. Ruletest for Precondition
The net effect is that validClaim can only be false when one or more drivers is older than 16, which is what we want. But obtaining this result required us to monkey around with our data -- and, possibly our Vocabulary, data model, and database schema as well -- to associate Claim with Policy. Sometimes we as rule modelers have this freedom and flexibility. Often, we do not. If we don't, then we need an alternative method for controlling the execution of subsequent rules without relying on unnatural or artificial data and/or data model manipulations. Here's where the precondition behavior is useful.
Using the same example as in above, right-click on Filter row 1 and select Precondition.
Figure 178. Selecting Precondition Behavior from the Filter Right-Click Popup 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 would never stop 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 179. A Filter in Precondition Mode
As described before, the precondition behavior of the Filter will cause 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, as shown:
Figure 180. Rulesheet with a Filter in Precondition Mode
accomplishes our business intent without artificially changing our Vocabulary or underlying data model. A final proof is provided in the following figure:
Figure 181. Testsheet for a Filter in Precondition Mode
The yellow funnel icon in the Filter window receives a small red circle symbol
