CALL FUNCTION - DESTINATION parameter_list
... [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 ...]
[system_failure = ns [MESSAGE smess]]
[communication_failure = nc [MESSAGE cmess]]
[OTHERS = n_others]].
These additions are used to assign actual parameters to the formal parameters of the remotely called function module, and return values to exceptions that are not class-based. These additions have the same basic meaning as they do in general function module calls.
In the case of RFC, however, the following differences to general function module calls apply:
- Bindings of actual parameters to incorrectly specified formal parameters are ignored.
- Typings are not checked. The content of actual parameters is handled in the remotely called function module and, if possible, casted to the type of the formal parameter. Rules that depend on the typing and the RFC log used apply. For more information, see the RFC documentation on SAP Help Portal.
Each formal parameter is handled implicitly like an optional parameter. Every input parameter or input/output
parameter not assigned an actual parameter is given either its type-dependent initial value or a default value specified explicitly in the definition.
Some other differences for specific additions are described in the following.
- If a remote-enabled function module is not called using the RFC, pass by parameter works like a general function module call and the corresponding exceptions are raised in if formal parameters are incorrect and actual parameters are unsuitable.
If possible, the extended
program check checks the pass by parameter and reports any formal parameters and unsuitable actual parameters as errors.
EXPORTING p1 = a1 p2 = a2 ...
IMPORTING p1 = a1 p2 = a2 ...
The following differences apply to the additions
- In character-like formal parameters, the actual parameter can have a length different from the formal parameter. In the called function module, a shorter actual parameter is filled with blanks on the right in the input and truncated in the output. If the actual parameter is longer, the reverse applies.
- Reference variables cannot be passed directly or as components of deep structures. As in general function module calls, however, it is not possible to pass tables with deep row types, structures, and strings.
When passing internal tables with non-unique table keys, the order of the duplicate rows in relation to these keys is not retained.
TABLES t1 = itab1 t2 = itab2 ...
As long as basXML is not configured as the
RFC protocol, the classic binary RFC protocol is used
TABLESparameters, and not the XML format xRFC, which is otherwise used for deep types. Passing internal tables using the
TABLESparameters can therefore be considerably faster in this case (depending on the data passed) than with other parameters.
basXML is now used as a unified
format for all types of RFC communication. The binary RFC protocol currently still has better performance
than basXML, but this will change in the future. The addition
TABLESis therefore only required for RFMs for which performance is currently critical.
CHANGING p1 = a1 p2 = a2 ...
With respect to the addition
CHANGING, the same differences apply as to the additions
EXCEPTIONS exc1 = n1 exc2 = n2 ...
EXCEPTIONS is used to perform classic
non-class-based exception handling, which works in essentially the same way as general function module calls. In addition, however, the
special exceptions SYSTEM_FAILURE and COMMUNICATION_FAILURE
can be specified to handle the exceptions raised by the RFC interface itself . An optional
addition can also be specified after these exceptions. If one of the special classic exceptions
communication_failure is raised, the first line of the associated
short dump is inserted in
cmess field. This field which must
be a flat character-like field. If a remotely called function module raises a class-based exception
during non-class-based exception handling, this exception is not transported and raises the predefined classic exception SYSTEM_FAILURE instead
If specified after
error_messageis ignored in RFC.
If the classic exception SYSTEM_FAILURE is raised when a
message of type "A", "E", or "X" is sent, the
smess field contains the message short text when
Class-based exception handling in RFCs is not possible in the current release track.