Expand +



Update BAPIs and Commit Handling

by Thomas G. Schuessler | SAPinsider

July 1, 2003

by Thomas G. Schuessler, ARAsoft SAPinsider - 2003 (Volume 4), July (Issue 3)

SAP uses a unique concept for managing Logical Units of Work (LUWs) in R/3 and other ABAP-based components. The dialog portion of a transaction (which is equivalent to a BAPI call) does not change the application database tables directly, but instead writes to the Update Log. Once the application determines that the updates should all be applied to the application tables (e.g., when a user saves a sales order) the application issues a COMMIT WORK statement, causing the asynchronous Update Task to make the necessary database changes. What consequences does this approach have for a BAPI programmer? This article will answer that question.

Update BAPIs in Different SAP Releases
All update BAPIs in R/3 3.1 (and there weren’t that many in that release) contained their own COMMIT WORK statement and were, therefore, stateless. In other words, you could not combine multiple update BAPIs into a single LUW. Stateless is usually good, since it is easy to understand and performs well. But in some application scenarios you need to have more control over the LUW. Because of this, SAP changed its approach in R/3 4.0: all update BAPIs should henceforth be stateful and allow the client programmer to decide when the COMMIT WORK should happen.

There Are BAPIs, and Then There Are BAPIs ...
Most update BAPIs written for 4.0 and later releases follow this new rule. Some do not. How can you find out about the LUW handling of a given update BAPI? First, check the documentation. In many cases, it will tell you whether the BAPI executes its own COMMIT WORK or requires an external one. Some BAPIs even have a parameter that allows you to choose between the two approaches.

If the documentation does not contain the pertinent information, then you need to test the BAPI to find the answer. In the SAP Function Builder (transaction code SE37), invoke the BAPI with suitable parameters and execute it. Check the Return parameter to ensure that the BAPI executed successfully. Now check whether any updates occurred in the database. There are two main ways to do this:

  • Use the appropriate online transaction. For instance, when you have added a new sales order using the SalesOrder.CreateFromDat1 BAPI, you can use transaction code VA03 to display the newly created sales order.

  • Use another BAPI. In the above sales order example, that would be SalesOrder.GetStatus.

If you cannot find the expected changes in the database, then the update BAPI does not issue its own COMMIT WORK, and you will have to call COMMIT WORK yourself.

External Commits
There are two BAPIs that allow you to commit and rollback, listed in Figure 1.

BapiService.TransactionRollback has a Return parameter, but makes no use of it. (Nothing can really go wrong when you roll back.)

BapiService.TransactionCommit, on the other hand, not only has a Return parameter, but another one, called Wait, as well. This parameter is extremely important since its improper use can result in either performance degradation in R/3 or problems in your client application.

BAPI Name RFM1 Name
BapiService.TransactionCommit BAPI_TRANSACTION_COMMIT
BapiService.TransactionRollback BAPI_TRANSACTION_ROLLBACK
Figure 1 Commit/Rollback BAPI's

Is It Worth Waiting for the Update Task?
When you pass a space character or an empty string to the Wait parameter, the commit BAPI executes a normal COMMIT WORK and returns control to the client application immediately. In most cases, this is what you want.

When you pass anything else to this parameter (by convention, “X” would be used), the BAPI executes a COMMIT WORK AND WAIT statement (ABAP is a verbose language). This not only causes the Update Task to commence processing the updates written to the Update Log for your session since the last commit or rollback, but it will also wait for the completion of said Update Task and report success or failure in the Return parameter.

Doesn’t that sound great? Is that what you should always use? No! Using COMMIT WORK AND WAIT slows down R/3 and should only be used when there is some justification (and paranoia does not count as justification). You might not trust the asynchronous update mechanism in R/3 and may be tempted to use COMMIT WORK AND WAIT just in case something goes wrong. But resist that temptation. In a normal production system, nothing ever goes wrong in the Update Task. This is not why COMMIT WORK AND WAIT was invented.

Only in This Special Case!
Let me give you a sample scenario in which COMMIT WORK AND WAIT should actually be used:

Your application first creates a new customer and then wants to create a sales order for that customer. It is not possible to commit these two update BAPIs in a single LUW, since the sales-order creation BAPI would come back with an error message saying that the specified customer number is wrong (remember that the application tables are not updated until COMMIT WORK). So you add the customer, commit, and then add the sales order.

In this type of scenario it makes sense to use COMMIT WORK AND WAIT. Otherwise, if you execute the sales-order creation BAPI too quickly after the customer creation, the Update Task might not be done with the changes for the customer creation, and you would get an error message.

In more general terms: only use COMMIT WORK AND WAIT if you execute more than one update BAPI, and a subsequent BAPI relies on the changes of a previous one.

Handling LUWs properly in your BAPI-enabled applications is actually not very difficult. The above should answer all your questions. If not, I’d like to hear from you. You can reach me at or at

1 RFM is the acronym for RFC-enabled Function Module

Thomas G. Schuessler is the founder of ARAsoft (, a company offering products, consulting, custom development, and training to a worldwide base of customers. The company specializes in integration between SAP and non-SAP components and applications. ARAsoft offers various products for BAPI-enabled programs on the Windows and Java platforms. These products facilitate the development of desktop and Internet applications that communicate with R/3.Thomas is the author of SAP’s BIT525 “Developing BAPI-enabled Web Applications with Visual Basic” and BIT526 “Developing BAPI-enabled Web Applications with Java” classes, which he teaches in Germany and in English-speaking countries. Thomas is a regularly featured speaker at SAP TechEd and SAPPHIRE conferences. Prior to founding ARAsoft in 1993, he worked with SAP AG and SAP America for seven years. Thomas can be contacted at or at

An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!