Dans la première partie de cet article, nous avons vu le principe de la corrélation et des scénarios d’utilisation. Dans cette seconde partie nous allons aborder la mise en œuvre pratique.
La corrélation comment ?
Les conditions de routage des messages dans Biztalk s’appuient systématiquement sur les propriétés promues du contexte du message. Le processus de corrélation n’échappera donc pas à cette règle…
Les propriétés de corrélation …
La première étape est de déterminer quelles seront les propriétés qui devront avoir une valeur particulière pour que les messages soient acheminés vers la bonne instance d’orchestration. Parmi ces propriétés on peut trouver :
· Des données du message qui ont été promues. Par exemple un numéro de commande ou un numéro de client
· Des propriétés « system » maintenues par Biztalk : le port par lequel a été reçu le message, le type de message,…
· Des propriétés propres à notre application présentes uniquement dans le contexte du message. Par exemple un identifiant de commande calculé (code client +date), un numéro de traitement interne …
Reprenons le scénario précédent de traitement de commande :
- L’orchestration reçoit une commande
- Elle envoie la commande en fabrication
- Elle attend une notification de livraison
- Elle attend une notification de facturation
Les messages traités par l’orchestration sont les suivants :
Commande :
Notification de livraison :
Notification de facturation :
Une commande sera ici identifiée par un numéro de client et un numéro de commande. Ce sont ces informations qui permettront d’acheminer les notifications de livraison et de facturation vers l’orchestration.
L’étape suivante va consister à s’assurer que les informations de routage (numéro de client et numéro de commande) sont promues dans le contexte de chacun des messages. Pour ce faire, il est nécessaire de créer un schéma de propriété. Ce schéma contiendra deux propriétés :
Il ne reste plus qu’à associer chaque schéma de message au schéma de propriété, et à promouvoir les informations d’identification. Pour ce faire :
- Sur chacun des schémas on affiche les promotions (Click droit : Promote / Show promotions )
- Puis on sélectionne notre schéma de propriété et on effectue la promotion du numéro de commande et du numéro de client :
A la fin de cette étape chaque schéma comporte une promotion pour le numéro de client et le numéro de commande (Remarquez au passage, que les noms des champs dans le message peuvent être différents de ceux des propriétés de contexte) :
Correlation type et Correlation set
Les opérations que nous venons d’effectuer permettent à Biztalk d’appliquer des règles de routage basées sur le numéro de commande ou le numéro de client, mais ne lui permettent pas de savoir quelles propriétés doivent avoir quelles valeurs pour qu’un message soit acheminé vers une instance d’orchestration précise.
L’orchestration doit définir quelles seront les propriétés qui doivent être analysées afin de lui acheminer les messages. Ceci s’effectuera par la création d’un Correlation Type : dans l’orchestration view :
Lors de la création on précise les propriétés sur lesquelles sera effectuée la corrélation :
Une fois la liste des propriétés définie nous avons besoin d’une variable qui contiendra les valeurs de ces propriétés quand elles seront connues (dans notre cas après envoi de la commande en fabrication). Cette variable est un correlation set .
On définit le correlation set dans l’orchestration view :
Ensuite, on précise son type (en l’occurrence le correlation type créé précédemment) :
Initialisation du correlation set et mise en place des souscriptions :
Les deux dernières étapes pour mettre en place la corrélation dans notre orchestration sont les suivantes :
- Nous devons récupérer le numéro de commande et le numéro de client et initialiser notre correlation set avec ces valeurs
- Nous devons également préciser que nous attendons des notifications de livraison et de facturation pour ce client et cette facture
Ceci se fait très simplement en modifiant des propriétés des receive shape et send shape :
L’envoi de la commande en fabrication va nous permettre d’effectuer la première étape (initialiser le correlation set). Cela est fait à l’aide de la propriété « Initializing Correlation Sets » dans laquelle nous sélectionnons notre correlation set:
La seconde étape est de préciser sur la réception des notifications livraison et facturation le correlation set à appliquer. Cela se fait tout aussi simplement avec la propriété « Following Correlation Sets ») :
La corrélation est maintenant en place et notre orchestration attendra les bonnes notifications.
Les sous-orchestrations et les ports auto-corrélés
Nous venons de voir l’implémentation de l’un des scénarios les plus courants de corrélation.
Nous avons, dans la première partie de cet article, évoqué un autre scénario très courant : le démarrage de plusieurs sous orchestrations et l’attente de leurs réponses. Ce scénario utilise bien sûr la corrélation mais avec une implémentation différente. Nous allons voir ici comment la mettre en œuvre.
Comment fonctionne un démarrage d’orchestration ?
Avant d’aller plus loin, voyons pourquoi dans notre cas il s’agit bien de corrélation de message.
Lors du démarrage d’une orchestration, les deux orchestrations ne dialoguent jamais directement.
En effet la start shape génère un message ExecMessage qui est posté dans la messageBox. Ce message déclenche la création d’une nouvelle instance de la sous orchestration, et l’initialisation de ses paramètres d’appel. La sous orchestration s’exécute et peut renvoyer des messages à l’orchestration appelante au travers d’un processus de corrélation.
Les propriétés de corrélation …
Dans ce scénario nous n’aurons pas à les définir. Le message ExecMessage contiendra les propriétés à promouvoir dans la réponse afin d’acheminer le message vers l’orchestration appelante (NB : Ces propriétés sont passées dans une MessagePart ).
Les correlation type et les correlation set …
Nous pourrions les définir, mais dans notre cas nous allons utiliser un port dit « auto-corrélé » ce qui nous permet de nous en affranchir.
La mise en œuvre
Mettre en place ce mécanisme de corrélation est extrêmement simple. Tout d’abord il nous faut configurer la sous orchestration :
Pour pouvoir envoyer nos messages de réponse à l’orchestration principale, nous ajoutons dans les paramètres de l’orchestration, un port :
Ensuite nous le configurons comme un port « classique » : On précise son nom, sa direction et son type de port :
Nous avons maintenant au niveau de notre sous orchestration, un port que nous pouvons utiliser pour renvoyer des messages à l’orchestration principale. Notez ici que, s’agissant d’un paramètre de type port, nous n’aurons aucune action de « binding » à effectuer dans la console d’administration (pour cette sous orchestration).
L’étape suivante consiste à configurer l’orchestration principale :
Dans celle ci nous devons créer un port pour recevoir les réponses. Bien évidemment ce port sera du même type que celui de la sous orchestration (les messages échangés sont identiques). Toute l’astuce est dans le choix du mode de binding du port : ici nous choisissons « Direct / Auto corrélé » :
Enfin, il ne nous reste plus qu’à appeler la sous orchestration (à l’aide de la « shape » start) en lui passant en paramètre notre port de réception :
Quelques briques Biztalk pour la corrélation : Listen, Parallel Actions & Delay
Dans notre boîte à outils Biztalk, il y a 3 shapes qui sont essentiellement destinées à être utilisées dans les scénarios de corrélation. Il s’agit de :
Listen :
Delay :
Et Parallel Actions :
Delay et Listen :
Ces deux briques sont le plus souvent utilisées ensembles. En effet, elles permettent de gérer le cas où une réponse n’a pas été reçue dans un délai imparti. Dans tous les scénarios où une réponse est attendue par une orchestration, il est important de gérer le cas où cette réponse n’arrive jamais. On utilisera pour cela quasi systématiquement un Listen associé à un receive et un delay. Cela permet de gérer les cas d’erreur. On pourra ainsi fixer un délai maximum de réponse (que ce délai soit de l’ordre de l’heure, la journée ou la semaine,…). On aura alors typiquement le type d’implémentation suivant :
Listen permet également d’implémenter les scénarios dans lesquels on peut recevoir différents types de réponse :
Parallel Actions
Cette shape est souvent mal utilisée : les développeurs pensent qu’elle est sert dans des scénarios de « Multi-Threading » : ce n’est nullement sa vocation. Elle est essentiellement utilisée pour permettre de recevoir des messages différents qui peuvent arriver dans n’importe quel ordre. Supposons, par exemple, que pour pouvoir émettre une facture il nous faille recevoir un acquittement de livraison et un règlement : ces deux éléments arriveront mais pas forcément dans un ordre précis. On utilisera alors Parallel Actions :
Un cas particulier : les convois
Pour achever cet article sur la corrélation, il reste un sujet particulier à aborder : il s’agit de ce que l’on appelle les convois. Je ne prétends pas ici donner une explication détaillée (On pourra, le cas échéant, se reporter à l’excellent article de Stephen W. Thomas disponible sur technet : http://technet.microsoft.com/en-us/library/ms942189.aspx).
Qu’est ce qu’un convoi ?
Comme le nom le laisse sous entendre, il s’agit d’un lot de messages qui ont des caractéristiques communes, et qui doivent être traités « ensembles ». En pratique cela signifie que l’on souhaite traiter ces messages dans une seule instance d’orchestration.
Les « caractéristiques communes » de ces messages seront, bien sur, des propriétés promues sur lesquelles on effectuera une corrélation.
Qu’elle est la différence avec une corrélation classique ?
Dans un scénario de corrélation classique, on envoie un message et on attend une ou plusieurs réponses. Dans le cas des convois, il n’y a pas d’envoi initial : les messages arrivent, et une seule instance d’orchestration doit être démarrée par convoi.
Ceci n’est pas une tâche simple puisque Biztalk doit pouvoir détecter que l’orchestration est initialisée par un convoi, et ne pas démarrer plusieurs instances quand plusieurs messages arrivent en simultané.
Pour ce faire il existe un certain nombre de patterns à respecter en fonction du type de convoi à traiter.
Quels sont les types de convoi ?
Il existe trois types de convoi :
- Les convois parallèles
- Les convois séquentiels uniformes
- Les convois séquentiels non uniformes
Un convoi parallèle est un convoi dans lequel les messages arrivent dans n’importe quel ordre.
A contrario, un convoi séquentiel est un convoi où les messages sont attendus dans un certain ordre.
Enfin, on distingue les convois uniformes et non uniformes en fonction du fait qu’ils sont constitués des mêmes types de message ou non.
Remarque : Un convoi parallèle uniforme est équivalent à un convoi séquentiel uniforme.
Comment les implémente-t-on ?
Pour l’implémentation de ces convois il suffit de respecter quelques règles simples.
Convoi parallèle :
Le convoi parallèle s’implémente avec une shape Parallel Actions comme suit :
La shape Parallel Actions est placée au début de l’orchestration. Elle contient les receive shapes pour chaque type de message du convoi. Toutes les receive shapes ont les propriétés suivantes :
· Activate à True
· Initializing Correlasion Set pointant vers le correlation set associé au convoi
Convoi séquentiel non uniforme :
Le convoi séquentiel non uniforme est une succession de réception :
Les points importants à noter sont :
- Les réceptions se font sur le même port, sur des opérations différentes
- Seule la première réception est marqué « Activate True »
- La première réception initialise le correlation-set
- Les réceptions suivantes, suivent le correlation-set
Convoi séquentiel uniforme :
Le convoi séquentiel uniforme est une simplification du convoi séquentiel non uniforme puisque, dans ce cas, on utilise qu’une seule opération au niveau du port :
D’autres articles sur le sujet :