So you’re in BizTalk and you’ve created a schema based off a SQL Server stored procedure which includes a field of type ‘XML’. Everything works great, and then you hit the error:

The adapter failed to transmit message going to send port "Audit.Send" with URL "SQL://./xxxxxx/". It will be retransmitted after the retry interval specified for this Send Port. Details:"HRESULT="0x80040e14" Description="XML parsing: line 1, character 1377, illegal qualified name character"

This error is thrown by SQL Server as it parses the string being passed into the SP for the XML field. Your SP looks something like

PROC [dbo].[prxxxx]
@ID uniqueidentifier,
@IncomingMessage xml = NULL

INSERT Event(ID, IncomingMessage)
VALUES (@ID, @IncomingMessage)

After much playing around with xml encoding (UTF-8 vs UTF-16 and ISO etc.) it still throws the same useless error (or the error ‘unable to switch the encoding’, but that’s caused by doing stupid things with XML encodings).

Looking at the outgoing message from the BizTalk pipeline, the character causing the issue was ‘_’, a perfectly valid XML character. However when looking at the SQL Server trace log, the innocuous underscore had become ‘+’ character….
Taking a close look at the XML we see:

<a1:Exception_x002B_Xml xmlns:a1="http:// ....

This type of XML is created when serialising an object to a SOAP message, and as can be seen the ‘_’ characters is actually the start of a hex number for the character ‘+’ which magically gets decoded by SQL server before the SP. So the actual XML passed to the SP was:

<a1:Exception+Xml xmlns:a1="http:// ....

So to fix this error we need to make sure any hex character references in our XML object are modified prior to being sent to SQL. In this case the XML document in SQL Server is for logging purposes only, so replacing all ‘_x0000_’ type values in the xml with ‘_x_0000_’ solves the issue perfectly.

I’ve heard the question asked a few times, is BizTalk an ESB? and I don’t believe the answer is really black and white.

If you look at the history of BizTalk, it really started out life as an Enterprise Application Integration (EAI) platform, which thanks to its Pub/Sub architecture meant it could effectively perform the duty of an ESB, just not very easily. Where other platforms such as IBMs WebSphere and Oracles Fusion have been marketed with the sole purpose of being an ESB, BizTalk started out life with what seems to be more humble ambitions, enabling disparate systems to communicate with one another.

BizTalk has many moving parts, and an underlying architecture which means it can be shaped and configured to serve an extremely wide range of problems. Unfortunately this flexibility is also ones of its greatest weaknesses, which means in the wrong hands solutions can be developed which may possibly solve an issue today, but will ultimately prove to be inflexible, restrictive, and unstable in the future.

Acknowledging a number of the shortcomings in using BizTalk as an ESB, an open source project was created which aimed at providing the tooling and patterns which would allow for much easier configuration of BizTalk as an ESB. This opensource project was eventually picked up by Microsoft and became known as ‘Microsoft ESB Guidance’ ( The key features added by this project were:

  • Addition of a routing slip design pattern (Itineraries)
  • Central exception handling
  • Dynamic resolution of endpoints, transforms, and routing slips

Over the coming years Microsoft continued to provide updates  to the ESB Guidance, eventually renaming it to the ‘ESB Toolkit’.

Which leads us to today, approaching nearly a decade on from the introduction of the ESB toolkit, and not a huge amount has changed. Extra adapters have been added to the toolkit, and dynamic resolution methods such as UDDI added, however the core features initially offered haven’t been expanded on.

So back to the question, is BizTalk an ESB? Yes, it can be, but simply using the ESB toolkit doesn’t mean you’ve developed an ESB solution (in the context of SOA), in fact there are likely many cases where BizTalk has been implemented as an ESB without the ESB Toolkit very well. The key to using BizTalk as an ESB is ensuring the system is designed from the ground up with a Service Orientated Architecture (SOA) that identifies the out of the box shortcoming with BizTalk and implements work arounds which don’t break the architecture.



The release of BizTalk 2013 has coincided perfectly with the start of a new client project related to creating what will be a relatively large SOA solution utilizing BizTalk as an ESB.

With the ESB Toolkit now a core feature of BizTalk, I was hoping for a slightly smother experience than that of BizTalk 2010, unfortunately this wasn’t really the case. After installing everything successfully thing looked promising, until you try and use the BRI resolver and hit the following exception:


Exception has been thrown by the target of an invocation.

Source: Microsoft.Practices.ESB.Resolver.ResolverMgr

Method: System.Collections.Generic.Dictionary`2[System.String,System.String] Resolve(Microsoft.Practices.ESB.Resolver.ResolverInfo, Microsoft.BizTalk.Message.Interop.IBaseMessage, Microsoft.BizTalk.Component.Interop.IPipelineContext)

Error Source: mscorlib 

Error TargetSite: System.Object InvokeMethod(System.Object, System.Object[], System.Signature, Boolean)  

Error StackTrace:    at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes, StackCrawlMark& stackMark)
   at System.Activator.CreateInstance(Type type, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
   at System.Activator.CreateInstance(Type type, Object[] args)
   at Microsoft.Practices.ESB.Resolver.ResolverFactory.Create(String key)
   at Microsoft.Practices.ESB.Resolver.ResolverMgr.GetResolver(ResolverInfo info)
   at Microsoft.Practices.ESB.Resolver.ResolverMgr.Resolve(ResolverInfo info, IBaseMessage message, IPipelineContext pipelineContext)


The test scenario I have is a FILE receive location using the pipeline ‘ItinerarySelectReceiveXML’ with the following settings:

FactKey: Resolver.Itinerary

ResolverConnectionString: BRI:\\policy=DemoSelection;


I suspected this was a configuration issue with ESB.config and the update from Enterprise Library 4.1 to 5.0 in version 2.2 of the toolkit, but after more than an hour of stuffing around and trying different version of EL I posted the issue to the Microsoft Connect forum.

Luckily I wasn’t the only person experiencing this issue, and Tomasso Groenendijk on the Microsoft Connect forum had picked up the change in the version of Unity used with EL 5.0, and thus the change in the config file format. The end solution is such that the following changes must be made to the ESB.config:

  • Remove the <typeConfig> element
  • Change the <typeAlias> element to <alias>
  • Change the <type> element to <register>.
  • Remove the <containers> elements and <types> elements.

Again, thanks to Tomasso who has also bloged the issue at: