Rule Priorities

When describing the rule engine algorithm in the Overview of the Rule Engine Framework section we said that action blocks are taken off the agenda at random. This is not quite true - the order of action blocks on the agenda is not completely random, but arranged according to rule priorities. The higher the priority of the rule corresponding to the action block the sooner it will be executed. The rule engine guarantees that action blocks corresponding to rules with higher priority are always executed before action blocks corresponding to rules with lower priority – whatever actions exist on the agenda are sorted according to the priorities of their rules and are taken off the agenda in that order.

It is important to stress, though, that if priorities of the rules are the same, the order of the corresponding action blocks is random. Most often action blocks on the agenda correspond to rules that have the same priority – that is why we ignored rule priorities when describing the rule engine algorithm.

So when are priorities important? First of all, when we are dealing with rules that invoke actions that do not modify the value of some attribute, but call predefined system operations, such as REPORT ERROR,SEND etc. By default Aware IM assigns lower priorities to such rules than the priorities of rules invoking actions that modify attributes. The rationale is that unlike modification of an attribute, the predefined system operations are one-off actions that usually have drastic effects that cannot be undone. For example, the REPORT ERROR action immediately aborts the execution of the rule engine without giving it a chance to change anything (unless process failure rules are defined). Consider the following rules:

Rule 1:

IF Policy.State IS UNDEFINED THEN REPORT ERROR 'State must always be defined' 

Rule 2:

IF Policy.State IS UNDEFINED THEN Policy.State = 'NEW' 

If priorities of these rules were equal there is a chance that Rule1 is executed before Rule 2. If this happened the engine would be immediately aborted without being able to change the value of the Policy.State to NEW and by doing so avoid execution of Rule 1. This does not happen as Aware IM assigns lower priority to Rule 1 than to Rule 2 or any other “modify attribute” rule. Therefore validation rules like Rule 1 are only evaluated after the values of all attributes have “stabilized”.

Another type of rule that is prioritised by Aware IM by default is a rule that has an action, which generates documents from document templates (see Document Generation). Again documents should only be generated after values of all attributes have stabilized and so such a rule has low priority.

It is relatively rare that someone might need to prioritize rules explicitly. One such need may arise from the necessity to specify the default action to be taken if all else fails. For example, there may be a situation when we enumerate possible options and take action in each case: If condition1 then do something; If condition2 then do something else; If condition 3 then do something else again and so on. Finally we may want to take a default action that is executed if neither of the conditions holds. We could write a rule that would negate all the conditions: If NOT condition1 and NOT condition2 and NOT condition3 … then take default action. If there are many conditions it may be quite tedious and impractical to negate them all. An alternative would be to assign lower priority to the rule that takes the default action compared to the rules that check conditions.