BizTalk Server 2013 will offer some new adapters: WCF-WebHttp, SFTP,
SB-Messaging, WCF-BasicHttpRelay and the WCF-NetTcpRelay adapters. Some of these adapters will bring the cloud closer to on premise systems. Through the connectivity with the Windows Azure Service Bus you can create hybrid solutions.
The Service Bus can be a bridge between Windows Azure, services or other cloud applications. The Windows Azure Service bus offers entities like Relay, Queues, Notification Hubs, Topics and Subscriptions. The interaction
with these entities is possible with the SB-Messaging,
WCF-BasicHttpRelay and the WCF-NetTcpRelay adapters.
The Windows Azure Service Bus is a durable, high
available and multi-tenant infrastructure that can be leveraged in for instance a store-and-forward scenario. Thousands of messages can be sent from multiple clients to a Service Bus Queue or Topic. BizTalk Server instance(s) can with their own pace
pick up the messages and process them. The queue or topic offers a means of load leveling or balancing if you like. An enterprise does not have to scale-up or out its infrastructure on premise when it can leverage
the Windows Azure Service Bus. It will be a different story when messages need to be processed within a very short time frame in on premise systems.
The Window Azure Service Bus offers relay service (entity) offers connectivity to WCF-endpoints that reside within a corporate enterprise network, without having to open up
a firewall connection or requiring intrusive changes to a corporate network infrastructure. With relay adapters of BizTalk Server 2013 the
boundaries can be pushed to
cloud. This means these endpoints can facilitate an entry point into a process or expose data within LOB-system through the cloud.
The SB-Messaging adapter enables you to send and receive messages from Service Bus entities like Queues, Topics and Subscriptions. These entities offer brokered messaging capabilities similar to on premise MSMQ and the BizTalk pub/sub mechanism.
can be sent to Queues and/or Topics and subscriptions and picked up by BizTalk through a receive location configured with the SB-Messaging adapter or messages can be sent to these entities by BizTalk through a send port configured with the SB-Messaging
Since Windows Azure is a multi-tenant you as a user of the Service Bus service need to create a namespace to manage your queues, topics and subscriptions (see
Service Bus Fundamentals). The namespace plays an essential role, when you configure the SB-Messaging adapter (Address
and Authentication). The URL of the QUEUE consists of
of the queue>/
and for a subscription
of the topic>/Subscriptions/<name of the subscription>/
The Prefetch Count is an interesting setting. You will find this setting on the same tab (General) of the SB-Messaging, where you specify the address of the Queue or Subscription. The default value is –1, yet you can change the setting to
specify the number of messages that are received simultaneously from the Service Bus Queue or a topic. You can find more on
prefetching through MSDN
Best Practices for Performance Improvements Using Service Bus Brokered Messaging.
Note: Setting the
to high can result in throttling in BizTalk Server as more inflight messages will enter BizTalk than can be processed. You might get the following warning:
BizTalk host BizTalkServerApplication throttled because InflightMessageCount exceeded the configured throttling limit.
Service Bus Messaging: Queues, SB-Messaging Adapter – Part II blog post.
With the Use Session check box you can use a Service Bus session to receive messages from a queue or a subscription. You will find this checkbox on the general tab of the SB-Messaging adapter transport properties. A session can be used to
group messages that belong together and can be useful when you for instance want to support FIFO (first in first out) pattern.
The authentication tab on the SB-Messaging adapter is intended to specify a URI for the Service Bus Access Control Service STS endpoint. You have to provide the credentials for authorization of Service Bus. The format of the URI is:
Specifying the address of a relay endpoint is similar to SB-messaging. The URI will contain the namespace, standard part of the DNS name being
servicebus.windows.net and name of the endpoint:
of the relay endpoint>/ (BasicHttpRelay)
the relay endpoint>/ (NetTcpRelay)
With the Binding tab you can configure the time-out and encoding-related properties. Depending on your requirements you can specify different values than the default. See the following resources for the specific details:
The Security Tab offers you the ability to specify the security for the BasicHttpRelay endpoint. You can specify the Security mode to
Transport or TransportWithMessageCredential and the scheme will be “https”. Setting it to none and the scheme will be “http”. By checking the “Enable service discovery” checkbox you can specify
whether the behavior of the service is published in the Service Registry or not. By checking this checkbox the Display name text box and Discovery mode combo box will be enabled. In the text box you can specify the name with which the service is published
to the Service Registry. The Discovery mode can be private or public. Public means publishing in the Service Registry, while private means this will not happen.
The final tab called Messages enables you to specify the data selection for the SOAP Body element. This is a common tab, which you can also find when configuring other WCF-based adapters in BizTalk, see also the
WCF Adapters UI Help.
Steef-Jan Wiggers edited Revision 2. Comment: Added text
Steef-Jan Wiggers edited Revision 20. Comment: Added text Bindings
As always... fantastic article!