Chaque brique de la plateforme d’échange couvre une partie du

fonctionnement général de la plateforme, le schéma ci-dessus

montre le co-fonctionnement des différents compostant et le
périmètre fonctionnel de chacun.

Ci-dessus une description fonctionnelle de chaque brique fonctionnelle

 Couche Administration : Une console centrale pour administrer les containers, les flux (apache karaf)
 Couche Supervision : Superviser les flows métiers et le traitement des flux. Solution CUSTUM développée à 100% par le CDS.
Répond à des problématique métier § Couche échange : Transformation et routage des flux.
 Couche échange Flux entré et sorti : Réception et l’envoie des Flux

Interne
 Figure 3 : Architecture fonctionnelle de la plateforme d’échanges PEX.
Processeur logique : médiation, transformation, routage,
A la réception du flux la plateforme d’échange PEX, le passe par déférente étapes :
• Intégration : Prise en charge des messages par la plateforme
• Transformation : Transformer le message en format pivot, avec enrichissement
• Routage : Calculer le plan de routage et définir les demi-flux en sorties.
• Traitement : enrichir le message.
• Transformation : transformer le message du format pivot au format de l’application cible avant l’envoi
• Diffusion : Envoi au client.

Dans le workflow d’un flux, les messages passent d’une étape à l’autre en utilisant une file JMS point-à-point dédiée. Pour alimenter la
supervision, une gestion des traces applicatives une file permet d’aliment la base de données à la fin de chaque étape. En cas d’erreur
technique une file d’attente est créé pour pouvoir rejouer les messages. Plusieurs fichiers de configuration sont utilisés pour piloter flux
dans la plateforme d’échange. Dans chaque demi-flux on trouve le fichier suivant :
Fichier de configuration Description
*.cfg Fichier central de la configuration du flux
*.log.cfg Fichier contient les messages de logue
Metadata.xml Information pour identifier le flux
planRoutage.xml Le plan de routage du flux

Interne
 Le diagramme ci-dessous présente les échanges de l’application « Plateforme d’Echange FRET 2.0 » avec les autres applications du SI.
Le découpage des flux est effectué par domaine fonctionnel qui regroupe un ensemble de flux métier déployé dans une instance dédiée sur le serveur de traitement
FUSE.

Figure 4 : Matrice de flux PEX

Interne
 Diagramme Architecture Logique Urbanisée
Le diagramme d’Architecture Logique Urbanisé (ALU) ci-dessous présente l’architecture logique de l’application PEX 2.0

Figure 7 : Schéma d'architecture logique urbanisée de la Plateforme d’Echange FRET

Interne
 1.ARCHITECTURE PHYSIQUE

Cette architecture permet une répartition de charges entre le deux datacenter PA3 et PA4 au
travers le load balancer. Elle permet ainsi de répondre à l’exigence en termes de haute
disponibilité exprimée dans le cahier de charge du projet.

Interne
 Périmètre des ECHANGES
INTEGRATION PAR L’ECHANGE
Paretenaires
Paretenaires
Externes
Partenaires
Externes
Externes Applications Applications
Applications Applications
Groupe SNCF
Applications DuApplications
SI-FRET
Groupe SNCF Du SI-FRET
Groupe SNCF Du SI-FRET
CFT, SFTP, HTTPS, MQ, MAIL …
WEB SERVICE
(A) SERVICE DE SECURITE

(B) SERVICE D’INTEGRATION PAR ECHANGE

(C) SERVICE DE
PERSISTANCE
ENRICHISSEMENT FILTRAGE/ROUTAGE TRANSFORMATION DIFFUSION
DE LA
DONNEES SERVICE DABONNEMENT D’UNE APPLICATION A UN FLUX (D)
(E) SERVICE DE SERVICE DE REJEU DE LA DONNEES (F)
MONITORIN
G ET
SERVICE DE
CARTOGRAPHIE
(G)
D’ALARMING TEMPS REELS DES
SERVICE TRACABILITE DES FLUX ET DES WEB SERVICES
(H)
ECHANGES

(A) SERVICE DE SECURITE

CFT, SFTP, HTTPS, MQ, MAIL …

WEB SERVICE
Applications Applications
Applications Applications
Paretenaires Groupe SNCF
Applications DuApplications
SI-FRET
Paretenaires Groupe SNCF Du SI-FRET
Externes
Paretenaires Groupe SNCF Du SI-FRET
Externes
Externes
DNUM
Interne
  Quel est l’objectif de l’application ?
Centraliser tous les échanges inter-applicatifs afin
d'apporter à l'ensemble des applications les lignes de
services qui garantissent l'opérabilité, la sécurité le
Maintien en condition Opérationnelle

 Garantie la sécurité des Echanges. Un chantier est
en cours le RSSI pour gérer au niveau du socle
l'anonymisation des données et chiffrement
 Le BUS d'Entreprise permet d'abonner n'importe
quelle applications à un flux déjà disponible sur le
BUS.
 De plus, il est possible de mettre la donnée à
disposition aux applications dans le format attendu
(Enrichissement/Routage/transformation
 Mécanisme automatique de rejeu des échanges en
cas d'erreur Technique (indisponibilité d'une
ressource)
 Persistance de la donnée en fonction de la durée de
rétention souhaité par l'application destinatrice:
capacité à resoumettre les flux en entrée à la
demande (ou cas d'incident)
 Traçabilité de tous les Echanges avec un outil de
Supervision Métier permettant de rechercher des
Echanges en fonction de paramètre métier
 Cartographie de tous les flux en temps réel

Interne
  Pourquoi a-t-elle été implémentée ?

 Améliorer l’Opérabilité, la Sécurité et les Maintient en

Condition Opérationnelle les Echanges inter-applicatifs
 Volonté de structurer et optimiser les échanges inter-
applicatifs et de tracer l'activité fonctionnelle
 Permet à l'URBA et aux instances gouvernantes du SI,
d'avoir la cartographie des applications et des
Echanges entre les applications du SI, du groupe SNCF
et des partenaires Externes (Entreprises Ferroviaires et
Gestionnaires d'Infrastructure internationales,
consortium ferroviaires européens …) et Client du
FRET.

 Quel(s) gain(s) sont attendus par l’appli (par rapport à l’appli
précédente) du point de vue métier ?
 La centralisation des Echanges permet de:
 faciliter l'implémentation de l'interfaçage des flux
avec les application
 Mettre en place de processus et d'instance de
gouvernance qui facilite le suivi par le métier des
transformation
 suivre les échanges associé au process métier à
partir de la Supervision Métier
Interne
 Quels gains sont attendus en termes de coûts Run ?
 Création systématique lors de la mise en place d'un flux
ou service, d'alarme pour détecter les anomalies
technique et fonctionnelle
 Depuis la reconstruction de la plateforme sur le DC SI-
FRET et la gestion par un nouveau exploitant, on a une
baisse significative des incidents majeurs.
 Gain en MCO et en disponibilité applicative
 INTEGRATION D’UNE SOLUTION API
MANAGEMENT INTERNE AU SI-FRET

Interne
 LIGNES DE SERVICES NÉCESSAIRES AUX ECHANGES POUR
L’OPÉRABILITÉ, LA SÉCURITÉ ET LE MAINTIENT EN CONDITION OPÉRATIONNELLE

API
COUCHE NIVEAU DE SERVICE FONCTIONANLITES 1 FONCTIONANLITES 2 FONCTIONANLITES 3 FONCTIONANLITES 4 PEX PEX DATA AUTRE SOLUTION
MANAGEMENT
PROTECTION
LOGIN/PASSWORD
A SERVICE SECURITE BLOQUAGE CLES SSH … CRYPTAGE ANONIMISATION 2 2 2
EXPOSITION DU EXPOSITION DU
B SERVICE API MANAGEMENT SERVICE EXTERNE SI SERVICE INTERNE SI 1 2 0
DIFFUSION/RUPTURE
B' SERVICE D'INTEGRATION PAR ECHANGE ENRICHISSEMENT FILTRAGE/ROUTAGE TRANSFORMATION DE PROTOCOLE 4 0 1
C SERVICE DE PERSISTANCE DE LA DONNEES PERSISITANCE ARCHIVAGE PURGE 3 0 0
D SERVICE D'ABONNEMENT Y A LA SOURCE Y DESTIANTAIRE 1 1 1

E SERVICE D'ALARMING ALARMES CONSIGNES AUTO CONSIGNES MANUEL 3 3

F SERVICE DE REJEU DE LA DONNEES RETRY REJEU AUTO REJEU MANUEL 3 1 1
CONSOLIDATION ALIMENTATION ALIMENTATION
G SERVICE DE REFERENCEMENT DE L'ECHANGE DATA AUTO DU REF MANUEL DU REF 1 1 1
CONSOLIDATION
H SERVICE DE TRACIBILITE DATA REMONTE BDD PEX REMONTE DATA API 2 1 2

PEX
PEX + API MANAGEMENT
API MANAGEMENT
NIVEAU DE SERVICE STANDARD

DNUM
Interne
 Périmètre des ECHANGES
INTEGRATION PAR LE SERVICE Les couches A (Sécurité), E
Paretenaires (Alarming), G (Referentiel
Paretenaires
Externes
Partenaires
Externes URBA): ne peuvent être
Externes Applications Applications
Applications
Groupe SNCF
Applications
Applications
DuApplications
SI-FRET implémenté que si la Solution
Groupe SNCF Du SI-FRET
HTTPS Groupe SNCF Du SI-FRET API MANAGEMENT est reprise
a sein du SI
(A) SERVICE DE SECURITE

(E) SERVICE API MANAGEMENT (B’)

SERVICE DE SERVICE DABONNEMENT D’UNE APPLICATION A UN FLUX (D)
MONITORIN
G ET SERVICE DE REJEU DE LA DONNEES (F)
D’ALARMING SERVICE DE
(G)
CARTOGRAPHIE
TEMPS REELS DES
SERVICE TRACABILITE DES WEB SERVICES (H)
ECHANGES

(A) SERVICE DE SECURITE

HTTPS

Applications Applications
Applications Applications
Groupe SNCF
Applications DuApplications
SI-FRET
Groupe SNCF Du SI-FRET
Paretenaires Groupe SNCF Du SI-FRET
Paretenaires
Externes
Paretenaires
Externes
Externes
DNUM
Interne
 Partenaires et Clients FRET Applications SI FRET Applications SNCF
FRONTAL INTERNET FRONTAL APPLICATION SI-FRET FRONTAL eSNCF

API MANAGEMENT FRET PLATEFORME ECHANGE FRET

SECURITE PORTAIL BDD PLAN DE
API GATEWAY DEVELOPPEUR ROUTAGE
API_KEY PORTAIL
ESB
OAuth2 / Monitoring PORTAIL API
TRACE SUPERVISION
ELASTIC
OIDC MANAGEMENT SEARCH

ID PROVIDER FOURNISSEURS DE RESOURCES (Applications SI FRET)

DNUM
Interne
 API MANAGEMENT FRET PLATEFORME ECHANGE FRET
PORTAIL BDD PLAN DE
SECURITE API GATEWAY DEVELOPPEUR ROUTAGE
PORTAIL
API_KEY
TRACE SUPERVISION ESB
OAuth2 / OIDC Monitoring PORTAIL API
ELASTIC
MANAGEMENT
SEARCH

1. Alimente la CARTOGRAPHIE des Services

2. Alimente le VISEUR des ECHANGES pour Rechercher les Traces des
Services
Développement CUSTOM pour
extraire les Traces d’appel des
web Service pour alimenter la
FILE JMS qui est dépilé en
temps réel par l’ESB (alimente 1. Intégration des définitions des API
les TRACES en BDD PEX_TRACE PEX_PDR
et ELASTIC SEARCH

2. Intégration des Traces des Services

DNUM
Interne
 DNUM
Interne