Application Management

Digg This!

Imagine that you have built a large enterprise application after carrying out extensive requirement studies. Just before the delivery, the client informs you that some of the business rules need to be changed. What do you do? Modify the business objects? Change the stored procedures? Depending on how you incorporated business logic in your solution, the updates may take several days or even weeks to apply. What if the business rules change again? Wouldn't it be nice if you could decouple the business rules from your application code so that you could maintain them separately?

Enter the world of rules-based applications. Rules-based applications address many of the challenges posed by business rules changes in organizations. Rules-based applications can provide a near real time responsiveness to the business rules changes and can greatly reduce the total cost of application ownership. With the comprehensive Business Rules Framework shipping with Microsoft BizTalk 2004, .NET developers can now build rules-based applications in the familiar Visual Studio.NET development environment. This article provides an overview of rules-based design and explains how you can build rules-based applications using the BizTalk 2004 Business Rules Framework. This article is based on the features available in the beta release of BizTalk Server 2004.

Handling Business Rules - The Traditional Way
While developing enterprise applications, you might have handled business rules in several ways. You may have encapsulated the business rules in business objects, or you may have implemented them in database stored procedures or triggers. In some situations, you would perhaps have maintained business configuration information in XML files or in database tables. Each of these approaches has a varying degree of success depending on the size and complexity of your application. For simple applications, you might have found that one or more of these approaches were sufficient. However, if your application is a large-scale enterprise application, these approaches have only limited success in the maintainability of the business rules.None of these approaches provide the flexibility for business workers to define or maintain the business rulesafter the application is deployed. With the traditional approach, for every change in the business rule or introduction of a new business rule, developers need to be involved.

Advantage of Rules-Based Applications
In rules-based applications, you define business rules independent of application code. The application need not be aware of the rule conditions or actions to be performed as a result of a matching rule condition. In rules-based applications, the rule engine matches the facts against the rules and executes appropriate actions. Your application only needs to supply the data required to evaluate the rule conditions. When the business rules change, you just need to modify them in the rule repository. The rule engine automatically accesses the new version of the rules at run time.

Another big advantage of rules-based design is that you can make the rules visible to the business workers and allow them to modify or define new rules. The importance of making the rules visible to the business users won't be evident until you analyze the complexity of the rules an organization follows for running their business. Often, no rule exists in isolation. Many rules are inter-linked and are not immediately obvious, even to the eyes of business experts. For example, a simple "vacation policy" may have an impact on the annual production of the company. A change of address of a customer may have an impact on the discounts offered. With greater flexibility, maintainability, and rules visibility, rules-based applications can significantly reduce the total cost of application ownership for enterprises.

BizTalk 2004 Business Rules Framework
The main components of the Business Rules Framework are:

1.  Business rules authoring tools: The framework comes with object models for composing and publishing business rules. You can define the business rules using the API or more conveniently using the Business Rules Composer. The Business Rules Composer is your one-stop shop for creating and maintaining business rules. The visual interface makes it easy for developers and business workers to define and publish new rules or release a new version of an existing rule.

2.  Rule store: Typically you will use SQL Server as a rule store but you have the option of storing the rules in an XML file. You can export or import business rules from file store to SQL Server store and vice versa.

3.  Rule engine: Rule Engine is the heart of the Business Rules Framework. The rule engine evaluates rule conditions and executes actions as a result of the evaluation.

The BizTalk 2004 Business Rules Framework contains other elements such as a rule engine update service, a fact retriever, and so on. The general process of creating rules and policies using the BizTalk Server 2004 Business Rules Framework is shown in Figure 1.

Identifying and Defining Business Rules
Every organization has business rules that control the behavior of the business process.Once you get the software requirements document, you can identify the business rules by carefully isolating sentences that contain conditions and actions. The following is an example of a business rule:

• If the applicant's annual income is greater than 10% of the loan applied, approve the loan application.

At run time, the rule engine evaluates the condition based on the facts supplied. If the condition evaluates to true, the action specified in the rule is executed by the rule engine. If you want to take some action when the condition evaluates to false, you need to define a separate rule. This looks strange, since every time you want to create a rule, you end up creating two rules, one for the positive condition and another for the negative condition. But this is the way the rules framework is currently designed. For the above rule example, you can define the negation rule as follows:

• If the applicant's annual income is less than 10% of the loan applied, reject the loan application.

  A rule can have more than one condition and conditions evaluated together can result in some action. Thus the following is a valid rule:

• If the applicant's annual income is greater than 10% of the loan applied and his age is greater than 25, approve the loan application.

  A rule can have more than one action:

• If the applicant's annual income is greater than 10% of the loan applied and his age is greater than 25, approve the loan application and send notification of the approval to the applicant.

Once you start defining the business rules, you will soon find that even an elementary business process requires many rules. Therefore, it makes sense to group the related rules for processing them together. Some rule engine vendors call the rule grouping a rule set. Microsoft has given a nice real-world name "Policy" for grouping related rules. Policy is not optional in the Microsoft business rules framework. Even if you have a single rule, it should be embedded within a policy. Version controlling happens at the policy level and not at the rule level.

Facts That Rules Can Use
In order to evaluate the conditions, the rules need data. For example, to evaluate the condition in the following rule, the rule engine needs "applicant's annual income" and "loan applied":

• If the applicant's annual income is greater than or equal to the eligible percentage of the loan applied, reject the loan application.

In BizTalk 2004 Business Rules Framework terminology, these kinds of data are called "facts." A "fact" is a piece of data the rule engine uses to evaluate the rule condition. The framework allows you to represent the facts in the form of .NET objects or their members, XML elements or attributes, or column values in a database table. If the facts change frequently, your application can supply these facts at run time. Such facts are called "short term facts." The rule engine will use the short term facts for a single execution cycle only. Alternatively, if a certain fact does not change frequently, you can implement a fact retriever so that the policy object automatically retrieves the facts at run time. Such facts are called "long term facts" and the rule engine will use them for several execution cycles once loaded in memory. You can create a fact retriever class by implementing the IFactRetriever interface.

Building Vocabularies of Facts and Definitions
How can the rule engine interpret "applicant's annual income," "eligible percentage," and "loan applied" in the business rule statement? Facts can come from different data sources such as an XML file, a .NET object, or a database table. The "applicant's annual income" and "loan applied" may come from an XML file or from a database table. There may be situations when many business rules use the same data for evaluating different rule conditions. Wouldn't it be nice if you could define standard terms for each piece of data and bind them with appropriate data source so that the terminology and usage are consistent across many rules? You don't want to call a piece of data "loan applied" in one rule and, say, "applicant's loan amount" in another rule. With the Business Rules Composer tool in BizTalk Server 2004, you can easily define fact definitions for your applications and bind them with the data source as shown in Figure 2.

The vocabulary definition wizard makes creating facts and definitions an easy task. To make the task of defining facts easier, the Business Rules Composer comes with prebuilt "functions" and "predicates" vocabularies. The functions vocabulary consists of several commonly used arithmetic operations such as add, multiply, divide, subtract, day, month, etc. You will typically use them while defining actions. The predicates vocabulary consists of several relational predicates such as "Equal", "GreaterThan", "LessThan", etc. You will typically use them while defining conditions for your business rules. BizTalk requires you to publish each vocabulary before using it in your rules. BizTalk doesn't allow you to delete or edit published vocabularies. This is to prevent other users from accidentally deleting or changing a vocabulary that you have already used in one or more rules.

Composing Rules and Policies
Once you publish the facts for your application, you can compose the business policies and rules. Creating rules using the Business Rules Composer is as simple as dragging and dropping the vocabulary items and setting their values as shown in Figure 3.

As the rules can exist only within a policy, you need to first create a policy version before adding rules. For each rule, you can add conditions by using appropriate predicates and functions. You can use logical "AND", "OR," "NOT," or a combination of them for each rule. Common actions for the rules are updating an element in an XML document, setting a field value in the database table, or setting a property in a .NET object. Though you can have many conditions and actions defined for each business rule, it's better to keep the rules simple so that they are more easily maintained. If you find that a rule has too many conditions, try splitting it into simpler rules with fewer conditions.

Prioritizing Rules
An important point to note is that there's no way you can directly invoke a rule. You invoke only the policy from your application, and the rule engine evaluates the rules within the policy and executes the actions specified in the rules. A policy can have several rules. When the rule engine executes the actions of a rule, new facts may be asserted. Facts asserted by one rule may be used by another rule in the same policy. You can set rule priorities so that they're evaluated in the preferred order. The rule engine will evaluate the rules with the higher priority first and executes their actions before evaluating rules with lower priority. This policy evaluation and execution process is shown in Figure 4.

At run time, the policy being executed will go through three stages: the matching stage, the conflict resolution stage, and the action stage. During the matching stage, the rule engine matches the facts in the working memory with the rule conditions. The rule engine evaluates the rule conditions with the facts available in the working memory. Rules that have matching conditions and evaluate to true are added to the agenda for execution. In the conflict resolution stage, the rule engine examines the rules in the agenda to decide which rule to execute next. When there's more than one rule in the agenda, the rule engine selects the rule with the highest priority for execution. You can set the rule priority (0, 1, 2...) while composing the rules. The larger the number, the higher is the priority. In case you don't want to set any priority, you can leave the default priority, "0". If more than one rule has the same priority number, the rule engine may select any of these rules for execution. In the action stage, the action specified in the selected rule is executed. One important point you should note is that rules are never executed in parallel. The rule engine always executes the rules one by one. Once a rule is executed, that rule is never added to the agenda again during the current policy execution. This is to avoid never-ending loops and also the undesirable effects of executing the actions of a rule more than once.

Testing Policies
It's important to thoroughly test your policies before publishing and deploying them. You can test your policies programmatically by invoking the PolicyTester object or, more conveniently, using the Business Rules Composer. The Business Rules Composer provides facilities for testing the policies with sample facts. It provides a trace output for the policy tested. The trace provides useful information such as fact activities, condition evaluation, agenda update, and rules firings. Part of a sample trace output is shown in Figure 5.

The fact activities section in the trace output indicates whether a fact is being asserted or retracted. The condition evaluation section lists the expressions evaluated and their results. The agenda indicates the rules that are added to the agenda for possible execution. The rule firing section indicates which rule has been executed.

Deploying Policies and Vocabularies
After testing the policies, the next step is to publish them so that they are ready for deployment. Publishing and deploying are two different steps. After publishing, your policies are not editable by anyone. The policies are not available to your applications until you deploy them in the production rule store. The approving authorities in the organization can have a final review before allowing the policies to be deployed. Deploying involves taking the published policies and deploying them in a rule store. During your development stage, your temporary rule store can be an XML file or a database. If your production rule store is different, you need to import the published policy from the file to database or export the same from the database to XML file. The next step is to deploy the policies.rule engine deployment. The wizard makes deploying and undeploying very easy (see Figure 6).

After deploying the policies and the relevant vocabularies in the production rule store, the policies are ready for use in your application.

Integrating Policies With Your Application
You can invoke policies from BizTalk orchestration or from any .NET application. Integrating policies with BizTalk orchestration or your .NET application essentially involves the following steps:

1. Add a reference to Microsoft.RuleEngine.dll in your application
2. Create policy object
3. Execute the policy by supplying the short term facts

Here's a sample of C# code that invokes a policy from a .NET application:

Microsoft.RuleEngine.Policy Policy;
Policy = new Microsoft.RuleEngine.Policy("MyPolicy");
Policy.Execute(MyShortTermFact);
Policy.Dispose();

In the above code, it's assumed that you have already declared and created a short term fact object "MyShortTermFact." Your short term fact can be an XML document or any .NET object that's used to match the rule conditions. In case of BizTalk orchestration, you will declare the variables for policy and short term fact objects in the "Variables Window" in the orchestration designer. In BizTalk orchestration, you need to place the code for executing the policy (such as the one above) in the "Expression Editor." You supply the short term facts as a parameter in the Execute() method of the policy object. If you have more than one short term fact, you can supply them in an object array. The Policy.Execute() method has overloads to accept a single object or an object array. The policy object retrieves the long term facts by calling the fact retriever object you have implemented and associated with the policy. Please note that the action to be carried out as a result of policy execution is not specified in the application code. You specify the action for each rule while composing the business rules. The application just knows which policy to invoke and supplies the short term facts, if any, at run time. This provides the flexibility to maintain the rules and the actions outside the application code. If you update your policy and deploy a new version of the policy, the rule engine loads the latest version of the policy at run time. To understand more about integrating policies with .NET application/BizTalk orchestration, you may want to explore the rules-based application samples shipping with the BizTalk Server 2004 SDK.

Deciding When to Use a Rules-Based Approach
To build rules-based applications, you need a standard framework such as the BizTalk Server 2004 Rules Framework. If you're building an enterprise application that has many business rules that are likely to change, a rules-based approach certainly would be your preferred option. The fact that the Microsoft Rule Engine ships with BizTalk Server 2004 indicates that Microsoft is clearly targeting the enterprise segment. If you're using BizTalk Server for integrating business processes within and outside your organization, combining BizTalk Orchestration with the Business Rules Framework will make it easy for you to incorporate business rules between the business processes. If your application is a simple desktop application with few business rules, using a rule engine may not be a viable option considering the additional cost of the rule engine. In such cases, you can consider traditional approaches such as XML configuration files or database files for maintaining business rules.

Conclusion
To be competitive in the market, organizations often need to quickly adjust their business strategies based on the market trends. Today, being competitive is the key to survival. The need of the hour is a solution that can cope with business changes in real time. With the BizTalk Server 2004 Business Rules Framework, for the first time, .NET developers are getting the opportunity to build rules-based applications in the Visual Studio.NET environment. The Microsoft Business Rules Framework provides easy to use tools for creating rules-based applications. Given the needs of today's businesses, rules-based applications may soon become the norm rather than the exception.