Transactional Channel

Le canal qui sait dire 'commit ensemble ou rollback ensemble' — alias topologique du Transactional Client.

Problème

Envoyer un message après une écriture en DB (ou inversement) sans coupling transactionnel risque l'incohérence : message envoyé mais DB pas committée, ou DB committée mais message perdu.

Forces

• Les opérations send et write touchent deux ressources distinctes (broker + DB).
• Le two-phase commit XA est lourd et indisponible sur de nombreux brokers modernes (Kafka).
• L'Outbox pattern fournit une alternative pragmatique mais nécessite un poller.
• Une perte de message peut casser la chaîne EDI partenaire.

Solution

Le pattern Transactional Channel se matérialise sous deux formes : (1) un broker XA-compliant (IBM MQ, ActiveMQ avec JTA) ; (2) l'Outbox pattern — au lieu d'envoyer sur le broker, le producer insère le message dans une table `outbox` au sein de la même transaction DB ; un poller dédié lit la table et publie sur le broker avec idempotence côté broker. Le second est dominant en cloud-native moderne (Kafka, SQS), le premier reste utilisé sur les hubs EDI enterprise.

Implémentation EDI

En EDI, un cas classique : l'ERP enregistre une commande client et doit publier un ORDERS EDIFACT au partenaire fournisseur. Sans Transactional Channel, l'ordre persiste mais l'ORDERS peut être perdu. Implémentations : (a) IBM Sterling sur DB2 avec XA — coût ops élevé mais sans poller ; (b) Outbox table sur PostgreSQL + Debezium → Kafka → AS2 sender — pattern moderne, faible coupling. Le pattern paye crucialement sur les bug-after-incident où l'incohérence persistait jusqu'à correction manuelle.

Anti-patterns

• Send hors transaction — incohérence garantie en cas de crash entre les deux operations.
• XA pour un broker non-XA (Kafka) — illusion de transaction qui ne tient pas.
• Outbox sans poller idempotent — chaque retry duplique le message côté broker.
• Pattern aux deux côtés (XA + Outbox) — overengineering.

Patterns liés

• Transactional Client — vue côté code de la même garantie.
• Guaranteed Delivery — principe broker complémentaire.
• Idempotence — évite les doublons côté receiver.

Sources

• Hohpe G., Woolf B. — EIP, Transactional Client (alias Transactional Channel). www.enterpriseintegrationpatterns.com/patterns/messaging/TransactionalClient.html
• Microsoft — Outbox pattern. learn.microsoft.com/en-us/azure/architecture/patterns/outbox