‎2007 Oct 25 1:18 PM
Hello
please tell me about the types and description of RFC
with regards
Basavaraj
‎2007 Oct 25 1:24 PM
hi
TRFC:
The called function module is executed exactly once in the RFC server system. 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 R/3
database, including a unique transaction identifier (TID).
If a call is sent, and the receiving system is down, the call remains in the local queue until a later
time. The calling dialog program can proceed without waiting to see whether or not 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.
Transactional RFCs use the suffix IN BACKGROUND TASK.
QRFC:
The characteristics of qRFC with send queue are:
Queued RFC with send queue enforces a serialization on the side of the send system. The
target system has no information about the serialization in the send system. This allows
communication with any R/3 target system as of Release 3.0.
qRFC with send queue is an enhancement of tRFC. It transfers an LUW (transaction) only if
it has no predecessors (in reference to the sequence defined in different application
programs) in the participating queues. In addition, after executing a qRFC transaction, the
system tries to start all waiting qRFC transactions automatically according to the sequence.
For queue administration, the system needs a queue name and a queue counter for each
qRFC transaction. Each tRFC call to be serialized is assigned to a queue name that can be
determined by the application. The application passes the queue name with the call of
function module TRFC_SET_QUEUE_NAME. This function module is called immediately
before each tRFC call to be serialized. See also Programming Serialization [Page 28].
A queue name is a text of up to 24 bytes length. You can choose any text, but you must not
use * (asterisk).
ARFC:
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 functions 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) and allows you to switch back and forth 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...
Siva
‎2007 Oct 25 1:24 PM
hi
TRFC:
The called function module is executed exactly once in the RFC server system. 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 R/3
database, including a unique transaction identifier (TID).
If a call is sent, and the receiving system is down, the call remains in the local queue until a later
time. The calling dialog program can proceed without waiting to see whether or not 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.
Transactional RFCs use the suffix IN BACKGROUND TASK.
QRFC:
The characteristics of qRFC with send queue are:
Queued RFC with send queue enforces a serialization on the side of the send system. The
target system has no information about the serialization in the send system. This allows
communication with any R/3 target system as of Release 3.0.
qRFC with send queue is an enhancement of tRFC. It transfers an LUW (transaction) only if
it has no predecessors (in reference to the sequence defined in different application
programs) in the participating queues. In addition, after executing a qRFC transaction, the
system tries to start all waiting qRFC transactions automatically according to the sequence.
For queue administration, the system needs a queue name and a queue counter for each
qRFC transaction. Each tRFC call to be serialized is assigned to a queue name that can be
determined by the application. The application passes the queue name with the call of
function module TRFC_SET_QUEUE_NAME. This function module is called immediately
before each tRFC call to be serialized. See also Programming Serialization [Page 28].
A queue name is a text of up to 24 bytes length. You can choose any text, but you must not
use * (asterisk).
ARFC:
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 functions 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) and allows you to switch back and forth 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...
Siva
‎2007 Oct 25 3:14 PM
HI,
RFC Locate the document in its SAP Library structure
Purpose
Communication between applications of different systems in the SAP environment includes connections between SAP systems as well as between SAP systems and non-SAP systems. Remote Function Call (RFC) is the standard SAP interface for communication between SAP systems. The RFC calls a function to be executed in a remote system.
Synchronous RFC
The first version of RFC is synchronous RFC (sRFC). This type of RFC executes the function call based on synchronous communication, which means that the systems involved must both be available at the time the call is made.
Transactional RFC (tRFC)
Transactional RFC (tRFC, also originally known as asynchronous RFC) is an asynchronous communication method that executes the called function module in the RFC server only once. 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 until a later time. The calling dialog program can proceed without waiting to see whether or not 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
· 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 guarantee that the transactional order of the calls is preserved.
Disadvantages of tRFC
· tRFC processes all LUWs independent 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. Therefore, there is no guarantee that the transactions are executed in the sequence dictated by the application. The only guarantee is that all LUWs are transferred sooner or later.
Queued RFC (qRFC)
To guarantee that multiple LUWs are processed in the order specified by the application, tRFC can be serialized using queues (inbound and outbound queues). This type of RFC is called queued RFC (qRFC).
qRFC is therefore an extension of tRFC. It transfers an LUW (transaction) only if it has no predecessors (in reference to the sequence defined in different application programs) in the participating queues.
Implementation of qRFC is recommended if you want to guarantee that several transactions are processed in a predefined order.
RFC: Data Transfer
All RFC types are transferred by means of CPI-C or TCP/IP. They constitute a form of Structure linkgateway communication.
PLZZZ DO GIVE POINTS ALSO.
REGARDS,
RIC.S