Plateforme d'Echange et de Confiancetelechargement.modernisation.gouv.fr/.../SGMAP_contratservice_PEC.pdf · Plateforme d'Echange et de Confiance Contrat de Service •Avis de dépôt

Plateforme d'Echangeet de Confiance

Contrat de Service

Plateforme d'Echange et de ConfianceContrat de Service

SOMMAIRE

1 INTRODUCTION .............................................................................................................. 4 1.1 Objet du document ......................................................................................................................... 4 1.2 SGMAP .......................................................................................................................................... 4 1.3 Plate-forme d’Échanges et de Confiance ....................................................................................... 4 1.4 Message Générique ........................................................................................................................ 4

2 FONCTIONNALITÉS DE LA PEC ..................................................................................... 5 2.1 Annuaire ......................................................................................................................................... 5 2.2 PEC Asynchrone et Synchrone ...................................................................................................... 5 2.3 Outils de confiance ......................................................................................................................... 5

3 PEC ASYNCHRONE ........................................................................................................ 6 3.1 Synthèse des fonctionnalités ......................................................................................................... 6

3.1.1 Avis générés par la PEC ......................................................................................................................................... 6 3.1.2 Protocoles de communication supportés ................................................................................................................ 7

3.2 Cinématiques d’échange ................................................................................................................ 8 3.2.1 Cas nominal ............................................................................................................................................................ 8 3.2.2 Cas d’erreur avant l’envoi du message (Avis de Non Dépôt) ................................................................................ 9 3.2.3 Cas d’erreur sur l’envoi (Avis de Non Livraison) .................................................................................................. 9

3.3 Format du message ....................................................................................................................... 10 3.3.1 Structure du message ............................................................................................................................................ 10 3.3.2 Spécifications de la structure du message ............................................................................................................ 11 3.3.3 Convention de nommage des avis de dépôt et de livraison .................................................................................. 11

3.4 Les connecteurs de la PEC Asynchrone ....................................................................................... 12 3.4.1 Connecteurs Presto .............................................................................................................................................. 12

3.4.1.1 Presto 2.0 / 2.0.1 : Partenaire Expéditeur � PEC .......................................................................................................... 14 3.4.1.2 Informations à fournir pour le mode Presto Complet ..................................................................................................... 15 3.4.1.3 Presto 2.0 / 2.0.1 : PEC � Partenaire Destinataire ........................................................................................................ 16

3.4.2 (S)FTP(S) .............................................................................................................................................................. 16 3.4.2.1 (S)FTP(S) : Partenaire Expéditeur � PEC ................................................................................................................... 16 3.4.2.2 (S)FTP(S) : PEC � Partenaire Destinataire ................................................................................................................... 17

3.4.3 SMTP .................................................................................................................................................................... 18 3.4.3.1 SMTP : PEC � Partenaire Destinataire .......................................................................................................................... 18

4 PEC SYNCHRONE ........................................................................................................ 20 4.1 Fonctionnalités de PEC Synchrone .............................................................................................. 20

4.1.1 Protocoles de communication supportés .............................................................................................................. 20 4.2 Cinématiques d’échange PEC Synchrone .................................................................................... 20

4.2.1 Cas nominal .......................................................................................................................................................... 20 4.2.2 Cas d’erreur ......................................................................................................................................................... 21

4.3 Structure des échanges PEC Synchrone ....................................................................................... 21 4.3.1 Contrat d’interface du connecteur ....................................................................................................................... 22 4.3.2 Méthodes à utiliser ............................................................................................................................................... 22

4.3.2.1 Méhtode « invoke » ........................................................................................................................................................ 22 4.3.2.2 Méthode « invokeTemplateWS » .................................................................................................................................... 23

4.3.3 Format des descriptions logiques de l’émetteur et du destinataire ..................................................................... 24

Plateforme d.odt Page 2 / 31


4.4 Le connecteur de la PEC synchrone ............................................................................................. 24

5 CONVENTION DE SERVICE ........................................................................................... 26 5.1 Niveaux de service ....................................................................................................................... 26

5.1.1 Heures d’ouverture des services ........................................................................................................................... 26 5.1.2 Arrêts réguliers de la production ......................................................................................................................... 26 5.1.3 Niveau de service de la PEC ................................................................................................................................ 26 5.1.4 Les délais de prévenance pour les arrêts planifiés ............................................................................................. 27

5.2 Gestion des incidents ................................................................................................................... 27 5.2.1 Incidents .............................................................................................................................................................. 27 5.2.2 Communication entre les parties suite à incident ................................................................................................ 27 5.2.3 Les traces enregistrées par la PEC ...................................................................................................................... 28 5.2.4 Communication et conservation des traces .......................................................................................................... 28



1Introduction

1.1Objet du document

Le but de ce document est de définir le contrat de service de la Plate-forme d’Échange et de Confiance (PEC) du SGMAP. Il décrit ses conditions d’utilisation, les cinématiques d’échanges, les typologies de messages, le format du message générique, les modes d’interfaçage et spécificités par protocoles d’échange.

Le document fourni toutes les informations nécessaires à un partenaire lui permettant de se raccorder à la PEC et d’utiliser les services qu’elle met à disposition.

1.2SGMAP

Le Secrétariat Général pour la Modernisation de l’Action Publique (SGMAP) a pour mission de coordonner, d’aider et d’inciter, au niveau interministériel, les administrations en vue de moderniser les modes de fonctionnement et de gestion de l’État pour améliorer le service rendu aux usagers, contribuer à une utilisation plus performante des deniers publics et mobiliser les agents publics.

Le SGMAP est au service des ministères pour coordonner leurs actions de réformes, les aider et les inciter dans leur modernisation. Elle pilote en particulier les audits de modernisation, le plan ADELE d’administration électronique, les lois de simplification et la politique de qualité au sein de l’État. Elle anime aussi le réseau des secrétaires généraux des ministères.

1.3Plate-forme d’Échanges et de Confiance

Le SGMAP met à disposition une plate-forme d’échange de message de données entre administrations, collectivités et partenaires de l’administration. Surnommée la PEC, cette dernière amène un transport fiable de bout en bout des messages d’informations à travers des réseaux hétérogènes.

La PEC met à disposition une série d’interfaces/connecteurs (PRESTO, Web Service, FTP, etc.) permettant aux autorités de s’interconnecter et d’inter-opérer.

L’objectif est de faciliter l’interopérabilité technique entre entités distinctes, via la publication d’interfaces d’échanges génériques, reposant si possible sur des standards.



1.4Message Générique

Les entités communiquant entre elles via la PEC (autorités administratives et partenaires), utiliseront un message dit générique, dont le mode de fonctionnement et la cinématique seraient identiques quel que soit l’application ou le partenaire d’origine/destination de l’échange.



2Fonctionnalités de la PEC

La PEC fourni un ensemble de service aux administrations et collectivités afin de leur faciliter les échanges.

2.1Annuaire

PEC comprend un annuaire des Autorités Administrative (AA) permettant de stocker les informations techniques nécessaires lors d’une connexion vers cette autorité. Par exemple, l’annuaire contient des adresses IP, des numéros de port, etc.

Cet annuaire identifie les AA via un quadruplet PAYS/SIRET/SERVICE/GUICHET (l’utilisation du champ SIRET pourra être adapté pour les pays étrangers) et permet ainsi aux utilisateurs de la PEC de faire abstraction dans leurs démarches des informations techniques des partenaires.

2.2PEC Asynchrone et Synchrone

La PEC met à disposition de ses partenaires, 2 modes d’échanges distincts :

•Les échanges dit « asynchrones » : il s’agit des échanges de message en temps différé. Ce mode de communication ne nécessite pas une connexion simultanée entre les partenaires émetteurs et destinataires d’un message, ce qui permet un découplage temporel entre les 2 acteurs de l’échange. Le partenaire émetteur de l’échange ne reste pas en attente d’une réponse du partenaire destinataire et peut continuer ses traitements après livraison du message à la PEC. Ce mode de communication sera préconisé pour des besoins d’échange réputés fiables sans contrainte de temps de traitement (aucun impératif de réponse en temps réel)

•Les échanges dit « synchrones » : Il s’agit de l’invocation des services applicatifs exposés par les partenaires de la PEC. Dans ce cadre, le partenaire appelant reste en attente d’une réponse du partenaire fournissant le service à travers la PEC. Ceci nécessite une connexion simultanée des 2 partenaires avec la PEC. Ce mode de communication sera préconisé pour des besoins d’échanges en temps réels (Accélération des dialogues pour obtenir les réponses dans des délais courts). PEC Synchrone affranchit l’expéditeur des problématiques de sécurité (gestion des certificats, etc.) éventuellement exigés par le service distant et mis à disposition par le partenaire destinataire.

2.3Outils de confiance

(A venir)



3PEC Asynchrone

3.1Synthèse des fonctionnalités

Les principales fonctionnalités de PEC Asynchrone sont les suivantes :

•Routage du message vers le partenaire : détermination des adresses physiques à partir d’adresse logique du type PAYS/SIRET/SERVICE/GUICHET

•Médiation de protocole : la PEC s’adapte aux protocoles existants des partenaires et leur évite ainsi de devoir s'accommoder aux protocoles de l’ensemble de partenaires avec lesquels ils communiquent

•Acheminement des Message, avec :

oGarantie de livraison, qui assure qu’un message pris en charge par la plate-forme est livré avec certitude, ou un compte rendu d’impossibilité de livraison est retourné à l’émetteur

oGarantie de la non-perte, qui assure aucune perte de message quel que soit l’événement survenant sur la plate-forme (suite à des reprises à chaud ou à froid d’un composant de la plate-forme, plantage des serveurs, arrêt/démarrage d’un service, etc.)

oGestion des doublons, qui assure qu’un message pris en charge ne sera jamais livré en double à son destinataire, sauf suite à une demande explicite de l’émetteur

•Pas de garanti de l’ordre d’acheminement ou de priorité des messages : La PEC Asynchrone ne garantit pas l’ordre de traitement des messages reçus. Autrement dit, même si la PEC reçoit les messages A puis B puis C, il n’y a aucune garantie que le destinataire les reçoive par la suite dans l’ordre d’arrivée.

•Supervision des messages permettant de fournir une visibilité de bout en bout sur l’exécution des messages, mais aussi de faciliter la prise en charge de la résolution des problèmes rencontrés lors des échanges sur la plate-forme

•Génération/gestion des avis de livraison et de dépôt

•Connectivité à plusieurs réseaux : INTERNET, SIGMA Administration, SIGMA partenaires

3.1.1Avis générés par la PEC

Lors de la soumission d’un message vers la PEC, l’émetteur a la possibilité de demander des avis pour connaître l’état d’avancement de sa demande.



•Avis de dépôt (AVD) : PEC indique à l’émetteur que le message a bien été reçu et est conforme aux exigences du contrat de service de la plate-forme PEC. Dans une version à venir, cet avis pourra inclure l’horodatage du message envoyé.

•Avis de non dépôt (AND) : PEC indique que le message n’est pas conforme aux exigences du contrat de service PEC (il existe des erreurs et il n’est pas possible de prendre en charge le message). Ces erreurs peuvent être liées à une incompatibilité des règles de sécurité (ex : message sensible émis via une zone et un protocole insuffisamment fiable), un destinataire inconnu, etc. Cependant, la non intégrité du message (ex : fichier zip corrompu, …) ou un non-respect du format de l’enveloppe normalisée (message.xml) ne permettent pas de retrouver l’émetteur et donc de lui envoyer un avis de non dépôt.

•Avis de livraison (AVL) : PEC indique à l’émetteur que l’acheminement du message et sa livraison au destinataire ont été réalisés selon le protocole établi.

•Avis de non livraison (ANL) : PEC indique à l’émetteur que le message n’a pas pu être acheminé jusqu’au destinataire pour des raisons techniques.

3.1.2Protocoles de communication supportés

Les principaux protocoles de communications pris en charge par la PEC sont les suivants :

•En entrée de PEC (sens Partenaire vers PEC) :

oFTP

oFTPS

oSFTPPlateforme d.odt Page 8 / 31


oPRESTO V2.0 / V2.0.1

�sur http

�https - SSL 1 way (authentification serveur)

•En sortie de PEC (sens PEC vers Partenaire)

oFTP

oFTPS

oSFTP

oPRESTO V2.0 / V2.0.1

�Sur http

�https - SSL 1 way (authentification serveur)

�https - SSL 2 way (authentification client et serveur)

oSMTP

Pour des raisons de sécurité, la PEC n’autorise des protocoles non chiffrés que sur le réseau SIGMA. Sur Internet, les échanges sur http ou FTP par exemple ne sont pas acceptés.

3.2Cinématiques d’échange

Les schémas ci-dessous décrivent la cinématique logique d’échange des messages utilisant PEC Asynchrone.

3.2.1Cas nominal

Cette cinématique décrit le cas nominal (sans erreur) d’échange entre un expéditeur et un destinataire.



Le message transmis au destinataire est exactement le même que celui fourni initialement par l’expéditeur. La plate-forme ne modifie aucune information (ni le format du message, ni le nom des fichiers).

Remarque : la pertinence de l’avis de livraison est dépendante de la qualité de service du protocole offert par le destinataire (PRESTO autorise une certaine confiance dans l’acheminement ; le protocole FTP nous garantit que la livraison est effective mais sans garantir l’intégrité ; le protocole SMTP n’offre aucune garantit d’acheminement).

3.2.2Cas d’erreur avant l’envoi du message (Avis de Non Dépôt)

Cette cinématique décrit le cas où une erreur fonctionnelle est détectée avant envoi du message au destinataire par la plate-forme d’échanges. Ceci concerne l’ensemble des cas d’erreur de traitement du message au sein de PEC avant envoi.

Le rejet peut être dû à une mauvaise identification de l’émetteur ou du destinataire, un message interdit, un niveau de sécurité exigé non respecté, etc.



3.2.3Cas d’erreur sur l’envoi (Avis de Non Livraiso n)

Cette cinématique décrit le cas où une erreur est détectée pendant l’envoi du message vers le destinataire.

L’erreur rencontrée peut être due à l’impossibilité de joindre le serveur du partenaire, des identifiants incorrects, etc.

3.3Format du message

Dans son mode de fonctionnement nominal, PEC emploie un format d’échange basé sur un fichier zip structuré de manière spécifique. Ce format d’échange est appelé « message PEC ».

3.3.1Structure du message

Un message PEC est constitué d’un fichier zip composé de :

•Un fichier XML nommé « message.xml » contenant :

oUn en-tête (balise « Header ») regroupant les informations nécessaires au traitement et acheminement du message

oUn corps (balise « Body ») regroupant les informations métiers (structure libre dans une balise « Content ») ou d’avis/accusé (structure définie par PEC, dans une balise « Acknowledgement »)

•Optionnellement N pièces jointes (de nombre et format libres).



Le message métier se retrouve donc dans le corps du fichier « message.xml » et l’ensemble des pièces jointes intégrées au fichier zip.

La structuration et le contenu du champ Body-Content sont libres et propres aux définitions des échanges. La plate-forme PEC n’utilise pas ce champ pour ses traitements...

Contraintes :

•Le fichier message.xml généré doit être un fichier XML valide respectant le schéma XML défini (cf. § 12)

•Le fichier zip transmis par l’émetteur doit être un fichier au format zip intègre et contenant le fichier « message.xml » ainsi que les pièces-jointes attendues.

•Chaque nom de fichier contenu dans le fichier zip doit être encodé en ANSI (aucun caractère spécial ou accentué) ou en UTF-8. Aucun autre encodage n’est toléré.

•Le nom du fichier zip ne doit pas contenir de caractères spéciaux (espace, guillemet, etc.) et doit se terminer par l'extension « .zip » en minuscule.

3.3.2Spécifications de la structure du message

Fichier Excel contenant la structure et la description des champs du fichier message.xml :


OpenDocument Spreadsheet


Fichier XSD contenant le schéma XML du fichier message.xml :

3.3.3Convention de nommage des avis de dépôt et de livraison

Les avis de dépôt et livraison (AVD, AND, AVL, ANL) sont comparables à des messages métiers nécessitant d’être acheminés vers leur destinataire. Ils reprennent donc la structure générale d’un message PEC, avec un fichier « message.xml » contenant les informations de l’avis et les informations nécessaires à son traitement et son acheminement.

La convention de nommage des fichiers zip d’avis générés par PEC est la suivante :

•<Localisation_PEC>_<MessageId>_<code_statut>.<Id>.zip

o<Localisation_PEC> = <SIRET PEC>-<Service PEC>-<Guichet PEC>

o<MessageId> : le MessageId du message initial préfixé par « message-id-»

o<code statut> : sur 3 caractères, au format suivant :

�AVD : Avis de dépôt

�AVL : Avis de livraison

�AND : Avis de non dépôt

�ANL : Avis de non livraison

o<Id> : identifiant unique de l’échange courant (préfixé par « pec-id- »)

A noter, cette convention de nommage est donnée à titre indicatif et ne doit pas être utilisée par les partenaires pour baser leur traitement. Elle est susceptible d’évoluer.

Les éléments nécessaires à l’identification des messages sont stockés dans le fichier message.xml

3.4Les connecteurs de la PEC Asynchrone

Le schéma suivant décrit le positionnement de PEC dans son environnement ainsi que les types de protocoles d’échanges possibles avec les partenaires.


Schema


3.4.1Connecteurs Presto

PRESTO (PRotocole d'Echange STandard et Ouvert) est un protocole d'échange de messages électroniques entre applications pour servir les besoins des administrations. Ce protocole est basé sur des technologies web services normalisées afin de favoriser l'interopérabilité.

Il existe deux normes Presto que supporte PEC :

•Presto2.0 : la version 2.0 de Presto impose l'utilisation des normes suivantes dans des versions bien précises SOAP (1.2), WSDL(1.1), WS-A(1.0), XOP/MTOM(1.0), WS-RM(1.1). De plus, le connecteur de la PEC met en place des règles fonctionnelles au travers 2 des 4 briques fonctionnelles de la norme PRESTO 2.0 :

oCore : socle de base des protocoles (essentiellement défini par la spécification d'un ensemble de standards Web Services).

oPièces jointes : mécanisme de traitement des pièces jointes aux messages Presto.

•Presto2.0.1 : la version 2.0.1 de Presto est très similaire à la version 2.0, à ceci près qu'elle apporte des précisions notables au niveau de la gestion de corrélations des messages ainsi qu'au traitement des entêtes de messages Presto, et ce, au travers de règles métier supplémentaires

oCore : socle de base des protocoles (essentiellement défini par la spécification d'un ensemble de standards Web Services).

oPièces jointes : mécanisme de traitement des pièces jointes aux messages Presto.

oAcquittement : mécanisme d'acquittement fonctionnel de messages Presto.



oRoutage & Corrélation : mécanisme de routages des messages Presto entre partenaires*

•Préconisations de raccordement :

oPour des raisons d’interopérabilité multi plate-forme, il est préconisé d’utiliser la norme Presto V2.0.1

oIl est possible d’utiliser le protocole PRESTO pour s’affranchir du message PEC. Autrement dit, la PEC utilise deux modes de PRESTO :

�PRESTO PEC où les fichiers échangés respectent la norme « Message PEC » décrit dans ce document

�PRESTO Complet où les fichiers échangés sont des pièces jointes sans utilisation du fichier « message.xml » donc sans respect du « Message PEC ». Dans ce cas, la PEC reconstituera le « Message PEC » à partir des informations contenues dans le Header du protocole PRESTO. L’inconvénient de ce mode est qu’il ne permet pas d’utiliser toutes les fonctionnalités de la PEC (Avis, confiance, etc.)

oQuelle que soit la version choisie, la PEC utilise la méthode « SendMessage » de la norme pour envoyer et recevoir des messages PEC.

oPRESTO repose sur le protocole « http » qu’il est possible de sécuriser en « https » suivant les normes SSL.



3.4.1.1Presto 2.0 / 2.0.1 : Partenaire Expéditeur �� PEC

Acteur Prérequis

Partenaire Expéditeur

Mettre en place un client PRESTOCommunication des règles de découpage : seuil et taille des messages•Afin d’assurer des performances optimales, il est d’autre part conseillé de découper les messages volumineux en segments de 128 à 512 ko.Sélectionner le mode d’envoi des messages (PRESTO PEC ou PRESTO Complet) :Pour le mode PRESTO Complet les informations à fournir dans les entêtes des messages Presto sont décrites dans la section ci-dessous Informations à fournir pour le mode Presto CompletSélectionner du niveau de sécurité :

•http•https SSL 1 Way•https SSL 2 Way :oFournir le certificat public client aux équipes de la PEC en cas

d’authentification SSL 2 WayoFournir le certificat de l’autorité de certification qui a généré le certificat

ainsi que les certificats intermédiaire de la chaîne de certificationFournir les informations réseaux du client : adresse IPAutoriser au niveau réseau l’émission des messages vers IP/port PEC le cas échéant

PEC Communication des informations de connexion :•Url du serveur Presto PEC•Informations réseaux : adresse IP, numéro de Port•Suivant le niveau de sécurité choisi :ohttp : aucune information supplémentaire n’est nécessaireohttps SSL 1 Way et 2 Way :�fourniture du certificat public serveur PEC�Fournir le certificat de l’autorité de certification qui a généré ce certificat

ainsi que les certificats intermédiaire de la chaîne de certificationAutoriser au niveau réseau la réception des messages vers IP de l’expéditeur

Conditions de fonctionnement

Ouverture de la route entre le connecteur Client Presto du partenaire expéditeur et le connecteur Serveur Presto de la PEC

3.4.1.2 Informations à fournir pour le mode Presto CompletPresto 2.0 : Pas de mode Presto Complet avec Presto 2.0Presto 2.0.1 : Voici un tableau récapitulatif des informations nécessaires à fournir dans les champs

des messages SOAP Presto 2.0.1 pour le bon fonctionnement du mode Presto Complet

Informations à fournir dans les entêtes des messages Presto(En jaune les informations obligatoires)

Description

/SOAPEnvelope/SOAPHeader/presto:PRESTOHeader/presto:References/messageId Identifiant du message

/SOAPEnvelope/SOAPHeader/presto:PRESTOHeader/presto:References/presto:refToMessageId Identifiant de corrélation avec un autre message



/SOAPEnvelope/SOAPHeader/presto:PRESTOHeader/ presto:References/presto:conversationId Identifiant de conversation

/SOAPEnvelope/SOAPHeader/presto:PRESTOHeader/presto:References/presto:processId Identifiant de processsus

/SOAPEnvelope/SOAPHeader/presto:PRESTOHeader/presto:Routing/presto:replyTo (obligatoirement de type Location_FR)

Adresse de l’émetteur

/SOAPEnvelope/SOAPHeader/presto:PRESTOHeader/presto:Routing/presto:to (obligatoirement de type Location_FR)

Adresse du destinataire

/SOAPEnvelope/SOAPBody/message Contenu du message

3.4.1.3Presto 2.0 / 2.0.1 : PEC �� Partenaire Destinataire

Acteur Prérequis

Partenaire Destinataire

Mise en place d’un serveur PRESTOCommunication des informations de connexion :

•Informations réseaux : adresse IP, numéro de port•URL du serveur PRESTO•Sélection du niveau de sécurité :ohttpohttps SSL 1 Way ou SSL 2 Way�Fournir le certificat public serveur�Fournir le certificat de l’autorité de certification qui a généré ce certificat

ainsi que les certificats intermédiaire de la chaîne de certification

Autoriser le cas échéant le niveau réseau la réception des messages issus de l’IP de la PEC

PEC Communication des informations réseaux : adresse IPCommunication des règles de découpage : seuil et taille des messagesSuivant le niveau de sécurité :

•http ou https SSL 1 Way : rien de plus à fournir•https SSL 2 WayoFourniture du certificat public clientoFournir le certificat de l’autorité de certification qui a généré le certificat

client de la PEC ainsi que les certificats intermédiaire de la chaîne de certification

Autoriser au niveau réseau l’émission des messages vers IP du destinataireConditions de fonctionnement

Ouverture de la route entre le Client Presto PEC et le Serveur Presto du Partenaire Destinataire



3.4.2(S)FTP(S)

Les interfaces FTP, SFTP et FTPS nécessitent les mêmes informations et ont le même degré de complexité pour leur mise en place.

Le protocole FTPS correspond au protocole FTP avec une couche de sécurité SSL tandis que le protocole SFTP correspond au protocole FTP au travers une connexion sécurisée SSH.

3.4.2.1 (S)FTP(S) : Partenaire Expéditeur �� PEC

Chaque partenaire désirant initier un message générique via (S)FTP(S) se voit attribuer un compte (S)FTP(S) sur la PEC qui lui est propre. Ce compte (S)FTP(S) offre au partenaire un répertoire de dépôt dédié et sécurisé :

•Les fichiers déposés doivent être des « Messages PEC »

•Aucune sous-arborescence n’est permise dans ce répertoire. Chaque fichier déposé doit l’être à la racine du répertoire de dépôt.

•Tout fichier pris en charge par la plate-forme PEC est retiré de l’arborescence du partenaire lors du traitement par PEC.

Acteur Prérequis

Partenaire Expéditeur

Choix du protocole souhaité : FTP, SFTP ou FTPSMise en place d’un client (S)FTP(S) correspondantCommunication des informations réseaux : adresse IPDemande d’un compte utilisateurPour SFTP, choix du mécanisme d'authentification pour le compte demandé:•par nom d'utilisateur et mot de passe •par clé : fournir la clé publique client aux équipes de la PECPour FTPS•aucuns pré-requis spécifiques

PEC Communication des informations du compte (S)FTP(S)•Adresse IP, numéro de portPour SFTP•Nom d’utilisateur et mot de passe (pas de mot de passe dans le cas d'une authentification par clé)Pour FTPS•Nom d’utilisateur et mot de passe du compte demandé•le certificat PEC


Ouverture de la route entre le Client FTP(S) du Partenaire Expéditeur et le serveur (S)FTP(S) PEC



Acteur Prérequis

Certificats et clé échangée correcte lors de la connexion client�serveur

3.4.2.2(S)FTP(S) : PEC �� Partenaire Destinataire

PEC met à disposition du Partenaire destinataire le fichier sur le serveur FTP(S) du partenaire.

Il est possible de définir le comportement de PEC lors de la copie en choisissant:

•Soit PEC doit écraser les fichiers déjà existant ayant le même nom

•Soit PEC doit refuser le dépôt pour les fichiers ayant le même nom. Dans ce cas PEC positionnera le message en erreur dès qu’un des fichiers existe. Attention, PEC ne remet pas le contenu du répertoire dans l’état précédent le dépôt.

Acteur Prérequis

Partenaire Destinataire

Choix du protocole souhaité : FTP, SFTP ou FTPSMise en place d’un serveur (S)FTP(S)Communication de la logique de livraison••••Écrasement ou non des fichiers déjà présentsCommunication des informations du compte•Adresse IP, numéro de port•Nom d’utilisateur et mot de passe (pas de mot de passe dans le cas d'une authentification par clé)•Répertoire de dépôt

Pour SFTP, choix du mécanisme d'authentification souhaité :•par nom d'utilisateur et mot de passe•par clé•Pour FTPS•Certificat serveur



Acteur Prérequis

PEC Communication des informations réseaux : adresse IPDemande de comptePour SFTP•avec une authentification par clé publique : communication de la clé publique utilisée par la PECPour FTPS•aucuns de pré-requis spécifiques.


Ouverture de la route entre le Client (S)FTP(S) de PEC et le serveur (S)FTP(S) du Partenaire Destinataire. Certificats et clé échangée correcte lors de la connexion client�serveur

3.4.3SMTP

Le protocole SMTP correspond à l’échange de courriel. La PEC ne peut recevoir de courriel, par contre elle peut en émettre vers un destinataire.

La taille des messages échangés via ce protocole est limitée à 5 Mo.

3.4.3.1SMTP : PEC �� Partenaire Destinataire

Le protocole SMTP ne garantissant pas la livraison du message (juste la prise en compte de la demande d’acheminement / transport), un problème d’acheminement (NPAI, …) ne pourra donc être identifié qu’au niveau du destinataire (message non reçu).

PEC considère que le message est livré dès lors qu’il l’a correctement transmis à son relai SMTP internet ou SIGMA Si l’adresse spécifiée dans l’annuaire de routage est incorrecte, l’erreur ne sera pas connue au niveau de la plate-forme PEC.

Sauf configuration spécifique des champs SMTP par l’émetteur, les champs auront le format suivant :

••••Contenu du mail :

oEmetteur : «PEC »

oRéponse à : N/A

oObjet : « [PEC] La PEC vous a transmis un message (identifiant « MessageId ») »

oCorps :



« Bonjour,Vous trouverez ci-joint le message qui vous a été a dressé.Référence : « MessageId »La PEC.»

••••Pièces-jointes: Le message PEC

Acteur Prérequis

Partenaire destinataire

Communiquer une adresse électroniqueMettre en place un outil de réception des courriels : webmail ou client SMTP

PEC N/A


Adresse électronique du partenaire valide



4PEC Synchrone

4.1Fonctionnalités de PEC Synchrone

Les principales fonctionnalités de PEC Asynchrone sont les suivantes :

•Acheminement des messages, avec garantie de la non-perte

•Supervision des messages de la plate-forme

•Mécanismes de routage de message : utilisation d’un annuaire des Autorités Administratives acteurs de la PEC permettant de centraliser les autorités, d’abstraire ces autorités de la gestion des couches par l’utilisation d’adresse logique des partenaires

•Appel web service inter zone (SIGMA vers SIGMA ou Internet vers Internet) mais aussi de SIGMA vers Internet. Les appels d’Internet vers SIGMA sont interdits.

•Médiation de protocole : un seul web service en entrée permet d’atteindre tous les web services des partenaires. Par ailleurs, permet aussi l’abstraction des exigences d’authentification imposées par le destinataire pour l’émetteur.

4.1.1Protocoles de communication supportés

En entrée de la PEC :

•Web Service

ohttp

ohttps SSL 1 Way

En sortie de la PEC :

•Web Service

ohttp

ohttp avec Login/Password (basic authentication)

ohttps SSL 1 Way

ohttps SSL 2 Way



4.2Cinématiques d’échange PEC Synchrone

4.2.1Cas nominal

Cette cinématique décrit le cas nominal (sans erreur) d’échange entre un expéditeur et un destinataire, c'est-à-dire lorsqu’un partenaire expéditeur souhaite utiliser un service d’un partenaire destinataire au travers de la PEC. Cette dernière affranchit l’expéditeur des notions de sécurité et connectivité au service distant.

Aucun avis n’est géré dans ce type d’échange puisque l’expéditeur est tenu en temps réel du bon fonctionnement de sa demande.

4.2.2Cas d’erreur

Cette cinématique décrit le cas où une erreur est détectée lors de l’utilisation du service distant.



Quelle que soit la cause de l’erreur détectée pendant l’appel, remontée par le service distant, ou par le protocole lorsque le service distant ne répond pas, le service PEC remonte une erreur au partenaire expéditeur.

Il n’y a pas de mécanisme de rejeu géré par PEC Synchrone.

4.3Structure des échanges PEC Synchrone

PEC Synchrone utilise un connecteur de type Web Service et donc une interface de communication basée sur un WSDL.

4.3.1Contrat d’interface du connecteur

Le message d’entrée du connecteur Web Service PEC Synchrone est caractérisé par un appel Web service (SOAP sur HTTP ou HTTPS) provenant d’un partenaire expéditeur de PEC.

Le contrat d’interface du proxy Web service repose sur le WSDL suivant :

Ce WSDL fait référence au Schéma XML suivant :


Web Services Description Language

W3C XML Schema


Voici un exemple de réponse renvoyée par le web service proxy :<?xml version='1.0' encoding='UTF-8'?><S:Envelope xmlns:S="http://schemas.xmlsoap.org/soa p/envelope/">

<S:Body><ns2:invokeResponse xmlns:ns2="http://proxyws.pec.d gme.gouv.fr/">

<return xmlns:typ="http://interfacews.tdd.sngi.cnav .fr/types/" xmlns:soapenv="http://schemas.xmlsoap.org/soap/enve lope/" xmlns:int="http://interfacews.tdd.sngi.cnav.fr/">

<soapenv:Header/><soapenv:Body>

<typ:IdentificationSNGITDDResponseElement><typ:result>

<int:codeRes>1</int:codeRes><int:libelleRes>message</int:libelleRes>

</typ:result></typ:IdentificationSNGITDDResponseElement>

</soapenv:Body></return>

</ns2:invokeResponse></S:Body>

</S:Envelope>

4.3.2Méthodes à utiliser

Le web service proposé par la PEC synchrone repose sur les opérations « invoke » et « invokeTemplateWS ».

4.3.2.1Méhtode « invoke »

L’opération « invoke » permet d’appeler un service distant et passant à la plate-forme PEC l’enveloppe SOAP nécessaire à l’appel du web service du partenaire destinataire. La PEC peut alors être vu comme un relais de web service.

Cette méthode repose sur les paramètres suivants :

•la description logique de l’acteur émetteur au format XML : Pays, SIRET, Service, Guichet.

•la description logique de l’acteur destinataire au format XML : Pays, SIRET, Service, Guichet.

oL’adresse technique et le type du web service sont définis dans le protocole de ce destinataire

•le Body SOAP du message à envoyer

Ce mode de fonctionnement implique que l’appelant connaisse la structure SOAP exacte qu’attend le web service du destinataire à contacter, car il doit fournir le body soap correct du message à envoyer. La plate-forme PEC ne réalisera aucune vérification sur cette enveloppe SOAP.

Exemple d’appel :



4.3.2.2Méthode « invokeTemplateWS »

Pour plus de souplesse pour le client de PEC, un système de modèle d’enveloppe SOAP permet également d’effectuer un appel web service via l’opération « invokeTemplateWS ». Dans ce cas, la plate-forme PEC réalise une correspondance entre les données qui lui sont passées et le modèle SOAP qu’elle possède.

Les paramètres de cette méthode sont :

•la description logique de l’acteur émetteur au format XML : Pays, SIRET, Service, Guichet

•la description logique de l’acteur destinataire au format XML : Pays, SIRET, Service, Guichet.

•Un tableau de chaîne pour lequel chaque valeur est substituée dans le modèle SOAP du web service à appeler.

Dans ce mode de fonctionnement, l’appelant n’a besoin que de connaître la liste des paramètres nécessaires pour appeler le web service du partenaire distant.

Exemple d’appel :

4.3.3Format des descriptions logiques de l’émetteur et du destinataire

La description logique XML d’un émetteur est la suivante :


Document XML

Document XML


De la même façon, la description logique XML d’un destinataire est la suivante :

Les vérifications suivantes seront effectuées par la PEC :

•La seule valeur supportée aujourd’hui par l’élément « Country » est FR

•L’attribut Siret est obligatoire

•Les 2 attributs Service et Guichet sont facultatifs

oSi l’attribut Guichet est spécifié alors l’attribut Service doit être présent

4.4Le connecteur de la PEC synchrone

Pour faire appel à la PEC synchrone, il n’y a qu’un seul connecteur possible. Il s’agit d’un web service.



Acteur Pré-requis

Partenaire appelant

Mettre en place un client web service respectant le WSDL fourni par la PECChoisir le niveau de sécurité voulu

•http•https SSL 1 way

Communication des informations réseau : adresse IP

PEC Communication des informations de connexion : adresse IP, numéro de portCommunication de l’URL du web serviceSi niveau de sécurité https SSL 1 way

•fourniture du certificat serveur de la PEC•fourniture du certificat de l’autorité de certification qui a généré le certificat

de la PEC ainsi que des certificats intermédiaires de la chaine de certificationConditions de fonctionnement

Ouverture des routes :•Entre le Client WebService du Partenaire Expéditeur et le serveur Webservice de PEC•Entre le Client WebService de PEC et le serveur du WeService du Partenaire Destinataire



5Convention de service

5.1Niveaux de service

Les engagements qui suivent concernent les niveaux de service applicables à l’exploitation du service rendu par la plate-forme d'échange de production du SGMAP.

5.1.1Heures d’ouverture des services

La plage d’ouverture de la PEC aux partenaires est : 24h/24 et 7j/7.

5.1.2Arrêts réguliers de la production

Un arrêt régulier est une indisponibilité du service en ligne qui se renouvelle avec une fréquence déterminée à l’avance (quotidien, hebdomadaire, mensuelle).

Les arrêts réguliers peuvent être prévus par exemple pour des opérations de gestion de données en back office, des opérations régulières de mise en production…

Les indisponibilités dues aux arrêts réguliers des services sont les suivantes :

Nom du service Heures d’arrêt Fréquence/jour

PEC Variable Tous les 3 mois environ (montées de version PEC)

Remarque : les arrêts réguliers sont normalement en dehors des plages horaires de travail (9h à 19h et en dehors des jours ouvrables).

5.1.3Niveau de service de la PEC

Le SGMAP surveille le service PEC pour détecter au plus tôt les baisses du niveau de qualité et l’augmentation anormale de la charge.

L’objectif de qualité de service de la PEC est le suivant :

Service Niveau de service

Taux de disponibilité 99,8% de disponibilité annuelle, hors indisponibilités planifiéesContinuité de Service Un maximum mensuel de quatre coupures de service d’une durée

supérieure à une heure durant la plage de disponibilité, hors indisponibilités planifiées

Délais de rétablissement Garantie de temps de rétablissement de l’infrastructure



Service Niveau de service

d’hébergement : 6 heuresRestaurationdes sauvegardes

J -1 après incidents

5.1.4 Les délais de prévenance pour les arrêts plani fiés

Un arrêt planifié est un arrêt de tout système rendant le service PEC indisponible totalement ou partiellement et prévu dans un planning prévisionnel.

Le SGMAP s’engage à informer ses partenaires au moins 72 heures à l’avance du planning prévisionnel des arrêts planifiés sur les environnements raccordés à la PEC (environnement de production et de pré-production).

L’information est systématiquement transmise par messagerie au responsable fonctionnel de l’application du partenaire. Les correspondants destinataires de l’information doivent accuser réception à l’émetteur de la prise en compte du message.

5.2 Gestion des incidents

5.2.1Incidents

En cas de dysfonctionnement, le SGMAP s’engage à mettre tous les moyens dont il dispose pour rétablir une situation normale dans les meilleurs délais.

Tous les incidents sur les services de la PEC sont tracés. A chaque incident ouvert est associé un niveau de priorité défini en fonction des critères suivants :

➔L’impact de l’incident sur le service aux partenaires,

➔L’urgence qui reflète l’évaluation de la rapidité avec laquelle un incident doit être résolu, en solution définitive ou de contournement.

5.2.2Communication entre les parties suite à incide nt

Le SGMAP met à disposition de ses partenaires un outil « Mantis » afin de leur permettre de remonter des incidents survenus. Mantis est accessible depuis l'adresse :

https://mantis.heai-dgme.fr/



Un compte partenaire est créé lors de chaque raccordement. Les tickets Mantis permettent de suivre l'état d'avancement des interventions du SGMAP de de conserver un historique des problèmes.

En cas d'extrème urgence, il existe une adresse électronique et un numéro de téléphone du service « gestion applicative PEC » :

• De 9h 00 à 18h00 sauf week-ends et jours fériés

[email protected]

01 53 18 14 11

La communication des incidents rencontrés par le SGMAP concernant l’utilisation du site du partenaire se fait uniquement par des personnes préalablement identifiées par le SGMAP.

5.2.3Les traces enregistrées par la PEC

Les traces sont de deux ordres :

•Les traces techniques, générées par les serveurs Web, d’applications, de bases de données… Ces traces peuvent permettre de retrouver ce qui a été fait sur un compte donné ou de détecter un dysfonctionnement de l’application. Ces traces sont stockées sous forme de fichier sur les serveurs

•Les traces applicatives : Ces traces contiennent les erreurs fonctionnelles (i.e. identifiées dans les spécifications) et les activités particulières (traitement des batchs par ex.). Elles sont remontées dans la console de supervision.

5.2.4Communication et conservation des traces

Aucune trace technique de la PEC ne sera fournie à un partenaire.

En cas d’incident, le SGMAP apporte, à la demande du partenaire, une assistance technique pour l’interprétation des erreurs rencontrées par le partenaire.

Le SGMAP conserve les traces d’activité 3 mois pour les traces techniques et 5 ans pour les traces applicatives.

Fin de document


Documents

Plateforme d'Echange et de Confiancetelechargement.modernisation.gouv.fr/.../SGMAP_contratservice_PEC.pdf · Plateforme d'Echange et de Confiance Contrat de Service •Avis de dépôt