RFC,TRFC

hi all,
what are the different types of RFCs and difference between them(RFC,TRFC etc)
Regards
raj

Dear Raj,
what are the different types of RFCs and difference between them(RFC,TRFC etc)
RFC Basics
This section gives a brief overview of the Remote Function Call (RFC) within an SAP System, that is
· How the RFC Interface works
· The functionality that is provided by the RFC and
· It explains the technical requirements for RFC on R/2, R/3 and external systems on all currently supported platforms.
The following background topics are available:
1. The RFC Interface
2. RFC in SAP Systems
The RFC Interface
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), but usually caller and callee will be in different systems. In the SAP System, the ability to call remote functions is provided by the Remote Function Call interface system . RFC allows for remote calls between two SAP Systems (R/3 or R/2), or between an SAP System and a non-SAP System.
RFC consists of the following interfaces:
· A calling interface for ABAP programs
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. RFC communication with the remote system happens as part of the CALL FUNCTION statement. RFC functions running in an SAP System must be actual function modules, and must be registered in the SAP System as "remote. When both caller and called program are ABAP programs, the RFC interface provides both partners to the communication. The caller may be any ABAP program, while the called program must be a function module registered as remote.
o The topic Calling Remote Function Modules in ABAP provides details on calling function modules registered as remote.
o The topic Writing Remote Function Modules in ABAP provides information on writing function modules that you want to call remotely.
· Calling interfaces for non-SAP programs
When either the caller or the called partner is a non-ABAP program, it must be programmed to play the other partner in an RFC communication. To help implement RFC partner programs in non-SAP Systems, SAP provides
External Interfaces
External programs to call function modules in SAP R/2 or R/3 systems and execute them in these systems can use rFC-based and GUI-based interfaces. Vice versa, ABAP programs in R/2 or R/3 can use the functions provided by external programs via these interfaces.
RFC in SAP Systems RFC is an extension of CALL FUNCTION in a distributed environment. Existing function modules can be executed from within a remote system (R/2 or R/3) via an RFC call. Adding a DESTINATION clause to the CALL FUNCTION statement does this:
The destination parameter displays an entry in the RFCDES table (which is defined with transaction SM59). This entry contains all necessary parameters to connect to and log in the destination system. The RFC API on OS/2, Windows, Windows NT and all R/3-based UNIX platforms makes it possible to use the RFC functionality between an SAP System (R/3 from Release 2.1 and R/2 from Release 5.0D onwards) and a C program on the above platforms. It is of no significance to the caller whether the remote function is provided in an SAP System or in a C program. RFC frees the ABAP programmer from having to program his own communications routines. When you make an RFC call, the RFC interface takes care of:
· Converting all parameter data to the representation needed in the remote system. This includes character string conversions, and any hardware-dependent conversions needed (for example, integer, floating point). All ABAP data types are supported.
· There is no support for Dictionary structures.
· Calling the communication routines needed to talk to the remote system.
· Handling communications errors, and notifying the caller, if desired. (The caller requests notification using the EXCEPTIONS parameter of the CALL FUNCTION statement.)
The RFC interface is effectively invisible to the ABAP programmer. Processing for calling remote programs is built into the CALL FUNCTION statement. Processing for being called is generated automatically (in the form of an RFC stub) for every function module registered as remote. This stub serves as an interface between the calling program and the function module.
A distinction is made between an RFC client and RFC server. RFC client is the instance that calls up the Remote Function Call to execute the function that is provided by an RFC server. In the following, the functions that can be executed remotely will be called RFC functions and the functions provided via RFC API will be called RFC calls.
All RFC functions available in a remote RFC server system, which are called by an RFC client, are processed transactionally. This means that after execution of the first RFC function in the RFC server system the complete context (all globally defined variables in the RFC server program or in the main program of a function module) is available for further RFC functions. The RFC connection is closed only
· When the context of the calling ABAP program has ended or
· Explicitly by RfcAbort or RfcClose in the external program.
Until Release 3.0 the connection to an R/3 System must be established to a previously defined application server. From Release 3.0 onwards, it is also possible to have an application server assigned by the message server on the basis of a load balancing procedure. This applies both for RFC between R/3 systems and between external systems and R/3 systems.
To make the execution of RFC functions reliable, safe and independent from the availability of the RFC server or RFC server system, the transactional RFC (tRFC) was introduced for R/3 systems from Release 3.0 onwards. This ensures that the called function module is executed only once in the RFC server system. In transactional RFC calls, the data that belongs to an RFC function must first be stored temporarily on the SAP database in the RFC client system. When processing is completed, this must be reported back to the calling ABAP program. Everything else is handled by the tRFC component in the R/3 System. Since a database is not always available on external systems, the link to the tRFC interfaces is implemented such that the client or server programs based on RFC API must take on some administrative functions to ensure that the respective function module is executed "only once".
Best Regards,
Srikanth
Reward the useful answers and you will get one point yourself<a href="/people/baris.buyuktanir2/blog/2007/04/04/point-for-points-reward-yourselfyourself

Similar Messages

Reg:RFC &TRFC

hi,
we have 2 clients 800 and 810 in the same server.
we have created a function module in 800 and wrote a simple select statement to fetch data from VBAK table and made it REMOTE.And i am fetching the data from 810 to update a table in 800.
    When executed with SRFC its fetching the data.but with TRFC data is not being fetched. why
the code as follows:
DATA : zpexport1 TYPE TABLE OF zpexport .
PARAMETERS p_kunnr TYPE kunnr.
CALL FUNCTION 'ZP_EXAMPLEBAPI'
DESTINATION 'ISPCLNT810'
EXPORTING
    kunnr           = p_kunnr
TABLES
    zpexport1       = zpexport1
IF zpexport1[] IS NOT INITIAL.
MESSAGE 'SUCCESS' TYPE 'S'.
ENDIF.
regards

hi,
we have 2 clients 800 and 810 in the same server.
we have created a function module in 800 and wrote a simple select statement to fetch data from VBAK table and made it REMOTE.And i am fetching the data from 810 to update a table in 800.
    When executed with SRFC its fetching the data.but with TRFC data is not being fetched. why
the code as follows:
DATA : zpexport1 TYPE TABLE OF zpexport .
PARAMETERS p_kunnr TYPE kunnr.
CALL FUNCTION 'ZP_EXAMPLEBAPI'
DESTINATION 'ISPCLNT810'
EXPORTING
    kunnr           = p_kunnr
TABLES
    zpexport1       = zpexport1
IF zpexport1[] IS NOT INITIAL.
MESSAGE 'SUCCESS' TYPE 'S'.
ENDIF.
regards

Standard RFC Vs tRFC

Hi..
While studying some XI material I came across tRFC. Please some body can tell me what is the difference between standard RFC and tRFC.
Thanks,
Pavani

Hi Pavani,
There are 5 types of RFCs
1. Synchronous RFC (sRFC) - calll waits for target response n then only the control proceeds
2. Asynchronous RFC (aRFC) - can be with or without response - "With" action like emailing based on any condition "Without" - exception raised during execution of RFM not propogated to client.
3. Transactional RFC (tRFC) - let us group one or more function modules - all FM are executed or none. Used for guaranteed transactional execution
4. Queued RFC (qRFC) - To conrol the execution order
5. Parallel RFC (pRFC) - Extension of aRFC. We can select group of Application servers to execute the RFCs. Multiple RFC destinations, Built-in load balancing and alerting mechanism

[Reward if helpful]
Regards,
Prateek

TRFC and Asynchronous RFC

Is there any diff between TRFC and ARFC ?
Is TRFC another name for ARFC?

Hi,
Transactional RFC (tRFC) they are previously known as ARFC
Transactional RFC (tRFC, previously known as asynchronous RFC) is an asynchronous communication method that executes the called function module just once in the RFC server. 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. The calling dialog program can proceed without waiting to see whether 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
·         are 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 maintain the transactional sequence of the calls.
Disadvantages of tRFC
·       tRFC processes all LUWs independently 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. It is therefore impossible to guarantee that the transactions will be executed in the sequence dictated by the application. The only thing that can be guaranteed is that all LUWs are transferred sooner or later.
regards
prasanth

In RFC

hi
In which cases we will create a RFC function moldule

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.
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
RFC Use in ABAP :
You can use the CALL FUNCTION statement to call remote functions, just as you would call local function modules. However, you must include an additional DESTINATION clause to define where the function should run:
CALL FUNCTION (RFC Name) DESTINATION Dest
EXPORTING
F1 = a1
F2 = a2
IMPORTING
F3 = a3
CHANGING
F4 = a4
TABLES
t1 = ITAB
EXCEPTIONS
http://help.sap.com/saphelp_nw04s/helpdata/en/22/0424ba488911d189490000e829fbbd/frameset.htm
http://help.sap.com/saphelp_nw04s/helpdata/en/22/0424ba488911d189490000e829fbbd/frameset.htm
Regards.

Limitations of RFC Adapter XI 3.0

In this presentation ( https://www.sdn.sap.com/content_documents/.../SAP%20XI%202.0%20-%20Features.pdf page 20), the following limitations are listed for the RFC Adapter for XI 2.0:
Functionality
Synchronous RFC
No support forRFMsthat use update task without COMMIT WORK
No SAP GUI
No callbacks
No session handling
No RFCs to non-SAP systems (using RFC client or server libraries)
tRFC: Support for exactly-once delivery for one message/call
Not all tRFC functionality
No bundling of multiple calls
With version 3.0, what are the current limitations??

SAP Documentation states the following:
Constraints
Note the following restrictions:
·        Assignment is only guaranteed for transactional RFCs (tRFCs), that is, for messages with quality of service Exactly Once (EO).
·        There is no transactional context for more than one RFC call for each LUW (Logical Unit of Work).
·        Not provided: SAPGUI, callbacks, and qRFC (quality of service Exactly Once In Order (EOIO)).
·        RFC library clients (RFC SDK) are not supported.
·        The context in the called system is not kept open over multiple calls (calls are stateless; there is no session).
·        Only the payload of a received message is evaluated. Additional attachments are ignored and not forwarded.
·        The receiver adapter can only process valid RFC XML documents, for example, those generated by the sender adapter or by the SAP JCo.
available at: http://help.sap.com/saphelp_nw04/helpdata/en/33/c6e63b60c25767e10000000a11402f/content.htm
best Regards
Christien

JDBC---RFC will Support Sync?????????

Hi All,
Wil JDBC--RFC Senario supports for Sync Comunication with out using BPM???
Regards
Vamsi

Hi Vamshi,
For JDBC (Sender/Receiver )Scenario we have to Install the JDBC Drivers on XI Server.
Use those Driver name and Connection in JDBC Adapter to connect to the Database.
For RFC Sender Adapter we have to create the Program ID in SAP R/3 side.
For RFC Receiver no need of any Extra settings.
step by step RFC to JDBC scenario
https://www.sdn.sap.com/irj/sdn/wiki?path=/display/xi/step%2bby%2bstep%2brfc%2bto%2bjdbc%2bscenario
Tips and Tutorial for Sender JDBC Adapter
/people/yining.mao/blog/2006/09/13/tips-and-tutorial-for-sender-jdbc-adapter
http://help.sap.com/saphelp_nw04s/helpdata/en/22/b4d13b633f7748b4d34f3191529946/frameset.htm
http://help.sap.com/saphelp_nw2004s/helpdata/en/22/b4d13b633f7748b4d34f3191529946/content.htm
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/3867a582-0401-0010-6cbf-9644e49f1a10
Also you can look at this scenario --> File to JDBC:-
/people/sap.user72/blog/2005/06/01/file-to-jdbc-adapter-using-sap-xi-30
/people/yining.mao/blog/2006/09/13/tips-and-tutorial-for-sender-jdbc-adapter
/people/sameer.shadab/blog/2005/10/24/connecting-to-ms-access-using-receiver-jdbc-adapter-without-dsn
/people/saravanakumar.kuppusamy2/blog/2005/01/19/rdbms-system-integration-using-xi-30-jdbc-senderreceiver-adapter
SENDER RFC
Registered server program name which is maintained in the ABAP should be called in the program ID.
for more information follow this links
/people/michal.krawczyk2/blog/2005/03/29/configuring-the-sender-rfc-adapter--step-by-step
/people/shabarish.vijayakumar/blog/2008/01/08/troubleshooting--rfc-and-soap-scenarios-updated-on-20042009
How to test the RFC to Flat File scenario
Type 3 ABAP Connection :
ex 1) If we want to execute any function module from one SAP system in another , we need type 3.
We define an RFC destination say ECC6CLNT100 with required parameters.
and to test it go to SE37, select any common sap function module and when you execute that it will ask
for RFC destination. you provide this destination and the function module will be executed in the target
system.
ex2) when you create a partner profile, you need to create a port and for creating a port, we need to
specify an RFC destination. here also we use type 3.
Type H.
ex1) when we need to send xml messages from an SAP system to any other system, we need this.
For example when we send messages using proxy from SAP system to the integration engine of XI, we
need type H.
Type T.
ex1) To we make an RFC call from R/3 to XI , we use sender RFC adapter in XI.
In R/3 system we need to create an RFC destination of type T.
Different types of RFC are :-
Asynchronous RFC - aRFC
Synchronous RFC - sRFC
Transactional RFC - tRFC
Queue RFC - qRFC
Parallel RFC - pRFC
Chk this link also:
Link :http://help.sap.com/saphelp_nw04/helpdata/en/6f/1bd5b6a85b11d6b28500508b5d5211/content.htm
https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/1685 [original link is broken] [original link is broken] [original link is broken]
Please go through the following links.
/people/bhavesh.kantilal/blog/2006/07/03/jdbc-receiver-adapter--synchronous-select-150-step-by-step JDBC Receiver Adapter -- Synchronous Select Step by Step
/people/yining.mao/blog/2006/09/13/tips-and-tutorial-for-sender-jdbc-adapter Sender JDBC adapter
/people/arpit.seth/blog/2005/06/27/rfc-scenario-using-bpm--starter-kit
FILE- RFC-FILE Synchronous (Using BPM)
/people/shabarish.vijayakumar/blog/2008/01/08/troubleshooting--rfc-and-soap-scenarios-updated-on-20042009 Trouble Shooting RFC and SOAP Scenario
Regards,
Vinod.

3rd party to sap using RFC adapter

Hi Folks,
I'm sending some IDOC to sap from the 3rd party. I have to use RFC (TRFC call) adapter as sender and IDOC as receiver adapter.
Can you please suggest me how to configure teh sender side.
Regards....

>
santosh nayak wrote:
> Hi Folks,
> I'm sending some IDOC to sap from the 3rd party. I have to use RFC (TRFC call) adapter as sender and IDOC as receiver adapter.
> Can you please suggest me how to configure teh sender side.
>
> Regards....
In order to use RFC as sender need to configure the below
SAP Side
RFC destination of type T using SM59 tcode
PI side
RFC destination of TYPE t type using same tcode
Note the progid provided should be same in both RFC destionations
Then during execution of RFC in SAP side need to provide the RFC destionation created there
HTH
Rajesh

What is RFC and how does work

Hi Sap Guru's
I want to know the RFC in SAP and how does it work?
Thanks in advance
Regards
Ramesh

Hi Ramesh,
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.
Hope this resolves your query.
Reward all the helpful answers.
Regards

Differences between rfc and ale/idoc.

hi ..
       will u please send the differences between rfc and ale/idoc's.

Hi,
Please reward with points if helpful................
ALE is SAP proprietary technology that enables data communications between two or more SAP R/3 systems and/or R/3 and external systems. There are three layers in ALE system: application services, distribution services, and communication services.
For communication services, ALE performs a Remote Function Call (RFC) using the port definition and RFC destination specified by the customer model. RFC is used to communicate 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.
Means of creating and operating distributed applications.
The purpose of Application Line Enabling is to guarantee a distributed, but integrated, R/3 installation. This involves business-controlled message exchange with consistent data across loosely linked SAP applications.
Application integration is achieved not via a central database, but via synchronous and asynchronous communication.
Application Link Enabling comprises the following three layers:
application services
distribution services
communication services
Two Development Models
     Distribution using BAPIs
     Distribution using Message type
The programming model "Distribution using message types" contains the definitions of message types and IDoc types and the ABAP code for processing inbound and outbound IDocs.
Defining message types and IDoc types:
If you want to create message type enhancements for master data distribution, you also have to create a new message type for each enhancement.
The ALE interface does not allow you to create different segment data for different IDoc types for the same message type.
Writing ABAP code:
         Outbound Processing
           Inbound Processing
You can find information on other ALE functions under:
                               Master Data Distribution
                              Communicating with Non-R/3 Systems
1. The Remote Function Call facility allows you to call an R/3 Function module on a remote machine.
2. To communicate between two R/3 Systems and also with an External System. External Application program also can call these function module for integration.
3. RFC or sRFC - Synchronous RFC
                 aRFC - Asynchronous RFC
                  tRFC - Transactional RFC
                  qRFC - Queued RFC (I.e. Serialization of tRFC)
Types of RFC Call
Synchronous
CALL FUNCTION Func Destination Dest
CALL FUNCTION func DESTINATION 'NONE' ...
CALL FUNCTION func DESTINATION BACK' ...
Asynchronous
CALL FUNCTION func STARTING NEW TASK taskname
PERFORMING form ON END OF TASK
RECEIVE RESULTS FROM FUNCTION func
Thanks
sivaparvathi

Regarding: RFC Function Mod

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

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-853c75674694

What is the use of t-rfc in ALE? compared to t-rfc, Qrfc is better and effi

what is the use of t-rfc in ALE? compared to t-rfc, Qrfc is better and efficient?

Hi Sunil,
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.
Hope this resolves your query.
Reward all the helpful answers.
Regards

Difference between different RFCs

Hi All,
Could you please provide me with some useful material or brief knowledge where i can find out :
what is an s-RFC, t-RFC and q-RFC ? ?
Where all these are used ? ?
And what is the Difference between them ? ?
Regards,
Arkesh Sharma

Please check this link
http://help.sap.com/saphelp_nw2004s/helpdata/en/62/73241e03337442b1bc1932c2ff8196/content.htm
http://help.sap.com/saphelp_nw2004s/helpdata/en/6f/1bd5b6a85b11d6b28500508b5d5211/content.htm
The qRFC Communication Model
qRFC Properties and Possible Uses
All types of applications are instructed to communicate with other applications. This communication may take place within an SAP system, with another SAP system, or with an application from a remote external system. An interface that can be used for dealing with this task is the Remote Function Call (RFC). RFCs can be used to start applications in remote systems, and to execute particular functions.
Whereas the first version of the RFC, the synchronous RFC, (sRFC) required both systems involved to be active in order to produce a synchronous communication, the subsequent generations of RFC had a greater range of features at their disposal (such as serialization, guarantee for one-time-only execution, and that the receiver system does not have to be available). These features were further enhanced through the queued RFC with inbound/outbound queue.
Communication between applications within an SAP system and also with a remote system can basically be achieved using the Remote Function Call (RFC). Here, the following scenarios are possible:
· Communication between two independent SAP systems
· Communication between a calling SAP system and an external receiving system
· Communication between a calling external system and an SAP receiving system
The following communication model shows what these communication scenarios may look like in reality. The actual sending process is still done by the tRFC (transactional Remote Function Call). Inbound and outbound queues are added to the tRFC, leaving us with a qRFC (queued Remote Function Call). The sender system is also called the client system, while the target system corresponds to the server system.
Scenario 1: tRFC
This scenario is appropriate is the data being sent is independent of each other. A calling application (or client) in system 1 uses a tRFC connection to a called application (or server) in system 2. In this scenario, data is transferred by tRFC, meaning that each function module sent to the target system is guaranteed to be executed one time only. You cannot define the sequence in which the function modules are executed, nor the time of execution. If an error occurs during the transfer, a batch job is scheduled, which sends the function module again after 15 minutes.
Scenario 2: qRFC with outbound queue
In this scenario, the sender system uses an outbound queue, to serialize the data that is being sent. This means that function modules which depend on each other (such as update and then change) are put into the outbound queue of the sender system, and are guaranteed to be sent to the target system one after each other and one time only. The called system (server) has no knowledge of the outbound queue in the sender system (client), meaning that in this scenario, every SAP system can also communicate with a non-SAP system. (Note: the programming code of the server system must not be changed. However, it must be tRFC-capable.)
Scenario 3: qRFC with inbound queue (and outbound queue)
In this scenario, as well as an outbound queue in the sender system (client), there is also an inbound queue in the target system (server). If a qRFC with inbound queue exists, this always means that an outbound queue exists in the sender system. This guarantees the sequence and efficiently controls the resources in the client system and server system. The inbound queue only processes as many function modules as the system resources in the target system (server) at that time allow. This prevents a server being blocked by a client. A scenario with inbound queue in the server system is not possible, since the outbound queue is needed in the client system, in order to guarantee the sequence and to prevent individual applications from blocking all work processes in the client system.
Properties of the Three Communication Types
To help you decide which communication type you should use in your system landscape for your requirements, the advantages of the three communication types are listed below:
1. tRFC: for independent function modules only
2. qRFC with outbound queue: guarantees that independent function modules are sent one after each other and one time only (serialization). Suitable for communication with non-SAP servers.
3. qRFC with inbound queue: in addition to the outbound queue in the client system, an inbound queue makes sure that only as many function modules are processed in the target system (server) as the current resources allow. Client and server system must be SAP systems. One work process is used for each inbound queue.
The qRFC Communication Model
Purpose
Communication within an SAP system or with a remote system can take place using Remote Function Call (RFC). This enables the following scenarios:
· Communication between two independent SAP systems
· Communication between a calling SAP system and an external receiving system
· Communication between a calling external SAP system and an SAP system as the receiving system
Implementation Considerations
The following communication model shows how these communication scenarios can occur in practice. tRFC (transactional Remote Function Call) is still responsible for actually sending communications. tRFC is preceded by inbound and outbound queues, which have led to the name qRFC (queued Remote Function Call). The sending system is called the client system, and the target system represents the server system.
There are three data transfer scenarios:
Scenario 1: tRFC
This scenario is suitable if the data being sent is not interrelated. A calling application (or client) in system 1 uses a tRFC connection to a called application (or server) in system 2. In this scenario, the data is transferred using tRFC. This means that each function module sent to the target system is guaranteed to be processed once. The order in which the function modules are executed, and the time they are executed, cannot be determined. If a transfer error occurs, a background job is scheduled that resends the function module after a defined period of time.
Scenario 2: qRFC with Outbound Queue
In this scenario, the sending system uses an outbound queue to serialize the data being sent. This means that mutually dependent function modules are placed in the outbound queue of the sending system and are guaranteed to be sent in the correct sequence, and only once, to the receiving system. The called system (server) has no knowledge of the outbound queue in the sending system (client). Using this scenario, every SAP system can communicate with a non-SAP system (the program code of the server system does not need to be changed, but it must be tRFC-compliant).
Scenario 3: qRFC with Inbound Queue (and Outbound Queue)
In this scenario, in addition to the outbound queue in the sending system (client), there is also an inbound queue in the target system (server). qRFC with an inbound queue always means that an outbound queue exists in the sending system. This guarantees that the sequence of communications is preserved, and at the same time the resources in the client and in the server system are controlled efficiently. The inbound queue is processed using an inbound scheduler, which only processes as many queues in parallel as the current resources in the target system (server) will allow, This prevents a server from being blocked by a client.
Features
Features of the Three Communication Types
To help you decide which communication types you need to implement according to your system landscape and your requirements, the advantages of the three types of communication are explained below:
· tRFC
Suitable only for independent function module calls; the sequence of the calls is not preserved
· qRFC with outbound queue
Function modules in a queue are guaranteed to be processed only once and in sequence (serialization). Also suitable for communication with non-SAP servers.
· qRFC with inbound queue
The function modules created in the outbound queue are transferred from the outbound queue to the inbound queue; the sequence of the function modules is preserved. An inbound scheduler processes the inbound queues in accordance with the specified resources. Both the client and the server system must be SAP systems. One work process is used for each inbound queue.
Queued Remote Function Call (qRFC)
Purpose
All types of applications are instructed to communicate with other applications. This communication may take place within an SAP system, with another SAP system, or with an application from a remote external system. An interface that can be used for dealing with this task is the Remote Function Call (RFC). RFCs can be used to start applications in remote systems, and to execute particular functions.
Integration
In contrast the first version of RFC, synchronous RFC (sRFC), which required both participating systems to be active to form synchronous communication, subsequent generations of RFC now provide a considerably extended range of functions (for example, serialization, guarantee that processing occurs once, and the receiving system does not have to be available). These features were further enhanced through the queued RFC with inbound/outbound queue.
Contents:
The information about qRFC is organized into the following main sections, with more detailed subsections:
The qRFC Communication Model
· qRFC with Outbound Queues
· qRFC with Inbound Queues
qRFC Administration
· qRFC Administration: Introductory Example
· Outbound Queue Administration
· Inbound Queue Administration
qRFC Programming
· qRFC Programming: Introductory Example
· Outbound Queue Programming
· Inbound Queue Programming
· qRFC API
For an introduction to the new bgRFC (Background RFC), use the following links:
bgRFC (Background RFC)
· bgRFC Administration
· bgRFC Programming
Using Asynchronous Remote Function Calls
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 functionu2019s 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
To start a remote function call asynchronously, use the following syntax:
CALL FUNCTION Remotefunction STARTING NEW TASK Taskname
DESTINATION ...
EXPORTING...
TABLES ...
EXCEPTIONS...
The following calling parameters are available:
§ TABLES
passes references to internal tables. All table parameters of the function module must contain values.
§ EXPORTING
passes values of fields and field strings from the calling program to the function module. In the function module, the corresponding formal parameters are defined as import parameters.
§ EXCEPTIONS
See Using Predefined Exceptions for RFCs
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)
Transactional RFC(tRFC, previously known as asynchronous RFC) is an asynchronous communication method that executes the called function module just once in the RFC server. 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. The calling dialog program can proceed without waiting to see whether 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
· are 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 maintain the transactional sequence of the calls.
Disadvantages of tRFC
· tRFC processes all LUWs independently 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. It is therefore impossible to guarantee that the transactions will be executed in the sequence dictated by the application. The only thing that can be guaranteed is that all LUWs are transferred sooner or later

REG:ALE,IDoc , RFC

HI,
PLEASE SEND ANY GOOD MTERIAL FOR ALE IDOC , RFC.
THANK YOU
ASHOK KUMAR

hi,
ALE / IDOC
http://help.sap.com/saphelp_erp2004/helpdata/en/dc/6b835943d711d1893e0000e8323c4f/content.htm
http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc
http://edocs.bea.com/elink/adapter/r3/userhtm/ale.htm#1008419
http://www.netweaverguru.com/EDI/HTML/IDocBook.htm
http://www.sapgenie.com/sapedi/index.htm
http://www.sappoint.com/abap/ale.pdf
http://www.sappoint.com/abap/ale2.pdf
http://www.sapgenie.com/sapedi/idoc_abap.htm
http://help.sap.com/saphelp_erp2005/helpdata/en/0b/2a60bb507d11d18ee90000e8366fc2/frameset.htm
http://help.sap.com/saphelp_erp2005/helpdata/en/78/217da751ce11d189570000e829fbbd/frameset.htm
http://www.allsaplinks.com/idoc_sample.html
http://www.sappoint.com/abap.html
http://help.sap.com/saphelp_erp2004/helpdata/en/dc/6b835943d711d1893e0000e8323c4f/content.htm
http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc
http://edocs.bea.com/elink/adapter/r3/userhtm/ale.htm#1008419
http://www.netweaverguru.com/EDI/HTML/IDocBook.htm
http://www.sapgenie.com/sapedi/index.htm
http://www.allsaplinks.com/idoc_sample.html
ALE/ IDOC/ XML
http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc
http://www.thespot4sap.com/Articles/SAP_XML_Business_Integration.asp
http://help.sap.com/saphelp_srm30/helpdata/en/72/0fe1385bed2815e10000000a114084/content.htm
IDOC Convertion
/people/kevin.wilson2/blog/2005/12/07/changing-fields-in-an-idoc-segment
http://www.sappoint.com/abap/ale.pdf
http://www.sappoint.com/abap/ale2.pdf
http://www.sapgenie.com/ale/configuration.htm
http://www.sappoint.com/abap/ale.pdf
http://www.sappoint.com/abap/ale2.pdf
http://www.sapdevelopment.co.uk/training
http://www.sapgenie.com/ale/why_ale.htm
http://www.sapdevelopment.co.uk/training
http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc
ALE/ IDOC
http://help.sap.com/saphelp_erp2004/helpdata/en/dc/6b835943d711d1893e0000e8323c4f/content.htm
http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc
http://edocs.bea.com/elink/adapter/r3/userhtm/ale.htm#1008419
http://www.netweaverguru.com/EDI/HTML/IDocBook.htm
http://www.sapgenie.com/sapedi/index.htm
http://www.sappoint.com/abap/ale.pdf
http://www.sappoint.com/abap/ale2.pdf
http://www.sapgenie.com/sapedi/idoc_abap.htm
http://help.sap.com/saphelp_erp2005/helpdata/en/0b/2a60bb507d11d18ee90000e8366fc2/frameset.htm
http://help.sap.com/saphelp_erp2005/helpdata/en/78/217da751ce11d189570000e829fbbd/frameset.htm
http://www.allsaplinks.com/idoc_sample.html
http://www.sappoint.com/abap.html
http://help.sap.com/saphelp_erp2004/helpdata/en/dc/6b835943d711d1893e0000e8323c4f/content.htm
http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc
http://edocs.bea.com/elink/adapter/r3/userhtm/ale.htm#1008419
http://www.netweaverguru.com/EDI/HTML/IDocBook.htm
http://www.sapgenie.com/sapedi/index.htm
http://www.allsaplinks.com/idoc_sample.html
ALE/ IDOC/ XML
http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc
http://www.thespot4sap.com/Articles/SAP_XML_Business_Integration.asp
http://help.sap.com/saphelp_srm30/helpdata/en/72/0fe1385bed2815e10000000a114084/content.htm
You need to create idocs for the same. Have a look at below link.It will heip you surely.
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCSRVEDI/CAEDI.pdf
To Create Idoc we need to follow these steps:
Create Segment ( WE31)
Create Idoc Type ( WE30 )
Create Message Type ( WE81 )
Assign Idoc Type to Message Type ( WE82 )
Creating a Segment
Go to transaction code WE31
Enter the name for your segment type and click on the Create icon
Type the short text
Enter the variable names and data elements
Save it and go back
Go to Edit -> Set Release
Follow steps to create more number of segments
Create IDOC Type
Go to transaction code WE30
Enter the Object Name, select Basic type and click Create icon
Select the create new option and enter a description for your basic IDOC type and press enter
Select the IDOC Name and click Create icon
The system prompts us to enter a segment type and its attributes
Choose the appropriate values and press Enter
The system transfers the name of the segment type to the IDOC editor.
Follow these steps to add more number of segments to Parent or as Parent-child relation
Save it and go back
Go to Edit -> Set release
Create Message Type
Go to transaction code WE81
Change the details from Display mode to Change mode
After selection, the system will give this message The table is cross-client (see Help for further info). Press Enter
Click New Entries to create new Message Type
Fill details
Save it and go back
Assign Message Type to IDoc Type
Go to transaction code WE82
Change the details from Display mode to Change mode
After selection, the system will give this message The table is cross-client (see Help for further info). Press Enter.
Click New Entries to create new Message Type.
Fill details
Save it and go back
Go thro' thesre links:-
http://help.sap.com/saphelp_46c/helpdata/en/dc/6b835943d711d1893e0000e8323c4f/content.htm
http://help.sap.com/saphelp_erp2005/helpdata/en/0b/2a6620507d11d18ee90000e8366fc2/frameset.htm
http://www.sappoint.com/presentation.html
http://www.allsaplinks.com/idoc_search.html
http://www.sapgenie.com/sapedi/idoc_abap.htm
http://www.thespot4sap.com/Articles/SAP_ALE_IDOCS.asp
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-853c75674694
Regards
Ashu

Detail RFC

Hi all
Pls tell me deatil of RFC, How we can create RFC in R/3
Thanks & regards
Naresh Kumar

Hi Naresh
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-853c75674694
You can find the entire information on RFCs
http://help.sap.com/search/highlightContent.jsp
Regards Rk

RFC,TRFC

Similar Messages

Maybe you are looking for