What Happens in an AS2 Exchange

This article outlines the flow of secure EDI communication between you and your trading partners while using AS2. You will learn the key steps and technologies involved. In ArcESB, the AS2 Connector makes it easy to automate these steps and work with these technologies.

For a guide to getting started with AS2 in ArcESB, see the "Connectors" chapter of the help documentation.

AS2 at a Glance

For all of its complexity in terms of its applications, AS2 boils down to two basic parts: A document is sent from an AS2 sender to an AS2 receiver via HTTP, which is a very flexible client-server protocol that serves as the backbone of the World Wide Web. The receiver acknowledges the transfer by providing the sender with a receipt.

The following illustration demonstrates the different steps that are taken in further detail.

Step 1: EDI Document Preparation

In an AS2 exchange, any type of document can be sent. Typically, however, most trading partners will implement a standard for specific document types.

The most common document types are EDI X12 documents (.x12 or .edi files), EDIFACT documents (.edifact files), or XML files (.xml files) The preparation of the document takes place before the AS2 communication begins.

EDI (Electronic Data Interchange) is a general term for the transfer of documents between trading partners and the standards that are adhered to therein. It is also represented as EDIINT (EDI over the Internet).

Step 2: AS2 Packaging

The AS2 document is prepared for sending. This consists of three types of document transformation. If the document consists of data that is compressible (i.e., not binary data), the document may be compressed using the zlib compression algorithm in order to reduce the size of the transported data. The data is typically signed using the private key of the sender in order to ensure the sender's identity as the creator of the document (usually with the SHA-1 signing algorithm). Finally, the data may be encrypted using the receiver's public key so only the trading partner will be able to read the data (usually using the 3DES encryption algorithm). This step may be skipped if the data is going to be delivered by a secure transport mechanism, such as HTTPS.

S/MIME is the set of standards used for the encryption and signing of a message/document. It not only governs the functions of signing and encryption, but it also provides standards for the formatting of the final message so that a compliant reader will be able to easily identify the structure of the message.

Step 3: HTTP/S Delivery

The prepared document is then delivered over the Internet to the trading partner's Web Server (over the HTTP or HTTPS protocol).

Step 4: AS2 Unpackaging

The receiver of the prepared document then unpackages to retrieve the EDI document. If the data was encrypted, the prepared document is then decrypted using the receiver's private key. If the data was signed, the signature on the document is verified using the sender's public key in order to ensure the identity of the sender. If the document has been compressed, the prepared document is then decompressed in order to produce the original EDI document.

Step 5: EDI Processing

At this point, the AS2 receiver passes the unpackaged EDI document to any back-end process that handles the data in order to perform any additional business logic. Now, the EDI document is parsed, and the receiver may even initiate a new AS2 transaction where the roles of sender and receiver are reversed. In particular with EDI-X12 documents, a 997 Functional Acknowledgement is often sent to the original sender in order to signify that the original EDI document was processed in the back-end business logic.

Step 6: MDN Reply

The receiver sends back an MDN (Message Delivery Notification) to the sender, and this MDN is- in most cases- signed with the receiver's private key. The MDN is a receipt that is returned in an AS2 exchange, and the MDN is used to report to the sender what was received and whether or not it was successfully received.

The MDN contains information about whether or not the document was successfully unpackaged. The MDN also contains a message digest that is calculated over the received payload. The MDN is then returned to the sender in one of two ways, and the respective ways depend on how the sender asked for the MDN to be delivered. In a synchronous transaction, the receiver returns the MDN in the HTTP reply from the receiver's Web server. In an asynchronous transaction, the HTTP reply contains a simple acknowledgement (200 OK), and the MDN is returned over a separate connection. This is usually the case if the unpackaging of the AS2 transmission is expected to take a while.

Step 7: MDN processing

When the sender receives the MDN from the receiver, the MDN signature will be verified if the MDN was signed. The status of the MDN will be checked to see if the receiver was successful in processing the transaction or if they encountered an error that was reported in the MDN. Finally, the message digest reported in the MDN is matched against a message digest that was calculated over the EDI data that was sent. With a signed MDN, the sender can verify that the receiver of the message received the entire contents of the EDI document as it was intended to be delivered.

Next Steps

You can use the ArcESB sample AS2 Connector as a template for setting up AS2 with your trading partner. You can also find videos and walkthroughs in the KB, including how to connect AS2 to your back-office processing.