SAP-Schnittstellen, die im Betrieb stabil bleiben

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 beiden Systemen sitzt und das tut, was eine Punkt-zu-Punkt-Verbindung nicht kann: Formate übersetzen, Nachrichten puffern, jede Übertragung protokollieren und fehlerhafte Datensätze mit Kontext zur Korrektur bereitstellen. Genau nach diesem Muster haben wir BridgeSync gebaut, die SAP-AFAS-Integration für einen belgischen nationalen Mautbetreiber: Vorher übertrug das Finanzteam Daten täglich von Hand, mit Fehlern und Compliance-Risiken; heute läuft der gesamte Austausch automatisch, mit eingebauter Validierung und Rückrollpfad für fehlerhafte Datensätze. Eine tägliche Abstimmung vergleicht beide Systeme Zeile für Zeile, der Monatsabschluss läuft also auf Daten, die bereits übereinstimmen. Dasselbe Muster wenden wir auf andere Kombinationen an: SAP mit Billing-Plattformen, Logistiksystemen oder individuellen ERPs.