Экспорт (0) Печать
Развернуть все

Route and Reply Actions: Bridging Protocol Mismatch

Обновлено: Ноябрь 2013 г.

Protocol mismatch comes into play when the message sender and message receiver operate on different message protocols. In a typical Службы BizTalk scenario involving мостs, a message sender sends a message to the мост, which processes it 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 and Мост XML «запрос-ответ» 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 «запрос-ответ» because only for this мост 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.

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. 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 мост this protocol mismatch, the persona that configures the мост uses the Route action to assign some relevant SOAP message headers, such as Action, MessageID, etc., to outgoing message. After the мост is configured and deployed to the Служебная шина, a POX message is sent to the мост. After processing the message but before routing the message to the WCF service, the headers specified in the Route action of the мост are stamped on the message and then sent to the WCF service, thus bridging the protocol mismatch. For instructions on how 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 using Route actions.

 

From/To To other мостs To Queues and Topics To Relay or External Service Endpoints

From мост

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 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 or Мост XML «запрос-ответ»), 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 «запрос-ответ».)

To understand this better, 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 «запрос-ответ». The message that is sent to the мост is a SOAP message with all the relevant headers. The мост, 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. For instructions on how to configure a Reply action, see XML Request-Reply Bridge : Configuring the Reply Action Before Routing the Response Message.

The following table lists how the property values can be transferred back from a мост to the message sending client using Reply actions.

 

From/To To other мостs To Relay or External Service Endpoints

From мост

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.

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.

См. также

Основные понятия

What are Bridges?

Корпорация Майкрософт проводит интернет-опрос, чтобы выяснить ваше мнение о веб-сайте MSDN. Если вы желаете принять участие в этом интернет-опросе, он будет отображен при закрытии веб-сайта MSDN.

Вы хотите принять участие?
Показ:
© 2014 Microsoft