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) undSAP 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 Euch meine Untersuchungsergebnisse in kondensierter Form kurz 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, Konfiguration, Ausführung und Monitoring der End-zu-End Geschäftsprozesse. 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 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 nichtfunktionaler Anforderungen, wie zum Beispiel Performance. Dabei kann beispielsweise anhand der Antwortzeiten gemessen werden, wie viel Zeit das System auf Nutzeranfragen benötigt. Zur Analyse und Optimierung der Performance eines Systems stehen verschiedene Ansätze zur Verfügung, beispielsweise 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äftsobjektes 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.

System Architektur - Performance-Modellierung einer SAP BPM-Abwendung
Abbildung 1: System-Architektur

Abbildung 1 zeigt die Architektur des Systems. 
Über das SAP Enterprise Portal melden sich die Benutzer am System an und können ihre zugewiesenen Aufgaben in der Universal Work List (UWL, eine 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 Anwendung, die Search 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

In Abbildung 2 ist grob der Prozessablauf beim Geschäftsobjekt Kunde dargestellt, auf den ich in meiner Arbeit Bezug genommen habe. 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, lediglich den Create-Button zu drücken und den Prozess sowie die Hauptanwendung zu starten.

Kunden Prozessablauf - Performance-Modellierung einer SAP BPM-Anwendung
Abbildung 2: Customer Prozessablauf

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, wie 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 oder 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. In beiden Fälle kann der Genehmiger einen Kommentar zur Begründung beifügen und eine Benachrichtigung wird an alle am Prozess beteiligten Nutzer gesendet. Sollte der Antrag genehmigt werden, wird sie 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 wird und eine erneute Syndizierung versucht wird, oder der Task kann sowohl offen oder 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 solange 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 der Messung am System durchgeführt werden kann. Diese lauten wie folgt:

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 handbares Maß belaufen hätte. Daher habe ich in meiner Arbeit anhand eines häufig vorkommenden Szenarios Messungen und Simulationen durchgeführt, und Stichproben für die Modellparametrisierung und Vergleichsanalyse gemacht. Mit Hilfe 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, welches alle Komponenten sowie deren Interfaces und Verbindungen untereinander enthält. Die Auswahl der Komponenten erfolgte anhand der Architektur des Systems sowie 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.

Beispiel Repository - Performance-Modellierung einer SAP BPM-Anwendung
Abbildung 3: Beispiel Repository

In Abbildung 3 ist beispielhaftes ein Repository zu sehen, das die Komponenten A, B und C sowie Interfaces und interne Services zur Kommunikation enthält. In dem von mir erstellten Modell sind jedoch nur die Komponenten der SAP CE im Detail modelliert, während das MDM, die PI und die ERP-Systeme nur als Blackbox in das Modell mit 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.

Modell des Log-In Vorganges - Performance-Modellierung einer SAP BPM-Anwendung
Abbildung 4: Modell des Login Vorgangs

Eine beispielhafte Modellierung eines Services ist in Abbildung 4 zu sehen, in der das Szenario einer Anmeldung am System dargestellt ist. Die beiden dabei 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 die Processing Rate) in einen Ressourcencontainer definiert.

Usage Modell der Neukundenerstellung - Performance-Modellierung einer SAP BPM-Anwendung
Abbildung 5: Usage Model der Neukundenerstellung

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. Abbildung 5 zeigt beispielhaftes ein Modell des Anwendungsfalls einer Neukundenerstellung. Um bei der Ausführung des Testfalls eine Last zu simulieren, definierte ich zudem ein Workload mit einer festen Nutzerzahl, in diesem Fall 50.

Histogramm einer Simulation mit PCM - Performance-Modellierung einer SAP BPM-Anwendung
Abbildung 6: Histogramm einer Simulation mit PCM

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 (siehe Abbildung 6), 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 essentiell, damit die Ergebnisse der Tests nicht verfälscht werden. Jede Ausführung, also mit 1, 20 und 50 User, habe ich je dreimal ausgeführt und anschließend die Durchschnitts-, Maximal- und Minimalzeiten bestimmt.

Infolge dieser Anforderungen konnte ich die folgenden Leistungsdaten sammeln.

Tab1 Gesamtdurchschnittswerte der Messung für 1 User - Performance-Modellierung einer SAP BPM-Anwendung
Tabelle 1: Gesamtdurchschnittswerte der Messung für 1 User

Tabelle 1 zeigt die Gesamtdurchschnittswerte der Performance-Metrik Antwortzeit, des Speicherverbrauchs und der benötigten CPU-Zeit des gesamten Testfalls von N = 1 User in drei Messungen. Die Werte der einzelnen Aktionen habe ich hier nicht aufgeführt, da die Tabelle sonst zu umfangreich wäre. 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 übernommen werden. 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.

Tab2 Durchschnittliche Gesamtdauer mit unterschiedlichem Workload - Performance-Modellierung einer SAP BPM-Anwendung
Tabelle 2: Durchschnittliche Gesamtdauer mit unterschiedlichem Workload
Durchschnittsgesamtdauer bei unterschiedlichem Workload (graphisch) - Performance-Modellierung einer SAP BPM-Anwendung
Abbildung 7: Durchschnittsgesamtdauer bei unterschiedlichem Workload (graphisch)

Wie anzunehmen war und wie auch aus Tabelle 2 und Abbildung 7 ersichtlich ist, 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 um circa 2,7 ansteigt, ist auffällig, dass dieser bei 50 Usern nur um 0,7 höher ist als bei 40. Woher die sinkende Steigung in diesem Fall stammt, 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. Sowohl bei der Ausführung des gesamten Anwendungsfalls, des Erstellprozesses und der Darstellung der UWL befanden sich die gemessene Durchschnittszeit innerhalb der jeweiligen Streuung der Simulationswerte. Wenn man lediglich diesen Versuch betrachtet, würde dieses PCM als Performance-Modell in Frage 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 der 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, dementsprechende Anpassungen im Modell, wie 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, wie zum Beispiel das Matching, waren nicht Teil meiner Analyse und deren Auswirkungen bei höherer Last sind dementsprechend nicht bekannt. Um dem entgegenzuwirken, kann einerseits 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 mit Hilfe 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 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 mit Hilfe von Performance-Kurven zu besseren Ergebnissen führen. Somit wird klar, dass die Performance-Modellierung einer SAP BPM Anwendung durchaus Potential für die Zukunft hat, aber noch weitere, detaillierte Untersuchungen in diesem Bereich nötig sind.

Ich freu mich auf Euer Feedback.

Servus,

Stefan Waldinger