EDI transmission via AS2
AS2 (Applicability Statement 2) is a variant of EDIINT (EDI over the internet). This is a specification for EDI data exchange that is tasked with sending and receiving EDI data via a secure connection.AS2 works with a kind of “envelope” in which EDI data formats (EDIFACT, XML, VDA, ANSI X12, TRADACOM, ASCII TXT, etc.) are embedded. The data are transmitted via http/https.
Secure EDI message transport through AS2 encryption
The EDI message to be transmitted is provided with an electronic signature (not a qualified digital signature as defined by the German Signature Act), encrypted, and sent directly to the EDI partner. In contrast to X.400, there is no provider between two EDI systems here; the partners communicate directly with each other. To ensure that the recipient has received the EDI document in unaltered form, decompressed it without errors, and decrypted it, the received EDI document is checked for originality and integrity. Subsequently, a confirmation message (Message Delivery Notification = MDN) is automatically returned to the sender of the EDI message.
Unambiguous error messages during AS2 data exchange
For each EDI transmission file, an MDN confirmation message is automatically generated by the receiving AS2 tool and returned to the EDI sender. If an AS2/MDN confirmation is missing, the sender’s AS2 tool automatically generates an error message. This error handling, which is integrated at the protocol level, is a core component of the AS2 data exchange and allows the unique assignment of a transmission error to the EDI transaction concerned. In combination with the no-fee processing and the instant EDI data transmission, this functionality is perceived by most users as one of the major advantages of AS2.
AS2 point-to-point connection; signed, encrypted, sent packed in an “envelope”, and with automatic confirmation of receipt (MDN = Message Delivery Notification)
EDI with AS2 has advantages!
Countless retail groups have switched their EDI data exchange from the X.400 protocol to AS2 for various reasons (provider-side transaction costs in X.400 data exchange, Telekom FileWork problem),and the popularity of the AS2 protocol is also increasing among the companies in our customer portfolio that previously communicated primarily via X.400.
The new X.400-MessageGateway (client-to-server coupling via sFTP with Telekom’s X.400 systems) now offers an alternative to the error-prone X.400 access program FileWork. However, for cost and other reasons, large market participants (Markant, OBI, etc.) are increasingly switching to the AS2 protocol.
The advantages are obvious: besides avoiding provider costs, the AS2 protocol includes a whole array of security improvements (e.g., acknowledgment of the EDI document exchange via MDN (= Message Delivery Notification), active encryption of the data communication, etc.) and is thus a process-relevant improvement of EDI transactions with regard to synchronous EDI data transmission, or rather a preliminary stage of the inclusion of EDI-relevant third-party applications.
AS2 variants require flexible EDI tools
It is interesting to note that AS2 communication in the EDI context is now no longer limited to the retail sector but is also becoming increasingly relevant for globally active suppliers, in particular, such as in EDI communication with US companies.In this context, the general standard is no longer classified as AS2 alone. Instead, there are more and more partner-specific AS2 variants which deviate from the norm. The bandwidth ranges from various AS2 protocol commands (get, push, pull, put, etc.) to encryption cascading within the AS2 modules involved.
AS2 certificate change made easy
In EDI practice, the EDI partners involved therefore frequently need to make change requests. A classic request scenario: the AS2 certificate change. Such a change is justified by the limited term of the AS2 certificates required for encryption. Each participant uses their own certificate, which has an AS2 certificate term of one to a maximum of five years. Due to this AS2 term limitation—in addition to the expiration of the user’s own certificates —the AS2 certificate changes of the connected EDI partners also have to be tracked.
Even minor changes in the IT infrastructure of a company can lead to the need for a number of additional EDI-specific adjustments, such as IP addresses of the AS2 modules, AS2 server paths, AS2 transmission protocols (http or https), etc. During post-processing, AS2 connection tests are usually mandatory to confirm the validity of the changes made in EDI practice as well. Many EDI partners also use AS2 production and test systems with their own EDI parameters, which multiplies the effort required for a changeover.
Softzoll meets all AS2 requirements
Frequently, it is not possible to map diverse variants for integrating modern EDI scenarios without a proprietary AS2 module, because the respective EDI partners cannot be implemented unless it is possible to create connection-specific parameters on byte level.
Softzoll recommends taking a holistic view of EDI communication requirements. This means that the objective of our products and developments always includes the mapping of all conceivable forms of EDI data communication; in case of doubt; this should even go so far as to cover customer-specific and other AS2 EDI specifications which do not conform to the AS2 standards. Softzoll supplies all AS2 components to be operated with the relevant functionality and flexibility. The broad, corresponding technical EDI basis as well as Softzoll’s corresponding practical experience are a prerequisite and guarantor for the successful implementation of your EDI project for complex requirements such as these.
Softzoll Communicator—the free AS2 tool
The Softzoll Communicator offers our customers the possibility to connect with our Berlin EDI data center (ISO 27001 certified)through an EDI transmission protocol of their choice (e.g., AS2, OFTP2, FTP/sFTP). The client can also be used to connect third parties via any communication path (AS2 routing of data etc.).