Self Correlating Port avec Microsoft BizTalk Server

Yolande DESPINASSE
Publié par Yolande DESPINASSE
Catégorie : BizTalk
17/11/2018

Lorsque l’on a besoin de débatcher un fichier dans une orchestration, il faut le faire dans un scope de type atomic afin de garantir la fiabilité de la transaction (respect des propriétés ACID). La contrepartie est qu’il est impossible de faire appel à un autre processus ne respectant pas l’atomicité. Si jamais on doit rajouter des informations sur chaque message débatché, par exemple, la seule solution est d’utiliser des « self correlating ports ».

Pour illustrer notre propos, nous allons utiliser l’API gratuite SWAPI qui regroupe différentes informations sur la saga StarWars comme la liste des personnages, des planètes ou encore des films. On récupère la liste des 10 personnages grâce à l’url https://swapi.co/api/people. Pour chaque personnage est indiqué l’url permettant d’accéder aux informations de sa planète d’origine. Nous souhaiterions avoir dans un même message les informations sur le personnage et le nom de sa planète d’origine.
On va utiliser deux orchestrations : l’orchestration principale qui va récupérer la liste des personnages, la débatcher et envoyer chaque message à des orchestrations secondaires qui, elles, se chargeront de récupérer le nom de la planète et de renvoyer le message complété à l’orchestration principale grâce aux ports « self corrélés ». L’ensemble des messages ainsi obtenu va être ré-agrégé dans un même message nous permettant d’avoir tous les personnages avec pour chacun le nom de sa planète d’origine.

 

Obtention de la liste des personnages avec une orchestration

 

La première étape est d’obtenir la liste des personnages grâce à l’API. La configuration du port se fait dans une shape expression.

 

orchestration get personnage

 

Débatching de la liste des personnages et appel de l’orchestration secondaire

 

Pour débatcher la liste des personnages obtenue, on utilise un scope atomic dans lequel on retrouve l’exécution du pipeline de débatching XMLReceive. Ensuite, une boucle permet de créer un message pour chaque personnage de la liste puis de lancer l’orchestration secondaire en charge de récupérer le nom de la planète de chaque personnage. Comme nous sommes dans un scope atomic, l’orchestration secondaire ne peut être lancée qu’en mode start.

 

debatching message orchestration

 

Mise en place de l’orchestration secondaire

 

L’élément essentiel de l’orchestration secondaire est le port self-corrélé. Pour ce faire, la première étape est de créer un type de port qui renverra le personnage avec le nom de la planète d’origine. Dans l’orchestration il faut créer le port logique qui utilise ce type en prenant bien soin de choisir un binding direct avec l’option Self-Correlating.

 

binding Self correlating

 

Pour que cela fonctionne correctement, il faut que ce port soit référencé dans les paramètres de l’orchestration secondaire et que donc il apparaisse lors de l’appel de cette orchestration secondaire dans l’orchestration principale.

 

Self correlated port parametre

 

Vue d’ensemble de l’orchestration secondaire :

 

orchestraction secondaire

 

Réception des messages complétés dans l’orchestration principale et ré-agrégation en liste

 

Dans l’orchestration principale il est nécessaire d’avoir le port self-corrélé afin de récupérer les messages complétés par les orchestrations secondaires. Ces messages vont ensuite être regroupés dans une liste grâce à l’utilisation d’une shape loop puis envoyés dans un dossier local.

 

self correlating port aggregation

 

Vue d’ensemble de l’orchestration principale simplifiée :

 

self correlating orchestration principale