RFC Destination

When a function module is called via the RFC interface, the calling program has to specify the connection parameters in the form of a destination. The destination determines the connection type, the partner program, and the target system. It is administrated using transaction SM59 and handles many different connection types, such as TCP/IP and connections to other SAP systems. With synchronous RFC, you have to explicitly specify the destination. A destination can also be specified for asynchronous and transactional RFC. If a destination is not specified in these cases, the function module is called via the RFC interface in the same system. The following conditions apply, depending on the execution type:

• For synchronous and asynchronous calls, the call parameter values are transferred directly to the function module. For transactional calls, the call parameter values are temporarily stored in the database until they are executed.

• With asynchronous calls, it is not possible to connect to external systems (TCP/IP connections in transaction SM59).

• For synchronous calls, the results of the called function are transferred directly. For asynchronous calls, the RECEIVE command can be used to cause the results to be received in callback routines. For transactional calls, the results cannot be transferred.

• With synchronous and asynchronous calls, the server of the called function module has to be available.

In order for a function module to be called via the RFC interface, it has to be marked in its attributes as 'remote-enabled', and its interface parameters can only be transferred using value transfer. Its table parameters are likewise implicitly transferred by value transfer. Remote-enabled function modules can be called in the system in which they are defined either using the RFC interface, or as normal function modules using the CALL FUNCTION command without any of its additions (DESTINATION, STARTING NEW TASK and IN BACKGROUND TASK|UNIT). To call them via the RFC interface, either the special destination "NONE" (see below) has to be specified, or an asynchronous or transactional RFC without a destination has to be executed.

All possible destinations are stored in the RFCDES database table. This table's content is administrated in transaction SM59. When a function module is remotely called from within an ABAP program, the destination after the DESTINATION addition in the CALL FUNCTION command is specified as a key value of the RFCDEST column in the RFCDES database table. The corresponding row of the database table contains all the parameters for communicating with external systems, which are specified in transaction SM59.

There are two predefined destinations that do not have to be maintained in transaction SM59:

• Destination " NONE" causes the function module to be started on the same application server as the calling program, but via the RFC interface and in its own context. This destination can be used for all types of calls.

• Destination " BACK" can be used in a remotely called function module and refers back to the caller. It can only be used in function modules that are called synchronously. The destination " BACK" can be used to call every remote-enabled function module of the calling system in all three execution types. With synchronous callbacks, the corresponding function group in the internal mode of the calling program is loaded, if it does not already exist there. The existing RFC connection is used for the callback.

Besides the destinations created in transaction SM59, and the two predefined destinations, destinations can also be specified directly in the form "hostname_sysid_sysnr", where " hostname" is the name of the application server, " sysid" is the name of an ABAP system, and " sysnr" is the system number, as they are displayed in (for example) transaction SM51.