Suivi de livraison des messages WMQ

Dans un réseau WMQ, il est souvent nécessaire de pouvoir prouver qu’un message a été envoyé et/ou reçu par son destinataire.

L’API WMQ propose en standard des techniques permettant d’assurer ce suivi. Il s’agit :

  • des options de notifications (Report Options)
  • des coordonnées de retour

Les options de notification sont des flags que l’on peut armer dans la zone REPORT du Message Descriptor (MQMQ), et qui génèrent des messages MQ à destination d’une adresse de retour.

L’adresse de retour est constituée d’un nom de file de réponse et d’un nom de Queue Manager, qui sont localisés les zones ReplyToQ et ReplyToQMgr de ce même Message Descriptor.

Les options de notifications sont assez nombreuses, celles qui nous intéressent ici sont les COA (Confirm on Arrival) et le COD (Confirm on Delivery).

Le COA est un message de notification qui est envoyé lorque le message initial arrive dans la file d’attente cible. Le COD lui est envoyé lorsque ce message est consommé par l’application cible.

Dans les deux cas, ces messages de notification sont envoyés à l’adresse figurant dans les zones ReplyToQ et ReplyToQMgr du MQMD.

La définition des options de notification et des coordonnées de retour sont à la charge de l’application qui pose le message. Celle-ci doit renseigner le MQMD avec les valeurs souhaitées.

Options de notification

  • MQRO_COA : Confirm Of Arrival
  • MQRO_COA_WITH_DATA : identique à MQRO_COA, mais avec les 100 premiers octets du message d’origine
  • MQRO_COA_WITH_FULL_DATA : identique à MQRO_COA, mais avec la totalité du message d’origine
  • MQRO_COD : Confirm Of Delivery
  • MQRO_COD_WITH_DATA : identique à MQRO_COD, mais avec les 100 premiers octets du message d’origine

Il est possible de spécifier que l’on souhaite recevoir les notifications de COA et de COD, mais il ne faut spécifier qu’une seule notification dans chaque catégorie.

Par défaut, le Msgid du message d’origine est placé dans le Correlid du message de notification. Il est ainsi possible de suivre l’arrivée et / ou la consommation des messages en exploitant les messages de notification.

Chemin de retour

Lors du dépôt d’un message par une application, la zone ReplyToQ du MQMD est à blanc.
Pour utiliser les options de notification, il faut au minimum renseigner la zone ReplyToQ avec le nom de la file où l’on souhaite recevoir les notifications.

Cette file doit exister sur le QM dont le nom est spécifié dans la zone ReplyToQMgr du MQMD, qui est renseignée par défaut avec le nom du QM local.

Lors de la génération d’un COA ou d’un COD par le QM cible, celui-ci utilise les zones ReplyToQ et ReplyToQMgr du MQMD du message d’origine, pour déposer le message de notification dans une XmitQ de même nom que celui du ReplyToQMgr.

Si la XmitQ porte un nom différent, il faut créer sur le QM cible un QM alias.

Problèmes de droits

Un COA est généré par le QM cible au moment où le message d’origine arrive dans la file d’attente de destination. Ce COA est déposé directement dans la XmitQ, avec le compte utilisateur sous lequel s’exécute le canal receiver, ou avec le compte spécifié dans le paramètre MCAUSER, s’il est renseigné.

Par défaut, le canal receiver s’exécute sous le compte « mqm », donc le message de COA pourra être déposé sans problème dans la XmitQ.

Si le canal receiver s’exécute sous un compte différent, ou si un MCAUSER est positionné, des ajustements seront nécessaires.

Un COD est généré par le QM cible au moment où le message d’origine est consommé. Dans le cas d’une consommation de messages sous contrôle de validation, le COD est généré au moment du COMMIT.
Ce COD est déposé directement dans la XmitQ, avec le compte utilisateur spécifié dans le champ UserIdentifier du MQMD du message d’origine.

A priori, ce compte n’est pas forcément connu coté QM cible, et/ou n’a pas de droits déposer des messages dans la XmitQ. En cas d’utilisation du COD, il faut donc soigneusement planifier les comptes utilisés et leurs différents droits sur les objets MQ.

Mise en œuvre

Le plus simple (dans un premier temps) est d’utiliser le COA.

Au niveau de l’application à l’origine du flux, il faut prévoir les changements suivants au niveau du Message Descriptor (MQMD) du message :

  • Champ ReplyToQ : à renseigner avec le nom de la file où l’on souhaite recevoir le COA
  • Champ ReplyToQMgr : à renseigner avec le nom du QM qui héberge la file de réponse. Par défaut il est renseigné avec le nom du QM d’origine.
  • Champ Report : Spécifier au choix
    • MQRO_COA
    • MQRO_COA_WITH_DATA
    • MQRO_COA_WITH_FULL_DATA

Pseudo Code en C (tiré des exemples livrés par IBM) :

md.ReplyToQ = MQ_Q_NAME;
md.ReplyToQMgr = MQ_Q_MGR_NAME;
md.Report = MQRO_COA;
MQPUT1(Hcon, /* connection handle */
&odR, /* object descriptor */
&md, /* message descriptor */
&pmo, /* default options */
messlen, /* message length */
buffer, /* message buffer */
&CompCode, /* completion code */
&Reason); /* reason code */

_c_2010_Demey_Consulting.png

Version PDF de cet article : Suivi de livraison des messages WMQ