No. 1© Logica 2011. All rights reserved Offre Supervision OFL by LOGICA Offre Supervision OFL by...

No. 1© Logica 2011. All rights reserved Offre Supervision OFL by LOGICA

Offre Supervision OFLby LOGICAMise en place d’un référentiel pérenne

© Logica 2011. All rights reserved Offre Supervision OFL by LOGICA

1. Notations2. Objets du référentiel OFL3. Règles de nommage4. Champs fonctionnels5. Démarche initiale6. Démarche pérenne7. Référentiel & erreurs techniques8. Transcodification9. Référentiel global

Agenda

© Logica 2011. All rights reserved Offre Supervision OFL by LOGICA No. 3

Bonnes pratiques

Fortement conseillé

Point de vigilance

A adapter/A configurer

Mauvaise piste/A éviter

Règles de nommage

Schémas

OFL HORS OFL

Acteur

Module OFL

Notations


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

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



Médiation

Echange

Est composé de 1 à n

Ex: Flux EAI

Ex: WS Champ métier

Extrait de 1 à n

Commun à 1 à n

MessageMessageMessage

Exploit des instances manipulant 1 à n

DocumentDécrit par 1

Application

Erreur

Est associé à 2 (source & cible)

Peut lever 1 à n

Contient 0 à n



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).

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

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 « TECHnical error ».– 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

Règles de nommage


– Cas particulier: les codes erreurs

– Les erreurs fonctionnelles: FUNC-CTRL-NUMSER• Avec:

– FUNC une constante « FUNC » pour « FUNCtional error ».– 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

Règles de nommage


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.

Champs fonctionnels


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.

No. 12

DEV

REFERENTIEL FLUX

Déploiement: import

INTEG

PROD

Spécifieur

Développeur

SFD Echange

Initialisation

Packaging: ExportDéploiement:

importDéploiement:

import

Démarche initiale

Mise à jour erreurs

VALID



La cible reste cependant:

No. 13

DEV


INTEG

PROD

Spécifieur

Urbaniste

Demande de mise à jour du référentiel

Homologation, analyse recoupement & Initialisation

Packaging: ExportDéploiement:

import


REFERENTIEL FLUX

Complément descriptif & adaptation

Démarche pérenne

VALID



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

Référentiel & erreurs technique


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

Transcodification


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 couloirsRéférencement des serveursConfiguration du packaging et valeurs de paramétrageLibrairies, utilitaires et services techniquesProjets & sous-projetsDéclencheurs & notifieursDomaines métier, datastores, silots, espaces de nomContactsAnnuaire UDDISAS et protocolesDocuments, historique & versions pour toutes ces notionsFréquences, capacity planning, performance, tunning systemetc.

No. 16

Référentiel global


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

No. 17



Ses objectifs :Etre exhaustifEtre représentatif et cohérentEtre le reflet exact de la réalitéEtre le fil directeurEtre une autorité de référencePermettre

• D’alimenter l’outil de supervision fonctionnelle• D’être le support de déploiement d’un packaging sur un environnement

No. 18


No. 19© Logica 2011. All rights reserved Offre Supervision OFL by LOGICA

Logica is a business and technology service company, employing 39,000 people. It provides business consulting, systems integration and outsourcing to clients around the world, including many of Europe's largest businesses. Logica creates value for clients by successfully integrating people, business and technology. It is committed to long term collaboration, applying insight to create innovative answers to clients’ business needs. Logica is listed on both the London Stock Exchange and Euronext (Amsterdam) (LSE: LOG; Euronext: LOG). More information is available at www.logica.com

Merci !

Rémy DELMOTTEExpert technique+33 7 86 96 90 [email protected]

Logica Nord, 8 rue Anatole France, 59043 LILLE CEDEX

François-Xavier BRUNArchitecte S.I.+33 6 84 93 28 [email protected]

mailto:[email protected]

mailto:[email protected]

No. 1© Logica 2011. All rights reserved Offre Supervision OFL by LOGICA Offre Supervision OFL by...

Documents

Transcript of No. 1© Logica 2011. All rights reserved Offre Supervision OFL by LOGICA Offre Supervision OFL by...