IDoc, OData oder RFC: die richtige SAP-Schnittstelle wählen

Eine einzelne SAP-Schnittstelle zu bauen ist unkompliziert. Schwierig wird es bei der Frage, welche der rund sechs verfügbaren Methoden zur Aufgabe passt. Ein IDoc-Interface aus dem Jahr 2005 läuft in vielen Systemen bis heute produktiv neben einer REST-API, die vergangenes Quartal entstanden ist. Wer die falsche Methode wählt, zahlt später mit Performance-Problemen, brüchiger Fehlerbehandlung oder einer Landschaft aus Punkt-zu-Punkt-Verbindungen, die niemand mehr überblickt.

Die Entscheidung lässt sich auf zwei Kernfragen herunterbrechen: Braucht der Prozess eine sofortige Rückmeldung (synchron) oder nicht (asynchron)? Und geht es um einzelne, transaktionale Vorgänge oder um hohe Volumina im Massenbetrieb?

Die drei klassischen Verfahren im Überblick

RFC und BAPI: synchron und transaktional

RFC (Remote Function Call) ist SAPs proprietäres Protokoll für die synchrone Kommunikation zwischen Systemen. BAPIs sind standardisierte, RFC-fähige Funktionsbausteine, die auf SAP-Geschäftsobjekte zugreifen. Sie sind stark typisiert und liefern sofortige Rückmeldung, ideal für Prozesse, die unmittelbar wissen müssen, ob eine Buchung erfolgreich war.

Wichtig in der Umsetzung: BAPIs committen nicht automatisch. Der aufrufende Prozess muss die Transaktionsgrenze über BAPI_TRANSACTION_COMMIT selbst kontrollieren. Der typische Schwachpunkt von RFC ist die enge Kopplung: Was bei einem Partner sauber funktioniert, wird bei fünf Partnern mit je eigener API-Variante schnell zur unübersichtlichen Punkt-zu-Punkt-Landschaft.

IDoc: asynchron, robust, für Massen

Das IDoc (Intermediate Document) ist SAPs Standard für asynchronen, hochvolumigen und lose gekoppelten Datenaustausch. IDocs folgen festen Nachrichtentypen wie ORDERS05 für Bestellungen oder INVOIC für Rechnungen und sind besonders in Logistik, Handel und Fertigung verbreitet, wo EDI-Standards die Norm sind.

IDocs sind bewusst batch-orientiert und entkoppeln Sender und Empfänger zeitlich. Sie kennen keine klassischen API-Rate-Limits, ihr Durchsatz wird durch Systemressourcen begrenzt: Work-Prozesse, Datenbank-I/O und RFC-Verbindungspools. Ein wichtiger Hinweis zur Zielarchitektur: In der Public-Cloud-Variante von S/4HANA stehen IDocs nicht zur Verfügung, dort sind OData oder SOAP zu verwenden.

OData: REST-basiert, für moderne Oberflächen

OData-Services sind REST-basierte Webservices über HTTP und die Grundlage moderner SAP-Integration, insbesondere für Fiori-Apps und S/4HANA. Sie eignen sich für flexiblen, feingranularen Echtzeitzugriff durch externe Anwendungen und sind der bevorzugte Weg für kundenseitige Apps, die einzelne Datensätze lesen oder schreiben.

Entscheidungsmatrix

Die folgende Gegenüberstellung fasst zusammen, wann welches Verfahren trägt:

Kriterium	RFC / BAPI	IDoc	OData
Kommunikation	synchron	asynchron	synchron (HTTP)
Volumen	niedrig bis mittel	hoch (Massen)	niedrig bis mittel
Rückmeldung	sofort	zeitversetzt	sofort
Kopplung	eng	lose	mittel
Typischer Einsatz	Echtzeit-Prüfung, 1:1	EDI, Stammdaten, Belege	Fiori, externe Apps
S/4HANA Public Cloud	eingeschränkt	nicht verfügbar	ja

Der Architektur-Fehler, der sich rächt

Der häufigste Fehler ist nicht die Wahl des falschen Protokolls für einen einzelnen Fall, sondern das Fehlen einer Integrationsstrategie. Jede neue Anbindung entsteht als direkte Punkt-zu-Punkt-Verbindung. Nach einigen Jahren existiert eine Landschaft aus dutzenden Einzelschnittstellen, jede mit eigener Fehlerbehandlung, eigenem Monitoring und eigener Logik.

Ab einer gewissen Zahl von Empfängern gehört zwischen SAP und die Zielsysteme ein Mediator, der Mapping, Routing und Fehlerbehandlung zentral übernimmt: SAP PI/PO, SAP Cloud Integration oder die SAP Integration Suite. Der Mehraufwand beim Aufbau zahlt sich durch Governance und Wartbarkeit aus.

* IDoc-Verarbeitung: Statusprüfung nach dem Einspielen
CALL FUNCTION 'IDOC_INBOUND_ASYNCHRONOUS'
  TABLES
    idoc_control_rec_40  = lt_control
    idoc_data_rec_40     = lt_data.
* Status 53 = erfolgreich gebucht, 51 = Fehler bei der Verarbeitung
* Robuste Integrationen werten den IDoc-Status systematisch aus,
* statt nur den technischen Empfang zu bestätigen.

Bezug zur Shop- und Marktplatzanbindung

Gerade bei der Verbindung von SAP mit E-Commerce- und Marktplatzsystemen wird die Methodenwahl konkret. Ein hochvolumiger Bestell- oder Auftragsstrom aus einem Marktplatz läuft sinnvoll über IDocs, während eine kundenseitige App Stammdaten in Echtzeit über OData liest. Beides gleichzeitig, mit einem Mediator für die Flüsse, die Konvertierung und Monitoring brauchen, ist in vielen Landschaften die tragfähige Kombination.