Alimentation différentielle de Naïades via services Web suivi d’un début de retour d’expérience sur les architectures de synchronisation de données à base.

Présentation au sujet: "Alimentation différentielle de Naïades via services Web suivi d’un début de retour d’expérience sur les architectures de synchronisation de données à base."— Transcription de la présentation:

1 Alimentation différentielle de Naïades via services Web suivi d’un début de retour d’expérience sur les architectures de synchronisation de données à base de flux entre composants du SIE U. Clain – A. Mauclerc GPA 27/06/2017

2 2 sujets à traiter distinctement
Projet Naïades : Identification d’une tâche de conception (2017) débouchant sur une mise en œuvre (2018) afin de basculer, pour au moins quelques agences, d’une alimentation totale en « annule et remplace » via échange de fichiers à une alimentation différentielle via Web Services Besoin opérationnel, visant à fluidifier les échanges et surtout à aller au devant de problèmes de volumétrie Début de retour d’expérience générique Sur la mise en place d’architectures de synchronisation de données sur la base de flux (WS) entre composants du SIE Sur la base du cas Naïades ainsi que de 2 autres cas en place, à savoir la synchronisation Interlocuteurs ARCADE et les échanges QESOUT sur ADES

3 Naïades

4 Contexte et objectifs Contexte Objectifs de l’action
Alimentation des données physico-chimiques dans Naïades Proposer un processus de collecte des données métier selon un scénario stable, pertinent et performant  ouverture sur une discussion plus générale que Naïades seule Objectifs de l’action Fluidifier / optimiser les processus d’alimentation  automatisation visée Disposer d’un système capable d’encaisser la forte volumétrie de ces données  mode différentiel visé Objectifs du document et de la présentation Souligner les orientations / pré-choix faits par l’équipe projet, argumentaire inclus, afin de les valider et s’assurer de leur faisabilité / pertinence avec les principaux intéressés Faciliter les travaux induits (écriture de CdC chez les fournisseurs, études techniques…)

5 Modes d’alimentation A noter Sujet principal de discussion
Distinguer système d’acquisition et système d’import (le même pour tous les lots de données) Sur Naïades, choix volontaire de (contrairement à ADES) : Soit synchronisation par WS en mode différentiel Soit synchronisation par dépôt de fichiers CSV en mode annule et remplace (sur une plage de temps données) Système de dépôt de fichiers CSV conservé pour les envois massifs et pour les producteurs ne pouvant basculer sur le WS

6 Aspects temporels A noter
Appel préalable (non mentionné ici) du SANDRE pour actualisation des stations (référentiel) Récupération des données en asynchrone (simulé par polling) Estimatif Délai max d’une semaine entre mise à disposition par le producteur et diffusion Délai moyen de 7h entre acquisition et diffusion (temps de traitement)

7 Choix d’architecture et points de vigilance éventuels
Format d’échange : QUESU 3.1 Raison : Version 2 ne prend pas en charge le différentiel et v3.0 implémentée par personne Protocole d’échange : SOAP : à débattre et confirmer avec le SANDRE versus des échanges Restfull Raison : Le QUESU V3.1 impose une implémentation du WS en SOAP Sécurité : HTTPS recommandé Raison : peu de criticité (données non confidentielles) mais facile à mettre en place et évite des attaques possible de type MITM ou Spoofing d’IP

8 Choix d’architecture et points de vigilance éventuels
Asynchronisme : Asynchrone obligatoire : proposition de l’équipe projet Précision : implémentation de la méthode 2 du service monitoring 2.1 : getDataASync() Raison : délai de traitement côté WS producteur au vu du volume potentiel de données Alerte : pas de pagination dans le scénario d’échange, ce qui laisse courir un risque, même en asynchrone et différentiel ! Compression des flux : GZIP : le protocole HTTP ne permet que de le demander « de préférence » mais proposition de l’équipe projet de le rendre obligatoire à l’implémentation Raison : volume potentiel des échanges

9 Choix d’architecture et points de vigilance éventuels
Mode différentiel : Obligatoire : proposition de l’équipe projet Précisions : passe par l’envoi de la dernière date de synchronisation à comparer aux dates de MAJ des objets en bases producteurs, et par l’utilisation de la balise <Action> (sans cela, rejet des objets retournés) Raison : volumétrie des données échangées Granularité minimale des échanges différentiels : L’Opération (au sens SANDRE) Raison : bon compromis entre objet traçable en différentiel dans les banques producteur et volumétrie max induite par ce type d’objet Vigilance : afin d’identifier de façon unique une opération (l’objet élémentaire de toute transaction), Naïades s’appuiera sur le cdStation, le support, la date et l'heure. Cette clé multiple devra être suivie chez chaque producteur. Par ailleurs, toute modification d’un de ces attributs se répercutera, non pas comme une modification côté Naïades, mais comme une suppression + ajout sous la nouvelle clé.

10 Début de retour d’expérience sur les architectures de synchronisation de données à base de flux entre composants du SIE

11 Expériences actuelles
Synchronisation Interlocuteurs AE  ARCADE Synchronisation QESOUT sur ADES Synchronisation QESU sur Naïades

12 Synchronisation Interlocuteurs AE  ARCADE
Direction et déclenchement Synchronisation bilatérale (modifications possibles de part et d’autre du système)  complexité Appel de l’AE vers ARCADE, soit à chaque modification, soit à pas de temps régulier Protocoles et formats : Uniquement via services Web (pas de dépôt institutionnalisé de fichiers ni XML ni CSV) Scénario INC Mode de mise à jour : Différentiel sans balise « Action » Cas de suppression inexistant (gel des objets) donc uniquement notion de mise à jour Granularité : Interlocuteur (objet référentiel donc plus simple) Souplesse du système : Pas de découplage des processus d’acquisition et d’import : problématique Appels synchrones mais paginables Appel des producteurs vers l’organe central : risque d’engorgement

13 Synchronisation QESOUT sur ADES
Options à la disposition du producteur Dépôt de fichier En annule et remplace sur un plage de temps spécifiée En différentiel Appel du service QESOUT

14 Synchronisation QESOUT sur ADES
Direction et déclenchement Synchronisation unilatérale du producteur vers ADES Protocoles et formats : Dépôt de fichiers (fichier XML) ou appel du service Web Monitoring Scénario QESOUT V2 Mode de mise à jour : Annule et remplace sur une plage de temps spécifiée à l’envoi Différentiel via balise Action Granularité : Prélèvement (objet non référentiel donc obligation de disposer d’un identifiant stable) Gérer les suppressions spécifiquement Souplesse du système : Découplage des processus d’acquisition et d’import : atout (WS) Appel d’ADES vers les producteurs : possibilité de mieux séquencer les appels Idée intéressante de rendre les actions « idempotentes » (best practices en Event Sourcing)

15 Tentative de synthèse Sur les synchronisations unilatérales déjà (cas majoritaire) Protocoles et formats Synchronisation via WS ET conservation d’un système de dépôt de fichiers (au moins dans le même format que l’échange WS) semble un bon compromis : sans trop de surcout Mode de mise à jour Différentiel Au niveau scénario, capitaliser sur ce qui est fait sur le QESOUT v2+ et QESU v3+ avec en complément : Gestion de la pagination Définir, peut-être dès le scénario, le niveau de granularité visé, et son identification si non référentiel Idée de rendre les actions idempotentes à creuser Souplesse des systèmes Découplage Acquisition / Import très intéressant De manière plus globale, découplage des flux à plusieurs endroits préconisés (cf. dernière slide) Privilégier les appels du consommateur vers le producteur (meilleure gestion des conflits et des charges) si lien direct entre les 2 Autres HTTPS et GZIP à ancrer : simple à mettre en œuvre et important dans certains cas

16 Ouverture : architecture prometteuse
Issue du CDC (Change Data Capture) et des approches de type Reactive Stream Principes : Découplage complet entre émission des modifications par les producteurs, et consommation par les « abonnés » Outil de Change Data Capture outillant les bases à « surveiller » et transformant les modifications en événements Outil central offrant un mécanisme de PubSub (Publication / Abonnement) Principes anciens, mais maturité récente des solutions sur étagère CDC Producteur 1 Modifications DEBEZIUM Change log Publish Subscribe CDC Producteur 2 Modifications DEBEZIUM Change log KAFKA Banque centrale CDC Producteur 3 Modifications DEBEZIUM Change log