Cycle de vie d'un message

L'illustration suivante fournit une vue d'ensemble détaillée de l'architecture BizTalk Server au niveau messagerie.

BizTalk Server

Dans cette vue simplifiée, un message est reçu par le biais d'un emplacement de réception défini dans un port de réception donné. Ce message est traité par l'emplacement de réception, puis publié dans la base de données MessageBox, le principal mécanisme de persistance et de routage de BizTalk Server. Le MessageBox évalue les abonnements actifs, puis achemine le message aux orchestrations et ports d'envoi disposant d'abonnements correspondants. Les orchestrations peuvent traiter le message et publier des messages via le MessageBox sur un port d'envoi à partir duquel il sera poussé vers sa destination finale.

Les composants clés suivants sont impliqués dans le traitement des messages BizTalk Server.

Ports de réception et emplacements de réception

Un port de réception est une collection d’un ou plusieurs emplacements de réception qui définissent des points d’entrée spécifiques dans BizTalk Server. Un emplacement de réception est la configuration d’un point de terminaison unique (URL) pour recevoir des messages. L'emplacement contient des informations de configuration pour un adaptateur de réception et un pipeline de réception. L’adaptateur est responsable de la partie transport et communications de la réception d’un message. En guise d'exemple, on peut citer les adaptateurs FILE et SOAP, chacun recevant des messages de différents types de sources. Le pipeline de réception se charge de préparer le message en vue de sa publication dans le MessageBox. Un pipeline est une série de composants exécutés dans l’ordre, chacun fournissant un traitement spécifique à un message, comme le déchiffrement/chiffrement, l’analyse ou la validation. Pour plus d’informations sur les pipelines, les ports de réception et les emplacements de réception, consultez Artefacts.

Ports d'envoi et groupes de ports d'envoi

Un port d’envoi est la combinaison d’un pipeline d’envoi et d’un adaptateur d’envoi. Un groupe de ports d'envoi regroupe des ports d'envoi et fonctionne comme une liste de distribution de courrier électronique. Un message envoyé à un groupe de ports d'envoi sera envoyé à tous les ports de ce groupe. Le pipeline d'envoi sert à préparer un message provenant de BizTalk Server en vue de sa transmission à un autre service. L'adaptateur d'envoi se charge d'envoyer réellement le message à l'aide d'un protocole spécifique comme SOAP ou FTP. Pour plus d’informations sur les ports d’envoi et les groupes de ports d’envoi, consultez Artefacts.

Orchestrations

Les orchestrations peuvent s'abonner à des messages (réception) et les publier (envoi) via le MessageBox. Les orchestrations peuvent en outre construire de nouveaux messages. Les messages sont reçus par le biais du mécanisme d'abonnement et de routage présenté précédemment. Lorsque des abonnements sont définis pour les orchestrations, une nouvelle instance est activée et le message est remis, ou, dans le cas d'abonnements d'instance, l'instance est réalimentée si nécessaire et le message est ensuite remis. Lorsque des messages sont envoyés à partir d'une orchestration, ils sont publiés dans la base de données MessageBox de la même manière qu'un message qui arrive sur un emplacement de réception avec les propriétés appropriées et qui est inséré dans la base de données pour être utilisé dans le routage. Pour plus d’informations sur les orchestrations, consultez Artefacts.

Base de données MessageBox

Le cœur du moteur de publication/d'abonnement dans BizTalk Server est la base de données MessageBox. MessageBox se compose de deux composants : une ou plusieurs bases de données Microsoft SQL Server et l’agent de message. La base de données SQL Server assure le stockage permanent de nombreuses choses comme les messages, les propriétés des messages, les abonnements, les états des orchestrations, les données de suivi et les files d'attente hôte pour le routage. Pour plus d’informations sur la base de données MessageBox, consultez La base de données MessageBox.

Hôtes et instance d'hôte

Un hôte est une représentation logique d’un processus Microsoft Windows qui exécute BizTalk Server artefacts tels que les ports d’envoi et les orchestrations. Un hôte instance est la représentation physique d’un hôte sur un serveur spécifique. Un hôte peut être de type In-process, ce qui signifie qu'il est possédé et géré par BizTalk Server, ou être un hôte isolé, c'est-à-dire que le code BizTalk Server s'exécute dans un processus qui n'est pas contrôlé par BizTalk Server. Les services Internet (IIS), qui hébergent la fonctionnalité de réception des adaptateurs HTTP et SOAP, illustrent parfaitement ce qu'est un hôte isolé. Les hôtes sont définis pour un groupe BizTalk Server entier, c'est-à-dire un ensemble de serveurs BizTalk Server partageant une même configuration, des MessageBoxes, des ports, etc. Pour plus d’informations sur les hôtes et les instances hôtes, consultez Entités.

Enregistrement d'un corps de message

Trois méthodes permettent d'enregistrer un corps de message.

À partir des requêtes de la page Hub du groupe de la console MMC d'administration

Cette méthode s'applique aux messages de la base de données MessageBox uniquement.

• Affichez une instance de service.

• Ouvrez la boîte de dialogue Détails de l’instance de service .

• Cliquez sur l’onglet Messages pour afficher la liste des messages associés à cette instance.

• Cliquez avec le bouton droit sur le message, puis cliquez sur Enregistrer.

  -ou-

• Double-cliquez sur le message pour l’ouvrir dans la visionneuse de messages, puis cliquez sur Enregistrer.

À partir du modèle OM (Operations object model)

• Utilisez GetInstance pour récupérer un objet Service Instance.

• Utilisez Instance.Messages [ ] pour énumérer tous les messages auxquels le service instance référence actuellement.

• Utilisez des méthodes sur l’objet de message, telles que Message.BodyPart [ ] et Message.Context [ ] pour y accéder et l’enregistrer.

À partir de DTA

• Récupérez des messages de la DTA à l’aide des appels d’API GetTrackedInstance et GetTrackedmessage .

Voir aussi

Architecture d’exécution