BizTalk Server 2013: New Adapters Series: WCF-NetTcpRelay
This is the second post on new adapters that will be shipped with BizTalk Server 2013. The post is based on BizTalk Server 2013 Beta. In this post I like to demonstrate the WCF-NetTcpRelay adapter.
The WCF-NetTcpRelay adapter can be used with BizTalk to send and receive messages from the Service Bus relay endpoints using the NetTcpRelayBinding. When configuring for instance a request response receive port, you can enable a receive location using the NetTcpRelayBinding. The receive location with contains an address using the “sb” URI scheme. Through the receive location the endpoint (address) will be registered in the Windows Azure Service Bus.
The URI consists of the namespace available in Windows Azure Portal Service Bus. Windows Azure is multitenant and therefore to manage the service bus capacities like relay has to be done through a unique namespace (see Create Namespace section of How to Use the Service Bus Relay Service).
The following scenario will describe a way to send messages to a Service Bus relay endpoint configured through WCF-NetTcpRelay 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. The received message will be routed to an orchestration that will process the message. The response will be send back to the client. Below you will find a diagram that shows the flow of a message from a client (Service Bus Explorer) 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-NetTcpRelay. A receive location in BizTalk Server 2013 can be configured with the WCF-NetTcpRelay Adapter using the "sb" URI scheme. The URI will be used to register the endpoint on the Windows Azure Service Bus. This can be specified through the General tab of WCF-NetTcpRelay Transport properties.
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. In the Security tab you can specify security capabilities of the WCF-NetTcpRelay receive location. Here you can specify the security mode, transport security, client security, discovery mode and access control service.
The transport mode will be Transport, the security is provided through using TLS over TCP or SPNego. Transport security setting is None in this scenario. This means that messages are not signed or encrypted. In case you want to prevent tampering with messages you can sign the message and/or encrypted in case you require date-level privacy; you then have to choose Sign or SignAndEncrypt and specify the message security/service certificate.
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 in 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 final tab called Messages enables you to specify the data selection for the SOAP Body element. In this scenario all settings are as is (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 within the relays tab.
If you disable the receive location and go back to relay tab in Windows Azure Portal and refresh the portal then the endpoint will be disappeared.
The discovery mode has been set to public for the endpoint this means that is also visible through the url https://<yournamespace>.servicebus.windows.net/.
With the relay present in the Service Bus you can send messages to it. Communication with the endpoint in this scenario will be two-way. Therefore message exchange will be request-reply. A message will be send through the Service Bus Explorer tool to the relay endpoint.
This tool created by Paolo Salvatori allows users to connect to a Service Bus namespace and administer messaging entities in an easy manner. It is a great tool to test messaging with for instance relays. You start the explorer, enter the credentials for the namespace in Windows Azure Service Bus you want to connect to, connect and you can manage your namespace.
In this scenario a message will be send to the relay endpoint. The message will contain two numbers (a en b) that will be added together by an orchestration tied to the relay endpoint (receive location) the result be send back to client (Service Bus Explorer). In the pane next to outer left pane you paste the message (payload). This is an instance of the expected message type (schema). In the sender tab you select the appropiate binding e.g. NetTcpRelayBinding.
Besides specifying the binding you can configure the number of messages, enable logging and statistics. In this scenario the logging was enabled to see the result of test. The test can be initiated by clicking start.
To test your endpoint configured through WCF-NetTcpRelay can easily be tested using the Service Bus Explorer. This will save you time in writing a test client.
This was the second 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 BizTalk solution I created for the calculation to relay through the MSDN code gallery. In the next post I will discuss the SB-Messaging.
Cheers,
Steef-Jan
The WCF-NetTcpRelay adapter can be used with BizTalk to send and receive messages from the Service Bus relay endpoints using the NetTcpRelayBinding. When configuring for instance a request response receive port, you can enable a receive location using the NetTcpRelayBinding. The receive location with contains an address using the “sb” URI scheme. Through the receive location the endpoint (address) will be registered in the Windows Azure Service Bus.
The URI consists of the namespace available in Windows Azure Portal Service Bus. Windows Azure is multitenant and therefore to manage the service bus capacities like relay has to be done through a unique namespace (see Create Namespace section of How to Use the Service Bus Relay Service).
The following scenario will describe a way to send messages to a Service Bus relay endpoint configured through WCF-NetTcpRelay 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. The received message will be routed to an orchestration that will process the message. The response will be send back to the client. Below you will find a diagram that shows the flow of a message from a client (Service Bus Explorer) 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-NetTcpRelay. A receive location in BizTalk Server 2013 can be configured with the WCF-NetTcpRelay Adapter using the "sb" URI scheme. The URI will be used to register the endpoint on the Windows Azure Service Bus. This can be specified through the General tab of WCF-NetTcpRelay Transport properties.
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. In the Security tab you can specify security capabilities of the WCF-NetTcpRelay receive location. Here you can specify the security mode, transport security, client security, discovery mode and access control service.
The transport mode will be Transport, the security is provided through using TLS over TCP or SPNego. Transport security setting is None in this scenario. This means that messages are not signed or encrypted. In case you want to prevent tampering with messages you can sign the message and/or encrypted in case you require date-level privacy; you then have to choose Sign or SignAndEncrypt and specify the message security/service certificate.
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 in 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 final tab called Messages enables you to specify the data selection for the SOAP Body element. In this scenario all settings are as is (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 within the relays tab.
If you disable the receive location and go back to relay tab in Windows Azure Portal and refresh the portal then the endpoint will be disappeared.
The discovery mode has been set to public for the endpoint this means that is also visible through the url https://<yournamespace>.servicebus.windows.net/.
With the relay present in the Service Bus you can send messages to it. Communication with the endpoint in this scenario will be two-way. Therefore message exchange will be request-reply. A message will be send through the Service Bus Explorer tool to the relay endpoint.
This tool created by Paolo Salvatori allows users to connect to a Service Bus namespace and administer messaging entities in an easy manner. It is a great tool to test messaging with for instance relays. You start the explorer, enter the credentials for the namespace in Windows Azure Service Bus you want to connect to, connect and you can manage your namespace.
In this scenario a message will be send to the relay endpoint. The message will contain two numbers (a en b) that will be added together by an orchestration tied to the relay endpoint (receive location) the result be send back to client (Service Bus Explorer). In the pane next to outer left pane you paste the message (payload). This is an instance of the expected message type (schema). In the sender tab you select the appropiate binding e.g. NetTcpRelayBinding.
Besides specifying the binding you can configure the number of messages, enable logging and statistics. In this scenario the logging was enabled to see the result of test. The test can be initiated by clicking start.
To test your endpoint configured through WCF-NetTcpRelay can easily be tested using the Service Bus Explorer. This will save you time in writing a test client.
This was the second 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 BizTalk solution I created for the calculation to relay through the MSDN code gallery. In the next post I will discuss the SB-Messaging.
Cheers,
Steef-Jan
Comments