Electronic data exchange
BusinessMail X.400—Telekom Germany’s business data network
The X.400 protocol—more security for electronic data exchange
Apart from FTP communication , the X.400 protocol is closely linked with the commencement of professional EDI document exchanges.In terms of security, X.400-based document flows focus on the exchange of sensitive, machine-readable EDI data in addition to pure data transport.To ensure system integrity, the X.400 protocol forms a closed network with controlled access points. Each user is virtually known by name (unique X.400 address) and interacts only with the help of personalized X.400 accounts (X.400 mailboxes) within the X.400 networks of the respective operators.
In practice, the stringent technical requirements for setting up and operating an X.400 network mean that there are only a few X.400 providers worldwide. A distinction is usually made between national (e.g., Deutsche Telekom’s X.400 network, Editel in Austria, etc.) and international (OpenText, formerly GXS, etc.) X.400 providers. X.400 interfaces exist between the X.400 networks of the providers, which also enable EDI data transport between the different X.400 networks and providers.A system-specific feature of the X.400 architecture predestines the X.400 protocol for use with highly sensitive EDI connections.
EDI transmission with X.400 and proprietary FileWork client
Classic X.400 data exchange with Filework client
Through their personal X.400 access account, each X.400 participant can set EDI data to be sent to this X.400 mailbox and retrieve received messages. Synchronization between the individual X.400 access accounts always takes place via the X.400 network of the respective X.400 operator and can be initiated manually or automatically.It is therefore impossible to directly access the X.400 mailboxes of third parties. Because of the additional benefit (value), X.400 networks are also called X.400 VANs (Value Added Networks).This is one of the main reasons why an EDI connection via X.400 was for a long time the tried and tested means of choice for transporting business process-related data exchanges between individual EDI systems.
Higher X.400 costs—no reliable EDI monitoring
The disadvantage of such an X.400 transport scenario is the additional costs that have to be paid to the respective X.400 provider for using the X.400 network. Provider, billing model, and various other factors determine the cost structure of X.400-based interaction between EDI participants during electronic document exchange (e.g., the frequency of access to the personal X.400 access account, the frequency of synchronization with the EDI partners’ mailboxes, file size, number of items, or bytes of the individual EDI messages).
The X.400 network of Deutsche Telekom, or TCom, is by far the most frequently used X.400 provider (BusinessMail X.400) in Germany. For a long time, access to the personal X.400 mailbox within the Telekom network was possible only through the proprietary X.400 client FileWork. For EDI data exchange, EDI messages are transferred to this client or taken from it. The actual synchronization process with Telekom’s central servers is handled at the technical level by the X.400 client, which is usually installed on site.
This approach has significant disadvantages with regard to holistic EDI monitoring. Due to technical restrictions, only the transfer or acceptance of EDI messages can be tracked with the X.400 client. FileWork has only a rudimentary script interface, which has been shown to be error-prone and therefore of little use in detecting whether EDI data has been correctly passed to Telekom’s X.400 servers.
Electronic data exchange via BusinessMail X.400 with X.400 MessageGateway
Telekom’s new EDI gateway: BusinessMail X.400
For some time now, Telekom has been offering a new technology called X.400 MessageGateway, which compensates for the existing disadvantages with respect to meaningful EDI monitoring.
On a technical level, an sFTP client-server coupling with Telekom’s central X.400 servers is set up for data reconciliation for the exchange of EDI documents. In this scenario, the Softzoll X.400 MessageGateClient forms the core technical component of X.400 connectivity: above the familiar sFTP protocol functionality, a superstructure has been implemented that enables the client to process and log the various X.400 statuses. On this basis, the secure transfer process of EDI data with Telekom’s servers can now also be professionally logged and tracked for the first time, which is an important component of global monitoring across all variants of EDI data transmission. The X.400 FileWork access program mentioned at the beginning does recognize various status messages for the individual sections of the X.400 exchange process, but they can only be read via a proprietary script interface, which is considered to be less integration-friendly in practice due to frequent malfunctions (see above). With the new technology of the X.400 MessageGateway, the evaluation of the relevant sFTP transmission statuses is simpler, less error-prone, and considerably more performant thanks to the robust and globally popular sFTP technology.
X.400 network: Cloud storage for EDI
So in all technical X.400 scenarios, the X.400 provider always just takes the EDI messages stored in the X.400 mailbox for dispatch and forwards them to the recipient’s mailbox. For this reason, X.400 mail systems are often referred to as store-and-forward networks.This characteristic makes X.400 suitable, among other things, for use in EDI scenarios in which a large number of suppliers must be integrated at several EDI process levels. Such constellations are often found in the retail segment, where the number of suppliers can go into the thousands. Among the sub-processes to be implemented, DESADV (delivery notification) and INVOIC (invoice) are often the focus of attention, as they have more stringent requirements (data quality and scope).
From the perspective of a business group, the ORDERS (outgoing order) process, which is underestimated due to its reduced semantic complexity, plays a key role and represents a challenge from a technical point of view. The underlying business model of (just-in-time) goods handling relies on the constant replenishment of retail products; the outgoing order data stream is essential for the success of the business model. These requirements can be simplified considerably by using X.400 technology.
EDI law and X.400: Responsibility – clearly assigned
Due to the special features of the X.400 scenario, the ordering process is finished and successfully completed when the ORDERS EDI messages are delivered to the sender’s X.400 mailbox. From this point on, the X.400 provider is responsible for transporting the EDI messages and for delivering them to the recipient’s X.400 access account. Upon receipt of the EDI order data in the recipient’s X.400 mailbox, the responsibility for the ordering process is transferred to the supplier, who must ensure the further proper processing of the received EDI order data.
For the shipper, the duty of care ends with the transfer of the EDI order data to their own X.400 account—a major relief! In addition, the supplier’s X.400 account serves as a buffer for the EDI ORDERS until they are retrieved by the supplier. Point-to-point connections based on protocols such as AS2 do not offer this functionality; in the event of a disruption to the internet connection on the supplier side, transfer of the EDI order data cannot be implemented, but responsibility remains with the sender, leading to delays and thus additional expense in the procurement process.