I am going to do a series of three blog posts (and accompanying videos) about how to integrate BizTalk and Azure. As you know, Azure is in the process of going live, and BizTalk can play a very compelling role bridging between on-premise and off-premise.
This post shows two key interactions with the Windows Azure platform AppFabric Service Bus:
- receiving a message from the Service Bus through a BizTalk receive location
- publishing to the Service Bus from an InfoPath form
It is the first point that I think illustrates what will become a VERY commonly used pattern. This sample is based on the Order Demo I created previously, and you can go watch those videos first to get a sense of what the demo is. It brings together BizTalk, SharePoint, ESB Toolkit, SQL Server Analysis Services, SQL Server Reporting Services, InfoPath and more, including showing how to use the Business Rules Engine for dynamic itinerary selection (a favorite pattern of mine). I blogged about that here. I like it because it’s a “SharePoint-based ESB-driven BizTalk-powered workflow”, really leveraging the power of the Microsoft stack.
The video for this blog post is available here at the MSDN BizTalk Developer site.
My goal in this post is to take an on-premises business process, and make it externally available. Now, traditionally in a BizTalk environment that would mean TYPICALLY that you expose a schema or orchestration as a Web service, and then reverse-proxy that so it can be reached from the outside world, probably with a load balancer in the mix.
There’s new tool in our toolbox now: Windows Azure platform AppFabric, which includes the Service Bus and Access Control Service. So, I set out to use that as an external relay, and an entry point into my existing order process demo.
Before we integrate with the existing system, let’s get the client->ServiceBus->BizTalk flow working.
Once you’ve signed up for the Azure service and received your developer token, the first thing you need to do is install the Windows Azure platform AppFabric SDK in your BizTalk environment. One of the things this gives you is a set of new WCF bindings, which is what I used in conjunction with BizTalk’s WCF-Custom adapter. I created a new BizTalk project, a new receive port and receive location, as shown below:
I had many options available, but as I was going .NET (BizTalk) to .NET (Service Bus), I opted to use the Net TCP binding for greater efficiency (perhaps not so important for a demo, but, might as well do it right). Note also that transport-level security is enabled.
For credentials, I used “shared secret”. This means that it will use the Access Control Service to authenticate me, and the corresponding issuerName and issuerSecret need to correspond to what you have set up using the Azure portal.
Normally, that would be it, but in my case there was a structural difference between what was being relayed to me from the Service Bus and what I needed for my existing process. So, I used the WCF adapters capability to reach into the message and only pass on what I had specified as being the body based on my XPath expression:
And that’s it! Enabling that receive location will create an endpoint “listener” (subscriber) in Azure’s Service Bus. Pretty remarkable really, when you consider that I needed to magic at the BizTalk end other than a new WCF binding, and I can now subscribe to message from the cloud. This is the sort of thing where when you first see it work, you sit back in your chair, say “wow”, and then think about what the implications are.
Next step, we need a publisher. My existing demo already had an InfoPath form, so I wanted to use that. However, how do you make InfoPath talk to Windows Azure platform Service Bus? Now, I’m hardly an InfoPath expert, but I thought I’d give it a shot anyhow. Following the lead from samples in the Azure SDK, I knew I had to set up some contracts. I had to embed this right in the formcode for the form, perhaps there’s a better way (any InfoPath experts, I’d love to know), but my goal here was “just make it work”, knowing full well that I’m dealing with CTPs and ultimate production-ready approaches would likely change anyhow. So, with that as my mindset, the following is what I ended up with. Notice the OrderRelayService class, and how that aligns with the URI in the BizTalk receive location.
Next, the “Save” button code just sets the order status, and then calls the SendForm method:
Lastly, we have the sending part. Yes, I have my credentials in the clear here, but once this post goes live those credentials will have changed 🙂
And, that’s it we can now use an InfoPath form to send messages to the Service Bus, and if the Access Control Service authorizes it, the message will be published. BizTalk will have an endpoint listening and will pick up that message.
The last thing we need to do now is hook this into the existing process flow. If you watched the original Order Demo video, you’ll know that I was creating orders in InfoPath, publishing to a SharePoint document list, and from there they were picked up by a BizTalk receive location that used the SharePoint adapter. As part of that, we use one of the standard ESB Toolkit pipelines to select and apply an itinerary, and we selected the itinerary based on a rules engine decision. So, how hard would it be to integrate that functionality into the messages we’re picking up from the Service Bus? Simple, we just add that pipeline to the receive location, and we’re done.
In this post, and the accompanying video, I have shown you how to take an on-premise BizTalk application and make it available externally via the Windows Azure platform Service Bus, by just adding another receive location. And, a huge benefit you get here against having exposed your own endpoint is the scale benefits of the cloud. You don’t need to worry about having servers in a DMZ, reverse proxies, load balancers, or any of that infrastructure “goo”.
At this point you may want to sit back, say “wow”, and think about what new possibilities this opens up and the solutions you can now create, combining on-premise BizTalk ESB (and perhaps some of your existing applications) with the Windows Azure platform.