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
- Use another BAPI. In the above sales order example, that would be
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.
There are two BAPIs that allow you to commit and rollback, listed in Figure
Return parameter, but makes no use of it. (Nothing
can really go wrong when you roll back.)
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.
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
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 firstname.lastname@example.org
or at email@example.com.
1 RFM is the acronym
for RFC-enabled Function Module
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 firstname.lastname@example.org or