Azure Service Bus integration with on-premise BizTalk 2013R2 - Part1

Few months back I came across the integration requirement where one of the Azure component and on-premise systems should exchange the data. We decided to use Azure Service Bus Queue to exchange data between cloud and on-premise systems. Here I will show you quick steps to integrate BizTalk 2013 with Azure Service Bus Queue (classic portal).

Note: I am using the Azure classic portal in this blog Because we configured the queue in the classic portal only. I will share the steps with new Azure portal in my upcoming blog.

Azure Service Bus Queue:
So first of all, open the Azure classic portal - https://manage.windowsazure.com. (I believe you have the required access/subscription to azure portal, if not please contact your organisation azure admin or subscribe for Microsoft free trial)
After opening the portal, click on the Service Bus link  on the left hand side Azure items list. The service Bus link would look like-
[EDIT]
Note: ACS Service Bus authentication feature is neither supported by the classic portal nor by the new Azure portal. If you would like to use this feature for your service bus queues then you can use Azure PowerShell scripts to crate the service Bus queue with ACS authentication.
Manage Service Bus with PowerShell


Now create a new service bus namespace first. This namespace will be part of your service bus queue URL.

It will take few seconds for activation. Once the namespace is available then click on it and create new queue (custom create).
Point to Remember (PTR): If you are integrating the queue with BizTalk 2013 then un-check "Enable Partition" checkbox. this queue feature is not supported by on-premise BizTalk 2013.

Your queue would be ready in few seconds and look like-


Now you have to configure the Shared access policy (SAS) so that other systems can access your newly created queue. Create the shared access policy as the below screenshots and select the permission (Manage/Send/Listen) based on the your usage.


Once the SAS is configured it would look like-
Endpoint=sb://amitsbtest.servicebus.windows.net/;SharedAccessKeyName=SBQSAStest1;SharedAccessKey=xxxxxxxxxxx
This key will be used for configuring BizTalk ports to send/receive the data from this queue.

BizTalk 2013R2:
Thanks to Microsoft BizTalk team, we have the SB-Messaging adapter available out-of-the-box in BizTalk 2013R2 adapter store. We will use the same for this tutorial.

Create a new receive port and a receive location and configure as-
Type (adapter) - SB-Messaging
Receive Handler - your host instance
Receive Pipeline - based on your message type and processing required. I am selecting default XMLReceive pipeline because I am using XML files for this tutorial
Queue URL - URL format should be like- sb://namespaceName.servicebus.windows.net/QueueName
Authentication Type - Shared Access Signature
Issue Name: Your Shared Access policy name
Issue Key: Your SAS key
Leave all other properties to their default value.



Apply the configuration and close the window. You are done here with the receive side configuration. Now your on-premise BizTalk 2013 interface can receive all the new EDI messages from your Azure queue.

Now lets see how to configure the send port to send the data to Azure service Bus Queues.
Create new one way send port and configure as:
Type (adapter) - SB-Messaging
Send Handler - your host instance
Send Pipeline - based on your message type and processing requreid. I am selecting default passthrough pipeline here
Queue (destination) URL - URL format should be like- sb://namespaceName.servicebus.windows.net/QueueName
Authentication Type - Shared Access Signature
Issue Name: Your Shared Access policy name
Issue Key: Your SAS key
Leave all other properties to their default value.

Apply the configuration and close the window. Now your on-premise BizTalk 2013 interface can send the EDI messages from your queue.

Happy Integrating!!