Category: Guest Poster

This article has been jointly written by Connected Pawns’ Mark Brimble and Adventures inside the Message Box’s Johann Cooper and is a response to MuleSoft’s recent blog article “10 reasons to walk from BizTalk” in an attempt to analyse whether the article has any merit.

A quick disclaimer first. Our trade is primarily but not limited to BizTalk. Our current focuses are on Microsoft products, however as it should be our loyalty is to our customers (whoever that might be at the time) and we consider ourselves open to any and all technologies. We consider MuleSoft products, and other integration offerings such as Boomi, to be opportunities rather than threats to our careers. We haven’t used MuleSoft products yet but do follow them out of interest as they are clearly an industry leader in the integration space, which is quite an achievement considering the strengths of the more established incumbents.

Recently one of our customers chose MuleSoft because it is open source and that better suits the culture of that organisation. This was a “greenfields” on-premises project and we helped them evaluate some of the products available. In our opinion it was not possible to make a choice solely on technological grounds and the decision had to be made on organizational factors e.g. were they buy versus build or open source versus vendor specific or what support model best suits.

On to the article… Our belief is that the target of this audience is CIOs and CFOs rather than integration specialists, and it is likely that it has been pushed through by marketing teams rather than technical teams, unfortunately with a degree of smoke and mirrors and misinformation. An integration specialist, especially one trained up in BizTalk Server, will see through most of the points raised very quickly.

First of all the article doesn’t make it clear whether it is comparing Anypoint to BizTalk Server or Services. There is no question that BizTalk Services is not yet a fully matured product, it is still in its infancy but there is no question that Microsoft are committed to it. BizTalk Server on the other hand is a robust and mature product. BizTalk Services doesn’t seek to replace BizTalk Server, but rather compliments it.  You could swap it out quite easily for any other cloud integration offering which could work alongside BizTalk Server. If a competitor wants to make point by point comparisons then it should do so against a specific product rather than leave things vague.

Points 1, 3, 4 and 7 in MuleSoft’s post are heavily marketing speak and don’t really offer any real substance in terms of comparison. All mature ESB type products are very heavy feature wise and it is not worth comparing feature for feature (unless there is a huge obvious gap).  What is important is to see which product fits your organisation better. If one product came out with a killer feature you could be rest assured that the same or a similar feature would quickly appear in all the competitors products. 

The way we see it, the most difficult part of integration projects is getting the requirements correct and sorting out dependencies rather than problems with tooling. These problems will be faced regardless which engine you use, so this isn’t a huge differentiating factor. Chances are the cost to deliver a project on an already established platform will be equivalent with all other things being equal (minus the whole amortization aspect which doesn’t apply to BizTalk Server but will of course apply to BizTalk Services).

Regarding the time required to provision an integration environment there is no question that setting up BizTalk Server is a project in itself, however this isn’t the case with BizTalk Services which adopts a more lightweight approach. Anypoint definitely holds the upper hand in this respect compared to BizTalk Server which is a traditional heavyweight product, but Microsoft doesn’t intend for BizTalk Server to fit in the lightweight category, which is instead taken care of by BizTalk Services. Whether you want to choose a heavyweight or lightweight offering should be a consideration when choosing a new integration engine, but doesn’t really come into play if you already have an established BizTalk Server environment.

With point 2 there are some major differentiating factors when it comes to cloud readiness which the article doesn’t explain in depth but we’ll try to provide our understanding here. MuleSoft definitely offers more connectivity options from the cloud than BizTalk Services currently does, though this gap should lessen with time. BizTalk Server doesn’t yet support high availability (the weakest link being a lack of support for SQL clustering) when running in IAAS mode in the cloud, whereas our understanding is this isn’t a problem with MuleSoft products. There is no doubt that Microsoft has some catching up to do, and this is reflected in Gartner/Forrester survey results. This is something MuleSoft should be capitalising on to capture the attention of those adopting a cloud strategy in a hurry.

Point 5 will appeal to open source people but who really cares if you can see the source code for the product… surely you aren’t going to change the source code yourself and redeploy a customized version of the product. Will Microsoft really chase us down if we use reflector to check out what’s under BizTalk Server’s hood? If that was the case we’d surely have an entire army of lawyers knocking on our doors 🙂

Point 6 is a good one. It isn’t a reason to walk away from BizTalk, but is a reason to choose Anypoint over BizTalk Server/Services if choosing an integration engine and you have a java preference. We don’t think multi-language support is really that appealing for the enterprise since most companies are going to choose one platform and stick with it. It does hold a certain appeal for ISVs however who might find that their target market for selling integration solutions is wider with a language agnostic solution.

Point 8 regarding costs is once again an unfair comparison. Is the comparison between BizTalk Server or Services? BizTalk Server definitely fits into the traditional heavyweight integration engine category unlike Anypoint; a comparison with BizTalk Services is more apt. That said we can’t perform a fair comparison here because MuleSoft does not publish all it’s prices. A little more transparency would be nice here, especially for ISVs who really need all the facts before approaching potential customers.

Point 9 might well be true but one would have to talk to people in the know to get a real answer. The fact is SLAs are just numbers and it’s about the ability to deliver on them. We don’t have enough experience (thankfully) with either company on P1 type issues so we can’t comment on this too much.

10 is and isn’t true. The release cadence for BizTalk Server and Services was committed to at the BizTalk Summit 2013 and they are reasonably aggressive. Regarding Gartner type reports it is true that MuleSoft is consistently on top, in fact Microsoft wasn’t even on the radar for a while due to a cloud offering not being available, however that has changed now and Microsoft is also in the leaders quadrant albeit still lagging behind Mule.  This should certainly come into play when evaluating vendors, but once again chances are that you aren’t going to walk away from an established integration platform solely to move to a vendor who might have a lead but is considered to be in the same category.

In summary we just don’t think there are many reasons for an organisation to ditch BizTalk Server and jump ship to MuleSoft, however there are many compelling reasons to assess MuleSoft products if you are either choosing a new integration engine for your company or you have a had a major change in strategy that requires you to move to the cloud in a hurry and aren’t keen to wait for Microsoft to fix up their gaps in BizTalk Services / BizTalk Server on IAAS.

My colleague Ian Hui figured out a problem that has had me scratching my head for the last two months and he has made me a very happy man.

While porting unit tests using BizUnit for the BRE Pipeline Framework from BizTalk 2010 to BizTalk 2013 I encountered a System.BadImageFormatException exception with the following error message – “Could not load file or assembly ‘file:///C:\Program Files (x86)\Microsoft BizTalk Server 2013\Pipeline Components\BREPipelineFrameworkComponent.dll’ or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded”.

Failed test

When I removed my custom pipeline component and only left behind the out of the box pipeline components like the XML Disassembler I noticed that the problem disappeared.  This, and some further digging caused me to believe that the problem is encountered with all pipeline components built in .Net 4.0 and above.  I tried a whole bunch of workarounds such as rebuilding the BizUnit test steps, the Winterdom pipeline testing framework and even the PipelineObjects.dll assembly using .Net 4.5 thinking that this might help work around the problem but I just kept hitting brick walls.  What made the problem even more mind-boggling was that the pipeline components that caused problems in unit tests ran just find in the BizTalk runtime.

In comes Ian who persevered with the problem long after I had resigned this to being something we would have to wait for Microsoft to fix.  He found that you needed to adjust the vstest.executionengine.exe.config file typically found in the “C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow” folder, setting the useLegacyV2RuntimeActivationPolicy attribute on the startup element to true as in the below  (you can download a copy of my config file from here if you want to copy/paste from it).


You can read more about this setting and what it does here.  The discrepancy in behaviour between the test execution and BizTalk runtime is easily explained by examining the BTSNTSvc64.exe.config file in the BizTalk program files folder as you’ll notice that the aforementioned attribute is set to true in this config file by default, which is why the runtime never had a problem with these pipelines.

BT config

Funnily enough after Ian figured out the answer for this problem he found that Shashidharan Krishnan had encountered the same problem in the past (on BizTalk 2010) and fixed it in the exact same way (he has documented this here), however he encountered completely different error messages and I suspect that he was running his unit tests through a console application rather than Visual Studio unit tests.  Either ways as the error messages he encountered are totally different from the ones we did, chances are that if you have the same error as us you might not find his post which is why we decided we would document this anyways.

Thanks again Ian (and Shashidharan).  You guys have just made unit testing BizTalk 2013 components more robust, thus ensuring the success of integration solutions developed for BizTalk 2013.

A guest post from my super resourceful and wise beyond his years colleague Colin Dijkgraaf (you can stop pointing the gun at my head now Colin :)), who came to the rescue with an out of the box solution where I was about to put on my coding hat and write my own custom pipeline component.

The age old (or at least as long as BizTalk has been around) of removing the namespace prefix on a document created by BizTalk came up.

The usual suggestions of using XSLT in a map, custom pipeline components came up when I searched.

However in one thread it was suggested to use the namespace components in the ESB toolkit.

Here is the message as it looked like initially.

 <ns0:Batch BatchName=”10.4″ BatchID=”125″ xmlns:ns0=”Test”>

  <Document DocumentType=”DocumentType_0″>


      <Field FieldName=”FieldName_0″>Field_0</Field>







First I tried just adding the ESB Add Namespace and just set the NamespaceBase Pipeline Component Property.

This resulted in the error message

There was a failure executing the send pipeline: “BizTalk_Server_Project1.SendPipeline1, BizTalk Server Project1, Version=, Culture=neutral, PublicKeyToken=c21ce57b7bcc506e” Source: “ESB Add Namespace” Send Port: “TestSendPort” URI: “C:\Test\test app\out\%MessageID%.xml” Reason: Error 105010: Root element contains a namespace that matches what was specified as the new namespace – however, the prefix that exists within the document ‘ns0’ does not match the prefix specified ”.  Please change the Prefix property accordingly.

 To resolve this I added the ESB Remove Namespace as below.

This resulted in the message below.   Success!

 <Batch xmlns=”Test” BatchName=”10.4″ BatchID=”125″ >

  <Document DocumentType=”DocumentType_0″>


      <Field FieldName=”FieldName_0″>Field_0</Field>







%d bloggers like this: