The BizTalk 2004 rules execution engine is “a discrimination network-based forward-chaining inference engine designed to optimize in-memory operation”. Apparently.
What I understand this to mean is that it can arrive at a decision based on reasoning of facts against conditions (inference), and that it reacts to new facts being “asserted” in a way which means that only rules which are relevant are re-examined (forward chaining). Facts get put into working memory. This triggers rules whose conditions match the new data. These rules then perform their actions. The actions may add new data/facts to memory, thus triggering more rules. And so on. The wikipedia has a pretty good summary.
Whilst this sounds pretty academic, it’s also important. Without understanding this, you can get yourself in a real buggers muddle – I’m proof of this! The rules engine has 3 stages to execution. The first stage is “matching” – if you’ve done some tracing of rules execution in the BRC this stuff will sound familiar. This stage checks its rules “conditions” against current “in memory” facts. These facts being loaded into memory are the “asserts” you see in the debug output. Once a condition is evaluated as true it gets added to the rule “agenda” (Agenda Update in the trace output). This is a sort of wait area until the engine has been through all the rules in the policy. Next stage is “Conflict Resolution” (don’t you just love that!). This is where the order of the rule firing is determined based upon the priority you have set for the rule. In the next “Action” stage, the actions of the rule are fired.
What’s important to remember here is that the “Action” stage could assert some more facts into memory. So what? Well to quote MSDN;
“Note that rule actions can assert new facts into the rule engine, which causes the cycle to continue. This is also known as forward chaining. It is important to note that the algorithm never pre-empts the currently executing rule. All actions for the rule that is currently firing will be executed before the match phase is repeated. However, other rules on the agenda will not be fired before the match phase begins again. The match phase may cause those rules on the agenda to be removed from the agenda before they ever fire. “
This is essentially what you would expect to happen I guess, but as most of the rules processing is done “behind closed doors” it can be hard to get a handle on what’s causing this type of effect. The tracing/debugging leaves a little to be desired. That’s where I’m off to next …