Azure Service Bus integration with on-premise BizTalk 2013R2 - Part 2

As promised, I am showing the steps for Azure Service Bus preview on the new Microsoft Azure Portal and the service bus queue creation steps here.

So first of all, Login to Azure portal (I believe you have the required access/subscription to azure portal, if not please contact your organisation azure admin and activate your subscription or sign up for free account).

Microsoft recently released the Service Bus Messaging Preview in the new Azure portal. It has been a long awaiting request. This release will help organizations keep their Azure components in one place and manage the Authentication and Authorization accordingly (unlike the classic azure service bus portal). Please visit the Azure documentation to learn more on this.

Coming back to the topic...

After opening the Azure portal, click on the More Services button on the left menu and search for the service bus link. This should look like the below screenshot.

Note: ACS Service Bus authentication feature is neither supported by the classic portal nor by the new Azure portal. If you want to use this feature for your service bus queues then use Azure PowerShell scripts to create the service Bus queue with ACS authentication.
Manage Service Bus with PowerShell

You can see the Service Bus namespace "AmitSBTest" we have created in Azure Service Bus integration with on-premise BizTalk 2013R2 - Part 1. All the service bus namespaces you created in the classic Azure portal will be visible in the new Azure portal. 

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

Enter your service bus namespace (in place of AmitSBtest1) and select Pricing tier, subscription, resource group and cloud location as required. Optionally you can pin it to dashboard.

It will take few seconds for activation. Once the namespace is available then click on it and create new queue.

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-

There are several other properties and configuration settings available for you in the new Azure Portal. You can explore them on the portal itself or visit the Azure Documentation, blogs etc. to learn more about the new Azure Service Bus features.

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.

Azure Service Bus messaging samples on GitHub

BizTalk configuration for the new Azure portal Service Bus queues are same as I described in my earlier blog Part 1

Happy Integrating!

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!!