1. Calling Programs
If permitted by the package concept, each processing block of ABAP program makes it possible to call◈ executable programs
◈ and transactions, that is, programs associated with a transaction code.
When a program is called, the calling program can be exited either temporarily or completely.
When the calling program is completely exited (right side of the figure), the called program is started in a new internal session, which replaces the internal session of the calling program.
A program that creates an internal session when it is called represents the main program of the main program group in the internal session.
Note: When the runtime environment loads a called program, the event LOAD-OF-PROGRAM is triggered in that program.
1.1 Calling Executable Programs
Executable programs are only directly executable from the end user's perspective. Whenever an executable program is started using System → Services → Reporting or a report transaction, the statement SUBMIT is executed internally. Executable programs are the only programs that can be called using SUBMIT.
◈ Flow of an Executable Program
◈ The Statement SUBMIT
Note: When the SUBMIT statement is executed, it is followed by an authorization check (using the authorization object S_PROGRAM) for the authorization group specified in the program attributes.
1.1.1 Flow of an Executable Program
The statement SUBMIT loads the called program in a separate internal session and starts a series of processes in the ABAP runtime environment that raise events and actions in the called program in the following order:
1. Program constructor event LOAD-OF-PROGRAM
2. The start values defined using the addition DEFAULT in the statements PARAMETERS and SELECT-OPTIONS are passed to the relevant data objects. The start values of all other data objects are set before LOAD-OF-PROGRAM.
3. Reporting event INITIALIZATION
4. The selection screen specified in selscreen_options is called if it contains at least one input field or button. If no explicit selection screen is specified, the standard selection screen is called. Complete selection screen processing is performed. After the selection screen processing, the program flow is either continued or ended, depending on the last user action on the selection screen. Before the first event of the selection screen processing, AT SELECTION-SCREEN OUTPUT, the values specified in selscreen_options are passed.
5. Reporting event START-OF-SELECTION
6. Different GET events, if the called program is associated with a logical database.
7. Reporting event END-OF-SELECTION
8. The basic list is called.
If the basic list is empty, the program is exited..
If the basic list is a spool list, it is sent to the SAP spool system and the program is exited.
If EXPORTING LIST TO MEMORY is specified in list_options, the basic list is stored in the ABAP Memory and the program is exited.
Otherwise, the basic list is a screen list and is displayed on the screen. User actions on a displayed screen list raise list events. The program is exited when the user exits the list display.
9. If no selection screen is displayed in step 4, because processing is performed in the background or not at all, the program flow is complete.
If a selection screen is displayed in step 4, the runtime environment calls the called program again after exiting the basic list. This loads the program again and the associated actions and events are performed again, starting with LOAD-OF-PROGRAM. During this new call, the runtime environment supplies the parameters, the selection criteria, and the dynamic selections of the selection screen between the events INITIALIZATION and AT SELECTION-SCREEN OUTPUT with the previous input values (other settings, such as whether the tabstrip page was active, are not passed). The program call is not complete until the user exits the selection screen processing by choosing Back, Exit, or Cancel.
The called program can be exited in any of these steps by using the statement LEAVE PROGRAM and during list processing by using LEAVE LIST-PROCESSING.
1.2.1 SUBMIT
Syntax
SUBMIT {rep|(name)} [selscreen_options]
[list_options]
[job_options]
[AND RETURN].
Addition:
... AND RETURN
Effect
The statement SUBMIT calls an executable program. The executable program is executed as described under Flow of an Executable Program. If the called program contains a syntax error, a non-handleable exception is raised. The name of the called program can be specified as follows:
◈ rep
Specified directly and statically as rep.
◈ (name)
Specified as the content of a parenthesized flat character-like data object name. The data object name must contain the name of the program to be accessed in uppercase letters. The following can be specified for name:
◈ Literal or constants
If the data object name is specified as a text field literal or as a constant, it can be evaluated statically and the called program is identified as the used object.
◈ Variable
If the data object name is specified as a variable, it is specified only dynamically and the content is not evaluated statically.
When the statement is executed, name is not evaluated until runtime (in both cases). If the program specified in name is not found, a non-handleable exception is raised.
The additions have the following meaning:
◈ The additions selscreen_options can be used to determine the selection screen for the program accessed and to supply it with values.
◈ The additions list_options allow the output medium and the page size to be specified in the basic list for the called program.
◈ The program can be scheduled for background processing by specifying job_options.
◈ The addition AND RETURN determines the internal session and the behavior with respect to SAP LUWs.
When the statement SUBMIT is executed, it is followed by an authorization check (using the authorization object S_PROGRAM) for the authorization group specified in the program attributes. The program attribute Start Using Variant is ignored if SUBMIT is used.
Security Note
If the name of a program unit is specified dynamically when it is called, and this name is passed to a program from outside, the result is a serious security risk. Any names passed to a program from outside must be checked thoroughly before being used in calls. The system class CL_ABAP_DYN_PRG, for example, can be used to do this. See Dynamic Calls.
Addition
... AND RETURN
Effect
The addition AND RETURN determines the object accessed by the runtime environment after the program has been called:
◈ Without the addition AND RETURN, the internal session of the program accessed replaces the internal session of the calling program in the same position in the call sequence, with the current SAP LUW being exited. Once program access is completed, the system returns to before the position from which the calling program was started. The content of the system field sy-calld at SUBMIT is copied by the calling program without AND RETURN.
◈ The addition AND RETURN starts the executable program in a new internal session of the current call sequence. The session of the calling program and the current SAP LUW are preserved. The called program runs in its own SAP LUW. Once program access is completed, program execution is continued after the statement SUBMIT.
The number of internal session in a call sequence is restricted to nine. If this is exceeded by SUBMIT ... AND RETURN, the program terminates and the entire call sequence is deleted.
Notes
◈ SUBMIT does not end the current database LUW (the addition AND RETURN is irrelevant here). A database commit or database rollback in the called program works in exactly the same way as in the current program.
◈ The statement SUBMIT with the addition AND RETURN opens a new SAP-LUW, but it does not open a new database LUW. This means that a database rollback in this SAP LUW can roll back all registration entries made by the statements CALL FUNCTION IN UPDATE TASK or CALL FUNCTION IN BACKGROUND TASK in the tables VB... or ARFCSSTATE and ARFCSDATA. Under certain circumstances, the statement ROLLBACK WORK in the called program can also affect the interrupted SAP LUW. To prevent this, an explicit database commit must be executed before the program is called. This problem does not occur in local updates.
◈ If there are still procedures registered in the current SAP LUW in a SUBMIT, without AND RETURN, the SAP LUW exits without calling or rolling back the procedures. Registered update function modules can no longer be executed. In a case like this, therefore, it is advisable to execute the statement COMMIT WORK or ROLLBACK WORK explicitly before the program call.
Exceptions
Non-Handleable Exceptions
◈ Cause: The specified program was not found.
Runtime Error: LOAD_PROGRAM_NOT_FOUND
◈ Cause: An attempt was made to pass an invalid value to a selection using the addition SIGN.
Runtime Error: SUBMIT_WRONG_SIGN
◈ Cause: The specified program is not a report.
Runtime Error: SUBMIT_WRONG_TYPE
◈ Cause: An attempt was made to pass more than one value to a report parameter.
Runtime Error: SUBMIT_IMPORT_ONLY_PARAMETER
◈ Cause: An attempt was made to use WITH sel IN itab to pass a table that does not have the appropriate structure to a selection.
Runtime Error: SUBMIT_IN_ITAB_ILL_STRUCTURE
◈ Cause: An attempt was made to pass a parameter that cannot be converted to the target field to the selection screen.
Runtime Error: SUBMIT_PARAM_NOT_CONVERTIBLE
◈ Cause: The called program contains a syntax error.
Runtime Error: SYNTAX_ERROR
◈ SUBMIT - selscreen_options
Syntax
... [USING SELECTION-SCREEN dynnr]
[VIA SELECTION-SCREEN]
[selscreen_parameters] ...
Additions
1. ... USING SELECTION-SCREEN dynnr
2. ... VIA SELECTION-SCREEN
Effect
The addition USING SELECTION-SCREEN specifies the selection screen, VIA SELECTION-SCREEN specifies whether it is displayed. The additions selscreen_parameters provide values for the parameters, selection criteria, and the free selection of the called selection screen.
The values are passed to the selection screen between the events INITIALIZATION and AT SELECTION SCREEN OUTPUT. The following hierarchy applies to the passing of the values:
1. First, the variant of the addition USING SELECTION-SET is passed, which sets all parameters and selection criteria to the values of the variant. The values previously set in the called program are overwritten.
2. The values of the table of the addition WITH SELECTION-TABLE are then passed. All parameters and selection criteria are overwritten accordingly.
3. Finally, the values of the additions WITH sel value are passed. All parameters and selection criteria are overwritten accordingly. If the addition WITH sel value is used more than once for the same parameter, this is overwritten with the last specified value. If the addition WITH sel value is used more than once for the same selection criterion, a selection table with the corresponding number of rows is passed.
Providing values for free selections is independent of this hierarchy.
Notes
◈ The options for parameter passing enable a selection screen to be viewed as a parameter interface of an executable program. This applies particularly for background selection screen processing and for parameters and selection criteria that are defined without screen elements using the addition NO-DISPLAY
◈ When passing data, note that any adjustments made to the screen format, such as abbreviations or the execution of conversion routines, are not executed for fields for which there are no screen elements on the selection screen. This applies for all parameters and selection criteria defined with NO DISPLAY. It also applies for all lines of a selection table with the exception of the first line.
◈ The additions selscreen_parameters only work the first time the called program is executed. If a selection screen is displayed in the called program, the runtime environment calls the program again after it is finished, thereby replacing the values specified in selscreen_parameters with the previous input values.
Addition 1
... USING SELECTION-SCREEN dynnr
Effect
This addition defines which selection screen is called. dynnr is a data object that must contain the dynpro number of a selection screen defined in the called program when the statement SUBMIT is executed.
◈ If the addition USING SELECTION-SCREEN is omitted or the dynpro number 1000 is entered, the standard selection screen is called. If no standard selection screen is defined in the called program, no selection screen is called.
◈ If a dynpro number that is not 1000 is entered in the addition USING SELECTION-SCREEN, the corresponding standalone selection screen is called. If no selection screen with this dynpro number is defined in the called program, a non-handleable exception is raised.
Addition 2
... VIA SELECTION-SCREEN
Effect
If this addition is specified, the selection screen is displayed on the screen. Otherwise, background selection screen processing takes place. In background selection screen processing, the selection screen events are triggered without the selection screen being displayed.
SUBMIT - selscreen_parameters
Syntax
... [USING SELECTION-SET variant]
[USING SELECTION-SETS OF PROGRAM prog]
[WITH SELECTION-TABLE rspar]
[WITH expr_syntax1 WITH expr_syntax2 ...]
[WITH FREE SELECTIONS texpr] ...
Additions
1. ... USING SELECTION-SET variant
2. ... USING SELECTION-SETS OF PROGRAM prog
3. ... WITH SELECTION-TABLE rspar
4. ... WITH expr_syntax1 WITH expr_syntax2 ...
5. ... WITH FREE SELECTIONS texpr
Effect
USING SELECTION-SET supplies all the selection screen components using a variant variant. If USING SELECTION-SETS OF PROGRAM is specified, a variant of a different program can be used; if WITH SELECTION-TABLE is specified, values for multiple selection screen components are passed as the content of an internal table rspar; WITH expr_syntax supplies individual selection screen components with values. The addition WITH FREE SELECTIONS makes it possible to pass dynamic selections to the selection screen of a logical database.
Addition 1
... USING SELECTION-SET variant
Effect
If this addition is specified, the parameters and selection criteria for the selection screen are supplied with values from a variant. variant expects a character-like data object that contains the name of a variant for the program called when the statement is executed. If the variant does not exist, the system sends an error message. If the variant belongs to a different selection screen, it is ignored.
Note
Variants for every program in which selection screens are defined can be created and managed either in ABAP Workbench or when the program is executed by choosing Goto - Variants on a selection screen.
Addition 2
... USING SELECTION-SETS OF PROGRAM prog
Effect
If this addition is specified, the variants of the program prog are used in the program called. prog expects a character-like data object that contains the name of a program when the statement is executed. The addition has the following effect:
If a variant variant is specified with USING SELECTION-SET, the system searches for this variant in the program prog.
If the selection screen is displayed using VIA SELECTION-SCREEN, all the functions that can be accessed by means of the menu path Goto - Variants affect the variants of the program prog. However, these functions are only active if prog is an executable program.
Note
The program prog should contain a selection screen that has the same parameters and selection criteria as the selection screen used in the program called.
Addition 3
... WITH SELECTION-TABLE rspar
Effect
If this addition is specified, parameters and selection criteria on the selection screen are supplied from an internal table rspar. rspar expects a standard table with row type RSPARAMS or RSPARAMSL_255 and without secondary table keys for . The structured data types RSPARAMS and RSPARAMSL_255 are defined in ABAP Dictionary and have the following components, all of which are data type CHAR:
◈ SELNAME (length 8),
◈ KIND (length 1),
◈ SIGN (length 1),
◈ OPTION (length 2),
◈ LOW (length 45 for RSPARAMS and 255 for RSPARAMSL_255).
◈ HIGH (length 45 for RSPARAMS and 255 for RSPARAMSL_255)
To supply parameters and selection criteria for the selection screen with specific values, the rows in the internal table rspar must contain the following values:
◈ SELNAME must contain the name of a parameter or selection criterion for the selection screen in block capitals
◈ KIND must contain the type of selection screen component ("P" for parameters, "S" for selection criteria)
SIGN, OPTION, LOW, and HIGH must contain the values specified for the selection table columns that have the same names as the selection criteria; in the case of parameters, the value must be specified in LOW and all other components are ignored.
If the name of a selection criterion is repeated in rspar, this defines a selection table containing multiple rows and passes it to the selection criterion. If parameter names occur multiple times, the last value is passed to the parameter.
The contents of the parameters or selection tables for the current program can be entered in the table by the function module RS_REFRESH_FROM_SELECTOPTIONS.
Notes
◈ In contrast to selection tables, the data types of the components LOW and HIGH in table rspar are always of type CHAR and are converted to the type of the parameter or selection criterion when passed, if necessary.
◈ The values specified must have the internal format of the ABAP values, and not the output format of the screen display.
◈ The data type RSPARAMSL_255 can be used from Release 7.2 instead of RSPARAMS, if the length of 45 characters for components LOW and HIGH is no longer sufficient.
Addition 4
... WITH expr_syntax1 WITH expr_syntax2 ...
Effect
This addition supplies values to individual parameters or selection criteria for the selection screen. Parameters are supplied with single values and selection criteria with selection tables that overwrite values already specified in the program called. The selection table to be passed is compiled from all the additions expr_syntax that address the same selection criterion sel. The following statements can be specified for expr_syntax, where the name of a parameter or a selection criterion must be specified directly for sel:
◈ sel {EQ|NE|CP|NP|GT|GE|LT|LE} dobj [SIGN sign]
Passing a single value.
The operators before dobj correspond to the values specified for column OPTION for selection tables. dobj expects a data object whose data type can be converted to the data type of the selection screen component sel. A character-like field containing 'I' or 'E' can be specified for sign. The default value is 'I'.
If sel is a selection criterion, the system appends a row in the selection table to be passed, placing the operator in column OPTION, the content of dobj in column LOW, and the content of sign in column SIGN.
If sel is a parameter, it is set to the value of dobj in the program called. The operator and the value of sign are ignored.
◈ sel [NOT] BETWEEN dobj1 AND dobj2 [SIGN sign]
Passing an interval.
In this case, sel must be a selection criterion. dobj expects data objects whose data type can be converted to that of the columns LOW and HIGH for the selection criterion sel. A character-like field containing 'I' or 'E' can be specified for sign. The default value is 'I'.
A row is appended in the selection table to be passed. If NOT is specified, the value 'NB' is placed in column OPTION; otherwise, the value entered is 'BT'. The content of the data objects dobj and sign is placed in the columns LOW, HIGH, and SIGN.
◈ sel IN rtab
Passing a ranges table.
In this case, sel must be a selection criterion. rtab expects a standard table without secondary table keys that has the same structure as the selection table for selection criterion sel. A table of this type can be created using the addition RANGE OF of the statements TYPES and DATA.
The rows in table rtab are appended to the selection table to be passed.
The addition expr_syntax can be specified more than once, and the same selection screen component can also be specified more than once.
Notes
◈ = or INCL can also be used instead of the operator EQ.
◈ The values specified must have the internal format of the ABAP values, and not the output format of the screen display.
Example
The program report1 has a standalone selection screen with the dynpro number 1100. In the program report2, an internal table with row type RSPARAMS and a ranges table are filled for this selection screen. These are passed at SUBMIT time, together with a single condition.
Program called
REPORT report1.
DATA text TYPE c LENGTH 10.
SELECTION-SCREEN BEGIN OF SCREEN 1100.
SELECT-OPTIONS: selcrit1 FOR text,
selcrit2 FOR text.
SELECTION-SCREEN END OF SCREEN 1100.
...
Calling program
REPORT report2.
DATA: text TYPE c LENGTH 10,
rspar_tab TYPE TABLE OF rsparams,
rspar_line LIKE LINE OF rspar_tab,
range_tab LIKE RANGE OF text,
range_line LIKE LINE OF range_tab.
...
rspar_line-selname = 'SELCRIT1'.
rspar_line-kind = 'S'.
rspar_line-sign = 'I'.
rspar_line-option = 'EQ'.
rspar_line-low = 'ABAP'.
APPEND rspar_line TO rspar_tab.
range_line-sign = 'E'.
range_line-option = 'EQ'.
range_line-low = 'H'.
APPEND range_line TO range_tab.
range_line-sign = 'E'.
range_line-option = 'EQ'.
range_line-low = 'K'.
APPEND range_line TO range_tab.
SUBMIT report1 USING SELECTION-SCREEN '1100'
WITH SELECTION-TABLE rspar_tab
WITH selcrit2 BETWEEN 'H' AND 'K'
WITH selcrit2 IN range_tab
AND RETURN.
Result
After report1 has been accessed by report2, the selection tables for the selection criteria selcrit1 and selcrit2 in the program called contain the following entries:
| SIGN | OPTION | LOW | HIGH | |
| selcrit1 | I | EQ | ABAP | |
| selcrit2 | I | BT | H | K |
| selcrit2 | E | EQ | H | |
| selcrit2 | E | EQ | K |
Addition 5
... WITH FREE SELECTIONS texpr
Effect
This addition supplies values to the dynamic selections for the selection screen for a logical database. The program called must be associated with a logical database that supports dynamic selections. texpr must be an internal table of the type RSDS_TEXPR from type group RSDS.
In texpr, the selections for the dynamic selections are specified in an internal format (Reverse Polish Notation). The function modules FREE_SELECTIONS_INIT, FREE_SELECTIONS_DIALOG, and FREE_SELECTIONS_RANGE_2_EX from the function group SSEL can be used to fill texpr in the calling program. Whereas the first two function modules execute a user dialog, the ranges tables can be passed to FREE_SELECTIONS_RANGE_2_EX for each node in the dynamic selection in an internal table of the type RSDS_TRANGE. These are then converted to a table of the row type RSDS_TEXPR. If the calling program contains a selection screen with the same dynamic selections, its content can be passed beforehand to a table of the type RSDS_TRANGE using the function module RS_REFRESH_FROM_DYNAMICAL_SEL.
The rows in the internal table type RSDS_TRANGE contain a flat component TABLENAME for each node and a table-like component FRANGE_T of the type RSDS_FRANGE_T for the fields in the node. The rows in RSDS_FRANGE_T contain a flat component FIELDNAME for each field and a table-like component SELOPT_T of the row type RSDSSELOPT from ABAP Dictionary. RSDSSELOPT contains the four components SIGN, OPTION, LOW, and HIGH and can include the ranges table.
Example
Program report1 is associated with the logical database F1S, which supports dynamic selections for the node SPFLI. The program report2 enters conditions in a nested internal table of the type rsds_trange with selection conditions for field CONNID in node SPFLI; this is then converted to a table of the type rsds_texpr, which is passed at SUBMIT time.
Program called
REPORT report1.
NODES: spfli, sflight, sbook.
...
Calling program
REPORT report2.
DATA: trange TYPE rsds_trange,
trange_line
LIKE LINE OF trange,
trange_frange_t_line
LIKE LINE OF trange_line-frange_t,
trange_frange_t_selopt_t_line
LIKE LINE OF trange_frange_t_line-selopt_t,
texpr TYPE rsds_texpr.
trange_line-tablename = 'SPFLI'.
trange_frange_t_line-fieldname = 'CONNID'.
trange_frange_t_selopt_t_line-sign = 'I'.
trange_frange_t_selopt_t_line-option = 'BT'.
trange_frange_t_selopt_t_line-low = '0200'.
trange_frange_t_selopt_t_line-high = '0800'.
APPEND trange_frange_t_selopt_t_line
TO trange_frange_t_line-selopt_t.
trange_frange_t_selopt_t_line-sign = 'I'.
trange_frange_t_selopt_t_line-option = 'NE'.
trange_frange_t_selopt_t_line-low = '0400'.
APPEND trange_frange_t_selopt_t_line
TO trange_frange_t_line-selopt_t.
APPEND trange_frange_t_line TO trange_line-frange_t.
APPEND trange_line TO trange.
CALL FUNCTION 'FREE_SELECTIONS_RANGE_2_EX'
EXPORTING
field_ranges = trange
IMPORTING
expressions = texpr.
SUBMIT report1 VIA SELECTION-SCREEN
WITH FREE SELECTIONS texpr.
Program Calls, Filling the Selection Screen
The example shows how to fill the standard selection screen when a program is called.
Source Code
REPORT demo_program_submit_sel_screen.
SELECTION-SCREEN BEGIN OF SCREEN 1100.
PARAMETERS: rsparams RADIOBUTTON GROUP grp1,
withexpr RADIOBUTTON GROUP grp1.
SELECTION-SCREEN END OF SCREEN 1100.
CLASS demo DEFINITION.
PUBLIC SECTION.
CLASS-METHODS main.
ENDCLASS.
CLASS demo IMPLEMENTATION.
METHOD main.
DATA: seltab TYPE RANGE OF i,
rspar TYPE TABLE OF rsparams.
CALL SELECTION-SCREEN 1100 STARTING AT 10 10.
IF sy-subrc <> 0.
RETURN.
ENDIF.
IF rsparams = 'X'.
rspar = VALUE #(
( selname = 'SELECTO'
kind = 'S'
sign = 'E'
option = 'BT'
low = 14
high = 17 )
( selname = 'PARAMET'
kind = 'P'
low = 'RSPARAMS' )
( selname = 'SELECTO'
kind = 'S'
sign = 'I'
option = 'GT'
low = 10 ) ).
SUBMIT demo_program_submit_rep
VIA SELECTION-SCREEN
WITH SELECTION-TABLE rspar
AND RETURN.
ELSEIF withexpr = 'X'.
seltab = VALUE #(
( sign = 'I'
option = 'BT'
low = 1
high = 5 ) ).
SUBMIT demo_program_submit_rep
VIA SELECTION-SCREEN
WITH paramet EQ 'WITH EXPR'
WITH selecto IN seltab
WITH selecto NE 3
AND RETURN.
ENDIF.
ENDMETHOD.
ENDCLASS.
START-OF-SELECTION.
demo=>main( ).
Description
When the program is executed, the system displays a prompt and depending on the selection made there fills the standard selection screen of the program called either using a table of the type RSPARAMS or using multiple WITH additions.
In both calls of demo_program_submit_rep, the system passes values leading to two-row selection tables selecto. The second row is displayed in the dialog box Multiple Selection for selecto. Without the addition VIA SELECTION-SCREEN of the statement SUBMIT, the system would equally fill but not display paramet and selecto in demo_program_submit_rep.
◈ SUBMIT - list_options
Syntax
... [LINE-SIZE width]
[LINE-COUNT page_lines]
{ [EXPORTING LIST TO MEMORY]
| [TO SAP-SPOOL spool_options] } ...
Additions
1. ... LINE-SIZE width
2. ... LINE-COUNT page_lines
3. ... EXPORTING LIST TO MEMORY
4. ... TO SAP-SPOOL spool_options
Effect
These additions modify the basic list in the called program. While LINE-SIZE and LINE-COUNT modify the formatting, the other two additions determine the output type of the list.
EXPORTING LIST TO MEMORY saves the list to the ABAP Memory and TO SAP-SPOOL sends it as a spool list to the SAP spool system. If these additions are not specified, the basic list is displayed as a screen list.
Note
The additions only take effect the first time the called program is executed. If a selection screen is displayed in the called program, the runtime environment accesses the program again after it ends, and ignores the additions list_options. This is particularly important to the addition TO SAP-SPOOL, because the basic list is displayed as a screen list and not as a spool list when the program is accessed again. For this reason, it is advisable not to use the addition VIA SELECTION-SCREEN when using list_options.
Addition 1
... LINE-SIZE width
Addition 2
... LINE-COUNT page_lines
Effect
These additions define the line width and page length of the basic list. They have the same effect as the additions of the same name in the introductory program statement for the called program. If the called program has the same additions in the introductory program statement, these overwrite the values specified for SUBMIT.
Addition 3
... EXPORTING LIST TO MEMORY
Effect
This addition stores the basic list for the program accessed in the ABAP Memory. It can only be used together with the addition AND RETURN.
The list is stored in the ABAP Memory as an internal table of the row type ABAPLIST, ABAPLIST being a structured data type in ABAP Dictionary.
The calling program can access the list stored once the program has been called, using function modules from the function group SLST.
◈ The function module LIST_FROM_MEMORY loads the list from the ABAP Memory to an internal table of the row type ABAPLIST.
◈ The function module WRITE_LIST inserts the content of an internal table of the row type ABAPLIST in the current list.
◈ The function module DISPLAY_LIST displays the content of an internal table of the row type ABAPLIST in a separate list dynpro.
◈ The function module LIST_TO_ASCI converts the content of an internal table of the row type ABAPLIST to ASCII representation.
Note
The addition can only work provided the function key Enter is not associated with a function code in the GUI status last defined for the called program.
Example
Once the program report has been called, the list stored there in the ABAP Memory is read using function modules and inserted in the current list.
DATA list_tab TYPE TABLE OF abaplist.
SUBMIT report EXPORTING LIST TO MEMORY
AND RETURN.
CALL FUNCTION 'LIST_FROM_MEMORY'
TABLES
listobject = list_tab
EXCEPTIONS
not_found = 1
OTHERS = 2.
IF sy-subrc = 0.
CALL FUNCTION 'WRITE_LIST'
TABLES
listobject = list_tab.
ENDIF.
Addition 4
... TO SAP-SPOOL spool_options
Effect
If this addition is specified, a new spool list level is opened in the internal session of the called program and the first output statement for the basic list of this program creates a new spool request. All list output for the called program is passed page by page as a spool list to the SAP spool system. The additions spool_options are used to define the spool and archiving parameters for the spool request.
Note
It is not possible to switch from the spool list to the screen list in the called program. The statement NEW-PAGE PRINT OFF does not modify a spool list level created using SUBMIT TO SAP-SPOOL.
Example
Calls an executable program and creates a spool request. When the name of the called program is passed to the input parameter REPORT of the function module GET_PRINT_PARAMETERS, the information about the line width and page length of the spool list is taken from the statement that introduces the program.
DATA: print_parameters TYPE pri_params,
archi_parameters TYPE arc_params,
valid_flag TYPE c LENGTH 1.
CALL FUNCTION 'GET_PRINT_PARAMETERS'
EXPORTING
report = 'SUBMITABLE'
archive_mode = '3'
IMPORTING
out_parameters = print_parameters
out_archive_parameters = archi_parameters
valid = valid_flag
EXCEPTIONS
invalid_print_params = 2
OTHERS = 4.
IF valid_flag = 'X' AND sy-subrc = 0.
SUBMIT submitable TO SAP-SPOOL
SPOOL PARAMETERS print_parameters
ARCHIVE PARAMETERS archi_parameters
WITHOUT SPOOL DYNPRO.
ENDIF.
◆ SUBMIT - spool_options
Syntax
... SPOOL PARAMETERS pri_params
[ARCHIVE PARAMETERS arc_params]
WITHOUT SPOOL DYNPRO...
Effect
These additions are used to supply the spool request with spool and archiving parameters. The latter are necessary if the spool list is archived using ArchiveLink.
The addition SPOOL PARAMETERS passes the spool parameters in a structure pri_params of data type PRI_PARAMS from ABAP Dictionary. If archiving is specified in pri_params, archiving parameters must be passed using the addition ARCHIVE PARAMETERS in a structure arc_params of data type ARC_PARAMS from ABAP Dictionary.
Structures of data types PRI_PARAMS and ARC_PARAMS must be filled by the function module GET_PRINT_PARAMETERS. When calling the function module, either individual or all spool parameters can be set in the program and/or a spool dialog window displayed. The function module creates a set of valid spool and archiving parameters for use as pri_params and arc_params and adds these to its output parameters.
If the structures pri_params or arc_params are initial, the spool parameters or archiving parameters created by a call of the function modules GET_PRINT_PARAMETERS with initial input values are used.
The addition WITHOUT SPOOL DYNPRO suppresses the spool dialog box that is displayed as standard when the addition TO SAP-SPOOL is used.
Notes
◈ These additions must always be used as indicated here. It is particularly important that the standard spool dialog box be suppressed. If the standard spool dialog box is used, inconsistent spool parameters may be passed to the program accessed if the user chooses Cancel to exit the GUI window. Instead, the spool dialog window can be displayed by calling the function module GET_PRINT_PARAMETERS. This function module has an output parameter VALID that indicates the consistency of the spool parameters created.
◈ Use of the addition WITHOUT SPOOL DYNPRO without passing spool parameters is no longer allowed in ABAP objects. In other objects, the spool parameters are derived from the user master record, if possible.
◈ Calling the spool dialog box with SUBMIT TO SAP-SPOOL has the disadvantage that the Back function is not available. After using this kind of statement to switch to spooling, the system cannot return to a point before the statement in question. Printing can only be exited using Exit, which ends the entire program. If Cancel is used to exit, inconsistent spool parameters can be passed to the program. To disconnect the spool dialog box from switching to spooling, it is recommended that he function module GET_PRINT_PARAMETERS is called.
◈ The same obsolete additions apply to the statement SUBMIT TO SAP-SPOOL as to the statement NEW-PAGE PRINT ON.
◆ Program Calls, Influencing the Basic List
The example shows how to influence the basic list of a program called.
Source Code
REPORT demo_program_submit_line.
SELECTION-SCREEN BEGIN OF SCREEN 1100.
PARAMETERS: name TYPE sy-repid
DEFAULT 'DEMO_PROGRAM_READ_TABLES' OBLIGATORY,
width TYPE i DEFAULT 80,
length TYPE i DEFAULT 0.
SELECTION-SCREEN END OF SCREEN 1100.
CLASS demo DEFINITION.
PUBLIC SECTION.
CLASS-METHODS main.
PRIVATE SECTION.
CLASS-METHODS security_check
IMPORTING name TYPE sy-repid
RETURNING value(checked_name) TYPE sy-repid.
ENDCLASS.
CLASS demo IMPLEMENTATION.
METHOD main.
DATA prog_type TYPE trdir-subc.
CALL SELECTION-SCREEN 1100 STARTING AT 10 10.
IF sy-subrc <> 0.
RETURN.
ENDIF.
SELECT SINGLE subc
FROM trdir
WHERE name = @name
INTO @prog_type.
IF sy-subrc <> 0 OR prog_type <> '1'.
MESSAGE 'Program not found or wrong type' TYPE 'I'
DISPLAY LIKE 'E'.
RETURN.
ENDIF.
name = security_check( name ).
IF name IS INITIAL.
MESSAGE 'Program execution not allowed' TYPE 'I'
DISPLAY LIKE 'E'.
RETURN.
ENDIF.
SUBMIT (name) LINE-SIZE width LINE-COUNT length AND RETURN.
ENDMETHOD.
METHOD security_check.
DATA whitelist TYPE HASHED TABLE OF string
WITH UNIQUE KEY table_line.
AUTHORITY-CHECK OBJECT 'S_DEVELOP'
ID 'DEVCLASS' FIELD 'SABAPDEMOS'
ID 'OBJTYPE' FIELD 'PROG'
ID 'OBJNAME' DUMMY
ID 'P_GROUP' DUMMY
ID 'ACTVT' FIELD '16'.
IF sy-subrc <> 0.
CLEAR checked_name.
RETURN.
ENDIF.
SELECT obj_name
FROM tadir
WHERE pgmid = 'R3TR' AND
object = 'PROG' AND
devclass = 'SABAPDEMOS'
INTO TABLE @whitelist.
TRY.
checked_name = cl_abap_dyn_prg=>check_whitelist_tab(
val = name
whitelist = whitelist ).
CATCH cx_abap_not_in_whitelist.
CLEAR checked_name.
RETURN.
ENDTRY.
ENDMETHOD.
ENDCLASS.
START-OF-SELECTION.
demo=>main( ).
Description
If the program called does not have its own LINE-SIZE or LINE-COUNT specifications in the REPORT statement, the values width and length are used for its basic list.
◈ SUBMIT - job_options
Syntax
... [USER user] VIA JOB job NUMBER n [LANGUAGElang] ...
Additions
1. ... USER user
2. ... LANGUAGE lang
Effect
This addition schedules the execution of the program accessed as a background task with the number n in the background request job. The number n for a background request job is supplied by function module JOB_OPEN in function group BTCH. The full program is not processed directly but in background processing, according to the parameters specified for the background request. The addition VIA JOB can only be used together with the addition AND RETURN.
The addition VIA JOB also loads the program accessed in a separate internal session when the statement SUBMIT is executed and the system performs all the steps specified before START-OF-SELECTION. This means the events LOAD-OF-PROGRAM and INITIALIZATION are raised and selection screen processing is performed. If the selection screen is not processed in the background when VIA SELECTION-SCREEN is specified, the user of the calling program can edit it and schedule the program accessed in the background request using the function Place in Job. If the user cancels selection screen processing, the program is not scheduled in the background job. In both cases, execution of the program executed is completed after selection screen processing and the system returns to the calling program due to AND RETURN.
When the program is scheduled in the background task, the selections specified by the user or in the additions for filling the selection screen are stored in an internal variant. When the program is executed in the background request, it is processed fully but the selection screen is processed in the background. All events are raised, including those for selection screen processing. The variant stored internally is passed to the selection screen between the INITIALIZATION and AT SELECTION SCREEN OUTPUT events.
If a basic list is created in the program accessed, a spool request should be created with explicit spool parameters by specifying TO SAP-SPOOL. Otherwise the addition VIA JOB implicitly creates a spool request that derives its spool parameters from standard values, some of which are taken from the user defaults, and which are not necessarily consistent.
System Fields
| sy-subrc | Meaning |
| 0 | Background task scheduled successfully. |
| 4 | Scheduling terminated by the user on the selection screen. |
| 8 | Error during the scheduling, that is during the internal call of JOB_SUBMIT. |
| 12 | Error during internal number assignment |
Note
Background jobs can be created and monitored by choosing the menu path System - Services - Jobs. Internally, the language elements shown here are used. In addition to JOB_OPEN, the function modules JOB_CLOSE and JOB_SUBMIT can also be used in the ABAP program. JOB_CLOSE closes the creation of a background request. Like the statement SUBMIT, JOB_SUBMIT schedules an ABAP program as a background task in a background request. JOB_SUBMIT provides more control options for background processing but must receive the input values for the selection screen in an existing variant. The statement SUBMIT creates this variant and accesses JOB_SUBMIT internally.
Example
Scheduling a submittable program as a background task with the number number in a background request name. After scheduling, the background task is completed by function module JOB_CLOSE and released immediately providing the user has the relevant authorization.
DATA: number TYPE tbtcjob-jobcount,
name TYPE tbtcjob-jobname VALUE 'JOB_TEST',
print_parameters TYPE pri_params.
...
CALL FUNCTION 'JOB_OPEN'
EXPORTING
jobname = name
IMPORTING
jobcount = number
EXCEPTIONS
cant_create_job = 1
invalid_job_data = 2
jobname_missing = 3
OTHERS = 4.
IF sy-subrc = 0.
SUBMIT submitable TO SAP-SPOOL
SPOOL PARAMETERS print_parameters
WITHOUT SPOOL DYNPRO
VIA JOB name NUMBER number
AND RETURN.
IF sy-subrc = 0.
CALL FUNCTION 'JOB_CLOSE'
EXPORTING
jobcount = number
jobname = name
strtimmed = 'X'
EXCEPTIONS
cant_start_immediate = 1
invalid_startdate = 2
jobname_missing = 3
job_close_failed = 4
job_nosteps = 5
job_notex = 6
lock_failed = 7
OTHERS = 8.
IF sy-subrc <> 0.
...
ENDIF.
ENDIF.
ENDIF.
Addition 1
... USER user
Effect
The optional addition USER can be used to specify a user name user of the type sy-uname, whose authorizations are used to run the background task. If USER is not specified, the user name of the current user session is used.
Notes
◈ The name specified after USER is checked using the authorization object S_BTCH_NAM. When the program is executed, only those names can be specified for which the current user has the correct authorization. The names permitted by the authorization object represent a type of whitelist of users whose authorizations allow the current user to execute a background task.
◈ The current user should not be specified explicitly using USER sy-uname. Not only is the user specified redundantly, the system field is also at risk of being overwritten before the background task is scheduled, for example in ABAP Debugger.
Addition 2
... LANGUAGE lang
Effect
This addition defines the text environment of the internal session in which the called program is executed and sets sy-langu to the value of lang here.
lang expects a character-like data object. This must contain a language key with a length of one character in the first place and this value must be contained in the column SPRAS of the database table T002. If the data object lang contains a blank in its first place, the logon language of the current user is used.
Note
If the function module JOB_SUBMIT is called internally, its optional parameter LANGUAGE is passed the first place of lang.
Example
The following statement
SUBMIT submitable TO SAP-SPOOL
SPOOL PARAMETERS print_parameters
WITHOUT SPOOL DYNPRO
VIA JOB name NUMBER number
LANGUAGE langu
AND RETURN.
has the same effect as the following function module call
CALL FUNCTION 'JOB_SUBMIT'
EXPORTING
authcknam = sy-uname
jobcount = number
jobname = name
language = langu
priparams = print_parameters
report = 'SUBMITABLE'.
1.2 Calling Transactions
A transaction is the execution of a program using a transaction code. The program process flow depends on which initial screen or selection screen, or which method, the transaction code is linked to.
There are two statements for calling transactions:
1.2.1 CALL TRANSACTION
Syntax Forms
Simple transaction call
1. CALL TRANSACTION ta WITH|WITHOUT AUTHORITY-CHECK [AND SKIP FIRST SCREEN].
Transaction call using batch input table
2. CALL TRANSACTION ta WITH|WITHOUT AUTHORITY-CHECK
USING bdc_tab { {[MODE mode] [UPDATE upd]}
| [OPTIONS FROM opt] }
[MESSAGES INTO itab].
Effect
The statement CALL TRANSACTION calls the transaction whose transaction code is contained in data object ta. The calling program and its data are retained. After the end of the transaction call, program execution of the calling program resumes after the statement CALL TRANSACTION. The data object ta must be character-like, flat and contain the transaction code in uppercase letters. The following can be specified for ta:
◈ Literal or constant
If the data object ta is specified as a text field literal or as a constant, it is evaluated as a statically specified object by tools such as the extended program check or the where-used list.
◈ Variable
If the data object ta is specified as a variable, it is specified only dynamically and the content is not evaluated statically.
When the statement is executed, ta is not evaluated until runtime (in both cases). If the transaction specified in ta cannot be found, a non-handleable exception is raised.
◈ In the first variant, the display of the initial screen can be suppressed.
◈ In the second variant, the transaction is executed using a batch input table.
In both variants, an authorization check can be performed on the called transaction.
When the transaction is called, the ABAP program associated with the transaction code is loaded in a new internal session of the current call sequence. The session of the calling program and the current SAP LUW are preserved. The called program runs in its own SAP LUW.
◈ If the called transaction is a dialog transaction, the event LOAD-OF-PROGRAM is triggered after the ABAP programs is loaded and the dynpro defined as the initial dynpro of the transaction is called. The initial dynpro is the first dynpro of a dynpro sequence. The transaction is finished when the dynpro sequence is ended by encountering the next dynpro with dynpro number 0 or when the program is exited using the statement LEAVE PROGRAM.
◈ If the called transaction is an OO transaction, the event LOAD-OF-PROGRAM is raised and the method associated with the transaction code is called when any program is loaded (except class pools). If the method is an instance method, an object of the associated class is created implicitly and referenced by the runtime environment. The transaction is finished when the method is finished or when the program is exited using the statement LEAVE PROGRAM.
Notes
◈ CALL TRANSACTION does not end the current database LUW. A database commit or database rollback in the called program works in exactly the same way as in the current program.
◈ The statement CALL TRANSACTION opens a new SAP-LUW but it does not open a new database LUW. This means that a database rollback in this SAP LUW can roll back all registration entries made by the statements CALL FUNCTION IN UPDATE TASK or CALL FUNCTION IN BACKGROUND TASK in the tables VB... or ARFCSSTATE and ARFCSDATA. Under certain circumstances, the statement ROLLBACK WORK in the called program can also affect the interrupted SAP LUW. To prevent this, an explicit database commit must be executed before the program is called. This problem does not occur in local updates.
◈ The number of internal sessions in a call sequence is restricted to nine. If this is exceeded by CALL TRANSACTION, the program terminates and the entire call sequence is deleted.
Security Note
If the name of a program unit is specified dynamically when it is called, and this name is passed to a program from outside, the result is a serious security risk. Any names passed to a program from outside must be checked thoroughly before being used in calls. The system class CL_ABAP_DYN_PRG, for example, can be used to do this. See Dynamic Calls.
Exceptions
Handleable Exceptions
CX_SY_AUTHORIZATION_ERROR
◈ Cause: No authorization for this transaction
Runtime Error: CALL_TRANSACTION_FAILED
Non-Handleable Exceptions
◈ Cause: Transaction not found.
Runtime Error: CALL_TRANSACTION_NOT_FOUND
◈ Cause: Transaction is an area menu and cannot be called.
Runtime Error: CALL_TRANSACTION_IS_MENU
◈ Cause: Transaction is locked.
Runtime Error: CALL_TRANSACTION_LOCKED
◈ Cause: Error in internal memory management.
Runtime Error: CALL_TRANSACTION_MSG_NO_PAGING
◈ Cause: Recursive call of a transaction using the addition USING.
Runtime Error: CALL_TRANSACTION_USING_NESTED
◈ CALL TRANSACTION - standard
Syntax
CALL TRANSACTION ta WITH|WITHOUT AUTHORITY-CHECK [AND SKIP FIRST SCREEN].
Addition:
... AND SKIP FIRST SCREEN
Effect
This variant calls the version described in ta as described under the statement CALL TRANSACTION. The additions WITH|WITHOUT AUTHORITY-CHECK are used to control the authorization check. AND SKIP FIRST SCREEN can be used to skip the initial screen.
Note
This variant does not set the system field sy-subrc.
Addition
... AND SKIP FIRST SCREEN
Effect
This addition suppresses the display of a screen of the initial dynpro of a called dialog transaction. The addition AND SKIP FIRST SCREEN suppresses the first screen only under these prerequisites:
On the initial dynpro, the dynpro number must not be specified as a static next dynpro in Screen Painter.
All mandatory input fields of the initial dynpro must be filled completely and with the correct values by the SPA/GPA parameters.
If these prerequisites are met, the screen of the dynpro is displayed that is specified in Screen Painter as the next dynpro of the initial dynpro.
Example
If the static next dynpro of the initial dynpro of the called dialog transaction FLIGHT_TA is not the initial dynpro itself, its screen is suppressed, since its input fields are filled using the SPA/GPA parameters CAR and CON.
DATA: carrid TYPE spfli-carrid,
connid TYPE spfli-connid.
...
SET PARAMETER ID: 'CAR' FIELD carrid,
'CON' FIELD connid.
TRY:
CALL TRANSACTION 'FLIGHT_TA' WITH AUTHORITY-CHECK
AND SKIP FIRST SCREEN.
CATCH cx_sy_authorization_error.
RETURN.
ENDTRY.
CALL TRANSACTION - AUTHORITY-CHECK
Syntax
... WITH|WITHOUT AUTHORITY-CHECK ...
Additions
1. ... WITH AUTHORITY-CHECK
2. ... WITHOUT AUTHORITY-CHECK
Effect
These additions control the authorization checks when the statement CALL TRANSACTION is executed.
Note
The statement CALL TRANSACTION when used without specifying one of the additions WITH AUTHORITY-CHECK or WITHOUT AUTHORITY-CHECK is obsolete.
Addition 1
... WITH AUTHORITY-CHECK
Effect
If this addition is specified, the authorization of the current user to execute the called transaction is checked using the following authorization objects before the transaction is called:
◈ The authorization object S_TCODE
◈ Any authorization object entered in the definition of the transaction code (transaction SE93). Fields of the authorization object for which no value is specified here are not checked.
If no authorization is found, a handleable exception of the class CX_SY_AUTHORIZATION_ERROR is raised.
Note
The addition WITH AUTHORITY-CHECK is the recommended method of checking the authorizations of the current user. It replaces checks using the statement AUTHORITY-CHECK, the function module AUTHORITY_CHECK_TCODE, and checks associated with the content of the database table TCDCOUPLES.
Addition 2
... WITHOUT AUTHORITY-CHECK
Effect
If this addition is specified, the authorization of the current user is not checked when the called transaction is executed.
Notes
◈ The addition WITHOUT AUTHORITY-CHECK indicates explicitly that no authorization checks are required when the transaction is called. It suppresses the corresponding error message from the security test in the extended program checks.
◈ If the addition WITHOUT AUTHORITY-CHECK is specified, the content of the database table TCDCOUPLES is ignored.
Syntax
CALL TRANSACTION ta WITH|WITHOUT AUTHORITY-CHECK
USING bdc_tab { {[MODE mode] [UPDATE upd]}
| [OPTIONS FROM opt] }
[MESSAGES INTO itab].
Additions
1. ... MODE mode
2. ... UPDATE upd
3. ... OPTIONS FROM opt
4. ... MESSAGES INTO itab
Effect
In the variant with the addition USING, the transaction is executed using a batch input table. The transaction is called as described under CALL TRANSACTION. The additions WITH|WITHOUT AUTHORITY-CHECK are used to control the authorization check.
bdc_tab expects an internal table with row type BDCDATA from ABAP Dictionary.. The additions control processing.
When a transaction with addition USING is called, the system field sy-binpt is set to value "X" in the called program; while this transaction is running, no other transaction can be called with this addition.
In a program, a batch input table bdc_tab is the internal representation of a subset of a batch input session and must be filled accordingly. The structure BDCDATA has the components shown in the table below.
| Component | Meaning |
| PROGRAM | Name of the program of the called transaction |
| DYNPRO | Number of the dynpro to be processed |
| DYNBEGIN | Flag for the beginning of a new dynpro (possible values are "X" and " ") |
| FNAM | Name of a dynpro field to be filled or batch input control statement, for example to position the cursor |
| FVAL | Value to be passed to the dynpro field or to the control statement |
Using the content of the internal table bdc_tab, any number of screens of the called transaction can be provided with input and user actions.
System Fields
| sy-subrc | Meaning |
| 0 | The processing of the called transaction was successful. |
| < 1000 | Error in the called transaction. If a message was sent within the transaction, it can be received using the addition MESSAGES. |
| 1001 | Processing error. |
Notes
◈ Calling a transaction using a batch input table is not the same as executing batch input sessions in batch input. There is no exact dividing line between the two, however, since batch input-based frameworks, such as CATT and batch input management, sometimes also execute the statement CALL TRANSACTION USING internally. In this way, they can use certain options not available in genuine batch input.
◈ The control options for a batch input table include the control options for batch input sessions in real batch input, plus some extra options.
Addition 1
... MODE mode
Effect
The addition MODE determines the processing mode for processing. mode can be specified as a character-like data object, whose content and purpose are shown in the following table. If one of the additions MODE or OPTIONS FROM is not used, the effect is the same as if mode had the content "A".
| mode | Meaning |
| "A" | Processing with screens displayed |
| "E" | Screens displayed only if an error occurs |
| "N" | Processing without screens displayed. If a breakpoint is reached in one of the called transactions, processing is terminated with sy-subrc equal to 1001. The field sy-msgty contains "S", sy-msgid contains "00", sy-msgno contains "344", sy-msgv1 contains "SAPMSSY3", and sy-msgv2 contains "0131". |
| "P" | Processing without screens displayed. If a breakpoint is reached in one of the called transactions, the system branches to the ABAP Debugger. |
| Others | As for "A". |
Addition 2
... UPDATE upd
Effect
The addition UPDATE determines the update mode for processing. upd can be specified as a character-like data object, whose content and purpose are shown in the following table. If one of the additions UPDATE or OPTIONS FROM is not used, the effect is the same as if upd had the content "A".
| upd | Meaning |
| "A" | Asynchronous update. Updates of called programs are executed in the same way as if the addition AND WAIT were not specified in the statement COMMIT WORK. |
| "S" | Synchronous update. Updates of the called programs are executed in the same way as if the addition AND WAIT were specified in the statement COMMIT WORK. |
| "L" | Local updates. Updates of the called program are executed in the same way as if the statement SET UPDATE TASK LOCAL were executed in the program. |
| Others | As for "A". |
Note
This option is not available for execution of batch input sessions in batch input. Updates are always synchronous.
Addition 3
... OPTIONS FROM opt
Effect
The addition OPTIONS covers the functions of the MODE and UPDATE additions and provides further options for controlling processing of the batch input table. The control parameters are specified in an opt structure of the type CTU_PARAMS from ABAP Dictionary. The CTU_PARAMS structure has the components displayed in the following table:
| Component | Meaning |
| DISMODE | Processing mode. Values as for the addition MODE. |
| UPMODE | Update mode for processing. Values as for the addition UPDATE. |
| CATTMODE | CATT mode for processing. While batch input is used mostly for data transfer, CATT processes are more complex transactions, since they are reusable tests. Values: " " (no CATT mode), "N" (CATT without single screen control), "A" (CATT with single screen control). |
| DEFSIZE | Selects whether the screens of the called transaction are displayed in the standard screen size. Values: "X" (standard size), " " (current size). |
| RACOMMIT | Specifies whether the statement COMMIT WORK terminates processing or not. Values: " " (COMMIT WORK terminates processing), "X" (COMMIT WORK does not terminate processing). |
| NOBINPT | Selection for the system field sy-binpt. Values: " " (sy-binpt contains "X" in the called transaction), "X" (sy-binpt contains " " in the called transaction). |
| NOBIEND | Selection for the system field sy-binpt. Values: " " (sy-binpt contains "X" after the end of the batch input table data in the called transaction ) "X" (sy-binpt contains " " after the end of the data in the called transaction). |
If the addition OPTIONS FROM is not used, the values set by the additions MODE or UPDATE or the standard values specified there "A" apply to DISMODE and UPMODE. The other components are set to the value " ".
Addition 4
... MESSAGES INTO itab
Effect
Using this addition, all the messages sent during batch input processing are saved to an internal table itab of the type BDCMSGCOLL from ABAP Dictionary.
A batch input table of the type row type BDCDATA specified after the addition USING of the statement CALL TRANSACTION when transactions are called must have the following content (achieved by appending rows to an initial table in this order):
◈ For each new dynpro, a new row with
◈ a program name in the column PROGRAM
◈ a dynpro number in the column DYNPRO
◈ an "X" in the column DYNBEGIN
◈ For each filled input field, a row with
◈ the name of the dynpro field in the column FNAM
◈ the passed value in the column FVAL
If the field is part of a table control or step loop, the required row number must be appended to the field name.
◈ If the cursor is to be positioned on a screen element
◈ the value "BDC_CURSOR" in the column FNAM
◈ the name of the screen element in the column FVAL
If the cursor is to be positioned on a screen element in a table control or step loop, the required row number must be appended to the name of the element.
◈ For each dynpro, the function code
◈ the value "BDC_OKCODE" in the column FNAM
◈ a function code in the column FVAL
Any columns not used in a row remain initial.
Note
Transaction Recorder records executed transactions as batch input tables. The resulting batch input tables can be displayed and edited. Programs and function modules can be generated to use these tables.
◈ Transaction Call - Examples
Transaction Call, SPA/GPA Parameters
The example shows how to call a transaction using SPA/GPA parameters.
Source Code
REPORT demo_call_transaction_spa_gpa.
PARAMETERS: carrid TYPE spfli-carrid,
connid TYPE spfli-connid.
CLASS demo DEFINITION.
PUBLIC SECTION.
CLASS-METHODS main.
ENDCLASS.
CLASS demo IMPLEMENTATION.
METHOD main.
SET PARAMETER ID: 'CAR' FIELD carrid,
'CON' FIELD connid.
TRY.
CALL TRANSACTION 'DEMO_TRANSACTION' WITH AUTHORITY-CHECK.
CATCH cx_sy_authorization_error.
RETURN.
ENDTRY.
ENDMETHOD.
ENDCLASS.
START-OF-SELECTION.
demo=>main( ).
Description
The transaction DEMO_TRANSACTION displays the details for a flight uniquely identified by the airline and the flight number. It is called from within main using the CALL TRANSACTION statement and filled with SPA/GPA parameters as initial values using the SET PARAMETER statement.
Transaction Call, BDC Table
This example shows how to call a transaction using a batch input table.
Source Code
REPORT demo_call_transaction_bdc.
CLASS demo DEFINITION.
PUBLIC SECTION.
CLASS-METHODS main.
ENDCLASS.
CLASS demo IMPLEMENTATION.
METHOD main.
DATA class_name TYPE c LENGTH 30 VALUE 'CL_ABAP_BROWSER'.
DATA bdcdata_tab TYPE TABLE OF bdcdata.
DATA opt TYPE ctu_params.
bdcdata_tab = VALUE #(
( program = 'SAPLSEOD' dynpro = '1000' dynbegin = 'X' )
( fnam = 'BDC_CURSOR' fval = 'SEOCLASS-CLSNAME' )
( fnam = 'SEOCLASS-CLSNAME' fval = class_name )
( fnam = 'BDC_OKCODE' fval = '=WB_DISPLAY' ) ).
opt-dismode = 'E'.
opt-defsize = 'X'.
TRY.
CALL TRANSACTION 'SE24' WITH AUTHORITY-CHECK
USING bdcdata_tab OPTIONS FROM opt.
CATCH cx_sy_authorization_error ##NO_HANDLER.
ENDTRY.
ENDMETHOD.
ENDCLASS.
START-OF-SELECTION.
demo=>main( ).
Description
Call Class Builder (transaction SE24) and display the class CL_SPFLI_PERSISTENT. The required authorization is checked by using the addition WITH AUTHORITY-CHECK. The internal table bdcdata_tab contains the entry for the processing of the first dynpro (1000) in the transaction. The structure opt is used to configure processing to skip the first screen and display the subsequent screen in standard size.
Transaction Call, Report Transaction
The example illustrates how a selection screen can be called using a report transaction.
Source Code
REPORT demo_call_selection_screen.
SELECTION-SCREEN BEGIN OF SCREEN 100.
SELECTION-SCREEN BEGIN OF BLOCK sel1 WITH FRAME TITLE tit1.
PARAMETERS: cityfr TYPE spfli-cityfrom,
cityto TYPE spfli-cityto.
SELECTION-SCREEN END OF BLOCK sel1.
SELECTION-SCREEN END OF SCREEN 100.
SELECTION-SCREEN BEGIN OF SCREEN 500 AS WINDOW.
SELECTION-SCREEN INCLUDE BLOCKS sel1.
SELECTION-SCREEN BEGIN OF BLOCK sel2
WITH FRAME TITLE tit2.
PARAMETERS: airpfr TYPE spfli-airpfrom,
airpto TYPE spfli-airpto.
SELECTION-SCREEN END OF BLOCK sel2.
SELECTION-SCREEN END OF SCREEN 500.
CLASS start DEFINITION.
PUBLIC SECTION.
CLASS-METHODS main.
ENDCLASS.
CLASS start IMPLEMENTATION.
METHOD main.
tit1 = 'Cities'.
CALL SELECTION-SCREEN 100 STARTING AT 10 10.
tit1 = 'Cities for Airports'.
tit2 = 'Airports'.
CALL SELECTION-SCREEN 500 STARTING AT 10 10.
tit1 = 'Cities again'.
CALL SELECTION-SCREEN 100 STARTING AT 10 10.
ENDMETHOD.
ENDCLASS.
START-OF-SELECTION.
start=>main( ).
Description
When the associated transaction DEMO_REPORT_TRANSACT is called, the executable program starts with the selection screen 500 in the same GUI window. Now proceed as described in the example Selection Screens, Calling Standalone Selection Screens.
Transaction Call, Dialog Transaction
The example illustrates a dialog transaction where the first dynpro is a selection screen.
Source Code
*&---------------------------------------------------------------------*
*& Modulpool SAPMSSLS *
*&---------------------------------------------------------------------*
PROGRAM sapmdemo_selscreen_dynp.
SET EXTENDED CHECK OFF.
SELECTION-SCREEN BEGIN OF SCREEN 500 AS WINDOW.
SELECTION-SCREEN BEGIN OF BLOCK sel1 WITH FRAME.
PARAMETERS: cityfr LIKE spfli-cityfrom,
cityto LIKE spfli-cityto.
SELECTION-SCREEN END OF BLOCK sel1.
SELECTION-SCREEN BEGIN OF BLOCK sel2 WITH FRAME.
PARAMETERS: airpfr LIKE spfli-airpfrom,
airpto LIKE spfli-airpto.
SELECTION-SCREEN END OF BLOCK sel2.
SELECTION-SCREEN END OF SCREEN 500.
AT SELECTION-SCREEN.
...
LEAVE TO SCREEN 100.
Description
When calling the assigned transaction DEMO_SELSCREEN_DYNP, the program starts by displaying selection screen 500. The user input on the selection screen can be processed, for example, at the event AT SELECTION-SCREEN, or later in the application logic. After processing the event AT SELECTION-SCREEN (PAI of the selection screen), the program branches to a next dynpro, 100.
1.2.2 LEAVE TO TRANSACTION
Syntax
LEAVE TO { {TRANSACTION ta} | {CURRENT TRANSACTION} }
[AND SKIP FIRST SCREEN].
Addition:
... AND SKIP FIRST SCREEN
Effect
The statement LEAVE TO TRANSACTION calls either the transaction whose transaction code is contained in data object ta, or the current transaction. The data object ta must be character-like, flat and contain the transaction code in uppercase letters. The following can be specified for ta:
◈ Literal or constant
If the data object ta is specified as a text field literal or as a constant, it is evaluated as a statically specified object by tools such as the extended program check or the where-used list.
◈ Variable
If the data object ta is specified as a variable, it is specified only dynamically and the content is not evaluated statically.
When the statement is executed, ta is not evaluated until runtime (in both cases).
When CURRENT TRANSACTION is specified, the current transaction is called using the transaction code that was used to call the transaction using CALL TRANSACTION or LEAVE TO TRANSACTION. This transaction code is contained in the system field sy-tcode except for parameter transactions or variant transactions. When using parameter actions or variant transactions, their transaction code is used for the call and sy-tcode contains the name of the implicitly called dialog transaction.
When using LEAVE TO TRANSACTION, the current call sequence is exited completely. Upon completion of the called transaction, the runtime environment returns to the position where the first program in the call sequence was called. The current SAP LUW is thereby ended.
When the transaction is called, the ABAP program associated with the transaction code is loaded in a new internal session. All previous internal sessions are deleted from the stack. At the same time, the ABAP memory is deleted, which means that EXPORT FROM MEMORY or IMPORT TO MEMORY do not transfer data when using LEAVE TO TRANSACTION.
The steps of the called dialog transaction or OO transaction are the same as with CALL TRANSACTION. When the called transaction is exited, the runtime environment returns to the position where the first program in the current call sequence was called.
If the transaction specified in ta is not found, or if ta is initial or blank, the stack of the current call sequence is deleted and the runtime environment returns directly to the position where the first program in the current call sequence was called. If ta is not initial, an appropriate message appears in the status bar.
The statement LEAVE TO TRANSACTION always terminates the current call sequence, regardless of whether or not a new transaction can be called.
Contrary to the statement CALL TRANSACTION, the authorization of the current user for executing the called transaction is always automatically checked as follows when using the statement LEAVE TO TRANSACTION:
◈ It is checked against the authorization object S_TCODE,
◈ It is check against any authorization object entered in the definition of the transaction code (transaction SE93). Fields of the authorization object for which no value is specified here are not checked.
If the required authorization is missing, a message with message type A (termination message) is triggered and the system responds appropriately.
Notes
◈ The CURRENT TRANSACTION call can be used to execute a current parameter transaction or variant transaction with the corresponding parameters or the transaction variant. Alternatively, the method GET_CURRENT_TRANSACTION of the class CL_DYNPRO can be used to obtain the transaction code of the current transaction. This method returns the transaction code during a parameter transaction or variant transaction instead of the transaction code of the implicitly called dialog transaction.
◈ LEAVE TO TRANSACTION does not end the current database LUW. A database commit or database rollback in the called program works in exactly the same way as in the current program.
◈ If procedures are still registered at LEAVE TO TRANSACTION in the current SAP LUW, the SAP LUW is ended and the procedures are not called or rolled back. Registered update function modules remain in the database, but can no longer be executed. In a case like this, therefore, it is advisable to execute the statement COMMIT WORK or ROLLBACK WORK explicitly before the program call.
Security Note
If the name of a program unit is specified dynamically when it is called, and this name is passed to a program from outside, the result is a serious security risk. Any names passed to a program from outside must be checked thoroughly before being used in calls. The system class CL_ABAP_DYN_PRG, for example, can be used to do this. See Dynamic Calls.
Addition
... AND SKIP FIRST SCREEN
Effect
The addition AND SKIP FIRST SCREEN has the same meaning as with CALL TRANSACTION.
2. Calling Processing Blocks
In every processing block of an ABAP program, processing blocks of the same program can be called (using internal calls) or processing blocks of other ABAP programs can be called (using external calls) .
◈ Calling procedures directly.
◈ Calling event handlers indirectly by raising events from the same class in methods. This provides the interface of the event handler. Prerequisite for the execution of an event handler is its registration.
◈ Calling event blocks indirectly by raising events in the runtime environment explicitly.
The statement MODULE does not call dialog modules in the processing blocks of an ABAP program, however, but in the processing blocks of the dynpro flow logic.
2.1 Calling Procedures
Procedures can be called internally and externally. The following figure shows the most important internal and external calls.
The statements for calling procedures are
◈ for methods:
meth( ... )
CALL METHOD dynamic_meth ...
◈ for function modules:
CALL FUNCTION func ...
◈ and (for the time being) for the obsolete subroutines:
PERFORM subr ...
These statements supply the parameter interfaces of the procedures. When the call ends correctly, control returns to the statement after the call position.
2.2 Internal Procedure Call
All procedures which are defined in the same ABAP program and are visible from the calling position can be called internally.
◈ In every ABAP program, and within a class, the visible methods of the class or visible methods of other local classes of the same program can be called. The calling of methods is the only procedure call which is recommended for the program modularization.
◈ In a function group, a function module which has been made available for external users can also be called internally.
◈ In every ABAP program that still contains subroutines, these can also still be called internally. Subroutines are an obsolete form of internal modularization and should be replaced by methods if possible.
The required program is always already loaded for internal calls.
2.3 External Procedure Calls
The following procedures of the same AS ABAP can be called externally:
- Procedures which are intended for external calls:
- Methods of global classes in class pools visible where called (that is, public methods in all programs), protected methods in subclasses, and private methods in friends of the classes.
- Function modules in function groups
- Methods of local classes of other programs that are visible at the call position if a reference variable with a reference to an object of the class was passed to the calling program
- Procedures which are not intended for external calls but can still be called externally (but should not be):
- Subroutines in executable programs, module pools, function groups, and subroutine pools
- Static methods of local classes which are visible at the call position, if the name of the class is specified dynamically using an absolute type name
In the first external call of a procedure of the same AS ABAP, its master program is loaded into the internal session of the calling program if it has not yet been loaded. Except when loading class pools, the event LOAD-OF-PROGRAM is also triggered, which calls the program constructor program. External calls of subroutines and methods of local classes is not recommended and is critical, since the assignment of the loaded master program to a program group is usually not determined:
◈ Program Groups in External Procedure Calls
Furthermore, the potential for properties of the calling and called programs to differ in the case of external procedure calls must be considered.
◈ Fixed Point Arithmetic in External Procedure Calls
- - Program Groups in External Procedure Calls
The programs within an internal session are grouped into program groups there. There is always a main program group and possibly multiple additional program groups. Each program group contains a main program and possibly several additional programs. In an external procedure call, it is important to know the program group of the master program of the procedure, if the procedure accesses shared resources of the program group. This causes non-critical and critical external procedure calls.
Non-Critical External Procedure Calls
The only procedures designed for external calls are the visible methods of global classes and function modules. The master programs of these procedures are always main programs of their program groups and the procedure always works with the resources of this program group.
Note: For this reason, only call the methods of global classes and function modules.
Critical External Procedure Calls
Subroutines and the methods of local classes are not designed for external calls. There is no static assignment to a program group in external subroutine calls or in dynamic calls of the local class of a program that does not form its own program group. The program in which an unloaded program is used for the first time determines the program group. The order of user actions, field contents, or switches can determine the order of the programs, which means that the master program of the procedure can be in the main program group in one instance, and in an additional program group in another instance.
The usage of external procedures of additional programs is critical for the following reasons:
◈ Within a program group, only the dynpros, selection screens, lists, and GUI statuses of the main program are used. For example, the statement CALL SCREEN does not call any dynpros of its own master program in an externally called subroutine of an additional program; instead, it calls a dynpro of the main program of its program group. The reaction to user actions also takes place in the main program.
◈ Interface work areas declared using the statements TABLES, NODES, or DATA BEGIN OF COMMON PART exist once only in each program group, and are shared by all of its programs. Each main program is shared by the additional programs of the interface work areas.
Therefore, there is no static way of defining which interface work areas and which screens are used by an externally called subroutine or local class. The following figure shows how programs are added to program groups, using the example of an external subroutine call.
Subroutines and methods of local classes must always be called internally and never externally.
Note: The text elements of an added program are always taken from its own text pool.
Example
The table work area dbtab declared in sapssubr is shared either with sapmprog or with saplfugr. If share has the value 'FUGR', saplfugr andsapssubr share the table work area. Otherwise it is shared by sapmprog and sapssubr.
PROGRAM sapmprog.
TABLES dbtab.
...
IF share = 'FUGR'.
CALL FUNCTION 'FUNC'.
ENDIF.
...
PERFORM sub IN PROGRAM sapssubr.
FUNCTION-POOL saplfugr.
TABLES dbtab.
...
FUNCTION func.
PERFORM sub IN PROGRAM sapssubr.
ENDFUNCTION.
PROGRAM sapssubr.
TABLES dbtab.
...
FORM sub.
...
ENDFORM.
- - Fixed Point Arithmetic in External Procedure Calls
A procedure that is called externally is executed according to the attribute Fixed Point Arithmetic in its master program. Here, each actual parameter bound to a formal parameter in the procedure is handled independently of the corresponding attribute of the calling program and, independently of the parameter type and pass by type, also according to the attribute of the program called.
Example
Take the following global class:
CLASS cl_test DEFINITION PUBLIC.
PUBLIC SECTION.
CLASS-METHODS meth RETURNING value(p) TYPE string.
ENDCLASS.
CLASS cl_test IMPLEMENTATION.
METHOD meth.
p = '1000'.
ENDMETHOD.
ENDCLASS.
A calling program section could be as follows:
DATA pack TYPE p DECIMALS 2.
pack = cl_test=>meth( ).
Depending on the attributes, the result is as follows, where the attributes of the calling program are in the top row and the attributes of the called program are in the left column:
| Fixed point arithmetic | on | off |
| on | 1000,00 | 1000,00 |
| off | 10,00 | 10,00 |
The formal parameter is assigned to the bound actual parameter, including the associated conversion while respecting decimal separators, only if fixed point arithmetic is switched on in the called procedure. If fixed point arithmetic is switched off in the called procedure, the decimal separator of the actual parameter is ignored.
However, if the call is as follows:
DATA pack TYPE p DECIMALS 2.
pack = + cl_test=>meth( ).
the result looks like this:
| Fixed point arithmetic | on | off |
| on | 1000,00 | 10,00 |
| off | 1000,00 | 10,00 |
In this case, the call takes place in an arithmetic expression. The return value of the call is assigned to an intermediate result of the same type as the formal parameter and this is then converted to the calculation type of the arithmetic expression in the calling program. In this case, therefore, the attribute of the calling program determines whether the decimal separator is respected.
The behavior in the second case generally meets the expectations of a calling program. Of course, this can also be achieved by introducing an auxiliary variable of the same type as the formal parameter used in the calling program first as an actual parameter and then assign it to the target field.
Note
The justification for the behavior shown here is that the passing of parameters is to be independent of pass by reference and pass by value. To bypass the associated problems, it is strongly recommend that fixed point arithmetic is not switched off in any program. In this context, this applies particularly to class pools and function groups.
2.4 Method Calls
There are two types of method call: static and dynamic. In static method calls, the name of the method must be specified in full in the program. In dynamic method calls, the full name of the method or part of the name is determined at runtime.
When an instance method is called using a reference variable and the static type of the reference variable is a superclass of the dynamic type, the dynamic method call can be used to call all visible methods of the dynamic type. In static method calls, however, only the visible methods of the static type can be called.
Static method calls have the pattern meth( ). They do not need a keyword; instead, the method is specified directly and the parameters are passed in parentheses. Dynamic method calls are introduced using CALL METHOD.
◈ Static method calls
◈ Dynamic method call
An obsolete syntax variant also exists where static method calls are still introduced using CALL METHOD.
System Fields
The system field sy-subrc is set to 0 when a method is called. If a non-class-based exception is raised that was handled by the assignment of a value, sy-subrc is set to this value.
2.4.1 Static Method Calls
There are two types of method call: standalone calls and functional calls. Method chainings are a special type of static method call.
◈ meth( ... ) - standalone method call
◈ meth( ... ) - functional method call
◈ ... meth1( ... )->meth2( ... )->... - method chaining
Obsolete variant of the standalone call:
◈ CALL METHOD meth ...
Exceptions
Handleable Exceptions
CX_SY_NO_HANDLER
◒ meth( ... ) - Standalone Method Call
Syntax
{ static_meth( )
| static_meth( a )
| static_meth( p1 = a1 p2 = a2 ... )
| static_meth( [EXPORTING p1 = a1 p2 = a2 ...]
[IMPORTING p1 = a1 p2 = a2 ...]
[CHANGING p1 = a1 p2 = a2 ...]
[RECEIVING r = a]
[EXCEPTIONS [exc1 =n1 exc2 = n2 ...]
[OTHERS = n_others]] ) }.
Alternatives:
1. static_meth( ).
2. static_meth( a ).
3. static_meth( p1 = a1 p2 = a2 ... ).
4. static_meth( EXPORTING ... IMPORTING ... CHANGING ... RECEIVING ... ).
Effect
Static call of a method specified by the name static_meth as a standalone statement. In the parentheses, the parameter interface of the method is supplied with the actual parameters. In the first alternative, no formal parameters are supplied with actual parameters. The second and third alternatives are short forms for methods where only the input parameters are supplied with actual parameters. The fourth alternative allows all possible formal parameters to be supplied with actual parameters, and the handling of non-class-based exceptions.
Alternative 1
static_meth( ).
Effect
Calls the method static_meth without pass by parameter. The method can either have no input parameters or input/output parameters or only optional input parameters or input/output parameters. An actual parameter is not assigned to any output parameters or return codes.
Example
Calls a method without parameters.
CLASS c1 DEFINITION.
PUBLIC SECTION.
CLASS-METHODS do_something.
ENDCLASS.
CLASS c1 IMPLEMENTATION.
METHOD do_something.
...
ENDMETHOD.
ENDCLASS.
START-OF-SELECTION.
c1=>do_something( ).
Alternative 2
static_meth( a ).
Effect
This is the short form of:
static_meth( EXPORTING p = a ).
The method static_meth can have either only one non-optional input parameter p or only optional input parameters, of which p is defined as the preferred parameter using PREFERRED PARAMETER. The value of a is passed to this input parameter; this value can be specified as a data object, function, or expression.
The method can only have optional input/output parameters. No actual parameters are assigned to these input/output parameters, any output parameters, or a return value.
Example
Calls a method with an input parameter
CLASS c1 DEFINITION.
PUBLIC SECTION.
CLASS-METHODS do_something IMPORTING p type i.
ENDCLASS.
CLASS c1 IMPLEMENTATION.
METHOD do_something.
...
ENDMETHOD.
ENDCLASS.
START-OF-SELECTION.
c1=>do_something( 333 ).
Alternative 3
static_meth( p1 = a1 p2 = a2 ... ).
Effect
This is the short form of:
static_meth( EXPORTING p1 = a1 p2 = a2 ... ).
The method static_meth can have any number of input parameters p1, p2, and so on, which are supplied with the actual parameters a1, a2, and so on. The actual parameters can be specified as a data object, function, or expression.
The method can only have optional input/output parameters. No actual parameters are assigned to these input/output parameters, any output parameters, or a return value.
Example
Calls a method with two input parameters.
CLASS c1 DEFINITION.
PUBLIC SECTION.
CLASS-METHODS do_something IMPORTING p1 type i
p2 type i.
ENDCLASS.
CLASS c1 IMPLEMENTATION.
METHOD do_something.
...
ENDMETHOD.
ENDCLASS.
START-OF-SELECTION.
c1=>do_something( p1 = 333 p2 = 444 ).
Alternative 4
static_meth( EXPORTING ... IMPORTING ... CHANGING ... RECEIVING ... ).
Effect
Calls the method static_meth with explicit pass by parameter and the option of handling non-class-based exceptions. This format can be used to call methods with any number of parameter interfaces.
Example
Calls a method with explicit pass by parameter.
CLASS c1 DEFINITION.
PUBLIC SECTION.
CLASS-METHODS do_something IMPORTING p1 type i
p2 type i
EXPORTING p3 TYPE i
p4 TYPE i
RETURNING VALUE(r) type i.
ENDCLASS.
CLASS c1 IMPLEMENTATION.
METHOD do_something.
...
ENDMETHOD.
ENDCLASS.
START-OF-SELECTION.
c1=>do_something( EXPORTING p1 = 333
p2 = 444
IMPORTING p3 = DATA(a1)
p4 = DATA(a2)
RECEIVING r = DATA(a3) ).
meth( ... ) - Specifying the Method
Syntax
... meth
| oref->meth
| class=>meth
| super->meth ...
Alternatives:
1. ... meth ...
2. ... oref->meth ...
3. ... class=>meth ...
Effect
These names are used for the to specify methods statically, where meth is a valid name for the method in the current context. A special case of specifying methods statically is when they are specified after the pseudo reference super in methods of subclasses.
Note: The name of a method can be the name of the method declared in METHODS, a name composed using the interface component selector, or an alias name.
Alternative 1
... meth ...
Effect
Can be specified in method implementations for any method meth of the same class. In instance methods, meth is a short form of me->meth, where me is the self reference.
Alternative 2
... oref->meth ...
Effect
Can be specified in processing blocks in which a method meth is visible, where oref contains an object reference to an object that contains the method as a component. oref can be specified as an existing reference variable or (in suitable operand positions) a constructor expression with a constructor operator NEW or CAST. The latter is particularly applicable for standalone method calls.
Alternative 3
... class=>meth ...
Effect
Can be specified in processing blocks in which a static method meth is visible, where class is one of the classes allowed by the package check, which contains the method as a static component.
super->meth( ... )
Syntax
... super->meth
| super->constructor ...
Alternatives:
1. ... super->meth ...
2. ... super->constructor ...
Effect
This special form of specifying methods statically can be used in methods of subclasses to call the implementation of a method with the same name in the direct superclass. The superclass is addressed using the pseudo reference super.
Alternative 1
... super->meth ...
Effect
Can be specified in the redefinition of the method meth in the implementation of a subclass and calls the implementation of the method meth in the direct superclass.
A method call super->meth can be used in the same operand positions and in the same syntax forms as oref->meth. The same rules apply to the passing of parameters.
Alternative 2
... super->constructor ...
Effect
Must be specified in an instance constructor implemented in a subclass to call the instance constructor of the direct superclasses. The following restrictions apply before the superclass constructor is called:
◈ The instance constructor does not have access to the instance components of its class. The self-reference me-> cannot be used. The static components of its class can be accessed only directly.
◈ Befor the superclass constructor is called, an instance constructor cannot be exited using statements such as RETURN or CHECK.
After the superclass constructure has been called, the self-reference me-> can be used and instance components can be accessed.
The superclass constuctor can be called using super->constructor only as a standalone statement.
Notes
During the execution of a superclass constructor called using super->constructor, meth and me->meth do not address the method implementations of the subclass as may be expected, but instead address the method implementations of the superclass.
The instance constructor of the superclass must be called if it is not declared explcitly.
◒ meth( ... ) - Functional Method Call
Syntax
... { static_meth( )
| static_meth( a )
| static_meth( p1 = a1 p2 = a2 ... )
| static_meth( [EXPORTING p1 = a1 p2 = a2 ...]
[IMPORTING p1 =a1 p2 = a2 ...]
[CHANGING p1 =a1 p2 = a2 ...] ) } ...
Effect
Functional call of a functional method static_meth in a suitable reading position for functions and expressions. The return value of the method declared using RETURNING is used as an operand and its full typing determines the data type of the operand. The actual parameters bound to output parameters and input/output parameters are handled in the same way as in standalone method calls.
The semantics of the syntax used to pass parameters is the same as in standalone method calls. The following differences from standalone method calls exist:
◈ The return value in functional method calls cannot be assigned to an actual parameter explicitly using RECEIVING.
◈ Inline declarations are not possible for actual parameters.
◈ Non-class-based exceptions cannot be handled using EXCEPTIONS.
If the return value method has a structured data type, a functional method call can, like a structure, be specified in front of the structure component selector - to access a component of the structure.
If the functional method has the same name as a predefined function, the functional method is always called.
Notes
◈ In functional method calls, class-based exceptions propagated from the method can be handled as usual in a TRY control structure or propagated further. The non-class-based exceptions of a functional method, however, always produce a runtime error.
◈ The same applies to resumable exceptions in functional method calls as in all other methods. If processing can be resumed successfully, execution of the statement called in the method can be completed.
◈ Method chaining is possible in the operand positions where functional methods can be specified.
◈ A functional method call whose first method is an instance method can be introduced using the instance operator NEW or the casting operator CAST.
◈ A single functional method call can be used as a predicative method call and as a relational expression.
◈ Functional method calls can be nested in any way, which means that inline declarations for actual parameters can produce confusing results. For this reason, inline declarations are not allowed.
◈ If successful, each method call sets the system field sy-subrc to 0, which means that all statements with functional method calls modify the value of this field.
Example
Functional call of a method. Unlike in the example for standalone method calls, the return value is assigned to the result. The inline declarations made in that example, however, are not possible here.
CLASS c1 DEFINITION.
PUBLIC SECTION.
CLASS-METHODS do_something IMPORTING p1 TYPE i
p2 TYPE i
EXPORTING p3 TYPE i
p4 TYPE i
RETURNING VALUE(r) TYPE i.
ENDCLASS.
CLASS c1 IMPLEMENTATION.
METHOD do_something.
...
ENDMETHOD.
ENDCLASS.
DATA: a1 TYPE i,
a2 TYPE i.
START-OF-SELECTION.
DATA(result) =
c1=>do_something( EXPORTING p1 = 333
p2 = 444
IMPORTING p3 = a1
p4 = a2 ).
Example
The functional method factorial in this example has the return value fact of type int8, used on the right side of an assignment in an expression.
CLASS math DEFINITION.
PUBLIC SECTION.
METHODS factorial
IMPORTING n TYPE i
RETURNING VALUE(fact) TYPE int8.
ENDCLASS.
CLASS math IMPLEMENTATION.
METHOD factorial.
fact = COND #( WHEN n < 0
THEN 0
ELSE
REDUCE #(
INIT f = 1
FOR i = 1 UNTIL i > n
NEXT f = f * i ) ).
ENDMETHOD.
ENDCLASS.
START-OF-SELECTION.
DATA(result) = 100 + NEW math( )->factorial( 4 ).
Example
The functional method get in this example has a structured return value whose component carrname is accessed.
CLASS carriers DEFINITION.
PUBLIC SECTION.
METHODS get
IMPORTING carrid TYPE scarr-carrid
RETURNING VALUE(r) TYPE scarr.
ENDCLASS.
CLASS carriers IMPLEMENTATION.
METHOD get.
SELECT SINGLE *
FROM scarr
WHERE carrid = @carrid
INTO @r.
ENDMETHOD.
ENDCLASS.
START-OF-SELECTION.
cl_demo_output=>display( NEW carriers( )->get( 'LH' )-carrname ).
◒ ... meth1( ... )->meth2( ... )->... - Method Chaining
Syntax
... { static_meth( ... )->meth1( ... )->meth2( ... )->...->meth( ... ) }
| { static_meth( ... )->meth1( ... )->meth2( ... )->...->attr } ...
Alternatives:
1. static_meth( ... )->meth1( ... )->meth2( ... )->...->meth( ... )
2. static_meth( ... )->meth1( ... )->meth2( ... )->...->attr
Effect
Chains static method calls to a chained method call or a chained attribute access. static_meth, meth1, meth2, ... , expect functional methods whose return values are reference variables pointing to objects of the next method along. All methods that follow static_meth must be called using the object component selector.
The parameters are passed to the functional methods static_meth, meth1, meth2, ... using the syntax valid for functional method calls.
Alternative 1
static_meth( ... )->meth1( ... )->meth2( ... )->...->meth( ... )
Effect
Chained method call. Calls the instance method meth in an object. The reference variable for the object is the return value of the preceding method chaining.
A chained method call be specified as a standalone statement or as a functional method call in a suitable operand position. When passing parameters to meth, the appropriate rules apply.
If the return value method of the last method has a structured data type, the chained method call can, like a structure, be specified in front of the structure component selector - to access a component of the structure.
Notes
◈ In static_meth, a constructor expression can be specified with a constructor operator NEW or CAST for oref not only in a functional call, but also in standalone statements.
◈ The obsolete statement CALL METHOD cannot be used as a prefix in a standalone statement in this form of the static method call.
Example
Calls the method m3 in an object of the class c3, addressed using method chaining.
CLASS c3 DEFINITION.
PUBLIC SECTION.
METHODS m3 CHANGING c3 TYPE string.
ENDCLASS.
CLASS c2 DEFINITION.
PUBLIC SECTION.
METHODS m2 IMPORTING i2 TYPE string
RETURNING value(r2) TYPE REF TO c3.
ENDCLASS.
CLASS c1 DEFINITION.
PUBLIC SECTION.
CLASS-METHODS m1 IMPORTING i1 TYPE string
RETURNING value(r1) TYPE REF TO c2.
ENDCLASS.
CLASS c1 IMPLEMENTATION.
METHOD m1.
CREATE OBJECT r1.
ENDMETHOD.
ENDCLASS.
CLASS c2 IMPLEMENTATION.
METHOD m2.
CREATE OBJECT r2.
ENDMETHOD.
ENDCLASS.
CLASS c3 IMPLEMENTATION.
METHOD m3.
c3 = 'New text'.
MESSAGE c3 TYPE 'I'.
ENDMETHOD.
ENDCLASS.
START-OF-SELECTION.
DATA txt TYPE string VALUE `test`.
c1=>m1(
i1 = `p1` )->m2(
i2 = `p2` )->m3(
CHANGING c3 = txt ).
Alternative 2
static_meth( ... )->meth1( ... )->meth2( ... )->...->attr
Effect
Chained attribute access. Accesses the instance attribute attr in an object. The reference variable for the object is the return value of the preceding method chaining.
If the attribute has a structured data type, the chained attribute access can, like a structure, be specified in front of the structure component selector - to access a component of the structure.
A chained attribute access can currently only be specified in suitable reading positions. Writes to an attribute addressed using method chaining are not yet possible.
Method Chaining
This example demonstrates method chaining in an operand position.
Source Code
REPORT demo_method_chaining.
CLASS demo DEFINITION.
PUBLIC SECTION.
CLASS-METHODS main.
PRIVATE SECTION.
METHODS meth IMPORTING str TYPE string
RETURNING value(ref) TYPE REF TO demo.
DATA text TYPE string.
ENDCLASS.
CLASS demo IMPLEMENTATION.
METHOD main.
DATA oref TYPE REF TO demo.
CREATE OBJECT oref.
cl_demo_output=>display(
oref->meth( `Hello ` )->meth( `world` )->meth( `!` )->text ).
ENDMETHOD.
METHOD meth.
text = text && str.
ref = me.
ENDMETHOD.
ENDCLASS.
START-OF-SELECTION.
demo=>main( ).
Description
In the argument of the method DISPLAY_TEXT statement, a chained attribute access is performed on the attribute text of the class demo. The attribute is changed by three chained method calls.
◒ meth( ... ) - Parameter Passing
Syntax
... [EXPORTING p1 = a1 p2 = a2 ...]
[IMPORTING p1 = a1 p2 = a2 ...]
[CHANGING p1 = a1 p2 = a2 ...]
[RECEIVING r = a ]
[EXCEPTIONS [exc1 = n1 exc2 = n2 ...]
[OTHERS = n_others] ].
Additions
1. ... EXPORTING p1 = a1 p2 = a2 ...
2. ... IMPORTING p1 = a1 p2 = a2 ...
3. ... CHANGING p1 = a1 p2 = a2 ...
4. ... RECEIVING r = a
5. ... EXCEPTIONS exc1 = n1 exc2 = n2 ... [OTHERS = n_others]
Effect
With the exception of addition EXCEPTIONS, these additions assign actual parameters a1 a2... to the formal parameters p1 p2 ... or r of the parameter interface of the called method. Any data objects (and some expressions) with a data type that matches the typing of the corresponding formal parameter according to the rules of the typing check can be specified as actual parameters.
With the exception of the return code r for functional methods and arithmetic expressions for input parameters, every formal parameter assumes all attributes of the assigned actual parameters when called. Non-class-based exceptions can be handled using the addition EXCEPTIONS. The order of the additions is fixed.
Notes
◈ The formal parameters and non-class-based exceptions of a method are defined as its parameter interface using the additions of the statements METHODS or CLASS-METHODS of global or local classes.
◈ Unlike function module calls, static parameter passing is checked by the syntax check and not just by the extended program check.
Addition 1
... EXPORTING p1 = a1 p2 = a2 ...
Effect
This addition assigns actual parameters to the input parameters of the called method. EXPORTING can be used to assign actual parameters to the optional input parameters. It must be used to assign actual parameters to the non-optional input parameters. When using pass by reference, a reference to an actual parameter is passed when the call is made; when using pass by value, the content of an actual parameter is assigned to the corresponding formal parameter.
a1, a2, ... are general expression positions. In other words, functions and expressions can be passed as actual parameters, alongside data objects. Special rules apply in this case.
Note
No substring access is possible after an actual parameter of type string or xstring specified after EXPORTING.
Addition 2
... IMPORTING p1 = a1 p2 = a2 ...
Effect
This addition assigns actual parameters to the output parameters of the called method. IMPORTING can be used to assign actual parameters to all output parameters, but this is not mandatory. In pass-by-reference, a reference is passed to an actual parameter when the call is made. In pass-by-value, the content of an output parameter is assigned to the actual parameter in question only if the method is completed without errors.
The actual parameters are result positions, which means that variables and writable expressions can be specified. Special rules apply in this case.
◈ Existing variables or writable expressions can be specified as actual parameters for functional method calls, but inline declarations cannot be specified.
◈ Inline declarations DATA(var) can also be specified for standalone method calls. If an inline declaration is specified and a formal parameter is fully typed, this type is used for the declaration. If the formal parameter is typed generically, the following data types are used:
◈ string for csequence and clike
◈ xstring for xsequence
◈ decfloat34 for numeric and decfloat
◈ p with the length 8 and no decimal places if p is generic
◈ The standard key for a standard table type with generic primary table key
Other generic data types cannot be made concrete for the inline declaration in a useful way and produce a syntax error.
Notes
◈ If, for example, a formal parameter is typed with the generic type c or x, string or xstring cannot be used as the type for an inline declaration, since this means the typing cannot be checked.
◈ Functional method calls are located on the right side of assignments or are part of expressions where no inline declarations are possible.
Addition 3
... CHANGING p1 = a1 p2 = a2 ...
Effect
This addition assigns actual parameters to the input/output parameters of the called method. CHANGING can be used to assign actual parameters to the optional input/output parameters. It must be used to assign actual parameters to the non-optional input/output parameters. When using pass by reference, a reference to an actual parameter is passed when the call is made; when using pass by value, the content of an actual parameter is assigned to the corresponding formal parameter. In pass by value, the modified content of an input/output parameter is assigned to the actual parameter in question only if the method is completed without errors.
The actual parameters are result positions, which means that variables and writable expressions can be specified. Special rules apply in this case.
Addition 4
... RECEIVING r = a
Effect
This addition assigns an actual parameter to the return value of the called method. This addition is only possible for standalone method calls and not for functional method calls. An actual parameter can be assigned to the return value of a functional method using RECEIVING. The data type of the actual parameter does not have to comply with the general rules of the typing check; it is sufficient if the return code can be converted to the actual parameter in accordance with the conversion rules.
If the method ends without errors, the content of the formal parameter is assigned to the actual parameter. The content is converted if necessary.
The actual parameter is a result position, which means that variables and writable expressions can be specified. Special rules apply in this case.
An existing variable or an expression or inline declaration DATA(var) can be specified as an actual parameter. An inline declaration is made with the fully known data type of the return value.
Note
The RECEIVING addition is usually not used for static method calls. A functional method with a return code is usually not called as a standalone method call. Instead it is usually called as a functional method call in operand positions.
Addition 5
... EXCEPTIONS exc1 = n1 exc2 = n2 ... [OTHERS =n_others]
Effect
This addition can only be used in standalone method calls and not in functional method calls.
EXCEPTIONS can be used to assign return codes to non-class-based exceptions exc1 exc2 ... declared in the parameter interface. Each exception exc1 exc2 ... that the caller wants to handle must be assigned to a directly specified number n1 n2 .... All numbers between 0 and 65535 can be specified. The behavior outside of this range is undefined.
By specifying OTHERS as the last item after EXCEPTIONS, all exceptions can be assigned not listed explicitly in exc1 exc2... a common return code, by assigning a number n_others. The same return code can be assigned to different exceptions (including OTHERS). The behavior when an exception is raised is as follows:
◈ If the statement RAISE or MESSAGE RAISING is used to raise an exception exc1 exc2 ... (to which a return code is assigned) the procedure is ended immediately, any output parameters or return codes passed by value are canceled, and the number n1 n2 ... assigned to the exception is available to be evaluated in sy-subrc .
◈ If the call of an exception raised by RAISE does not assign a return code, the program terminates with a runtime error.
◈ If the call of an exception raised by MESSAGE RAISING does not assign a return code, the message is sent and the system continues in accordance with the message type.
If no exception is raised, a call sets sy-subrc to 0.
The addition EXCEPTIONS cannot be specified in the call if RAISING is used to declare class-based exceptions in the parameter interface of the called procedure.
The specified exceptions must be present in the parameter interface of the method.
Notes
◈ If the value 0 is assigned to an exception, this indicates that the caller wants to ignore this exception. If the exception is raised in the method, no runtime error occurs, but the exception cannot be handled.
◈ Information about the behavior of class-based exceptions in methods can be found in Class-Based Exceptions in Procedures.
Example
The method GET_DOCU of the class CL_ABAP_DOCU_ITF has two input parameters and two output parameters, plus a return value that indicates whether the method was executed successfully. Functionally, the method is called as an operand of a comparison expression in a logical expression. The values in the output are reused in further method calls only if the method completed successfully.
DATA: itf TYPE tline_tab,
head TYPE thead.
IF cl_abap_docu_itf=>get_docu(
EXPORTING langu = sy-langu
object = 'ABENABAP'
IMPORTING itf = itf
head = head ) = 0.
cl_abap_docu_itf=>get_docu_includes(
EXPORTING head = head
CHANGING itf = itf ).
ENDIF.
2.4.2 Dynamic Method Call
The following statement is used for dynamic method calls:
CALL METHOD
All other uses of this statement are obsolete.
◈ CALL METHOD
Syntax
CALL METHOD dynamic_meth { parameter_list
| parameter_tables }.
Effect
This statement calls the method dynamically specified in dynamic_meth(Dynamic Invoke). Actual parameters are assigned to formal parameters of the method, either statically using parameter_list or dynamically using parameter_tables. The syntax of parameter_list is the same as that in the explicit parameter specification for the static method call.
Notes
◈ In the dynamic method call, the parameters are not passed in parentheses. The syntax of the dynamic method call is like that of a function module call.
◈ The CALL_METHOD statement should now only be used for the dynamic method call. It is unnecessary, and therefore obsolete, for the static method call.
Security Note
If the name of a program unit is specified dynamically when it is called, and this name is passed to a program from outside, the result is a serious security risk. Any names passed to a program from outside must be checked thoroughly before being used in calls. The system class CL_ABAP_DYN_PRG, for example, can be used to do this. See Dynamic Calls.
System Fields
The system field sy-subrc is set to 0 when a method is called. If a non-class-based exception is raised that was handled by the assignment of a value, sy-subrc is set to this value.
Example
Dynamic call of the static method GUI_DOWNLOAD of global class CL_GUI_FRONTEND_SERVICES for storing the content of an internal table in a file on the current presentation server. The names of the class and method are specified in the strings class and meth. The interface parameters are passed in the internal table ptab and return values are assigned to the exceptions of the method are assigned using table etab. Exceptions that occur at the method call itself are handled in a TRY control structure with statement CATCH.
DATA: line TYPE c LENGTH 80,
text_tab LIKE STANDARD TABLE OF line,
filename TYPE string,
filetype TYPE c LENGTH 10,
fleng TYPE i.
DATA: meth TYPE string,
class TYPE string,
ptab TYPE abap_parmbind_tab,
etab TYPE abap_excpbind_tab.
DATA: exc_ref TYPE REF TO cx_sy_dyn_call_error.
class = 'CL_GUI_FRONTEND_SERVICES'.
meth = 'GUI_DOWNLOAD'.
filename = 'c:\temp\text.txt'.
filetype = 'ASC'.
ptab = VALUE #( ( name = 'FILENAME'
kind = cl_abap_objectdescr=>exporting
value = REF #( filename ) )
( name = 'FILETYPE'
kind = cl_abap_objectdescr=>exporting
value = REF #( filetype ) )
( name = 'DATA_TAB'
kind = cl_abap_objectdescr=>changing
value = REF #( text_tab ) )
( name = 'FILELENGTH'
kind = cl_abap_objectdescr=>importing
value = REF #( fleng ) ) ).
etab = VALUE #( ( name = 'OTHERS' value = 4 ) ).
TRY.
CALL METHOD (class)=>(meth)
PARAMETER-TABLE
ptab
EXCEPTION-TABLE
etab.
CASE sy-subrc.
WHEN 1.
...
...
ENDCASE.
CATCH cx_sy_dyn_call_error INTO exc_ref.
MESSAGE exc_ref->get_text( ) TYPE 'I'.
ENDTRY.
Exceptions
Handleable Exceptions
CX_SY_NO_HANDLER
◈ Runtime Error: UNCAUGHT_EXCEPTION
CX_SY_DYN_CALL_EXCP_NOT_FOUND
◈ Cause: Exception does not exist
Runtime Error: DYN_CALL_METH_EXCP_NOT_FOUND
CX_SY_DYN_CALL_ILLEGAL_CLASS
◈ Cause: Specified class does not exist
Runtime Error: DYN_CALL_METH_CLASS_NOT_FOUND
CX_SY_DYN_CALL_ILLEGAL_METHOD
◈ Cause: Method cannot be accessed.
Runtime Error: CALL_METHOD_NOT_ACCESSIBLE
◈ Cause: The called method is not implemented.
Runtime Error: CALL_METHOD_NOT_IMPLEMENTED
◈ Cause: Calls the static constructor
Runtime Error: DYN_CALL_METH_CLASSCONSTRUCTOR
◈ Cause: Calls the instance constructor
Runtime Error: DYN_CALL_METH_CONSTRUCTOR
◈ Cause: Method does not exist
Runtime Error: DYN_CALL_METH_NOT_FOUND
◈ Cause: Method is not static
Runtime Error: DYN_CALL_METH_NO_CLASS_METHOD
◈ Cause: Calls a non-visible method
Runtime Error: DYN_CALL_METH_PRIVATE
◈ Cause: Calls a non-visible method
Runtime Error: DYN_CALL_METH_PROTECTED
CX_SY_DYN_CALL_ILLEGAL_TYPE
◈ Cause: Type conflict during method call.
Runtime Error: CALL_METHOD_CONFLICT_GEN_TYPE
◈ Cause: Type conflict during method call.
Runtime Error: CALL_METHOD_CONFLICT_TAB_TYPE
◈ Cause: Type conflict during method call.
Runtime Error: CALL_METHOD_CONFLICT_TYPE
◈ Cause: Incorrect parameter type
Runtime Error: DYN_CALL_METH_PARAM_KIND
◈ Cause: Actual parameter cannot be filled
Runtime Error: DYN_CALL_METH_PARAM_LITL_MOVE
◈ Cause: Incorrect table type for a parameter
Runtime Error: DYN_CALL_METH_PARAM_TAB_TYPE
◈ Cause: Incorrect parameter type
Runtime Error: DYN_CALL_METH_PARAM_TYPE
CX_SY_DYN_CALL_PARAM_MISSING
◈ Cause: Missing actual parameter
Runtime Error: DYN_CALL_METH_PARAM_MISSING
◈ Cause: Parameter reference is empty
Runtime Error: DYN_CALL_METH_PARREF_INITIAL
CX_SY_DYN_CALL_PARAM_NOT_FOUND
◈ Cause: Incorrect parameter name
Runtime Error: DYN_CALL_METH_PARAM_NOT_FOUND
CX_SY_REF_IS_INITIAL
◈ Cause: Reference variable is empty
Runtime Error: DYN_CALL_METH_REF_IS_INITIAL
Non-Handleable Exceptions
◈ Cause: Invalid parameters for dynamic method call. Relevant for instance constructors when instantiated dynamically.
Runtime Error: CALL_METHOD_PARMS_ILLEGAL
- - CALL METHOD - dynamic_meth
Syntax
... (meth_name)
| oref->(meth_name)
| class=>(meth_name)
| (class_name)=>(meth_name)
| (class_name)=>meth ...
Additions
1. ... (meth_name) ...
2. ... (class_name) ...
Alternatives:
1. ... (meth_name) ...
2. ... oref->(meth_name) ...
3. ... class=>(meth_name) ...
4. ... (class_name)=>(meth_name) ...
5. ... (class_name)=>meth ...
Effect
These names are used to specify methods dynamically.
Addition 1
... (meth_name) ...
Effect
meth_name expects a character-like field that must contain the name of a method when the statement is executed.
Addition 2
... (class_name) ...
Effect
class_name expects a character-like field that must contain the name of a class in uppercase letters when the statement is executed. An absolute type name can also be specified. The following can be specified for class_name:
◈ Literal or constant
If the data object class_name is specified as a character literal or as a constant, it can be evaluated statically and the specified class is identified as the used object.
◈ Variable
If the data object class_name is specified as a variable, it is specified only dynamically and the content is not evaluated statically.
When the statement is executed, class_name is not evaluated until runtime (in both cases).
Alternative 1
... (meth_name) ...
Effect
This variant is only possible for methods of the same class. It has the same effect as me->(meth_name) (see alternative 2).
Alternative 2
... oref->(meth_name) ...
Effect
This form is possible for all visible methods of objects. oref can be any class reference variable or interface reference variable that points to an object that contains the method or interface method specified in meth_name. This method is searched for first in the static type, then in the dynamic type of oref
Note
In the dynamic case too, only interface components can be accessed and it is not possible to use interface reference variable to access any type of component.
Alternative 3
... class=>(meth_name) ...
Alternative 4
... (class_name)=>(meth_name) ...
Alternative 5
... (class_name)=>meth ...
Effect
These forms are possible for all visible static methods. Both the class and method can be specified dynamically. The class class and the method meth can also be specified directly.
In the alternatives with a dynamic class name (class_name), first the class is searched for, then the method. If class is specified statically, the search for the method is carried out in the existing class.
Notes
◈ If, in class_name, a class of another program is specified using an absolute type name, this program is loaded into a new additional program group or into the current program group, depending on the program type (if not already loaded). If required, the program constructor is also executed.
◈ The external calling of local class methods is critical, especially for executable programs, module pools, and subroutine pools, since it can usually not be determined statically which program group the framework group is assigned to.
- - CALL METHOD - parameter_tables
Syntax
... [PARAMETER-TABLE ptab]
[EXCEPTION-TABLE etab].
Additions
1. ... PARAMETER-TABLE ptab
2. ... EXCEPTION-TABLE etab
Effect
In the dynamic method call these additions assign actual parameters and exceptions to the formal parameters and non-class-based exceptions, respectively, using the special internal tables ptab and etab.
Addition 1
... PARAMETER-TABLE ptab
Effect
Use PARAMETER-TABLE to assign actual parameters to all formal parameters of a dynamically called method. ptab expects a hashed table of table type ABAP_PARMBIND_TAB or of row type ABAP_PARMBIND from the type group ABAP. When the statement CALL METHOD is executed, the table must contain exactly one row for each non-optional formal parameter; this row is optional for each optional formal parameter. The table columns are:
◈ NAME of type c and length 30
for the name of the corresponding formal parameter in uppercase letters. If a nonexistent formal parameter is specified, a handleable exception is raised.
◈ KIND of type c of length 1.
for the category of the formal parameter. This column is used to check the interface. The category of the formal parameter is determined in the declaration of the called method. If KIND is initial, no check is executed. If KIND contains the value of a constant EXPORTING, IMPORTING, CHANGING, RECEIVING of class CL_ABAP_OBJECTDESCR, a check is executed (from caller viewpoint), whether the formal parameter specified in NAME is an input parameter, output parameter, input/output parameter or a return value; in case of an error, the handleable exception CX_SY_DYN_CALL_ILLEGAL_TYPE is raised.
◈ VALUE of type REF TO data
as a pointer to an appropriate actual parameter. The data object to which the reference variable in VALUE points is assigned to the formal parameter specified in NAME.
The column NAME is the unique key of table ptab.
Addition 2
... EXCEPTION-TABLE etab
Effect
Use EXCEPTION-TABLE to assign return values to all non-class-based exceptions of a dynamically called method. etab expects a hashed table of table type ABAP_EXCPBIND_TAB or of row type ABAP_EXCPBIND from the type group ABAP. During execution of the statement CALL METHOD, this table can contain exactly one row for every non-class-based exception of the method. The table columns are:
◈ NAME of type c and length 30
for the name of the respective exception or OTHERS in uppercase letters.
◈ VALUE of type i
for the number value to be available in sy-subrc after the exception specified in NAME was raised.
The column NAME is the unique key of table etab.
2.5 CALL FUNCTION
Syntax Forms
General Function Module Call
1. CALL FUNCTION func { parameter_list
| parameter_tables }.
Registration of an Update Task Function Module
2. CALL FUNCTION update_function IN UPDATE TASK
[EXPORTING p1 = a1 p2 = a2 ...]
[TABLES t1 = itab1 t2 = itab2 ...].
Remote Function Call
3. CALL FUNCTION... DESTINATION ...
Effect
Calls or registers a function module. Static and dynamic function module calls have no differences in their syntax. The function module is always specified by a data object and the name of the called function module not determined until runtime.
System Fields
The system field sy-subrc is set to 0 when a function module is called. If a non-class-based exception is raised that was handled by the assignment of a value, sy-subrc is set to this value. After the registration of an update function module using CALL FUNCTION ... IN UPDATE TASK, however, sy-subrc is undefined.
Notes
◈ Unlike method calls, there are no different syntax variants for static and dynamic calls of function modules. They can, however, be distinguished as follows
◈ In a static function module call, a known static function module is specified as a character literal or as a constant and the parameter is passed statically.
◈ In a dynamic function module call, the name of the function module is specified in a variable and the parameter is passed dynamically. This is possible in general function module calls.
◈ CALL CUSTOMER-FUNCTION is another variant for calling obsolete functino module exits.
Security Note
If the name of a program unit is specified dynamically when it is called, and this name is passed to a program from outside, the result is a serious security risk. Any names passed to a program from outside must be checked thoroughly before being used in calls. The system class CL_ABAP_DYN_PRG, for example, can be used to do this. See Dynamic Calls.
2.5.1 CALL FUNCTION func
Syntax
CALL FUNCTION func { parameter_list
| parameter_tables }.
Effect
This statement calls the function module specified in func. The name func must be a character-like data object containing the name of a function module permitted by the package check in uppercase letters when the statement is executed. Each function module in AS ABAP has a unique name, which is why do not need to specify the function group. The following can be specified for func:
◈ Literal or constant
If the data object func is specified as a character literal or as a constant, it is evaluated as a statically specified object by tools such as the extended program check or the where-used list.
◈ Variable
If the data object func is specified as a variable, it is specified only dynamically and the content is not evaluated statically.
When the statement is executed, func is not evaluated until runtime (in both cases). More specifically, the types of the parameters are not known until runtime.
The additions parameter_list or parameter_tables are used to assign (statically or dynamically) actual parameters to the formal parameters of the function module and return codes to the non-class-based exceptions.
Security Note
If the name of a program unit is specified dynamically when it is called, and this name is passed to a program from outside, the result is a serious security risk. Any names passed to a program from outside must be checked thoroughly before being used in calls. The system class CL_ABAP_DYN_PRG, for example, can be used to do this. See Dynamic Calls.
Exceptions
Handleable Exceptions
CX_SY_NO_HANDLER
Runtime Error: UNCAUGHT_EXCEPTION
CX_SY_DYN_CALL_ILLEGAL_FUNC
◈ Cause: The called function is known but not active.
Runtime Error: CALL_FUNCTION_NOT_ACTIVE
◈ Cause: The called function is unknown.
Runtime Error: CALL_FUNCTION_NOT_FOUND
CX_SY_DYN_CALL_ILLEGAL_TYPE
◈ Cause: The type of the actual parameter does not meet the requirements of the function interface.
Runtime Error: CALL_FUNCTION_CONFLICT_GEN_TYP
◈ Cause: The actual parameter does not have the length expected by the function.
Runtime Error: CALL_FUNCTION_CONFLICT_LENG
◈ Cause: The actual parameter does not have the type expected by the function.
Runtime Error: CALL_FUNCTION_CONFLICT_TYPE
◈ Cause: Only valid functions can be called in the update.
Runtime Error: CALL_FUNCTION_NO_VB
◈ Cause: An actual parameter does not meet the alignment requirements of the corresponding formal parameter.
Runtime Error: CALL_FUNCTION_WRONG_ALIGNMENT
CX_SY_DYN_CALL_PARAM_MISSING
◈ Cause: The function expects a parameter not specified by the caller.
Runtime Error: CALL_FUNCTION_PARM_MISSING
CX_SY_DYN_CALL_PARAM_NOT_FOUND
◈ Cause: The caller specified a parameter not recognized by the function.
Runtime Error: CALL_FUNCTION_PARM_UNKNOWN
Calling Function Modules
This example demonstrates how a function module is called.
Source Code
REPORT demo_call_function.
CLASS demo DEFINITION.
PUBLIC SECTION.
CLASS-METHODS main.
ENDCLASS.
CLASS demo IMPLEMENTATION.
METHOD main.
DATA carrier TYPE s_carr_id VALUE 'LH'.
DATA: itab TYPE spfli_tab,
wa LIKE LINE OF itab.
cl_demo_input=>request( CHANGING field = carrier ).
CALL FUNCTION 'READ_SPFLI_INTO_TABLE'
EXPORTING
id = carrier
IMPORTING
itab = itab
EXCEPTIONS
not_found = 1
OTHERS = 2.
CASE sy-subrc.
WHEN 1.
MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
INTO DATA(msg).
cl_demo_output=>display( msg ).
LEAVE PROGRAM.
WHEN 2.
cl_demo_output=>display(
'Undefined error in function module' ).
LEAVE PROGRAM.
ENDCASE.
cl_demo_output=>display( itab ).
ENDMETHOD.
ENDCLASS.
START-OF-SELECTION.
demo=>main( ).
Description
The function module READ_SPFLI_INTO_TABLE reads all data from the database table SPFLI where the key field CARRID matches the import parameter id and passes this data into the internal table itab. If no suitable data can be found, the exception NOT_FOUND is raised using MESSAGE ... RAISING. Otherwise, the table is passed to the caller as an export parameter.
The actual parameters carrier and itab in the program above have the same data types as the corresponding interface parameters of the function module. The exception NOT_FOUND is handled and the function module displays the same message text as if it were not handled.
2.5.2 CALL FUNCTION - parameter_list
Syntax
... [EXPORTING p1 = a1 p2 = a2 ...]
[IMPORTING p1 = a1 p2 = a2 ...]
[TABLES t1 = itab1 t2 = itab2 ...]
[CHANGING p1 = a1 p2 = a2 ...]
[EXCEPTIONS [exc1 = n1 exc2 = n2 ...]
[error_message = n_error]
[OTHERS = n_others]].
Additions
1. ... EXPORTING p1 = a1 p2 = a2 ...
2. ... IMPORTING p1 = a1 p2 = a2 ...
3. ... TABLES t1 = itab1 t2 = itab2 ...
4. ... CHANGING p1 = a1 p2 = a2 ...
5. ... EXCEPTIONS exc1 = n1 exc2 = n2 ... OTHERS = n_others
6. ... EXCEPTIONS ... error_message = n_error ...
Effect
With the exception of the addition EXCEPTIONS, these additions assign the actual parameters a1, a2, ... to the formal parameters p1, p2, ... or t1, t2, ... of the called function module. All data objects (and some expressions) whose data type matches the typing of the appropriate formal parameter can be specified as actual parameters. With the exception of calculation expressions specified for input parameters, each formal parameter inherits all properties of the assigned actual parameter when called. Non-class-based exceptions can be handled using the addition EXCEPTIONS. The order of the additions is fixed.
A handleable exception is raised whenever a formal parameter is incorrect and the name of the function module is specified by a constant or as a character literal. Unlike in method calls, static checks are performed only by the extended program check and not by the syntax check. If the name of the function module is specified by a variable, the specification of an incorrect formal parameter is ignored at runtime.
Note
The formal parameters and non-class-based exceptions of a function module are defined as its parameter interface in Function Builder.
Addition 1
... EXPORTING p1 = a1 p2 = a2 ...
Effect
This addition assigns actual parameters to the input parameters of the called function module. EXPORTING can be used to assign actual parameters to the optional input parameters. It must be used to assign actual parameters to the non-optional input parameters. When using pass by reference, a reference to an actual parameter is passed when the call is made; when using pass by value, the content of an actual parameter is assigned to the corresponding formal parameter.
a1, a2, ... are general expression positions. In other words, functions and expressions can be passed as actual parameters, alongside data objects. Special rules apply in this case.
Notes
◈ No substring access is possible after an actual parameter of type string or xstring specified after EXPORTING.
◈ Unlike in method calls, types cannot be specified generically (#) when a constructor expression is specified. This is because the typing of the parameters is not determined until runtime.
Addition 2
... IMPORTING p1 = a1 p2 = a2 ...
Effect
This addition assigns actual parameters to the output parameters of the called function module. IMPORTING can be used to assign actual parameters to all output parameters, but this is not mandatory. In pass-by-reference, a reference is passed to an actual parameter when the call is made. In pass-by-value, the content of an output parameter is assigned to the actual parameter in question only if the function module is completed without errors.
Note
Unlike in method calls, no writable expressions and no inline declarations can be specified.
Addition 3
... TABLES t1 = itab1 t2 = itab2 ...
Effect
This addition assigns actual parameters to the table parameters of the called function module. If TABLES is used, internal tables itab1, itab2, ... must be assigned to all non-optional table parameters t1, t2, ... of the called function module. These internal tables are optional for all optional table parameters. For itab1, itab2, ... , only standard tables can be specified. The data is passed using a reference (with the exception of RFC). If a specified table itab1, itab2, ... has a header line, this is also passed. Otherwise, the header line of the corresponding table parameter t1, t2, ... is initial after the call.
Addition 4
... CHANGING p1 = a1 p2 = a2 ...
Effect
This addition assigns actual parameters to the input/output parameters of the called function module. CHANGING can be used to assign actual parameters to the optional input/output parameters. It must be used to assign actual parameters to the non-optional input/output parameters. When using pass by reference, a reference to an actual parameter is passed when the call is made; when using pass by value, the content of an actual parameter is assigned to the corresponding formal parameter. In pass by value, the modified content of an input/output parameter is assigned to the actual parameter in question only if the function module is completed without errors.
Note
Unlike in method calls, no writable expressions can be specified.
Addition 5
... EXCEPTIONS exc1 = n1 exc2 = n2 ... OTHERS = n_others
Effect
EXCEPTIONS can be used to assign return codes to non-class-based exceptions exc1 exc2 ... declared in the parameter interface. Each exception exc1 exc2 ... that the caller wants to handle must be assigned to a directly specified number n1 n2 .... All numbers between 0 and 65535 can be specified. The behavior outside of this range is undefined.
By specifying OTHERS as the last item after EXCEPTIONS, all exceptions can be assigned not listed explicitly in exc1 exc2... a common return code, by assigning a number n_others. The same return code can be assigned to different exceptions (including OTHERS). The behavior when an exception is raised is as follows:
◈ If the statement RAISE or MESSAGE RAISING is used to raise an exception exc1 exc2 ... (to which a return code is assigned) the procedure is ended immediately, any output parameters or return codes passed by value are canceled, and the number n1 n2 ... assigned to the exception is available to be evaluated in sy-subrc .
◈ If the call of an exception raised by RAISE does not assign a return code, the program terminates with a runtime error.
◈ If the call of an exception raised by MESSAGE RAISING does not assign a return code, the message is sent and the system continues in accordance with the message type.
If no exception is raised, a call sets sy-subrc to 0.
The addition EXCEPTIONS cannot be specified in the call if RAISING is used to declare class-based exceptions in the parameter interface of the called procedure.
When a function module is called, the extended program check responds only if a specified exception is not declared in its interface. This is not checked while the program is being executed.
Notes
◈ For the addition EXCEPTIONS. CALL FUNCTION also has an obsolete short form, in which the return code = n can be omitted after a specified exception. If an exception is raised, the value 1 is assigned to sy-subrc implicitly. The return code must always be specified explicitly, however.
◈ If the value 0 is assigned to an exception, this indicates that the caller wants to ignore this exception. If the exception is raised in the function module, no runtime error occurs, but the exception cannot be handled.
◈ Information about the behavior of class-based exceptions in function modules can be found in Class-Based Exceptions in Procedures.
Addition 6
... EXCEPTIONS ... error_message = n_error ...
Effect
If the predefined exception error_message is specified after EXCEPTIONS, all messages
◈ that are sent using the statement MESSAGE without the addition RAISING,
◈ that are sent using the statement MESSAGE RAISING because no return code is assigned to them,
◈ that are sent by the ABAP runtime environment
during function module processing are affected as follows:
◈ Messages of the type S, I, or W are not sent but are flagged in the log in background processing.
◈ Messages of the type E and A raise the exception error_message and set sy-subrc to n_error. The message class, message type, message number, and the contents of possible placeholders for the MESSAGE statement are in the fields sy-msgid, sy-msgno, sy-msgty, and sy-msgv1, ... sy-msgv4. With messages of the type A, the statement ROLLBACK WORK is also executed explicitly. For information about behavior in background processing, see messages in background processing.
◈ Messages of the type X are not affected. As always, they cause a program termination with a short dump.
Notes
◈ When handling messages with the predefined exception error_message, it does not make a difference whether the message is sent in the current function module or in a module that is called by this function module. Unlike the exceptions raised by the statement RAISE, messages sent using the statement MESSAGE are propagated across calling levels.
◈ The following situations can arise for the statement MESSAGE RAISING within the called function module:
◈ If a return code is assigned to the exception specified after RAISING, the exception is handled independently of error_message and sy-subrc is set to this value.
◈ If no return code is assigned to the exception specified after RAISING and error_message is specified, the sent message is affected as specified above.
◈ If no return code is assigned to the exception specified after RAISING and error_message is not specified, the message is sent in accordance with its type.
◈ When continuing with a program after handling a type A message, note that a complete ROLLBACK WORK was carried out, and not just a database rollback.
◈ The statement ROLLBACK WORK is executed when messages of type A are caught using error_message, and is therefore forbidden in updates and when processing subroutines after PERFORM ON COMMIT or PERFORM ON ROLLBACK and also produces runtime errors.
◈ When programs are executed, the ABAP runtime environment can also send messages, for example when the automatic checks on screen input are performed. These messages are caught using error_message in the same way as messages sent using MESSAGE.
Example
Calling the function module GUI_DOWNLOAD for saving the content of an internal table to a file on the current presentation server. The name of the function module is specified as an untyped character literal, which is the most frequent type of specification in static parameter assignment.
CONSTANTS path TYPE string VALUE `c:\temp\`.
DATA: line TYPE c LENGTH 80,
text_tab LIKE STANDARD TABLE OF line,
fleng TYPE i.
...
CALL FUNCTION 'GUI_DOWNLOAD'
EXPORTING
filename = path && `text.txt`
filetype = 'ASC'
IMPORTING
filelength = fleng
TABLES
data_tab = text_tab
EXCEPTIONS
file_write_error = 1
invalid_type = 2
no_authority = 3
unknown_error = 4
OTHERS = 10.
CASE sy-subrc.
WHEN 1.
...
...
ENDCASE.
2.5.3 CALL FUNCTION - parameter_tables
Syntax
... [PARAMETER-TABLE ptab]
[EXCEPTION-TABLE etab] ...
Additions
1. ... PARAMETER-TABLE ptab ...
2. ... EXCEPTION-TABLE etab ...
Effect
These additions use the special internal tables ptab and etab to assign actual parameters to the formal parameters of the function module and return values to the non-class-based exceptions.
Addition 1
... PARAMETER-TABLE ptab ...
Effect
PARAMETER-TABLE can be used to assign actual parameters to all formal parameters of the called function module. ptab expects a sorted table of table type ABAP_FUNC_PARMBIND_TAB or of row type ABAP_FUNC_PARMBIND from the type group ABAP. When the statement CALL FUNCTION is executed, the table must contain exactly one row for each non-optional formal parameter; this row is optional for each optional formal parameter. The table columns are:
◈ NAME of type c and length 30
for the name of the corresponding formal parameter in uppercase letters. If a nonexistent formal parameter is specified, a handleable exception is raised.
◈ KIND of type i
for the category of the formal parameter. KIND must have the value of one of the following constants of the type group ABAP:
- ABAP_FUNC_EXPORTING for input parameters
- ABAP_FUNC_IMPORTING for output parameters
- ABAP_FUNC_TABLES for table parameters
- ABAP_FUNC_CHANGING for input/output parameters
If the category specified from the caller perspective does not match the actual category of the formal parameter, a handleable exception is raised.
◈ VALUE of type REF TO data
as a pointer to an appropriate actual parameter. The data object to which the reference variable in VALUE points is assigned to the formal parameter specified in NAME.
◈ TABLES_WA of type REF TO data
as a pointer to a suitable work area if the column KIND contains the value ABAP_FUNC_TABLES. If TABLES_WA is not initial, the data object to which the reference variable in TABLES_WA points is passed to the header line of the table parameter specified in NAME.
The columns NAME and KIND form the unique key of the table ptab.
Addition 2
... EXCEPTION-TABLE etab ...
Effect
EXCEPTION-TABLE can be used to assign return values to exceptions of the called function module that are not marked as exception classes in Function Builder. etab expects a hashed table of table type ABAP_FUNC_EXCPBIND_TAB or of row type ABAP_FUNC_EXCPBIND from the type group ABAP. The table can contain exactly one row for each non-class-based exception of the function module when the statement CALL FUNCTION is executed. The table columns are:
◈ NAME of type c and length 30
for the name of the corresponding exception or error_message, or OTHERS in uppercase letters.
◈ VALUE of type i
for the number value that is available in sy-subrc after the exception specified in NAME is handled
◈ MESSAGE of type REF TO data
(not currently used)
The column NAME is the unique key of table etab.
Example
Calls the function module GUI_DOWNLOAD with dynamic pass by parameter The name of the function module is specified in the string func and the interface is supplied with data using the internal tables ptab and etab.
DATA: line TYPE c LENGTH 80,
text_tab LIKE STANDARD TABLE OF line,
filename TYPE string,
filetype TYPE c LENGTH 10,
fleng TYPE i.
DATA: func TYPE string,
ptab TYPE abap_func_parmbind_tab,
etab TYPE abap_func_excpbind_tab.
func = 'GUI_DOWNLOAD'.
filename = 'c:\temp\text.txt'.
filetype = 'ASC'.
ptab = VALUE #( ( name = 'FILENAME'
kind = abap_func_exporting
value = REF #( filename ) )
( name = 'FILETYPE'
kind = abap_func_exporting
value = REF #( filetype ) )
( name = 'DATA_TAB'
kind = abap_func_tables
value = REF #( text_tab ) )
( name = 'FILELENGTH'
kind = abap_func_importing
value = REF #( fleng ) ) ).
etab = VALUE #( ( name = 'OTHERS' value = 10 ) ).
CALL FUNCTION func
PARAMETER-TABLE ptab
EXCEPTION-TABLE etab.
CASE sy-subrc.
WHEN 1.
...
...
ENDCASE.
2.6 PERFORM
General Subroutine Call
1. PERFORM subr_identifier [parameter_list].
Registration of Subroutines
2. PERFORM subr ON { {COMMIT [LEVEL idx]} | {ROLLBACK} }.
Effect
Calling or Registering Subroutines.
Subroutines can be called statically and dynamically, internally and externally. Parameters can only be passed if they are called statically. Also, subroutines can be registered for execution at the end of an SAP LUW.
Note: Subroutines are obsolete. Do not create new subroutines in new programs. Methods should be used instead. Subroutines created in existing programs for internal modularization can continue to be called. Whenever possible, avoid calling subroutines of other programs externally.
2.6.1 PERFORM - general
Syntax
PERFORM subr_identifier [ parameter_list].
Effect
This statement calls the subroutine specified with the name subr_identifier and assigns the actual parameters specified in parameter_list to the formal parameters of the subroutine.
Notes
◈ Subroutines are obsolete. Do not create new subroutines in new programs. Subroutines created in existing programs for internal modularization can continue to be called. Whenever possible, avoid calling subroutines of other programs externally.
◈ Information about the behavior of class-based exceptions in subroutines can be found in Class-Based Exceptions in Procedures.
Exceptions
Handleable Exceptions
CX_SY_NO_HANDLER
◈ Siehe Klassenbasierte Ausnahmen in Prozeduren.
Runtime Error: UNCAUGHT_EXCEPTION
CX_SY_PROGRAM_NOT_FOUND
◈ Cause: The specified program was not found.
Runtime Error: LOAD_PROGRAM_NOT_FOUND
◈ Cause: The specified program cannot exist because the program name is longer than 40 characters.
Runtime Error: PERFORM_PROGRAM_NAME_TOO_LONG
CX_SY_DYN_CALL_ILLEGAL_FORM
◈ Cause: The specified subroutine was not found.
Runtime Error: PERFORM_NOT_FOUND
◈ Cause: The specified index was too small.
Runtime Error: PERFORM_INDEX_0
◈ Cause: The specified index was negative.
Runtime Error: PERFORM_INDEX_NEGATIVE
◈ Cause: The specified index was too large.
Runtime Error: PERFORM_INDEX_TOO_LARGE
CX_SY_DYN_CALL_PARAM_MISSING
◈ Cause: The called FORM expects more parameters than were specified.
Runtime Error: PERFORM_PARAMETER_MISSING
CX_SY_DYN_CALL_PARAM_NOT_FOUND
◈ Cause: More parameters were specified than expected by FORM.
Runtime Error: PERFORM_TOO_MANY_PARAMETERS
CX_SY_DYN_CALL_ILLEGAL_TYPE
◈ Cause: In parameter passing using the addition STRUCTURE, the addressing offsets do not match in the actual and target structures.
Runtime Error: PERFORM_BASE_WRONG_ALIGNMENT
◈ Cause: The deep components contained in the actual and target structures cannot be passed to each other. This error occurs only in parameter passing using STRUCTURE.
Runtime Error: PERFORM_CAST_DEEP_MISMATCH
Cause: When passing a generically defined type to the form, a type conflict occurred.
Runtime Error: PERFORM_CONFLICT_GENERIC_TYPE
◈ Cause: The table type of the actual parameter does not match the table type of the parameter defined in the form.
Runtime Error: PERFORM_CONFLICT_TAB_TYPE
◈ Cause: The type of the actual parameter does not match the type of parameter defined in the form.
Runtime Error: PERFORM_CONFLICT_TYPE
◈ Cause: The actual parameter occupies less memory space than the target parameter defined in the form. This error occurs only in parameter passing using STRUCTURE.
Runtime Error: PERFORM_PARAMETER_TOO_SHORT
◈ Cause: In parameter passing using the addition STRUCTURE, the fragment views of the actual and target parameters do not match.
Runtime Error: PERFORM_CONFLICT_UC_STRUCT
◈ Cause: When the form is called, an internal table is expected as the actual parameter.
Runtime Error: PERFORM_TABLE_REQUIRED
◈ Cause: A hashed table was passed to a parameter defined using TABLES.
Runtime Error: PERFORM_STD_TAB_REQUIRED
2.6.1.1 PERFORM - subr_identifier
Syntax
... subr
| {subr|(sname) IN PROGRAM [prog|(pname)] [IF FOUND]}
| {n OF subr1 subr2 ...} ...
Alternatives:
1. ... subr ...
2. ... subr|(sname) IN PROGRAM [prog|(pname)] [IF FOUND] ...
3. ... n OF subr1 subr2 ...
Effect
These names are used in the statement PERFORM to specify the called program and the ABAP program in which it is defined.
Note: As well as the alternatives shown here, there is another obsolete form of the external subroutine call.
Alternative 1
... subr ...
Effect
When specified directly, subr calls any subroutine of the current program using its name declared in the statement FORM. The subroutine must exist.
Alternative 2
... subr|(sname) IN PROGRAM [prog|(pname)] [IF FOUND] ...
Effect
If specified, this is used to call any subroutine of the current program or of another program. The subroutine and the program can be specified as follows:
◈ subr
Subroutine specified directly as subr.
◈ (sname)
Specifies the subroutine as the content of a character-like data object sname. The data object sname must contain the name of the subroutine in uppercase letters.
◈ prog
Specifies the program directly as prog (static external subroutine call).
◈ (pname)
Specifies the program as the content of a character-like data object pname (dynamic external subroutine call). The data object pname must contain the name of the program in uppercase letters. The following can be specified for pname:
◈ Literal or constant
If the data object pname is specified as a character literal or as a constant, it can be evaluated statically and the specified program is identified as the used object.
◈ Variable
If the data object pname is specified as a variable, it is specified only dynamically and the content is not evaluated statically.
When the statement is executed, pname is not evaluated until runtime (in both cases).
If an external subroutine is statically specified, the syntax check does not check whether the specified program and subroutine exist. Only the extended program check registers any nonexistent programs or subroutines as errors by default. This also applies to names specified as constants or literals. If the addition IF FOUND is specified, the extended program check also skips the check.
If the statically or dynamically specified subroutine or program does not exist at runtime, a handleable exception of the class CX_SY_DYN_CALL_ILLEGAL_FORM or CX_SY_PROGRAM_NOT_FOUND is raised by default. If the addition IF FOUND is specified, the statement PERFORM is skipped.
If the specified program exists, it is loaded, if required, into the internal session and scanned for the specified subroutine. The event LOAD-OF-PROGRAM is not triggered. If the subroutine is available, the event LOAD-OF-PROGRAM is triggered (if not already triggered) and then the subroutine is executed.
Notes
◈ External calls of subroutines are almost completely obsolete. Instead of subroutines, methods and function modules can be used as explicit functional interfaces of a program.
◈ Furthermore, external calls of subroutines are critical, since there is usually no static way of determining which program groups are assigned to the master program.
◈ If no further addition is specified apart from IN PROGRAM (no IF FOUND, no parameter list), the program name can be omitted and is added implicitly with the name of the current program.
Security Note
If the name of a program unit is specified dynamically when it is called, and this name is passed to a program from outside, the result is a serious security risk. Any names passed to a program from outside must be checked thoroughly before being used in calls. The system class CL_ABAP_DYN_PRG, for example, can be used to do this.
Alternative 3
... n OF subr1 subr2 ...
Effect
This specification selects a subroutine subr of the current program from a list. The list subr1 subr2 ... can contain up to 256 directly specified subroutines. n must be a numeric data object containing a number between 1 and the specified number of subroutines when the statement is executed. The subroutine subr is called, whose list position is in n. In this variant, it is not possible to specify parameter_list and only subroutines without a parameter interface can be called.
Example
This example calls n internal subroutines subr_1 through subr_n successively from a list.
DATA n TYPE i.
...
DO n TIMES.
PERFORM sy-index OF subr_1 subr_2 ... .
ENDDO.
FORM subr_1.
...
ENDFORM.
FORM subr_2.
...
ENDFORM.
...
2.6.2 PERFORM - parameter_list
Syntax
... [TABLES itab1 itab2 ...]
[USING a1 a2 ...]
[CHANGING a1 a2 ...].
Additions
1. ... TABLES itab1 itab2 ...
2. ... USING a1 a2 ...
3. ... CHANGING a1 a2 ...
Effect
These additions assign actual parameters to the formal parameters from the parameter interface for the subroutine subr. All data objects whose data type matches the typing of the corresponding formal parameter can be specified (see Check Typing) as actual parameters. Each formal parameter assumes all the properties of the actual parameter assigned to it when it is called. The order of the additions is fixed.
Addition 1
... TABLES itab1 itab2 ...
Effect
If the addition TABLES is specified, each table parameter t1 t2 ... for the subroutine called that is defined with the addition TABLES of the statement FORM must be assigned an internal table itab as the actual parameter. The assignment of the actual parameters to the formal parameters takes place using their positions in the lists t1 t2 ... and itab1 itab2 ... .
Only standard tables can be specified for itab. The data is passed using a reference. If a specified table itab has a header line, this is also passed; otherwise, the header line in the corresponding table parameter t is blank when it is called.
Note
The use of table parameters in the interface for subroutines is obsolete but a large number of subroutines have not yet been converted to appropriately typed USING or CHANGING parameters, so that they must still be supplied with data by the addition TABLES of the statement PERFORM.
Example
Static call of the internal subroutine select_sflight while passing a table parameter.
PARAMETERS: p_carr TYPE sflight-carrid,
p_conn TYPE sflight-connid.
DATA sflight_tab TYPE STANDARD TABLE OF sflight.
...
PERFORM select_sflight TABLES sflight_tab
USING p_carr p_conn.
...
FORM select_sflight TABLES flight_tab LIKE sflight_tab
USING f_carr TYPE sflight-carrid
f_conn TYPE sflight-connid.
SELECT *
FROM sflight
WHERE carrid = @f_carr AND
connid = @f_conn
INTO TABLE @flight_tab.
ENDFORM.
Addition 2
... USING a1 a2 ...
Addition 3
... CHANGING a1 a2 ...
Effect
If the additions USING and CHANGING are specified, a type-friendly actual parameter a1 a2 ... must be assigned to each of the formal parameters u1 u2 ... and c1 c2 ... defined with the same additions of the statement FORM. The actual parameters specified after USING and CHANGING form a single shared list. They are assigned to the formal parameters after the position in the shared list. The type of parameter pass is defined by the additions USING and CHANGING of the statement FORM. The addition USING must be before CHANGING. Otherwise, the assignment of the actual parameters to the additions USING and CHANGING is ignored by the statement PERFORM. It is also irrelevant whether only one or both of the additions is specified.
Notes
◈ For program documentation purposes, it is best to specify the additions USING and CHANGING in the statement FORM in accordance with the definition of the parameter interface.
◈ No substring access is possible after an actual parameter of type string or xstring specified after USING or CHANGING.
◈ When passing an actual parameter to a USING parameter typed as a reference variable, an up cast is not possible.
◈ A USING parameter declared for pass by reference behaves in the same way as a CHANGING parameter, which however means that the content of the actual parameter could be changed in an illegal way.
◈ A USING parameter defined for pass by value should have a syntax, which behaves for the calling program like a parameter defined for pass by reference.
Example
The following five PERFORM statements mean the same but only the fourth is recommended, since it is the only one that documents the interface of the subroutine called.
DATA: a1 TYPE string,
a2 TYPE string,
a3 TYPE string,
a4 TYPE string.
PERFORM test USING a1 a2 a3 a4.
PERFORM test CHANGING a1 a2 a3 a4.
PERFORM test USING a1 CHANGING a2 a3 a4.
PERFORM test USING a1 a2 CHANGING a3 a4.
PERFORM test USING a1 a2 a3 CHANGING a4.
...
FORM test USING p1 TYPE string
p2 TYPE string
CHANGING value(p3) TYPE string
value(p4) TYPE string.
...
ENDFORM.
Event handlers are special methods that are declared by the addition FOR EVENT ... OF of the statements METHODS and CLASS-METHODS. Instead being called directly using explicit method calls, they are usually called indirectly using RAISE EVENT. They can only be executed if an event handler is registered using SET HANDLER.
◉ RAISE EVENT
Syntax
RAISE EVENT evt [EXPORTING p1 = a1 p2 = a2 ...].
Addition:
... EXPORTING p1 = a1 p2 = a2 ...
Effect
This statement can only be used in methods. It raises the event evt. evt is the name to be specified directly for an event that must be declared with the statement EVENTS or CLASS-EVENTS directly in the same class, in a superclass, or in an implemented interface.
After the event is raised, all event handlers that were registered for this event with the statement SET HANDLER are executed. The execution order is undefined and can change while the program is being executed. After the event handlers have been executed, the system continues with the method after RAISE EVENT.
Addition
... EXPORTING p1 = a1 p2 = a2 ...
Effect
If the addition EXPORTING is used, actual parameters a1 a2 ... can be assigned to all optional formal parameters p1 p2... of the event evt and must be assigned to all non-optional formal parameters. The values of the actual parameters are passed to the event handlers whose definition specifies the formal parameters after the addition IMPORTING of the statements [CLASS-]EVENTS.
a1, a2, ... are general expression positions. In other words, functions and expressions can be passed as actual parameters, alongside data objects. Special rules apply in this case.
Notes
1. To avoid endless recursion, a maximum of 1023 further events can be raised using RAISE EVENT in event handling.
2. If the formal parameter sender is defined for an event handler, this is automatically supplied with the reference to the raising object when instance events are raised. It cannot be specified explicitly after EXPORTING.
3. If there is an exception in an event handler, event handling is canceled. For a class-based exception, the control is then returned to the raising object. See Class-Based Exceptions in Event Handlers.
Example
Raises an instance event e1. An actual parameter must be assigned to the non-optional formal parameter p1.
CLASS c1 DEFINITION.
PUBLIC SECTION.
EVENTS e1 EXPORTING value(p1) TYPE string
value(p2) TYPE i OPTIONAL.
METHODS m1.
ENDCLASS.
...
CLASS c1 IMPLEMENTATION.
METHOD m1.
...
RAISE EVENT e1 EXPORTING p1 = '...'.
...
ENDMETHOD.
ENDCLASS.
Exceptions
Non-Handleable Exceptions
1. Cause: RAISE EVENT statements nested too deeply.
Runtime error: RAISE_EVENT_NESTING_LIMIT
◉ SET HANDLER
Syntax Forms
1. SET HANDLER handler1 handler2 ... FOR oref|{ALL INSTANCES}
[ACTIVATION act].
2. SET HANDLER handler1 handler2 ... [ACTIVATION act].
Effect
This statement registers or deregisters the event handlers handler for the corresponding instance events or static events.
System Fields
| sy-subrc | Meaning |
| 0 | All specified handlers could be registered or deregistered. |
| 4 | At least one of the specified handlers could not be registered, as it is already registered for the same event. |
| 8 | At least one of the specified handlers could not be deregistered, as it is not registered for the event in question. |
Notes
● The statement SET HANDLER manages internally different system tables that associate the event raisers and event handlers with each in single registrations, mass registrations, and registrations of static events. Each registration represents a row in one of the system tables assigned to the event raiser. A handler can only appear once in a particular system table, but can appear in multiple system tables, that is, it can be registered for different events. When the system raises an event using RAISE EVENT, it evaluates the corresponding system tables and calls the event handlers registered there.
● The order of the calls of registered event handlers is not defined and can change during program runtime. To get a fixed order of different method calls, these can be called in one event handler.
● When registering an instance method, a reference to the corresponding object in the relevant table is created and then deleted again when deregistering. With respect to the garbage collector, such a reference has the same effect as a reference in a reference variable. Objects registered as handlers are not deleted as long as they are registered, that is, they are not deregistered using the ACTIVATION addition. If a raising instance is deleted by the garbage collector, the corresponding system table is also deleted and as a result, its registrations are reversed.
● If the statement SET HANDLER registers the current handler again for the current event in event handling, it is not clear whether the registration is ignored by the current event handler. This can produce endless recursions and should be avoided.
Example
Registration of event handlers for two instance events and a static event. In the first statement SET HANDLER, a static event handler h1 and an instance method h2, are registered for the instance events e1 and e2 of the object referenced by the reference variable trigger. In the second statement SET HANDLER, an instance method h3 is registered for the static event ce1 of the class c1.
CLASS c1 DEFINITION.
PUBLIC SECTION.
EVENTS e1.
CLASS-EVENTS ce1.
ENDCLASS.
CLASS c2 DEFINITION INHERITING FROM c1.
PUBLIC SECTION.
EVENTS e2.
ENDCLASS.
CLASS c3 DEFINITION.
PUBLIC SECTION.
CLASS-METHODS h1 FOR EVENT e1 OF c1.
METHODS: h2 FOR EVENT e2 OF c2,
h3 FOR EVENT ce1 OF c1.
ENDCLASS.
...
DATA: trigger TYPE REF TO c2,
handler TYPE REF TO c3.
SET HANDLER: c3=>h1 handler->h2 FOR trigger,
handler->h3.
Exceptions
Non-Handleable Exceptions
● Cause: Unable to register any more handlers.
Runtime Error: SET_HANDLER_DISP_OVERFLOW
● Cause: Handlers of instance methods need the FOR addition.
Runtime Error: SET_HANDLER_E_NO_FOR
● Cause: Event handler was registered for a static event.
Runtime Error: SET_HANDLER_FOR_CE
● Cause: The raiser of an event must not be NULL.
Runtime Error: SET_HANDLER_FOR_NULL
● Cause: The handler of an event must not be NULL.
Runtime Error: SET_HANDLER_HOBJ_NULL
1. SET HANDLER - FOR
Syntax
SET HANDLER handler1 handler2 ... FOR { oref |{ALL INSTANCES} }
[ACTIVATION act].
Additions
1. ... FOR oref
2. ... FOR ALL INSTANCES
3. ... ACTIVATION act
Effect
This statement registers the event handlers handler1 handler2 ... for the associated instance events of the objects specified after FOR. The addition ACTIVATION can be used to deregister event handlers or perform a dynamic registration.
An event handler is raised if the associated instance event is raised using RAISE EVENT in an object for which it is registered. An event handler handler can be specified as follows, where the names have the same meaning as in the explicit method call:
◈ meth
◈ oref->meth
◈ class=>meth
Methods meth can be specified from the same class or from other classes defined as instance event handlers using the addition FOR EVENT evt OF {class|intf} of the statements [CLASS-]METHODS. No event handlers for static events can be specified. At least one name must be specified.
The type class or intf specified after FOR EVENT OF in the definition of an instance event handler defines the objects whose events it can handle. Single objects or all handleable objects can be specified after FOR.
Addition 1
... FOR oref
Effect
This addition registers or deregisters the event handlers of the list handler1 handler2 ... for exactly one object. oref is an object reference that must point to an object whose events can be handled by the specified event handlers. The class of the object must be class or a subclass of class, or must implement the interface intf directly or through a superclass.
oref is a functional operand position.
Example
Registers an event handler for an ALV event.
CLASS demo DEFINITION.
PUBLIC SECTION.
METHODS main.
PRIVATE SECTION.
DATA itab TYPE TABLE OF scarr.
METHODS handle_double_click
FOR EVENT double_click OF cl_salv_events_table.
ENDCLASS.
CLASS demo IMPLEMENTATION.
METHOD main.
DATA alv TYPE REF TO cl_salv_table.
...
TRY.
cl_salv_table=>factory(
IMPORTING r_salv_table = alv
CHANGING t_table = itab ).
SET HANDLER handle_double_click FOR alv->get_event( ).
CATCH cx_salv_msg.
...
ENDTRY.
ENDMETHOD.
METHOD handle_double_click.
...
ENDMETHOD.
ENDCLASS.
Addition 2
... FOR ALL INSTANCES
Effect
This addition registers or deregisters the event handlers of the list handler1 handler2 ... for all objects whose events they can handle. These are all objects whose classes are either class or the subclass of class, or which implement the interface intf directly or through a superclass. A registration of this type is also valid for all raising instances created after the statement SET HANDLER.
Addition 3
... ACTIVATION act
Effect
A single-character text-like field act can be specified after the addition ACTIVATION. If act has a value "X" (default value), the event handlers handler are registered; however, if act has the value " ", the registration of the event handlers handler is canceled. A single registration cannot, however, be deregistered using mass deregistration. Conversely, individual raising objects cannot be excluded from registration after a mass registration.
Note
As long as the registration of an instance method as an event handler for an instance event is not canceled using ACTIVATION " " or all raising instances are deleted, the associated object cannot be deleted by the garbage collector, since it is still used by the runtime environment.
2. SET HANDLER - static_event
Syntax
SET HANDLER handler1 handler2 ... [ACTIVATION act].
Addition:
... ACTIVATION act
Effect
This statement registers the event handlers handler1 handler2 ... for the associated static events. The addition ACTIVATION can be used to deregister event handlers or perform a dynamic registration.
An event handler is executed if the associated static event is raised using RAISE EVENT. The list handler1 handler2 ... has the same form as for instance events, but can only contain event handlers for static events declared using CLASS EVENTS.
The event that can be handled by an event handler for static events is already defined uniquely by its definition using the statement [CLASS-] METHODS. The addition FOR (required when registering or deregistering instance event handlers to determine the raising instances) cannot be specified. The registration or deregistration of an event handler for static events is independent of the instance and is applies globally to the current internal session.
Addition
... ACTIVATION act
Effect
The same applies to the syntax and semantics of the addition ACTIVATION as to the statement SETHANDLER for instance events.
Note
As long as the registration of an instance method as an event handler for a static event is not canceled using ACTIVATION " ", the associated object cannot be deleted by the garbage collector, since it is still used by the runtime environment.
2.3 Call Event Blocks
Event blocks are processing blocks in an ABAP program that are executed when the corresponding event occurs in the ABAP runtime environment. The following statements can be used to trigger the events (program-driven) in two cases:
2.3.1 SET USER-COMMAND (classic list processing)
2.3.2 PUT (in logical databases)
If implemented, the event blocks are also called. Both statements are effectively obsolete. You can find more information about them in the relevant sections.
3. Exiting Program Units
Program units that can be exited using ABAP statements are:
◈ Complete ABAP programs
◈ Processing blocks
◈ Loops
3.1 Exiting Programs
This section contains the statement LEAVE PROGRAM used for exiting programs.
Apart from LEAVE PROGRAM, the following statements also leave a program that calls other programs without returning to the caller after the call:
◈ LEAVE TO TRANSACTION
◈ SUBMIT without AND RETURN Leaving certain processing blocks can also cause the entire program to be exited implicitly.
LEAVE PROGRAM
Syntax
LEAVE PROGRAM.
Effect
This statement ends the current main program immediately and deletes its internal session, including all loaded programs, instances, and their data.
The statement LEAVE PROGRAM can appear anywhere within any processing block. It ends the program regardless of the program or object or the program group of the internal session in which it is executed.
The runtime environment responds to the LEAVE PROGRAM statement depending on how the main program was called in the internal session:
◈ If the main program was called using CALL TRANSACTION, SUBMIT AND RETURN, or CALL DIALOG, the runtime environment returns to the calling program after the call position. If the main program was called with CALL DIALOG, the output parameters of the dialog module are passed to the calling program.
◈ If the main program was called using LEAVE TO TRANSACTION or using a transaction code from within a dynpro, the runtime environment returns to the position at which the first program in the current call sequence was called.
◈ If the main program was called using SUBMIT without the addition AND RETURN, the runtime environment returns to the position at which the calling program was started.
Notes
◈ If procedures are still registered when a program is exited in the current SAP-LUW, the SAP-LUW is ended without calling or rolling back the procedures. Registered update function modules remain in the database, but can no longer be executed. In this case, the statement COMMIT WORK or ROLLBACK WORK should be executed explicitly before leaving the program.
◈ The statement LEAVE without additions is obsolete.
Processing blocks can be implicitly exited by
◈ normal exiting
or program-driven exiting, using these statements:
◈ RETURN
◈ EXIT
◈ CHECK
◈ STOP
◈ CHECK SELECT-OPTIONS (obsolete, for logical databases only)
◈ REJECT (obsolete, for logical databases only)
The onward flow of the program depends on the type of processing block.
In addition to the statements described here, statements that call other units without returning to the caller after the call is made, also end their processing block. These include:
◈ LEAVE [TO] SCREEN
◈ LEAVE LIST-PROCESSING
◈ LEAVE TO TRANSACTION
◈ SUBMIT without AND RETURN
Messages and raised exceptions can also end processing blocks.
Note
Exiting a procedure by pressing RETURN (or EXIT or CHECK) is the error-free way to end the procedure. Formal parameters for which the pass by value is defined are not passed to the assigned actual parameters only if the procedure terminates after an error (if an exception is raised or a message is sent).
3.2.1 Regular Exiting of a Processing Block
A processing block is exited in a regular when reaching its end. For processing blocks that are concluded using an END statement, this is the end. Event blocks that are not concluded explicitly with a statement have an implicit conclusion after their last statement.
Depending on the processing block exited, the runtime environment behaves as follows:
◈ In procedures, the program returns to after the point where they were called. The output parameters for which pass by values are defined are passed to the bound actual parameters.
◈ In dialog modules, the program returns to after the point in the dynpro flow logic where they were called.
◈ In event blocks, the control is given back to the runtime environment and the current process of the runtime environment continues with the program execution.
Syntax
RETURN.
Effect
This statement ends the current processing block immediately. It can appear at any point in a processing block and ends this block regardless of the statement block or control structure in which the block appears.
After the processing block is exited, the runtime environment responds in the same way as when the processing block is exited in a regular way (with the exception of LOAD-OF-PROGRAM and the reporting event blocks START-OF-SELECTION and GET). In particular, the output parameters of procedures are passed to the bound actual parameters.
◈ The event block LOAD-OF-PROGRAM cannot be exited using RETURN.
◈ After the reporting event block START-OF-SELECTION is exited using RETURN, the runtime environment does not trigger any more reporting events; instead, it calls the list processor directly to display the basic list.
◈ After the reporting event block GET is exited using RETURN, subordinate nodes in the hierarchical structure of the associated logical database are no longer processed. The logical database reads the next row of the current node or next higher node, if it has reached the end of the hierarchy level.
Note
The statement RETURN is provided for exiting processing blocks early but correctly. However, since RETURN behaves differently in GET events than when the event block is exited as usual, the statement REJECT should be used here, which was designed especially for this purpose.
Example
Exits the method show_list using RETURN if one of the formal parameters required (structure or data_tab) is initial.
METHOD show_list.
"IMPORTING structure TYPE c
" data_tab TYPE ANY TABLE.
DATA alv_list TYPE REF TO cl_gui_alv_grid.
IF structure IS INITIAL OR
data_tab IS INITIAL.
RETURN.
ENDIF.
CREATE OBJECT alv_list
EXPORTING i_parent = cl_gui_container=>screen0.
alv_list->set_table_for_first_display(
EXPORTING i_structure_name = structure
CHANGING it_outtab = data_tab ).
CALL SCREEN 100.
ENDMETHOD.
3.2.3 EXIT - processing_block
Syntax
EXIT.
Effect
If the statement EXIT is located outside a loop, the statement immediately terminates the current processing block.
After the processing block is exited, the runtime environment responds in the same way as when the processing block is exited in a regular way (with the exception of the event block LOAD-OF-PROGRAM and the reporting event blocks START-OF-SELECTION and GET). In particular, the output parameters of procedures are passed to the bound actual parameters.
◈ The event block LOAD-OF-PROGRAM cannot be exited using EXIT.
◈ After the reporting event blocks START-OF-SELECTION and GET have been exited using EXIT, the runtime environment does not trigger any more reporting events; instead, it calls the list processor directly to display the basic list.
3.2.4 CHECK - processing_block
Syntax
CHECK log_exp.
Effect
If the statement CHECK is located outside a loop and log_exp is false, the statement terminates the current processing block. Any logical expression can be specified for log_exp.
After the processing block is exited, the runtime environment proceeds in the same way as when the processing block is exited in the normal way (with the exception of the event block LOAD-OF-PROGRAM and the reporting event block GET). In particular, the output parameters of procedures are passed to the bound actual parameters.
◈ The event block LOAD-OF-PROGRAM cannot be exited using CHECK.
◈ After the reporting event block GET is exited using CHECK, subordinate nodes in the hierarchical structure of the associated logical database are no longer processed. The logical database reads the next row of the current node or next higher node, if it has reached the end of the hierarchy level.
Notes
◈ In a procedure (method, function module, subroutine), CHECK log_exp works outside a loop in the same way as:
IF NOT log_exp.
RETURN.
ENDIF.
◈ A further variant of the statement CHECK for exiting processing blocks is CHECK SELECT-OPTIONS that can only be used in GET event blocks for logical databases.
Syntax
STOP.
Effect
The statement STOP is only to be used in executable programs and in the following event blocks:
◈ AT SELECTION-SCREEN (without additions)
◈ START-OF-SELECTION
◈ GET
These event blocks are exited using STOP and the runtime environment raises the event END-OF-SELECTION.
Note
The statement STOP cannot be used in methods and raises a non-handleable exception when processing dynpros called using CALL SCREEN, during a LOAD-OF-PROGRAM event, and in programs not called using SUBMIT.
Example
Ends the event block GET sbook of the logical database F1S, after max postings have been issued, and branches to END-OF-SELECTION.
NODES: sflight,
sbook.
DATA: bookings TYPE i,
max TYPE i VALUE 100.
GET sflight.
cl_demo_output=>next_section( |{ sflight-carrid } | &&
|{ sflight-connid } | &&
|{ sflight-fldate }| ).
GET sbook.
bookings = bookings + 1.
cl_demo_output=>write( |{ sbook-bookid } | &&
|{ sbook-customid }| ).
IF bookings = max.
STOP.
ENDIF.
END-OF-SELECTION.
cl_demo_output=>line( ).
cl_demo_output=>display( |First { bookings } bookings| ).
◈ Cause: The statement STOP was executed outside the process flow for an executable program.
Runtime Error: STOP_NO_REPORT
◈ Cause: The statement STOP was executed during the process flow for a dynpro and therefore outside the permitted events.
Runtime Error: STOP_WITHIN_CALLED_DYNPRO
3.3 Exiting Loops
You can use the following statements to exit loops:
3.3.1 EXIT - loop
Syntax
EXIT.
Effect
If the EXIT statement is specified within a loop, it exits the loop by ending the current loop pass. The program flow resumes after the closing statement in the loop.
Note
Outside of a loop, the statement EXIT exits the current processing block (see EXIT - Processing Block). EXIT, however, should only be used within loops.
Example
Exits a loop using EXIT if the loop index sy-index is greater than a number limit.
DATA limit TYPE i VALUE 10.
DO.
IF sy-index > limit.
EXIT.
ENDIF.
cl_demo_output=>write( |{ sy-index } | ).
ENDDO.
cl_demo_output=>display( ).
3.3.2 CHECK - loop
Syntax
CHECK log_exp.
Effect
If the statement CHECK is executed in a loop and log_exp is incorrect, the statement CHECK immediately terminates the current loop pass and the program continues with the next loop pass. Any logical expression can be specified for log_exp.
Notes
◈ Inside a loop, CHECK log_exp functions just like
IF NOT log_exp.
CONTINUE.
ENDIF.
◈ Outside a loop, the statement CHECK exits the current processing block (see CHECK), however it is best to only use CHECK inside loops.
Example
A loop pass is exited using CHECK if the loop index sy-index is an odd number.
DATA remainder TYPE i.
DO 20 TIMES.
remainder = sy-index MOD 2.
CHECK remainder = 0.
cl_demo_output=>write_text( |{ sy-index }| ).
ENDDO.
cl_demo_output=>display( ).
3.3.3 CONTINUE
Syntax
CONTINUE.
Effect
The CONTINUE statement can only be used in loops. If it is used, the current loop pass is ended immediately and the program flow is continued with the next loop pass.
Example
A loop pass is exited using CONTINUE if the loop index sy-index is an odd number.
DATA remainder TYPE i.
DO 20 TIMES.
remainder = sy-index MOD 2.
IF remainder <> 0.
CONTINUE.
ENDIF.
cl_demo_output=>write_text( |{ sy-index }| ).
ENDDO.
cl_demo_output=>display( ).
No comments:
Post a Comment