EDI

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).

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.

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 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 X.400 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.

In most situations, EDI integration with X.400 is best achieved as an end user integration using X.400 P3 or P7. 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 Gateways

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).

Indirect Gateways

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 product for this with M-Switch MIXER. 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.