Tag Archive: BizTalk Server 2013


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).

Config

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.

Advertisements

With some encouragement and prodding from some of the other senior members of my team I finally spun up a BizTalk 2013 VM through the Azure Portal. I must say that I was very pleased with the experience and am very excited at the potential that hopefully will be unleashed by this and other such platforms.

Once I got my BizTalk 2013 VM all configured up, I did what I do on every single dev BizTalk machine that I setup…I changed the schedule for the TrackedMessages_Copy_BizTalkMsgBoxDb SQL Agent job such that it runs every 10 seconds instead of the default every one minute. This results in me wasting less time waiting to see tracked messages and removes the temptation for me to pull out what little hair I have left in frustration.

Schedule

However after making the change I found that the SQL job was failing with the error “Could not find server ‘xxxxx’ in sys.servers”.

FailedJob

I followed the instructions on this lifesaver of a blog post by Christian Loris which suggested that the wrong server name might be registered in SQL Server. Sure enough this turned out to be the case, and I can only guess that this might be a byproduct of the way that Azure spins up a VM with the specified DNS name from a base image.

If anyone else has similar problems with their BizTalk 2013 VM then do the following (credit to the aforementioned blog post). First check that there is indeed a server name clash by running the below queries against the Master database and seeing whether they return anything other than the expected server name (the second query should return an unexpected value).

Check Queries

Once you’ve confirmed a naming issue you need to drop the unexpected server name and add the correct server name as below.

Fix

Once you have done this you will need to restart the SQL Server service and your TrackedMessages_Copy_BizTalkMsgBoxDb job should start working again.

Another alternative that was suggested to me by my colleagues who also encountered the same issue recently was to change the server name used in the SQL agent job step to the unexpected alias. They also mentioned that they encountered the problem immediately after their first reboot of the VM so it is quite likely that many if not most people spinning up a Biztalk 2013 Azure VM will encounter this problem.

I have recently been pointed towards a help page written by Microsoft with a wealth of information regarding BizTalk Server 2013 which I was unaware of (thanks to Kundan Karma in the LinkedIn BizTalk Elite group) – http://msdn.microsoft.com/en-US/library/jj248691(v=bts.80).aspx

What with all us bloggers writing about the release of BizTalk 2013 Beta I found that the help page was nowhere to be seen on google without just the right keywords. It contains very detailed information on usage of new adapters and known bugs (I doubt anyone has been able to deduce yet that BizTalk Server 2013 doesn’t perform as well as it’s 2010 counterpart when dealing with large messages so its good to see this information available).

For all the pioneers who have been fiddling with the beta in the dark, there is now a great resource available for you to do so in a methodical manner and not just about all the new features, but how to use them as well. Thanks Microsoft.

What a surprise today finding out that Microsoft has decided to brand it’s next version of BizTalk Server as BizTalk Server 2013.  Even better, they’ve already thrown a beta version at the general public which is a whole lot more full-fledged in terms of new features compared to some earlier builds made available to a select audience.

While its early days and features are bound to evolve between now and the release date, I’m sure many are curious to find out quite how Microsoft has decided to implement some of the promised features.

In today’s blog post which is the first in a series focusing on the new features in BizTalk Server 2013, I will focus on the much awaited dependency modelling feature that has been added to the administration console.  Such a feature has been sorely lacking in previous versions of BizTalk, making it very difficult for operations staff to get an idea of how BizTalk artifacts relate to each other.  Freeware tools such as BizTalk Documenter have filled this role reasonably well but there hasn’t really been a live view on dependencies available without peeking into the source code.

There is now a new option in the “Action” pane in the Administration Console called “View Dependencies” which can also be seen if you right-click on a supported artifact type.  This option exposes the new functionality by filling in the dependency details in the “Dependency Statistics” section at the bottom of the console.  Neither the View Dependencies option nor the Dependency Statistics section of the screen will be seen when browsing to artifact types that don’t support dependency modelling.

Well, I’ve built and deployed my first BizTalk Server 2013 application with the goal towards getting an initial understanding of how dependency modelling has been implemented.  The application consists of the below :

  • Four schemas (two external schemas and two internal schemas)
  • Three maps
    • From the first external schema to the first internal schema
    • From the first internal schema to the second internal schema
    • From the second internal schema to the second external schema
  • Two orchestrations – each of these orchestrations receive a message of internal schema one, map it to internal schema two, exercise a very simple BRE (Business Rules Engine) policy, and send the message out
    • The first orchestration contains logical ports with a specify later binding, bound to the receive and send ports mentioned below
    • The second orchestration contains logical ports with direct binding, not making use of any filter expressions.  Just for funsies this orchestration exercises the XMLTransmit pipeline on the outbound message before it is sent out
  • The aforementioned BRE policy
  • A one-way receive port which is bound to the first orchestration and a corresponding file receive location.  The receive port uses the XMLReceive pipeline and exercises the map that transforms the first external schema to the first internal schema
  • A one-way file send port which is bound to the first orchestration and also contains a filter so that it subscribes to messages with a message type of the second internal schema

I kept my schemas, maps, and orchestrations in separate BizTalk projects so I could see if there was any cross assembly dependency tracking.  I was a bit disappointed to find out that there is no visibility of cross assembly dependencies, at least not at this stage.

Let’s start with receive ports.  If we right-click on the receive port that I created and choose view dependencies then we see the below.

So interestingly we now see that this receive port has listings in the Used by (other artifacts are dependent on) section as well as the Using section.  Clicking on any of these numbers will give you a handy consolidated list of all the artifacts of that type which depend on or are dependents for this receive port.  Only the specify later bound orchestration is listed as dependant on this receive port whereas the one that uses direct binding is not listed.  This makes good sense because the direct bound orchestration has a loose subscription based purely on message context whereas the specify later binding orchestration is bound to the receive port.  The inbound map that is exercised by this receive port is listed in the using section since the receive port is dependant on it.  The receive location is also listed here.  I think that being able to see a list of all the receive locations for a given receive port will be well received by BizTalk Operators.

Next up lets inspect the dependencies for the receive location.  As one might have guessed, the receive location is used by it’s parent receive port.  The pipeline that it makes use of is listed as an artifact that the receive location is dependent on which is quite handy.

If we try to inspect the dependencies for the XMLReceive pipeline we see that the receive location that makes use of it is listed as dependent on the pipeline.  This provides some really fantastic information for those planning deployments which involve new versions of pipelines.

I was disappointed to find that when I tried to view dependencies on the XMLTransmit pipeline there was no information listed even though it was used by our second orchestration.  It looks like dependencies between pipelines and orchestrations aren’t quite catered for.

Next up let’s take a look at the dependencies for the map that is used on our receive port which transforms the first external message to the first internal message.  As seen below the schemas which make up the map are listed as dependents, and the receive port that makes use of this map is listed in the used by section.

On inspection of the map that transforms the first internal message to the second internal message and is used in the two orchestrations I found once more that the dependency between the maps and the orchestrations were not listed.

Viewing the dependencies on the second internal schema showed that it is used by two maps, the link to the orchestration is once more ignored.

On to the orchestrations.  Viewing dependencies on the specify later bound orchestration shows a dependency on the receive and send port that the orchestration is bound to but no mention of schemas and maps.

Viewing dependencies on the direct bound orchestration displays an empty Dependency Statistics screen, even ignoring the XMLTransmit pipeline that was exercised in this orchestration.

It became quickly apparent that there is no support for dependency modelling on the BRE policy, which once more is a bit disappointing but of course these are early days.

And finally viewing the send port shows that the orchestration with specify later binding is dependent on this send port, and that this send port is dependant on the map and pipeline which it exercises.

So while I have used the word disappointing quite a few times in this blog post, I am actually fairly happy with this implementation.  It is a big leap forward compared to what was previously available and one can only hope that Microsoft chooses to flesh out this feature even more.  It should make planning for deployments and everyday administration a whole lot easier and reduce the amount of detective work that is required to prepare for deployments.

If I’ve made a mistake or if I’ve left out a type of artifact that you are interested in and want me to explore further do let me know and I’ll update this post.

%d bloggers like this: