Because the rule is evaluating both Cargo and Aircraft in the context of a FlightPlan, we say that the rule has scope, which means that the rule evaluates only that data which matches the rule's scope. This has an interesting effect on the way the rule is evaluated. When the rule is executed, its scope ensures that the Corticon Server evaluates only those pairings that match the sameFlightPlan. This means that a cargo.weight will only be compared to an aircraft.maxCargoWeightif both the cargo and the aircraft share the same FlightPlan. This simplifies rule expression greatly, because it eliminates the need for us to specify whichFlightPlan we are talking about for each Aircraft-Cargo combination. When a rule has context, the system takes care of this matching automatically by sending only those Aircraft - Cargo pairs that share the sameFlightPlan to be evaluated by the rule. And, since Corticon Studio automatically handles multiple instances as collections, it sends all pairs to the rule for evaluation.
Note: See the following topic, Collections, for a more detailed discussion of this subject.
To test this new rule, we need to structure our Ruletest differently to correspond to the new structure of our rule and reflect the rule's scope. For more information on the mechanics of creating associations in Ruletests, also refer to the Set Up the Ruletest Scenario section in the Corticon Studio Tutorial: Basic Rule Modeling and the Creating Associations chapter in the Quick Reference Guide.
Finally, one FlightPlan is created for each Aircraft-Cargo pair. This means a total of three FlightPlans are generated each night. Using the terms in our Vocabulary and the relationships betweenthem, we have the possibilities shown in Figure 45. The rule will evaluate these combinations and identify any violations.
Figure 50. New Ruletest Using FlightPlan as the Rule Scope
What is the expected result from this Ruletest? If the results follow the same pattern as in the first Ruletest, we might expect the rule to fire nine times (three Aircraft evaluated for each of three Cargo shipments).
But refer to Ruletest Results Using Scope – Note no Violations and you will see that the rule, in fact, fired only 3 times – and only for those Aircraft-Cargo pairs that are related by common FlightPlans. This is the result we want. The Ruletest shows that there are no FlightPlans in violation of our rule.
Figure 51. Ruletest Results Using Scope – Note no Violations
One final point about scope: it is critical that the context you choose for your rule supports the intent of the business decision you are modeling. At the very beginning of our example, we stated that the purpose of the application is to check flightplans that have already been created. Therefore, the context of our rule was chosen so that the rule's design was consistent with this goal – no aircraft-cargo combinations should be evaluated unless they are already matched up via a common flightplan.
But what if our business purpose had been different? What if the problem we are trying to solve was modified to: Of all possible combinations of aircraft and cargo, determine which pairings must not be included in the same FlightPlan. The difference here is subtle but important. Before, we were identifying invalid combinations of pre-existing FlightPlans. Now, we are trying to identify invalid combinations from all possible cargo-aircraft pairings. This other rule might be the first step in a screening or filtering process designed to discard all the invalid combinations. In this case, the original rule we built, root-level context, would be the appropriate way to implement our intentions, because now we are looking at all possible combinations prior to creating new FlightPlans.
