Middleware wird aus guten technischen Gründen in SAP-Integrationslandschaften eingesetzt: Systeme werden entkoppelt, Protokolle übersetzt, Fehlerbehandlung zentralisiert und Nachrichten transformiert. Was in Architekturgesprächen häufig weniger Beachtung findet, sind die Auswirkungen dieser Entscheidungen auf das Monitoring. Denn gleichzeitig entstehen neue Blind Spots, die oftmals nicht explizit bewertet werden.
Ein Hub, der Nachrichten korrekt verarbeitet, ist für das sendende SAP-System praktisch unsichtbar. Dasselbe gilt für einen Hub, bei dem nach der Übergabe Fehler auftreten. Aus Sicht des SAP-Systems ist nicht erkennbar, ob eine Nachricht tatsächlich zugestellt, korrekt transformiert und vom Zielsystem verarbeitet wurde. Dafür muss der Hub separat überwacht werden, und das Monitoring muss so konzipiert sein, dass Fehler auch für das Team sichtbar werden, das für die SAP-Seite verantwortlich ist.
Dieser Artikel zeigt, wie Middleware-Architekturen die verfügbare Sichtbarkeit verändern, an welchen Stellen sich die Verantwortung für das Monitoring verschiebt und welche Architekturentscheidungen den Betrieb über Integrationsgrenzen hinweg deutlich einfacher machen.
Was eine Hub-Architektur tatsächlich an der Sichtbarkeit verändert
Die Ausgangssituation bei Point-to-Point-Verbindungen
Bei einer direkten RFC- oder IDoc-Verbindung zwischen zwei SAP-Systemen ist das Monitoring auf der Senderseite vergleichsweise vollständig. SM58 zeigt, ob ein transaktionaler RFC-Aufruf versendet und bestätigt wurde. BD87 zeigt den IDoc-Status in den einzelnen Verarbeitungsschritten. Schlägt der Aufruf fehl, wird der Fehler in den Transaktionsmonitoren des sendenden Systems sichtbar. Ist er erfolgreich, bestätigt das Acknowledgement, dass das empfangende System die Nachricht angenommen hat.
Diese Sichtbarkeit ist nicht perfekt. Eine Nachricht, die von der RFC-Schicht des empfangenden Systems erfolgreich bestätigt wurde, kann später auf Anwendungsebene trotzdem fehlschlagen und beispielsweise einen IDoc-Fehler mit Status 51 erzeugen. Dieser ist auf der Senderseite nicht sichtbar, solange das Empfängersystem nicht explizit überwacht wird. Dennoch ist die mögliche Fehlerfläche klar definiert und begrenzt. Die auf SAP-Seite verfügbaren Monitoring-Werkzeuge decken einen großen Teil davon ab.
Was sich ändert, sobald Middleware ins Spiel kommt
Sobald eine Nachricht über einen Hub läuft, reduziert sich die Sicht des sendenden SAP-Systems im Wesentlichen auf einen einzigen Datenpunkt: Hat die Nachricht die Middleware erfolgreich erreicht?
Wenn ja, setzt das SAP-System seine Verarbeitung fort. Alles, was danach geschieht, also die Verarbeitung in der Middleware, die Transformation, die Zustellung an das Zielsystem und die Verarbeitung auf Anwendungsebene, liegt außerhalb der direkten Sicht des sendenden SAP-Systems.
Wie groß diese Monitoring-Lücke ist, hängt davon ab, wie asynchron die Hub-Architektur aufgebaut ist. In einer vollständig asynchronen Architektur legt das SAP-System die Nachricht in der Eingangswarteschlange der Middleware ab und setzt seine Verarbeitung sofort fort. Aus Sicht des SAP-Transaktionsmonitorings war der Versand erfolgreich. Ob das nachgelagerte System die Nachricht tatsächlich empfangen und verarbeitet hat, muss das Monitoring der Middleware beantworten.
Bei einem synchronen Hub wartet das SAP-System auf eine Antwort der Middleware, die wiederum auf eine Antwort des Zielsystems wartet. Dadurch kennt SAP das Ergebnis der gesamten Aufrufkette, da entweder eine erfolgreiche Antwort oder ein Fehler zurückgegeben wird. Synchrone Architekturen erhalten damit mehr End-to-End-Sichtbarkeit, haben jedoch Auswirkungen auf die Performance: Der SAP-Workprozess hält die Verbindung während der gesamten nachgelagerten Verarbeitung offen.
Asynchrone Hubs und das Problem der Dead Letter Queue
Asynchrone Integration ist heute das dominierende Muster in modernen SAP-Middleware-Architekturen, da sie die Performance von Sender und Empfänger voneinander entkoppelt. Das SAP-System wird nicht blockiert, während es auf eine Antwort eines nachgelagerten Systems wartet. Lastspitzen auf der Empfängerseite bremsen das sendende SAP-System nicht unmittelbar aus. Das sind klare Vorteile.
Der Preis aus Monitoring-Sicht ist, dass die Bestätigung der tatsächlichen Verarbeitung vollständig aus dem Sichtbereich des SAP-Senders verschwindet. Der Sender weiß lediglich, dass die Nachricht übergeben wurde. Die Bestätigung, dass sie vom Empfänger verarbeitet wurde, befindet sich ausschließlich in den Logs der Middleware und, bei einer gut konzipierten Hub-Architektur, in den Anwendungsdaten des Zielsystems.
Ein typischer Fehlermodus asynchroner Architekturen ist die Dead Letter Queue, kurz DLQ. Wenn eine Nachricht innerhalb der Middleware wiederholt nicht verarbeitet werden kann und die maximale Anzahl an Retries erreicht ist, wird sie in die DLQ verschoben. Dieses Verhalten ist korrekt: Die Nachricht bleibt für eine spätere Analyse erhalten, statt verworfen zu werden.
Das operative Problem entsteht, wenn sich Nachrichten unbemerkt in der DLQ ansammeln, weil kein Alert für die Queue-Tiefe eingerichtet wurde.
Eine DLQ, in der sich seit drei Tagen Nachrichten ansammeln, steht für drei Tage fehlgeschlagener Zustellungen ohne Alert. Das sendende SAP-System betrachtet die Übergabe als erfolgreich, weil die Nachricht den Hub erreicht hat. Der Hub wiederum hat seine definierte Fehlerbehandlung ausgeführt und die Nachricht in die DLQ verschoben. Das Business bemerkt das Problem unter Umständen erst, wenn ein nachgelagerter Prozess falsche oder fehlende Daten produziert.
| Achtung: Dead Letter Queues ohne Monitoring-Alerts gehören zu den häufigsten Ursachen für unbemerkte Integrationsfehler in Hub-basierten Architekturen. Ein Alert bereits bei ein oder zwei Nachrichten in einer DLQ ist in einer Produktionsumgebung nicht übertrieben. Nachrichten in einer DLQ haben sämtliche vorgesehenen Wiederholungsversuche ausgeschöpft. Jeder Eintrag steht damit für eine nicht erfolgte Zustellung. Bei Tier-1-Nachrichtentypen sollte ein solcher Alert als kritisch eingestuft werden. |
|---|
Die doppelte Monitoring-Anforderung und typische Verantwortungslücken
Jede Integration, die über Middleware läuft, benötigt Monitoring an mindestens zwei Punkten: im sendenden System und im Hub. Das sendende System bestätigt, dass die Nachricht übergeben wurde. Der Hub bestätigt, dass sie verarbeitet und zugestellt wurde. Keine dieser beiden Informationen reicht allein aus.
In den meisten Unternehmen liegen diese beiden Bereiche bei unterschiedlichen Teams. Das SAP-Basis- oder Operations-Team überwacht die SAP-Seite. Ein Middleware-, BTP-Operations- oder Infrastrukturteam ist für den Hub zuständig. Schlägt eine Nachricht irgendwo dazwischen fehl, müssen beide Teams ihre jeweiligen Monitoring-Daten prüfen, Zeitstempel und Nachrichtenkennungen vergleichen und die Fehlersequenz über die technische Grenze hinweg rekonstruieren.
Die eigentliche Lücke entsteht, wenn beide Monitoring-Umgebungen keinen gemeinsamen Identifier für eine Nachricht verwenden. Ohne eine Correlation ID, die vom SAP-Sender über die Middleware bis zum Zielsystem erhalten bleibt, müssen SAP-seitige und Hub-seitige Ereignisse über Zeitstempel und manuelle Vergleiche zusammengeführt werden. Unter dem Druck eines Incidents ist das langsam und fehleranfällig.
Diese Lücke lässt sich durch eine klare Architekturentscheidung vermeiden: Jede Nachricht erhält bereits an ihrem Ursprung eine Correlation ID. Das SAP-System erzeugt oder übermittelt einen eindeutigen Identifier im Payload. Die Middleware übernimmt diesen Identifier in ihre Processing Logs. Das Zielsystem verwendet ihn wiederum in den Acknowledgements auf Anwendungsebene.
Tritt ein Fehler auf, kann jedes Team in allen Monitoring-Systemen nach derselben Kennung suchen und sofort die relevanten Ereignisse der einzelnen Verarbeitungsschritte finden.
Transformationsfehler: technisch erfolgreich, fachlich falsch
Die Transformation von Nachrichten in der Middleware, beispielsweise von einem IDoc-Format in einen REST-Payload, das Mapping unterschiedlicher Feldnamen oder die Umstrukturierung hierarchischer Daten, führt zu einer Fehlerklasse, die weder der SAP-Sender noch das Zielsystem automatisch erkennen müssen.
Die Transformation findet in der Middleware statt. Erzeugt sie einen syntaktisch gültigen, aber semantisch falschen Output, kann die Nachricht erfolgreich zugestellt und vom Zielsystem ohne technischen Fehler verarbeitet werden. Das fachliche Ergebnis ist trotzdem falsch.
Ein Beispiel: Bei einem Bestell-IDoc führt ein Mapping-Fehler dazu, dass die Menge in das Preisfeld geschrieben wird. Die resultierende Bestellung ist strukturell korrekt, enthält aber falsche Werte. Sowohl die Middleware als auch das Zielsystem melden eine erfolgreiche Verarbeitung. Der Fehler wird erst sichtbar, wenn jemand feststellt, dass der Preis exakt der bestellten Menge entspricht und damit offensichtlich unplausibel ist.
Monitoring für diese Art von Fehler erfordert eine Payload-Validierung auf Middleware-Ebene. Dabei wird nicht nur geprüft, ob eine Transformation technisch erfolgreich durchgeführt wurde, sondern auch, ob die transformierten Daten erwartete Werte und plausible Wertebereiche enthalten.
Diese Monitoring-Anforderung gehört bereits in die Designspezifikation des Integration Hubs. Sie sollte nicht erst nach dem ersten Produktions-Incident ergänzt werden.
SAP Integration Suite: Die Monitoring-Schnittstelle, die viele Teams zu wenig nutzen
SAP Integration Suite auf BTP bietet eine Operations-Ansicht, in der sich der Status der Nachrichtenverarbeitung, Ergebnisse von Flow-Ausführungen und Fehlerlogs einsehen lassen. Sie ist das richtige Werkzeug für das Monitoring von auf BTP betriebenen Integration Flows. Gleichzeitig haben viele SAP-Basis-Teams höchstens lesenden Zugriff darauf und nutzen die Ansicht nicht im täglichen Operations-Kontext.
Für ein automatisiertes Integration Monitoring ist die OData API der Integration Suite noch interessanter. Sie stellt den Status der Nachrichtenverarbeitung, Statistiken zu Flow-Ausführungen und Fehlerzahlen maschinenlesbar bereit. Eine Monitoring-Plattform, die diese API beispielsweise jede Minute abfragt und einen Alert auslöst, sobald die Fehlerquote bestimmter Flows einen definierten Schwellenwert überschreitet, liefert die Echtzeit-Sichtbarkeit auf der Hub-Seite, für die die Operations-Ansicht sonst manuell geprüft werden müsste.
Für die Einrichtung werden API-Client-Credentials im BTP-Subaccount mit den entsprechenden Berechtigungen für das Message Monitoring, ein Endpoint für die Management API der Integration Suite sowie eine Monitoring-Plattform benötigt, die REST APIs abfragen kann.
Viele SAP-Monitoring-Lösungen bieten diese Integration nicht standardmäßig an. Deshalb bleibt die Operations-Ansicht in vielen Umgebungen ein manuell geprüftes Werkzeug statt einer automatisierten Alert-Quelle. Eine API-Integration ändert das grundlegend.
| Hinweis: Wird die Integration Suite für bestimmte Integrationsmuster parallel zu einer Drittanbieter-Middleware wie MuleSoft oder Boomi eingesetzt, müssen beide Plattformen unabhängig voneinander überwacht werden. Eine Landschaft, in der ein Teil der Integrationen über Integration Suite und ein anderer Teil über eine Drittanbieter-Lösung läuft, benötigt Monitoring für jede einzelne Plattform. Gleichzeitig sollten Correlation IDs ein plattformübergreifendes Message Tracing ermöglichen, wenn ein Business-Prozess mehrere Integrationsplattformen durchläuft. |
|---|
Architekturentscheidungen, die gutes Monitoring überhaupt erst ermöglichen
Welche Auswirkungen eine Integration-Hub-Architektur auf das Monitoring hat, wird größtenteils bereits in der Architekturphase entschieden und nicht erst im späteren Betrieb. Drei Entscheidungen haben besonders großen Einfluss auf die Monitoring-Abdeckung.
Erstens sollte für den Großteil der SAP-Nachrichtenflüsse möglichst eine zentrale Integrationsplattform standardisiert werden, anstatt jedem Projektteam die Einführung einer eigenen Middleware-Lösung zu erlauben. Eine Landschaft mit Integrationen auf fünf unterschiedlichen Plattformen benötigt fünf Monitoring-Ansätze, fünf Alert-Konfigurationen und fünf unterschiedliche Eskalationswege.
Eine Konsolidierung muss weder sofort noch vollständig erfolgen. Sie sollte jedoch die klare strategische Richtung darstellen. Neue Integrationen, die von der Standardplattform abweichen, sollten eine explizite Begründung erfordern.
Zweitens sollte die Monitoring-Verantwortung im Integrationsarchitektur-Dokument eindeutig definiert werden. Wer überwacht die SAP-Senderseite? Wer den Hub? Wer das Zielsystem? Wer ist der Eskalationskontakt, wenn eine Nachricht auf dem Transportweg fehlschlägt?
Diese Fragen benötigen operative Antworten, bevor der erste Produktions-Incident auftritt und nicht erst währenddessen.
Drittens sollten DLQ-Alerting und die Implementierung einer Correlation ID verbindliche Anforderungen für jede neue Integration sein und keine optionalen Zusatzfunktionen. Beide sind technisch nicht besonders komplex umzusetzen. Trotzdem werden sie regelmäßig ausgelassen, weil sie nicht Teil der funktionalen Anforderungen sind, an denen Projektpläne und Go-live-Termine ausgerichtet werden.
Werden sie genauso wie fachliche Anforderungen in die Abnahmekriterien einer Integration aufgenommen, ist sichergestellt, dass sie vor dem Go-live umgesetzt werden und nicht erst nach dem ersten unbemerkten Fehler nachgerüstet werden müssen.
Eine Middleware-Architektur, die diese drei Anforderungen erfüllt, wird Integrationsfehler nicht vollständig verhindern. Sie sorgt aber dafür, dass das Monitoring im Fehlerfall über die notwendigen Daten verfügt, um den Incident schnell zu erkennen, und dass organisatorisch klar ist, wer reagieren muss. Genau das ist das realistische Ziel von Integration Monitoring in einer komplexen SAP-Landschaft.
Redpeaks überwacht SAP-seitige Interface-Metriken wie IDoc-Status, RFC-Queue-Tiefe und qRFC-Zustand und unterstützt die Integration von Daten aus BTP Operations APIs. Dadurch entsteht eine End-to-End-Sicht auf SAP-Integrationen über die Middleware-Grenze hinweg.
