Performance-Modellierung einer SAP BPM-Anwendung

Ich studiere Wirtschaftsinformatik an der TU München. „Performance-Modellierung einer SAP BPM-Anwendung“ war das Thema meiner Bachelor Thesis, die ich bei IBsolution geschrieben habe. Dafür habe ich aktiv in einem Kundenprojekt bei IBsolution mitgearbeitet. Ziel dieses Gesamtprojektes der IBsolution war es, eine bestehende Stammdatenlösung auf der Basis von SAP Master Data Management (MDM) und SAP Business Process Management (BPM) effizient weiterzuentwickeln. Dabei rückte das Thema Performance als wichtiges Qualitätskriterium in den Vordergrund, weshalb Performance-Analysen unabdingbar für die Entwicklung wurden. In diesem Blogbeitrag möchte ich meine Untersuchungsergebnisse in kondensierter Form vorstellen.

Hintergrund meiner Arbeit

Damit Unternehmen in einem dynamischen und konkurrenzstarken Geschäftsumfeld langfristig erfolgreich agieren, spielen effiziente und flexible Geschäftsprozesse eine bedeutende Rolle. Um diese Anforderungen zu unterstützen, bietet SAP BPM Vorgehensmodelle, Methoden, Technologien und Referenzinhalte für die Modellierung, die Konfiguration, die Ausführung und das Monitoring von End-zu-End-Geschäftsprozessen. Unternehmen können mit dieser Lösung schnell auf eine Anforderung reagieren (z. B. durch eine Prozessänderung) oder unternehmenseigene Prozesse effektiver gestalten (z. B. durch die Automatisierung von Entscheidungen).

Dadurch ergeben sich für die Entwicklung von Anwendungen, die mit BPM umgesetzt werden, große Herausforderungen. Neben den funktionalen Anforderungen existiert eine Vielzahl ebenso wichtiger nicht-funktionaler Anforderungen wie Performance. Dabei kann beispielsweise anhand der Antwortzeiten gemessen werden, wie viel Zeit das System für Nutzeranfragen benötigt. Zur Analyse und Optimierung der Performance eines Systems stehen verschiedene Ansätze zur Verfügung, zum Beispiel Lasttests oder Simulationen durch Modelle. Insbesondere Modelle unterstützen die Entwickler dabei, Performance-Auswirkungen bereits in den frühen Entwicklungsphasen zu erkennen und vorherzusagen. Das Palladio Component Model (PCM) eignet sich vor allem für die Modellierung komponentenbasierter Software und wurde daher auch für die im Folgenden beschriebene Beispielanwendung der Neuanlage des Geschäftsobjekts Kunde verwendet. Im Rahmen meiner Arbeit wurde eine bestehende SAP BPM-Anwendung in ein PCM überführt und mit realen Messwerten verglichen. Anhand der Ergebnisse konnte ich feststellen, inwieweit das erstellte Modell die Realität widerspiegelt und ob es als Referenz für weitere Arbeiten verwendet werden kann.

Architektur der SAP-Anwendung

Das Ziel des Systems ist eine Bereitstellung von Stammdatenservices in der Kundenumgebung. Diese umfassen ein zentrales Repository für die Stammdaten in einem standardisierten Modell, eine Plattform für Stammdatenprozesse, ein zentrales Stammdatenverteilungssystem sowie Services für die Datenqualität und -migration. Die Stammdatenpflege beruht auf drei Geschäftsobjekten: Customer (Kunde), Vendor (Lieferant) und Material, wobei der Fokus meiner Arbeit nur auf dem Geschäftsobjekt Kunde liegt.

Über das SAP Enterprise Portal melden sich die Benutzer am System an und können ihre zugewiesenen Aufgaben in der Universal Work List (UWL, Inbox für alle anfallenden und zugewiesenen Aufgaben) bearbeiten oder je nach Rolle des Users einen neuen Prozess starten. Innerhalb des Portals sind die SAP Master Data Management (MDM) Web-Dynpro-Applikationen eingebettet, die aus den Web-Dynpro-Komponenten zusammengesetzt sind. Dabei gibt es zwei zentrale Anwendungen: die Search Application und die Main Application.

Der Prozessablauf wird vom SAP NetWeaver Business Process Management (BPM) und vom SAP NetWeaver Business Rules Management (BRM) gesteuert, die anhand von Nutzerinformationen bereitgestellt werden. Über das Service Enablement werden externe Webservices aufgerufen, um beispielsweise länderspezifische Steuerprüfungen durchzuführen. Die Logik für die individuellen Geschäftsfälle ist in der Java Business Logic implementiert. Für die Verwaltung der Stammdaten ist das MDM eingebunden.

Das Repository, in dem die Datenmodelle konfiguriert und die Stammdaten gespeichert werden, basiert auf SAP NetWeaver MDM und bildet den Kern der Stammdatenlösung. Verbunden ist das MDM einerseits mit der SAP Netweaver Composition Environment (CE), auf der der Fokus der Modellierung in diesem Projekt liegt, und andererseits mit der SAP Process Integration (PI). Die beiden Server, der Import und der Syndication Server, sind einerseits dafür zuständig, die Daten aus dem SAP Enterprise Resource Planning (ERP) in das Repository zu laden, und andererseits vom Repository in das ERP zu syndizieren. Das geschieht über verschiedene Ports in der PI.

Prozess

Alle Prozesse werden von der Suchanwendung aus gestartet. Je nach Prozesstyp ist es eventuell notwendig, zuvor einen bestimmten Kunden anhand der Suchfunktion auszuwählen und dadurch beispielsweise einen Change- oder Block-Prozess zu starten. Um einen neuen Kunden anzulegen, reicht es aus, den Create-Button zu drücken und den Prozess sowie die Hauptanwendung zu starten.

Im ersten Fenster der Applikation wählt der Antragsteller ein Template aus, wodurch bereits vordefinierte Daten für den Kunden angelegt werden. Ist das Template gewählt, können im nächsten Schritt die Kundendaten, zum Beispiel Adressdaten, eingegeben oder geändert werden. Falls der Kunde anhand seiner Adresse auf einer Karte angezeigt werden soll, ist ein Webservice mit eingebunden, der ein neues Fenster mit Google Maps öffnet. Bevor die Anfrage abgeschlossen und dem Genehmiger zum Bestätigen weitergeleitet wird, wird ein Dublettencheck durchgeführt, um zu prüfen, ob der Kunde eventuell bereits im System angelegt ist. Aus diesem Grund und aus anderen Gründen besteht die Möglichkeit, die Anfrage zu beenden und den Prozess abzubrechen. Zudem ist es noch möglich, zusätzliche Informationen zum jeweiligen Kunden einzugeben. Abschließend wird die Anfrage an den ersten Genehmiger weitergeleitet und in seine UWL verlinkt

Im nächsten Prozessschritt hat der Genehmiger die Möglichkeit, entweder die Anfrage anzunehmen oder als Rework an den Antragsteller zurückzusenden, damit dieser die Daten ändern kann, oder als Reject komplett zu verwerfen. Der Genehmiger kann jeweils einen Kommentar zur Begründung beifügen und eine Benachrichtigung wird an alle am Prozess beteiligten Nutzer gesendet. Sollte der Antrag genehmigt werden, wird er an den finalen Genehmiger weitergeleitet, der dieselben Möglichkeiten wie der erste hat.

Haben schließlich alle Genehmiger den Antrag bewilligt, wird die Syndizierung durchgeführt, um den neuen Kunden in die ERP-Systeme zu verteilen. Sollte dort etwas fehlschlagen, wird eine Mitteilung zusammen mit einem Task an den ersten Genehmiger geschickt. Entweder kann dieser ein Error Handling ausführen, bei dem zehn Minuten gewartet und eine erneute Syndizierung versucht wird, oder der Task kann sowohl offen als auch geschlossen zum Support gesendet werden, damit sich ein Experte um das Problem kümmert.

Bei erfolgreicher Syndizierung in das ERP wird der neuen Datensatz im MDM-Repository eingecheckt, um ihn frei verfügbar und änderbar zu machen. Im MDM ausgecheckte Objekte können so lange nicht bearbeitet oder gepflegt werden, bis der Bearbeiter den Prozess abschließt.

Für die spätere Performance-Modellierung habe ich den Anwendungsfall „Kunde erstellen“ als Usage-Model modelliert und anschließend simuliert.
 Um bei der Simulation geeignete Ergebnisse erzielen zu können, müssen zuvor die wichtigsten Performance-Metriken definiert werden, damit eine Vergleichsanalyse zwischen Simulation und Messung am System durchgeführt werden kann. Diese lauten wie folgt:

• Antwortzeit

• Durchsatz

• Ressourcennutzung

Es war nicht möglich, alle möglichen Anwendungsfälle und Szenarien durchzuführen, da sich die zu erwartende Menge an Daten auf ein nicht handhabbares Maß belaufen hätte. Daher habe ich in meiner Arbeit anhand eines häufig vorkommenden Szenarios Messungen und Simulationen durchgeführt sowie Stichproben für die Modellparametrisierung und Vergleichsanalyse gemacht. Mithilfe dieser Stichproben war es dann möglich, die Performance-Metriken mit Methoden aus der Statistik auszuwerten, um die Werte vergleichbar zu machen.

Modell

Um die Grundlage für das Modell zu schaffen, habe ich zunächst ein zentrales Repository erstellt, das alle Komponenten sowie deren Interfaces und Verbindungen untereinander enthält. Die Auswahl der Komponenten erfolgte anhand der Architektur des Systems und des gesetzten Fokus auf die Anwendung. Der Component Developer, der üblicherweise für diese Aufgabe zuständig ist, kann, basierend auf seinem Wissen über die Beschaffenheit der Komponenten und der Funktionsweise der Anwendung, ein sehr detailliertes und vollständiges Repository erstellen.

In dem von mir erstellten Modell sind nur die Komponenten der SAP CE im Detail modelliert, während das MDM, die PI und die ERP-Systeme nur als Blackbox aufgenommen wurden. Somit werden deren Performance-Auswirkungen bei der Simulation nicht berücksichtigt. Für die übrigen Komponenten habe ich alle Interfaces, Services und Ressourcenverbrauche modelliert, die am fokussierten Prozess beteiligt sind.

Die beiden beteiligten Aktionen verbrauchen bei jeder Ausführung Ressourcen vom System und haben daher Auswirkungen auf die Performance. Im Fokus meiner Betrachtung lagen hierbei der Speicherbedarf (HDD), die Verzögerung bzw. Antwortzeit des Systems (Delay) sowie die CPU. Nach Abschluss der Komponentenspezifikationen habe ich im nächsten Schritt aus zusammengehörigen Komponenten Systeme modelliert. Um ein System zu erstellen, wurden die Komponenten aus dem Repository ausgewählt, die in einem System zusammen agieren und mit anderen Systemen wie dem MDM kommunizieren.

Nachdem die Komponenten mit ihren Spezifikationen und das System modelliert waren, wurde als nächstes die Umgebung, auf der das System installiert ist und betrieben wird, mitsamt der Hardware bestimmt. Dabei habe ich genau die Teile mit in die Umgebung eingefügt, von denen die Services Ressourcen konsumieren, also HDD, Antwortzeit und CPU. Dieser Teil erforderte keine Modellierungsarbeit, sondern wurde nur durch Hinzufügen der Hardwarespezifikationen (in diesem Fall der Processing Rate) in einen Ressourcencontainer definiert.

Bevor ich Simulationsläufe starten konnte, mussten noch die Anwendungsfälle modelliert werden. Dafür erstellt man ein neues Usage Model, in dem alle möglichen Szenarien als modellierte Prozesse erstellt werden. Um bei der Ausführung des Testfalls zur Neukundenerstellung eine Last zu simulieren, definierte ich zudem ein Workload mit einer festen Nutzerzahl, in diesem Fall 50.

Nachdem nun das gesamte Modell fertiggestellt war, konnte ich mit den Simulationen beginnen. Dazu stellt das PCM die SimuBench zur Verfügung, mit der die Anwendungsfälle simuliert und anhand von Sensoren Daten gesammelt werden. Diese Daten, die die simulierten Antwortzeiten der jeweiligen Aufrufe beinhalten, konnte ich anschließend, beispielsweise als Histogramme, graphisch darstellen und auswerten.

Messergebnisse

Zunächst habe ich Messungen am System durchgeführt, wenn nur ein User den Testfall durchführte. Bei jeder Testausführung im Experiment waren dieselben Bedingungen gegeben. Das bedeutet, dass während der Tests keine anderen Aktivitäten auf dem System durchgeführt wurden. Dies ist essenziell, damit die Ergebnisse der Tests nicht verfälscht werden. Jede Ausführung mit 1, 20 und 50 Usern habe ich je dreimal ausgeführt und anschließend die Durchschnitts-, Maximal- und Minimalzeiten bestimmt.

Da im Vorfeld bereits die richtige Zuordnung der HTTP-Requests den Aktionen im Prozess oder PCM erfolgt ist, konnte ich die Werte problemlos in das Modell übernehmen. Dazu werden die zugehörigen Aktionen mit den drei verschiedenen Messwerten und jeweils einer Wahrscheinlichkeit von 33,3 % parametrisiert.
 Obwohl sich das Experiment nur auf die Messung und Simulierung auf einem Workload von 20 und 50 Usern beläuft, habe ich Tests und Messungen auch mit 30 und 40 Usern durchgeführt. Mit diesen Ergebnissen erstellte ich zwei verschiedene Diagramme. Diese dienten mir dazu, die durchschnittliche Gesamtlaufzeit der Tests und der einzelnen Aktionen mit steigender Nutzerzahl einzuschätzen und zu veranschaulichten.

Wie anzunehmen war, nimmt die gesamte Durchschnittsdauer mit steigendem Workload zu. Anhand der Faktoren in der Tabelle kann man zudem feststellen, um wie viel die Zeit dabei ansteigt. Während der Faktor zwischen 20 und 30 Usern um circa 2,7 ansteigt, ist auffällig, dass er bei 50 Usern nur um 0,7 höher ist als bei 40. Die sinkende Steigung in diesem Fall kann unterschiedliche Ursachen haben. Eine Hilfestellung zur Untersuchung dieses Phänomens könnte die Betrachtung der Zeiten für die einzelnen Werte liefern.

Fazit & Ausblick

Wie aus meinem Versuch mit 20 konkurrierenden Usern hervorgegangen ist, kann das PCM die realen Messwerte näherungsweise abbilden. Bei der Ausführung des gesamten Anwendungsfalls, des Erstellprozesses und der Darstellung der UWL befanden sich die gemessenen Durchschnittszeiten innerhalb der jeweiligen Streuung der Simulationswerte. Wenn man lediglich diesen Versuch betrachtet, würde dieses PCM als Performance-Modell infrage kommen, wobei weitere Optimierungsschritte nichtsdestotrotz zu einem besseren Ergebnis führen könnten. Da sich in diesem Fall das Verhalten der Antwortzeit bei der Darstellung der UWL noch wie erwartet gezeigt hat, entsprechen hier die Simulationswerte näherungsweise den Realwerten. Auffallend war jedoch, dass die reale Antwortzeit des Erstellprozesses mit steigendem Workload keine deutliche Steigerung aufweist. Hier kann keine genaue Aussage über die Antwortzeit getroffen werden, da die verschiedenen Zeiten relativ ähnlich sind. Bei einem Workload von 20 Usern liegt diese sogar über der von 50 Usern. Doch im Gesamten entsprechen die simulierten Werte auch an dieser Stelle der Realität.

Im Gegensatz dazu hat die Analyse des erhöhten Workloads ein gegensätzliches Ergebnis geliefert. Die gesamte Antwortzeit der Simulation liegt durchschnittlich rund 130 Sekunden über der gemessenen. Auch wenn man die Streuung berücksichtigt, ist kein Zusammenhang zwischen Realität und Simulation zu erkennen. Für eine Analyse der Ursachen habe ich, wie auch im ersten Versuch, die Darstellung der UWL und den Prozessablauf genauer betrachtet. In beiden Fällen hat sich die Antwortzeit nicht in der Art verhalten, wie anzunehmen war. Während das Laden und Darstellen der UWL in einer deutlich höheren Antwortzeit resultiert als in der Simulation, liegt diese beim Erstellungsprozess weit über der realen. Das Wiedergeben dieses Verhaltens ist ein entscheidendes Kriterium, das das Modell erfüllen muss, um passende Ergebnisse bei einer höheren Anzahl zu erzielen.

Da aber diese Auswirkungen vom Modell nicht simuliert werden konnten, bedarf es einer genaueren Analyse des Systems und der technischen Infrastruktur, um Aufschluss darüber zu erlangen. Dadurch kann sich die Möglichkeit ergeben, entsprechende Anpassungen im Modell, zum Beispiel Änderungen in der Ressourcenumgebung, vornehmen zu können und folglich zu einem besseren Simulationsergebnis zu kommen. Eine andere oder zusätzliche Ursache hierfür könnte das MDM sein, das nicht in das Modell übernommen wurde. Die Schritte, in denen mit dem MDM kommuniziert wird, etwa das Matching, waren nicht Teil meiner Analyse und ihre Auswirkungen bei höherer Last sind dementsprechend nicht bekannt. Um dem entgegenzuwirken, kann das MDM als System oder Performance-Kurve in das Modell integriert werden.

Zusammenfassend kann ich festhalten, dass die Simulation des erstellen Modells nur teilweise der Realität entspricht und daher ohne Optimierungen und Anpassungen nicht als geeignetes Werkzeug zur Performance-Analyse verwendet werden kann. Die Performance-Analyse mithilfe von Modellen stellt insgesamt jedoch eine adäquate Möglichkeit dar, um geeignete Einschätzungen bezüglich des Performance-Verhaltens zu erhalten. Vor allem durch eine einfache und schnelle Modellierung sowie durch die Verfügbarkeit von Referenzmodellen können einige Vorteile erzielt werden. Zum einen können Kosten, die durch das Erstellen und Durchführen umfangreicher Testanwendungen erzeugt werden, gespart werden. Zum anderen werden Abschätzungen bereits vor und während der Entwicklung möglich gemacht.

Insbesondere das Palladio Component Model bietet dabei vielseitige Möglichkeiten, um ein bestehendes oder geplantes System zu modellieren und zu analysieren. Durch die intuitive Bedienbarkeit und die gute Entwicklungsumgebung kann relativ schnell ein reales System modelliert werden. Bisher wurden damit fast ausschließlich JEE-Anwendungen modelliert und analysiert, weshalb der Bezug zu einer SAP BPM-Anwendung einen sehr interessanten Anwendungsfall darstellt. Die effiziente Analyse der Performance von SAP BPM-Anwendungen ist ein aktuelles Thema und könnte durch Modelle eine adäquate Alternative zu den Lasttests bilden.

Das Modell, das aus meiner Arbeit resultiert, konnte zwar mit den vorhandenen Informationen realitätsnah erstellt werden, spiegelt jedoch das Verhalten des Systems nicht in allen Punkten wider. Hierzu müssen genauere Details vorliegen, die anschließend in das Modell übernommen werden. Eine weitere Optimierungsmöglichkeit wäre die Einbindung des MDM in das Modell, um auch diese Auswirkungen auf die Performance zu berücksichtigen. Da aber an dieser Stelle Messwerte schwieriger zu generieren sind, könnten Abschätzungen mithilfe von Performance-Kurven zu besseren Ergebnissen führen. Somit wird klar, dass die Performance-Modellierung einer SAP BPM-Anwendung durchaus Potenzial für die Zukunft hat, aber noch weitere, detaillierte Untersuchungen in diesem Bereich nötig sind.