#OSSPARIS17 - Saturne : la maîtrise des échanges de données massifs par l’Open Source, par ROMAIN GUIDER et OLIVIER ROSEC

Saturne : la maîtrise des échanges de données massifs
par l’open sourceParis Open Source Summit 2017
Saturne : la maîtrise des
échanges de données
massifs par l’open source
Paris Open Source Summit 2017
Olivier.Rosec@cnav.fr
Romain.Guider@obeo.fr

 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

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.
Les normes d’échange du
domaine social et fiscal

données sociales).
 DSN (déclaration sociale nominative) :
 Remplace une dizaine de déclarations
 1 million d’établissements, 15 millions de salariés

données sociales).
 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
Net-Dadsu Plateforme
CnavHTTP
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 guichetMSA
dépôtRG dépôtRA
gestionpourOPS de
base etadministrations
Cnam Pôle Emploi
Dares
concentrateur
retraite
complémentaire
IRC1 IRCn
concentrateur
prévoyance
FNMF
M 1 Mn
concentrateur
prévoyance FFSA
A 1 A n
concentrateur
prévoyance Ctip
IP 1 IPn
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
Sortir d’un existant touffu…
… grâce à une vision claire.

 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
Sortir d’un existant touffu…
… grâce à une vision claire.

Contrat d’interface sur
▪ Un format technique
▪ XML, CSV, etc.
La vision :
définir des normes d’échange

▪ XML, CSV, etc.
▪ Un format logique
▪ Structure de messages, blocs de
données, rubriques
La vision :

▪ XML, CSV, etc.
▪ Un format logique
▪ Structure de messages, blocs de
données, rubriques
▪ Des règles de cohérence
La vision :

▪ 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
Référentiel unique pour
les livrables
• Documentaires
Outil de gestion
de Norme
Documentation
de la norme
• Saturne : la maîtrise des échanges de données massifs par l’open source

La vision :
un référentiel unique
Outil de gestion
de Norme
Documentation
de la norme
Base de
connaissances
Référentiel unique pour
les livrables
• Documentaires
• Binaires

La vision :
généricité + génération de code
Outil de gestion
de Norme
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

La vision :
Outil de gestion
de Norme
Documentation
de la norme
Base de
connaissance
Librairie
Saturne
Briques
génériques
Brique de contrôle
Contenu
métier

La vision :
Outil de gestion
de Norme
Documentation
de la norme
Base de
connaissance
Librairie
Saturne
Briques
génériques
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 2017Saturne : la maîtrise des échanges de données massifs par l’open source

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

#OSSPARIS17 - Saturne : la maîtrise des échanges de données massifs par l’Open Source, par ROMAIN GUIDER et OLIVIER ROSEC

Recommandé

Recommandé

Contenu connexe

Similaire à #OSSPARIS17 - Saturne : la maîtrise des échanges de données massifs par l’Open Source, par ROMAIN GUIDER et OLIVIER ROSEC

Similaire à #OSSPARIS17 - Saturne : la maîtrise des échanges de données massifs par l’Open Source, par ROMAIN GUIDER et OLIVIER ROSEC (20)

Plus de Paris Open Source Summit

Plus de Paris Open Source Summit (20)

#OSSPARIS17 - Saturne : la maîtrise des échanges de données massifs par l’Open Source, par ROMAIN GUIDER et OLIVIER ROSEC