BizTalk Server 2013: New Adapters Series: WCF-BasicHttpRelay
In next couple of weeks I like to do a series of blog posts on the new adapters provided in the upcoming release of BizTalk Server 2013. In this post I like to demonstrate the WCF-BasicHttpRelay adapter.
The WCF-BasicHttpRelay adapter can be used with BizTalk to send and receive messages from the Service Bus relay endpoints using the BasicHttpRelayBinding. This is a binding that BizTalk can use to configure endpoints which can communicate with ASMX-based Web services and other services that conform to the WS-I Basic Profile 1.1. The BasicHttpRelayBinding is derived from the standard BasicHttpBinding. However, the key difference between the two is that the BasicHttpRelayBinding can create publicly reachable and, if required, publicly discoverable HTTP listener endpoint listening on the Windows Azure Service Bus, while the BasicHttpBinding listens through the standard HTTP.sys listener on the local Windows computer.
The following scenario will describe a way to send messages to a Service Bus relay endpoint configured through WCF-BasicHttpRelay adapter in BizTalk Server 2013. A message from a client application will be send through the relay in the Windows Azure Service Bus to BizTalk Server. Below you will find a diagram that shows the flow of a message from a client (a feedback application) that will send a message to endpoint registered in Windows Azure Service Bus, which will be relayed through to BizTalk.
BizTalk Server has an endpoint registered in the Windows Azure Service Bus through a receive location that is configured with the WCF-BasicHttpRelay adapter. A receive location in BizTalk Server 2013 can be configured with the WCF-BasicHttpRelay Adapter using the "http" or "https" URI scheme. The URI will be used to register the endpoint on the Windows Azure Service Bus. The URI can be specified in the general tab of the WCF-BasicHttpRelay Transport properties.
WCF-BasicHttpRelay Transport properties General Tab.
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. For this scenario the default values are used.
WCF-BasicHttpRelay Transport properties Security Tab.
When setting the Security mode to Transport or TransportWithMessageCredential the scheme will be “https”. Setting it to none 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. 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.
Finally with the Access control service you can specify the credentials to be used for authorization with the Service Bus in Access control service case you have specified that the Relay Client authentication type is RelayAccessToken. If that is the case then you will have to specify through Access control service (Edit… button) the Issuer name and key.
WCF-BasicHttpRelay Transport properties Messages Tab.
In this scenario all settings are left default.
Enabling the receive location will result in registration of receive location as an endpoint on Windows Azure Service Bus. This will be visible in Windows Azure Portal under the Service Bus your namespace and then relays.
With the relay present in the Service Bus you can send messages to it. Communication with the endpoint in this scenario will be one-way. Therefore message exchange will be fire-and forget. In case the Relay client authentication type is set to none when configuring the adapter your endpoint is accessible for everyone that has knowledge of the endpoint address. With a simple HTTP post I can send an XML message to the endpoint.
The message ends up in BizTalk being published to the MessageBox through Receive Port having a receive location configured with WCF-BasicHttpRelay adapter. A send port will have subscription of the message, which was received through the receive port and will send the message to a file location on the BizTalk machine.
In case the Relay client authentication type is set to RelayAccessToken when configuring the adapter your endpoint is only accessible for those that have the key and have knowledge of the endpoint address.
This scenario shows how with relative ease you can configure a receive port to register an endpoint in Windows Azure Service Bus. This enables you to receive messages into BizTalk to for instance start a process or collect data. In case you register an endpoint in the Windows Azure Service Bus like this then there is an easy way to test it. You can download the Service Bus Explorer by Paolo Salvatori. This great tool enables you to connect to the service bus, browse within you namespace your queues, topics and relays (see my post on Visual Studio Service Bus Explorer versus Standalone Service Bus Explorer). It provides capabilities to test communication with the Windows Azure Service Bus. If I go to the endpoint I created and select the URI I can send a test message to it.
The message will be send to BizTalk through relay in the Windows Azure Service Bus and finally end up in a folder on the BizTalk machine.
To test your endpoint configured through WCF-BasicHttpRelay can easily be tested using the Service Bus Explorer. This will save you time in writing a test client. This was the first of the series on the new adapters that will be available with the upcoming releases of BizTalk Server 2013.
The scenario above was created on a BizTalk Server 2013 Beta Virtual Machine I created on-premise with Windows Server 2008 R2, Visual Studio 2012 and SQL Server 2012. You can download the client I created for sending messages to relay through code gallery. In the series I will discuss the WCF-NetTCPRelay in the next post followed by posts on the SB-Messaging, WCF-WebHTTP and SFTP Adapter.
Cheers, Steef-Jan
The WCF-BasicHttpRelay adapter can be used with BizTalk to send and receive messages from the Service Bus relay endpoints using the BasicHttpRelayBinding. This is a binding that BizTalk can use to configure endpoints which can communicate with ASMX-based Web services and other services that conform to the WS-I Basic Profile 1.1. The BasicHttpRelayBinding is derived from the standard BasicHttpBinding. However, the key difference between the two is that the BasicHttpRelayBinding can create publicly reachable and, if required, publicly discoverable HTTP listener endpoint listening on the Windows Azure Service Bus, while the BasicHttpBinding listens through the standard HTTP.sys listener on the local Windows computer.
The following scenario will describe a way to send messages to a Service Bus relay endpoint configured through WCF-BasicHttpRelay adapter in BizTalk Server 2013. A message from a client application will be send through the relay in the Windows Azure Service Bus to BizTalk Server. Below you will find a diagram that shows the flow of a message from a client (a feedback application) that will send a message to endpoint registered in Windows Azure Service Bus, which will be relayed through to BizTalk.
BizTalk Server has an endpoint registered in the Windows Azure Service Bus through a receive location that is configured with the WCF-BasicHttpRelay adapter. A receive location in BizTalk Server 2013 can be configured with the WCF-BasicHttpRelay Adapter using the "http" or "https" URI scheme. The URI will be used to register the endpoint on the Windows Azure Service Bus. The URI can be specified in the general tab of the WCF-BasicHttpRelay Transport properties.
WCF-BasicHttpRelay Transport properties General Tab.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. For this scenario the default values are used.
WCF-BasicHttpRelay Transport properties Binding Tab.The created channel is SSL-protected if the endpoint URI scheme is “https” and configured through the security tab of WCF-BasicHttpRelay Transport properties.
WCF-BasicHttpRelay Transport properties Security Tab.When setting the Security mode to Transport or TransportWithMessageCredential the scheme will be “https”. Setting it to none 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. 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.
Finally with the Access control service you can specify the credentials to be used for authorization with the Service Bus in Access control service case you have specified that the Relay Client authentication type is RelayAccessToken. If that is the case then you will have to specify through Access control service (Edit… button) the Issuer name and key.
The Access control Service Dialog Box.The final tab called Messages enables you to specify the data selection for the SOAP Body element.
WCF-BasicHttpRelay Transport properties Messages Tab.
In this scenario all settings are left default.
Enabling the receive location will result in registration of receive location as an endpoint on Windows Azure Service Bus. This will be visible in Windows Azure Portal under the Service Bus your namespace and then relays.
With the relay present in the Service Bus you can send messages to it. Communication with the endpoint in this scenario will be one-way. Therefore message exchange will be fire-and forget. In case the Relay client authentication type is set to none when configuring the adapter your endpoint is accessible for everyone that has knowledge of the endpoint address. With a simple HTTP post I can send an XML message to the endpoint.
The message ends up in BizTalk being published to the MessageBox through Receive Port having a receive location configured with WCF-BasicHttpRelay adapter. A send port will have subscription of the message, which was received through the receive port and will send the message to a file location on the BizTalk machine.
In case the Relay client authentication type is set to RelayAccessToken when configuring the adapter your endpoint is only accessible for those that have the key and have knowledge of the endpoint address.
This scenario shows how with relative ease you can configure a receive port to register an endpoint in Windows Azure Service Bus. This enables you to receive messages into BizTalk to for instance start a process or collect data. In case you register an endpoint in the Windows Azure Service Bus like this then there is an easy way to test it. You can download the Service Bus Explorer by Paolo Salvatori. This great tool enables you to connect to the service bus, browse within you namespace your queues, topics and relays (see my post on Visual Studio Service Bus Explorer versus Standalone Service Bus Explorer). It provides capabilities to test communication with the Windows Azure Service Bus. If I go to the endpoint I created and select the URI I can send a test message to it.
The message will be send to BizTalk through relay in the Windows Azure Service Bus and finally end up in a folder on the BizTalk machine.
The scenario above was created on a BizTalk Server 2013 Beta Virtual Machine I created on-premise with Windows Server 2008 R2, Visual Studio 2012 and SQL Server 2012. You can download the client I created for sending messages to relay through code gallery. In the series I will discuss the WCF-NetTCPRelay in the next post followed by posts on the SB-Messaging, WCF-WebHTTP and SFTP Adapter.
Cheers, Steef-Jan
Comments