Transactional Outbox

Le modèle Transactional Outbox enregistre une modification métier et le message sortant correspondant dans une même transaction locale de base de données. Un processus distinct, le relais, lit ces enregistrements et les publie auprès du courtier de messages. Il comble ainsi le décalage entre une transaction validée et une tentative d’envoi que l’application n’a finalement pas pu effectuer.

Dans un exemple fictif, le ticket d’assistance S-27 passe à l’état « fermé ». Le service enregistre ensemble le nouvel état et l’événement E-27. Si la transaction échoue, les deux modifications sont annulées. Si elle est validée puis que le service s’arrête brutalement, l’événement reste enregistré pour être publié ultérieurement.

Publication et traitement restent distincts

Si le relais publie E-27 puis s’arrête avant d’enregistrer ce succès, il peut publier le message une seconde fois. Le destinataire doit traiter les livraisons répétées sans reproduire leur effet, par exemple à l’aide d’une Transactional Inbox. L’outbox seule ne garantit pas qu’un effet soit produit une seule fois sur l’ensemble base de données, courtier et destinataire.

Définissez comment repérer les enregistrements en attente, rendre les échecs visibles et, si nécessaire, préserver l’ordre des événements de chaque ticket. Prévoyez aussi le nettoyage et la reprise. CDC peut servir de base technique au relais ; capturer des modifications de lignes ne définit pas à lui seul un événement métier.

Sources

• Chris Richardson — Transactional Outbox