qRFC Communication Model

Scenarios

The following scenarios are possible when using qRFC:

• Communication between two SAP systems

• Communication between an SAP system in the client role and an external server.

• Communication between an external client in an SAP system in the server role.

Processing Options

The actual send process takes place on a tRFC basis. However the tRFC is preceded by inbound and outbound queues that determine a processing order for the data packages (LUWs) to be sent or updated. This queuing mechanism is the core of qRFC functionality.

The following graphic shows the difference between tRFC and the different queue types of qRFC:

tRFC and qRFC Processing

Error! Objects cannot be created from editing field codes.

Case 1: tRFC

Using tRFC ( without queues) is intended for when the data to be sent is not in a logical connectivity that requires a specific processing order.

A client (system 1) establishes a tRFC connection to a server (system 2). Every function call sent to the target system is executed exactly once.

You cannot define the sequence in which the function modules are processed or the time when this happens. If a transfer error occurs, a background job is scheduled that resends the function module after a defined period of time.

Case 2: qRFC with Outbound Queue

In this scenario the sender system uses an outbound queue to serialize the data to be sent, that is, function calls that depend upon each other are put in the outbound queue of the sender system and transferred to the target system in Exactly Once In Order - EOIO. The called system (server) has no knowledge of the outbound queue in the sender system (client). This send process is intended in particular for communicating between an SAP system and a non-SAP system.

Case 3: qRFC with Additional Inbound Queue in the Target System

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. In this case, both communication parties must be SAP systems.

The additional inbound queue means that resources in the client and server can be controlled efficiently at the same time. The inbound queue is processed using an Inbound Scheduler (QIN scheduler). One work process is used for each queue. The QIN schedule processes only so many queues in parallel as the target system resources that are currently available allow. This prevents a server being blocked by a client.