RFC | How to Create & Use It

[Former Member]

Hi Friends,

Can any one give me one complete example of RFC enabled function module? Also explain me how to

use it and in what situations / requirement do we use RFC enabled FM and not BAPIs?

Thanks,

Pradeep

[Former Member]

Hi,

Check the following link:

http://sapmaterial.com/RFCmaterial.html

Regards,

Bhaskar

[Former Member]

Hi,

********************************************************************

Remote Function Calls (RFC) - Introduction

Remote Function Calls allow users to call R/3 function modules or external functions "remotely".

RFC development libraries exist for OS/2, Windows, Windows NT, and for all UNIX platforms supported by SAP. These help you to communicate with external programs (C and C++).

The R/3 Function Builder also contains an RFC generator that you can use to generate external programs and download them onto your frontend system.

In an RFC, a series of tasks is performed automatically:

Data conversion

Logon to the SAP partner system

Conversion of all RFC data types

Control of the communication flow

The following basic conditions apply when you call a function module remotely:

The function module that you call must be flagged as "remote". You set this attribute in the Function Builder. Tools -> ABAP Workbench -> Development -> Function Builder. Note that all parameters in a remotely-callable function module must have a reference field.

The target must be defined (see Defining remote destinations). To do this, choose Tools → Administration, Administration → Network →RFC destinations.

You can execute a function module as follows:

Synvhronously:,,CALL FUNCTION func DESTINATION dest

Asynchronously,,CALL FUNCTION func ... STARTING NEW TASK taskname

Transactionally:,,CALL FUNCTION func... IN BACKGROUND TASK

In a Remote Function Call, there is an RFC client and an RFC server. The RFC client is the instance that calls the function "remotely". The RFC server provides and executes the function.

To ensure that RFC functions are executed on the RFC server regardless of the availablity of the server, you can make the call transactional (see CALL FUNCTION func ... IN BACKGROUND TASK). This buffers the parameters in the R/3 database and they are transferred as a single unit.

See also the information about RFC logon to the target system (remote logon), trusted systems, and the RFC authorization concept.

Typical problems and their solutions:

ABAP runtime error: RAISE_EXCEPTION

Error message CALL_FUNCTION_OBJECT_ID

No ABAP short dump after failed RFC logon

SYSTEM_FAILURE: Screen output without connection to user

RFC destination is incorrect after IP addresses were changed

RFC logon screen appears

Short dumps with error ID RFC_NO_AUTHORITY

Help Documentation

For a comprehensive description of communication interfaces in the SAP environment, refer to Remote Communications.

CALL FUNCTION DESTINATION

Variant 4

CALL FUNCTION func DESTINATION dest.

Extras:

1. The same as with CALL FUNCTION func

2. ... EXCEPTIONS syst_except = rc MESSAGE mess

Effect

Executes the function module from an external source (as a Remote Function Call or RFC); dest can be a literal or a variable.

Depending on the specified destination, the function module is executed in another R/3 or R/2 System. Externally callable function modules must be flagged as such in the Function Builder (of the target system).

Since each destination defines its own program context, further calls to the same or different function modules with the same destination can access the local memory (global data) of these function modules.

To maintain existing destinations, choose Tools → Administration, Administration → Network → RFC destinations.

Note

Note that a database commit occurs at each Remote Function Call (RFC). Consequently, you cannot use Remote Function Calls between pairs of statements that open and close a database cursor (such as SELECT ... ENDSELECT).

Note

See also RFC Logons to the Target System (Remote Logon)

Notes

Special destinations:

The destination NONE refers to the calling system. Function modules called with

CALL FUNCTION func DESTINATION 'NONE' ...

are executed in the system of the calling program, but in their own program context.

You can use the destination BACK if the current program was already called by RFC. Then, BACK refers back to the calling program:

CALL FUNCTION func DESTINATION 'BACK' ...

If the program is not called from a "remote" source, the exception COMMUNICATION_FAILURE is triggered.

Each SAP system has a standard name. This is formed from the host name (e.g. SY-HOST), the system name (SY-SYSID) and the system number (a two-digit number assigned on installation of the application server).

You can use this name as a destination.

For example, you can call the function module func in the system C11 on the host sapxyz with system number 00 as follows:

CALL FUNCTION func DESTINATION 'sapxyz_C11_00' ...

You can also use SAProuter path names as destinations (see also SAProuter documentation).

Note

Parameter passing

When you pass data to an externally called function module, there are some differences to the normal function module call:

With table parameters, only the table itself is passed, not the header line.

If one of the parameters of the interface of an externally called function module is not specified when called, the import parameters are set to their initial value. If no default value was given in the interface definition, TABLES parameters are defined as an empty table and unspecified export parameters are lost.

Note

Passing structured data objects

Since transport to another system may require data conversion, the structure of field strings and internal tables must be known to the runtime system when the call is made. The structure of a field string or internal table is not known if it was passed to the subroutine with the (obsolete) addition STRUCTURE, or if it is a parameter of a function module.

In these cases, external calls can result in a conversion error.

Note

If, during a Remote Function Call, an error occurs in the target system, details of the error message are passed back to the calling system in the following system fields: SY-MSGNO, SY-MSGID, SY-MSGTY, SY-MSGV1, SY-MSGV2, SY-MSGV3, and SY-MSGV4. These fields are initialized before every RFC. If a short dump or a type X message occurs, the short text of the dump is transferred to the caller, and the contents of SY-MSGID, SY-MSGTY, SY-MSGNO, and SY-MSGV1 assigned by the system.

In RFC-enabled function modules, no ABAP statements are allowed that would end the RFC connection (for example, either LEAVE or SUBMIT without the AND RETURN addition).

Note

If an error occurs in the target system, the details are passed to the calling system ( SY-MSGNO, SY-MSGID, SY-MSGTY and SY-MSGV*).

Note

C interface

You can call external function modules from C programs. It is also possible to store function modules in a C program and call them with CALL FUNCTION ... DESTINATION. For this purpose, SAP provides a C interface.

Note

Authorization check

If the instance profile parameter 'auth/rfc_authority_check' is set (to 1), the system automatically performs an RFC authorization check. The authorization check refers to the relevant function group for the function module to be called. If no authorization is found, a runtime error occurs. You can check the authorization in advance with the function module AUTHORITY_CHECK_RFC. If the RFC communication takes place in one system in the same user context - that is, using the same client and user ID - the system does not carry out an RFC authority check. For more information on this topic, see

RFC Authorization Concept

Note

Note that a database commit occurs at each Remote Function Call (RFC). Consequently, you cannot use Remote Function Calls between pairs of statements that open and close a database cursor (such as SELECT ... ENDSELECT).

Note

Please consult Data Area and Modularization Unit Organization documentation as well.

Addition 2

... EXCEPTIONS syst_except = rc MESSAGE mess

Effect

Function module calls with the addition DESTINATION can handle two special system exceptions:

SYSTEM_FAILURE

This is triggered if a system crash occurs on the receiving side.

COMMUNICATION_FAILURE

This is triggered if there is a connection or communication problem.

In both cases, you can use the optional addition

... MESSAGE mess

to receive a description of the error.

Note

In principle, you should always handle these two system exceptions when the function module is called.

Example

DATA: INFO LIKE RFCSI, "Importing parameter

MSG_TEXT(80) TYPE C. "Message text

...

• Synchronous call to function module RFC_SYSTEM_INFO

CALL FUNCTION 'RFC_SYSTEM_INFO'

DESTINATION 'NONE'

IMPORTING

RFCSI_EXPORT = INFO

EXCEPTIONS

COMMUNICATION_FAILURE = 1 MESSAGE MSG_TEXT

SYSTEM_FAILURE = 2 MESSAGE MSG_TEXT.

IF SY-SUBRC NE 0.

WRITE: MSG_TEXT.

ELSE.

WRITE: 'O.K.'.

ENDIF.

...

Note

The documentation, Typical RFC Problems and Their Solutions, will help you to analyze the errors you encounter.

Exceptions for RFC

Non-Catchable Exceptions

Cause: The called function module has not been released for RFC.

Runtime Error: CALL_BACK_ENTRY_NOT_FOUND

Cause: Destination type is not allowed.

Runtime Error: CALL_FUNCTION_DEST_TYPE

Cause: Missing communication type (I for internal connection, 3 for R/3) when calling an asynchronous RFC

Runtime Error: CALL_FUNCTION_DESTINATION_NO_T

Cause: The destination entered does not exist.

Runtime Error: CALL_FUNCTION_NO_DEST

Cause: The destination entered (in load distribution mode) does not exist.

Runtime Error: CALL_FUNCTION_NO_LB_DEST

Cause: Data received for unknown CPI-C connection.

Runtime Error: CALL_FUNCTION_NO_RECEIVER

Cause: The function module you tried to call is flagged as one that cannot be called remotely.

Runtime Error: CALL_FUNCTION_NOT_REMOTE

Cause: An error occurred when calling the function remotely. This error is logged in the calling system.

Runtime Error: CALL_FUNCTION_REMOTE_ERROR

Cause: The logon data for the user is not complete.

Runtime Error: CALL_FUNCTION_SIGNON_INCOMPL

Cause: The attempt to log on in the form of an internal call to a target system is not valid.

Runtime Error: CALL_FUNCTION_SIGNON_INTRUDER

Cause: RFC from an external program without a valid user ID.

Runtime Error: CALL_FUNCTION_SIGNON_INVALID

Cause: The user tried to log onto the target system without a valid user ID.

Runtime Error: CALL_FUNCTION_SIGNON_REJECTED

The error code signifies the following:

1) Incorrect password or invalid user ID

2) User locked

3) Too many logon attempts

5) Error in authorization buffer (internal error)

6) No external user check

7) Invalid user type

😎 User's validity interval has been exceeded

Cause: No authorization for logon as a trusted system.

Runtime Error: CALL_FUNCTION_SINGLE_LOGIN_REJ

The error code signifies the following:

0) Incorrect logon data with a valid security key.

1) Either the calling system is not a trusted trusted system, or the security key is invalid.

2) Either the user has no RFC authorization (authorization object S_RFCACL) or else someone tried to log on using a protected user, 'DDIC' or 'SAP*'.

3) The timestamp for the logon data is invalid.

Cause: An RFC without a valid user ID is only allowed for a system function module. The meaning of the error code is the same as for CALL_FUNCTION_SINGLE_LOGIN_REJ.

Runtime Error: CALL_FUNCTION_SYSCALL_ONLY

Cause: Data error (internal table info) when calling a function remotely

Runtime Error: CALL_FUNCTION_TABINFO

Cause: No memory available for the table to be imported

Runtime Error: CALL_FUNCTION_TABLE_NO_MEMORY

Cause: Only applies to asynchronous RFC: Task name is already being used

Runtime Error: CALL_FUNCTION_TASK_IN_USE

Cause: Only applies to asynchronous RFC: The specified task is already open

Runtime Error: CALL_FUNCTION_TASK_YET_OPEN

Cause: No trusted authorization for the RFC call and trusted system

Runtime Error: CALL_RPERF_SLOGIN_AUTH_ERROR

Cause: No valid trusted entry for the calling system

Runtime Error: CALL_RPERF_SLOGIN_READ_ERROR

Cause: No RFC authorization for the user

Runtime Error: RFC_NO_AUTHORITY

CALL FUNCTION IN BACKGROUND TASK

Variant 5

CALL FUNCTION func IN BACKGROUND TASK.

Extras:

1. ... AS SEPARATE UNIT

2. ... DESTINATION dest

3. ... EXPORTING p1 = f1 ... pn = fn

4. ... TABLES p1 = itab1 ... pn = itabn

Effect

Flags the function module func to be run asynchronously. That is, it is not executed at once. Instead, the data passed using EXPORTING or TABLES is placed in a database table and the next COMMIT WORK executes it in another work process.

Note

This variant applies only as of R/3 Release 3.0, so both the client system and the server system must be Release3.0 or later.

Note

qRFC with output queue

The qRFC with output queue is an enhancement of the tRFC. Serializing the tRFC, which you can implement with queues, ensures that the order of LUWs dictated by the application is adhered to when the data is sent.

Information about qRFC can be found in the "application help" under Serialized RFC: qRFC with Output Queue

Addition 1

... AS SEPARATE UNIT

Effect

Executes the function module in a separate LUW under a new transaction ID.

Addition 2

... DESTINATION dest

Effect

Executes the function module externally as a Remote Function Call (RFC); dest can be a literal or a variable.

Depending on the specified destination, the function module is executed either in another R/3 System or as a function module implemented in C. Function modules that ca n be called externally must be flagged as such in the Function Library (of the target system).

Since each destination defines its own program context, further calls to the same or different function modules with the same destination can access the local memory (global data) of these function modules.

Note

Note that a database commit occurs at each Remote Function Call (RFC). Consequently, you cannot use Remote Function Calls between pairs of statements that open and close a database cursor (such as SELECT ... ENDSELECT).

Addition 3

... EXPORTING p1 = f1 ... pn = fn

Effect

EXPORTING passes values of fields and field strings from the calling program to the function module. In the function module, formal parameters are defined as import parameters. Default values must be assigned to all import parameters of the function module in the interface definition.

Addition 4

... TABLES p1 = itab1 ... pn = itabn

Effect

TABLES passes references to internal tables. All table parameters of the function module must contain values.

Notes

If several function module calls with the same destination are specified before COMMIT WORK, these normally form an LUW in the target system. Calls with the addition 1 are an exception to this rule - they each have their own LUW.

You cannot specify type 2 destinations (R/3 - R/2 connections). (See Technical details, Administration transaction)

Example

REPORT RS41503F.

/* This program performs a transactional RFC.

TABLES: SCUSTOM.

SELECT-OPTIONS: CUSTID FOR SCUSTOM-ID DEFAULT 1 TO 2.

PARAMETERS: DEST LIKE RFCDES-RFCDEST DEFAULT 'NONE',

MODE DEFAULT 'N',

TIME LIKE SY-UZEIT DEFAULT SY-UZEIT.

DATA: CUSTITAB TYPE TABLE OF CUST415,

TAMESS TYPE TABLE OF T100,

WA_CUSTITAB TYPE CUST415.

SELECT ID NAME TELEPHONE INTO CORRESPONDING FIELDS OF TABLE CUSTITAB

FROM SCUSTOM WHERE ID IN CUSTID ORDER BY ID.

PERFORM READ_CUSTITAB.

EDITOR-CALL FOR CUSTITAB TITLE 'Editor for table CUSTITAB'.

PERFORM READ_CUSTITAB.

CALL FUNCTION 'TRAIN415_RFC_CALLTRANSACTION'

IN BACKGROUND TASK

DESTINATION DEST

EXPORTING

TAMODE = MODE

TABLES

CUSTTAB = CUSTITAB.

CALL FUNCTION 'START_OF_BACKGROUNDTASK'

EXPORTING

STARTDATE = SY-DATUM

STARTTIME = TIME

EXCEPTIONS

OTHERS = 1.

IF SY-SUBRC = 1.

EXIT.

ENDIF.

COMMIT WORK.

CALL TRANSACTION 'SM58'.

----

---

• FORM READ_CUSTITAB *

----

---

FORM READ_CUSTITAB.

WRITE: / 'System ID:', SY-SYSID.

SKIP.

LOOP AT CUSTITAB INTO WA_CUSTITAB.

WRITE: / CUSTITAB-ID, CUSTITAB-NAME,

WA_CUSTITAB-TELEPHONE.

ENDLOOP.

ULINE.

ENDFORM.

Note

Authorization Check

If the instance profile parameter auth/rfc_authority_check is set to 1, the system automatically performs an RFC authorization check on the function group of the function module that is to be called. If the user has no authorization to call this function module, a runtime error occurs. The authorization can be checked beforehand using the AUTHORITY_CHECK_RFC function module. If the RFC communication takes place within one system, in the same user context - that is, with the same user id in the same client - no RFC authorization check takes place. For more details, refer to RFC Authorization Concept.

Note

Typical RFC problems and their solutions. The following may help you analyze any errors that may occur.

Exceptions for RFC

Non-Catchable Exceptions

Cause: The called function module has not been released for RFC.

Runtime Error: CALL_BACK_ENTRY_NOT_FOUND

Cause: Destination type is not allowed.

Runtime Error: CALL_FUNCTION_DEST_TYPE

Cause: Missing communication type (I for internal connection, 3 for R/3) when calling an asynchronous RFC

Runtime Error: CALL_FUNCTION_DESTINATION_NO_T

Cause: The destination entered does not exist.

Runtime Error: CALL_FUNCTION_NO_DEST

Cause: The destination entered (in load distribution mode) does not exist.

Runtime Error: CALL_FUNCTION_NO_LB_DEST

Cause: Data received for unknown CPI-C connection.

Runtime Error: CALL_FUNCTION_NO_RECEIVER

Cause: The function module you tried to call is flagged as one that cannot be called remotely.

Runtime Error: CALL_FUNCTION_NOT_REMOTE

Cause: An error occurred when calling the function remotely. This error is logged in the calling system.

Runtime Error: CALL_FUNCTION_REMOTE_ERROR

Cause: The logon data for the user is not complete.

Runtime Error: CALL_FUNCTION_SIGNON_INCOMPL

Cause: The attempt to log on in the form of an internal call to a target system is not valid.

Runtime Error: CALL_FUNCTION_SIGNON_INTRUDER

Cause: RFC from an external program without a valid user ID.

Runtime Error: CALL_FUNCTION_SIGNON_INVALID

Cause: The user tried to log onto the target system without a valid user ID.

Runtime Error: CALL_FUNCTION_SIGNON_REJECTED

The error code signifies the following:

1) Incorrect password or invalid user ID

2) User locked

3) Too many logon attempts

5) Error in authorization buffer (internal error)

6) No external user check

7) Invalid user type

😎 User's validity interval has been exceeded

Cause: No authorization for logon as a trusted system.

Runtime Error: CALL_FUNCTION_SINGLE_LOGIN_REJ

The error code signifies the following:

0) Incorrect logon data with a valid security key.

1) Either the calling system is not a trusted trusted system, or the security key is invalid.

2) Either the user has no RFC authorization (authorization object S_RFCACL) or else someone tried to log on using a protected user, 'DDIC' or 'SAP*'.

3) The timestamp for the logon data is invalid.

Cause: An RFC without a valid user ID is only allowed for a system function module. The meaning of the error code is the same as for CALL_FUNCTION_SINGLE_LOGIN_REJ.

Runtime Error: CALL_FUNCTION_SYSCALL_ONLY

Cause: Data error (internal table info) when calling a function remotely

Runtime Error: CALL_FUNCTION_TABINFO

Cause: No memory available for the table to be imported

Runtime Error: CALL_FUNCTION_TABLE_NO_MEMORY

Cause: Only applies to asynchronous RFC: Task name is already being used

Runtime Error: CALL_FUNCTION_TASK_IN_USE

Cause: Only applies to asynchronous RFC: The specified task is already open

Runtime Error: CALL_FUNCTION_TASK_YET_OPEN

Cause: No trusted authorization for the RFC call and trusted system

Runtime Error: CALL_RPERF_SLOGIN_AUTH_ERROR

Cause: No valid trusted entry for the calling system

Runtime Error: CALL_RPERF_SLOGIN_READ_ERROR

Cause: No RFC authorization for the user

Runtime Error: RFC_NO_AUTHORITY

CALL FUNCTION STARTING NEW TASK

Variant 2

CALL FUNCTION func ...STARTING NEW TASK task name.

Extras:

1. ... DESTINATION dest

2. ... DESTINATION IN GROUP group name

3. ... DESTINATION IN GROUP DEFAULT

4. ... PERFORMING form ON END OF TASK

5. ... EXPORTING p1 = f1 ... pn = fn

6. ... TABLES p1 = itab1 ... pn = itabn

7. ... EXCEPTIONS syst_except = rc MESSAGE mess

Effect

Starts the function module func asynchronously in a new session. In contrast to normal function module calls, the calling program resumes processing as soon as the function module is started in the target system. It does not wait until the function module has finished. Using CALL SCREEN, the called function module can, for example, display a screen and thus interact with the user. Note that taskname must be a valid string of at least 2 characters, preferably fewer than 8 characters. You cannot use either ' ' or SPACE as tasknames.

Notes

Note that under certain circumstances, an RFC may cause a database commit. For this reason, do not insert an RFC between two OpenSQL statements that open and close a database cursor (such as SELECT...ENDSELECT).

This variant applies only from R/3 Release 3.0, so both the client system and the server system must have Release 3.0 at least.

With this variant, the called function module must also be flagged in the Function Builder as externally callable, even if it is executed locally (without the addition Destination).

There can be no function call to the destination 'BACK' in the called function module (for more information about the destination 'BACK', see CALL FUNCTION func DESTINATION dest).

This variant does not allow you to execute external programs that you access from a TCP/IP-type detination asynchronously. (See the Transaction Tools -> Administration, Administration -> Network -> RFC destinations for maintaining destinations).

Neither does this variant allow you to display images such as lists or screens in a separate window during RFC communication using a SAProuter.

From Release 4.0 onwards, you can carry out a new, stricter system load check on RFC destinations. (In RFC destination maintenance of an R/3 connection, choose Destination -> ARFC-Optionen). Before the function module is executed, the system checks that the destination has sufficient resources available. If not, the system delays execution of the function module for a given period of time. The algorithm used to determine the system load on the target machine is the same as that used for an asynchronous RFC with the DESTINATION IN GROUP addition. Note that this option is only available for target systems from Release 3.1H onwards. This procedure is active as default.

In principle, parallel processing makes sense whenever application servers have the necessary resources. In this case, the application servers must be configured with at least 3 dialog work processes.

A program that is run in the background and uses RFC parallel processing requires at least 1 dialog work process per application server (because parallel processing takes place in a dialog work process).

If the instance profile parameter 'auth/rfc_authority_check' is set to 1, the system automatically performs an RFC authorization check. The authorization check refers to the relevant function group for the function module to be called. If no authorization is found, a runtime error occurs. You can check the authorization in advance with the function module AUTHORITY_CHECK_RFC. If the RFC communication takes places in one system and in the same user context (that is, the same client and User ID) the system does not perform an RFC authority check. For more information, see: RFC Authorization Concept.

When you are using asynchronous RFC to implement parallel windows, all these windows are closed if the caller session is the only session and terminates.

Note that asynchronous tasks that have been started are not necessarily closed when the calling program ends.

See also RFC Logons to the Target System (Remote Logon).

Addition 1

... DESTINATION dest

Effect

Executes the function module externally as a Remote Function Call (RFC); dest can be a literal or a variable. The R/3 System where the function module is executed depends on the specified destination. Externally callable function modules must be flagged as such in the Function Builder (of the target system).

Note

If the destination is not explicitly specified, the system uses the default destination 'NONE'.

Note

If, during a Remote Function Call, an error occurs in the target system, details of the error message are passed back to the calling system in the following system fields: SY-MSGNO, SY-MSGID, SY-MSGTY, SY-MSGV1, SY-MSGV2, SY-MSGV3, and SY-MSGV4. These fields are initialized before every RFC. If a short dump or a type X message occurs, the short text of the dump is transferred to the caller, and the contents of SY-MSGID, SY-MSGTY, SY-MSGNO, and SY-MSGV1 assigned by the system.

In RFC-enabled function modules, no ABAP statements are allowed that would end the RFC connection (for example, either LEAVE or SUBMIT without the AND RETURN addition).

Note

Note that a database commit occurs at each Remote Function Call (RFC). Consequently, you cannot use Remote Function Calls between pairs of statements that open and close a database cursor (such as SELECT ... ENDSELECT).

Addition 2

... DESTINATION IN GROUP group name

Addition 3

... DESTINATION IN GROUP DEFAULT

Effect

You use this addition to perform parallel execution of function modules (asynchronous calls) on a predefined group of R/3 System application servers.

You use addition 2 (DESTINATION IN GROUP group name) to perform parallel execution of function modules on a predefined group of application servers. To maintain the RFC groups, choose Tools -> Administration -> Administration ->Network -> RFC destinations -> RFC -> RFC groups. The application programmer is responsible for the availability of RFC groups in the production system. In this case the group name variable must be of the type RZLLITAB-CLASSNAME

You use addition 3 (DESTINATION IN GROUP DEFAULT) to perform parallel execution of function modules (asynchronous calls) on all currently available R/3 System application servers. However, instead of this variant, you are recommended to use an RFC group with appropriate resources for parallel processing of asynchronous calls (at least for performance reasons). Please note that the addition DESTINATION IN GROUP ' ' has the same effect as the addition DESTINATION IN GROUP DEFAULT.

When you first call a function module with these additions, the system initializes the specified RFC group (unless the group has already been explicitly identified).

To obtain current information about resources (that is, the resources available to process function modules), you can also initialize the RFC group explicitly in the program using the function module SPBT_INITIALIZE. You must perform this action before the first function module call.

In both cases, the system first ascertains the currently available resources (work processes) on the available application servers (either a group of servers or all servers). By checking the current system load of each application server, the system determines how many work processes are available to execute asynchronous calls.

After ascertaining the available resources, the asynchronous call is executed to one of the

destinations. If no resources are available at that particular time, the system executes the

exception routine RESOURCE_FAILURE (see the addition EXCEPTIONS). In the case of

an asynchronous function module call, this exception must be handled by the application

program (see example).

No resources are made available by the system if resource availability limits are exceeded:

Notes

To be taken into consideration for RFC parallel processing, an application server must have at least 3 free dialog processes.

The system triggers the exception RESOURCE_FAILURE only for asynchronous RFCs with the additions DESTINATION IN GROUP group name and DESTINATION IN GROUP DEFAULT.

At present, only one RFC group per program environment is supported for parallel execution of asynchronous calls. Using both the additions DESTINATION IN GROUP group name and DESTINATION IN GROUP DEFAULT in a program is thus not allowed.

To find out which destination was automatically selected, call the function module SPBT_GET_PP_DESTINATION immediately after the function module call with the two additions. This returns the selected RFC destination.

If you want to delete an application server from the list of the configured RFC group at runtime (for example, when the application server is not accessible for technical reasons), use the function module SPBT_DO_NOT_USE_SERVER.

Addition 4

... PERFORMING form ON END OF TASK

While the parameters for receiving results (that is IMPORTING and TABLES parameters) are specified directly as additions in the case of "conventional" function modules (see variant 2), these are logged in the FORM routine form when making an asynchronous call (see RECEIVE).

Notes

If a function module returns no result, and you are not interested in error messages that arise when executing the function module, this addition (... PERFORMING form ON END OF TASK) can be omitted.

If you want to handle the error messages that arise when executing the asynchronous function module call, you must use this addition. Also, when receiving the results in the FORM routine (see RECEIVE), you must react accordingly to the system exceptions SYSTEM_FAILURE and COMMUNICATION_FAILURE.

With asynchronous RFC, the task name uniquely identifies the asynchronous connection and thus the context called.

If several asynchronous function modules are executed consecutively to the same destination, you must assign a different task name to each.

A calling program that starts an asynchronous RFC with the PERFORMING form ON END OF TASK addition cannot switch roll areas or change to an internal mode. This is because the asynchronous function module call reply cannot be passed on to the relevant program. You can perform a roll area switch with SUBMIT or CALL TRANSACTION.

If a calling program makes asynchronous calls, finishes, and then expects responses, it cannot receive these responses.

To wait for the reply to a started asynchronous function module, use the WAIT command with the addition PERFORMING form ON END OF TASK. Here, WAIT must be in the same program context (mode).

Note that executing asynchronous calls is subject to a roll area change.That is, subroutines performed to receive asynchronous calls can take place while other asynchronous calls are being made. Thus as a developer you must ensure that subroutines can be executed at any time. You must not make assumptions about the implicit processing sequence.

Addition 5

... EXPORTING p1 = f1 ... pn = fn

Effect

Passes values of fields and field strings from the calling program to the function module. In the function module, the formal parameters are defined as import parameters.

Addition 6

... TABLES p1 = itab1 ... pn = itabn

Effect

Passes references to internal tables.

Addition 7

... EXCEPTIONS syst_except = rc MESSAGE mess

Effect

While any exceptions arising in the called function module are handled by the second

addition (see the FORM subroutine RETURN_INFO), this addition can handle two special

system exceptions, (as with function module calls with the DESTINATION addition):

SYSTEM_FAILURE

is triggered, if a system crash occurs on the receiving side.

COMMUNICATION_FAILURE

is triggered if there is a connection or communication problem.

In both cases, you can get a description of the error with the optional ... MESSAGE messaddition

Note

In principle, you should always react to these two system exceptions, whether you are making an asynchronous function module call or receiving results.

Examples

Calling a transaction in a seperate session.

DATA: MSG_TEXT(80) TYPE C. "Message text

...

• Asynchronous call to Transaction SM59 -->

• Create a new session

CALL FUNCTION 'ABAP4_CALL_TRANSACTION' STARTING NEW TASK 'TEST'

DESTINATION 'NONE'

EXPORTING

TCODE = 'SM59'

EXCEPTIONS

COMMUNICATION_FAILURE = 1 MESSAGE MSG_TEXT

SYSTEM_FAILURE = 2 MESSAGE MSG_TEXT.

IF SY-SUBRC NE 0.

WRITE: MSG_TEXT.

ELSE.

WRITE: 'O.K.'.

ENDIF.

Using RFC groups to parallelize function module calls(RFC parallel processing)

TYPES: BEGIN OF TASKLIST_TYPE,

TASKNAME(4) TYPE C, "Verwaltung der Tasks

RFCDEST LIKE RFCSI-RFCDEST,

END OF TASKLIST_TYPE.

DATA: INFO LIKE RFCSI, C, "Message text

JOBS TYPE I VALUE 10, "Number of parallel jobs

SND_JOBS TYPE I VALUE 1, "Sent jobs

RCV_JOBS TYPE I VALUE 1, "Received replies

EXCP_FLAG(1) TYPE C, "Number of RESOURCE_FAILUREs

TASKNAME(4) TYPE N VALUE '0001', "Task name administration

TASKLIST TYPE TABLE OF TASKLIST_TYPE,

WA_TASKLIST TYPE TASKLIST_TYPE.

...

DO.

...

CALL FUNCTION 'RFC_SYSTEM_INFO'

STARTING NEW TASK TASKNAME DESTINATION IN GROUP DEFAULT

PERFORMING RETURN_INFO ON END OF TASK

EXCEPTIONS

COMMUNICATION_FAILURE = 1

SYSTEM_FAILURE = 2

RESOURCE_FAILURE = 3.

CASE SY-SUBRC.

WHEN 0.

• Administration of asynchronous tasks

WA_TASKLIST-TASKNAME = TASKNAME.

CLEAR WA_TASKLIST-RFCDEST.

APPEND WA_TASKLIST TO TASKLIST.

WRITE: / 'Started Task: ', WA_TASKLIST-TASKNAME COLOR 2.

TASKNAME = TASKNAME + 1.

SND_JOBS = SND_JOBS + 1.

JOBS = JOBS - 1. "Number of existing jobs

IF JOBS = 0.

EXIT. "Job processing finished

ENDIF.

WHEN 1 OR 2.

• Handling of communication and system failure

...

WHEN 3. "No resources available at present

• Receive reply to asynchronous RFC calls

IF EXCP_FLAG = SPACE.

EXCP_FLAG = 'X'.

• First attempt for RESOURCE_FAILURE handling

WAIT UNTIL RCV_JOBS >= SND_JOBS UP TO '0.01' SECONDS.

ELSE.

• Second attempt for RESOURCE_FAILURE handling

WAIT UNTIL RCV_JOBS >= SND_JOBS UP TO '0.1' SECONDS.

ENDIF.

IF SY-SUBRC = 0.

CLEAR EXCP_FLAG. "Reset flag

ELSE. "No replies

"Endless loop handling

...

ENDIF.

ENDCASE.

ENDDO.

...

• Receive remaining asynchronous replies

WAIT UNTIL RCV_JOBS >= SND_JOBS.

LOOP AT TASKLIST INTO WA_TASKLIST.

WRITE:/ 'Received Task:', WA_TASKLIST-TASKNAME COLOR 1,

30 'Destination: ', WA_TASKLIST-RFCDEST COLOR 1.

ENDLOOP.

...

FORM RETURN_INFO USING TASKNAME.

RECEIVE RESULTS FROM FUNCTION 'RFC_SYSTEM_INFO'

IMPORTING RFCSI_EXPORT = INFO

EXCEPTIONS

COMMUNICATION_FAILURE = 1

SYSTEM_FAILURE = 2.

RCV_JOBS = RCV_JOBS + 1. "Receiving data

IF SY-SUBRC NE 0.

• Handling communication and system failure

...

ELSE.

READ TABLE TASKLIST WITH KEY TASKNAME = TASKNAME

INTO WA_TASKLIST.

IF SY-SUBRC = 0. "Daten registrieren

WA_TASKLIST-RFCDEST = INFO-RFCDEST.

MODIFY TASKLIST INDEX SY-TABIX FROM WA_TASKLIST.

ENDIF.

ENDIF.

...

ENDFORM.

Note

Typical RFC Problems and Their Solutions will help you analyze the errors you may encounter.

Note

If the error CALL_FUNCTION_NO_RECEIVER occurs, data for an unknown CPI-C

connection has been received (see also, RFC exceptions below). This causes an error

because the answer from an asynchronous function module call (using a CPI-C log) has

been received and this could not be passed to the associated program context.

This situation occurs if a SUBMIT or CALL TRANSACTION statement is used, after an asynchronous function module call, with the PERFORMING form ON END OF TASK addition. Using the SUBMIT command, an internal session is created, which may in some cases prevent the answer from the asynchronous function module call being passed to the session.

Exceptions for RFC

Non-Catchable Exceptions

Cause: The called function module has not been released for RFC.

Runtime Error: CALL_BACK_ENTRY_NOT_FOUND

Cause: Destination type is not allowed.

Runtime Error: CALL_FUNCTION_DEST_TYPE

Cause: Missing communication type (I for internal connection, 3 for R/3) when calling an asynchronous RFC

Runtime Error: CALL_FUNCTION_DESTINATION_NO_T

Cause: The destination entered does not exist.

Runtime Error: CALL_FUNCTION_NO_DEST

Cause: The destination entered (in load distribution mode) does not exist.

Runtime Error: CALL_FUNCTION_NO_LB_DEST

Cause: Data received for unknown CPI-C connection.

Runtime Error: CALL_FUNCTION_NO_RECEIVER

Cause: The function module you tried to call is flagged as one that cannot be called remotely.

Runtime Error: CALL_FUNCTION_NOT_REMOTE

Cause: An error occurred when calling the function remotely. This error is logged in the calling system.

Runtime Error: CALL_FUNCTION_REMOTE_ERROR

Cause: The logon data for the user is not complete.

Runtime Error: CALL_FUNCTION_SIGNON_INCOMPL

Cause: The attempt to log on in the form of an internal call to a target system is not valid.

Runtime Error: CALL_FUNCTION_SIGNON_INTRUDER

Cause: RFC from an external program without a valid user ID.

Runtime Error: CALL_FUNCTION_SIGNON_INVALID

Cause: The user tried to log onto the target system without a valid user ID.

Runtime Error: CALL_FUNCTION_SIGNON_REJECTED

The error code signifies the following:

1) Incorrect password or invalid user ID

2) User locked

3) Too many logon attempts

5) Error in authorization buffer (internal error)

6) No external user check

7) Invalid user type

😎 User's validity interval has been exceeded

Cause: No authorization for logon as a trusted system.

Runtime Error: CALL_FUNCTION_SINGLE_LOGIN_REJ

The error code signifies the following:

0) Incorrect logon data with a valid security key.

1) Either the calling system is not a trusted trusted system, or the security key is invalid.

2) Either the user has no RFC authorization (authorization object S_RFCACL) or else someone tried to log on using a protected user, 'DDIC' or 'SAP*'.

3) The timestamp for the logon data is invalid.

Cause: An RFC without a valid user ID is only allowed for a system function module. The meaning of the error code is the same as for CALL_FUNCTION_SINGLE_LOGIN_REJ.

Runtime Error: CALL_FUNCTION_SYSCALL_ONLY

Cause: Data error (internal table info) when calling a function remotely

Runtime Error: CALL_FUNCTION_TABINFO

Cause: No memory available for the table to be imported

Runtime Error: CALL_FUNCTION_TABLE_NO_MEMORY

Cause: Only applies to asynchronous RFC: Task name is already being used

Runtime Error: CALL_FUNCTION_TASK_IN_USE

Cause: Only applies to asynchronous RFC: The specified task is already open

Runtime Error: CALL_FUNCTION_TASK_YET_OPEN

Cause: No trusted authorization for the RFC call and trusted system

Runtime Error: CALL_RPERF_SLOGIN_AUTH_ERROR

Cause: No valid trusted entry for the calling system

Runtime Error: CALL_RPERF_SLOGIN_READ_ERROR

Cause: No RFC authorization for the user

Runtime Error: RFC_NO_AUTHORITY

Defining Remote Destinations

You maintain remote destinations in table RFCDES. This table cont the logical destinatinos for remote function calls (RFCs).

You cannot maintain table RFCDES directly.

You can maintain the logical destination in the following ways:

Transaction SM59

(Tools → Administration, Adminstration → Network → RFC destinations

Using the Implementation Guide ( IMG):

Choose Tools → Business Engineering → Customizing, Implement. projects → SAP reference IMG

In the hierarchy structure of the IMG, choose

Cross-application components

Distribution (ALE)

Communication

Define RFC destination

Each time you call a remote function, you must specify the remote system in the DESTINATION addition.

The following information is required:

Technical settings

- Connection type (TCP, SNA, ...)

- Remote system

- Destination

- Load distribution in a server group (optional)

- Name of the R/3 target sytsem (if you specified load distribution)

- Target host (if you are not using load distribution)

- Instance number

Security options

Trusted System?

Description of the logical destination

Logon information for the user

- User

- Client

- Password

- Logon language

The system displays the name of the users who created and last changed the entry, along with a timestamp.

You must enter the remote system details in order for the system to create an entry in table RFCDES.

In a Remote Function Call, the user, client, and password fields are read from the RFC destination information to log onto the remote system.

For RFC communication with different clients and users you must enter a correct password for each separate user.

If you have not filled out the language, client, and user fields for the RFC destination, the sytsem uses the entries from the system table as default values.

Notes

You do not need to fill out the user details or password for RFC communication between application servers in the same R/3 System and client wiht the same user.

If you are running the RFC in dialog mode (but not in background mode) and the RFC logon fails, the system displays an RFC logon screen, allowing you to log onto the remote system 'by hand'.

The RFC logon screen is not displayed if the first function module to be called belongs to the system-specific function group SRFC. This function group includes function modules such as RFC_PING, RFC_SYSTEM_INFO, and RFC_LOGIN.

If you still want an RFC logon screen to be displayed, you must use the 'RFC_CONNECTION_CLOSE' function module to end the first RFC communication.

No logon screen is displayed when you use trusted and trusting systems.

Remote Function Call (RFC) - Authorization Concept

Since Release 3.1G you have been able to run RFC authorization checks based on the (called) function group.

If the instance profile parameter 'auth/rfc_authority_check' is set to 1, the system automatically runs an RFC check. The authorization check refers to the function group of the function module to be called. If no authorization exists, this leads to runtime error RFC_NO_AUTHORITY. If the RFC communication takes place within one system and in the same user context, i.e., the same client and user identification, no RFC authorization check is performed.

You can first check the authorization using function module AUTHORITY_CHECK_RFC. The system runs the RFC authorization check each time you access the called function module using RFC (the system checks the corresponding function module groups).

The authorization is checked using authorization object S_RFC.

This authorization object contains the following three fields:

RFC_TYPE : Type of the RFC object to be protected

This field can currently have the value 'FUGR' (function group).

RFC_NAME : Name of the RFC object to be protected

This field currently contains function group name. It may be up to 18 characters long. The authorization check only applies to the first 18 characters.

ACTVT : Activity

This field can currently have the value 16 (execute).

From Release 4.0, the authorization check is active by default (that is, auth/rfc_authority_check = 1).

In addition, from Release 4.0 you can also set up a trusted relationship between systems (see also documentation on Trusted/Trusting Systems). This sets up a trusted relationship between the calling and the called systems, whereby this relationship is initiated by the called system. In the called system you must then specify the users in the calling system who may execute Remote Function Calls over this type of trusted relationship (trusted users). Additionally you must assign the trusted users with trusted profiles (authorization object S_RFCACL) in the called system.

This authorization contains the following fields:

RFC_SYSID : ID of the calling system

RFC_CLIENT : Client for the calling system

RFC_USER : ID of the calling user

RFC_EQUSER : Identifier, whether or not the user may be called by a user with the same ID (Y = Yes, N = No).

RFC_TCODE : Calling transaction code

RFC_INFO : Additional information from the calling system (currently inactive)

ACTVT : Activity

This field can currently have the value 16 (Execute)

Using this, you can specify exactly which users may call remote function modules using other user IDs.

Note : The authorization check based on the function groups (authorization object S_RFC) takes place independently of the authorization checks within the trusted systems.

Reward points if useful

Regards,

Mansi.

[Former Member]

Hi,

RFC enabled function module is called from both SAP or non SAP systems. But the function is remote enabled. we have to create a RFC destination which is an entry in the RFCDES table. If the data is available in one server and is not available in other server, we have to create a remote function in the server which contains data and is called from server as

call function 'FUNCTION' destination <rfc destination>.

reward id useful.

[Former Member]

I have done it on my own.

[Former Member]

How?

regards

Chris