Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

RFC requests from ABAP to Java not processed

Former Member
0 Kudos

Hi,

I am facing an issue in my Java program where some of the Inbound RFC requests are not being processed. Can someone please help me in understanding the sequence of method execution when a RFC is received as Inbound RFC connection at Java program side?

Following methods are implemented for JCoServerTIDHandler();

checkTID(), commit(), rollback(), confirmTID().

Specifically, I wanted to know about confirmTID() method call as I could see from the logs that this particular method is called when the RFC request is not processed. It never reaches to JCoServerFunctionHandler() when confirmTID() is called.

I got this at one of threads about ConfirmTID() but didnt get the whole idea.

"ConfirmTID() => At this point, the application is informed that execution has been ended by the call with the specified TID. Under certain circumstances, this call might be received in a different Listener or, if problems arise, may not be received in the ABAP backend system at all."

Does it mean handleRequest() was called?

Any help/guide is much appreciated as I am facing this issue sporadically not always.

Please note that we are using aRFC connection to call the remote function to Java from ABAP.

Thanks,

Wasim

1 ACCEPTED SOLUTION

Ulrich_Schmidt
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi Wasim,


Wasim Ansari wrote:

It never reaches to JCoServerFunctionHandler() when confirmTID() is called.

This is the way, the tRFC protocol is designed. The R/3 system calls confirmTID(), after the actual function call has been processed successfully (and the ok code which indicates this has arrived back at the R/3 system successfully!). In fact, the Confirm step may happen hours/days later, if network problems occur between the successful execution of the FM and the Confirm step.

It is your responsibility to keep the transaction ID, that you get in the checkTID() step, in a permanent storage, like a database or a file, so you can later correlate the handleRequest() and any Rollback, Commit or Confirm step that may happen on this TID. For a good explanation of how the tRFC protocol works (and how to guarantee "once and only once" execution of a transaction!) see https://scn.sap.com/docs/DOC-52888. This describes it for C/C++ programs using the NetWeaver RFC library, but the same logic also applies to Java programs using JCo.

Best Regards, Ulrich

1 REPLY 1

Ulrich_Schmidt
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi Wasim,


Wasim Ansari wrote:

It never reaches to JCoServerFunctionHandler() when confirmTID() is called.

This is the way, the tRFC protocol is designed. The R/3 system calls confirmTID(), after the actual function call has been processed successfully (and the ok code which indicates this has arrived back at the R/3 system successfully!). In fact, the Confirm step may happen hours/days later, if network problems occur between the successful execution of the FM and the Confirm step.

It is your responsibility to keep the transaction ID, that you get in the checkTID() step, in a permanent storage, like a database or a file, so you can later correlate the handleRequest() and any Rollback, Commit or Confirm step that may happen on this TID. For a good explanation of how the tRFC protocol works (and how to guarantee "once and only once" execution of a transaction!) see https://scn.sap.com/docs/DOC-52888. This describes it for C/C++ programs using the NetWeaver RFC library, but the same logic also applies to Java programs using JCo.

Best Regards, Ulrich