Initiation à Opalis

Dans le jargon Opalis, la dénomination exacte est « Policies » mais cela a évolué dans SCO pour s’appeler « Runbooks ». Pour information, le terme workflow devrait être utilisé en théorie pour désigner un ensemble de Runbooks. Ces runbooks sont un ensemble d’étapes modélisées par des « Objets » sous Opalis 6.3 ou par des « Activities » sous SCO. Ces éléments techniques sont soit intégrés par défaut par l’installation du produit, soit ajouté par l’import d’un pack d’intégration (Integration Pack – IP). Le « Runbook Designer », qui n’est autre qu’une console MMC, permet de créer des Runbooks. Voici quelques exemples d’activités présentes par défaut dans Orchestrator.

Initiation à Opalis

La partie « Monitoring » est un ensemble d’activités disponibles pour superviser plusieurs types de d’information. Nous pouvons par exemple obtenir l’adresser IP d’un ordinateur, obtenir la taille d’une partition, obtenir l’état d’un processus ou d’un service Windows ou encore obtenir un évènement précis de l’observateur d’évènements Windows.

La partie « File Management » est un ensemble d’activités disponibles pour manipuler des fichiers et dossiers. La copie ou le déplacement de fichier et dossier est une action simple à mettre en œuvre. Nous pouvons aller plus loin en utilisant l’activité « Get File Status ». Un scénario qui pourrait être mis en place est d’attendre que la date de modification d’un fichier est changée pour effectuer une action.

La partie « Text File Management » est un ensemble d’activités pour manipuler des fichiers. Il est assez simple de lire un fichier, ajouter ou supprimer des lignes ou obtenir une chaine de caractère d’une ligne. Notez qu’un pack d’intégration pour le traitement plus avancé de fichier texte est disponible sur CodePlex (suppression des espaces, chercher l’occurrence d’un caractère, remplacement de chaine de caractères, etc.).

La partie « Utilities » permet d’aller un peu plus loin au niveau des activités en étant capable de connecter ou déconnecter un partage réseau, requêter une base de données ou des fichiers XML, d’appeler un service Web ou encore créer des pages Web.

La partie « System » permet de manipuler tout ce qui est lié au système Windows, à savoir arrêter un processus, exécuter des scripts ou des programmes, démarrer ou arrêter des services Windows, faire des requêtes WMI ou encore exécuter des scripts .NET. Ces derniers sont utilisés pour y placer du code PowerShell, C#, JScript ou VB.NET.

D’autres activités standards sont disponibles comme la gestion des dates et des heures, l’envoie de mails, la gestion des notifications (Opalis ou Windows ou Syslog) ou celles propres aux contrôles des Runbooks (l’initialisation, le chainage ou la jonction d’un Runbook). Un « Drag » et « Drop » permet de les utiliser.
A partir de ces activités, on modélise ses processus métier à travers la console Runbook Designer. Une console de test appelée le « Runbook Tester » permet de tester (ou compiler) ses Runbooks. Les développeurs qui peuvent l’utiliser sont parfois perturbés car elle porte la logique du produit, logique différente d’un compilateur comme Visual Studio.

L’exemple ci-dessous permet de démarrer ou d’arrêter un service Windows en fonction de son état. Lors de l’exécution du Runbook, il faut spécifier un nom de serveur et le nom du service que l’on souhaite arrêter ou démarrer. Rien d’exceptionnel me direz-vous, ce n’est qu’à titre d’exemple pour vous montrer la logique.

Lorsque les activités disponibles ne permettent pas de répondre aux besoins, il faut soit utiliser un pack d’intégration qui pourrait répondre au besoin, soit utiliser des activités « .NET Script » pour développer la solution. Notez que l’inconvénient d’utiliser des .NET Scripts est le fait qu’on perde le gain du produit à savoir, ne pas développer. En revanche, le fait de les utiliser peut apporter un réel gain dans la gestion des erreurs souhaitée.