Sie sind auf Seite 1von 1

All or Nothing Database and SAP

If you are writing business programs, you are dependent on having certain program parts executed in full
or not at all. If the program, for example, debits money on one account and credits money on another, it
must not happen that the money is deducted from the one account and not credited on the other. If
problems occur during this procedure, it must be ensured that these related postings are executed either
in full or that none of them is executed.. This would mean that, in the latter case mentioned above,
postings already executed would have to be reset entirely.
Processes of this nature are generally called transactions. At the end of a transaction, it is confirmed
and posted in its entirety to the database (COMMIT) or discarded in its entirety (ROLLBACK). One could
assume that the SAP program can access the transaction handling process of the database. However,
this is hardly possible. A business transaction may extend over several screens. It is not certain that a
program works with the same work process over several screens. On the contrary, it is the feature of the
SAP NW AS that it can work with much less work processes than users. If a program is just waiting for
inputs, its work process so far can be passed to another user. A program can work with different work
processes, one after the other, and a work process can be used by different programs, one after the
Database transactions, however, cannot cover several work processes. If a work process changes its
owner, the database transaction with which it was linked must be committed or rolled back. A typical
ABAP application program can work with several different work processes, one after the other. Therefore,
the SAP NW application server has its own transaction concept. The Open SQL statements INSERT,
UPDATE, MODIFY, and DELETE allow you to program database changes that extend over several
dialog steps. But even if you have not explicitly programmed a database commit, the implicit database
commit that occurs after a screen has been processed concludes the database transaction.
The solution to this problem is to combine all the update postings of a program using function modules.
If you call a function module using the statement CALL FUNCTION ... IN UPDATE TASK, the function
module is flagged for execution using a special update work process. The actual execution of the
function module is postponed therefore. This means that you can write the Open SQL statements for the
database changes in the function module instead of in your program, and call the function module at the
point in the program where you would otherwise have included the statements. When you call a function
module using the IN UPDATE TASK addition, it and its interface parameters are stored as a log entry in
a special database table called VBLOG. You can then commit or roll back all the update postings of a
program in one go.
If you work with the Object Services, you do not have to take care of transaction handling. Changes to
persistent objects are written to the database by the Object Services, using update posting function
modules provided you set a Commit. For this purpose, you can use either the regular COMMIT
WORK, or you can use the transaction service for object-based wrapping of transaction control. The
transaction service provides you with the option as an additional feature of nesting transactions to as
deep a level as you wish and rolling back changes to inner transactions without the outer transactions
being affected by them.