Offre Supervision OFL by LOGICA Mise en place d’un référentiel pérenne

1. Offre Supervision OFL by LOGICA Mise en place d’un référentiel pérenne

2. Agenda Notations Objets du référentiel OFL Règles de nommage Champs fonctionnels Démarche initiale Démarche pérenne Référentiel & erreurs techniques Transcodification Référentiel global

3. Notations Bonnes pratiques Fortement conseillé Point de vigilance A adapter/A configurer Mauvaise piste/A éviter Règles de nommage Schémas OFL HORS OFL Module OFL Acteur No. 3

4. Objets du référentiel OFL L’Open Framework Logica (OFL) est une solution autonome qui permet de compléter une plateforme de services en proposant un suivi détaillé (technique, applicatif et/ou fonctionnel) des échanges et des médiations ainsi que différents tableaux statistiques. Son positionnement orienté « run » ne le soustrait pas à un référentiel strict des échanges et services du BUS. Le référentiel OFL est une représentation descriptive « temps réel » des différents éléments qui transitent sur le BUS. Le référentiel OFL ne doit pas se substituer à un référentiel de flux global, utilisé en amont pendant les phases de réflexion/spécification et en aval en support au déploiement. No. 4

5. Objets du référentiel OFL Les objets OFL sont une implémentation d’un sous ensemble des concepts liés aux échanges: L’application : représente un acteur applicatif au sein du SI. Le champ métier/fonctionnel : est un extract du message échangé décrivant précisément la nature de l’instance (discriminant fonctionnel). Le document : décrit le message par un regroupement de champs fonctionnels. La médiation : est un traitement d’échange de granularité minimale. Elle est l’unique représentation d’un service unitaire (synchrone ou non). L’échange : est un ensemble cohérent de médiations permettant la représentation d’un échange asynchrone, généralement de type EAI. L’erreur : descriptif d’une erreur pouvant être potentiellement levée par une instance. Il est possible de définir le rejeu d’une instance à partir du descriptif de l’erreur levée. De la même manière, les notificateurs (pour l’exploitation) sont associés à un type d’erreur. No. 5

6. Objets du référentiel OFL Ex: Flux EAI Echange Champ métier Commun à 1 à n Ex: WS Est composé de 1 à n Extrait de 1 à n Médiation Est associé à 2 (source & cible) Application Peut lever 1 à n Contient 0 à n Exploit des instances manipulant 1 à n Erreur Message Message Message Décrit par 1 Document No. 6

7. Règles de nommage Conventions générales: • Utiliser la norme « CamelCase » : la première lettre de chaque mot est en majuscule, le reste en minuscules. • Utiliser seulement [a-z] & [0-9] pour les corps des mots, uniquement [A-Z] pour la première lettre et « . » comme séparateur de version. • Préférer une longueur courte et l’utilisation d’abréviations (en remplissant les descriptifs systématiquement pour plus de clarté). Ex: ESB pour EntrepriseServiceBus. • Ne pas référencer un objet depuis un autre (sauf contre-indication). Ex: même si un service a pour application cible « XRM », préférer « GestionPersonne » à « GestionPersonneXRM ». • Ne pas utiliser de tiret '-', d'underscore '_', d'espace ' ', ou d'autres caractères ($, *, accents, ...). • Pas de « Franglais », préférer l’anglais pour les objets purement techniques et le français pour le reste. • Les versions sont normées comme suit: X.Y.Z… avec XYZ (0-999). No. 7

8. Règles de nommage • Echanges: ActionObjetComplementAppliSource • Ex: DedoulonnagePersonneMorale • Médiation (type étape): AppliObjetBUS ou BUSObjetAppli • Source ou cible • Ex:ReferentielPMBUS, BUSPMXRM, BUSPMSharepoint • Médiation (type service): Service-X.Y-Operation-X.Y • Le service représente au mieux un objet métier • L’opération représente au mieux une action • Ex: Contrat-1.1-RecuperationAdresse-2.3 • Document: NomDocument • Ex:ALMCoreBusinessFields, DiscriminantContrat, ClientExterne • Champ métier: NomChamp • Ex:CodeContrat, IdentifiantMétier • Application: NomApplication • Ex:ESB, ECC, ComptaCore, Sharepoint No. 8

9. Règles de nommage • Cas particulier: les codes erreurs Le code d’une erreur est une composition du quadrigrame (4 caractères max, peut être moins) discriminant de l’application associé au type de l’erreur fonctionnelle ou le code erreur renvoyé par l’ESB pour les erreurs techniques. Il inclut également la technologie sur laquelle l’erreur est survenue (technique) ou un quadrigramme représentatif d’un contrôle fonctionnel (ex: CTDR pour CriTères De Recherche). Il est fortement conseillé de compléter la description du référentiel des applications avec ce quadrigrame. Par défaut utiliser « BUS ». Il faut dissocier les erreurs techniques et fonctionnelles: • Les erreurs techniques: TECH-TECHNO-NUMSER • Avec: • TECH une constante « TECH » pour « TECHnicalerror ». • TECHNO la technologie sur laquelle l’erreur est levée, par défaut « DEFAUT ». • NUMSER un numéro de série pour identifier une erreur particulière sur une techno, par défaut « 000001 » • Ex: TECH-JDBC-001, TECH-BWENGINE-100035 No. 9

10. Règles de nommage • Cas particulier: les codes erreurs • Les erreurs fonctionnelles: FUNC-CTRL-NUMSER • Avec: • FUNC une constante « FUNC » pour « FUNCtionalerror ». • CTRL quadrigramme d’un contrôle fonctionnel sur laquelle l’erreur est levée, par défaut « DEFAUT ». • NUMSER un numéro de série pour identifier une erreur particulière sur une techno, par défaut « 000001 » • Ex: FUNC-CTDR-000001 (CTDR = CriTères De Recherche), FUNC-VALIDATION-000005 No. 10

11. Champs fonctionnels Précisions sur les champs fonctionnels : • Veiller à réutiliser au maximum les champs fonctionnels existants. • Un ensemble de champs par défaut sont proposés : • Ils doivent être utilisés au maximum et complétés pour chaque échange/médiation. No. 11

12. Démarche initiale Il est possible, en l’absence d’un référentiel autonome (et des process associés), d’utiliser une instance OFL dédiée à la mise au point du référentiel. Aucune instance OFL ne doit être en mode « Apprentissage » hormis la DEV. La création du référentiel doit être une opération manuelle. Elle ne peut être automatisée que si elle est en dehors du processus de traitement des instances d’échange. Une construction des erreurs techniques peut être progressive pendant le design entre la DEV et le référentiel central. Développeur Initialisation REFERENTIEL FLUX Mise à jour erreurs Packaging: Export Déploiement: import SFD Echange Déploiement: import PROD Déploiement: import Déploiement: import DEV Spécifieur INTEG VALID No. 12

13. Démarche pérenne La cible reste cependant: Urbaniste Homologation, analyse recoupement & Initialisation REFERENTIEL FLUX Demande de mise à jour du référentiel Complément descriptif & adaptation Packaging: Export Déploiement: import Déploiement: import Spécifieur Déploiement: import Déploiement: import DEV PROD INTEG VALID No. 13

14. Référentiel & erreurs technique Placer le référentiel en mode « non apprentissage » impose de disposer d’un catalogue d’erreurs exhaustif. Sans ce listing, il est possible de visualiser un échange/médiation levant une exception, mais le détail de l’erreur n’est pas sauvegardée et l’instance est considérée par défaut comme « annulée » : En ce qui concerne les erreurs fonctionnelles, cette anticipation ne pose pas de problème : au design il est nécessaire de traiter spécifiquement ce type d’erreurs. Pour les erreurs techniques, il est préconisé de composer, systématiquement et par application, l’exhaustivité des codes erreurs techniques possibles en parcourant le catalogue des codes erreurs de l’éditeur (ex: Tibco BW codes), exception faite des technologies non utilisées dans l’échange (ex: AS400). Un outillage adéquat permet l’initialisation du catalogue à la création d’un échange (référentiel) à partir de l’existant (listing du BUS par exemple). No. 14

15. Transcodification La notion de transcodification est fortement liée au référentiel. Elle peut être gérée par un module classique capable de gérer des valeurs associées au descriptif du référentiel. Les transcodifications sont décrites par les équipes « métier » et peuvent évoluer dans le temps. Ceci impose donc des process (administratifs) et services techniques plus souples qu’une simple livraison d’un environnement à l’autre. Avec OFL, cela se traduit généralement par la mise à disposition de services de chargement de données et d’une architecture intégrant des caches frontaux utilisés suite à la livraison (mode opératoire indépendant). Dans le même ordre d’idée, la notion de nomenclature est techniquement la même implémentation qu’une transcodification 1-1 simple (avec une application purement technique, ex: BUSNomenclature). No. 15

16. Référentiel global Il doit décrire la plateforme d’échange de manière globale avec, à minima, les notions suivantes: Notions de base d’OFL (pour exports) Environnements et couloirs Référencement des serveurs Configuration du packaging et valeurs de paramétrage Librairies, utilitaires et services techniques Projets & sous-projets Déclencheurs & notifieurs Domaines métier, datastores, silots, espaces de nom Contacts Annuaire UDDI SAS et protocoles Documents, historique & versions pour toutes ces notions Fréquences, capacity planning, performance, tunning system etc. No. 16

17. Référentiel global Exemple de MCD d’un référentiel global (voir Offre spécifique ) : No. 17

18. Référentiel global Ses objectifs : Etre exhaustif Etre représentatif et cohérent Etre le reflet exact de la réalité Etre le fil directeur Etre une autorité de référence Permettre • D’alimenter l’outil de supervision fonctionnelle • D’être le support de déploiement d’un packaging sur un environnement No. 18

19. Merci ! Rémy DELMOTTE Expert technique +33 7 86 96 90 48 remy.delmotte@logica.com François-Xavier BRUN Architecte S.I. +33 6 84 93 28 63 francois.xavier.brun@logica.com Logica Nord, 8 rue Anatole France, 59043 LILLE CEDEX