匯出 (0) 列印
全部展開

Route and Reply Actions: Bridging Protocol Mismatch

更新日期: 2013年11月

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.

另請參閱

顯示:
© 2014 Microsoft