Ordering the Operations – Execution Patterns in irAuthor®

RE

Robert Eaman

08/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.

InRule for JavaScript | inrule said: "[…] couple of weeks ago we announced availability of InRule® for JavaScript through an early adopter program. To our knowledge this is […]".
Dynamic Surveys in Dynamics CRM Part II: Managing Dependencies | inrule said: "[…] this post makes extensive references to my preceding post, Surveys in Dynamics CRM Part I: Don’t Be a Monkey With Your Survey. If you are the type of person who likes to get the full story, you should go back and read the […]".
Josh Elster said: "In the time since this post was published, I've added (via a PR) full Windows Containers example code, DOCKERFILEs and scripts. They share common ancestry with the GH Gists I posted earlier, but are more up-to-date and tested. Here's a direct link to that sub-folder: https://github.com/InRule/Samples/tree/master/Developer%20Samples/WindowsContainers Now that our Samples repository is public, feel free to file Issues if you have problems or features you'd like to see implemented. If you have something you'd like to contribute, then by all means do so! The contributor guidelines and process are listed in the root of the repository. Enjoy! I'll update the body of the post as well with this link.".