SAP Integration Suite Monitoring nach PI/PO: 7 Veränderungen im Betrieb

SAP Integration Suite Monitoring nach PI/PO: 7 Veränderungen im Betrieb

Der Wechsel von SAP PI/PO zur SAP Integration Suite verändert nicht nur die Integrationsplattform. Auch die Art, wie Integrationsteams Nachrichten überwachen, Fehler analysieren und fehlgeschlagene Prozesse erneut anstoßen, verändert sich.

Wer viele Jahre mit SAP Process Integration oder Process Orchestration gearbeitet hat, kennt Werkzeuge und Abläufe wie Message Monitoring, NWA oder die detaillierte Analyse einzelner Adapter. Nach der Migration zur SAP Integration Suite funktionieren viele dieser gewohnten Muster nicht mehr eins zu eins.

Das bedeutet jedoch nicht, dass weniger Informationen zur Verfügung stehen. Vielmehr verschiebt sich der Fokus: von der technischen Analyse einzelner Middleware-Komponenten hin zur Überwachung von Integration Flows, Message Processing Logs und klar definierten Verarbeitungsschritten.

Welche Veränderungen sollten Teams beim Monitoring besonders berücksichtigen?

1. Nicht mehr die einzelne Nachricht steht im Mittelpunkt, sondern ihre Verarbeitung im Integration Flow

In SAP PI/PO orientiert sich die Fehlersuche häufig stark an Message IDs, Kommunikationskanälen und technischen Verarbeitungsschritten.

In der SAP Integration Suite übernimmt das Message Processing Log (MPL) eine zentrale Rolle. Es enthält Informationen zu verarbeiteten Nachrichten sowie zu einzelnen Verarbeitungsschritten innerhalb eines Integration Flows.

Für Betriebsteams bedeutet das eine Umstellung in der Denkweise.

Die entscheidende Frage lautet nicht mehr ausschließlich: „Welche Nachricht ist fehlgeschlagen?“ Sondern zunehmend: „In welchem Schritt des Integration Flows ist die Verarbeitung fehlgeschlagen?“

Gerade nach einer PI/PO-Migration sollte deshalb nicht versucht werden, das bisherige Monitoring-Konzept unverändert auf die neue Plattform zu übertragen.

2. Trace sollte gezielt für die Fehleranalyse eingesetzt werden

Ein weiterer Unterschied zeigt sich bei der Detailanalyse.

In SAP Integration Suite kann für einen Integration Flow das Log Level Trace aktiviert werden. Dadurch lassen sich unter anderem Payload, Header und Properties während verschiedener Verarbeitungsschritte untersuchen.

SAP empfiehlt Trace beziehungsweise Debug jedoch insbesondere für Entwicklungs- und Testumgebungen und nicht als permanenten Monitoring-Modus.

Für den produktiven Betrieb braucht es deshalb ein bewusstes Logging-Konzept.

·        Welche Informationen werden standardmäßig protokolliert?

·        Welche Daten werden nur im Fehlerfall benötigt?

·        Wann wird Trace aktiviert?

·        Welche Informationen müssen über Custom Header auffindbar sein?

3. Geschäftliche Identifikatoren werden für die Suche wichtiger

Eine technische Message ID allein reicht im Support häufig nicht aus.

Ein Fachbereich meldet normalerweise nicht: „MPL 12345 ist fehlgeschlagen.“ Die Meldung lautet eher: „Auftrag 4711 wurde nicht übertragen.“

Genau deshalb sollten relevante Geschäftsidentifikatoren bereits beim Design eines Integration Flows berücksichtigt werden.

Custom Header Properties können beispielsweise dazu genutzt werden, Nachrichten anhand bestimmter Informationen im Message Processing Log wiederzufinden.

Damit wird aus rein technischem Monitoring ein Monitoring, das auch reale Geschäftsprozesse nachvollziehbar macht.

·        Bestellnummer

·        Rechnungsnummer

·        IDoc-Nummer

·        Liefernummer

·        Business Partner

·        Quellsystem

·        Zielsystem

4. Die Qualität des iFlow-Designs beeinflusst die Fehleranalyse direkt

In PI/PO konnten erfahrene Entwickler häufig über technische Logs sehr tief in die Verarbeitung einsteigen.

In der SAP Integration Suite spielt dagegen die Struktur des Integration Flows eine entscheidende Rolle.

Wenn ein iFlow viele Transformationen, Skripte, Routing-Entscheidungen und Aufrufe externer Systeme in schwer nachvollziehbaren Blöcken kombiniert, wird auch das Monitoring komplizierter.

Eine klar strukturierte Integration erleichtert dagegen die Frage: „Wo genau ist die Verarbeitung fehlgeschlagen?“

Deshalb sollten Integration Flows nicht nur mit Blick auf die technische Funktion entwickelt werden. Wartbarkeit und Fehleranalyse gehören bereits in die Designphase.

5. Retry funktioniert anders als klassisches „erneut senden“

Auch beim Umgang mit temporären Fehlern sollten PI/PO-erfahrene Teams ihre Betriebsprozesse überprüfen.

SAP Integration Suite unterstützt unterschiedliche Retry-Szenarien. Eine Möglichkeit besteht darin, Nachrichten über JMS Queues zwischenzuspeichern.

Schlägt die Verarbeitung beispielsweise aufgrund eines vorübergehenden Problems bei einem externen System fehl, kann die Nachricht in der Queue verbleiben und erneut verarbeitet werden.

Für den Betrieb entstehen dadurch neue Fragen: Befindet sich die Nachricht noch in einer Queue? Läuft bereits ein Retry? Ist der Fehler temporär oder dauerhaft? Muss überhaupt manuell eingegriffen werden?

Ein fehlgeschlagener Verarbeitungsschritt bedeutet also nicht automatisch, dass eine Nachricht endgültig verloren ist.

6. Payload Logging sollte bewusst und selektiv geplant werden

Bei der Fehlersuche ist der erste Wunsch häufig: „Zeig mir die komplette Nachricht.“

Technisch ist das in vielen Situationen möglich. Trotzdem sollte eine produktive Monitoring-Strategie nicht darauf basieren, jede Payload dauerhaft mitzuschreiben.

Für Unternehmen bedeutet das: So viel Logging wie für Support und Nachvollziehbarkeit notwendig – aber nicht automatisch so viel wie technisch möglich.

Das ist besonders relevant bei hohen Nachrichtenvolumen und bei Daten, die aus Sicherheits- oder Datenschutzgründen nicht unnötig in Logs gespeichert werden sollten.

7. Monitoring muss Teil des Migrationsprojekts sein

Ein häufiger Fehler bei PI/PO-Migrationen besteht darin, sich hauptsächlich auf die erfolgreiche technische Übertragung der Schnittstellen zu konzentrieren.

Doch ein Integration Flow ist erst dann produktionsbereit, wenn auch geklärt ist, wie er später betrieben wird.

Monitoring ist damit kein Thema, das erst nach der Migration beginnt. Es ist Teil der Zielarchitektur.

·        Wer überwacht fehlgeschlagene Nachrichten?

·        Nach welchen Kriterien werden Alerts ausgelöst?

·        Welche Informationen benötigt der Support?

·        Welche Fehler werden automatisch erneut verarbeitet?

·        Wann ist ein manueller Eingriff erforderlich?

·        Wie lassen sich Nachrichten anhand fachlicher Kriterien suchen?

·        Welche Logging-Regeln gelten für Produktionssysteme?

SAP PI/PO und SAP Integration Suite: Was verändert sich beim Monitoring?

Fazit: Nicht nur Schnittstellen migrieren, sondern auch das Betriebsmodell

Der Wechsel von SAP PI/PO zur SAP Integration Suite ist mehr als die Übertragung vorhandener Schnittstellen auf eine neue technische Plattform.

Auch Monitoring, Logging, Retry und Fehleranalyse sollten neu betrachtet werden.

Wer versucht, die Arbeitsweise aus PI/PO unverändert fortzuführen, wird sich in der neuen Umgebung zunächst schwerer orientieren. Wer dagegen bereits während der Migration definiert, wie Integration Flows strukturiert, Nachrichten identifiziert und Fehler im späteren Betrieb analysiert werden sollen, schafft eine deutlich bessere Grundlage für den produktiven Betrieb.

Planen Sie aktuell den Wechsel von SAP PI/PO zur SAP Integration Suite? MDP Group unterstützt Unternehmen bei der Analyse bestehender Integrationslandschaften, der Migrationsplanung sowie bei der Umsetzung und dem Betrieb von Integrationsszenarien mit SAP Integration Suite.