Consider the following scenario. In Microsoft BizTalk Server 2004 and in Microsoft BizTalk Server 2006, you have an orchestration that calls a Call Rules shape. The Call Rules shape uses a business policy that evaluates a condition or fires an action that makes a connection to the database. When this orchestration runs, you find that the condition is not evaluated or the action of the rule is not fired.

Note When you click Test Policy in the Business Rules Composer to test the policy, the condition is evaluated or the action is fired successfully.

When you click Test Policy in the Business Rules Composer, a DataConnection object is automatically built for you. Additionally, the database is updated after execution finishes. However, when you call the same policy from an orchestration by using the Call Rules shape, no DataConnection object is passed to the policy.

Note If you build the rules by using database objects where “database binding type”= “Data table/data row”, the composer executes a SELECT * FROM TABLE command and asserts the resulting rows as a TypedDataTable class when the policy is tested. In the following instructions, you must create a TypedDataTable in the same way and use it instead of a DataConnection object, instead of creating a DataConnection object. For more information, see the BizTalk Business Rules documentation.

To resolve this problem, use one of the following methods:

Create a DataConnection object

Create a DataConnection object in the orchestration, and pass the DataConnection object into the Call Rules shape with the document and any other objects that you pass in. If the policy changes the database data, you must commit the transaction after the policy executes. For an example of how to do this, see the sample code in the "More Information" section.

Add a FactRetriever object

Add a FactRetriever object to the policy. This object is called when a policy is fetched and can be used to create and to assert the DataConnection object. In BizTalk Server 2006, a second interface called IFactRemover can be defined on the same object and is called when the policy is disposed. Therefore, you can commit the database changes when the policy has finished executing. The advantage of using the second resolution is that the FactRetriever object is set up when the policy is created. Orchestrations that use the policy do not have to be aware that a database is used. The drawback is that the database must be known when the policy is created, and you cannot use a different database at execution time.

The following example shows the steps and the code that you can use to create a DataConnection object in the orchestration and pass the DataConnection object into the Call Rules shape:

1. Create the following variables.

   DataCon of type Microsoft.RuleEngine.DataConnection
   SqlCon of type System.Data.SqlClient.SqlConnection
   SqlTran of type System.Data.SqlClient.SqlTransaction
   

   Note DataCon, SqlCon, and SqlTran are examples of variable names. You may use different names.
2. In an Expression shape before the Call Rules shape, add code that is similar to the following.

   SqlCon.ConnectionString = "Data Source=(local);Initial Catalog=Test;Integrated Security=SSPI";
   SqlCon.Open();
   SqlTran = SqlCon.BeginTransaction();
   DataCon = new Microsoft.RuleEngine.DataConnection("test", "FlagTable", SqlCon, SqlTran); 

3. In an Expression shape after the Call Rules shape, add the following code.

   DataCon.Update(); 
   SqlTran.Commit();
   

To create a FactRetriever object, see the Business Rules sample programs that are installed with BizTalk Server. For example, see the "Loans Processing Using Business Rules" sample.