Conception, réalisation et mise en place d applications de supervision orientée métier au sein du groupe France Télécom

Transcription

1 Conception, réalisation et mise en place d applications de supervision orientée métier au sein du groupe France Télécom Travail de Fin d Études France Télécom Division Systèmes d Information Service National de Production Informatique Tuteur école : Émmanuel Otton Tuteur entreprise : Cédric Cherrière Jean-Philippe Caruana ifi 2003 février juin 2003

2 Conception, réalisation et mise en place d applications de supervision orientée métier au sein du groupe France Télécom Travail de Fin d Études France Télécom Division Systèmes d Information Service National de Production Informatique Tuteur école : Émmanuel Otton Tuteur entreprise : Cédric Cherrière Bâtiment Équerre 3-5, rue Hélène Boucher Saint Quentin en Yvelinnes Jean-Philippe Caruana ifi 2003 février juin 2003

3 Avant propos Conventions de notation En général, les mots en petites capitales font l objet d une explicitation dans le glossaire, page 56 ; les références à la bibliographie sont faites entre crochets [] ; le code source est encadré comme ceci, avec les mots clefs en bleu et le type des données en violet : // Ceci est un exemple de code source employe. Il s agit de code " Business Bridge ", dont la syntaxe est proche du " Visual Basic " ( mots clefs comme If, For, Do Loop et types de donnees classiques, tels que Integer, String, mais aussi DateTime ) Remerciements Je voudrais remercier M. Marc Anconetti, directeur de la Direction de l Ingéniérie (d.i.) du Service National de Production Informatique (s.n.p.i.) du groupe France Télécom (d.s.i., Division du Système d Information) pour son accueil au sein de son service. Je voudrais également remercier M. Gilles Reignier, adjoint à la d.i. de M. Anconetti et directeur de projet de PréviensNoo pour son accueil dans l équipe et son aide dans mon travail. Je voudrais aussi remercier M. Cédric Cherrière, ingénieur et chef de projet de PréviensNoo, qui a tenu son rôle de tuteur de stage à merveille, en m accompagnant tout en me laissant un grand champ libre. Encore merci Cédric. Enfin, je voudrais remercier les autres membres de l équipe PréviensNoo, MM. Patrick Rousset, Sébastien Dupuis et Cheng Lu pour leur aide et leur soutien quotidien dans mon travail. Il reste encore une personne à remercier : M. Alain Griers, un ami de longue date qui m a permis d entrer en contact avec Cédric Cherrière et d obtenir ainsi un stage vraiment passionnant. i

4 Résumé Le stage s est déroulé au sein de l équipe PréviensNoo du d.s.i./s.n.p.i. de France Télécom. La plus grande partie du stage a consisté à concevoir et à développer une application de supervision des applications développées par l équipe PréviensNoo. L application développée sous Business Bridge s appelle Mega Vision. Cette application fonctionne de manière simple : elle télécharge sur chaque serveur supervisé les fichiers dont elle a besoin pour établir la valeur de ses indicateurs après traitement des informations. Les fichiers téléchargés sont générés par chaque serveur à intervalles de temps réguliers. Concevoir et développer cette application m a permis d aborder tous les aspects d un projet informatique, en partant d un besoin exprimé jusqu à la réalisation finale. Cependant, à cause de certaines limitations du produit de développement, l application n a pas pu être développée à 100%. Il reste donc encore un peu de travail. Ce travail sera réalisé dans la suite du stage pendant les deux mois qui vont suivre. ii

5 Table des matières Avant propos Résumé Table des matières Table des figures Liste des tableaux i ii v vi vii Introduction 1 I Rapport d action 2 1 Objet Mesurer l impact d une dégradation d un logiciel : une nécessité Superviser les outils de supervision Conclusion 5 3 Justification 6 4 Suites à donner 7 5 Rappel de la démarche L expression du besoin : le point de départ L étape de documentation : indispensable pour pouvoir comprendre le problème L étape de réflexion : découper le problèmes en sous entités Apporter une solution concrète à chacun des problèmes Qualification et validation du travail II Rapport d études 10 6 L environnement et le contexte du travail chez France Télécom Le groupe France Télécom Les filiales cotées en bourse La Division des Systèmes d Information Le Service National de Production Informatique iii

6 6.5 L équipe PréviensNoo L outil utilisé : Business Bridge de Systar Introduction Concepts de Business Bridge La supervision métier : un concept nouveau différent de la supervision technique Le concept d objet dans Business Bridge : une vision particulière de cette notion La programmation événementielle Fonctionnement de Business Bridge Les différents éléments de Business Bridge et leurs relations Les étapes du développement Mode de fonctionnement de l application de supervision MegaVision Fonctionnement sur les machines distantes Infrastructure Applications Utilisation du service cron sur chaque machine Traitements sur le serveur de supervision Initialisation : domaine dinit Supervision : domaine dsupervision Structure des données Remarque sur les noms Configuration Données Alarmes Conception et spécifications de l application Conception L indicateur Infrastructure L indicateur Applications Contraintes liées à l application Spécifications Les DataSources employées Les indicateurs de la surveillance au niveau Infrastructure Les indicateurs de la surveillance au niveau Applications III Annexes 39 A Le groupe France Télécom 40 A.1 Les activités du groupe France Télécom A.1.1 La téléphonie fixe A.1.2 Les mobiles A.1.3 Internet A.1.4 Les services aux entreprises A.2 La Division Systèmes d Information A.3 Le Service National de Production Informatique Jean-Philippe Caruana février juin 2003 iv

7 B Détails concernant l architecture fonctionnelle de Business Bridge 46 B.1 Contexte B.2 Architecture technique C Description des trois types de solutions envisagées pour vérifier l existence et l état des Process et Bridget Models sur une machine distante 49 C.1 Introduction et problématique C.2 Première solution : créer un Bridget Model spécialisé C.2.1 Présentation de la solution C.2.2 Avantages et inconvénients de cette solution C.3 Deuxième solution : exécuter des scripts par commande Telnet C.3.1 Présentation de la solution C.3.2 Avantages et inconvénients de cette solution C.4 Troisième solution : utiliser une commande similaire à la commande Unix cron C.4.1 Présentation de la solution C.4.2 Avantages et inconvénients de cette solution C.5 Conclusion Bibliographie 53 Jean-Philippe Caruana février juin 2003 v

8 Table des figures 7.1 Un exemple d interface web pour l affichage des indicateurs Un exemple de tableau de bord pour l affichage des indicateurs Supervision distante d une application Business Bridge Fonctionnement de l application Mega Vision Détail du fonctionnement de la lecture des fichiers de résultats Schématisation du fonctionnement global de l application Modèle physique des données de l application Présentation de la surveillance A.1 Organigramme du groupe France Télécom A.2 Organigramme de la DSI A.3 Organigramme du SNPI B.1 Architecture fonctionnelle de Business Bridge vi

9 Liste des tableaux 9.1 Norme France Télécom pour le nommage des principaux éléments (extraits) Seuils et règles de contrôle pour l indicateur des services NT Seuils et règles de contrôle pour l indicateur Process Model Seuils et règles de contrôle pour l indicateur Bridget Model Seuils et règles de contrôle pour l indicateur DataSource vii

10 Introduction L équipe PréviensNoo réalise et maintient pour la production au sein du groupe France Télécom un grand nombre d applications de supervision. Ces applications de supervision sont développées sous Business Bridge, de Systar. Il serait utile de pouvoir suivre leur bon fonctionnement et être alerté en cas de défaillance d un composant du système. Le but recherché n est aucunement de rétablir les services ou les composants défaillants, mais de signaler le problème le cas échéant, car ces défaillances entraînent des graves dysfonctionnements et il est nécessaire de redémarrer tous les services à la suite de l un d eux. Le but de cette application de supervision est de détecter et d avertir des arrêts de fonctionnement d un service, ou de tout ou partie d un serveur ou d une application. Une application de supervision est hébergée par un serveur Windows NT. L application surveillée fonctionne sur un serveur distant et est surveillée par un autre serveur. Le fonctionnement de Business Bridge est simple : les DataSources font remonter l information jusqu au Bridget Model, responsable de la corrélation entre le données, jusqu au Process Model qui est chargé de l affichage des informations. Chacun des composants précités peut tomber en panne sans qu il soit aujourd hui possible de le savoir directement ; la seule connaissance actuelle d un problème d une des applications de supervision est indirecte et retardée. Le but de ce stage a donc été de concevoir puis de développer une solution à ce problème. 1

11 Première partie Rapport d action 2

12 Chapitre 1 Objet Nous décrivons ici la problématique et la situation au sein de France Télécom qui ont conduit à superviser les applications existantes à l aide d outils de Business Activity Monitoring (bam, appelés aussi outils de Business Process Performance Management : bppm) tel que Business Bridge, de Systar[16]. On trouvera une description de l outil Business Bridge et de son fonctionnement au chapitre 7, page Mesurer l impact d une dégradation d un logiciel : une nécessité L équipe PréviensNoo du s.n.p.i. est un centre de compétence pour la supervision des processus métier du Système d Information du groupe France Télécom. Un processus métier, c est l ensemble des actions qui concourent à la réalisation d un résultat attendu par le commanditaire. Les processus métier type du groupe France Télécom sont intimement liés à son activité : la vente de services dans le domaine des télécommunications (téléphonie et réseaux). Les applications type sont par exemple la prise de commande d abonnement pour la téléphonie mobile (groupe Orange) ou la facturation des télécommunications depuis les téléphones fixes. Les outils de supervision traditionnels ne permettent pas aujourd hui de déceler certains dysfonctionnements logiciels, réseau ou matériels. Avec ces outils «traditionnels», il est difficile de mesurer l impact d une dégradation de l état d une application informatique, sur l utilisateur ou sur le client. L utilisation d outils de bam, tel que Business Bridge, permet de : avoir une vision de bout en bout du déroulement des processus métier ; suivre les indicateurs métiers en temps réel ; détecter les anomalies avant qu elles n impactent les activités de l entreprise ; aux équipes informatiques d informer les équipes métiers à temps pour qu elles puissent s organiser ; apprécier objectivement la qualité de service délivrée aux clients ou aux partenaires. Gilles Reignier, chef du projet PréviensNoo, décrit le projet dans un document de communication interne [13] : «Business Bridge mesure la performance des processus (transverses à plusieurs applications). Il fournit en temps réel des indicateurs critiques de performance 3

13 métier. Cette supervision s adresse aux acteurs «métier» qui s assurent du bon déroulement des processus critiques, et aux exploitants techniques. La supervision corrèle en temps réel les résultats et analyse le fonctionnement sous divers aspects : Disponibilité : le service est-il complètement rendu de bout en bout? Vraisemblance : les informations fournies sur les services détenus par le client France Télécom sont elles celles attendues? Fluidité : le temps de traitement pour rechercher un client est-il stable?» 1.2 Superviser les outils de supervision Cependant, bien qu il soit de très bonne qualité, l outil Business Bridge n est pas parfait, et les applications de supervision s arrêtent d elles-mêmes de façon incongrue et imprévisible. Il est difficile, voire impossible, de déterminer rapidement où réside le problème, car il faut absolument remonter l historique du fonctionnement de la supervision par la lecture des fichiers de logs, ce qui s avère souvent fastidieux. Il est donc nécessaire de développer une application permettant de superviser les serveurs de supervision PréviensNoo (au nombre de trois actuellement) et les applications en cours de fonctionnement sur ces serveurs. Le but est de savoir si l infrastructure et les application de supervision fonctionne correctement. Le travail réalisé au cours de ce stage a donc notamment consisté à concevoir et développer une application de supervision des serveurs et applications de l équipe PréviensNoo. Cette application s appelle Mega Vision. Jean-Philippe Caruana février juin

14 Chapitre 2 Conclusion L application Mega Vision est conforme aux attentes de l équipe PréviensNoo : elle est fonctionnelle et répond au besoin de façon complète. Les fonctionnalités manquantes sont liées aux limitations du logiciel de développement de la solution, Business Bridge. Elles ne pourront être résolues que de deux façons : soit le produit Business Bridge évolue dans un sens qui permettra de résoudre ces problèmes, soit une solution utilisant un autre produit devra être utilisée. Dans tous les cas, la résolution de ces problèmes ne sera pas aisée. En effet, il semble que les limitations liées à Business Bridge soient un choix délibéré des développeurs du produit. Du fait de la grande quantité de travail de Systar pour faire évoluer son produit vers une nouvelle version majeure, il apparaît peu probable qu une demande de modification du produit aboutisse actuellement. De même, trouver une solution alternative risque d être difficile, tant le fonctionnement intrinsèque de Business Bridge nécessite une profonde connaissance de Windows. L accès à cette connaissance est facilité par Business Bridge lui-même, mais ne plus l utiliser entraînerait une augmentation de la complexité du problème, Business Bridge agissant dans ce contexte comme un filtre simplificateur du fonctionnement de Windows. On voit bien que le chemin à parcourir dans ce sens sera sans doute long et ardu. Cependant l application est présente, fonctionne en production, donc les objectifs ont été atteints. Cela m a permis de participer à un cycle complet de réalisation d un projet : expression du besoin, conception, spécifications, développement, qualification puis validation. La rédaction de la documentation utilisateur et développeur [4] de l application m a permis d apprendre à communiquer sur mon projet et de synthétiser ma pensée dans un objectif industriel. 5

15 Chapitre 3 Justification Le stage a permis d aborder un problème complexe ; une analyse nous a amenés à décomposer le problème en entités élémentaires pour en résoudre tour à tour chacune des difficultés. Tous les choix ont été réalisés après analyse de chaque situation et mûre réflexion. Il a tout d abord été choisi d utiliser des utilitaires gratuits quand les utilitaires Windows faisaient défaut, comme cela a été le cas pour la commande psservice ou le service cron. Cela a permis d obtenir la liste des services NT concernés et la liste des objets Business Bridge utilisés sur chaque serveur supervisé. Le traitement des informations est entièrement réalisé sur un serveur dédié à ce travail afin d éviter de surcharger les serveurs supervisés en leur ajoutant une opération supplémentaire. Il a été préféré de télécharger deux fichiers depuis un serveur distant en une seule connexion FTP plutôt que d exécuter à distance des commandes de listage de services et de télécharger un fichier par connexion FTP : cela limite le nombre de connexions (une au lieu de deux) et évite le fonctionnement parfois surprenant des commandes à distances, telles que le BE AdminShell ou psservice, notamment à cause des noms de domaines réseau Windows qui doivent être les mêmes pour que ces utilitaires fonctionnent, et l architecture complexe du Système d Information de France Télécom ne garantit pas cette uniformité des noms. 6

16 Chapitre 4 Suites à donner Les suites à donner sont de plusieurs ordres : elles portent sur le travail restant à réaliser par manque de temps et sur le travail impossible à réaliser dans l état actuel de Business Bridge. Le design des DashBoards, de par leur essence purement statique, n a pas été réalisé avant une mise en production définitive. Cette tâche peut être très rapide si l on s appuie sur les DashBoards déjà créés par l équipe PréviensNoo pour les autres applications comme par exemple l exploitation des application Orange. Le contrôle de la fonction reporting n a pas été pris en compte, aussi une prochaine version devra mettre l accent sur cet aspect qui, bien que peu exploité actuellement par l équipe PréviensNoo, peut s avérer très problématique en cas d utilisation plus intense de cette fonctionnalité. Le contrôle de l activité des DataSources n a pas été réalisé car Business Bridge interdit au développeur de pouvoir filtrer dans la DataSource LogReader sur le chemin DAT qui est celui des DataSources. Ceci est une limitation voulue par les développeurs de Business Bridge, probablement pour des raisons de sécurité mais qui pose problème dans notre cadre. Tant que Systar ne permettra pas la filtration sur le chemin DAT, cette partie de la supervision, pourtant importante, demeurera impossible. La principale piste à suivre est la recopie des fichiers de log concernés dans un fichier facile à télécharger et à exploiter sur le serveur de supervision. Notons enfin qu un «débroussaillage» des messages et de leur sévérité dans les logs a été réalisé en pré-étude de ce problème. Cependant, il n apparaît pas dans ce rapport, mais pourra servir de base pour continuer le travail. Certains cas limites, comme l utilisation du même Bridget Model en plusieurs exemplaires, ne sont pas traités correctement. Ceci est dû au mode de filtrage des réponses du BE AdminShell qui ne crée qu une seule ligne pour toutes les occurrences du même Bridget Model lorsqu on demande la liste des Bridget Model présents sur un serveur donné. Il serait intéressant, même si ce cas est rare, de pourvoir à ce problème. Il est nécessaire de mettre l application réalisée en production sur les trois serveurs, car cela n a pas encore été fait. Une documentation[4] a été rédigée afin de faciliter l installation sur les postes clients et sur le serveur de supervision. Cette documentation doit du reste être testée, afin de savoir si rien n a été oublié, si tout est clair pour un utilisateur λ désirant utiliser ou installer une supervision d applications de supervision. 7

17 Chapitre 5 Rappel de la démarche La démarche suivie est très simple et logique : elle part d un besoin exprimé par l équipe pour arriver à une solution pratique et à une recherche de pistes pour la suite du travail. 5.1 L expression du besoin : le point de départ Cette phase a abouti à un cahier des charges. Le besoin, résumé dans l objet de ce rapport (page 3), est la nécessité de superviser les applications de supervision créées par l équipe PréviensNoo et l infrastructure des trois serveurs concernés. 5.2 L étape de documentation : indispensable pour pouvoir comprendre le problème Une fois le besoin exprimé, il est indispensable de comprendre le problème dans toute son étendue. C est pourquoi il est nécessaire de se documenter sur les divers aspects du problème. Les sources d informations principales ont été la documentation de Business Bridge et l aide des programmes concernés, mais aussi des suggestions des autres membres de l équipe et la fréquentation (plus rare) des forums spécialisés. 5.3 L étape de réflexion : découper le problèmes en sous entités Il est impossible de résoudre un problème important en une seule fois, il faut le découper en sous entités. Il convient ensuite de résoudre chaque petit problème séparément pour arriver à une solution finale pour le problème de départ. Les principaux sous-problèmes qui ont été isolés pour parvenir à la solution sont exposés de manière brève ci-après : quelles sont les informations pertinentes dont aurait besoin l application pour réaliser son travail? comment connaître la liste et l état : des services NT présents sur un serveur ; des Bridget Models, Process Models et DataSources présents sur un serveur? comment récupérer ces informations sur un hôte distant qui ne partage pas forcément le même domaine Windows sous ouvrir de trou de sécurité supplémentaire? C est le point de départ de la réflexion. Il a été nécessaire de se documenter sur le fonctionnement de Business Bridge et des applications développées avec cet outil. 8

18 comment ordonnancer ou automatiser des tâches d exécution de script sur un serveur distant? comment configurer l application finale? Par lecture de fichier ou par l interface Web offerte par Business Bridge? Chaque problème avait plusieurs façon d être résolu. Il a donc été nécessaire de comparer les solutions afin de tirer la meilleure possible, dans le contexte qui nous concerne, tout en gardant à l esprit la possibilité d évoluer dans l avenir. Un exemple d étude pour le choix d une des solutions est disponible en annexe C, page 49. Cet exemple concerne le choix du service cron et le mode de vérification de l existence des Process Models et Bridget Models présents sur un serveur Business Bridge. 5.4 Apporter une solution concrète à chacun des problèmes La résolution de tous les petits problèmes pris séparément a abouti à une solution globale pour le fonctionnement de Mega Vision. La solution est expliquée de manière succincte dans le paragraphe suivant. Sur chaque serveur supervisé, des fichiers contenant respectivement la liste des services et celle des composants Business Bridge sont créés à intervalles réguliers à l aide d un service de type cron. Ces fichiers sont téléchargés par connexion FTP et analysés pour en extraire les informations pertinentes à la supervision. Ce travail de supervision est divisé en deux parties dès le début, la partie Infrastructure qui est l image de la disponibilité des serveurs et des services présents sur ceux-ci, et la partie Applications dont l objet est le bon fonctionnement des applications de supervision. Ensuite, les informations pertinentes sont remontées à l utilisateur après traitement par l application. 5.5 Qualification et validation du travail Une fois le travail effectué, il est nécessaire de finaliser le cycle de travail par la qualification puis éventuellement la validation du produit avant la mise en production qui est l achèvement du travail. La qualification s est faite au fur et à mesure de l avancement du travail, fonctionnalité par fonctionnalité. Ceci a permis une validation rapide avant la mise en production finale. Cette étape finale s est déroulée sans aucun problème, du fait de la manière d avancer, petit à petit, sans précipitation. Jean-Philippe Caruana février juin

19 Deuxième partie Rapport d études 10

20 Chapitre 6 L environnement et le contexte du travail chez France Télécom Le travail s est effectué au sein de l équipe PréviensNoo de la d.i. (direction de l Ingéniérie) du s.n.p.i. (Service National de Production Informatique), composante de la Division Systèmes d Information (d.s.i.) du groupe France Télécom. Ce chapitre en est une présentation succincte, plus de détails sont donnés en annexe A, page Le groupe France Télécom Le groupe France Télécom est une des plus grandes entreprises françaises dont l activité principale est les télécommunications en général, ce qui comprend : la téléphonie fixe (activité historique issue de l époque des ptt (Poste, Télégraphe, Téléphone)) ; la téléphonie mobile (FTM (France Télécom Mobiles), puis Orange) ; Internet (filiale Wanadoo) ; les services aux entreprises (filiale Equant). Un organigramme du groupe est disponible en page Les filiales cotées en bourse Les filiales cotées en bourse du groupe France Télécom sont Wanadoo, Orange et Equant. Wanadoo couvre l ensemble de la chaîne des activités Internet (accès, portails, e-commerce, annuaires, services aux professionnels), en France, dans plusieurs pays d Europe et au-delà. Dans un marché en pleine croissance, Orange conserve ses positions en France et gagne du terrain à l étranger. Elle explore toutes les possibilités d innovation : WaP, GPRS, UMTS... Equant offre l une des gammes de services data les plus étendues au monde en proposant l IP, le Frame Relay, l ATM, la voix, l intégration voix-données, l hébergement et les applications et services aux professionnels. 11

21 6.3 La Division des Systèmes d Information La d.s.i. est responsable du Système d Information du groupe France Télécom. Elle est divisée en plusieurs entités, principalement : le s.n.p.i., Service National de Production Informatique ; le s.i.c.o.r. : conception et développement du si du domaine commercial (relation client) ; le s.i.f.a.c. : conception et développement du si du domaine de la facturation ; le s.i.r.e.s. : conception et développement du si du domaine du réseau et des services. Un organigramme de la d.s.i. est disponible en page Le Service National de Production Informatique Le s.n.p.i. est responsable au niveau national de l architecture de production et d exploitation et assure la disponibilité, le fonctionnement et la sécurité des applications informatiques du groupe. Il est principalement composé des entités : d.i. (Direction de l Ingéniérie) : responsable de la définition de l architecture de production du s.n.p.i. ; dex : responsable de l exploitation informatique des applications en production. Le s.n.p.i. est localisé principalement en région parisienne. Un organigramme du s.n.p.i. est disponible en page L équipe PréviensNoo L équipe PréviensNoo du SNPI est un centre de compétence pour la supervision des processus métier du Système d Information du groupe France Télécom. Ses missions et activités sont les suivantes : valider et tester le produit, ses différentes versions ; centraliser la documentation sur Business Bridge ; être un interlocuteur privilégié avec le fournisseur Systar ; donner conseil et formation ; assister la maîtrise d œuvre pour le développement de solutions de bam ; apporter le soutien à la production ; développer des solutions pour les applications du s.n.p.i. Jean-Philippe Caruana février juin

22 Chapitre 7 L outil utilisé : Business Bridge de Systar Vous trouverez ici une description succincte de l outil utilisé au sein de l équipe PréviensNoo pour réaliser ses applications de supervision : Business Bridge. Cet outil est aussi utilisé pour réaliser la supervision des applications de supervision de l équipe PréviensNoo. Nous voyons ici ce qu est la supervision métier et ce en quoi cela est différent de la supervision technique classique. 7.1 Introduction Un processus métier est «l ensemble des actions qui concourent à la réalisation d un résultat attendu par le commanditaire». Par exemple, le processus facturation est un ensemble de traitements des données incluant le détail des télécommunications, l impression et le postage de la facture au client. Business Bridge est un progiciel fonctionnant sous Windows NT4 ou 2000 qui nécessite l installation d un serveur Microsoft IIS. Il permet de développer des applications de supervision de processus métier, notamment dans le secteur des télécommunications. On appelle cela du bam, Business Activity Monitoring ou bppm, Business Process Performance Management. Le concept du bam est de fournir un accès à des indicateurs de performance métier critiques pour améliorer la réactivité et l efficience des opérations : contrôler le bon fonctionnement «du point de vue métier» en permanence et en temps réel sur les processus stratégiques sur le fonctionnement du processus et le service rendu ; faire le lien entre incidents et leurs conséquences en terme métier ; permettre de s attacher aux vrais problèmes : ceux qui ont un impact sur les processus stratégiques ; identifier les situations anormales même en l absence d alerte technique détectable. 7.2 Concepts de Business Bridge La supervision métier : un concept nouveau différent de la supervision technique Il existe deux visions différentes du rendu de service : celui des informaticiens et celui des utilisateurs : 13

23 La supervision technique est réalisée par des informaticiens. Leurs indicateurs sont de type purement techniques, c est la surveillance des machines et du réseaux qui est réalisée. Il s agit de s assurer que le matériel informatique soit toujours disponible pour les utilisateurs. Les utilisateurs se servent d une application informatique dont ils ne connaissent pas le fonctionnement, leur seul problème est que cette application doit fonctionner correctement. Si ce n est pas le cas, alors ils ne pourront pas travailler dans de bonnes conditions. Il est fréquent de rencontrer des situations où tous les indicateurs techniques sont positifs mais que l application ne fonctionne pas au niveau de l utilisateur. Le concept de la supervision métier, c est justement de combler cet écart entre ces visions, de penser en termes de rendu de service plutôt qu en termes techniques. Tout commence par un échange avec l utilisateur avec qui le dialogue est orienté services et non technique Le concept d objet dans Business Bridge : une vision particulière de cette notion Business Bridge permet l accès aux objets. Ces objets sont appelés en interne Bridget, contraction des mots Business Bridge et object. Il s agit de l instance d une classe, c est un objet au sens «classique» du terme dans les notions d objet UML par exemple. Ce sont des objets un peu particuliers : même si les mécanismes d héritage sont conservés, certaines propriétés classiques de la notion d objet sont absentes dans Business Bridge. Ainsi : l héritage multiple est, comme en Java, interdit ; les bridgets n ont pas de méthode, ils n ont que des attributs. Pour combler ce manque, la programmation est totalement événementielle et est régie par des règles et des routines de code (voir plus loin). Les autres notions issues de la programmation orientée objet sont conservées, et le vocabulaire utilisé dans Business Bridge est le même : ainsi les classes filles héritent leurs attributs de leur classe mère et chaque instanciation d un classe donne lieu à la création (dynamique) d un objet. Enfin, chaque classe fille peut surcharger un attribut issu d une classe mère. Il y a cependant de nombreux types d objets, comme les bridgets, les alarmes, les paramètres. Dans Business Bridge, tout est objet, et les instances d objets peuvent être codées «en dur», elles sont alors statiques, mais les instances peuvent être dynamiques, c est à dire créées au besoin. Cela rend la programmation plus difficile, mais aussi plus souple et facilement adaptable aux situations. Nous ne reviendrons pas sur la notion d objet dans la suite de ce document. Le lecteur intéressé se reportera sur les ouvrages dédiés à cette notion La programmation événementielle Comme nous l avons vu plus haut, les Bridgets n ont pas de méthode, ce sont des objets «qui ne font rien». Cependant, il est nécessaire de pouvoir faire interagir ces objets entre eux et avec leur environnement. Business Bridge propose pour cela un fonctionnement purement événementiel. Attention, ici le mot évènement est à prendre au sens large du terme, et non à un sens plus restreint comme dans Visual Basic par exemple : dans Visual Basic, un évènement est une action d un utilisateur (cliquer sur un bouton, ouvrir un menu...), tandis Jean-Philippe Caruana février juin

24 que dans Business Bridge, un évènement est déclenché par le passage d une valeur à une autre pour une variable (qui passe de vraie à fausse par exemple) ou le déclenchement d un filtre (voir plus loin) en fonction de certains critères. À chaque évènement, la règle associée se déclenche par la vérification d une condition et un comportement est réalisé. Ce comportement peut être le lancement d un sous-routine. Ainsi, dans Business Bridge, le code (dont la syntaxe est très proche de celui de Visual Basic) peut être contenu dans une règle ou dans une sous-routine. Ce qui diffère la règle de la sous-routine, c est leur mode de lancement : la règle est déclenchée lorsqu un filtre (il s agit en fait d un booléen) passe de la valeur fausse à vraie. Le code correspondant est exécuté. La sous-routine est exécutée à la demande, après un appel (réalisé avec la fonction Call(Sub)). 7.3 Fonctionnement de Business Bridge Les différents éléments de Business Bridge et leurs relations Business Bridge est constitué de plusieurs composants, depuis l extraction des données jusqu à l affichage final en passant par le traitement des données (cf. figureb.1, page 47). Ces éléments sont les suivants : la collecte d informations depuis le Système d Information de l entreprise ; les filtres qui permettent de restreindre le flot d informations à ce qui est utile ; la corrélation entre les données ; l affichage des processus métier ; un affichage plus personnalisé des processus ; le traçage des activités de Business Bridge ; la mise en place du reporting. La collecte d informations Le DataSource service permet la collecte d informations sur le fonctionnement d un processus métier en se connectant au système d information de l entreprise. Cette collecte d informations peut aussi être réalisée par des outils encore plus spécifiques selon la source de données : le Transaction Recorder pour la DataSource telnet ; le Web Recorder pour la DataSource web. Ces deux outils permettent d automatiser des actions répétitives, comme la navigation sur un site web dont on veut extraire des informations à intervalles réguliers. Il existe de nombreux types de DataSources, en particulier : connexion Minitel ; connexion web ; connexion HTTP ; telnet (VT220, IBM) ; lecture dans un fichier ; lecture de messages MQ Series ; récupérations d évènements Patrol ; shell Windows NT... Jean-Philippe Caruana février juin

25 L utilisation des filtres Un filtre a pour but de récupérer l information utile dans les données reçues des Data- Sources. Le fonctionnement d un filtre est simple : il se déclenche sur la reconnaissance d un élément remarquable et récupère les données recherchées dont l emplacement est précisé dans la description du filtre. L utilisation de caractères génériques (parfois appelés jokers ou bien wild cards) est possible et la reconnaissance peut être ou pas, au besoin, sensible à la casse. Un filtre est défini pour une DataSource donnée. Son déclenchement peut à son tour déclencher une règle qui sera suivie d une action. Un filtre est en fait un booléen dont la valeur est fixée par défaut à faux. Ce booléen passe à la valeur vraie à chaque fois que le filtre est déclenché. C est sur cette valeur que s appuie le moteur de Business Bridge pour déclencher les règles correspondantes. Enfin, des filtres peuvent être regroupés dans des pré-filtres pour assurer une meilleure lisibilité du code et améliorer les performances de l application en regroupant les messages de même type. La corrélation entre les données La corrélation entre les données est réalisée par le Correlation Engine et correspond à l exécution des instructions codées dans le Bridget Model (selon les règles mentionnées plus haut). Cette partie est la plus importante de Business Bridge, car c est ici que le développeur Business Bridge passera environ 85% de son temps. L outil permettant la construction d un Bridget Model s appelle le Bridget Builder. Notons que la création des filtres évoqués plus haut est elle aussi réalisée dans le Bridget Builder. L affichage des processus métier La modélisation d un processus métier est réalisée grâce au Process Builder qui permet de construire un Process Model. Il y est nécessaire d établir des indicateurs en fonction de la surveillance à effectuer. L affichage est ensuite réalisé par Business Bridge dans une interface web (c est pour cela que le serveur IIS est nécessaire). L affichage consiste en une liste des indicateurs et d une puce représentant leur état (cf. figure 7.1, page 17). Il est possible pour l utilisateur de disposer d informations plus détaillées sur l état d un indicateur en cliquant dessus. L outil appelé Process Builder permet de créer les Process Models. Vers un affichage plus personnalisé des processus Business Bridge propose en plus de l affichage web des processus un affichage plus personnalisé par le moyen des Dashboards, car l interface proposée par Business Bridge n est pas suffisante ni configurable. Pour palier à ces limites, il est possible d utiliser un Dashboard. Le résultat obtenu est bien plus configurable qu avec l interface web proposée par défaut par Business Bridge, mais le gros inconvénient est l impossibilité de réaliser quelque chose de dynamique, tout doit être codé «en dur», alors que jusqu à présent, il était possible (pour Bridget Model comme pour le Process Model) de coder de manière dynamique, d instancier et de créer des objets au besoin. Un exemple de DashBoard est visible en page 17. Enfin, l outil permettant la création de DashBoards s appelle le DashBoard Builder. Jean-Philippe Caruana février juin

26 Fig. 7.1 Un exemple d interface web pour l affichage des indicateurs Fig. 7.2 Un exemple de tableau de bord pour l affichage des indicateurs Jean-Philippe Caruana février juin

27 Le suivi des activités de Business Bridge Il est nécessaire pour le programmeur de pouvoir «déboguer» son programme. Il dispose pour cela dans Business Bridge d un outil de visualisation des évènements. L outil Log Viewer est dédié à ce travail et l utilisation des couleurs et des filtres le rend très pratique. Le programmeur peut à tout instant de son Bridget Model écrire un message de Log qui sera visible depuis le Log Viewer. La mise en place du reporting Cet outil permet, en sélectionnant les données à archiver et leur présentation de construire un Report Model. C est un outil très limité mais qui peut s avérer néanmoins utile pour certaines applications. C est cependant un outil très peu utilisé au sein de l équipe PréviensNoo Les étapes du développement Pour développer une application avec Business Bridge, il faut procéder en plusieurs étapes (que nous détaillons après) : 1. créer le Brigdet Model 2. créer le Process Model 3. créer le Dashboard (optionnel) 4. créer le Report Model (optionnel) On ne passe évidement à l étape suivante que lorsque l étape en cours est terminée et fonctionne correctement. Jean-Philippe Caruana février juin

28 Chapitre 8 Mode de fonctionnement de l application de supervision MegaVision Nous détaillons ici le fonctionnement général de l application. Nous ne rentrerons pas dans le détail du code, nous nous cantonnerons uniquement aux principes et au déroulement du fonctionnement. Tout le traitement évoqué ici est réalisé par le Correlation Engine, qui reste la partie centrale de Business Bridge. Le fonctionnement est divisé en deux parties : une partie s effectue en tâche de fond sur le serveur supervisé et le traitement est réalisé sur le serveur de supervision. 8.1 Fonctionnement sur les machines distantes Chaque serveur supervisé va effectuer lui même les requêtes nécessaires à la collecte des informations dont on a besoin pour connaître l état. Le lancement automatisé des requêtes est réalisé grâce à l utilisation d un service de type cron. Cela permet de simplifier les problèmes de lecture à distance liés à l utilisation d un utilitaire capable de cela, à cause des problème de noms de domaines qui se doivent d être les mêmes pour fonctionner (cf. justification en annexe C, page 49). Les deux utilitaires BE AdminShell et psservice sont concernés. De plus, il est peut être difficile de prévoir le comportement de ce genre de programmes dans un utilisation à distance en cas de problèmes, tandis qu une connexion FTP est beaucoup plus simple à mettre en œuvre et que le fonctionnement en local de ces utilitaires fonctionne parfaitement bien. Comme nous l avons vu plus haut, la supervision est divisée en deux parties : la partie Infrastructure et la partie Applications Infrastructure En ce qui concerne la partie Infrastructure, il s agit de connaître l état des services présents sur le serveur. L utilitaire gratuit psservice [18] permet cela. L utilitaire psservice a été choisi à cause du manque d informations que donne la commande Windows correspondante qui se contente de lister les services sans en donner l état. De plus, psservice est gratuit (c est un freeware) mais son code est inaccessible. 19

29 Fig. 8.1 Supervision distante d une application Business Bridge Légende des abréviations : DS : DataSource BM : Bridget Model PM : Process Model DB : DashBoard R : outil de reporting Jean-Philippe Caruana février juin

30 L exécution de la commande psservice donne pour chaque service NT présent sur la machine le résultat suivant : SERVICE_ NAME : BE_ CorrelationEngine_ 300 DISPLAY_ NAME : BE Correlation Engine 300 Is the BusinessBridge central unit that executes the logic defined in the Bridget Model. TYPE : 110 WIN32_ OWN_ PROCESS INTERACTIVE_ PROCESS 5 STATE : 4 RUNNING ( STOPPABLE, NOT_PAUSABLE, ACCEPTS_ SHUTDOWN ) WIN32_ EXIT_ CODE : 0 (0 x0) SERVICE_ EXIT_ CODE : 0 (0 x0) CHECKPOINT : 0 x0 10 WAIT_ HINT : 0 x0 On dispose ainsi des informations dont nous avons besoin : le nom du service (ici BE Correlation Engine 300) et son état (ici, état running, valeur de la variable STATE à 4). L autre état possible est stopped et la variable STATE est alors à 1. Les autres informations ne nous sont pas utiles pour le moment. Il est possible de stocker dans un fichier le résultat de ce type de requête en utilisant le caractère supérieur à (>). Ainsi, pour stocker la liste de tous les services NT dans un fichier nommé resultps.txt situé dans le répertoire BBRcmd, la commande devient : psservice > C:\ BBRcmd \ resultps. txt Applications En ce qui concerne la partie Applications, il s agit d avoir la liste de tous les Bridget Models, Process Models et DataSources présents sur un serveur. Ces informations sont facilement accessibles depuis la console d administration graphique de Business Bridge, mais elles sont aussi accessibles depuis l utilitaire BE AdminShell fourni avec la suite Business Bridge. Cet utilitaire a la possibilité de recevoir un fichier contenant la liste des commandes d administration en argument ; ainsi, si les commandes sont contenues dans le fichier CmdBEAdminShell.txt et qu on désire stocker le résultat dans le fichier resultbe.txt, la commande à employer devient : BE_AdminShell C:\ BBRcmd \ CmdBEAdminShell. txt > C:\ BBRcmd \ resultbe. txt Les commandes utiles contenues dans le fichier CmdBEAdminShell.txt sont faciles à utiliser : list : permet d obtenir la liste des objets du service avec lequel on dialogue, Process Service, Bridget Service ou bien DataSource Service ; list running : permet d obtenir la liste des DataSources utilisées. L utilisation de la commande list seule dans la mode DataSource délivre la liste des DataSources non connectées ; ce : permet de dialoguer avec le Bridget Service ; process : permet de dialoguer avec le Process Service (par défaut, l utilitaire nous connecte avec ce service) ; ds : permet de dialoguer avec le DataSource Service ; exit : sort du programme d administration en mode console. Il est bien évidement possible d arrêter ou de démarrer n importe quelle application de supervision depuis la ligne de commande, mais on préférera se servir de l interface Jean-Philippe Caruana février juin

31 graphique pour cela. Cependant, on s aperçoit ici qu il est possible, en plus de la simple supervision, de pouvoir intervenir de manière automatique sur un dysfonctionnement de Business Bridge, de redémarrer un Bridget Model qui s est arrêté par exemple, par le biais du BE AdminShell. Ainsi, si on désire afficher successivement la liste des Process Models, celle des Bridget Models puis celle des DataSources, on écrira dans le fichier CmdBEAdminShell.txt les commandes suivantes 1 : Listing 8.1 Contenu de la liste des instructions demandées au BE AdminShell list ce list datasource 5 list running exit Utilisation du service cron sur chaque machine Puis, il s agit pour chaque serveur supervisé d effectuer ces opérations à intervalles réguliers. Un détail de la justification est donné en annexe C, page 49, en particulier après la page 51 au niveau de la différence entre la commande fournie par Microsoft at et l équivalent Unix du démon cron gratuitement disponible en tant que service [17]. Ainsi, pour exécuter une liste de toutes les commandes toutes les 10 minutes, le fichier crontab contiendra la ligne : 0,10,20,30,40,50 * * * * C:\ BBRcmd \ ToutesLesCommandes. bat Au final, la liste des commandes à exécuter par le service cron est contenue dans un fichier batch nommé ToutesLesCommandes.bat : Listing 8.2 Contenu du fichier ToutesLesCommandes.bat psservice > C:\ BBRcmd \ resultps. txt BE_AdminShell C:\ BBRcmd \ CmdBEAdminShell. txt > C:\ BBRcmd \ resultbe. txt 8.2 Traitements sur le serveur de supervision On se reportera à la partie traitant du modèle des données en page 29 afin de bien comprendre comment ce qui est exposé dans la suite fonctionne. L application de supervision va télécharger les fichiers créés par le service cron exécuté sur chaque machine distante. Ainsi, tous les traitements se feront en local, de façon à minimiser la charge nécessaire au traitement sur le serveurs supervisés en centralisant les traitements sur un serveur dédié. Ce serveur n a pas besoin d être un serveur trop puissant (un simple PC de bureau suffit). Comme pour les machines distantes, le traitement est divisé en deux parties, la partie Initialisation et la partie Supervision. C est pourquoi elles ont été séparées dans deux domaines Business Bridge différents. 1 la connexion avec le Process Service est déjà effective à l ouverture de l utilitaire, il est donc inutile de l ajouter dans le fichier des commandes Jean-Philippe Caruana février juin

32 Fig. 8.2 Fonctionnement de l application Mega Vision Initialisation : domaine dinit Cette partie permet d initialiser la supervision au premier démarrage, mais aussi à chaque démarrage d une instance de supervision. La figure 8.4, page 28 récapitule de façon visuelle ce que nous expliquons dans les lignes qui suivent. Après une initialisation de toutes les variables de travail, l application lit les fichiers de configuration qui contiennent la liste des services et la liste des machines à superviser. Tous les fichiers de configuration se terminent nécessairement par la chaîne de caractères _EOF_ (EOF comme End Of File). Cela permet de détecter la fin d un fichier de manière aisée : un simple filtre sur ce motif déclenche une règle qui permet de passer à la prochaine étape. Ainsi, à la fin de la lecture du fichier qui décrit les serveurs et les applications à superviser, la règle de fin de lecture reofmachines déclenche la lecture du fichier qui contient la liste des services Business Bridge qui doivent être présents sur tous les serveurs supervisés en appelant la fonction correspondante slireconfservices. Cela s écrit très simplement de la sorte : When Do Listing 8.3 Règle dinit/reofmachines fieofmachine Call slireconfservices La liste des services (cf. liste p 34) est disponible dans le fichier BEservices.txt. La liste des serveurs, de leur configuration (utilisateur et mot de passe pour connexion FTP, nom du dossier où télécharger les fichiers) et de la liste des applications (PM, BM) sont présents dans le fichier texte conf.txt. Jean-Philippe Caruana février juin

33 Listing 8.4 Contenu du fichier de configuration des serveurs et de applications supervisés [ serveur ] <dossier,user, password > nombm / PM, versionbm, versionpm, WebName 5 [ PNOOTST4 ] <BBRcmd, FTPuser, bbr > DexOrange, PAPPCM_G1R0C2, PAPPCM_G1R0C2, PAP PCM > super_ supervision, G0R1C5, G0R1C5, MEGA VISION 10 [ PNOOTST3 ] <BBRcmd, FTPuser, bbr > Salle de Pilotage, GRIMG1R1C0, GRIMG1R1C0, GRIM _EOF_ Le nom du serveur est écrit entre crochets ( [ ] ), le nom du dossier où sont présents les fichiers, le nom utilisateur puis le mot de passe FTP sont présentés après le signe inférieur à (<), séparés par des virgules. Chaque application, après le signe supérieur à (>) est décrite, dans cet ordre : nom du projet, version du Bridget Model, version du Process Model, nom Web du Process Model Supervision : domaine dsupervision Lorsque la liste des services nécessaires a été chargée en mémoire après lecture, la supervision peut débuter. Celle-ci est composée de deux phases principales : le téléchargement des fichiers contenant toutes les informations nécessaires à la supervision, puis la lecture de ces fichiers et l analyse des résultats. Téléchargement des résultats Le téléchargement par FTP des fichiers de résultats des requêtes BE AdminShell et psservice est réalisé par la séquence initialisée par la sub slancerftp : création du fichier d ordres FTP (screerfichierordres) et téléchargement à proprement parler (stelecharger) pour chaque serveur jusqu à la fin du téléchargement (règle rfinftp). Le téléchargement est réalisé par connexion FTP depuis la DataSource Windows NT Shell. Il est possible de réaliser une connexion FTP sous Windows avec la liste des commandes (changement de dossier courant, liste des fichiers à télécharger dans un sens ou dans un autre...) contenue dans un fichier texte grâce à l option -s : ftp - s: FTPcmd. txt LeServeur Cette ligne permet de se connecter au serveur LeServeur et d exécuter la liste des commandes contenue dans le fichier FTPcmd.txt. Sous Business Bridge, cela s écrit 2 : Listing 8.5 Subroutine dsupervision/stélécharger Use sfichier As String Use brdynmachine As bcmachine Select ( brdynmachine, iclef Asc, iclef = ilaclef ) 5 sfichier = " C:\ BBRcmd \ FTPcmd. txt " 2 stélécharger prend en argument l entier ilaclef qui est une variable globale contenant l indice du serveur auquel il faut se connecter Jean-Philippe Caruana février juin

34 CommandToSource ( dssuper_ FTPShell, " ftp - s :" & sfichier & " " & brdynmachine. smachine ) Le fichier FTPcmd.txt contient, pour un serveur nommé LeServeur dont l utilisateur est User et son mot de passe UserPassWord les instructions suivantes : Listing 8.6 Contenu du fichier de téléchargement User UserPassWord get resultps. txt C:\ BBRcmd \ Serveur \ PS date. txt get resultbe. txt C:\ BBRcmd \ Serveur \ BE date. txt 5 bye Où l entité date est la date de téléchargement du fichier et le dossier Serveur existe sur le serveur de supervision. Ce fichier est créé pour chaque téléchargement dans la routine screerfichier. La règle rfinftp s active sur le mot clef bye 3 qui déclenche le filtre fifinftp : When Do fifinftp Listing 8.7 Règle dsupersivion/rfinftp icurrentmachine = icurrentmachine // on efface le fichier de commandes par securite DeleteFile ("C:\ BBRcmd \", " FTPcmd. txt ") If ( icurrentmachine < iclefmachine + 1) Then Call slancerftp ( icurrentmachine ) 10 Else // lire les fichiers telecharges icurrentmachine = 0 Call spreparerfichiers // on ajoute des _EOF_ aux fichiers telecharges pour faciliter la suite Call slecture // debut de la lecture 15 End If Notons que le fichier FTPcmd.txt contenant la liste des commandes FTP, et donc le nom utilisateur et le mot de passe, est immédiatement effacé après utilisation pour éviter tout trou de sécurité supplémentaire. Cette règle détermine si il faut ou pas continuer de télécharger des fichiers sur les serveurs. Si le téléchargement est terminé, alors la lecture des résultats peut commencer. L entier global icurrentmachine est gardien de l indice de la machine en cours et l entier global iclefmachine est le nombre de serveurs qu il faut superviser (ce nombre a été créé dans la phase d Initialisation). Lorsque tous les fichiers sont téléchargés, le compteur des serveurs icurrentmachine est réinitialisé et la lecture commence. Lecture des fichiers téléchargés La figure 8.3, page 26 présente de manière visuelle les explications qui suivent. C est la sous-routine rlecture qui est chargée de coordonner la lecture des fichiers : Listing 8.8 Sous-routine dsupervision/rlecture icurrentmachine = icurrentmachine bye permet de clore une connexion FTP Jean-Philippe Caruana février juin

35 Fig. 8.3 Détail du fonctionnement de la lecture des fichiers de résultats Jean-Philippe Caruana février juin

36 Use brdynmachine As bcmachine brdynmachine = Get bcmachine ( iclef = icurrentmachine ) 5 If ( icurrentmachine < iclefmachine + 1) Then If ( brdynmachine. bnonconnectee = False ) Then // lire les fichiers telecharges de cette machine Call slireresultbe ( icurrentmachine ) ElseIf ( brdynmachine. bnonconnectee = True ) Then 10 bnotconnected = True End If Else 15 End If // passer a la suite : verifier toutes les applis Call sverifappli La lecture se fait en cascade : ainsi, après la lecture des applications Business Bridge du serveur en cours (slireresultbe), une règle de fin de lecture (reof_be) déclenche la lecture de la liste des services NT. Cette règle déclenche aussi la liste des actions à réaliser pour mettre à jour les valeurs Listing 8.9 Sous-routine dsupervision/rlireresultbe Use brdynfichier As bcfichier Select ( brdynfichier, iclef Asc, iclef = ilaclef ) Do While ( Fetch ( brdynfichier )) CommandToSource ( dssuper_ ResultFile, brdynfichier. snombe ) 5 Loop Remarque : la sous-routine rlireresultps est presque semblable à rlireresultbe, seul le nom du fichier varie (brdynfichier.snombe devient brdynfichier.snomps). Lorsque la lecture de ce fichier est terminée, la routine rlecture est à nouveau appelée, car c est elle qui indique si tous les fichiers téléchargés ont été lus et si il faut passer à la phase suivante : l exploitation des résultats lus. Exploitation des résultats Cette dernière phase du Bridget Model recopie les valeurs dont le Process Model aura besoin pour afficher les informations qui finalement sont importantes pour l utilisateur final (indicateurs de disponibilité des serveurs, des applications). Jean-Philippe Caruana février juin

37 Fig. 8.4 Schématisation du fonctionnement global de l application Jean-Philippe Caruana février juin

38 Chapitre 9 Structure des données La structure des données doit permettre de disposer en permanence de toutes les informations dont l application a besoin pour fonctionner correctement, c est à dire montrer en temps réel l état des services et briques Business Bridge de chaque serveur PréviensNoo. Pour plus de compréhension, on se reportera au modèle physique des donnée disponible page 30. Comme pour l application, le modèle physique se décompose en deux parties : la partie configuration et la partie des données réelles de chaque application et chaque serveur supervisé. Cependant, avant de décrire ces deux parties, nous faisons une remarque sur le nommage des éléments concernés. 9.1 Remarque sur les noms Le document interne [9] qui spécifie les normes de codage est le document de référence utilisé par tous les développeurs Business Bridge de France Télécom. Les règles énoncées dans ce document sont assez classiques : il faut préfixer chaque variable par son type en minuscule, souvent une seule lettre suffit. C est ce que montre le tableau 9.1. Chaque élément est appelé selon le schéma préfixe nom. Élément classe d objet instance de classe classe d alarme instance d alarme entier chaîne de caractères booléen date préfixe bc br ac al i s b dt Tab. 9.1 Norme France Télécom pour le nommage des principaux éléments (extraits) Ainsi, un entier s appelant clef sera intitulé iclef, et une classe d objets s appellera bcclasse. Dans la figure 9.1, le nom de la classe est situé en haut de la case et la (ou les) clef(s) de la classe sont soulignées ou en police grasse. 29

39 Fig. 9.1 Modèle physique des données de l application Jean-Philippe Caruana février juin

40 9.2 Configuration Cette partie contient toutes les informations de configuration de l application. Ces informations sont rechargées à chaque lancement de l application. bclisteservices iclef snom bappele butilise La liste des services NT dont la présence est nécessaire est gardée dans la classe bclisteservices. Cette liste est recréée à chaque itération du programme. Chaque service est décrit par son nom et deux booléens qui permettent de contrôler leur utilisation dans le Bridget Model. La liste des serveurs à superviser est contenue dans la classe bcmachine. Cette classe sauvegarde l état de la machine (connectée ou pas) et toute la configuration nécessaire pour s y connecter à distance. bcmachine iclef smachine sdossier suser spassword bnonconnectee butilise bcprocessmachine iclef smachine bnonconnectee Notons qu il est nécessaire de dupliquer cette classe sous le nom de bcprocessmachine pour permettre au Process service d afficher correctement les valeurs en temps réel et d éviter les doublons (c est une limitation de Business Bridge). Pour cette classe, seuls les attributs iclef, smachine et bnonconnectee sont présents, car le Process service n est chargé que de l affichage de l information, pas de la traiter. La liste des applications est quant à elle contenue dans la classe bclisteapplis. Chaque application est décrite par les éléments qui la composent : BM, PM et nom Web. Les DS, du fait de la relation de type 1 n qui les relient au BM ne peuvent pas être décrites dans cette classe, car il est impossible de connaître d avance le nombre de DataSources qu il y aura. bclisteapplis iclef iclefmachine snombm sversionbm sversionpm swebname bpresent butilise balarmeenvoyee bcfichier iclef imachineid snombe snomps Enfin, les noms sous lesquels les fichiers téléchargés dans le dossier de chaque serveur concerné sont gardés dans la classe bcfichier. Pour chaque serveur, une instance est créée ; celleci contient les deux noms de fichiers, snombe pour le fichier contenant le résultat obtenu par le BE AdminShell, et snomps pour le fichier contenant la liste et l état de tous les services NT du serveur. Jean-Philippe Caruana février juin

41 9.3 Données Cette partie est découpée en deux : d une part les informations qui ne seront pas vues du Process Model et celles vues du Process Model. À chaque fois que des informations doivent être vues du Process Model, il a été nécessaire de dupliquer presque entièrement la classe et d ajouter la propriété clef à l un des attributs. Cette petite astuce permet au développeur Business Bridge de contourner bien des embêtements lorsqu il programme tout de manière dynamique et flexible, ce qui est notre cas ici. bcappli iclef swebname ipmid ibmid imachineid butilise snombm sversionbm sversionpm Pour chaque application trouvée sur l un des serveurs, une occurrence de cette classe est créée ou mise à jour dans la routine dsupersivion/screerappli. La clef de cette classe est le nom Web de l application afin d éviter les doublons d une même application. Notons une redondance de certains attributs par rapport aux classes bcbm, bcpm, bcds décrites plus bas : le but est d éviter au Correlation Engine une recherche supplémentaire parmi les instances de ces classes et d alléger le traitement des informations. De plus, cette classe est dupliquée en bcprocessappli, la clef supplémentaire est l attribut iclef. bcbm iclef iid imachineid iappliid sprojet sversion ipmid bcpm iclef iid imachineid iappliid sprojet sversion ibmid swebname bcds iclef iid imachineid iappliid ibmid setat smode snom Les classes bcbm, bcpm, bcds décrivent respectivement les BM, PM et DS utilisés par des applications. La plupart des attributs sont renseignés lors de la lecture des fichiers téléchargés, mais les attributs qui font la liaisons entres ces classes (ipmid, ibmid) et la classe bcappli (le lien entre iappliid et iclef de la classe bcappli) sont remplis ou mis à jour lors de la phase de traitement, et notamment dans la routine dsupervision/screerappli. Les classes dupliquées bcprocessbm, bcprocesspm, bcprocessds dans la routine spourlepm prennent, pour les deux premières, l attribut sversion comme clef supplémentaire ; la classe bcprocessds voit l attribut ibmid devenir clef supplémentaire. bcbeservice iclef snom ietat iancienetat imachineid iserviceid butilise bpresentavant Cette classe contient tous le services trouvés sur chaque serveur. Chaque service est décrit de manière similaire à la liste des services attendus (cf. la classe bclisteservice dans la partie configuration, page 31), mais ici l état est pris en compte (notons l attribut iancienetat qui permet de déceler la chute ou le rétablissement d un service en cours de fonctionnement et l envoi d une alarme adéquate) Jean-Philippe Caruana février juin

42 La classe bcprocessbeservice est la duplication à deux clefs de la classe précédante. Elle est allégée par rapport à sa sœur, car toutes les informations ne sont pas utiles pour le Process Model. bcprocessbeservice iclef snom ietat imachineid 9.4 Alarmes Les alarmes sont, comme nous l avons déjà vu, des objets particuliers. Une classe d alarme a été définie pour chaque changement d état remarquable. Nous les détaillons rapidement ci-après : acserviceabsent Cette alarme est envoyée lorsque l un des services requis pour le bon fonctionnement des applications n est pas présent sur l un des serveurs. La liste des services est contenue dans un des fichiers de configuration. acarretservice Cette alarme est envoyée lorsque que l un des services passe de l état de marche running à celui d arrêté stopped ou stopping. acretournormale Cette alarme est envoyée lorsque l un des services précédemment arrêté retourne à l état de marche running. acappliabsente Cette alarme est envoyée lorsqu une application présente dans le fichier de configuration n est trouvée sur aucun des serveurs. acapplidown Cette alarme est envoyée lorsqu une application rencontre une avarie : arrêt ou gel du Bridget Model, du Process Model ou de l une de ses DataSources. acappliup Cette alarme est envoyée lorsqu une application retourne dans un état de fonctionnement optimal dans lequel tout fonctionne parfaitement. Jean-Philippe Caruana février juin

43 Chapitre 10 Conception et spécifications de l application Avant de passer à la réalisation pratique de l application, il est nécessaire de passer par une étape de conception. Les documents qui ont résulté de cette phase [2], [3] permettent, après validation du demandeur, de travailler plus rapidement et de manière conforme aux attentes. La rédaction des dossiers de conception et de spécifications est le résultat de l analyse du problème Conception Le document de conception [2] d une application de supervision doit comprendre les parties suivantes (cf. [7]) ; présentation du processus à superviser ; présentation de la surveillance ; description détaillée de chaque indicateur et bilan. Nous avons déjà vu (page 13) en quoi consistait la supervision métier, aussi nous n y reviendrons pas ici. Les indicateurs choisis sont de type disponibilité et se découpent en deux familles : les indicateurs concernant l infrastructure matérielle en charge de la supervision, aujourd hui trois serveurs Windows NT. Ces indicateurs seront regroupés sous l indicateur principal Infrastructure ; les indicateurs concernant les applications en elles-mêmes qui seront regroupes sous l indicateur principal Applications. Ce découpage est représenté dans la figure 10.1, page L indicateur Infrastructure Pour chaque serveur de supervision (au nombre de trois aujourd hui, respectivement appelés PNPNOOA1, PNPNOOA2, PNPNOOD1), il est nécessaire de lister les services Windows NT requis par Business Bridge pour fonctionner correctement. Ces services sont les suivants : BE AdminService 300 BE AlarmService 300 BE CorrelationEngine 300 BE DataSourceService 300 BE LogService

44 Fig Présentation de la surveillance BE Patrol DataSourceService 300 BE ProcessService 300 BE ReportService 300 BE SNMP DataSourceService 300 BE TNG DataSourceService 300 BE ODBC DataSourceService 300 BE SOAP DataSourceService 300 Chaque service sera disponible si il est dans l état running et indisponible si il est dans l état stopped ou autre ou si il est absent du système L indicateur Applications Process Model Bridget Model Data Source 1 Data Source 2 Data Source 3 Le fonctionnement d une application Business Bridge est simple : le centre est le Bridget Model (BM). Le BM est relié à un seul Process Model (PM) et à une ou plusieurs DataSources (DS), comme indiqué ci-contre. Pour chaque application, et pour chaque BM, PM et DS, un indicateur de type disponibilité est nécessaire. Selon la solution employée, les DataSources à utiliser sont de deux types : soit il s agit de la DataSource WindowsShell couplée à l utilisation du programme BE AdminShell, afin de surveiller les DataSources de façon plus aisée. Cette solution a un inconvénient : si Business Bridge tombe en panne, on ne peux plus utiliser le programme BE AdminShell, car il sera indisponible. soit il s agit de la DataSource Log Reader qui permet d aller chercher dans les fichiers de log les messages qui correspondent à un arrêt d une DataSource. Cette solution a un avantage par rapport à la précédente : elle est indépendante de l état de Business Bridge sur la machine surveillée, mais l inconvénient est qu il sera nécessaire de Jean-Philippe Caruana février juin

45 connaître le code des applications utilisées ainsi que les messages de logs envoyés à la console par la DataSource, et il n existe pour le moment aucune normalisation des messages envoyés au Log Service. Il est possible de consulter directement les fichiers de log par lecture directe dans le fichier, il faut se servir de la DataSource File Reader pour réaliser cela. (Cette DataSource prend en argument le nom du fichier à lire). Cependant, l utilisation de Business Bridge actuellement interdit de surveiller l état des DataSources sur une machines distante par lecture des logs, le filtrage est interdit par Systar Contraintes liées à l application La supervision ne doit gêner en aucun cas le fonctionnement des serveurs qui hébergent les applications supervisées ni surcharger le réseau inutilement. Enfin, l outil utilisé pour ces opérations sera Business Bridge Spécifications Cette partie [3] s appuie sur le dossier de conception et sera la base pour le travail qui suit, celui du codage à proprement parler. Ce dossier de conception exprime une partie des solutions techniques envisagées lors de la phase d analyse et de réflexion Les DataSources employées Elles sont principalement de deux type (Windows NT Shell et Lecture de fichier) mais il reste à explorer la lecture de logs. DataSource Windows NT Shell Nous utilisons cette DataSource pour pouvoir utiliser des instructions MS-DOS et pouvoir ensuite en lire le résultat. Cette Data- Source sert au téléchargement par FTP en ligne de commande des fichiers générés sur chaque machine par les utilitaires BE AdminShell et psservice. Elle s appelle dssuper FTPShell. DataSource File Reader Une première DataSource Lecture de Fichier permet de lire la configuration de l application au niveau des machines à superviser. Ce fichier contient la liste des machines, login et password pour la connexion FTP, nom du dossier où sont situés les documents ainsi que la liste des applications à contrôler sur chaque machine. Cette DataSource s appelle dssuper ConfFile. Dans la même veine, une DataSource Lecture de Fichier est nécessaire pour connaître la liste des services NT à contrôler sur toutes les machines distantes. Cette Data- Source s appelle dssuper BEFile. Enfin, une dernière DataSource Lecture de Fichier est utile quand il s agit de lire les fichiers créés par BE AdminShell sur la machine distante, téléchargés via FTP. Cette DataSource s appelle dssuper ResultFile. DataSource Log Reader (voie restant à explorer) Les applications écrivent dans des fichiers de log, aussi nous servirons-nous de la DataSource Log reader pour lire les informations issues des log des application surveillées. Il en sera créé une par machine distante supervisée. Ainsi, ces DataSources s appelleront respectivement dssuper Log A1, dssuper Log A2 et dssuper Log D1 pour les machines PNPNOOA1, PNPNOOA2 et PNPNOOD1. Jean-Philippe Caruana février juin

46 Les indicateurs de la surveillance au niveau Infrastructure Le tableau 10.1 présente ces différents indicateurs et la légende correspondante. État Icône Conditions Hors surveillance Supervision Impossible Optimal Interrompu Hors période calendaire Problème de connexion Le service est disponible Le service n est pas disponible, ou n a pas été trouvé Tab Seuils et règles de contrôle pour l indicateur des services NT Les indicateurs de la surveillance au niveau Applications Les tableaux 10.2, 10.3 et 10.4 concernant respectivement les indicateurs Process Model, Bridget Model et DataSource sont disponibles en page 37 et suivante. État Icône Conditions Hors surveillance Supervision Impossible Optimal Interrompu Hors période calendaire Problème de connexion Le Process Model est lancé et fonctionne correctement Le Process Model est soit absent, soit gelé Tab Seuils et règles de contrôle pour l indicateur Process Model Jean-Philippe Caruana février juin

47 État Icône Conditions Hors surveillance Supervision Impossible Optimal Interrompu Hors période calendaire Problème de connexion Le Bridget Model est lancé et fonctionne correctement Le Bridget Model est soit absent, soit gelé Tab Seuils et règles de contrôle pour l indicateur Bridget Model État Icône Conditions Hors surveillance Supervision Impossible Optimal Interrompu Hors période calendaire Problème de connexion La DataSource est lancée et fonctionne correctement La DataSource n est pas lancée : elle est à l arrêt ou ne répond plus Tab Seuils et règles de contrôle pour l indicateur DataSource Jean-Philippe Caruana février juin

48 Troisième partie Annexes 39

49 Annexe A Le groupe France Télécom France Télécom est un des principaux opérateurs de télécommunications dans le monde. Le chiffre d affaires consolidé de France Télécom s élève à 11,4 milliards d euros au 31 mars La clientèle est internationale 1 : plus de 111,7 millions de clients servis sur les cinq continents (220 pays et territoires) ; 49,6 millions de clients en téléphonie fixe ; 50,8 millions de clients en téléphonie mobile ; plus de 10,5 millions de clients actifs sur Internet ; grandes entreprises multinationales clientes. A.1 Les activités du groupe France Télécom (source : site intranet de France Télécom [15]). Un organigramme simplifié du groupe est disponible en page 42. A.1.1 La téléphonie fixe C est l activité historique de l entreprise. Sur ce marché de plus en plus concurrentiel, la stratégie de France Télécom repose sur : une qualité de service ; des offres tarifaires simples ; des prestations innovantes. L accès fixe reste la base des télécommunications et s enrichit sans cesse de nouveaux services. A.1.2 Les mobiles France Télécom est aujourd hui l un des principaux opérateurs mobiles dans le monde et l un des véritables fournisseurs de services pan-européens. Il est le premier opérateur en France et au Royaume-Uni, second aux niveaux européen et mondial. A.1.3 Internet Aujourd hui l ensemble des métiers Internet est représenté dans le groupe avec la filiale Wanadoo : 1 chiffres du 31 mars

50 des portails généralistes et spécialisés ; du commerce électronique ; des annuaires ; des solutions d hébergement. Wanadoo, filiale de France Télécom, est un acteur majeur sur le marché européen de l Internet et des annuaires avec, au 31 mars 2003, 8,786 millions de clients Accès Internet, 2,4 milliards de pages vues et, au 31 décembre 2002, plus de annonceurs Annuaires. Wanadoo occupe une position de leader de l Internet en France, au Royaume-Uni et de numéro 2 en Espagne. Wanadoo est également présent aux Pays-Bas et au Maroc. Wanadoo compte 1,6 million d abonnés au câble et à l ADSL. Cette activité regroupe des marques comme alapage.com, PagesJaunes, QDQ.com (l équivalent des Pages Jaunes en Espagne) ou Freeserve (fai au Royaume-Uni). A.1.4 Les services aux entreprises France Télécom, via sa filiale Equant, est un leader des services de télécommunications pour les entreprises de toute taille, leur apportant de la valeur au travers de solutions de communication innovantes et personnalisées partout dans le monde dans les domaines de la voix (téléphonie fixe et mobile), des données (réseaux Intranet et Extranet, connectivité à l Internet, hébergement de sites web) et de l image (transmission, diffusion). Equant est un opérateur de télécommunications spécialisé dans la transmission de données pour les grandes entreprises et détient plus de 10% du marché de l IP et de la donnée pour les multinationales. La transmission de données est le secteur le plus dynamique dans les télécommunications avec 25% de croissance par an. Equant exploite un des réseaux de transmission de données les plus importants du monde, qui couvre 220 pays et territoires, avec des services locaux d assistance dans 145 pays et territoires. Forte de plus de cinquante ans d expérience dans cette activité, Equant sert des milliers de grandes entreprises mondiales. Equant opère sur un réseau virtuel privé mondial depuis 1998 en utilisant des infrastructures issues de SITA, filiale des compagnies aériennes. La société combine les canaux de distribution mondiaux existants d Equant et de Global One, intégrant les accords de France Télécom avec ses filiales et ses affiliés à travers le monde. Les services d Equant, qui s adressent à un public large, permettent d optimiser ses canaux de distribution et d identifier de nouvelles sources de revenus. Enfin, Equant bénéficie des réseaux de distribution exceptionnels de France Télécom en France. Jean-Philippe Caruana février juin

51 Fig. A.1 Organigramme du groupe France Télécom Jean-Philippe Caruana février juin

52 A.2 La Division Systèmes d Information L organisation de France Télécom considère l activité si (Système d Information) comme un centre de coût. En cela, il se doit d être rentable La d.s.i. : fournit à tout le Groupe des compétences et des solutions informatiques : conception et mise en œuvre des architectures fonctionnelles et techniques ; conseil en Systèmes d Information pour les Unités d Affaires et les filiales ; solutions Système d Information : logiciels, progiciels, intégration ; exploitation/soutien et hébergement. crée des services, des liens, de la cohérence : faire converger les flux de données nécessaires à la facturation de plus de 90 millions de clients chaque mois ; mettre en place des outils fédérateurs ; développer la mobilité au service de tout le groupe : la messagerie, l intranet, l annuaire. construit des solutions cohérentes et évolutives dans le temps : anticiper les impacts de l innovation technologique et des besoins de demain sur les métiers et le si ; mettre en place l e-business dans toute l entreprise, assurer la diffusion et le partage des connaissances ; permettre au client final de dialoguer directement avec l entreprise, 24 heures sur 24, 7 jours sur 7. L organigramme de la d.s.i. est disponible en page 44. Jean-Philippe Caruana février juin

53 Fig. A.2 Organigramme de la DSI Jean-Philippe Caruana février juin

54 A.3 Le Service National de Production Informatique Le s.n.p.i. est responsable de l architecture de production et d exploitation et assure la disponibilité, le fonctionnement et la sécurité des applications informatiques du groupe. Il a en particulier pour missions : d assurer la production informatique des applications nationales ; de gérer les données patrimoniales ; d exploiter les grands centres informatiques ; de mutualiser les productions informatiques de filiales ; de proposer aux filiales des offres de services bureau orientés métier et des offres de services de production ; d héberger les plates-formes de développement, intégration et de backup. Le s.n.p.i. doit effectuer ses missions tout en respectant les objectifs de quantité (industrialisation), sécurité, qualité de service et maîtrise des coûts. Fig. A.3 Organigramme du SNPI Jean-Philippe Caruana février juin

55 Annexe B Détails concernant l architecture fonctionnelle de Business Bridge B.1 Contexte Dans les centres de production, le pilotage de la qualité de service se fait actuellement sur une base essentiellement technique, avec une diversité et une dispersion des composants qui ne permet pas de mesurer le niveau de qualité vu des utilisateurs par métier, ni de réagir avec la meilleure connaissance des impacts clients en cas de dysfonctionnement. L objectif du projet PréviensNoo est d améliorer la disponibilité et les performances des chaînes applicatives critiques de l entreprise par la mise en place d une solution de supervision orientée processus métier de la qualité de service. Cette solution doit permettre de : surveiller les applications contenues dans ces chaînes, l ensemble du SI sur lequel reposent ces applications, mais aussi le déroulement de la chaîne elle-même ; réagir dès qu une dégradation est susceptible d affecter soit l utilisateur final, soit le résultat attendu ; historiser les éléments de mesure de performance dans le but de faire des analyses de tendance. Les fonctions des différentes couches logicielles sont les suivantes : Web Service : Il assure la gestion de l interface utilisateur et permet la diffusion et la présentation des informations de contrôle de processus sur les navigateurs Internet des utilisateurs ; Process Service : Il supporte les modèles (Process Model) des processus métiers surveillés. Il assure les fonctions de calcul d impact et il implémente les règles de propagation des états ; Correlation Engine : Il s agit du moteur de corrélation qui traite en temps réel les événements issus des différentes sources d information. Il s appuie sur la modélisation des objets techniques (Bridget Model) et il implémente les règles qui permettent d interpréter le comportement des éléments surveillés pour alimenter le Process Model ; DataSource Service : Il assure l interface avec les applications du système d information ou les agents de supervision en place et prend en charge les phases de connexion, de collecte et de filtrage des informations ; Log Service : Il effectue l enregistrement de tous les messages et les événements générés par Business Bridge ; 46

56 Fig. B.1 Architecture fonctionnelle de Business Bridge Jean-Philippe Caruana février juin