Picking the correct EDI (Electronic Data Interchange) document exchange provider is very important for a trouble-free business workflow; EDI exchange is becoming a very common requirement in today's automated business domain. Things may look complicated, but a simple questionnaire would immensely help you pick and choose between the plethora of EDI providers out there.
Rather than hosting and maintaining your own EDI exchange infrastructure, it is often cheaper and more convenient to bring a third-party (often SaaS, i.e. online/cloud hosted) EDI communication provider.
However, there are a few points that need careful consideration before you do so:
1. What document types are you dealing with?
EDI is just an umbrella term for a wide array of electronic trading document standards: EDIFACT, ANSI X12, ebXML and so forth. Each of these has dozens of types representing actual documents: UN/EDIFACT CUSCAR D.11A for customs cargo reporting, X12 INS-112 for property damage reports, and so forth. In real life you wouldn't _really_ be exchanging EDI, but one or more of these concrete types. So it is important to know whether your provider supports the expected set of document types.
Providers (like AS2 Gateway) are payload agnostic - meaning whatever you give them, they will transfer verbatim; regardless of whether it is an X12 INS-112, an UN/EDIFACT D.11A, or even a JPEG image or a ZIP file. This is very convenient because you can simply plug-in such a provider easily into your EDI exchange workflow, and forget about everything else.
However, if you expect the third-party EDI exchange provider to do additional work based on the document type, you might need to contact the vendor and clarify whether they support it.
2. Do you wish to only send, only receive, or do both?
While most providers do support both, knowing your communication direction would be important. With some high-tier providers, as well as open-source solutions like OpenAS2, configuring the receiving path could be quite challenging; in others like AS2 Gateway, most of the possible receiving configurations would be taken care of by the platform itself.
3. Do you want to modify or transform the document, before transmission or after reception? Or is it just a send/receive?
Some providers offer EDI processing facilities (composing, interpreting and even autogeneration and auto-reply). However, this usually comes at an additional cost and, more importantly, configuration overhead. If you are not looking at modifying or interpreting the content (e.g. your supply chain management (SCM) or warehouse/inventory management system would already be able to do this for you) it would be simple and cost-effective to go for a provider that simply provides EDI transmission capabilities.
4. What is the preferred transmission medium for EDI exchange?
As mentioned earlier, EDI is just an umbrella term, and even UN/EDIFACT CUSCAR D11A is a document type. Usually what is more important is the medium of transfer.
A good analogy is a goods delivery system: you have goods (information) packaged in various ways (formats) - bubble wraps, sachets, boxes, crates, etc. - that are loaded into a vehicle (medium of transport) - van, lorry, freight train, etc. - and carried to the destination.
Similarly, trading information is packaged into various document formats and transmitted to the destinations (trading partners).
A few famous transports used for EDI exchange are:
VAN (Value Added Network)
Contrary to the similarly-named vehicle type, this is a dedicated end-to-end network for exchange of EDI (and other document types) - like privately-owned rail tracks. These are quite expensive and difficult to operate and maintain, so most organizations are moving away from them.
ASn (Applicability Statement) family of standards: AS1, AS2, AS3 and AS4
These are attempts to transfer EDI data securely over existing public networks (like transporting valuables in sealed containers, on public highways). ASn falls into four standards, utilizing email, HTTP (same tech used by browsers and most web/mobile applications), FTP (file transfer protocol) and web services (over HTTP). By far the most popular and widely-adopted is AS2, the HTTP-based protocol.
OFTP (ODETTE File Transfer Protocol)
This is another transfer mechanism like AS2 (more advanced, in some aspects). OFTP is more popular in Europe rather than in the Americas; AS2 is more popular in the latter, thanks to the initiative by Wal-Mart. OFTP has its own network protocol, whereas others like ASx are built on already-established protocols like HTTP/S.
If you are dealing with Wal-Mart, Amazon or any other American partners (large or small), you would probably need to go for AS2.
5. How much do you intend to transfer (say, per month)?
While most providers have extensible plans, they are often quite expensive beyond the basic limit. For example, for a 1000 messages/month package, the cost for 1500 total (500 extra) messages could be significantly higher than the cost of directly going for a 2000 messages/month package.
Additionally, remember that most cloud-based vendors use shared systems for message exchange. If you tend to receive or send batches (spikes) of documents (e.g. every day at midnight) the transmission performance might be affected, especially if the EDIs are large (several megabytes) in size.
6. How many partners are you dealing with?
EDI exchange usually happens between predefined partners - digital identities for easily and reliably communicating with and managing real-world business relationships. If you intend to exchange EDIs with multiple partners, go for a platform and package that supports as many as you want.
7. Do you want multiple trading identities?
Since EDI communication is generally two-way, you as a trading entity will also have your own identity (referred to as station, local station, local partner etc.). Others will refer to you by this identity when they transfer documents to you. The standards allow you to have multiple such identities (e.g. JOHNDOE for dealing with Wal-Mart and JACKSON for Amazon), so if you intend to leverage it, make sure you pick a platform that supports it.
8. Do you have strict security or compliance requirements?
Cloud or SaaS EDI transfer services would often work for generic EDI exchange use cases. However, some trading partners may impose tighter limits; network configurations (VPNs, firewalls and other layers of security), advanced encryption and signing algorithms, non-standard headers, etc.
In other cases, your own EDI/AS2 installation may need to meet various security or compliance requirements; either as specific corporate guidelines or in terms of generic standards like PCI-DSS, SOC or HIPAA. They may be imposed by your partner, or your own organizational policies
In either case, such scenarios may require you to go for a dedicated EDI exchange set-up; or, in extreme cases, an on-premise EDI transfer utility which can then be further customized to meet the specific requirements and compliance guidelines.
9. How would you like to connect the EDI exchange workflow to your existing trade systems?
Manual send/receive may work for up to a few hundred messages per month, but you would need automation if:
- your message counts are in several hundreds, thousands, or beyond
- you already have automated trade systems in place - warehouse management, automated order processing, and so forth
On-premise solutions usually offer more flexibility for connecting with existing systems; however, modern online EDI exchange software also offer convenient B2B system integration options. For example, AS2 Gateway allows you to send and receive messages via SFTP (secure file transfer protocol); place your files into a SFTP outbox directory, and read received files via another SFTP inbox directory. Similar entrypoints will soon be introduced for other storage-driven options such as AWS S3.
Meanwhile, REST APIs are becoming increasingly popular as integration points for EDI exchange. REST does offer simple and convenient interaction with general entities; yet, it may be complex when handling EDI payloads; especially when uploading and downloading large EDI exchanges. AS2 Gateway also has a beta-stage API, where you can gain access on demand.
Usually, on-premise EDI exchange solutions can support virtually any type of custom integration. AS2 Gateway On-premise, for example, can connect with a wide array of systems, protocols and transports; including SSH/SCP, files, S/FTP, HTTP/REST, message queues (AMQP, ActiveMQ, IBM MQ, AWS SQS, Kafka etc.), storage-as-a-service like AWS S3, Dropbox, and so forth.
10. What is your implementation deadline - or go-alive timeline?
On-premise has an installation overhead, while online solutions help you get started with EDI exchange in just a few clicks.
However, setting up communication is the most time-consuming part of the process. Exchanging the connectivity information between the trading parties (e.g. partners in AS2) as early as possible, can greatly simplify and speed up the process.
- party identifiers (e.g. AS2 IDs)
- proper message configurations (does each party need their messages encrypted, signed, and/or compressed? if so, with what algorithms?)
- certificates (encryption, signing, HTTPS, trust chains) and other cryptographic entities
- any special markers (e.g. custom entries, such as HTTP headers) within the EDI exchange process
Despite the initial overhead, on-premise offers a smoother ride on the long term. Fixes and enhancements can go-alive faster, and you can bring in any desired customizations; even proprietary ones, as long as the EDI exchange vendor can support it. If your trading system is highly dynamic, and evolving and scaling fast, bringing in an on-premise EDI exchange can considerably save time (and money) long-term.
Did we cover all your questions? Do you need to know more? Either way, drop us a line and find the one-stop solution to all your EDI/AS2 needs!
In conclusion
Setting up your EDI exchange may not be trivial. But when you know the requirements and pick the correct provider, the rest would be fairly smooth. Once set up correctly, the EDI exchange would be one of the most automatable, integration-friendly, resilient and maintenance-free components of your trading infrastructure.
Feel free to contact us for advice or guidance in setting up an EDI/AS2 exchange. In most cases, you can follow our documentation and do it yourself as well, on our cloud AS2 Gateway.
No comments:
Post a Comment