Properties of interface parameters
When an interface parameter p1,
p2... is defined in the Function Builder, properties are determined for the parameter, which
are reflected in the syntax of parameters and table_parameters.
Syntax of parameters
... { VALUE(p1) | p1 }
{TYPE [REF TO] type} | {LIKE struc-comp} | {STRUCTURE struc}
[OPTIONAL|{DEFAULT def1}]
{ VALUE(p2) | p2 }
{TYPE [REF TO] type} | {LIKE struc-comp} | {STRUCTURE struc}
[OPTIONAL|{DEFAULT def2}]
...
Syntax of table_parameters
... p1 {TYPE itab_type} | {STRUCTURE struc} [OPTIONAL]
p2 {TYPE itab_type} | {STRUCTURE struc} [OPTIONAL]
...
The syntax and semantics of VALUE,
TYPE, OPTIONAL, and
DEFAULT are mainly the same as in the definition of method interfaces with
[CLASS-]METHODS. The option of typing interface parameters with LIKE or STRUCTURE is obsolete.
Type of parameter passing
There are two ways in which parameters can be passed:
pass by reference and
pass by value. Pass by value is selected
in the Function Builder by selecting pass by value, and in the above syntax, differs from pass by reference by the specification of VALUE(
).
- In pass by reference, the formal parameter points directly to the actual parameter, so that changes to the formal parameters have an immediate effect on the actual parameter.
- In pass by value, when the function module is called, the formal parameter is created as a copy
of the actual parameter (in IMPORTING and
CHANGING parameters), or initial (in EXPORTING
parameters) in the stack. In CHANGING and
EXPORTING parameters, the formal parameter is copied to the actual parameter when returning from the function module.
Note the following for the different types of parameter:
- In IMPORTING, EXPORTING,
and CHANGING parameters, pass by reference and pass by
value are possible, in TABLES parameters, only pass by reference is possible.
- IMPORTING parameters passed by reference cannot be overwritten in the function module.
- EXPORTING parameters passed by reference are not initialized
when the function module is called. For this reason, no read access to these parameters should be permitted before the first write access.
Typing of interface parameters
The parameter interface of a function module is public across the system. Interface parameters can therefore
only be typed with reference to data types from the ABAP Dictionary or from the public visible section
of global classes. In the Function Builder, interface parameters can be typed by the selection of either
TYPE, TYPE REF TO or
LIKE. While typing with TYPE is also displayed as
TYPE in the above syntax, typing with LIKE is not
only represented by LIKE, but also by STRUCTURE.
- Typing with TYPE [REF TO] is the recommended typing
for interface parameters of function modules. It takes place when TYPE
or TYPE REF TO is selected in the Function Builder. For
IMPORTING, EXPORTING, and CHANGING parameters, any
predefined ABAP type (complete or generic), or any data type from
the ABAP Dictionary or from the public visibility section of a global class can be specified after
TYPE. After TYPE REF TO, the generic data type data, a non-generic data type, or an
object type can be specified and the interface parameter is typed as a
reference variable. In
TABLES parameters, only one table type itab_type can be specified from the ABAP Dictionary of table type 'standard table' with a flat line type. The
typing check is performed in the same way as for subprograms and methods.
- Typing with LIKE is obsolete. It takes place if an
elementary component of a flat structure (or database table) struc-comp
from the ABAP Dictionary is specified after LIKE in the Function
Builder. The typing check is the same as for the specification of components after TYPE, with the exception that the
fractional portion is not taken into account for packed numbers.
- Typing with STRUCTURE is obsolete. It takes place if a
flat structure structure (or database
table) struc from the ABAP Dictionary is specified after LIKE in the Function Builder. This structure is then forced on the formal parameter
(casting), and it is possible to access
the individual components. For a formal parameter typed with STRUCTURE, a connected actual parameter must be a structure. In non-
Unicode programs, the actual parameter must be suitably
aligned (in pass by reference) and its
length must exactly match the length of the forced structure struc,
with the exception of table parameters. For table parameters, the length of the actual parameter must be at least the length of the structure. In Unicode programs, the
Unicode fragment view of a
structured actual parameter must match that of struc. For an elementary actual parameter this must be character-type and flat.
Note
If a component of a global program structure in the function group of a function module has exactly
the same identity (structure name struc and component
comp) as the component of a structure in the ABAP Dictionary
specified after LIKE, LIKE
refers to the component of the structure defined in the function group. This leads to a warning in a
syntax check. In contrast, TYPE always refers to types in the ABAP Dictionary.
Optional parameters
IMPORTING, CHANGING,
and TABLES parameters can be made optional by the selection
of optional in the Function Builder.
EXPORTING parameters are always optional. IMPORTING and CHANGING parameters can be assigned a replacement parameter
(default value in the Function Builder). In the above syntax,
this is expressed using the additions OPTIONAL or
DEFAULT. For an optional parameter, no actual parameter must be entered when the function
module is called. While a formal parameter with the addition OPTIONAL
is then initialized according to its type, a formal parameter with the addition
DEFAULT assumes the value and type of the replacement parameter def1 def2 ....
If no actual parameter is specified for a generically typed formal parameter with the addition OPTIONAL when it is called, the type of the formal parameter is completed according to
fixed rules.
Note
Within a function module, the logical expression
IS SUPPLIED can be used to check if an optional formal parameter was assigned an actual parameter when it was called.
Global Parameters
The formal parameters of a function module can be made known globally in the Function Builder through
the path Edit → Interfaces → Globalize parameters.
Then the field Global is selected in the properties of the function module. The formal parameters of a global interface have the following properties:
- All parameters that are fully typed and are defined for being passed as a value are treated as if
global data objects of the same name were declared in the Top Include. This means they are visible in
the same function group and, when the function module is exited, they retain their value. When the function
module is called, all the parameters of a global interface are initialized or they are assigned their default value.
- All the other parameters are handled in such a way as if global data objects with the same name
were declared in the Top Include (for table parameters, these are two in each case: one for the table
body and one for the header row). However, these can only be used during execution of the function module.
In other words, they are visible in the entire function group, but they can only be accessed during
execution of the function module. If one such parameter is accessed outside of function module execution,
a runtime error GETWA_NOT_ASSIGNED is triggered since these parameters are implemented internally through field symbols to which a data object is assigned only during execution of the function module.
In the function group, no global data objects with the same name must be created like a global parameter.
If several function modules of a function group have global interfaces, parameters with the same name must be defined identically.
Note
The use of global interface parameters is obsolete and, in new function modules, interfaces should generally not be globalized. ________________________________________________________________________