List screens are one of the most basic ways of developing reports in ABAP. This chapter explains how to use list screens for report development.

13 List Screens

List screens, also known as classical lists, are one of the three types of screens in the SAP GUI. The other two type of screens, as previously discussed, are selection screens and general (dialog) screens. List screens are obsolete and have been replaced with the SAP List Viewer (ALV) for live applications, but because many old programs might still use list screens, understanding them is important to work with such programs.

In ABAP, we can create different types of programs, and not all program types support screens. Before we talk more about list screens, let’s discuss the different types of ABAP programs that you can create, whether they support screens, and the various processing blocks that they support. We’ve already worked with some of these program types while discussing the various topics covered so far in this book.

We’ll start our discussion in this chapter by looking at the various types of ABAP programs in Section 13.1, which should serve as a quick recap of the different program types used so far in this book. Different program types behave differently during execution, and we’ll discuss program execution in Section 13.2. Note that one program can call other programs during execution. In Section 13.3, we’ll look at how memory is managed when a program runs and we’ll explore various ways in which different programs can exchange data during runtime.

ABAP is an event-driven programming language. We discussed various events in Chapter 7, but in Section 13.4 we’ll look at events specific to list screens. Classical lists are typically used to generate reports or issue print output; they can be used for creating normal reports (basic lists ) and drilldown reports (detail lists ). We’ll discuss basic and detail lists in Section 13.5. We’ll look at classical reports that use basic lists in Section 13.6, and finally at interactive reports that use detail lists in Section 13.7. We’ll take what we’ve learned and put it to practice in Section 13.8.

13.1 Program Types

When you created your first program in Chapter 4, you saw that the program type attribute in the Program Attributes window is a dropdown list with various options (see Figure 13.1).

The Program Attributes window can be called using the menu path Goto • Attributes from the ABAP Editor screen. The various types of programs include executable programs, module pools, function groups, class pools, interface pools, subroutine pools, type groups, and include programs.

Figure 13.1 Program Types in ABAP Editor

When you run an ABAP program, you call its processing blocks in a specific sequence. The program type attribute needs to be set while creating the program. The program type determines which processing blocks the program can contain, how the program is executed and handled by the ABAP runtime environment, and whether the program can define its own screens.

In this section, we’ll look at the different program types.

13.1.1 Executable Programs

Traditionally, executable programs are used for developing reports due to their sequence of execution. This is why executable programs are introduced with a REPORT statement in the code. For example, if you create an executable program with the name ZEXAMPLE_PROGRAM, you’ll see that the first statement inserted in ABAP Editor is REPORT ZEXAMPLE_PROGRAM.

An executable program can contain any ABAP processing blocks , except function modules. They can also contain any number of local classes. Executable programs support screens, but it’s not mandatory to have a screen defined for the program to run. You don’t need to manually design a screen to work with executable programs; you can use use selection screens and list screens, which are generated by specific statements in the code (such as PARAMETERS or SELECT-OPTIONS for selection screens and WRITE for list screens).

A selection screen allows the user to specify selection criteria, based on which the data from the database can be processed and shown as output on the list screen. This process flow makes selection screens suitable for developing reports.

Executable programs are executed with SUBMIT statements. Users can execute programs directly by entering the program name in Transaction SA38 or using the menu path System • Services • Reporting. Even when using the transaction or menu path, the system uses the SUBMIT statement internally to execute the program.

An executable program can also be executed directly from ABAP Editor (Transaction SE38 ). However, end users may not have the required authorizations to open ABAP Editor to execute the program, because ABAP Editor is an ABAP Workbench tool and requires development authorizations to access.

Transaction SA38 provides a simple interface to run any executable program by entering the program name, as shown in Figure 13.2. Optionally, a transaction code can be assigned to an executable program, allowing the program to be executed directly using the transaction code. These transactions are called report transactions.

Executable programs are the only programs that can be used for background processing. Executable programs are created using either ABAP Editor or Object Navigator (Transaction SE80).

Figure 13.2 Initial Screen of Transaction SA38

13.1.2 Module Pool Programs

Module pool programs are used for dialog-oriented applications that contain a large number of screens. They’re created using ABAP Editor or Object Navigator and are introduced with the PROGRAM statement.

A module pool program can contain all the possible processing blocks in ABAP, except function modules and reporting events (INITIALIZATION, START-OF-SELECTION, GET, END-OF-SELECTION). Module pool programs can contain as many local classes as required.

Unlike executable programs, module pool programs can’t be executed directly using the program name. Instead, they’re executed using a transaction code. It’s mandatory for a module pool program to have at least one screen defined; that is, you can’t execute a module pool program without having a screen defined for the program.

To execute a module pool program, a transaction code is created for the program, which links to the initial screen of the program when the transaction is executed. From this initial screen flow logic, dialog modules are called. The execution of module pool programs is controlled by screen flow logic. The screens for the module pool program are created using the Screen Painter tool. We’ll discuss the module pool program flow further in Section 13.2.2.

13.1.3 Function Groups

Function groups are introduced using the FUNCTION-POOL statement and are the only program type that can contain function modules. A function group can use all processing blocks in ABAP, except reporting events. They can also contain local classes.

Function groups are created using the Function Builder tool (Transaction SE37 ) or Object Navigator. They can be executed by a transaction code, but are generally loaded by calling the function modules of the function group. When a function module is called, the entire function group with all its function modules is loaded into the program memory. For this reason, it’s important to keep only related function modules in a function group.

Similar to executable programs and module pools, a function group can have its own screens defined, including selection screens and list screens. The screens of a function group are called from the function module belonging to the group.

13.1.4 Class Pools

Class pools are created in the Class Builder tool (Transaction SE24) and are introduced with the CLASS-POOL statement. They act as a container to hold exactly one global class and as many local classes as required. They can’t have any other processing blocks, except methods. A class pool can’t have any screens defined.

Note

Executable programs, module pools, and function groups are the only three types of programs that support screens.

A class pool is loaded when the global class is called from programs. A transaction code can be created for a method of the global class so that an object of the class can be created implicitly when the method is used.

Type pools are predecessors of the general type definitions in ABAP Data Dictionary. Type pools are obsolete; we no longer use type pools to define global data types. One drawback of type groups is their missing semantic attributes; in other words, except for any comments in the code, semantic attributes can’t be maintained for data types or constants defined in a type group, unlike other ABAP Data Dictionary objects, such as data elements.

In older systems, the declarations in a type group are made visible in other programs using the TYPE-POOLS statement.

13.1.8 Include Programs

Include programs provide library functions through which the source code maintained in an include program can be inserted in other programs using the INCLUDE statement. They aren’t standalone programs on their own and can’t be executed independently. They’re used to organize the program source code into smaller editable units. They don’t have introductory statement, because they don’t represent stand-alone compilation units with memory of their own.

Now that you have an understanding of the various types of programs, let’s discuss how these programs are executed.