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 Salesforce.com. 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 Salesforce.com 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 Salesforce.com. Through the use of Outbound Messaging, we can configure Salesforce.com to call any HTTP endpoint when a user-specified scenario occurs. For instance, every time a contact’s address changes, Salesforce.com could send a message out with whichever data fields we choose. Naturally this requires a public-facing web service that Salesforce.com 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 Salesforce.com Outbound Messages can be sent though the AppFabric Service Bus to an on-premises BizTalk Server. I haven’t seen anyone try integrating Salesforce.com with Azure AppFabric yet, so hopefully this is the start of many more interesting examples.
First, a critical point. Salesforce.com 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, Salesforce.com 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 Salesforce.com 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 Salesforce.com 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 Salesforce.com 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 Salesforce.com. Why an orchestration? When Salesforce.com 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 Salesforce.com Outbound Message’s Endpoint URL. Once I change the billing address of any Account in Salesforce.com, the Outbound Message is invoked and a message is sent from Salesforce.com 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 Salesforce.com 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!
Richard Seroter's Architecture Musings 
Richard,
The Amazon link to your book reports “Out of print — limited availability.”
Cheers,
Roger Jennings
@rogerjenn
Hi Roger. Yah, since the book missed the original release date, we went into Amazon purgatory. The “buy” button should get added back soon!
It is a very compelling pattern and during my talk I for BizTalk User Group I showed it and people where amazed.