Top 5 Reasons Why Your EDI Transfer is Failing

EDI transfer is a very popular medium for business document exchange; yet, setting up and maintaining an EDI transfer communication link can be fairly challenging. While SaaS EDI transfer offerings simplify the process to a great extent, there are several pitfalls that need manual intervention; especially during the initial set-up.

Note: This article only applies to EDI transfer via the AS2 protocol. If you are using different protocols, check out the guides for the respective protocol; or consider the benefits of migrating to AS2, the most popular secure EDI exchange protocol.

1. There is something wrong with your network communication link.

AS2 EDI transfer happens over the public internet, so both parties (trading partners - you and your recipient) must be able to connect to each other. As such, this should be your first checkpoint, whenever something has gone wrong.

(a) Network (IP address) whitelisting - you, your partner, or both

Usually applications use network firewall rules for controlling EDI/AS2 connectivity access, so allowing (whitelisting) you on your partner's side would often involve some communication and manual intervention.

Whitelisting comes at two levels:

• you, on your partner's side (if you are unable to connect/send to your partner)
• your partner, on your side (if your partner is unable to connect/send to you)

SaaS providers like AS2 Gateway will usually allow access from any network/IP address; and use alternative measures to validate and regulate security. However, if your partner uses a legacy system like VAN (Value Added Network) or an on-premise application, you might need to contact them and send them your EDI application's IP address for whitelisting.

Finding and whitelisting your IP address (when you cannot connect to your partner)

The process of finding your IP address can vary:

• For an on-premise EDI/AS2 installation, you will need to ensure that your organization has a public IP address; and that the EDI application is exposed over, or reachable from, that address. Once confirmed, you can find the IP address value via an online service like IPEcho. Contact your EDI/AS2 vendor or consult your network/infrastructure team for more instructions and support.

• For a cloud or SaaS installation, you will usually be able to find the IP address via its user interface or documentation; for example, the public IP of AS2 Gateway is 52.204.119.191, as mentioned in their documentation. Contact the vendor if you cannot find the IP address in this manner.

Finding (and whitelisting) your partner's IP address (when your partner cannot connect to you)

Note: This step can be omitted if you go with a SaaS EDI transfer solution like AS2 Gateway which has minimal network restrictions on inbound EDI transfers.

First, check whether the current configuration works; ask your partner to try connecting to your EDI exchange (e.g. send a test message). If it results in an error like "connection refused" or "connection timed out", your firewall is probably blocking him from connecting.

Contact your partner, obtain their EDI transfer IP address (from which he will be connecting to you), and:

• if you're using an on-premise EDI exchange, whitelist the IP on your organization network/firewall.

• if you're on a SaaS EDI transfer service, contact the service provider for instructions, settings or assistance on whitelisting the partner's IP address.

(b) You are calling the wrong endpoint on your partner's AS2 system - or the other way around.

Each EDI/AS2 exchange system has a specific endpoint (URL) for receiving incoming transmissions. For example, AS2 Gateway receives EDI/AS2 transmissions at:

• http://service.as2gateway.com:8280/service/as2-receiver and
• https://service.as2gateway.com:8043/service/as2-receiver

If your EDI application is not configured with the correct endpoint of your partner (or his with yours), the sending would fail with HTTP errors; such as:

• 301/302: Redirect,
• 400: Bad Request,
• 404: Not Found,
• 405: Method not allowed,
• 500: Internal Server Error, or
• 503: Service Unavailable.

You would need to consult your trading partner and configure his EDI transfer endpoint on your side; and send him the AS2 endpoint of your application so that he can set up your endpoint for transfers from his side.

AS2 Gateway makes this quite easy by allowing you to share your local trading station details with your partner via email, in one click. If your partner is also using AS2 Gateway or the on-premise AS2Station, he will be able to do the same.

2. Your EDI transfer recipient has not properly configured you as one of his trading partners.

In EDI transfer over AS2, each party (sender and recipient) should configure the other a trading partner. This allows both parties to trust each other and utilize various security mechanisms during EDI exchange.

If your transfer is not receiving any response (e.g. causing a "connection closed" error), or resulting in an HTTP error: e.g.,

• 400: Bad Request,
• 403: Forbidden,
• 404: Not Found, or
• 500: Internal Server Error,

it might be worth contacting your partner and verifying that he has added you as a correspondence on his EDI/AS2 system.

Similarly, if your partner is seeing similar issues on his side, you may need to ensure that you have added him as a trading partner on your EDI exchange application. The steps for defining a new trading partner are usually included in the provider's documentation.

3. You are (or your partner is) using the wrong certificates.

Certificates can help to establish secure channels for EDI/AS2 transfers over the insecure, public internet. An EDI exchange involves quite a few certificate types; it is quite possible to swap them incorrectly, or fail to import some of them, resulting in a bad, non-working configuration.

(a) Encryption certificate

This is provided by your partner, and your EDI/AS2 application uses it to encrypt and secure the content being sent out to your partner. (Similarly you need to send your own certificate to your partner, for him to be able to communicate with you.)

This certificate may be missing if your partner does not expect you to encrypt your EDI transfers; in that case you can ignore this (although it would be a security loophole).

(b) Signing certificate

This, also provided by your partner, is used to produce a digital signature; for ensuring that the EDI content has not been tampered with, during the transfer.

It is possible to use the encryption certificate itself as the signing certificate, or to disable signing entirely; in which case you can ignore this step.

(c) HTTPS or SSL certificate

This is used only when the EDI transfer happens over HTTPS; it refers to the certificate that your AS2 application should use for encrypting the overall communication (high-level, not just the EDI content) during transfer.

(d) Chain certificates

Each of the above certificates can be "signed" by a third party, in order to verify that the certificate in your possession truly belongs to your partner; otherwise a third party could send you a fake certificate, and later intercept and read all your communications intended for your partner.

Sometimes this can be a "trust chain" where the original certificate is signed by one party, who is in turn signed by another party, and so forth; until there's a root authority that is implicitly trusted by the EDI/AS2 application, hence validating all the previous trust relationships.

In such cases, your partner may have provided you with one or more "chain certificates" that would constitute this "trust chain", which you would then need to import into your EDI/AS2 exchange application.

If there are no chain certificates, it could mean either:

• your partner's certificate is signed by a root authority (that any application would generally trust), or
• your partner himself has signed it: a "self-signed" certificate

Dealing with self-signed certificates

While the latter sounds insecure, if you received the certificate file via trustworthy means, it is secure enough for use in EDI/AS2 transfers.

Your EDI/AS2 application may complain that the certificate is "self-signed" and "untrusted" (especially on Windows). In this case, you would need to add it to the list of trusted certificates; but if the application itself has a certificate store feature, it is safer to add it there, rather than at operating system level.

By nature, if you fail to configure any of these certificates (e.g. forget to import the chain certificates); or mistakenly swap them (e.g. use the HTTPS certificate in place of the encryption certificate), EDI/AS2 communications would fail.

Unless your partner has named them properly, it would be difficult to tell these certificates apart. If you know the "owner names" (distinguished names) of each certificate, you can open the files via a certificate viewer and figure out which is which. Most operating systems provide native certificate viewers (simply double-click the file).

Online solutions like AS2 Gateway provide built-in certificate stores for easy addition and management of such encryption, signing and chain certificates.

4. Missing or invalid MDN (receipt notifications)

AS2 protocol optionally enables partners to confirm the receipt of EDI/AS2 transfers via message disposition notifications (MDNs); similar to receipts in monetary transactions.

If the EDI sender has requested an MDN from the recipient, but the recipient fails to provide one, the EDI transfer is considered as a failure. In such cases, AS2 recommends the sender to retry the EDI/AS2 transfer up to a desired number of times.

If the recipient has configured his EDI/AS2 application incorrectly, this could lead to repeated re-transfers of the same EDI content, leading to undesired errors.

Additionally, AS2 allows two types of MDNs. One is synchronous or sync, where the recipient sends back the receipt immediately, as a direct response on the same EDI transfer channel. The other is asynchronous or async, where the recipient briefly acknowledges the original channel, and later sends back a proper receipt on a separate channel. The type of MDN could be explicitly configured at partner level, or requested on a per-message basis using certain AS2 headers.

However, if one of the two EDI transfer applications does not honor this MDN type convention, it could lead to errors and re-transmissions as described earlier.

5. Mismatched EDI transfer configurations

EDI transfer over AS2 requires quite a few configurations, on your side as well as your partner's side.

Cloud EDI transfer solutions have detailed instructions on these; however the steps are error-prone, and one mistake can lead to complete breakdown of the EDI communication channel.

(a) Double-checking your end

There are a few EDI transfer configurations that you should receive from your partner and configure on your side. Here is a brief summary:

For sending to your partner:

• Your partner's unique identifier (AS2 ID)
• The endpoint (URL, address) at which your partner receives EDI/AS2 traffic
• The type of EDI/AS2 traffic your partner is expecting (encrypted? signed? compressed? if compressed, is it before or after encryption?)
• For encryption, your partner's encryption certificate
• With signing, your partner's signing certificate
• If the transfer happens over HTTPS, the HTTPS certificate of your partner's AS2 software, along with any non-standard signers of it (chain certificates; as described before)

In addition, you can decide whether to request an MDN (receipt) for the sent EDI/AS2 message; and, if so,

• whether it should be sync or async (see above), and
• whether it should also be signed (like the AS2 message itself).

While most partners would natively support all these combinations, double-checking could be useful in troubleshooting failures.

For receiving from your partner:

On standard EDI/AS2 applications like AS2 Gateway, this should not usually require additional configuration on your end; other than your partner's AS2 ID. However, the setup may vary based on your EDI/AS2 software.

(b) Double-checking your partner's end:

Here are some EDI transfer configurations that you should send to your partner, and he should configure on his side:

For your partner to send files to you:

This is similar to the set of configurations that you would configure on your side, in order to transfer EDI to your partner:

• Your unique identifier (AS2 ID)
• The EDI/AS2 traffic endpoint of your AS2 application
• For encryption, your encryption certificate
• With signing, your signing certificate (could be the same as the encryption certificate)
• If the transfer happens over HTTPS, the HTTPS certificate of your AS2 software; along with any chain certificates

As mentioned before, solutions like AS2 Gateway provide one-click options to share all these details in one click.

For you to send files to your partner:

This should only require your AS2 ID on your partner's end; although your partner's AS2 application may require other configurations as well.

Some applications may require your partner to explicitly define the type of messages (encrypted, signed, compressed, etc.) that you would be sending; others like AS2 Gateway will intelligently derive them from the incoming messages themselves.

Summary

EDI transfers over AS2 could fail due to one or more of a variety of reasons. Checking the underlying error messages is often the key to finding and rectifying these issues.

These issues could be network-level (firewalls and invalid endpoints); content-level (like invalid or swapped certificates); or simple misconfigurations of partner details (AS2 ID, messaging mode or MDN settings) on either your or your partner's side.

Online AS2 providers like AS2 Gateway have support channels where you can obtain further support on any EDI exchange issues experienced by you or your partner.