TRFC implementation in XI

Dear All,
Is there any documentation/blogs available on how tRFC is implemented in XI ?
Thanks and Regards,
V Vikram

Hi,
you can have a look at <a href="http://help.sap.com/saphelp_nw70/helpdata/en/0d/5ab43b274a960de10000000a114084/frameset.htm">RFC Adapter</a>

Features
The RFC adapter maps the following RFC calls to XML messages and the other way around:
● Synchronous RFC calls (sRFCs) in messages with Structure linkquality of service Best Effort (BE)
● Transactional RFC calls (tRFCs) in messages with quality of service Exactly Once (EO)
● The receiver RFC adapter can also process messages with quality of service Exactly Once In Order (EOIO). They are mapped to transactional RFC calls (tRFC).

Kind regards,
Manuel

Similar Messages

Calling RFC FM in update or background task

hi experts,
I have a RFC FM in system B and i want to call it from system A. if the system B is down when the call happens then the call is lost. basically i want the call happen when the system B is up. somewhere i have read that when u call the RFC FM in update task/ background task , SAP will try to make the call to system B at periodic intervals of time till the system B is up. is that so? what is the difference between calling the RFC in update task and background task?
thanks

Hi,
the transactional RFC (tRFC) implements true asynchronous communication.
Remote system need not be available at the time of the RFC Client tRFC execution.
If the call is sent while remote system is unavailable, the call remains in the local holding queue and the calling program can continue to run without waiting the response of the execution.
If the RFC server is not activated until a certain period, the call is scheduled as a background job
For the transactional call to a remote function module we use the statement:
CALL FUNCTION <func> IN BACKGROUND TASK <task> (DESTINATION dest) u2026
The update task that you mentioned is something different than the RFC technique and in the case of the function module, the function must have the 'Update Module' parameters marked.
For more info about this topic please check the link:
[http://help.sap.com/saphelp_nw04/Helpdata/EN/41/7af4daa79e11d1950f0000e82de14a/frameset.htm]
[http://help.sap.com/saphelp_nw04/Helpdata/EN/41/7af4daa79e11d1950f0000e82de14a/frameset.htm]
Kind regards.
Andrea

Implementation or Create of TRFC

Hello Experts,
I need your help regarding TRFC function module.
i want to post data from ECC system to CRM system i have done this thing using rfc function module to update customer licensing when user update BP licensing in ecc that time my rfc fucntion called and update BP information in CRM system . but due to network traffic some time information is not update.thats why i want to implement TRFC i have read some information about this so that i can fix this problem.
Please provide me steps to create or implement TRFC i am very new to SAP.
Thanks in advanced.

Read the F1 documentation and/or SAP on-line documentation on IN BACKGROUND TASK(tRFC) & IN BACKGROUND UNIT(bgRFC). Infact bgRFC is a polished version of tRFC available as of Release 7.0.
If you face any specific issues get back to the forums!

Problem with Scenario tRFC - XI - File

Hello,
Can you tell me if it is possible to implement the scenario
tRFC -> XI -> File Adapter
without using a sync-async bridge.
I am having a hard time implementing this scenario.
My problem is that I am not able to see the messages in transaction SXMB_MONI in XI.
Nevertheless, I am able to see the messages on transaction SM58 in the sending system with the following error message
com.sap.aii.af.rfc.afcommunication.RfcAFWException: alternativeServiceIde
I know that this message is truncated but I don't know the missing part.
What I have done is:
Developed a simple report that calls a RFC with the addition in background task (so it is tRFC).
Created a RFC Destination of type T (TCP/IP)
registration
same program id that I have configured in my RFC Sender Adapter (case-sensitive)
also with the aplication server's gateway and gateway service.
On the XI Side I have created the "usual" objects:
For the receiver side (file adapater) I have created
Data Types,
Message Types,
Message Interfaces
+
Message Mapping
Interface Mapping
On the sender side I have used the imported RFC structure.
Can anyone please help.
Thanks in advance

Hello again gentlemen,
Sorry for the late reply but I was unppluged from my computer for the weekend.
First thanks for your answers.
Just to make it clear:
What I am trying to configure is a async scenario, OK?
So I think Udo got my problem rigth. That's why I am using the addition 'IN BACKGROUND TASK' to call my RFC FM.
I tested the RFC DESTINATION and it is working fine.
My doubt was if I could configure a async scenario for
RFC->XI->File adapter...
You have answered my question... I know now that it is possible to configure the scenario I am configuring...
So now what I have to do is figure out why it is not working but that is probably due to a malfunctioning configuration.
I am closing this message and if I had other problems I will post them later...
Michal,
Nice blogs, keep going
Best regards and thanks
Vasco

Difference between TRFC and QRFC

Dear all,
i understand that TRFC functions as EO and QRFC functions as EOIO.
but can anyone of u pls make me understand there significance with a practical example :
1. in terms of XI
2. without XI when we say that one R3 is connected to other with say TRFC or QRFC
pl help

Hi! Tarang,
I just adding few points in this forum...Actually your question and some of the answers given are different .Some of them are deviating the topic.
According to my knowledge and as per SAP documentations also I am adding these points. Correct me if I am wrong.
At first QRFC , TRFC are different from the BE, EO and EOIO because trfc are message protocols and BE , EO and EOIO are nothing but Quality of Services (QOS).
You can check this in the below URL::
http://help.sap.com/saphelp_nw70/helpdata/EN/0d/5ab43b274a960de10000000a114084/frameset.htm
QOS is one of the property of TRFC's.
1) See Got o SMQ1 an SMQ2 what you will found:: ?
QRFC Monitor Outbound Queue and QRFC Monitor Inbound Queue. both Queues QRFC s common.ok its a simple thing.
2) Also lets take IDOC Adapter for IDOC whether it may be File to IDOC or IDOC to File Scenario where you will monitor the IDOC in SM58 also right ? why because this TRFC's are mainly for communicating with one SAP system to another SAP System. IDOC is mainly sending data via TRFC ports. That is why you ill monitor the IDOC if data doesn't reached means in Transaction COde:: SM58.
3) QRFC Outbound and QRFC Inbound is mainly for communicating with SAP System and Non SAP Systems. Okay you can get this information in the below further explination and link.
Note::qRFC communication is an extended form of tRFC communication. It adds a serialization concept to the transactional concept of tRFC.
http://help.sap.com/saphelp_nw70/helpdata/EN/3b/befa40badbf46fe10000000a1550b0/frameset.htm
Some applications use qRFC with outbound queue to improve system performance and not for serialization. If this is the case, you can switch automatically from the qRFC LUW with outbound queue to the tRFC LUW to avoid a hanging queue if a SYSTEM_FAILURE occurs
Note:: To cancel a background job if tRFC errors occur use program RSARFCEX to restart tRFC.
First What is the purpose of RFC:: ?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.
There are 3 types of communications::
Communication within an SAP system or with a remote system can take place using Remote Function Call (RFC). This enables the following scenarios:
·      a) Communication between two independent SAP systems
       b) Communication between a calling SAP system and an external receiving system
       c) Communication between a calling external SAP system and an SAP system as the receiving
            system
Features of the Three Communication TypesTo 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:
... 1)      tRFC
Suitable only for independent function module calls; the sequence of the calls is not preserved
·   2)   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.
·   3)     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.
http://help.sap.com/saphelp_nw70/helpdata/EN/3b/befa40badbf46fe10000000a1550b0/frameset.htm
http://help.sap.com/saphelp_nw70/helpdata/EN/e7/555e3c0f51a830e10000000a114084/content.htm
XI point of View...
Basically Once the TRFC or QRFC is funtion is over XI will place the Message into the Adapter engine queues based on the Comminication channel configuration.
Suppose if it is and EO then XI ill place the message in any Queue based on the free and priority and if configuration is done as per EOIO then XI ill place all the messages in the Same queue name so that it ill processes in order one after another and if the above message fails and remaining all other messages will be in the queue and doesnt process untill the failed mesages gets removed
But in case of EO it may be places in any queue and if one message fails then another message of same interface may processed sucessfully based on another queue order.
I hope it wil be helpful to you...
Regards::
Amar Srinivas Eli

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

Using tRFC or qRFC with JCo

Hello,
how can I use JCO to perform tRFC to an R/3 system from a java application running on WAS 640?
I understand that according to the docs JCo should be able to do tRFC and qRFC. Are there sample code
fragments that show how to implement tRFC, e.g. the
transaction-id handling? Has anybody experience using
JCo for tRFC or qRFC?
As far as I know it's the only secure way to call BAPIs
that are modifying master or transactional data in SAP.
Thanks for your help,
Kind regards
Christof Johner
Thanks
Bruno

Hi Christof,
there is another thread in this forum concerning JCo and transactions: Maybe you can find something there.
There is a method createTID in JCO.Client and I have it working. I get a tid that seems to be valid. What I do is something like this:
String tid = JCO.Client::createTID()
1. JCO.Client::execute(JCO.Function, tid)
n. JCO.Client::execute(JCO.Function, tid)
call BAPI_TRANSACTION_COMMIT or BAPI_TRANSACTION_ROLLBACK using JCO.Client::execute(JCO.Function, tid).
Unhappily, the whole thing does not become transactional this way: rollback does not work and the sucks gets committed after every single RFC call.
According to footnote 6 in http://www.sapinsideronline.com/searchspi/search.htm?page=article&key=32644&query_text=JCo using JCo.Client::createTID must be the way to go, though.
This Mr.Schüsseler from arasoft.de seems to know how. As I have the same problem I'm going to send him a mail to ask him.
Let me know in case you figure anything out ([email protected]). In case I figure anything out I will post it here.
Cheers, Oliver

Doubt in XI implementation

Hi Friends
I am starting a scenario in which AS-IS is, there is a R/3 system on which pay roll system is implemented.In R/3 there are many reports execute in timely manner and create a flat file and sent it to a another R/3 system. These reports are outbound process which flows into another R/3 system on daily basis.
Now in TO-BE we have to involve XI in between these two systems. Then what will be possible solutions for this implementation apart from writing new RFC. Because they dont want to do anything in R/3 and which solution will be the best in this case
Or without writing RFC we cant do this?
Its urgent.
Plzz repond with your valuable suggestions.
Thanks in advance.
Regards
Sami

Hi sami,
You should definetly go for PROXY. why i am telling you.
Before WAS 6.2 (i.e. WAS<6.2), RFC or IDOC were used to communicate with other SAP systems.But from WAS>=6.2 generally proxies are used to communicate.
There are many advantages of proxy over RFC and IDOC.
XI 3.0 provides a variety of ways to access data from different sources. There are adapters to connect files,
databases, messaging systems, Web Services. With R/3 systems (3.1h and higher), IDoc and RFC can be
used.
The standard communication channel for SAP systems is the ABAP Proxy which is available for Web AS
6.20 and higher.
- 2 -
The Proxy communication supports the full Quality of Service (Exactly Once In Order) between XI and
The RFC-Adapter does not support In Order but only Exactly Once (so-called tRFC)
The SOAP-Adapter supports In Order, i.e. the order of the messages of the sender is kept during the processing.
Hence, SAP recommends to use the ABAP Proxy communication.
u can see the links below...
File to ABAP Proxy
/people/prateek.shah/blog/2005/06/14/file-to-r3-via-abap-proxy
ABAP Proxy to file
/people/ravikumar.allampallam/blog/2005/03/14/abap-proxies-in-xiclient-proxy
Regards
biplab
****Reward points if it helps you!!

Workflow implementation(help)

hi all,
i am new to workflows but have learned a bit on the same from help.sap,sdn etc....
now we r implementing workflows for our client and he needs some std. workflows to start with
i have done performed auto workflow customizing(SWU3)
but now when i am testing std. worfklows in dev. server i am getting diffrent
kinds of errors like say
one of the task say "deletebillingblock" says error as "The calling of the object method for the work item ended with a return value for which no handling is modeled in the workflow." in the workflow log
other says "The workflow runtime system has called an application method in a tRFC or background context. A message was processed in this application method. This causes the execution of the workitem to be cancelled in this context."
i dont know y this is happening
is there any more customization needed other than swu3 (basis/abap work)
rgds
Edited by: SAP SD GUY on Jan 7, 2009 10:08 AM

Hi,
"The calling of the object method for the work item ended with a return value for which no handling is modeled in the workflow." in the workflow log
This kind of Error comes due to the following reasons:-
1> There is a problem in the Binding, in which step this Error is Coming. You have Binded the element for which there is no Target Defined. Source is there but no Target is there, so it is unable to catch the data that you want to send through Binding.
2> It also could be because of Binding Mismatch. The Container elements would not be having the same Data Type.
"The workflow runtime system has called an application method in a tRFC or background context. A message was processed in this application method. This causes the execution of the workitem to be cancelled in this context."
This Error can be because of the RFC Settings that are not propoerly configured in SWU3. All the ticks should be green in Colour. Check the same for the Server on which you are trying to trigger the WF.
For more on WF: Kindly check theses:-
https://www.sdn.sap.com/irj/scn/wiki?path=/display/abap/workflow%252bscenario
/people/sapna.modi/blog/2007/02/19/workflows-for-dummies--introductionpart-i
Let me know if you still face any issues.
Regards,
Kanika

How process tRFC in parallel using NCo 3.0

Hi,
Can NCo 3.0 process in parallel tRFC?
I´m using the class MyTidHandler that came on tutorial with the download of the connector.
Do I need to do some extra implementation in class MyTidHandler or in class MyServerHandler? If so, can anyone give me an idea how to implement? Or the parallel process should work just fine and probably is a problem on my code?
Thanks
Antonio Coelho
Edited by: antonio.coelho on May 27, 2011 3:09 PM

Hi kglad,
Once again thanx for your help. I had one more problem for
which I need a solution.
As you know,I am new to ActionScript 3.0 and flash.
Presently, I am using Adobe flash CS3 and working with it using
ActionScript 3.0.
I need code (or) procedure for developing an application in
such a way that, When I click on a button present
on the stage, I should get execute an HTML file(say,
Hello.html) which is present in the local hard-disk in the same
folder as with the flash file.
I had developed HTML file and flash file.
I am attaching the JavaScript code which is getting executed
in flash:
So, the java-script file is not getting executed .Instead, it
is displaying a browser with a blankpage. So, I need the
ActionScript to get executed.
Please, help me.... It's very urgent....
Thanks in advance.

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

Tasks/activities of a Basis consultant during SAP implementation

Hi,
Could someone share the list of tasks/activities of a Basis resource to handle during an SAP Implementation project.
Thanks in advance,
Srinivas

HI,
i think these are the simplest Basis activities in an sap implementation.
1. Preapration of the Landscape of the systems
2. Connectivities btw. different systems like SAP R/3 - BW and so on
3. Transport Administation i.e TP creation, release, importing to QA - PRD and so
4. configuration of RFCs and TRFCs if needed
5. Config. of Data Transmissions
6. Config. of IDOCs and Message Types
7. Cutover plan preparation for the Go-Live
8. System back ups and Logs Maintanance
9. Installation of all required Patches and Notes
10. system down time estimatations and planning
Rgds
Radhakrishna D S

LARFCTOP - Implementation of note 925855

Hi all,
I have big problem. Our Basis team asked me to implement that note and in the end when I have made all changes through note I have got that error:
The type "typ_last_tid_dest" is unknow.
In note 0000802892 is manual how to implement it and some program codes, but for LARFCTOP there is a part with declaration of that type but there is no type definition before.
We have system 640.
data: gt_last_tid_dest type hashed table of
typ_last_tid_dest
with unique key dest.
data: gv_last_tid_dest like line of gt_last_tid_dest.
Loggen von tRFCs (Daten für ARFCLOG)
data: begin of active_log occurs 0,
arfcdest like destlog-dest,
end of active_log.
I was looking in versions of that file but we have original one.
Please can anybody help me with that issue?
Thanks a lot for any help or advice
Petr
PS. I know that this shoud be implemented by patch but our customer doesnt want it

So if you have level 16 you can't apply this note because it's only valid for SP 17.
You have to install first SP 17 and then implement the note OR
directly install SP 18 that contains the correction of this note.
Regards,
Walter

The difference between qRFC and tRFC

I am studying RFC now,i don't understand when i should use qRFC or tRFC.can any expert tell me.
thanks

Hi kim,
welcome to sdn.
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
thanks
karthik
reward me if usefull

TRFC call

Dear All,
I was trying to implement a tRFC call using the addition IN BACKGROUND TASK; as I understand that while making a tRFC call the RFC function, together with data is saved in the database of the AS ABAP with a unique TID & I thought that we can view the TID using the transaction SM58. But to add to my surprise I could see nothing, can you please elaborate the possible reasons for this?
Well I understand the following points already.
1. A function call that contains the clause STARTING NEW TASK represents an aRFC call.
2. A function call that contains the clause IN BACKGROUND TASK represents a tRFC call.
3. If a function call only contains a DESTINATION clause but does not contain any clauses like STARTING NEW TASK or IN BACKGROUND TASK then it represents a sRFC call.
One more think if you could probably put light on is what is a bgRFC call?
Many Thanks,
Tanmoy

Hello Tanmoy,
bgRFC does everything you could do with "Classic tRFC qRFC".
But it does it faaar better.
I highly recoomend bgRFC - bgRFC Programming - Connectivity - SAP Library
To summarize, here is the list of RFC options in ABAP:
(1)    sRFC – synchronous RFC (DESTINATION….)
(2)    aRFC – asynchronous RFC (with or without response) (STARTING NEW TASK… DESTINATION…)
(3)    pRFC – asynchronous RFC over an RFC server group (with or without response) (STARTING NEW TASK… DESTINATION IN GROUP…).
(4)    tRFC/qRFC – ‘store and execute later’ RFC – execution controlled by qRFC scheduler (IN BACKGROUND TASK….)
(5)    bgRFC – ‘store and execute later’ RFC – execution controlled by bgRFC scheduler (IN BACKGROUND UNIT….)
Thank you,
Best Regards,
JothiSubaramaniam P
SAP IMS CST

TRFC implementation in XI

Similar Messages

Maybe you are looking for