ALV – ABAP List Viewer Programming (Lesson - 11)

The common desired  features of any  report are “column alignment”, sorting, filtering, subtotals, totals etc. To implement these from scratch , a lot of coding effort  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

Each of these reports provide function modules which help in producing desired output without much effort. Lets look at them in detail -

Simple Report

Important function modules in these report are -

• Reuse_alv_fieldcatalog_merge
• Reuse_alv_list_display
• Reuse_alv_events_get
• Reuse_alv_grid_display
• Reuse_alv_commentary_write

REUSE_ALV_FIELDCATALOG_MERGE
This function module is used to populate a field catalog 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.
Note : Fieldcatalog can be filled manually also by filling up all the required details into the internal table
Important parameters in are:
1. Export:

• I_program_name : report id
• I_internal_tabname : the internal output table
• 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.

REUSE_ALV_LIST_DISPLAY
This is the function module which prints the data.
The important parameters are:
1. Export:

• I_callback_program : report id
• I_bypassing_buffer : ‘X’
• I_buffer_active : ‘ ‘
• I_callback_pf_status_set : routine where a user can set his own pf status or change the functionality of the existing pf status.
• I_callback_user_command : routine where the function codes are handled.

• I_structure name : name of the dictionary table
• Is_Layout : structure to set the layout of the report
• 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)
• It_events : internal table with a list of all possible events of ALV and their corresponding form names.

2. Tables:

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

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 REUSE_ALV_LIST_DISPLAY
1 = hierarchical-sequential list  REUSE_ALV_HIERSEQ_LIST_DISPLAY
2 = simple block list REUSE_ALV_BLOCK_LIST_APPEND
3 = hierarchical-sequential block list   REUSE_ALV_BLOCK_LIST_HS_APPEND
REUSE_ALV_GRID_DISPLAY
A new function from ABAP4.6 version, to display the results in grid rather than a preview.
Parameters : same as reuse_alv_list_display

Note:Grid cannot handle high volumes. Functions like sort, scrolling down consumes a lot of resources / time if the volume of data to be displayed is high. There is no clear cut definition such that if the amount of data is X go for list or grid  but the developer has to take a call based on his experience. If not sure, then list is the better option

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

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

This internal table has three fields:

1. Typ : ‘H’ – header, ‘S’ – selection, ‘A’ – action
2. Key : only when typ is ‘S’.
3. Info : the text to be printed

Block Report

This looks like a simple report but this report has the features of sorting and filtering only.This report is used if you have to display more than one report on the output. Technically speaking if you have multiple internal table with data to be displayed as separate blocks then we go for block report of ALV.
The important functions used for creating this report are:

• REUSE_ALV_BLOCK_LIST_INIT
• REUSE_ALV_BLOCK_LIST_APPEND
• REUSE_ALV_BLOCK_LIST_DISPLAY

REUSE_ALV_BLOCK_LIST_INIT
This function module is used to set the default gui status etc. The parameters are similar to the one used in reuse_alv_list_display or reuse_alv_grid_display
REUSE_ALV_BLOCK_LIST_APPEND
This function module adds the data to the block.
Important Parameters
1.Export :

• is_layout : layout settings for block
• it_fieldcat : field catalog
• I_tabname : internal table name with all all possible events

2.Tables :

• t_outtab : internal table with output data.

REUSE_ALV_BLOCK_LIST_DISPLAY
This function module display the list with data appended by the above function.
Parameters : All the parameters are optional.

Hierarchical Reports

Hierarchical display is used for displaying data that are related. Like sales order and item details. Here sales order details can be the header data whereas them items in the sales order can be the item data
The function module used for this is
REUSE_ALV_HIERSEQ_LIST_DISPLAY
Export:

• I_CALLBACK_PROGRAM
• I_CALLBACK_PF_STATUS_SET
• I_CALLBACK_USER_COMMAND
• IS_LAYOUT
• It_fieldcat
• It_events
• I_tabname_header : Name of the internal table in the program containing the output data of the highest hierarchy level.
• I_tabname_item : Name of the internal table in the program containing the output data of the lowest hierarchy level.
• Is_keyinfo : This structure contains the header and item table field names which link the two tables (shared key).

Tables

• t_outtab_header : Header table with data to be output
• t_outtab_item : Name of the internal table in the program containing the output data of the lowest hierarchy level.

All the definitions of internal tables, structures and constants are declared in a type-pool called SLIS. This internal table can be populated automatically by using REUSE_ALV_FIELDCATALOG_MERGE’.

Display Variants

• Display variants are used to set the default properties of an alv output like sort criteria, filtering criteria, totaling and subtotaling etc
• Display variants can be user specific and standard (standard variants can be used by any user )
• Kind of display variants that can be saved is controlled by the parameter i_save that is passed in function modules  reuse_alv_list_display / reuse_alv_grid_display
• You can provide an option on the selection screen to select what display variant to be used

The common function modules related to selecting / validating display variants are

1. Reuse_alv_variant_default_get
2. Reuse_alv_variant_f4
3. Reuse_alv_variant_existence

Thats all to ABAP- ALV programming!

Subscreens (Lesson - 9)

Before you read this tutorial make sure you what a Dialog Program is …

Subscreens

• A subscreen is an independent screen that is displayed in an area of another (“main”) screen.
• Subscreens allow you to embed one screen within another at runtime. You can include multiple sub-screens on main screen.
• The term subscreen applies both to the screen that you embed, and the area on the main screen in which you place it. This tutorial is about subscreen areas. The actual screens created through SE51 transaction, are called subscreen screens if defined in screen attributes.
• When you use a subscreen, the flow logic of the embedded screen is also embedded in the flow logic of the main screen.Hence, Using subscreens on screens is like using includes in ABAP programs.

To use a subscreen, you must follow three simple steps

1. Define the subscreen area(s) on a screen
2. Define suitable subscreen screens
3. Include the subscreen screen in the subscreen area.

Also, you need to adjust the frame of sub-screen and main screen. You need to name it in the field name field.
Further, you also need to adjust the fields within the subscreen to make them appear in main screen. In case the sub-screen is defined to be larger than the available area in the main screen, only the part of subscreen will be visible that fits in the the area available. The area is always measured from the top left corner of screen. Hence you should take adequate care while defining sub-screen areas and creating sub-screens.
EXAMPLE
For instance here we have defined two sub-screen areas on main screen and have attached two different Sub-screen to corresponding areas. Whenever main screen is called, the PBO of main screen is called. But before display, the PBO’s of each screen attached with sub-screen areas on main screen are also called.

You can include a subscreen screen using the CALL SUBSCREEN statement in the flow logic of the main screen.
To include a subscreen screen in the subscreen area of the main screen and call its PBO flow logic, use the following statement in the PBO event of the main screen:

PROCESS BEFORE OUTPUT.
CALL SUBSCREEN <area> INCLUDING [<prog>] <dynp>.

This statement assigns the subscreen screen with number <dynp> to the subscreen area called <area>. You can also specify the program in which the subscreen screen is defined (optional). If you do not specify the program explicitly, the system looks for the subscreen screen in the same ABAP program as the main program. If it does not find a corresponding subscreen screen, a runtime error occurs. The PBO flow logic of the subscreen screen is also included at the same point. This can call PBO modules of the ABAP program in which the subscreen screen is defined. At the end of the subscreen PBO, the global fields from the program are passed to any identically-named screen fields in the subscreen screen. The PBO flow logic of the subscreen screen can itself include further subscreens.
The name <area> of the subscreen area must be entered directly without inverted commas. You can specify the names <prog> and <dynp> either as literals or variables. If you use variables, you must declare and fill identically-named variables in the ABAP program. The screen number <dynp> must be 4 characters long. If you do not assign a subscreen screen to an area, it remains empty.
To call the PAI flow logic of the subscreen screen, use the following statement in the PAI flow logic of the main screen:

PROCESS AFTER INPUT.
CALL SUBSCREEN <area>.

This statement includes the PAI flow logic of the subscreen screen included in the subscreen area <area> in the PBO event. This can call PAI modules of the ABAP program in which the subscreen screen is defined. Data is transported between identically-named fields in the subscreen screen and the ABAP program either when the PAI event is triggered, or at the corresponding FIELD statements in the PAI flow logic of the subscreen screen.
Points to Remember

• Names of elements of sub-screens within a screen should be unique
• You should not have OK_CODE or FCODE attached with sub-screen. The OK_CODE of main screen itself is OK_CODE of sub-screen
• Sub-screens cannot have any dialog modules containing SET TITLEBAR, SET PF-STATUS, SET SCREEN, LEAVE SCREEN or LEAVE TO SCREEN. This will cause runtime error.
• You need to call it in the flow logic (both PBO and PAI) of the main screen.
• CALL SUBSCREEN is not allowed in CHAIN..ENDCHAIN and LOOP ENDLOOP statements
• Can not have an AT EXIT-COMMAND module
• The fields that you use are the global fields. They must be declared in the top include
• If using subscreens from another dialog program the data transfer will not happen unless you add specific code.

Dialog Programming (Lesson - 8)

SAP-ABAP supports two types of programs – Report Program and Dialog Program.
If your ABAP program demands user input , Dialog programming is used.
A  user dialog is any form of interaction between the user and the program and could be any of the following

• Entering data
• Choosing a menu item
• Clicking a button
• Clicking or double clicking an entry

Dialog program is also used when we need to navigate back and forth between screens
Dialog programs are created with type as ‘M’ – Module Pool. They cannot be executed independently and must be attached to at least one transaction code in which you specify an initial screen.

Difference between Report and Dialog Programs

Report Program:
A report is a program that typically reads and analyzes data in database tables without changing the database.
Dialog Program:
A dialog program allows you to work interactively with the system and to change the contents of the database tables. Each dialog program has a certain sequence of screens that are processed by the system one after the other.

A Sample transaction processing in Dialog Programming

Components of Dialog Program

Unlike report which generally entails the creation of one autonomous program which can be executed independently of other objects, dialog program development entails development of multiple objects none of which can be executed on it’s own. Instead all objects are linked hierarchically to the main program and and are executed in a sequence dictated by the Dialog Main Program.
The components of a dialog program are:
Transaction code

• The transaction code starts a screen sequence.
• You create transaction codes in the Repository Browser in the ABAP Workbench or using Transaction SE93.
• A transaction code is linked to an ABAP program and an initial screen.
• You can start a screen sequence from any ABAP program using the CALL SCREEN statement.

Screens

• Each dialog in an SAP system is controlled by one or more screens.
• You create screens using the Screen Painter in the ABAP Workbench through transaction SE51
• Each screen belongs to an ABAP program.
• These screens consist of a “screen mask” or “layout” and its flow logic. The screen has a layout that determines the positions of input/output fields and other graphical elements such as checkboxes and radio buttons. A flow logic determines the logical processing within screen.

GUI status

• Each screen has a GUI status(es) which are independent components of a program.
• This controls the menu bars, standard toolbar, application toolbar , with which the user can choose functions in the application.
• You create them in the ABAP Workbench using the Menu Painter.

ABAP Program

• Each screen and GUI status in the R/3 System belongs to one ABAP program.
• The ABAP program contains the dialog modules that are called by the screen flow logic, and also process the user input from the GUI status.
• ABAP programs that use screens are also known as dialog programs.
• In a module pool (type M program); the first processing block to be called is always a dialog module. However, you can also use screens in other ABAP programs, such as executable programs or function modules. The first processing block is then called differently; for example, by the runtime environment or a procedure call. The screen sequence is then started using the CALL SCREEN statement.

Screen Flow Logic
Screen Flow logic is primarily divided into four components.

• Process Before Output (PBO) event: which is processed before the screen is displayed
• Process After Input (PAI) event: which is processed after a user action on the screen
• Process on help request (POH): which is processed when F1 is pressed
• Process on value request (POV):which is processed when F4 is pressed

Dynpro

• A screen together with its Flow logic  is called a Dynpro (“Dynamic Program” since the screen flow logic influences the program flow)
• Each dynpro controls exactly one step of your Dialog Program.
• The screens belonging to a program are numbered. The  screen flow sequence can be either linear or cyclic. From within a screen chain, you can even call another screen chain and, after processing it, return to the original chain. You can also override the statically-defined next screen from within the dialog modules of the ABAP program.

ABAP Module Pool

• On a PBO or PAI event a Dynpro calls an ABAP dialog program.  Collection of such programs is called the ABAP module pool.
• For example modules called at the PAI event are used to check the user input and to trigger appropriate dialog steps, such as the update task.
• All dynpros to be called from within one transaction refer to a common module pool.

Structure of a Dialog Program

Process Flow for a Dialog Program

Report Programming (Lesson -7)

SAP-ABAP supports two types of Programs -  Report Programs & Dialog Programs. Report Programs are used when large amounts of data needs to be displayed
Purpose/Use of Report Programs

• They are used  when data from a number of tables have to be selected and processed before presenting
• Used when reports demand  a special format
• Used when the report has to be downloaded from SAP to an Excel sheet to be distributed across.
• Used when the report has to be mailed to a particular person.

Important Points to Note About Report Program

• Report Programs are always Executable Programs. Program Type is always 1.
• Every Report program corresponds to a particular Application Type i.e. either with Sales & Distribution, FI – CO etc. It can also be Cross Application i.e. type ‘*’.
• Report Programming is an Event-driven programming.

• The first line of a report program is always Report <report-name>.
• In order to suppress the list heading or the name of the program the addition No Standard Page Heading is used.
• The line size for a particular report can be set by using the addition line-size <size>.
• The line count for a particular page can be set by using the addition line-count n(n1). N is the number of lines for the page and N1 is the number of lines reserved for the page footer.
• To display any information or error message we add a message class to the program using the addition: Message-id <message class name>. Message classes are maintained in SE91.

Therefore an ideal report program should start with:

Report <report name> no standard page heading
line-size <size>
line-count <n(n1)>
message-id <message class>.

Selection Screen

“Selection screen”  is the screen where one specifies the input values for which the program should run.
The selection screen is normally generated from the

1. Parameters
2. Select-Options

Syntax

Selection-screen begin of screen <screen #>
selection-screen begin of block <#>  with frame title <text>
………
………
selection-screen end of block <#>
selection-screen end of screen <screen #>

Parameters
Parameters helps one to do dynamic selection. They can accommodate only one value for one cycle of execution of the program.
Syntax
Defining parameters as a data type

Parameters p_id(30) type c.

Defining parameters like a table field.

Parameter p_id like <table name>-<field name>.

Parameters can be Checkboxes as well as Radiobuttons.

Parameters p_id as checkbox.
Parameters p_id1 radiobutton group <group name>.
Parameters p_id2  radiobutton group <group name>.

Parameters can be listbox.

Parameter p_id like <table name>-<field name> as listbox

Select Options
A Select-Option is used to input a range of values or a set of values to a program
Syntax

select-options s_vbeln for vbak-vbeln.

You can also define a select option like a variable

select-options s_vbeln for vbak-vbeln no intervals no-extension

Events in an ABAP Report Program

ABAP report programs are event driven programs. The different events in a report Program are:
Load-of-program

• Triggers the associated event in an internal session after loading a program of type 1, M, F, or S.
• Also runs the associated processing block once and once only for each program and internal session.
• The processing block LOAD-OF-PROGRAM has roughly the same function for an ABAP program of type 1, M, F or S as a constructor has for classes in ABAP Objects

Initialization.

• This event is executed before the selection screen is displayed .
• Initialization of all the values.
• You can assign different values other than the values defaulted on the selection screen .
• You can fill your selection screen with some values at runtime.

At Selection-Screen.

• The event is processed when the selection screen has been processed (at the end of PAI ).
• Validation & Checks of inputted values happen here

Start-of-Selection.

• Here the program starts selecting values from tables.

End-of-selection.

• After all the data has been selected this event writes the data to the screen.

Interactive Events

• Used for interactive reporting. It is used to create a detailed list from a basic list.

Formatting the report

ABAP allows the reports to be formatted as the user wants it to be. For example, “Alternate Lines” must appear in different colors and the “Totals” line should appear in Yellow.
Syntax

Format Color n
Format Color n Intensified On

n may correspond to various numbers
Please note that there are other additions along with format as well

FORMAT COLOR OFF INTENSIFIED OFF INVERSE OFF HOTSPOT OFF INPUT OFF

Interactive Programming

• Using Interactive Programming users  can actively control the data retrieval and display of data
• Used to  create a detailed list from a very basic list
• The detailed data is written on a secondary list.
• The secondary list may either completely overlay the first screen or one can display it in a new screen
• The secondary lists can be themselves interactive.
• The first list may also call a transaction.
• There are different events associated with interactive programming.

Some commands used for interactive programming
Hotspot
If one drags the mouse over the data displayed in the repor the cursor changes to a Hand with an Outstretched Index finger. An hotspot can be achieved using the FORMAT statement.

Syntax: Format Hotspot On (Off).

Hide
This command helps you to store the field names based on which one will be doing further processing to get a detailed list. It is written directly after the WRITE statement for a field. When a row is selected the values get automatically filled in the variables for further use.

Syntax: Hide <field-name>.

Logical Databases

• Instead of using “Select” queries you can use logical database to retrieve data for a program.
• Logical databases are created by transaction SE36
• The name of a logical database can be up to 20 characters long. It may begin with a namespace prefix.
• The data is selected by another program and one can access the data using GET <table-name> command which places the data in the work area <table-name>.

Advantages of a logical database over normal Select queries.

1. It offers check conditions to see whether the input is correct, complete and plausible
2. It contains central authorization checks for database access
3. Enhancements such as improvement in performance immediately apply to all reports which use logical database.

Note: Due to the complexities involved, logical databases are not used in most of the cases