The transaction model in which BAPIs are used determines how you have to program BAPIs.
Transaction and Logical Unit of Work (LUW)
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 SAP LUW is all the steps involved in a transaction including updating the database.
The ACID principle applies to transaction models, meaning that transactions are:
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.
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.
There must be no functional dependencies between two transactions, one transaction must not affect another transaction.
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.
Transaction Control in Client
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.
Transaction Handling via Service BAPIs
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() .
The transaction-controlling BAPIs BAPIService.TransactionCommit and BAPIService.TransactionRollback are only available as of Release 4.5 . In Release 4.0, please use the function modules BAPI_TRANSACTION_COMMIT and BAPI_TRANSACTION_ROLLBACK , in their place. The result of these function modules is identical to calling the BAPIs.
Use of the Update Task
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:
SUBMIT REPORT AND RETURN
For an example, see BAPI Transaction Model Without Commit
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.
If a BAPI executes a COMMIT WORK command, this must be mentioned in the BAPI documentation. This is the only way users are able to know that the BAPI contains a COMMIT WORK command.
These BAPIs must also be documented in SAP Note 0131838, "Collective Note for BAPIs with the Commit Work Command".
For an example of the old transaction model, see Old Transaction Model for BAPIs (with Commit) .