Das Transaktionsmodell für die Verwendung von BAPIs beeinflußt die Art und Weise, wie BAPIs programmiert werden müssen.

In dem Transaktionsmodell, das für die Entwicklung von BAPIs verwendet wird, stellt eine Transaktion eine Verarbeitungseinheit oder Logical Unit of Work (LUW) dar. Eine R/3-LUW ist die Gesamtheit der Schritte einer Transaktion einschließlich der Fortschreibung auf der Datenbank (Verbuchung).

Für Transaktionsmodelle gilt das ACID-Prinzip, d.h. Transaktionen sind:

• Atomar

Beim Aufruf einer Transaktion sollen Datenbankoperationen entweder vollständig oder überhaupt nicht ausgeführt werden. Es müssen entweder alle relevanten Daten auf der Datenbank verändert werden oder es darf keine Datenmodifikation erfolgen.

• Consistent (konsistent)

Ein wiederholter Aufruf einer Transaktion muß das gleiche Ergebnis liefern. Es dürfen keine Daten übernommen werden, die das Ergebnis implizit beeinflussen.

• Isolated (isoliert)

Zwischen zwei Transaktionen dürfen keine funktionalen Abhängigkeiten existieren; eine Transaktion darf nicht durch eine andere Transaktion beeinflußt werden.

• Durable (dauerhaft)

Änderungen oder Transaktionen können nicht zurückgenommen werden.

Ein BAPI muß so implementiert sein, daß es transaktional ist, also dem ACID-Prinzip entspricht. Darüber hinaus soll das BAPI-Transaktionsmodell einem Benutzer ermöglichen, mehrere BAPIs miteinander in einer LUW zu kombinieren
Das BAPI-Transaktionsmodell besagt also, daß sowohl einzelne BAPIs transaktional sein müssen, als auch die Kombination mehrerer BAPIs in einer LUW dem ACID-Prinzip entsprechen muß.

Das BAPI-Transaktionsmodell muß dem Benutzer eine explizite Transaktionssteuerung ermöglichen. Der Aufrufer kann folglich bei der Kombination mehrerer BAPIs selbst entscheiden, zu welchem Zeitpunkt er ein 'Commit Work' (bzw. gegebenenfalls ein 'Rollback Work') durchführt. Dies bedeutet insbesondere, daß die BAPIs selbst (im allgemeinen) kein 'COMMIT WORK'-Kommando ausführen.

Bezüglich der Kombination mehrerer BAPIs innerhalb einer LUW existieren die folgenden Einschränkungen:

• Wurde eine Instanz von einem schreibenden BAPI angelegt, modifiziert oder gelöscht, kann ein lesendes BAPI anschließend nur dann auf die aktuellen Daten zugreifen, wenn vorher ein Commit-Work stattgefunden hat.
• Es ist nicht möglich, innerhalb einer LUW zweimal schreibend auf die gleiche Instanz zuzugreifen. Beispielsweise kann nicht innerhalb der gleichen LUW zunächst das Objekt angelegt und anschließend verändert werden.

Möglich ist es dagegen, innerhalb einer LUW mehrere Instanzen des gleichen Objekttyps anzulegen.

Das Abschließen einer Transaktion erfolgt entweder über ein Commit-Work- oder über ein Rollback-Kommando. Eine BAPI-Transaktion muß speziell über den Aufruf der BAPIs BapiService.Transaction Commit() bzw. BapiService.TransactionRollback() beendet werden.

Operationen, die die Datenbank verändern, müssen über die Verbuchung durchgeführt werden. Ansonsten besteht die Gefahr, daß während des RFC-Aufrufs unkontrollierte und unerwünschte Datenbank-Commits ausgeführt werden.

Außerdem darf der Aufruf eines BAPIs keine zusätzliche, vom BAPI unabhängige LUW anstoßen. Aus diesem Grund sind folgende Kommandos in einem BAPI nicht erlaubt:

• CALL TRANSACTION
• SUBMIT REPORT
• SUBMIT REPORT AND RETURN

Zu Release 3.1 führten die BAPIs selbst das 'COMMIT WORK'-Kommando durch, d.h. ein BAPI war gleichbedeutend mit einer LUW oder Transaktion. Zusätzlich zu den BAPIs aus Release 3.1 gibt es noch wenige weitere Ausnahmen, in denen aus technischen Gründen ein 'COMMIT WORK'-Kommando enthalten ist.