Um die Datenkonsistenz bei einem Datenbankfehler zu gewährleisten, müssen die Anwendungstabellen in der gleichen Logical Unit of Work (LUW) aktualisiert werden wie die IDoc-Statustabelle. Ansonsten führt ein Datenbankfehler, z.B. "no tablespace", zu den folgenden Situationen:

• Anwendungstabellen korrekt, Aktualisierung des IDoc-Status gescheitert: der IDoc hat den Status "bereit für Übergabe an Anwendung" und würde nun noch ein zweites Mal verarbeitet, obwohl die Daten bereits verarbeitet sind.

• Die Aktualisierung des IDoc-Status verläuft erfolgreich, jedoch scheitert die Anwendungsaktualisierung: Das IDoc hat den Status "erfolgreich verarbeitet", jedoch wurden die Anwendungstabellen nicht aktualisiert. Das IDoc kann nicht erneut verarbeitet werden, daher erreichen die Daten niemals die Anwendung.

Um sicherzustellen, daß nur eine LUW verwendet wird, darf der Anwendungsfunktionsbaustein die Daten nicht in der Datenbank festschreiben. Die Daten werden von der ALE-Schicht festgeschrieben, nachdem die Funktion aufgerufen wurde und die Statussätze des IDocs aktualisiert worden sind.

Dies ist nicht möglich, wenn die Anwendungsdaten über eine Call Transaction aktualisiert werden, da jede Call Transaction automatisch mit einem Commit Work abgeschlossen wird. In diesem Fall muß die Transaktion selbst modifiziert werden (siehe unten).

Ein Call Dialog anstatt einer Call Transaction umgeht zwar einen Commit Work, kann aber nur eingesetzt werden, wenn der Dialogschritt keine PERFORM ON COMMIT-Anweisungen enthält - da der Commit über ALE nach Abschluß des Dialogs erfolgt, gehen alle globalen Variablen, die während des Dialogs gesetzt wurden, verloren. Verwenden Sie daher einen Call Dialog nur mit äußerster Vorsicht!

Enthalten die IDocs Stammdaten (z.B. Kundendaten), dann erweist sich das Problem als nicht so akut, da fehlende Daten immer bei Bedarf noch einmal übertragen werden können, und eine doppelte Verarbeitung eines IDocs führt nicht dazu, daß ein Beleg zweimal erstellt wird.