first of all qRFC is just an extension to tRFC
the main difference is that when using qRFC
you can put all your calls/messages in a queue
so they get executed one by one which is not the case
with tRFC as with tRFC they get exectued without
retaining the original sequence
(so last call can be executed first)
with XI (sender RFC adapter) you can only use tRFC
but with a little RFC wrapper it is possible
to invoke qRFC calls from XI on the R3
<a href="/people/michal.krawczyk2/blog/2005/06/28/xipi-faq-frequently-asked-questions">XI FAQ - Frequently Asked Questions</a>
The difference between qRFC and tRFC is the demanded Quality-of-Service (Q-o-S). With qRFC, it is the Q-o-S exactly-once-in-order (EOIO) and with tRFC it is the Q-o-S exactly-once (EO). To be able to guarantee the sequence of qRFC units and, at the same time, parallelize independent units, the dependencies are implemented using queues in qRfc . tRFC units do not belong to a queue and can therefore always be processed in parallel.
Thus in Qrfc a particular order is followed while processing, while in Trfc it is not.
Please refer to the following link for more details,
In the link below search for EO and EOIO . the diff between them is same as the diff bet Qrfc and Trfc
Hope this helps,
Read through these links, it would help you understand TRFC and QRFC:
Transactional RFC and queued RFC are variants of the Remote Function Call that make the data transfer between different SAP R/3 systems more reliable and more secure.
Transactional RFCguarantees the following attributes:
Queued RFC (qRFC with Outbound Queue)
To offset this disadvantage, a serialization of tRFC is performed using wait queues. It is called queued RFC (qRFC). With this serialization, an outbound queue for tRFC was created in SAP R/3, which is therefore referred to as qRFC with outbound queue. The main features of qRFC are as follows:
· A LUW is only transferred if it has no predecessor (in reference to the sequence defined in the applications) in the participating queues. After a qRFC transaction is executed, the system attempts to start the next qRFC transaction in the sequence from the queue.
· A queue name and a queue counter are required fore each qRFC transaction for queue administration. Each tRFC call that is to be processed chronologically is assigned a queue name determined by the application.
When one system calls an FM in another system, a tRFC(transactional RFC) is used. This tRFC inturn calls a FM that passes the idocs to the target system.
tRFCs enable asynchronous communication, and hence they use the concept of queues.
qRFC acts as an intermediated layer between the tRFC and the application.
The tRFC call, enters the queue(qRFC), and the processes in the queue are executed in first in first out order.
They are variants of remote function calls
Transactional RFC guarantees the following attributes:
· The call is executed exactly once in the target system.
· Calls that belong to a Logical Unit of Work (LUW) are either completely executed, or not executed at all.
If the target system is not available when the call is made, the call remains in the local wait queue. The calling dialog program can, however, proceed. If the target system does not become active within a certain amount of time, the call is scheduled as a background job.
Although tRFC significantly improves the reliability of the data transfer, it also has disadvantages. This method does not ensure that the sequence of LUWs specified in the application is observed. However, there is a guarantee that all LUWs will be transferred at some point.
Queued RFC (qRFC with Outbound Queue)
To offset this disadvantage, a serialization of tRFC is performed using wait queues. It is called queued RFC (qRFC).With this serialization, an outbound queue for tRFC was created in SAP R/3, which is therefore referred to as qRFC with outbound queue. The main features of qRFC are as follows:
·A LUW is only transferred if it has no predecessor (in reference to the sequence defined in the applications) in the participating queues. After a qRFC transaction is executed, the system attempts to start the next qRFC transaction in the sequence from the queue.
·A queue name and a queue counter are required fore each qRFC transaction for queue administration. Each tRFC call that is to be processed chronologically is assigned a queue name determined by the application."
We currently have an interface that makes an tRFC (EO) call from R/3 to XI. It works fine. We would like to move to qRFC so that the data is also serialized (EOIO).
In R/3, there are 2 ways to implement the qRFC:
1) qRFC with Outbound Queue - call TRFC_SET_QUEUE_NAME
2) qRFC with Outbound and Inbound Queue - call 'TRFC_SET_QIN_PROPERTIES'
Which do we use to guarantee EOIO processing of the RFC in XI?
I think I answered my own question:
According to the XI RFC Adapter FAQ (730870) qRFC is not supported for the RFC Adapter.
We can get R/3 to serialize the call if we use 'TRFC_SET_QUEUE_NAME' but this will still result in an EO message in XI, not an EOIO message.
It looks like EOIO is supported after SP11 but only for the RFC Receiver Adapter (XI -> R/3), not for the Sender Adapter (R/3 -> XI)
A tRFC lets you group one or more functional module calls to a tRFC LUW
Each FM in the LUW is executed exactly once or not at all.
All the function modules are executed in order, these RFCu2019s are used especially in scenarios (business docs posting i.e. invoices, shipping.. etc) where the target systems might not be available at the time of posting.
Monitoring transaction for tRFC is u201CSM58u201D,this is to track errors during either the transmission of a call or the execution of the FM on the target system.
EOIO(Exactly once in order)
qRFC,an extension of tRFC offers fine control over the sequence in which tRFC sessions are executed.
All the recorded calls are save into a database, when commit work is occurred in the calling program.
A separate scheduler process controls scheduling and execution of qRFC LUWs.
The qRFCs scheduler ensure the execution order of subsequent LUWs
It stops the execution of subsequent LUWs in the same queue when a qRFC LUW is executed with an error.
the main difference between tRFC and qRFC is :
tRFC: It processes all LUWs independednt of one another. Due to the amount of activated tRFC processes, performance may reduce significantly and there is no guarantee that the sequence of LUWs defined in the application program is same as they get executed. tRFC follows the EO(Exactly once)
qRFC: The processing sequence of the transactions is defined in the application program is the same as the sequence how they got executed. qRFC is EOIO(Exactly Once In Order).
Transactional RFC (tRFC) and Queued RFC (qRFC). tRFC is used mainly to
transfer ALE Intermediate Documents (IDocs).
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.
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.