It may not need to be async at the TN processing rule, I was testing changing the setting in our lower environment. Currently in production we’re sending the transactions synchronously.
I was thinking by changing the processing rule to async, it would send multiple documents at a time.
The 20 limit is determined by our partner that is receiving the documents. They have stated that they have 20 receiving threads to receive the documents from us. I feel that’s optimistic, and it’s probably closer to 10 or even 5 at a time, based on my testing I’ve been doing over the past week.
We are trying to increase the throughput to the partner, as sending all our documents serial is becoming too slow with the volume we are experiencing. When the entire process was designed, the volume was 5 times lower than what it is today. The partner has requested that we send certain documents concurrently (channel 1), while keeping the others serial (channel 2). I have been able to split these, but the issue is now to send those in channel 1 concurrently at a limit no more than 5 at a time.
I am looking into UM configuration as well, as it looks like UM can only process so many documents at a time, and it seems like when I flood UM with 200 concurrent and 300 serial, it processes the 300 serial faster for some reason. I am thinking that there might be a setting that we need to increase to handle this, but I haven’t found where it is yet.