July 30, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

BizTalk 2004 Business Rules Explained

  • June 21, 2005
  • By Jeffrey Juday
  • Send Email »
  • More Articles »

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:
  1. AssignEmployeeObjectValues runs first and always runs, because 1 equals 1 is always true. In the underlying execution of the rule, a function is called in a .NET object.
  2. CheckEmployeeNumber compares the employee number to a list of employee numbers in a database table and sets the ValidApprover to "Valid".
  3. ConfirmValidApprover performs another test to determine if the employee number is a Valid Approver. If the rule is true, ValidApprover is set to "Valid".
  4. CheckEmployeeNumber runs a second time because AssignEmployeeObjectValue performs an action to change the facts in memory.

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).


Click here for a larger image.

Figure 7. Populate the If Section by Dragging-And-Dropping

Now, you drag-and-drop vocabulary definitions into the "argument" sections in the predicate and actions. A completed Rule appears in Figure 8.


Click here for a larger image.

Figure 8. A Completed Rule

In the "IF" section of the sample above, CheckEmployeeNumber maps to the CheckEmployeeNumber method in the CheckEmployee.class inside the Rule.Test assembly. CheckEmployeeNumber accepts an ArrayList class parameter and returns a Boolean value. The EmployeeInfoObjectArray vocabulary definition maps to an ArrayList member variable inside the MyArrayList class. In the "THEN" section, ValidEmployee maps to the ValidEmpNo Element in the XML document and assigns the text "Valid" to the ValidEmpNo Element.

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.

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.


Click here for a larger image.

Figure 9. "Test Policy" Dialog

When a Policy executes from a BizTalk Orchestration, you must pass the classes and XML documents you use in the rules into the policy. Therefore, you must do the same thing when you test the policy. To load an instance of an XML document, select a document on the file system. To load a database fact, you must select a database table.

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:

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."

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).


Click here for a larger image.

Figure 10. Debugging Classes from Visual Studio

When you test the policy, the debugger will pause whenever it encounters a breakpoint.

This completes the introduction to vocabulary development, policy development, and policy execution. You have just one final topic to learn: deployment.





Page 2 of 3



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel