Electronic data interchange (EDI) is an electronic communication system that provides standards for exchanging data via any electronic means. By adhering to the same standard, two different companies, even in two different countries, can electronically exchange documents (such as purchase orders, invoices, shipping notices, and many others). EDI has existed for more than 30 years, and there are many EDI standards (including X12, EDIFACT, ODETTE, etc.), some of which address the needs of specific industries or regions. It also refers specifically to a family of standards.

In Newegg, EDI is used for exchanging business data between VF / Stocking vendors, third-party logistic carriers & manufacturers. A large number of EDI files were processed every day. There are several systems are running to connect internal business systems with external partners, which maintained by EDI team. Along with the growth of the company’s business, the term EDI has expanded, to stand not only exchanging data with partners in X12 format, but also supports exchanging with CSV files, XML files, Excel files and even third-party REST APIs, it make our systems become more and more complex, the cost of maintenance has increased.

EDI as a Service offers a comprehensive set of fully outsourced EDI services that helps companies to take full advantage of their EDI investment. With EDI Service, companies are able to optimize the efficiency, reliability, and reach of their electronic supply chain while reducing costs, infrastructure and overhead. Future they also have the ability to let existing or new partners register and integrate with their own EDI smoothly and rapidly.

EDI Service Portal is the user interface of the EDI Service platform, it allows different users to setting up relationship between their local system and trading partners to exchange business data via EDI X12 encoding and transmission. EDI Service Portal contains not only the fundamental EDI functionalities, but also including comprehensive monitoring and statistic functionalities. The EDI Service Portal is developed based on Angular JS – the most popular Java script framework created by Google, and Bootstrap - the most popular HTML, CSS, and JS framework for developing responsive, mobile first projects on the web. Almost all of the functionalities in EDI Service Portal were implemented by consuming EDI Service Core APIs, and you can read more information about EDI Service Core API in the next segment.

In EDI Service Portal, all functionalities were implemented by the EDI Service Core API calling through Newegg API Gateway.

In EDI Service Platform, there are many different kind of entities grouped together within an organization to maintain the entities isolation. There are two kinds of partners, one is local partner, it stand for local business group. Another one is trading partner, which stands for 3rd party systems of other companies. Both local partner and trading partner contains one or more stations, the station stand for the department or business division inside the partner.

To exchange EDI data in EDI Service Platform, a relationship must be established between two stations of partners (a local partner and a trading partner), and the EDI encoding properties and transmission settings must be configured on the relationship which is the agreement.

The encoding properties in an agreement controls how EDI X12 file will be generated or disassembled, and the transmission settings in an agreement controls how the EDI files get transferred between partners, including protocols and related settings.

The Core API provides functionalities to maintain those entities and relationship between them.

When user creating Partners, Stations and Agreements, that information also distributed to the EDI Service Runtime Deployment API, which was hosted in a Windows Service running on the BizTalk server, the reason the deployment API must be hosted in a Windows service is because the deployment process was implemented by calling the TPM assembly provided by Microsoft in BizTalk Server installation and it need to access the BizTalk management database directly, and each BizTalk has its own deployment API, it cannot be done if the API was hosted on Newegg API servers.

In current implementation, each organization was hosted on a single BizTalk server. It’s due to the restrictions by BizTalk. In the future, we can replace BizTalk with other implementation, and the restrictions will be broken.

EDI Service Portal use account to manage users in the entire system. There are different type of users in EDI Service Platform, supervisor is the System Administrator which have full access to the EDI Service platform, it can create or manage user accounts, it also could work as an agent to manage a specific organization to manage resources and partnerships inside the organization, when the supervisor is working as an organization agent, it has the same privileges of the organization administrator. An organization could have three different users: the organization administrator, local partner user and station user. For the detailed difference between different users please refer to the user manual of EDI Service Portal.

The system supervisors could work as an agent of an organization, and then he/she could manage resources in that organization like an organization administrator.

In the EDI Platform, EDI data was formed in X12 format, currently the ASC X12 is the only standard that the EDI Platform supports, it will support more formats in the future version for sure.

As we mentioned in the overview section, there are two kinds of xml formats data in EDI Service Platform, one is EDI Xml, and another one is Business Xml, both Xml was described by corresponding Xml schema (XSD), this is the first resource in EDI Service Platform.

When it comes to transformation, the transformation progress was implemented by one of the Extensible Stylesheet Language (XSL), the XSL Transformation (XSLT) which is an XML language for transforming XML documents, in EDI Service Platform we call it mapper, and it is the second resource.

Another resource in EDI Service Platform is the transmission, which defines the transport settings to exchange EDI data for a specific partners, it has multiple types, such as FTP, AS2 and Newegg Message Queue.

The last resource in EDI Service Platform is certificates, we use certificates to encrypt/decrypt and sign EDI files while it been transferred via AS2 protocol. Since the current runtime implementation is based on Microsoft BizTalk Server which running on a Windows Server, the certificate will be deployed on the server’s certificate store automatically. Please refer to this link to get more information about certificates used in AS2 protocol.