Ansicht
Dokumentation
ABAPCALL_FUNCTION_DESTINATION_PARA - CALL FUNCTION DESTINATION PARA
RFUMSV00 - Advance Return for Tax on Sales/Purchases General Data in Customer MasterThis documentation is copyright by SAP AG.
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$]$] $}
$| ${ $[PARAMETER-TABLE ptab$]
$[EXCEPTION-TABLE etab$] $} ...
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 ... $[MESSAGE ...$]
6. PARAMETER-TABLE ptab
7. EXCEPTION-TABLE etab
Effect
Parameter passing for sRFC. These additions are used to assign actual parameters to the formal parameters of the synchronously called remote function module and return values to non-class-based exceptions. These additions essentially have the same 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, is cast 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 to which no actual parameter is assigned 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.
Notes
- If a remote-enabled function module is not called using RFC, parameter passing behaves in the same way as in a general function module call and the corresponding exceptions are raised for incorrect formal parameters and unsuitable actual parameters.
- If possible, the extended
program check checks the passing of parameters and reports any incorrect formal parameters and unsuitable actual parameters as errors.
Addition 1
EXPORTING p1 = a1 p2 = a2 ...
Addition 2
IMPORTING p1 = a1 p2 = a2 ...
Effect
The following differences apply to the additions EXPORTING and IMPORTING:
- 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, tables with deep line types, structures, and strings can be passed.
- When passing internal tables with non-unique table keys, the order of the duplicate lines in relation to these keys is not retained.
Addition 3
TABLES t1 = itab1 t2 = itab2 ...
Effect
When using TABLES to pass data to table parameters, the difference is that only tables with flat line types and no secondary table key can be passed and any existing header lines are not passed.
Notes
- As long as basXML is not configured as the RFC protocol, the classic binary RFC protocol is used implicitly for TABLES parameters, and not the XML format xRFC, which is otherwise used for deep types. Passing internal tables using the TABLES parameters can therefore be considerably faster in this case than with other parameters, depending on the data passed.
- basXML is now
recommended as a uniform 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 TABLES is therefore only required for RFMs for which performance is currently critical.
Addition 4
CHANGING p1 = a1 p2 = a2 ...
Effect
With respect to the addition CHANGING, the same differences apply as to the additions EXPORTING and IMPORTING.
Addition 5
EXCEPTIONS exc1 = n1 exc2 = n2 ... $[MESSAGE ...$]
Effect
The addition EXCEPTIONS is used to perform classic non-class-based exception handling, which works in essentially the same way as in general function module calls. In addition, however, the special exceptions SYSTEM_FAILURE and COMMUNICATION_FAILURE can be specified here to handle the exceptions raised by the RFC interface itself.
An optional MESSAGE addition can also be specified after these exceptions. If one of the special classic exceptions system_failure or communication_failure is raised, the first line of the associated short dump is placed in the smess or cmess field. This field must be flat and character-like.
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
Notes
- The specification of error_message after EXCEPTIONS is 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 MESSAGE is specified.
- Class-based exception handling in RFCs is not possible in the current release track.
Addition 6
PARAMETER-TABLE ptab
Addition 7
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 dynamically.
The description and usage of the internal tables is the same as for the general call of function modules, but the RFC-specific rules apply that are described above for static parameter passing.
Furthermore, the column message with type REF TO data of exception table etab can be used as pointer to a character-like field for the special exceptions system_failure or communication_failure. If such an exception occurs, the character like field is filled with the same content as smess or cmess specified behind MESSAGE in static parameter passing.
Notes
- The column message of exception table etab is not used for general function calls.
- The character-like field referred by column message can also be of type string here.
RFC - Dynamic Parameter Passing in sRFC
General Material Data rdisp/max_wprun_time - Maximum work process run time
This documentation is copyright by SAP AG.
Length: 12571 Date: 20240416 Time: 233958 sap01-206 ( 178 ms )
