Sunday, December 18, 2011

Why BAPIs should not have Commit in them?


  We have always been told that BAPIs should not have Commit in them.but then what is the harm in using a commit in BAPIs?

One of the reasons stated is that functionalities if lagged inside in BAPI and then without considering the time lag, the commit statement is executed then it could cause setbacks and inconsistencies.

Another issue, is the upgrade issues poses by such statements as it would come increasing difficult with new error handling and functionalities or Business scenarios being added in newer releases.

But the primary reason is because of Transaction model developed for BAPIs
In Release 4.0 the commit control must be taken out of write BAPIs, that is, those BAPIs that cause database changes.The transaction model in which BAPIs are used determines how you have to program BAPIs.

Logical Unit of Work (LUW) and Statelessness

Within the context of the transaction model used to develop BAPIs for R/3 Releases 3.1 and 4.0 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 whole transaction must be programmed to be stateless.

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. 


So, its important that we consider the ACID principle whenever we are constructing a Custom BAPI as well.

No comments:

Post a Comment