SFTP under load, AS2 routing by ISA identity, and a batch of smaller changes

SFTP mailboxes can be quirky. Some will accept two sessions at a time, maybe three, and beyond that they start refusing you. If you keep trying to connect, something on the other end decides you are an attacker and bans your IP for an hour, which is a fun thing to discover at 4pm on a Friday.

Tediware runs on several servers, each with several worker threads, each with its own connection pool, and until recently the number of sessions we could open to one partner was a function of that infrastructure rather than of anything the partner had agreed to. Most of the time it didn’t matter. On a busy day it mattered a lot. Making it more robust and resilient is the largest thing in this update.

What happens to a 200-file burst

A customer submits 200 outbound documents to the same partner within a few seconds, which is normal behavior for a nightly batch coming out of an ERP.

The first fix was a cap: SFTP connections now carry a Max concurrent sessions setting, and Tediware will not open more sessions to that mailbox than the number you put there, across every server we run. If you leave the field blank, we assume 2, which is the conservative guess and is right for most partners. If your partner has told you they allow more, put the number they gave you.

The second enhancement is upload coalescing. When several documents are bound for the same SFTP connection, they land in a queue instead of each going out on its own, and a drain job (serialized per connection, so two of them can never overlap on the same mailbox) ships the whole backlog over one held session. Those 200 files are one connect now.

Two smaller behaviours changed alongside that:

• Refused connections back off instead of retrying. A refusal from a partner’s server no longer fall into the generic connection-error bucket which was causing retries and aggravating rate limiters.
• Bad credentials fail once. Authentication failures used to be retried like any other connection error. They do not heal in five seconds, and re-sending a rejected password is precisely the pattern that gets an account locked, so they now fail immediately and surface.

Other updates

• Duplicate a partner. Partners that differ from an existing one in a few fields no longer have to be built from scratch. Duplicating deep-copies the partner and all of its transaction set configurations into a pre-filled new-partner form, with the name and key suffixed and the control numbers defaulted to the source’s current values plus one, all editable before you save. Flows are not copied, since they are regenerated from partner config anyway, so the copy arrives flow-less and the detail page’s usual rebuild prompt takes it from there. The sandbox partner cannot be duplicated.
• Per-transaction-set directories. Some partners sort files into a folder per transaction set, which a single connection-level directory cannot express. Transaction settings now take an optional Remote Directory that overrides the connection default. Leaving it blank keeps current behavior. It applies only to dedicated SFTP connections; on a VAN-routed connection the partner is not known until the envelope is parsed, so the field is shown but disabled with the reason. The path is literal and named from your partner’s point of view, so a folder they call “Inbound” may well be the one Tediware writes to.
• Partner key in the results API. detail.partner appears in GET /platform/results, as { "key": "ACME_FOODS" }, so you can attribute a result to a trading partner without a second lookup.

Everything above is live. If any of it touches something you are working on, or if the SFTP work changed the behaviour you were seeing with a particular partner, email me at adrian@tediware.com.