Exporter (0) Imprimer
Développer tout

Didacticiel : utilisation de ponts BizTalk Service pour échanger des messages à partir du service de relais Service Bus

Mis à jour: septembre 2014

Ce didacticiel explique comment envoyer des messages XML avec différents schémas vers un point de terminaison de pont unique qui a été déployé à l'aide de Microsoft Azure BizTalk Services. Ce pont traite le message et le redirige vers plusieurs services de relais basés sur la logique métier définie dans le cadre de la solution. Dans le cadre de ce scénario, le didacticiel présente également d'autres fonctionnalités de BizTalk Services telles que :

  • Les filtres de routage : le pont vous permet de router des messages vers le destinataire souhaité sur la base de filtres. Les filtres sont définis sur certaines valeurs qui sont transmises avec le message. Par exemple, si la valeur de l'élément <Destinataire> dans le message XML est définie sur Finance, envoyer le message vers Service A. Sinon, envoyer le message vers Service B. Pour plus d'informations, consultez The Routing Condition.

  • Action de routage : les actions de routage aident à pallier aux incompatibilités de protocoles. Par exemple, prenez deux applications, App A et App B. App A envoie des messages en utilisant le protocole REST tandis que App B reçoit uniquement des messages SOAP. Si en revanche App A envoie le message au pont, le pont inclut des en-têtes SOAP dans le message dans le cadre de l'action de routage. Le pont envoie ensuite le message vers App B. Pour plus d'informations, consultez The Routing Action.

  • Action de réponse : une action de réponse fournit la même fonctionnalité lors du renvoi d'une réponse au client que l'action de routage lors de l'envoi d'un message au récepteur. Par conséquent, si App B envoie une réponse à App A, chaque pont utilise les fonctionnalités d'action de réponse pour horodater la réponse avec les en-têtes nécessaires au client. Pour plus d'informations, consultez Reply Action.

Ce didacticiel décrit les fonctionnalités du pont ainsi que d'autres dans le cadre d'un scénario d'application professionnelle.

Northwind Traders est une entreprise d'assurance automobile. Cette société reçoit une demande pour de nouveaux devis de police d'assurance au format XML qui respecte le schéma de la norme ACORD (une norme pour les messages d'assurances). Les messages entrants peuvent être dans un format quelconque conforme à la norme ACORD. Northwind Traders doit donc configurer une solution capable de traiter les messages XML conformes à plusieurs schémas XML. Après la réception du message par Northwind Traders, celui-ci est validé par rapport aux schémas de message ACORD fournis et transformé en un schéma interne à Northwind. Northwind envoie ensuite le message à un service principal chargé de continuer le traitement du message. Toutefois, certaines conditions de routage doivent être remplies avant de pouvoir envoyer le message au service.

  • Si le montant du devis dans le message est inférieur à 10 000 €, ce dernier doit être envoyé à un service de relais (par exemple, RelayReceiverServiceA). Avant d'envoyer le message au service de relais, un en-tête SOAP appelé QuoteType doit être ajouté à l'en-tête du message. La valeur de cet en-tête doit être définie sur SmallAmounts.

  • Si le montant du devis dans le message est supérieur à 10 000 €, ce dernier est traité comme une demande à haut risque et sera envoyé à un autre service de relais (par exemple, RelayReceiverServiceB). Avant d'envoyer le message au service, un en-tête SOAP appelé QuoteType doit être ajouté à l'en-tête du message. La valeur de l'en-tête doit être définie sur LargeAmounts.

Après avoir reçu le message, les services génèrent une réponse, ajoutent des en-têtes, puis renvoient une réponse au pont. Les services ajoutent les en-têtes suivants :

 

Réponse du service En-têtes ajoutés

RelayServiceA

 

Nom de l'en-tête Valeur de l'en-tête

MsgStatus

Réussite

Eligibility

ApprovedForSmallAmounts

RelayServiceB

 

Nom de l'en-tête Valeur de l'en-tête

MsgStatus

Réussite

Eligibility

ApprovedForLargeAmounts

La réponse du service est au même format que celui des demandes internes à Northwind. Après que le pont ait reçu la réponse, il la transforme selon le schéma de message de réponse conforme aux normes ACORD. Le pont extrait également la valeur de l'en-tête MsgStatus et l'attribue à un élément dans le schéma de réponse. Pour terminer, avant de renvoyer le message au client, le pont ajoute un autre en-tête appelé ProcessingStatus et définit sa valeur sur Terminé. L'illustration suivante décrit ce scénario.

Utilisation de ponts avec des services de relais

Northwind Traders utilise BizTalk Services pour configurer ce scénario sur . Pour que ce scénario fonctionne de bout en bout, Northwind Traders effectue les actions suivantes :

  • L'entreprise crée deux services de relais, RelayReceiverServiceA et RelayReceiverServiceB. RelayReceiverServiceA reçoit les messages dont le montant du devis est inférieur à 10 000 €. RelayReceiverServiceB reçoit les messages dont le montant du devis est supérieur à 10 000 €. Après avoir reçu le message, les deux services génèrent un message de réponse et l'horodatent avec les en-têtes, comme décrit dans le scénario d'application professionnelle.

  • Northwind crée un projet de service BizTalk et ajoute un Pont demande-réponse XML pour traiter les messages XML entrants et envoyer une réponse. Northwind ajoute également un composant de service de relais bidirectionnel pour RelayReceiverServiceA et pour RelayReceiverServiceB.

  • Northwind ajoute les artefacts nécessaires (schémas et transformations) au projet de service BizTalk.

  • Northwind configure le chemin d'accès à la demande du Pont demande-réponse XML pour :

    • configurer l'étape de validation afin de valider les messages XML par rapport aux schémas ACORD ;

    • configurer l'étape d'enrichissement pour promouvoir des propriétés, sur la base desquelles les messages sont routés vers les services principaux ;

    • configurer l'étape de transformation afin de transformer des messages à partir du schéma ACORD vers le schéma interne de Northwind.

  • Northwind configure le chemin d'accès à la réponse du Pont demande-réponse XML pour :

    • configurer l'étape d'enrichissement afin d'extraire l'en-tête MsgStatus que les services de relais ont ajouté au message de réponse ;

    • configurer l'étape de Transformation afin de transformer la réponse en provenance des services de relais en un schéma de message conforme aux normes ACORD. Au cours de cette étape, le pont attribue également la valeur de l'en-tête MsgStatus à un élément dans le schéma de réponse ;

    • configurer l'action de réponse afin d'inclure l'en-tête ProcessingStatus dans le message de réponse envoyé au client.

  • Northwind ajoute deux points de terminaison de relais externes au projet de service BizTalk, qui représentent les deux services de relais, et les connecte au pont Pont demande-réponse XML. Northwind utilise ces connecteurs de routage pour :

    • connecter tous les composants sur l'aire de conception de la Configuration de pont et paramétrer les conditions de filtrage en fonction du montant du devis ;

    • horodater l'en-tête QuoteType du message et définir sa valeur sur SmallAmounts ou sur LargeAmounts selon le service vers lequel le message est routé.

  • Enfin, Northwind déploie les deux services de relais sur Service Bus et le projet de service BizTalk sur BizTalk Services, puis envoie un message au point de terminaison du pont.

Ce didacticiel est rédigé autour d'un exemple, Bridges_RelayServices.zip, qui est disponible dans le cadre du téléchargement dans la galerie de codes MSDN. Utilisez l'exemple et parcourez ce didacticiel pour comprendre comment l'exemple a été généré ou utilisez ce didacticiel pour créer votre propre application. Ce didacticiel cible la deuxième approche de façon à ce que vous compreniez comment cette application a été créée. En outre, autant que possible, le didacticiel est cohérent avec l'exemple et utilise les mêmes noms pour les artefacts (par exemple, schémas, transformations, etc.) que ceux utilisés dans l'exemple.

Même si Microsoft recommande de suivre le didacticiel pour comprendre les concepts et les procédures, si vous souhaitez utiliser l'exemple, voici comment procéder :

  • Téléchargez l'exemple Bridges_RelayServices et apportez les modifications appropriées, notamment spécifier l'espace de noms, le nom de l'émetteur, la clé de l'émetteur Service Bus. Après avoir apporté les modifications nécessaires, générez et déployez l'application.

  • Créez et hébergez les deux services de relais de manière à accepter les messages de demande reçus via le pont.

  • Utilisez l'outil MessageSender inclus dans le package pour envoyer des messages de demande au pont. Consultez les invites de commandes pour les services ainsi que l'outil MessageSender pour déterminer si les messages ont été traités correctement. Si c'est le cas, les schémas de demande et de réponse sont enregistrés dans le dossier \bin\Debug du projet. L'emplacement et le nom des fichiers de message sont également affichés dans les invites de commandes correspondantes.

À partir de l'emplacement de téléchargement de BizTalk Services (http://go.microsoft.com/fwlink/?LinkId=235057), téléchargez et installez le Kit de développement logiciel (SDK) BizTalk Services. Pour obtenir des instructions, consultez Installer le Kit de développement logiciel (SDK) Azure BizTalk Services. L'installation du SDK installe également le modèle de projet de service BizTalk dans Visual Studio. Ce modèle de projet est utilisé pour créer des ponts permettant de valider, de transformer et de router des messages vers différents points de terminaison, comme décrit dans le scénario d'application professionnelle.

Voir aussi

Afficher:
© 2015 Microsoft