SAP Systems

RFC functionality between two SAP systems or between an external system and an SAP system has been available since Release 2.1 of the SAP system.

Up to Release 3.0 of the SAP system, RFCs are executed directly using the application server; in later versions, the load can be distributed across application servers by using a pre-activated message server.

The RFC offers a variety of “service qualities“. These are:

· Synchronous RFC

· Asynchronous RFC without further service promise

· Transactional RFC, which guarantees one-time execution and is offered as of Version 3.0

· Queue RFC, which guarantees one-time execution while assuring the call sequence and is offered as of Version 3.1.

Note for Linking to R/2

In the R/2 system, function modules are available as a concept for modularizing ABAP programs as of Version 5.0. From Version 5.0D, function modules can also be called and executed remotely.

Destinations are stored and maintained in the R/2 System using the transaction SM59 in table TRFCD.

In the case of an RFC between an R/2 System in an IBM environment and another SAP system or external systems, an SAP Gateway must be running on a machine that supports SNA LU6.2 protocol for the IBM host. The SNA product must also be installed on this machine, and the SAP Gateway must be able to run in conjunction with this product. This is necessary, because some SNA products are not compatible on the same machines.

The following SNA products are currently supported:

· SNA services or SNA server on IBM-AIX systems

· SNAplusLink on HP-UX systems

· Communication Manager on OS/2

· SNA Server on Windows NT systems

· SNALink SNA peer-to-peer 8.0 on SUN systems

· TRANSIT-SERVER and TRANSIT-CPIC on SNI-SINIX systems.

External Systems

External systems must support TCP/IP.

· MS Windows platforms:	Microsoft standard
· UNIX and Linux platforms:	TCP/IP
· OS/390:	TCP/IP for OS/390 from IBM.
· OS/400:	Manufacturer’s standard.

The RFCSDK contains the RFC API and various test and example programs. For the given platforms, the RFCSDK contains the following libraries and include files:

· saprfc.h	This include file contains all the required data types, structures and declarations of the RFC functions.
· sapitab.h	This include file contains all the functions required to manipulate internal tables
· RFC library	Depending on the platform, the following libraries are required:
	MS Windows:	For Unicode: librfc32u.dll, librfc32u.lib for Compile/Link For Non-Unicode: librfc32.dll and librfc32.lib, for Compile/Link
	UNIX and Linux platforms:	For Unicode: librfcu.a, librfcum.so For Non-Unicode: librfc.a, librfccm.so
	OS/390:	For Unicode: librfcu.o For Non-Unicode: librfc.o
	OS/400:	For Unicode: librfcu.dll For Non-Unicode: librfc.dll

RFC Restrictions

In contrast to the normal function module call, the following restrictions apply to an RFC:

· For each call that is made using synchronous RFC, a database commit is performed. For this reason, a synchronous RFC must not be used between Open SQL statements that open or close a database cursor.

· In a function module that is called remotely, you must not use statements that close the current context and therefore the connection. An example of this is the statement LEAVE PROGRAM, or SUBMIT without the addition RETURN.

· In the case of a synchronous RFC, dynpros and selection screens that are called in a remotely-called function module are displayed in the calling system if the calling program is executed in dialog processing, and if the user defined in the destination has dialog authorization. The screen data is transmitted by the RFC interface to the calling system. In this particular case, you can display lists that are written in a remotely-called function module by using LEAVE TO LIST-PROCESSING.

· As only pass by value is used for the RFC, when exceptions do occur, you can never access interim results when a synchronous RFC is made.

· Information messages are warnings are handled in the same way as status messages.

RFC Trusted/Trusting Systems

You can use transaction SMT1 to define a calling system in the system being called as a trusted system. The system being called is then referred to as a trusting system.

Trusted SAP systems can log on to another SAP system without the need for a password. The existence of trust relations such as this between SAP systems has the following advantages:

· "Single Sign-On" across system boundaries

· No password transfer across the net

· Timeout mechanism for the logon data prevents misuse.

· User-specific logon data for the trusted system is checked.

You can configure multiple SAP systems as mutual trusted systems. When building a trust relationship between two systems, the initiative starts with the called system (server system). Here, users of the calling system who are allowed to make RFC calls by way of a trust relationship of this kind, must be identified in the system being called (trusted users).

Before a trusted system can be defined, a destination for this system must be created in the trusting system. In addition, the RFC users must have the corresponding authorizations in the trusting system (authorization object S_RFCACL). You can check the authorizations for the logged on users in the trusting system in advance, by using the function module AUTHORITY_CHECK_TRUSTED_SYSTEM.

In a trust relationship, the calling system (client system) plays the role of the trusted system, and the called system (server system) plays the role of the trusting system.

RFC Authorization

When a remote call of a function module is made, an automatic authorization check is performed, provided that the profile parameter auth/rfc_authority_check is set to 1. The authorization check uses the authorization object S_RFC to check whether the user defined in the destination has RFC authorization for the function group of the called function module.

In addition to the function groups belonging to the application function modules, authorization object S_RFC must also contain any RFC function groups in order to perform technical processes during communication:

● For tRFC and qRFC calls between two SAP systems: Function groups ERFC and ARFC

● For all RFC calls in external (non-SAP) systems: function group SYST

When a function module is called remotely from within the same system, the automatic authorization check only takes place if the client and user ID are not the same. Across system boundaries, the automatic authorization check is only performed in systems that are not recognized as “trustworthy”. Rating a system as an RFC Trusted/Trusting System is done using transaction SMT1.

The automatic authorization check is made by implicitly calling function module AUTHORITY_CHECK_RFC. If it detects an authorization issue, this function module triggers one of the exceptions defined in its interface, namely USER_DONT_EXIST or RFC_NO_AUTHORITY, thus triggering a runtime error. We recommend that you call the function module AUTHORITY_CHECK_RFC explicitly before a remote call, thus enabling you to handle any exceptions that may arise. If it detects the relevant authorization, the function module does not return an explicit result. Instead, like all function modules that are performed successfully, it sets sy-subrc to 0.

RFC System Fields

As is the case every time a function module is called, when an RFC is made, the system field sy-subrc is initialized in the calling program, or set to the value that is specified in exception handling. In addition, each time a function module is called remotely, the system fields sy-msgid, sy-msgno, sy-msgty and sy-msgv1 to sy-msgv4 are initialized in the calling program. While a remotely-called function module is being executed, if an error message or termination message is sent using the statement Message, then the exception SYSTEM_FAILURE is triggered in the calling program. You can assign a return value to this for the call. When exceptions occur, these system fields are supplied with the properties of the message.

RFC Exceptions

For the external function call, you can use the addition EXCEPTIONS of the statement CALL FUNCTION - RFC (RFC variants) to assign return values to the exceptions defined in the interface of the called function module. Class-based exceptions cannot be propagated to the caller from a remotely-called function module, and have the effect of an exception that cannot be processed.

In addition to the exceptions defined in the interface of the called function module, an external function call may trigger the following predefined exceptions:

· The exception SYSTEM_FAILURE occurs if a runtime error arises during execution of the remotely-called function module.

· The exception COMMUNICATION_FAILURE occurs if the connection cannot be made to the partner system, or if the connection is broken during communication.

We strongly recommend that you assign a return value to these two exceptions for each RFC, and that you process these, otherwise a runtime error may occur in the exception situations described.

RFC Context

Every remote call of a function module that is made using the RFC interface defines a separate context in the target system. The function group of the function module is loaded into an internal session of the context, and is retained. What this means is that, if repeated calls of function modules belonging to the same destination and the same function group are made, the global data of this function group can be accessed collectively. When functions are called in external systems, this behavior is simulated by the API of the RFC library. A connection and its context is retained until it is explicitly closed, or until the calling program is finished. To close a connection explicitly, the function module RFC_CONNECTION_CLOSE can be used, or the API functions RfcAbort and RfcClose.

RFC Performance Profile

When a function module that is defined in a different system to the calling program is called, this process is referred to as a Remote Function Call (RFC). For this type of program communication, RFC interfaces are available. These support function calls between different SAP systems (for example, Web Application Servers) or between an SAP system and an external system. In this process, an RFC client calls the function module, while an RFC server supplies and executes this. The RFC interface performs the following actions:

· Calls and manages the communication routines that are required in order to communicate with the remote system.

· Logs on to and off from the remote system and performs authorization checks for the function group that is used.

· Converts actual parameters into the display required by the remote system, and the other way round. This may also include platform-specific conversions (such as differing code pages or byte sequences). This conversion supports all ABAP data types.

· Handles all errors that occurr during the communication and, if requested, forwards them to the caller.

In the example comprising communication between different SAP systems, two ABAP programs communicate with each other using the RFC interface, whereas in the case of communication between SAP systems and external systems, an ABAP program communicates with a program of a different programming language (C, C++, Visual Basic, Java or .NET).

For communication with programs of different programming languages, RFC libraries are available for all operating systems that are supported by SAP, such as MS Windows, Unix (RS/6000, SUN Solaris, HP-UX), Linux, z/OS (OS/390) and OS400:

· Java Connector (JCo) for Java

· .NET Connector for .NET (C#, VB.NET)

· RFC Software Development Kit (SDK) for C and C++

The following additions to the statement CALL-FUNCTION-RFC effect a Remote Function Call:

· CALL FUNCTION - DESTINATION (synchronous RFC)
If the addition DESTINATION is specified without one of the following two additions, the calling program waits until the remotely-called function has finished.

· CALL FUNCTION - STARTING NEW TASK (asynchronous RFC, aRFC)
With the addition STARTING NEW TASK, the processing of the calling program is continued as soon as the remotely-called function is started, without waiting for it to end. The results can be obtained from callback routines.

· CALL FUNCTION - IN BACKGROUND TASK (transactional RFC, tRFC)
With the addition IN BACKGROUND TASK, the remotely-called function is marked for execution and is started using the statement COMMIT WORK.

RFC Destination

When calling a function module using the RFC interface, the calling program must specify the parameters of the connection in the form of a destination. This destination defines the type of connection, the partner program, and the target system. You can manage it using transaction SM59, and it distinguishes between a variety of connections, such as TCP/IP or SAP connections. For a synchronous RFC, the destination must be specified explicitly. For asynchronous and transactional RFCs, a destination can be specified. If no destination has been specified the function module is called using the RFC interface in the same system. Depending on the type of execution, the following conditions apply:

· For synchronous and asynchronous calls, the values of the call parameters are transferred to the function module directly, whereas in the case of transactional calls, these are stored in the database temporarily until execution.

· For asynchronous calls, no connection to external systems is possible (TCP/IP connections in transaction SM59).

· For synchronous calls, the results of the called function are copied directly. For asynchronous calls, results can be received in callback routines by using the statement RECEIVE, whereas in the case of transactional calls, transferring results is not possible.

· The server of the called function module must be available for synchronous and asynchronous calls.

To be able to call a function module using the RFC interface, the function module in question must be flagged as being remote-capable in its properties, and for its interface parameter, only pass by value is allowed. Even for table parameters, a pass by value is performed implicitly. Within the system in which they are defined, remote-capable function modules can either be called using the RFC interface, or like normal function modules. The normal call is made using the statement CALL FUNCTION without using one of the additions DESTINATION, STARTING NEW TASK or IN BACKGROUND TASK. When making the call using the RFC interface, you must either specify the special destination "NONE" (see below), or you must perform an asynchronous or transactional RFC without specifying a destination.

All the possible destinations are stored in the database table RFCDES, whose content is managed using transaction SM59. When calling a function module remotely from an ABAP program, the destination is specified using addition DESTINATION of the statement CALL FUNCTION, in the form of a key value in column RFCDEST of database table RFCDES. The relevant rows of the database table contain all parameters defined in transaction SM59 that are used for communicating with the external system.

There are two predefined destinationen that do not have to be entered using transaction SM59:

· Destination "NONE" has the effect that the function module is started on the same application server as the calling program, however through the RFC interface and in its own RFC context. This destination is possible for all types of call.

· Destination "BACK" can be used in a function module that is called remotely, and links back to the caller. You can only specify this in function modules that have been called synchronously. Destination "BACK" can be used to call each remote-capable function module of the calling system in all three execution types. For a synchronous callback, the relevant function group is loaded into the internal session of the calling program, if it is not yet available there. The existint RFC connection is used for this callback.

As well as the destinations created in transaction SM59 and the two predefined destinations, you can also specify destinations directly, in the form "hostname_sysid_sysnr". Here, "hostname" refers to the name of the application server, "sysid" is the name of an SAP system, and "sysnr" is the system number, as is displayed using transaction SM51, for example.

RFC in SAP Systems

In all SAP systems, CALL FUNCTION represents an integral part of the ABAP language. This statement executes a function (a function module) in the same system.

REMOTE FUNCTION CALL (RFC) is an extension of CALL FUNCTION in a distributed environment. Existing function modules can be executed using an RFC from a remote system. This is done by adding a DESTINATION clause to the CALL FUNCTION statement:

The destination parameter displays an entry in the RFCDES table (which is defined with transaction SM59). This entry contains all necessary parameters to connect to and log in the destination system.

You can use RFC between two SAP systems.

By using the RFC Library (RFC API), you can also use the functions of the RFC between an SAP system and a C program on different platforms. It is of no significance to the caller whether the remote function is provided in an SAP System or in a C program.

RFC frees the ABAP programmer from having to program his own communications routines. When you make an RFC call, the RFC interface takes care of:

· Converting all parameter data to the representation needed in the remote system. This includes character string conversions, and any hardware-dependent conversions needed (for example, integer, floating point). All ABAP data types are supported.

· Calling the communication routines needed to talk to the remote system.

· Handling communications errors, and notifying the caller, if desired. (The caller requests notification using the EXCEPTIONS parameter of the CALL FUNCTION statement.)

The RFC interface is effectively invisible to the ABAP programmer. Processing for calling remote programs is built into the CALL FUNCTION statement. Processing for being called is generated automatically (in the form of an RFC stub) for every function module registered as remote. This stub serves as an interface between the calling program and the function module.

A distinction is made between an RFC client and RFC server. RFC client is the instance that calls up the Remote Function Call to execute the function that is provided by an RFC server. In the following, the functions that can be executed remotely will be called RFC functions and the functions provided via RFC API will be called RFC calls.

All RFC functions available in a remote RFC server system, which are called by an RFC client, are processed transactionally. This means that after execution of the first RFC function in the RFC server system the complete context (all globally defined variables in the RFC server program or in the main program of a function module) is available for further RFC functions. The RFC connection is closed only

· when the context of the calling ABAP program has ended or

· explicitly by RfcAbort or RfcClose in the external program.

You can either assign an application server directly, or assign it through a message server, as part of a load distribution. This applies to RFCs between two SAP systems and to RFCs between an SAP system and an external system.

To make the execution of RFC functions reliable, safe and independent from the availability of the RFC server or RFC server system, the transactional RFC (tRFC) is available for SAP systems. This ensures that the called function module is executed only once in the RFC server system.

In transactional RFC calls, the data that belongs to an RFC function must first be stored temporarily on the SAP database in the RFC client system. When processing is completed, this must be reported back to the calling ABAP program. Everything else is handled by the tRFC component in the SAP system.

Since a database is not always available on external systems, the link to the tRFC interfaces is implemented such that the client or server programs based on RFC API must take on some administrative functions to ensure that the respective function module is executed only once.

In an SAP system, other SAP systems can be defined as trusted systems. Trusted systems can access the called system (the trusting system) without having to provide a password.
For more information, see Trusted System.

The RFC Interface

A remote function call (RFC) is the call of a function module that runs in a different system to the calling program. Although it is also possible to call a function module in the same system as an RFC, normally RFCs are used when the caller and the called function module run in the same system.

In the SAP system, these functions are provided by the RFC interface system. The RFC interface system enables function calls between two SAP systems, or between an SAP system and an external system.

The RFC- interface system is made up of the following interfaces:

· Calling interface for ABAP programs

· Each ABAP program can call a remote function module using the command CALL FUNCTION...DESTINATION. The parameter DESTINATION informs the SAP system that the called function module runs in a different system to the calling system. RFC communication with the remote system takes place as a part of the CALL FUNCTION command.

· RFC function modules in an SAP system must be proper function modules and must be registered in the SAP system as remote.

· If the calling program and the called program are both ABAP programs, the RFC interface provides both communication partners. The calling program can be any ABAP program, and the called program must be a function module that is registered as remote.

· For more detailed information on calling function modules that are registered as remote, see Calling RFC Function Modules in ABAP.

· For more information on writing function modules that you want to call remotely, see Writing RFC Function Modules in ABAP.

· Interfaces for calling non-ABAP programs

If either the calling program or the called partner is not an SAP program, this program must be programmed in such a way that it can play the role of the other partner in RFC communication.

To support you when implementing RFC partner programs in non-SAP systems, read: Components of the SAP Communication Technology

RFC-supported and GUI-supported interfaces can be used by external programs to call function modules in SAP systems, and execute them in these systems. Likewise, ABAP programs can also use these interfaces to use functions supplied by external programs.