Windows Azure BizTalk Services Just Became 19% More Interesting

Buried in the laundry list of new Windows Azure features outlined by Scott Guthrie was a mention of some pretty intriguing updates to Windows Azure BizTalk Services (WABS). Specifically, this cloud-based brokered messaging service can now accept messages from Windows Azure Service Bus Topics and Queues ( there were some other updates to the service as well, and you can read about them on the BizTalk team blog). Why does this make the service more interesting to me? Because it makes this a more useful service for cloud integration scenarios. Instead of only offering REST or FTP input channels, WABS now lets you build complex scenarios that use the powerful pub-sub capabilities of Windows Azure Service Bus brokered messaging. This blog post will take a brief look at how to use these new features, and why they matter.

First off, there’s a new set of developer components to use. Download the installer to get the new capabilities.

2014.02.21biztalk01

I’m digging this new style of Windows installer that lets you know which components need upgrading.

2014.02.21biztalk02

After finishing the upgrade, I fired up Visual Studio 2012 (as I didn’t see a template added for Visual Studio 2013 usage), and created a new WABS project. Sure enough, there are two new “sources” in the Toolbox.

2014.02.21biztalk05

What are the properties of each? When I added the Service Bus Queue Source to the bridge configuration, I saw that you add a connection string and queue name.

2014.02.21biztalk06

For Service Bus Topics, you use a Service Bus Subscription Source and specify the connection string and subscription name.

2014.02.21biztalk07

What was missing in the first release of WABS was the ability to do durable messaging as an input channel. In addition, the WABS bridge engine still doesn’t support a broadcast scenario, so if you want to send the same message to 10 different endpoints, you can’t. One solution was to use the Topic destination, but what if you wanted to add endpoint-specific transformations or lookup logic first? You’re out of luck. NOW, you could build a solution where you take in messages from a combination of queues, REST endpoints, and topic subscriptions, and route it accordingly. Need to send a message to 5 recipients? Now you send it to a topic, and then have bridges that respond to each topic subscription with endpoint-specific transformation and logic. MUCH better. You just have more options to build reliable integrations between endpoints now.

Let’s deploy an example. I used the Sever Explorer in Visual Studio to create a new queue and a topic with a single subscription. I also added another queue (“marketing”) that will receive all the inbound messages.

2014.02.21biztalk08

I then built a bridge configuration that took in messages from multiple sources (queue and topic) and routed to a single queue.

2014.02.21biztalk09

Configuring the sources isn’t as easy as it should be. I still have to copy in a connection string (vs. look it up from somewhere), but it’s not too painful. The Windows Azure Portal does a nice job of showing you the connection string value you need.

2014.02.21biztalk10

After deploying the bridge successfully, I opened up the Service Bus Explorer and sent a message to the input queue.

2014.02.21biztalk11

I then sent another message to the input topic.

2014.02.21biztalk12

After a second or two, I queried the “marketing” queue which should have both messages routed through the WABS bridge. Hey, there it is! Both messages were instantly routed to the destination queue.

2014.02.21biztalk13

WABS is a very new, but interesting tool in the integration-as-a-service space. This February update makes it more likely that I’d recommend it for legitimate cloud integration scenarios.



Categories: BizTalk, Cloud, Windows Azure, Windows Azure BizTalk Services

3 replies

  1. Microsoft removed the ACS configuration section from the Access connection information dialog–when the service bus namespace is created in the Azure portal UI–on September 3, 2014. This is the dialog that contains the Default Issuer and Key used to secure the service bus entry. In order to work around this, create the service bus namespace in PowerShell rather than via the UI. The Access connection information dialog will then contains the necessary attributes and match your blog post. Here is a link to the Microsoft statement and rational. http://blogs.msdn.com/b/servicebus/archive/2014/09/03/change-to-azure-service-bus-portal-default-authentication-mechanism-for-service-bus-namespaces-now-sas.aspx. Thanks for your great post and blog in general that I always enjoy!

Trackbacks

  1. Windows Azure BizTalk Services – My learnings 1 | Connected Pawns
  2. Aligning Microsoft Azure BizTalk Services Development with Enterprise Integration Patterns

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: