EDI (electronic data interchange) is the direct, application-to-application transmission of business documents such as purchase orders, invoices and remittance advices. EDI is a critical component of many e-commerce solutions. Isode does not provide software to manage EDI formats or business integration, but does provide components for transfer of EDI documents. This page describes Isode's EDI solution components.

EDI Transport

EDI Transport


EDI defines messages and rules for exchanging business information. EDI requires a transport mechanism to exchange messages, which can operate client/client, client/server or server/server. X.400 is a common choice for transferring EDI messages as it offers:

  • High reliability
  • Good audit logging, security and management
  • Two levels of end to end acknowledgement as standard features
  • Can build store and forward networks in desired configurations, including mesh and star

The above diagram shows an overall architecture for how X.400 servers and protocols are used to build an X.400 EDI infrastructure which enables the exchange of EDI messages. The two core Isode products used to provide this service are:

  • M-Switch X.400 is a high performance X.400 MTA (Message Transfer Agent), suitable for high volume backbone operation. M-Switch X.400 provides a flexible, secure and robust MTA solution.
  • M-Store X.400 is an X.400 Message Store supporting client access using the X.400 P7 protocol, and accepting messages from an MTA using X.400 P3.

EDI applications can connect to an X.400 Infrastructure in two ways:

  1. By use of X.400 P7, connecting to an X.400 Message Store such as M-Store X.400. This is a client server protocol to access delivered messages, and to submit new messages. This is appropriate for small end user EDI applications, and might typically be used by someone running an EDI application on a PC.
  2. By use of X.400 P3, connecting to an X.400 Message Transfer Agent such as M-Switch X.400. This is appropriate for server applications, that do not require the X.400 infrastructure to store messages. It provides a submission and delivery service.

Service Provider Options

End user EDI organizations will often connect to each other using a service provider, providing connectivity between EDI organizations, and acting as a transaction broker (as with a traditional EDI VAN (Value Added Network). This model is shown below.



The core component for a service provider will be one or more X.400 Message Transfer Agents (M-Switch X.400) which provide X.400 switching connectivity between the EDI end user organizations, who are the customers of the EDI . Where the EDI service provider wishes to support small end users, it will also operate an X.400 Message Store (M-Store X.400) in order to provide X.400 P7 client server access.

EDI End User Organization Options

An EDI end user organization typically has two connectivity choices. The first is to connect using X.400 P7 to an EDI service provider. This is a good choice for a small organization that does not require to operate its own X.400 servers. Use of X.400 P3 could in principle be an alternate option for such organizations, but in practice most EDI service providers have chosen to offer X.400 P1 and P7 services, but not P3.

The second choice is for an end user organization to operate an X.400 Message Transfer Agent (M-Switch X.400) and to connect using X.400 P1 (server to server). This is appropriate for an organization with higher volumes of traffic to connect to an EDI service provider, or for two end user organizations to interconnect directly without using and EDI service provider. In this configuration, the EDI end user organization has two choices to connect users to the X.400 Message Transfer Agent:

  1. Direct connection of end users, using X.400 P3.
  2. Operate a local X.400 Message Store (M-Store X.400) and connect end users using X.400 P7.

EDI Application Integration


EDI applications using an X.400 infrastructure need to be able to connect using X.400 P3 or P7. While some EDI applications have integrated X.400 support, in most cases this needs to be added. Isode provides an EDI Client API product, which is a cross-platform simple API, which enable an EDI application to operate over either a P3 or P7 connection. This API is ideal for applications and special purpose clients that require to be connected to an X.400 infrastructure with a minimum of intervening software. Benefits of the Isode EDI Client API:

  • Support of both P3 and P7, means that the EDI application can be deployed in either of the scenarios shown above, without code changes.
  • API provides a simple abstraction and sample applications, which enable very rapid development.
  • API enables generation of X.400 Inter Personal Notifications (IPNs) to acknowledge EDI message receipt.
  • Use of a programmatic API ensures robust message handling, and a straightforward approach to dealing with error conditions.
  • API supported in Java and 'C', as popular programming languages.
  • API supported in Tcl scripting language, which enables flexible testing and easy integration.

EDI Gateways

In most situations, EDI integration with X.400 is best achieved as an end user integration using X.400 P3 or P7 as described above. In this model each instance of the EDI application is an X.400 end user that sends and receives EDI messages. There are more complex scenarios, where there is a need to integrate X.400 transfer with other transfer mechanisms, where this simple model does not work. If there is a need to map large numbers of addresses, and to map transport errors between X.400 and the remote system, then a gateway model is appropriate. Isode offers two EDI gateway approaches, described below.

Direct EDI Gateway

Isode provides an X.400 Gateway API which is co-resident with M-Switch X.400. This API enables an EDI gateway to get at the full message transfer capabilities of X.400, and can support generic integration between an external EDI transfer infrastructure and X.400. In particular, the gateway can receive messages to be delivered to multiple recipients, and can generate X.400 delivery reports (which is not possible with X.400 P3 or P7). While offering full generality, this API is designed to be easy to use.


Indirect EDI Gateway using X.400/Internet Conversion


EDI is often operated over the Internet using SMTP (Simple Mail Transfer Protocol). This can lead to a requirement to convert between EDI/X.400 and Internet Mail. The MIXER specifications are a good basis to achieve this. Isode offers a solution for this with its M-Switch MIXER product. This provides a flexible mapping between MMHS and Internet Email, including full directory based configuration of the mappings. M-Switch MIXER also includes flexible authorization, which can control use of the MIXER gateway and control who can send messages.



In some situations this basic mapping is sufficient. Where additional mapping is needed, such as conversion to XML formats, this architecture can be extended to use SMTP to connect to an EDI Gateway. This architecture has the advantage of using the popular SMTP protocol, but does mean that some X.400 services are not available as a consequence of the MIXER translation. If access to all X.400 services is needed, the direct EDI Gateway approach is recommended.