This post was originally published here.
The BizTalk Server 2013 Beta release comes with the SB-Messaging adapter. This adapter allows our on-premise BizTalk environment to integrate seamlessly with the Windows Azure Service Bus queues, topics and subscriptions. Together with my colleague Mathieu, I had a look at these new capabilities.
Adapter Configuration
The configuration of SB-Messaging receive and send ports is really straightforward. BizTalk just needs these properties in order to establish a connection to the Azure cloud:
- Service Bus URL of the queue, topic or subscription:
sb://<namespace>.servicebus.windows.net/<queue_name>
- Access Control Service STS URI:
https://<namespace>-sb.accesscontrol.windows.net/
- Issuer name and key for the Service Bus Namespace
Content Based Routing
Both Service Bus and BizTalk messaging layer offer a publish-subscribe engine, which allows for content based routing. In BizTalk, content based routing is done through context properties, the Azure Service Bus uses Brokered Message properties. A BizTalk context property is a combination of the propertyName and propertyNamespace. In Azure Service Bus, context properties are only defined by a propertyName. How are these metadata properties passed from the cloud to BizTalk and vice versa?
Sending from BizTalk to Service Bus topic
In order to pass context properties to the Service Bus topic, there’s the capability to provide the Namespace for the user defined Brokered Message Properties. The SB-Messaging send adapter will add all BizTalk context properties from this propertyNamespace as properties to the Brokered Message. Thereby, white space is ignored.
Receiving from Service Bus subscription in BizTalk
Also at the receive adapter, there’s the possibility to pass properties to the BizTalk message context. You can specify the Namespace for Brokered Message Properties, so the SB-Messaging adapter will write (not promote) all Brokered Message properties to the BizTalk message context, within the specified propertyNamespace. Be aware when checking the option Promote Brokered Message Properties, because this requires that a propertySchema is deployed which contains all Brokered Message properties.
Receive port message handling
I was interested in the error handling when an error occurs in the receive adapter or pipeline. Will the message be roll backed to the Azure subscription or suspended in BizTalk? Two fault scenarios were investigated.
Receive adapter unable to promote property in BizTalk
In this case, we configured the receive port to promote the context properties to a propertyNamespace that did not contain all properties of the Brokered Message. As expected, the BizTalk adapter threw an exception:
“The adapter “SB-Messaging” raised an error message. Details “System.Exception: Loading property information list by namespace failed or property not found in the list. Verify that the schema is deployed properly.”
The adapter retried 10 times in total and moved afterwards the Brokered Message to the dead letter queue of the Service Bus subscription. Afterwards, BizTalk started processing the next message.
Receive pipeline unable to parse message body
In this simulation we tried to receive an invalid XML message with the XMLReceive pipeline. After the error occurred, we discovered that the message was suspended (persisted) in BizTalk.
WCF adapter framework
It’s a pity to see that this new adapter is not implemented as a WCF-binding. Due to this limitation, we can’t make use of the great extensibility capabilities of the WCF-Custom adapter. The NetMessagingBinding could be used, but I assume some extensibility will be required in order to transform BizTalk context properties into BrokeredMessageProperty objects and vice versa. Worthwhile investigating…
Conclusion
The BizTalk product team did a great job with the introduction of the SB-Messaging adapter! It creates a lot of new opportunities for hybrid applications.
