webMethods

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…”

2021-07-26 20:34:42 AEST [SAP.0110.0039W] Confirm action for nonexisting Transaction TID "0AD21E0E51FA60FE8F83004E"
2021-07-26 20:35:18 AEST [SAP.0110.0002I] Listener - Create 0AD21E0E51FA60FE8F83004E
2021-07-26 20:35:18 AEST [SAP.0110.0009I] Inbound tRfc: Execute 0AD21E0E51FA60FE8F83004E, IDOC_INBOUND_ASYNCHRONOUS from ISECP
2021-07-26 20:35:19 AEST [SAP.0110.0003I] Listener - Commit 0AD21E0E51FA60FE8F83004E
2021-07-26 20:35:20 AEST [SAP.0110.0005I] Listener - Confirm 0AD21E0E51FA60FE8F83004E

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.

I’ve checked a couple of historical resources -

• 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).

KM

Thanks Kasi.

• We have a 2-node IS cluster, but both SAP adapters use a single Centralised Transaction Store (CTS) running on one of the nodes
• I ran a ‘Find Dependents’, but we don’t call pub.sub.transaction:sweep in our codebase at all

Thanks again – appreciate the insights.

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.

Question - Do you plans to perform an upgrade?

KM

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).