Pages

RFC-Interview Questions & Answers-SAP ABAP-3.

11. What Is Synchronous RFC (sRFC)?

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.

12. What Is Asynchronous RFC (aRFC)?

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.

13. What Is Transactional RFC (tRFC)?

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).

14. What Is Queued RFC (qRFC)?

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.

15. What Is The Disadvantage Of Using Queued RFC (qRFC)?

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.