Zurück in die Quelle.

Eine Handlung ist ein benannter Typ mit Parametern, Vorbedingungen und Wirkung: welche Objekte sie liest, welche Eigenschaften sie ändert, in welche Quelle sie schreibt. Parameter sind typisiert wie Eigenschaften. Ein Pflichtparameter ohne Wert oder ein Wert außerhalb seines Bereichs erreicht nie eine Quelle.

Vorbedingungen sind Regeln über den Zustand, etwa dass ein Objekt in einem bestimmten Zustand ist oder ein Verweis gesetzt ist. Sie werden unmittelbar vor der Ausführung gegen den aktuellen Stand geprüft, nicht gegen den Stand, als der Vorschlag entstand.

Zuerst das Schema: Typen, Pflichtfelder, Wertebereiche. Dann die Regeln der Ontologie: Kardinalität, Vorbedingungen und das Recht des Handelnden an genau dieser Handlung. Zuletzt die Quelle selbst, die ihre eigenen Prüfungen behält. FORGE umgeht sie nicht.

Weist die Quelle eine Änderung ab, gilt sie nicht. Die Meldung der Quelle geht unverändert an den Handelnden zurück und in den Verlauf.

FORGE schreibt nie direkt in die Tabellen eines fremden Systems. Geschrieben wird über die Schnittstelle, die der Hersteller dafür vorsieht: einen REST- oder OData-Aufruf, bei SAP einen BAPI-Aufruf mit anschließendem BAPI_TRANSACTION_COMMIT oder ein eingehendes IDoc. So greifen die Prüfungen, Sperren und Folgebuchungen der Quelle wie bei einer Eingabe von Hand.

Als erledigt gilt eine Handlung erst, wenn die Quelle bestätigt hat und FORGE die Änderung beim nächsten Lesen wieder sieht. Bis dahin steht der neue Wert in der Ontologie als ausstehend, nicht als gültig.

Netze verlieren Antworten, und ein Aufruf kann angekommen sein, obwohl seine Bestätigung fehlt. Damit eine Wiederholung nicht doppelt wirkt, trägt jede Ausführung einen Idempotenzschlüssel. Schnittstellen, die einen solchen Schlüssel annehmen, etwa im Kopf Idempotency-Key, den ein Entwurf der IETF beschreibt, erkennen die Wiederholung selbst. Für andere hält FORGE fest, welcher Schlüssel schon bestätigt ist, und fragt vor einer Wiederholung den Zustand in der Quelle ab.

Die Absicht zu schreiben und die Änderung im eigenen Speicher hält FORGE in derselben Transaktion fest. Nach dem Outbox-Muster landet der Auftrag in einer Ausgangstabelle; ein eigener Prozess liest sie und ruft die Quelle auf. Fällt FORGE dazwischen aus, geht kein Auftrag verloren, und keiner entsteht ohne die Änderung, zu der er gehört. Zusammen mit dem Idempotenzschlüssel wirkt jede Handlung so genau einmal, obwohl der Aufruf mehrmals unterwegs sein kann, sofern die Quelle Wiederholungen erkennt oder ihr Zustand eindeutig zeigt, ob der erste Aufruf gewirkt hat. Wo beides fehlt, wiederholt FORGE nicht selbsttätig, sondern legt den Fall zur Entscheidung vor.

Berührt eine Handlung zwei Systeme, gibt es keine gemeinsame Transaktion über beide. FORGE zerlegt sie darum in eine Saga: eine Folge lokaler Schritte, jeder mit einem Gegenschritt, der seine Wirkung fachlich aufhebt. Scheitert der dritte Schritt, laufen die Gegenschritte des zweiten und des ersten in umgekehrter Reihenfolge.

Ein Gegenschritt löscht keine Vergangenheit, er ist eine neue Buchung, etwa eine Stornierung, und beide stehen im Verlauf. Wo sich eine Wirkung nicht ausgleichen lässt, steht dieser Schritt zuletzt in der Folge, damit vor ihm alles geprüft und geschrieben ist, was sich noch zurücknehmen lässt.

Zwischen Vorschlag und Ausführung kann jemand anderes denselben Wert geändert haben. Wo die Schnittstelle bedingtes Schreiben kennt, schreibt FORGE darum nur unter Bedingung: Die Handlung trägt die Version, die sie gelesen hat, und die Quelle führt die Änderung nur aus, wenn diese Version noch gilt. Bei HTTP-Schnittstellen ist das der Kopf If-Match mit dem ETag des gelesenen Stands; passt er nicht mehr, antwortet der Dienst mit 412 Precondition Failed (RFC 9110). In Datenbanken ist es eine Versionsspalte in der Bedingung des Updates. Wo die Schnittstelle das nicht kennt, etwa bei vielen BAPIs und bei IDocs, prüft FORGE die Version unmittelbar vor dem Aufruf und nutzt, wo vorhanden, die Sperren der Quelle; eine Änderung im verbleibenden Zeitfenster fällt beim erneuten Lesen als Konflikt auf.

Ein Konflikt endet nie in stillem Überschreiben. Die Handlung kehrt mit beiden Ständen zurück, und der Handelnde entscheidet neu. Im Verlauf stehen danach Handlung, Parameter, Handelnder, gelesene Version, Antwort der Quelle, Idempotenzschlüssel und Zeitpunkt, als Kette von Einträgen wie im Prototyp von Freigabe und Protokoll.