http://www.developer.com/xml/article.php/3514166/BizTalk-2004-Business-Rules-Explained.htm
Have your users ever asked for an easier way to control aspects of your BizTalk Orchestration? If so, you should investigate BizTalk Business Rules. Business Rules allow you to wrap .NET objects and XML document elements in plain language for use by non-developers. Using Business Rules, a non-developer can much more clearly view the execution logic behind portions of your Orchestrations or even make small changes to portions of your Orchestration.
Business Rules Engine is a new tool in BizTalk 2004. Its development tool is an application called Business Rules Composer. When you develop Business Rules, you describe the rules using readable descriptive text and configure the rules to utilize underlying .NET objects, database information, and XML elements. When you are finished, the rules resemble bullet points in a memo rather than programming code.
The book BizTalk Server 2004 Unleashed devotes an entire chapter to Business Rules development. This article ties elements of the book and BizTalk product documentation together so you can begin building your own Business Rules. It looks at portions of a fictitious expense-approval process that performs various tests to determine the validity of the employee number before approving an expense.
Unlike their traditional "if/then" brethren, rules do not have an "else" section. Rules are grouped together in a policy. When a policy executes, .NET classes and XML documents pass into the Policy from the Orchestration. Classes and XML information loaded in the memory of an executing policy are called facts.
To summarize: Policies are groups of rules; rules contain conditions and actions; rules are developed using vocabularies, and vocabularies are user-friendly mappings to underlying .NET classes and XML elements. With this understanding of the basic terminology, you're now ready to examine the Business Rules development tool.
Figure 1. The Business Rules Composer Interface
Development is simple: right-click on the policy or vocabulary version to create a new rule or policy. Let's delve more deeply into development, beginning with vocabulary.
Figure 2. The Vocabulary Definition Wizard
Figure 3 shows the XML Document Element options.
Figure 3. The XML Document Element Options
Figure 4 shows the "Database Table Option" wizard.
Figure 4. The "Database Table Option" Wizard
After selecting the .NET Class option, you are prompted to select the assembly containing the class. You are restricted to Assemblies loaded in the Global Assembly Cache (GAC), so any Assembly you use must be signed and loaded in the GAC. After selecting the .NET class, class method, or property, the dialog shown in Figure 5 allows you to add more descriptive text to method arguments, which are displayed when the .NET class is used in Rule Definition.
Figure 5. Add More Descriptive Text to Method Arguments Figure 6. The Class MyArrayList Class
Finally, unlike other .NET components implemented in a BizTalk Orchestration, business rules classes need not be serializable.
Now that you have a vocabulary, you can begin building your policy.
Now that you know what the Rules do, you can look at how to develop rules.
As stated previously, policies are groups of rules. Rule definition works differently from vocabulary definition. Vocabulary development utilizes a wizard. Rule definition employs drag-and-drop. To define a rule, right-click on the version of the rule and select "Add New Rule". The right side of the screen will be populated with an IF (condition section) and a THEN (action section). Next, you populate the IF section by dragging-and-dropping a predicate from the predicate section on the vocabulary tab (see Figure 7).
Figure 7. Populate the If Section by Dragging-And-Dropping Figure 8. A Completed Rule
You must declare properties and methods separate from the class vocabulary definition. As you can see above, if you don't declare properties and methods separately, you reduce the natural readability of the rule. As stated previously, natural readability is one of the goals of Business Rules.
You also must enter a "Display Name" if you configure a vocabulary definition with the "Get" option. In the sample, the GetValidEmployee and the ValidEmployee vocabulary definition both map to the ValidEmpNo element. To make the Business Rule readable, both definitions must display the same name. Therefore, one of the definitions must display a name that is different from the actual name of the definition. Thus, the "Get" option requires a separate Display Name, which can be configured to match the name of the "Set" option.
The example above used the text "Valid" to assign a value to the XML element. You could have created a "Constant Values Range" vocabulary definition and used the constant in lieu of the text.
It's now time to learn how the policy you created executes.
Figure 9. "Test Policy" Dialog
Loading a .NET class is different. You must create a class called a FactCreator, which follows the IFactCreator interface in the Microsoft.RuleEngine namespace. The FactCreator class assembly must be signed and loaded in the GAC. Business Rules Composer invokes the CreateFacts method in the FactCreator. CreateFacts creates all of the appropriate objects and returns the objects as an Object array. See the example below:
After a rule is evaluated, it will not be evaluated again unless its facts are updated. In the sample code, the CheckEmployeeNumber evaluates to "false" and the rule is not fired. Subsequently, the AssignEmployeeObjectValues rule is fired and the EmployeeInfoObject is updated. When the EmployeeInfoObject is updated, the CheckEmployeeNumber rule is reevaluated, found to be "true", and the rule is fired. You can view the execution of your Business Rules in the rule engine trace. Trace is updated when you press the "Test" button. The BizTalk product documentation explains how to interpret the trace output.
You are not limited to using a BizTalk Orchestration or the Business Rules Composer to execute your policy. You can access the policy API and execute a policy programmatically.
As for debugging classes used in your executing policy, you can debug classes from Visual Studio by selecting the "Debug" Processes option and attaching to the Microsoft.RuleComposer.exe process (see Figure 10).
Figure 10. Debugging Classes from Visual Studio
This completes the introduction to vocabulary development, policy development, and policy execution. You have just one final topic to learn: deployment.
Figure 11. Rules Engine Deployment Wizard
To download the accompanying source code for this article, click here. Jeffrey Juday is a software developer with Crowe Chizek in South Bend, Indiana. He has been developing software with Microsoft tools for more than 12 years in a variety of industries. Jeff currently builds solutions using BizTalk 2004, ASP.NET, Sharepoint, and SQL Server 2000. You can reach Jeff at jjuday@crowechizek.com.
BizTalk 2004 Business Rules Explained
June 21, 2005
Terminology
First, you should learn some terminology in order to follow along with the text. In BizTalk 2004 Business Rules, a Vocabulary maps all of the .NET classes, XML elements, and database information to user-friendly readable text. (More about how to perform the mapping comes later in the article.) You use a Vocabulary when you develop a rule. A rule closely resembles an if/then statement that you would see in traditional development. The "if" part of a rule is called a condition, and the "then" part of a rule is called an action.
Business Rules Composer
Most of your business rules development will be done in the Business Rules Composer, which you access from the BizTalk 2004 menu. Business Rules Composer saves all of its data to a SQL Server database on the BizTalk 2004 database server. As Figure 1 shows, you browse policies, vocabularies, and .NET classes in the left panes and develop rules in the right pane.
Vocabulary Development
You can develop rules without building a vocabulary, but you decrease the readability of your Business Rules if you don't use a vocabulary. As stated earlier, a vocabulary maps your .NET classes, XML elements, and database information to user-friendly text. Navigating to the policy version and selecting "Add new Definition" invoke the Vocabulary Definition Wizard shown in Figure 2.
Policy Development
Before delving into rule development, reviewing what each rule in the sample does in the order that the rule executes would be helpful:
Policy Execution
When you are ready to test a policy, you right-click on it and select "Test Policy." You will be prompted with the dialog in Figure 9.
public object[] CreateFacts (RuleSetInfo ruleSetInfo)
{
objs = new object[2];
objs[0] = new Rule.Test.CheckEmployee ();
objs[1] = new Rule.TestArrayList.MyArrayList ();
return ( objs );
}
Asserting is the act of loading facts (.NET objects, XML Documents, etc.) into the memory of the executing policy. As the rules engine executes the policy, it builds something called an agenda. The rules engine scans all rules and adds any rule that can be evaluated to the agenda. A rule can be evaluated as long as all of the appropriate vocabulary definitions have been asserted. After a rule has been evaluated, it is removed from the agenda. After evaluation, if the "IF" section evaluates to "true", the action part of the rule is executed, or in Business Rules vernacular, "fired."
Deployment
To move policies and vocabularies from one server to another, you must access another tool called Rules Engine Deployment Wizard (see Figure 11).
Give Users More BizTalk Orchestration Control
If you want to give systems analysts or power users more control over areas of a BizTalk Orchestration, Business Rules might be the answer. With Business Rules you can wrap your .NET classes and XML document elements in easy-to-understand language that systems analysts and developers alike can use.
Download the Code
About the Author
