Silver Award WinnerSilver Award Winner

Introduction

The BizTalk Server 2013 version introduced a few new adapters: WCF-WebHttp, SFTP, SB-Messaging, WCF-BasicHttpRelay and the WCF-NetTcpRelay.  And these adapters kind of closed the gap between cloud and on premise or you could view the addition of these adapters to support hybrid integration. The SB-Messaging provides connectivity with the Azure Service Bus, one of the most mature services. This service offers entities like Relay, Queues, Notification Hubs, Topics and Subscriptions, and Event Hubs. The interaction with these entities is possible with the SB-Messaging, WCF-BasicHttpRelay and the WCF-NetTcpRelay adapters. In this article the focus will be the SB-Messaging adapter that provides connectivity with queue, topics and subscriptions.

Scenario

This article will demonstrate how to send to and receive messages from an Azure Service Bus Queue. The diagram below visualizes this from a high level perspective.


Picture 1. High level overview of the scenario.

Setup

An Azure Service Bus Namespace is configured and two queues are created:

  • inboundqueue with max size of 1 Gb and no duplicate detection, session or partitioning
  • outboundqueue with max size of 1 Gb and no duplicate detection, session or partitioning

Picture 2. In- and outbound queue (entities) in the tnwiki service bus namespace.

Creating a namespace in the Service Bus Service in your Azure Subscription see MSDN How to use Service Bus queues:
Within the namespace two Shared Access Policies are created:
  • tnwiki_listen with a listen permission
  • tnwiki_send with a send permission

Picture 3. Permission setting on queues.

Overview of SAS

Below an excerpt from Shared Access Signatures written by Dan Rosanova (source: https://azure.microsoft.com/en-us/documentation/articles/service-bus-sas-overview/)

I quoted:

“Shared Access Signatures are an authentication mechanism based on SHA-256 secure hashes or URIs. SAS is an extremely powerful mechanism that is used by all Service Bus services. In actual use, SAS has two components: a Shared Access Policy and a Shared Access Signature (often called a token).

You can find more detailed information about Shared Access Signatures with Service Bus in Shared Access Signature Authentication with Service Bus.

Shared Access Policy

I quoted from the same source:

“An important thing to understand about SAS is that it all starts with a policy. For every policy, you decide on three pieces of information: name, scope, and permissions. The name is just that; a unique name within that scope. The scope is easy enough: it's the URI of the resource in question. For a Service Bus namespace, the scope is the fully qualified domain name (FQDN), such as https://<yournamespace>.servicebus.windows.net/.

The available permissions for a policy are largely self-explanatory:

  • Send (used in our scenario)
  • Listen (used in our scenario)
  • Manage
After you create the policy, it is assigned a Primary Key and a Secondary Key. These are cryptographically strong keys. Don't lose them or leak them - they'll always be available in the Azure classic portal. You can use either of the generated keys, and you can regenerate them at any time. However, if you regenerate or change the primary key in the policy, any Shared Access Signatures created from it will be invalidated (see picture x)

When you create a Service Bus namespace, a policy is automatically created for the entire namespace called RootManageSharedAccessKey, and this policy has all permissions. You don't log on as root, so don't use this policy unless there's a really good reason.” 

Note: However, you need the RootManageSharedAccessKey and its key in a connection-string when you want to manage the servicebus from the ServiceBus Explorer!

The policies can be applied per queue, through the configure tab. You can create additional policies and have up to 12 policies attached to it.

Walkthrough

Queues can be created in the Azure Portal and configured afterwards with regards to apply a policy. The policy is configured by selecting a provisioned queue and choose configure tab. On this tab a shared access policy can be added and permission can be specified.


Picture 4. Configure shared access policy and permission setting.
To send a message to a service bus queue from BizTalk a Send Port with the SB-Messaging adapter has to be configured.

Picture 5. Specify the endpoint address i.e. outboundqueue.
In the General Tab the address of the queue is specified by following format as depicted in the screen shot under example:
  • sb:.//mynamespace.servicebus.net/myqueuename/

In the authentication tab you specify the credentials of the SAS i.e. the shared access policy name and key.


Picture 6. Specify the authentication settings.
Note that ACS is still supported, however the preferred way is SAS!

In the third tab you can specify certain properties, which will be skipped in this scenario. The tab deals with brokered message properties that can be set.

When a message is dropped in a folder it will published in the MessageBox and picked up by the subscribing send port configured with SB-Messaging Adapter. The message will be send to the outboundqueue.

Picture 7. Message send to the outboundqueue.

With the Service Bus explorer we can peek into the outbound queue to see if the message is there.


Picture 8. Message inspection using the Service Bus Explorer.

The Service Bus Explorer can also be used in this scenario to send a message to the inbound queue. A BizTalk Receive Port configured with a receive location using the SB-Messaging adapter is listening to this queue.


Picture 9. Send a message using Service Bus Explorer.
 
Once the message is sent we can inspect the folder where the message will be delivered.
Picture 10. Messsage content of the message to be send to the inboundqueue.
 
The receive location is configured with SB-Messaging. In the General Tab the address of the queue is specified by following format as depicted in the screen shot under example:
  • sb:.//mynamespace.servicebus.net/myqueuename/

Picture 11. Specify the endpoint address i.e. inboundqueue.
 
In the authentication tab you specify the credentials of the SAS i.e. the shared access policy name and key.


Picture 12. Specify the authentication settings.
 
Note that ACS is still supported, however the preferred way is SAS!

In the third tab you can specify certain properties, which will be skipped in this scenario. The tab deals with brokered message properties that can be promoted.

See Also

Read suggested related topics:

Another important place to find an extensive amount of BizTalk related articles is the TechNet Wiki itself. The best entry point is BizTalk Server Resources on the TechNet Wiki.