Comme souvent, vous avez entendu dire que Control-M était le meilleur workload manager. Maintenant que vous l’utilisez régulièrement, vous connaissez très bien Control-M mais, malheureusement, la gestion des dépendances devient un cauchemar ? Bienvenue dans le bain. Je vais tenter de vous aiguiller un peu.

Si personnellement je considère Control-M comme un très bon job scheduler, je lui trouve, entre autre, un défaut de taille : les « dépendances » (ou « conditions »). C’est ce qui a motivé cet article. Partager mon expérience pour éviter ce que j’appelle « le piège des dépendances ».

Dans Control-M, si vous souhaitez conditionner deux jobs (J1 et J2, en externe ou interne à un smart folder), vous devez mettre une condition en sortie de J1 puis remettre le même nom de condition en entrée de J2. Et comme vous faites les choses bien, comme BMC vous l’a recommandé, vous supprimez cette condition dans la sortie de J2. Vous avez donc mis trois fois le même nom dans trois endroits différents… Vous répéterez ceci autant de fois que vous avez de successeurs de J1. Et bien sûr, comme vous testez les code retours de vos prédécesseurs, vous aurez autant de scénarios de ce trio à définir.

Là ou cela se complique, c’est lorsque que vous supprimez un des successeurs de J1 (job obsolète par exemple) en oubliant de modifier J1. Comme vous n’aurez pas supprimé cette condition relative dans J1, alors cette condition sera toujours postée par J1, sans jamais être supprimée par son successeur disparu. Et ce chaque jour, avec autant d’enregistrements dans la database.

Alors, petit à petit, vous mettrez en place, un script de gestion qui supprimera toutes ces conditions « perdues ». Il faudra cependant faire très attention à certaines conditions qui doivent perdurer dans le temps. Celles, par exemple, qui construisent des dépendances entre périodicités différentes (ex : un quotidien qui dépend d’un mensuel).

Imaginez tous ceci dans une Production de plusieurs dizaines voire centaines de milliers de jobs…

En conclusion, avec Control-M vous devez connaître et modifier les prédécesseurs, lorsque vous leur ajouter des successeurs. Vous devez modifier deux définitions de job, à chaque création de dépendance. Définir les ressources d’un successeur dans un prédécesseur n’est, à mon humble avis, pas une bonne pratique (liens trop forts). Vous serez très vite obligé de mettre en place un outil de gestion de ces conditions potentiellement « perdues ».

Je conçois que ce principe soit puissant, simple à gérer et très dynamique pour le moteur Control-M mais, à mon avis, il apporte bien trop de problèmes de gestion lorsqu’on travaille dans le cadre d’une Production volumineuse.

Attention : surtout si vous voulez garder le contrôle et l’appartenance de votre Production, ne mettez jamais de commande Control-M dans vos scripts qui exécutent votre applicatif. Ce principe est à bannir, pas seulement pour Control-M mais pour tous les workload managers sous peine d’avoir une forte adhérence entre vos applications et le gestionnaire de batch.

Retour d’expérience de conversion

Dans le cadre de nos migrations avec uMSe, lors de conversions d’un Control-M vers un autre workload manager, nous constatons un nombre très important de dépendances perdues. Bien plus, qu’avec d’autres ordonnanceurs. Bien entendu, notre moteur uMSE ne les reconduit jamais mais nos clients sont un peu déstabilisés à l’idée d’avoir été confrontés à ces débordements. Ils sont toutefois très vite rassurés de ne plus avoir à gérer ceci dans leur nouvelle Production.

L’autre effet pervers de cette gestion dans Control-M est que notre moteur uMSe détecte des dépendances en double (voire plus). En effet, au bout de plusieurs années et plusieurs collaborateurs, des conditions Control-M ont été ajoutées sans avoir osé supprimer celles qui se répétaient. Nous avons constaté, au plus, une moyenne de 4,7 dépendances par job dans certains Control-M alors qu’habituellement on voit plutôt 1,7 à 2,1 dépendances par job.