A la surface d’un service dans System Center Service Manager (3/4)

le premier runbook vous a plu? Et bien on continue et cette fois sans une seule ligne de Powershell. On prend une grande inspiration et on va plonger vers le runbook de la mort.

Il fait référence à des activités qui sont issues de SCSM. Mon précédent Runbook ne faisait qu’exécuter l’opération. Il faut faire le lien entre SCSM et notre premier Runbook qui a besoin de paramètres en entrée. D’un autre côté, il aurait été possible d’utiliser mon premier Runbook tel qu’il est, cependant :

  • On aurait passé les paramètres en dur. Si le nombre de paramètre doit changer, il faut tout reprendre
  • On ne peut pas récupérer des informations depuis SCSM si on ne les passe pas en paramètres
  • On ne peut pas remonter d’information vers SCSM (bonne exécution ou erreur à telle étape)
  • Sauf si mon Runbook plante, il indiquera toujours qu’il s’est bien terminé

Pour ces raisons, j’ai pris l’habitude de toujours avoir un Runbook intermédiaire. La première fonction de mon nouveau Runbook, récupérer les informations depuis SCSM. Sa seconde fonction, c’est de gérer les erreurs d’exécution de mon premier Runbook. C’est une gestion « Minimaliste », il n’y a pas de notion d’incident au sens SCSM. Enfin, mon Runbook va créer une relation entre mon ordinateur pour lequel le service a été activé et la représentation du service ISATAP qui sont tous les deux des objets dans SCSM.

Amis de la CMDB, bonsoir. Le grand chalenge de l’intégration SCSM avec Orchestrator, c’est :

  • Comment indiquer au Runbook ou récupérer tous ses paramètres
  • Comment le Runbook indique s’il a réussi son exécution ou non
  • Comment s’est terminée la requête de l’utilisateur
  • Comment indiquer que le service a été activé/désactivé pour l’objet sélectionné
  • Comment gérer les erreurs

Ca fait beaucoup de choses à voir dans un seul billet. Attention les yeux, ça pire et mérite pas mal d’explications.

clip_image002

Commençons par la première activité et première bizarrerie : Un seul paramètre en entrée.

clip_image003

Techniquement, cela correspond à l’identifiant unique de l’activité qui a été réalisée lors de la « Service request » de l’utilisateur. Petit flashback vers le premier billet de la série :

clip_image005

C’est la représentation de mon objet « Runbook Automation Activity » créé lors de l’exécution de la « Service Request » initialisé par l’utilisateur. La « Service Request » a été créé par rapport à un modèle qui lui référence une seule activité. Dans l’illustration ci-dessous, on retrouve la fameuse activité qui a été générée lors de l’exécution mon runbook avec son paramètre :

clip_image007

Maintenant que nous avons l’identifiant unique de l’activité qui a été créé pour exécuter mon Runbook, on va l’utiliser. Il désigne un objet de classe « Runbook Automation Activity ». Mon premier usage sera de retrouver le lien qui uni cet objet et un objet de la classe « Windows Server ». C’est l’ordinateur que l’utilisateur a sélectionné dans le premier billet. Seulement, ce n’est pas un objet Active Directory mais un objet dans la CMDB dont les attributs ont été enrichis par tous les connecteurs. J’ai perdu personne?

clip_image008

A ce stade, on peut avoir un ou plusieurs éléments retournés (la Request Offering aurait pu autoriser la sélection multiple). En sortie nous avons donc une seule instance d’objet « Windows Server ». Plus précisément nous avons l’identifiant unique de l’objet dans la CMDB, son « SC Object Guid ». Nous n’avons plus qu’à interroger SCSM pour nous extraire les informations de cet objet de classe « Windows Server » en précisant l’identifiant unique comme critère de filtrage.

clip_image009

A ce stade, deux possibilités. Soit on a bien identifié l’objet, soit il y a eu un problème. Si vous reprenez la vue générale du Runbook, vous verrez qu’il y a une un lien rouge. Lorsqu’on clique dessus, on retrouve le critère qui fait que le Runbook empruntera ce chemin :

  • Erreur d’exécution
  • ou nombre d’objets retournés par l’activité présente égal à 0

clip_image011

Pour la suite de ce billet, on va considérer que tout se passe pour le mieux. Prochaine étape, déterminer quel routeur ISATAP doit être configuré pour l’objet ordinateur que nous venons d’identifier. C’est encore une activité « Get Relationship », toujours concernant notre « Runbook Automation Activity » mais cette fois, c’est un objet de classe « Business Service » que nous recherchons. C’est dans cet objet que j’ai indiqué le nom de mon routeur ISATAP.

clip_image012

Dans SCSM, un Business service est un objet de la CMDB. Il représente un service composé de composants supervisés qui ont un lien entre eux. L’indisponibilité de l’un des composants de mon service aura nécessairement des répercutions sur mon service. Dans mon cas, ce « Business Service » est issu du service décrit dans SCOM. Ce qui a été déclaré dans SCOM a été utilisé pour alimenter l’objet équivalent dans la CMDB de SCSM. Si on va voir mon « Business Service », on constate que dans l’onglet « Extension », on trouve son identifiant unique mais aussi un champ « Service FQDN ».

clip_image014

On se doute tout de suite que ce n’est pas un champ standard. Effectivement, c’est une extension que j’ai intégré à la classe d’objet « Business Service » via un Management Pack. Pour ceux que cela intéresse, voilà une très bonne explication vidéo de l’équipe produit. Pour faire simple, nous utilisons le « Service Manager Authoring Tool » pour créer un Management pack qui va réaliser une extension de la classe d’objet « Business Service ». J’ai donc créé un attribut pour stocker une chaine de caractère.

clip_image016

Si j’ai créé un attribut, c’est pour l’utiliser. Je vais donc stocker le nom pleinement qualifié du routeur ISATAP que nous allons configurer.

clip_image018

C’est cette information dont mon Runbook a besoin. En sortie de l’activité « Get Business Relationship », on est censé avoir la référence de mon Business Service. L’activité « Get Business Service » est tout à fait classique, on filtre juste sur l’identifiant unique que nous avons récupéré de l’activité précédente.

clip_image019

A ce stade, on a accès aux objets nous permettant d’extraire les informations nécessaires à l’exécution de notre premier « Runbook ». On va donc appeler une activité « Invoke Runbook » qui se charge d’exécuter notre premier Runbook et lui passer nos deux arguments. Pour chaque argument, c’est juste un attribut d’un objet que nous avons préalablement identifié par des activités de type « Get Object ». On va juste s’assurer que nous ne continuerons l’exécution de notre Runbook après qu’il nous ait rendu la main.

clip_image020

Si vous souvenez, en fin d’exécution, notre premier Runbook retourne une valeur. Nous allons l’exploiter. C’est très simple si tout se passe bien. Pour suivre, ces liens sont en vert dans mon Runbook.

clip_image022

Par contre, notre Runbook peut avoir planté ou retourné un code erreur. Il faut bien traiter les deux cas. Pour suivre, ces liens sont en rouge dans mon Runbook.

clip_image024

Comme tout s’est bien passé, mon serveur est maintenant un client ISATAP. Du point de vue de la CMDB, ce serait bien d’avoir une relation entre le routeur ISATAP et ses clients. En cas d’indisponibilité du service ISATAP, les premiers impactés, c’est bien les clients. C’est ce que nous allons faire avec l’activité « Create Relationship ».

clip_image025

Pour expliquer, allons voir ce que cela a donné au niveau de l’objet « Business Service » correspondant à mon service « Service réseau ISATAP ». D’une part, on constate la présence d’un lien entre mon objet « Runbook Automation Activity » et mon « Business Service ». Normal, c’était un paramètre passé lors de la création de l’activité à partir du modèle. D’autre part, l’activité « Create-Relationship » a créé un lien entre mon « Windows Server » et mon « Business Service ».

clip_image027

On approche de la fin. Notre activité s’est bien déroulée. On peut considérer que le service est activé. Ce serait bien que ce soit indiqué dans la CMDB. Ce sera super utile pour ne proposer à l’utilisateur final de n’activer le service que pour les systèmes pour lequel il ne l’est pas (prochain billet). Sur ce point, j’ai beaucoup cherché avant de revenir à des fondamentaux, donc la simplicité. Si on avait un attribut dans la CMDB dans lequel indiquer que le service ISATAP a été activé sur cet ordinateur? Rien de plus simple, il suffit d’étendre la CMDB, tout comme pour le « Business Service », nous allons utiliser le « Service Manager Authoring Tool » pour créer une nouvelle classe d’objet nommée MyWindowsComputer » qui héritera ses caractéristiques de la classe « Windows Server ». J’ai juste ajouté une propriété nommé « ISATAPEnabledService » dont le contenu sera de type « Booléen ». J’avais prévenu : Simple!

clip_image029

Dans la console SCSM, on pourra retrouver cet attribut dans l’onglet « Extensions ». Ci-dessous l’attribut en question pour mon ordinateur sélectionné par l’utilisateur dans sa demande de service.

clip_image031

Maintenant, revenons à notre Runbook. Ce qu’on veut, c’est indiquer la valeur « True » pour l’attribut « ISATAPEnabledService » pour l’objet « MyWindowsComputer ». Ça tombe bien car l’activité « Get Computer Object » de notre Runbook désigne déjà cet objet avec la propriété « SC Object GUID ».

clip_image032

Etant donné que notre Runbook s’est bien déroulé. Autant l’indiquer dans SCSM (cela nous donne la date de réalisation de l’opération. C’est utile pour savoir si on respecte ses engagements en terme de SLA). Au niveau de l’objet « Runbook Automation Activity », c’est l’attribut « Status » qu’il faut mettre à jour à l’aide de l’activité « Update Activity ». A ceux qui se demandent pourquoi j’indique « Terminéé » comme valeur et non « Completed », je les renvoie vers ce billet (Ca m’apprendra à ne pas mettre à jour mes maquettes).

clip_image033

C’est la dernière ligne droite. Notre « Service Request » n’ayant qu’une seule « Activité », le travail est donc terminé. Autant remonter cette information à l’utilisateur final. ce qui l’intéresse, c’est pas le résultat des activités intermédiaires qui ont été nécessaire pour réaliser sa demande, lui, il veut juste savoir si c’est terminé. Pour cela, j’ai créé un dernier Runbook nommé « SCSM-ISATAP-SUCCESS-RESULT » qui sera le plus simple possible. On va lui passer deux paramètres :

  • Notre fameux « ActivityID » qui nous permet de remonter à l’activité « Runbook Automation Activity »
  • Le résultat que l’on désire indiquer dans l’objet « Service Request »

clip_image034

Je ne présente plus l’activité « Initialize data »,elle est des plus banales maintenant. Ce qui va nous intéresser, c’est la suivante.

clip_image035

Ce qu’il nous faut, c’est le moyen de remonter depuis l’objet « Runbook Automation Activity » jusqu’à l’objet « Service Request ». Ça tombe bien, c’est cette dernière qui a créé la première, il y a donc une relation entre eux. Avec l’activité « Get Relationship », on peut donc retrouver l’objet « Service request » qui lui est lié.

clip_image036

Je ne présente plus l’activité « Update Object », nous l’avons déjà utilisé pour mettre à jour l’objet « Runbook Automation Activity », cette fois, on va l’utiliser pour mettre à jour des attributs de l’objet « Service Request » que l’on vient de trouver.

clip_image037

Dans les faits, voilà où cela va inscrire ces informations.

clip_image039

 

Si vous êtes arrivés au terme de ce billet, dites vous bien que vous êtes maintenant bien loin de la surface et qu’il va falloir remonter. Problème, on va avoir plusieurs paliers à réaliser dans SCSM. J’espère que vous avez encore de l’air dans la bouteille car la remontée va être longue pour le dernier billet.

 

BenoîtS – Simple and Secure by Design but Business compliant

Benoit

Simple, yes, Secure Maybe, by design for sure, Business compliant always!

Les derniers articles par Benoit (tout voir)

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.