This is the third post in this series. So far, we have seen:

  • Post #1: Creating an ESB on-ramp that receives from Azure’s AppFabric Service Bus
  • Post #2: Sending a Message from BizTalk to Azure’s AppFabric ServiceBus with a Dynamic Send Port

In this third post, we will see how to use an ESB off-ramp to send a message to the Windows Azure AppFabric ServiceBus. We will actually be doing the same thing as we did in the second post, however, we’ll be doing it in a different way.

There is an accompanying video for this post (as I did with the others too), which you can find here.

The sequence used here is:

  1. Message is picked up from a file drop (because that’s how most BizTalk demos start:))
  2. An itinerary is retrieved from the itinerary repository and applied to the message
  3. The itinerary processing steps are performed, and the message is sent to the ServiceBus
  4. The message is retrieved by the receive location I wrote about in my previous post
  5. 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.

In this case, we’re not using an orchestration at all, we’ve specified in the itinerary that all processing happens at a messaging level.

The first part of this is the itinerary selection, which is as shown below. As you can see, I’ve “hard-wired” this receive location, and anything coming through it will get the “ServiceBusTest.OrderRelayNetTcp” itinerary applied to it.

The itinerary itself is also quite simple (this one is slightly different than the one shown in the video, but they are functionally equivalent).

All of the magic happens in the “SetProperties” resolver. In this case I am using a STATIC resolver, however, that just means I have statically specified the values. The settings are being applied dynamically by the itinerary processing components. Note that I have specified we are using the WCF-Custom adapter provider. As was the case with the first two posts in this series, I have installed the Windows Azure platform AppFabric SDK, which gave me some additional bindings that let me relay messages through the ServiceBus. In the second post, we used one of those bindings along with the WCF-Custom adapter by setting some values on a dynamic send port. In this one, we will set the same properties, but do so using the out-of-the-box ESB Toolkit WCF-Custom adapter provider. Each adapter provider registered with the ESB has a UI that can be associated with it, and you get there by clicking the Endpoint Configuration ellipses:

If you compare the values above to what I set in the second post in this series, you’ll see they are pretty much the same.

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 using an ESB off-ramp. 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 also that in this example I used the netTcpRlayBinding, which is a high performance .NET-to-.NET, but also requires TCP/IP ports be open, which could be an issue depending on how locked down your network is.

For my demo purposes, I use the ws2007HttpRelayBinding (also provided with the Azure AppFabric SDK), as that’s over port 80.

In this series of posts I have shown you how to bridge the gap between on-premise and Windows Azure AppFabric ServiceBus using out-of-the-box BizTalk and/or ESB Toolkit components. There is much more that can be done, this is only the beginning. We are entering a really interesting time, and I think that “hybrid” applications, with some part on-premise, other parts off-premise, will become increasingly common. As that happens, having a clean integration solution becomes very important so that we don’t create “Point-to-point Spaghetti 2.0”, a more modern version of the chaos that many experienced integration developers have seen all too frequently.

I hope you’ve enjoyed these posts and videos, and that they help you as you explore the new and exciting world of Windows Azure.