Business Rule Engine (BRE) | BizTalk | Part-1

The Business Rules Framework is a Microsoft .NET-compliant class library. It provides an efficient inference engine that can link highly readable, declarative, semantically rich rules to any business objects (.NET components), XML documents, or database tables. 

Application developers can build business rules by constructing rules from small building blocks of business logic (small rule sets) that operate on information (facts) contained in .NET objects, database tables, and XML documents. This design pattern promotes code reuse, design simplicity, and modularity of business logic. 

BRE uses Rete algorithm; a highly efficient algorithm for implementing business rule engines. BRE can be invoked from Orchestration Process or from a C# method; here, I would cover those as well. 

Overview of BRE

• Business Rule Composer: GUI, this helps us to create, manage, and test policies. 
• Policy: In a Policy, we can define rules and test and execute the policy. Once a policy is defined, we can either publish, deploy or un-deploy it. We can maintain multiple versions of a policy. 
• Rules: Rules are the actual representation of business rules inside a policy. It contains data (facts), predicates, and actions. We can set the priority on each rule. 
• Facts: Data that BRE operates against. 
• Fact Source: Fact sources can be XML documents, database, or .NET objects. 

Functions: 

• Assert: Assert 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. 
• Update: Indicates that a certain fact should be reevaluated, causing all rules using the fact to be reevaluated. 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. 
• Halt: Halt function to halts the current rule engine execution. 

Let’s start by creating a simple policy for performing a lookup on Product Code based on the Product Name received from the source system and we would test and integrate the policy inside a process. 

Open the Business Rule Composer by selecting Start->Programs->Microsoft BizTalk Server 2013->Business Rule Composer. 

Within the Policy Explorer, right-click the Policies node, and click Add New Policy. Give the policy name as BizTalkDJ.ProductCodeLookUp. 
By default, version 1.0 of the policy is created. 
Right-click the version, and choose Save. 
Right-click Version 1.0, and then click AddNewRule and rename it to Title. 

On the right pane of the rule, in the Condition pane (top) right-click choose Conditions, click on Predicates and then choose the applicable predicate (equal)

Now, in the Facts Explorer window, click the XML Schemas tab. 
Right-click Schemas, click Browse, and then select the OrderRequest.xsd file, browse and drag the ProductName node from the Facts Explorer window to argument1 in the Condition pane and in the Condition pane, click arugument2, provide the evaluating data (Title). On completing the condition in then action pane, drag the ProductCode node from the Facts Explorer window to the action pane at the bottom-right side of Business Rule Composer. Click <Enter a value> and then type look up code (TO). 

A policy can have one or more rules. You will be adding another rule, repeat these steps to create the rules for Escrow and Signing Products. And we can prioritize execution of rules by specifying the Priority property on rules in Business Rule Composer. For example, if you click the Title node in the Policy Explorer window, you can see the Priority property in the Properties window. The larger the number, the higher the rule priority. 

Test Policy 
We can unit test the policy by right-clicking on Version 1.0, and then choose Test Policy, in a Test Select Facts window, under XMLDocuments node, select OrderRequest, and then click on Add Instance to choose the input request to your policy.

Click Test. 

Invoking Policy in Orchestration

You can invoke a policy from an orchestration in one of the following ways: 
By using the Call Rules shape 

By using the Expression shape, and programmatically invoking the rule engine to execute the policy (Policy.Execute method) 

Using the Call Rules shape is the most common way and also the recommended way to invoke a policy from an orchestration. This is a simple process, where we would receive an order request; then execute the BRE policy to enrich the order request before sending to destination system. The orchestration should look like the following figure. 

Deploy and configure the application, then process order request and see the enriched output order request. 

Create Vocabulary
In the Facts Explorer window, click the Vocabularies tab. Right-click Vocabularies, click Add New Vocabulary, and then type BREConcept.OrderRequest as the name for the vocabulary. 

Right-click Version 1.0(not saved) in BREConcept.OrderRequest, and then click Add New Definition. 
In the Vocabulary Definition Wizard, select XML Document Element or Attribute, and then click Next. For the Definition name, type GetProductName. 
Click Browse, and select the OrderRequest.xsd file, in the Select Binding dialog box, expand OrderRequest and choose ProductName. Then specify the operation as Get. 

Similarly, repeat the steps to create vocabulary for ProductCode but this time, we would choose operation as Set. (You can play around the xpath), here I have modified the xpath as show in the table.

Original X-path Binding 

X-path Selector: 
/*[local-name()='OrderRequest' and namespace-uri()=‘‘]/*[local-name()='ProductList' and namespace-uri()=‘‘]/ *[local-name()='Product' and namespace-uri()=‘‘] 

X-path Field: 
*[local-name()='ProductCode' and namespace-uri()=‘‘] 

Modified X-path Binding 
X-path Selector: 
/*[local-name()='OrderRequest' and namespace-uri()=‘‘]/*[local-name()='ProductList' and namespace-uri()=‘‘]/ *[local-name()='Product' and namespace-uri()=‘‘]/*[local-name()='ProductCode' and namespace-uri()=‘‘] 

X-path Field: 

We can have multiple versions of a vocabulary and only the published vocabulary can be used in the policy. Both Policy and vocabulary can be exported/imported. 

Conclusion: 
In this article, I covered how to develop and integrate BRE policies with BizTalk Process. Now you can apply this solution to your own business scenario. 

The video demonstration is available on the Youtube, here is the embedded video.