Talk, talk and more talk about BizTalk

Add context menu item to Visual Studio

Here’s a nifty way to add a ‘Run in Command Prompt’ context menu item to the Visual Studio solution explorer.

Very handy for executing .cmd files to generate .Net type definitions from a BizTalk schema.


May 28, 2013 Posted by | Uncategorized | , | Leave a comment

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

Unable to configure BAM Tools

While installing BizTalk 2010 in a multi-server configuration (one server for BizTalk, a different server for SQL), I received the following error while attempting to configure the BAM Archive database:

Microsoft SQL Server Data Transformation Services (DTS) 2008 with SP1 or higher for BAM Archiving is not installed on the local machine. Please install Microsoft SQL Server 2008 Integration Services. Could not load file or assembly

Additional information:

Could not load file or  assembly ‘Microsoft.SqlServer.ManagedDts, Version=, Culture=neutral, PublicKeyToken=89845dcd8080cc91’ or one of its dependencies…

The wording of the suggested solution takes a too literal approach. Whilst installing Integration Services would solve the problem, only the actual DLL library ‘Microsoft.SqlServer.ManagedDTS‘ needs to be installed.

This can be done by performing an install from the Sql Server installation media, but choosing to install only the following:

  • – Management Tools – Basic
    • – Management Tools – Complete

It should now be possible to complete the configuration successfully.

February 14, 2013 Posted by | BAM, BizTalk | , | Leave a comment

BizTalk and SAP

Great, if long, post on integration between BizTalk and SAP.


With SAP being one of the better known, and widely adopted ERP systems, there are a lot of opportunities for integration experts who can “bridge the gap” between SAP and Microsoft technologies.

December 11, 2012 Posted by | BizTalk, WCF | , | Leave a comment

Where’s my Sybase ODBC driver?

I am currently working with a customer that use Sybase (remember them?) Adaptive Server Enterprise, as their primary database environment.  Sybase and Microsoft originally co-developed the early versions of SQL Server, so there are still enough similarities that it “feels” like working with MS-SQL, albeit an older version.

However, the BizTalk Adapters are not so forgiving, and will not work with ASE.  Our solution was to use the open-source ODBC Adapter provided by TWOCONNECT (link).  This was when we ran into trouble.

Opening the ODBC Data Source Administrator to add a new System DSN left me with only 2 available options in the Driver’s tab:


Digging into things a little, I determined that the Sybase drivers are 32-bit only, but my development machine is running 64-bit Windows.  In order to be able to configure 32-bit ODBC drivers, you need to run the 32-bit version of ODBC Data Source Administrator.  This can be done by entering “C:\Windows\SysWOW64\odbcad32.exe” from the Run prompt:

Now the full range of “legacy” 32-bit ODBC drivers and data sources are available:

One final issue to consider.  If you have configured and wish to use a 32-bit DSN, you will need to run any associated Send and Receive Ports within the context of a 32-bit Host Instance.

November 19, 2012 Posted by | BizTalk | , , , | Leave a comment

Thread starvation in WCF Send Port

I recently ran into an intermittent problem where we were receiving the following exception:
System.InvalidOperationException: There were not enough free threads in the ThreadPool to complete the operation.
in conjunction with a stack trace indicating we were well and truly down in the WCF ServiceModel code base. This resulted in numerous suspended messages, and a messy Event Log.

A little investigation showed that it occurred due to a bulk update of the source system, which propagated a whole bunch of messages (around 1000 in a 5 minute period), via WCF, to a web service on the destination system. This resulted in a flood of messages from BizTalk to the WCF Send Adapter, which happily allocates each message to be sent to the back of it’s own processing queue. Each pending message gets allocated a work item thread.

The destination system only exposed a ASMX-style web service, so we were restricted to using basicHttpBinding.  Windows, and by inference, BizTalk, limits the default number of outbound HTTP connections to 2.  So were were pumping a whole lot of messages to WCF, as quickly as BizTalk could, but WCF could only dispose of, at maximum, 2 at a time.  Within a short amount of time, the process thread pool is exhausted, and errors resultant.

My solution was two-fold:

Increase the ‘maxconnections’ property for outbound Http connections.

This can either be applied at the machine level, or at the app config level.  I chose to avoid unwanted side effects by only modifying the BTSNTSvc64.exe.config, adding the following snippet within the <configuration></configuration> root:

    <add address="" maxconnection="12" />

Again, I took the conservative option, and only altered the maxconnection property for those intended for that specific server.  I dislike side-effects…

Increase the maximum number of threads allocated to the Host Instance

Fortunately, the BizTalk architecture was set up in such a way that this specific application had it’s own set of Host Instances.  This allowed me to increase the number of Maximum Engine Threads, without too much risk of starving other applications and processes on the server.

This is done within the Host Settings Dashboard, accessed by right-clicking on the BizTalk Group and selecting ‘Settings…” (sorry, BizTalk 2010+ only, folks).  You get a screen similar to the one below:

Host Engine Threads

So, I doubled the number of threads, which in conjunction with the increased throughput, above, should ensure we don’t run into this issue again.

October 17, 2012 Posted by | BizTalk, WCF | , | Comments Off on Thread starvation in WCF Send Port

When to Stop/Restart a Host Instance

Further to a question I recently answered on StackOverflow, I wanted to expand a little on when it is necessary to restart a BizTalk Host Instance, and when this is overkill.

Host Instance restart required

Any change to an underlying datatype, map or orchestration will require a restart of the corresponding Host Instance.  This is due to the way the .Net runtime manages type-loading of assemblies.

All BizTalk schemas, maps and orchestrations are compiled to .Net code inside an Assembly.  The .Net runtime supports dynamic loading and type-discovery of Assemblies, but does not support removal or un-loading.  This means that any time you change any code-based .Net artefact, a Host Instance restart is required before the change will be seen.

Runtime Configuration change

The counter to this is Configuration based runtime artefacts, including the configuration and binding of BizTalk Adapters.  For example, it is possible to change the path and file-mask properties of a File based Receive Adapter, or even change from using a File Receive Adapter to a SQL Receive Adapter within the same Receive Port, with the chage reflected immediately, and with zero down-time.

September 17, 2012 Posted by | BizTalk | , | Leave a comment

Dynamics AX 2009 adapter “Unable to log on to Microsoft Dynamics AX.”

This post is just to clarify the authentication settings required for being able to receive messages from Microsoft Dynamics AX (2009) into BizTalk using the older-style Microsoft Dynamics Adapter.  The latest version of AX uses a more generic WCF based approach, so your mileage may vary.

Firstly, there are two sets of of credentials to provide into the adapter:

  • Gateway user – These are the Domain credentials used to authenticate to the AX Server
  • Proxy user – The username, and password, of an additional Domain user, as setup in Dynamics

The Proxy User details can be determined within Dynamics from the set of credentials, that the “BizTalk” service account uses to connect to AX.

July 30, 2012 Posted by | BizTalk | , , | Leave a comment

Changing / Removing document namespaces

I recently ran into a requirement to both transmit and receive documents using “Plain Old Xml”. The system we were integrating was not able to understand the concept of namespaces in an Xml document, but BizTalk requires them, as messages are determined by the combination of a document’s Namespace and Root Node.

The solution was two-fold. For incoming messages, we “inject” a pre-determined namespace into the document as soon as it hits BizTalk. For outbound messages, we strip out all namespaces and alias’ just as we are sending it. The best was to do this is using a Pipeline Component.

There are a number of components and methods out there for adding a namespace to an inbound messages, see here and here.  I ended up re-using a sample I found on CodePlex.

To remove namespaces from the outbound messages, I massaged the content of the message using a Regular Expression, and some simple text replacement:

private static string RemoveNamespace(XmlDocument xdoc)
  // Regex to search for either xmlns:nsN="..." or xmlns="..."
  const string pattern = @"xmlns:?(\w+)?=""[\w:/.]*""";
  string xml = xdoc.OuterXml;

  Regex replace = new Regex(pattern);
  // Replace all occurances of the namespace declaration
  string temp = replace.Replace(xml, String.Empty);
  foreach (Match match in replace.Matches(xml))
    // Loop through each Match in the Regex, this gives us the namespace aliases found
    if (match.Success && match.Groups.Count > 1)
      if (!String.IsNullOrEmpty( match.Groups[1].Value))
        Regex alias = new Regex(@"\b" + match.Groups[1].Value + ":");
        // Replace all occurances of the
        temp = alias.Replace(temp, String.Empty);
  return temp;

The regular expression identifies namespace declarations, whether they declare an alias or not.  We then iterate all of the matched aliases, removing them from the target xml document.

Edit: I have added a link to cut-down sample project, detailing exactly how the pipeline component should be implemented.  Click here to download.

Edit2: Modified the regex pattern slightly so it also accounts for elements declared in the “empty” namespace.

June 26, 2012 Posted by | BizTalk, Pipeline | , , | 3 Comments

Unexpected use of keyword: ‘task’

I am currently using BizTalk 2010 as the integration hub between a number of systems, including Microsoft Dynamics CRM Online. The XLANG/s Orchestration compiler will complain with the following:

Unexpected use of keyword: ‘task’

One of the core entities in CRM is the ‘Task’, a sub-type of an Activity in the Sales process. However, we run into a problem in BizTalk when working with the schemas generated out of CRM, as ‘Task’ is also a reserved word in XLANG/s.

My solution was to create a ‘taskInternal’ schema alongside the generated ‘task’ schema. I set the Data Structure Type of taskInternal to the complex type ‘task’, to avoid redundant data types. Now we can build and compile our Orchestration just fine, as ‘taskInternal’ is not a reserved word.

Finally, we need a pair of very simple maps, from taskInternal->task and from task->taskInternal. These are applied on our physical Send Port, in the Outbound Maps and Inbound Maps sections respectively. Without this Inbound/Outbound mapping, we are not sending the correct Xml message types to/from CRM.

Note, there are another couple of reserved words that you might want to take a similar approach with, for example, ‘operator’ and ‘request’ are both reserved in XLANG/s.

September 27, 2011 Posted by | BizTalk, CRM 2011, WCF | , , | Leave a comment