Architecture « publication-abonnement »
Dans une conception publication/abonnement, trois composants entrent en jeu :
Serveurs de publication
Abonnés
Événements
Parmi les serveurs de publication, on peut citer les ports de réception qui publient les messages qui arrivent à leur emplacement de destination, les orchestrations qui publient les messages lorsqu'elles envoient des messages ou lorsqu'elles démarrent une autre orchestration de manière asynchrone et répondent à (ou sollicitent) des ports d'envoi qui publient les messages lorsqu'ils reçoivent une réponse de l'application cible ou du transport.
Dans BizTalk Server, il existe deux types main d’abonnements : l’activation et l’instance. Un abonnement d’activation spécifie qu’un message qui remplit l’abonnement doit activer ou créer une nouvelle instance de l’abonné lors de sa réception. Les ports d'envoi dotés de filtres ou ceux liés à des orchestrations et les orchestrations qui reçoivent des formes dont la propriété Activer est définie sur True sont des exemples d'éléments qui créent des abonnements d'activation. Un abonnement instance indique que les messages qui remplissent l’abonnement doivent être acheminés vers un instance déjà en cours d’exécution de l’abonné. Les orchestrations dotées de ports de réception corrélés et de style requête/réponse en attente d'une réponse de BizTalk Server sont des exemples d'éléments qui créent des abonnements d'instance.
Au niveau de l'information, la différence entre ces deux types d'abonnements réside dans le fait qu'un abonnement d'instance inclut l'ID d'instance unique, stocké dans la table des abonnements de la base de données principale MessageBox. Lorsqu'une instance d'orchestration ou un port de réception termine le traitement, les abonnements d'instance sont supprimés de la base de données MessageBox alors que les abonnements d'activation restent actifs tant que l'orchestration ou le port d'envoi est inscrit.
Création d'abonnements
Les abonnements sont créés par des classes de service dans BizTalk Server répertoriées dans la table adm_ServiceClass de la base de données de gestion BizTalk. Ces services incluent le service de mise en cache des messages In-process et isolés qui est hébergé par le Gestionnaire des points de terminaison et les orchestrations/XLANG hébergées par le sous-service XLANG. Chacune de ces classes de service peut créer des abonnements et recevoir des messages publiés.
Un abonnement est une collection d'instructions de comparaison, ou prédicats, qui impliquent des propriétés de contexte de message et les valeurs spécifiques à l'abonnement. Par exemple, Type de message est une propriété de contexte de messages et de nombreux abonnements la spécifient. Des informations générales sur l'abonnement sont insérées dans la table d'abonnements par l'agent des messages alors que les prédicats spécifiques sont insérés dans les tables suivantes, en fonction du type d'opération spécifié pour l'abonnement :
BitwiseANDPredicates
EqualsPredicates
EqualsPredicates2ndPass
ExistsPredicates
FirstPassPredicates
GreaterThanOrEqualsPredicates
GreaterThanPredicates
LessThenOrEqualsPredicates
LessThenPredicates
NotEqualsPredicates
Pour ce faire, appelez les procédures stockées Bts_CreateSubscription_<application name> et Bts_InsertPredicate_<application name> dans la base de données MessageBox, où <nom de l’application> est le nom de l’hôte BizTalk qui crée l’abonnement.
Quand un port d'envoi est inscrit, le port crée au minimum un abonnement pour tout message avec l'ID de transport de ce port d'envoi dans le contexte. Cela permet au port d'envoi de toujours recevoir des messages qui lui sont spécifiquement destinés. Lorsqu'un port d'orchestration est lié à un port d'envoi particulier, les informations relatives à cette liaison sont stockées dans la base de données de gestion BizTalk. Lorsque des messages sont envoyés de l'orchestration via le port lié au port d'envoi physique, l'ID de transport est inclus dans le contexte de sorte que le message soit acheminé vers ce port d'envoi. Il est cependant important de noter que ce port d'envoi n'est pas le seul port susceptible de recevoir des messages envoyés depuis l'orchestration. Lorsqu'une orchestration envoie un message, le message est publié dans la base de données MessageBox avec toutes les propriétés promues appropriées. Le port d'envoi lié est assuré de recevoir une copie du message, car l'ID de transport figure dans le contexte. Cependant, tout autre port d'envoi, ou orchestration, peut être associé à un abonnement qui correspond également aux propriétés du message. Il est très important de comprendre que chaque fois qu'un message est publié directement dans la base de données MessageBox, tous les abonnés dont les abonnements correspondent recevront une copie du message.
Publication et routage
Une fois qu'un abonnement est créé et activé, il est nécessaire qu'un message soit publié avant que le traitement ne puisse avoir lieu. Les messages sont publiés lorsqu'ils sont reçus dans BizTalk Server d'un des services précédemment mentionnés. Dans le cadre de cette présentation de l'acheminement, nous allons nous concentrer sur les messages reçus dans BizTalk Server via un adaptateur.
Lorsque les messages transitent par le pipeline de réception, des propriétés sont promues dans le contexte du message. Une fois qu'un message est prêt à être publié dans la base de données MessageBox après avoir été traité par l'adaptateur de réception et le pipeline, la première chose qui se produit est que l'agent des messages insère les valeurs des propriétés promues et les valeurs de prédicat à partir du contexte du message dans la base de données MessageBox SQL Server principale. La présence de ces valeurs dans la base de données permet à l'agent des messages de prendre des décisions relatives au routage.
Au cours de l'étape suivante, l'agent des messages demande à la base de données MessageBox principale de rechercher les abonnements correspondant au lot actuel de messages publiés. N'oubliez pas qu'à ce stade, seules les propriétés ont été écrites dans la base de données, ce qui n'est pas le cas des messages. La procédure bts_FindSubscriptions stockée dans la base de données MessageBox interroge les tables d'abonnement et de prédicats et les lie aux propriétés du message stockées pour le lot actuel de messages.
Muni de ces informations, l'agent des messages insère le message une fois dans chaque base de données MessageBox possédant un abonnement en appelant la procédure stockée bts_InsertMessage. La procédure stockée bts_InsertMessage est d’abord appelée avec un ID d’abonnement. Lors de cette première passe, la procédure stockée appelle la procédure stockée int_EvaluateSubscriptions qui est chargée de rechercher les informations détaillées de l’abonnement, de vérifier que le message répond aux exigences de sécurité de l’application en vérifiant que les prédicats de message correspondent aux propriétés de l’application pour l’hôte et d’insérer une référence au message dans la file d’attente spécifique à l’application ou la file d’attente suspendue spécifique à l’application en fonction de l’état. Les ID de message, d'abonnement et de service ainsi que les informations sur l'abonnement sont insérés dans la table de files d'attente propre à l'application pour chaque abonnement trouvé pour cette application. Une fois que les messages sont insérés, les valeurs relatives au lot sont effacées des tables de propriétés et de prédicats du message.
La procédure stockée bts_InsertMessage est ensuite appelée pour chaque partie composant le message. Lors du premier appel, le contexte du message est passé et est ensuite inséré dans la table SPOOL avec les métadonnées relatives au message, telles que le nombre de parties, le nom du composant de corps et l’ID. En outre, le corps du message est inséré dans la table PARTS à l’aide de la procédure stockée int_InsertPart. La procédure stockée bts_InsertMessage est ensuite appelée pour chaque partie restante du message. Ces parties sont simplement transmises à la procédure stockée int_InsertPart en vue d'être enregistrées dans la table des parties.
Lorsque les messages sont acheminés, des références sont ajoutées pour chaque service qui reçoit l'instance spécifique du message et ses parties en insérant des enregistrements dans les tables suivantes :
MessageRefCountLog1
MessageRefCountLog2
PartRefCountLog1
PartRefCountLog2
Ces références empêchent que les messages et les parties ne soient supprimés par des tâches de nettoyage qui s'exécutent régulièrement pour supprimer de la base de données MessageBox les messages qui n'existent plus dans le système. Deux tables sont utilisées pour limiter les problèmes de conflit et de verrouillage.
Le message étant désormais acheminé vers la file d'attente appropriée, stocké dans les tables de files d'attente et des parties, puis référencé dans les files d'attente propres à l'application, il doit être retiré des files d'attente par les instances de l'application. Chaque instance d'hôte possède des threads chargés de retirer les messages de la file d'attente. Ces threads interrogent en permanence la base de données à des intervalles configurés dans la table adm_ServiceClass de la base de données de gestion BizTalk. Cette même table comporte une colonne qui indique le nombre de threads chargés du retrait des messages. Chaque thread appelle la base de données MessageBox et appelle la procédure stockée bts_DequeueMessages_<application> appropriée pour l’application hôte dans laquelle il s’exécute. Cette procédure stockée utilise la sémantique de verrouillage pour s’assurer qu’un seul instance et un thread de file d’attente peuvent fonctionner sur un message dans la file d’attente à un moment donné. L'instance de l'hôte qui obtient le verrou obtient le message. Il est ensuite chargé de la remise du message au sous-service auquel le message est destiné.
Si le service qui reçoit le message est le gestionnaire des points de terminaison, le port d'envoi est alors appelé (ou la partie de réponse d'un port de réception requête-réponse). S'il s'agit du sous-service XLANG/s, une orchestration est créée ou recherchée en vue de traiter l'abonnement, selon qu'un ID d'instance figure ou non dans l'abonnement. Le service libère la référence au message et à sa partie de sorte que si aucun autre service ne comporte des références, les données du message peuvent être supprimées.