Effect of Engine Control Functions on Business Rule Execution – Part1
Policies in BizTalk Rule Engine execute according to Match – Conflict Resolution – Action algorithm. Engine control functions influence rule execution cycle in big way. They cause execution cycle to recur more than once and also control action agenda to be executed.
Following are BRE engine control functions –
I will explain each of these functions with example and would cover them in two parts. Before I move further, I request you to read (if you don’t know already) my article about business rule execution @ https://blogs.msdn.com/brajens/archive/2006/10/13/understaing-rule-execution-in-biztalk-rule-engine.aspx
Assert
Assert function is a way to insert facts into rule engine working memory at execution time. Assert function might cause rule execution cycle to repeat and it can also alter rule execution agenda. When a fact is added using Assert () function, rule execution cycle repeats itself and rules are reevaluated.
Consider following example,
Suppose there is a policy which is based on following facts (say .net objects).
Fact1 |
Fact2 |
Fact3 |
Properties A B |
Properties C D |
Property E |
There are three rules using these facts
Rule1 |
Rule2 |
Rule3 |
If Fact1.A = 2 Then Fact1.B=10 Fact2.D=2 |
If Fact2.C=1 Then Fact2.D=5 |
If Fact3.E>0 Then Fact2.C=1 Assert(Fact2) |
When policy is called for execution, following facts are supplied –
Fact1 |
Fact2 |
Fact3 |
A = 2 B |
Not Supplied |
E = 9 |
Rules execution starts as per Match – Conflict Resolution – Action algorithm. Following action agenda is loaded into working memory for execution –
Fact1.B=10
Fact2.C=1
Assert (Fact2)
Since Fact2 was not supplied, Rule 2 and action [Fact2.D=2] are ignored. When Assert () function runs during execution, Fact2 got inserted into rule engine working memory. States of facts have changed now, it triggers rule execution cycle again with same Match – Conflict Resolution – Action algorithm in context of changed state of facts.
Next execution cycle produces following action agenda –
Fact1.B=10
Fact2.D=1
Fact2.C=1
Assert (Fact2)
It means, every time an Assert () function is executed, execution cycle repeats itself and all rules are evaluated again to determine new set of agenda for action. This concept is called Forward Chaining.
This leads to a problem also. If you check new agenda, you will find that Assert () is called again and it will trigger execution cycle repeat again. This will cause end less loop of execution. The default maximum loop count of re-evaluation of rules is 2^32. One can use Maximum Execution Loop Depth property of the policy to adjust loop counts.
There is a way to do away with this end less loop scenario and that is use of “update” function.
Update
Update is similar to Assert because it also causes execution cycle to repeat and controls action agenda in working memory. The difference lies in how rules are evaluated. In Assert all of the rules are re-evaluated while in Update only those rules are re-evaluated where updated fact is either in predicate or in both action and predicate.
Consider same example again with little change –
Rule1 |
Rule2 |
Rule3 |
If Fact1.A = 2 Then Fact1.B=10 Fact2.D=2 |
If Fact2.C=1 Then Fact2.D=5 |
If Fact3.E>0 Then Fact2.C=1 Update(Fact2) |
When policy is called for execution, following facts are supplied –
Fact1 |
Fact2 |
Fact3 |
A = 2 B |
C = 2 |
E = 9 |
Rules execution loads following action agenda into working memory for execution –
Fact1.B=10
Fact2.D=2
Fact2.C=1
Update (Fact2)
Rule 2 is ignored because “if condition” did not match. When Update () function executes, Fact2 got updated into rule engine working memory. Rule execution cycle repeats again with same Match – Conflict Resolution – Action algorithm in context of changed state of facts. During rules re-evaluation only those rules are considered where Fact2 is either in predicate or in both action and predicate. If you check all of the rules, only Rule 2 satisfies this condition.
Since only Rule 2 is re-evaluated, Next execution cycle produces following action agenda –
Fact2.D=5
Conclusion
“Assert” and “Updated” are two very useful functions to determine execution cycle and working memory agenda. Developers get flexibility to add or update a fact or their state to determine policy execution results. For further study, there is a very nice article in MSDN which shows use of these functions. Here is link - https://msdn2.microsoft.com/en-us/library/ms942178.aspx
Comments
- Anonymous
October 28, 2007
I think you have some mistakes.For Assert First Round, It should beFact1.B=10Assert(Fact2) Second Round, it should beFact1.B=10Fact2.D=2Fact2.C=1Assert(Fact2)Or me wrong? - Anonymous
January 27, 2008
Love the article, however under Assert description, both the agenda (i.e. list of actions) are not correct. In the first, fact "Fact2.D=2" is missing and should be included. In the second, fact "Fact2.D=1" should be corrected to "Fact2.D=2". - Anonymous
April 15, 2008
The comment has been removed