Business Rules in BizTalk Server

Now that you are comparatively well versed with the BizTalk Server 2004, we lead you to understand how the Business Rules Engine in BizTalk Server empowers the business and the business rules

Wednesday, March 08, 2006

Print

Comment

Email

Digg

Del.icio.us

Reddit

Twitter

One of the many compelling reasons to embrace the BizTalk Server 2004 is, of course, the Business Rules Engine. The first article of this series (EAI with BizTalk Server 2004, page 20, December 2005) did a decent job of introducing you to all the BizTalk technologies and lingos. Now with this one, let's take a dive in the waters and explore further this interesting product from the Microsoft Server family. Business Rules are the decision maker points in a process that compare factual data and take decisions in a business process. Traditionally, these business rules have always been a part of the procedural or object implementation. 

The business rules, so implemented, have a characteristic of being opaque to the users. Business analysts/knowledge workers responsible for maintaining the business processes don't have easy access to these rules. Being embedded in the code, it often becomes difficult to change these rules. In several instances, business revolves around the old rules despite the need for change only because they do not wish to touch the working solution.

Moreover, from the programming perspective, it is easy to implement simple rules. However, as the number of variables and the evaluations increase, it becomes increasingly complex to develop and maintain the solution. BizTalk 2004 recognized these inefficiencies and tried to empower the business analyst with the ability to configure the business rules. The entire concept revolves around separating the rules from the actual implementation logic. Isolating the business rules allows the business processes to be agile and flexible to external changes. Publishing these rules as services extends the agility towards the architecture while embracing the Service oriented concepts.

The vocabulary can be defined from any constant, a .net class, xml document or even a database table or column

The Business Rules Engine is a stand alone product that is installed along with the BizTalk 2004 product suite. It also exposes a set of .NET API, thus, extending this flexibility to .NET applications as well.

The business rules framework deals with facts, and facts represent the real world data. The Rules Engine maintains a set of rules clubbed together as a policy to deal with these facts. In addition to the information from these facts, it can also interact with information from SQL Server or even .NET components to assist them in making the decision.

As we go through this article, we will explore in detail, the various parts like vocabularies, conditions, actions and other things that help form a complete rules solution. We will also take a glance at various components of the Business Rules suite such as the Rules composer, Rules Deployment Wizard and the engine that forms the complete framework.

The elements of rules
As discussed earlier, we will evaluate the rules based on facts. The facts here are necessarily the real world data that will add business value when the facts assist in making decisions.

These facts can be acquired from a database, an XML message or even a .NET component. To interact with these facts in a user-friendly manner, the framework introduces us to vocabularies.

Vocabularies wrap the facts in nice, easy to understand names. The vocabulary, thus, makes the business rules easier to read, understand and even share the business terminology.

To form a rule, a fact needs to be evaluated with a condition. Comparing with a real world example, to check if the Purchase Order amount exceeds $25000, the PO amount fact needs to be evaluated against the constant value of $25,000. Based on the result of this condition, one or more actions can be triggered. In this case, we might mark the message with a flag saying that it will require an approval from the purchase manager.

The vocabulary can be defined from any constant, a .net class, xml document or even a database table or column

A condition applies one or more predicates to the facts. Hence, the resulting expression always evaluates in true or false. It can typically be like whether the amount is greater than $25,000 or something more complex like whether the request is generated by assistant manager, has undergone any review sessions and whether the amount is greater than $2,500. Such expressions using the facts and the predicates always evaluate in either true or false. In our example the predicate will be 'Greater than'. Therefore, the above condition will always be evaluated to either true or false.

The expressions are converted to potentially complex ones by making use of various other connectives like AND, OR and NOT. However, due to the inherent behavior that we saw in our examples these rules will always evaluate to either true or false.

Based on the outcome of the rules, we can execute 'actions' that determine our business process. These actions can include asserts or updates to the facts. As we saw in the example, we can update the ApprovalRequired field (obviously expressed as a fact) to indicate in our business process that an approval is required for this purchase order.

Several rules like this one can be clubbed together to form a policy. This in fact is very much synonymous to the terms that we normally use outside the Business Rules. As an example, when we talk about a company policy regarding remunerations, we are actually referring to a set of rules that are laid by the company with respect to the remunerations.

The policies in the Rules Engine, thus, form the smallest unit for which we can maintain versions. A policy is created, tested and subsequently deployed on the BizTalk Server. It can contain any number of rules resulting in complexities of various degrees. The policy, when deployed, is stored in the Rules Engine database (again maintained in the SQL Server).  Thus, all the related rules can be clubbed together in a single policy and can be used from with a BizTalk Orchestration or even a .NET application.

What helps make the rules?
As we discussed earlier, the rules engine is a standalone product. It consists of several modules that help in composing, testing, deploying and executing the rules. The most important modules that complete the rules engine are – Business Rules Composer, Rules Deployment Wizard and the Runtime executing engine.

The vocabulary can be defined from any constant, a .net class, xml document or even a database table or column

Although it's pretty obvious from the names, still, let's take a glimpse at the things that they make simpler and more importantly, how they do so. The Business Rules Composer, as the name suggests, helps us compose the rules. It allows creating the vocabulary definitions from the facts as well as the creation of conditions, actions and the policies that group them together. The facts can be created from various sources including XML schemas, database artifacts and .NET components.

The composer exposes its best benefit with a powerful user interface that allows the business analysts to modify the business rules without much of technicalities. The composer provides a very simple and efficient interface to create complex rules from defined facts.  Along with the compositions, the Rules Composer offers a flexible interface for testing the policies before they are deployed. Versioning capabilities are built-in into the composer to track the policies as they are modified over a period of time.

The Rules Deployment wizard allows easy deployment of the rules while ensuring that the new rules being deployed are available to the consumers in near real time. This capability significantly reduces the overhead of redeveloping, retesting and redeploying the applications.

The Runtime Rules engine executes the published rules. These rules can be executed using a .NET application or a BizTalk Orchestration. To use them in a BizTalk orchestration, we can make use of any shape that supports .NET expressions like the expression shape or decision shape. However, the rules are most commonly used with the Call Rules shape. The Business Rules suite comes with an easy-to-use deployment tool-the Rules Engine Deployment Wizard. The Rules Engine structures the policies and vocabularies in such a way that they can be expressed in terms of simple XML documents. This makes it very easy to use the policies across different BizTalk Servers. However, to consume or use the policies, they have to be published in the BizTalk Rules Engine Database. Once published to the database, they can be consumed by the .NET or BizTalk solutions. The BizTalk Rules Engine Deployment Wizard helps in various ways. It allows us to publish these artifacts from XML files to the database, or even create the XML files from the published policies and vocabularies, thus, allowing easy exchange of these artifacts between the servers.

What's next?
Now that we are familiar with all the basics, in the forthcoming articles we will delve more  to explore how we can build this agility into our .NET and BizTalk solutions.

Sanket Bakshi, Sr Technical Associate, Mahindra British Telecom