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 - http://msdn2.microsoft.com/en-us/library/ms942178.aspx

Comments (3)

  1. NineTom says:

    I think you have some mistakes.

    For Assert

      First Round, It should be

    Fact1.B=10

    Assert(Fact2)

      Second Round, it should be

    Fact1.B=10

    Fact2.D=2

    Fact2.C=1

    Assert(Fact2)

    Or me wrong?

  2. Asad Khan says:

    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".

  3. When I include the fact "Fact2.D=2" in first execution cycle and correct the fact "Fact2.D=1" to "Fact2.D=2" in the second cycle then both the cycles become identical..

    According to me First Cycle of execution would be :

    Fact1.B=10

    Fact2.D=2

    Fact2.C=1

    Assert (Fact2)

    and Second one would be :

    Fact1.B=10

    Fact2.D=5

    Fact2.C=1

    Assert (Fact2)

    Brajendra Singh, what u say? is that correct or not?

Skip to main content