Difference between TRFC and QRFC

[former_member206760]

Dear all,

i understand that TRFC functions as EO and QRFC functions as EOIO.

but can anyone of u pls make me understand there significance with a practical example :

1. in terms of XI

2. without XI when we say that one R3 is connected to other with say TRFC or QRFC

pl help

[Former Member · Accepted solution]

EO provides possibility to process messages parallel. If one fails others will keep processed. EOIO will guarantee a sequence and helps to avoid overtaking within the message queue. If one fails here all msg. behind will wait.

for tRFC / qRFC see http://help.sap.com/saphelp_nw70/helpdata/en/62/73241e03337442b1bc1932c2ff8196/content.htm

[former_member206760]

thanks for your help guys

[Former Member]

Hi! Tarang,

I just adding few points in this forum...Actually your question and some of the answers given are different .Some of them are deviating the topic.

According to my knowledge and as per SAP documentations also I am adding these points. Correct me if I am wrong.

At first QRFC , TRFC are different from the BE, EO and EOIO because trfc are message protocols and BE , EO and EOIO are nothing but Quality of Services (QOS).

You can check this in the below URL::

QOS is one of the property of TRFC's.

1) See Got o SMQ1 an SMQ2 what you will found:: ?

QRFC Monitor Outbound Queue and QRFC Monitor Inbound Queue. both Queues QRFC s common.ok its a simple thing.

2) Also lets take IDOC Adapter for IDOC whether it may be File to IDOC or IDOC to File Scenario where you will monitor the IDOC in SM58 also right ? why because this TRFC's are mainly for communicating with one SAP system to another SAP System. IDOC is mainly sending data via TRFC ports. That is why you ill monitor the IDOC if data doesn't reached means in Transaction COde:: SM58.

3) QRFC Outbound and QRFC Inbound is mainly for communicating with SAP System and Non SAP Systems. Okay you can get this information in the below further explination and link.

Note::qRFC communication is an extended form of tRFC communication. It adds a serialization concept to the transactional concept of tRFC.

Some applications use qRFC with outbound queue to improve system performance and not for serialization. If this is the case, you can switch automatically from the qRFC LUW with outbound queue to the tRFC LUW to avoid a hanging queue if a SYSTEM_FAILURE occurs

Note:: To cancel a background job if tRFC errors occur use program RSARFCEX to restart tRFC.

-

-

---

First What is the purpose of RFC:: ?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.

There are 3 types of communications::

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

· a) Communication between two independent SAP systems

b) Communication between a calling SAP system and an external receiving system

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

system

Features of the Three Communication TypesTo 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:

... 1) tRFC

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

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

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

-

-

---

XI point of View...

Basically Once the TRFC or QRFC is funtion is over XI will place the Message into the Adapter engine queues based on the Comminication channel configuration.

Suppose if it is and EO then XI ill place the message in any Queue based on the free and priority and if configuration is done as per EOIO then XI ill place all the messages in the Same queue name so that it ill processes in order one after another and if the above message fails and remaining all other messages will be in the queue and doesnt process untill the failed mesages gets removed

But in case of EO it may be places in any queue and if one message fails then another message of same interface may processed sucessfully based on another queue order.

I hope it wil be helpful to you...

Regards::

Amar Srinivas Eli

[former_member184619]

Hi Tarang,

As you already know tRFC is used for EO and qRFC is used for EOIO..

tRFC and qRFc terms are genric and have the same meaning in terms of XI as well as R/3..

tRFC is used when we are looking for a guranteed delivery say in case of Invoices, PO.. In this case tRFC tries to deliver to target system, which might not be available at that time..but it will deliver at a later stage whenever the target system is Up and running.

qRFC is an extension of tRFC which solves the problem by offering control over the sequence in which tRFC sessions are executed.

Reference: https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/f078394a-4469-2910-c4bf-

853c75674694

and check this blog for there use in XI queues

/people/sap.india5/blog/2006/01/03/xi-asynchronous-message-processing-understanding-xi-queues-part-i

Sachin

[JoelTrinidade]

Hi Tarang,

I have posted some content about quality of service ,,, below is about RFC.

Transactional RFC (tRFC) and Queued RFC (qRFC). tRFC is used mainly to

transfer ALE Intermediate Documents (IDocs).

Transactional RFC

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 you risk duplicating a completed function call.

To alleviate this problem, you can use transactional RFC, which guarantees that each function call you issue will only be executed once, even if you submit it 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. If it has, the transaction is ignored.

Queued RFC

When you use transactional RFC, you cannot guarantee 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 you need to specify a particular processing order, you can use queued RFC, which is an extension of transactional RFC. 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.

refer

http://johnv.sapgenie.com/docs/RFC.pdf

http://zerone.samcheok.ac.kr/Asp_pr/Language/.%5Cuploadfile%5CJCo%20Tutorial-1.pdf

www.sapgenie.com/sapgenie/docs/SAP%20Connectors.doc

[JoelTrinidade]

Hi Tarang,

Its quiet a surprise this question coming from you. You are quiet a knowledgeable person in terms of XI.

Anyways:

The sender of a message uses the attribute Quality of Service (QoS) to determine how a message is delivered. The following types of quality of service are supported:

● BE (Best Effort):

The message is sent synchronously. The sender waits for a response before it continues processing.

● EO (Exactly Once):

The message is sent asynchronously. The sender does not wait for a response. The Integration Engine and the Adapter Engine guarantee that the message is sent and processed exactly once.

● EOIO (Exactly Once In Order):

Messages are delivered with the same queue names (supplied by the application) in the same sequence that they were sent from the sender system. Message processing is asynchronous in this case.

In the case of quality of service BE an error occurs if more than one receiver is determined for a message. In the case of delivery types EO and EOIO, the message is copied correspondingly and sent to the individual receivers.

Regards

joel

Edited by: joel trinidade on Mar 26, 2009 10:41 AM

[former_member206760]

Thanks Kai.

can anybody throw some more light on this ?