When you run an ABAP program, you call its processing blocks in a specific sequence. This is controlled from outside the program by the processors of the current work process. For the purposes of program flow, we can summarize the screen processor and ABAP processor of the work processes invovled into the ABAP runtime environment. The runtime environment contains a range of special control patterns that call screens and processing blocks in certain orders. These successive sections are also called processors. When you run an ABAP program, the control passes between various processors.
Each ABAP program has a program type which must be determined in the program attributes when the program is created.
There are seven program types from which you can choose: executable program, module pool, function group, class pool, interface pool, subroutine pool, and include program.
Prior to Release 4.6, you had to specify the internal one-character ID to select a program type. An executable program, for example, was assigned type 1. Now the program type is chosen based on the full name. The program type defines the basic technical attributes of a program, that is, which processing blocks a program may contain, how the program is handled and executed by the ABAP runtime environment, and whether it can work with its own screens.
When you run an ABAP application program, you must call at least the first processing block from outside the program, that is, from the runtime environment. This processing block can then either call further processing blocks or return control to the runtime environment. When you start an ABAP program, the runtime environment starts a processor (dependent on the program type), which calls the first ABAP processing block. The program can be started either by the user or by the system (for example, in background processing), or through an external interface, for example, for Remote Function Calls (RFC).
Normally, the user of an SAP System does not come into direct contact with the program. However, this is not true for executable programs which can be started by entering the program name after choosing System -> Services -> Reporting. All other independent programs (that is, all program types except include programs) can either be called by entering a transaction code or be loaded by using their procedures. In most cases, users do not even need to know the program name or transaction code as the call of a program is normally linked to menu paths of the associated applications.
The transaction code is a twenty-character name which is assigned to a screen or a method of an ABAP program and is used for program execution. To execute a program, you either enter the transaction code in the input field of the standard toolbar or use the statements CALL TRANSACTION or LEAVE TO TRANSACTION. Transaction codes linked to screens are valid for executable programs, module pools and function groups. Transaction codes linked to methods are allowed for all program types except include programs.
You create executable programs directly using the tool called ABAP Editor. Executable programs can contain all processing blocks supported in ABAP, with the exception of function modules, and as many local classes as required. Executable programs are only started with the SUBMIT statement. Although NetWeaver AS ABAP offers several ways to call executable programs by entering their name on the screen, the system still executes the SUBMIT statement in the background.
It is not necessary to control executable programs directly using self-defined screens since the relevant processors of the runtime environment call the processing blocks and screens (selection screens and lists) automatically and in a predefined sequence. The process flow allows the user to enter selection parameters on a selection screen. The data is then selected from the database and processed. Finally, an output list is displayed. At no stage does the programmer have to define his or her own screens. User actions on screens can then trigger further processing blocks.
The runtime environment also allows you to work with a logical database, that is, with a special ABAP program for reading data from database tables. The flow of an executable program is oriented towards reporting (whose main tasks are to read data from the database, process it, and display the results). This is why executable programs are often referred to as reports, and why running an executable program is often called reporting (see Report Programming). Analogously, the source code of an executable program starts with the REPORTstatement.
Since it is not compulsory to define event blocks, you can yourself determine the events to which your ABAP program should react. Furthermore, you can call your own screens or processing blocks at any time, leaving the prescribed program flow. You can use this, for example, to present data in a table on a dialog screen instead of in a list. The simplest executable program contains only one processing block (START-OF-SELECTION).
No user dialog is required for executable programs (see Dialog Programming). You can fill the selection screen using a variant and output data directly to the spool system instead of to a list. Consequently, executable programs are a prerequisite for background processing.
If a transaction code has been assigned to an executable program, users can then start it using the transaction code and not the program name. The reporting-oriented runtime environment is also called when you run a report using a transaction code. This kind of transaction is called a report transaction.
It is appropriate to use executable programs (reports) when the flow of your program corresponds either wholly or in part to the pre-defined flow of the runtime environment. Until Release 4.5A, the only way to use a logical database was to use an executable program. However, from Release 4.5A, it is also possible to call logical databases on their own.
Module pools are directly created using the ABAP Editor and are introduced with the PROGRAM statement. With the exception of reporting event blocks and function modules, module pools can contain all processing blocks supported in ABAP and as many local classes as required. While they are executed, all events of the ABAP runtime environment may be triggered.
The most important technical attribute of a module pool is that it can only be controlled using screen flow logic. You must start them using a transaction code, which is linked to the program and one of its screens (initial screen). Another feature of these programs is that you must define your own screens in the Screen Painter (although the initial screen can be a selection screen).
When you start a program using a transaction code, the runtime environment starts a processor that calls the initial screen. This then calls a dialog module in the corresponding ABAP program. The remainder of the program flow can take any form. For example, the dialog module can:
· return control to the screen, after which the processing passes to a subsequent screen. Each screen has a following screen, set either statically or dynamically. Screens and their subsequent screens are components of freely definable screen sequences.
· call other screen sequences, selection screens or lists, from which further processing blocks in the ABAP program are started.
· call other processing blocks itself, either internally or externally.
· call other application programs using CALL TRANSACTION or SUBMIT.
It is appropriate to use module pools when you write dialog-oriented programs using a large number of screens whose flow logic largely determines the program flow of screen sequences.
Function groups or function pools are introduced with the FUNCTION-POOL statement and are the only programs that are allowed to contain function modules (which are special procedures that can be called from within all other ABAP programs). They can be executed using transaction codes but are normally loaded by their function modules being called. With the exception of reporting event blocks, function groups can contain all processing blocks supported in ABAP and as many local classes as required.
Like executable programs and module pools, function groups can contain their own screens, including selection and list screens. Screen processing, that is reacting to user actions in event blocks and dialog modules, also takes place in the function group. The screens are called from within the function modules of the group. A function group containing screens and a single function module therefore allows you to modularize screen flows.
The Function Builder is a tool in the ABAP Workbench that you can use to create function groups and function modules.
Class pools may not contain any screens of their own or any processing blocks except methods. They are introduced with the CLASS-POOL statement and are exclusively used as a container for exactly one global class and as many local classes as required. Class pools are loaded by using their global class. As of Release 6.10, you can also link transaction codes to methods of global classes so that an object of the class is implicitly created when they are used.
The Class Builder is a tool in the ABAP Workbench that you can use to create class pools.
Interface pools may not contain any screens of their own or any processing blocks. They are introduced with the INTERFACE-POOL statement and are exclusively used as a container for one global interface which can be implemented in any global or local classes. They are loaded by using the interface.
Like class pools, you create interface pools in the Class Builder of the ABAP Workbench.
Subroutine pools are created using the ABAP Editor and are introduced with the PROGRAM statement. They may not contain any screens of their own, and with the exception of the LOAD-OF-PROGRAM event block they may only use subroutines as processing blocks. Subroutine pools are loaded by externally calling their subroutines from within other ABAP programs.
Type groups or type pools are created using the ABAP Dictionary tool and are introduced with the TYPE-POOL statement. They may not contain any screens of their own or any processing blocks. Type groups are exclusively used as containers for global data types which can be made visible in any ABAP program using the TYPE-POOLS statement.
In contrast to all other program types, include programs do not represent stand-alone compilation units with a memory area of their own. Include programs cannot be executed. They merely serve as a library for ABAP source code. They are exclusively used to organize program texts into small editable units which can be inserted at any place in other ABAP programs using the INCLUDE statement. There is no technical relationship between include programs and processing blocks. Includes are more suitable for logical programming units, such as data declarations, or sets of similar processing blocks. The ABAP Workbench has a mechanism for automatically dividing up module pools, function groups and class pools into include programs. You create your own include programs using the ABAP Editor.