Gestion des acquittements (ACK/NACK) dans BizTalk

Contexte

 

Nous avons rencontré dans le cadre d’un projet client le besoin de gérer les acquittements (ACK) ainsi que les non acquittements (NACK) lors de l’envoi d’un message. En effet, nous avons besoin d’avoir un comportement différent en cas de :

1. Bon envoi du message : backup du message + mise à jour d’un flag dans une table Oracle ;
2. Problème lors de l’envoi du message : pas de backup ni de mise à jour de la table Oracle + envoi d’un email.

Dans cet article, nous allons donc aborder le système d’accusé de réception (ACK) proposé par BizTalk. Nous commencerons par la mise en oeuvre de l’acquittement via une orchestration puis terminerons avec une démonstration simple.

 

Mise en place de l’acquittement

 

Avant d’aller plus loin, il est important de souligner que l’on peut tout autant se servir d’un composant de pipeline custom afin de promouvoir la propriété AckRequired (booléen indiquant si l’accusé de réception est requis) et se passer de l’orchestration. Cependant, après différents tests, nous nous apercevons que promouvoir la propriété via un composant de pipeline fonctionne très bien en cas de non acquittement (NACK) mais n’a pas le comportement souhaité quand le message est correctement envoyé (ACK).

C’est pourquoi nous avons décidé de nous tourner vers l’orchestration car dans notre problématique nous avons besoin de gérer à la fois les ACK et les NACK.

 

L’orchestration dans Visual Studio

 

• ReceiveMsg : on récupère le message indépendamment de son type (fichier plat ou XML) ;
• ConstructMsg / MsgAssignement : on réalise une copie du message ;
• SendMsgCopy : on envoie le message en sélectionnant bien la valeur Transmitted correspondant à la propriété Delivery Notification (au niveau du port d’envoi logique) afin d’initialiser la fameuse propriété AckRequired à True ;

 

 

 

 

 

 

 

 

 

 

• Catch Delivery FailureException / Terminate : on met fin au processus si le message transmis n’est pas bien envoyé. Pour info, l’exception est de type
  Microsoft.XLANGs.BaseTypes.DeliveryFailureException ;
• SendBackup : on sauvegarde le message acquitté si et seulement si le message a bien été envoyé au préalable.

 

Exemple

 

Démonstration ci-dessous avec un exemple de flux très simple avec des transports de type FILE. Libre à vous ensuite d’adapter cette gestion des ACK/NACK, le principe restant le même peu importe le type de transport utilisé (SMTP, FTP, SQL…).

 

Configuration BizTalk

Ci-dessous la liste de nos ports :

 

 

Les ports SendPort.ACK et SendPort.NACK ont pour filtres respectifs :

 

 

L’idée étant d’avoir comportement différent en fonction du bon envoi du message.

Binding des autres ports avec l’orchestration :

 

 

Résultat

Enfin, nous allons déclencher le flux avec 3 fichiers dont 1 fichier plat et 2 fichiers XML :

 

 

Observation des propriétés promues AckSendPortName et AckType (générées par la propriété DeliveryNotification=Transmitted dans l’orchestration) :

 

 

Note : la propriété AckType est à ACK si le message parvient à destination et NACK dans le cas contraire.

Ci-dessous les fichiers correspondants au routage des messages d’acquittement :

 

 

Dans notre exemple, ces fichiers sont vides mais témoignent bien de l’accusé de réception. On pourrait tout à fait avoir recours à d’autres types de transport (SMTP, etc.) ainsi qu’utiliser un composant de pipeline custom afin de mettre en place le comportement souhaité.

Les fichiers sauvegardés à l’issue du jeu et dont on est sûr que leur contenu a bien été acheminé :

 

 

Conclusion

 

Comme pouvez le constater, il n’est pas très coûteux et plutôt aisé de mettre en place le système d’accusé de réception (ACK, NACK) proposé par BizTalk qui nous permet d’adopter un comportement différent en fonction du bon envoi du message.