The transaction model in which BAPIs are used determines how you have to program BAPIs.

Within the context of the transaction model used to develop BAPIs, a transaction represents one processing step or one logical unit of work (LUW). An R/3 LUW is all the steps involved in a transaction including updating the database.

The ACID principle applies to transaction models, meaning that transactions are:

• Atomic

When a transaction is called, database operations are either fully executed or not at all. Either all relevant data has to be changed in the database or none at all.

• Consistent

If a transaction is called more than once, each call must have the same result. No data is imported that may indirectly affect the result.

• Isolated

There must be no functional dependencies between two transactions, one transaction must not affect another transaction.

• Durable

Changes cannot be reversed and transactions cannot be canceled.

A BAPI must be implemented so that it is transactional. In other words, it complies with the ACID principle. The BAPI transaction model must also enable users to combine several BAPIs in one LUW.
The BAPI transaction model, therefore, implies both that individual BAPIs must be transactional and that several BAPIs combined in one LUW must comply with the ACID principle.

The BAPI transaction model must afford the user explicit transaction control. Therefore, if several BAPIs are called together, the caller can decide him/herself when to execute a COMMIT WORK (or, as the case may be, a ROLLBACK WORK). This means that BAPIs themselves cannot (generally) execute a COMMIT WORK command.

The following restrictions apply to combining several BAPIs in one LUW:

• If an instance was created, modified or deleted by a write BAPI, a read BAPI can only access the most recent data if a COMMIT WORK has taken place.
• It is not possible to make two write accesses on the same instance within one LUW. For example, you cannot first create and then change the object within the same LUW.

You can, however, create several instances of the same object type within an LUW.

A transaction is completed either using a COMMIT WORK command or a ROLLBACK command. A BAPI transaction must be ended by calling the BAPIs BapiService.Transaction Commit() or BapiService.TransactionRollback().

Operations that change the database must be carried out through the updating process. Otherwise, there’s a risk that both unchecked and unwanted database COMMITs are executed during the RFC call.

Additionally, the call of a BAPI must not trigger further LUWs that are independent of the BAPI. For this reason BAPIs must not contain the following commands:

• CALL TRANSACTION
• SUBMIT REPORT
• SUBMIT REPORT AND RETURN

In Release 3.1, the BAPIs themselves executed the COMMIT WORK command, BAPIs had the same purpose as an LUW or transaction. Besides the BAPIs from Release 3.1, there are few further exceptions which, for technical reasons, contain a COMMIT WORK command.