thinking in rules

Ordering the Operations - Execution Patterns in irAuthor®

Robert Eaman | 8/15/2017

Beyond the basics of PEMDAS for individual calculations, how does the “order of operations” work in a rule application? Here’s a quick blog post about how to understand order of operations in InRule®.

Troubleshooting: Begin at the End

The first thing to know about the order of operations is where to find it in an executed rule application. That place is the rule engine feedback tab in irVerify®. The rule engine feedback tab lists every single evaluation that the rule engine conducts—in order—from start to completion of the rule engine’s runtime effort. This is essentially the post-mortem order of operations.

How the “Order of Operations” Works in irAuthor

While it’s easy to see how a rule actually ran, predicting its order requires knowledge of some basic rules of thumb. The first thing to know: the InRule rule engine executes rules in a deterministic manner according to the following input variables:

A)     Relationships:                  The structure and order of entities and associated rules

B)     Rule set settings:             The Fire Mode and Run Mode settings on existing rule sets

C)     Incoming Data:                The entity state data configured or loaded at runtime (prior to                                                    rule execution)

Since C) above (the incoming entity state data) is not known to the rule engine at authoring time, the complete agenda of execution is determined dynamically at runtime. How that agenda is built depends upon a number of factors.

Agenda Processing

When the Apply Rules button is pressed in irVerify (or when the Apply Rules directive is invoked through irSDK®), the rule engine’s agenda of tasks is developed to schedule work items for the rule engine. Development of this agenda considers entities, rule sets, rules, and calculation fields in the following basic order:

1)     Entities / Sequential and Optimized RuleSets: Entities and their children are tree-walked depth-first to find any executable logic. Any Sequential or Optimized RuleSets found are executed inline.

2)     Rescheduled or Activated Sequential RuleSets/Optimized RuleSets or Rules: Any Sequential RuleSet or Optimized RuleSet or Rule added to the Agenda due to an invalidated Dependency, or Activation change will execute after all items in step 1 have been processed.

3)     Explicit RuleSets:  If an Explicit RuleSet is executed from irSDK, it will execute after all items in steps 1 and 2 have been processed.

4)     Single-Pass RuleSets: During the Entity tree-walk for Sequential/Optimized RuleSets, any Single-Pass Sequential RuleSets found will execute after all items in steps 1, 2 and 3 have been processed.

5)     Calculation Fields: If Entities contain any unconsumed Calculation Fields, they will be evaluated by a second depth-first Entity State tree-walk, and any Calculations rescheduled for execution on the Agenda will evaluate after all items in steps 1, 2, 3 and 4 have been processed.

In Practical Terms…

The easiest way to use this knowledge to control your rule application’s execution flow is the following is to remember several basic rules of thumb:

A)    In general, execution precedence is “inside-out,” meaning that child-level rules and calculations are evaluated before parent level rules and calculations

B)    The rule engine notes the dependencies of calculations, and slots the dependencies to occur before the calculations

C)     Auto-sequential rule sets may refire if changes occur in that rule set’s dependencies

D)    Explicit rule sets are never evaluated until they are told to do so

E)     A common way to execute an explicit rule set is conditionally, invoking an execute rule set or execute member rule set action as the result of conditional logic

F)     Auto rule sets will run once for each occurrence of that entity in the passed-in data state

G)    A very common execution pattern is to create a controller rule set with an auto fire mode, and then to use primarily explicit rule sets (which are launched conditionally from that auto rule or its subsidiaries)

Whichever method you choose, you’ll want to check the rule engine feedback during development and unit testing to ensure that you didn’t overlook something in your execution order.

Best of luck! And feel free to drop us a line with questions

comments powered by Disqus