Skip to Content

In ABAP Geek 2 – ABAP Program Types you have learned about the different ABAP program types. Now, let’s turn to ABAP program execution. The last two rows of the table in ABAP Geek 2 show which programs can be executed and how. With the exception of Type Pools and Interface Pools all programs can be executed via a Transaction Code. Furthermore, executable programs can be executed via the ABAP statement SUBMIT. Besides execution via transaction codes or SUBMIT, you can load ABAP programs by calling their procedures from ABAP programs that are already loaded.

We will examine program execution via transaction codes first:


We call an execution of an ABAP program using a transaction code a transaction . There are dialog , report, parameter, variant, and – as of Release 6.10 – OO transactions. A transaction is started by entering the transaction code in the input field on the standard toolbar or by means of the ABAP statements CALL TRANSACTION or LEAVE TO TRANSACTION. Transaction codes can also be linked to screen elements or menu entries. Selecting such an element will start the transaction.

A transaction code is simply a twenty-character name connected with a dynpro, another transaction code, or, as of Release 6.10, a method of an ABAP program. Transaction codes linked with dynpros are possible for executable programs, module pools, and function groups. Parameter transactions and variant transactions are linked with other transaction codes. Transaction codes that are linked with methods are allowed for all program types that can contain methods. Transaction codes are maintained in transaction SE93.

So, a transaction is nothing more than SAP’s way of program execution – but why is it called “transaction”? Well, ABAP is a language for business applications and the most important features of business applications were/are transactions. Since in the beginnings of SAP the execution of a program often meant the same as carrying out a business transaction, the terms transaction and transaction code were chosen for program execution. But never mix up the technical meaning of a transaction with business transactions For business transactions its the term LUW (Logical Unit of Work) that counts – and during one transaction (program execution) there can be many different LUW’s.

Let’s have a look at the different kind of transactions:

Dialog Transaction

The most common kind of transactions. The transaction code of a dialog transaction is linked to a dynpro of an ABAP program. When the transaction is called, the respective program is loaded and the dynpro is called. Therefore, a dialog transaction rather calls a dynpro sequence than a program. Only during the execution of the dynpro flow logic, the dialog modules of the ABAP program itself are called. The program flow can differ from execution to execution. You can even assign different dialog transaction codes to one program.

Parameter Transaction

In the definition of a parameter transaction code, a dialog transaction is linked with parameters. When you call a parameter transaction, the input fields of the initial dynpro screen of the dialog transaction are filled with parameters. The display of the initial screen can be inhibited by specifying all mandatory input fields as parameters of the transaction.

Variant Transaction

In the definition of a variant transaction code, a dialog transaction is linked with a transaction variant. When a variant transaction is accessed, the dialog transaction is called and executed with the transaction variant. In transaction variants you can assign default values to the input fields on several dynpro screens in a transaction, change the attributes of screen elements, and hide entire screens. Transaction variants are maintained in transaction SHD0.

Report Transaction

A report transaction is the transaction code wrapping for starting the reporting process. The transaction code of a report transaction must be linked with the selection screen of an executable program. When you execute a report transaction, the runtime environment internally executes the ABAP statement SUBMIT. I’ll speak about SUBMIT in my next Weblog.

OO Transaction

A new kind of transactions as of Release 6.10. The transaction code of a OO transaction is linked with a method of a local or global class. When the transaction is called, the corresponding program is loaded, for instance methods an object of the class is generated and the method is executed. OO transactions can be linked with the Transaction Service of the Object Services.


The system field sy-tcode contains the transaction code, that was used to execute a program. After starting a program with SUBMIT, it contains the transaction code of the caller. In parameter and variant transactions, sy-tcode does not contain their own transaction codes but the transaction code of the implicitly called dialog transaction. In order to get the transaction code of parameter and variant transactions, you can use the static method GET_CURRENT_TRANSACTION of the class CL_DYNPRO (as of Release 6.20).

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Former Member
    Dear Horst Keller,
    we developed for our customers an application which among other things acts as a individual menu in the R/3 system from which every user can call his transactions. In this application we now have problems with more and more transactions which restart themselves from the application data screen (e.g. VA01, AS01, AS02, AS03). In session manager, procedure is recognized by entry in the field SY-TCODE. But this is not possible in our application (up to now) because SY-TCODE is overwritten in customer programms. So we need the possibility for our application to act as a “system” program or as a “menu”.
    Multiple contacts with SAP on OSS-level and inquiries in user group didn’t show us a solution. However, we recognized that many other customers wants to have solved the same problems.
    With best regards

Leave a Reply