Way of functioning of SAP Jco Library

[saprookieat]

Dear SAP community,

We have implemented a JCo Server, which uses tRFC and the JCoFunction IDOC_INBOUND_ASYNCHRONOUS. The JCoServerFunctionHandler as well as the JCoServerTIDHandler have custom implementations for saving IDocs with CRUD operations into the database.

During internal tests we noticed, that for instance, if we would throw a RuntimeException (e.g. the database connection has been lost) in the commit() method of the JCoServerTIDHandler the transaction will not be reprocessed.

The same behavior could be observed, if we just throw a RuntimeException in the handleRequest(JCoServerContext jcoServerContext, JCoFunction jcoFunction) of the JCoServerFunctionHandler implementation. 

In both cases we receive an error in the log file, but SAP does not seem to send the IDoc again or check with checkTID(JCoServerContext serverContext, String transactionID) if the IDoc has been processed already.

So my lack of understanding results in three questions:

• Is there no feedback with regards to the information in case the IDoc has been received?
• Do you need to call a specific JCoFunction to signal SAP the IDoc has not been successfully received and needs to be sent again in a later try?
• Is this in general not something I can do with the JCo Java Library and it needs to be configured on the SAP system to handle feedback sent back (e.g. through a RuntimeException) to the SAP system (I do not know, if there is a response from the SAP library in this case)

I would appreciate any valuable input with regards to this question as I am currently a bit stuck to cover all necessary edge cases to ensure data consistency.

Thank you in advance!

[HAL9000 · Accepted solution]

To your questions:
1. The sender of the tRFC request should realize that the IDoc send operation failed, i.e. the runtime exception is returned to the sender. If the sender was an ABAP system, see transaction SM58 for the asynchronous RFC error log. You should find a corresponding entry there.

2. No, this should not be necessary.

3. What you are trying to do is absolutely what JCo and the IDoc Library are designed for. If the scenario does not work, you have to investigate at the sender side first, why the failed IDoc(s) are not re-transmitted with the same TID after a failure. Of course, it is also important, how you are reacting in your TIDHandler on the received events. JCoServerTIDHandler.checkTID(...) has to return true for this TID, which failed in a previous call. Otherwise the IDoc(s) won't be sent again. If checkTID isn't called with this TID once again, this is a configuration issue (e.g. time interval for retry attempts) or a bug at the sender system side.

[saprookieat · Accepted solution]

Thank you very much HAL9000, your valuable input made things a lot more clear now!