No, pub.sap.client:confirmTID does NOT commit the transaction! The transaction is already committed, when pub.sap.client:sendIDoc (or ALE:OutboundProcess) returns successfully. confirmTID confirms the transaction, and this is a BIG difference from committing it. (See my explanation of the tRFC protocoll in my previous post form Aug-20.)
And again: NEVER do the confirmTID inside the same Flow that sends the IDoc! It will only lead to duplicates. (It is better to just forget about confirmTID and instead schedule a clean-up job in R/3 that deletes old TIDs from ARFCRSTATE, than to use confirmTID incorrectly…!)
Most probably the hardware of the SAP system has become faster or it has more work processes now, so now it is able to really process these two orders in parallel…
Mike: when you “send another one”, do you use the same TID as the first time, or do you let ALE:OutboundProcess create a new one? If you want to prevent duplicates, you need to use the original TID, of course!
Let me repeat: if you want to guarantee transactional security (exactly-once execution), then you need to put a bit effort into it and comply with the tRFC protocoll. Here is the basic outline:
First HTTP request:
HTTP client calls createTID and stores the returned $tid together with the IDoc data in permanent memory (file or database).
Second HTTP request:
HTTP client calls the Flow that creates and sends the IDoc, submitting the payload and including the TID in an HTTP header “X-TID”. (If you use the standard IDox-XML format and include the HTTP header “Content-Type: application/x-sap.idoc”, then this Flow does not even need the documentToIDoc step.)
If this request ends in HTTP return code 200, proceed to the third step. Otherwise keep repeating the second step like once an hour, but always use the same TID! If it’s only a network error, the submission will probably be successful one of the next times. If it’s for example a configuration error on SAP side, an admin should investigate and fix it before the external program makes the next retry.
Third HTTP request:
Eventually the submission will end successfully. Now the external program deletes the payload data and the TID from permanent memory and makes the last HTTP call to confirmTID, so that the SAP system can clean up it’s status keeping as well.
If there is no external HTTP client, but the wM IS (or SAP BC) is the creator of the IDocs, it’s even a bit easier. For example using SAP BC (which keeps transaction status in WmPartners in the “Message Store”), you could set up two Scheduler jobs like this:
First job:
Creates a TID and the IDoc and passes both to ALE:InboundProcess. (ALE:InboundProcess persists the TID and IDoc in the message store and then calls the Routing Rule, which will call ALE:OutboundProcess (“ALE Transport”) ALE:OutboundProcess then sets the status to “Committed” or “Rolled back”, depending on whether the IDoc reached SAP successfully or not.) Don’t perform the confirmTID in the first job!!
Second job:
Using the public Services in the WmPartners Package (wm.PartnerMgr.xtn.admin:list & get), you loop through the message store:
o If you find a TID in status Committed, call the Service wm.PartnerMgr.gateway.runtime:confirmTID. It will follow the Routing Rule, perform the confirmTID in the correct SAP system and also update the status in the message store. (The Routing Rule needs to have the flag “Forward ConfirmTID Event” activated.)
o If you find a TID in status Confirmed, delete it (wm.PartnerMgr.xtn.admin:delete)
o If you find a TID in status Rolled back, and the last state change is more than an hour ago, resend it (use wm.PartnerMgr.xtn.admin:getMessage and pass its output into ALE:InboundProcess again.)
o TIDs in Created and Executed should be left untouched. They are not yet completely finished.
In older wM IS releases the WmPartners Package does not provide the above functionality. (This was added only in SAP BC 4.7 and 4.8) In this case: upgrade to wM 7. (Or perhaps wM 6 is sufficient?!? Not sure.) In newer wM releases webMethods replaced the WmPartners Package with something better, and that should then provide similar functionality as the one I outlined above for the SAP BC.
Lanzelot
#Adapters-and-E-Standards#Integration-Server-and-ESB#webMethods