Comparison of 3 types of RFC

Hi,
We have 2 custom tables with the same structure, One in the ECC system(source) and the other in R/3 system(destination) . The requirment is to sync the data between the tables. I am exploring the RFC method and require your comments on which of the 3 RFC ( asynchronous/ transactional / synchronous ) options would be the best for the given requirment, keeping in mind the error handling.
Thanks!
-Esha

Hi Raj,
for your requirement, you can use ALE /IDOC concept. search for ALE / Idoc configuration steps. Follow those steps to reach your requirement.
let us know if any help required for the same .
you can use RFC method by using synchronous method.
~linganna

Similar Messages

CBMA issue in PI 7.31 - Connection type is RFC rather than JMS.

Hi,
I am facing issue with CBMA in production PI 7.31 which is working perfectly in quality system. I configured alert rules and scheduled AlertConsumerJob also. Configured alerting.isactive to true and alerting.target to '1'.
I observed that Message Alert configuration from PIMON is routed to alert framework rather than to the page where rules that are created in ID are displayed. From nwa->soa->monitor->Message Alert Configuration, able to see the rules created in ID. Does correcting this helps me?
Not sure if this is correct or not, but i even tried pinging the url http://host:port/AdapterFramework/alerting/ping.jsp, which shows Connection type as RFC in production. In quality it was JMS. Is this the issue? Please guide me.
Thanks,
Prasanna.

Hi,
Did you run the CTC wizard for this ?
Configuring Component-Based Message Alerting - Configuring Process Integration After Installation - SAP Library
Also, refer - Create new Alert consumer and its next steps in PI7.31 dual stack
Regards,

Portability and Comparison between char types

Hi gurus,
I cannot trasport a program.
on SE38 I went to:
Extended syntax check
Portability ASCII/EBCDIC
And I got the following message:
'Greater than/less than comparisons with character type
operands may not be portable'
on this instruction
if ( hbsid-kunnr between zfiec-kunnda and zfiec-kunna ).
I also tried with
.    if ( hbsid-kunnr => zfiec-kunnda
                   and hbsid-kunnr <= zfiec-kunna ).
.    if ( hbsid-kunnr GE zfiec-kunnda ....
it gives me the same error.
Is there a helping hand ?
Thanks,
Christian

Hi,
Its a SLIN error. you can get the exhaustive list on running Extended Program check.
You can use RANGES to avoid the error or you can skip the error using "#EC PORTABLE.
Regards,
Nirmal

Types of rfc

hi everyone,
            why we use "apply control record from payload ",in idoc recevier adapter?how many types of rfc's are there?
Warm regards,
somu

Communication 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.
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)
Transactional RFC (tRFC, also originally known as asynchronous RFC) is an asynchronous communication method that executes the called function module in the RFC server only once. 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 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.
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
·         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 guarantee that the transactional order of the calls is preserved.
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 (qRFC)
To guarantee that multiple 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).
qRFC is therefore an extension 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.
Implementation of qRFC is recommended if you want to guarantee that several transactions are processed in a predefined order.

Define fault message type for RFC

Hi,
How can I define the fault message type for RFC so that when I import RFC from another server to XI, I can view this Fault type.
So far I could only see Request and Response type .
Thanks

Hi Rokie,
Acc. to me by default we are having only request and response mesages for RFC and in case some exception/fault is there the RFC will through this in the response under the Return parameter having msg,id number as sub fields which you can map to fault message type.
Sachin

How many types of rfc there

hi guru
how many types of rfc there
thanks
subhasis

Hi Subhasis ,
There are 5 types of RFC.
Here is a link to a very good documnet on RFC
<a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/f078394a-4469-2910-c4bf-853c75674694">RFC Document</a>
Regards
Arun

How many types of RFC's?

how many types of rfc's wat r they?

hi
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).
RFC consists of two interfaces : A calling interface for ABAP Programs and a calling interface for Non-SAP 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 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.
     The RFC Interface takes care of :-
- Converting all parameter data to the representation needed in the remote system
Calling the communication routines needed to talk to the remote system.
Handling communications errors, and notifying the caller, if desired ( using EXCEPTIONS paramater of the CALL FUNCTION).
You can use the CALL FUNCTION statement to call remote functions by including an additional DESTINATION clause.
CALL FUNCTION remotefunction
          DESTINATION dest
               EXPORTING f1 =
             IMPORTING f2 =
           TABLES t1 =
           EXCEPTIONS
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.
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]
Calling remote function modules BACK :-
    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.
Synchronous RFC The calling program continues the execution only after the called function is complete.
Asynchronous RFC - The calling program continues the execution without waiting for return from the called function.
       Eg: CALL FUNCTION remotefunction STARTING NEW TASK taskname.
Transactional RFC - 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. Transactional RFCs use the suffix IN BACKGROUND TASK .
       Eg : CALL FUNCTION remotefunction IN BACKGROUND TASK
regards
vijay
reward points if helpfull

Load balance for HTTP Connection to ABAP System (Type H) RFC connection

Experts,
For proxy we are using HTTP Connection to ABAP System (Connection type H) RFC connection in PI to get connected to ECC. I only see the option to use Target host in the Target system settings than Load balance option. In general ABAP Connection (Connection type 3) has Load balancing status option in Target system settings.
My requirement is I should use a logon group with the message server when PI connects to ECC. How can we achieve this? At the moment I can only use the Central Instance or any dialog server (App server) in RFC but not a logon group.
Thanks in advance.
Mahesh

Hi Naga
Could you check the link below?
http://help.sap.com/saphelp_nwmobile71/helpdata/en/47/c5935087b62d66e10000000a42189c/content.htm
https://service.sap.com/sap/support/notes/1040325

Types of RFC's

Hi,
Can any one please tell me the types of RFC's and the difference between them.
Thanks,
Subba Rao ILam

Hi,
Hi,
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCFESDE2/BCFESDE2.pdf
TRFC:
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.
QRFC:
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).
ARFC:
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) 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...
Have a look at the following document which was published recently in the SDN:
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/f078394a-4469-2910-c4bf-853c75674694
Regards,
Omkar.

How many types of rfcs are there

Hello,
Can any body explain about how many type of rfcs are there. give the difference also.
Thanks.

Hi,
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.
Rewords some points.
Rgds,
P.Nag

Type of RFC ?

From ECC6 system I need to create connection to Portal, which type of RFC should I select ? Type 3 or H ? Customer provided me load balancer ip and user id/password too. Which option to select ?
Same rfc i've to create in 4.6C system too but there is no H or G connection, what to select in 4.6C for connection to a portal ?

The RFC type should be T,
Read
http://help.sap.com/saphelp_nw04s/helpdata/EN/42/821640b7b6dd5fe10000000a155106/content.htm
Regards
Juan

Trigger Output Type through RFC

My requirement is when RFC is called then based on the invoice number and Fax number this RFC should able to create invoice document in PDF format and sent a mail to particular fax number with PDF as attachement.....
we have created output type to trigger the print program which call the smartform then then we convert smartform into PDF format and send a mail so by this we are done with part to create the PDF and email it ...
but the problem is i want to trigger output type when RFC is called....so that it will called the print program and process goes on as planned..?
Is there any FM to trigger O/p type so that i can call it in RFC
or some other option???

You did not specify what area you need to retrigger an output type for, but here is a sample to retrigger a delivery output.
CALL FUNCTION 'BAPI_LIKP_PROCESS_MSG_DIRECT'
    EXPORTING
DYNAMICOUTPUTDEVICE       =
      processing                       = PROCESSING
SORTMESSAGE               = 1
    TABLES
      deliverynumber                 = delnbrs
      outputtype                       = outputs
      messageprotocol              = bapimsgprot
      return                              = bapiret2.
Thanks

Diff Types of RFC?

Hi All,
What are the Different types of RFC??
Brain C

Hi,
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCFESDE2/BCFESDE2.pdf
TRFC:
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.
QRFC:
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).
ARFC:
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) 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...
Sri

Using Table types in RFC

Hi All,
I am trying to create one RFC. But in that RFC, I wish to use Table types as import and export parameters completly avoiding Tables tab. Will that effect the performance of RFC if I use Table types. If Yes, Please give clear clarification where it effects the performance.
Also please let me know how the performance of the RFC is effected if we use Tables tab.
Thanks,
Ravee..

"I wish to use Table types as import and export parameters completly avoiding Tables tab."
I'm not sure if Tables can be avoided, if just using regular ABAP. I know that the Importing tab would not work when I tried it (under vrs 4.6b).
Because you are launching separate processes, in separate memory areas: any parameter you use in RFC has to be known by the calling and the callee functions/programs. This means that you need a common reference. If you have more than one function module in a function group, you can use the TOP file and a 'Z' data dictionary structure.
I hope that this helps,
Dan Perecky

ABAP Table Type in RFC Callable Object in GP

Hi Experts,
I have created a RFC in ABAP that has as one of its export parameters a table type. I am trying to call this RFC in my GP process. So I created the external service callable object as required. However, when I look at the output parameters for the callable object, the table type is not shown as a list (the is list column is not checked for this parameter).
Do you know if ABAP table types is supported/recognized by GP as a list? or is this a limitation?
Any help is welcomed!
Thanks in advance.
Robert

Hi Aneel,
You can try the following:
e.g.
for j = 1 to ActiveCell.SpecialCells(11).Column
oParam4.Rows.Add
if j=1 then oParam4.Value(j, "NAME") = ActiveSheet.Cells(1,j).Value
if j=2 then oParam4.Value(j, "TYPE") = ActiveSheet.Cells(1,j).Value
if j=3 then oParam4.Value(j, "NUMB") = ActiveSheet.Cells(1,j).Value
next j
Regards,
ScriptMan

Comparison of 3 types of RFC

Similar Messages

Maybe you are looking for