ABAPCALL_FUNCTION_DESTINATION_PARA - CALL FUNCTION DESTINATION PARA

CL_GUI_FRONTEND_SERVICES - Frontend Services   CL_GUI_FRONTEND_SERVICES - Frontend Services  
This documentation is copyright by SAP AG.

CALL FUNCTION - DESTINATION parameter_list

Short Reference



Syntax

... [EXPORTING  p1 = a1 p2 = a2 ...]
    [IMPORTING  p1 = a1 p2 = a2 ...]
    [CHANGING   p1 = a1 p2 = a2 ...]
    [TABLES     t1 = itab1 t2 = itab2 ...]
    [EXCEPTIONS [exc1 = n1 exc2 = n2 ...]
               [system_failure = ns [MESSAGE smess]]
                [communication_failure = nc [MESSAGE cmess]]
                [resource_failure      = nr]
                [OTHERS = n_others]].

Additions

1. EXPORTING p1 = a1 p2 = a2 ...

2. IMPORTING  p1 = a1 p2 = a2 ...

3. CHANGING   p1 = a1 p2 = a2 ...

4. TABLES     t1 = itab1 t2 = itab2 ...

5. EXCEPTIONS exc1 = n1 exc2 = n2 ...

Effect

These additions are used to assign actual parameters to the formal parameters of the remotely calledfunction module, and return values to exceptions that are not class-based. These additions have the same basic meaning as they do in generalfunction module calls.

Unlike general function module calls, however, RFC generally ignores the interface to incorrectly specifiedformal parameters. In addition, the addition EXCEPTIONS, when specified, controls whether class-basedexception handling is performed or not (from Release 7.1, EhP1). These differences and others are described in the following.

Addition 1

EXPORTING p1 = a1 p2 = a2 ...

Addition 2

IMPORTING  p1 = a1 p2 = a2 ...

Addition 3

CHANGING   p1 = a1 p2 = a2 ...

Effect

The following differences apply to the additions EXPORTING, IMPORTING, and CHANGING:

  • In character-like formal parameters, the actual parameter can be shorter than 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.
  • Referencevariables cannot be passed directly or as components of deep structures. As in general function module calls, however, you are allowed to pass tables withdeep row types, structures, and strings.
  • When passing internal tables with non-unique tablekeys, the order of the duplicate rows in relation to these keys is not retained.


Addition 4

TABLES  t1 = itab1 t2 = itab2 ...

Effect

When using TABLES to pass data to table parameters, the difference is that only tables withflat row types and nosecondary table key can be passed, and that an existingheader line is not passed.

Notes

  • As long as basXML is not configured as theRFC protocol,the classic binary RFC protocol is used implicitly for TABLES parameters, and not the XML formatxRFC, which is otherwise used for deep types. Passing internal tables using the TABLES parameters can therefore be considerably faster in this case (depending on the data passed) than with other parameters.
  • basXMLis now recommended as the common format for all types of RFC communication. basXML currently still offersbetter performance than xRFC. However, this will change in the future. The TABLES addition is therefore only required for RFMs for which performance is currently critical.


Addition 5

EXCEPTIONS exc1 = n1 exc2 = n2 ...

Effect

The EXCEPTIONS addition controls which type of exception handling is used for RFC.

We recommend that you use class-based exception handling, where all class-based exceptions raised whenthe RFC is executed are transported to the caller where they can be handled in a TRYcontrol structure. In addition to the class-based exceptions that can be triggered by a function module called remotely, the RFC interface can trigger additional exceptions, which are all subclasses ofCX_REMOTE_EXCEPTION:

  • Exceptions of class CX_REMOTE_APPL_ERROR. Theseexceptions are caused by error situations that arise when a remotely called function is executed on the RFC server. These error situations can be caused by runtime errors or sending amessage of type "A", "E", or "X".
  • Exceptions of class CX_CONNECTIVITY_ERROR.These exceptions are triggered by all errors that occur when connections are being established, when resources are being assigned, or in the communication layer.

If a remotely called function module triggers a classic exception during class-based exception handling, this is mapped to a class-based exception from theCX_CLASSIC_EXCEPTION class, whose attribute EXCEPTION_NAME contains the name of the exception.

Non-class-based exception handling is essentially the same as with general function module calls, with the difference that thespecial exceptionsSYSTEM_FAILURE, COMMUNICATION_FAILURE, and RESSOURCE_FAILURE can also be specified to handle the exceptionsthat are triggered by the RFC interface itself. An optional MESSAGE addition can also be specifiedafter these exceptions. If one of the special classic exceptions system_failure or communication_failure is raised, the first line of the associatedshortdump is inserted in the smess or cmess field. This field which must be a flat character-likefield. If a remotely called function module raises a class-based exception during non-class-based exceptionhandling, the exception is not transported. Instead, it causes a runtime error on the RFC server, which triggers a database rollback, and raises the predefined classic exception SYSTEM_FAILURE.

Notes

  • Prior to Release 7.1, EhP1, class-based exception handling was not supported. Classic exception handlingwas always used. If the EXCEPTIONS addition was not specified, every exception resulted in a runtime error on the RFC client.
  • Specifying error_message after EXCEPTIONS has no effect in the RFC.
  • If the classic exception SYSTEM_FAILURE is raised when amessage of type "A", "E", or "X" is sent, the smess field contains the message short text when MESSAGE is specified.

Example

See Exception Handling in RFC.


CL_GUI_FRONTEND_SERVICES - Frontend Services   Fill RESBD Structure from EBP Component Structure  
This documentation is copyright by SAP AG.


Length: 10738 Date: 20120518 Time: 195907     triton ( 318 ms )