Transactional Outbox

Il modello Transactional Outbox salva una modifica ai dati di business e la registrazione persistente del messaggio in uscita nella stessa transazione locale del database. Un processo separato, il relay, legge queste registrazioni e le pubblica sul broker di messaggi. Si copre così l’intervallo in cui il commit è riuscito, ma l’applicazione non arriva a tentare l’invio successivo.

In un esempio fittizio, il ticket di assistenza S-27 passa allo stato «chiuso». Il servizio salva insieme il nuovo stato e l’evento E-27. Se la transazione fallisce, entrambe le modifiche vengono annullate. Se il commit riesce e poi il servizio si arresta, l’evento resta registrato per la pubblicazione successiva.

Pubblicazione ed elaborazione restano separate

Se il relay pubblica E-27 e si arresta prima di registrare l’esito positivo, può pubblicare di nuovo il messaggio. Il destinatario deve gestire le consegne ripetute senza duplicarne l’effetto, per esempio con una Transactional Inbox. La sola outbox non garantisce un effetto esattamente una volta fra database, broker e destinatario.

Definisca come individuare le registrazioni in attesa, rendere visibili gli errori e, se necessario, mantenere l’ordine di pubblicazione degli eventi di ciascun ticket. Preveda anche pulizia e ripresa. CDC può fornire una base tecnica al relay; rilevare modifiche alle righe non definisce da solo un evento di business.

Fonti

• Chris Richardson — Transactional Outbox