SAP-Systeme stabil anbinden

Wir arbeiten mit dem gesamten Spektrum: RFC und BAPI für synchrone Aufrufe gegen freigegebene Geschäftsfunktionen, IDoc für asynchrone Massendaten wie Belege, Stammdaten und Bewegungsdaten, OData und REST für moderne Anwendungen, Partner und mobile Clients. Welche Technologie zum Einsatz kommt, entscheidet der Anwendungsfall, nicht eine Vorliebe: Ein nächtlicher Stammdatenabgleich braucht etwas anderes als eine Webanwendung, die live in SAP buchen soll. Für den Datentransport zwischen SAP und Drittsystemen setzen wir auf Middleware mit Queues und nachrichtenbasierten Architekturen wie Kafka, damit ein vorübergehender Ausfall auf einer Seite nie zu Datenverlust führt. Über 20 Jahre Senior-Engineering-Erfahrung im Team bedeuten dabei auch: Wir kennen die Altlasten, die in gewachsenen SAP-Landschaften üblich sind, und müssen sie nicht erst entdecken, wenn sie brechen.

Ja, das ist einer der häufigsten Einstiege. Wir beginnen mit einer Analyse der Fehlerbilder: Welche Nachrichten scheitern, wie oft, an welcher Stelle, und was kostet die Nacharbeit heute. Daraus entsteht ein Bild, wie viel sich stabilisieren lässt, ohne die angebundenen Systeme anzufassen, oft mehr, als Teams erwarten. Typische Maßnahmen sind saubere Wiederaufsetzpunkte, Retry-Logik mit Dead-Letter-Queue, eine tägliche Abstimmung, die fehlende oder doppelte Datensätze erkennt, und Monitoring, das meldet, bevor die Fachabteilung etwas bemerkt. Die bestehende Schnittstelle läuft währenddessen weiter; Verbesserungen werden parallel aufgebaut und erst umgeschaltet, wenn die Abstimmung zeigt, dass beide Pfade dieselben Ergebnisse liefern. Erst wenn eine Verbindung nicht mehr zu retten ist, schlagen wir einen Ersatz vor, und begründen das.

Ein Releasewechsel ist der Moment, in dem vergessene Schnittstellen sichtbar werden, meist zum schlechtesten Zeitpunkt. Wir beginnen deshalb mit einer Bestandsaufnahme: Welche Verbindungen existieren, welche Technologien nutzen sie, welche sind vom neuen Release betroffen. RFC-Aufrufe und IDoc-Ströme verhalten sich unter S/4HANA nicht immer identisch, und manche kundeneigene Funktionsbausteine fallen weg. Jede betroffene Schnittstelle wird gegen das neue Release getestet, bevor umgestellt wird, und die Umstellung erfolgt schrittweise, Verbindung für Verbindung, statt an einem einzigen Stichtag. Wo eine Middleware zwischen SAP und den Drittsystemen sitzt, zahlt sie sich hier doppelt aus: Der Vertrag nach außen bleibt stabil, während sich das SAP-System dahinter ändert, und die angebundenen Systeme merken vom Wechsel im Idealfall nichts.

Über eine Middleware, die zwischen SAP und den anderen Anwendungen sitzt. SAP wird je nach Anwendungsfall über RFC, BAPI, IDoc, OData oder REST angebunden, die Middleware prüft die Daten und übersetzt sie in das Format des Zielsystems. Ändert sich das SAP-System dahinter, bleibt der Vertrag nach außen stabil, und die angebundenen Anwendungen laufen weiter.