9. November 2026 · Christian Buck
Schnittstellen als Verträge
Viele SAP-Landschaften haben Hunderte Schnittstellen. Dokumentiert ist meist das Mapping: welches Feld auf welches Feld geht. Selten steht irgendwo, wer fachlich für die Schnittstelle zuständig ist, welches System im Zweifel recht hat und wie alt die Daten beim Empfänger sein dürfen. Solange alles läuft, fällt das nicht auf. Bei einem Fehler oder einer Ablösung fehlt dann die Grundlage für jede Entscheidung.
Einen konkreten Anlass für diese Fragen gibt es gerade in vielen Unternehmen. SAP hat für SAP Process Orchestration 7.5 die Mainstream-Wartung bis Ende 2027 angekündigt, die erweiterte Wartung bis Ende 2030. Die Nachfolge liegt in der SAP Integration Suite auf SAP BTP. Wer die Schnittstellen dafür ohnehin anfasst, kann sie bei der Gelegenheit als Verträge beschreiben.
Was in den Vertrag gehört
Ein Schnittstellenvertrag ist kein langes Dokument. Er beantwortet je Datenfluss wenige Fragen:
- Fachlicher Eigentümer: Wer entscheidet über Inhalt und Änderungen? Zum Beispiel der Vertrieb für Kundenaufträge; die IT betreibt die Schnittstelle nur.
- Führendes System: Wo wird der Datensatz angelegt und geändert, wo nur gelesen? Zum Beispiel der Geschäftspartner in S/4HANA mit einer Kopie in der Anwendung auf SAP BTP.
- Aktualität: Wie alt dürfen die Daten beim Empfänger höchstens sein? Sekunden für eine Verfügbarkeitsprüfung, ein Tag für ein Berichtswesen.
- Fehlerfall: Wer wird benachrichtigt, wer korrigiert, darf die Nachricht wiederholt werden? Eine Wiederholung ist unkritisch, wenn der Empfänger doppelte Nachrichten erkennt.
Dazu kommt die Version des Datenmodells. Eine API, die von mehreren Anwendungen genutzt wird, braucht eine Regel, wie Änderungen angekündigt werden und wie lange die alte Version erreichbar bleibt.
Ereignis oder synchroner Aufruf
Die zweite Entscheidung betrifft das Muster. Ein synchroner Aufruf passt, wenn der Aufrufer die Antwort braucht, um weiterzuarbeiten: eine Preisermittlung, eine Verfügbarkeitsprüfung, eine Bonitätsauskunft. Der Aufrufer wartet, und der Aufgerufene muss in diesem Moment erreichbar sein.
Ein Ereignis passt, wenn ein System andere über eine Änderung informiert und selbst keine Antwort erwartet: Auftrag angelegt, Geschäftspartner geändert, Lieferung gebucht. Der Sender kennt die Empfänger nicht, und neue Empfänger lassen sich ergänzen, ohne den Sender zu ändern. Auf SAP BTP übernimmt ein Event-Broker wie SAP Event Mesh die Verteilung.
Beide Muster haben Grenzen. Ketten synchroner Aufrufe koppeln die Verfügbarkeit: Ruft A das System B auf und B das System C, steht A, sobald C ausfällt. Ereignisse verlangen dagegen Empfänger, die doppelte Nachrichten erkennen und mit einer veränderten Reihenfolge umgehen können. Ohne fachlichen Eigentümer entsteht bei Ereignissen außerdem leicht ein Geflecht, in dem niemand mehr weiß, wer auf welche Nachricht reagiert.
Drei Beispiele aus Projekten
Im Bankenmeldewesen ist der Vertrag von außen vorgegeben. Die Aufsicht legt das XML-Schema fest, die Übertragung läuft über einen Webservice, und die Aktualität ergibt sich aus dem Meldetermin. Offen bleibt intern meist nur, wer bei einer Rückweisung korrigiert. Diese Frage sollte vor dem ersten Meldetermin beantwortet sein.
Beim Laden von Quellsystemen in SAP BW/4HANA ist die Aktualität der Ladezeitpunkt. Wird nachts geladen, sind die Daten tagsüber bis zu einem Tag alt. Das ist für die meisten Berichte ausreichend, sollte aber mit der Fachseite vereinbart sein, bevor jemand einen Tagesbericht als Steuerungsinstrument nutzt.
Bei einer Anwendung auf SAP BTP mit CAP, die side-by-side zu S/4HANA arbeitet, führt S/4HANA die Stammdaten, und die BTP-Anwendung führt ihre eigenen Vorgänge. Lesende Zugriffe auf Stammdaten laufen dort synchron über OData. Änderungen an eigenen Vorgängen, die S/4HANA kennen muss, eignen sich für Ereignisse.
Was das für eine Ablösung bedeutet
Eine Migration, die jede Schnittstelle eins zu eins nachbaut, übernimmt auch die ungeklärten Fragen. Ich würde jede Schnittstelle vorher mit den vier Festlegungen erfassen. Dabei zeigt sich in der Regel dreierlei: Einige Schnittstellen werden nicht mehr genutzt und können entfallen, einige synchrone Abfragen lassen sich durch Ereignisse ersetzen, und für einige findet sich kein fachlicher Eigentümer. Die letzte Gruppe braucht eine Entscheidung, bevor sie migriert wird.
Wie dokumentieren Sie Schnittstellen in Ihrer Landschaft, und wer ist dort fachlich zuständig?
Fragen zum Beitrag oder zu Ihrem Projekt? info@bissanda.com · Alle Beiträge