Talk, talk and more talk about BizTalk

Parameters not available in Call Rules shape

I had developed a simple Rule Policy in the Business Rule Composer, and was attempting to include it in an Orchestration using the Call Rules shape. The Policy was correctly Published and Deployed, and was available in the ‘Select the business policy’ drop-down, however, I was unable to specify any parameters to pass to the Policy. The parameters section simply did not provide any facility for mapping a local message instance to a policy parameter.

A little research revealed this post, detailing the solution.

It is important that there is no ambiguity with the schemas for messages being passed to the BRE.  To this end, the BRE requires you set the Document Type name of any Schema Facts to the Fully Qualified Name (FQN) of the schema.  The Fully Qualified Name can be found in the Properties of the .xsd file in Visual Studio.

Once the Document Type has been changed to use a FQN, and any Rules and/or Vocabularies appropriately updated, the Policy can be re-published, and parameters will be accessible within the Call Rules shape.


March 28, 2013 Posted by | BizTalk | , | Leave a comment

Calling helper methods from the Business Rules Engine

Here’s a trick that usually gets people new to BizTalk.

The Business Rule Engine has the ability to call (public) static methods on any .Net class, without needing to assert an instance of the class first. However, when you execute your policy, nothing is returned into the policy, and your rules will not work as expected.

The problem is that, by default, the BRE will not execute the static method, unless a specific registry setting is set.  This keeps the default behaviour backwards compatible with the original BTS2004 release of the BRE.

To enable calling these methods, add a REG_DWORD key named “StaticSupport“, with a value of “1” to the following registry path:

32-bit Windows


64-bit Windows


August 16, 2011 Posted by | BizTalk | , , , | Leave a comment

Calling the Business Rules Engine from .Net code

I recently had a chicken-and-egg request from a customer.

They wanted to be able to see how their data would appear after being processed by their BizTalk orchestration, but without actually passing the data through the orchestration (as this would change the state in their database).  Complicating this, the outgoing data is processed by a set of Policies using the Business Rules Engine (BRE).

Here’s the steps I undertook:

  • Generate a strongly-typed version of the target schema.  This is done using the xsd.exe tool included in the Visual Studio SDK.
    xsd.exe biztalktalk.targetschema.xsd /class /namespace:http://biztalktalk.targetnamespace/

    Include the resultant .cs file in your project.

  • First thing is to apply the Business Rules to the source document.  This mirrors the approach we’ve taken through the Orchestration.
  • In code, we create an instance of the Rules Engine:
    TypedXmlDocument typedDoc = new Microsoft.RuleEngine.TypedXmlDocument(document, docType);
    Policy pol = new Policy(ruleName);

    Where document is the source document, and docType is the fully qualified document type (i.e. AssemblyName.ClassName) of the source document.

  • If you have multiple rules in multiple policies, you will need to set-up (and dispose) a new Policy object for each rule-set.
  • The above step makes changes directly to the wrapped “document” XML document.  After this step, you can use the old document with the Business Rule changes applied.

Now we want to format the source document according to the destination schema.  We currently do this in BizTalk using a map, so rather than replicate our development efforts, and possibly introducing errors, we will “re-use” the BizTalk map from our .Net code.

  • Right click on your map file in Visual Studio, and select “Validate Map”.  In the output pane, there will be a link saying “… The output XSLT is stored in the following file: <file://…”  The file at this location contains the valid XSLT representation of your BizTalk map.
  • Copy the .xsl file into the same directory as your solution, and include it in your project.
  • Next, use the XSLT to transform the initial document into the format defined by the XSD in the first step.  I’ll write more about this later, but for now, this site is your friend.

Now we have an Xml Document in the expected destination format, with all BRE rules applied.  You can bind to this document in an ASP.NET DataGrid, and away you go.

August 12, 2008 Posted by | BizTalk | , , | Leave a comment