Le paradigme Orchestrator

La première chose à savoir est certainement le déclenchement même d’un Runbook. Un Runbook peut être démarré par un opérateur à travers la console Web ou la console Runbook Designer mais il peut également être déclenché de manière automatique. Un déclenchement horaire peut être utilisé pour les opérations dites récurrentes mais un déclenchement par évènement peut être utilisé. Celui-ci est particulièrement utile si vous souhaitez déclencher votre Runbook à l’arrivé d’un fichier dans un dossier créé par une application métier.

Le paradigme Orchestrator

La deuxième chose primordiale est de comprendre le rapport entre deux activités dans un Runbook Orchestrator, à savoir un évènement, un lien et une tâche, le tout régi pas ce que l’on appelle le bus de données. Comment décidez-vous que la tâche au sein de votre activité va permettre de passer à l’exécution de l’activité suivante ? Si vous prenez mon exemple plus haut avec les services Windows, l’activité nommée « Arrêt du service » n’est uniquement exécutée que si la condition (filtre dans le jargon Orchestrator) est remplie. La condition de son exécution, comme le montre la copie d’écran ci-dessous, est que le « Service status » de l’activité « Statut du service » est égal à « Service Running ».

Ce qu’il faut comprendre, c’est qu’une fois qu’une activité a été exécutée, toutes les informations propres à cette activité sont publiées sur le bus de données et disponibles aux activités suivantes. Une condition peut être ajoutée en cliquant sur « Add » dans les propriétés du lien qui lie les activités. On a ensuite la possibilité d’accéder aux « Published Data ». Ces données publiées sur le bus de données nous apportent toute l’intelligence pour construire un Runbook en bon et due forme. Dans notre exemple, j’ai choisi la donnée publiée « Service status ».

Les données publiées sont disponibles en fonction des activités comme le montre l’exemple sur les services. En revanche, il est possible de créer ses propres données publiées à partir des propriétés d’une activité. Si vous utilisez l’activité « .NET Script » et que vous souhaitez récupérer le résultat d’une exécution d’une commande PowerShell, cela n’est pas possible à moins que vous la stockiez dans une variable publiée qui sera ainsi disponible sur le bus de données Orchestrator. Il existe également ce que l’on appelle les données publiées communes. Elles correspondent aux informations propres à l’environnement d’exécution (nom du Runbook, heure de fin d’exécution, Process ID, etc.).

Dès que cette logique est acquise, il est possible de faire des enchainements conditionnels, des flux décisionnels, parallélisé les exécutions d’activités, faire des boucles, appeler des Runbooks enfants, etc. Il existe d’autres moyens techniques au sein de ce produit comme l’utilisation de variable fixe, de groupe d’ordinateurs, de compteur ou encore de calendriers définis dans le Runbook Designer. Bref, vous l’avez compris, Orchestrator, c’est génial.