Passer au contenu
Français
Portail client
Contact
  • Il n'y a aucune suggestion car le champ de recherche est vide.

7. SCHÉMA GÉNÉRAL DE L’INTERACTION ENTRE LE SERVICE EN LIGNE DELTA-IE ET LES SYSTÈMES OPÉRATEURS

Emplacement : Documentation SDS > DGDDI DeltaIE - CSO document principal v11 20251212 > PRESENTATION

Figure 33 : Schéma général d’interaction entre le service en ligne Delta -IE et les systèmes opérateurs

‌

8. CARACTÉRISTIQUES COMMUNES À TOUS LES ÉCHANGES

‌

Principe et canal d’échange

Les éléments relatifs aux échanges dans le cadre des opérations de sortie sont à compléter dans une version ultérieure.

‌

L’intégralité des échanges (sens système opérateur EDI vers Delta-IE et inversement) s’effectue par l’échange de webservices en REST via le canal internet.

La publication des messages pour Delta-IE consiste à appeler les webservices exposés (après une phase d’authentification (Cf. 8.7 Sécurité) et à recevoir le retour de la bonne prise en compte du message (code HTTP 200) ou de l’erreur éventuelle (code HTTP 40x ou 50x) (Cf. 8.5 Gestion des erreurs). Le retour de la bonne prise en compte du message confirme que le message sera bien pris en charge en asynchrone par Delta-IE48.

Les webservices à appeler sont exposés sur l’URL https://api.douane.gouv.fr/delta-ie/ .

Pour les tests les webservices à appeler sont exposés sur l’URL https://api-form.douane.gouv.fr/delta-ie/ .

Pour les échanges inverses, des webservices doivent aussi être exposés par les systèmes opérateurs EDI. La Douane est en charge d’appeler ces webservices exposés. Les principes de gestion des codes retours indiqués ci-dessus sont identiques. Une URL dédiée est donc à exposer commençant par : https:// /

Se référer aux chapitres suivants de définition des échanges pour obtenir l’URL complète notamment les informations sur (cf. partie « Endpoints des webservices » exposés pour chacun des échanges)

La solution de configuration initiale et de mise à jour de l’URL des opérateurs EDI est définie dans le document [2].

Format d’échange

Les messages échangés entre les opérateurs et Delta-IE (et inversement) s’effectuent exclusivement via des appels de webservices HTTP avec le verbe POST. Ces messages échangés sont au format JSON.

Le format des messages (contrat de service) est défini à l’aide du dictionnaire des messages sous forme de tableur (accompagné d’un onglet « Mode d’emploi » permettant de comprendre la lecture).

Niveau de service

‌

  • Période de fonctionnement de l'échange
  • Nombre maximal d'échanges entrants
  • Temps de traitement pour un échange (temps entre un message entrant et un message sortant)
  • Délai de prévenance d'une indisponibilité programmée
  • Pertes de Données Maximale Autorisée (PDMA)

48Attention, le code http 200 garantit la prise en charge du message mais pas son traitement. Seule la réponse positive ou négative de Delta-IE garantit le traitement effectif.

‌

Conditions d’utilisation

Le déclarant doit utiliser une solution EDI certifiée par Delta-IE et être titulaire d’un agrément l’autorisant à déposer des déclarations dans le service en ligne Delta-IE.

‌

Gestion des erreurs

Deux grands types d’erreurs sont possibles :

  • Les erreurs retournées dans la réponse suite à une requête de publication des messages avec réception du retour invalide (code HTTP 40x ou 50x) en synchrone (cf. partie 8.5.1);
  • Les erreurs générées après publication du message suite à la réception du retour de la bonne prise en compte du message (code HTTP 200) (cf. partie 8.5.2)

‌

Erreurs lors de la publication du message vers Delta-IE

‌

À la publication, la distinction des erreurs s’effectue via le code HTTP retourné et éventuellement des informations supplémentaires dans le corps de la réponse.

‌

Les erreurs possibles sont les suivantes :

‌

  • 400 — Description : Erreur fonctionnelle sur les données nécessaires à la bonne prise en compte du message par la plateforme d’échange des Douanes (GUN2) : trame incomplète par exemple. ; Traitement du cas d’erreur : L’opérateur EDI doit corriger son message.
  • 401 — Description : Erreur d’authentification (cf. document [2] Authentification API Externe_v1.2 du 20/07/2021) ; Traitement du cas d’erreur : L’opérateur doit se ré-authentifier avec les identifiants adéquats.
  • 404 — Description : URL inconnue. ; Traitement du cas d’erreur : L’opérateur EDI doit corriger son URL d’appel.
  • 500 — Description : Erreur technique survenue ne permettant pas de prendre en compte la demande. L’erreur ne dépend pas du type de message. ; Traitement du cas d’erreur : Pour ne pas saturer le serveur Douane, pas d’envoi de nouveaux messages pendant 5 minutes. Tant qu’une erreur 500 est retournée sur un message, une seule nouvelle requête doit être envoyée. Le temps entre chaque tentative ne doit pas être inférieur à 5 minutes.

‌

Erreurs suite à la publication du message vers Delta-IE

‌

Les erreurs post publication sont transmises au travers des messages IE917 et IE456 à l’importation, IE917 et IE556 pour les échanges avec le bureau d’exportation, IE917 et IE557 (et IE548) pour les échanges avec le bureau de sortie. Elles sont liées aux erreurs signalées par le service en ligne Delta-IE.

‌

Ces erreurs sont de deux types :

  • Les erreurs techniques sont celles relevées lors des contrôles de surface, qui visent à vérifier le respect de la structure du message et du format des données tels qu’ils sont décrits par chacun des messages entrants dans le document [1] Dictionary of messages.
  • Les erreurs fonctionnelles regroupent les erreurs identifiées lors des contrôles de recevabilité fonctionnelle, qui visent à vérifier le respect des listes de codes et des règles de validation décrites

‌

dans l’onglet « RULES » du document [1] Dictionary of messages.

Le service en ligne Delta-IE réalise d’abord tous les contrôles de surface pour le message entrant et transmet au déclarant l’ensemble des erreurs techniques identifiées dans la limite d’un nombre calibré paramétrable (au maximum 999). Les erreurs techniques sont transmises au travers du message IE917. En cas de détection d’erreurs techniques, Delta-IE ne réalise pas des contrôles de recevabilité fonctionnelle.

En l’absence d’erreur technique, le service en ligne Delta-IE réalise les contrôles de recevabilité fonctionnelle et transmet au déclarant l’ensemble des erreurs fonctionnelles identifiées dans la limite d’un nombre calibré paramétrable (au maximum 999). Les erreurs fonctionnelles sont transmises au travers du message IE456 à l’importation, IE556 pour les échanges avec le bureau d’exportation et IE557 pour les échanges avec le bureau de sorite.

Contenu de l’erreur :

Pour les erreurs techniques transmises via IE917 :

Pour chaque erreur technique relevée (jusqu’à 999) :

  • XMLErrorLineNumber : Numéro de ligne dans le fichier au sein de laquelle l'erreur a été relevée ;
  • XMLErrorColumnNumber : Numéro de colonne de la balise à l’origine de l’erreur au sein de la ligne précisée dans XMLErrorLineNumber (numéro de caractère / d'octet) ;
  • XMLErrorPointer (optionnel) : Le chemin complet de la balise à l’origine de l’erreur détectée (tronqué à gauche en cas de dépassement de 512 caractères) ;
  • XMLErrorCode : Code d’erreur sur 2 chiffres associé à la nature de l’erreur détectée, pouvant notamment être : non-respect de la structure du message (balise XML non refermée, ordre des balises, hiérarchie des balises, etc.), non respect du format des valeurs présentes dans les balises (types, longueurs, caractères autorisés, valeurs limites autorisées, etc.), non-respect des cardinalités (balise manquante, balises pas assez ou trop répétées), doublon ;
  • XMLErrorText : Description textuelle de la nature de l'erreur relevée (voir exemples fournis pour XMLErrorCode) ;
  • XMLlErrorOriginalAttributeValue (optionnel) : valeur originale non conforme, renseignée uniquement lorsque l'erreur relevée porte sur la valeur dans une balise du message rejeté (ex. de natures d'erreur : type, longueur, caractères autorisés, valeurs limites autorisées).

Lorsque plusieurs erreurs sont détectées sur le même élément de données ou le même groupe de données, les informations relatives aux erreurs ne sont pas fusionnées.

Pour les erreurs fonctionnelles transmises pour les échanges à l’importation via IE456 :

Au niveau général :

  • importOperationBusinessRejectionType : Objet métier visé par le message de rejet (déclaration, demande de rectification ou d’invalidation, ou notification de présentation, etc.) ;
  • importOperationRejectionCode et importOperationRejectionReason : Motif de rejet selon l’objet rejeté (par exemple pour une déclaration : invalidité de la garantie, demande de rectification ou d’invalidation, ou notification de présentation, etc.).

Puis pour chaque erreur fonctionnelle relevée (jusqu’à 999) :

  • functionalErrorPointer : Selon le code d’erreur, MRN, type de message ou chemin complet de l’élément de données ou du groupe de données à l’origine de l’erreur détectée (tronqué à gauche en cas de dépassement de 512 caractères) ;
  • functionalErrorCode : Code d’erreur précisant la nature de l’erreur détectée, pouvant être : non- respect de la liste de codes, non-respect d’une règle/d’une condition communautaire (pouvant concerner la présence ou l’absence d’une donnée, la cohérence des informations renseignées, etc.), doublon, MRN inconnu ou invalide, incohérence du message par rapport au cycle de vie de la déclaration, ou encore non-respect d’une règle/condition nationale (cf. tableau sur la page suivante) ;
  • functionalErrorReason : Motif de l’erreur, précisant soit la liste de codes non respectée, soit la règle ou la condition communautaire ou nationale non respectée ;

‌

  • functionalErrorRemarks : Remarque (optionnelle) liée à certain code d’erreur pour aider le déclarant à mieux comprendre l’erreur détectée. Une erreur nationale est systématiquement accompagnée d’une remarque ;
  • functionalErrorOriginalAttributeValue : Valeur originale non conforme (optionnelle).

Lorsque plusieurs erreurs sont détectées sur le même élément de données ou le même groupe de données, les informations relatives aux erreurs ne sont pas fusionnées.

Nota : en cas d’erreur identifiée sur les ED « bureau de déclaration », « déclarant » (et « représentant ») (par exemple : EORI du déclarant non valide), l’information initiale renseignée par l’opérateur dans le message entrant sera reprise dans la partie supérieure du message de rejet IE456 (malgré son invalidité) ; tandis que l’erreur relevée sera indiquée dans la partie inférieure du message de rejet IE456 relative à « Erreurs fonctionnelles ».

Pour les erreurs fonctionnelles transmises pour les échanges avec le bureau d’exportation via IE556 (rejet générique du bureau d’export), pour les erreurs fonctionnelles transmises pour les échanges avec le bureau de sortie via IE557 (rejet générique du bureau de sortie) ou pour les erreurs fonctionnelles transmises en cas de rejet de notification de sortie de stockage IE548 :

Au niveau général :

IE556 (rejet générique du bureau d’export) et IE557 (rejet générique du bureau de sortie)

  • exportOperationBusinessRejectionType : Objet métier visé par le message de rejet ;
  • exportOperationRejectionCode et exportOperationRejectionReason : Motif de rejet selon l’objet rejeté (cf. tableau sur la page suivante)

IE548 (Rejet de la notification de sortie de stockage)

  • exportOperationManifestRejectionReason : Motif de rejet de la notification de sortie de stockage (précision en lien avec le décompte des marchandises stockées)

Puis pour chaque erreur fonctionnelle relevée (jusqu’à 999 (à confirmer)) :

  • functionalErrorPointer : Selon le code d’erreur, MRN de l’opération d’exportation, numéro de référence de la notification de sortie de stockage de l’opération d’exportation, type de message ou chemin complet de l’élément de données ou du groupe de données à l’origine de l’erreur détectée (tronqué à gauche en cas de dépassement de 512 caractères) ;
  • functionalErrorCode : Code d’erreur précisant la nature de l’erreur détectée, pouvant être : non- respect de la liste de codes, non-respect d’une règle/d’une condition communautaire (pouvant concerner la présence ou l’absence d’une donnée, la cohérence des informations renseignées, etc.), doublon, MRN inconnu ou invalide, incohérence du message par rapport au cycle de vie de la déclaration, ou encore non-respect d’une règle/condition nationale (cf. tableau sur la page suivante) ;
  • functionalErrorReason : Motif de l’erreur, précisant soit la liste de codes non respectée, soit la règle, la condition communautaire ou nationale non respectée, ou la contrainte transitoire ;
  • functionalErrorOriginalAttributeValue : Valeur originale non conforme (optionnelle).

Lorsque plusieurs erreurs sont détectées sur le même élément de données ou le même groupe de données, les informations relatives aux erreurs ne sont pas fusionnées.

Les codes erreurs fonctionnelles possibles sont les suivantes :

‌

  • 12 — Description communautaire : Codelist violation ; Description associée : Renseignement d’un élément de donnée en dehors de la liste des valeurs prédéfinies au sein de la liste de codes applicables à ce champ
  • 13 — Description communautaire : Condition violation (Missing) ; Description associée : Absence d’un élément de donnée requis/obligatoire

‌

  • 15 — Rule violation : Condition violation (Not allowed) ; Renseignement non autorisé d’un élément de donnée suivant la(les) règle(s) de gestion associée(s) à ce champ : Renseignement non autorisé d’un élément de donnée suivant la(les) condition(s) de remplissage associée(s) à ce champ
  • 26 — Rule violation : Duplicate Message ID ; Renseignement non autorisé d’un élément de donnée suivant la(les) règle(s) de gestion associée(s) à ce champ : Duplication d’un échange / Réception d’un même échange de nouveau
  • 90 — Rule violation : Unknown MRN ; Renseignement non autorisé d’un élément de donnée suivant la(les) règle(s) de gestion associée(s) à ce champ : MRN de la déclaration inconnu du système
  • 92 — Rule violation : Message out of sequence ; Renseignement non autorisé d’un élément de donnée suivant la(les) règle(s) de gestion associée(s) à ce champ : Message en dehors de la séquence de l’échange
  • 93 — Rule violation : Invalid MRN ; Renseignement non autorisé d’un élément de donnée suivant la(les) règle(s) de gestion associée(s) à ce champ : Structure du MRN non conforme aux spécifications
  • 99 — Rule violation : National error ; Renseignement non autorisé d’un élément de donnée suivant la(les) règle(s) de gestion associée(s) à ce champ : Erreur nationale

‌

Erreurs sur un message vers l'opérateur EDI

‌

Pour un message vers l'opérateur EDI, la distinction des erreurs s’effectue via le code HTTP retourné et éventuellement des informations supplémentaires dans le corps de la réponse.

‌

Les erreurs possibles sont les suivantes :

‌

  • 400 — Description : Erreur fonctionnelle sur les données nécessaires à la bonne prise en compte du message par la plateforme d’échange de l'opérateur EDI : trame incomplète par exemple. ; Traitement du cas d’erreur : Pas de rejeu.
  • 401 — Description : Erreur d’authentification. ; Traitement du cas d’erreur : Rechargement du dernier jeton paramétré sur le compte API et rejeu (cas où le jeton a été mis à jour sur le compte API).
  • 404 — Description : URL inconnue. ; Traitement du cas d’erreur : Pas de rejeu. Si l’URL a été mise à jour sur le compte API, elle sera rechargée dans le cache des URL sortantes lors du prochain rechargement complet du cache (toutes les 4h à heure fixe).
  • 500 — Description : Erreur technique survenue ne permettant pas de prendre en compte la demande. L’erreur ne dépend pas du type de message. ; Traitement du cas d’erreur : Cf. §8.6.2Rejeux des appels vers le SI des opérateurs EDI

Les échanges sortants vers les opérateurs EDI font l’objet d’une supervision fonctionnelle par une équipe dédiée, avec alerte lorsqu’il y a des erreurs (une fois passés les rejeux s’il y en a).

‌

Gestion des rejeux

Pour répondre à des indisponibilités techniques temporaires pouvant avoir lieu sur le SI Douane ou celui de l'opérateur EDI, un système de rejeu est à mettre en place de part et d'autre.

‌

Rejeux des appels vers la Douane

À l’appel du webservice, lorsque l’erreur HTTP 500 est renvoyé ou lorsque l’appel tombe en timeout, le SI de l'opérateur EDI doit rejouer l'appel dans les conditions indiquées au §8.6.1 en traitement du code d'erreur 500.

‌

Rejeux des appels vers le SI des opérateurs EDI

Si une erreur HTTP 401/500 est renvoyée, ou si l'appel tombe en timeout : la plateforme d'échange de la Douane rejoue l'appel jusqu’à une vingtaine de fois sur des intervalles de temps de plus en plus importants, le dernier rejeu se faisant 12h après la première tentative. Ce mécanisme doit permettre d’absorber les indisponibilités du SI de l’opérateur.

‌

Sécurité

‌

  1. Échanges systèmes opérateurs EDI vers Douane

La sécurité des échanges des systèmes opérateurs EDI vers Douane est portée par une authentification OAuth2 avec un chiffrement de tous les échanges en https (cf. document [2]).

‌

Les principes d’authentification en OAuth2 sont les suivants. Les endpoints des services Douane exposés sur Internet sont sécurisés via l’utilisation d’un jeton d’authentification dans le header HTTP. Le jeton d’accès (Access Token) est obtenu via l’appel d’un endpoint dédié (/oauth2/token) permettant d’authentifier le système opérateur EDI auprès du serveur d’authentification de la Douane. L’authentification du compte de service repose sur le flux « Resource Owner Password Credentials Grant » de la spécification OAuth2. Le jeton d’authentification obtenu doit ensuite être utilisé pendant toute sa durée de vie pour ne pas saturer inutilement le serveur d’authentification. L’endpoint /oauth2/token n’est donc à rappeler que lorsque le jeton est expiré.

‌

Le chiffrement des échanges en https doit s’effectuer selon le protocole TLS1.x via l’utilisation de certificats (one-way). Le certificat serveur du serveur API de la Douane est utilisé pour établir la session TLS.

‌

Seuls les prestataires disposant d’un contrat d’utilisation EDI-GUN et certifiés par la Douane sont en mesure d’échanger des informations de manière électronique.

‌

Échanges Douane vers systèmes opérateurs EDI

La sécurité des échanges Douane vers systèmes opérateurs EDI est portée par l’envoi d’un jeton opérateur stocké dans le SI Douane (« token » paramétré dans le compte API) avec un chiffrement de tous les échanges en https.

‌

Les opérateurs EDI sont responsables de la mise à disposition des informations techniques pour permettre les échanges vers leur système (URL et jeton d’authentification). Les opérateurs EDI doivent respecter les principes décrits dans le chapitre §8.1 sur la définition des URL et des endpoints des webservices. En termes d’authentification, le système du déclarant doit vérifier, à chaque appel, la validité du jeton d’authentification positionné dans le header HTTP (dans le champ Authorization: Bearer).

‌

Le chiffrement des échanges en https doit s’effectuer selon le protocole TLS1.x via l’utilisation de certificats (one-way). Le certificat serveur de l’opérateur EDI est utilisé pour établir la session TLS.

Source : https://mgi-team.atlassian.net/wiki/spaces/DOCI5/pages/4994301953