Understanding the Components of an EDI Environment
Utilizing EDI enables firms to lower their costs of doing business – through reduced error rates, quicker payment cycles and fewer incurred business-administration costs.
Despite EDI’s critical role in millions of business transactions every year, it’s still something of a black box. Few people understand what really goes on when data is sent off or received. We’d like to pull back the covers a bit and give you a brief glimpse at the software and hardware that work in concert inside a complete EDI setup.
EDI Academy, one of the nation's leading EDI training providers has graciously provided a list of system components, and a brief description of each one. In a few short minutes, you’ll be able to dazzle your IT guys with your newfound understanding, and put your children to sleep with descriptions of things they don’t care about.
Karl Kleinbach
Editor EZNews
 Click the image for larger versions |
Software Environment
Millions of lines of code have been written for over 30 years to produce EDI related software. It would not be cost effective or efficient to build a home grown EDI translator, mapper or a communications adapter. There are many EDI software vendors available and they can be found by referring to the EDI Vendor Directory.
If a company does not outsource their EDI operations and decides to install an in-house EDI solution, there are several key components that every EDI software environment must contain: the software vendors typically sell them in full packaged bundles or as separate adapters. However, the Translator, Mapper, Communications and Scheduling tool should be included as core components of an EDI software package. Additional components such as the database, business application, and the integration bridge will typically be sold separately.
Translator & Mapper
As received, an EDI transaction set contains all the information about a purchase order or payment, but not in a form that is either human-readable or usable by any other electronic business software. The data must be converted into a different format, and this is the work of the EDI translator.
The EDI mapper is used to create the conversion specifications; once compiled, the map gives instructions to the translator on how to convert the data. The translator converts an EDI standard document such as an X12 Purchase Order into a human readable format that could be a printed report or even better, into a proprietary or XML format that could be integrated into the Business Application.
Communications Tool
Most EDI software packages will contain a communications management tool used for sending and receiving trading partner data. This tool will typically support multiple transport protocols such as TCP/IP, FTP, HTTP, SMTP, AS1, AS2, etc. Typically FTP and a script to connect to a Value Added Network Service will be included in the standard bundle of the communications component. Since communication set-ups can get complicated, sometimes it makes sense to use a communications adapter that is outside of the EDI software package scope. For example, there are software vendors that specialize just in the communications portion of the software tool.
Scheduling Tool
In order to invoke the communications and the translator tools, a scheduler is needed. The scheduler builds the steps to automate the EDI process. The scheduler automates operations in the EDI environment. The scheduling tool should also have trigger or event based processing features. For example, an EDI translation and communications session is instructed to kick off once a file arrives in a certain directory.
Database
A relational database management system is needed in order for the EDI software package to function and store data. This component needs to be acquired separately from the EDI software package. Most software vendors allow the flexibility of using any standard database tool such as Oracle, MySQL, Microsoft SQL Server or Microsoft Access. Some EDI translators have their own proprietary database.
Business Application
The business application is certainly an integral part of the EDI environment. Once the machine-readable raw EDI data is translated, it should be integrated into the business application to reap all the benefits EDI has to offer. A business application can range from a small business package such as QuickBooks to a full blown enterprise resource planning (ERP) system such as SAP or PeopleSoft. The business application may also be home-grown.
Integration Bridge
Business Applications typically do not allow proprietary translated files to be imported or exported without doing some programming. Sometimes there is a commercial integration bridge tool available that would link the translated EDI file directly into the Business Application. For example, if a map converts an EDI X12 file to a comma delimited or CSV file, the integration bridge tool does the actual work of importing the file into the business application.
Additional Components
Other software environment components may include (but are not limited to) the following features: Trading Partner setup and maintenance, Audit , Security Encryption/Decryption, Archiving, Fail Over capabilities, Error and Alert Notification, Easy Version Conversion, Document Turnaround, Cross-Reference Tables and others.
Hardware & Infrastructure
The hardware and infrastructure setup can range from a personal computer with internet access to a mainframe supercomputer depending on the processing requirements. It is important that all EDI software components ( not just the translator) follow the same standards of appropriately selecting hardware and infrastructure environments. In extremely sophisticated EDI implementations, the EDI components may be separated into multiple servers. For example, the communications software will reside on a different machine from the translator software.
Operating System & Server
Most EDI software packages support multiple operating systems. The most popular environments are: Windows Servers, Unix/Linux, and IBM based mainframes such as the AS/400 and MVS. The operating system of choice should be determined by the company’s IT department infrastructure. For example, if a company is a Microsoft shop and uses Windows servers and network stations and Microsoft SQL Server databases, it would not make sense to install an EDI solution based on a UNIX environment.
On the other hand, if the company’s infrastructure is based on a UNIX environment with an ORACLE database as a backend, it would not make sense to implement EDI in a Microsoft environment. Some software vendors imply that UNIX and Mainframe environments are more dependable for heavy volume data processing.
In a large size organization, the EDI solution installation, the EDI software package and its related components will be installed on two or three separate server environments:
- Development/Sandbox – Safe place for creating and testing implementations without affecting the production environment. For example, software patches or upgrades can be tested here before applying them to the test or production servers to check how they will affect the overall EDI environment.
- QA/Test/Staging – The QA server can be used as a safe area to build, compile and test new EDI maps before applying them to production. The QA environment can also be a staging area to test transactions with new trading partners.
- Production – The production environment is where the day-to-day EDI operations are running. This environment should be locked down and no changes should be made to production without going through proper change control and quality assurance methods.
Networking & Telecommunications
In the not-too-distant past, most EDI transmissions were sent via modems and telephone lines. While some EDI is still done this way, for the most part, fiber optic cables and high speed internet have replaced the telephone modem as a means of data transmission.
Typically an EDI server will be in some sort of data center facility that has appropriate network infrastructure in place to support the required EDI communication methods. Network routers and switches help direct the path for data travel. Firewalls, VPN gateways and intrusion detection systems ensure the data is secure and protected and cannot be spoofed. Data centers can be in-house or co-located depending on the business’ needs.
Fail-over, Backup & Disaster Recovery
EDI is a mission critical component for most organizations, which means a disaster recovery and a failover plan should be in place.
- Fail-over: would be the method to become operational again, if for example, the hard disk or the CPU motherboard of the EDI server crashes. The speed at which the EDI environment needs to become operational again will dictate the type of fail over requirements. For example, in a just-in-time automotive manufacturing environment, auto parts are being received an hour before they are put on the assembly line. The EDI failover time is zero. To mitigate the risk of a situation like this, parallel live production servers could be set up to mirror each other. If one fails, the other instantly picks up the processing. Not a beat is missed.
- Backup: Before EDI, business transactions could be placed in file cabinets and stored off site somewhere. With EDI in place it is important that EDI data is backed up frequently. All EDI data formats should be backed up, meaning the machine-readable EDI data, the translated proprietary data, communication logs and obviously the database. Again, the extent to which a company backs up and restores its data is determined by the business’ requirements. A lot of data backup options exist such as online and on-site, which is the most quickly accessible data. Off-site storage should also be considered.
- Disaster Recover (DR): If a plane crashes into the data center building, a well-implemented disaster recover plan would be set in motion. If the EDI server is in Silicon Valley (San Jose, CA) it might make sense to put the second hot-production mirroring server somewhere in a data center in New Jersey. Typically, a well-implemented disaster recovery plan includes all components of the IT environment and not just EDI.
For example, the EDI server interacts with the business application server (e.g. SAP or PeopleSoft server). During disaster recovery testing it would make sense to test that in the off-site data center location the DR business application server and the DR EDI server successfully interact with each other.
-
About The EDI Training Academy
The EDI Academy founders entered the EDI arena more than 15 years ago, and have been responsible for successful EDI implementations at companies in many industries.
The EDI Academy provides clients a foundational knowledge of the EDI process, and helps them understand EDI from both a strategic and an implementation perspective.
EDI Academy training classes are taught by highly-qualified EDI professionals with at least 10 years of diverse industry experience ranging from Fortune 500 companies to entrepreneurial startups.
Learn more about EDI and how integration worksDownload the whitepaper “Integrating EDI into Accounting and ERP Systems” by Vantage Point. Learn more about…
|
Next Steps
EDI Resources
Video: Why EZConnect
