AS2: Part 2 – Best Practices

This last year the EDI community has shown a substantial increasing interest in AS2. But what exactly is AS2? This is the second in a multipart series to examine AS2 and what it means going forward to the EDI industry. If you want all the historical and technical information on AS2, then I suggest you Google AS2. This series is about the practical uses and not to bore you with (too many) details. (See also AS2: Part 1 – What Is It?.)

The one thing that most amazes me about AS2 is how many different ways it has been implemented. Just when I think I’ve seen every variation, someone comes up with something new. What there does not seem to be anywhere is an agreement on Best Practices for AS2, so here are mine.

TCP Ports

Without getting in to a deep technical discussion on TCP Port assignments, I feel that this is something that needs to be addressed with AS2.

Most Internet communication standards have common port assignments such as 80 for http, 443 for http over ssl, 20 & 21 for ftp, 25 for smtp, 110 for pop3, etc. Even obscure things you have never heard of have common port numbers (e.g. 17: Quote of the Day).

Generally, when an RFC is written, it incorporates a request for a port assignment. The authors of AS2 did not request this, and in fact they do not even mention TCP port assignments in the entire RFC. I suspect they felt that 80 and 443 would be assumed since AS2 is an http web process. This is not how it is, unfortunately.

What we see in the real world is every hub setting up the service on any port they want, creating unnecessary chaos and Swiss cheese out of their trading partners’ firewalls. Here is a list of some that we have seen out there:

80, 443, 2080, 4080, 4090, 4079, 5080, 6080, 6260, 8080, 8050, 9080, 9480, 32002, 49201, 57080

By far the most common ones seem to be 4080 and 5080. I would strongly urge anyone out there setting up AS2 to stick to ports 80 and 443. It will save your trading partners many headaches getting their firewalls set up properly. If you absolutely must use something other than 80 and 443, use 4080 or 5080 as they are the most common. Firewall administrators everywhere will thank you.

Firewalls

Please make your AS2 server behave like any other web server and don’t burden yourself with having to map every single trading partner through your firewall. It can be made as bulletproof as any other web server, and if you use port 80 as noted above, this is going to be easier to sell to management. Additionally, only messages with AS2 IDs and certificates that you are expecting can get data through. Having to register each of your trading partner’s IP addresses is a lot of work for you, and frustrating for them when they move systems around.

If you insist on mapping every AS2 trading partner connection through your firewall and your trading partner sends you a block of IPs to use (e.g. x.x.x.224/27 or x.x.x.224 255.255.255.224), do recognize that as a block and register the whole block. Don’t add the single address x.x.x.224 to your firewall. If you are sophisticated enough to be using a firewall, you should be intelligent enough to recognize an IP block when someone sends it to you.

HTTPS

The strength and beauty of AS2 is the ability to sign and encrypt data with known certificates. Why do extra work by encrypting the entire session again with SSL? It is unnecessary, takes more processing power, and is yet another certificate to maintain. The goal here is less work, not more, right?

If you absolutely, positively must use HTTPS let me request the following:

• Do not use a self-signed certificate for HTTPS. This will only add to problems to your trading partners having to maintain yet another one-off certificate in their system to properly recognize your server. Having your web server certificate signed by a known certificate authority will pose fewer problems for your trading partners.
• I shouldn’t have to mention this, but since I recently dealt with this issue: Make sure your certificate common name matches your web server URL!

AS2 IDs and EDI IDs

The AS2 ID is like the phone number for your AS2 system. If you have more than one system (e.g. Test and Production), do not give them the same AS2 ID (more on test systems below). If you have more than one department running AS2, do not give them the same AS2 ID. Only use the same AS2 ID on different servers if they are for load balancing or redundancy; otherwise, each AS2 server gets its own AS2 ID.

• Make AS2 IDs Unique per Server

Do not assign the same EDI Qualifier/IDs (GLNs, etc.) to different AS2 servers. If you are running your own AS2 server, you are essentially running your own VAN. If you are running multiple AS2 servers with different AS2 IDs, you are running multiple VANs. You know how frustrating it is for the same EDI IDs to be assigned to different VANs.

• Assign each EDI ID exclusively to one AS2 ID

Testing and Test Systems

Setting up AS2 connections is a process. First all the parameters and certificates need to be exchanged. Then firewalls (if necessary) need to be configured. Then the process of attempting to send and receive files begins.

• Set up a web page that has all your information including URL, AS2 ID and downloadable certificate(s). Include the contact name and e-mail on this page. Put this in all your e-mail messages to your trading partners. Put all your changes on this page (e.g. contact, certificates, etc.) and set up a link to a service like http://www.changedetection.com/forwebsites.html so your trading partners can be notified automatically.
• Have a nice landing page if your software provides it when users try to reach your AS2 URL from a web browser. That allows them to test IP and firewall issues before trying to send a message.
• Allow your system to accept text documents; do not restrict this mime-type. The person on the other end might only have access to communications and not to the EDI data. Even if they have access to the EDI data, they might not be able to generate a test document. Remember, AS2 is a communications protocol; when testing we first just need to make sure any document can be sent and received, before it is plugged into the EDI system.
• Do not use the same AS2 ID for both Test and Production systems
• Do not use the same Qualifier/ID, GLN or whatever EDI addressing your system uses on both systems. Have a Test ID (ZZ*MYCOMPANYTEST) and Production ID (ZZ*MYCOMPANYPROD). You have no idea how complex it can make it to route data to two different systems, using the same EDI IDs. It is akin to giving someone the same phone number to call two different places, and expecting the right phone to magically ring.
• Make sure the two systems work the same way. It is infinitely frustrating when theAS2 test system works one way and the production system another.

Typical Configuration

Use signatures and encryption for all communications, payload and MDNs. It is why we use AS2 and how I’ve seen 100% of AS2 configured. It appears to be everyone’s best practice.

AS2 has a compression option; I’ve never seen anyone request it. Unless you are sending very large, compressible files, it will probably increase your processing demands and not show much speed improvement.

Synchronous vs. Asynchronous MDNs. It just seems to me that an MDN is so small, that it might as well be processed synchronously. Technically, the sending system requests synchronous or asynchronous, but your trading partner might request that you use one or the other. It really doesn’t matter either way. However, if you find that synchronous MDNs are bogging your system down, perhaps you need to review the next section on Inline Processing.

Inline Processing

AS2 is a transport protocol; it is not a syntax analyzer. I’ve seen far too many systems that put data analysis in the AS2 system. If it is a valid AS2 transmission with valid certificates from an expected trading partner, please issue a positive MDN.

• Do not try to validate the X12 or EDIFACT data in the AS2 system. Do not send a negative MDN because of the EDI data. There are EDI protocols for that. Please use them.
• Do not limit the data by the MIME-TYPE, most people don’t know what that is, let alone know how to configure their AS2 system to send a specific MIME-TYPE.
• If you MUST bind these together, then provide a meaningful, proper MDN. 99% of the time this results in an empty, blank, unsigned MDN that is meaningless. If your system is rejecting the data because of the data, then put that in a meaningful MDN (e.g. You sent mime-type text/plain, application/edi-x12 expected).

There are a lot of moving parts to this. When things work right it isn’t a problem; however, when they don’t, it is a huge benefit to break down the issues into smaller parts. When the communication channel is intertwined with the data formatting, it can become very difficult to diagnose.

Certificates

Ah, certificates. The next in this series will be dedicated to certificates, so only the most basic best practices here.

• Give your certificate file a meaningful name: Company.as2id.StartDate.ExpireDate.cer (lorendata.ecgrid.20120830.20140829.cer).
• Make your certificates good for at least two years. It really sucks to get an entire AS2 system set up and tested only to find out the new certificate needs to be installed next week. In the current state of the art, that is inevitable, but the longer your certificates are valid, the less this happens.
• There is no defined maximum lifetime for certificates. I’ve seen several trading partners require that certificates be valid for no more than five years, but not any shorter. This is probably a safe maximum.
• Changing certificates is a pain. This will be explored much further in the next article. For now, I urge you to not set your change for weekends, holidays or after hours. If you do, you are requiring that every single one of your trading partners pay someone overtime to accommodate your certificate change. The best days are Tuesday, Wednesday and Thursday. Do this at a low volume part of the business day for most of your trading partners. Also, give them 60 days of lead-time to help them schedule. Many of your trading partners will actually have to open up the manual to figure out how to do this, or hire someone from the outside. Help them help you. Be considerate of everybody’s time.
• Send a copy of your public certificate with every message you send to your trading partners for initial setup and changes. Do not make them look for previous messages or have to bother you to request the certificate again.
• Attach the certificate to the e-mail in several ways. Many e-mail programs have problems with certificates as attachments. Attach with the extension renamed to .txt, zip it and attach the Zip file. Also, if you can, post it on a web site and give your trading partners the URL where they can download it.

Service Providers and VANs

Many of your trading partners will be using Service Providers and VANs. They systems will generally offer them AS2 connections into your system. If at all possible, set up one connection to that service provider and let all their customers (your trading partners) use the same connection. Nothing is gained by making each one use its own AS2 ID and certificate; they are all coming from the same system. Think how much work the service provider is saving you by not having to manage all those separate connections.

Miscellaneous

While not specific to AS2 configuration, there are a few things that will help you along:

• Set up a twitter account for your EDI trading partners. You are now running your own network; you need to be proactive in letting them know when you have outages (planned or otherwise). When your system goes down, a lot of other people need to know what is going on.
• Respond in a timely manner to all questions and requests. Even if it is simply to tell them that you are busy and when you will get back to them. The sound of silence can be frightening to a small supplier who is having problems connecting to your system.
• By choosing to in-house your communications rather than outsourcing it to a VAN or service provider, you need to be a great customer service department for your trading partners. Yes, you have a lot of AS2 experience behind you, but computers are computers and we are all depending on third-party software. If something is not working, it might be your system. Even if you are not having the problem with anyone else, it might be your system. The goal is not to be right, but to get the systems working.
• Think about what you liked and did not like about your VAN; do not be like the part you did not like.

My overall goal is to not make this more complicated than it needs to be. In most cases, the simplest configuration is the best one. However, if you are implementing a more complex system (e.g. test and production servers), then make sure “simplest applies” to the whole system, not to each individual server. You will save your trading partners (and yourself) a ton of headaches if you keep it simple.

Next time, more than you ever wanted to know about certificates…

Todd Gould
President
Loren Data Corp.