regarding: RFC Function Mod

[Former Member]

Hi all,

Can any body Tell me whats the Difference between Synchroner RFC and Asynchroner

All i KNow is that

Synchroner RFC

CALL FUNCTION func DESTINATION dest

parameter_list.

Asynchroner RFC

2. CALL FUNCTION func STARTING NEW TASK task

[DESTINATION {dest|{IN GROUP {group|DEFAULT}}}]

parameter_list

[{PERFORMING subr}|{CALLING meth} ON END OF TASK].

Can any body Please explain ...

Thanks

Srinivas

[Former Member]

hi,

this is all explained in the ABAP help.

Se38

CTRL+F8

type in CALL end press enter

Now click call function module

then click the 5th variant CALL FUNCTION func IN BACKGROUND TASK.

And lastly read.

Kind regards, Rob Dielemans

[former_member189059]

Asynchronous RFC :

This is used when you need to increase the performance of ABAP program by having system call more than one function module in parallel than forcing the program to wait for results .

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.

[Former Member]

hi,

A remote function call (RFC) is the call of a function module that runs in a different system to the calling program. Although it is also possible to call a function module in the same system as an RFC, normally RFCs are used when the caller and the called function module run in the same system.

In the SAP system, these functions are provided by the RFC interface system. The RFC interface system enables function calls between two SAP systems, or between an SAP system and an external system.

The RFC- interface system is made up of the following interfaces:

• Calling interface for ABAP programs

• Each ABAP program can call a remote function module using the command CALL FUNCTION...DESTINATION. The parameter DESTINATION informs the SAP system that the called function module runs in a different system to the calling system. RFC communication with the remote system takes place as a part of the CALL FUNCTION command.

• RFC function modules in an SAP system must be proper function modules and must be registered in the SAP system as remote.

• If the calling program and the called program are both ABAP programs, the RFC interface provides both communication partners. The calling program can be any ABAP program, and the called program must be a function module that is registered as remote.

• For more detailed information on calling function modules that are registered as remote, see Calling RFC Function Modules in ABAP.

• For more information on writing function modules that you want to call remotely, see Writing RFC Function Modules in ABAP.

• Interfaces for calling non-ABAP programs

If either the calling program or the called partner is not an SAP program, this program must be programmed in such a way that it can play the role of the other partner in RFC communication.

To support you when implementing RFC partner programs in non-SAP systems, read: Components of the SAP Communication Technology

RFC-supported and GUI-supported interfaces can be used by external programs to call function modules in SAP systems, and execute them in these systems. Likewise, ABAP programs can also use these interfaces to use functions supplied by external programs.

These are the types of RFC :

Asynchronous RFC (aRFC)

Synchronous RFC (sRFC)

Transactional RFC (tRFC)

Queued RFC (qRFC)

Parallel RFC (pRFC)

RFC:

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.

Asynchronous RFC :

This is used when you need to increase the performance of ABAP program by having system call more than one function module in parallel than forcing the program to wait for results .

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:

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.

For More Info,

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

[Former Member]

Hi srinivas,

1. CALL FUNCTION func DESTINATION dest

It means : It will <b>WAIT</b> for the function module to complete,

<b>and then proceed further.</b>

2. CALL FUNCTION func STARTING NEW TASK task

It means : <b>DO NOT WAIT</b>

(The details of the FM and its parameters are LOGGED somewhere,

and the FM is called in background, in another independent session)

regards,

amit m.

[Former Member]

Hi..,

CALL FUNCTION - RFC

Syntax Forms

Synchroner RFC

1. CALL FUNCTION func DESTINATION dest

parameter_list.

Asynchroner RFC

2. CALL FUNCTION func STARTING NEW TASK task

[DESTINATION {dest|{IN GROUP {group|DEFAULT}}}]

parameter_list

[{PERFORMING subr}|{CALLING meth} ON END OF TASK].

Transaktionaler RFC

3. CALL FUNCTION func IN BACKGROUND TASK

[DESTINATION dest]

parameter_list

[AS SEPARATE UNIT].

The destination contains the connection parameters for remote function calls. It contains the connection type, the target system and the partner program. Connections that affect SAP systems exclusively can be agreed as trustedsystems. RFC destinations are managed using transaction code SM59.

regards,

ABhay.

<b>rewrads point if useful</b>

[Former Member]

hi

just copy the code. u will come to know the diff

CALL FUNCTION 'ABAP4_CALL_TRANSACTION <b>STARTING NEW TASK 'TEST'</b>
*  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 1.
*    WRITE :/ 'call transaction denied'.
*
*  WHEN 2.
*    WRITE :/ ' transaction doesnot exist'.
*

if u use <b>STARTING NEW TASK TEST</b> it is asynchronous.. tx gets sm59 exec in another session.

<b>if u dont use STARTING NEW TASK TEST its synchronousi.e txn exec in same session.</b>

regards

ravish

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

Message was edited by:

ravish goyal

[Former Member]

hi,

When calling a function module using the RFC interface, the calling program must specify the parameters of the connection in the form of a destination. This destination defines the type of connection, the partner program, and the target system. You can manage it using transaction SM59, and it distinguishes between a variety of connections, such as TCP/IP or SAP connections. For a synchronous RFC, the destination must be specified explicitly. For asynchronous and transactional RFCs, a destination can be specified. If no destination has been specified the function module is called using the RFC interface in the same system. Depending on the type of execution, the following conditions apply:

· For synchronous and asynchronous calls, the values of the call parameters are transferred to the function module directly, whereas in the case of transactional calls, these are stored in the database temporarily until execution.

· For asynchronous calls, no connection to external systems is possible (TCP/IP connections in transaction SM59).

· For synchronous calls, the results of the called function are copied directly. For asynchronous calls, results can be received in callback routines by using the statement RECEIVE, whereas in the case of transactional calls, transferring results is not possible.

· The server of the called function module must be available for synchronous and asynchronous calls.

To be able to call a function module using the RFC interface, the function module in question must be flagged as being remote-capable in its properties, and for its interface parameter, only pass by value is allowed. Even for table parameters, a pass by value is performed implicitly. Within the system in which they are defined, remote-capable function modules can either be called using the RFC interface, or like normal function modules. The normal call is made using the statement CALL FUNCTION without using one of the additions DESTINATION, STARTING NEW TASK or IN BACKGROUND TASK. When making the call using the RFC interface, you must either specify the special destination "NONE" (see below), or you must perform an asynchronous or transactional RFC without specifying a destination.

All the possible destinations are stored in the database table RFCDES, whose content is managed using transaction SM59. When calling a function module remotely from an ABAP program, the destination is specified using addition DESTINATION of the statement CALL FUNCTION, in the form of a key value in column RFCDEST of database table RFCDES. The relevant rows of the database table contain all parameters defined in transaction SM59 that are used for communicating with the external system.

There are two predefined destinationen that do not have to be entered using transaction SM59:

· Destination "NONE" has the effect that the function module is started on the same application server as the calling program, however through the RFC interface and in its own RFC context. This destination is possible for all types of call.

· Destination "BACK" can be used in a function module that is called remotely, and links back to the caller. You can only specify this in function modules that have been called synchronously. Destination "BACK" can be used to call each remote-capable function module of the calling system in all three execution types. For a synchronous callback, the relevant function group is loaded into the internal session of the calling program, if it is not yet available there. The existint RFC connection is used for this callback.

As well as the destinations created in transaction SM59 and the two predefined destinations, you can also specify destinations directly, in the form "hostname_sysid_sysnr". Here, "hostname" refers to the name of the application server, "sysid" is the name of an SAP system, and "sysnr" is the system number, as is displayed using transaction SM51, for example.

Pls reward points.

Regards,

Ameet