In this presentation we demonstrate how easy it is to integrate BizTalk Server 2013 with Windows Azure Service Bus queues & topics, facilitating the creation of powerful hybrid applications.
A webcast of the narration and demos can be found here: http://youtu.be/jQefUBvc4Dk
20. www.briztalk.org
Brisbane BizTalk User Group
http://www.facebook.com/BrisbaneBizTalkUserGroup
@briztalk
http://www.youtube.com/user/BrizTalkUserGroup/videos
Editor's Notes
In this presentation we will be demonstrating how easy it is to integrate BizTalk Server 2013 with Windows Azure Service Bus queues & topics, facilitating the creation of powerful hybrid applications.
To begin with, we should mention the main features of Windows Azure Service Bus. Essentially, the Service Bus provides a rich set of tools to support both connectivity via the cloud (using relays & protocol tunnel eventing) as well as Pub / Sub messaging structures including queues and topics to enable integration. It supports reliable transfer, routing through filters, and even some primitive transformation.
While BizTalk 2013 provides ample support for Service Bus relays, the subject of this presentation is limited to integrating with queues & topics only.
Service Bus queues are a cloud-based version of the same queues we are used to working with in any other programming model. They are essentially First-In First-Out data structures that have one sender and one receiver. They are great for load-levelling and offline batching. In the former case, multiple receivers can compete for messages and be self-paced in processing them; however this scenario doesn’t guarantee ordered processing because a processing failure may put the item back on the queue after the next item has already been retrieved by another receiver.Queue messages are made up of a collection of properties, which are just key/value pairs, and may include an optional body. Note that the body is “opaque”, meaning it is not exposed to the broker.
Topics differ from queues in that they support multiple subscribers, so more than one receiver can get the same message. It is essentially a publish / subscribe model not very different in concept from the BizTalk messaging engine. Filters can be used to target messages to individual subscribers. There is also support for filter actions that actually modify, add, or remove properties as the message is selected; so in that we have a limited transformation capability.
Everything in Service Bus starts with a namespace. The root of the namespace is always the same, it is your app name followed by “.servicebus.windows.net”. However, this namespace tree can have as many leaves as you wish… well, at least up to 32 segments and/or a 450 path character limit. The best thing is that each leaf can be individually maintained and secured with Access Control Services.
Each Service Bus namespace has a shadow in ACS, which allows you to configures users, rules, & policies. ACS works by claims, and identities are federated by ACS providers (Google, Facebook, Yahoo, LiveiD, ADFS, etc.).Claims are mapped to rights for each realm.
BizTalk Server 2013 included a number of new enhancements and adapters to facilitate integration with the cloud. In fact, a major focus of this release was to make it easier to build hybrid applications – that is, applications that utilise on-premises systems but still leverage the cloud to support greater connectivity and elasticity.
The adapter we will focus on in this presentation is the SB-Messaging adapter. This adapter enables you to easily connect to existing Service Bus queues and topics. All you need at a minimum is the URL and the ACS details for authentication. There are also some additional properties that enable you to control how the message properties are written or promoted to the BizTalk message context.
Let’s look at the send adapter first. In this mode, the minimum settings are the URL to the Service Bus resource (which you specify on the first tab), and the ACS namespace and credentials used to authenticate to the resource.
You also have the option to explicitly specify some default brokered message properties, as well as provide a namespace corresponding to any BizTalk context properties that you want added to the brokered message’s user properties. Note that this is NOT the namespace used to write them into the SB message, it is used only to retrieve context properties from the BizTalk message.
The receive mode of the adapter is very similar, with just a few subtle differences. You still need to provide the mandatory URL and ACS credentials of course.
The main difference is in the option to add user defined brokered message properties to the BizTalk message context. Note that standard brokered message properties are already written to the context (although not promoted), so including this namespace will add the user-defined ones as well. You can also choose to promote them, but be aware that you need to have ALL the brokered message properties defined in a property schema, or you will get runtime errors.
The final difference is that the receive mode of the adapter allows you to specify whether or not to use a session when retrieving messages. If your queue or topic has been configured to support sessions, this setting allows you to pull a group of related messages all at once.
Let’s have a closer look at the URL that we use to point to our queues & topics. As mentioned previously, all Service Bus addresses have the same format: they start with the “sb” protocol, and have a base address that consists of your custom namespace token followed by the standard “servicebus.windows.net” tokens. What follows varies depending on whether you are pointing to a queue or a topic subscription. If it’s a queue, then it is simply the path to the queue, which may be right at the root level or might be nested under several levels – but always ending with the queue name.For topics, it’s a little bit different. All topics must have a least one subscription, so the path must end in a series of three tokens: the topic name, the constant “Subscriptions”, and the subscription name.
Finally, regarding the namespaces for Brokered Message properties, it is important to note that there is one namespace used for all standard message properties (for example, SequenceNumber, TimeToLive, ContentType, etc.), and another namespace for any user-defined properties that you decide to include from your BizTalk context properties when you write to the queue or topic subscription. It doesn’t matter what namespace is used in the BizTalk message context for these properties – when you include them in the Brokered Message, they will always be assigned this user namespace.
Now it’s time for our first demo, where we will show how easy it is to connect to a Windows Azure Service Bus queue using the BizTalk 2013 SB-Messaging adapter. In fact, it is so easy we won’t even need to crack open Visual Studio for this demonstration![ Webcast of demos can be found here: http://youtu.be/jQefUBvc4Dk ]
In this 2nd demo, we will show how easy it is to connect to a Windows Azure Service Bus topic using the BizTalk 2013 SB-Messaging adapter. For this one, we will demonstrate some more advanced features including custom property promotion and filtering subscriptions.[ Webcast of demos can be found here: http://youtu.be/jQefUBvc4Dk ]
Here are some useful references for both Windows Azure Service Bus and also for BizTalk Server 2013 and its ability to integrate with Service Bus queues and topics via the new SB-Messaging adapter.
I hope you have found this presentation useful and informative. Please also take some time to visit our user group’s web portal, where you’ll find plenty of other links and resources. If you decide to join (membership is free), you’ll not only have access to more areas of the portal including downloads of presentations and code samples, but you’ll also receive event notifications and newsletters from BrizTalk. I promise you won’t be spammed, and you can always unsubscribe if you change your mind. You can also find us on Facebook, YouTube, orfollow us on Twitter.