Utilisation de plusieurs continuations
L'utilisation de l'Éditeur de modèle de suivi dans des environnements dans lesquels il existe plusieurs activités vous demande de comprendre le scénario dans lequel ces activités sont suivies pour que vous puissiez mapper les ports de réception, les orchestrations et les ports d'envoi dans le bon ordre.
Dans un modèle de suivi, l'Éditeur de modèle de suivi évalue automatiquement le début et la fin de l'activité. L'activité démarre lors de la collecte des premières données et termine lors de la collecte des dernières.
Dans la plupart des cas, la création d'une seule continuation, comme une continuation entre deux orchestrations, est un processus simple pour les développeurs. L'Éditeur de modèle de suivi s'avère complexe dans le cas de continuations multiples. Un scénario de continuation multiple est où une activité bam (Business Activity Monitoring) s’étend sur plusieurs ports de réception, orchestrations et ports d’envoi. Pour pouvoir collecter les données BAM dans un seul enregistrement, vous devez créer des continuations entre toutes les planifications BizTalk Server. Ce processus peut s'avérer compliqué lorsqu'il est réalisé via l'interface utilisateur de l'Éditeur de modèle de suivi.
Cette rubrique décrit comment créer des continuations simples et multiples dans différents scénarios.
Description du scénario de base : ports de réception, orchestrations et ports d'envoi multiples
Ce scénario implique un serveur BizTalk disposant de plusieurs ports de réception, orchestrations et ports d'envoi. Une propriété de contexte interchangeID générique est utilisée pour lier les continuations. Vous pouvez utiliser n'importe quelle propriété de contexte, comme activityID ou tout autre identificateur unique. Le choix d'un contenu particulier n'est pas associé à l'étude de ce scénario.
Dans le cadre de ce scénario, l'étude de l'élément de données/l'étape majeure/le contexte-propriété-valeur suivis à partir de ces ports et orchestrations n'est pas traitée. Cette partie du mappage est propre à la logique d'entreprise. L'objectif est de capturer toutes les données BAM de tous les ports et orchestrations sur une seule ligne dans la table d'activité finale. Les différents modes de réception et de traitement d'un message par les orchestrations présentent des défis et solutions très intéressants.
Notes
Le scénario d'un port ou d'une orchestration peut être considéré comme un cas spécial du scénario des ports et orchestrations multiples.
Solution du scénario 1 : un port de réception et une orchestration
Dans ce scénario, un message arrive sur exactement un seul des ports de réception et est traité par une seule orchestration.
Pour créer la continuation, procédez comme suit :
Créez une continuation dans l'arborescence d'activité de dossier du modèle de suivi.
Choisissez le schéma de propriété de contexte en cliquant sur le bouton Sélectionner la source d’événement , puis sur l’élément de menu Sélectionner une propriété de contexte .
Recherchez la propriété interchangeId dans la liste Nom de la propriété de contexte , puis sélectionnez-la.
Dans le schéma de propriété, mappez interchangeID sur le dossier de continuation que vous venez de créer.
Cliquez avec le bouton droit sur le nouveau nœud interchangeID dans l'arborescence, puis sélectionnez les ports d'origine du mappage.
Dans la boîte de dialogue Sélectionner des ports qui s’affiche, sélectionnez tous les N ports de réception.
Créez un dossier ContinuationID dans l'arborescence d'activité.
Ouvrez chaque orchestration en cliquant sur le bouton Sélectionner la source d’événement , puis en cliquant sur l’élément de menu Sélectionner une planification d’orchestration . À partir de chaque orchestration, cliquez avec le bouton droit sur une forme de l'orchestration, puis mappez la propriété de contexte interchangeID au nouveau dossier continuationID.
Dans un déploiement contenant trois orchestrations, votre modèle de suivi ressemblerait à ceci :
Solution du scénario 2 : un port de réception et plusieurs orchestrations
Dans ce scénario, un message arrive sur exactement un seul des ports de réception et est traité par chaque orchestration. Ceci ce produit car le message est envoyé simultanément à chacune des orchestrations.
Dans ce cas, nous avons besoin d'une continuation et d'un continuationID pour chaque orchestration. Le processus de création des continuations est similaire aux étapes décrites dans la solution de scénario 1. Pour un déploiement à trois orchestrations, votre profil de suivi résultant ressemble à ceci :
Solution du scénario 3 : routage basé sur le contenu
Ce scénario définit une solution de routage basé sur le contenu. Un message arrive sur exactement un seul des ports de réception et est envoyé à un seul port d'envoi. Ce routage a lieu en fonction de la valeur de la propriété de contexte du message. Dans ce cas, une seule continuation est nécessaire. Le mappage ressemble à ceci :
Notes
Le mappage ci-dessus est également valable pour un message qui arrive sur exactement un seul des ports de réception et qui est envoyé à tous les ports d'envoi.
Solution du scénario 4 : une orchestration, plusieurs ports d'envoi
Dans ce scénario, il existe plusieurs envois. . Un message est traité exactement par l’une des orchestrations, qui est déterminée par les règles de traitement, et est envoyé à tous les ports d’envoi. Dans ce cas, une seule continuation est nécessaire. Le mappage ressemble à ceci :
Solution du scénario 5 : orchestrations séquentielles
Dans ce scénario, un message est traité par chaque orchestration, une par une, dans l'ordre, puis est transmis à l'orchestration suivante via la continuation. Le mappage ressemble à ceci :
Collecte de données dans un environnement asynchrone
Lorsque vous configurez les continuations, la fonction BAM attend l'arrivée des données. Dans un environnement asynchrone, vous ne pouvez pas recevoir de réponse provenant d'un processus principal.
Si vous ne recevez pas les données de réponse, l'instance de l'activité attend indéfiniment. L'activité ne s'arrête jamais et les enregistrements restent dans les tables de la base de données d'importation principale BAM. Prenez le cas des transactions à long terme, où il n'est pas possible de connaître le moment d'arrivée des données. Il n'y a pas de délai d'expiration, puisque l'arrivée des données dépend de la logique ou des processus d'entreprise, après quoi l'activité est marquée comme étant terminée. Les données peuvent arriver le jour même, ou dans de rares cas, l'année suivante.
La solution est d'utiliser des activités connexes.
Séparez votre activité en deux activités distinctes. Liez les deux activités entre elles, et liez la réponse à l'activité initiale.
Pour plus d’informations sur les activités associées, consultez Relations d’activité.