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 send 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 offer 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. Messages 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 Adapter.
Since Windows Azure is 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 sb://<namespace>.servicebus.windows.net/<name of the queue>/ and for a subscription sb://<namespace>.servicebus.windows.net/<name 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 prefetch count 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. See also 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 of 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: https://<namespace>-sb.accessscontrol.windows.net/
Specifying the address of a relay endpoint is similar to SB-messaging. The URI will contain namespace, standard part of the DNS name being servicebus.windows.net and name of the endpoint: http(s)://<namespace>.servicebus.windows.net/<name of the relay endpoint>/ (BasicHttpRelay) or sb://<namespace>.servicebus.windows.net/<nameof 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.
Maheshkumar S Tiwari edited Revision 50. Comment: Minor formatting
Steef-Jan Wiggers edited Revision 48. Comment: Changed title
Steef-Jan Wiggers edited Revision 44. Comment: Fixed Typo's
Steef-Jan Wiggers edited Revision 42. Comment: Added labels
Steef-Jan Wiggers edited Revision 41. Comment: Added resource link
Steef-Jan Wiggers edited Revision 40. Comment: Added resource link
Steef-Jan Wiggers edited Revision 39. Comment: Added resource links
Steef-Jan Wiggers edited Revision 38. Comment: Added resource link
Steef-Jan Wiggers edited Revision 37. Comment: Added new resource links
Steef-Jan Wiggers edited Revision 36. Comment: Added resource link
As always... fantastic article!
Steef-Jan Wiggers edited Revision 35. Comment: Added resource links
Steef-Jan Wiggers edited Revision 34. Comment: Added resource link