Cookies Preferences
AS2

AS2 Retry Settings for Failed & Incomplete Messages

Learn how to customize AS2 retry settings in MFT Gateway to handle failed and incomplete messages, ensuring secure and reliable EDI communication.

Dinuka Ekanayake

Dinuka Ekanayake

Published: 03 Jul 2025

Blog image

In AS2 (Applicability Statement 2) communication, particularly in B2B communications involving EDI (Electronic Data Interchange) transactions, reliable and guaranteed on-time delivery is a key requirement. However, in AS2 communications over networks, issues like server unavailability, transmission timeouts, or network failures may occur and those factors result in Incomplete or Failed AS2 communications.

To ensure reliable delivery and prevent data loss, handling incomplete and failed message transmission scenarios in an AS2 gateway is a very important point. Therefore, systems must implement a strong AS2 message retry mechanism to make sure messages that initially fail or time out are not lost but retried for successful delivery. Products like MFT Gateway manage these incomplete and failed communications to ensure secure, accurate, and guaranteed delivery without any data loss. This blog explores why AS2 message retry logic matters, how it operates in MFT Gateway, and how organizations can customize retry settings for improved control and reliability.

Common Causes of Message Failures in AS2 Communication

In any system, message delivery can fail due to various technical reasons. It is better to understand why Failed or Incomplete Message failures occur, and understanding these kinds of scenarios will help in designing a good Message Retry mechanism. Below are some common scenarios that can happen across any system.

  1. AS2 Timeout Configuration

    One of the most frequent reasons for delivery failure is transmission timeout failure. When a system is configured with an AS2 timeout setting, it waits for a specific duration after sending an AS2 message to receive the network-level (HTTP) response. If the response is not received from the receiving side within this period, the transmission is treated as a failure.

  2. Partner System Downtime

    If the recipient’s AS2 server is temporarily unavailable due to maintenance or a system crash, it will result in a failed AS2 communication. In such cases, the sending system is unable to establish a connection, leading to a transmission failure.

  3. SSL Errors

    Also, in two-way SSL communications, if client or server authentication fails, SSL handshake failures can occur, causing Failed AS2 communication. These handshake errors prevent the establishment of a secure connection, stopping the message exchange process.

Incomplete vs. Failed Messages

  • Incomplete Messages:

    These are messages that were sent but did not get the network-level (HTTP) response for the transmission. They need careful handling to prevent duplicate deliveries or incorrect success reports.

  • Failed Messages:

    During AS2 transmission, if an error is encountered immediately, such as a bad URL, SSL error, or permanent rejection by the receiver, these reasons cause Failed Messages, and the system recognizes that the message could not be delivered.

Both of the above-mentioned scenarios need to be handled within a retry logic to ensure reliable communication and to prevent issues such as resending duplicates or overloading the partner’s system.

Customizing Retry Behavior in MFT Gateway

In systems like MFT Gateway, for incomplete messages, such as when a trading partner accepts the message but fails to provide an acknowledgment within the specified transmission timeout or for failed messages like partner system downtimes, a message retry option is available with a specific retry count. Users can enable custom retries for incomplete messages with up to three different retry counts, while MFT Gateway automatically retries failed messages in scenarios like those mentioned above by default.

However, for incomplete messages, retrying may result in sending the same message again, causing duplicate messages to be stored on the partner’s end.

In MFT Gateway, there are three maximum retry count options including 3 retries, 5 retries, or 10 retries for incomplete or failed messages. An MFT Gateway user can customize the maximum auto-retry count for both failed and incomplete messages by selecting one of these options. If no selection is made, the default of 10 retries will be applied.

Customizing Retry Behavior in MFT Gateway

The retry intervals in MFTG are based on an exponential backoff strategy, starting from 30 seconds. For example, the 1st retry occurs after 30 seconds, the 2nd retry happens 1 minute after the 1st retry, the 3rd retry occurs 2 minutes after the 2nd retry, and so on. This logic is explained further in the grid below.

Retry Attempt Retry Interval
1 0.5 min
2 1 min
5 8 min
8 64 min
10 256 min

MFT Gateway

Conclusion

AS2 message delivery is important for secure and timely B2B communication. Handling failed or incomplete messages is key to keeping systems reliable and efficient. Issues like timeouts, partner system downtime or other failures can interrupt the message flow. Using a reliable retry mechanism helps automatically manage these problems without needing manual action. By understanding the difference between failed and incomplete messages, and setting the right retry counts and time gaps, organizations can avoid data loss and make sure messages are delivered. This helps maintain smooth, secure, and accurate EDI communication, even when temporary issues occur.

Dinuka Ekanayake

Dinuka Ekanayake

Dinuka is a Junior Quality Assurance Engineer at Aayu Technologies, dedicated to ensuring software excellence. With a passion for precision, he focuses on delivering reliable and high-quality solutions. Outside of work, Dinuka enjoys watching TV series, exploring new destinations, and spending quality time with friends.
Talk to an EDI Expert
Stay Compliant. Stay Connected. Powered by AS2.

Join hundreds of organizations already taking full control of their B2B AS2 communications with our trusted solutions. Contact us today to tailor a solution that fits your specific AS2 EDI needs.

Request a demo and take a live look at all the features of our AS2 EDI solutions.
Get answers to your questions and explore customizations that we can offer tailored specifically for you.
Get to know the dedicated deployment option available for your specific use cases.
Loading...
Please wait...

We're processing your request

Related Articles

View All Blogs
MFT gateway
Dedicated AS2 Server - B2B Trading via AS2
Aayu logomark
Driving Innovation, Simplifying Connections.
EDI via AS2
30-day Free Trial
Secure and Compliant