Splitter

Briser un message composite en plusieurs messages atomiques. Un INVOIC EDIFACT qui porte 100 factures devient 100 messages indépendants. Un 856 X12 multi-bons-de-livraison devient un message par bon. Le pattern qui transforme un batch en flux.

Problème

En EDI, les partenaires regroupent souvent plusieurs unités métier dans un même interchange : 100 factures dans un INVOIC, 50 lignes d'expédition dans un DESADV multi-livraisons, 20 bons de commande dans un 850 batch. Cette densification arrange l'émetteur (moins de files, moins de transmissions), mais elle complique le récepteur qui voudrait traiter chaque unité indépendamment : idempotence par facture, retry par ligne, statut par bon.

Forces

• Granularité du retraitement. Si une seule facture sur 100 est en erreur, on veut isoler celle-là et rejouer les 99 autres — pas tout rejouer.
• Parallélisation. Plusieurs consommateurs peuvent traiter les enfants en parallèle, ce qui réduit le temps total de traitement.
• Atomicité métier. Une unité de retry doit correspondre à une unité métier — pas à un batch de transport.
• Traçabilité. Les enfants doivent conserver une référence vers le parent pour que les opérateurs puissent reconstituer l'origine en cas d'incident.

Solution

Hohpe & Woolf (EIP §259, sous le nom Splitter, parfois Sequencer) prescrivent un composant qui : (a) reçoit le message composite, (b) itère sur les sous-éléments selon la grammaire du format, (c) émet un message par sous-élément en propageant les en-têtes nécessaires (sender, receiver, corrélation parent) et (d) optionnellement signale la fin de séquence par un marqueur last.

┌────────────────────┐
INVOIC (100 fact) │      Splitter      │
       ────────▶│ (boucle sur UNH    │
                  │  ou groupes LIN)   │
                  └─────────┬──────────┘
                            │
              ┌─────────────┼─────────────┐
              │             │             │
              ▼             ▼             ▼
         facture 1     facture 2     facture 100
        (UNH=INVOIC) (UNH=INVOIC)  (UNH=INVOIC)

Topologie

Trois variantes :

• Eager Splitter. Lit l'intégralité du composite en mémoire, émet chaque enfant. Simple, mais ne marche pas sur des fichiers très volumineux (un DESADV de 500 MB).
• Streaming Splitter. Parse au fil de l'eau, émet les enfants pendant la lecture. Indispensable au-delà de quelques dizaines de MB.
• Splitter + Aggregator. Couple souvent observé en production — on éclate pour parallélisme, on agrège les résultats avant de répondre à l'émetteur original.

Implémentation EDI

Deux niveaux de splitting à distinguer :

• Niveau interchange — un UNH par message enfant. L'interchange EDIFACT peut contenir plusieurs UNH (jusqu'à un UNZ). Le splitter émet un message par bloc UNH ... UNT. C'est le découpage le plus naturel et le plus fréquent.
• Niveau message — lignes LIN en EDIFACT, HL en X12. Plus rare, mais utile quand un seul message contient plusieurs unités métier différentes. Exemple classique : un INVOIC dont chaque LIN est une facture distincte (consolidation contractuelle douteuse mais observée).

UNB+UNOC:3+SENDER:14+RECEIVER:14+260514:1545+BATCH001'
UNH+1+INVOIC:D:96A:UN:EAN008'
BGM+380+INV-001+9'
...
UNT+42+1'
UNH+2+INVOIC:D:96A:UN:EAN008'
BGM+380+INV-002+9'
...
UNT+38+2'
UNH+3+INVOIC:D:96A:UN:EAN008'
BGM+380+INV-003+9'
...
UNT+45+3'
UNZ+3+BATCH001'

Le splitter sur ce batch émet trois messages : chacun composé d'un nouvel UNB (régénéré ou hérité), du segment UNH au UNT de la facture, et d'un nouvel UNZ. Le sender et le receiver UNB sont propagés tels quels. Le UNB Interchange Control Reference peut être (a) régénéré (un par enfant) ou (b) suffixé (BATCH001-001, BATCH001-002) selon la convention. L'option (b) est préférable car elle préserve la traçabilité explicite vers le parent.

Traçabilité parent / enfants

Chaque enfant doit porter une référence vers le parent dans son contexte d'intégration (pas forcément dans le payload EDIFACT, qui ne le supporte pas toujours, mais dans la métadonnée d'envoi). Trois informations indispensables :

• parent.interchange_id — l'UNB CTRL du composite original.
• parent.position — l'index de l'enfant dans le composite (1, 2, 3...).
• parent.total — la taille de la séquence (utile pour l'agrégateur en aval).

Anti-patterns

• Eager splitter sur gros fichier. Charger 500 MB en mémoire pour les éclater ensuite consomme de la heap, déclenche des GC, et finit en OOM. Toujours streamer.
• Perte du parent. Sans corrélation explicite vers le parent, on ne peut plus reconstituer la fenêtre du batch en cas d'incident. Le journal d'audit doit toujours montrer la lignée.
• Splitter sans dedup en aval. Si le splitter ré-émet le même enfant après un crash, il faut un Idempotent Receiver derrière, sinon l'enfant sera intégré deux fois.
• Position implicite par ordre d'arrivée. Si on ne stocke pas la position explicitement, on dépend de l'ordre dans la queue — qui n'est pas garanti dans la plupart des brokers modernes.

Patterns liés

• Aggregator — le pattern inverse, souvent couplé en aval.
• Message Router — appliqué sur chaque enfant après split.
• Idempotence — chaque enfant doit avoir une clé d'unicité propre.

Sources

• Hohpe G., Woolf B. — Enterprise Integration Patterns, pattern Splitter (§259) et Sequencer. enterpriseintegrationpatterns.com — Splitter
• Apache Camel — Split EIP, support du streaming et du tokenizer. camel.apache.org — Split EIP
• UN/EDIFACT — ISO 9735 §6.3. Spécification du bracketing UNH/UNT qui définit la granularité naturelle de splitting.
• ASC X12 — 004010 §B.1.1.3.4. Spécification des bornages ST/SE pour le splitting en X12.