Bonnes pratiques de nommage des objets WebSphere MQ

L’objectif de cet article est de donner les règles de nommage à respecter pour les objets WMQ, et de proposer des normes et des bonnes pratiques, dans l’optique d’un plan de nommage.

Règles de nommage WebSphere MQ

Les règles de nommage à respecter pour les objets MQ sont les suivantes :

  • Objets MQ : 48 caractères maxi
    • Sauf les canaux : 20
    • Sauf les QM sur z/OS : 4
  • Caractères autorisés
    • Uppercase : A-Z
    • Lowercase : a-z
    • Numérique : 0-9
    • Point : « . »
    • Underscore :« _ »
    • Forward slash : « / »
    • Pourcentage : « % »

Les caractères blancs et accentués sont interdits, les noms de type SYSTEM.* sont réservés.

Il faut tenir compte de ces limitations lors de l’établissement du plan et des normes de nommage.

Normes et bonnes pratiques

De manière générale, éviter de mettre le type de l’objet dans le nom :

    • QMxx, QL.xxx, QR.xxx

Inutile d’inclure le nom du Queue Manager dans un nom de file :

    • QM01.QL.INPUT

Il faut préférer les noms en MAJUSCULES (Eviter le mIxEd CaSe), et ne pas hésiter à donner un nom descriptif (sans excès).

Nommage du Queue Manager

Pour le choix du nom du Queue Manager, on peut distinguer 2 cas :

  • La couche MQ est considérée comme faisant partie de l’infrastructure technique
  • La couche MQ est considérée comme faisant partie de l’application

Dans le premier cas, le nom du Queue Manager peut être dérivé du hostname, avec par exemple un suffixe de 1 ou 2 digits.

Dans le deuxième cas, le nom du Queue Manager peut être rattaché au nom de l’application

Si le nom du serveur ou de l’application n’intègre pas la notion d’environnement (Prod, Intégration, UAT, Dv, …), il faut prévoir d’y consacrer un digit (P, I, U, D, …) dans le nom du Queue Manager, par exemple sous forme de suffixe.

Il faut malgré tout essayer de limiter le nom d’un Queue Manager à 9 caractères (cf. nommage des canaux DQM), et surtout s’assurer que le nom d’un Queue Manager est unique dans le réseau.

Nommage des files d’attente applicatives

Si l’application est référencée par un trigramme applicatif, inclure celui-ci dans le nom des files, de préférence en majeur (préfixe). Cette approche est utile pour l’administration des objets et l’affectation des droits MQ.

Inclure également dans le nom de la file le nom de flux

Eviter :

  • d’inclure le nom du QM (portabilité des scripts)
  • d’inclure le type de file (évolution de l’architecture)
  • les noms type FROM.APP1.TO.APP2
  • d’inclure le nom de l’application source du flux

Exemple : TAA.INTERRO1, SWIFT.IN01, CPT2FAC

Nommage des canaux

  • Canaux DQM (canaux QM à QM) :
    • Concaténer le nom du Queue Manager source et le nom du Queue Manager cible, séparés par un point.
    • Exemple : < nom_qm1 >.< nom_qm2 >

Note : Le nom des canaux étant limité à 20 caractères, cette norme nécessite que le nom des Queue Manager soit au maximum de 9 caractères chaque.

  • Canaux Cluster Sender
    • A minima : TO. < nom_qm_cible >
    • Préférer : TO. < nom_cluster > .< nom_qm_cible >
  • Canaux Cluster Receiver
    • A minima : TO. < nom_qm_source >
    • Préférer : TO. < nom_cluster > .< nom_qm_source >
  • Canaux SVRCONN
    • Donner un nom significatif de l’usage : ADMIN, MONITOR, APP01, …

Nommage des autres objets système

  • Dead Letter Queue : DLQ
  • Xmitq : Utiliser le nom du Queue Manager distant
    • Exemple : Xmitq GRP22 pour les flux vers le QM GRP22
  • Listener :
    • Si le listener est unique pour le Queue Manager, on peut l’appeler LISTENER
    • S’il y a de multiples listener, on peut les nommer par fonction : ADMIN, PORTAIL, APP1, … ou LISTENER< n° du port >
    • Exemple : LISTENER1416
  • Initiation Queue : Pour le démarrage automatique des canaux (triggering), utiliser l’INITQ par défaut (SYSTEM.CHANNEL.INITQ).

_c_2010_Demey_Consulting.png