Transactional RFC Monitoring

[Former Member]

hi all,

Can anyone explain to me how transactional RFC works? As what i've understand it, the first transaction to get in is the first to be executed right?

Here's my scenario. I always monitors the transactional RFC,and from time to time, I observe irregularities. For example, at arround 9:00 am, bunch of transactions are displayed and the status are "status recorded". By 11:00 am, transactions are added again but this time one of the status of transactions timed 11:00am is "status executing" even if there are still remaining transactions that are recorded by 9:00 am. The way i understand it, the "first in" "first out" here was not applied.

Could anyone clear this? am i right about the "first-in first-out" scenario? if yes, how can i correct tmy problem? If not, can you explain??

Your response is highly appreciated.

cheers,

Jay

[Former Member · Accepted solution]

Hi,

<i>As what i've understand it, the first transaction to get in is the first to be executed right?</i>

Yes.

<i>bunch of transactions are displayed and the status are "status recorded". By 11:00 am, transactions are added again but this time one of the status of transactions timed 11:00am is "status executing" even if there are still remaining transactions that are recorded by 9:00 am.</i>

The particular status is displayed, only when the corresponding process is successful.

"status recorded" means that the message has been recorded in the queue, and the next process is executing.

"status executing" for example(if this does not change for a long time) means that, the process has started executing the message, but there was an error, and the process was not executed successfully and hence the next status was not updated.

Regards,

Smitha.

[former_member91687]

Hi Jay,

A calling application uses a tRFC connection to a called application. 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. <b>You cannot define the sequence in which the function modules are executed, nor the time of execution</b>. If an error occurs during the transfer, a <b>batch job</b> is scheduled.

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 integrity of TRfc is explained <a href="http://help.sap.com/saphelp_nw04/helpdata/en/22/042585488911d189490000e829fbbd/content.htm">here</a>, read this and you will understand it better.

Regards,

Chandra

[Former Member]

Smitha,

Thanks for quick and clever response, I appreciate it. But my point here is that, why is it that the transactions recorded earlier sometimes the last or late to be executed? Is there a way we can correct this problem?

Thanks again in advance,

Jay

[Former Member]

Hi Jay,

As given in the RFC adapter help

Transactional RFC calls (tRFCs) in messages with quality of service Exactly Once (EO)

The tRFC in SAP sense means:

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.

What you are talking abt is EOIO. As per the RFc adapter help, it supports:

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).

Hope this is of some help.

Regards

Vijaya

[Former Member]

Hi,

As I specified before, the status of a process is recorded in sm58 only when there is an error.

And when an error occurs, a batch program is called in the background.

Now, it all depends on when the batch programs finishes executing. A newly arrived message might be processed faster by the batch program than the one that's been in the queue for a long time.

<i>Is there a way we can correct this problem?</i>

We came across this problem usually when we were trying to use idoc acknowledgements.

Any rectification, should be done at the end systems.

In the sm58, at the most, you could try and execute the LUW again.

Regards,

Smitha.

[Former Member]

Hi Jay,

Data can be transferred between two SAP systems reliably and safely via transactional RFC (tRFC).

This RFC was renamed from asynchronous to transactional RFC, because asynchronous RFC has another meaning in SAP systems.

The remote system need not be available at the time when the RFC client program is executing a tRFC. In SAP systems, the tRFC component stores the called RFC function together with the corresponding data in the database, including a unique transaction identifier (TID). This ensures that the called function module executed exactly once in the RFC server system.

For more information on tRFC in ABAP, see <a href="http://help.sap.com/saphelp_nw04/helpdata/en/22/042537488911d189490000e829fbbd/content.htm">Transactional Remote Function Calls</a>.

Regards,

Abhy

[Former Member]

Hi Jay,

Please look at these..

http://help.sap.com/saphelp_bw31/helpdata/en/22/042b1d488911d189490000e829fbbd/content.htm

https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/help/sdn_nw04/sapdocu/netw...

Hope these help!

cheers,

Prashanth