Plateforme de collecte

Transcription

1 GIP-SNE : Spécification des WS de télé-dépôt Tessi Documents Services Siège social : 116 rue de Silly Boulogne Billancourt Tél (0) Fax +33 (0) SARL au capital de euros RCS NANTERRE - N de TVA intracommunautaire : FR APE : 6311 Z

2 LE FOURNISSEUR Société : Tessi Documents Services Nom : PEIFFER Prénom : Nicolas Fonction : Responsable R&D Modification : Frédérique TOURNEIXDRUTEL Cachet et signature : 2/10

3 SOMMAIRE PLATEFORME DE COLLECTE I. II. III. IV. 1. V. VI. 4 CONTEXTE PRÉSENTATION AUTHENTIFICATION DESCRIPTION DU WEB SERVICE POST /DOCUMENT GESTION DES ERREURS MODE OPÉRATOIRE D ACTIVATION D UN GUICHET /10

4 I. Contexte Dans le cadre de la mise en place d une plateforme de collecte pour le GIP-SNE, il a été demandé de pouvoir transmettre les pièces justificatives pour une demande de logement social depuis plusieurs canaux : Via un portail professionnel (pwp) Via un portail grand public (pgp) Via une application mobile Via l envoi de mails sécurisés Via appel d un WebService 4/10

5 L objet du présent document est de décrire ce dernier canal. Il s agit pour le guichet de transmettre un fichier pdf (mono ou multi-dossier) contenant les pièces constitutives du/des dossier(s) ainsi que le bordereau et la/les fiche(s). La taille maximale sur pdf sera de 10Mo. C est une application métier du guichet qui fera l appel au WS. 5/10

6 II. Présentation Afin de dialoguer entre les applications métiers et la plateforme de collecte, une API REST sera mise en place. Le format JSON sera utilisé afin de faire transiter les données entre les applications métiers et le serveur, aussi bien au niveau des requêtes que des réponses. L authentification à l API se base sur le système WSSE ainsi que sur un système de jeton. III.Authentification La sécurisation des échanges Web Services est effectuée par la mise en place d'une connexion sécurisée HTTPS La sécurisation des échanges est donc assurée par le protocole d'échange (HTTPS) et non par le Web Service (WS/Security). Fonctionnement : - Le client demande au serveur l'ouverture d'une connexion HTTPS. Le serveur lui retourne son certificat. Ce certificat serveur permet au client de valider l'identité du serveur. Le client génère une clé symétrique qu'il chiffre avec la clé publique du certificat du serveur. Le client envoie la clé symétrique chiffrée au serveur accompagnée de son certificat client. Le serveur vérifie l'identité du client. Le client et le serveur peuvent maintenant échanger des données chiffrées avec la clé symétrique échangée précédemment. 6/10

7 IV. Description du web service Le web service va permettre d effectuer : La transmission des pièces justificatives La méthode à utiliser est décrite ci-après. RESSOURCE POST /document Upload du document 1. POST /document Description : Méthode permettant de transmettre un document sur le serveur. Le fichier est transmis en même temps dans la requête Remarque : La taille maximale d un fichier est de 10 Mo Le fichier sera au format pdf et contiendra : o Pour les pdf Mono-Dossier : BdT + FR + Feuilles o Pour les pdf Multi-Dossier : BdT + FR + Feuilles + FR + Feuilles +. + FR + Feuilles Il est à noter que les bordereaux de transmission (BdT) ainsi que les fiches récapitulatives (FR) devront disposer d un QR Code. Pour plus d informations sur les QR Codes utilisés, se référer à l annexe technique «GIPSNE - Spécifications QR Code-v1.2.doc» Ressource : [POST] /document Données envoyées : 7/10

8 Nom du paramètre Type Requis Description file Dictionnaire Description du fichier file.size Entier Taille du document en octets file.hash String Hash du document (SHA-256) file.name String Nom du document file.file Base64 Contenu du document encodé en base64 Données reçues : Objet Type Description status Chaîne "success" si le requête s'est bien passée ou "error" en cas d'échec payload Structure voir ci-dessous Objet documentid Type Chaine Description Identifiant du document Ci-après un exemple de structure retournée : { "token" : "AVHEIVdU-vpAPtzGM+NAoTmBp/iOd i7j08taphgj7u2m2s...==", "status" : "success", "payload" : { "documentid" } : "6cfb8fdb-e84c-4d0b-9868-e8233fd93d22" } 8/10

9 V. Gestion des erreurs En cas d erreur, une erreur HTTP sera retournée par l api : Code Description 401 Unauthorized 403 Forbidden 405 Method Not Allowed 415 Unsupported Media Type 422 Unprocessable Entity 501 Not implemented En complément, une réponse json sera renvoyée au client. Celle-ci sera de la forme : { "code ":1234, "desc ": "Description de l'erreur" } Ci-après les différents codes d erreur possibles : Code Description 0001 Erreur interne 0002 Echec d authentification 0003 Paramètres manquants 0004 Paramètres invalides 0005 Numéro de dossier invalide 0006 Le numéro de dossier est déjà utilisé 9/10

10 VI. Mode opératoire d activation d un guichet Chaque nouveau guichet souhaitant utiliser les Web Services, devra fournir : - Le code guichet (unique) Le code territoire (unique) La clef publique permettant l authentification. Dans un premier temps, la solution sera déployée avec un guichet pilote. Cette phase pilote permettra d identifier d éventuelles problématiques sur le raccordement à la plateforme de collecte et d affiner en conséquence le mode opératoire. Le mode opératoire définitif sera rédigé à l issue du pilote. L ensemble des informations devra être fourni au plus tard 2 semaines avant la date de raccordement. 10/10