An Integration Story with Azure Service Bus and BizTalk 2013R2

13 May, 2016 by Naresh Punjabi

A recent Integration project with an enterprise customer provided us with some very good insights on Hybrid Integration. As in any Integration scenario our client's backend system required data exchange with its integration partners over the internet. Our Integration challenge was to ensure that we create a platform that is resilient, flexible & ensures guaranteed delivery. Our solution used the (1) Azure Traffic Manager for Distribution of all synchronous WCF requests and automatic failover in case of outages, (2) Azure Service Bus for receiving asynchronous messages from Trading partners and a (3) BizTalk Environment on Azure IAAS.

Below are some of our learnings from the project and some good practices which can be used in designing an Integration solution which involves the above technologies.

Geographically Distributed Servers: BizTalk servers were created in 2 different Azure data centres. This made the solution highly resilient. An outage in one of the data centres did not impact the overall message processing in the solution. This also helps during any planned maintenance activities when servers are required to be restarted or kept offline. When a server is taken offline Azure Traffic Manager would redirect all the requests to the other BizTalk Node. Also Asynchronous messages received on the service bus queues would continue to be processed with the design patterns explained below. Given below is the physical architecture diagram of the solution.



Primary & Backup Subscribers: Service Bus Topics were created in namespaces which were again distributed in two different data centres. Each Service Bus Topic then had two Receive Ports Subscribing to it. Our Trading partners were free to send messages on any service bus end point. In case if there were issues in connecting to one end point they could then publish the message to the other end point and it will still ensure guaranteed delivery. Below is a diagram that explains this design:



Each Service Bus End point had multiple subscribers. This design of multiple subscribers (SB Receive Port) for a message ensured that a message is immediately processed by a backup subscriber if the primary subscriber fails to connect to the Service bus for any reason.

Azure Service Bus Topics: All messages were received through Azure Service Bus Topics. Topics proved to be of great value particularly in long running orchestrations which asynchronously send messages to trading partners and wait for a response. The partners are free to post the response message on any Service Bus Endpoint in any of the 2 data centres. Topics can then be configured to publish a copy of the message to both the BizTalk servers and thus it can rehydrate the orchestration instance that has a subscription on the response message. We ensured to have a dummy subscription on both environments so if the message comes to the node where there is no subscribing orchestration then it can be consumed and won’t error out as “Suspended” in the Admin console

This approach can also be effectively used for closing BAM activities. In architectures having two independent BizTalk nodes where messages are sent asynchronously and the BAM record requires information from the response, the activity will remain open in Node1 if the response is sent to Node2. Topics can then be used to publish copies of messages to 2 nodes thus closing the activity.

Labels: We used Service Bus Labels effectively to identify the type of message that is dropped in the service bus and then route it accordingly. A partner would send a message on the Service bus end point and label it accordingly. Using the Service Bus Explorer a subscription was created on the Topic based on different types of labels which a trading partner can send. The receive port would then subscribe to the message based on this subscription.

Dead Letter Queues: This is one area which can be a huge performance bottleneck if it is not catered for in the design. There will be occasions when messages would be dead-lettered for a variety of reasons. This queue needs to be trashed regularly or it will significantly impact the performance of the solution. Remember each queue may need only one dead letter subscription but each topic may require multiple dead letter subscriptions (i.e. one dead letter queue for each subscription. So the subscriptions for the queue would be like:


And the dead letter queue subscription for a topic would be as below:


We created receive locations which constantly drained the dead letter queues and raised events in the Event Log. These events were then subscribed by event monitoring tools which informed support teams whenever a message was dead lettered.

Latest Posts