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 function’s 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.

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,

  • 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

  • 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 function’s 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 function’s 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

  • About types of rfcs

    dear all,
              this is jyothi. can u please explain the different rfcs and waht is the difference between those types.

    HI,
    SYNCHRONOUS R F C:
    With synchronous RFC, processing stops in the calling program until the called remote function is processed and its output is returned. Then in the calling program, the processing continues after the call.
    The statement CALL FUNCTION ... DESTINATION enables you to call remote ABAP function modules or C routines in external server programs.
    When you call a function in this way, always include handling for the standard exceptions COMMUNICATION_FAILURE and SYSTEM_FAILURE.
    The exception COMMUNICATION_FAILURE is resolved by the system if the specified destination in the sideinfo table RFCDES is not maintained, or if the connection to the remote system cannot be established.
    The exception SYSTEM_FAILURE is resolved if the function module or C routine that you want to start in the remote system is not available.
    The connection to a remote destination remains intact for as long as the context of the calling program remains active. The function groups addressed in the remote destination remain active for as long as the calling program itself remains active (this is the same as with local calls). This means that if you call two function modules from the same function group one after the other, they can both access the same global data of the function group.
    Each function module called using synchronous RFC forms its own logical unit of work (LUW) (exception:
    You can debug function modules called remotely in R/3 - R/3 connections.
    If a remotely-called function module uses dialogs (for example, CALL SCREEN,
    CALL TRANSACTION or lists), they are executed in the session of the caller (and are fully functional).
    Note that RFC dialogs in background processing lead to a program termination with the exception SYSTEM_FAILURE (but you can use RFC within background processing).
    ASYNCHRONOUS RFC :
    In an asynchronous Remote Function Call, the called remote function is started and then continues processing on its own immediately in the calling program. Remote function processing is separate from the calling program. The function output can be received later in the program.
    Asynchronous RFC is intended for parallel processing of processes.
    With the addition STARTING NEW TASK you can call a remote function module asynchronously. You can use any task name.
    The function module that you call is executed in its own work process.
    You can also use aRFC in background processing. Note, however, that even here, each aRFC call occupies a dialog work process.
    In the sideinfo table RFCDES, you can set the number of aRFC calls for each destination using the aRFC options. After these aRFC calls an automatic load check is performed on the target server. If resource bottlenecks are detected, the system waits for a short time for the next aRFC call,
    meant for the same remote system, and the client program is rolled out of its work process. It can then receive results from previous aRFC calls.
    During the call, you may not specify an IMPORTING addition since the call does not wait for the end of the function module. Here, you can only handle the two system exceptions, COMMUNICATION_FAILURE and SYSTEM_FAILURE for the same reason. The function module output must be received and the function module-specific exceptions must be handled later on in a different place. (See following slides)
    Receiving the function module output and handling the function module-specific exceptions are optional, however.
    A program can receive output (parameters and exceptions) from a function module that is running asynchronously.
    To implement this, when you call use the addition "PERFORMING ON END OF TASK", where the specified subroutine must exist in your program, and through which the output of the function module is received using command "RECEIVE RESULTS FROM FUNCTION . .". When the function module ends, the subroutine is called automatically.
    The subroutine must also have a formal parameter with any name you choose. When the subroutine is called, it receives the accompanying task name. This parameter lets you see which aRFC call just ended, and you can receive the relevant
    output using the RECEIVE RESULTS FROM FUNCTION command.
    The subroutine may not contain any statements that interrupt the program execution (such as CALL SCREEN, SUBMIT, COMMIT WORK, WAIT, RFCs, W or I messages). WRITE statements in this subroutine specially defined for aRFC have no effect.
    The subroutine can only be executed automatically if the calling program is in rollout status. -> "WAIT UNTIL" statements (see next slide).
    The addition KEEPING TASK with the RECEIVE statement causes the function group context that was loaded remotely to wait until the calling program has ended. This lets you use the old remote context with later aRFC calls with the same task name.
    The language element WAIT UNTIL with the addition PERFORMING is only useful with aRFC, and otherwise has no effects.
    When the WAIT UNTIL statement is executed, the conditions specified are checked.
    If it is fulfilled, the program processing continues directly after the WAIT UNTIL statement.
    Otherwise the system waits in rollout status for the output from the aRFCs. If the aRFC output is now returned, the form routine specified during the call is executed and is sent back to the WAIT UNTIL statement.
    This check/wait procedure repeats until the WAIT conditions are fulfilled, or until there are no more open RFC calls.
    Note that the WAIT UNTIL statement sets the SY-SUBRC. Therefore, store the SY-SUBRC value (set in the form routine by exceptions-handling in RECEIVE RESULTS) in its own global variable before leaving the form routine, if you need this value again later (after WAIT UNTIL).
    aRFC is particularly suited for implementing parallel processing in several R/3 Systems.
    You can also use aRFC within the same SAP R/3 System, for example, to move some of the processing load to an application server specially used for this.
    Enter the RFC destination that refers to the corresponding application server. (You can find this under Internal connections in Transaction SM59.)
    You can also use aRFC locally within the same application server to implement parallel processing in several work processes.
    Here you do not need to specify a destination.
    Note, however, that several work processes will be occupied by your program at the same time.
    LOAD BALANCING USING RFC GROUPS:
    You can divided the application servers for an SAP R/3 System into different RFC groups using Transaction SM59.
    When calling a function module within this R/3 System, you can specify one of the defined RFC groups using the addition DESTINATION IN GROUP , which selects the server that has the lowest load in order to execute the function module.
    Instead of specifying a specific RFC group, you can also enter the word DEFAULT. The server is selected from all the application servers of the R/3 System.
    If all the servers of the specified group are overloaded (see next slide), the exception RESOURCE_FAILURE is triggered.
    Note that:
    - You have to specify the addition DESTINATION IN GROUP after STARTING NEW TASK as opposed to the DESTINATION addition.
    - You can only use this addition within the current SAP R/3 System (you cannot have additional DESTINATION entries).
    For each server in the specified RFC group, the system checks if the application server has:
    - a dispatcher queue load of <> No IMPORTING . . . / PERFORMING . . . ON END OF TASK when calling;
    -> No RECEIVE RESULTS FROM FUNCTION . . .
    In the source system, you can use the administration transaction SM58 that lets you display and modify tRFC-LUWs.
    EXECUTION:
    tRFC calls are first stored in the local tRFC tables ARFCSSTATE and ARFCSDATA. The execution status of the LUWs is logged in table ARFCSSTATE, while ARFCSDATA contains the input data for the tRFCs.
    If you do not want to execute a remote LUW immediately, rather trigger it at a later time, call the function module START_OF_BACKGROUNDTASK before the COMMIT WORK statement locally. Here, you must enter the date and time of execution.
    The COMMIT WORK statement automatically schedules an immediate job or a job set for a later start time to remotely call the LUW. In the job execution, the relevant data is read from the tRFC tables, and the corresponding tRFCs are transmitted. If the remote LUW is executed successfully, the accompanying entries are deleted from the tRFC tables. If an error occurs, an automatic repeat mechanism, or rollback mechanism is activated (see next slide).
    If the update is triggered locally because of the COMMIT WORK statement, the tRFCs are only executed when the local update is successfully completed.
    WHEN ERROR COMES:
    If a connection cannot be made to the partner, this is logged in the tRFC status table ARFCSSTATE (which you can see by using Transaction SM58), and the job is rescheduled. You can set in the destination the number of times the system repeats the effort to connect, and the time intervals, by using the tRFC options. The default is a maximum 30 times with a 15 minute interval.
    If, after a tRFC-LUW is successfully executed in the partner system in one of the function modules, the program terminates with an A/X-message (MESSAGE A/X...) or triggers an exception (RAISE...),
    - all the changes made in the current LUW are automatically rolled back in the remote system, and
    - the remote program termination is logged in the tRFC status table ARFCSSTATE (viewable using SM58) in the source system.
    The entries relevant to the LUW remain in the tRFC tables and the execution job is not rescheduled. In this case, you can find the remote error using Transaction SM58, and you have to correct the problem in the remote system. Afterward you must trigger the remote execution again also in Transaction SM58.
    If you want to cancel and roll back this remote execution from a remote function module of a tRFC-LUW, but you also want to reschedule the job in the source system (for example, because a master record that is to be processed is locked and the LUW must be executed again), call the function module RESTART_OF_BACKGROUNDTASK in the remote function module instead of MESSAGE A... or RAISE...
    LUW BUILDING:
    If tRFCs are transmitted with different destinations before the COMMIT WORK, they are grouped into different LUWs according to their destination.
    A tRFC call with the addition AS SEPARATE UNIT is always processed as a separate LUW independently of the other tRFCs.
    Each tRFC-LUW is assigned a unique transaction ID (viewable with Transaction SM58).
    The function module ID_OF_BACKGROUNDTASK (which is called before the COMMIT WORK) returns this ID.
    You can determine the LUW execution status using the function module STATUS_OF_BACKGROUNDTASK under the transaction ID (which is called after the COMMIT WORK).
    If you also called the update function modules locally before the COMMIT WORK, tRFC calls are only processed when the local update function modules have been processed successfully.
    You can also call transactional C functions. However, you must use the rollback mechanism in the external server program .

  • 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

Maybe you are looking for

  • Save portion of a waveform chart

    First of all I acquire 2 voltage signals and save them in a file. The next thing I have to do is to read that file and show a portion of the waveform in a picture inside the page of a tab control, so each page of the tab control has a picture of a di

  • Movie keeps stopping after 45 clicks

    Hi, My flash movie keeps stopping after I've clicked 45 times and I've no idea why. There are lots of buttons on the page and when you click them they count how many times the buttons has been clicked and display this in a dynamic text box underneath

  • Tcode for checking the Maintenance Plan

    Hello, I want the transaction code for checking the list of maintenance plan for a particular plant. I went thru tcode IP03, IP16 but could not find the option of plant there.. Kindly guide.. Regards, Naren

  • How to edit the defaul profiles in profile manager?

    Hello: I'm setting up Profile Manager for the first time, and I'd like to change some of the auto-generated content from the EVERYONE group. Specifically, I would like to chnage the ports in the Mail.app container so that IMAP mail accesses port 993

  • Sales Returns - BOM

    HI SAP Gurus, Can you please help me on what should be the exact Item Category Configuration while creating a Return Sales Order,w.ref. to Billing doc which contains BOM (ERLA). Regards, Sree..