SAP Schnittstellen: welcher Weg für welchen Ablauf passt

Welche Schnittstellen bietet SAP für ECC und S/4HANA?

SAP stellt für S/4HANA laut eigener Dokumentation zwei API-Typen bereit: OData-Schnittstellen und SOAP-Schnittstellen. OData wird in den Versionen 2 und 4 unterstützt, SOAP in den Versionen 1.1 und 1.2. Beide gelten für S/4HANA On-Premise ebenso wie für die Public Edition.

Daneben gibt es die klassischen Wege, die schon im ECC-System existieren: BAPIs, RFC-fähige Funktionsbausteine und IDocs. SAP schreibt, dass S/4HANA alle APIs unterstützt, die in SAP ERP verfügbar sind. Ausgenommen sind APIs für Funktionen auf der Simplification List und RFC-Bausteine, die in SAP-Hinweis 2259818 aufgeführt sind.

Der dritte Baustein sind Business Events. Ändert sich ein Objekt in S/4HANA, etwa ein Auftrag, kann das System ein Ereignis an einen Broker wie SAP Event Mesh senden. Andere Systeme abonnieren dieses Ereignis und reagieren, ohne das ERP ständig abzufragen.

OData und SOAP: die Web-Schnittstellen von S/4HANA

OData ist der Standardweg, um einzelne Datensätze in S/4HANA zu lesen und zu ändern. Jede Ressource hat eine eigene URL, und die HTTP-Methode bestimmt die Aktion: GET liest, POST legt an, PUT oder PATCH ändert, DELETE löscht. Welche Methoden ein Service zulässt, legt der jeweilige Anwendungsfall fest.

Für Automatisierungen sind drei Funktionen aus der SAP-Dokumentation wichtig. Mit $batch lassen sich mehrere Operationen in einer Anfrage bündeln, die Zahl der Operationen kann je Service begrenzt sein. Mit $select, $filter, $top und $skip holen Sie nur die benötigten Felder und große Ergebnismengen in Teilen. ETags verhindern, dass zwei gleichzeitige Änderungen sich gegenseitig überschreiben: Stimmt der mitgeschickte Stand nicht mehr, lehnt der Server die Änderung ab.

SOAP-Schnittstellen arbeiten mit XML-Nachrichten in einem festen Umschlag aus Header und Body. Für asynchrone SOAP-Kommunikation sichert die SAP-Infrastruktur laut SAP die Zustellung genau einmal ab, über WS-RM oder das SAP-eigene SAP-RM. Für synchrone Aufrufe bietet SAP NetWeaver ein Verfahren, das doppelte Ausführung verhindert; solche Webservices nennt SAP idempotent.

Im On-Premise-System muss ein OData-Service aktiviert sein, bevor er erreichbar ist. SAP beschreibt dafür die Transaktion /IWFND/MAINT_SERVICE auf dem Front-End-Server. In der Public Edition läuft der Zugang über Kommunikationsvereinbarungen, dazu mehr unten.

• OData V4 verbessert laut SAP Verarbeitungszeit und Ressourcenverbrauch gegenüber V2.
• Die vollständige Spezifikation eines OData-Service und die WSDL eines SOAP-Service lassen sich im SAP Business Accelerator Hub herunterladen.

BAPI, RFC und IDoc: die klassischen Wege

BAPIs sind laut SAP Methoden von SAP-Geschäftsobjekten, die im Business Object Repository abgelegt sind und als RFC-fähige Funktionsbausteine im Function Builder liegen. Sie arbeiten auf der Geschäftsebene: Ein externes Programm legt zum Beispiel einen Beleg an, ohne die Tabellen dahinter zu kennen. Für einen Vorgang mit direkter Rückmeldung nutzt man laut SAP meist den synchronen Aufruf sRFC.

RFC ist das Protokoll, über das ein externes System Funktionsbausteine im SAP-System aufruft. SAP empfiehlt ausdrücklich, nur freigegebene RFC-Bausteine zu nutzen, damit die Schnittstelle stabil bleibt. Ob ein Baustein freigegeben ist, steht in Transaktion SE37 auf der Registerkarte Attribute.

IDocs sind laut SAP das Standardformat für den elektronischen Datenaustausch. Ein IDoc enthält einen Steuersatz, Datensätze in Segmenten und Statussätze; der letzte Verarbeitungsstatus steht im Steuersatz. Die Kommunikation ist immer asynchron. Der Transport über tRFC führt einen Aufruf genau einmal aus und hält ihn in einer Warteschlange, wenn der Empfänger nicht erreichbar ist. Mit qRFC lässt sich zusätzlich die Reihenfolge sichern. Asynchrone BAPI-Aufrufe laufen laut SAP über ALE, wobei zusätzliche IDoc-Schnittstellen erzeugt werden.

Für ein ECC-System sind diese drei Wege oft die naheliegende Anbindung. Für S/4HANA bleiben sie nutzbar, sind aber vor einem Umstieg gegen die Simplification List und SAP-Hinweis 2259818 zu prüfen.

Ein IDoc-Typ kann mehrere verwandte Nachrichtentypen tragen. SAP nennt als Beispiel ORDERS01 für Bestellung (ORDERS) und Auftragsbestätigung (ORDRSP).

Wie finden Sie die passende SAP API im Business Accelerator Hub?

Der SAP Business Accelerator Hub unter api.sap.com ist der Katalog, in dem SAP alle öffentlich verfügbaren APIs für S/4HANA veröffentlicht. SAP beschreibt ihn als Webanwendung, um APIs zu finden, zu erkunden und zu testen. Für S/4HANA On-Premise und für die Public Edition gibt es getrennte Pakete, weil sich Umfang und Version unterscheiden.

Für eine Planung sind vier Angaben je API entscheidend. Erstens das Release: Über die Auswahl Select Release sehen Sie, ob die API zu Ihrem Stand passt. Zweitens die Version aus Haupt-, Neben- und Patchnummer; eine neue Hauptversion bedeutet laut SAP eine inkompatible Änderung. Drittens die unterstützten Anmeldeverfahren. Viertens der Freigabestatus: SAP führt eine Deprecation Policy und kündigt veraltete APIs im What's-New-Dokument des jeweiligen Release an.

Der Hub zeigt den neuesten Stand; ein System auf älterem Feature Package kann abweichen, prüfen Sie die API also auch im eigenen System. Freigegebene APIs sollen laut SAP eine stabile, langfristige Grundlage sein, eine eigene Z-Schnittstelle hat diese Zusage nicht. SAP ordnet Erweiterungen seit 2025 in die Stufen A bis D ein: A nutzt nur freigegebene Schnittstellen, B zusätzlich klassische APIs, Schreibzugriffe auf SAP-Tabellen gehören zu D. Daraus folgt die Reihenfolge: freigegebene API, dann klassische API, Eigenentwicklung nur mit Begründung. Mehr zu Clean Core steht auf der Seite zum S/4HANA-Umstieg.

• API im Hub für das eigene Produkt und Release suchen, nicht nur nach Namen.
• Status prüfen: freigegeben oder als veraltet gekennzeichnet.
• Spezifikation herunterladen und Pflichtfelder für Ihren Ablauf markieren.
• Mit der SAP-Basis klären, ob der Service im eigenen System aktiv ist.

Was unterscheidet die Anbindung in Public Cloud, Private Cloud und On-Premise?

In der S/4HANA Cloud Public Edition stellt SAP OData- und SOAP-APIs bereit, und der Zugang läuft immer über eine Kommunikationsvereinbarung. Sie basiert auf einem Kommunikationsszenario, das die ein- und ausgehenden Services eines Geschäftsprozesses bündelt. Dazu gehören ein Kommunikationssystem für den Partner und ein technischer Kommunikationsbenutzer für die Anmeldung. Die Service-URL steht danach im eingehenden Teil der Vereinbarung.

In S/4HANA On-Premise und in der Private Edition aktiviert die SAP-Basis OData-Services selbst, und die klassischen Wege BAPI, RFC und IDoc stehen zusätzlich zur Verfügung, soweit sie nicht durch Simplification List oder SAP-Hinweis 2259818 ausgeschlossen sind. Das gibt mehr Möglichkeiten, aber auch mehr Verantwortung für die Auswahl stabiler Schnittstellen.

Ein ECC-System ist die technische Basis für BAPI, RFC und IDoc. Steht der Umstieg bevor, gehört die Logik außerhalb des ERP, damit beim Wechsel nur die Schnittstelle getauscht wird.

Die Zeile zu ECC stützt sich auf die SAP-Aussage, dass S/4HANA die APIs aus SAP ERP weiterführt. Welche Web-Services Ihr ECC-Stand konkret anbietet, prüft Ihre SAP-Basis im System, etwa in SOAMANAGER.

Wie meldet sich ein externes System an SAP an?

Laut SAP unterstützt jede API eigene Anmeldeverfahren; dokumentiert sind Basic mit Benutzer und Passwort, x509-Zertifikate, OAuth 2.0 und Single Sign-on über SAML. Für eingehende Kommunikationsbenutzer in der Public Edition nennt SAP zusätzlich Principal Propagation und OAuth 2.0 mit mTLS.

Für Abläufe ohne angemeldeten Menschen ist ein technischer Benutzer mit Zertifikat oder OAuth 2.0 der übliche Weg. Basic-Anmeldung ist einfach, legt aber ein Passwort in der Konfiguration ab, das gepflegt und gewechselt werden muss. Principal Propagation reicht dagegen die Identität des angemeldeten Menschen an SAP durch, sodass dessen eigene Berechtigungen gelten.

Unabhängig vom Verfahren gilt: Der technische Benutzer bekommt nur die Rechte, die der Ablauf braucht. Ein Benutzer, der Lieferantenrechnungen anlegt, braucht keine Rechte auf Personaldaten. Die SAP-Fehlermeldung 403 zeigt laut SAP genau diesen Fall an: Der Benutzer ist nicht berechtigt, die angeforderten Daten zu lesen oder die Aktion auszuführen.

Welche SAP-Schnittstelle passt zu welchem Ablauf?

Der passende Weg ergibt sich aus zwei Fragen: Braucht der Ablauf sofort eine Antwort, und kommt er einzeln oder in großer Menge? Einzelne Vorgänge mit Rückmeldung passen zu OData oder BAPI per sRFC. Mengen und Partneraustausch passen zu IDoc oder asynchronem SOAP. Reaktionen auf Änderungen passen zu Business Events.

Die Tabelle zeigt die naheliegende Wahl je Ablauf. Sie ersetzt nicht die Prüfung im Business Accelerator Hub, ob für Ihr Release eine freigegebene Schnittstelle existiert.

Für Berichte über mehrere Gesellschaften lohnt der Blick auf die Seite zum ERP-Reporting. Wie der Rechnungseingang fachlich geprüft wird, bevor er in SAP landet, steht auf der Seite zum Rechnungseingang.

Indirekter Zugriff und Digital Access: der Lizenz-Prüfpunkt

Jede Schnittstelle zu SAP ist auch eine Lizenzfrage, denn laut SAP erfordert jede Nutzung der Software eine passende Lizenz, unabhängig vom Zugriffsweg. In einem Leitfaden von April 2018 nennt SAP ausdrücklich BAPIs, RFC, IDocs und Webservices als technische Wege, die daran nichts ändern. Als indirekten Zugriff beschreibt SAP die Nutzung über eine Nicht-SAP-Software zwischen Anwender und ERP, etwa ein eigenes Frontend oder eine Drittanwendung.

Mit dem Modell Digital Access hat SAP 2018 eine dokumentbasierte Lizenzierung eingeführt. Laut einem aktuellen SAP-Learning-Kurs zählt dabei das Anlegen von Belegpositionen in neun Dokumenttypen, darunter Verkauf, Einkauf, Rechnung und Fertigung; Lesen, Ändern und Löschen zählen nicht. Unbeaufsichtigte Bots von Drittanbietern brauchen laut Kurs eine Digital-Access-Lizenz. Gemessen wird für S/4HANA und die Private Edition mit dem Report RSUVM_DAC.

Welches Modell für Sie gilt, steht in Ihrem SAP-Vertrag, nicht in dieser Übersicht. SAP weist selbst darauf hin, dass die Leitfäden allgemeine Hinweise sind und die Lage je Vertrag abweichen kann. Klären Sie den Lizenzweg deshalb vor dem Bau eines Ablaufs mit Ihrem SAP-Ansprechpartner.

• Vertragsmodell feststellen: Named User, Digital Access oder eine Mischung.
• Je geplantem Ablauf festhalten, welche Belege er in SAP anlegt.
• Prüfen, ob unbeaufsichtigte Abläufe vorgesehen sind.
• Ergebnis schriftlich mit dem SAP-Ansprechpartner abstimmen, bevor der Ablauf live geht.

Diese Seite ist keine Lizenzberatung. Zahlen, Gewichtungen und Preise des Modells Digital Access nennen wir bewusst nicht; sie ergeben sich aus Ihrem Vertrag.

Woran scheitern SAP-Schnittstellen im Betrieb?

Die meisten Störungen zeigen sich als HTTP-Statuscode oder als IDoc-Status, und SAP dokumentiert die häufigsten Bedeutungen. Wer sie im Ablauf auswertet, statt nur Erfolg oder Misserfolg zu melden, findet die Ursache meist ohne SAP-Berater.

Ein zweites typisches Problem ist die doppelte Buchung. Ein synchroner Aufruf, der nach einer Zeitüberschreitung wiederholt wird, kann einen Beleg zweimal anlegen, wenn die erste Anfrage doch angekommen war. Darum prüft ein sauberer Ablauf vor jeder Wiederholung, ob der Beleg schon existiert.

Ablauf in 7 Schritten

1. 01
   Ablauf beschreiben

   Welcher Vorgang, welche Belege, welche Menge pro Tag, braucht er sofort eine Antwort? Daraus folgt die Grundrichtung: synchron, asynchron oder ereignisgesteuert.

2. 02
   Release und Betriebsmodell feststellen

   ECC, S/4HANA On-Premise, Private oder Public Edition und den Stand des Feature Package mit der SAP-Basis klären.

3. 03
   Schnittstelle im Hub auswählen

   Im SAP Business Accelerator Hub die freigegebene API für Ihr Release suchen, Version und Status prüfen, Spezifikation herunterladen. Bei ECC freigegebene BAPIs oder IDoc-Typen wählen.

4. 04
   Lizenz und Berechtigung klären

   Lizenzweg mit dem SAP-Ansprechpartner abstimmen, technischen Benutzer mit minimalen Rechten und passendem Anmeldeverfahren anlegen lassen.

5. 05
   Im Testsystem bauen

   Ablauf außerhalb des ERP mit echten, anonymisierten Daten im Testsystem aufbauen, Fehlerfälle wie 403, 412 und doppelte Anlage gezielt durchspielen.

6. 06
   Überwachung einrichten

   Statuscodes, IDoc-Status und Warteschlangen auswerten und bei Fehlern die zuständige Person benachrichtigen, statt still abzubrechen.

7. 07
   Live schalten und pflegen

   Nach Freigabe produktiv nehmen und die What's-New-Hinweise jedes SAP-Release auf veraltete APIs prüfen.

Häufige Fragen