The difference between qRFC and tRFC

[Former Member]

I am studying RFC now,i don't understand when i should use qRFC or tRFC.can any expert tell me.

thanks

[Former Member · Accepted solution]

Hi kim,

welcome to sdn.

The qRFC Communication Model

qRFC Properties and Possible Uses

All types of applications are instructed to communicate with other applications. This communication may take place within an SAP system, with another SAP system, or with an application from a remote external system. An interface that can be used for dealing with this task is the Remote Function Call (RFC). RFCs can be used to start applications in remote systems, and to execute particular functions.

Whereas the first version of the RFC, the synchronous RFC, (sRFC) required both systems involved to be active in order to produce a synchronous communication, the subsequent generations of RFC had a greater range of features at their disposal (such as serialization, guarantee for one-time-only execution, and that the receiver system does not have to be available). These features were further enhanced through the queued RFC with inbound/outbound queue.

Communication between applications within an SAP system and also with a remote system can basically be achieved using the Remote Function Call (RFC). Here, the following scenarios are possible:

· Communication between two independent SAP systems

· Communication between a calling SAP system and an external receiving system

· Communication between a calling external system and an SAP receiving system

The following communication model shows what these communication scenarios may look like in reality. The actual sending process is still done by the tRFC (transactional Remote Function Call). Inbound and outbound queues are added to the tRFC, leaving us with a qRFC (queued Remote Function Call). The sender system is also called the client system, while the target system corresponds to the server system.

Scenario 1: tRFC

This scenario is appropriate is the data being sent is independent of each other. A calling application (or client) in system 1 uses a tRFC connection to a called application (or server) in system 2. In this scenario, data is transferred by tRFC, meaning that each function module sent to the target system is guaranteed to be executed one time only. You cannot define the sequence in which the function modules are executed, nor the time of execution. If an error occurs during the transfer, a batch job is scheduled, which sends the function module again after 15 minutes.

Scenario 2: qRFC with outbound queue

In this scenario, the sender system uses an outbound queue, to serialize the data that is being sent. This means that function modules which depend on each other (such as update and then change) are put into the outbound queue of the sender system, and are guaranteed to be sent to the target system one after each other and one time only. The called system (server) has no knowledge of the outbound queue in the sender system (client), meaning that in this scenario, every SAP system can also communicate with a non-SAP system. (Note: the programming code of the server system must not be changed. However, it must be tRFC-capable.)

Scenario 3: qRFC with inbound queue (and outbound queue)

In this scenario, as well as an outbound queue in the sender system (client), there is also an inbound queue in the target system (server). If a qRFC with inbound queue exists, this always means that an outbound queue exists in the sender system. This guarantees the sequence and efficiently controls the resources in the client system and server system. The inbound queue only processes as many function modules as the system resources in the target system (server) at that time allow. This prevents a server being blocked by a client. A scenario with inbound queue in the server system is not possible, since the outbound queue is needed in the client system, in order to guarantee the sequence and to prevent individual applications from blocking all work processes in the client system.

Properties of the Three Communication Types

To help you decide which communication type you should use in your system landscape for your requirements, the advantages of the three communication types are listed below:

...

1. tRFC: for independent function modules only

2. qRFC with outbound queue: guarantees that independent function modules are sent one after each other and one time only (serialization). Suitable for communication with non-SAP servers.

3. qRFC with inbound queue: in addition to the outbound queue in the client system, an inbound queue makes sure that only as many function modules are processed in the target system (server) as the current resources allow. Client and server system must be SAP systems. One work process is used for each inbound queue.

The qRFC Communication Model

Purpose

Communication within an SAP system or with a remote system can take place using Remote Function Call (RFC). This enables the following scenarios:

· Communication between two independent SAP systems

· Communication between a calling SAP system and an external receiving system

· Communication between a calling external SAP system and an SAP system as the receiving system

Implementation Considerations

The following communication model shows how these communication scenarios can occur in practice. tRFC (transactional Remote Function Call) is still responsible for actually sending communications. tRFC is preceded by inbound and outbound queues, which have led to the name qRFC (queued Remote Function Call). The sending system is called the client system, and the target system represents the server system.

There are three data transfer scenarios:

Scenario 1: tRFC

This scenario is suitable if the data being sent is not interrelated. A calling application (or client) in system 1 uses a tRFC connection to a called application (or server) in system 2. In this scenario, the data is transferred using tRFC. This means that each function module sent to the target system is guaranteed to be processed once. The order in which the function modules are executed, and the time they are executed, cannot be determined. If a transfer error occurs, a background job is scheduled that resends the function module after a defined period of time.

Scenario 2: qRFC with Outbound Queue

In this scenario, the sending system uses an outbound queue to serialize the data being sent. This means that mutually dependent function modules are placed in the outbound queue of the sending system and are guaranteed to be sent in the correct sequence, and only once, to the receiving system. The called system (server) has no knowledge of the outbound queue in the sending system (client). Using this scenario, every SAP system can communicate with a non-SAP system (the program code of the server system does not need to be changed, but it must be tRFC-compliant).

Scenario 3: qRFC with Inbound Queue (and Outbound Queue)

In this scenario, in addition to the outbound queue in the sending system (client), there is also an inbound queue in the target system (server). qRFC with an inbound queue always means that an outbound queue exists in the sending system. This guarantees that the sequence of communications is preserved, and at the same time the resources in the client and in the server system are controlled efficiently. The inbound queue is processed using an inbound scheduler, which only processes as many queues in parallel as the current resources in the target system (server) will allow, This prevents a server from being blocked by a client.

Features

Features of the Three Communication Types

To help you decide which communication types you need to implement according to your system landscape and your requirements, the advantages of the three types of communication are explained below:

...

· tRFC

Suitable only for independent function module calls; the sequence of the calls is not preserved

· qRFC with outbound queue

Function modules in a queue are guaranteed to be processed only once and in sequence (serialization). Also suitable for communication with non-SAP servers.

· qRFC with inbound queue

The function modules created in the outbound queue are transferred from the outbound queue to the inbound queue; the sequence of the function modules is preserved. An inbound scheduler processes the inbound queues in accordance with the specified resources. Both the client and the server system must be SAP systems. One work process is used for each inbound queue.

Queued Remote Function Call (qRFC)

Purpose

All types of applications are instructed to communicate with other applications. This communication may take place within an SAP system, with another SAP system, or with an application from a remote external system. An interface that can be used for dealing with this task is the Remote Function Call (RFC). RFCs can be used to start applications in remote systems, and to execute particular functions.

Integration

In contrast the first version of RFC, synchronous RFC (sRFC), which required both participating systems to be active to form synchronous communication, subsequent generations of RFC now provide a considerably extended range of functions (for example, serialization, guarantee that processing occurs once, and the receiving system does not have to be available). These features were further enhanced through the queued RFC with inbound/outbound queue.

Contents:

The information about qRFC is organized into the following main sections, with more detailed subsections:

The qRFC Communication Model

· qRFC with Outbound Queues

· qRFC with Inbound Queues

qRFC Administration

· qRFC Administration: Introductory Example

· Outbound Queue Administration

· Inbound Queue Administration

qRFC Programming

· qRFC Programming: Introductory Example

· Outbound Queue Programming

· Inbound Queue Programming

· qRFC API

For an introduction to the new bgRFC (Background RFC), use the following links:

bgRFC (Background RFC)

· bgRFC Administration

· bgRFC Programming

Using Asynchronous Remote Function Calls

Asynchronous remote function calls (aRFCs) are similar to transactional RFCs, in that the user does not have to wait for their completion before continuing the calling dialog. There are three characteristics, however, that distinguish asynchronous RFCs from transactional RFCs:

· When the caller starts an asynchronous RFC, the called server must be available to accept the request.

The parameters of asynchronous RFCs are not logged to the database, but sent directly to the server.

· Asynchronous RFCs allow the user to carry on an interactive dialog with the remote system.

· The calling program can receive results from the asynchronous RFC.

You can use asynchronous remote function calls whenever you need to establish communication with a remote system, but do not want to wait for the functionu2019s result before continuing processing. Asynchronous RFCs can also be sent to the same system. In this case, the system opens a new session (or window). You can then switch back and for between the calling dialog and the called session

To start a remote function call asynchronously, use the following syntax:

CALL FUNCTION Remotefunction STARTING NEW TASK Taskname

DESTINATION ...

EXPORTING...

TABLES ...

EXCEPTIONS...

The following calling parameters are available:

§ TABLES

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

§ EXPORTING

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

§ EXCEPTIONS

See Using Predefined Exceptions for RFCs

RECEIVE RESULTS FROM FUNCTION Remotefunction is used within a FORM routine to receive the results of an asynchronous remote function call. The following receiving parameters are available:

§ IMPORTING

§ TABLES

§ EXCEPTIONS

The addition KEEPING TASK prevents an asynchronous connection from being closed after receiving the results of the processing. The relevant remote context (roll area) is kept for re-use until the caller terminates the connection.

Transactional RFC (tRFC)

Transactional RFC(tRFC, previously known as asynchronous RFC) is an asynchronous communication method that executes the called function module just once in the RFC server. 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).

If a call is sent, and the receiving system is down, the call remains in the local queue. The calling dialog program can proceed without waiting to see whether the remote call was successful. If the receiving system does not become active within a certain amount of time, the call is scheduled to run in batch.

tRFC is always used if a function is executed as a Logical Unit of Work (LUW). Within a LUW, all calls

· are executed in the order in which they are called

· are executed in the same program context in the target system

· run as a single transaction: they are either committed or rolled back as a unit.

Implementation of tRFC is recommended if you want to maintain the transactional sequence of the calls.

Disadvantages of tRFC

· tRFC processes all LUWs independently 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. It is therefore impossible to guarantee that the transactions will be executed in the sequence dictated by the application. The only thing that can be guaranteed is that all LUWs are transferred sooner or later

thanks

karthik

reward me if usefull

[Former Member]

Hi,

Refer the theard

https://forums.sdn.sap.com/click.jspa?searchID=12961375&messageID=1289314

Regards

Kiran Sure

[Former Member]

Hi Kim,

Please check this link

http://help.sap.com/saphelp_nw2004s/helpdata/en/62/73241e03337442b1bc1932c2ff8196/content.htm

http://help.sap.com/saphelp_nw2004s/helpdata/en/6f/1bd5b6a85b11d6b28500508b5d5211/content.htm

tRFC and qRFC

The transactional RFC and the qRFC use the resource check. The associated ABAP language elements for both RFC types is:

CALL FUNCTION Remote function IN BACKGROUND TASK DESTINATION destination

With a preceding additional function call (TRFC_SET_QIN_PROPERTIES or TRFC_SET_QUEUE_NAME) tRFC can be defined as qRFC.

This ABAP command flags the function module remote function for asynchronous processing. The module is not executed immediately. The data transferred with EXPORTING or TABLES is placed in a database table. A COMMIT WORK then triggers the function module. There are various cases:

● The data is updated. If tRFC/qRFC has been triggered within the update, these are executed in parallel after the V1 update (within the update). If the tRFC/qRFC call is registered in the scheduler, the scheduler is simply triggered within the update. The execution of tRFC/qRFC takes place outside the update through the scheduler.

● The data is not updated. The tRFC/qRFC function modules started within the application LUW are executed in parallel as far as possible. If local system resources are exhausted, the tRFC/qRFC is serialized so as not to further increase resource utilization. However, this is not the case if the tRFC/qRFC function modules are processed in batch. If the tRFC/qRFC have been started in batch, they are always processed in parallel as in the update process, regardless of the system resource utilization.

No resource checks are run with RFC calls from the update process or batch, since these must always be processed in parallel to avoid deadlocks.

Best regards,

raam