Behandlung von inhaltlichen Fehlern – EDI und APIs im Vergleich
Beim 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.
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 S/4HANA Systems die klassische Übertragungsmethode per SAP IDoc und die Kopplung über die APIs des SAP API Business Hub:
SAP IDocs | SAP APIs | |
Protokoll | tRFC | HTTP/S |
Anrufmuster | Asynchroner Aufruf | Synchroner Aufruf |
Format | Flat File (Inhouse) | XML oder JSON |
Formatbeschreibung | SAP format description | Open API standard (Swagger), WSDL |
Verzeichnis der Fomate | SAP-eigene Formatbeschreibung | Offener API-Standard (Swagger) , WSDL |
Typische Szenarien |
|
|
Behandlung von inhaltlichen Fehlern | Fehlerbehandlung direkt in SAP unter anderem durch die verantwortlichen Fachbereiche |
|
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 S/4HANA-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«).
> Lesen Sie mehr zur Integration von SAP S/4HANA
Vielen Dank für Ihre Nachricht
Wir freuen uns über Ihr Interesse an SEEBURGER
Haben Sie Fragen oder Anmerkungen?
Wir freuen uns hier über Ihre Nachricht.
Ein Beitrag von: Stefan Hilpp
Stefan Hilpp ist Managing Consultant bei SEEBURGER 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.