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!

[Ulrich_Schmidt]

In addition to what HAL9000 already said:

The default configuration for tRFC in the SAP system is to resend rolled-back units, only if they failed due to a network error (COMMUNICATION_FAILURE). In the case of a SYSTEM_FAILURE, this is not done, because the assumption is, that an administrator first has to check this SYSTEM_FAILURE and eliminate the root cause for it, before it makes sense to repeat the same transaction.

And if you throw a RuntimeException from JCo's handleRequest() method, this will result in a SYSTEM_FAILURE being reported back to the ABAP system. (You should see the error message from the RuntimeException in SM58).

However, there are several ways to change the tRFC behavior of the backend and make it try to resend rolled back transactions periodically. The easiest way in the case where the tRFC units are IDocs, is to create a variant for report RSEOUT00 with the desired inputs and then schedule this variant as a periodic background job (transaction SM36). (Don't run it too often. Once per hour is probably good enough for most scenarios. And make sure the errors that cause an IDoc to get rolled back, are really only temporary, otherwise you will put a lot of unnecessary strain on the system by automatedly producing thousands of errors/rollbacks...)

A retransmission can always be triggered manually from transaction SM58, which is quite convenient for testing.

[saprookieat]

Thank you Ulrich_Schmidt for the additional explanations!

[saprookieat]

Is it possible to throw a JCoRuntimeException with type COMMUNICATION_FAILURE in such cases and trigger a another send request from the Java SAP JCo Library or are all Exceptions in the handleRequest() or commit() methods automatically of the type SYSTEM_FAILURE?

[Ulrich_Schmidt]

COMMUNICATION_FAILURE is used by the backend for indicating a "broken" network connection to the partner (JCo program in this case). You cannot "trigger" a COMMUNICATION_FAILURE from the partner, because for sending an error message over to the other side, the connection between the two sides still needs to be alive... 🙂

So "sending a COMMUNICATION_FAILURE" would be a "contradiction in itself"...