Configuring the Receiver Remote Function Call (RFC) Adapter


After completing this lesson, you will be able to:

  • Configure the receiver RFC adapter

Receiver RFC Adapter Configuration

You can use a receiver Remote Function Call (RFC) adapter to connect SAP systems and non SAP systems. The receiver adapter contains the technical information of the connection to the back-end system.

If the target system is a non SAP system, the target system first registers with a gateway. The gateway and the program ID are defined.

Specify an SAP system for the Metadata Repository (MDRS) because non SAP systems cannot provide the RFC signature.

In the case of SAP systems, system and logon specifications are required.

You can either enter an application server (an instance) directly or use load balancing and maintain to determine the message server and logon group.

RFC Communication

The logon data consists of the following parameters:

  • SAP Client

  • User

  • Password

  • Logon Language

The user behind the RFC communication is of the Communication type. Communication users do not have dialog authorization and therefore cannot be used for normal logons. Moreover, these users are exempt from having to change their password periodically.

For an overview of user types, execute transaction SU01 and then input help for the user types in the logon data area.

The communication channel assigned to the target system must also be assigned to the inbound interface using an Integrated Configuration.

The values assigned to the business system in the Integration Directory (ID) under Adapter-Specific Identifiers are not used.

BAPIs as Special Remote-Enabled Function Modules

Business Application Programming Interfaces (BAPIs) are special remote-enabled function modules and therefore belong to a subgroup of RFC-enabled function modules. Two characteristics of these function modules are particularly important when using the RFC adapter – the RETURN parameter (instead of exceptions) and the way COMMIT behaves with function modules that update the database.

One of the characteristics of BAPIs is that they do not have any exception as part of the signature. As a result, BAPIs cannot create application error messages. Application errors and messages in general (for example, error, success, warning, and information) are set up in the RETURN parameter and then evaluated accordingly by the sender application.

The RETURN parameter is a structure or table and appears in the ESR as frequency 1 or 1 . . . unbounded.

COMMIT Behavior with Update BAPIs

To post data into the target system, BAPI requires an explicit COMMIT WORK statement to write data into the database. This COMMIT WORK statement is not executed in the BAPI itself but by another function module.

If you want to use the communication channel to call BAPIs as remote-enabled function modules to update data in the database, choose Commit Handling for Single BAPI Calls. If executed successfully, the transaction is written to the database by calling the function module BAPI_TRANSACTION_COMMIT explicitly. If an error occurs, the BAPI_TRANSACTION_ROLLBACK rolls back the transaction. The value of the field TYPE in the RETURN parameter determines the result. If successful, the tables are empty and the values S, I, and W display. All other entries are evaluated as errors. To change this, choose BAPI Advanced Mode and enter the name to be evaluated as successful in the table.

Configure the RFC Adapter 

Configure the Scenario for an RFC Call

Log in to track your progress & complete quizzes