Référentiels partagés Définition et positionnement dans le SI ·...

DSI .

Référentiels partagés

Définition et positionnement dans le SI

Référence : CNRS / DSI / REFERENTIELS / Référentiels_applications_v5.doc

Date : janvier 2005

Version : 5.0

Auteurs : Equipe Référentiels du projet RUE (Référentiels – Urbanisation – EAI)

Passage de la version 1.0 à 2.0 : Prise en compte des orientations fixées par le groupe de travail sur l’Urbanisation

Passage de la version 2.0 à 3.0 : découpage du document en deux parties : la première sur les généralités et la seconde sur la mise en œuvre des référentiels partagés.

Passage de la version 3.0 à 4.0 : précision sur la localisation applicative des référentiels partagés (reformulation en 4.1).

Passage de la version 4.1 à 5.0 : précision sur les fonctions et services pour les référentiels partagés.

Objet du document :

- Citer les principaux objectifs de la mise en œuvre des référentiels partagés

- Lister le vocabulaire autour des référentiels partagés

- Poser les règles d'identification des référentiels partagés

- Aider à la définition de référentiels partagés

- Définir les fonctions des applications sur les référentiels partagés

- Préciser les services applicatifs autour des référentiels partagés

Référentiels partagés Définition et positionnement dans le SI

CNRS / DSI / REFERENTIELS / Référentiels_applications_v5.doc janvier 2005 1

Sommaire

1. OBJECTIFS DE LA MISE EN ŒUVRE DES REFERENTIELS PARTAGES .....................................................................2

2. VOCABULAIRE SUR LES REFERENTIELS PARTAGES....................................................................................................3

3. DEFINITION D'UN REFERENTIEL PARTAGE.......................................................................................................................5 3.1. COMPOSITION D'UN REFERENTIEL PARTAGE..................................................................................................................5 3.2. LOCALISATION D'UN REFERENTIEL PARTAGE ................................................................................................................5

4. LES META-INFORMATIONS D’UN REFERENTIEL PARTAGE........................................................................................7 4.1. DEFINITION SEMANTIQUE D'UNE INFORMATION DE REFERENCE ...............................................................................7 4.2. VALIDITE DES INFORMATIONS DE REFERENCE ...............................................................................................................7 4.3. STATUT DE L'ETAT DES INFORMATIONS DE REFERENCE .............................................................................................7 4.4. ORIGINE DE L'INFORMATION DE REFERENCE ..................................................................................................................7 4.5. LES PROPRIETAIRES DES REFERENTIELS PARTAGES ......................................................................................................7 4.6. LES CIRCUITS DE MISE A JOUR DES REFERENTIELS PARTAGES.....................................................................................7 4.7. LA MISE A DISPOSITION DE CES META-INFORMATIONS.................................................................................................8

5. LES FONCTIONS SUR LES REFERENTIELS PARTAGES PRESENTES DANS LES APPLICATIONS ..................9 5.1. LES FONCTIONS DANS LES APPLICATIONS PROPRIETAIRES..........................................................................................9

5.1.1. Fonction de mise à jour..............................................................................................................................................9 5.1.2. Fonction d'administration.........................................................................................................................................9 5.1.3. Fonction de consultation...........................................................................................................................................9 5.1.4. Fonction de référencement ........................................................................................................................................9

5.2. LES FONCTIONS DANS LES APPLICATIONS UTILISATRICES ...........................................................................................9 5.2.1. Fonction de mise à jour..............................................................................................................................................9 5.2.2. Fonction de référencement ..................................................................................................................................... 10

6. LES SERVICES APPLICATIFS POUR LES REFERENTIELS PARTAGES .................................................................. 11 6.1. CARTOGRAPHIE GENERALE DES FLUX D’INFORMATIONS DE REFERENCE ...............................................................11 6.2. LES SERVICES DANS LES APPLICATIONS PROPRIETAIRES ............................................................................................12

6.2.1. Service de consultation........................................................................................................................................... 12 6.2.2. Service d’exposition................................................................................................................................................. 12 6.2.3. Service d’introduction de références.................................................................................................................... 12 6.2.4. Service de gestion des dépendances référentielles ............................................................................................ 13

6.3. LES SERVICES DANS LES APPLICATIONS UTILISATRICES..............................................................................................13 6.3.1. Service d’exposition................................................................................................................................................. 13 6.3.2. Service d’introduction de références.................................................................................................................... 13

7. SYNTHESE DES FONCTIONS ET SERVICES APPLICATIFS REFERENTIELS PARTAGES ................................. 14 7.1. SCHEMA POUR UNE DUPLICATION DE REFERENTIEL ENTRE APPLICATIONS.........................................................14 7.2. SCHEMA POUR UNE PRISE EN COMPTE DE REFERENCES EXTERNES AU CNRS........................................................15 7.3. SCHEMA POUR UNE DEPENDANCE REFERENTIELLE ENTRE REFERENTIELS ...........................................................16 7.4. SCHEMA POUR UN PARTAGE DE REFERENTIEL ENTRE APPLICATIONS SANS DUPLICATION ...............................17



1. OBJECTIFS DE LA MISE EN ŒUVRE DES REFERENTIELS

PARTAGES

Dans le cadre de la démarche d’urbanisation mise en œuvre sur le SI de gestion du CNRS, une réflexion a été menée autour de la notion de référentiel pour un système d’information. Cette étude a mis en avant des préconisations sur les référentiels, leur gestion et leur partage.

Deux principaux objectifs sont recherchés : • un meilleur partage des informations de référence, en terme de qualité et de maîtrise des

échanges de référence, • une meilleure réactivité du SI face aux évolutions des informations de référence.

Pour atteindre un meilleur partage, la démarche s’appuie sur une définition claire et partagée de chaque référentiel au travers de fiches référentiel partagé établissant un contour précis du partage de référentiel sur les aspects sémantique, propriété, administration et description. Des modélisations de données (format pivot) avec un ajout systématique de méta informations, et des cartographies applicatives de flux complètent la description.

La réactivité accrue du SI est envisagée par un couplage faible entre les applications utilisatrices des informations de référence. Les informations de référence sont par nature peu mises à jour mais fortement partagées (contrairement aux informations de gestion par exemple). Les informations de référence nécessitent ainsi un fort partage entre les applications du SI, partage qui peut complexifier la prise en compte des évolutions structurelles des informations de référence. Il est donc important de découpler les applications utilisatrices des informations de référence en minimisant les liens directs entre les applications.

Cette réduction des liens directs entre applications, ainsi que la maîtrise des échanges de référence, est un des objectifs de la mise en œuvre de l’outil EAI WebMethods pour le SI de gestion du CNRS.



2. VOCABULAIRE SUR LES REFERENTIELS PARTAGES

Parmi les préconisations émises dans le cadre de la démarche d’urbanisation, une d’entre elles introduit une classification des référentiels. Ainsi, on distingue : • les référentiels dits « externes » qui sont constitués de données issues de l’extérieur du SI

CNRS mais utilisées par le SI de gestion du CNRS, • les référentiels spécifiques au SI CNRS : ceux-ci peuvent être découplés en référentiels dits

d’organisation (structurels) et en référentiels dits internes (non structurels).

Egalement, une préconisation porte sur la localisation des référentiels (application propriétaire ou cliente). Il en ressort notamment 2 types de localisation : • dans une application de gestion qui sera alors propriétaire du référentiel, • dans une application dédiée à la gestion du référentiel, de fait propriétaire du référentiel.

Une autre préconisation tient à enrichir la qualification des informations de référence. Ainsi il est préconisé de compléter les informations de chaque référentiel par des méta informations précisant : • la (ou les) période(s) de validité de l'information de référence (ex.: exercice, année, période, date

d'effet, ...), • le statut (état(s) de référence) de l'information de référence (ex.: provisoire, attente validation,

validée, active, inactive, en cours de création, en cours de modification,...), • l'origine de l'information de référence (ex.: date de création, créateur, référentiel propriétaire,...).

Enfin, une dernière préconisation évoque des services de partage (mode exposition et accès) des référentiels. Ces services sont portés par les applications de gestion : mode exposition si l’application est propriétaire du référentiel, mode accès si l’application est cliente du référentiel.

Ainsi, tout référentiel peut être qualifié de maître dans son application propriétaire (en mode exposition) et d’esclave dans une application utilisatrice (en mode accès).

Le cas échéant, la possibilité d’enrichissement (soit en référence, soit en descriptif) d’un référentiel par une application cliente est autorisée.

La mise en place d’une infrastructure d’EAI, autour de WebMethods, doit faciliter la mise en œuvre de ces services de partage d’informations de référence entre des applications du SI.

Pour cela, l’outil d’EAI exposera les fonctionnalités suivantes : • possibilité de mettre en œuvre des modèles de données (formats pivots) représentant la structure

des référentiels, • possibilité de mettre en place un mécanisme de publication et abonnement pour les applications

propriétaires et clientes des référentiels , • publication des référentiels dans l’EAI à partir des applications propriétaires, avec prise en charge

des étapes suivantes : o le cas échéant, détection automatique des modifications apportées au référentiel dans

l’application propriétaire, o transformation des données du format de l’application source vers le format pivot choisi pour le

référentiel, o publication du référentiel au format pivot. Deux types de publication pourront être mis en

œuvre : - publication complète de tout le contenu du référentiel, - publication limitée aux modifications apportées au référentiel (ajout, suppression ou modifications des données du référentiel dans l’application propriétaire).

• abonnement des applications clientes aux référentiels qui les intéressent, avec : o transformation des données du format pivot vers le format de l’application cliente, o le cas échéant, mise à jour des données dans l’application cliente. Cette mise à jour sera faite

soit par suppression et remplacement des données préexistantes, soit par mise à jour différentielle.

• gestion des échanges de données à mettre en œuvre pour l’alimentation des référentiels externes : o traitement automatique de la réception des données,



o transformation des données source au format pivot choisi pour le référentiel avec possibilité de valider ou enrichir les données par un acteur humain,

o mise à jour des données dans les applications propriétaires des référentiels.

La mise à disposition de référentiels peut s’illustrer ainsi :

Illustration de la mise à disposition de référentiels.



3. DEFINITION D'UN REFERENTIEL PARTAGE

3.1. COMPOSITION D'UN REFERENTIEL PARTAGE

Un référentiel contient des informations de référence.

Une information de référence est principalement caractérisée par la stabilité de sa définition et par un fort accès consultatif.

Le partage entre plusieurs fonctions (zone, quartier ou bloc) est aussi un préalable à tout classement d’une information dans la zone référentielle.

3.2. LOCALISATION D'UN REFERENTIEL PARTAGE

Il n’est pas envisagé de regrouper tous les référentiels dans une base unique centralisée.

Selon l’opportunité (au niveau applicatif, existence d’un PGI ou utilisation par plusieurs PGI ou ...) et selon des règles d’urbanisation, les référentiels partagés peuvent être : • Soit présents dans des applications dédiées exclusivement à la gestion de référentiels partagés, • Soit portés dans les applications prenant en charge des fonctions de gestion du SI.

Les règles d’urbanisation, à considérer comme critère d’éligibilité d’une application de gestion du SI en tant que propriétaire d’un référentiel partagé, sont les suivantes :

1. principe de cohérence forte :

il convient d’examiner les liens du référentiel avec le métier auquel l’application de gestion répond :

o si le référentiel est fortement lié avec le métier de l’application, alors l’application de gestion peut être choisie pour porter le référentiel (principe de cohérence forte),

o si le référentiel n’a pas d’adhérence ou très peu avec le métier de l’application, alors il est préférable que l’application de gestion ne porte pas le référentiel (cohérence faible).

2. cycle d’évolution du référentiel :

il convient également d’identifier le cycle d’évolution (caractère stable ou instable) du référentiel en terme de délai entre 2 changements de description, de périmètre :

o si le cycle d’évolution est court, alors les applications de gestion n’ont pas vocation à porter le référentiel,

o si le cycle d’évolution est long, alors les applications de gestion peuvent être choisies pour porter le référentiel.

Pour la construction de notre SI, nous souhaitons privilégier la règle 1 quelles que soient les conclusions de la règle 2.

En effet, dans le cas d’un cycle d’évolution court, une cohérence forte avec une application de gestion nécessitera une adaptation de cette application pour intégrer l’évolution du référentiel. Le gain recherché en découplant l’application et le référentiel ne serait alors pas obtenu puisque l’impact de l’évolution sera à prendre en considération dans l’application de gestion. C’est pourquoi, il est jugé préférable de donner la priorité à la règle 1 et de faire porter le référentiel par l’application de gestion en cohérence forte avec le référentiel.



Le tableau suivant résume les critères d’éligibilité d’une application pour porter un référentiel :

Cohérence référentiel – application de gestion

Cohérence forte Cohérence faible

Localisation du référentiel Application de gestion propriétaire Application spécifique Référentiel propriétaire

Pour chaque référentiel, il est nécessaire de bien identifier sa localisation et de développer une architecture d'échange (normalisé, anonyme et indépendant) d'informations entre les applications pour faciliter la circulation des informations présentes dans les référentiels partagés. (cf. volet EAI du projet RUE Référentiel - Urbanisation - EAI)).



4. LES META-INFORMATIONS D’UN REFERENTIEL PARTAGE

Pour chaque référentiel partagé, les méta informations décrites ci-après sont recensées dans un document spécifique dénommé « fiche référentiel partagé ».

4.1. DEFINITION SEMANTIQUE D'UNE INFORMATION DE REFERENCE

Toute information identifiée comme information de référence doit obligatoirement faire l'objet d'une définition explicite permettant notamment :

- d'apporter une vision claire et précise du contour de cette information de référence (aucune ambiguïté ne doit exister sur les limites et le contenu de cette information de référence)

- une adhésion de tous les « consommateurs » sur la définition et le contour qu'elle porte (partage de la définition).

4.2. VALIDITE DES INFORMATIONS DE REFERENCE

Dans la mesure du possible, toute information identifiée comme information de référence doit être accompagnée de méta-informations sur la période de validité de l'information comme information de référence (ex.: exercice, année, période, date d'effet, ...).

4.3. STATUT DE L'ETAT DES INFORMATIONS DE REFERENCE

Afin de mieux qualifier l’information de référence, notamment lors de son utilisation par une fonction du SI, il faut essayer de donner, à toute information identifiée comme information de référence,des méta-informations sur le statut de ou des état(s) de référence de l'information de référence (ex.: provisoire, attente validation, validée, active, inactive, ...).

4.4. ORIGINE DE L'INFORMATION DE REFERENCE

Dans la mesure du possible, toute information identifiée comme information de référence doit obligatoirement être accompagnée de méta-informations sur l'origine de l'information de référence (ex.: date de création, créateur, ...).

4.5. LES PROPRIETAIRES DES REFERENTIELS PARTAGES

Tout référentiel partagé doit avoir un propriétaire désigné explicitement.

Pour identifier le propriétaire d'un référentiel, le principe de "primo-créateur" est à privilégier, à savoir que le propriétaire est au plus proche de la création de l'information de référence.

Dans des cas plus complexes, en second lieu, il peut être envisagé d’identifier qui a le droit de suppression sur ces informations pour en déterminer le propriétaire.

4.6. LES CIRCUITS DE MISE A JOUR DES REFERENTIELS PARTAGES

Les circuits de mise à jour doivent être identifiés clairement.

Des responsables (notion de rôles plutôt que d'individus) des mises à jour doivent être déterminés et recensés.



4.7. LA MISE A DISPOSITION DE CES META-INFORMATIONS

La mise à disposition des méta informations est effectué sur le site des Référentiels partagés dans l’espace Urbanisation du site de la DSI (http://www.dsi.cnrs.fr/description_referentiel/).



5. LES FONCTIONS SUR LES REFERENTIELS PARTAGES

PRESENTES DANS LES APPLICATIONS

5.1. LES FONCTIONS DANS LES APPLICATIONS PROPRIETAIRES

5.1.1. Fonction de mise à jour

Des fonctions de création, de modification et de suppression sont à mettre en oeuvre dans l'application propriétaire du référentiel.

Dans le cas (à considérer comme marginal) d’un référentiel porté par plusieurs applications (multi-sources applicatives soit en terme de références, soit en terme de descriptions), les fonctions de mise à jour, mises en œuvre dans chacune des applications propriétaires, doivent être limitées au seul périmètre de propriété des applications.

5.1.2. Fonction d'administration

Des fonctions de validation du référentiel sont à prévoir dans l'application propriétaire du référentiel :

- validation de références introduites dans l'application propriétaire,

- le cas échéant, validation de références proposées par les applications utilisatrices du référentiel auxquelles l'application propriétaire doit apporter une réponse à la demande d'ajout de référence.

Ces fonctions de validation doivent permettre de gérer des validations soit en mode centralisé , soit en mode réparti , et être configurées de telle sorte à obtenir des validations implicites (sans intervention du(es) administrateur(s)) ou des validations explicites.

5.1.3. Fonction de consultation

Des fonctions de consultation du référentiel sont à prévoir dans l'application propriétaire du référentiel pour effectuer des recherches au sein du référentiel:

5.1.4. Fonction de référencement

Des fonctions de référencement dans le référentiel sont à prévoir dans l'application propriétaire. Elles ont pour objectif de permettre l’intégration de références dépendantes issues d’un référentiel porté par une autre application et pour lequel une dépendance référentielle a été établie.

Le référencement consiste à attribuer une identification, dans le référentiel dépendant, de la référence provenant du référentiel source de la dépendance.

5.2. LES FONCTIONS DANS LES APPLICATIONS UTILISATRICES

5.2.1. Fonction de mise à jour

Des fonctions de création, de modification et de suppression sont à mettre en oeuvre dans les applications utilisatrices de référentiel.

Elles ont pour but de prendre en compte les évolutions des informations de référence dans leur référentiel d’origine (référentiel maître).



5.2.2. Fonction de référencement

Pour un référentiel donné, dans le cas où des applications utilisatrices n’identifient pas les références selon les mêmes règles que l’application propriétaire du référentiel, des fonctions de référencement sont à prévoir dans les applications utilisatrices.

Elles ont pour objectif d’attribuer une identification conforme aux règles de l’application utilisatrice à partir des références reçues provenant de l’application propriétaire.


CNRS / DSI / REFERENTIELS / Référentiels_applications_v5.doc janvier 2005 11 11

6. LES SERVICES APPLICATIFS POUR LES REFERENTIELS PARTAGES

Le partage des informations de référence est présenté dans le cadre de l’utilisation de l’EAI webMethods.

Les échanges d'informations (descriptions et valeurs) sont à privilégier en XML.

6.1. CARTOGRAPHIE GENERALE DES FLUX D’INFORMATIONS DE REFERENCE

Le schéma suivant représente les flux d’informations de référence :

- Dans le cas de références externes au CNRS introduites dans notre SI (flux bleus),

- Dans le cas de partage de références entre plusieurs applications de notre SI (flux verts),

- Dans le cas de dépendances référentielles entre référentiels (flux rouges),

- Dans le cas d’identifications différentes d’une même référence entre plusieurs applications (flux marrons).



6.2. LES SERVICES DANS LES APPLICATIONS PROPRIETAIRES

6.2.1. Service de consultation

Un service de consultation est à mettre en oeuvre dans l'application propriétaire du référentiel. Il doit permettre de présenter le contenu du référentiel à toute application utilisatrice sans pour autant que cette dernière n’ait à dupliquer le référentiel parmi ses données.

Il sera donc appelé par les applications utilisatrices du référentiel. Cependant, 2 contextes sont à distinguer :

- Liaison synchrone : dans ce cas, l’application utilisatrice fera appel directement au service de l’application propriétaire,

- Hors liaison synchrone (asynchrone court et long) : dans ce cas, il est préconisé de passer par l’EAI pour appeler le service porté par l’application propriétaire. Il sera alors possible notamment de bénéficier des fonctions EAI de transformations (format pivot) et d’enrichissement le cas échéant.

6.2.2. Service d’exposition

Un service d’exposi tion est à mettre en oeuvre dans l'application propriétaire du référentiel.

Il doit permettre :

- d’exposer les évolutions du contenu d’un référentiel à toute application utilisatrice possédant une duplication du référentiel parmi ses données (le circuit préconisé est que le service de publication de l’EAI s’appuie sur le service d’exposition de l’application propriétaire ; ainsi, les publications d’informations de référence, effectuées par l’EAI, sont déclenchées par l’activation du service d’exposition de l’application propriétaire),

- d’exposer, le cas échéant, dans le cadre de dépendances référentielles, l’identification des références dépendantes dans le référentiel dépendant (l’EAI prenant en charge la gestion des références croisées et dépendantes).

6.2.3. Service d’introduction de références

Un service d’introduction de référence est à mettre en oeuvre dans l'application propriétaire du référentiel.

Il sert à prendre en compte, dans l’application propriétaire, les références externes au CNRS qui seront préparées soit par l’EAI (passage automatisable au format attendu CNRS) soit par le service lui-même (passage semi-automatisable au format attendu CNRS nécessitant une intervention manuelle).

Il sera appelé par l’EAI dès lors que des évolutions de contenu seront détectés par l’EAI (avec ou sans préparation EAI au format attendu CNRS).



6.2.4. Service de gestion des dépendances référentielles

Un service de gestion des dépendances référentielles est à mettre en oeuvre dans l'application propriétaire du référentiel dépendant.

Il sert à prendre en compte, dans l’application propriétaire du référentiel dépendant, les informations de référence et leurs évolutions du référentiel pour lequel une dépendance référentielle a été établie.

Il sera appelé par le service d’abonnement supporté par l’EAI pour lequel l’application propriétaire du référentiel dépendant aura souscrit.

6.3. LES SERVICES DANS LES APPLICATIONS UTILISATRICES

6.3.1. Service d’exposition

Un service d’exposition est à mettre en oeuvre dans les applications utilisatrices de référentiels.

Il doit permettre d’exposer, le cas échéant, les ré-identifications de référence dans des applications utilisatrices qui gèrent une identification différente de celle de l’application propriétaire (l’EAI prenant en charge la gestion des références croisées entre applications).

Ce service appelle le service de publication de l’EAI.

6.3.2. Service d’introduction de références

Un service d’introduction de référence est à mettre en oeuvre dans les applications utilisatrices de référentiels.

Il sert à prendre en compte, dans chaque application utilisatrice dupliquant les référentiels, les évolutions de contenu des référentiels.

Il sera appelé par le service d’abonnement supporté par l’EAI pour lequel les applications utilisatrices auront souscrit.



7. SYNTHESE DES FONCTIONS ET SERVICES APPLICATIFS REFERENTIELS PARTAGES

7.1. SCHEMA POUR UNE DUPLICATION DE REFERENTIEL ENTRE APPLICATIONS



7.2. SCHEMA POUR UNE PRISE EN COMPTE DE REFERENCES EXTERNES AU CNRS



7.3. SCHEMA POUR UNE DEPENDANCE REFERENTIELLE ENTRE REFERENTIELS



7.4. SCHEMA POUR UN PARTAGE DE REFERENTIEL ENTRE APPLICATIONS SANS DUPLICATION

Référentiels partagés Définition et positionnement dans le SI ·...

Documents

Transcript of Référentiels partagés Définition et positionnement dans le SI ·...