Applicability Statement 4
AS4 (Applicability Statement 4) is often described as a further development of AS2. Taking a closer look, it quickly becomes clear that its scope of application goes beyond the mere transport of EDI data. In contrast to AS2, AS4 makes it possible to integrate applications that were not originally developed for linking with EDI data exchange components (API communication).
New opportunities for service-driven B2B architectures through integration of API interfaces
For this purpose, the AS2 protocol was connected to the WS-* protocol stack with the help of ebMS (ebXML Messaging Service). In practice, this means that the existing AS2 features have been extended to include the ability to interact with existing web service functionality. API interfaces (Application Programming Interface) can be integrated into the process chains in addition to the EDI functionalities: AS4 is therefore particularly suitable for use in service-focused B2B architectures. B2B meets A2A.
The API definitions to be included can be divided into two subsections. One of these subranges comprises REST in combination with JSON. This variant is mainly used in connection with mobile application scenarios. Nevertheless, some renowned ERP software manufacturers are currently considering using the JSON format in combination with SOAP or web services when designing new ERP interfaces. The idea behind this is that these interfaces can be used not only for integration of EDI processes on the ERP side but also view EDI data exchange merely as a seamless external extension of internal SOA (Service Orientated Architecture) integration. Here, AS4, unlike AS2, is not only used for the pure exchange of EDI data but also extends the IT ecosystem by the possibility of additionally integrating APIs in the form of SOAP-based web services. Web services are therefore de facto APIs at the AS4 level. AS4 is attempting to standardize and simplify web services in order to make them usable for EDI exchange and as integrators for B2B processes.
Transmission of PDF and mixed file types
The combination of SOAP and XML is seen by many users as the means of choice for AS4 implementations. This view does not quite do justice to AS4, since in addition to XML, it is also possible to transport a large number of file types that are also important for EDI transfer. In addition to XML derivatives such as OpenTrans, formats such as EDIFACT, VDA, flat file ASCII/TXT, JSON, HL7, and even PDF and binary data based on AS4 can be exchanged; mixed file types can also be transmitted. Encryption mechanisms can be used but are not mandatory.
AS4 also has a number of features that bring additional advantages for EDI data exchange from a conceptual point of view:
Striving for conformity and standardization
At the technical level, the AS4 MSHs (Message Service Handlers) play an important role in this context: the individual AS4 MSH distinguishes between a user message—the carrier of the actual EDI file—and the signal message,
whereby the signal messages are what makes the AS4 protocol so innovative. In addition to the above-mentioned error management, the PULL requests for the retrieval of EDI messages are also transmitted here. The receipt confirmation is also transmitted at this level. Unlike AS2, however, this is not referred to as an MDN (message delivery notification) but as an AS4 receipt, i.e., a valid confirmation of receipt.
AS4 is clearly striving for standardization to simplify the use of online services for EDI data exchange and B2B integration. In addition to conforming to the OASIS standard, AS4 is therefore also ISO-compliant and Drummond-certifiable.
AS4 not widely used in EDI integration projects to date
In contrast to AS2, AS4 has not yet been able to gain significant acceptance in current EDI integration projects. One of the reasons for this is certainly that AS4 was designed as an open standard in order to be able to generate useful programming extensions more easily than is the case with the AS2 standard published as a globally valid RFC.However, this supposed advantage can quickly lead to increased complexity and resulting expenses at the project level. As the possible applications were deliberately chosen broadly, extensive bilateral agreements often have to be made when defining project details. A similar effect was observed several years ago with the emergence of the first XML formats.
Consequently, the possible applications of AS4 are currently limited to authorities and associations as well as some flagship projects (e.g., CISCO, JEITA, ENTSOG, PEPPOL, IATA).
This post is also available in DE.