‎2007 Apr 26 9:15 AM
Hi Experts,
I have never used RFC ,Please explain me step by step process and also
some basic concepts of RFC.
Thanks..
‎2007 Apr 26 9:17 AM
‎2007 Apr 26 9:17 AM
Hi sweta,
1. RFC Function module
is nothing, but a simple function module,
with Attriburtes set to Remote Enabled in SE37. Thats all.
2. While calling the RFC FM from abap code,
we have to use the suffix DESTINATION 'MYDEST'
and such destination needs to be maintained in SM59.
regards,
amit m.
‎2007 Apr 26 10:09 AM
Hi Experts ..
thanks for your valuable answers ..now i have got the basics..
but please tell me the actual process to implement the same .
‎2007 Apr 26 9:21 AM
RFC is a functional module that is executed in a different system.
So when calling RFC you have to mension a destination in ur ' CALL FUNCTION' command.
Like:
Call Function 'name'
destination.....
export parameters
import parameters
tables
exception.rest of the things are similar with FM when calling a RFC.
when creating RFC:
1. in attribute you have to check the remote enabled' radio button.
2. All the parameters should be passed by value only, not pass by referance.
‎2007 Apr 26 9:21 AM
hi Swetha
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.
Regards Rk
‎2007 Apr 26 9:22 AM
Sweta,
Remote Function Call:
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
Go thro' the link to understand RFC concepts and programming with RFC function modules ,
http://help.sap.com/saphelp_47x200/helpdata/en/22/042860488911d189490000e829fbbd/frameset.htm,
Don't forget to reward if useful...
‎2007 Apr 26 9:23 AM
Hi Sweta,
Go through this info.
Check this info.
These are the types of RFC
Asynchronous RFC (aRFC)
Synchronous RFC (sRFC)
Transactional RFC (tRFC)
Queued RFC (qRFC)
Parallel RFC (pRFC)
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 .
Transactional RFC
This let you group one or more function module call together o tRFC LUW and ensure that fucnction module within LUW is called once . In contrast to aRFC and sRFC the tRFC belonging to tRFC LUW are executed in order .
tRFC is always used if a function is executed as a Logical Unit of Work (LUW). Within a LUW, all calls are
1.Executed in the order in which they are called
2.Executed in the same program context in the target system
3.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
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). You can then switch back and for between the calling dialog and the called session
RECEIVE RESULTS FROM FUNCTION Remotefunction is used within a FORM routine to receive the results of an asynchronous remote function call. The following receiving parameters are available:
IMPORTING
TABLES
EXCEPTIONS
The addition KEEPING TASK prevents an asynchronous connection from being closed after receiving the results of the processing. The relevant remote context (roll area) is kept for re-use until the caller terminates the connection.
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.
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:
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
Therefore, Queued RFC is better than Transactional RFC.
Remote Function Call:
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.
http://help.sap.com/saphelp_47x200/helpdata/en/22/042860488911d189490000e829fbbd/frameset.htm.
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) 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
For more information on RFC, please go through the link.
http://help.sap.com/saphelp_nw04/helpdata/en/6f/1bd5b6a85b11d6b28500508b5d5211/content.htm
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.
Rewards points if useful.
Rgds,
P.Naganjana Reddy
‎2007 Apr 26 9:24 AM
Remote Function call means calling a function module existing in another system.
you have to specify a destination where this function will be executed. This destination is created in transaction SM59.
call function '<FM NAME>' destination '<DEST>'.
there are different types of RFC
synchronous - your callling program will wait for the execution of remote function to finish and then proceed.
asynchronous - calling program does not wait for execution of remote function to finish. you can retrieve results later using the RECEIVE RESULTS FROM statement
two more types are there - transactional and queued rfc. please explore these...
read more in the abap help. its explained quite nicely there.
regards,
Priyank
‎2007 Apr 26 10:54 AM
Hi Sweta,
After creating the RFC (through SE37), you can implement it in your progam or another Function Module by using statment CALL FUNCTION and RFC name.
e.g. CALL FUNCTION 'F4IF_INT_TABLE_VALUE_REQUEST'
EXPORTING
RETFIELD = 'PBLNR'
VALUE_ORG = 'S'
TABLES
VALUE_TAB = l_t_loc
EXCEPTIONS
PARAMETER_ERROR = 1
NO_VALUES_FOUND = 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.
Exporting parameters of program : Importing parameter of RFC
Importing parameters of program : Exporting parameter of RFC
Changing Parameters : Both import and export
Tables Parameters : Both import and export
You can also handle the exceptions of RFC through the value of SY-SUBRC.
As in above example there are three exceptions and whichever is raised
accordingly the value of SY-SUBRC is posted
‎2007 Apr 26 11:18 AM
Hi..
nw i have got the logic ..
thanks lot for your response..
‎2007 Apr 26 10:54 AM
Hi Sweta,
After creating the RFC (through SE37), you can implement it in your progam or another Function Module by using statment CALL FUNCTION and RFC name.
e.g. CALL FUNCTION 'F4IF_INT_TABLE_VALUE_REQUEST'
EXPORTING
RETFIELD = 'PBLNR'
VALUE_ORG = 'S'
TABLES
VALUE_TAB = l_t_loc
EXCEPTIONS
PARAMETER_ERROR = 1
NO_VALUES_FOUND = 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.
Exporting parameters of program : Importing parameter of RFC
Importing parameters of program : Exporting parameter of RFC
Changing Parameters : Both import and export
Tables Parameters : Both import and export
You can also handle the exceptions of RFC through the value of SY-SUBRC.
As in above example there are three exceptions and whichever is raised
accordingly the value of SY-SUBRC is posted
Naveen Jain