Lors du séminaire Control-M du BMC Exchange 2014 de Paris le 13 novembre 2014, un groupe du BTP a témoigné sur sa migration de $Universe vers Control-M.

Cette conversion que j'ai eu la chance de mener est fortement d'actualité, en particulier depuis le rachat en 2014 de la société ORSYP (éditeur de $Universe) par la société AUTOMIC (éditeur d'Automic, appelé anciennement UC4).

Ce projet de migration est appuyé sur une architecture Control-M v8.0.00 avec un Control-M/Enterprise Manager et un Control-M/Server par environnement en Windows et utilisant la base de données Post-GRE SQL fournie par BMC Software. Les modules Forecast et SelfService ont été mis en œuvre. Il consistait à migrer les deux ordonnanceurs d'ORSYP ($Universe et Unijob) vers Control-M pour une soixantaine de serveurs (Windows, AIX, Linux) et un millier de jobs à la source.

Un important travail de formation et de normalisation a été réalisé en début de projet, il a pour but de retranscrire au mieux les besoins du client en terme de vue métier et d'exploitabilité de la solution et de constituer les règles de nommage des objets Control-M en ce sens.

La conversion des jobs $Universe a été réalisée avec le Conversion Toolkit v8.0.00 de BMC Software. Le résultat obtenu en termes d'ordonnancement est très satisfaisant. Nous noterons quelques non- prises en charge par l'outil comme le cas des Sessions sans tâche ou ne contenant qu'une Uproc (problèmes remontés aux laboratoires qui sont en cours de traitement).

Le problème de cette conversion automatisée dédiée au plus grand nombre est le nommage des entités. En effet, le toolkit de Conversion fourni des jobs Control-M avec des nommages $Universe. Certains paramètres ne sont pas renseignés, d'autres portent de noms d'Uproc, de taches ou de sessions. Les noms de serveurs sont extraits par $U en numéro IP, donc reconduit dans Control-M sous cette forme. Les ressources portent elles aussi des noms $U et ne sont pas toujours pertinentes. Pour simplifier la conversion, le format des conditions générées par le Conversion toolkit est <Job>_Ok ou <Job>_ENDED-OK, ce qui ne correspondait pas à la norme choisie par l'entreprise de BTP qui est de type <prédécesseur>-to-<successeur>.

Un outillage spécifique que j'ai développé, nous permet d'extraire des XML (deftable) générés par le Toolkit de conversion, un tableau au format EXCEL dans lequel le client peut mettre à jour sa norme. Certains champs, comme ici dans le projet du groupe de BTP, pour la fréquence d'exécution, peuvent être remplis lors de la génération du fichier EXCEL. Le client ne saisit que des codes, les nommages finaux seront créés lors de la renormalisation.

Ce fichier une fois complété, d'autres outillages réalisent la renormalisation des fichiers XML issu du toolkit pour générer des fichiers XML à la norme du client. Cette dernière opération permet aussi d'ajouter les spécificités du client, comme l'ajout de ressources quantitatives permettant des blocages, des envois de messages pour l'ouverture de tickets d'incidents lorsqu'un job est en erreur, …). Une variable %%OLD_UPROC est aussi ajoutée afin de faire le lien entre l'ancien et le nouvel ordonnancement. Cette dernière pourra être facilement supprimée avec l'utilitaire de modification en masse de la console.

A l'issue de cette livraison, certains ajustements restent à réaliser comme la suppression des doublons issus du contournement mis en place dans $Universe pour gérer l'impossibilité de faire l'action post-exécution : "Si Erreur, alors on continue". Avec $U, dans une chaine A, B, C, si le job A est en erreur, mais que l'on doit continuer la chaine. On prévoit deux jobs D et E. Où D est une copie de B et E, une copie de C. Et en cas d'erreur, on fait continuer la chaine par la branche "erreur" (D et E). Dans Control-M, D et E seront à supprimer, puis il faudra simplement ajouter une condition A-to-B en Do Action lorsque le job est NotOK.

Le groupe de BTP a réalisé cette conversion sur 6 mois, par lots non liés pour ne pas avoir à gérer de communications temporaires entre $Universe et Control-M. Cette durée est liée aussi à la migration de l'ordonnanceur Unijob (ORSYP) qui a été réalisée manuellement, car les exports de ce produit ne permettaient pas d'automatiser la conversion.

Ce type de projet demande une implication des équipes, la constitution d'un document de normes qui ne peut être créé qu'à partir d'une vraie formation. Et un travail important pour normaliser les jobs, coté client, qu'il ne faut pas négliger lors du dimensionnement du projet.

Les outillages utilisés dans ce projet peuvent être mis en œuvre pour tous types de projets de renormalisation, mais aussi dans le cadre de conversions réalisées par le toolkit de BMC (Automic, Autosys, TWS, cron, WinAT, …).

A noter, BMC nous a annoncé au cours du séminaire, que les ordonnancements complexes $Universe permettant d'instancier des chaines seront prochainement pris en compte par le Toolkit de conversion.

Elle est attendue officiellement pour juin 2015, date à laquelle la version 6.4.01 ne sera plus supportée.

On nous annonce entre autre pour cette version 9, un mécanisme de haute disponibilité intégré, de la planification dynamique de jobs, le partage de données d'un job à un autre, la sortie au format type Visio des définitions, la mise à jour des fix pack des Agents via le Configuration Manager, une automatisation des changements d'environnements (Recette vers Production), ...

Les deux derniers Add-ons récemment sortis (ou à sortir) et nécessitant la v8, ont été présenté :

Le serveur d'archivage (serveur externe appuyé sur une base Post-GRE compressé) qui doit assurer la collecte des OUTPUT (ex-SYSOUT) pour les conserver suivant des règles à définir. Celles-ci seront consultable depuis la console Workload Automation et le Self-Service.

La console de changement (version Web du planning de la console v8 ou du Desktop pour ceux qui sont restés sur les anciennes versions). Cette console doit permettre à Monsieur Toulemonde de créer des chaines et de les soumettent à l'équipe Control-M. Un mécanisme d'annotations et d'échanges est mis à disposition. En fonction des profils, les utilisateurs pourront avoir un accès partiel au formulaire de définitions. Le Scheduling et les Actions pouront, par exemple, rester dans le périmètre de l'équipe Control-M. En ce cas, Les onglets Scheduling et Actions ne seront pas affiché et l'utilisateur donnera sa planification dans les commentaires. Enfin, un module de définition et de contrôle des normes est aussi proposer pour obliger l'utilisateur à respecter celle-ci.

Une équipe projet dit "Putois" des labs a réalisé une sorte de Control Module customisable. Manière d'encapsuler par exemple, les commandes de CFT ou de Time Navigator et de les proposer sous la forme d'un Control Module. Le produit présenté en version super Beta est à intégrer par les labs pour en faire un vrai produit qui pourrait être disponible courant 2015 et peut-être inclus dans la licence standard. Espérons qu'ils auront l'idée de nous permettre de partager les modules créés et d'associer à cet outil un forum et une communauté et une plateforme d'échange.

Prochainement, un compte-rendu sur la présentation que j'ai donné conjointement avec la SOCOTEC sur le thème de la Migration de $Universe vers Control-M.