BizTalk Server 2013: New Adapters Series: SB-Messaging
In previous two posts on the new adapters available with BizTalk Server Bus I discussed both the Relay adapters: BasicHttp and NetTcpRelay. The Relay is one of the capabilities of the Windows Azure Service Bus. It enables you to expose WCF Service that resides within your enterprise. Benefit of exposing the service or at least an endpoint (as a listener) in Windows Azure that you do need to open up a firewall connection or make changes your corporate network. You can circumvent issues with NAT or Dynamic IP. With both posts I provided links to Code Gallery to find samples that illustrate the walk-throughs.
Besides the relay service the Windows Azure Service Bus also offers queues, topics and subscriptions. Service Bus Queues offer a brokered messaging similar to on-premise MSMQ. The message can be sent to the queue and a consumer can pick up the message for further processing. The consumer can be a receive port within BizTalk. A receive location within a receive port can be configured using the SB-Messaging adapter that enables communication with a Service Bus Queue.
Above you see a diagram of client sending a message to queue in Windows Azure and then the message is picked up by BizTalk (Message Receiver). Important aspect is the namespace. Since Windows Azure is multitenant as a user of the Service Bus service you need to create a namespace to manage your queues, topics and subscriptions. 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>/
As you see in the screen shot above when configuring the SB-Messaging adapter you have to specify the URL. Besides the URL you can specify the open/close and receive time out settings. The Prefetch Count is an interesting setting. Default 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. I did some experimenting with this setting, see my post Service Bus Messaging: Queues, SB-Messaging Adapter – Part II. I can say from experience that you have to careful with this setting as you can flood BizTalk with messages if set too high.
By selecting the Use Session check box you can use a Service Bus session to receive messages from a queue or a subscription. Kent Weare has created an excellent blog post explaining sessions. The next tab Authentication you can specify a URI for the Service Bus Access Control Service STS endpoint. The format of the URI is:
https://<namespace>-sb.accessscontrol.windows.net/
Besides specifying the URI you also have to specify the Issuer Name and Issuer Key. You can find these through the Windows Azure Portal in the Service Bus Service namespace you manage.
The final tab is the Properties tab. Here you can specify the namespace that the adapter can use to write the brokered message properties as message context properties on the message received by BizTalk Server.
You can select the Promote Brokered Message Properties in case you want to promote the brokered message properties.
The Service Bus Topic is similar to a queue, however with topics you have subscriptions. With subscriptions on a topic you can support a publish/subscribe messaging communication model. You can send messages to multiple consumers (subscribers), while with a queue you can only send messages to one consumer. With topics and subscriptions you can support a multi-cast messaging solution. Both Topic and subscriptions and queues support load-leveling/balancing. Below in the diagram you can see how messages can be sent from a client to a topic. A topic can have a rule that interprets the message properties and allow a message to write to a subscription. Basically a rule is a filter/restriction to determine, which message is allowed by which subscription. Rules are optional as you do not have to set them. In case of a multi-cast solution you write messages to multiple subscriptions.
A receive location configured with SB-Messaging adapter can pick up messages from a subscription. The URL of the subscription consists of
sb://<namespace>.servicebus.windows.net/<name of the topic>/Subscriptions/<name of the subscription>
Configuration of the SB-Messaging is the same as for the queue. The only difference the specification of the URL.
Currently there is a lot of resources available on Service Bus and SB-Messaging with BizTalk:
Cheers,
Steef-Jan
Besides the relay service the Windows Azure Service Bus also offers queues, topics and subscriptions. Service Bus Queues offer a brokered messaging similar to on-premise MSMQ. The message can be sent to the queue and a consumer can pick up the message for further processing. The consumer can be a receive port within BizTalk. A receive location within a receive port can be configured using the SB-Messaging adapter that enables communication with a Service Bus Queue.
Above you see a diagram of client sending a message to queue in Windows Azure and then the message is picked up by BizTalk (Message Receiver). Important aspect is the namespace. Since Windows Azure is multitenant as a user of the Service Bus service you need to create a namespace to manage your queues, topics and subscriptions. 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>/
As you see in the screen shot above when configuring the SB-Messaging adapter you have to specify the URL. Besides the URL you can specify the open/close and receive time out settings. The Prefetch Count is an interesting setting. Default 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. I did some experimenting with this setting, see my post Service Bus Messaging: Queues, SB-Messaging Adapter – Part II. I can say from experience that you have to careful with this setting as you can flood BizTalk with messages if set too high.
By selecting the Use Session check box you can use a Service Bus session to receive messages from a queue or a subscription. Kent Weare has created an excellent blog post explaining sessions. The next tab Authentication you can specify a URI for the Service Bus Access Control Service STS endpoint. The format of the URI is:
https://<namespace>-sb.accessscontrol.windows.net/
Besides specifying the URI you also have to specify the Issuer Name and Issuer Key. You can find these through the Windows Azure Portal in the Service Bus Service namespace you manage.
The final tab is the Properties tab. Here you can specify the namespace that the adapter can use to write the brokered message properties as message context properties on the message received by BizTalk Server.
You can select the Promote Brokered Message Properties in case you want to promote the brokered message properties.
The Service Bus Topic is similar to a queue, however with topics you have subscriptions. With subscriptions on a topic you can support a publish/subscribe messaging communication model. You can send messages to multiple consumers (subscribers), while with a queue you can only send messages to one consumer. With topics and subscriptions you can support a multi-cast messaging solution. Both Topic and subscriptions and queues support load-leveling/balancing. Below in the diagram you can see how messages can be sent from a client to a topic. A topic can have a rule that interprets the message properties and allow a message to write to a subscription. Basically a rule is a filter/restriction to determine, which message is allowed by which subscription. Rules are optional as you do not have to set them. In case of a multi-cast solution you write messages to multiple subscriptions.
A receive location configured with SB-Messaging adapter can pick up messages from a subscription. The URL of the subscription consists of
sb://<namespace>.servicebus.windows.net/<name of the topic>/Subscriptions/<name of the subscription>
Configuration of the SB-Messaging is the same as for the queue. The only difference the specification of the URL.
Currently there is a lot of resources available on Service Bus and SB-Messaging with BizTalk:
- MSDN: Windows Azure Service Bus
- Windows Azure Service Bus Developer Guide
- TNWiki: Windows Azure Service Bus Resources
Cheers,
Steef-Jan
Comments