Anthony Cecchini is the President of Information Technology Partners (ITP), an SAP consulting company headquartered in Pennsylvania. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 17 years of experience in SAP R/3 business process analysis and SAP systems integration. His areas of expertise include SAP NetWeaver integration; ALE development; RFC, BAPI, IDoc, Dialog, and Web Dynpro development; and customized Workflow development. You can reach him at [email protected]
Problems with ABAP output and why the ALV Grid Control can help
In this Blog series I will dive deeply into the ALV Grid Control and elaborate on its advantages in ABAP list processing. Lets begin by looking at some problems with “Classical” list processing…
Within an SAP system there is a lot of data that needs to be reviewed, maintained, and interpreted. You know what I’m talking about — inventory data, controlling data, accounting data, employee addresses, and so on and so forth. The bigger a company, the greater the amount of data that needs to be output for review and analysis.
Within the context of certain applications, the terms “output” and “list” can be synonymous. When I took my very first ABAP class at SAP Education, I learned that the term list denotes an output page that has been created using ABAP statements like WRITE, POSITION, or FORMAT, and text lines are buffered in a list buffer before a system program called the ABAP list processor steps in to perform various run-time activities. Lists created in this way are often referred to as classical lists (everything in SAP that is okd is lovingly termed Classical) and represent the standard output method of data.
If you have dealt with list formatting issues and/or the use of events for interactive lists, you will find the features and functions introduced by the new ALV Grid Control will make your life a lot simpler.
Granted, the effort to create a classical list for just simple output of data is minimal. But amass a few lists across a few applications, each created by a different developer, and things get a bit more complicated. The ABAP list processor lacks standard baseline list handling functions like sorting, filtering, and calculations, so these types of functions have to be added by hand for each new list. Responsibility for list layout and interface design is also left to the developer.
This is why you find different schemes for list handling and layout in different applications. Lack of standard, baseline list processing functions means that developers devise their own methods for common list handling activities such as headings, sorting, filtering, rendering subtotals, and the like. The result is that end users who work with more than one application may have to deal with different ways to access these simple list functions based on the developer who coded the solution.
The ALV Grid Control solves this problem. Its user interface provides a set of generic functions (e.g., sorting, filtering) for handling tabular data. It also confers the many benefits of controls technology to users, enabling more operations by mouse, and interaction with other controls, such as drag-anddrop. Developers simply plug the ALV Grid Control into their applications and the tool takes care of the rest. You do not need to do any further programming to offer users these functions. How you “plug” the control into an application is the first thing I will show you in this month’s blog. So lets get started!
ALV Grid Control Baseline Functionality
Take a look at the screen shot below; it shows a tab-strip with an ALV Grid Control and its integrated toolbar, which, thanks to the controls technology, enables mouse-oriented access to a variety of list handling functions.
Columns can be selected and dragged to a different column position. Users can invoke functions that refer to a selected column (like hide, search, or filter) directly via a context menu. (The selection of columns and rows complies with the Microsoft standard, which means that users can do things like use the CTRL key to select rows or columns that are not adjacent.)
Where the ALV Grid Control is placed within a SAP GUI screen is up to you. You can, for example, “dock” a control to an arbitrary side of a dynpro. The ABAP Workbench uses this technique in combination with an ALV Grid Control to dynamically blend in additional information — e.g., a global worklist that contains repository objects, or syntax error messages belonging to the currently shown source code.
Let’s take a closer look at the toolbar. See the screen shot below for an overview of the generic functions of the toolbar.
The user can sort the list by one or more columns, filter entries (e.g., display only data of one day), and calculate totals and subtotals. Users can determine column order and column length to retrieve needed information in a more convenient fashion. Developers can allow these settings to be saved in a display variant that can be saved as the default setting, such that the user’s preference for settings is loaded before the list is displayed. Some of the functions made available in the toolbar are there to provide better visualization of lists that either have a lot of columns or a lot of rows. The Detail function, for example, allows users who are working with a list that has a lot of columns to view values of a line in a separate pop-up window. For lists that are very long, a user can calculate subtotals, then collapse all subtotal levels by clicking on the little buttons of the total line. Particular subtotal lines can be collapsed or expanded, too. Users will also find functions, like the ABC analysis tool, to facilitate the analysis of data. To print a list, the ALV Grid Control calls the SAP List Viewer. Alternatively, users can export a list to MS Word or MS Excel. For those who usually work with Excel, the ALV Grid Control offers a function to switch between Grid and Excel inline display.
Now that you have seen the standard list handling functions that become available to users via the ALV Grid Control, let’s talk about integrating this control with your applications.
Integrating the ALV Grid Control
When you create lists in the classic way, the ABAP list processor is responsible for storing, displaying, and managing a single list or multiple lists. ABAP statements are used to temporarily store the lists on the application server while the program is executed, and, with the help of the list processor, display them on a special container screen.
In contrast, the ALV Grid Control uses the SAP Controls Technology for displaying lists. Controls are binary reusable software components installed on the local PC. (Please see my blog on SAP Controls Technology)
This eliminates the need for the system to access the application server in order to do something like move columns of a table. Basically, if you use the Controls Technology, specific functions are shifted from the application server (backend) to the SAP GUI (frontend).
Integrating the ALV Grid Control into a Screen
In order to display the ALV Grid Control (or any control, for that matter) on a screen, you need a container control instance. A container control is responsible for displaying or arranging one or more controls on the screen. For integrating a control into a screen, you have a choice of the following five different container control types:
Since these container classes can be combined, there is a tremendous degree of flexibility for placing the ALV Grid Control on the screen.
The container control is instantiated using the CREATE OBJECT statement, and then linked to an area on the screen. When a control that is to be displayed is instantiated, you can specify the container control as its parent. This creates a close connection between these two controls. It is possible to link the control together with its container control to another screen afterward, which requires that the two screens are at the same pop-up level. This means that the call level for modal dialog boxes must be the same.
Although there are many methods, events, and attributes defined within the class interface, only one method call is needed to display a list with the ALV Grid Control. Take a look at the screen shot below…..its a cheat sheet for the definitions and methods needed for displaying a list using the ALV Grid Control.
So once you have generated an instance of the ALV Grid Control, integrated it into a screen, and selected the data that is to be displayed, this one simple call
is all that you need to provide a list with a set of generic functions.
Generating an instance of the control and integrating it into a screen is not specific to the ALV Grid Control. You do this the same way you would any control.
What about selecting the data that is to be displayed and passed to the instance together with a description of the fields? You need to understand that displaying data via the ALV Grid Control requires, at a minimum, that you provide the following two types of information: the output table and the field catalog.
The output table is an internal table that contains the data that is to be displayed. In most cases, a structure of the output table already resides in the ABAP Dictionary. When you pass the structure name to the ALV Grid Control, the field catalog for the description of fields is generated automatically. As you will soon see in upcoming blogs, the field catalog can be created in a number of ways. You will also see that some of the fields in this catalog must be specified. The bottom line is that a structure description of the data that is to be displayed must be declared to the ALV Grid Control either through the field catalog or the corresponding ABAP Dictionary structure.
Lets finish this blog with a code example. I will assume you will create screen 100 and use a custom container to hold the ALV Grid Control. Here is the code, I will follow with an explanation:
DATA: OK_CODE LIKE SY-UCOMM,
G_GRID TYPE REF TO CL_GUI_ALV_GRID,
G_CUSTOM_CONTAINER TYPE REF TO CL_GUI_CUSTOM_CONTAINER,
GT_SFLIGHT TYPE TABLE OF SFLIGHT. “output table
CALL SCREEN 100.
MODULE PAI INPUT.
MODULE PBO OUTPUT.
SET PF-STATUS ‘MAIN100’.
* create controls
IF G_CUSTOM_CONTAINER IS INITIAL.
CREATE OBJECT G_CUSTOM_CONTAINER
EXPORTING CONTAINER_NAME = ‘MYCONTAINER’.
CREATE OBJECT G_GRID
EXPORTING I_PARENT = G_CUSTOM_CONTAINER.
* ALV specific part starts here
* data selection
SELECT * FROM SFLIGHT INTO TABLE GT_SFLIGHT.
* display output table in ALV instance
CALL METHOD G_GRID->SET_TABLE_FOR_FIRST_DISPLAY
EXPORTING I_STRUCTURE_NAME = ‘SFLIGHT’
CHANGING IT_OUTTAB = GT_SFLIGHT.
We start by calling SCREEn 100. This calls modules PBO and PAI within its flow logic. At PBO time, we define a status MAIN100 to leave the program with function code EXIT (this is nothing but classic ABAP dialog programming). We then create an instance of the Custom Container Control and an instance of the
ALV Grid Control. Note that the latter is connected to the first by parameter I_PARENT and that the container control is placed on an area that has been defined in the Screen Painter with the name MYCONTAINER. Next we pass ALV the target data that is to be displayed in a list of the flight model
One last point worth noting is that data selection is well separated from the call to display the data. If this is also the case for old reports that uses the ABAP list processor at your company, it can be easily converted to a report based on the ALV Grid Control. The more the data selection is mingled with commands to display the data, the greater the amount of effort required to convert the old report.
That’s it! Now that the control has been integrated on the screen, you will likely want to configure it to do other cool things. The key to configuring the ALV Grid Control for your particular application is the structures that are passed by the application to an ALV Grid instance before or during list display. For some simple extensions of your ALV Grid instance, you only need to set the right parameter and pass the table or structure by using method set_table_for_first_display. But this is what we will cover next month.