ABAP Objects und mit ihnen die Object Services existieren in einer hybriden Welt, in der neben rein objektorientierten und rein klassischen Anwendungen auch Mischformen beider Programmierstile vorkommen können. Im folgenden wird kurz auf das Zusammenspiel klassischer und objektorientierter Verbuchungstechniken eingegangen.

In einer klassischen Anwendung werden datenbankändernde Anweisungen in der Regel in Verbuchungsbausteinen programmiert, diese während der Programmausführung registriert und die Verbuchung mit der Anweisung COMMIT WORK angestoßen.

Wenn in einer klassischen Anwendung auf Dienste der Object Services zugegriffen wird, also beispielsweise mit einem persistenten Objekt gearbeitet oder eine objektorientierte Transaktion gestartet wird, wird beim ersten Zugriff automatisch eine implizite Top-Level-Transaktion im Kompatibilitätsmodus erzeugt und gestartet. Alle expliziten Zugriffe auf Persistenz- und Transaktionsdienst sind in diese implizite Top-Level-Transaktion eingebettet.

Wenn in der klassischen Anwendung COMMIT WORK ausgeführt wird, wird gleichzeitig die Top-Level-Transaktion beendet und der Transaktionsdienst leitet die Verbuchung aller bis dahin geänderten persistenten Objekte ein. Die Verbuchung der persistenten Objekte erfolgt nach den Verbuchungen der klassischen Anwendung. Entsprechen werden durch ein klassisches ROLLBACK WORK auch sämtliche Änderungen an persistenten Objekten innerhalb der Top-Level-Transaktion rückgängig gemacht.

Insbesondere werden solche Änderungen verbucht, die in objektorientierten Untertransaktionen mit der Methode END bestätigt wurden, während Änderungen, die mit UNDO rückgängig gemacht wurden, nicht berücksichtigt werden. Es kann also durchaus sinnvoll sein, auch in klassischen Anwendungen mit objektorientierten (Unter-)Transaktionen zu arbeiten, um einen einfach zu bedienenden COMMIT/ROLLBACK-Mechanismus zu haben.

Bei objektorientierten Transaktionen ist der objektorientierte Transaktionsmodus eingestellt. Die Top-Level-Transaktion ist die erste explizit gestartete Transaktion.

Es ist durchaus denkbar, daß innerhalb eines Programms im objektorientierten Modus klassische Komponenten aufgerufen werden, die klassische Verbuchungsbausteine verwenden und registrieren. Dies ist prinzipiell möglich, solange keine der klassischen Komponenten die Anweisung COMMIT WORK ausführt, da diese innerhalb einer objektorientierten Transaktion zu einem Laufzeitfehler führt.

Die Verbuchung der klassischen Verbuchungsbausteine wird durch das implizite COMMIT WORK am Ende der objektorientierten Top-Level-Transaktion angestoßen. Wenn in einer aufgerufenen klassischen Komponente wiederum eine objektorientierte Transaktion gestartet wird, ist diese automatisch Untertransaktion der Top-Level-Transaktion und wird ebenfalls bei deren Ende vor den persistenten Objekten verbucht.