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

On parle souvent de Cloud mais on voit rarement comment cela fonctionne. Pour mieux comprendre, j’ai monté une « petite infrastructure ». Pour faire simple, je me suis basé sur les spécifications du Private Cloud Fast Track program. C’est simple, avec un peu de tuning, ça tiens en 32Go de mémoire vive. Prévoir quelques longues heures d’installation .

Tout au long de ce billet (et quelques autres), on va se balader entre System Center Service Manager 2012 et System Center Orchestrator 2012. Mais avant de rentrer dans des choses compliquées voyons à quoi ressemble un service du point de vue de l’utilisateur qui le consomme. Dans mon Cloud (aucun jeu de mot avec la plateforme qui m’héberge), j’ai un une machine virtuelle qui assure le rôle de routeur ISATAP (Non, il n’y aura pas de DirectAccess dans ce billet). C’est le service qui sera consommé par les machines virtuelles dépendantes de mon Cloud.

D’un point de vue purement technique, activer ISATAP sur un système, cela revient à exécuter quelques commandes Powershell. Comme je veux bien faire les choses, on va les exécuter via une session distante. Mais avant de rentrer dans le « dur », voyons à quoi cela ressemble du point de vue de l’utilisateur final. Commençons par la surface des choses.

Dans son portail SCSM, je lui présente un catalogue de service. Au sens SCSM du terme, c’est un regroupement de services qui ont été regroupés dans un « Service Offering ». L’idée est de pouvoir regrouper les demandes ayant trait à un même domaine mais aussi d’en autoriser l’accès à certaines populations. Dans mon cloud, mon utilisateur se voit présenter les services qui lui sont accessibles.

clip_image002

Au sein du « Service Offering », l’utilisateur peut constater la présence de deux « Request Offering ». Dans SCSM, une « Request Offering » fait en quelque sorte le lien entre le portail et tout ce qui se trouve sous le capot de SCSM.

clip_image004

En cliquant sur la « Request Offering », le portail SCSM affiche un certain nombre d’informations qui y sont liés dont le contenu de la base de connaissance qui y est associé.

clip_image006

Un peu plus tôt, j’avais indiqué qu’une « Request Offering » faisait le lien entre le portail et ce qui se trouve caché dans SCSM. C’est le cas. Pour notre demande de service ISATAP, il faut bien sélectionner un compte ordinateur pour lequel on va activer le service. Plus tard on découvrira que ces informations ne sont pas issues directement de l’annuaire Active Directory mais de la CMDB qui a elle-même récupérer ces informations de l’AD. Mais ça ce sera pour plus tard.

clip_image008

Toutes les informations pour traiter la demande de service ont été renseignées, il ne reste plus qu’à valider cette demande.

clip_image010

C’est maintenant que la magie de SCSM commence. Notre « Request Offering » n’était que l’interface graphique. En fait, elle a passé ses paramètres à une « Request Template » dans SCSM. Une « Request template » regroupe en ensemble d’activité qui va permettre de traiter la demande de l’utilisateur. On peut avoir différents type d’activités. Dans mon cas, ma « Request Template » ne contient qu’une seule activité qui se contente d’appeler un Runbook Orchestrator. Lorsque l’utilisateur a initialisé sa demande de service, SCSM a créé un objet « Request Template » SR1298 et l’activité qui y est liée RB1299.

clip_image012

Après une phase d’initialisation, la mécanique SCSM ne met en œuvre. Dans le cas qui nous occupe, elle appelle un Runbook dont on peut constater que l’exécution suit son cours.

clip_image014

Lorsque tout se passe bien dans le Runbook Orchestrator le statut de la requête est considéré comme terminé.

clip_image016

Voilà un service vu de l’utilisateur. C’est la partie visible de l’iceberg. Allons voir de l’autre côté dans la console SCSM. C’est là que ça commence à se compliquer. Dans l’illustration ci-dessous, on retrouve bien la « Service Request » initialisée par l’utilisateur. Dans l’état actuel des choses, elle est considérée comme active car l’activité qui y est associé n’est pas encore terminée.

clip_image018

Si on regarde le détail de la « Request « Template », on retrouve bien le compte ordinateur sélectionné, mais aussi un GUID. C’est la référence de l’objet Active Directory dans la CMDB de SCSM. C’est l’objet « Active Directory » dans la CMDB qui nous intéresse dans SCSM.

clip_image020

Notre « Service Request » ne contient qu’une seule activité. C’est le « Runbook template » qui est référencé.

clip_image022

Au final, dans l’onglet résultat, on retrouvera le résultat final de la demande de service.

clip_image024

Voilà pour la surface des choses. Dans le prochain billet, on va rentrer dans le “dur” des choses et comprendre comment tout cela a été assemblé dans SCSM pour en arriver là. Dans la prochaine étape, on va rester des choses assez simples avec notre premier Runbook Orchestrator. Prenez votre inspiration, on plonge.

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.