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.
Outillage de normalisation
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.
/http%3A%2F%2Fsmc-cit.com%2Fwp-content%2Fuploads%2F2015%2F10%2Fheader.jpg)
