Forward Confirm Event Flag
Routing notifications support the forward Confirm event feature as described at
Forward Confirm Event Flag.
A call sequence in this case could be as follows:
1. The client creates a 24 alphanumeric GUID (or calls pub.sap.client:createTID to obtain one from the SAP ECC (or R/3) system).
2. The client sends the document to one of the InboundProcesses (for example an IDoc-XML to the pub.sap.transport.ALE:InboundProcess) and passes the TID along in the header field "X-TID: <tid>". The routing notification which processes this message should have the Forward ConfirmTID Eventflag set to "true".
3. If and only if the client receives a return code 200 from Adapter for SAP in step, it calls the same InboundProcess again with $action set to 4 (Confirm) like this:
This achieves two things: The state in Adapter for SAP's transaction store is set to Confirmed, and the entry in the receiving SAP system's tRFC check table (ARFCRSTATE) is cleaned up. This may be important for tRFC performance, if the SAP system receives large numbers of documents.
4. If the client receives an error return code in step 2 or no response at all, it may later resubmit the same document (using the same TID) without needing to fear duplicate processing. Then, after one of the subsequent tries has finally succeeded, the TID can be confirmed as described in step 3.
Note:
If the document is sent another time after the Confirm event has already been executed, this will lead to a duplicate document. The Confirm event should only be called if the client knows that the document has been processed without error and will therefore never resubmit this document again.