Sending Messages from to BizTalk Server Through Windows Azure AppFabric

In a very short time, my latest book (actually Kent Weare’s book) will be released.  One of my chapters covers techniques for integrating BizTalk Server and  I recently demonstrated a few of these techniques for the BizTalk User Group Sweden, and I thought I’d briefly cover one of the key scenarios here.  To be sure, this is only a small overview of the pattern, and hopefully it’s enough to get across the main idea, and maybe even encourage to read the book to learn all the gory details!

I’m bored with the idea that we can only get data from enterprise applications by polling them.  I’ve written about how to poll from BizTalk, and the topic has been covered quite well by others like Steef-Jan Wiggers and Synthesis Consulting.  While polling has its place, what if I want my application to push a notification to me?  This capability is one of my favorite features of  Through the use of Outbound Messaging, we can configure to call any HTTP endpoint when a user-specified scenario occurs.  For instance, every time a contact’s address changes, could send a message out with whichever data fields we choose.  Naturally this requires a public-facing web service that can access.  Instead of exposing a BizTalk Server to the public internet, we can use Azure AppFabric to create a proxy that relays traffic to the internal network.  In this blog post, I’ll show you that Outbound Messages can be sent though the AppFabric Service Bus to an on-premises BizTalk Server. I haven’t seen anyone try integrating with Azure AppFabric yet, so hopefully this is the start of many more interesting examples.

First, a critical point. Outbound Messaging is awesome, but it’s fairly restrictive with regards to changing the transport details.  That is, you plug in a URL and have no control over the HTTP call itself.  This means that you cannot inject Azure AppFabric Access Control tokens into a header.  So, Outbound Messages can only point to an Azure AppFabric service that has its RelayClientAuthenticationType set to “None” (vs. RelayAccessToken).  This means that we have to validate the caller down at the BizTalk layer.  While Outbound Messages are sent with a client certificate, it does not get passed down to the BizTalk Server as the AppFabric Service Bus swallows certificates before relaying the message on premises.  Therefore, we’ll get a little creative in authenticating the caller to BizTalk Server. I solved this by adding a token to the Outbound Message payload and using a WCF behavior in BizTalk to match it with the expected value.  See the book chapter for more.

Let’s get going.  Within the administrative interface, I created a new Workflow Rule.  This rule checks to see if an Account’s billing address changed.


The rule has a New Outbound Message action which doesn’t yet have an Endpoint address but has all the shared fields identified.


When we’re done with the configuration, we can save the WSDL that complies with the above definition.


On the BizTalk side, I ran the Add Generated Items wizard and consumed the above WSDL.  I then built an orchestration that used the WSDL-generated port on the RECEIVE side in order to expose an orchestration that matched the WSDL provided by  Why an orchestration?  When sends an Outbound Message, it expects a single acknowledgement to confirm receipt.


After deploying the application, I created a receive location where I hosted the Azure AppFabric service directly in BizTalk Server.


After starting the receive location (whose port was tied to my orchestration), I retrieved the Service Bus address and plugged it back into my Outbound Message’s Endpoint URL.  Once I change the billing address of any Account in, the Outbound Message is invoked and a message is sent from to Azure AppFabric and relayed to BizTalk Server.

I think that this is a compelling pattern.  There are all sorts of variations that we can come up with.  For instance, you could choose to send only an Account ID to BizTalk and then have BizTalk poll for the full Account details.  This could be helpful if you had a high volume of Outbound Messages and didn’t want to worry about ordering (since each event simply tells BizTalk to pull the latest details).

If you’re in the Netherlands this week, don’t miss Steef-Jan Wiggers who will be demonstrating this scenario for the local user group.  Or, for the price of one plane ticket from the U.S. to Amsterdam, you can buy 25 copies of the book!


Categories: BizTalk, Cloud, Dynamics CRM,, SOA, Windows Azure AppFabric

8 replies

  1. Richard,

    The Amazon link to your book reports “Out of print — limited availability.”


    Roger Jennings

  2. It is a very compelling pattern and during my talk I for BizTalk User Group I showed it and people where amazed.


  1. Distributed Weekly 109 — Scott Banwart's Blog
  2. Windows Azure and Cloud Computing Posts for 6/28/2011+ - Windows Azure Blog
  3. 2011 Year in Review « Richard Seroter's Architecture Musings
  4. Is AWS or Windows Azure the Right Choice? It’s Not That Easy. « Richard Seroter's Architecture Musings
  5. Windows Azure and Cloud Computing Posts for 5/10/2012+ - Windows Azure Blog

Leave a Reply

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

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

Google photo

You are commenting using your Google 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 )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: