API, AS2, FTP – What’s the diff?

We get searches all the time about As2 -what is As2, As2 vs. FTP, etc. The crux of the matter is not what As2 is, it is what it does…and how it’s used by different actors in various supply chains.

As2 is a file transfer mechanism that uses Http as the transport medium, certificates to secure the payload (the EDI document), and a overriding “state machine” that orchestrates the transfer.

As2 differs from FTP (and the secure flavors of FTP) in the way it handles file transfers. Failures, success, and reporting mechanisms are different, and perhaps a bit richer, with tighter control of failed transfers. Also, FTP, in addition to facilitating the transfer, also grants access to the server directories (which are defined in the FTP application). Even though you may have limited the FTP server’s access, and set the appropriate permissions, FTP can execute directory commands and such. So…..it’s good to know that.

AS2 transfers an encrypted file from parter to partner – period. There is no directory access other than what has been configured. Credentialing for vanilla FTP is trivial, name and password. There are several version of secure FTP (s/FTP, FTP/s, and some things that are called FTP that have no relation to the standard (OFTP). Good? Still, between system operators that know what they are doing, FTP remains the king of the file transfer kingdom – there have been challengers, none have stolen the crown. Yet.

FTP software runs from free to very expensive for multitenant service provider systems.

AS2 has many differences, most notably setup requirements that drive some sysadmins crazy. The AS2 Standard (it is an IETF standard)) defines many things, but what was left out of the spec causes most of the problems we see in the wild. For one thing, the geniuses who promoted and who still certify AS2 never defined a port configuration standard. Let that sink in for a moment. Had port config  been at least suggested as a best practice, it would have saved many beleaguered EDI administrators much agitation. There is one well known deficiency we can cure right now – please, everyone use port 80 for As2. Just do it.

Next, s/MIME types and certificates. I’ll write about that next week, we will party out of this evolving article,  and even call upon Todd Gould, the EDI Communication Sector’s leading architect, on what to do about making AS2 easier to scale and manage. Hint, AS2 is an acceptable communications technology for secure file transfer, but as a populist weapon for waging a VAN revolt, it’s just not most effective way to create change in the industry.  I will expand greatly on the topic of “VAN Exodus” next week – but for now let me say one thing:

AS2, taken as a standalone communications channel and file handling methodology (its not a protocol), does not deliver enough sum total value as a VAN replacement. Large As2 systems, the types used by major hubs, a burdened by sunken and recurring costs, machine dependencies, support labor, and general overhead. While VANs deliver, for all their faults, a global network of addressable end-points, at a very low (True total cost) prices, and with almost zero on-premises infrastructure.

AS2 systems, as a class, are spawning a generation of isolated non-addressable partner endpoints.  Furthermore, AS2 systems cause many system administrators heartburn when configuring the 47 1/2 trading partner, if you know what I mean. Translation:  Quite a few As2 systems  started up fine, and were rather docile, until they outgrew their infrastructure base, and partner support issues that seemed non-existent at first…..became nightmares after the Nth trading partner was added…..

The nightmare scenario was related to me by a user of ECGridOS, who was testing the 3.0 beta extensions for Unified VAN+AS2 message handling – this developer was a very experienced integration consultant, one who does it all – he selects hardware and software, writes integration code, and he never uses mapping tools – he hard codes the SQL in the database – he also builds the racks and manages his clients EDI systems via RDP – as if that was not enough, he had, until becoming an ECGridOS developer, generally negotiated the VAN contracts for his clients – which removed a very essential element of control from his otherwise meticulously integrated systems. His conversion to ECGrid and ECGridOS for his client portfolio brought many advantages with the sphere of VAN based EDI Communications.

When the time came for our hero to start implementing AS2, his experience was sufficient for him to intuit the potential downsides, even when things were working well. As2 took the comms equation and turned it on his head. Now, the comms dependencies where a new, living, breathing entity that he was responsible for- and that meant he had to be available for the partner growing pains.

Yada yada – these problems are well known in regards to As2 – an arbitrary communications method that plunks every vagary into the lap of the EDI staff or their professional services team. When Todd made ECGridOS 3.0 beta available to a limited (but growing cohort) of top-tier developers who had experience with the production version of the API, we started to see the magic happen.

The praise was forthright, “why hasn’t anyone done this before, I love it!”, I guess he was speaking of the ‘VAN Exodus'”. Here was someone that knew the;score, Comms via a VAN  and AS2 should have  always been unified. The idea that As2 had to be show-horned into a dedicated IT spot to gain some semblance of ‘communications autonomy’, has been a misguided trend.

Furthermore, if the costs of using VANs have become costly, why is As2, of all things, the answer. I guess that it may have been a top down initiative from a powerful retailer, many have speculated that it started with Walmart. At any rate, a tremendous amount of agitation has ben borne by many a good EDI or IT administrator – over the use of AS2 as a lower cost replacement for VANs and KC’s.

I posit that many AS2 operators at the end user level may be coming around the realization that these systems have built in an hidden costs they never could have dreamed of, and administrative and support overhead that they never envisioned. If VAN metering costs are the issue, then that should be tackled, and if communications are a problem, then that should be addressed.

So Todd, in an amazing stroke of genius, took his architectural sword, and cut through the know of VAN costs, and As2 complexities, and made one unique solution that just about fixes everything.

ECGridOS API with AS2 extensions.

ECGridOS – the EDI Network Architectural Foundation that makes AS2 easy, inexpensive, and a seamless extension of B2B Communications along with VAN based messaging.

Till next week. AW.

FTP:The Train has left the station

See this new post about the exciting AS2 extensions to the ECGridOS API

There are a number of ways to verify that a file has uploaded successfully , but there is certainly no way to resolve end-to-end issues. FTP, while it works most of the time, leaves much to be desired from a delivery reporting standpoint – especially if you have multiparty routes and transactions. I guess there is always the phone or a provider’s web interface – but really….

IF you are too bored with the details of AS2 and FTP, especially if you are a service provider looking for an alternative, but are more of a fun type, hear the ECGridOS API Value Proposition in Video Prose

AS2: I came all this way for a partner interface, and all I got was this lousy protocol!

AS2 is the un-improved improvement. While AS2 is a perfectly fine secure connector for partner to partner, or to VAN, it is a proprietary MIME implementation that does not give back to its users an equal measure of utility or productivity –  not compared to the investment. Don’t stop me now!

AS2 interfaces are HTTP secured connections using signed certificates that require some level of management to keep the certs up to date. If you are a company with one or two interfaces, good for you, Jack. If you are managing hundreds or thousands of AS2 certs, I don’t have to explain the pain of keeping the cert database up-to-date. But wait there is more:


Too many As2 partner interfaces are charged per connection – you have to buy each connection as a unique instance – which they are not. It has the flavor of a raw deal for  mid sized partners. I have never seen the likes of As2 – a mediocre protocol at best, and a kludge charged at caviar rates to the least empowered parties.

Technically, AS2 is a cut above FTP for its richer status reporting and security. If you write your own integration code, you do have options, however; there are numerous functional clones of Drummond AS2 for Visual Studio and other IDE’s. There are real, ‘genuine’, code libraries for As2. It will be on to you to make it work. I have seen drop in As2 partner interfaces for SAP and GIS that cost thousands per partner interface, whereas an As2 code library is around 450-1000 bucks, and is reusable for as many Partner ID’s as you want. My personal belief is that VARs and EDI integration shops should eschew AS2 – what a great chant for the future of B2B trade!

What are we getting for our investment in As2? Especially for code level integrators and VARS, there are better solutions based solely on the technical merits, and costs saving are not the primary justification. We can start with a self serving look at ECGridOS, Loren Data’s API for accessing the routing power of the mature and powerful ECGrid EDI routing transit broker architecture.

ECGridOS is a Web Services API with over 90 functions for configuring and controlling trading partners, as well as managing,  sending, receiving, and tracking EDI docs in transit from end-to-end, and more? Most EDI functions can code up with less than a dozen functions. Yet, there is so much more.

As I explained in the previous post, ECGridOS is the programmer’s gateway to ECGrid, a most powerful EDI routing system. If your application would benefit from integrated EDI communications functions, there is no comparison to FTP or AS2. I want to make it abundantly clear however that Loren Data fully supports FTP and As2 in our other service offerings.

However, for code level calling and customization of new products and for platform providers (PAAS, SAAS) who want to offer x12 communications services to all available commerce routes via one unified connection – this is it.


Tags: , , ,

2 Responses to “API, AS2, FTP – What’s the diff?”

  1. Babelabout says:

    AS2 can even be completely free on top of your internet connection cost 😉 AS2 is just a combination of three well-known (old) standard technologies, i.e. MIME, RSA PKCS #n and HTTP, for which support exists for years in any programming language! As an example, I have written 137 lines VBScript that can actually send any messages via AS2, have a look at here and let me know what you think. I just need little encouragement to provide full AS2 support in the same way!

    • alan-w says:

      There are quite a few freeware AS2 tools for Visual Studio, Eclipse, and other environment. I think in one of my posts, I cover that action. The Drummond Red Herring is another issue, or non issue. Point is, for AS2, you can pay, not pay, pay too much, etc. The downside of AS2 is that it adds very little value for what you exchange in time to code. The two ends of an AS2 connection need at least what I call, ‘liars reliability’.

      As a VB and Visual studio (or for that matter Eclipse) man, you would do well to look at ECGridOS, because you can’t get better message tracking, you do get the benefits of a peer to peer connection AS2 hub, and the 600,000 routes to every VAN in the world (virtually). True, some AS2 freeware is, well, free, and ECGridOS is a few bucks a month, but if you review the API documents, you will why, you will see the power of an EDI API.