BizTalk Server 2013 Ordered Delivery Improvements

By Nick Hauenstein

This post is the twentieth in a weekly series intended to briefly spotlight those things that you need to know about new features in BizTalk Server 2013.

Almost buried in the middle of the new features list, you will find that for those in the healthcare industry, Microsoft has finally delivered on a longer-term ask in the form of improvements to the handling of ordered delivery in BizTalk Server 2013. The ask was for better performance when using the MLLP adapter, but in reality – anyone who relies on ordered delivery with more than a single Send Port can benefit and see anywhere from 300-500% better performance.

This is the glimpse into the improvement that we get from the What’s New article:

In previous BizTalk versions with scenarios where ordered delivery uses multiple endpoints, the slowest adapter type is the maximum speed. This behavior directly impacts HL7 solutions. When using the MLLP adapter, acknowledgements (ACK) are required. Delays can occur because an ACK must be received before the next message is sent.

In BizTalk Server 2013, the next message can be sent without waiting for an ACK from the previous message. When the ACK arrives, it is internally correlated/connected with its message.

What was the Problem?

If you spend some time snooping around the blogs on MSDN from those involved in BizTalk Server development, you are likely to come across this post (back from when BizTalk Server 2013 hadn’t yet been christened 2013).

The post explains that in previous versions of BizTalk Server, whenever a host had a set of messages queued up and ready for delivery, if the first one was destined for an ordered Send Port, then the Host would be blocked until delivery of the message was successful (regardless of available threads, or other non-ordered Send Ports).

So what is the fix?

In the 2013 version of BizTalk Server, instead of relying only on the Host Queue, and blocking all messages that follow an ordered message, each Send Port with ordered delivery enabled is dedicated its own thread within the Host Instance, and messages sent to those locations will not block any other Send Ports that also have messages ready and waiting.

How Do I Take Advantage of This New Functionality?

That’s the really beautiful part about this feature; it’s built into the Messaging Engine. There is nothing special that you have to configure to enable this behavior, no code that you have to write – it’s just there and better by default. The only thing to keep in mind, is that since each ordered send port is dedicated its own thread, you may want to go to the BizTalk Settings Dashboard, and ensure that the  Messaging Engine Threads is appropriately configured to accommodate those Send Ports along with any other work that the Host has been assigned.

Best BizTalk Server Version Yet

If you haven’t made the move to BizTalk Server 2013 yet, or at least explored the evaluation to see what it has to offer, I would strongly encourage you to do so. Of course, if you want some dedicated hands-on time and instruction at the same time, I highly recommend our completely overhauled BizTalk 2013 Administrator Immersion class.

That’s all for this week. I’m back in the saddle after spending some time on vacation, so I will be back again next week. Until then, take it easy!

BizTalk Server 2013: Discovering Dependencies

By Nick Hauenstein

This post is the eighteenth in a weekly series intended to briefly spotlight those things that you need to know about new features in BizTalk Server 2013.

This week, I have decided to spotlight a simple feature that probably won’t be readily noticed unless you know it’s there, and you’re looking for it: Dependency Tracking1. This feature can prevent you from being yelled at by a dreaded 4-6 line error dialog, or other unforeseen consequences, providing you check dependencies before removing or redeploying an artifact.

the New Dependency Statistics Panel

If you have spent very much time in the new BizTalk Server 2013 Administration Console, you may have noticed that there is a new panel that shows up along the bottom:


If you’re anything like me, then it probably took you a while to figure out how to make this panel display information. As you can see, it hangs out at the bottom of the screen devoid of content by default.

In order to get those statistics, you have to access the context menu of the artifact that you’re interested in, and then click View Dependencies:


This will populate the two sections of the panel with (1) number of items that depend on the artifact, and (2) the number of items that the artifact depends on:


Clicking on one of these numbers will take you to the matching items with a breadcrumb to bring you back into context:


While none appeared while viewing the Orchestration dependencies, the items may include Schemas, Maps, Pipelines, Orchestrations, Receive Locations, Receive Ports, and Send Ports (e.g., below where we have Receive Locations / Maps in play):


Discovering Dependencies Not Found in the Binaries

As you continue to drill-down and view dependencies of each item, you will see the bread crumb update with the dependency chain. Here I can see that the original Orchestration I was examining ultimately depends on the JsonReceive pipeline (due purely to configuration in this case):


The Little Things

This is one of those little things that I have not yet had to make heavy use of, but I can see how it will bring value while tearing through more complex integrations trying to make heads or tails of what’s really going on.

If you want to try this out for yourself and get a glimpse of the Admin experience in BIzTalk Server 2013, come join us in October, November, or December for our BizTalk 2013 Administrator Immersion class.

1 Interestingly enough, this is the first feature highlighted in a similar series that Nitin Mehrotra has been running on his blog.