In a previous post, I wrote about how to extend the reach of an ESB on-ramp to Windows Azure platform AppFabric ServiceBus. This same technique also works for any BizTalk receive location, as what makes it an ESB on-ramp is the presence of a pipeline that includes some of the itinerary selection and processing components from the ESB Toolkit. In that post (and accompanying video) I showed how to use InfoPath as a client to submit the message to the ServiceBus, which subsequently got relayed down and into a SharePoint-based ESB-driven BizTalk-powered workflow.
In this and the next post, we’ll look at how to send messages in the other direction, and in this post, I’ll show how to do it using a BizTalk dynamic send port. If you’re used dynamic send ports with BizTalk, you’ll know they’re a powerful construct that let you programmatically sent endpoint configuration information that will subsequently be provided to a send adapter. This is a great way to have a single outbound port that can deliver messages to a variety of endpoints. And, dynamic ports are a key concept behind ESB off-ramps, but more on that later.
The video to go along with this post can be found here.
The sequence used here is:
- Message is picked up from a file drop (because that’s how most BizTalk demos start:))
- A BizTalk orchestration bound to that receive port is instantiated
- The orchestration (in an expression shape) sets properties the adapter will use
- The message goes to the dynamic send port and is dispatched
- The message is retrieved by the receive location I wrote about in my previous post
- A send port has a filter set to pick up messages received by that receive port, and persists the file to disk
The last two steps are not covered here, but are shown in the video.
Our orchestration is proof-of-concept simple, as you may have expected:
In our message assignment shape, first we create and work with the message:
Then, because the outbound port in our orchestration is a dynamic port, we set a couple of properties on that:
And. THAT’S IT!!!!! That is all we have to do in order for BizTalk to send a message to the Azure platform AppFabric ServiceBus. As you can see from the behavior specified, this is a secured channel (in this case I am using “shared secret”). The actual security part of this is provided with the Windows Azure platform AppFabric Access Control Service, which is tightly integrated with the ServiceBus.
Note the value of the WCF.BindingType (netTcpRlayBinding). This is just one of the ServiceBus-related bindings you get when you install the Azure platform AppFabric SDK. This particular binding is high performance .NET-to-.NET, but requires TCP/IP ports be open, which could be an issue depending on your network.
I’ve always loved the flexibility that the WCF-Custom adapter provides, and here is yet another example. Another team issues an SDK well after the current release of BizTalk, and because we’re all leveraging WCF it makes it trivial for us to take advantage of the new capabilities.
The next post and video in this series will show how to provide message sending capabilities using the components provided with the ESB Toolkit. Stay tuned.