Depuis ces dernières années, les opportunités de projet de conversion ont augmentées et les outils pour mener à bien ce type de projet ont eux aussi été amélioré.

Pour Control-M, l'éditeur BMC Software propose aujourd'hui un Toolkit de migration qui prend en charge de nombreux produits comme $Universe, One Automation, ZEKE, TWS, Autosys, TNG, mais aussi la crontab Unix et le gestionnaire Windows AT de Microsoft.

De mon côté, j'ai mis en place des outillages de renormalisation qui me permettent d'adapter les XML de définitions générés par le toolkit de migration et de les adapter aux normes et standards de l'utilisateur pour optimiser l'exploitabilité de la solution Control-M. Ils offrent aussi la possibilité de pouvoir en exploiter toutes les fonctionnalités et de combler certains raccourcis .

Méthodologie de migration.

Une conversion ne peut pas s'improviser. Elle doit s'appuyer sur une méthodologie projet et sur l'expérience de l'équipe de mise en œuvre. Certains utilisateurs finaux se contente d'acquérir la licence auprès de l'éditeur et confie la migration à leur équipe internes ou à des consultants non expérimentés d'une société de services généraliste. Pour ma part, je dispose d'une importante expérience en la matière, d'une méthodologie éprouvée et d'outillages spécifiques permettant d'accélérer et d'optimiser les phases de conversion.

La formation est une des clés de réussite d'un projet de migration. Les équipes maitrisent la solution source, mais n'ont qu'une connaissance marketing, ou lié à un POC de la solution cible. Une vraie formation permet à tout le monde de parler la même langue.

Risques et contraintes

La migration à 100% n'existe pas. On ne peut pas avec les mécanismes et fonctionnalités d'un ordonnanceur reproduire à l'identique des mécanismes et fonctionnalités d'un autre ordonnanceur. Des adaptations sont obligatoires et constitues le principal risque d'une migration. La charge et la durée de telles adaptations n'est pas facile à évaluer. Il est parfois nécessaire de reprendre manuellement des scripts utilisant les commandes ou des variables propres à l'ordonnanceur source.

La complexité d'une importante conversion réside dans les mécanismes qu'il est parfois nécessaire de mettre en place pour faire communiquer l'ancien et le nouvel ordonnanceur.

La vie des applicatifs rythme celle de l'exploitation. Mises à jour, nouvelles versions ou modifications ponctuelles sont le lot commun et ne permettent pas de longue période de conversion. La période entre le moment où l'on fait un export des données descriptives des traitements dans l'ordonnanceur source et le moment où l'on active ces traitements dans l'ordonnanceur source, s'appelle la période de gel. Car on ne peut plus faire de modifications sur les batchs exportés. L'automatisation des procédures de migration permet de limiter cette période de gel. On peut en effet, continuer la modification sur la source pendant les phases de validations car l'export final sera réalisé quelques heures avant la mise en production sur la cible.

Les contraintes de temps sont parfois négligées dans une phase d'appel d'offre. Les prestataires et fournisseurs sollicités sont tentés de faire rêver leur futur client en lui laissant croire qu'Harry Potter c'est recyclé dans la migration d'ordonnanceurs. L'expérience m'oblige à dire qu'un projet de conversion ne peut pas être réalisé en 3 semaines ! Qu'il s'étale souvent sur plusieurs mois. Mais que commercialement les concurrents ne peuvent pas avancer cet argument, car ils ont peur que leur client ne veuillent pas l'entendre. Lancer un appel d'offre de migration quelques mois ou semaines avant la date anniversaire du renouvellement du contrat de licence de son ordonnanceur n'est pas raisonnable.

Projets et références

Vous connaissez la migration des environnements $Universe de SOCOTEC vers Control-M. Cela avait fait l'objet d'un témoignage au BMC Exchange 2014 que j'avais relayé sur ce blog dans l'article "Migration $U vers Control-M – Témoignage". Le convertisseur a été amélioré et prend en charge aujourd'hui les TIH (environnement complexe spécificité de $U).

Le rachat par Automic de l'éditeur Orsyp a conduit de nombreux clients à s'interroger sur la pertinence d'une migration. En effet, l'architecture Serveur/Agents de One Automation n'est pas identique à celle de $Universe qui implantait un moteur d'ordonnancement sur chaque serveur applicatif. De plus, le mode évènementiel de l'ordonnanceur d'Orsyp n'est pas celui d'Automic.

Je mène en ce moment deux projets de conversion de $Universe vers Control-M avec des volumétries importantes et je suis beaucoup sollicité par des utilisateurs de $Universe pour répondre à des présentations ou des appels d'offre.

Mais le sujet des migrations ne se limite pas à cet ordonnanceur. J'ai migré l'an dernier un environnement Job Scheduler (ordonnanceur open source) vers Control-M. BMC ne propose pas de toolkit, mais la structure au format XML des définitions de cet outil a facilité la conversion. La lourdeur du moteur et de la console de pilotage développés en Java avaient eu raison du client utilisateur.

Pour un autre client, J'ai récemment migré des plateformes NSM vers un Control-M version 8.

L'utilitaire de conversion fourni par l'éditeur m'a bien aidés à dégrossir le sujet. Mais comme il a été avant tout étudié pour convertir du TNG Unicenter et que NSM est l’évolution de ce produit, j'y ai trouvé quelques lacunes. En effet, en plus des actions correctives permettant d'apporter une normalisation adaptée au besoin du client, il m'a fallu compléter les XML convertis en allant récupérer dans les extractions NSM certains paramètres SAP qui n'étaient pas migrés. J'ai aussi transformé en jobs de type SAP BW les process chains qui étaient restées sous la forme d'une commande NSM. J'ai retrouvé une problématique équivalente avec les jobs SAP migrés de $Universe, les paramètres SAP ne sont pas totalement renseignés et nécessitent une adaptation.

A cela, il faut ajouter la conversion des planifications qui n'est pas réalisée car, il n'est pas possible d'extraire les calendriers NSM au format attendu par le Conversion toolkit. Mais la généralisation des Rule Based Calendars qui sont, comme pour $Universe avec les Rules, équivalent aux calendriers utilisés par NSM a permis de simplifier la migration.

Les concepts de NSM, comme ceux de TNG sont appuyés sur des Jobset et des jobs, c’est-à-dire des notions que l'on retrouve dans les Folders et les jobs de Control-M. La notion de montée au plan est là aussi présente dans NSM. Ces bases communes et une bonne formation ont elles aussi facilités la conversion au niveau des utilisateurs.

Si vous souhaitez échanger sur ce sujet, vous pouvez commenter cet article ou me contacter par mail. Je vous répondrais avec plaisir.

Et oui, vous en rêviez ! Un petit ajout caché dans les options de la console Control-M Workload Automation en Fix Pack 7, mais quelle fonctionnalité !

Ce que vous attendiez depuis des années est enfin là. Une révolution ! Et pourtant, rien dans la Release notes.

Juste au dessus du format des conditions Drag and drop, une coche avec l'option "Update condition name when property change".

Oui, vous avez bien lu ! J'ai un job A, lié à un job B par la condition A-TO-B, si je renomme le job A en job Z, la condition change de nom et s'appelle Z-TO-B !

C'est pas génial !