Post on 14-Feb-2016
description
ABAP Report ProgrammingSAP-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 Headingis 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:
1 Report <report name> no standard page heading
2
3
4
5
6
7
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. Parameters2. Select-Options
Syntax
1
2
3
4
5
6
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
1 Parameters p_id(30) type c.
Defining parameters like a table field.
1 Parameter p_id like <table name>-<field name>.
Parameters can be Checkboxes as well as Radiobuttons.
1
2
Parameters p_id as checkbox.Parameters p_id1 radiobutton group <group name>.
Parameters p_id2 radiobutton group <group name>.
Parameters can be listbox.
1 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
1 select-options s_vbeln for vbak-vbeln.
You can also define a select option like a variable
Events in an ABAP Report ProgramABAP 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 hereStart-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 reportABAP 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
123
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
1 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 programmingHotspotIf 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.
1 Syntax: Format Hotspot On (Off).
HideThis 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.
1 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
Dialog ProgrammingSAP-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 entryDialog 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 ProgramUnlike 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
SubscreensSubscreens 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 screen2. 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:
12345
PROCESS BEFORE OUTPUT. CALL SUBSCREEN <area> <span style="list-style: none; float: none; cursor: pointer !important; color: rgb(0, 153, 0) !important; position: relative !important; font-size: inherit !important; vertical-align: inherit !important; display: inline !important; text-align: left !important; margin: 0px !important; border-style: none none solid !important; border-color: initial !important; border-bottom-width: 1px !important; padding: 0px 0px 0.065em !important; text-decoration: underline !important; line-height: 20px;" class="intexthighlight" phasehl="km:en" id="JtIdp" title="">INCLUDING</span> [<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:
12345
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.
Process On Value and Process On Help- Screen Flow logic and their uses in SAP
Process on Help-Request (POH) : F1 Help Whenever F1 is pressed the POH event for the specified data
element is executed. If the PROCESS ON HELP-REQUEST event does not exist in the
process logic of a screen, the documentation of the field in the ABAP Dictionary is taken as a basis and displayed. Even if that does not exit no help is displayed.
To display field help documentation, you must code the following screen flow logic in the POH event:
12
PROCESS ON HELP-REQUESTFIELD <f> [MODULE <mod>] WITH <num>
If there is screen-specific data element documentation for the field <f>, you can display it by specifying its number <num>.
The number <num> can be a literal or a variable. The variable must be declared and filled in the corresponding ABAP program.
Note, the FIELD statement does not transfer the contents of the screen field <f> to the ABAP program in the PROCESS ON HELP-REQUEST event. It just shows help documentation. That's it.
The module <mod> is defined in the ABAP program like a normal PAI module. The processing logic of the module must ensure that adequate help is displayed for the field in question. Instead of calling an extra screen with text fields, you should use one of the following function modules to display a suitable SAPscript documentHELP_OBJECT_SHOW_FOR_FIELD
This function module displays the data element documentation for components of any structure or database table from the ABAP Dictionary.
You pass the name of the component and structure or table to the import parameters FIELD and TABLE.
HELP_OBJECT_SHOW
Use this function module to display any SAPscript document. You must pass the document class (for example, TX for general
texts, DE for data element documentation) and the name of the document to the import parameters DOKCLASS and DOKNAME.
For technical reasons, you must also pass an empty internal table with the line type TLINE to the tables parameter of the function module.
Process on Value (POV): F4 When the user chooses the function Possible entries (F4), the
system displays the possible input values for a field (values, check table, matchcode), provided they were stored by the developer.
The event PROCESS ON VALUE-REQUEST is always processed if the user has called "Possible entries".
To define Possible values for a field on screen, you need to defined following in POV event of screen flow logic:
123
PROCESS ON VALUE-REQUEST FIELD <em>field name</em> MODULE <em>module name</em>
For Possible values, within module defined above, you should use the general function moduleHELP_VALUES_GET_WITH_TABLE to get possible values from ABAP Dictionary.
There are some other functions that can also be used for input help :
F4IF_FIELD_VALUE_REQUEST
Calls the input help of the ABAP Dictionary dynamically. You can pass the component names of a structure or
database table of the ABAP Dictionary to the function module in the import parameters TABNAME and FIELDNAME.
The function module starts the ABAP Dictionary input help for this component.All of the relevant screen fields are read.
If you specify the import parameters DYNPPROG, DYNPNR, and DYNPROFIELD, the user's selection is returned to the corresponding field on the screen.
If you specify the table parameter RETURN_TAB, the selection is returned into the table instead.
1234567891011121314151617
MODULE VALUE_CARRIER INPUT. CALL FUNCTION 'F4IF_FIELD_VALUE_REQUEST' EXPORTING TABNAME = 'DEMOF4HELP' FIELDNAME = 'CARRIER1' DYNPPROG = PROGNAME DYNPNR = DYNNUM DYNPROFIELD= 'CARRIER'. ENDMODULE.
F4IF_INT_TABLE_VALUE_REQUEST This function module displays a value list that you created in
an ABAP program. The value list is passed to the function module as
the table parameter VALUE_TAB. If you specify the import parameters DYNPPROG, DYNPNR, and
DYNPROFIELD, the user's selection is returned to the corresponding field on the screen.
If you specify the table parameter RETURN_TAB, the selection is returned into the table instead.
123456789
CALL FUNCTION 'F4IF_INT_TABLE_VALUE_REQUEST'EXPORTING<p>RETFIELD = 'CONNID'DYNPPROG = PROGNAMEDYNPNR = DYNNUMDYNPROFIELD = 'CONNECTION'VALUE_ORG = 'S'TABLESVALUE_TAB = VALUES_TAB.</p>
ALV - ABAP List Viewer ProgrammingThe 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 Report2. Block Report
3. Hierarchical Sequential Report
Each of these reports provide function modules which help in producing desired output without much effort. Let’s look at them in detail -
Simple ReportImportant 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_writeREUSE_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' - action2. Key : only when typ is 'S'.
3. Info : the text to be printed
Block ReportThis 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_DISPLAYREUSE_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 events2.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 ReportsHierarchical 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_get2. Reuse_alv_variant_f4
3. Reuse_alv_variant_existence