Stefan Rubsch
 - 20. März 2020

Wie das Applikationsmanagement für SAP PI die Geschäftsprozesse am Laufen hält

SAP PI

Das Applikationsmanagement für SAP PI unterscheidet sich grundlegend vom Support für viele andere Applikationen, da es sich um eine reine Middleware ohne fachlichen Bezug handelt. Anders als z. B. bei SAP HR, wo fachliche Daten des Personalwesens verwaltet werden, besteht das Ziel der SAP PI nur darin, den Verkehr von Nachrichten zwischen verschiedenen Applikationen zu regeln. Wie Application Management Services für SAP PI die Informationsübermittlung zwischen den Applikationen am Laufen halten und welchen Missverständnissen das Applikationsmanagement hierbei ausgesetzt ist, lesen Sie in diesem Blogartikel.

Eine häufige Herausforderung besteht darin, dass der fachliche Hintergrund der Nachrichten, die zwischen den verschiedenen Fachapplikationen ausgetauscht werden, dem Applikationsmanagement der SAP PI verborgen bleiben. Die SAP PI verbindet als Middleware verschiedenste Applikationen miteinander. Daher vermitteln Application Management Services (AMS) häufig zwischen dem Applikationssupport von Sende- und Empfangsapplikation. Um das effektiv zu tun, ist es allerdings notwendig, über den Tellerrand zu blicken und nicht nur auf die eigene Applikation fokussiert zu sein.

Fehlerbehebung dank AMS

Ein alltägliches Beispiel dazu sind Störungen, die nicht nur die Funktion einzelner Applikationen betreffen, sondern fachlich übergeordnete Geschäftsprozesse, bei denen mehrere Applikationen unterschiedlicher Art beteiligt sind. In diesem Fall liegt die Ursache für die Störung selten bei der SAP PI. Für die Analyse der Störung sind allerdings Application Management Services der PI meist unverzichtbar, da sie den Nachrichtenverkehr auf der SAP PI nachvollziehen und somit die Menge der potenziellen Fehlerquellen eingrenzen können.

Häufig ist es so, dass Informationen aus System A an System B übermittelt werden sollen, dort jedoch nicht ankommen. In diesem Fall kann mithilfe der PI analysiert werden, ob die fehlende Nachricht tatsächlich von System A abgeschickt bzw. von System B empfangen wurde. Nicht selten stellt sich dann heraus, dass das System die Nachricht in Wahrheit gar nicht abgeschickt hat, weil es aufgrund fehlerhafter Werte zu einem Laufzeitfehler kam. Dank der AMS der SAP PI musste dabei nicht gleich zu Beginn an allen erdenklichen Stellen nach Fehlern gesucht werden. Stattdessen konnte es direkt zielgerichtet auf System A analysiert werden.

Ein anderer Mehrwert, den AMS bieten, ist, dass sie Störungen früh identifizieren und die beteiligten Applikationen schnell darauf aufmerksam machen. Durch diese Art des proaktiven Incident Managements können technische Störungen teilweise behoben werden, bevor sie überhaupt einen negativen Business Impact hervorrufen. Mit dem richtig agierenden AMS wirkt die SAP PI somit stabilisierend auf den Geschäftsbetrieb.

Missverständnisse gegenüber AMS für SAP PI

Zu beachten ist, dass Application Management Services häufig mit bestimmten Erwartungen konfrontiert werden, die sie nicht erfüllen können. Aufgrund des proaktiven Incident Managements sind die sie häufig der Überbringer schlechter Nachrichten. Diese haben nicht selten zur Folge, dass die SAP PI mit Störungen assoziiert wird. Andere AMS-Bereiche sehen dann die Ursache häufig bei der PI. Ein anderes Missverständnis besteht darin, dass der Support der SAP PI auch für Netzwerkfragen der richtige Ansprechpartner sei. Zuletzt kommt es gelegentlich vor, dass Störungen, bei denen die verursachende Applikation unklar ist, gerne der PI zugeschoben wird.

All diese Herausforderung lassen sich jedoch meistern, indem der AMS der SAP PI anderen Beteiligten die eigene Rolle erklärt und sich dadurch klar von benachbarten Abteilungen abgrenzt. Dazu eignen sich z. B. Kick-Off-Termine. Hier wird den Kollegen aus anderen Bereichen verdeutlicht, bei welchen Fragen der PI-Support der richtige Ansprechpartner ist und bei welchen nicht.

Durch proaktives Handeln zu einem besseren Incident Management

Nicht nur beim Incident Management, sondern auch bei der Kommunikation mit der Entwicklung lohnt sich eine proaktive Herangehensweise. Als Middleware laufen hunderttausende von Nachrichten über die SAP PI. Das führt schnell zu einer hohen Auslastung des Systems, auf dem die Applikation läuft. Je komplexer Unternehmensprozesse sind, desto größer sind auch die Anforderungen an die Middleware.

Auch aufgrund externer Einflüsse, wie z. B. staatlicher Regulationen, werden Unternehmensprozesse im Allgemeinen stetig komplexer statt einfacher. Die Anzahl der Schnittstellen, über die verschiedene Applikationen die SAP PI ansprechen, nimmt dabei stetig zu. Daher besteht die Gefahr, dass die SAP PI über die Zeit – salopp gesagt – „zumüllt“, da alte Schnittstellen häufig durch neue ersetzt und damit obsolet werden. Im Worst Case senden die beteiligten Systeme weiterhin Nachrichten über diese Schnittstelle, obwohl sie gar nicht mehr benötigt werden. Das führt zu einer unnötigen Beanspruchung der SAP PI und verringert zudem die Übersicht, was bei der Analyse von Störungen negativ zu tragen kommt.

Im Optimalfall geht der AMS der PI proaktiv auf die Entwicklung zu und macht sie darauf aufmerksam, dass die jeweilige Schnittstelle nicht mehr benötigt wird. Hier müssen auch die AMS-Bereiche der beteiligten Applikationen und deren Entwicklungen mit ins Boot geholt werden. Auch, wenn der organisatorische Aufwand zunächst beträchtlich ist, so ist er dennoch in jedem Fall lohnenswert. Alle Applikationen stellen sicher, dass nur noch Daten verteilt werden, die tatsächlich benötigt werden und somit Wartbarkeit und Erweiterbarkeit vereinfacht werden. Für die SAP PI ist dies ebenfalls unerlässlich, um den stabilen Betrieb gewährleisten zu können.

Erfahrungswerte aus dem 2nd-Level-Support

Unsere Erfahrungen aus dem 2nd-Level-Support der SAP PI lassen sich wie folgt zusammenfassen:

  • Als reine Middleware unterscheidet sich die SAP PI grundlegend von den meisten anderen Applikationen, da sie keine reellen Geschäftsprozesse abbildet.
  • Daraus ergibt sich, dass der Support der Applikation ein besonderes Maß an Überblick über die verschiedenen Prozesse der PI erfordert.
  • Der 2nd-Level-Support der SAP PI zeichnet sich im Incident Management dadurch aus, dass er zwischen den Verantwortlichen der beteiligten Applikationen vermittelt, um so die Störungsbehebung zu beschleunigen.
  • Die SAP PI selbst ist nur selten die Ursache für Störungen. Allerdings unterstützt der AMS der SAP PI das Incident Management, indem er bei der Analyse den Verlauf der versendeten Nachricht zwischen den beteiligten Systemen nachvollzieht.
  • Der Support der SAP PI agiert proaktiv und hilft dabei, Störungen zu beheben, bevor sie einen Business Impact erzeugen.

Haben Sie zum Thema Applikationsmanagement für SAP PI noch weitere Fragen? Melden Sie sich gerne bei uns. Wenn Sie ebenfalls Unterstützung durch Application Management Services für Ihr SAP PI oder andere IT-Bereiche in Ihrem Unternehmen benötigen, empfehlen wir Ihnen die Angebote des mind Managed Supports.

Stefan Rubsch

Stefan Rubsch

Mein Name ist Stefan Rubsch und ich bin begeisterter SAP Consultant bei mindsquare. Wie meine Kollegen habe ich mein Hobby zum Beruf gemacht.

Sie haben Fragen? Kontaktieren Sie mich!



Das könnte Sie auch interessieren


Schreiben Sie einen Kommentar

Bitte füllen Sie alle mit * gekennzeichneten Felder aus. Ihre E-Mail Adresse wird nicht veröffentlicht.





Angebot anfordern
Preisliste herunterladen
Expert Session
Support