Business Rules in BizTalk Server

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