Programming Transactions

Transactions

A transaction is a logical process in the R/3 System. Examples include generating a list of customers, changing a customer's address or booking a flight reservation for a customer. From the user's point of view, it is a self-contained unit.

Caution: As in DP generally, the term "transaction" has several different meanings in the R/3 System:

• In terms of database programming, a transaction - also known as a database transaction or an LUW - is an inseparable sequence of database operations concluded with a database commit.
  

• In terms of dialog programming, a transaction - also known as an SAP transaction (see CALL TRANSACTION) - is a complex object which consists of a module pool and screens, and is called with a transaction code. An SAP transaction usually covers a whole series of logical processes. For example, the SAP transaction SE38 allows you to display, change, print or rename ABAP/4 programs.

Update transactions

Preserving database integrity

If a transaction involves updating the database, the changes are made either in their entirety or not at all (see example under "Semantic integrity" in Database Integrity). The successful conclusion of a transaction is concluded by a database commit, but an error triggers a database rollback (see LUW). Since database updates in one LUW cannot be canceled by a database rollback in a subsequent LUW, all database updates in one transaction must be performed in a single LUW.

To achieve this, each transaction should contain a single database commit. With many transactions, there are three reasons to contradict this point of view:

• Duration of database locks
  
  To protect a database object against accesses by other transactions, it is locked by the database system until the next database commit (see Database Locking). If this lock is retained for more than one dialog step, the system would then wait for further user input. The uncontrolled duration of this database lock would thus adversely affect the parallel execution of several transactions. For this reason, each dialog step in the R/3 System is concluded by a database commit. A transaction containing more than one dialog step contains more than one LUW.
  
  

• Overflow of the rollback log
  
  To be able to perform a database rollback, a database system must generate a copy of each database object before making a change. These copies are kept in a rollback log until the end of an LUW. An overflow of the rollback log always results in the termination of the transaction which caused it. For example, attempting to remind a large number of defaulting customers in the same transaction could trigger such an error. You can onls solve this problem by dividing the set of database updates into several smaller units ( LUWs) for the database system. In this particular example, the executing program could perform a database commit for each customer reminded.
  
  

• Exceeding the time allocation
  

Bundling database updates

In the interests of data integrity, all the database updates for transactions which contain more than one LUW should be bundled together into one single LUW. To prevent overload here, you can delay the execution of FORM routines and functions in ABAP/4 programs.

• PERFORM form ON COMMIT
  
  By using the addition ON COMMIT, you can delay execution of a subroutine until the next ABAP/4 command COMMIT WORK occurs. All subroutines specified in this way are executed together in the LUW concluded by this COMMIT WORK
  
  

• CALL FUNCTION function IN UPDATE TASK
  
  With this statement, the function module function is registered so that it can be executed by an update process on encountering the next ABAP/4 command COMMIT WORK. In this case (i.e. asynchronous processing), the dialog process does not wait until the function module has been executed. However, with COMMIT WORK AND WAIT (i.e. synchronous processing), the processing does not continue until the function module has finished. All function modules specified as "Update with immediate start" or "Immediate start, no restart" (in short V1) are executed together in one LUW. All function modules specified as "Update with delayed start (in short V2 are executed in a separate LUW. The type V2 is mainly used for less urgent database updates (e.g. of a statistical nature).
  
  

• CALL FUNCTION function IN BACKGROUND TASK
  
  With this statement, the function module function is registered so that it can be executed on encountering the next ABAP/4 command COMMIT WORK. In this case (i.e. asynchronous processing), the dialog process does not wait until the function module has been executed. All function modules specified in this way are executed together in one LUW by any dialog process.
  
  By using the addition DESTINATION, you can even run the function module in a different R/3 System (see Transactional Remote Function Call). In this case, all function modules specified in this way for one destination executed together in one LUW.

This technique of bundling database updates allows you to distribute the execution of a transaction across several work processes and even across different R/3 Systems.

The ABAP/4 commands COMMIT WORK and ROLLBACK WORK

When using the bundling technique, you must always signal the conclusion of an update transaction by calling the ABAP/4 command COMMIT WORK once . In addition to the database commit, this triggers all the FORM routines and functions registered by this transaction. While the database commit simply leaves a Logical Unit of Work (LUW) after successful conclusion, the ABAP/4 command COMMIT WORK only triggers part of the processing within a transaction. A transaction cannot be considered as successfully completed until this part has also been successfully executed.

Although it is not obligatory, you should signal the conclusion of an update transaction that uses the bundling technique by calling the ABAP/4 command COMMIT WORK. This is not only good programming style, but also relieves you from having to release locked objects explicitly (see SAP Locking).

If an error is detected during the transaction, you can use the ABAP/4 command ROLLBACK WORK to roll back the database to its level before the beginning of the transaction.

Handling terminations

If the processing of parts of a transaction is delayed, runtime errors may occur. In this case, you should be aware of the following:

If a runtime error occurs or if you call the ABAP/4 command MESSAGE with the message type 'A' in a FORM routine form registered with PERFORM form ON COMMIT, the LUW that contains the ABAP/4 command COMMIT WORK is automatically canceled by a database rollback (see LUW). Then, no further registered FORM routines or functions are executed and the user sees the relevant information about the termination on the screen. The ABAP/4 command ROLLBACK WORK results in a runtime error.

If a runtime error occurs or if you call the ABAP/4 command ROLLBACK WORK or MESSAGE with the message type 'A' in a V1 function function registered with CALL FUNCTION function IN UPDATE TASK , all database updates of already executed V1 functions are automatically canceled by a database rollback (see LUW). V2 functions and functions registered with CALL FUNCTION IN BACKGROUND TASK are not executed. All database updates of the LUW that contain the ABAP/4 command COMMIT WORK and thus all updates of FORM routines registered with PERFORM ON COMMIT are not canceled.

If a runtime error occurs or if you call the ABAP/4 command ROLLBACK WORK or MESSAGE with the message type 'A' in a V2 function function registered with CALL FUNCTION function IN UPDATE TASK, only the database updates of this V2 function are automatically canceled by a database rollback (see LUW). Any existing V2 functions and functions registered with CALL FUNCTION IN BACKGROUND TASK are executed.

With V1 and V2 functions, the user sees information about the termination on the screen, provided his/her R/3 System has been set up accordingly. By choosing Tools -> Administration -> Monitoring -> Update, he/she can analyze the termination and - after eliminating the cause of the termination - manually restart all functions of the type 'Update with immediate start' and 'Update with delayed start' that belong to the transaction.

If a runtime error occurs or if you call the ABAP/4 command ROLLBACK WORK or MESSAGE with the message type 'A' in a function function registered with CALL FUNCTION function IN BACKGROUND TASK, all the database updates of already executed functions of the same destination are automatically canceled by a database rollback (see LUW). The user sees information about the termination on the screen. If an error is detected during the processing of a function registered in this way, you can decide in the program whether all the functions with the same destination should be executed again after the database rollback (see Transactional Remote Function Call).

Short response times in dialog transactions

The acceptance of dialogs by users depends entirely on transaction response times. In this context, success rests not only on the short response times of a user's "own" transaction. Since the response times of one transaction affects those of another, you must always take response times of other transactions into account when programming. By their nature, database operations contribute most to the increase of response times in dialog transactions.

Distributing a transaction across several work processes

By bundling database updates, you can distribute a transaction across several work processes. Asynchronous execution of the database update in an update or background process shortens response times in the dialog process.

Schematic flow of a transaction:

d p1 b1 d f1 g p2 d f2 b2 d c t1   d   w
| LUW1  | LUW2    |  ...  | LUWn   |        | LUW ...
|-------|---------|-------|--------|--------|---dialog process-->

                                    d  t2   d     d t3  d
                                    |  LUW  | ... | LUW |
----------update process------------|-------|-----|-----|----->

                                              d t4  d
                                              | LUW |
----------dialog process----------------------|-----|--------->

b1, b2,,Registration of functions for execution in the background
c,,,,ABAP/4 command COMMIT WORK
d,,,,Database commit
f1, f2,,Registration of V1 functions for execution in update process
g,,,,Registration of V2 functions for execution in update process
p1, p2,,Registration of FORM routines
t1,,,,Execution of all registered FORM routines
t2,,,,Execution of all registered V1 functions
t3,,,,Execution of one registered V2 function per LUW
t4,,,,Execution of all registered functions in the background
w,,,,Wait until all V1 functions have finished in case of
,,,,COMMIT WORK AND WAIT

For further information please refer to

SAP Transaction Concept