Any insights or thoughts on this SAP adapter message: “Confirm action for nonexisting Transaction TID…”?
In the example below, 40 seconds before an IDoc comes into webMethods, the SAP adapter complains about the TID that will be used: "Confirm action for nonexisting Transaction TID…”
Back in 2011, I posted this issue on errors associated with ‘missing IDocs’ – IDocs outbound from SAP that didn’t seem to reach the webMethods SAP adapter. I never technically solved the issue.
A decade later, this message is much more common in logs (though it is no longer associated with missing IDocs). The difference then and now is we now use a custom ‘TID Tracking Database’ to track TID values in IDoc delivery to SAP systems (to support the requirment that IDoc delivery retries must reuse an original TID value). Later, a scheduler uses ‘pub.sap.client:confirmTID’ to deletes TIDs in the database that are more than 24 hours old. But the errors above are for IDocs inbound to webMethods (which the database does not track).
I suppose it is the SAP system that has attempted to confirm a TID for documents it later sends out … but that’s just me guessing.
Any thoughts on this? This is not a serious problem. I just thought to close the loop as the other thread is closed.
This can happen if you have more than one independent instance (each with a local transaction store), but you are using the same listener ID - this is the more likely scenario.
Or, the pub.sap.transaction:sweep service removing TIDs that aren’t complete, yet (less likely).
Sonam, it’s pub.sap.transaction:sweep - please check again. It could perhaps be a scheduler as well. The service is documented in the SAP Adapter guide (I reckon you are using 8.2 or older).
Anyhow, I suspect that one node started the transaction while the other node tried to commit it, in your case. I also see that you can safely ignore the error - just that the transactions won’t be in a committed state in the store.
SAP Adapter 7.1 is the valid version for all IS versions between 7.1 and 9.12 (resp. 10.0).
From 10.1 onwards there is a newer SAP Adapter 10.1, which can be used instead of SAP Adapter 7.1.
Did you read the chapter about Clustering in the SAP Adapter Install and Users Guide?
At the end of this chapter there is also a part covering the CTS.
Sorry Kasi – my typo. Yes, I did find pub.sap.transaction:sweep - but ‘Find Dependents’ proves we don’t call it in our codebase.
I don’t think one IS cluster node can initiate a transaction while another node commits the same transaction (I am speaking in the context of IS sending an IDoc to SAP). The logs I quoted were for an inbound IDoc (SAP → IS). With CTS configured, I think IS cluster nodes won’t mixup processing of an inbound IDoc transaction.
I don’t know of plans to upgrade (we are on extended support).
Thanks Holger. We use SAP Adapter Version 7.1.0.18.914 with IS 10.1 - how did you know? Based on the IS message codes in the log?
Is version 7.1 associated with the " Confirm action for nonexisting Transaction TID… ” problem?
Yes, I recall helping setup SAP adapter CTS clustering years ago. I think it’s functioning fine. On both nodes, if I go to Adapters > SAP Adapter > Settings, I can see two hosts listed under the Adapters in this Group section. The CTS controller node says Centralized Store=Local file system, while the CTS slave node says Centralized Store=Remote file system
looks like you do not have any Fixes applied to the SAP Adapter.
Latest Fix for SAP Adapter 7.1 I am aware of is Fix19.
What is your JCo version?
You can find these informations in the about page of the SAP Adapter UI in IS Admin UI.
Sonam, I assumed that your IS nodes were not clustered (i.e., standalone HA nodes but without clustering). Do get to latest fixes as @Holger_von_Thomsen has advised (for both SAP Adapter and IS), as this issue was not reported any time recently.
Since you are on EME, if the issue persists, do open a support ticket.
Happy to help; I researched further, please check these -
I’m not fully familiar with CTS, but it seems to have a Server IS vs Client IS setup - do you shutdown the client node(s) first before you shutdown the server?
Is the number of IS instances equal to the number of processes that are listening to SAP?
Do you use pub.sap.transaction:deleteAll, perhaps, for cleanups instead of sweep?
From the logs, it looks like the TID was eventually committed; though you’d like to understand why this “nonexisting” message pops up, you can change the logging level of SAP Adapter to “Error” and this will disappear
The product fix also stipulates minimum required versions of IDoc Class and WAR - should be documented in your fix readme file; do compare your environment against it
The latest fix is Fix 20 (link), but I don’t see this exact issue fixed in it, even though I see the same issue being reported a bunch of times; this suggests that it’s an environment/configuration issue
You should consider updating your JCo and JCoIDoc libs as they look fairly outdated.
I have just checked SAP Marketplace and found out that Support for JCo 3.0.x has ended in October 2020.
Final versions are JCo 3.0.21 (released December 2020) and JCoIDoc 3.0.14 (released Ocober 2019) still available for download.
I am not sure if SAP Adapter 7.1 with proper Fixes applied is compatible with JCo 3.1.x, but SAP Adapter 10.1 should be able to use JCo 3.1.
Current versions for JCo 3.1.x are JCo 3.1.4 (released April 2021) and JCoIDoc 3.1.1 (released September 2020).
As Kasi stated the required versions of the Libs should be indicated in the Adapter Requirements Guide and the readmes for the SAP Adapter Fixes.
Remember to shutdown and restart IntegrationServer when updating the SAP libraries to get the native part loaded properly.
Would also suggest, please consider upgrading the latest IS/SAP Adapter version as many things have been evolved/improvised (with jco libs) bi-directional integration aspects with latest SAPECC/S4 systems.
Thanks to Kasi, I have a likely cause: I mentioned earlier we ‘track’ TIDs during IDoc delivery and ‘confirm’ TIDs on SAP after 24 hours by executing pub.sap.client:confirmTID via scheduled service. In addition, we call pub.sap.transaction:deleteAll - this deletes the entire local transaction store every hour on the hour to keep it manageable. The two actions may be interacting with each other (thanks Kasi for the thought).
I used to think that confirmTID confirms (deletes) the TID on the remote SAP system only. Does it try to confirm a TID value in the local CTS transaction store too?
Below, I’ve interleaved some outbound (IS → SAP) IDoc transfer logs with SAP adapter logs – they indicate the cleanup service tried to ‘confirm’ a TID 24 hours after transmission, but found it deleted already. I’m not sure if this was because deleteAll ran in the interim, or if some SAP-side process deleted the TID. But the ‘already deleted’ narrative accounts for the majority of the Confirm action for nonexisting Transaction TID messages in outbound IS → SAP IDoc transmission. I still don’t know what could cause inbound (SAP → IS) IDoc logs provided at the top of this post. I intend to discuss with our Basis team.
<<<Custom code sends IDoc to SAP by calling pub.sap.client:sendIDoc with TID=0AD21E0EE0AD6109DCBD102F>>>
2021-08-04 10:18:05 AEST [SAP.0110.0002I] SendIDoc - Create 0AD21E0EE0AD6109DCBD102F
2021-08-04 10:18:05 AEST [SAP.0110.0003I] SendIDoc - Commit 0AD21E0EE0AD6109DCBD102F
<<<24 hours later, cleanup scheduler confirms TID=0AD21E0EE0AD6109DCBD102F on SAP system>>>
2021-08-05 10:19:39 AEST [SAP.0110.0039W] Confirm action for nonexisting Transaction TID "0AD21E0EE0AD6109DCBD102F"
@Holger_von_Thomsen - thanks for your tips; I appreciate them. I recall discussing impending JCo 3.0.x support issues with our Basis team earlier. From memory, we’re not unsupported. Obviously, a current version is better - we have to weigh the change with testing requirements and the move to SAP Adapter 10.1.
Yes, CTS is basically another client-server arrangement setup to run within the EAI cluster.
I’m not sure what you meant by number of IS instances and SAP listener processes, but each IS node runs a SAP adapter.
Yes! We run deleteAll every hour. This deletes all entries in the webMethods SAP transaction store to keep the store down to a manageable size. Perhaps this is what caused the problem with confirmTID trying to delete a TID that deleteAll already deleted.
Thanks on the log suppression suggestion
Yes, prerequisite checks for patches are a good idea
@rmg - yes, your suggestions are correct. Good to see you after all these years.
Glad that we figured the issue out, Sonam; here’s more -
Issue - deleteAll deletes TIDs at scheduled intervals, which clears your store and the process/thread tries to look for a TID thereafter (i.e., to update the state for the TID). The problem is that deleteAll is meant to clear entries irrespective of their processing state.
Resolution - Use sweep instead, as it allows you to filter the entries that must be cleared, based on filter criteria such as sender, receiver, but more importantly, state. The service is documented here along with valid entries for state (link). This should solve your problem.
P.S - confirmTID does not delete anything; it just updates the state of the TID.
Thanks Kasi. Good idea about sweep. But a complication is we have two types of IDoc transmission going:
Some ORDERS05 IDocs to SAP
For most orders, we use pub.sap.client:sendIDoc, along with our custom ‘TID tracking’ functionality. To separate cleanup from the transmission, I don’t call confirmTID at this point. Instead, 24 hours later, a ‘cleanup’ scheduler cleans up the TID tracking database, then calls confirmTID to update transaction status from ‘Committed’ to ‘Confirmed’. This also lets the remote SAP system know it can delete the TID - see comment (*) at the end.
All other IDocs types (dozens)
No TID tracking used. After transmission, transaction should be ‘Committed’ or ‘Rolledback’. Never ‘Confirmed’.
The sweep service has a msgType input. (Edit: I checked and this input DOES accept regexs). I could run it with these inputs:
msgType=ORDER.* – regex for all order IDocs sent to SAP
msgType=^(?!.*ORDER).*$ – regex for every other IDoc type. This regex uses negative lookahead. It’s a good example of the ‘two problems’ effect.
To use sweep I’ll need to write a special sweeper service with at least two calls to sweep (one per category above). If my colleagues transition IDoc integrations to use TID tracking, we must remember to tweak this sweeper.
So at this stage, I plan to pinch my nose and carry on using deleteAll. Over several years, I haven’t observed deleteAll causing any ill effect to IDocs being processed (in ‘New’ status, say). Maybe the CTS store is transactional and deleteAll cannot interrupt an IDoc being processed. Another alternative is to reconsider the basic ‘TID Tracking’ design and call confirmTID immediately after sendIDoc (instead of waiting on the ‘cleanup’ scheduler)
Thanks again for all your help! Your insight is most welcome. Thanks also to the other guys.
(*) From what I understand,confirmTIDpromises to never use the TID anymore. This allows the remote SAP system to delete the TID entry.
Sonam, I appreciate your explanation of the interfaces and your thought-process; certainly helps people who are looking for guidance for a similar hurdle.
Yes, I’m inclined towards not fixing something that is working (while debating inside my head)
You can suppress the logging to only errors, so long, until you redesign the framework.
