"While" Semantics
Normally when the rule engine finishes execution of an action it starts re-evaluating rules that depend on changed facts only. However, generally speaking, it must also re-evaluate conditions of the rule that triggered the last action irrespective of whether the rule depends on the changed facts or not. The rationale behind this is that if conditions of a rule are met its actions must be executed. There is no guarantee that the action that has just been executed had changed anything that could have affected its conditions, so the engine must evaluate the rule again1).
This behaviour means that the same rule may be evaluated over and over again provided that its conditions still hold. Thus a rule may encapsulate the semantics of the “while” statement – instead of defining a rule as “IF something is true then do something” we might as well define it as “WHILE something is true then do something”.
The only problem with the above behaviour is that the subtlety of the “while” semantics is easy to overlook. Anyone defining business rules must be very careful as the incorrect usage of rules may cause infinite loops (the rule engine will eventually time out and abort if an infinite loop does occur). Consider the following rule:
IF Glass.State <> 'FULL' THEN INCREASE Glass.WaterLevel BY 10
The rule is supposed to add some water to a glass if it is not full already. If we only have this single rule defined for a Glass object and we evaluate it for a glass with the State attribute not FULL initially, the rule will keep executing the INCREASE action until the engine times out. However, if we add the following rule to the Glass object everything will be fine:
IF Glass.WaterLevel = 100 THEN Glass.State = 'FULL'
AwareIM supports a special flag that makes it possible to turn off the “while” semantics behaviour for a rule (see Advanced Rule Options). If this flag is turned off the rule engine will not evaluate the rule that triggered the execution of the last action block taken off the agenda (unless the conditions of the rule depend on the values of attributes that the action of the rule changes). For example, if the flag for the rule
IF Glass.State <> 'FULL' THEN INCREASE Glass.WaterLevel BY 10
is turned off, the rule will be evaluated initially and its action will be executed (jf state is not FULL), but it will not be executed immediately again. Other actions (if there are any) will get executed and if those actions do not change the value of the State attribute our rule will not be re-evaluated again. However, if our rule were written like this:
IF Glass.WaterLevel <> 100 THEN INCREASE Glass.WaterLevel BY 10
it would be re-evaluated repeatedly after the execution of the INCREASE action irrespective of the value of the “while semantics” flag. This is because the INCREASE action changes the value of the WaterLevel attribute and the rule condition depends on this value.