ALV In BRIEF

Introduction

Here is the definition for ALV from SAP Help: “The ALV Grid control is a flexible tool for displaying lists.

The tool provides common list operations as generic functions and can be enhanced by self-defined options.”

The ALV Grid control is used to build non-hierarchical, interactive, and modern-design lists. As a control, it is a component that is installed on the local PC.

The ALV Grid control provides typical list functions as sorting, filtering, summing, etc.,while also gives the opportunity to develop user functions where needed.
It presents numerous interfaces like Excel Inplace and Crystal Reports.

The wrapper class implemented to encapsulate ALV Grid functionality is “CL_GUI_ALV_GRID”.
There is another way to display lists with ALV utilizing “REUSE_ALV...” functions.

Building Blocks

While preparing a list to be displayed via an ALV grid control, we have some basic components to prepare.
These are;

i. List data:
Obviously, this is the data in an internal table to be listed. Standard ALV functions except sorting makes just read access to the list data. However, sorting changes state of the internal table.
The internal table holding list data may be of any flat type. Deep types are only allowed when set for some functionalities of ALV Grid.

ii. Field Catalog: We use another internal table to define specifications on how the fields of our list will be displayed. This internal table is called the
“field catalog”.
The field catalog must comprise some technical and additional information about display options for each column to be displayed.
There are three procedures to generate the field catalog as “Automatic generation”, “Semi-automatic generation”, and “Manual generation”.
The internal table for the field catalog must be referenced to the dictionary type “LVC_T_FCAT”.

iii. Layout Structure: We fill a structure to specify general layout options for the grid. With this structure we can set general display options, grid customizing, totals options, color adjustments etc...
The layout structure must be of type “LVC_S_LAYO”.

iv. Event Handler: We should define and implement an event handler class if we want to handle events triggered by the ALV Grid instance.
After creating ALV Grid instance, we must register an instance of this event handler class to handle ALV Grid events.

v. Additional Data: To trigger some additional features of ALV Grid we can have some additional data to pass as parameters. For example, initial sorting criteria, buttons to be deactivated, etc...


General Scheme

Now, we can figure out a primitive scheme to prepare our ALV Grid. As a control object, ALV Grid instance requires a container to be linked to the screen.
Generally, an instance of the class “cl_gui_custom_container” is used for this purpose.
Instances of some other container classes such as “cl_gui_docking_container”, “cl_gui_dialogbox_container” may also be used.
In our example we take a custom container.

To create a custom container instance, we need a custom control area on the screen. Step 1.
Add a custom control on the screen which will be related to the custom container.
Let’s give it the name ‘CC_ALV’.
Step 2
Declare global variables to be used for ALV Grid. Code Part 1 – Global data definitions for ALV
*-- Global data definitions for ALV
*--- ALV Grid instance reference DATA gr_alvgrid TYPE REF TO cl_gui_alv_grid .
*--- Name of the custom control added on the screen DATA gc_custom_control_name TYPE scrfname VALUE ‘CC_ALV’ . *--- Custom container instance reference DATA gr_ccontainer TYPE REF TO cl_gui_custom_container .
*--- Field catalog table DATA gt_fieldcat TYPE lvc_t_fcat .
*--- Layout structure DATA gs_layout TYPE lvc_s_layo .

Step 3
Declare your internal table which is supposed to hold the list data. Let’s name it “gt_list”. Here is an example declaration.
*--- Internal table holding list data DATA BEGIN OF gt_list OCCURS 0 . INCLUDE STRUCTURE SFLIGHT .
*--In further sections, some additional fields will added here
*--for some functionality DATA END OF gt_list .

Code Part 2

Declaration of the internal table that will hold the list data Step 4 �� Somewhere in your program before calling list display, fill your list data as you want.
Here, it is not our concern what the data are. We assume the internal table is filled reasonably.
We will use the data of table SFLIGHT as our list data. Step 5 �� Call the screen which comprises the ALV Grid control.
At PBO of this screen we will deal with creating the ALV Grid instance.

CODE Part 3

PBO of the flow logic for the screen containing ALV Grid control *--PBO PROCESS BEFORE OUTPUT . ... MODULE display_alv . ...

Code Part 4

Inside the module ... MODULE display_alv OUTPUT . PERFORM display_alv . ENDMODULE .
Step 6 �� Now, it is high time we wrote something to play. So, this piece will be the one we will deal mainly. What we do is, checking whether an instance of the container (or ALV Grid) exists.
If it exists, refreshing it, and if not, creating and setting ALV for the first display. FORM display_alv .

he common features of report are column alignment, sorting, filtering, subtotals, totals etc. To implement these, a lot of coding and logic is to be put. To avoid that we can use a concept called ABAP List Viewer (ALV).

Using ALV, we can have three types of reports:

1. Simple Report

2. Block Report

3. Hierarchical Sequential Report

There are some function modules which will enable to produce the above reports without much effort.

All the definitions of internal tables, structures

and constants are declared in a type-pool called SLIS.

Simple Report

The important function modules are:

· Reuse_alv_list_display

· Reuse_alv_fieldcatalog_merge

· Reuse_alv_events_get

· Reuse_alv_commentary_write

· Reuse_alv_grid_display

A. REUSE_ALV_LIST_DISPLAY: This is the function module which prints the data.

The important parameters are:

1. Export:

a. I_callback_program : report id

b. I_callback_pf_status_set : routine where a user can set his own pf status or change the

functionality of the existing pf -status.

c. I_callback_user_command : routine where the function codes are handled.

d. I_structure name : name of the dictionary table

e. Is_Layout : structure to set the layout of the report

f. It_fieldcat : internal table with the list of all fields and their attributes which are to

be printed (this table can be populated automatically by the function

module REUSE_ALV_FIELDCATALOG_MERGE)

g. It_events : internal table with a list of all possible events of ALVand their

corresponding routine names.

2. Tables:

a. t_outtab : internal table with the data to be output

B. REUSE_ALV_FIELDCATALOG_MERGE:

This function module is used to populate a fieldcatalog which is essential to display the data in ALV. If the output data is from a single dictionary table and all the columns are selected, then we need not exclusively create the field catalog. Its enough to mention the table name as a parameter(I_structure_name) in the REUSE_ALV_LIST_DISPLAY. But in other cases we need to create it.

The important parameters are:

1. Export:

a. I_program_name : report id

b. I_internal_tabname : the internal output table

c. I_inclname : include or the report name where all the dynamic forms are handled.

2. Changing

ct_fieldcat : an internal table with the type SLIS_T_FIELDCAT_ALV which is declared in

the type pool SLIS.

C . REUSE_ALV_EVENTS_GET: Returns table of possible events for a a list type

1. Import:

Et_Events : The event table is returned with all possible CALLBACK events for the

specified list type (column ‘NAME’). For events to be processed by the

callback, their ‘FORM’ field must be filled. If the field is initialized, the event

is ignored. The entry can be read from the event table, the field ‘FORM’ filled

and the entry modified using constants from the type pool SLIS.

2. Export:

I_list_type:

0 = simple list

1 = hierarchical-sequential list

2 = simple block list

3 = hierarchical-sequential block list

D. REUSE_ALV_COMMENTARY_WRITE : This is used in the Top-of-page event to print the headings and other comments for the list.

1. It_list_commentary : Internal table with the headings of the type slis_t_listheader.

This internal table has three fields:

Typ : ‘H’ - header, ‘S’ - selection, ‘A’ - action

Key : only when typ is ‘S’.

Info : the text to be printed

E. REUSE_ALV_GRID_DISPLAY: A new function in 4.6 version, to display the results in grid rather than as a list.

Parameters : same as reuse_alv_list_display

HIERARCHICAL REPORTS

A. REUSE_ALV_HIERSEQ_LIST_DISPLAY

1. Export:

a. I_CALLBACK_PROGRAM

b. I_CALLBACK_PF_STATUS_SET

c. I_CALLBACK_USER_COMMAND

d. IS_LAYOUT

e. IT_FIELDCAT

f. IT_EVENTS

g. I_TABNAME_HEADER : Name of the internal table in the program containing the output data of the

highest hierarchy level.

h. I_TABNAME_ITEM : Name of the internal table in the program containing the output data of the

lowest hierarchy level.

i. IS_KEYINFO : This structure contains the header and item table field names which link the two tables

(shared key).

2. Tables

a. T_OUTTAB_HEADER : Header table with data to be output

b. T_OUTTAB_ITEM : Name of the internal table in the program containing the output data of the

lowest hierarchy level.

BLOCK REPORT

This is used to display multiple lists continuously.

The important functions used in this report are:

A. REUSE_ALV_BLOCK_LIST_INIT

B. REUSE_ALV_BLOCK_LIST_APPEND

C. REUSE_ALV_BLOCK_LIST_DISPLAY

D. REUSE_ALV_BLOCK_HS_LIST_APPEND

A. REUSE_ALV_BLOCK_LIST_INIT

Parameters:

a. I_CALLBACK_PROGRAM

b. I_CALLBACK_PF_STATUS_SET

c. I_CALLBACK_USER_COMMAND

This function module is used to set the default GUI status etc.

B. REUSE_ALV_BLOCK_LIST_APPEND

Export :

a. IS_LAYOUT : layout settings for block

b. IT_FIELDCAT : field catalog

c. I_TABNAME : Internal table name of the output data

d. IT_EVENTS : internal table name with all possible events

Tables :

a. T_OUTTAB : internal table with output data.

This function module adds the data to the block.

INTERNAL TABLES IN SLIS

Slis_t_fieldcat_alv :

This internal table contains the field attributes. This internal table can be populated automatically by using ‘REUSE_ALV_FIELDCATALOG_MERGE’.

Important Attributes:

a. col_pos : position of the column

b. fieldname : internal fieldname

c. tabname : internal table name

d. ref_fieldname : fieldname (dictionary)

e. ref_tabname : table (dictionary)

f. key(1) : column with key-color

g. icon(1) : icon

h. hotspot(1) : hotspot

i. Symbol(1) : symbol

j. Checkbox(1) : checkbox

k. just(1) : (R)ight (L)eft (C)ent

l. do_sum(1) : sum up

m. no_out(1) : (O)blig. (X)no out

n. outputlen : output length

o. seltext-l : long key word

p. seltext_m : middle key word

q. seltext_s : short key word

r. reptext_ddic : heading(ddic)

s. ddictxt(1) : (S)hort (M)iddle (L)ong

t. datatype : datatype

SLIS_T_EVENT :

Internal table for storing all the possible events of the ALV. This can be populated by the function module Reuse_alv_events_get

The columns are :

name : name of the event

form : name of the routine

SYNTAXES FOR THE ROUTINES

I_CALLBACK_PF_STATUS_SET

Syntax :

FORM set_pf_status USING rt_extab TYPE slis_t_extab

The table RT_EXTAB contains the function codes which are hidden in the standard interface.

I_CALLBACK_USER_COMMAND

Syntax :

FORM user_command USING r_ucomm LIKE sy-ucomm

rs_selfield TYPE slis_selfield.

The parameter r_ucomm contains the function code.

The structure rs_selfield has the details about the current cursor position