Exportar (0) Imprimir
Expandir todo

Acciones de enrutamiento y respuesta: eliminación de discrepancias de protocolo

Actualizado: febrero de 2015

Las discrepancias de protocolo se producen cuando el remitente y el receptor de un mensaje operan en protocolos de mensaje distintos. En un escenario de Servicios de BizTalk típico en el que hay puentes, un remitente de mensaje envía un mensaje al puente. El puente procesa el mensaje y lo envía al receptor del mismo. Esto significa que la discrepancia de protocolo debe eliminarse en dos instancias:

  • Primero, cuando el mensaje se envía al receptor. Esto es válido tanto para el Puente unidireccional XML como para el Puente de solicitud y respuesta XML, ya que en ambos casos el mensaje se tiene que enviar a un receptor de mensaje. Esto se conoce como acción de enrutamiento.

  • Secundo, cuando el mensaje de respuesta recibido del receptor del mensaje se envía de vuelta al remitente del mensaje. Esto es válido solo para el Puente de solicitud y respuesta XML, dado que hay que enviar de vuelta al remitente del mensaje una respuesta únicamente para este puente. Esto se conoce como acción de respuesta.

Las acciones de enrutamiento y de respuesta operan sobre las propiedades que se han definido en la fase de enriquecimiento.

Centrémonos en un escenario para saber cómo se puede usar la acción de enrutamiento para realizar una discrepancia de protocolo. Según el escenario, se debe enviar un mensaje POX (Plain Old XML)/REST al servicio WCF (que espera un mensaje SOAP) mediante un Puente unidireccional XML. El mensaje que se envía a un puente es una carga XML simple y carece de encabezados. Por otra parte, el mensaje saliente al servicio WCF debe tener encabezados SOAP definidos. Para eliminar esta discrepancia de protocolo con un puente, la persona que configure el puente usa la acción de enrutamiento para asignar algunos encabezados de mensaje SOAP relevantes (como Action, MessageID, etc.) al mensaje saliente. Tras configurar e implementar el puente en el CmdLets, se envía un mensaje POX al puente. Después de procesar el mensaje, pero antes de enrutarlo al servicio WCF, los encabezados especificados en la acción de enrutamiento del puente se marcan en el mensaje y, luego, este se envía al servicio WCF, es decir, se elimina la discrepancia de protocolo. Para configurar una acción de enrutamiento, consulte The Routing Action.

En la siguiente tabla se refleja el modo en que los valores de propiedad entre fases intermedias (o el destino) de un Proyecto de servicio de BizTalk se pueden transferir mediante acciones de enrutamiento:

 

De/A A otros puentes A colas y temas A extremos de servicio externo o retransmisión

Desde un puente

Las propiedades no se pueden transferir tal cual (pares clave-valor), pero se pueden pasar asignándoles valores de encabezados de mensaje saliente (HTTP o SOAP).

Las propiedades se pueden transferir tal cual (pares clave-valor) y también se pueden pasar como valores de encabezados de mensaje saliente

Las propiedades no se pueden transferir tal cual (pares clave-valor), pero se pueden pasar asignándoles valores de encabezados de mensaje saliente (HTTP o SOAP). Sin embargo, dependerá del diseñador del puente garantizar que se pasan los encabezados relevantes que pueda usar el servicio externo o de retransmisión.

La acción de respuesta es idéntica a la acción de enrutamiento. La única diferencia es que, mientras que la acción de enrutamiento es aplicable cuando un mensaje se envía al receptor de mensaje deseado (ya sea en un Puente unidireccional XML o en un Puente de solicitud y respuesta XML), la acción de respuesta es aplicable cuando el mensaje de respuesta procedente de un receptor del mensaje debe enrutarse de nuevo al remitente del mensaje (solo en el caso de un Puente de solicitud y respuesta XML).

Para entender esto de mejor forma, solo tenemos que invertir el escenario que usamos con la acción de enrutamiento. Imaginemos que el remitente del mensaje necesita enviar un mensaje SOAP a un servicio REST que espera un mensaje POX/REST, mediante un Puente de solicitud y respuesta XML. El mensaje que se envía al puente es un mensaje SOAP con todos los encabezados relevantes. El puente, antes de enrutar el mensaje al servicio REST, elimina implícitamente los encabezados de mensaje y envía únicamente la carga XML al servicio REST. La respuesta procedente del servicio REST es también un mensaje POX. Antes de que el mensaje de respuesta POX se envíe de vuelta al remitente del mensaje, la acción de respuesta marca los encabezados de mensaje del mensaje POX y, luego, envía el mensaje con envoltura SOAP al remitente del mismo. Para configurar una acción de respuesta, consulte Puente de solicitud y respuesta XML: Configuración de la acción de respuesta antes de enrutar el mensaje de la respuesta.

En la siguiente tabla se refleja el modo en que los valores de propiedad se pueden volver a transferir desde un puente al cliente que envió el mensaje mediante acciones de respuesta:

 

De/A A otros puentes A extremos de servicio externo o retransmisión

Desde un puente

Las propiedades no se pueden transferir tal cual (pares clave-valor), pero se pueden pasar asignándoles valores de encabezados de mensaje saliente (HTTP o SOAP).

Las propiedades no se pueden transferir tal cual (pares clave-valor), pero se pueden pasar asignándoles valores de encabezados de mensaje saliente (HTTP o SOAP). Sin embargo, dependerá del diseñador del puente garantizar que se pasan los encabezados relevantes que pueda usar el servicio externo o de retransmisión.

Aun cuando sea posible usar acciones de enrutamiento y de respuesta para definir las propiedades de encabezado de un mensaje, es preciso tener en cuenta los siguientes aspectos:

  • Debe tener cuidado al utilizar los encabezados de mensajes SOAP To y ReplyTo. El motivo es que el enlace subyacente, como los enlaces de WCF, pueden invalidar estos encabezados de mensaje. Por lo tanto, si la aplicación que usa estos mensajes espera los encabezados de mensaje que se definieron mediante las acciones de enrutamiento y de respuesta, podrían surgir errores inesperados.

  • El encabezado SOAP MessageID no se debe establecer cuando se enrute un mensaje a extremos que usen basicHttpBinding o basicHttpRelayBinding.

Vea también

Mostrar:
© 2015 Microsoft