SEEBURGER

Wir verstehen uns als Motor der digitalen Transformation Ihres Unternehmens

Behandlung von inhaltlichen Fehlern – EDI und APIs im Vergleich

Comparison of EDI and APIBeim Datenaustausch zwischen Geschäftspartnern können inhaltliche Fehler auftreten. Es genügt schon, dass das Zielsystem eigentlich plausible Daten schlicht nicht richtig interpretiert. Bei EDI als batch-gesteuertem Dateiaustausch erfolgt die Fehlerbehandlung typischerweise auf dem empfangenden System, während bei einer Kopplung über APIs das aufrufende System nur eine Fehlermeldung zurückerhält und für die Fehlerbehandlung selbst verantwortlich ist.

Inhaltliche Fehler im Blick

ERP-Systeme tauschen Daten sowohl mit anderen internen System als auch mit externen Geschäftspartnern aus. Die Datenübertragung erfolgt in der Regel auf dem klassischen Übertragungsweg, d.h. asynchron und über ein Dateiformat wie z.B. SAP-IDocs. Eventuelle inhaltliche Fehler, die sogenannten »Content-Fehler«, müssen dabei aufgrund der Asynchronität zwingend auf dem jeweils empfangenden System behandelt werden. So können SAP-Anwender beispielsweise inhaltliche Fehler in eingehenden SAP IDocs typischerweise selbst korrigieren und die IDocs dann manuell weiterverarbeiten.

Beispielhafte Fehlermeldung eines SAP IDocs mit inhaltlichem Fehler
Beispielhafte Fehlermeldung eines SAP IDocs mit inhaltlichem Fehler

 

Dem gegenüber ermöglichen synchrone APIs dem empfangenden System eine direkte Reaktion in Echtzeit. Anstatt einfach ein IDoc mit fehlerhaftem Inhalt zu akzeptieren und die Fehler anschließend selbst zu behandeln, kann das ERP-System den fehlerhaften Inhalt direkt über die API ablehnen und eine Fehlermeldung an das aufrufenden B2B/EDI-System zurückgeben.

Die folgende Tabelle vergleicht für ein SAP S4\HANA Systems die klassische Übertragungsmethode per SAP IDoc und die Kopplung über die APIs des SAP API Business Hub:

SAP IDocsSAP APIs
ProtokolltRFCHTTP/S
AnrufmusterAsynchroner AufrufSynchroner Aufruf
FormatFlat File (Inhouse)XML oder JSON
FormatbeschreibungSAP format descriptionOpen API standard (Swagger), WSDL
Verzeichnis der FomateSAP-eigene FormatbeschreibungOffener API-Standard (Swagger) , WSDL
Typische Szenarien
  • Batch-getriebene Verarbeitung gebündelter Informationen
  • Datenkonvertierung gebündelter Informationen
  • B2B/EDI Anbindung an externe Trading Partnern über AS2, OFTP2 oder VAN
  • Informationsanfrage modularer Einzelanfragen quasi in Echtzeit
  • Echtzeiteinbuchung in einzelnen Schritten
  • Enterprise Application Integration (EAI)
  • Enterprise Service Bus (ESB)
  • Web-Shop-Anbindung
  • Anbindung von SAP Lösungen, welche durch Zukauf Teil der SAP-Familie wurden, zum Beispiel SAP Ariba SAP SuccessFactors oder SAP Concur
  • Anbindung von Cloud-Systemen wie etwa Sales Force
Behandlung von inhaltlichen FehlernFehlerbehandlung direkt in SAP unter anderem durch die verantwortlichen Fachbereiche
  • Im Falle einer Punkt-zu-Punkt Verbindung auf dem die API aufrufenden System
  • Bei Verwendung einer Integrationsplattform auf eben jener Integrationsplattform

Beispielhafter Vergleich zwischen SAP IDocs und APIs des SAP API Business Hubs

 

Ablauf des API-Aufrufs

Das Zielsystem (Service Provider) gewährt dem aufrufenden System (Service Consumer) Zugriff auf die verfügbaren APIs. Der Service-Consumer fragt den Service anschließend über die entsprechende API beim Service-Provider an und erhält von diesem im Falle eines Fehlers eine synchrone Fehlermeldung zurück. Die Service-Anfrage ist für den Service Provider damit erledigt und der Service Consumer (das aufrufende System) muss sich um die weitere Fehlerbehandlung kümmern.

Der wesentliche Unterschied bei der Umstellung von SAP IDocs auf APIs – oder anders formuliert von asynchronen Aufrufen auf synchrone Service-Anfragen – besteht also darin, dass die Fehlerbehandlung im letzteren Fall durch den Service-Consumer erfolgt – und damit im konkret betrachteten Beispiel außerhalb des SAP ERP-Systems. D.h. alle Werkzeuge, Abfangroutinen und Nutzeroberflächen für die Fehlerbehandlung liegen somit – je nach Weg des API-Zugriffs – entweder direkt auf dem aufrufenden System oder aber auf der gegebenenfalls dazwischenliegenden Integrationsplattform bzw. dem B2B/EDI-System.

Für aufrufende Systeme bedeutet die Umstellung eines bestehenden asynchronen Aufrufs per Datei auf synchrone Service-Anfragen per API deshalb einen nicht unerheblichen Umsetzungsaufwand. Denn neben der rein technischen Umstellung gilt es auch organisatorische Gesichtspunkte zu berücksichtigen. Beispielsweise müssen die beteiligten Fachbereiche der aufrufenden Organisation mit eingebunden und die Fehlerbehandlung mit diesen diskutiert werden.

Für B2B/EDI-Lösungen, die künftig SAP S4\HANA-Systeme über die APIs des SAP API Business Hubs statt wie bisher über SAP-IDocs anbinden sollen, ist das nicht nur eine technische Umstellung, sondern auch eine organisatorische. Für die beteiligten Fachbereiche ändert sich bei der manuellen Fehlerbehandlung zumindest das entsprechende Werkzeug.

Mit SEEBURGER BIS als Plattform für die API-Integration und das API-Management können Fehlerbehandlungen auf API-Strecken vereinheitlicht und gleichzeitig die Komplexität dynamischer API-Umgebungen im Zaum halten gehalten werden – was Zeit und Geld spart. Selbstverständlich unterstützt SEEBURGER alle API-Schnittstellen für SAP S/4HANA (und SAP in der »klassischen Ausführung«).

 

Kontaktieren Sie uns für Informationen, Anwendungsfälle und Anforderungen.

Wir freuen uns hier über Ihre Nachricht.

Von |
Teilen Sie diesen Beitrag, wählen Sie Ihre Plattform!

Über den Autor:

Stefan Hilpp
Stefan Hilpp ist Managing Consultant bei der SEEBURGER AG und seit 1996 im Unternehmen tätig. Dies beinhaltet auch eine mehrjährige Auslandstätigkeit für die Seeburger Inc. (USA). Ebenso verfügt er über langjährige Erfahrung als Projektleiter in internationalen Projekten im Umfeld SAP XI, SAP PI, SAP PO. Er ist gelernter Dipl.-Ingenieur (BA) im Bereich Elektrotechnik und hat einen MBA-Abschluß im Bereich »International Management Consulting«. Sein aktueller Tätigkeitsbereich bei SEEBURGER umfasst die Bereiche Projektleitung, Pilotprojekte (POC) und PreSales-Unterstützung für die »Business Integration Suite«. Seit mehreren Jahren hat er außerdem einen Lehrauftrag »Business Integration Consulting« im Masterstudiengang Logistik an der Hochschule Ludwigshafen.