How to set up an EDI Server

Question

I was tasked to check out the feasibility of doing inhouse EDI, as the 3rd party costs are getting out of hand.

In doing web searches on the subject, there is a lot of info about the various documents types and formats and creating them from XML or database files. This looks pretty straightforward. However, I don't see much on the subject of the server to server communication.

The question is, what does it take to set up such as server? I am looking for a 3rd party component that I can run on a Windows server as a server (I see it like as IIS server which just sits there and waits for incoming connections and then does the handshake and accepts the file.) The only thing I have found so far is that MS BizTalk server includes EDI capability.

I have also found Edidev.com which has an AS2 server which looks like it might fit the bill.

I am completely new to this area, and don't want to miss anything important.

Ranice

Another site with EDI components that I found: rdpcrystal.com – Ranice

Answer 1

Most traditional EDI software houses have "enterprise" scale integration options that run on (as) a server. Gentran, TrustedLink, BizTalk..all names that are in that space and are usually a sizable (expensive) investment.

What I use here is Liaison's Delta (translation) and ECS (communication). Both run as client / server. The translation software is a true Windows drag / drop any-to-any mapper that can handle all integration scenarios. This commercial software would run you around $20k. We are currently supporting well over 100 trading partners, doing about 3000 batches of data per day. The system is integrated with our ERP and not only handles EDI but XML, flat file, CSV data as well. Delta and ECS. You might be interested in reading this: My Case Study

If you have your own translation engine (parser) and just want a piece for communication, you can still check out ECS, Cleo Lexicom, or Axway. All have Managed File Transfer solutions that will work for you, and run as a Windows service.

So our server handles AS2 communication, picks up files on schedules, sends data via FTP and FTPs, handles web services via HTTP, and has client utilities to show data coming in and out of the system. It also automatically generates the 997 for inbound transactions. Setup of ECS is very easy. Learning a translator - any translator - can be a daunting task. There are quirks to every one of them. That's where the time will be invested in.

Disturb

I've been reading up on AS2 for an hour now and I still don't understand the essence of this extra layer which really seems like sheer overhead to any tech person. Why do we need this in the first place and why can't we just use https with REST with various payloads? It's so obfuscated to me that I'm banging my head on the wall. Sorry for ranting mate :) – Cankerous

Because REST APIs were not popular 10 years ago when EDI systems started migrating off the Value Added Networks. So initially everyone invested in bisync modems then the internet came around and everyone agreed on a standard over HTTP, with options for security. Investments were made into the standard, companies made a lot of money. Now it fits in the "if it ain't broke, don't fix it" category. – Disturb

Anyway the decision is beyond my influence. My task is to setup one such AS2 server to enable communication with a partner. Do you reckon that, as of 2018, OpenAS2 is a workable option? I'll try to go ahead with an open source option first and see if they require that (questionable) Drummond certification. Oh boy, those days of misery are for me. – Cankerous

OpenAS2 should work fine for you. /n software also gives you one free trading partner. – Disturb

Answer 2

There are many different options available when talking about EDI.

The primary components involved in an Full EDI Setup include, a Translation Tool, a Job Scheduler, a Managed File Transfer (MFT) Solution, and a Server.

Now, what most EDI professionals, primarily EDI Oustourcing Companies want the public to believe is that is setting up your own In House EDI solution is extremely difficult and will cost an arm and a leg.

Granted, some outsource options out there really do cost an arm and a leg like Gentran, GXS Open Text, IBM Sterling, and the other mainstream EDI Service providers out there. Others like Liaison, 1EDI Source, and the like are quite a bit more cost effective and have various different support packages out there including cloud based solutions.

The overall truth of the matter though, and getting back to the original point on setting up your own In-House Solution, is that everything that these EDI Service Providers provide can be done In-House at a fraction of the cost. There are open source solutions, free cloud services options, or off the shelf software that can be installed, implemented, and integrated for use with your business systems.

The cost in this scenario is the In-House EDI Specialist to run, maintain, and implement new relationships with your newly built EDI Solution.

One example solution: Open Source Solution

(Free to download, install,& use)

Translation Tool - MFT Solution - AS2 Server

[ Bots EDI Translator - Waarp MFT - OpenAS2 Server ]

bots.sourceforge.net/en/index.shtml

sourceforge.net/projects/waarp/

sourceforge.net/p/openas2/wiki/Home/

There are many other options out there that can be pieced together and customized to fit your specific business needs.

EDI simply defined is the translation and transmission of electronic business documents from one company to another.

The Translation tool is simply taking one data field from one file and putting in the predefined field on the other file.

The Managed File Transfer is the GUI you want to use in order to view transactions, resend transactions, manually download previous transactions, etc.

The File Transfer portion is simply setting up the communication settings between your company and the company you want to send/receive the file. Can be configured as FTP, SFTP, AS2, or even email distribution lists.

I am the former Business Manager of one of those 3rd Party EDI Service Providers, and was amazed at how the industry was able to trick the users into thinking that EDI was so complex and hard to implement, maintain, or even understand.

I am still in the EDI Industry, and currently work as the Business Analyst for a Manufacturing Company doing, you guessed it, In-House EDI.

Bacchus

very interesting. I actually ended up writing my own server and translation tool and it is now up and running, processing thousands of documents every day as an in-house EDI solution. It's all written in .net and asp.net. I now know pretty much all there is to know about our particular flavor of EDI as processed by utility companies. Like you say, at the end of the day, it's just a text document going across the wire. – Ranice

@zac-odell would you mind explaining a bit more the role of each component? The translation tool only works with local files? Is the MFT just a GUI for cron jobs doing FTP? What's AS2 and why does it nee a server? Is it EDI over HTTP? This would enrich the answer a lot. Thanks – Bathulda

Answer 3

This is a really old question (but then, EDI is a REALLY old technology).

Your transmission software is what is internet facing, and most of your trading partners will use a form of FTP, and your translation software will just pickup the files from their FTP mailbox. NOTE that many trading partners insist of having a Drummond certified FTP server, so this could be the most expensive part of a small EDI setup.

Anyway, the way to set this up is to have your FTP/SFTP/FTPS server (Cleo Lexicom or something similar) accept and/or send the files, and your translation software take over from there.

Argolis