• AS2 (Applicability Statement 2) is a protocol used to exchange business data safely and securely via HTTP, making it one of the most popular methods for EDI message exchange with partners
• Today the AS2 EDI protocol is increasingly recognised as the most reliable and attractive way for businesses across industries to exchange EDI messages
• AS2 operates over HTTP and is optimised for secure EDI transmission, providing a standardised method for structured data exchange
• AS2 ensures data integrity and confidentiality through encryption, digital signatures, and message disposition notifications (MDNs)

Applicability statement 2 – more commonly referred to as AS2 – is a protocol which is used to exchange business data in a safe and secure way via HTTP. Today the AS2 EDI protocol is one of the most popular ways that businesses exchange EDI messages with their partners.

In this article we’ll explore how the AS2 protocol works and why it is so popular in the EDI sphere.

AS2’s growing usage

On the face of it, AS2 is simply one of a number of different protocols that are available to businesses when it comes to exchanging EDI data with one another. However, AS2 is increasingly being recognised as the most reliable and attractive EDI protocol for businesses across all industries. 

The reason for AS2’s impressive reputation can be boiled down to three key benefits that it offers users:

• Security

When messages are sent via AS2 they are encrypted by the sender and have to be decrypted by the receiver. This provides a layer of security that is crucial given the business-critical nature of the information being exchanged. 

• Transparency

When using AS2, the sender will always get an acknowledgement notifying them if their partner has successfully received the message or not. Plus every message has a unique identifier, which makes tracing very easy.

• Convenience

AS2 is extremely popular with large supply chain organisations. In the retail sphere, for example, Walmart, Amazon and Migros all require suppliers to use AS2 – with Walmart having done so since 2002. This has had a knock-on effect on supply chains across the world, meaning AS2 is now the logical choice for customers and suppliers alike. Moreover, the fact that AS2 uses HTTP to exchange messages is also beneficial, as HTTP’s own popularity and high level of standardisation makes debugging simple.

What are the key attributes of the AS2 protocol?

Keys and certificates

One central feature of the AS2 protocol is the use of keys. In AS2 exchanges, sender and receiver have both a public and private key. These public and private keys are mathematically related, with the public key being calculated using the private key. 

Public keys are meant to be shared with partners, and allow recipients to verify message authenticity without requiring the sender’s private key. If the system just required each party to have a public key, there would be no way to verify that a message wasn’t sent by a fraudulent party. 

In AS2 exchanges, a certificate contains the public key of a party, together with a signature, which can be made using the private key of a trusted certificate authority (CA).

Key stores

Key stores are containers that hold several private keys and certificates. Two common use cases of containers are identity stores and trust stores. The first holds a private key with the corresponding public certificate. The latter holds a set of certificates, e.g. from CAs. 

Key stores are usually single files with different extensions. Common extensions are .jks (Java Key Store) and .p12 (present industry standard).

Encryption

Data encryption is a key aspect of the AS2 protocol as it ensures the security of the data being transmitted. In exchanges sent via AS2 the sender encrypts the payload with the public key of the receiver. This ensures that only the receiver (who has the relevant private key) can decrypt the message.

Most commonly used AS2 encryption algorithms = Triple DES (3DES) and AES-256 (both state-of-the art encryption algorithms)

Digital Signatures

In addition to encryption, AS2 also uses digital signatures, which allow the user to guarantee the authenticity of the sender/receiver. First, the sender signs the payload with a private key. The receiver then verifies the origin and authenticity of the message using the sender’s public key.

Most commonly used AS2 signature algorithms = SHA1, SHA256 and SHA512

Acknowledgements

In AS2 EDI exchanges, a Message Disposition Notification (MDN) serves as an acknowledgement of the message transfer to ensure non-repudiation. It is a digitally signed receipt of a file which is received by the recipient and sent back to the message sender.

Hash Function / MIC

The message integrity check (MIC) is connected to the MDN, and ensures the integrity of the message content. It is calculated with a secure hash function over the payload. The receiver calculates the MIC over the received payload and sends the MDN, including the MIC value, back to the sender. If the returned MIC value equals the original calculated MIC value, the payload is an integer.

How AS2’s secure transmission loop works

The diagram below shows how a message is transmitted from sender to receiver, and how the receipt of the message is communicated back to the sender.

[click to enlarge]

On the sender’s side…

1) The message integrity check (MIC) is completed using a secure hash function. 

2) The sender then digitally signs the message content with their private key and the file content (including the signature) is placed in a MIME message. 

3) The MIME message, which includes the file content and the digital signature, is encrypted using the receiver’s public key (certificate). 

4) Before the data is transmitted via HTTP, specific AS2 EDI headers are added, e.g. AS2-FROM and AS2-TO. Additionally, a request for the return of a signed receipt is requested.

On the receiver’s side…

5) The message AS2 headers are checked to verify if sender and receiver are correct.

6) The receiver then decrypts the message with their private key.

7) To verify the sending partner (and that the payload wasn’t changed), the signature is verified with the sender’s public key (certificate). If both steps are successful, the integrity of the data and authenticity of the sender can be guaranteed. 

8) The receiver returns the signed receipt as confirmation (MDN). This receipt contains the hash value of the message (MIC). Therefore, the sender has confirmation of the proper authentication and decryption of the receiver. The MDN is also transmitted via HTTP, either synchronously during the same session or asynchronously within a different session than the sender’s original session.

Back on the sender’s side…

9) The signature of the MDN is verified with the receiving partners certificate, confirming that the MDN was digitally signed.

10) The MDN is stored for non-repudiation or troubleshooting purposes.

Setting up an AS2 EDI connection

Before you can start exchanging messages via AS2 with partners, it is necessary to complete several steps. The first and most important of these is setting up the relevant AS2 software. 

Software setup

For businesses in this position there are three distinct approaches to choose between: installing the software on-premise, installing via the cloud, or opting for a Software as a Service (SaaS) solution.

1) Installing on-premise 

Traditionally, on-premise installation has been the most popular approach for achieving AS2 compatibility (be it on company servers or virtual machines).

Pros

• Simple to meet data localisation requirements
• Tight integration with internal systems possible

Cons

• Expensive, especially when operational and maintenance costs are accounted for
• Integration with cloud-based systems (e.g. Google storage) can be difficult

2) Installing via the cloud

A cloud-based approach offers a simple way to satisfy regulatory requirements while leveraging the flexibility and availability of the cloud. 

Pros

• Excellent scalability and availability
• Greater capacity for integration with cloud services
• Lower cost than in-house installation thanks to much simpler operation and maintenance

Cons

• Integrating with legacy in-house technology can be difficult

3) Utilising an SaaS provider

Using a SaaS provider offers a quick way to achieve AS2 EDI connectivity, with users able to sign up and configure AS2 settings themselves via a web interface. 

Pros

• High potential for cost savings, particularly for businesses sending a low volume of messages via AS2, as payment is typically managed on a per use basis
• AS2 connectivity can be achieved extremely fast
• No maintenance or operational costs

Cons

• Can be difficult to meet specific data localisation or network requirements. 
• As with cloud-based installations, integration with in-house legacy technology may be tricky

Creating a partner profile

Once access to AS2 EDI software has been achieved (either via on-premise installation, the cloud or an SaaS solution) both you and your partner must provide the other with your AS2 identifier, URL and certificate. 

Both parties must then create a ‘Partner’ entity within the AS2 software using this information.

Testing

After partner profiles have been created, the next step is to test connectivity.  This is done by exchanging basic text files, which can then be verified for integrity by the receiver. During this stage it is also advisable to test the sending and receiving of MDNs.

The AS2 connection is deemed complete and validated only when both partners can exchange files successfully.

Final setup and go-live

Once testing has been successfully completed, the AS2 connection can be made live. 

Looking to experience the benefits of EDI with minimal internal effort?

Whether it’s setting up an AS2 EDI connection, handling complicated EDI mappings, or simply liaising with partners during onboardings, EDI processes can be technical and time consuming. 

Thankfully, however, effective EDI doesn’t have to be difficult!

At ecosio we understand the importance of successful, reliable EDI connections, and are passionate about helping our clients to experience EDI’s full potential. As we know that supply chain organisations don’t always have the time or expertise to integrate, run and maintain an EDI solution, we offer a fully managed service, allowing businesses to experience all the benefits of efficient EDI with none of the hassle.

With a single connection to ecosio’s cloud-based EDI solution (our Integration Hub), you can achieve hassle-free connections to all your partners, no matter how complicated your routing or mapping requirements. 

In short, we take care of all your EDI needs, from liaising with partners and setting up connections to message monitoring and error resolution, leaving you to concentrate on what you do best.

For more information, contact us today!

Der Beitrag The AS2 EDI Protocol Explained erschien zuerst auf ecosio.

But EDI integration in modern ERP systems is a complicated process and one that requires significant expertise if a long-lasting solution is to be achieved. While there are many things that can go wrong when implementing/migrating to a new EDI solution, there are four main hurdles that must be overcome: standards, technology, processes and legal requirements…

Hurdle 1: Standards

EDI document standards were created to make supply chain automation easier by providing a set structure for commonly used B2B documents. However, as EDI has evolved over the decades, more and more standards have been created to cater to increasingly specific requirements across different industries and geographical areas. The image below, for example, illustrates how the need for increasingly specific formats has led to the creation of a multitude of subsidiary standards under the umbrella of the EDIFACT core standard.

Faced with this ever-growing maze of standards and formats, businesses require the ability to send messages via various protocols and convert messages easily between multiple different formats. Given most businesses have only minimal in-house EDI expertise, it’s no surprise that the technical effort involved in automating the conversion between message formats is one of the most common hurdles on the path to EDI supply chain success.
 

Hurdle 2: Technology

Thanks to recent innovations such as APIs and common import and export interface standards of ERP systems (e.g. based on XML or JSON), businesses have ostensibly never been better positioned to achieve widespread supply chain automation.

Unfortunately, however, many businesses are hampered by extremely complicated legacy IT landscapes and are therefore unable to experience the benefits of streamlined EDI. As illustrated by the diagram below (which shows the genuine IT landscape of a large retailer pre-upgrade), often legacy systems include several separate information silos and connections to multiple service providers. With no central governance and such a wealth of areas where errors could occur, internal teams are often scared to touch anything in case they disrupt or break mission critical processes.

Similarly, some ERP systems are so basic that they are unable to exchange structured files. This capability must therefore be implemented before EDI functionality can be integrated.

Hurdle 3: Processes

Whilst selecting middleware that can handle your business’s technical requirements is obviously important, even more important is establishing the right processes, as without these lasting success is impossible. Though integration admittedly requires expert knowledge, the technical aspect of integration is often the easiest part, with Gartner noting that:

“Only 5% of the interface is a function of the middleware choice. The remaining 95% is a function of application semantics.”

Successful EDI supply chain automation relies on efficient processes. For example, monitoring and support processes are essential if errors are to be identified and resolved before they impact partners.

Generally, successful EDI processes rely on the following key factors:

• Deep application and domain know-how of the business involved
• Technical capabilities
• Available resources
• Project management skills
• Project management support (e.g. onboarding tools)

Hurdle 4: Legal requirements

In an effort to save costs and gain more transparency regarding B2G invoices, many governments have introduced legislation dictating how companies should format and transmit structured electronic invoices (a subject we cover in detail in our e-invoicing white paper). Since April 2020, the majority of European government bodies have been required to accept electronic invoices. Moreover, many countries are seeking to make all B2B and B2G e-invoicing mandatory in an attempt to reduce the so-called VAT gap between expected and collected VAT revenues.

Given the geographic reach of most EDI supply chains and the pace at which e-invoicing legislation in particular is being created and amended, staying on top of regulations is no easy task. Non-compliance with regulations is not an option, however, as it can bring large fines.

If you want to stay on top of e-invoicing regulations, why not sign up to our E-invoicing Updates Newsletter? By doing so you’ll get all the most important e-invoicing updates and helpful e-invoicing assets direct to your inbox every two months!

Want more information on how to overcome these hurdles?

This article is a snippet from our white paper Unlocking the Secrets to Successful EDI Integration. In this paper we explore the development of ERP systems, what makes an EDI supply chain resilient, how to avoid common integration headaches, the benefits of full EDI integration and how to ensure your integration project is a success.

Download your copy of “Unlocking the Secrets to EDI / ERP Integration Success” and find out how you can implement (and benefit from) a solution that is able to overcome all four of the hurdles discussed in this article, simply fill in your details.

Alternatively, if you have any questions about supply chain automation or anything else EDI related, feel free to get in touch! We are always happy to help!

Der Beitrag EDI Supply Chain Automation – The Four Main Hurdles erschien zuerst auf ecosio.

In this article we will look specifically at the four most commonly used EDI protocols: AS2, OFTP2, HTTP and REST APIs.

What is an EDI protocol?

An EDI protocol describes and defines the exchange of data between computers and is used by the communication software/application. In essence each protocol is like a separate language, as unless the trading partners are using a VAN, the computers of both parties must use the same protocol in order to communicate. 

The chosen protocol also determines the level of message encryption, what software and hardware will be required and the ease with which transmissions can be received (i.e. whether both sides’ machines have to be online at the same time for message exchange to occur or not).

Although EDI can theoretically be conducted between two partners via any electronic method capable of transmitting the relevant information, the vast majority of EDI today is conducted over the internet. With the emergence of new technology came the need for standardised protocols. Naturally, over the past few decades the number of these protocols has increased. Thankfully, however, most supply chain organisations today use one of the following exchange channels:

HTTP

First established in 1991, HTTP, or Hypertext Transfer Protocol, is a well-known and popular file transfer protocol. Since its inception four subsequent updates have been released, with the fifth and latest (confusingly called version 3.0) having come out in 2018.

As it only requires a web browser and no additional installation, HTTP constitutes a simple method of completing person to server and person to person file transfers. As anyone who uses the internet is likely to recognise, HTTP resources can be easily located on the network through URLs (or Uniform Resource Identifiers).

The downside of HTTP’s simplicity is the lack of security it offers, however. Although not as prone to firewall issues as File Transfer Protocol (FTP), HTTP is unable to secure data or meet regulatory measures. Due to the security disadvantage plain HTTP is therefore not recommended and at least the use of HTTPS with TLS (transport layer security) should be considered. Similarly, as HTTP doesn’t offer users the ability to receive receipts automatically, it is lacking when it comes to message traceability.

Advantages of HTTP

• Simple to implement
• Ease of use (only requires a web browser)
• Less prone to firewall issues than other protocols due to standard port range

Disadvantages of HTTP

• Not very secure
• No process traceability

AS2

AS2 (or Applicability Statement 2) rose in popularity drastically after the turn of the millennium following the move by Walmart to require its suppliers to use it. Many other large retailers followed suit, meaning AS2 quickly became the most popular EDI protocol across many industries for point-to-point connections.

Unlike many other protocols, AS2 was developed specifically for B2B document exchange. As a result it offers several advantages over HTTP, including better security and the ability for acknowledgements and transactions to happen in real time. 

AS2 uses the HTTP(S) protocol to send EDI messages through an encrypted tunnel. In a standard AS2 message files are transmitted as ‘attachments’. All file formats can also be handled and messages can be signed to provide authentication if required. As virtually no ERP system offers inbuilt AS2 capability, however, this must be integrated separately. To do this requires detailed knowledge and can lead to long troubleshooting if the administrator is not well versed with AS2 and its functionalities.

In order to improve traceability AS2 requires receipts, or Message Disposition Notifications (MDNs) to confirm message delivery/receipt. In contrast to AS1 and AS3 protocols, AS2 offers multiple MDN return options, including the ability to return synchronous or asynchronous MDN..

Thanks to its compliance with the Health Insurance Portability and Accountability Act of 1996 (HIPAA), AS2 is particularly popular in the healthcare industry today. 

Advantages of AS2

• No limit on the amount/size of data you can exchange
• As long as your organisation’s server is live, so is your AS2 connection
• Ability to exchange all file formats
• No yearly or transaction fees
• Possible via point-to-point or indirectly via a VAN
• Widespread adoption throughout EDI users

Disadvantages of AS2

• Requires integration of separate application
• Requires specific AS2 knowledge to setup, maintain and troubleshoot 

OFTP2

Like AS2, OFTP, or ODETTE File Transfer Protocol, was specifically designed for B2B document exchange by the Organisation for Data Exchange by Tele Transmission in Europe (ODETTE) in the mid 1980s. 

In 2007, the OFTP2 protocol was developed specifically to be used over the internet. This update included important improvements over OFTP such as improved data security (via exchange of digital certificates) and the capacity for high compression.

In addition to allowing for very secure exchange of high volumes of data via dedicated servers, OFTP2 is remarkably simple to use compared to other protocols, with only 14 commands.

Crucially, unlike with AS2, with OFTP it is possible to push and pull information (rather than just pushing). It also gives the user the ability to request signed receipts, further improving data security.

For temporary issues, OFTP2 offers transmission restarts. This is preferable to the alternative method of causing an error and aborting the session, which in turn requires the message to be resent in a following session.

OFTP2 is widely used in the automotive industry in Europe, though is also popular across retail, manufacturing, banking and government industries among others.

Advantages of OFTP2

• Simple to use
• Allows for high-volume data exchange (up to 9 Petabytes)
• Ability to push and pull messages
• Highly secure
• Automatic file restart
• Widespread adoption throughout process and automotive industries

Disadvantages of OFTP2

• Requires integration of separate application
• Requires specific knowledge
• Requires all participants to have the capability, which limits its adoption. 
• Requires registration with the ODETTE organisation to receive accredited Odette ID

REST API

An API, or Application Programme Interface, is a combination of rules and mechanisms which dictates how two endpoints are able to interact and share information. 

In theory data exchange via APIs offers a great advantage to businesses as it allows for free access to important B2B data without the need for participation of the partner or availability in the moment of transmission. Once an API has been set up, data can be accessed instantly and whenever convenient. Companies are also able to ensure a high level of security by the ability to restrict access as required. 

As there is little standardisation or restriction surrounding how APIs should be created and used, however, using APIs for B2B data exchange can become difficult the more partners your business has as you effectively have to reinvent the wheel for each connection. Unlike with AS2 or OFTP2, which adhere to predetermined standards, APIs can be used in different ways. For example, one trading partner could request to pull the files, one only accepts pushing files onto his server and yet another a mix of both approaches. Similarly, the semantics of the data being exchanged is also not standardised with data exchange via APIs. Whereas traditional EDI protocols rely on universally accepted document standards (e.g. EDIFACT), this is not the case with APIs, meaning each connection requires additional work. APIs can be very useful for EDI, however, as we explore in more detail in the article “Conducting EDI via API – What are the benefits?”.

REST, which stands for Representational State Transfer, is not a protocol itself, but rather a common method of writing API. APIs themselves lack a uniform structure. Instead structure is created through messaging formats such as JSON. Like AS2, REST relies on HTTP(S). 

Advantages of REST API

• Flexible data exchange either by pulling whenever ready or receiving data immediately via POST
• Widespread knowledge for implementation not limited to EDI users of specific industries, but generally web developers, therefore e.g. enabling could ERP users to directly exchange messages

Disadvantages of REST API

• Lack of standardisation
• Becomes increasingly inefficient as an EDI method the larger your partner network, and often requires an API management layer
• Web programming expertise required if handled in-house

What is the simplest way to send EDI messages via these protocols?

For small and medium-sized suppliers, by far the easiest solution for trading EDI messages is to use an EDI service provider – or VAN (Value Added Network). 

Unfortunately, setting up point-to-point EDI connections is a complicated process and requires a lot of technical expertise. Plus, although certain protocols are favoured by particular industries, as your supply chain grows you will undoubtedly encounter requests to conduct EDI over different exchange channels. 

By selecting a fully managed EDI solution all connection issues are taken care of by your provider. With just a single connection to ecosio’s cloud-based EDI solution (our Integration Hub), your business will be able to send automated messages to your entire partner ecosystem… and any future partners. In addition to allowing you to experience the cost benefits of fully automated EDI, this approach completely removes the responsibility for establishing, monitoring and troubleshooting your B2B message exchange processes, leaving your staff free to focus on more value-adding activities.

Find out more

For more information on EDI protocols and how to get started with B2B data exchange automation, contact us today.

Der Beitrag The Four Most Common EDI Protocols Explained erschien zuerst auf ecosio.

• X.400 is a message transfer protocol similar to e-mail but over a dedicated network, often called a Value Added Network (VAN) in the B2B sector
• X.400 was adopted in 1984 by the CCITT (now ITU) and extended in 1988, with IPM84 networks remaining compatible with newer IPM88 networks
• X.400 has secured a niche in EDI message transmission, supported in Germany as BusinessMail X.400 and still used alongside protocols like AS2
• X.400 networks use mailboxes managed by message stores and transfer via message transfer agents, with structured addressing and improved security from a separate authenticated network

The simple answer to the question “What is X.400?” is that “it is a message transfer protocol – in principle very similar to e-mail, but over a dedicated network rather than the internet”.

Yes, although it is hard to imagine in this day and age, there are other networks that exist parallel to the Internet. In the B2B sector these networks are often called Value Added Networks (or VANs). Of these the X.400 network is probably the best known.

However, there is much more to X.400 than this, as we’ll explore in this article…

A quick review…

Before we go into the technical details, let’s turn back the clock a little: 30 years ago, in 1984, the Comité Consultatif International Téléphonique et Télégraphique (CCITT), now the International Telecommunication Union (ITU), first adopted X.400 as a standard. In 1988, the X.400 standard was extended. This distinction is still noticeable today, as some (sub)networks are still based on the old IPM84 (IPM stands for Interpersonal Messaging Standard, and 84 for the year 1984). Fortunately, however, these are largely compatible with the “newer” IPM88 networks.

The name IPM already indicates that X.400 should initially be positioned as a general mail or messaging system. At the same time, work on an e-mail system was already underway in the context of Internet protocols. The protocols SMTP, POP and IMAP – with the establishment of the Internet in our daily lives – then became established in the late 1990s as global standards for interpersonal messaging, i.e. e-mail. As we will see later, X.400 and Internet e-mail (i.e. SMTP/POP/IMAP) are relatively similar in their topology and mode of operation. However, X.400 is considered a much more complex protocol family, not least because of its additional functionalities.

While X.400 has been completely replaced by Internet e-mail in the interpersonal messaging sector, it has been able to secure a niche existence for the transmission of EDI messages. In Germany, access to the X.400 network is marketed by Deutsche Telekom under the name BusinessMail X.400 – formerly Telebox or Telebox400. Therefore the term Telebox is often still used today as a synonym for an X.400 mailbox. Besides AS2, X.400 is the most used protocol for the transmission of EDI messages today. While AS2 is not yet offered by every company for the transmission of EDI messages, the acceptance of X.400 for the exchange of EDI data can be described as very high.

Due to the not inconsiderable costs for the transmission of the messages – Deutsche Telekom still charges in kilobytes (!) – AS2 connections are increasingly in demand for medium to high message volumes. In order to save costs at low message volumes, it makes sense for SMEs and other supply chain organisations to enlist the help of an EDI provider. As providers purchase a higher volume of messages than individual supply chain businesses, they are able to achieve a better per-message cost. Suppliers can then pass these savings (as ecosio does) onto their customers. But this is a subject for another time. For now, let’s look further into the technical structure and functionality of X.400.

Structure of X.400 networks

As with Internet e-mail, communication takes place via mailboxes. An X.400 mailbox is managed by a Message Store (MS) and identified by a unique address. Messages are transmitted to a mailbox via so-called Message Transfer Systems (MTS) or Message Transfer Agents (MTA) Users access their X.400 mailbox via User Agents – i.e. client software. The following figure provides a simplified overview of the topology of X.400 networks.

X.400 Network Topology

X.400 has a two-tier domain structure: An ADMD is a so-called public service area. ADMDs are usually operated by telecommunications companies – such as Deutsche Telekom. Several ADMDs can exist in a country. A PRMD is a so-called private utility area and is managed independently by companies for better organization. The distinction between ADMDs and PRMDs is an interesting technical detail – but in practice it hardly plays a role any more. Today, a company usually operates a single X.400 mailbox for the exchange of EDI messages or a few if it is a large company and there is a functional separation (e.g. ordering and invoicing processes).

Addressing in the X.400 network

Each X.400 mailbox is identified by a unique address – just like Internet e-mail. X.400 addresses are semantically structured similar to SMTP e-mail addresses, but are somewhat more complex in notation and often longer. Let’s look at the following example to explain the attributes of an address and how to read them:

G=Max; S=sample man; O=sample company; OU=purchasing; A=X400EXAMPLE; C=AT

This example address would identify the X.400 mailbox of Max Mustermann, who works in purchasing at Musterfirma. The mailbox would be hosted directly in the Austrian ADMD X400EXAMPLE – without using a PRMD. The attributes used in this example

• C (Country name)
• ADMD (Administration Management Domain)
• O (Organisation name)
• OU (Organisational Unit Names)
• G (Given name)
• S (Surname)

are used very frequently in addresses. A more detailed overview of the use of addresses in networks is given in RFC 1685 or Harald T. Alvestrand’s X.400 Website (from 1995):

Deutsche Telekom also uses the attributes CN (Common Name) and n-id (User Agent Numeric ID) in its X.400 network (VIAT). Using these attributes can cause problems when addressing from/into an older IPM84 network (e.g. MARK400). The simplest workaround is to simply omit these attributes – the unique identification of the X.400 mailbox in the VIAT network can also be done without CN and n-id (if the parameters G and S are used).

Confirmation of message receipt

One feature – which is almost indispensable when transmitting EDI – is the notification of the sender that a message has been successfully received. X.400 knows two types of notifications.

• Delivery Notification (DN): is generated by the server that places the message in the mailbox of the recipient and transmits to the sender MTA. This means the confirmation is generated by the server (on which the X.400 mailbox is hosted) and transmitted to the sender. The negative counterpart of the DN is the so-called Non-delivery Notification (NDN) and is transmitted to the sender in case of an error.
• Receipt Notification (RN): can be generated by the recipient’s client software and is transmitted to the sender – in practice, the RN is hardly ever requested or supported in automated transmission. The negative counterpart of the RN is the Non-receipt notification (NRN).

The sequence is shown as an example in the following diagram.

X.400 Notifications

Although in practice the Receipt Notification (RN) has hardly any significance, with the receipt of the Delivery Notification (DN) it can already be assumed that the EDI system of the recipient has received the message – at least on a technical level. The sender is then usually informed of any processing problems with the message via e-mail or telephone.

Importance of X.400 for EDI today

The end of X.400 message transmission has often been predicted – not least because of the high costs. But it is still impossible to imagine the EDI sector without it. In addition to the principle (particularly prominent in EDI) “never touch a running system”, the security aspects are a major advantage: After all, it is a separate network, physically separated from the Internet. Every participant is authenticated, which reduces the potential for abuse compared to SMTP/email to a minimum.

If you want to use an X.400 mailbox for your EDI data exchange or would like to reduce your existing X.400 costs, contact us today. We are always happy to answer any questions!

Der Beitrag X.400 – What is it and Why is it Still Around? erschien zuerst auf ecosio.