Actions de routage et de réponse : pallier aux incompatibilités de protocoles

Mis à jour: juillet 2015

Des incompatibilités de protocoles entrent en jeu quand l'expéditeur et le récepteur d'un message utilisent des protocoles de message différents. Dans un scénario BizTalk Services standard impliquant des ponts, un expéditeur envoie un message au pont. Le pont traite le message puis l'envoie au récepteur du message. Cela signifie que les incompatibilités de protocoles doit être palliées par un pont au niveau de deux instances :

  • Premièrement, quand le message est envoyé au récepteur du message. Ceci s'applique aussi bien à un pont unidirectionnel XML qu'à un Pont demande-réponse XML, car dans les deux cas le message doit être envoyé à un récepteur de message. Ceci porte le nom d'action de routage.

  • Deuxièmement, quand le message de réponse est renvoyé par le récepteur du message à l'expéditeur du message. Ceci s'applique uniquement à un Pont demande-réponse XML, car une réponse doit être renvoyée à l'expéditeur du message seulement pour ce pont. Ceci porte le nom d'action de réponse.

Les actions de routage et de réponse fonctionnent toutes sur les propriétés que vous définissez à l'étape d'enrichissement.

Considérons un scénario qui nous aidera à comprendre comment une action de routage peut être utilisée pour générer des incompatibilités de protocoles. Conformément à ce scénario, un message POX (Plain Old XML)/REST doit être envoyé à un service WCF (qui attend un message SOAP) via un pont unidirectionnel XML. Le message qui est envoyé à un pont correspond à une charge utile XML simple et ne possède pas d'en-tête. En revanche, le message sortant destiné au service WCF doit posséder certains en-têtes SOAP. Pour pallier par un pont à ces incompatibilités de protocoles, la personne qui configure le pont utilise l'action de routage pour attribuer au message sortant certains en-têtes de message SOAP pertinents, tels que : Action, MessageID, etc. Une fois que le pont est configuré et déployé dans Service Bus, un message POX est envoyé au pont. Après le traitement du message mais avant son routage vers le service WCF, les en-têtes spécifiés dans l'action de routage du pont sont marqués sur le message puis envoyés au service WCF, ce qui pallie aux incompatibilités de protocoles. Pour configurer une action de routage, consultez The Routing Action.

Le tableau ci-dessous montre comment les valeurs des propriétés peuvent être transférées entre les étapes intermédiaires (ou la destination) d'un projet de service BizTalk à l'aide des actions de routage :

 

De/À Vers d'autres ponts Vers des files d'attente et des rubriques Vers des points de terminaison de service de relais ou de service externe

Du pont

Les propriétés ne peuvent pas être transférées en l'état (paires clé-valeur), mais elles peuvent être transmises en étant attribuées en tant que valeurs d'en-tête de message sortant (HTTP ou SOAP).

Les propriétés peuvent être transférées en l'état (paires clé-valeur) et peuvent également être transmises en tant que valeurs d'en-tête de message sortant.

Les propriétés ne peuvent pas être transférées en l'état (paires clé-valeur), mais elles peuvent être transmises en étant attribuées en tant que valeurs d'en-tête de message sortant (HTTP ou SOAP). Toutefois, le concepteur du pont est tenu de garantir la transmission des en-têtes appropriés, qui peuvent être consommés par le service de relais ou le service externe.

Une action de réponse est tout à fait similaire à une action de routage. La seule différence tient au fait qu'une action de routage s'applique quand le message est envoyé au récepteur de message prévu (dans un pont unidirectionnel XML ou un Pont demande-réponse XML), tandis que l'action de réponse s'applique quand le message de réponse provenant du récepteur de message doit être acheminé en retour à l'expéditeur du message (seulement dans le cas d'un Pont demande-réponse XML).

Pour mieux comprendre cela, il vous suffit d'inverser le scénario utilisé pour l'action de routage. Considéré que l'expéditeur doit envoyer un message SOAP à un service REST, qui attend un message POX/REST, via un Pont demande-réponse XML. Le message qui est envoyé au pont est un message SOAP doté de tous les en-têtes appropriés. Avant d'acheminer le message au service REST, le pont retire implicitement les en-têtes du message et envoie uniquement la charge utile XML au service REST. La réponse du service REST est également un message POX. Avant que le message de réponse POX soit renvoyé à l'expéditeur, l'action de réponse ajoute les en-têtes de message au message POX, puis envoie le message doté de l'enveloppe SOAP à l'expéditeur du message. Pour configurer une action de réponse, consultez Create an XML Request-Reply Bridge.

Le tableau ci-dessous montre comment les valeurs des propriétés peuvent être transférées en retour, à partir d'un pont, au client d'envoi du message à l'aide d'actions de réponse :

 

De/À Vers d'autres ponts Vers des points de terminaison de service de relais ou de service externe

Du pont

Les propriétés ne peuvent pas être transférées en l'état (paires clé-valeur), mais elles peuvent être transmises en étant attribuées en tant que valeurs d'en-tête de message sortant (HTTP ou SOAP).

Les propriétés ne peuvent pas être transférées en l'état (paires clé-valeur), mais elles peuvent être transmises en étant attribuées en tant que valeurs d'en-tête de message sortant (HTTP ou SOAP). Toutefois, le concepteur du pont est tenu de garantir la transmission des en-têtes appropriés, qui peuvent être consommés par le service de relais ou le service externe.

Vous pouvez utiliser des actions de routage et de réponse pour définir les propriétés des en-têtes de message, mais vous devez prendre en compte les points suivants :

  • Vous devez être prudent en utilisant les en-têtes de message SOAP To et ReplyTo. En effet, des liaisons sous-jacentes, telles que les liaisons WCF, peuvent remplacer ces en-têtes de message. Par conséquent, si l'application qui consomme ces messages attend les en-têtes de message que vous définissez via les actions de routage et de réponse, cela peut entraîner des erreurs inattendues.

  • Vous ne devez pas définir l'en-tête SOAP MessageID quand vous acheminez un message vers des points de terminaison qui utilisent basicHttpBinding ou basicHttpRelayBinding.

Voir aussi

Afficher: