Architecture technique pour la gestion du référentiel Interlocuteur du SIE GPA du 13 février 2013.

Présentation au sujet: "Architecture technique pour la gestion du référentiel Interlocuteur du SIE GPA du 13 février 2013."— Transcription de la présentation:

1 Architecture technique pour la gestion du référentiel Interlocuteur du SIE GPA du 13 février 2013

2 > 2 Rappels et éléments de contexte  Objectif de l’action  Doter le SIE d’un référentiel commun des interlocuteurs, autrement dit des usagers de l’eau  Besoins  Initialement formulé par le projet BNPE  Besoin mis en exergue par le surcroit de complexité que ce manque induisait sur les opérations de « fusion de bases »  Projet à la croisée des bases Agence de l’Eau, DDT, SANDRE…  Egalement exprimé par le projet OSMOSE  Bénéfique à la grande majorité des projets SIE : référentiel transverse utilisé dans la plupart des dictionnaires SANDRE

3 > 3 Démarche 1.Production de 3 documents  Dictionnaire SANDRE : mise à jour des concepts échangés  Règles d’administration : codification, gel, spécificités de l’administration répartie  Architecture technique : flux principaux, outils, règles de synchronisation, cas d’utilisation 2.Validation croisée avec regard sur les autres documents  Dictionnaire SANDRE : ADD (GPS, GPA)  Règles d’administration : GPS (ADD, GPA)  Architecture technique : GPA (ADD, GPS) 3.Passage en CCNSI  Prise en compte des impacts au regard des feuilles de route DSI AE 4.Présentation d’une proposition co-validée CCNSI-SIE aux DG

4 > 4 Démarche 20132012 Maj dictionnaire Sandre Validation ADD / GPS Rédaction doc organisationnel Validation GPS / GCIB Rédaction doc architecture technique Validation GPA Feuille de route ‘CCNSI’ Nouveau CS BNPE Présentation aux DG Fin juin

5 > 5 Discussion présente  Avancement  3 documents à un stade de maturité suffisante pour avis  Première cohérence entre documents assurée  Eléments envoyés au GPA  Document d’architecture pour validation  Dictionnaire et règles d’administration pour vision d’ensemble  Objectif  Présentation du document d’architecture  Synthèse des grands principes  Fourniture de pistes de lecture  Etude en interne avec équipes de développements, architectes…  Retours attendus auprès du groupe de travail (dans un délai d’un mois)  Validation formelle d’une V2 au prochain GPA

6 > 6 Documents tiers (1/2)  Dictionnaire SANDRE  Intervenant  Interlocuteur : reflet du « glissement » de concept  4 catégories :  Particulier  Établissement  Service d’établissement  Structure  Codification revue : code SANDRE systématique, code SIRET obligatoire pour les établissements  Inclusion de la notion de code alternatif (ancien « alias »), pivot pour les autres documents, et d’éléments essentiels pour le dédoublonnage (n° de téléphone)  Modélisation de tous les concepts jugés utiles au SIE :  Identification a posteriori des concepts référentiels : interlocuteur, codes alternatifs, adresse de l’interlocuteur

7 > 7 Documents tiers (2/2)  Règles d’administration  Eléments généraux : identification du référentiel, règles de cohérence, d’intégrité  Administration répartie :  Super-administrateur : SANDRE (aussi passage obligé pour les non sirétés, organe de recours…)  Administrateurs répartis : Agence de l’Eau, services gérant LANCELEAU et SANDRE  Diffuseur : SANDRE au moyen d’un flux direct d’ARCADE  Rappel du principe des alias (ou codes alternatifs) :  Pivot des synchronisations (correspondance et délimitation du périmètre d’échange)  Seule partie du modèle nécessitant une restriction en modification  Gel et chaînage :  Notion de gel clairement définie et dissociée de la cessation d’activité, et réservée aux changements fondamentaux ou corrections d’erreurs  Chaînage métier non pris en charge, donc uniquement assuré pour les rapprochements (lien et champs prévus dans le dictionnaire SANDRE)  Vérification de cohérence avec la base SIRENE

8 > 8 Architecture proposée

9 > 9 Difficultés identifiées et principes retenus  Difficultés identifiées :  Dues à la synchronisation : fréquence et mode de synchronisation, risque de désynchronisation, identification des périmètres à échanger  Dues à l’administration répartie : risques d’écrasements d’information, de pollution des bases partenaires en retour, nécessité ou non de cloisonner les champs d’intervention des administrateurs  Liées à sa mise en application et à sa faisabilité : impact sur les SI partenaires, coûts et délais induits, politique d’initialisation  Positionnements et principes clés retenus :  Synchronisation incrémentale quotidienne, et, à chaud selon demandes  Périmètre : Ne seront échangés entre deux systèmes que les interlocuteurs intéressant les deux parties  Objectif du référentiel : Mettre en commun les interlocuteurs plus que leurs attributs  Base SIRENE utilisée pour la plupart des champs (pour les établissements)  Choix laissé aux partenaires à l’intégration de garder leurs informations ou de les écraser  Non partitionnement des droits des administrateurs (hormis sur les alias)  Intégration voulue la moins invasive possible sur les SI partenaires déjà en place  Initialisation facilitée par la simplicité du modèle et le code SIRET, prévue de façon indissociable de la mise en place des outils

10 > 10 Vues globales  Alimentation

11 > 11 Vues globales  Diffusion

12 > 12 Flux macroscopiques 1.Synchronisation quotidienne 2.Demande de création ou de modification dans le ref. SIE 3.Recherche ou mise à jour de la base partenaire 4.Confrontation par code SIRET et récupération des champs gérés par l’INSEE 5.Versement hebdomadaire des nouveaux interlocuteurs intéressant les métiers utilisant BDNU 6.Copie / duplication à la demande d’interlocuteurs BDNU dans LANCELEAU Non représenté : Basculement d’AE ou LANCELEAU vers SANDRE pour création d’intervenants sans SIRET

13 > 13 Flux élémentaires  Opérations atomiques des échanges : méthodes des WS  Exercice mené :  Vérification croisée que les besoins macroscopiques sont réalisables à partir d’un enchainement des ces 3 méthodes élémentaires GetObjectSummary GetObject SetObject -Critères techniques -Critères thématiques -Critères spatiaux -Critères techniques -Identifiants -Options techniques -Objets à modifier

14 > 14 Périmètres (1/2)  En termes de corpus (quels interlocuteurs s’échanger ?)  Ne seront échangés entre deux systèmes que les interlocuteurs intéressant les deux parties  Traduction technique :  Synchronisation automatique uniquement sur des interlocuteurs possédant un alias du partenaire  Variation du périmètre d’échange uniquement sur action manuelle (unitaire ou en masse)  Prérequis :  Bien définir pendant les phases d’initialisation les interlocuteurs partenaire à mettre en commun

15 > 15 Périmètres (2/2)  En termes de champs (quelles valeurs dans chaque champ ?)  Mettre en commun les interlocuteurs plus que leurs attributs  Indépendamment de cette assertion :  Besoin exprimé par de nombreux partenaires de conserver certaines valeurs de champs différentes de celles connues en central (exemple : façon d’écrire le nom, la raison sociale…)  Risque de conflit humain conduisant à un écrasement « en boucle » des valeurs  Risque de conflit technique  Proposition :  Liberté de conserver chez les partenaires des valeurs différentes de celles en central pour les champs non fondamentaux (la plupart, hormis les codes, le statut, les attributs techniques SIE…)  Appui sur la base SIRENE pour la quasi-totalité des champs des interlocuteurs avec SIRET, persistance en central des dernières valeurs envoyées pour les autres cas  Description d’un processus de synchronisation incrémentale visant à minimiser le risque de conflit technique :  Avant tout envoi de modification, récupération SIE  Partenaire de l’état connu dans le SIE  Si « signature » identique à celle connu chez le partenaire : envoi  Sinon, gestion du conflit nécessaire (cas détaillée dans les UC)

16 > 16 Cas d’utilisation  Panel balayé  Cas généraux  Cas relatifs aux Agences de l’Eau  Cas relatifs à LANCELEAU  Cas relatifs au SANDRE  Le cas des Offices de l’Eau n’est pas oublié mais sera traité différemment, pour prendre en compte les différences importantes en termes de volumétrie et de SI existant  Postulats sur les niveaux d’intégrations nécessaires  Agences de l’Eau :  Transparent pour toutes les applications, sauf celle d’administration des intervenants  Impact réduit pour l’application d’administration des intervenants (quelques écrans probablement à modifier)  LANCELEAU :  Intégration plus forte profitant des développements futurs au travers d’OASIS (induit une prises en compte dans certains écrans, dans les circuits de données…)  SANDRE :  Intégration assez forte sur l’outil existant puisque le SANDRE devra pourvoir remplir son rôle d’administrateur central

17 > 17 Cas d’utilisation général : synchronisation

18 > 18 Cas d’utilisation Agence de l’Eau

19 > 19 Cas d’utilisation Agence de l’Eau Traitement d’un interlocuteur via une application métier Base Interlocuteur AE Cas Résolution d’un conflit technique Envoi auto des ajouts / modifications dans le SIE Nominal Conflit technique détecté Tentative de rapprochement manuel au SIE Création sans code SIRET Rapproché Traitement d’une demande de création par le SANDRE Non rapproché Modifications sur l’applications d’administration des interlocuteurs Mise en place d’une tâche planifiée (et/ou trigger) cliente des services Web ARCADE Très grande majorité des cas : -Interlocuteurs avec SIRET -Interlocuteurs sans SIRET déjà connus du SIE Pas de changement

20 > 20 Cas d’utilisation Agence de l’Eau

21 > 21 Cas d’utilisation Agence de l’Eau

22 > 22 Cas d’utilisation Agence de l’Eau

23 > 23 Flux élémentaires

24 > 24 Impacts estimés de la mise en œuvre  Evolution des outils  Aucun impact a priori sur les applications métiers  Modification / ajout de fonctionnalités et d’écrans sur l’outil d’administration des interlocuteurs  Mise en place des tâches planifiées et/ou triggers pour la synchronisation quotidienne et l’envoi automatique des modifications  ARCADE :  Modifications des WS en fonction des dernières modifications  Adaptation et accompagnement prévu pendant l’intégration chez les partenaires  Autres (infrastructure, organisation…)  Mise en place de flux sécurisés entre serveurs (par exemple, liste blanche de certificats connus entre ARCADE et les SI partenaires…)  Gestion distribuée du projet de mise en œuvre (correspondant dans chaque Agence, environnements miroirs dans chaque SI…)  …