AS4 (Applicability Statement 4) wird oft als Weiterentwicklung von AS2 beschrieben. Genauer betrachtet wird schnell deutlich, dass der Anwendungsbereich über den reinen Transport von EDI-Daten hinausgeht: AS4 ermöglicht im Gegensatz zu AS2 die Einbindung von Applikationen, die ursprünglich gar nicht für die Verknüpfung mit Komponenten des EDI-Datenaustauschs entwickelt wurden (API-Kommunikation).

Für diesen Zweck wurde das AS2-Protokoll unter Zuhilfenahme von ebMS (ebXML Messaging Service) mit dem WS-*-Protokollstack verbunden. In der Praxis bedeutet dies, dass die bestehenden AS2-Features um die Möglichkeit der Interaktion mit bestehenden WebService-Funktionalitäten erweitert wurden. API-Schnittstellen (Application Programming Interface) können zusätzlich zu den EDI-Funktionalitäten in die Prozessketten eingebunden werden: AS4 eignet sich somit insbesondere zum Einsatz bei serviceorientierten B2B-Architekturen. B2B meets A2A.

Die einzubindenden API-Definitionen können in zwei Teilbereiche gegliedert werden. Einer dieser Teilbereiche wird von REST in Kombination mit JSON gebildet. Diese Variante wird hauptsächlich in Verbindung mit mobilen Anwendungsszenarien eingesetzt. Gleichwohl überlegen momentan einige namhafte ERP-Softwarehersteller, bei dem Design neuer ERP-Schnittstellen das JSON-Format in Kombination mit SOAP bzw. Web Services einzusetzen. Die Idee dahinter ist, dass diese Schnittstellen nicht nur zur ERP-seitigen Integration von EDI-Prozessen eingesetzt werden können, sondern den EDI-Datenaustausch lediglich als nahtlose externe Erweiterung der internen SOA (Service Orientated Architecture) -Integration ansehen. AS4 dient in diesem Zusammenhang anders als AS2 also nicht nur dem reinen EDI-Datenaustausch, sondern erweitert das IT-Ökosystem um die Möglichkeit, zusätzlich API’s in Form von SOAP-basierten Web Services einzubinden. Web Services sind auf AS4-Ebene also de facto als API’s zu betrachten. AS4 versucht dabei eine Standardisierung und Vereinfachung von Web Services anzustreben, um diese für den EDI-Austausch und als Integratoren für B2B-Prozesse nutzbar zu machen.

Als Mittel der Wahl für AS4-Implementierungen wird von zahlreichen Anwendern die Kombination aus SOAP und XML angesehen. Diese Sichtweise wird AS4 nicht ganz gerecht, da neben XML der Transport einer Vielzahl auch für den EDI-Transfer wichtiger Dateitypen möglich ist. Zusätzlich zu XML-Derivaten wie OpenTrans können Formate wie EDIFACT, VDA, Flatfile ASCII/TXT, JSON, HL7, aber auch PDF und Binärdaten auf Basis von AS4 ausgetauscht werden; die Übertragung gemischter Dateitypen ist ebenfalls möglich. Verschlüsselungsmechanismen können dabei zum Einsatz kommen, sind aber nicht obligatorisch.

AS4 weist darüber hinaus eine Reihe von Features auf, die auch in konzeptioneller Hinsicht zusätzliche Vorteile für den EDI-Datenaustausch mit sich bringen:

Auf technischer Ebene kommt in diesem Kontext den AS4 MSH’s (Message Service Handler) eine wichtige Bedeutung zu: der einzelne AS4 MSH unterscheidet zwischen einer User Message – Träger der eigentlichen EDI-Datei – und der Signal Message.

Die Signal Messages kennzeichnen den innovativen Teil des AS4-Protokolls. Neben dem o.a. Fehlermanagement werden hier auch die PULL Requests für den Abruf von EDI-Nachrichten übermittelt. Zudem wird auf dieser Ebene die Empfangsbestätigung übertragen. Anders als bei AS2 spricht man in diesem Zusammenhang jedoch nicht von einer MDN (Message Delivery Notification) sondern von einem AS4 Receipt, also einer validen Empfangsbestätigung.

AS4 bemüht sich sichtlich um eine Standardisierung, um den Gebrauch von Web Services für den EDI-Datenaustausch und die B2B-Integration zu vereinfachen. Neben der Konformität mit dem OASIS-Standard ist AS4 daher auch ISO-konform und Drummond-zertifizierbar.

Im Gegensatz zu AS2 hat AS4 bis heute keine nennenswerte Verbreitung bei aktuellen EDI-Integrationsprojekten erlangen können. Einer der Gründe hierfür ist sicherlich, dass AS4 als offener Standard konzipiert wurde. um leichter nützliche programmtechnische Erweiterungen generieren zu können, als dies bei dem als weltweit gültigen RFC veröffentlichten AS2-Standard der Fall ist. Dieser vermeintliche Vorteil kann auf Projektebene jedoch schnell zu erhöhter Komplexität und daraus resultierenden Aufwänden führen. Da die Anwendungsmöglichkeiten bewusst breit gewählt sind, müssen bei der Definition von Projektdetails oftmals umfangreiche bilaterale Abreden getroffen werden. Ein ähnlicher Effekt war vor etlichen Jahren auch beim Aufkommen der ersten XML-Formate zu beobachten.

Folgerichtig sind die Anwendungsbereiche von AS4 zurzeit auf Behörden und Verbände sowie einige Leuchtturmprojekte beschränkt (z.B. CISCO, JEITA, ENTSOG, PEPPOL, IATA).