Demey Consulting - Freelance WebSphere & MQSeries

Nouveautés MO71 version 7.1

Luc-Michel Demey — 2012-03-17T21:31:25Z

Le SupportPack MO71 est un outil d'administration de réseau MQ développé par IBM et proposé gratuitement aux utilisateurs. (cf un article plus détaillé ici).

La dernière version du MO71 supporte les nouvelles fonctions de WMQ 7.1, et propose quelques "goodies" intéressants :

Foreign Queue Manager
Logical Name

Foreign Queue Manager

Cette fonction permet d'afficher sur la "vue réseau" le statut d'un Queue Manager avec lequel le MO71 n'a aucune connexion, mais qui communique avec un QM défini dans le MO71.

Soit par exemple un Queue Manager LMD01, administré par un MO71 :

Il est connecté au Queue Manager LMD02 par des canaux DQM, mais LMD01 n'est pas "vu" par le MO71 :

LMD02 est par exemple situé sur le serveur d'un partenaire auquel le MO71 n'a pas d'accès (si la partenaire a mis en place un peu de sécurité). On démarre le canal LMD01.LMD02 …

Au bout de quelques secondes, le Queue Manager apparait dans la liste, mais avec une couleur bleue :

Note : penser à cocher "Allow Queue Manager discovery" dans les préférences du MO71. Dans la "vue réseau" du MO71, si on spécifie "Show Foreign Location", on peut afficher le statut des canaux entre LMD01 et LMD02 :

Logical Name

Le Logical Name est une fonction qui permet d'afficher un Queue Manager dans le MO71 sans connaitre son nom.

Par exemple, on sait qu'il y a un Queue Manager sur un serveur en 192.168.66.6, que le port du listener est 14146, mais on ne connait pas son nom.

La solution consiste à définir dans le MO71 un Queue Manager "bidon" :

Nom : toto (par exemple)
en cochant la case "Logical name en haut à droite

Le Queue Manager "toto" est maintenant visible dans la liste :

Si on regarde les détails du Queue Manager "toto", on voit qu'il se nomme en fait LMD03 :

En revenant sur la liste, le Queue Manager LMD03 est maintenant affiché, et même s'il est en gris, il est possible de le manipuler comme tout autre queue manager :

Plus d'informations : info2012 demey-consulting.fr ou Tél. : +33 608 755 655

Version PDF de cet article :


Nouveautés MO71 version 7.1

Fin de support WebSphere MQ version 6

Luc-Michel Demey — 2012-01-11T17:41:00Z

WebSphere MQ version 6 est disponible depuis Juin 2006. La fin de support (EOS), initialement annoncée par IBM en Septembre 2011, a été reportée au 21 Septembre 2012.

WebSphere MQ version 7.0 est disponible depuis Juin 2008, tandis que la version 7.1 est disponible depuis Novembre 2011.

Si votre réseau MQ est encore en version 6, il est important de monter le niveau afin de rester dans la fenêtre du support pour ce produit.
Par contre, la question qui peut se poser, c'est vers quelle version migrer ?

La 7.0 est maintenant largement rôdée, et apporte avec le RefreshPack 7.0.1 des fonctions intéressantes comme le Queue Manager multi-instance, ou la reconnexion automatique du client MQ.

La version 7.1 apporte une grande amélioration de la gestion de la sécurité (pas seulement côté SSL) et permet de s'affranchir de certaines limites de la 7.0.1 en ce qui concerne le multi-instance sous Windows. Il est également possible d'installer la 7.1 en "cohabitation" avec la 7.0 sur le même serveur, pour effectuer une migration progressive. Enfin, MQ 7.1 va surtout bénéficier au fil de l'eau de nouvelles fonctions apportées sous forme de RefreshPacks.

Vers quelle version faut-il migrer vos serveurs encore en MQ version 6 ?

Cela dépend bien entendu de chaque entreprise, et la décision finale vous appartient, mais voici quelques éléments de réflexion si vous n'avez pas encore entamé cette migration.

Si votre réseau MQ ne comporte qu'un nombre réduit de serveurs (5 par exemple), il peut être pertinent de migrer directement en MQ 7.1, avec par exemple le planning suivant :

Avril 2012 : passage de l'environnement de test / recette en version 7.1
Mai 2012 : tests de non régression
Juin 2012 : Migration en MQ 7.1 de l'environnement de production.

Même si MQ 7.1 est encore un peu jeune en ce mois de janvier, d'ici à Juin deux niveaux de fixes seront disponibles qui corrigeront les éventuels bugs de jeunesse.

Si par contre vous disposez d'un réseau MQ conséquent, il est urgent de valider une nouvelle version en environnement de test, afin de pouvoir commencer la migration de la production courant mai.

Dans ce cas, une montée vers la version 7.0.1 est peut-être préférable, le risque de tomber sur un bug non corrigé en 7.1 étant d'autant plus important qu'il y a beaucoup d'applications à tester.

Quelle que soit la cible retenu, l'essentiel est de viser une fin de migration avant la période d'été, car tout le monde sait qu'en été que le temps passe plus vite et les projets avancent plus lentement !

Depuis de nombreux mois, j'ai effectué pour mes clients de nombreuses migrations vers la version 7.0.1, à partir de MQ 5.3 ou de MQ 6.0. Depuis Décembre 2011, je suis intervenu pour aider des clients à migrer depuis MQ 6 et même MQ 7.0 vers MQ 7.1.

Si vous souhaitez un accompagnement dans ce type de migration, n'hésitez pas à me contacter.

Migrer depuis WebSphere Application Server version 6.1

Luc-Michel Demey — 2012-01-02T18:51:06Z

Migrer en WAS 7 ou en WAS 8 ?

Il y a aujourd'hui 3 versions majeures de WebSphere Application Server disponibles :

WAS 6.1, annoncé en 06/2006
WAS 7.0, annoncé en 10/2008
WAS 8.0, annoncé en 06/2011

On pourrait presque y ajouter WAS 8.5 (alias Liberty), pré-annoncé depuis plusieurs mois et disponible en beta.

Il y a un peu moins d'un an, IBM a annoncé la fin de support de WAS 6.1 pour Septembre 2011 : Discontinuance of Support for IBM WebSphere Application Server V6.1

Tous les utilisateurs de WAS 6.1 doivent donc planifier la migration de leurs environnements avant cette date. Etant donné qu'il se passe en général peu de choses pendant les mois d'été, et/ou qu'un projet (même de migration) a souvent un peu de retard dans le planning, il est prudent de viser Juin 2012 pour la fin de cette migration.

Migrer certes, mais vers quoi ?

Il y a 6 mois, la réponse était évidente : vers WAS 7.0. Il y a trois mois également.

Maintenant, si on considère que WAS 8 a déjà bénéficié d'un premier fix pack (8.0.0.1) en septembre, que le 2ième ne devrait plus tarder, et qu'à la date cible de la fin de migration, WAS 8 aura un an, la réponse "Migrer vers WAS 7.0" n'est plus aussi évidente.

Migrer de WAS 6.1 vers 7.0 permet d'utiliser une version de WebSphere éprouvée, qui a déjà fait ses preuves depuis plus de 2 ans, sur laquelle de nombreux bugs ont déjà été corrigés (10 niveaux de fixes depuis la sortie.

Migrer de WAS 6.1 vers 8.0 permet d'atteindre tout de suite le dernier niveau technologique de Java (pour certains développeurs c'est important), avec une charge liée à la migration qui devrait être du même ordre qu'une cible WAS 6.1.

Alors, quelle cible choisir ?
Il n'y a pas de réponse unique, chaque société doit évaluer la situation en fonction de ses propres critères, et en particulier du support des versions de WAS par les éditeurs de progiciels.

Mais ce qui est certain, c'est que la question est ouverte, et que WAS 7.0 n'est pas la seule réponse possible à la migration des WAS 6.1 à effectuer au premier semestre 2012.

Présentation WMQ 7.1 Guide MQ du 15/11/2011

Luc-Michel Demey — 2011-11-15T22:05:29Z

Vous trouverez ci -dessous les documents présentés à la réunion du 15/11/2011 du Guide MQ :

Présentation WebSphere MQ 7.1
Présentation originale de la conférence de Berlin


Présentation WMQ version7.1


What's new in WebSphere MQ 7.1

Bonne lecture !

Les nouveautés de WebSphere MQ version 7.1

Luc-Michel Demey — 2011-10-13T14:27:07Z

(En direct de la conférence WebSphere de Berlin)

Multi-version / Cohabitation / Migration

Possibilité d'installer simultanément plusieurs copies de WMQ, dans des répertoires distincts.
Les différents WMQ peuvent être au même niveau, à des niveaux de correctifs différents (7.1.0.0 et 7.1.0.1 par exemple), à des niveaux de version différents (7.0 et 7.1 par exemple). Le niveau de MQ 7.0.1 est au minimum 7.0.1.6.
Chaque QM est rattaché à une "installation" de WMQ et peut être ainsi "migré" de la 7.0.1.6 à la 7.1 très rapidement.
La migration vers MQ 7.1 peut être faite depuis MQ V6, MQ V7.0, MQ V7.0.1
gskit 8 intégré - s'installe dans les répertoires MQ (plus de risque d'interférences avec une autre installation du GSKit)

Sécurité des canaux

Le filtrage des accès par les canaux est maintenant possible. Cette nouvelle fonction est très riche :

Nouvel objet MQSC : Channel Authentication Record
Permet de spécifier comment seront traitées les connexions entrantes :
- DQM
- Clients MQ
- Telnet sur le port du listener
Réglages possibles :
- Autoriser la connexion
- Autoriser la connexion et assigner un MCAUSER
- Refuser la connexion
- Refuser la connexion si utilisateur "privilégié" (MUSR_MQADMIN, mqm, ...)
- Autoriser / Refuser en fonction :
  - de l'adresse IP source
  - du DN du certificat SSL
  - ...

QM multi-instance Windows

Il n'est plus nécessaire que les systèmes soient contrôleurs de domaine comme en MQ 7.0.1

Sécurité des objets

Les commandes setmqaut peuvent maintenant être passées sous formes de commandes MQSC : SET AUTHREC
Intégration du SupportPack MD05 (Role Based AUthorities Wizard) dans l'explorateur MQ 7.1
Possibilité de donner des droits sur des files éloignées —> plus nécessaire de donner les droits sur la XmitQ ou sur la SYSTEM.CLUSTER.TRANSMIT.QUEUE.

Extraction de la config d'un QM

Une nouvelle commande (dspmqcfg) apporte la même fonction que le MS03 (saveqmgr)

Divers

Ajout du paramètres BATCHLIMIT sur les canaux (idem BATCHINT, mais s'applique au volume échangé)
Possibilité pour un client MQ de récupérer ses paramètres de connexion via un LDAP (remplace MQSERVER, CCDT, ...)
Disponibilité d'un client MQ pour système i
Possibilité de connaitre le niveau de version d'un QM partenaire ou d'un client connecté via un canal (si le partenaire est au moins en MQ 7.1)
Explorateur WMQ : embarque une version réduite d'Eclipse (moins d'espace disque)
Sous Windows, les paramètres MQ ne sont plus dans la registry mais dans le qm.ini et le mqs.ini (comme Unix)
Intégration de WebSphere MQ Telemetry (ex SCADA)
Intégration de WebSphere MQ Low Latency

et encore plein d'autres choses, en particulier sur les nouveaux Shared Message Data Sets (SMDS) pour Shared Queues (MQ z/OS).

Ce qu'il n'y a pas

Utilisation de l'Installation Manager pour l'installation de MQ
Un outil de gestion des logs (type MS62) intégré dans le produit de base

Disponibilité :

11/11/2011 pour la version téléchargeable et l'Infocenter
25/11/2011 pour la version CD

10 ans déjà !

Luc-Michel Demey — 2011-07-14T22:00:00Z


10 ans !

Il y a exactement 10 ans commençait l'aventure "Demey Consulting".

Après 14 ans dans une multinationale de l'informatique (IBM) et 3 ans chez un petit éditeur de logiciels, j'ai choisi de monter ma propre structure.

Au cours de ces 10 années, j'ai eu l'opportunité de mener des projets passionnants, qui m'ont fait voyager aux 4 coins de l'Europe et au delà (Angleterre, Belgique, Luxembourg, Suisse, ... et même Maroc et Tunisie).

J'interviens essentiellement sur la gamme de logiciels IBM WebSphere, en particulier Application Server, WebSphere MQ, Portal et Broker.

Si mon secteur économique d'intervention est majoritairement Banque / Finance (ABN Amro, BNPPA, Crédit Agricole, ING Direct, LCFR, Natixis, Oséo, UBS, ...), la Distribution/Logistique (Autotrans, Conforama, Darty, Geodis), et l'industrie (Arkéma, Ricoh, SKF, Toshiba) sont également très présentes.

Les projets menés ont été de toutes de taille : de 3 à 200 jours, à temps plein ou partiel, à travers trois types d'activités :

une majorité de régie
des missions d'audit et d'architecture au forfait
une activité centre de formation

Dans ces projets, il y a de l'architecture technique, des migrations vers les dernières versions de WMQ et WAS, des audits de production et de sécurité, de l'industrialisation de déploiement, du monitoring, ...

J'ai eu la chance d'intervenir sur quelques "premières" technologiques :

1ere mise en œuvre de MQ / SSL en Europe, avec WMQ 5.3 CSD4
1ere mise en production en France d'un lien ME WAS 6.1 / WMQ 6

Parmi les "beaux" dossiers que j'ai eu à traiter, on peut citer :

Migration WAS 7 / WMQ 7 / Commerce 7 d'une grosse infrastructure e-commerce avec évolution vers une architecture multi-cellules
Déménagement d'un data center WAS (30 instances) avec arrêt minimum de la production
Migration d'un environnement Portal 5 sous Windows vers Portal 6 sous Linux
Upgrade WMQ 5.3 vers WMQ 7.0 d'une grosse infrastructure MQ (plus de 100 instances) sans arrêt de la production
Sécurisation SSL de réseaux WMQ bancaires
Déploiement industriel d'infrastructures WAS (avec CIP, fichiers de réponse, scripts jython, ...)
Etude et mise en œuvre de solutions Haute Disponibilité pour WAS et WMQ

L'activité de centre de formation, d'abord sur WebSphere MQ et plus récemment sur WebSphere Application Server, a représenté 200 jours / élève, par groupes de 3 à 8 personnes. Ces filières sont complémentaires de celles proposées par l'éditeur, car leur granularité permet de traiter des besoins non couverts par ailleurs. Je suis également sous-traitant d'IBM Formation (en Franc et en Suisse) pour des sessions WMQ 7 et WAS 7 sur supports IBM.

La veille technologique occupe une part importante de mon temps. Chaque année, je participe à la conférence WebSphere (Vienne, Barcelone, Hambourg, Dusseldorf ces dernières années, Berlin en 2011). J'assiste également aux workshops proposés aux partenaires IBM pour découvrir les nouvelles offres.

Bref, ces dix ans, c'est à peine si je les ai vu passer. En route pour les 10 suivantes !

Audit d'architecture WebSphere MQ

Luc-Michel Demey — 2011-01-26T18:40:38Z

Un nouveau module dans l'offre Demey Consulting :

L'audit d'architecture WebSphere MQ (WMQ Architecture Assessment)

Objectif : Evaluer la mise en œuvre d'une solution WMQ

L'objectif est d'évaluer la mise en œuvre du logiciel WebSphere MQ sur un réseau existant, vis à vis des recommandations de l'éditeur du logiciel, des bonnes pratiques généralement constatées, et des retours d'expérience observés dans des configurations de même type.

Cette intervention se déroule en 3 ou 4 phases :

Phase 1 : Recueil d'éléments sur le réseau MQ existant
Cette phase se déroule en général dans les locaux du client, via des relevés sur les systèmes concernés, et des interviews des personnes en charge de l'administration de l'environnement.
Durée : Entre 0,5 et 3 jours suivant la complexité du réseau étudié.

Phase 2 : Analyse des éléments obtenus en phase 1
Cette phase peut se dérouler dans les locaux du client ou hors site.
Durée : Entre 0,5 et 2 jours suivant la complexité du réseau étudié.

Phase 3 : Rédaction d'un rapport
Cette phase se déroule en général hors site.
L'objectif est de formaliser les résultats de l'analyse de la phase 2, en mettant en évidence les points forts et les points d'attention de la configuration analysée.
Si nécessaire, un plan d'action est proposé pour faire évoluer les éléments présentant un problème.
Durée : Entre 0,5 et 2 jours suivant la complexité du réseau étudié.

Phase 4 : Présentation des conclusions au comité DSI (optionnel)
Cette phase permet de présenter, sous forme de Powerpoint, une synthèse des éléments du rapport de la phase 3.
Durée : 1/2 journée (+ 1/2 journée de préparation).

La fiche technique du workshop :


Audit d'architecture WebSphere MQ

Plus d'informations : info2011 demey-consulting.fr ou Tél. : +33 608 755 655

Meilleurs Voeux pour 2011 !

Luc-Michel Demey — 2010-12-31T23:05:00Z

Cliquez sur l'image pour voir l'animation ...

Workshop Sécurité & SSL Websphere MQ

Luc-Michel Demey — 2010-12-07T07:50:00Z

Un nouveau module dans l'offre Formation Demey Consulting :

Workshop Sécurité & SSL Websphere MQ

L'objet de ce workshop est de former les participants à la sécurité sur WMQ, en particulier par la mise en œuvre du « setmqaut » et des certificats SSL. Il s'adresse à des personnes connaissant déjà WebSphere MQ. Il n'y a pas de rappel sur les fonctions de base.

Ce workshop de 2 à 3 jours est constitué de présentations magistrales (PowerPoint et paperboard), et de travaux pratiques, idéalement sur l'environnement à protéger. Il peut être facturé comme Formation ou Transfert de compétence.

La fiche technique du workshop :


Workshop Sécurité & SSL Websphere MQ

Plus d'informations : info2011 demey-consulting.fr ou Tél. : +33 608 755 655

Persistence des messages

Luc-Michel Demey — 2010-12-06T14:57:57Z

La "persistance" d'un message MQ peut être vue comme un niveau de service, un indicateur de l'importance de ce dernier.

Un message désigné comme "persistant" bénéficiera d'une haute protection par MQ, afin de garantir sa livraison, ceci au dépend de consommation CPU et disque plus importantes que pour le message non persistant. Point intéressant, lors de son redémarrage, le Queue Manager purge tous les messages non persistants présents dans les files.

Des messages d'interrogation de solde, de stock (et les réponses) seront probablement non persistants. Un message de commande, de virement, ... seront très probablement persistants.

Mais comment rendre un message MQ "persistant" ?

Il y a légende tenace qui veux que la persistance d'un message soit celle de la file d'attente dans laquelle il se trouve, certains parlent même de "files persistantes". C'est faux (enfin, presque ...)

Lors du MQPut, l'application qui dépose le message peut spécifier dans le MQMD trois valeurs pour le champ "Persistence" :

MQPER_PERSISTENT : le message sera persistant
MQPER_NOT_PERSISTENT : le message sera non persistant
MQPER_PERSISTENCE_AS_Q_DEF : Dans ce dernier cas, l'application utilise la valeur du paramètre DEFPSIST de la file dans laquelle est déposée le message :
- YES : le message sera persistant
- NO : le message sera non persistant (valeur par défaut)

Dans le cas du DQM (Distributed Queue Management), la file d'où est extrait la valeur de la persistance est dans l'ordre :

la file alias
ou alors la file éloignée
ou enfin la XmitQ

La logique et les bonnes pratiques font que c'est l'application (et non l'infrastructure) qui doit décider si le message est ou non persistant.

Dans le cas d'une application qui ne renseigne pas le champ "Persistence" du MQMD (et c'est mal !), celui-ci est renseigné avec la valeur par défaut MQPER_PERSISTENCE_AS_Q_DEF. C'est donc la première file rencontrée qui donnera sa persistance au message. Et si cette file a conservé ses valeurs par défaut (DEFPSIST NO), le message sera non persistant.

Quelque soient les valeurs DEFPSIST des autres files dans lesquelles le message est amené à passer, ce dernier gardera la persistance initiale qui lui a été attribué lors du MQPut.