Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
Windows Server

BizTalk Server 2009 : Use The Business Rule Engine (part 2) - What Are the Artifacts That Constitute a Business Rule?

5/24/2013 5:33:22 PM

In the "What Is a Business Rule Engine?" section, we touched briefly on the structure of a business rule and the fact that it is composed of facts (no pun intended), conditions, and actions (see Figure 2). In this section, we give you a detailed look at these artifacts.

Figure 2. Business rule structure

4.1. Facts and Vocabularies

Before embarking on the creation of business rules, the business analyst should identify the different data facts involved in the evaluation or execution of a particular rule. Those facts are usually aliased using a domain-specific nomenclature understood by peers in that domain. Such domain-specific definitions are referred to in the Business Rule Composer as a vocabulary, as in the vocabulary specific to the problem domain for which you are creating the business rules.

Vocabularies are a wonderful way to abstract facts from their implementation. Although a vocabulary set can be composed of different types of facts, the business analyst and business rule creator can deal with them all in the same fashion while creating or updating their business rules.

These types of facts can be included when composing a vocabulary:

  • Constant values, ranges of values, or value sets used to validate and constrain rule parameters.

  • .NET classes or class members, which may be used to wrap other vocabularies and/or define bindings and binding parameters. "For example, a vocabulary definition might refer to a .NET method that takes two parameters. As part of the definition, one parameter may be bound to the value in an XML document and the other may be defined by the user at design-time but limited to the valid values defined in another definition that defines a 'set'".

  • XML document elements or attributes.

  • Data tables or columns in a database.

  • Custom managed facts to be retrieved through a .NET object that implements the fact retriever interface.

Using the Business Rule Composer, you may define vocabularies and store them in the shared rule store. Vocabularies can also be consumed by tool developers responsible for integrating rule authoring into new or existing applications.


The requirement to define vocabularies and facts before the definition of the business rules within a policy can be cumbersome and annoying for most business analysts, and usually results in them creating and publishing multiple versions of their vocabularies as they are developing the business rules. Hopefully in the future, the Business Rule Composer will allow the composition of business rules based on unpublished vocabularies that business analysts can create and edit while creating their rules, and restrict users from publishing policies until the vocabulary they use is published.

Before being used in business rules, vocabularies must be stamped with a version number and published in the rule store. Once published, a vocabulary version is immutable. This guarantees that the definitions in the vocabulary will not change. It preserves the referential integrity between policies and the vocabulary. This prevents any policies that use a particular version of the vocabulary from failing unexpectedly due to changes in the underlying vocabulary .

Users can define two types of vocabulary items or facts, short-term and long-term facts. A short-term fact is specific to a single execution cycle of the Business Rule Engine and does not need to exist beyond that execution cycle. A long-term fact is loaded into memory for use over an arbitrary number of execution cycles. Long-term facts are used to represent static datasets or data that changes infrequently, such as a list of U.S. states or daily interest rates.

In the BizTalk BRE, the only real distinction between the two is in implementation Long-term facts improve performance by limiting queries to source repositories and should be considered for high-performing applications.

To use long-term facts, you must configure your policy to know where to find them and implement a fact retriever object that can fetch those facts from an external store and present them to the policy. According to the BizTalk Server 2009 documentation (Microsoft, 2009), there are three ways to supply fact instances to the rule engine:
  • The simplest way to submit fact instances to the rule engine is with short-term, application-specific facts that you pass in to the policy object as an array of objects or as XML messages from an orchestration at the beginning of every execution cycle.

  • You can use your rule actions to assert additional facts into the engine during execution when those rules evaluate to true.

  • You can write a fact retriever—an object that implements a standard interface and typically uses them to supply long-term and slowly changing facts to the rule engine before the policy is executed. The fact retriever may cache these facts and use them over multiple rule execution cycles.


If your data changes frequently between execution cycles and must be reinstantiated and asserted again, you likely want to represent this data as short-term facts.

4.1.1. XML Fact Strategies

As we mentioned previously, facts asserted into the rule engine's working memory can be .NET objects, XML documents, or data tables. These facts contain fields called slots in the world of rule engines. If a business rule requires access to a slot in a fact to evaluate a condition and that slot is not defined—for example, an optional XML element that is not defined in the XML input message—the BRE will throw an exception. The engine will attempt to perform this evaluation because the relevant fact has been asserted. However, when it looks for the slot, it will not find it.

In this situation, why does the engine throw an exception?

When you create a vocabulary definition for a node in your schema or when you use an XML fact directly in the rule, two properties are set: XPath Selector and XPath Field. These properties are the way the engine can refer to data fields or slots in a given fact. The vocabulary definition maps these to business-friendly terms defined by the Name and Display Name properties.

The XPath Selector defines and selects a fact. If a vocabulary definition is referring to a fact rather than a slot, the XPath Field property will be empty. However, there will be an additional XPath expression in the XPath Field property if the vocabulary definition is referring to a slot. This XPath expression is used to select a descendant node of the fact. The engine will throw an exception if a fact exists and it tries to evaluate a business rule condition depending on this fact, but the vocabulary in the condition refers to a slot that does not exist in the message instance asserted into the engine's working memory.

If the fact does not exist, no error would occur in the first place. Very simply, the engine would not be able to assert the fact and would therefore realize that it cannot evaluate any rule conditions that depend on this fact. If the fact exists, the engine assumes that the child element exists and throws an error when it tries to access the nonexistent element.

To ensure that you do not run into such situations, you can edit the XPath Selector so that it only selects fact instances with the required slots defined. XPath supports filters that you can use to amend the XPath Selector to ensure those required slots exist.

For example, if you had a message like this one:

      <Field2> MyField2 value </Field2>

a vocabulary named MyDataField defined to reference Field2 will have an XPath Selector value of

/*[local-name()='My_Message' and namespace
[local-name()='MyMessage' and namespace
uri()='']/*[local-name()='Fields' and namespace-uri ()='']

and an XPath Field value of

*[local-name()='Field2' and namespace-uri()='']

To avoid exceptions if an asserted My_Message instance does not have a Field2 element defined, you can modify the XPath Selector to the following:

/*[local-name()='My_Message' and namespace-
[local-name()='MyMessage' and namespace-
uri()='']/*[local-name()='Fields' and namespace-uri()=''][Field2]

You can improve this filtering process further by modifying the XPath Selector to select My_Message nodes with a Field2 child element, which has a nonempty text node only:

/*[local-name()='My_Message' and namespace-
[local-name()='MyMessage' and namespace-
uri()='']/*[local-name()='Fields' and namespace-uri()=''][Field2!=""]

The key to effectively using the BRE and using XML facts is to understand XPath and the difference between facts and slots, and to edit your XPath Selectors and XPath Fields accordingly to meet your needs. A good example is a business rule that should perform an action only if a certain number of fields have the same value. For instance, an institute that wants to automate the selection of courses it offers to its students would use a business rule that looks at a feedback summary report for a class and adds the class to the offered courses roster only if ten students or more responded that the course was "Very Good". This could be implemented through a set of complex business rules or custom code. A better alternative is to leverage XPath to define a vocabulary item that represents the count of "Very Good" responses.

Assuming the feedback summary is as follows:

  <Course title="Introduction to BizTalk 2009" />
  <Instructor>John Smith</Instructor>
    <answer value="Good"/>
    <answer value="Bad"/>
    <answer value="Very Good"/>
    <answer value="Good"/>
    <answer value="Very Good"/>
    <answer value="Very Good"/>
    <answer value="Very Good"/>
    <answer value="Very Good"/>
    <answer value="Very Good"/>
    <answer value="Very Good"/>
    <answer value="Very Good"/>
    <answer value="Very Good"/>
    <answer value="Very Good"/>
    <answer value="Good"/>
    <answer value="Bad"/>
    <answer value="Very Good"/>
    <answer value="Good"/>
    <answer value="Very Good"/>
    <answer value="Very Good"/>
    <answer value="Very Good"/>
    <answer value="Very Good"/>
    <answer value="Very Good"/>
    <answer value="Very Good"/>
    <answer value="Very Good"/>
    <answer value="Very Good"/>
    <answer value="Very Good"/>


you could define a vocabulary item named GoodCount that counts the number of "Very Good" answers as follows:

XPath Selector: /*[local-name()='CourseFeedback' and namespace-
and namespace-uri()='']/*[local-
name()='WouldYouRecommendThisCourseToAFriend' and namespace-uri()='']

XPath Field: Count(//answer[@value="Very Good"])

You can then define a business rule as part of the policy that checks whether the count is greater than ten, and if so sets the course to be OnRoster.

XPath Selector: /*[local-name()='CourseFeedback' and namespace-uri()=

XPath Field: *[local-name()='CourseOnRoster' and namespace-uri()='']

SetCourseOnRoster (priority = 0)
IF GoodCount
     is greater than or equal to 10
THEN CourseOnRoster = "Yes"
ELSE CourseOnRoster = "No"

Leveraging XPath queries in the definition of XPath Field properties is a great way to minimize custom code and optimize the execution of the BRE to evaluate complex rules.

4.1.2. Custom Fact retrievers

Fact retrievers are used to manage long-term facts used by business policies. "If a fact changes infrequently, rule processing efficiency can be obtained by saving it as a long-term fact and loading it into memory to reuse. By referencing this fact retriever in a policy, the user ensures that the engine (more accurately the policy class) will call the fact retriever to get long-term facts" .

To expose long-term facts to the BRE and leverage them in the definition of business rules and policies, you may use custom fact retrievers, which are custom .NET classes that implement the Microsoft.RuleEngine.IFactRetriever interface. This interface has a single public method, UpdateFacts. A particular fact retriever may be associated with a particular policy version through the policy property settings. This indicates to the BRE that an instance of that fact retriever object should be instantiated and the method UpdateFacts called to update all custom facts associated with that particular policy. It is the responsibility of the fact retriever to determine when the fact base has changed.


A long-term fact only needs to be asserted once for the same rule engine instance. For example, when you use the Call Rules shape in an orchestration, the policy instance is moved into an internal cache. At this time, all short-term facts are retracted and long-term facts are kept. If the same policy is called again, either by the same orchestration instance or by a different orchestration instance in the same host, this policy instance is fetched from the cache and reused. In some batch processing scenarios, several policy instances of the same policy could be created. If a new policy instance is created, you must ensure that the correct long-term facts are asserted.

The following custom fact retriever, DbFactRetriever, selects a set of rows from a database table, adds them to a typed data table, and asserts it as a fact. You can also add your own code to determine whether cached data is obsolete and should be updated.

public class DbFactRetriever:IFactRetriever
      public object UpdateFacts(RuleSetInfo rulesetInfo,
 Microsoft.RuleEngine.RuleEngine engine, object factsHandleIn)
         object factsHandleOut;

         // The following logic asserts the required DB rows only once and always
         // uses the same values (cached) during the first retrieval in
         // subsequent execution cycles
         if (factsHandleIn == null)

            string strCmdSqlCon = "Persist Security Info=False;"+
             "Integrated Security=SSPI;database=mydatabasename;server=myservername";
            SqlConnection conSql = new SqlConnection(strCmdSqlCon);

            // Using data connection binding
            // DataConnection dcSqlCon = new DataConnection("Northwind", "CustInfo",
            // conSql);

            // Using data table binding
            SqlDataAdapter dAdaptSql = new SqlDataAdapter();
            dAdaptSql.TableMappings.Add("Table", "CustInfo");
            SqlCommand myCommand = new SqlCommand("SELECT * FROM CustInfo", conSql);
            myCommand.CommandType = CommandType.Text;
            dAdaptSql.SelectCommand = myCommand;
            DataSet ds = new DataSet("Northwind");
            TypedDataTable tdtCustInfo = new TypedDataTable(ds.Tables["CustInfo"]);


            factsHandleOut = tdtCustInfo;
            factsHandleOut = factsHandleIn;
          return factsHandleOut;

4.2. Conditions

After creating the vocabulary and publishing it to the rule store, the business rule creator can now create the business rules constituting the business policies. The creation of the business rules constitutes creating a set of conditions and actions for each rule.

A condition is simply a Boolean expression that consists of one or more predicates applied to facts. "Predicates can be combined with the logical connectives AND, OR, and NOT to form a logical expression that can be potentially quite large, but will always evaluate to either true or false" .

A set of predefined predicates are available in the Business Rules Framework:

  • After: Tests whether a date/time fact happens after another date/time fact

  • Before: Tests whether a date/time fact happens before another date/time fact

  • Between: Tests whether a date/time fact is in the range between two other date/time facts

  • Exists: Tests for the existence of an XML node within an XML document[]

    [] Although the predicate is called Exists, it will only check whether a given node is empty. If the node does not exist in the XML document, an exception will be thrown and the processing will stop.

  • Match: Tests whether the specified text fact contains a substring that matches a specified regular expression or another fact

  • Range: Tests whether a value is within a range defined by the lower-bound value (inclusive) and upper-bound value (inclusive)

  • Equal: The equality relational operator

  • GreaterThan: The greater than relational operator

  • GreaterThanEqual: The greater than or equal relational operator

  • LessThan: The less than relational operator

  • LessThanEqual: The less than or equal relational operator

  • NotEqual: The not equal to relational operator

4.3. Actions

Actions are the functional consequences of condition evaluation. If a rule condition is met, a corresponding action or multiple actions will be initiated. Actions can result in more rules being evaluated and trigger a chain effect. They are represented in the Business Rules Frame-work by invoking methods or setting properties on objects, or by performing set operations on XML documents or database tables. The Business Rules Framework provides a set of pre-defined functions that can be used in actions:

  • Assert: Adds a new fact to the current rule engine instance.


To assert a .NET object from within a rule, you can add the built-in Assert function as a rule action. The rule engine has a CreateObject function, but it is not displayed explicitly with the rest of the functions in the Facts Explorer window in the Business Rule Composer. By simply dragging the constructor method of the object you wish to create from the .NET Class view of the Facts Explorer to the action pane, the Business Rule Composer will translate the constructor method into a CreateObject call in the rule definition (Moons, 2005).

  • Update: Refreshes the specified fact in the current rule engine instance. If this fact is used in business rule conditions in the current policy, this will result in those rules being reevaluated. Rules that use the fact being updated in their actions will not be reevaluated and their actions will remain on the agenda.

A rule with an action that updates the value of a fact being used in its condition evaluation might result in a cyclical valuation loop, if the value used to update the fact always results in the condition being evaluated to true. By default, the Business Rule Engine will cycle through 2⁁32 loops before it exits the match–conflict resolution–action cycle . This value is a configurable property per policy version.

  • Retract: Removes the specified fact from the current rule engine instance.

  • RetractByType: Removes all existing facts of the specified fact type from the current rule engine instance.

  • Clear: Clears all facts and rule firings from the current rule engine instance.

  • Halt: Halts the current rule engine execution and optionally clears all rule firings. The facts remain unaffected so that values are returned.

  • Executor: Returns a reference to the current rule engine instance of type IRuleSetExecutor.

  • FindAll: Returns a string containing all substrings that match a specified regular expression in the specified text.

  • FindFirst: Returns a string containing the first substring that matches a specified regular expression in the specified text.

  • Add: Adds two numeric values.

  • Subtract: Subtracts two numeric values.

  • Multiply: Multiplies two numeric values.

  • Divide: Divides two numeric values.

  • Power: Returns the result of a number raised to a power.

  • Remainder: Returns the remainder after a number is divided by a divisor.

  • Year: Returns the year component of the specified date/time fact, a value in the range 1 to 9999.

  • Month: Returns the month component from the specified date/time fact, a number from 1 to 12.

  • Day: Returns the day of the month component from the specified date/time fact, a number from 1 to 31.

  • Hour: Returns the hour component from the specified date/time fact, a number from 0 (12:00 a.m.) to 23 (11:00 p.m.).

  • Minute: Returns the minute component from the specified date/time fact, a number from 0 to 59.

  • Second: Returns the second component from the specified date/time fact, a number from 0 to 59.

  • TimeOfDay: Returns the time component from the specified date/time fact.

  • DayOfWeek: Returns the day of the week from the specified date/time fact, a number from 0 (Sunday) to 6 (Saturday).

8.4.4. Rules and Priorities

The BRE implements the RETE algorithm. By default the execution of rule actions is nondeterministic. The engine evaluates all rules in the policy and creates an agenda of actions for rules with valid conditions to be executed. The execution of actions on the agenda might result in condition reevaluation or more conditions being evaluated, if those actions update or assert new facts. With all rules having the same priority, there is no guaranteed order of execution for the actions on the agenda. To guarantee an order of execution, you need to resort to using rule priorities.

The default priority for all rules is zero. Priority for execution is set on each individual rule. The priority is a positive or negative integer value, with larger numbers having higher priority. Actions added to the agenda for rules with valid conditions are executed in order from highest priority to lowest priority.

To see how priority affects the execution order of rules, take a look at the following example from the BizTalk Server 2009 documentation (Microsoft, 2009):

Rule1 (priority = 0)
IF Fact1 == 1
THEN Discount = 10%

Rule2 (priority = 10)
IF Fact1 > 0
THEN Discount = 15%

Although the conditions for both rules have been met, Rule2, having the higher priority, is executed first. The action for Rule1 is executed last, and so the final discount is 10%, as demonstrated here:

Working MemoryAgenda
Fact1 (value=1)Rule2 Discount = 15%
 Rule1 Discount = 10%
Other -----------------
- Microsoft Dynamics CRM 4 : Scribe Integration - Scribe Insight Architecture
- Microsoft Dynamics CRM 4 : Scribe Integration - Integration Options
- Maintaining Dynamics GP : Safeguarding data by Backing Up everything
- Maintaining Dynamics GP : Improving stability by Managing Dictionaries
- Client Access to Exchange Server 2007 : Using Cached Exchange Mode for Offline Functionality
- Client Access to Exchange Server 2007 : Using Outlook 2007 Collaboratively (part 3) - Using Group Schedules
- Client Access to Exchange Server 2007 : Using Outlook 2007 Collaboratively (part 2) - Sharing Information with Users Outside the Company
- Client Access to Exchange Server 2007 : Using Outlook 2007 Collaboratively (part 1)
- Windows Server 2003 on HP ProLiant Servers : The Physical Design and Developing the Pilot - Time Services (part 2) - Domain Time Hierarchy
- Windows Server 2003 on HP ProLiant Servers : The Physical Design and Developing the Pilot - Time Services (part 1) - Time Services Role in Authentication
Top 10 video Game
-   Renoir [PS4/XOne/PC] Kickstarter Trailer
-   Poly Bridge [PC] Early Access Trailer
-   Renoir [PS4/XOne/PC] Gameplay Explanation Trailer
-   Renoir [PS4/XOne/PC] More About Trailer
-   King's Quest: A Knight to Remember [PS3/PS4/X360/XOne/PC] Complete Collection Trailer
-   Samurai Warriors Chronicles 3 | Announcement Trailer
-   FIFA 16 | No Touch Dribbling with Lionel Messi
-   Why We're Cautiously Optimistic For The Final Fantasy VII Remake
-   Civilization: Beyond Earth – Rising Tide [PC] E3 Gameplay Walkthrough
-   Why We're Excited For the FFVII Remake
-   Mortal Kombat X | Predator Brutality
-   Mortal Kombat X | Predator Fatality
-   Poly Bridge [PC] Early Access Trailer
-   Silence: The Whispered World 2 [PS4/XOne/PC] Cinematic Trailer
-   Devilian [PC] Debut Trailer
Popular tags
Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 windows Phone 7 windows Phone 8
programming4us programming4us
Popular keywords
HOW TO Swimlane in Visio Visio sort key Pen and Touch Creating groups in Windows Server Raid in Windows Server Exchange 2010 maintenance Exchange server mail enabled groups Debugging Tools Collaborating
programming4us programming4us
PS4 game trailer XBox One game trailer
WiiU game trailer 3ds game trailer
Trailer game
Heroes Charge
Windows Vista
Windows 7
Windows Azure
Windows Server
Game Trailer