Don’t Ignore the Automated Resending Feature

In my last entry discussing the restriction of outbound communications, I briefly mentioned one of the benefits of using an automatic retry option for your AS2 transmissions. Automated resending, or what are sometimes called AS2 reliability features, can be a simplifying and powerful tool in a variety of situations beyond what I’ve already discussed, however. In this entry, I’m going to talk about some of those cases and the advantages they offer.

Most AS2 applications offer some sort of automatic retry facility in case the initial attempt to send an outbound document fails. Despite this, I’ve noticed that many users ignore this feature. They might wonder what the point in retrying is, thinking that a failure in an HTTP transmission usually indicates something that is not going to resolve itself, such as pointing to the wrong address or hitting a blocked port. While this is true in many cases, there are just as many times when the problem will clear itself up, such as running up against the maximum number of port connections, hiccups in the “cloud” between networks, or scheduled server downtime. Utilizing this automatic resend feature minimizes the hassle of having to manually resend documents and it is an easy way of distinguishing persistent failures that probably require some intervention with more intermittent problems.

That’s all well and good for problems with the message itself, but if you’re using AS2 you’re probably sending and looking for MDNs as well. What happens if the MDN fails to send? There’s nothing to be done in the case of synchronous MDNs since that initial connection is blown, but why not resend asynchronous MDNs? This is more courteous to your partner since they don’t have to resend the whole document, which may be quite large, and also saves you the time and trouble of handling a duplicate document.

For both of the above cases, you’ll likely have to decide what the appropriate interval is between the initial failure and the retry or resend attempt. This is a judgment call, but in general, separating them by a few minutes is a good idea. If you attempt the retries and resends too quickly, you may not be giving the problem enough time to resolve; give it too much time, and you might be delaying the receipt of time sensitive information.

But let’s look at this same scenario from the perspective of the original sender: what if you never received that asynchronous MDN? One shortcoming of AS2 is that there’s no way to confirm your trading partner has received and processed an MDN. Another is that there’s no built-in way for trading partners to tell each other how long they should expect to wait for the asynchronous MDN. Some AS2 applications enable you to get around this with a feature that automatically resends the original message when an asynchronous MDN wasn’t received within a given period of time. The advantage to this feature goes above and beyond retrying failed HTTP connections, providing an extra level of reliability that works even in a non-obvious error condition. When deciding on a time interval to resend here, talk it over with your trading partner. They should be able to tell you the usual delay between message receipt and the dispatch of an asynchronous MDN. It may be on the order of several minutes or, in rare cases, even an hour or more.

If you’re worried about futilely attempting retries or resends forever, then stop worrying. Implementation of any of these reliability features usually includes a limit to how often they are attempted, often including a warning notification of some sort to alert the user. So if your AS2 software features well implemented reliability options, there’s no reason not to use them. By having to account for fewer lost and duplicate messages, the savings in time and stress can be considerable.

Leave a Reply

Your email address will not be published. Required fields are marked *