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

Enrichment Pipeline

La chaîne ordonnée d'enrichissements qui transforme un message parser brut en payload exploitable par le métier — chaque étape consulte un référentiel, ajoute un champ.

Problème

Un INVOIC EDIFACT contient des codes : GLN du fournisseur (3010234567890), GTIN du produit (0023456789012), BIC bancaire (BNPAFRPP). Pour l'ERP, ces codes sont opaques : il a besoin du nom du fournisseur, de l'adresse de facturation, du libellé produit, de la TVA applicable, de l'IBAN à créditer, du code pays, de la classification douanière HS. Si chaque consumer en aval (ERP, archive, lake) fait ses propres lookups, on duplique 5 fois les requêtes aux référentiels, on n'a pas une vue cohérente, et on couple chaque consumer aux schémas des référentiels.

Forces

  • Les messages EDI sont volontairement codés. Optimisation taille historique, normalisation des identifiants.
  • Les consumers ont besoin du décodé. L'utilisateur final ne lit pas 3010234567890, il veut « Carrefour France SAS ».
  • Les référentiels sont la source de vérité. PIM, MDM, registre légal — un seul lookup centralisé.
  • Les étapes ont des dépendances. Le calcul de TVA dépend du pays du fournisseur résolu en étape 1.
  • Les référentiels peuvent être lents ou indisponibles. Le pipeline doit gérer le degraded mode.

Solution

Composer un pipeline d'Content Enricher en étages ordonnés. Chaque étage prend en input le message + les enrichissements précédents, fait son lookup, ajoute son champ, passe au suivant. L'ordre suit les dépendances. Chaque étage est testable indépendamment. La résilience est par étage : si le PIM est down, on peut continuer avec un champ productLabel: null et flagger le message. Le pipeline est versionné et observabilité par étape (latence, taux d'échec, cache hit rate). Implémentations : Apache Camel routes, Kafka Streams topology, AWS Step Functions, Temporal workflows. 

INVOIC EDIFACT (brut, codes GLN seuls)
        │
        ▼
  ┌──────────────────────────┐
  │ 1. Enrich Partner GLN    │ ─── lookup GLN → Partner master
  │    + supplier name/addr  │
  └─────────┬────────────────┘
            ▼
  ┌──────────────────────────┐
  │ 2. Enrich Product GTIN   │ ─── lookup PIM
  │    + label, weight, HS   │
  └─────────┬────────────────┘
            ▼
  ┌──────────────────────────┐
  │ 3. Enrich Tax rates      │ ─── lookup pays / produit
  │    + VAT rate, code      │
  └─────────┬────────────────┘
            ▼
  ┌──────────────────────────┐
  │ 4. Enrich BIC bank info  │ ─── lookup BIC → IBAN validation
  └─────────┬────────────────┘
            ▼
  INVOIC enrichi → broker → ERP

Implémentation EDI

Cas concret : hub EDI hospitalier reçoit un message ORM-O01 HL7 v2.5 avec MRN et codes LOINC. Le pipeline d'enrichissement : (1) MRN → identité patient depuis MPI (Master Patient Index) ; (2) code LOINC → libellé examen depuis FHIR Terminology Server ; (3) code ICD-10 du diagnostic → libellé clinique ; (4) prescripteur NPI → coordonnées et spécialité ; (5) pharmacie destinataire → adresse, formats supportés. Le message résultant est exploitable par le HIS sans nouvelle lookup. Côté retail : ORDERS EDIFACT avec GTIN seul, enrichi par PIM (GS1 GDSN) pour récupérer libellé, poids, packaging, HS code, normes douanières. Camel route : from("kafka:edi.in").to("bean:partnerEnricher").to("bean:productEnricher").to("bean:taxEnricher").to("kafka:edi.enriched"); Chaque étape utilise un cache local (Caffeine) + cluster (Redis) pour éviter les requêtes répétitives au référentiel maître.

Anti-patterns

  • Enrichissement en aval, chez chaque consumer. Duplication des lookups, divergence des résultats si le référentiel change entre deux consumers.
  • Étape bloquante synchrone sans timeout. Si le PIM mais 30s, le pipeline complet bloque.
  • Sans cache. Le même GLN consulté 1 000 fois par seconde : requêtes inutiles, latence élevée.
  • Sans gestion des trous. Si le GLN du fournisseur n'est pas dans le référentiel, on plante au lieu de flagger et router vers Dead Letter.
  • Enrichment qui contient du métier. « Si pays = FR, taxer à 20% » dans l'enricher : c'est de la business logic à mettre dans un service dédié.
  • Pipeline gigantesque. 20 étapes : latence et complexité. Regrouper les étapes logiquement liées.

Patterns liés

Sources