Das Problem
Die kritischen Fehler entstehen selten im glücklichen Pfad. Ein Prozess kann nach einer externen Aktion abstürzen, bevor er das Ergebnis speichert. Beim Neustart sieht er denselben offenen Fall und führt die Aktion womöglich ein zweites Mal aus.
Der Ansatz
Das Action Ledger ist ein kleiner Transaktionskern für Software-Agenten. Es speichert Fälle dauerhaft, vergibt begrenzte Bearbeitungsleases und schreibt Zustandswechsel in eine unveränderliche Ereignishistorie.
Vor dem externen Aufruf wird der Versuch dauerhaft gespeichert. Danach liest ein Adapter das maßgebliche System erneut. Nur eine frische Rücklese-Bestätigung darf die Aktion abschließen.
- Stabile Fallidentitäten, damit derselbe Eingang nicht zwei Fälle erzeugt
- Zustände für pending, waiting, human decision und complete
- Zeitlich begrenzte Leases und sichere Wiederaufnahme nach einem Ausfall
- Idempotente Aktionsschlüssel und Fingerprints für den beabsichtigten Request
- Append-only Historie für Fälle, Aktionen und den Schreibschalter
Was das zeigt
Der wichtigste Unterschied ist nicht erfolgreich oder fehlgeschlagen. Er ist versucht oder bestätigt. Systeme, die diese beiden Zustände vermischen, können nach einem Abbruch ihre eigene Vergangenheit nicht zuverlässig erklären.
Wo der Ansatz passt
Das Muster gilt für jeden automatisierten Prozess mit einer Außenwirkung: ERP-Buchungen, Dokumentfreigaben, Nachrichten, Bestellungen oder Statusänderungen. Je folgenreicher die Aktion, desto wichtiger sind Identität, Zustandsverlauf und Rücklese-Beleg.
Die Referenzimplementierung ist für mehrere Prozesse auf einem Rechner gedacht, nicht als verteiltes System. Sie ist weder Queue noch Scheduler noch Workflow-Engine.