SAP JCO v3 with IDoc - What happens if Destination.confirmTID() method fails?

[Former Member]

All,

I am developing a component that sends an IDoc to SAP via the JCO v3. Everything works successfully and now I am performing some reliability testing. My main question is around the behavior of the confirmTID() method. In my case, an IDoc XML message leaves my external system from a transactional JMS queue and executes the following client code:

// Get Destination from our existing JCOManager class for connectivity
JCoDestination destination = jcoManager.getDestination();

// Parse the IDoc from XML string
String iDocXML = exchange.getIn().getBody().toString();
IDocRepository iDocRepository = JCoIDoc.getIDocRepository(destination);
IDocFactory iDocFactory = JCoIDoc.getIDocFactory();
IDocXMLProcessor processor = iDocFactory.getIDocXMLProcessor();
IDocDocumentList iDocList = processor.parse(iDocRepository, iDocXML);

// Send the IDoc
String tid = destination.createTID();
JCoIDoc.send(iDocList, IDocFactory.IDOC_VERSION_DEFAULT, destination, tid);
destination.confirmTID(tid);

What happens at line 12 above if the network connection breaks? Right now, what I am seeing is that the IDoc successfully gets sent via the send() method at line 11 and then a JCoException is thrown by the confirmTID()  method at line 12.

My problem is that this message is all originating from a transactional JMS queue. I want to rollback the local client transaction and retry if an exception occurs during send(). But if the message is successfully sent via send(), I may not want to retry when the confirmTID fails because I do not want duplicate messages sent to SAP. From my observation thus far, it appears that would happen because I can see the IDoc in SAP inbound (WE02) even though the confirmTID() method did not complete.

Can someone please clarify what the pattern should be? Are you required to invoke confirmTID to submit an IDoc? It appears that you need a live connection to do so. What do you do upon connection failure here?

Thanks,

Paul Manning

[MarkusTolksdorf]

Hi Paul,

confirmTID() is telling the server system that the client knows that the tRFC call (or more specific in your case the IDoc) has been executed successfully and that the client will not send the same transaction again. Therefore, the server knows that it can safely remove the TID (transaction ID) from its transaction management without risking duplicate execution of transactions. This is certainly only true, if the client is behaving according to the protocol and is not re-executing the transaction even though everything was executed successfully. If confirmTID() is failing, this does not hurt so much. Only transaction management tables will increase over time, but typically, there are cleanup jobs running that assume that a missing confirm is ok after e.g. 24 hours.

So, in your case you can assume everything to be ok as soon as JCoIDoc.send() has been executed without an exception and remove the message afterwards from the JMS queue. Only in case JCoIDoc.send() is throwing an exception, you need to re-execute the send method for the same message and leave the message inthe JMS queue. After you have removed the message from the queue, you can execute confirmTID(). If it fails for some reason, you can repeat it later as well, but you don't need to try forever. The confirmTID() is of less importance, however, it can be considered nice by a client to invoke it, as the server can cleanup its TID management.

Best regards,

Markus

[Former Member]

Thank you for the explanation Markus. It definitely supports my observations thus far.

-Paul Manning