All or Nothing – Database and SAP Transactions 

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 other.

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.