rfc

[Former Member]

what r the types of rfc? and differences between them?

[Former Member]

hi,

Have a look at below link. It gives you a PDF which contains all the details abt RFC.

http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCFESDE2/BCFESDE2.pdf

<u>TRFC:</u>

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.

<u>QRFC:</u>

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

<u>ARFC:</u>

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 function’s 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...

I hope it helps.

Best Regards,

Reshma

[Former Member]

Hi,

RFC

Remote Function Call:

RFCs are requests that an SAP component sends to invoke functions on remote systems, or calls that remote systems initiate to invoke functions on an SAP component.A process that can accept RFCs from SAP components. This allows SAP components to access functions in external systems. In SAP BC terminology, the process is called a Listener. Listeners are one or more threads on SAP Business Connector that wait for incoming requests from SAP components. Listeners are named and register with an SAP gateway to indicate that they are ready to accept requests. Listeners can accept RFC or tRFC requests.

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.

RFC is an SAP interface protocol. Based on CPI-C, it considerably simplifies the programming of communication processes between systems.

RFCs enable you to call and execute predefined functions in a remote system - or even in the same system.

RFCs manage the communication process, parameter transfer and error handling.

Have a look at this link.

http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCFESDE2/BCFESDE2.pdf

http://help.sap.com/saphelp_47x200/helpdata/en/22/042860488911d189490000e829fbbd/frameset.htm.

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

Please go through the following link. You will get good info on RFC & its types.

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

check out the following link it might help you

http://help.sap.com/printdocu/core/Print46c/de/data/pdf/BCFESDE2/BCFESDE2.pdf

http://help.sap.com/saphelp_46c/helpdata/en/22/0424ba488911d189490000e829fbbd/frameset.htm

Regards,

Priyanka.

[Former Member]

hi

check with the following links

http://help.sap.com/saphelp_46c/helpdata/en/22/0424ce488911d189490000e829fbbd/content.htm

http://www.planetsap.com/RFC.htm

http://www.sap-img.com/abap/interview-question-on-bapi-rfc-abap-objects-tables.htm

regards

dinesh

[Former Member]

Hi,

RFC (remote function call) is a call to a function module running in a different system.Programmatically ,you can call the RFC enabled function module

using the "CALL FUNCTION Destination" statement.

There are 3 types of RFC's.

1.Synchronous RFC: With this call,the calling program stops processing until the control is returned back to the called function

2.Transactional RFC (tRFC)

Transactional RFC (known as asynchronous RFC) is an asynchronous communication method that executes the called function module in the RFC server only once.

3.Queued RFC: 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).

You need to enable the function module to RFC from se37 transaction.

Regards

[Former Member]

hi

<b>CALL FUNCTION – RFC</b>&#61656; A remote function call is a call to a function module running in a system different from the caller's. The remote function can also be called from within the same system (as a remote call).

&#61656; RFC consists of two interfaces : A calling interface for ABAP Programs and a calling interface for Non-SAP programs.

&#61656; Any ABAP program can call a remote function using the CALL FUNCTION...DESTINATION statement. The DESTINATION parameter tells the SAP System that the called function runs in a system other than the caller's.

&#61656; You can use the CALL FUNCTION statement to call remote functions by including an additional DESTINATION clause.

&#61656; <b>CALL FUNCTION ‘remotefunction’

DESTINATION dest

EXPORTING f1 =

IMPORTING f2 =

TABLES t1 =

EXCEPTIONS

&#61656; Calling remote functions locally :-

( i.e. call a remote function within the same system )

The two options to do this are –

• CALL FUNCTION...DESTINATION = 'NONE'

• CALL FUNCTION... [no DESTINATION used]</b>

The remote function can invoke its own caller (if the caller is itself a function module), or any function module loaded with the caller.

You can trigger this call-back mechanism using

CALL FUNCTION... DESTINATION 'BACK‘.

<b>Types of RFC’s</b>

&#61656; <b>Synchronous RFC</b> – The calling program continues the execution only after the called function is complete.

SYNTAX: CALL FUNCTION func DESTINATION dest

parameter_list.

&#61656; <b>Asynchronous RFC</b> - The calling program continues the execution without waiting for return from the called function.

SYNTAX

Eg: CALL FUNCTION ‘remotefunction’ STARTING NEW TASK ‘taskname’.

EXAMPLE: T_RFC in ECCHYD

REPORT calltransaction.

CALL FUNCTION 'ABAP4_CALL_TRANSACTION' STARTING NEW TASK 'TEST'

EXPORTING

tcode = 'SM59'

EXCEPTIONS

call_transaction_denied = 1

tcode_invalid = 2

OTHERS = 3.

IF sy-subrc <> 0.

• MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO

• WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.

ENDIF.

CASE sy-subrc.

WHEN 2.

WRITE 😕 ' transaction doesnot exist'.

ENDCASE.

<b>&#61656; Transactional RFC</b> &#61558; This type of RFC was renamed from asynchronous to transactional RFC, because asynchronous RFC has another meaning in R/3 Systems.

&#61558; The called function module is executed exactly once in the RFC server system. Each function call is seen as a transaction in the target system.

&#61558; Transactional RFCs use the suffix IN BACKGROUND TASK. The remote system need not be available at the time when the RFC client program is executing a tRFC.

&#61558; The tRFC component stores the called RFC function together with the corresponding data in the R/3 database, including a unique transaction identifier (TID).

&#61558; If a call is sent, and the receiving system is down, the call remains in the local queue until a later time.

&#61558; 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.

&#61558; The system logs the remote call request in the database tables ARFCSSTATE and ARFCSDATA with all of its parameter values. You can display the log file using transaction SM58.

&#61558; When the calling program reaches a COMMIT WORK, the remote call is forwarded to the requested system for execution.

&#61558; Transactional RFC requests are transferred, with parameter data in byte-stream form, using TCP/IP or X400.

&#61558; LUW's are identified by transaction ID's that are unique world-wide. The transaction ID can be determined from an ABAP program by calling function module ID_OF_BACKGROUNDTASK. (You must call this function after the first asynchronous CALL, and before the related COMMIT WORK.)

&#61558; The system function module ARFC_DEST_SHIP transports the data to the target system and the function module ARFC_EXECUTE executes the stored function calls. If an error or an exception occurs during one of the calls, all the database operations started by the preceding calls are rolled back and an appropriate error message is written to the file ARFCSSTATE.

&#61558; Once you have identified the ID of the LUW, you can use the function module STATUS_OF_BACKGROUNDTASK to determine the status of the transactional RFC.

&#61558; Call transaction SM58 (Tools _ Administration _ Monitoring _ Transactional RFC). This tool lists only those transactonal RFCs that could not be carried out successfully or that had to be planned as batch jobs. The list includes the LUW ID and an error message. Error messages displayed in SM58 are taken from the target system. To display the text of the message, double-click on the message.

&#61558; If a LUW runs successfully in the target system, the function module ARFC_DEST_CONFIRM is triggered and confirms the successful execution in the target system. Finally, the entries in the Tables ARFCSSTATE and ARFCSDATA are deleted.

DISADVANTAGES

&#61558; These can reduce performance significantly in both the send and the target

systems.

&#61558; 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.

SYNTAX

Eg : CALL FUNCTION ‘remotefunction’ IN BACKGROUND TASK

CALL FUNCTION func IN BACKGROUND UNIT

parameter_list.

&#61656; The field ‘dest’ can be either a literal or a variable. Logical destinations are defined in the RFCDES table via transaction SM59 or via the menu path: Tools ->Administration,Administration->Network->RFC destinations.

SAMPLE PROGRAM

RSTRFCT0

regards

ravish

<b>plz dont forget to reward points if helpful</b>