Route and Reply Actions: Bridging Protocol Mismatch

  • Article

 

Important

Microsoft Azure BizTalk Services (MABS) is being retired, and replaced with Azure Logic Apps. If you currently use MABS, then Move from BizTalk Services to Logic Appsprovides some guidance on moving your integration solutions to Logic Apps.

If you're brand new to Logic Apps, then we suggest getting started here:

Protocol mismatch comes into play when the message sender and message receiver operate on different message protocols. In a typical BizTalk Services scenario involving bridges, a message sender sends a message to the bridge. The bridge process the message and then sends it out to the message receiver. This means the protocol mismatch has to be bridged at two instances:

  • First when the message is sent to the message receiver. This is applicable for both XML One-Way Bridge and XML Request-Reply Bridge because in both cases the message has to be sent to a message receiver. This is called Route Action.

  • Second when the response message received from the message receiver is sent back to the message sender. This is applicable only in XML Request-Reply Bridge because only for this bridge a response has to be sent back to the message sender. This is called Reply Action.

Both Route and Reply actions operate on the properties that you define in the Enrich stage.

Route Action

Let us consider a scenario to understand how Route action can be used to do a protocol mismatch. As per the scenario, a POX (Plain Old XML)/REST message has to be sent to a WCF service (that expects SOAP message) via an XML One-Way Bridge. The message that is sent to a bridge is a simple XML payload and has no headers. On the other hand, the outgoing message to the WCF service must have some SOAP headers defined. To bridge this protocol mismatch, the persona that configures the bridge uses the Route action to assign some relevant SOAP message headers, such as Action, MessageID, and so on to the outgoing message. After the bridge is configured and deployed to the Service Bus, a POX message is sent to the bridge. After processing the message but before routing the message to the WCF service, the headers specified in the Route action of the bridge are stamped on the message and then sent to the WCF service, thus bridging the protocol mismatch. To configure a Route action, see The Routing Action.

The following table lists how the property values can be transferred between intermediary stages (or the destination) of a BizTalk Service project using Route actions:

From/To

To other bridges

To Queues and Topics

To Relay or External Service Endpoints

From bridge

The properties can’t be transferred as-is (key-value pairs) but can be passed on by assigning them as values of outgoing message headers (HTTP or SOAP)

The properties can be transferred as-is (key-value pairs) and can also be passed on as values of outgoing message headers

The properties can’t be transferred as-is (key-value pairs) but can be passed on by assigning them as values of outgoing message headers (HTTP or SOAP). However, it’s the prerogative of the bridge designer to ensure that relevant headers, which can be consumed by the relay or external service, are passed.

Reply Action

Reply action is exactly similar to Route action. The only difference is that while the Route action is applicable when the message is sent to the intended message receiver (either in XML One-Way Bridge or XML Request-Reply Bridge), the Reply action is applicable when the response message from a message receiver has to be routed back to the message sender (only in the case of XML Request-Reply Bridge.)

To understand this better, you can simply reverse the scenario used for Route action. Consider that the message sender needs to send a SOAP message to REST service that expects POX/REST message, via an XML Request-Reply Bridge. The message that is sent to the bridge is a SOAP message with all the relevant headers. The bridge, before routing the message to the REST service, implicitly strips the message headers and sends only the XML payload to the REST service. The response from the REST service is also a POX message. Before the POX response message is sent back to the message sender, the Reply action stamps the message headers on the POX message and then sends the SOAP enveloped message to the message sender. To configure a Reply action, see Configure the Reply Action Before Routing the Response Message.

The following table lists how the property values can be transferred back from a bridge to the message sending client using Reply actions:

From/To

To other bridges

To Relay or External Service Endpoints

From bridge

The properties can’t be transferred as-is (key-value pairs) but can be passed on by assigning them as values of outgoing message headers (HTTP or SOAP)

The properties can’t be transferred as-is (key-value pairs) but can be passed on by assigning them as values of outgoing message headers (HTTP or SOAP). However, it’s the prerogative of the bridge designer to ensure that relevant headers, which can be consumed by the relay or external service, are passed.

Considerations While Setting the Header Properties through Route and Reply Actions

Even though you can use Route and Reply actions to set message header properties, you must consider the following points:

  • You must be careful when using the To and ReplyTo SOAP message headers. This is because the underlying binding, such as WCF bindings, can override these message headers. So, if the application that consumes these messages is expecting the message headers that you set through Route or Reply actions, it might result in unexpected errors.

  • You must not set the MessageID SOAP header when routing a message to endpoints that use basicHttpBinding or basicHttpRelayBinding.

See Also

What are Bridges?