Understanding Rule Execution in BizTalk Rule Engine

BizTalk business rule engine (BRE) is a wonderful tool to extend dynamics and flexibility of business. It allows business rules to be tailored on the fly with no hazards and downtime.

In BRE, you can define “Policy”. Policy contains “Rules” drafted by business people. You can consider “Policy” as a logical grouping of rules. For example, in banking system, rules associated to house loan approval process can be clubbed under one policy. Rule definition contains two parts – Condition and Action. condition can be defined based on fact values or independent of that. If rule condition(s) are met by facts then all actions under that rule are executed. Rules can also be assigned priority. Rules with higher priority number are preferred in execution. Once policy is laid out, during day to day business, “Facts” are supplied in the course of policy to run business procedure according to rules.

How do these rules execute? Do they run sequential or run in block? I am sure every BTS developer is interested to learn this. My current entry explains these fundamentals of “Business Rule Execution”.

We will try to understand rules execution through example. Let’s assume that there is a policy “P1” which contains following rules –

Cond1, cond2 etc. are conditions of rules and Action11, Actions21 etc. are actions executed under their respective rules. Rules are also assigned priority. We will use this example to understand execution.

Business Rule Execution

Business rules execution cycle works in three stages –

• Match
• Conflict Resolution
• Action

Match

Rules conditions are evaluated based on values provided in facts. Few interesting things to learn here –

- Conditions of all rules are evaluated together at once.

- If there are conditions which are shared across rules then those conditions are evaluated only once.

- If some condition is based on fact and that particular fact is not supplied then that rule is ignored.

This provides better efficiency in execution. Rules whose condition satisfy become candidate for execution and outline rule engine “Agenda” for execution cycle.

In our example, if cond1, cond2, cond5 and cond6 match then R1, R2, R5 and R6 add up to “Agenda”.

Agenda – R1, R2, R5, R6

You can consider “Agenda” formation as yield of match stage.

Conflict Resolution

In this stage, rules are checked against their predefined priority to establish exact sequence of execution. Priorities are put on rules when you desire one rule to be executed before another. Rules with higher priority number are executed first. Rules with same priority number can be executed in any sequence.

During conflict resolution, the sequence of rule execution alters in agenda based on their priority number. In our example, Agenda thus becomes –

Agenda – R5, R2, R1, R6

Action

Actions in the resolved rules (as queued in agenda) are executed in this stage. Actions belonging to a rule are treated as a block and executed from top to bottom. Then next rule in picked according to sequence in agenda.

In our example, actions are executed as following –

Action51

Action52

Action21

Action11

Action12

Action61

Conclusion

This was a straightforward execution cycle to understand basics. If you employ engine control functions like “Assert”, “Update” etc. then execution becomes little more complex. For example, in “Action” stage you might insert some facts or update fact values which will enables few other rules to be candidate of agenda. And then execution cycle repeats again from “Match” stage. This concept is called “Forward Chaining” . I have planned to write another entry about forward chaining and effect of engine control functions on rule execution cycle. Please wait for some time and thanks for reading current one.