Currently I am in an environment where there will be 10s of thousands of transactions that are aborted due to SAP being unable to consume them. Rather than add SAP connections or attempt to space out the transactions, the customer has us manually reprocessing these in MWS.

I would think that a utility, or flow process, could be written to query (Processing Status = “ABORTED” and sender = xxx) and return the list of transaction IDs that meet the criteria. From that point I’m not entirely sure how to proceed. Can the status be set to “REQUE” or something along that line?

Any help would be appreciated.

You can always get those faild bizdoc Internalid’s using query services and call the tn:reroute service (reprocessing mode) which will certainly help bulk reprocessings via programmatically…Have you tried this logic option?

HTH,
RMG

I have not tried anything yet and was inquiring if there was an accepted approach. Sounds like there is so I’ll give it a try. Thank you.

Sure and please let us know how it goes:)

HTH,
RMG

Scott,

Just wanted to make a quick comment: the reason why your transactions are going into an ABORTED state may not necessarily be due to SAP being unable to consume them. TN has limits that control how many transactions it can process asynchronously at any given time.

By default, when executing processing rules asynchronously, TN will spawn a maximum of 75% of the Integration Servers’ total thread count to process the documents concurrently. Once it reaches this maximum, it will start to queue the next requests into an in-memory queue up to a maximum default of 1000. As the threads are released, it de-queues the requests and processes them. If you happen to go over the 1000 maximum, new transactions are aborted and their processing status are set to ABORTED.

Anyway, I’m not sure if this is what’s happening in your case, but I wanted to give you a heads up just in case. If this is indeed what’s happening, you should see a message in the log that says “ThreadQueue: too many jobs waiting.” Let me know if that’s the case and we can talk about how to resolve it.

Percio

Hi Percio Castro

We had an issue today where a lot of transactions were in ABORTED processing status. On checking logs, found the below:

java.lang.Exception: ThreadQueue: too many jobs waiting

Checked MWS Logs and could see no log:

2016-12-05 02:00:06 EST (com.webMethods.caf.deleteditemsadmin.PurgeScheduleListener:INFO) - Purging thingID: /meta/default/basic/0000013143
2016-12-05 02:06:24 EST (Framework:INFO) - Closing session, but no Context is available
2016-12-05 02:16:07 EST (Framework:INFO) - Closing session, but no Context is available
2016-12-05 02:22:19 EST (Framework:INFO) - Closing session, but no Context is available
2016-12-05 09:11:22 EST (Framework:INFO) [RID:60756] - Request [1p6sosazaxfdo3zdr53l3av3y:null] http:/.intranet.local:8686/ (GET)
2016-12-05 09:21:45 EST (Framework:INFO) [RID:60757] - Request [dwrrigndp24818nd156zb0nng:null] http://:8686/ (GET)
2016-12-05 09:21:49 EST (Framework:INFO) [RID:60758] - Request [dwrrigndp24818nd156zb0nng:Guest] http://:8686/user.current.start.page (POST)
2016-12-05 09:21:49 EST (Framework:INFO) [RID:60758] - Trying to authenticate user: ASP4267
2016-12-05 09:21:49 EST (Framework:INFO) [RID:60758] - user asp4267 authenticated = true
2016-12-05 09:21:50 EST (Framework:INFO) [RID:60759] - Request [1pqn14fthgq4k1azd1ybp82clu:asp4267] http://:8686/user.current.start.page (GET)

Not sure about the purge activity that was happening

You wouldn’t see anything in MWS. MWS simply hosts the Tranding Networks UI, but all of the work actually takes place on the Integration Server. You may want to check the IS log for clues as to what may have caused this.

If you’re looking to avoid this issue, there are a couple of ways:

• Temporary fix: increase the configuration tn.thread.maxWaiting

• Permanent fix: stop using asynchronous processing rules. Asynchronous processing rules made sense back when customers had TN but not Broker. However, that’s rarely the case now. Most companies that have TN now also either have Broker or UM as their messaging bus. In that case, instead of using an asynchronous processing rule, I recommend using a synchronous processing rule that simply publishes the document. You can then process the document on the subscription side. In fact, I do this so much that I created a TN delivery service to do the publishing.

Percio

Hi,

@Percio,

Out of curiosity:

Do you mean you have made a synchronous TN delivery service that publishes the incoming message and returns a ‘success’ result to the calling partner?

Does the remaining message processing is done within TN or you just return the processed message back to TN?

Best Regards,

Gerardo,

In a nutshell yes, but what determines exactly what the partner receives is typically my gateway service. For example, if I have a gateway service that handles cXML, then if the delivery service completes successfully, i.e. the message is published successfully, then the gateway service would return a cXML 200 OK rather than a ‘success’ flag.

The remaining message processing is done in the trigger service. I typically include some bizdoc identifying information in the publishable document so that if I need to update TN from the trigger service, I can. This allows me to take full advantage of TN while also reaping the benefits of pub/sub, including more robust asynchronous processing.

Percio

Looks good.

Thank You.

Season’s Greetings,