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

Vous pensez que nous avons fait le plus dur. C’est presque vrai. Nous sommes encore à 60 mètres sous la surface, il faut remonter mais dans SCSM cette fois. Les paliers seront les suivants :

  • Synchronisation du connecteur Orchestrator
  • Création des Runbook templates
  • Création des Services Request
  • Création des Request Offering
  • Création du service Offering

A la fin, pensez à recommencer à respirer, on sera enfin de retour à la surface d’un service.

 

Palier synchronisation du connecteurs Orchestrator

SCSM s’articule autour d’une CMDB (Configuration Management Database), il raisonne donc par rapport aux données dont il a connaissance, que celles-ci soient générés au sein de la solution ou importées au travers de connecteurs. Dans le cas qui nous occupe, nous allons avoir des besoins de données en provenance de deux sources :

  • Orchestrator : pour récupérer les informations relatives aux runbook que nous allons utiliser
  • Active Directory : pour récupérer les comptes ordinateurs pour lesquels le service sera proposé et le groupe de sécurité que nous allons utiliser.

 

Commençons avec un peu de Powershell (on va pas changer les bonnes habitudes) pour identifier les connecteurs. Celui qui m’intéresse, c’est Orchestrator. Avoir des Runbook, c’est bien, les voir dans SCSM, c’est mieux. Pour cela il faut forcer le connecteur SCSM à interroger le Web Service d’orchestrator pour extraire les informations et références mes nouveaux Runbooks.

clip_image002

Si tout se passe bien et qu’on a pas oublié qu’il faut que les Runbook soit bien en état « Checkin », on les retrouve dans la console SCSM.

clip_image004

Justement, allons voir à quoi ressemble mon objet Runbook dans SCSM. Visiblement, il a compris qu’il y avait un paramètre nommé « ActivityID » en entrée et qu’il ne retournait aucune information.

clip_image006

A ce stade, cela devient intéressant car on découvre de nouveaux objets SCSM : « Runbook Activity template » et « Request Offering». Pas si vite, on a encore pas mal de temps à passer au palier.

clip_image008

Palier Runbook templates

Nous avons des Runbook, très bien, il nous faut maintenant pouvoir les utiliser dans des activités. On va donc créer des objets « Runbook Automation Activity » pour chaque objet « Runbook ».

clip_image010

Lorsqu’on regarde de plus près, on constate que c’est bien un objet « Runbook Automation Activity » et que nous allons le stocker dans le « Management Pack ».

clip_image012

Premier élément essentiel, un Runbook doit être référencé comme une activité bien particulière. Pour cela, la case d’option « Is ready for Automation » doit être cochée.

clip_image014

Dans mon billet précédent, mon Runbook faisait référence à un paramètre nommé « ActivityID ». Maintenant, on sait d’où cela vient. Plus tard, lorsque ce template sera utilisé par le « Request template », l’objet « Runbook Automation Activity » va juste passer son identifiant d’objet SCSM comme paramètre.

clip_image016

Concrètement, allons voir ce que cela donne sur un objet « Runbook Automation Activity » qui a déjà exécuté un Runbook. On constate tout de suite que le paramètre ActivityID est bien renseigné.

clip_image018

En allant faire un tour dans l’onglet « Configuration Items », on va même trouver le serveur qui a été passé en paramètre. C’est l’objet « Windows Server » que nous avons utilisé dans le Runbook.

clip_image020

Même principe pour le « Business Service ».

clip_image022

Revenons dans notre « Runbook Activity Template ». On retrouve bien le « Business Service » que j’ai indiqué mais aucune trace de l’objet « Windows Server » passé en paramètre. On verra plus tard que le paramètre est injecté lors de l’exécution. Ce serait trop facile après tout.

clip_image024

Palier Service request

Notre « Runbook Automation Activity », il faut l’utiliser dans une séquence d’activités. Dans notre cas, la séquence, ce n’est qu’une seule activité. J’ai donc une « Service request » pour activer mon service et une seconde pour le désactiver.

clip_image026

Allons-y, créons notre « Service request ».

clip_image028

Notre service présente un certain nombre de caractéristiques tout à fait classique. Ce qui va nous intéresser, c’est son onglet « Activity ».

clip_image030

Celui-ci référence l’activité que nous allons exécuter. Pour simplifier les choses, je n’ai volontairement référencé qu’une seule activité. Il aurait tout à fait été possible d’ajouter une activité de validation avec des conditions. Restons simples.

clip_image032

Nous venons de sélectionner le « Runbook Automation Activity ». On a une base de travail, il faut passer à l’interface graphique. Ce sera l’objet de la « request Offering ».

 

Palier Request Offering

On se rapproche de la surface mais on n’y est pas encore. On a un nouveau palier pendant lequel on va s’attarder sur la notion de « Request Offefing ». C’est la demande de service qui sera publié dans le portail SCSM. C’est ce qu’on voit dans la rubrique « List View ».

clip_image034

On peut donc en déduire que c’est la liste des services proposés aux utilisateurs sans distinction. Dans mon cas, j’ai donc deux « Request Offering » :

  • Enable ISATAP Service (V3)
  • Disable ISATAP Service (V3)

Une Service « request offering » fait office d’interface graphique. On spécifie le « Request template » que l’on veut utiliser, quels paramètres sont attendus en entrée et comment on les passe au « Request template ». Dans le cas qui nous occupe, mon runbook a besoin d’un seul paramètre : l’ordinateur sur lequel on désire utiliser le service. Pour la création d’une « Request Offering », c’est par là que cela se passe :

clip_image036

Déjà on distingue deux grandes catégories « Draft » et « Published ». C’est intéressant car cela permet d’introduire la gestion des changements. L’assistant rappelle les deux grands usages, on passe, ce n’est pas là qu’on va passer notre palier.

clip_image037

La première caractéristique de ma « Request « Offering », c’est d’avoir un nom, une description et un « Request Template » qu’on va passer en lui indiquant des paramètres.

clip_image038

Justement, passons un peu de temps sur le paramètre attendu. Du point de vue de l’interface graphique, on demande à l’utilisateur de désigner un objet ordinateur. Le paramètre est indiqué comme obligatoire. Dans mon cas, je voulais que l’interface graphique affiche une liste de serveurs. C’est donc un « Query Result ».

clip_image039

Voilà pour l’interface. Maintenant, il faut l’alimenter. Plus précisément fournir une requête pour alimenter le « Query result » pour notre paramètre en entrée. Allons y et cliquons sur « Configure ».

clip_image040

C’est là qu’on reparle de la CMDB. Je veux afficher la liste des serveurs. La classe d’objets se rapprochant le plus de cela c’est « Windows Server ». Maintenant, faut affiner la requête aussi bien en termes de sélection que d’attributs retournés.

clip_image042

Ça se passe dans le second onglet avec le critère de filtrage. Je veux pouvoir afficher la liste des serveurs pour lesquels le service n’est pas encore activé. Si on se souvient du précédent post, après que le service ait été activé, j’actualisais un attribut de la classe Windows Server. Donc, si le service n’est pas encore activé, la valeur de cet attribut est censée être à « False ».

clip_image044

Note : A ceux qui se demandent à quoi sert le « Set Token », c’est pour exploiter l’identité de l’utilisateur connecté au portail. C’est très utile pour filtrer les machines virtuelles de SCVMM en fonction sur le critère du propriétaire.

Maintenant qu’on a identifié le sous-ensemble qui nous intéresse, il faut alimenter le « Query Result » avec de la matière pour l’affichage, c’est le troisième onglet.

clip_image046

Résolvons maintenant un grand mystère. Comment un ordinateur sélectionné dans le portail fini comme paramètre d’un Runbook.

clip_image048

Donc, on peut positionner l’objet sélectionné par l’utilisateur (ou les objets, après, c’est une question de traitement dans le Runbook Orchestrator) comme paramètre de la « Service Request ». Tout de suite, on ne comprend pas l’intérêt. Allons en voir une.

En première page d’une « Service Request », on peut retrouver les paramètres renseignés par l’utilisateur. Sauf que ce n’est pas parlant. On sait qu’on a un objet en paramètre, son GUID et son displayname. Pour l’équipe qui va gérer les incidents, c’est pas réellement exploitable.

clip_image050

Par contre indiquer que l’objet passé en paramètre est en relation avec la « request Offering», c’est tout de suite plus compréhensible. Si un incident survient lors du déroulement de la « request Offering », on sait tout de suite quels objets en relation sont concernés.

clip_image052

Si vous vous souvenez bien, ma « Request Template » référence une « Runbook Automation Activity » pour exécuter mon Runbook. C’est là qu’on passe le paramètre au runbook. Grâce à l’identifiant de l’objet « Runbook Automation Activity » passé en paramètre, le Runbook est capable de remonter dans la CMDB jusqu’à l’objet appelant et les paramètres qui y sont associés.

clip_image054

Maintenant que ce mystère est levé, revenons à notre « Request Offering ». Tous les paramètres obligatoires sont renseignés. Passons à la suite.

clip_image055

La phase de mappage des paramètres permet par exemple de stocker des commentaires optionnels renseignés par l’utilisateur sur le portail. On peut stocker ces informations dans l’objet « Service Request » ou dans l’objet « Runbook Automation Activity ».

clip_image056

Le savoir ne vaut que s’il est partagé. Autant afficher dans le portail le ou les articles de la base de connaissance qui concernent ce service.

clip_image057

Enfin la publication. S’il est publié, c’est que ce sera visible dans la vue « List View ».

clip_image058

A ce stade, le service est opérationnel et visible dans le portail. C’est bien mais on peut faire mieux. On est encore au dernier palier et au-dessus de 50 bars de pression (Ne jamais oublier que la pression est aussi dans les bars mais après la plongée).

clip_image059

Palier Service Offering

C’est le dernier palier, avant la surface, un peu plus de 60 bars de pression, on est bon mais on ne va pas perdre de temps. Dans SCSM, un « Service Offering » permet de regroupe des « Request Offering » dans un sous-ensemble. L’intérêt est de pouvoir filtrer la liste des services offerts aux utilisateurs en fonction de l’appartenance à un groupe. Dans la console, ça se trouve là.

clip_image061

Rien à rajouter à ce niveau. Ca présente très bien ce qu’est un « Service Offering ». Passons immédiatement à la suite.

clip_image062

Là, j’avoue que j’ai passé un peu de temps à comprendre. SCSM est un produit international. Il s’adapte donc à la langue de l’utilisateur. Mon poste client étant en langue US, j’ai intérêt à indiquer cette langue dans les caractéristiques de ma « Service Offering » si je veux la voir dans mon portail.

clip_image063

C’est toujours plus pratique d’avoir une relation entre le « Service « Offering » et le « Business Service ». Si mon service de routage ISATAP devait être défaillant, ce serait bien de savoir quels services sont impactés dans mon portail.

clip_image064

Fournir des explications sur mon service, c’est tout aussi important. Autant avoir des articles dans la base de connaissances sur le sujet. On facilite ainsi la vue de l’utilisateur.

clip_image065

Voilà tout l’intérêt des « Services Offering », regrouper les « Request Offering » traitant du même sujet.

clip_image066

Ca y est, c’est la surface. Notre service est enfin opérationnel et visible dans le portail en tant que tel. Il apparait dans la vue « category View ».

clip_image068

La boucle est enfin bouclée, je vous renvoie au premier billet de la série pour revivre l’expérience utilisateur. C’est la fin de cette plongée au cœur d’un service cloud mis en œuvre dans un cloud privé. A ceux qui sont arrivé au bout de la lecture de ce billet, chapeau, vous n’êtes pas si nombreux que cela.

 

Pour finir, ce n’est que la surface des choses. Ce n’est qu’un simple service technique qu’on propose à l’utilisateur d’activer. Le véritable chalenge après, c’est d’être capable de savoir qui consomme ce service pour être capable de lui en refacturer l’usage. Mais là c’est une autre histoire.

 

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

Benoit

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

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.