Paris Open Source Summit 2017 - Saturne : La maîtrise des échanges de données massifs par l'open source

Saturne : la maîtrise des échanges de données massifs

par l’open source Paris Open Source Summit 2017

Saturne : la maîtrise des échanges de données massifs par l’open source Paris Open Source Summit 2017

[email protected] [email protected]

mailto:[email protected]

mailto:[email protected]

Saturne : l'origine

La rencontre

Les normes d’échange du domaine social et fiscal

Leurs urbanisations typiques

Sortir d’un existant touffu… … grâce à une vision claire.

Saturne : la vision

Modéliser des normes d’échange

Éviter les développements

Un référentiel unique

Généricité et génération de code

Saturne : la réalisation Illustrations

Les briques et l’analyse de la valeur

Industrialiser

Ressources, REX, bilan

Feuille de route

Saturne : la maîtrise des échanges de données massifs par l’open source

Paris Open Source Summit 2017

Saturne : la maîtrise des

échanges de données

massifs par l’open source


La rencontre d’un opérateur public avec un acteur du libre

N4DS (norme pour la dématérialisation des déclarations de données sociales). Mise en production 2012.





DSN (déclaration sociale nominative) : Remplace une dizaine de déclarations

1 million d’établissements, 15 millions de salariés





DSN (déclaration sociale nominative) : Remplace une dizaine de déclarations

1 million d’établissements, 15 millions de salariés

RGCU (répertoire de gestion des carrières unique) : BDD géante des périodes d’activité professionnelle de tous les assurés

sociaux de France.

Texte de 2010. Mise en production en 2019.

700 millions d’éléments par an entrants et sortants




Les urbanisations typiques du domaine social et fiscal



Net-Dadsu Plateforme

Cnav HTTP

SMTP WS

Filtrage / éclatement par

sous-groupes vers retraite

complémentaire et

prévoyance sous forme de

Dadsu IRC et Dadsu

prévoyance

Livraison Dadsu

TDS tirées des

Dadsu complètes

par Web service

Filtrage /

éclatement par

rubriques vers

partenaires TDS

sous forme hors

norme

WS

Dépôt manuel HTTP

ou envoi PJ SMTP par

déclarants sur net-

Dadsu

Dépôt direct B2B par déclarants

sur plateforme Cnav (WS ?) –

possible seulement si Dadsu

TDS

Liaisons WS entre net-

Dadsu et plateforme Cnav

pour consultation des

bilans par déclarant

IRC IP

FNMF

FFSA

SRE

CNR

ACL Irca

ntec

DGfi

p Cnam

OVD Cnam

AT

CN

FPT

RAEP

CRP

NPA

C CPRP

SNCF

Cavi

mac

net-entreprises guichet MSA

dépôt RG dépôt RAgestion pour OPS de

base et administrations

Cnam Pôle Emploi

Dares

concentrateur retraite

complémentaire

IRC 1 IRC n

concentrateur prévoyance

FNMF

M 1 M n

concentrateur prévoyance FFSA

A 1 A n

concentrateur prévoyance Ctip

IP 1 IP n

Les projets d’échange vont de la collecte chez des déclarants parfois très nombreux (près de deux millions d’employeurs) au filtrage et éclatement de jeux de données multi-métiers, pour des dizaines d’organismes destinataires.

Spécification du format d’échange par tous les partenaires : union des besoins



Spécification du format d’échange par tous les partenaires : union des besoins

Qui confieront à la MOE de chaque point de dépôt la validation des données collectées

Qui confieront à la MOE de leur SI métier la (re-)validation des données collectées



Contrat d’interface sur

Un format technique

XML, CSV, etc.


La vision : définir des normes d’échange


Un format technique

XML, CSV, etc.

Un format logique

Structure de messages, blocs de données, rubriques




Un format technique

XML, CSV, etc.

Un format logique


Des règles de cohérence




Un format technique

XML, CSV, etc.

Un format logique


Des règles de cohérence



Référentiel unique pour les livrables

Documentaires

Binaires (moteurs de validation)

Moteur et règles

Domain Specific Language

Mixer généricité et génération de code

Socle open source


La vision : éviter les développements

La vision : un référentiel unique


• Documentaires Outil de gestion de Norme

Documentation

de la norme

• Saturne : la maîtrise des échanges de données massifs par l’open source Paris Open Source Summit 2017

La vision : un référentiel unique

Outil de gestion de Norme

Documentation

de la norme

Base de

connaissances


• Documentaires

• Binaires


La vision : généricité + génération de code


Documentation

de la norme

Base de

connaissances

Librairie Saturne

Briques génériques

Brique de contrôle

Outil graphique d’autocontrôle

API pour fabriquer ses propres outils




Documentation

de la norme

Base de

connaissance

Librairie Saturne


Brique de contrôle



Contenu métier




Documentation

de la norme

Base de

connaissance

Librairie Saturne


Brique de contrôle



Contenu métier

Contenu technique


Illustrations

• Exemple de contrôle • Exemple d’arbo


Si le Statut du salarié est de

type ‘cadre dirigeant’ (=’03’),

cette rubrique ne peut prendre

que la valeur ’01’ (cadre).

(S21.G00.40.002 = '03') =>

($rub = '01')

S21.G00.40.003/CCH-11

Outils de la DSN : socle open source

Eclipse

Eclipse Modeling


Socle open source

(dev communauté)

Eclipse

Eclipse Modeling

Librairie Saturne

Socle open source

(dev communauté)

Saturne (dev Obeo) Norme (dev

CNAV/Pôle norme)


Outils de la DSN : librairie générique Saturne

Eclipse

Eclipse Modeling

Librairie Saturne NEODeS

Socle open source

(dev communauté)

Saturne (dev Obeo) Norme (dev

CNAV/Pôle norme)


Outils de la DSN : composition avec la norme

Eclipse

Eclipse Modeling

Librairie Saturne NEODeS

Brique de Contrôle

DSN Val

Norme (dev

CNAV/Pôle norme)

Outils générés


Outils de la DSN : génération des outils

Socle open source

(dev communauté)

Saturne (dev Obeo)

Industrialiser

Paris Open Source Summit 2017 Saturne : la maîtrise des échanges de données massifs par l’open source Paris Open Source Summit 2017

Industrialiser


Industrialiser



Industrialiser


Et l’open source dans tout ça?


Ressources et productivité



Compétences (technologies utilisées) côté développement et exploitation Un spécialiste Jenkins, Maven, Tycho, Git… pour l’intégration continue (mutualisé sur d’autres projets) Un auditeur averti en matière de release engineering (mutualisé sur d’autres projets) Des développeurs Java familiers d’EMF

Ressources (environnement, nombre de personnes et profils, pour installer, maintenir, etc.), Serveur d’intégration continue Un environnement pérenne d’homologation des builds (tests, performance, parallélisme).

Support, Par TMA, de toute l’infrastructure

Maintenance et évolution Feuille de route guidée par les besoins des projets et le suivi de l’évolution du socle technique

Charge MOE normes 5 jours pour une itération de

modélisation norme 10 jours pour le DSL des contrôles

sémantiques 10 jours pour une livraison complète 40 jours pour la couverture de tests

initiale d’une norme

Compétences (technologies utilisées) côté développement et exploitation Des développeurs Java intéressés par le fonctionnel (et familiers d’EMF grâce au coaching de la TMA)

Ressources (environnement, nombre de personnes et profils, pour installer, maintenir, etc.), Une à deux personnes par norme / an (pour tous les livrables, toutes les branches et versions) Rechercher la polyvalence Documenter en temps réel (wiki)

Le retour d’expérience



Arbre de modélisation Impossible de construire un moteur de validation efficace quand les blocs de données occupent des places différentes dans l’arbre des instances. Les modèles de messages sont donc construits par restriction sur un message couvrant ;

Gestion de la mémoire Pour décharger les données inutiles il faut définir la portée (scope en termes de données) d’une règle en remontant au contexte le plus haut ; Le moteur de transformation peut employer un mécanisme de déchargement mémoire « agressif » car l’absence de validation sémantique ne rend pas nécessaire de mémoriser les données comme pour exécuter les contrôles dans le cas du moteur de validation ; Généricité Le chemin est étroit entre s’adapter à une nouvelle norme et tordre le méta-modèle. Mais en 2017 on peut considérer que la combinaison d’un socle éprouvé et des mécanismes d’extension possibles fait de Saturne une suite polyvalente et robuste. Il y a aussi des progrès à faire en termes de conception de normes d’échange.

Bilan

Les plus Les moins

Indépendance de chacun Duplication d’efforts Écarts d’interprétation

Modularité par addition Redondance sémantique

Pas de conflits sur les spécifications

Implémentations infidèles

Réingéniérie de service limitée à la façade web

Applis en silos, technologies figées

Les plus Les moins

Partage des entités, des services et des coûts

Pilotage fort au lieu du consensus mou

Modularité par service Unicité des objets

Service unifié rendu à l’usager

La modélisation et de la conception doivent être claires et robustes.

Couvrir 80% des besoins Difficile d’atteindre 100% des besoins.

Approche classique Approche Saturne


33

Merci de votre attention


Technology

Paris Open Source Summit 2017 - Saturne : La maîtrise des échanges de données massifs par l'open source