Transaktionskonzept

In vielen Fällen, etwa bei einer Bestellung, fallen im Rahmen eines Vorgangs mehrere Nachrichten an, die inhaltlich zusammenhängen. Eine Liefermeldung bezieht sich etwa auf eine Bestellung und eine Rechnung auf eine Lieferung. Dadurch entsteht eine Reihenfolge der Nachrichten innerhalb eines Vorgangs, und nur wenn diese Reihenfolge von den angeschlossenen Systemen berücksichtigt wird, können empfangene Nachrichten sinnvoll interpretiert werden.
Da die Implementierung des Transaktionsverfahrens doch sehr komplex ist, kann in Absprache darauf verzichtet werden. Hierzu muss jedoch beachtet werden, dass die Felder „Kennung der Transaktion" sowie beide Sequenznrn Felder leer bleiben.
Ein geschlossener Vorgang, dessen Nachrichten zusammenhängen, wird ihm Rahmen dieses Dokuments als Transaktion bezeichnet. Eine konkrete Durchführung einer solchen Transaktion wird mit einem eindeutigen Bezeichner versehen, der als Kennung der Transaktion im Kopf der Nachricht mitgeführt wird. Diese Kennung wird als laufende Nummer vom orderManager in seiner ersten Nachricht innerhalb eines Vorgangs (PurchaseOrderCreate oder PurchaseOrderAck nach PurchaseOrderCreate) vergeben und muß dann bei jeder nachfolgenden Nachricht im Rahmen des Vorgangs (z.B. PurchaseOrderAccept, PurchaseOrderDecline, DeliveryNote, etc.) mit übertragen werden.
Wenn eine unmittelbar physikalische Verbindung besteht, werden in der Regel Nachrichten vom Empfänger in der gleichen Reihenfolge, in der der Sender sie abschickt hat, auch entgegen genommen und verarbeitet. Das liegt unter anderem an der hohen Geschwindigkeit und der Verlustfreiheit üblicher Netzwerktechnik, wodurch die Übertragungszeit vernachlässigbar wird und für alle Nachrichten zudem in etwa gleich ist. Damit entspricht die Ordnung der Nachrichten der Ordnung der sie verursachenden Benutzeraktionen. Eine Garantie für eine die Reihenfolge erhaltende Verarbeitung von Nachrichten gibt es hier jedoch nicht.
Wenn keine dauerhafte Verbindung zwischen Sender und Empfänger besteht, oder bei einem zeitweisen Ausfall der Verbindung laufen Nachrichten eines Vorgangs in einem Puffer (Verzeichnis, Warteschlangen) auf und warten auf ihre Weiterleitung und Verarbeitung. Dadurch steigen die Laufzeiten der Nachrichten signifikant an und zudem fallen sie für die Nachrichten eines Vorgangs unterschiedlich aus. In Abhängigkeit vom Mechanismus, der die Reihenfolge bestimmt, in dem die Nachrichten aus ihrem Puffer gelesen werden, kann es passieren, dass zu einem späteren Zeitpunkt abgeschickte Nachrichten andere Nachrichten, die zu einem früheren Zeitpunkt abgeschickt worden sind, „überholen".
Bevor der Empfänger eine Nachricht, die eine andere überholt hat, verarbeiten darf, muss er solange warten, bis die ältere, aber langsamere Nachricht eingetroffen und verarbeitet ist. Der Empfänger muss sich also erst auf den „Wissensstand" bringen, der notwendig ist, um die jüngere, aber schnellere Nachricht verstehen zu können.
Um überhaupt feststellen zu können, welche von zwei Nachrichten die jüngere und welche die ältere ist, nummerieren sowohl die Warenwirtschaft als auch der ordermanager die von ihnen verschickten Nachrichten mit aufsteigenden ganzen Zahlen. orderManager und die Warenwirtschaft führen für jeden Vorgang einen Zähler für die von ihnen verschickten Nachrichten, und speichern gleichzeitig den Zähler des Gegenübers, wenn sie eine neue Nachricht empfangen. Der eigene Zähler startet zu Beginn der Transaktion bei 0, wird bei jeder in einer Transaktion verschickten Nachricht um eins erhöht und im Kopf als „Sequenznummer des Senders der Nachricht" übergeben. Der Empfänger merkt sich diese Zahl und schickt sie bei seiner nächsten Nachricht im Feld „Sequenznummer des Empfängers der Nachricht" wieder zurück.

ordermanager  beginnt zum Beispiel eine Transaktion mit dem Versenden einer PurchaseOrderSubmit-Nachricht (Definition in den folgenden Abschnitten), in deren Kopf seine eigene Sequenznummer, also die des Senders auf 1, die der Warenwirtschaft, also des Empfängers auf 0 gesetzt wird. Die Warenwirtschaft empfängt die Nachricht und sieht am Nachrichtentyp, dass nun ein neuer Vorgang beginnt und merkt sich die 1 als die letzte erhaltene Sequenznummer des ordermanager. In ihrer Antwortnachricht vom Typ „PurchaseOrderAck" trägt die Warenwirtschaft als ihre Sender-Sequenznummer 1 ein, und als Empfänger-Sequenznummer die von ordermanager erhaltene 1.
Anhand der gemerkten 0 und der jetzt empfangenen 1 kann ordermanager erkennen, dass zwischen seiner Nachricht und der Antwort der Warenwirtschaft keine weiteren Nachrichten an ihn liegen und er die Antwort sofort verarbeiten kann.
Anders sähe es dagegen aus, wenn ordermanager zunächst eine schnellere Nachricht vom Typ „PurchaseOrderAccept" empfinge, in deren Kopf als Sequenznummer des Senders eine 2 eingetragen ist. Der letzte ihm bekannte Zählerwert der Warenwirtschaft ist die 0 vom Beginn der Transaktion. Die dazwischen liegende 1 wäre dann bei ihm noch nicht angekommen und er müsste die „PurchaseOrderAccept"-Nachricht solange zwischenspeichern, bis die „PurchaseOrderAck"-Nachricht eingetroffen und verarbeitet ist. Erst dann ist auch auf Seiten des ordermanager  wieder die Reihenfolge hergestellt, in der die Nachrichten von der Warenwirtschaft versandt worden sind.
Dieser Mechanismus betrifft nur Nachrichten, die im Rahmen des Bestellvorgangs anfallen, alle anderen Nachrichten (Basisdaten, Produktinformationen) werden vorerst außerhalb von Transaktionen verschickt.
Um sicherzustellen, dass alle Nachrichten garantiert ausgeliefert werden, werden einzelne Nachrichten, von denen nicht sicher bekannt ist, ob sie zugestellt werden konnten (weil zum Beispiel während des Versendens der Sender ausgefallen ist), möglicherweise mehrmals zugestellt. Empfängt eine Seite eine Nachricht mehr als einmal, obwohl bereits die erste Nachricht erfolgreich verarbeitet worden ist, dann müssen alle folgenden ignoriert werden. Ob eine Nachricht bereits empfangen worden ist, kann anhand der Transaktionskennung und der Sequenznummern ermittelt werden.