13.2 Program Execution
Programs are either executed by the user directly or called by other programs. Of all the available program types, only executable programs and module pool programs are executed by the user directly; all the other programs are loaded when called from other already running programs. For example, a user will run an executable program, and if a functional module is called within this executable program, then the function group is loaded into memory. The user doesn’t execute the function group directly.
An ABAP program is made of various processing blocks, and executing an ABAP program is all about calling these processing blocks in a certain order. The execution flow of the program is entirely controlled by the runtime system. When the program is executed, the first processing block is always called from outside the program by the runtime environment, and the rest of the sequence depends on user actions.
For example, if you execute a report program, the runtime environment first calls the INITIALIZATION event and, if a selection screen is defined, prepares the selection screen. Based on the user actions on the selection screen, other processing blocks are called. The program type determines which of the processing blocks is first called.
In this section, we’ll look at implementing both executable programs and module pool programs, the only program types executed by the user. We’ll then discuss how to internally call the other program types we’ve discussed thus far.
13.2.1 Executable Program Flow
Executable programs are executed by entering the program name in Transaction SA38 (see Figure 13.2). From a user perspective, executable programs are the only programs that can be executed by their program names. However, often users need not know the program names, because the programs are either assigned an easy-to-remember transaction code (e.g., Transaction MRKO) or linked to menu items on the screen. From a technical perspective, executable programs are the only programs that can be executed using a SUBMIT statement—for example, SUBMIT ZEXAMPLE_PROGRAM.
When an executable program is run, the ABAP runtime environment triggers a predefined sequence of events. The sequence of events triggered by the ABAP runtime environment is as follows:
- LOAD-OF-PROGRAM
- INITIALIZATION
- AT SELECTION-SCREEN
- START-OF-SELECTION
- GET
- END-OF-SELECTION
The selection screen events are triggered only if the program has a selection screen defined using the PARAMETERS or SELECT-OPTIONS statement in the program. Similarly, list events are triggered if the program generates a list screen (see Section 13.4 for more on list events). A list is generated automatically at the end of program execution. User actions on the list trigger list events.
The sequence of events for executable programs makes them suitable for developing reports. Reports provide read-only access to the database; the data from the database can be read based on the selection criteria entered by the user and shown as a report output on a list screen.
For example, when the user executes a report, we can initialize the program variables under the INITIALIZATION event, validate the selection screen inputs under the AT SELECTION-SCREEN event, select and process the data under the START-OF-SELECTION event, and finally generate the report output under the END-OF-SELECTION event.
We can use the GET event to process the data from a logical database, an ABAP program that transfers the data from multiple logically related database tables to ABAP programs in an efficient way. In the past, logical databases could only be used in executable programs using the GET event, but now they can be used in other programs as well without the need to use GET event.
13.2.2 Module Pool Program Flow
Module pool programs are executed differently than executable programs. To execute a module pool program, we need to define at least one screen and create a transaction code. The transaction code links the program with one of its screens, which becomes the initial screen. From this initial screen, dialog modules and other screens are called.
The sequence of events triggered for module pool programs is as follows:
- LOAD-OF-PROGRAM
- PROCESS BEFORE OUTPUT (PBO)
- PROCESS AFTER INPUT (PAI)
The ABAP runtime environment first calls the PBO event of the initial screen and displays the screen to the user. User actions on the screen trigger PAI. After PAI, the ABAP runtime environment triggers the same screen’s PBO or another screen’s PBO immediately, before presenting the screen again, depending on whether the same screen is called or a different screen is called. Additional events such as PROCESS ON HELP-REQUEST (POH) and PROCESS ON VALUE-REQUEST (POV) are called if the user selects (F1) or (F4) help respectively for screen fields.
With this program flow, the role of the ABAP program is to maintain dialog modules that are called from the screen—hence the name module pool program.
Module pool programs (also called dialog programs) are used to create transactions that allow the user to modify the data in the system. Most of the standard SAP transactions that are used by users to carry out day-to-day activities such as creating sales orders (Transaction VA01) and purchase orders (Transaction ME21n) are dialog programs.
13.2.3 Calling Programs Internally
As mentioned previously, only executable programs and module pool programs are called by the user through a screen; all other program types are called internally using specific statements (e.g., using CALL FUNCTION to call a function module that loads the function group).
Even executable programs and module pools can be called internally from other programs that are already running. Executable programs are called internally using the SUMBIT statement with the program name (e.g., SUBMIT ZDEMO_PROGRAM.), whereas module pool programs are called using CALL TRANSACTION (e.g., CALL TRANSACTION MM01.) or LEAVE TO TRANSACTION (e.g., LEAVE TO TRANSACTION MM01.) statement.
A program call can be distinguished by whether the calling program is terminated when the new program is called or the called program is embedded in the calling program. The SUMBIT and LEAVE TO TRANSACTION statements terminate the calling program and load the new program in memory, while SUBMIT AND RETURN (e.g., SUMBIT ZDEMO_PROGRAM AND RETURN) and CALL TRANSACTION stack the current program with all its data before loading the called program into memory.
Once the called program’s execution ends, the calling program is loaded back into memory with all its data and continues execution of the statement immediately after the call location. This allows us to go back to the previous program in the call sequence.
Now that you have an understanding of how programs are executed, let’s take a look at how memory is organized in ABAP programs.