Eine RFC-Destination kann um 09:00 Uhr in SM59 einen erfolgreichen Verbindungstest zurückgeben, obwohl das System am anderen Ende seit 07:30 Uhr keine eingehenden Aufrufe mehr verarbeitet. Der Test prüft, ob ein Netzwerkpfad existiert. Er prüft nicht, ob auf der Empfängerseite eine Anwendung läuft, Daten liest oder die empfangenen Informationen verbucht. Sie erhalten also ein grünes Verbindungssignal, aber keinen Hinweis darauf, dass jede seit 07:30 Uhr gesendete Nachricht stillschweigend verloren geht.
Das ist das prägende Merkmal von Schnittstellenfehlern in SAP-Landschaften: Die gefährlichsten Ausfälle melden sich nicht als Fehler. Sie wirken wie operatives Schweigen. Die Schnittstelle ist technisch aktiv. Nachrichten werden technisch gesendet. Auf der Senderseite wird kein Fehlerstatus ausgelöst. Der Ausfall wird erst sichtbar, wenn ein Fachbereich fragt, warum die Bestandsaktualisierung aus dem Warehouse-Management-System nicht gebucht wurde, oder warum die Kundenrechnungen aus dem Billing-Lauf nicht im System des EDI-Partners erscheinen.
Dieser Artikel behandelt die spezifischen Fehlermuster, die SAP-Schnittstellen-Monitoring von anderen Monitoring-Bereichen unterscheiden, die Metriken und Signale, mit denen stille Ausfälle erkannt werden, bevor sie das Business erreichen, sowie die Monitoring-Abdeckung, die über IDoc-, RFC-, API- und Geschäftsprozessebenen hinweg sinnvoll ist.
Warum Schnittstellenfehler anders sind als andere SAP-Monitoring-Probleme
Der Fehler, der nicht wie ein Fehler aussieht
Das meiste SAP-Monitoring basiert auf Fehlerzuständen: ein Job mit Status ABORTED, ein Work Process im Fehlerzustand, ein System, das nicht mehr reagiert. Das sind sichtbare Ausfälle. Etwas ist eindeutig falsch, ein Alert wird ausgelöst, und das Operations-Team untersucht den Vorfall.
Schnittstellenfehler erzeugen auf der Senderseite häufig keinen sichtbaren Fehlerstatus. Ein IDoc, das an ein EDI-Subsystem gesendet wurde, bleibt dauerhaft im Status 02, wenn das EDI-System keine Nachrichten mehr abholt. Es wird kein neuer Fehler erzeugt. Die Anzahl der IDocs im Status 02 steigt einfach weiter. Eine qRFC-Queue füllt sich mit ausgehenden Nachrichten, weil das empfangende System unter Last steht und langsam verarbeitet. Kein Fehler wird ausgelöst, bis die Queue ein konfiguriertes Limit erreicht, und in vielen Systemen ist dieses Limit nicht eingerichtet. Ein HTTP-Endpunkt antwortet mit Statuscode 200, aber der Response Body enthält eine Fehlermeldung, die von der sendenden Integrationsschicht nicht ausgewertet wird.
Die Monitoring-Abdeckung, die solche Situationen erkennt, unterscheidet sich von klassischem Threshold-Alerting auf Fehlerzahlen. Sie muss Zustände überwachen, die technisch keine Fehler sind, operativ aber abnormal: Nachrichten, die länger als erwartet in einem Dispatch-Status hängen, Queues, die wachsen, obwohl sie sich leeren sollten, oder Volumenmuster, die vom normalen Verhalten zur jeweiligen Tageszeit abweichen.
Warum Volumen genauso wichtig ist wie die Fehlerrate
Eine gut funktionierende Order-to-Cash-Schnittstelle in einem Fertigungsunternehmen verarbeitet während der Geschäftszeiten mehrere Hundert ORDERS05-IDocs pro Stunde. Nachts verarbeitet sie null IDocs. Beide Zustände sind normal.
Nicht normal ist: null IDocs um 10:00 Uhr an einem Dienstagmorgen, wenn eigentlich Bestellungen fließen sollten. Das ist in keiner SAP-Transaktion ein Fehlerzustand. BD87 zeigt keine Fehler. WE05 zeigt nichts in der Queue. Die Schnittstelle wirkt gesund, weil nichts fehlschlägt. Tatsächlich werden aber keine Nachrichten gesendet, was bedeutet, dass upstream etwas aufgehört hat, Nachrichten zu erzeugen.
Volumenbasiertes Monitoring, das prüft, ob der Nachrichtendurchsatz zum erwarteten Muster für Tageszeit und Business-Kalender passt, erkennt diese Fehlerkategorie. Eine Schnittstelle, die dienstagmorgens normalerweise 400 IDocs pro Stunde verarbeitet und nach 30 Minuten Geschäftsbetrieb immer noch bei null steht, fällt nicht aus. Sie ist abwesend. Diese Unterscheidung ist wichtig, weil die Behebung eines Verarbeitungsfehlers, bei dem etwas Fehler erzeugt, anders aussieht als die Behebung eines Volumenabfalls, bei dem upstream nichts mehr sendet.
Die Erkennung von Volumenanomalien benötigt historische Baselines pro Schnittstelle und Zeitfenster. Sie ist komplexer zu konfigurieren als Alerting auf Fehlerzahlen, weshalb die meisten Monitoring-Setups sie auslassen. Gleichzeitig erkennt genau diese Ebene die stillen Ausfälle mit dem größten Business Impact.
IDoc-Monitoring: über Statuscodes hinausdenken
Die Statuscodes, die sofortige Aufmerksamkeit verdienen
IDocs in SAP haben mehr als 70 Statuscodes, die jeden Schritt der ausgehenden und eingehenden Verarbeitung abdecken. Die meisten davon sind rein informativ. Eine Teilmenge steht für Zustände, die in einer Produktionsumgebung sofortige Aufmerksamkeit erfordern. Die folgende Übersicht behandelt die Codes mit der größten operativen Relevanz.
Acht Statuscodes machen den Großteil der IDoc-Vorfälle aus, die ein Monitoring verdienen. Unter den Fehlerzuständen ist Status 51, Fehler beim Buchen, in der Produktion am häufigsten: Das IDoc hat den Schritt der eingehenden Verarbeitung erreicht, konnte aber das SAP-Dokument nicht erstellen. Die Ursachen reichen von fehlenden Stammdaten über Berechtigungsfehler bis hin zu einer falschen Konfiguration des Nachrichtentyps. Status 51 benötigt fast immer einen Fachanwender oder einen funktionalen Consultant, nicht nur Basis. Eine Weiterleitung an ein generisches Basis-Postfach verlängert die Lösungszeit um Stunden.
Status 25, Verarbeitung fehlgeschlagen, und Status 26, Syntaxprüfungsfehler, weisen auf Probleme auf Sender- oder Mapping-Seite hin. Status 25 deutet häufig auf das EDI-Subsystem oder das ausgehende ABAP-Programm hin. Status 26 bedeutet, dass das IDoc mit einem strukturellen Fehler erzeugt wurde, was auf ein Code- oder Konfigurationsproblem beim Sender verweist.
Zwei Zwischenzustände verdienen besondere Aufmerksamkeit, obwohl sie keine Fehlercodes sind. Status 02 und 12, an EDI-Subsystem oder ALE-Variante gesendet, bedeuten, dass das IDoc an die nächste Verarbeitungsschicht übergeben wurde. Technisch ist das kein Fehler. Aber ein IDoc, das während der Geschäftszeiten vier Stunden lang in Status 02 steht, ist operativ abnormal. Altersbasierte Alerts auf diese Status, nicht nur fehlerbasierte Alerts, gehören zu den wertvollsten Ergänzungen im Monitoring und werden dennoch selten implementiert.
Status 64, bereit zur Übergabe an die Anwendung, ist der eingehende Queue-Zustand. Einige Einträge zu einem beliebigen Zeitpunkt sind normal. Ein wachsender Rückstau ist es nicht. Überwachen Sie die Anzahl der IDocs im Status 64 über ein 15-Minuten-Fenster. Wenn sie steigt statt sich abzubauen, hält die eingehende Verarbeitungskapazität nicht Schritt, und die upstream Ursache sollte gefunden werden, bevor der Rückstau groß genug wird, um Business-Fristen zu beeinträchtigen.
IDocs, die in der Verarbeitung hängen: die Queue, die ohne Alarm wächst
Status 64 steht für eingehende IDocs, die empfangen und für die Verbuchung in der Anwendung in eine Queue gestellt wurden, wo sie auf einen verfügbaren Prozess warten. Unter normaler Last leert sich diese Queue schnell. Einige Einträge im Status 64 zu einem bestimmten Zeitpunkt sind zu erwarten. Ein wachsender Rückstau im Status 64 ist es nicht.
Der Rückstau wächst, wenn die eingehende Verarbeitungskapazität nicht mit dem eingehenden Volumen Schritt halten kann. Das passiert, wenn die Background Work Processes für die eingehende IDoc-Verarbeitung durch andere Jobs belegt sind, wenn das eingehende Verarbeitungsprogramm selbst durch eine Performance-Regression langsam wird, oder wenn ein vorheriges IDoc in derselben Verarbeitungssequenz blockiert und nachfolgende IDocs aufhält.
Die Überwachung der Anzahl von IDocs im Status 64 über ein rollierendes 15-Minuten-Fenster, mit einem Alert, wenn diese Zahl wächst statt sinkt, erkennt Kapazitätsprobleme, bevor sie sichtbare Verzögerungen in den Geschäftsprozessen verursachen, die von den eingehenden Daten abhängen.
Das IDoc, das erfolgreich war, aber das Falsche gebucht hat
Status 53 ist der Erfolgscode eines IDocs: Das Anwendungsdokument wurde gebucht. Für die meisten Monitoring-Konfigurationen ist ein IDoc im Status 53 abgeschlossen. Die Schnittstelle hat funktioniert. Es gibt nichts zu überwachen.
Diese Annahme stimmt für die meisten IDocs. Sie ist falsch für Nachrichtentypen, bei denen die fachliche Validierungslogik schwach ist oder bei denen das Mapping vom externen Format zum SAP-Dokument komplex ist. Ein ORDERS05-IDoc kann mit Status 53 abgeschlossen werden und einen Kundenauftrag mit falschem Warenempfänger erstellen, wenn die Partnerfindungskonfiguration eine Lücke hat. Ein DESADV-IDoc, also ein Lieferavis, kann erfolgreich gebucht werden und einen Wareneingang gegen die falsche Bestellposition erzeugen, wenn die MBLNR-Referenzverarbeitung einen Grenzfall enthält.
Diese Fehlerkategorie lässt sich nicht auf IDoc-Ebene erkennen. Sie erfordert Business-Process-Monitoring: Es muss geprüft werden, ob die von der Schnittstelle erzeugten Dokumente im Kontext Sinn ergeben. Ein Wareneingang gegen eine Bestellung, die bereits vollständig geliefert wurde, oder ein Kundenauftrag mit einer Position im Wert von null, sind Signale in den Business-Daten, die zeigen, dass eine Schnittstelle etwas gebucht hat, das sie nicht hätte buchen dürfen.
Nicht jede Schnittstelle rechtfertigt dieses Monitoring-Niveau. Relevant ist es für hochvolumige, geschäftskritische Flows, bei denen ein systematischer Datenfehler in der Buchungslogik manuell erst nach Tagen entdeckt würde und Hunderte Dokumente betreffen könnte, bevor jemand ihn bemerkt.
RFC- und qRFC-Monitoring: Verbindungen, die lebendig aussehen, es aber nicht sind
SM59-Verbindungstests sind keine Health Checks
Die Standardmethode zur Prüfung einer RFC-Destination ist der Verbindungstest in SM59: Destination auswählen, Test ausführen, grünes Ergebnis sehen. Dieser Test bestätigt, dass ein Netzwerkpfad zwischen dem SAP-System und dem Zielhost existiert und dass das Zielsystem auf einen initialen Handshake antwortet. Er bestätigt nicht, dass die Anwendung hinter dieser Verbindung läuft, dass sie eingehende RFC-Aufrufe verarbeitet oder dass das in der Destination konfigurierte Benutzerkonto die Berechtigungen besitzt, die aufgerufenen Funktionsbausteine auszuführen.
Eine RFC-Destination, die den SM59-Test besteht, obwohl die empfangende Anwendung vor 20 Minuten abgestürzt ist, wird auch beim nächsten Test weiterhin bestehen. Der Test prüft das Netzwerk, nicht die Anwendung. Diese Unterscheidung ist wichtig, wenn eine Schnittstelle still ausfällt: Ein erfolgreicher SM59-Test ist kein Beweis dafür, dass die Schnittstelle funktioniert. Ihn als solchen zu verwenden, führt zu verlorener Analysezeit.
Ein besserer Nachweis ist ein kürzlich erfolgreicher tRFC-Aufruf in SM58, der dispatcht und als empfangen bestätigt wurde, oder eine aktive qRFC-Nachricht, die verarbeitet und aus der Queue entfernt wurde. Monitoring sollte auf transaktionsbezogene Nachweise erfolgreicher Verarbeitung schauen, nicht auf verbindungsbezogene Nachweise der Netzwerkerreichbarkeit.
qRFC-Queue-Tiefe als Frühwarnsignal
Queued RFC liefert Nachrichten in FIFO-Reihenfolge an eine registrierte Queue im empfangenden System. Jede Queue hat einen Namen, einen zugeordneten Application Server und ein Verarbeitungsprogramm. Wenn alles funktioniert, gelangen Nachrichten in die Queue und werden schnell genug verarbeitet, sodass die Tiefe niedrig bleibt. Wenn die Empfängerseite langsam, ausgelastet oder nicht verfügbar ist, wächst die Queue-Tiefe.
Das Wachstum der Queue-Tiefe kommt vor harten Fehlern. Die Nachrichten schlagen noch nicht fehl. Sie warten. Aber eine Queue, die von einer normalen Tiefe von 5 auf 200 innerhalb der letzten Stunde gewachsen ist, zeigt ein System unter Stress. Sie wird irgendwann fehlschlagen, wenn die Ursache des Rückstaus nicht behoben wird. Alerts auf das Wachstum der Queue-Tiefe, statt auf Fehler in der Queue zu warten, geben dem Operations-Team Vorlaufzeit zur Untersuchung und Intervention.
Die relevanten Monitoring-Schwellenwerte sind spezifisch für jede Queue und ihr normales Verarbeitungsmuster. Eine Queue, die normalerweise bei einer Tiefe von 2 läuft und jetzt bei 50 steht, ist alarmierender als eine Queue, die während Batch-Fenstern normalerweise bei 80 liegt und jetzt 90 erreicht. Einheitliche generische Schwellenwerte über alle qRFC-Queues hinweg erzeugen bei manchen Lärm und übersehen bei anderen echte Probleme.
Blockierte Queues: was SYSFAIL und CPICERR wirklich bedeuten
Eine qRFC-Queue im Status SYSFAIL hat einen systembezogenen Fehler festgestellt: typischerweise ein Verbindungsproblem, einen Timeout oder einen Fehler bei der Queue-Registrierung im empfangenden System. Die Queue stoppt die Verarbeitung. Alle Nachrichten hinter der fehlerhaften Nachricht bleiben in der Queue. Sie werden nicht zugestellt, und für jede einzelne Nachricht wird kein separater Fehler erzeugt.
CPICERR weist auf einen CPI-C-Kommunikationsfehler hin, was typischerweise bedeutet, dass das empfangende System die Verbindung oder den Aufruf verweigert hat. Beide Zustände erfordern manuelles Eingreifen: entweder das zugrunde liegende Konnektivitätsproblem beheben und die Queue freigeben, oder die Queue auf einen anderen Application Server verlagern, wenn der registrierte Server nicht verfügbar ist.
Die Monitoring-Anforderung für blockierte Queues ist einfach und absolut: Jede Queue im Status SYSFAIL oder CPICERR in Produktion erfordert sofortige Aufmerksamkeit. Es gibt keinen akzeptablen Schwellenwert. Eine blockierte Queue in Produktion ist eine zu viel, denn eine blockierte Queue ist kein degradierter Zustand. Sie ist ein gestoppter Zustand für jede Nachricht in dieser Queue.
Achtung: Queue-Blockierungen lösen im SAP-Standardmonitoring keinen Alert aus, sofern dies nicht explizit konfiguriert wurde. Standardmäßig bleibt eine blockierte Queue still in SMQ1 liegen, bis jemand die Transaktion manuell öffnet. In Umgebungen ohne aktives qRFC-Queue-Monitoring werden blockierte Queues von Fachanwendern entdeckt, die fehlende Daten melden, nicht vom Operations-Team.
API- und Middleware-Integrationen: wo Monitoring schwieriger wird
HTTP 200 ist keine Erfolgsgarantie
REST- und SOAP-Integrationen zwischen SAP und externen Systemen nutzen HTTP als Transportschicht. HTTP-Response-Codes sind das primäre Signal für Erfolg oder Fehler auf Verbindungsebene: 200 bedeutet, dass die Anfrage empfangen und eine Antwort zurückgegeben wurde, 4xx bedeutet, dass die Anfrage abgelehnt wurde, 5xx bedeutet, dass der Server einen Fehler hatte.
Das Problem ist: 200 bedeutet, dass eine Antwort zurückgegeben wurde, nicht dass die Antwort einen Erfolg enthält. Ein empfangendes System, das den Payload angenommen, aber bei der Verarbeitung einen fachlichen Logikfehler festgestellt hat, gibt häufig HTTP 200 mit einem Fehler im Body zurück: ein JSON-Objekt mit Fehlercode, eine XML-Antwort mit Fault-Element oder eine reine Textantwort mit einer Exception-Meldung. Die SAP-seitige Integrationsschicht hat die Nachricht gesendet, einen 200 erhalten, sie als erfolgreich protokolliert und weitergemacht. Das empfangende System hat sie nicht verarbeitet.
HTTP-Integrationen nur auf Ebene des Response Codes zu überwachen, erkennt lediglich harte technische Fehler. Monitoring auf Ebene des Response Body, bei dem der Inhalt geprüft wird, ob er einen echten Erfolg statt eines verpackten Fehlers signalisiert, erkennt Fälle, in denen der Transport funktioniert hat, die fachliche Operation aber nicht. Dafür muss die Integrationsschicht eine Response-Body-Validierung implementieren, nicht nur eine Statuscode-Prüfung.
Monitoring von SAP Integration Suite und BTP-basierten Flows
SAP Integration Suite, früher SAP Cloud Platform Integration, routet und transformiert Nachrichten zwischen SAP und externen Systemen. Ihre Fehlermuster unterscheiden sich von direkten RFC- oder IDoc-Schnittstellen, weil sie eine zusätzliche Ebene mit eigener Fehlerbehandlung, Retry-Logik und Message Store einführt.
Ein Integration-Suite-Flow kann auf verschiedene Arten fehlschlagen, die auf SAP-Seite nicht sichtbar sind: Der Flow-Adapter erreicht den Zielendpunkt nicht, die Nachrichtentransformation erzeugt einen Mapping-Fehler, die Retry-Policy schöpft alle Versuche aus und die Nachricht wird in die Fehlerqueue verschoben. All diese Zustände sind in der Operations-Ansicht der Integration Suite im BTP-Cockpit sichtbar, nicht in einer SAP-Transaktion.
Für SAP-Teams, die an Monitoring über ABAP-basierte Transaktionen gewöhnt sind, entsteht dadurch eine Sichtbarkeitslücke. Das SAP-System hat die Nachricht erfolgreich an Integration Suite gesendet. Dort ist das Problem entstanden. Ohne Monitoring-Abdeckung über beide Ebenen, die ABAP-SAP-Schicht und die BTP-Schicht, beginnt die Untersuchung mit nur der halben Realität.
Praktisch bedeutet das: Schnittstellen-Monitoring für BTP-integrierte Landschaften muss das BTP-Operations-Monitoring explizit in den Scope aufnehmen, nicht als etwas behandeln, das das Cloud-Team separat erledigt. Message-Error-Zahlen, fehlgeschlagene Flow-Instanzen und Adapter-Fehlerraten aus Integration Suite sind für das Gesamtbild der Schnittstellengesundheit genauso relevant wie SM58- und BD87-Daten.
Ablauf von SSL-Zertifikaten: der vermeidbarste Schnittstellenausfall
SSL-Zertifikate auf RFC-Destinationen, HTTPS-Endpunkten und Middleware-Connectors laufen ab. Wenn sie ablaufen, schlägt die Verbindung mit einem Zertifikatsvalidierungsfehler fehl, und die Schnittstelle stoppt sofort. Keine schrittweise Verschlechterung, keine Warnphase, keine automatische Verlängerung in den meisten SAP-Konfigurationen.
Das ist eine der vermeidbarsten Kategorien von Schnittstellenfehlern. Ein Zertifikatsablauf ist planbar. Das Ablaufdatum ist im Voraus bekannt. Ein Alert 30 Tage vor Ablauf gibt dem Team Zeit, das Zertifikat ohne Dringlichkeit zu erneuern und auszurollen. Ein Alert 7 Tage vorher reicht in den meisten Fällen ebenfalls aus. Kein Alert bedeutet Entdeckung zum Ablaufzeitpunkt, während der Arbeitszeit, wenn das Team Glück hat, am Wochenende, wenn es Pech hat.
Das Monitoring des Ablaufs von SSL-Zertifikaten ist nicht komplex. Es benötigt eine Liste von Endpunkten mit Zertifikaten, eine geplante Prüfung des Ablaufdatums jedes Zertifikats und einen Alert-Schwellenwert. Das Setup dauert einige Stunden. Der Schnittstellenausfall, den es verhindert, dauert deutlich länger zu beheben, besonders wenn die Zertifikatserneuerung eine externe CA einbindet und Vorlaufzeit braucht.
End-to-End-Flow-Monitoring: technische Gesundheit mit Business-Ergebnissen verbinden
Wenn die Schnittstelle funktioniert, der Geschäftsprozess aber nicht
Technisches Schnittstellen-Monitoring, das IDoc-Status, RFC-Queues und HTTP-Codes abdeckt, zeigt, ob die Datentransportschicht funktioniert. Es zeigt nicht, ob der Geschäftsprozess funktioniert, der von diesen Daten abhängt. Eine Schnittstelle kann jede Nachricht fehlerfrei verarbeiten, während der unterstützte Geschäftsprozess nicht mehr funktioniert, weil die verarbeiteten Daten falsch sind.
Das Beispiel, das in der Praxis am häufigsten vorkommt: Eine eingehende ORDERS05-Schnittstelle verarbeitet ohne Fehler und erstellt Kundenaufträge in SAP, während eine im sendenden System aktualisierte Preiskondition in der SAP-Preisfindung nicht berücksichtigt wird. Jeder Auftrag wird gebucht. Jedes IDoc erreicht Status 53. Das Business entdeckt den Preisfehler, wenn die ersten Rechnungen mit falschen Beträgen ausgehen. Das technische Monitoring war die ganze Zeit grün.
Business-Process-Monitoring schließt diese Lücke, indem es Ergebnisse prüft, nicht nur den Transportstatus. Hatten die von der Schnittstelle erstellten Kundenaufträge die erwarteten Margenbereiche? Wurden Bestandsbewegungen an die erwarteten Lagerorte gebucht? Wurden eingehende Rechnungen automatisch abgeglichen, oder mussten sie ungewöhnlich häufig manuell geprüft werden? Das sind Business-Layer-Signale, die technisches Schnittstellen-Monitoring nicht liefert.
Die Einführung von Business-Flow-Monitoring erfordert Zusammenarbeit zwischen IT Operations und Prozessverantwortlichen, um zu definieren, wie ein gesundes Ergebnis für jede Schnittstelle aussieht. Es ist aufwendiger aufzubauen als Statuscode-Monitoring. Es erkennt jedoch den Fehlermodus, der die teuersten Vorfälle verursacht: die korrekte Verarbeitung falscher Daten.
Volumenanomalie-Erkennung als Ergänzung zum Fehler-Alerting
Jede Schnittstelle in Produktion hat ein normales Volumenmuster. Manche sind konstant und verarbeiten während des Geschäftstags einen stetigen Nachrichtenfluss. Manche sind batch-orientiert, erzeugen zu einem bestimmten Zeitpunkt einen Peak und werden danach ruhig. Andere hängen vom Kalender ab, mit höheren Volumen an bestimmten Tagen oder zu bestimmten Zeitpunkten im Monat.
Eine Volumen-Baseline pro Schnittstelle, Stunde und Wochentag ermöglicht eine Alert-Kategorie, die Fehler-Monitoring nicht liefern kann: den Alert, der auslöst, wenn eine normalerweise aktive Schnittstelle still wird. Null verarbeitete Nachrichten in den letzten 30 Minuten bei einer Schnittstelle, die normalerweise 200 pro Stunde verarbeitet, ist kein Fehlerzustand. Es ist eine Abwesenheit. Aber diese Abwesenheit stellt ein Business-Risiko dar, das dem Risiko einer fehlerverarbeitenden Schnittstelle entspricht: Der nachgelagerte Prozess erhält keine Daten.
Volumenanomalie-Erkennung benötigt mindestens vier Wochen Baseline-Daten, bevor Alert-Schwellenwerte belastbar sind, weil wöchentliche und monatliche Muster erfasst werden müssen, um echte Anomalien von erwarteten Low-Volume-Zeiten zu unterscheiden. Der Konfigurationsaufwand lohnt sich für Schnittstellen, die kritisch genug sind, dass ein zweistündiger Volumenabfall sichtbare Business-Auswirkungen hätte.
Referenz für die Abdeckung des Schnittstellen-Monitorings
Die folgende Tabelle ordnet die in diesem Artikel besprochenen Monitoring-Metriken nach Ebene, mit der relevanten SAP-Quelle oder Ansicht, einem praktischen Alert-Schwellenwert und der empfohlenen Monitoring-Aktion.
| Metrik | Quelle / Ansicht | Alert-Schwellenwert | Maßnahme |
|---|---|---|---|
| IDOC-EBENE | |||
| Anzahl fehlerhafter IDocs | BD87 / WE05 | Jeder Fehler in Produktion | Sofort alerten, inklusive IDoc-Nummer, Nachrichtentyp und Partner. |
| IDocs, die in Status 02/12/64 hängen | WE05 / WE09 | Mehr als 10 Einträge älter als 30 Minuten | Hinweis darauf, dass das EDI-Subsystem nicht verarbeitet oder die eingehende Queue blockiert ist. |
| IDoc-Volumen nach Nachrichtentyp | WE05 aggregiert | Abfall über 30 % gegenüber dem Stundendurchschnitt | Volumenanomalien erkennen stille Ausfälle, bevor Fehler auftreten. |
| Anzahl fehlgeschlagener IDoc-Retries | BD87 | Mehr als 3 Retries auf demselben IDoc | Wiederholte Fehler zeigen ein systemisches Problem, keinen transienten Vorfall. |
| RFC- / QRFC-EBENE | |||
| Hängende SM58-Einträge | SM58 | Jeder Eintrag älter als 5 Minuten in Produktion | tRFC-Einträge, die nicht verarbeitet werden, weisen auf Empfänger- oder Netzwerkprobleme hin. |
| qRFC-Queue-Tiefe ausgehend | SMQ1 | Mehr als 50 Einträge dauerhaft | Queue-Aufbau zeigt, dass der Empfänger langsam ist oder nicht reagiert. |
| qRFC-Queue-Tiefe eingehend | SMQ2 | Mehr als 50 Einträge dauerhaft | Eingehender Rückstau beeinträchtigt die Buchungslatenz aller abhängigen Prozesse. |
| Blockierter Queue-Status, SYSFAIL/CPICERR | SMQ1 / SMQ2 | Jede blockierte Queue | Eine blockierte Queue stoppt alle nachfolgenden Nachrichten in dieser Queue, unabhängig vom Inhalt. |
| HTTP- / API-EBENE | |||
| HTTP-Fehlerrate pro Endpunkt | ICM-Logs / Middleware | Mehr als 1 % über ein 15-Minuten-Fenster | HTTP-500- und 503-Raten weisen auf Instabilität auf Empfängerseite hin. |
| Trend der API-Antwortzeit | Middleware / BTP | Mehr als 2x Baseline dauerhaft | Wachsende Latenz geht harten Fehlern oft voraus. Erkennen, bevor SLAs verletzt werden. |
| Ablauf von SSL-Zertifikaten | Certificate Store | Weniger als 30 Tage bis Ablauf | Alert bei 30 Tagen. Abgelaufene Zertifikate verursachen sofortige Verbindungsfehler ohne sanfte Degradation. |
| Fehlerrate von Integration-Suite-Flows | SAP BTP Operations | Mehr als 0,5 % pro Stunde | BTP-Flows können ohne ITSM-Integration still fehlschlagen. Auf Plattformebene überwachen, nicht nur SAP-seitig. |
| BUSINESS-FLOW-EBENE | |||
| Order-to-Delivery-Lücke | Custom ABAP / Monitoring | Offene Aufträge länger als X Stunden ohne Lieferungserstellung | Erkennt Schnittstellenfehler, die ohne Fehler verarbeitet wurden, aber keine nachgelagerten Schritte ausgelöst haben. |
| Match-Rate eingehender Rechnungen | Custom ABAP / Monitoring | Unter 95 % automatischer Abgleich | Sinkende Match-Rate weist auf Datenqualitätsprobleme im eingehenden Schnittstellen-Payload hin. |
| Nachrichtenvolumen vs. Business-Kalender | Interface Monitor | Volumenabfall an erwartetem Hochlasttag | Null Nachrichten an einem Montagmorgen, wenn Bestellungen fließen sollten, ist ein businessrelevantes Signal. |
Die Schnittstellenebene ist der Ort, an dem die meisten SAP-Blind Spots entstehen
Schnittstellen-Monitoring erhält weniger systematische Aufmerksamkeit als Application-Server- oder Datenbank-Monitoring, teils weil es mehrere Systeme und Verantwortungsgrenzen umfasst, teils weil die Fehlermuster weniger offensichtlich sind. Eine Datenbank, die nicht mehr reagiert, ist sofort sichtbar. Eine Schnittstelle, die Nachrichten verarbeitet, ohne Business-Ergebnisse zu liefern, erfordert eine andere Art von Aufmerksamkeit, um erkannt zu werden.
Die Abdeckung, die den Unterschied macht, kombiniert drei Ebenen. Technisches Transport-Monitoring, das IDoc-Status, RFC-Queues und API-Fehlerraten abdeckt, ist die Basis. Die Volumenanomalie-Erkennung ist die Ebene, die Ausfälle erkennt, die keine Fehler erzeugen. Business-Flow-Monitoring ist die Ebene, die Ausfälle erkennt, bei denen der Transport korrekt ist, die Ergebnisse aber falsch sind.
Die meisten SAP-Landschaften haben irgendeine Version der ersten Ebene. Nur wenige haben die zweite, und noch weniger die dritte. Die Lücke zwischen der ersten Ebene allein und allen drei Ebenen ist die Lücke zwischen Monitoring, das erkennt, was SAP ausdrücklich als falsch markiert, und Monitoring, das erkennt, was das Business irgendwann als falsch melden wird. Letzteres verhindert den Anruf am Freitagnachmittag, warum die Lieferungen der letzten Woche nicht versendet wurden.
Redpeaks überwacht SAP-Schnittstellen über IDoc-, RFC-, qRFC-, HTTP- und BTP-Ebenen hinweg aus einer einzigen agentenlosen Verbindung, mit Alerting auf Basis von Volumen-Baselines und ITSM-Integration, die jeden Alert-Typ an das richtige Team weiterleitet.
