Top 40 Sap Rfc Interview Questions You Must Prepare 19.Mar.2024

The response time for the transfer of data depends on the network used. Ideally, the response time should be between 10 and 100 milliseconds. 

High response times can be due to the following three things

  • The network connection is generally slow or overloaded.
  • The recipient system is physically overloaded.
  • Too few processes are configured in the recipient system to receive RFCs.

An ABAP/4 program can call up an OLE Automation Server (such as Excel) on the desktop. The ABAP/4 OLE Automation Controller consists of a set of ABAP/4 language elements that an ABAP/4 client program can use to drive an OLE Automation server on either Windows or Apple Macintosh frontends.

Parallel Processing is an extension of aRFC. Generally when we call a function module, it will stop the current program, execute another (called) program and then returns control to original program and again original program starts execution.

With asynchronous function module control will start parallel without stopping the current program from which you called the function module. Parallel processing is generally used when there is a need to process large amount of data.

In parallel processing, a job step is started as usual in a background processing work process. A program that runs in a job step can be programmed to use a special variant of asynchronous RFC to have portions of the data to be processed run in parallel in other work processes. You can recognize such a program by its use of the CALL FUNCTION STARTING NEW TASK DESTINATION IN GROUP instruction to start the function modules that process the data.

While the job itself runs in a background process, the parallel processing tasks that it starts, run in dialog work processes. Such dialog work processes may be located on any SAP server. Parallel processing has been implemented in some SAP applications that have long-running reports.

METHOD 1:

Suppose you want to debug a function module which is there in SRM/APO system from R/3.

(FYI: As you all know this RFC Destination is maintained via transaction code SM59 )

Keep the external break-point in your calling program before it calls the RFC. Now login into the Destination system where you’re remote enabled function module exist and put an external break-point.

Now go to Transaction code SRDEBUG and click on the Activate Debugging Button: It will give you a pop up which confirm your id, application server etc.

Click enter which will give you another popup. Keep it as it is.

Now go to your Report program in source system and Execute it , it will open debugger , when you press F5 key to go inside the RFC Function module it will start debugging in APO system.

METHOD @Calling a custom RFC 

Three steps needs to be followed.

For example we are calling an RFC enabled FM in ECC system  from CRM system.

  • Add an infinite loop in the remote custom Function Module (adding a “DO. ENDDO.” statement at  the start of the FM would be enough). 
  • Execute your program in the CRM system. The execution stops at the RFC call, because of the infinite loop. 
  • Now login to the ECC system and go to transaction SM50 select the process which is executing  the RFC and navigate to the menu: “Program/Session->Program->Debugging” this triggers the debugger session in a separate window. 

 

Any ABAP/4 program can call a remote function using the CALL FUNCTION DESTINATION statement.

The RFC interface provides the ability to call remote functions. In SAP, RFC Interface system is used for setting-up RFC connections between different SAP systems, and also between an SAP and an external (Non SAP) system.

RFC consists of two interfaces:

a) Calling interface for ABAP Programs: Any ABAP program can call a remote function using the CALL FUNCTION...DESTINATION statement. The DESTINATION parameter tells the SAP System that the called function runs in a system other than the caller's.

Syntax:
CALL FUNCTION <‘RFC_Name’>DESTINATION
  EXPORTING 
     f1 =
  IMPORTING 
     f2 =
  TABLES
     t1 =
  EXCEPTIONS
.

b) Calling Interface For Non-SAP programs: If either the calling program or the called partner is not an SAP program, the program in question must be programmed in such a way that it can play the role of the other partner in RFC communication. 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. Connectors can be used to achieve the same, for example SAP Java Connector (JCo) or SAP .Net Connector.

The system logs the remote call request in the database tables ARFCSSTATE and ARFCSDATA with all of its parameter values. You can display the log file using transaction SM5@When the calling program reaches a COMMIT WORK, the remote call is forwarded to the requested system for execution.

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.

Different testing options available for RFC connection are:

  • Connection test.
  • Authorization test.
  • Unicode Test.
  • Remote Logon Test

RFC stub programs contain all the parameter-handling and communications necessary to call SAP function modules from a non-SAP System.

Logical destinations are defined in the RFCDES table (or the TRFCD table in R/2 Systems) via transaction SM59

RFC stands for Remote Function Call. Remote Function Call is an interface for communication between a SAP System and other SAP or third-party compatible system. Remote function calls may be associated with SAP software and ABAP programming and provide a way for an external program (written in languages such as PHP, ASP, Java, C, C++) to use data returned from the server or insert data into server records. 

For business applications, sometimes it becomes necessary to communicate and exchange information (in predefined formats) with other SAP Systems or non-SAP Systems (Example Visual Basic to SAP, Java to SAP etc.). To enable this communication, SAP has provided us with a mechanism called RFC, which stands for 'Remote Function Call'.

RFC’s can be used for external integration with SAP, such as PHP/SAP, Flex/SAP, Ruby/SAP, etc.

In SAP, RFC Interface system is used for setting-up RFC connections between different SAP systems, and also between an SAP and an external (Non SAP) system.

Say for example, If you have VB system which has your company's Inventory Management & you have FICO / SD / MM / PP in you SAP system. Your  VB Inventory mgmt system wants to send or receive data/update database in SAP. This can be done use RFC.

Although an RFC associated with communication between two different systems, it can also be created for communication within a system.

RFC’s can be created or maintained via transaction code SE3@RFC calls a function to be executed in a remote system. SM59 transaction code can be used to define and maintain the logical destination of RFC.

For Windows frontends, SAP provides interfaces based on Microsoft's Object Linking and Embedding technology (OLE Automation).

Some of the disadvantages of  tRFC are:

  • tRFC processes all LUWs independent of one another. Due to the amount of activated tRFC processes, this procedure can reduce performance significantly in both the send and the target systems.
  • In addition, the sequence of LUWs defined in the application cannot be kept. Therefore, there is no guarantee that the transactions are executed in the sequence dictated by the application. The only guarantee is that all LUWs are transferred sooner or later.

Basically RFC’s can be recognized in an ABAP program by the syntax CALL FUNCTION <rfc name=' '> DESTINATION <destination name=' '>.

If the RFC function call contains the clause STARTING NEW TASK, it is an asynchronous RFC; the clause IN BACKGROUND TASK indicates a transactional RFC. If the call only contains the clause DESTINATION, but neither STARTING NEW TASK nor IN BACKGROUND TASK, then the RFC is started as a synchronous RFC.

The following code starts the functional module ZRFC_SALES_DEL_STATUS synchronously, asynchronously, and transactionally. 

* Synchronous RFC
CALL FUNCTION ‘ZRFC_SALES_DEL_STATUS’
DESTINATION ‘R10’
EXCEPTIONS
argument_error = 1
send_error = 2
OTHERS = 3.
* Asynchronous RFC
CALL FUNCTION ‘ZRFC_SALES_DEL_STATUS’
STARTING NEW TASK task
DESTINATION ‘R10’
EXCEPTIONS
communication_failure = 1
system_failure = 2
RESOURCE_FAILURE = 3.
* Transactional RFC
CALL FUNCTION ‘ZRFC_SALES_DEL_STATUS’
IN BACKGROUND TASK
DESTINATION ‘R10’
COMMIT WORK.

When transactional RFC’s are used, there is no guarantee of the order in which the function calls will be processed in the system (it is quite possible that one call might overtake another). For cases where there is a need to specify a particular processing order, Queued RFC can be used. 

qRFC is an extension of tRFC. In qRFC, you place each function call in a logical queue. A function call cannot be executed until all of its predecessors in the queue have been processed. Queued RFC calls are processed asynchronously.

qRFC are to be preferred when there is a need of guarantee that several transactions are processed in a predefined order or when there is a need of guarantee that multiple LUWs (Logical Unit of Work/ Transaction) are processed in the order specified by the application. 

qRFC ensures that the transaction is committed based on FIFO Queue. It ensures transaction consistency of LUW and reliability of data transmission. The system stores the queue specifications in table TRFCQOUT. With each COMMIT WORK, the system determines a counter that is used to keep the sequence of transaction processing.

SMQ1: To monitor the outbound queues of a sending system refer SCOT for Fax.

SMQ2: Provides interface to monitor inbound queues.

There are two restrictions on writing remote functions that are to be called transactionally:

  • Transactional calls cannot return parameter values. As a result, the interface for these functions should not specify any EXPORT parameters.
  • Functions that run transactionally may not perform call-backs: the caller's context does not necessarily still exist when the call-back is relayed back to the original system.

Some of the salient features of tRFc are:

  • tRFC guarantees that a called function module is executed in the target system exactly once.
  • All tRFC calls terminated with the statement COMMIT WORK belong to one LUW (Logical Unit of Work). Each LUW automatically receives a transaction ID.
  • Within an LUW, all function modules are executed in the target system in the sequence in which they are called in the send system.
  • tRFC calls with the addition AS SEPARATE UNIT map a separate LUW each in the target system. Such a sub LUW contains exactly one tRFC call and is processed independent of the actual (superior) LUW. This sub LUW receives its own transaction ID.
  • If within an LUW several destinations are used, all tRFC calls that belong to one destination also form a sub LUW. However, since this bundling happens only internally, there is no separate transaction ID assigned to the sub LUW.

The RFC interface is effectively invisible to the ABAP/4 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.

Some of the functions of the RFC interface are:

  • Calling the communication routines needed to talk to the remote system.
  • Converting all parameter data to the representation needed in the remote system
  • Handling communications errors, and notifying the caller, if desired (using EXCEPTIONS parameter of the CALL FUNCTION).

The RFC-API on OS/2, Windows, Windows NT and all R/3-based UNIX platforms makes it possible to use the RFC functionality between an SAP System (R/3 from Release 2.1 and R/2 from Release 5.0D onwards) and a C program on the above platforms. It is of no significance to the caller whether the remote function is provided in an SAP System or in a C program.

Asynchronous RFC is based on asynchronous communication which means the receiving system may or may not be able to retrieve the function call request made from the sender system. The function call can be processed at a later time when the receiving system gets available. Till that time the function call remains in an outbound queue of the sending system and the call is repeated at regular intervals until the receiving system gets available to process the request.

The advantage of this communication is that the receiving system need not be available all the time to process the request especially in cases where the receiving system is temporarily unavailable like due to upgrade or any other reason.

aRFC is a means of communication between systems where acknowledgements are not required (it is similar to post card delivery).It doesn't require both the systems to be available at the time of execution and the result is not immediately required to be sent back to calling system.

The Source System resource does not wait for the target system as they deliver the message/data without waiting for any acknowledgement. It is not reliable for communication since data may be lost if the target system is not available.

Asynchronous RFC can be used for

  • For communication between systems.
  • For parallel processing jobs.

Fast RFC is a type of RFC used for system internal communications. Interactions between J2ee engine in SAP & the ABP runtime environment in the same instance are done using Fast RFC. This type of RFC is possible only if both the source & target are on the same system.

When the context of the calling ABAP/4 program has ended or explicitly by RfcAbort or RfcClose in the external program.

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) was introduced for R/3 systems from Release 3.0 onwards,data can be tranferred between two R/3 systems. This ensures that the called function module is executed only once in the RFC server system.

If, for example, due to network/communication problems the first LUW in a queue cannot be executed, not only this queue keeps pending, but also all other LUWs that are interdependent with this queue. The resulting "jam" could cause a database problem. However, as soon as the communication problem is solved, all transactions and thus all queues can be processed automatically one after the other.

A remote function call is a call to a function module running in a system different from the caller's. The remote function can also be called from within the same system (as a remote call), but usually caller and callee will be in different systems.

Synchronous Communication is implemented when there is a need for immediate return of data (response) from the receiving system to the sender system. The receiving system should be active at the time this communication is made so that it can process the function call at that very time. This communication is very helpful when real time response is required or when results are required immediately from the destination system.

Synchronous RFC is based on synchronous communication which means both the source system and destination system (Client & Server) involved must be available at the time function call is made.

sRFC is a means of communication between systems where acknowledgements are required. The resources of the Source System wait at the target system and ensure that they deliver the message/data with ACKD. The Data is consistent and reliable for communication.

The only issue is if the target system is not available, the source system resources wait until target system is available which may lead to the Processes of source system to go into Sleep/RFC/CPIC Mode at target systems and hence blocks these resources.

Synchronous RFC can be used for

  • For communication between systems.
  • For communication between SAP Web Application Server to SAP GUI.

  • communications between two independent SAP System
  • client-server communications between an external client and an SAP System acting as the server
  • client-server communications between an SAP System acting as the client and an external server.

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) are used. This ensures that the called function module is executed only once in the RFC server system.

If an error occurs during a synchronous remote function call, the system cannot tell at what point the error occurred (most crucially, whether the function module was actually processed in R/3 before the operation failed). Restarting a failed call is therefore a dangerous thing to do, since there is a risk of duplicating a completed function call. 

In Such cases, tRFC’s can be used which guarantees that each function call issued will be executed only once, even if the call is submitted repeatedly to the R/3 System. The system implements this safeguard by assigning a unique transaction ID (TID) to each transaction that you submit. When you attempt to process the transaction, the system checks whether that TID has already been processed or not. If it has, the transaction is ignored.

tRFC is an extension of aRFC. Transactional RFC is an asynchronous communication method that executes the called function module in the RFC server only once, even if the data is sent multiple times due to some network issue. The remote system need not be available at the time when the RFC client program is executing a tRFC. 

The tRFC component stores the called RFC function, together with the corresponding data, in the SAP database under a unique transaction ID (TID). tRFC is similar to aRFC as it does not wait at the target system (Similar to a registered post). If the system is not available, it will write the Data into aRFC Tables with a transaction ID (SM58) which is picked by the scheduler RSARFCSE (which runs for every 60 seconds).

RFCs are not only used for external access to SAP systems but also for interconnections of SAP systems. For example, if there is a Central User Administration (CUA) installed in an SAP system landscape, then there will be need of RFC destination to all daughter systems of the CUA system.

Say we have CRM and R/3 System. In CRM we cannot know anything about delivery status of sales orders. In such cases RFC's can be used to retrieve delivery status of sales orders from R/3 Server. In This way CRM server can get information or data regarding Delivery status of Sales Orders.

An important scenario which requires RFC is Application Link Enabling (ALE). Let's assume there is a Master Data Management (MDM) system and we want to distribute the master data to all SAP systems which would require access to master data. For such scenarios, ALE can be used to distribute the master data among the different SAP systems using IDocs. ALE in turn uses RFC to establish a connection between MDM and its daughter system in this scenario.

In Remote Function Calls, The actual table is transferred, but not the table header. If a table parameter is not specified, an empty table is used in the called function.

Internal ABAP tables can be used as parameters for function module calls. In a local function module call, a parameter table is passed on by reference, and no new local copy has to be created. RFC does not support the ‘by reference’ mechanism, so the whole table has to be exchanged between the RFC client and the RFC server. When the RFC server receives the table entries, it creates a local copy of the internal table.

You can trigger this call-back mechanism by using the special destination name "BACK". If this name is specified in an RFC call on the system acting as the server, the system uses the same RFC connection that was established when the server received the first call. Once an RFC connection is established, it is maintained until it is either explicitly closed or until the calling program terminates.

RFC client is the instance that calls up the Remote Function Call (RFC) to execute the function that is provided by an RFC server. The process that starts the RFC is called the sender or client, and the process in which the RFC is executed is the recipient or server.

Say we have CRM and R/3 System. If we want to read Sales Order’s Delivery Status record from R/3 System’s database, we will have to create a remotely callable function module in the R/3 environment which retrieves Sales Order’s Delivery Status records. Now we will have to call this function from the CRM System using a remote function call (Also list the destination for the target R/3 System in SM59). In this case CRM server acts as an RFC Client and R/3 acts as an RFC Server.

Sometimes there might be a need to call a remote function call from within the same system. This function can run either as a remote or a local call, depending on the CALL FUNCTION statement on how it is declared. It’s a known fact that parameter handling are different for Remote Function Call and Local Function Call, so whether the call runs as remote or local the parameter handling gets affected adversely.

We can call remote functions calls locally using two ways.

CALL FUNCTION...DESTINATION = 'NONE'

This is a remote call, even though DESTINATION = 'NONE' means that the remote function will run in the same system as the caller. As a remote call, the function module runs in its own roll area, and parameter values are handled as for other remote calls

CALL FUNCTION ‘RFC_SALES_DEL_STATUS’
DESTINATION ‘NONE’
EXPORTING VBELN = SALESNO
TABLES STATUS_T = IT_TAB
EXCEPTIONS NO_RECORD_FOUND = 01.

CALL FUNCTION... [no DESTINATION used]

This is a local call, even though the function module is registered as remote. The module does not run in a separate roll area, and is essentially like a normal function call. Parameter transfer is handled as for normal function modules. In particular, if the call leaves some EXPORTING parameters unspecified, it terminates abnormally.

CALL FUNCTION ‘RFC_SALES_DEL_STATUS’
EXPORTING VBELN = SALESNO
TABLES STATUS_T = IT_TAB
EXCEPTIONS NO_RECORD_FOUND = 01.

While defining RFC destination via tcode SM59, there is an option to make the RFC connection as 'Trusted'. Once selected, the calling (trusted) system doesn't require a password to connect with target (trusting) system.

Following are some of the advantages of using trusted channels:

  • Cross-system Single Sign-On facility.
  • Password does not need to be sent across the network.
  • Timeout mechanism for the log-on data prevents misuse.
  • Prevents the mishandling of log-on data because of the time-out mechanism.
  • User-specific log-on details of the calling/trusted system is checked.

The RFC users must have the required authorizations in the trusting system (authorization object S_RFCACL).Trusted connections are mostly used to connect SAP Solution Manager Systems with other SAP systems.

To help implement RFC partner programs in non-SAP Systems, SAP provides :

- The RFC Generator to create stub programs External Interfaces

System raises COMMUNICATION_FAILURE and SYSTEM_FAILURE internally, there is no reason for you to raise them in your program.

CALL FUNCTION RemoteFunction DESTINATION Dest

    EXPORTING 
       f1 =...
       f2 =...
    IMPORTING 
       f3 =...
    TABLES 
       t1 =...
    EXCEPTIONS......

The field 'Dest' can be either a literal or a variable. Its value is a logical destination (for example,

"CRM110") known to the local SAP System. Logical destinations are defined using transaction SM59 and the corresponding data is stored in standard database table RFCDES.

The remote function call concept, for example, allows you to access a function module in an R/3 System from an ABAP program in a CRM System. If you want to read Sales Order’s Delivery Status record from your R/3 System’s database, create a remotely callable function module in the R/3 environment which retrieves Sales Order’s Delivery Status record. Call this function from your CRM System using a remote function call and listing the destination for the target R/3 System:

CRM System: Client
CALL FUNCTION ‘RFC_SALES_DEL_STATUS’
DESTINATION ‘R10’
EXPORTING VBELN = SALESNO
TABLES STATUS_T = IT_TAB
EXCEPTIONS NO_RECORD_FOUND = 01.
R/3 System: Server
FUNCTION RFC_SALES_DEL_STATUS.
.... (Read Sales Order’s Delivery Status record)
ENDFUNCTION.

The function library in R/3 provides a facility for generating and then downloading RFC programs to a workstation or PC. This facility is the RFC Interface Generator. With this tool, you can create RFC stub programs (that call SAP function modules) and example programs (that show how to call stub programs).