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="https://answers.sap.com/people/baris.buyuktanir2/blog/2007/04/04/point-for-points-reward-yourselfyourself
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.