QuickLearn Blog

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

For whatever reason, the feature that we’ll be looking at today did not actually make the new features list on MSDN — which is unfortunate really, because it is a welcome relief for those that have a lot of Dynamic Send Ports fighting for host resources in environments with multiple BizTalk Server Applications.

What new feature might I be talking about? The new Configure Send Handler dialog in BizTalk Server 2013!

Let’s take a step back and tackle this one, one piece at a time…

Back to the Basics of Hosts in BizTalk Server

BizTalk Server has a rich scaling model based on the concepts of Hosts and Host Instances.

A Host is essentially a definition of a workload. A workload that might involve the processing of a certain set of orchestrations, a certain set of receive operations, or a certain set of send operations.

A Host Instance is an NT Service running on a machine for the purpose of processing that specific work load.

Within BizTalk, each Host is allowed to make use of certain adapters as part of its work. These Hosts (not specific instances, but the workloads themselves) then become the valid Send or Receive Handlers for that adapter – and might even have specific settings at the Host level (e.g., each Host can have a specific SMTP server pre-configured at the Host level  for the SMTP adapter).

All of these settings can be seen under the Platform Settings node within the BizTalk Server Administration Console:

Each Host (think workload/queue here) can be configured to have unique throttling characteristics through the BizTalk Settings Dashboard for the BizTalk group:

Each Host Instance (think worker/consumer/service running on some BizTalk box) can also be configured to have unique throttling characteristics to some degree through the BizTalk Settings Dashboard for the BizTalk group:

This has allowed us (since 2010 in the form shown above) to take control over how our BizTalk installations are resourced on a fairly granular basis. Even after setting up Hosts, Host Instances, and Adapter Handlers, we can take direct control over how each executable component within a BizTalk Application is resourced by assigning it to a specific Host (workload/queue):

(Note: Ignore that this is an Isolated Host. For the purpose of the screenshot, I wanted to show only where the property existed on the form)

So that’s pretty neat, and maybe pretty boring if you already know all of this stuff – so what does it have to do with Dynamic Send Ports, or BizTalk Server 2013?

Dynamically Sending a Message in BizTalk Server

Before we can see what benefit we’re getting in 2013 with regards to Hosts and Host Instances, we have to understand Dynamic Send Ports. A Dynamic Send Port is a Send Port that doesn’t allow us to select and/or configure an adapter from the Administration Console. Instead, it allows us to select/configure an adapter in code as the message is being processed.

More specifically, it allows us to provide information in the context of the message that tells the Send Port which adapter to use, and how to configure that adapter. This would enable scenarios like sending a file to a different location based on some information inside the message (without having to know those locations AT ALL in advance).

One interesting thing about Dynamic Send Ports in the past, is that they haven’t had a “Send handler” property. In other words the Send Port itself does not specify which workload / work queue to place the work of sending the message (or executing the pipeline for that matter).

Instead, the way that the Host is chosen is based on the adapter that the message wants to use. The handler mappings for that adapter are looked up, and the default send handler for that adapter is used.

Performance Issues for Dynamic Send Ports

Let’s imagine that I have multiple applications that take advantage of dynamic send ports. Now let’s imagine that they’re all sending WCF messages using the WCF-Custom adapter. What ends up happening is that all of that work is converging on the same Host (workload / work queue), and our Host Instances (workers) for that one Host are now being used for processing the work of all of these applications.

That’s fine if all of those applications are equally important, and don’t mind some level of contention with one another. But if one is critically important, and I want to have some level of reserved resources for it, I’m kind of stuck – until BizTalk Server 2013.

How BizTalk Server 2013 Solves Dynamic Send Port Scaling

Bringing it back full circle to where we started, BizTalk Server 2013 introduces a solution to this problem — the Configure Send Handler dialog. You can access this dialog through the Configure button in the Transport group of a Dynamic Send Port:

Clicking that magical button brings you to the screen of a thousand choices. In this screen you get to select which Host will execute the work of the Dynamic Send (pipeline execution / transport of the message via the adapter) depending on the adapter that the message is looking for:

This makes BizTalk Server 2013 a must have for those of us that work consistently with Dynamic Sends (especially in the context of ESB Toolkit based integrations).

Where Can I Learn This Stuff?

This is one of those features that spans job roles in its benefits. It will benefit the BizTalk Administrator, empowering him/her to take more control over multi-tenant environments, and it will also greatly benefit the BizTalk Developer that has in the past been torn between a flexible choice and a better performing choice. I’m definitely excited to be able to take advantage of it 🙂

Okay at this point, I’m going to put on my marketing voice, and you’re going to pretend you’re awake at 2 AM watching very persuasive infomercials…

Maybe this has you excited too, and you have enough information to go on and do great things. Maybe, this has you realizing you’re getting a little bit behind the bleeding edge, and want to get sharper.

If that’s you, you’re still using BizTalk Server 2010, and you want to prepare yourself for the leap to 2013, then consider doing so with one of our BizTalk Server 2013 classes for your job role and skill level:

Take care until next time. I hope to see you in the field doing great things (and telling the rest of the community about it), or in class preparing to do so!