ediverse

Tapez pour rechercher dans les standards, messages, outils et glossaire.

ediverse Explorer la plateforme

À la une PEPPOL BIS Billing 3.0 L’obligation européenne d’e-invoicing arrive : France sept 2026, Belgique janv 2026, Allemagne 2025.

— 01

Fondamentaux

— 02

Standards

— 03

Messages phares

— 04

Outils

Guaranteed Delivery

L'assurance qu'aucun message ne se perd même si un broker crash.

Problème

Un broker en mémoire perd ses messages au reboot. En EDI, perdre un INVOIC = perdre une trace fiscale = audit échec. Comment garantir la durabilité ?

Forces

  • Performance vs durabilité — fsync à chaque write coûte cher.
  • Réplication vs disponibilité — un broker répliqué tient le crash mais ajoute de la latence.
  • EDI contient des messages à valeur juridique — INVOIC fiscaux 10 ans, MDN signés non-répudiables.
  • Le producteur veut un ACK rapide — sinon il retransmet (et la déduplication doit gérer).

Solution

Configurer le broker (Kafka, RabbitMQ, IBM MQ) en mode persistant avec réplication ≥ 3, fsync sync ou async selon SLA, et acks=all côté producteur. Le broker n'acquitte le message que quand au moins N replicas l'ont écrit sur disque. La perte d'un broker (jusqu'à N-1) n'entraîne aucune perte de message.

Implémentation EDI

En EDI, configuration Kafka recommandée : min.insync.replicas=2, replication.factor=3, acks=all, producer retries=infinite. Sur Apache MQ : persistent=true, transactional=true. Pour AS2/AS4 : confirmation MDN signé après écriture en base = guaranteed delivery applicatif. Coût typique : +20-30 ms de latence vs in-memory.

Anti-patterns

  • acks=1 sur Kafka — perte possible si le leader crash avant réplication.
  • min.insync.replicas=1 — équivalent de pas de réplication.
  • Persister le message en base mais pas dans le broker — incohérence si l'app crash entre les deux.

Patterns liés

Sources