When you link an executable program to a logical database by entering the name of the logical database in the program attributes, the subroutines of the logical database program together with the event blocks of the executable program form a modularized program for reading and processing data. The individual processing blocks are called in a certain predefined sequence by the runtime environment. The runtime behavior is controlled by the structure, selections, and PUTstatements in the logical database, and by the GET statements in the executable program.
The runtime environment calls depend both on the structure of the logical database and on the definition of the executable program. The structure of the logical database determines the sequence in which the processing blocks of the logical database are called. These, in turn, call GET event blocks in the executable program. These GET event blocks determine the read depth of the logical database. TABLES or NODESstatements in the declaration part of the executable program determine which of the input fields defined in the logical database are included in the selection screen. They also define interface work areas for passing data between the logical database and the executable program.
The actual access to the database is made using Open SQL statements in the PUT_TABLE subroutines. The data that is read is passed to the executable program using the interface work areas (defined using the TABLES statement). Once the data has been read in the logical database program, the executable program can process the data in the GET event blocks. This technique separates data reading and data processing.
If you specify a logical database in the attributes of an executable program, this affects the standard selection screen of the program. It contains both the selection fields from the logical database and those from the program itself. You can specify which of the logical database selections are relevant for your program, and should therefore appear on the screen, by declaring interface work areas for the relevant nodes.
The following list shows the sequence (shown above) in which the ABAP runtime environment calls the subroutines of the logical database and the event blocks in the executable program. The runtime environment executes a series of processors (selection screen processor, reporting processor) in the runtime environment.. The ABAP code listed below shows the processing blocks that belong to the individual steps.
1. Initialization before the selection screen is processed.
This subroutine is called once only before the selection screen is first displayed.
This event occurs once only before the selection screen is first displayed.
2. PBO of the selection screen Initialization before each occasion on which the selection screen is displayed (for example, to supply default values for key fields).
This subroutine is called each time the selection screen is sent before it is displayed.
AT SELECTION-SCREEN OUTPUT.
This event is called each time the selection screen is sent (before it is displayed).
3. The selection screen is displayed at the presentation server, and the user can enter data in the input fields.
4. Possible request for Input help (F4) or field help (F1).
If the user requests a list of possible entries for database-specific parameters par or selection criteria selop, these subroutines are called as required.
If the user requests field help for these parameters, the subroutines are called with the ending _HLP instead of _VAL.
AT SELECTION-SCREEN ON
VALUE-REQUEST FOR par.
AT SELECTION-SCREEN ON VALUE-REQUEST FOR selop-LOW.
AT SELECTION-SCREEN ON VALUE-REQUEST FOR selop-HIGH.
If the user requests a list of possible entries for database-specific parameters par or selection criteria selop, these events are triggered as required.
If the user requests field help for these parameters, the events with the addition ON HELP-REQUEST occur instead of ON VALUE-REQUEST.
5. PAI of the selection screen. Checks to see whether the user has entered correct, complete, and plausible data. Also contains authorization checks. If an error occurs, you can program a user dialog and make the relevant fields ready for input again.
FORM pai USING fname mark.
The interface parameters FNAME and MARK are passed by the runtime environment.
FNAME contains the name of a selection criterion or parameter on the selection screen.
If MARK = space, the user has entered a simple single value or range selection.
If MARK = '*', the user has also entered selections on the Multiple Selection screen.
Using the combination FNAME = '*' and MARK = 'ANY', you can check all entries at once when the user chooses a function.
AT SELECTION-SCREEN ON fname.
Event for processing a particular input field.
AT SELECTION-SCREEN ON END OF fname.
Event for processing multiple selections.
Event for processing all user input.
6. Processing before reading data.
BEFORE EVENT 'START-OF-SELECTION'.
The logical database can use this subroutine for necessary actions before reading data – for example, initializing internal tables.
First reporting event in an executable program after the selection screen has been processed. You can use this event block to prepare the program for processing data.
7. Reading data in the logical database and processing in the executable program.
The logical database reads the selected data of the node node.
GET table [LATE].
This event is triggered by the PUTstatement in the above subroutine. This event block allows you to process the data read for node in the corresponding interface work area.
8. Processing after reading data.
AFTER EVENT 'END-OF-SELECTION'.
The logical database can use this subroutine for necessary actions after reading data, for example, releasing memory space.
Last reporting event. You can use this event block to process the temporary dataset that you have created (for example, sort it).
9. If a list was generated during the above steps, the list processor in the runtime environment takes control of the program and displays the list.
Suppose TABLE1 is the root node and TABLE2 is its only subordinate node in a logical database. The processing steps for reading and processing data would then have the following hierarchical order:
GET table1 LATE.
It makes sense to use authorization checks using the AUTHORITY-CHECK statement in the following subroutines in the database program or event blocks of the executable program:
· Subroutines in the database program:
· Event blocks in the executable program:
¡ AT SELECTION-SCREEN
¡ AT SELECTION-SCREEN ON fname
¡ AT SELECTION-SCREEN ON END OF fname
¡ GET table
Whether you place the authorization checks in the database program or in the executable program depends on the following:
· The structure of the logical database.
For example, you should only check authorizations for company code if you actually read lines containing the company code at runtime.
Avoid repetitive checks – for example, within SELECT loops.
The separation of database access and application logic allows you to program all of your authorization checks centrally in the logical database program. This makes it easier to maintain large programming systems.