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