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. By 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 by 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.
First, you should learn some terminology so that you can 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.
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.
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.
Figure 1. The Business Rules Composer Interface
Vocabularies and policies are versioned and, like many other things in the BizTalk world, have a number of degrees of activation. Both vocabularies and policies must be published to make them available to Orchestrations and other parts of BizTalk. Policies have a third state called Deployed, which allows activation by an Orchestration.
Development is simple: right-click on the policy or vocabulary version to create a new rule or policy. You’ll delve more deeply into development, beginning with vocabulary.
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.
Figure 2. The Vocabulary Definition Wizard
The vocabulary definition options will change depending on the radio button selected. Look at each definition option independently, beginning with XML Document Elements.
Figure 3 shows the XML Document Element options.
Figure 3. The XML Document Element Options
As you would expect, you must supply an XML schema definition. After selecting the schema, the tool automatically fills in the XPath and the appropriate field type. Selecting the “Set” option configures the vocabulary item to be used in assignment operations. The “Get” option works a lot like the Get options in languages such as Visual Basic. Choosing it configures the item for read-only operations. (Coverage of the “Display Name” option accompanies the upcoming Rule development discussion.) Now, on to the “Database Table Option.”
Figure 4 shows the “Database Table Option” wizard.
Figure 4. The “Database Table Option” Wizard
Like the XML Document Element definition dialog, you browse to the field defining the item to which you want to map. You have two options for binding type: data table/data row and data connection. Deciding whether to select a row over a connection depends on how you are going to use the vocabulary and the number of records in the table. When the data table/data row option is used in a rule, all data will go into memory. Using a vocabulary defined as a data connection will query the underlying table. Finish the vocabulary definition with the .NET Class option.
After you select 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
There are only two real limits to the classes you can employ. The first is that classes cannot have a variable number of parameters. An easy workaround is to use an ArrayList collection or some other object collection. In the example, the vocabulary definition EmployeeInfoObjectArray is an ArrayList member variable in the class MyArrayList class. The definition appears in Figure 6.
Figure 6. The Class MyArrayList Class
The second limitation is really more of a different mindset than a limitation. Non-developers normally don’t refer to a property on an object as ObjectName.PropertyName. So, if you plan to use an object and an object’s property or method, you must declare both the object and the property separately in the vocabulary.
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.