Sichten auf Geschäftsprozesse als Werkzeug zur Darstellung laufender Prozessinstanzen

Transkript

1 Institut für Architektur von Anwendungssystemen (IAAS) Universität Stuttgart Universitätsstraße 38 D Stuttgart Diplomarbeit Nr Sichten auf Geschäftsprozesse als Werkzeug zur Darstellung laufender Prozessinstanzen Gregor Latuske Studiengang: Softwaretechnik Prüfer: Prof. Dr. Frank Leymann Betreuer: Dipl. Inf. David Schumm begonnen am: beendet am: CR-Klassifikation: C.2.4, D.2.2, H.4.1, H.5.2, H.5.3

2 Kurzfassung Die Komplexität von Geschäftsprozessen nimmt immer weiter zu. So können Prozesse mehrere hunderte Aktivitäten umfassen. Die Überwachung solcher Geschäftsprozesse mit Hilfe von Business Process Monitoring gestaltet sich schwierig, da schnell die Übersicht verloren geht. Außerdem zeigt sich an dieser Stelle die große Kluft zwischen dem Management eines Unternehmens und der IT. Dies liegt unteranderem daran, dass in den meisten Fällen bei der Darstellung auf ein Prozessmodell zurückgegriffen wird, welches für den Betrieb auf einem Workflow Management System (WfMS) angepasst wurde. Teilweise haben die zuvor modellierten und die dann tatsächlich ausgeführten Geschäftsprozesse nicht mehr viel miteinander gemein. Letztere enthalten viele technische Details die zum Beispiel für das Management nicht von Belang sind. Dieses Mankos können durch den Einsatz von Process Views behoben werden. Sie erlauben ähnlich wie Views im Datenbankumfeld benutzerdefinierte Sichten auf ein und denselben Prozess. Process Views erlauben es Aktivitäten auszulassen, zu aggregieren oder besonders hervorzuheben. Auf diese Weise kann zum Beispiel eine Sicht erzeugt werden, die aus dem ausführbaren Geschäftsprozess den modellierten ableitet. Was mit einem statischen Prozessmodell sehr einfach funktioniert, wird bei der Verwendung von Process Views im Zusammenhang mit einem Monitoring Werkzeug aber wesentlich komplexer. In diesem Fall müssen nämlich zudem die Statusinformationen einer Prozessinstanz abgebildet werden. Genau diese Verknüpfung der Process Views und des Business Process Monitoring ist das Ziel der Diplomarbeit. Zunächst werden bereits bestehende Business Process Monitoring Werkzeuge in Bezug auf die Integration von Process Views untersucht. Anschließend wird auf dieser Basis die Architektur und das Konzept einer Neuentwicklung präsentiert. Daraufhin wird erläutert, warum dies sinnvoller als eine Erweiterung ist. Auch einige Besonderheiten der Implementierung werden beleuchtet. Zum Abschluss werden die Grenzen und Möglichkeiten dieser Lösung dieser Lösung präsentiert und ein Ausblick über Verbesserungs- und weiter Forschungsmöglichkeiten gewagt. Das im Zusammenhang mit dieser Diplomarbeit erstellte Werkzeug ist als Open-Source-Anwendung mit dem Namen Business Process Illustrator verfügbar. 2

3 Inhaltsverzeichnis Kurzfassung... 2 Inhaltsverzeichnis Einleitung Motivation Aufgabenstellung Gliederung des Arbeit Hinweise Grundlagen Business Process Monitoring Process Views Business Process Execution Language (BPEL) Anforderungen Technologien und Architektur Technologien und Architekturentscheidungen Schichtenarchitektur Technologien Resultierende Architektur Konzepte Client BPI Model Prozessmodell Prozessinstanz Aktivität Link Ereignisse und Statusinformationen BPI Frontend Konzept für die Oberfläche Realisierung der Oberfläche BPI Service Abfrage der Prozessmodelle Prozessmodell Parser Abfrage der Ereignisse und Aggregation der Statusinformationen Generierung der SVG-Grafik

4 5.5 BPI Service Adapter ODE Apache ODE Management API Persistierung der Ereignisse Implementierung BPI Model BPI Frontend JavaScript Einsatz JSF Komponenten Einzelseiten für Darstellung des Prozessmodells Grafiken BPI Service Dynamisches Laden des BPI Service Adapters Einstellungen BPEL Parser SVG-Segmente BPI Service Adapter ODE Sonstiges Projektstruktur und Werkzeuge Installations- und Betriebsmöglichkeiten Lasttest Zusammenfassung und Ausblick Zusammenfassung Ausblick Anhang Literaturverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Listingverzeichnis Erklärung

5 1 Einleitung 1.1 Motivation Die Entwicklung und Wartung von Software wird zunehmend aufwändiger und komplexer. Um die Komplexität zu beherrschen existieren mittlerweile einige Prinzipien. Dazu gehört beispielsweise die Trennung der Anwendung von der Datenhaltung (Datenunabhängigkeit). Dies kann zum Beispiel mit Hilfe einer Datenbank erfolgen. Ein weiterer wichtiger Schritt ist die Trennung der Anwendungslogik von der Präsentationslogik. Auch die Objektorientierung hat einen nicht unerheblichen Anteil an der Verringerung der Komplexität. Aber auch all die genannten Prinzipien konnten die immer weiter ansteigende Komplexität der Software nicht gänzlich verhindern. Ein neuer viel versprechender Ansatz ist die Trennung einzelner Funktionen der Anwendungslogik und dem Kontroll- und Datenfluss. Diese Anwendungsfunktionen werden als Dienste bereitgestellt und können innerhalb des Unternehmens oder auch von Extern aufgerufen werden. Die Orchestrierung dieser Funktionen beschreibt einen Geschäftsprozess (engl. Business Process), dessen technische Umsetzung als Workflow bezeichnet wird. Bei einem Prozessmodell handelt es sich um die Beschreibung eines Geschäftsprozesses; als Prozessinstanzen bezeichnet man die konkrete Ausführung eines solchen Prozessmodells. Die Überwachung eines solchen Systems kann beispielsweise mit einem Business Process Monitoring Werkzeug erfolgen. Dort werden das Prozessmodell sowie der Zustand einzelner Prozessinstanzen und Aktivitäten visualisiert. Ein Prozessmodell besteht mitunter aus mehreren hundert Aktivitäten (also Aufrufen von Anwendungsfunktionen), sodass dieses sowohl bei der Erstellung als auch bei der Überwachung im laufenden Betrieb sehr schnell unübersichtlich werden kann. Deshalb wird in vielen Fällen die Konzipierung eines Geschäftsprozesses in einer anderen Beschreibungssprache (z.b. BPMN (Business Process Modeling Notation) [31]) durchgeführt. Prozesse die mit diesen Sprachen entwickelt werden enthalten keine technischen Details und sind deswegen schlanker und leichter zu überschauen. Ein weiterer wichtiger Aspekt ist das Interesse der Unternehmen ihren Partnern nicht den vollen Einblick in ihre Geschäftsprozesse zu geben. Sie möchten wichtige Details, die für die Partnerunternehmen nicht relevant beziehungsweise betriebsintern sind, verbergen. Process Views, die eine benutzerdefinierte Sicht auf einen solchen Geschäftsprozess bieten, können dabei helfen. Aber nicht nur wichtige Details, die nicht von jedem eingesehen werden sollen, können damit versteckt werden, sondern es kann auch die Gesamtkomplexität des Prozesses reduziert werden. So können zum Beispiel technische Details oder Aktivitäten, die eine bestimmte Abteilung nicht betreffen, ausgeblendet werden. Viele Modellierungswerkzeuge oder WfMS enthalten oftmals bereits Business Process Monitoring Werkzeuge. Allerdings sind diese meist nicht frei verfügbar und der Quellcode nicht öffentlich zugänglich. Die wenigen Werkzeuge, die diese Bedingungen erfüllen, sind wiederum in den meisten Fällen an ein konkretes WfMS gebunden und müssten erweitert werden, um andere Systeme unterstützen zu können. Allerdings gibt es zum jetzigen Zeitpunkt keine einzige Anwendung, welche sowohl die bereits genannten Anforderungen umsetzt als auch zusätzlich noch die Verwendung von benutzerdefinierten Process Views erlaubt. Bei diesen Sichten handelt es sich aber um einen sehr viel versprechenden Ansatz, um die Übersicht während des Test- und Produktivbetriebs zu wahren. Außerdem kann an dieser Stelle der Bruch, der zwischen dem Management eines Unternehmens und 5

6 der IT [28] besteht, merklich gemindert werden. Grund dafür sind die Process Views, die es erlauben über ein und denselben Geschäftsprozess sprechen zu können, jedem Beteiligten aber nur die von ihm gewünschten Details zeigen. Dies ist die Stelle, an der diese Diplomarbeit ansetzen soll. 1.2 Aufgabenstellung Die Aufgabe dieser Diplomarbeit besteht darin Methoden und Techniken für die Anwendung von Process Views Transformationen im Umfeld des Business Process Monitoring zu definieren. Vorhandene Process Monitoring Werkzeuge sollen geprüft und gegebenenfalls um die Generierung von benutzerdefinierten Views erweitert werden. Die Erstellung einer neuen Anwendung ist ebenfalls möglich. Ein geeigneter Algorithmus für die Generierung der dazugehörenden Process Views soll entwickelt werden. Um dieser Aufgabe gerecht zu werden, muss das Konzept der Process Views für Business Process Monitoring im Detail ausgearbeitet und erläutert werden. Anschließend soll die Eignung des Konzepts anhand einer Implementierung geprüft werden, welche auf einer konkreten Beschreibungssprache für Geschäftsprozesse basiert. 1.3 Gliederung des Arbeit Die vorliegende Arbeit ist in die folgenden sieben Kapitel unterteilt: In Kapitel 1 werden die Motivation und die Aufgabenstellung dieser Diplomarbeit erläutert, die Gliederung der Arbeit (also dieser Abschnitt) beschrieben und Hinweise zu verwendeten Begriffen und der Formatierung gegeben. Kapitel 2 enthält die Beschreibung der Grundlagen dieser Arbeit. Dazu gehören das Business Process Monitoring, die Process Views sowie die Beschreibungssprache für Geschäftsprozesse BPEL. Die Anforderungen, die an die zu entwickelnde Anwendung gestellt werden, sind Teil von Kapitel 3. Dieser Abschnitt enthält auch Informationen über verwandte Arbeiten und welche Ideen und Konzepte in diese Arbeit mit eingeflossen sind. Das anschließende Kapitel 4 umfasst die Technologien, die für die Realisierung dieser Diplomarbeit verwendet werden, und die Architektur der Anwendung. Im ersten Teil werden die Architektur der bereits vorgestellten verwandten Arbeiten und die Vor- und Nachteile der zwei- und dreischichtigen Architektur erläutert. Daraufhin werden verschiedene Technologien für den jeweiligen Einsatzzweck vorgestellt. Die Entscheidung, auf welche dieser Technologien in dieser Diplomarbeit zurückgegriffen wird und welche Auswirkungen dies auf die Anwendung hat, wird abschließend verdeutlicht. Im zweiten Teil von Kapitel 4 wird die daraus resultierende Architektur beschrieben. In Kapitel 5 werden die für Umsetzung dieser Diplomarbeit entwickelten Konzepte erläutert. Die Unterteilung orientiert sich an denen, in der Architektur vorgestellten, Komponenten. Die wichtigsten Aspekte werden anhand von Beispielen genauer vorgestellt und vertieft. Kapitel 6 umfasst Details über wichtige Konzepte und Problemlösungen aus der Implementierung der Anwendung. Auch hier gibt es wieder eigene Abschnitte für die bereits erwähnten Komponenten. Den Abschluss bildet eine Passage über Aspekte, die für die Wartung und den Betrieb der Anwendung wichtig sind. 6

7 Das abschließenden Kapitel 7 beinhaltet eine Zusammenfassung über die präsentierten Konzepte sowie deren Vorteile und Grenzen. Zum Schluss wird ein Ausblick auf zukünftige Arbeiten und mögliche Verbesserungen und Erweiterungen der Anwendung gegeben. 1.4 Hinweise Die Anwendung, die in dieser Diplomarbeit erstellt wurde, steht als Open-Source-Software auf Sourceforge 1 zum Download bereit. Es existiert sowohl eine Version für den Betrieb als auch eine Version für die Entwicklung. Der Projektname der Anwendung lautet Business Process Illustrator und wird auch in dieser Arbeit an einigen Stellen verwendet. Der vollständige Quellcode (Namen von Attributen, Methoden, Klassen etc. und Kommentare) der Software ist in englischer Sprache. Da ein Großteil der verwendeten Literatur nur in englischer Sprache zur Verfügung steht und auch keine Übersetzung ins Deutsche existiert, mussten einige Passagen durch den Autor übersetzt werden. Diese können daher teilweise nicht exakt mit der Intention des Originaltextes übereinstimmen. Im Zweifelsfall muss auf die referenzierte Quelle zurückgegriffen werden. Wenn für einen englischen Fachbegriff ein adäquater deutscher Fachbegriff existiert, wird dieser verwendet. Ansonsten wird der ursprüngliche Begriff genutzt. Englische Bezeichner aus Spezifikationen oder der Anwendung werden nicht übersetzt. In dieser Arbeit werden die Begriff Process View statt Sicht auf Geschäftsprozess und Business Process Monitoring statt Werkzeug zur Darstellung laufender Prozessinstanzen verwendet, da sie wesentlich kürzer, prägnanter und verbreiteter sind. Begriffe aus Spezifikationen oder der Anwendung werden kursiv dargestellt (z.b. ProcessModel als Name einer Klasse). Sie können auch mit einem deutschen Wort mit Hilfe eines Bindestrichs verbunden werden (z.b. Flow-Aktivität). Alle Klassen- oder Sequenzdiagramme entsprechen der Unified Modeling Language 2 (UML) Notation

8 2 Grundlagen 2.1 Business Process Monitoring Das Business Process Monitoring ist ein Sammelbegriff für alle Maßnahmen, die Informationen zum aktuellen Stand einer Prozessinstanz eines Prozessmodells bereitstellen [15]. Diese Prozessinstanzen werden entweder gerade ausgeführt oder wurden bereits abgeschlossen. Bei dieser Art des Monitorings wird der Status einzelner Aktivitäten visualisiert. Auf diese Weise kann schnell ermittelt werden, wie weit die Ausführung bereits fortgeschritten ist. Verschiedene Nutzer profitieren von Business Process Monitoring: Während der Entwicklung eines Prozesses können beispielsweise nicht alle Faktoren getestet werden (wie z.b. dynamisches Binden an Webservices bei BPEL). Für die Administratoren sind derartige Monitoring Werkzeuge hilfreich, um Probleme während der Testphase und auch während des Betriebs, zu erkennen. Dies wird als kontinuierliches Monitoring bezeichnet [7] [57]. Wenn ein Workflow aber nicht nur Maschinen, sondern auch Menschen einbindet, ist für diese ein solches Werkzeug nützlich, um zu erkennen bei welchem Mitarbeiter die Ausführung zurzeit nicht voran geht. So können die Kollegen direkt auf ein Problem eingehen. Natürlich ist es auch bei maschinenorientierten Workflows interessant zu erkennen, welche Teile des Geschäftsprozesses Probleme bereiten. Ein weiterer wichtiger Nutzer einer Monitoring Anwendung ist der Kunde, der sich zum Beispiel über den aktuellen Stand seiner Bestellung informieren möchte. Natürlich haben nicht alle drei Gruppen, dieselben Interessen. So interessieren einen Kunden oder Mitarbeiter die technischen Details möglicherweise nicht, wobei diese für einen Administrator wiederum sehr wichtig sind. Um diese Kluft zwischen Business und IT [28] zu realisieren, können Process Views eingesetzt werden (siehe nächstes Kapitel). Das Business Process Monitoring muss man von Business Activity Monitoring (BAM) [27] [18] und Auditing abgrenzen. Beim Auditing werden alle relevanten Ereignisse der Prozessinstanzen aufgezeichnet. Mit Ereignissen werden die Statusänderungen einer Aktivität während der Ausführung einer Prozessinstanz bezeichnet. Anschließend können diese analysiert und zum Beispiel Fehler oder Schwachstellen im Prozessmodell aufgedeckt werden. Ein weiterer Grund für das Auditing kann das Nachkommen gesetzlicher Auflagen (Compliance) sein, bei denen es notwendig ist diese Daten für mögliche Kontrollen vorrätig zu haben. Das Business Activity Monitoring geht über das Business Process Monitoring hinaus. Auch hier wird mit aktuellen Daten gearbeitet. Diese werden aber anhand der Key Performance Indicators (KPIs) aufbereitet (z.b. Anzahl der Bestellungen pro Stunde). Auf diese Weise können Probleme aufgedeckt und es kann entsprechend gegen gesteuert werden. Eine Sicht auf einzelne Prozessinstanzen ist aber nicht vorgesehen. Dafür ist dort oftmals die Möglichkeit gegeben Problemfälle zu definieren und bei Eintritt eine Alarmmeldung ausgeben zu lassen. Die Daten, die das Monitoring Werkzeug darstellt, können über zwei Mechanismen vom WfMS abgerufen werden: das aktive und das passive Monitoring. Bei aktivem Monitoring übermittelt das überwachte WfMS die neuen Ergebnisse selbständig an das Werkzeug (Pushing). Das passive Monitoring zeichnet sich dadurch aus, dass die Anwendung die Informationen selbstständig abruft. Gerade für 8

9 Kunden, die beispielsweise den Status ihrer Bestellung abfragen möchten, ist dieses Verfahren ausreichend. Möchte man damit dennoch eine kontinuierliche Überwachung erreichen, müssen die Daten in periodischen Intervallen abgerufen werden (Polling). Bei beiden Varianten können diese Informationen auch über die Auditing Datenbank abgerufen werden. Vorteil des aktiven Monitoring ist es, dass nur Daten übertragen werden müssen, wenn neue Ereignisse eintreten. Allerdings können bei dieser Variante keine bereits gespeicherten Daten abgerufen werden. Diese muss das Werkzeug zunächst selbständig also passiv - abfragen. Ab dem Zeitpunkt des ersten Abfragens stehen dann aber alle relevanten Informationen zur Verfügung. Die Verteilung der Daten kann zum Beispiel über eine Publish-Subscribe-Funktion [19] erfolgen. So muss das WfMS nicht über alle Anwendungen informiert sein, die diese Statusinformationen erhalten möchten. Wenn der Status einer Prozessinstanz nicht kontinuierlich abgerufen werden soll, ist passives Monitoring besser geeignet. Damit nicht immer alle Ereignisse übertragen werden müssen, kann ein Zeitstempel mitgeschickt werden. Dieser gibt an, welche Daten bereits bekannten sind und nicht mehr geliefert werden müssen. 2.2 Process Views Process Views können mit Views bei Datenbank Management Systemen (DBMS) verglichen werden [45]. Dabei handelt es sich um eine virtuelle Tabelle, die auf einer physischen oder einer anderen virtuellen aufsetzt. In gleicher Weise werden Process Views als abstrakte Prozessmodelle von Basis- Prozessmodellen oder anderen Process Views abgeleitet [26]. Sie können entweder zusammen mit den Prozessmodellen erstellt und zur Ausführungszeit angezeigt werden oder aber erst während der Ausführung ermittelt werden. Gründe für die Verwendung von Process Views gibt es viele. Sie werden vor allem eingesetzt, um die Komplexität eines Prozessmodells zu reduzieren und so schneller einen Überblick zu erlangen [43] [41]. Ein weiterer Aspekt sind die unterschiedlichen Nutzergruppen, die an einem Prozess beteiligt sind. Dazu gehören innerhalb des Unternehmens verschiedene Abteilungen, aber auch andere Unternehmen und Kunden [9]. Sie alle haben sehr unterschiedliche Anforderungen und benötigen andere Informationen. So genügt dem Management zum Beispiel ein knapper Überblick; die IT möchte aber wiederum sämtliche Details einsehen können. Ein weiterer Grund für den Einsatz von Process Views ist die starke Vernetzung von Unternehmen. Sie arbeiten über das Internet zusammen und müssen natürlich permanent Informationen austauschen. Dafür ist es erforderlich Teile der Definition des eigenen Prozesses (private view) als Process Views (public view) für die Geschäftspartner offen zu legen [13]. Auf diese Weise wird sichergestellt, dass der Partner nur die für ihn relevanten Daten erhält. Falls dennoch Informationen zur Verfügung gestellt werden, die das Partnerunternehmen nicht benötigt, kann es die vordefinierte Process View um eigene Regeln zu erweitern. Somit stehen nur noch die wirklich benötigen Informationen zur Verfügung. Process Views können außerdem auch als Grundlage für das Compliance Management in Geschäftsprozessen genutzt werden [44]. Bei Compliance handelt es sich um gesetzliche Vorgaben und Regelungen, eigene Anforderungen oder Industriestandards, deren Einhaltung überprüft werden muss. Prinzipiell gibt es drei Arten, wie Process Views umgesetzt werden können. Das Prozessmodell kann reduziert werden [42], das heißt Aktivitäten ausgelassen werden, Aktivitäten können aggregiert wer- 9

10 den [26] oder besonders visualisiert und hervorgehoben werden [43]. In jedem Fall ist es wichtig, dass die Grundstruktur des Prozessmodells erhalten bleibt [9]. Diese drei Grundfunktionen zum Erzeugen von Process Views können kombiniert werden und durch verschiedene Bedingungen ausgeführt werden. Wenn Personen in einem Prozess involviert sind, können zum Beispiel nur noch jene angezeigt werden, an denen sie beteiligt sind. Auch technische Aktivitäten, die für die Ausführung eines Prozessmodells benötigten werden, können für das Management beispielsweise entfernt werden. Die Informationen, die eine konkrete Prozessinstanz liefert, können verwendet werden, um Process Views zu erstellen. So ist es möglich abgeschlossene Aktivitäten auszublenden oder aber Aktivitäten, die nicht mehr ausgeführt werden können, auszulassen [41]. Zusätzlich können noch unterschiedliche Darstellungsformen wie Graphen, Schwimmbahnen (engl. Swim Lanes) oder Tabellen gewählt werden [9]. Auch die Darstellung einer einzelnen Aktivität kann sich unterscheiden: So können Informationen wie das Start- oder Enddatum der Ausführung oder genutzte Variablen angezeigt werden. Process Viewing Patterns [43] beschreiben einfache und elegante Lösungen zum Erstellen von Process Views (oder Teilen davon). Außerdem enthalten diese Patterns Angaben, wie sie auf eine konkrete Beschreibungssprache angewandt werden können. Mit Hilfe dieser Process Viewing Patterns können auch die besonderen Merkmale von Process Views beschrieben und diese Sichten einfacher verglichen werden. 2.3 Business Process Execution Language (BPEL) BPEL ist eine XML-basierte Beschreibungssprache für Geschäftsprozesse (Business Processes). Die Grundlage für BPEL bilden die Sprache WSFL (Web Service Flow Language) von IBM [21] und XLANG (XML Business Process Language) von Microsoft [29]. Beide Unternehmen veröffentlichten im Jahr 2002 [20] die erste BPEL Version unter dem Namen BPEL4WS. Die Version 2.0, dessen Entwicklung das OASIS-Komitee übernommen hat, trägt den Namen WS-BPEL und stammt aus dem Jahr 2007 [38]. Beide Versionen unterstützen in erster Linie maschinenorientierte Geschäftsprozesse, die mit Webservices interagieren. In diesem Bereich ist BPEL der de-facto Standard. Allerdings existiert mit BPEL4People [1] eine Erweiterung, die die Integration von Personen erlaubt. Ein BPEL-Prozessmodell kommuniziert mit Webservices, kann aber gleichzeitig als Webservice in einen anderen Prozess oder Programm integriert werden. Aus diesem Grund umfasst jedes vollständige Prozessmodell auch eine WSDL-Schnittstelle (Web Service Description Language). Der Standard unterscheidet zwischen ausführbaren und abstrakten, nicht ausführbaren Prozessmodellen. Letztere können auch als Process Views angesehen werden, die zum Beispiel wichtige interne Details vor einem externen Partner verbergen. Aufgrund der Kombination der Graph-basierten Sprache WSFL und der Kalkül-basierten Sprache XLANG ist die grafische Repräsentation eines BPEL-Prozessmodells komplexer als bei beiden Ursprungssprachen. Für die Modellierung wird oftmals BPMN verwendet und anschließend eine Transformation vorgenommen, da BPEL sehr viele technische Details enthält, die nur für die Ausführung relevant sind. Auf diese Weise können aber auch BPMN-Prozessmodelle entstehen, welche sich nicht mit BPEL realisieren lassen [31]. 10

11 Ein BPEL-Prozessmodell umfasst mehrere Hauptbausteine (siehe Tabelle 1). Nähere Details zu sämtlichen Bausteinen enthält die Spezifikation [38]. In dieser Diplomarbeit sind von den Hauptbausteinen nur die Aktivitäten und Handler relevant, da sie den Kontrollfluss bilden. Baustein Partner Links Variables Correlation Sets Handlers Activities Beschreibung Schnittstellen zu anderen Webservices. Variablen, in denen die Daten einer Prozessinstanz gespeichert werden. Korrelationsmengen erlauben es Nachrichten einer Prozessinstanzen zuzuordnen; wichtig bei asynchroner Kommunikation Handler, die zur Fehlerbehandlung oder dem Verarbeiten von Nachrichten genutzt werden. Aktivitäten, die den Hauptkontrollfluss oder andere Dienste aufrufen bilden. Tabelle 1 - Hauptbausteine eines BPEL-Prozessmodells 11

12 3 Anforderungen Die Anforderungen an die Anwendung ergeben sich in erster Linie direkt aus der Aufgabenstellung der Diplomarbeit. Andere lassen sich erst durch genauere Analyse des Themas ermitteln. Zunächst wird auf die direkten Anforderungen eingegangen und anschließend auf die daraus resultierenden. Die Aufgabenstellung der Diplomarbeit beschreibt zunächst das Konzept der Process Views. Für diese Process Views sollen Techniken und Konzepte für die Transformierung von Prozessmodellen definiert werden, um daraus schließlich einen Algorithmus zur Generierung dieser Process Views zu entwickeln. Der nächste Schritt, den die Aufgabenstellung fordert, ist die Verbindung einer bestehenden oder neu entwickelten Business Process Monitoring Software mit dem Process View Algorithmus. Dazu ist es notwendig existierende Anwendungen zu analysieren und gegebenenfalls anzupassen. Zusätzliche zu diesen Aufgaben ist der Einsatz von Java als Programmiersprache vorgeschrieben. Neben der Plattformunabhängigkeit ist sicherlich auch ihre hohe Verbreitung im Umfeld des Business Process Monitoring dafür ausschlaggebend. Aus diesen grundlegenden Anforderungen können unmittelbar weitere abgeleitet werden. So soll die Monitoring Anwendung die installiert Prozessmodelle sowie deren Prozessinstanzen vom WfMS abzurufen. Das Werkzeug soll nicht speziell an ein WfMS gebunden sein, sondern die Möglichkeit bieten unterschiedliche Systeme einzusetzen. Der Prototyp muss nur ein WfMS direkt unterstützen, sich aber ohne Probleme erweitern lassen. Eine Prozessinstanz ist eine konkrete Ausführung eines Prozessmodells. Die Instanz einer Klasse beider objektorientierten Programmierung lässt sich damit gut vergleichen. Eine Kombination aus Prozessmodell und Prozessinstanz soll durch einen Benutzer ausgewählt werden können, um sich eine grafische Darstellung anzeigen zu lassen. In diesem Graphen (die grafische Darstellung eines Prozessmodells) sollen die Aktivitäten des Prozessmodells und deren aktueller Status, bezogen auf eine Prozessinstanz, angezeigt werden. Dies bedeutet, dass die entsprechende Monitoring Software die Abfrage aktueller Ereignisse von einem WfMS unterstützen muss, welche eine spezielle Schnittstelle erfordert, um den zeitnahen Abruf dieser Informationen (der Prozessmodelle, ihrer Prozessinstanzen und deren Ereignisse) zu unterstützen. Außerdem soll es möglich sein beliebig viele Darstellungen ein und desselben oder auch unterschiedlicher Prozessmodelle gleichzeitig geöffnet zu halten. Diese sollen unabhängig voneinander konfiguriert werden können und keine Wechselwirkungen (Änderungen in Darstellung A bewirkt Änderungen in Darstellung B) aufweisen. Sortier- und Filterungsmöglichkeiten der Prozessmodelle und Prozessinstanzen sind zwingend notwendig, da der Benutzer sonst bei großen Datenmengen, die im Betrieb eines WfMS schnell erreicht werden können, den Überblick leicht verlieren kann. Eine Seitenverwaltung soll die Anzahl der gleichzeitig angezeigten Datensätze zusätzlich reduzieren. Damit der Status der Aktivitäten im angezeigten Graphen möglichst aktuell bleibt, soll entweder das WfMS über eine Push-Funktion neue Ereignisse übermitteln oder die Monitoring Anwendung diese in benutzerdefinierten Intervallen mit Hilfe einer Poll-Funktion abfragen. Die Vor- und Nachteile dieser Ansätze wurden bereits im Kapitel 2.1 über Business Process Monitoring erläutert. Welche Variante in dieser Diplomarbeit gewählt wurde, wird im Abschnitt über die Architekturentscheidungen (Kapitel 4.1) erläutert. 12

13 Process Views sollen auf die visualisierten Prozessmodelle angewendet werden können, um deren Komplexität zu reduzieren. Für die Definition dieser Views gibt es zwei unterschiedliche Möglichkeiten. Der Benutzer kann beispielsweise ein Prozessmodell angeben, das bereits an seine Wünsche angepasst wurde. In diesem Fall muss aber zusätzlich festgelegt werden, wie die Ereignisse einer Aktivität auf ein geändertes Prozessmodell abgebildet werden sollen. Eine Alternative ist die Angabe von Regeln für die Anwendung von View Transformationen. Auf diese Weise kann der Algorithmus die Abbildung der Statusinformationen selbst übernehmen, da genau bekannt ist, welche Aktivitäten zum Beispiel entfernt oder aggregiert werden. Die dritte Möglichkeit erlaubt dem Benutzer die Auswahl von Process Views aus vorgefertigten Anwendungsszenarien. Dieser Ansatz benötigt keine vorherige Anpassung oder Annotierung des Prozessmodells, erlaubt allerdings nur vordefinierte Views. Auch diese Problematik wird im Abschnitt Architekturentscheidungen nochmals beleuchtet. Zunächst sind zwei Anwendungen zu erwähnen, die während zweier Diplomarbeiten am Institut für Architektur von Anwendungssystemen der Universität Stuttgart entstanden sind. Die ersten Anwendung [30] aus dem Jahr 2006 bildet die Grundlage für das ein Jahr später entwickelte Werkzeug [49]. Es handelt sich in beiden Fällen um eine lokal laufende Java-Anwendung, die direkt mit dem WfMS kommunizieren. Allerdings sind beide Anwendung an ein spezielles WfMS (ActiveBPEL 3 bzw. Apache ODE [4]) gebunden. Außerdem können die Werkzeuge nur BPEL-Prozesse darstellen und bieten keine Möglichkeit dies ohne größere Aufwände abzuändern. Ein großer Vorteil einer lokalen Java- Anwendung ist jedoch, dass Ereignisse ohne periodisches Abfragen, sondern direkt bei deren Auftreten, übermittelt werden können. Die Darstellung bleibt somit immer aktuell. Ein anderes Werkzeug von Sun [47], welches ebenfalls auf BPEL ausgerichtet ist, setzt hingehen auf eine Web-Anwendung, bei der eine Push-Funktion so nicht einsetzbar ist. Allerdings hat eine solche Anwendung auch einen entscheidenden Vorteil: Sie kann direkt und ohne Installation verwendet werden. Auch die Konfiguration muss nicht vom Benutzer durchgeführt werden. So muss zum Beispiel nur der Administrator angeben, unter welcher Adresse das WfMS zu finden ist. Lediglich die Adresse der Monitoring Anwendung muss bekannt sein. Ein Nachteil dieses Werkzeugs ist, dass es nur sehr wenige Informationen, die die Ereignisse liefern, auf der Oberfläche darstellt. So werden nur der Name der Aktivität und die Information, ob eine Aktivität überhaupt ausgeführt oder gestartet wurde, dargestellt. Außerdem unterstützt es nicht die Darstellung der Links innerhalb der BPEL-Aktivität Flow. Dies ist darauf zurückzuführen, dass die WfMS von Sun (Open ESB 4 ), auf den dieses Werkzeug zugeschnitten ist, diesen Typ ebenfalls nicht nutzt. Eine sehr ähnliche Anwendung gibt es auch von WSO2 [56]. Das Werkzeug kann Daten von Apache ODE und dem WSO2 Business Process Server 5 abrufen. Ansonsten ist die Struktur der Anwendung weitgehend identisch. Alle bisher vorgestellten Anwendungen bieten aber keine Möglichkeiten Process Views anzuwenden und das Prozessmodell so kompakter und schlanker darzustellen. Natürlich gibt es weitere Monito

14 ring Werkzeuge. Allerdings sind diese nicht frei verfügbar, sondern Bestandteil eines WfMS. Dazu gehört beispielsweise der WebSphere Business Monitor 6 von IBM. Die Eigenschaften der hier vorgestellten Werkzeuge haben natürlich auch Einfluss auf diese Anforderungen der hier entwickelten Anwendung. Sie sollte in jedem Fall die Darstellung von BPEL- Prozessmodellen in vollem Umfang unterstützen, aber auch die Möglichkeit bieten andere Beschreibungssprachen später einfach zu integrieren. Ob nun eine Push- oder Poll-Funktion zu bevorzugen ist und welche Konsequenzen dies auf die Anwendung hat, wird im nächsten Kapitel erläutert. Eine weitere Problematik ist, dass all diese Anwendungen nur mit einem WfMS eines speziellen Herstellers zusammenarbeiten können und somit ein unkomplizierter Austausch nicht möglich ist. Wie eine mögliche Lösung dieses Problems aussehen kann, wird ebenfalls im nächsten Kapitel erläutert. Da es zum heutigen Zeitpunkt fast keine solchen Werkzeuge gibt, die als Open-Source-Anwendung zur Verfügung stehen, ist die öffentliche Bereitstellung des Quellcodes dieser Anwendung ein naheliegender Schritt

15 4 Technologien und Architektur Einige, der in Kapitel 3 erläuterten, Anforderungen haben direkten Einfluss auf die Wahl der einzusetzenden Technologien sowie auf die Architektur der Anwendung. In diesem Kapitel werden zunächst unterschiedliche Technologien für die jeweiligen Probleme untersucht und anschließend die getroffenen Entscheidungen verdeutlicht. Diese haben direkten Auswirkungen auf die abschließend erläuterte Architektur. 4.1 Technologien und Architekturentscheidungen Aus den Anforderungen wird direkt ersichtlich, dass es einerseits eine Oberfläche geben muss, auf der der Benutzer das Prozessmodell und die Prozessinstanz auswählen und die grafische Darstellung betrachten kann, andererseits ein WfMS, von der diese Daten abgerufen werden. Wie und wo die Verarbeitung der Daten erfolgt wird im folgenden Abschnitt geklärt Schichtenarchitektur In jedem Fall übernimmt der Client die Ein- und Ausgabe, er kann aber auch für die Verarbeitung der Daten verantwortlich sein. Die Architektur der Anwendungen aus den bereits genannten Diplomarbeiten besteht aus zwei Schichten (im Sinne der Schichtenarchitektur [8]), da dort die Clients die Datenverarbeitung vollständig übernehmen. Bei dem Werkzeug von Sun handelt es sich um eine Web-Anwendung, bei der der Client nur noch für die Ein-und Ausgabe genutzt wird. Die Datenverarbeitung wird vom Webserver übernommen, der zwischen dem WfMS und dem Client eingeordnet ist. Man spricht in diesem Fall auch von einer dreischichtigen Architektur. Die Verarbeitung der Daten muss dann also eine zusätzliche Schicht bzw. Komponente übernehmen. Eine Integration dieser Funktion in das WfMS wäre zwar möglich, aber nur in wenigen Fällen realisierbar. Die Vor- und Nachteile beider Lösungen werden im Folgenden abgewogen und die Entscheidung, die in dieser Diplomarbeit getroffen wurde, wird erläutert Zwei-Schichten-Architektur Die hier vorgestellte zweischichtige Architektur zeichnet sich dadurch aus, dass sämtliche Datenverarbeitungsschritte auf dem Client ausgeführt werden. Nur die Datenhaltung wird von einem Server (in diesem Fall das WfMS) übernommen. Abbildung 1 zeigt die Architektur eines solchen Monitoring Werkzeugs. Der Client kommuniziert also direkt mit dem WfMS, deren Schnittstelle, die Management API, fest vorgegeben ist. Somit lässt sich die Trennstelle zwischen Client und Server nicht frei wählen. Die beiden Werkzeuge, die während der bereits genannten Diplomarbeiten entstanden sind, besitzen eine solche Architektur. Sie setzen auf dem Client eine Java-Swing-Anwendung ein. Swing ist eine Grafikbibliothek zum Programmieren von grafischen Benutzungsoberflächen und Teil der Java Standard Edition [33]. 15

16 Vorteile Abbildung 1 - Zwei-Schichten-Architektur Der größte Vorteil der zweischichtigen Architektur ist, dass kein zusätzlicher Server notwendig ist. Die Architektur ist vergleichsweise einfach: Sowohl die Entwicklung als auch die Wartung ist unkomplizierter. Außerdem kann die Leistungsfähigkeit heutiger PCs ausgenutzt werden. Neue Ereignisse können entweder über Push oder Poll auf den Client übertragen werden. Nachteile Ein Nachteil dieser Architektur ist jedoch, dass der Client entsprechend konfiguriert werden muss, um auf die WfMS zugreifen zu können. Falls diese Konfiguration geändert werden sollte, müssen sämtliche Clients aktualisiert werden. Auch der Einsatz mehrerer Instanzen eines WfMS ist für den Client nicht transparent. Wenn mehrere Instanzen eingesetzt werden sollen, muss der Client sämtliche Adressen kennen. Außerdem muss die zuvor angesprochene Leistungsfähigkeit des Clients auch nicht immer gegeben sein. Mobile Endgeräte bieten beispielsweise nicht immer die benötigte Leistung. Ein weiterer Nachteil ist, dass Caching von Daten nur lokal erfolgen kann. Das heißt sämtliche Daten müssen an jeden Client übertragen werden, was zu einer hohen Netzwerklast führen kann. Fall die neuen Ereignisse mit Hilfe einer Push-Funktion übertragen werden sollen, muss sich der Client in irgendeiner Form auf Seiten des WfMS registrieren. Dies bedarf einer weiteren Komponente, da diese Anmeldung vermutlich nur von wenigen WfMS unterstützt wird. Natürlich kann dieses Problem auch mit Hilfe von Messaging gelöst werden (siehe [19]) Drei-Schichten-Architektur Bei der dreischichtigen Architektur wird die Anwendungslogik auf eine mittlere Schicht (Middleware) verlagert. Der Client kommuniziert ausschließlich mit dieser Schicht und übernimmt nur noch die Einund Ausgabe der Daten. In Abbildung 2 wird diese Mittelschicht als Sever bezeichnet. Bei dem Client kann es sich entweder um eine Java-Anwendung handeln, die lokal ausgeführt wird, oder auch um einen Webbrowser, der eine HTML-Seite [52] darstellt. Auch eine Mischform (z.b. Rich Internet Application (RIA)) ist möglich. In diesem Fall kann die Ausführung gewisser Teile der Anwendungslogik wieder vom Client übernommen werden. 16

17 Vorteile Abbildung 2 - Drei-Schichten-Architektur Die Wartung und Konfiguration eines Clients innerhalb einer dreischichtigen Architektur ist wesentlich einfacher. Der Client braucht keine Informationen über die Adresse und den Typ des WfMS zu haben; er kommuniziert nur mit dem Server. Wenn nur die Anwendungslogik geändert wird und die Schnittstelle zum Client stabil bleibt, muss dieser nicht angepasst werden. Daten können nun auch auf dem Server gespeichert werden, das WfMS wird entlastet. Wenn der Server an seine Leistungsgrenzen stoßen sollte, können weitere Instanzen aufgesetzt werden. Da die Anwendungslogik an einer zentralen Stelle gebündelt wird, können weitere Client- Anwendungen, die zum Beispiel andere Darstellungen erlauben, ohne größeren Aufwand implementiert werden. Erleichtert wird dies dadurch, dass die Client-Anwendung nur noch für die Ein- und Ausgabe zuständig ist. Kenntnisse über die Implementierung der anderen Clients sind nicht notwendig. Im Gegensatz dazu muss bei der zweischichtigen Architektur die Anwendungslogik dupliziert werden. Auch in diesem Fall können neue Ereignisse mit Hilfe von Push oder Poll übermittelt werden. Nachteile Die Realisierung der Architektur ist sowohl während der Entwicklung als auch später in der Wartung wesentlich aufwändiger. Mit dem Server, der auch immer erreichbar sein muss, entsteht zudem eine zusätzliche Fehlerquelle. Durch die zusätzliche Kommunikation wird im gesamten Netzwerk zusätzliche Netzwerklast erzeugt. Durch geschicktes Verteilen der Server und Caching kann diese aber reduziert werden Entscheidung In dieser Diplomarbeit wird eine Rich Internet Application, also eine webbasierte Anwendung mit drei Schichten, umgesetzt. Dafür sprechen einige Gründe: Eine solche Anwendung ist flexibel von überall einsetzbar. Die einzige Voraussetzung ist ein Webbrowser. Durch den Einsatz von AJAX oder anderen Webtechnologien (wie z.b. Adobe Flash 7 oder Adobe Flex 8 ) kann der Eindruck einer lokalen Anwendung erzeugt werden. Allerdings hat man in diesem Fall Probleme mit dem zeitnahen Übertragen neuer Ereignisse, da sich eine Push-Funktion nur schwierig realisieren lässt. Dies liegt im Aufbau des HTTP-Protokolls [54] begründet, bei dem ein Anfrage-Antwort-Konzept eingesetzt wird, das immer vom Client ausgeht. So kann der Server nicht von sich aus Daten an die Clients schicken. Weiter spricht dafür, dass keine Installation vorgenommen werden muss, sondern die Anwendung vollständig über das Internet bezogen wird. Falls Änderungen durchgeführt werden, ist eine manuel

18 le Aktualisierung des Clients nicht notwendig. Zwar kann dies auch mit einer Java-Anwendung, die mit Hilfe von Java Web Start 9 auf den Rechner geladen wird, realisiert werden, allerdings ist dann eine lokale Installation der Java Laufzeit nötig. Im Gegensatz zur zweischichtigen Architektur kann in diesem Fall das dahinter liegende WfMS getauscht werden, ohne dass der Client umkonfiguriert oder angepasst werden müsste. Ein solches System ist auch wesentlich einfacher zu skalieren. Falls ein einzelner Server überlastet ist, können weitere zugeschaltet werden, die dann einen Teil der Clients übernehmen. Durch Caching auf Seiten des Servers können die Aufrufe der Management API des WfMS deutlich reduziert werden. Falls nötig können auch weitere Schichten eingeführt werden, um zum Beispiel die Verteilung der Daten zu optimieren. Im nächsten Abschnitt wird auf die unterschiedlichen Technologien eingegangen, die für die Realisierung notwendig sind Technologien Aufgrund der Vorgabe, Java als Programmiersprache zu verwenden, bietet sich die Java Enterprise Edition für die Realisierung der dreischichtigen Architektur an. Damit wird beispielsweise der Einsatz von Adobe Flash zwar nicht unmöglich; allerdings bieten sich natürlich Technologien an, die entweder aus der Enterprise Edition stammen oder zumindest auch auf Java basieren und sich somit leichter integrieren lassen. Bei einer Rich Internet Application besteht die Anwendung auf dem Client aus HTML-Seiten mit entsprechender JavaScript Unterstützung oder zum Bespiel aus der Flash-Anwendung. Diese kann natürlich in eine HTML-Seite eingebettet werden. Auf diese Weise ist es zum Beispiel möglich, die Anzeige der Prozessmodelle und Prozessinstanzen in HTML und die grafische Darstellung der Prozessmodelle also den Graphen - mit einer anderen Technologie zu realisieren. In den nachfolgenden Abschnitten werden verschiedene Technologien vorgestellt, die für die entsprechenden Anwendungsfälle eingesetzt werden können. Zudem wird die getroffene Entscheidung, welche Technologie eingesetzt werden soll, erläutert Grafische Darstellung der Prozessmodelle Zu den Anforderungen an diese Darstellung gehören eine einfache Integration in eine Java- Anwendung, eine schnelle Aktualisierung sowie eine flexible Anpassung des Aussehens. Im Folgenden werden JavaFX [34], mxgraph /JGraph [23] und SVG [55] vorgestellt. Anschließend erörtert welche Technologie ausgewählt wird. Andere Technologien wie Adobe Flash oder Adobe Flex wurden zwar zu Beginn der Diplomarbeit in Erwägung gezogen, schieden allerdings durch ihre hohe Einarbeitungszeit aus. JavaFX JavaFX ist ein Framework für Rich Internet Applications (ähnlich wie auch Adobe Flash oder Flex). Das heißt nicht, dass nicht nur die Graphen der Prozessmodelle damit dargestellt werden könnten, sondern auch die Tabellen. JavaFX wird vollständig auf dem Client ausgeführt und kommuniziert mit dem Webserver über HTTP [54] oder Webservices. Die Anwendung wird direkt aus dem Internet geladen und kann mit Hilfe von Java Web Start oder als Java-Applet ausgeführt werden

19 Ein Vorteil ist natürlich die Ähnlichkeit zu Java, obwohl eine eigene Skriptsprache, JavaFX Script, verwendet wird. Viele Komponenten erben auch aus Klassen der Java Standard Edition. Außerdem kann sehr einfach eine direkte Manipulation der angezeigten Elemente durch den Benutzer ermöglicht werden. Ein weiterer Vorteil ist zudem, dass der Client die Berechnung des Graphen übernimmt. Der Server wird an dieser Stelle erheblich entlastet. Für die konkrete Darstellung eines Graphen gibt es in JavaFX zwar eine Komponente [39], diese müsste allerdings stark angepasst werden. In ersten Versuchen einen Prototyp zu erstellen, bereitete dies einige Schwierigkeiten. Alternativ könnte natürlich eine eigene Graph Komponente erstellt werden. Allgemein ist erkennbar, dass JavaFX noch in den Kinderschuhen steckt: Es existieren noch nicht sehr viele Komponenten und auch die Geschwindigkeit bei der Ausführung kann noch deutlich verbessert werden. Ein weiterer Nachteil ist die Notwendigkeit einer Java Laufzeitumgebung. mxgraph/jgraph MxGraph ist eine spezielle Sammlung von Bibliotheken für die Genierung von Graphen. Ursprünglich handelte es sich um eine Java Implementierung mit dem Namen JGraph. Die bereits präsentierten Werkzeuge der Diplomarbeiten [30] und [49] verwenden JGraph zur Darstellung der Prozessmodelle. Mittlerweile existieren auch Versionen für.net, JavaScript und PHP. Die ursprüngliche Java Implementierung baut auf Swing auf und ist somit nicht für die Generierung des Graphen innerhalb einer Webanwendung geeignet. Generell können mit diesen Bibliotheken sehr schnell Graphen erzeugt und diese auch dynamisch angepasst werden. Speziell bei der JavaScript Version sind nur dafür wenige Codezeilen nötig. Allerdings ist es sehr aufwändig, die angezeigten Knoten des Graphen an die Anforderungen für die diesen Anwendungsfall anzupassen, damit sie beispielsweise Statusinformationen anzeigen. Das liegt unteranderem auch daran, dass BPEL kein reines Graphenmodell enthält. An die Clients entstehen mit dieser Technologie quasi keine Anforderungen, da jeder derzeit gängige den Webbrowser JavaScript unterstützt. Allerdings hat der Einsatz dieser Skriptsprache auch einige Nachteile: Zum einen muss der Client diese Berechnungen selbst durchführen (in Java benötigen diese Berechnungen wesentlich weniger Leistung). Zum anderen wird die Entwicklung aufwändiger, da hier wesentlich mehr Code in JavaScript geschrieben werden muss. Scalable Vector Graphics (SVG) SVG basiert auf XML und dient zur Beschreibung von zweidimensionalen Vektorgrafiken. Mit Hilfe von Cascading Style Sheets (CSS) [50] kann das Aussehen der Elemente einfach angepasst werden. Die SVG-Grafik kann direkt auf dem Server geniert werden (der Client könnte diese Aufgabe aber auch übernehmen) und via JavaScript auf dem Client manipuliert werden. Allerdings gibt es im Gegensatz zu mxgraph mehr generische Funktionen, die als Basis für eine eigene Implementierung dienen müssten, dafür aber mehr Möglichkeiten für die Umsetzung der Darstellung erlauben. Einfache und auch komplexe Strukturen können mit SVG problemlos umgesetzt werden. Es bestehen wesentlich mehr Gestaltungsmöglichkeiten, da man nicht an eine Graphen-Struktur wie bei mxgraph gebunden ist. Dafür muss ein solcher Graph selbst definiert werden, da es keine vordefinierten Elemente gibt. Das Werkzeug von Sun [47], das ebenfalls SVG für die Darstellung des Prozessmodells verwendet, kann in diesem Fall als Grundlage verwendet werden. 19

20 Die meisten gängigen Webbrowser unterstützen diese Technologie von Haus aus. Es existieren aber auch Plugins, die diese Aufgabe übernehmen können. Allerdings umfasst die Unterstützung meist nicht 100% aller Teile der Spezifikation von SVG. Die grundlegenden Elemente, die hier benötigt werden, unterstützen aber alle Browser. Entscheidung Alle der drei präsentierten Technologien können Graphen darstellen, jedoch gibt es starke Unterschiede im Aufwand der jeweiligen Realisierung. Bei JavaFX müssten entsprechende Komponenten selbst entwickelt werden, zudem käme die zusätzliche Kommunikation zwischen Client und Server als Nachteil hinzu. Bei mxgraph gibt es, wie der Name auch schon andeutet, nur die Möglichkeiten Graphen zu erzeugen. Andere Elemente müssen ergänzt werden. Dis ist wiederum mit erheblichen Aufwand verbunden. SVG hat den Vorteil, dass es sehr flexibel ist und nicht auf eine bestimmte Darstellung fixiert ist. Mit Hilfe der Standard-Elemente kann ein Graph verhältnismäßig leicht generiert werden. Dies würde dann auch auf der Serverseite geschehen und der Algorithmus könnte vollständige in Java implementiert werden. Mit Apache Batik 10, einer Bibliothek zum Generieren und Manipulieren von SVG- Grafiken, kann dieser Vorgang zudem noch vereinfacht werden. Durch den Einsatz von JavaScript kann sogar auf der Client-Seite der SVG-Code direkt verändert werden. Mittlerweile wird diese Technologie auch von den meisten Webbrowsern hinreichend unterstützt, sodass es keine Probleme mit der Darstellung gibt. All diese Argumente sprechen für die Verwendung von SVG in dieser Diplomarbeit. Zudem kann eine entsprechende Darstellung auf Basis des Werkzeugs von Sun sehr schnell umgesetzt werden Tabellarische Darstellung der Prozessmodelle und Prozessinstanzen Die tabellarische Darstellung der Prozessmodelle und Prozessinstanzen könnte beispielsweise auch mit Hilfe von JavaFX realisiert werden. Allerdings ist die Umsetzung einer einfachen Tabelle mit dieser Technologie vergleichsweise mit hohem Aufwand verbunden. Dies gehört jedoch auch nicht zum angedachten Aufgabenspektrum von JavaFX. Aufgrund der Verwendung von HTML, welche unteranderem dafür entwickelt wurde, kann eine solche Darstellung mit GWT [17] oder JSF [35] wesentlich einfacher realisiert werden. Google Web Toolkit (GWT) Das Google Web Toolkit nutzt zur Entwicklung die Programmiersprache Java. Anschließend wird dieser Quelltext in JavaScript übersetzt. Die angezeigte HTML-Seite wird nach am Aufruf dynamisch erzeugt. Da GWT kein vollständiges Framework ist, wird im Hintergrund die Java Servlet Technologie [33] eingesetzt. Alle Interaktionen mit dem Server laufen über AJAX, sodass keine Seite neugeladen werden muss. Eine Rich Internet Application lässt sich somit ohne Probleme realisieren. Allerdings benötigt GWT sehr viel Vorarbeit für die Konfiguration, um eine lauffähige Anwendung zu erhalten. Für einen Prototyp ist dies nicht optimal, da man einen raschen Durchstich erreichen möchte. Außerdem gibt es für Tabellen keine fertigen Komponenten, die sich direkt einsetzen lassen. Diese müssten dafür erst entwickelt werden. Außerdem ist es nicht immer gewollt Berechnungen auf dem

21 Client durchzuführen (z.b. aufgrund von Sicherheitsaspekten oder notwendiger Leistungsfähigkeit). Natürlich können diese auch auf dem Server ausgeführt werden, hierfür muss aber eine weitere Schnittstelle definiert werden, auf die der Client per AJAX zugreift. Außerdem wird in diesem Fall der größte Vorteil von GWT nicht genutzt. Da während der Entwicklung nur Java Code entsteht, ist es für einen Java-Programmierer sehr einfach, einen Einstieg zu finden. Die Trennung von Design und Code kann so allerdings nur schwer umgesetzt werden. JavaServer Faces (JSF) JavaServer Faces ist Teil der Java Enterprise Edition und setzt auf JSP-Seiten auf, indem eigene Tags und Filter hinzugefügt werden. Ab Version 2.0, die Bestandteil der 2009 veröffentlichten Java EE Version 6.0 [32] ist, ist eine vollständige Abtrennung von JSP-Seiten möglich. Außerdem wird seitdem auch AJAX, das heißt asynchroner Aufruf von Funktionen auf dem Server, unterstützt. Eine Integration in eine Java EE Anwendung ist problemlos möglich. Zu einer JSF Anwendung gehört immer mindestens eine sogenannte Managed Bean und eine JSP- Seite bzw. ein Facelet (dabei handelt es sich um eine spezielle XHTML-Seite [51]). JSF enthält viele Komponenten, die sich problemlos kombinieren lassen. Auch können seit der Version 2.0 sehr leicht eigene Komponenten angefertigt werden. Diese relativ neue Version hat allerdings auch den Nachteil, dass noch kaum zusätzliche Komponenten existieren, die die Arbeit erleichtern. Aus diesem Grund müssten auch hier eigene Komponenten entwickelt werden, die die bestehenden ergänzen. Dafür erlaubt JSF aber einen schnellen Durchstich, sodass sehr schnell eine ungefähre Vorstellung vermittelt werden kann, wie die Anwendung später aussehen soll. Durch die strikte Trennung von Design und Code, können diese Artefakte separat angepasst und wiederverwendet werden. Entscheidung Beide Technologien lassen sich sehr einfach in eine Java Anwendung integrieren, können ohne Probleme erweitert werden und setzen nur einen Standardwebbrowser voraus. Da mit beiden Technologien bereits Erfahrungen gesammelt wurden, kann dies auch nicht zur Entscheidung führen. GWT eignet sich hervorragend für komplexe Webanwendungen, die sehr viele Berechnungen auf der Clientseite durchführen. Da in dieser Diplomarbeit die Darstellung von Inhalten im Vordergrund steht ist JavaServer Faces aber die bessere Wahl. Zwar gibt es auch hier einige Funktionen wie Sortier- und Filtermöglichkeiten, diese können aber auch mit JSF problemlos realisiert werden. Da JSF nur eine Schnittstelle beschreibt muss noch eine konkrete Implementierung ausgewählt werden. In dieser Diplomarbeit wird MyFaces [3] von Apache eingesetzt, diese könnte aber einfach gegen eine andere Implementierung getauscht werden Workflow Management System (WfMS) Als WfMS wird Apache ODE [4] (Orchestration Director Engine) eingesetzt, da es sich um eine frei zugängliche und kostenlose Open-Source-Software handelt. Diese bietet zudem noch eine Management API, über welche Prozessmodelle, Prozessinstanzen und Ereignisse abgerufen werden können. Außerdem lässt sich Apache ODE ohne Probleme einrichten und konfigurieren und bietet eine vollständige Unterstützung von WS-BPEL 2.0 (d.h. alle Aktivitätstypen werden unterstützt). Zudem ver- 21

22 wendet eines der bereits vorgestellten Werkzeuge [49] ebenfalls diese Software. Der Open ESB von Sun, welcher von dem ebenfalls erwähnten Tool [47] genutzt wird, bietet dem gegenüber keine vollständige Unterstützung von BPEL und scheidet somit aus Zusammenfassung In dieser Zusammenfassung werden alle eingesetzten Technologien und deren Version ausgelistet. Auch die eingesetzten Werkzeuge werden aufgeführt. Diese werden für die Entwicklung und den Betrieb verwendet, können aber auch ausgetauscht werden und haben keinen Einfluss auf die Architektur der Anwendung. Bibliotheken, die die eingesetzten Technologien benötigten und mitlieferten, werden hier nicht aufgeführt. JSF 2.0 benötigt keine weiteren Teile aus Java EE 6, obwohl es selbst Teil dieser Spezifikationssammlung ist. Aus diesem Grund kann Apache Tomcat in Version 6 (Webcontainer für Java EE 5) eingesetzt werden. Eingesetzte Technologien Java Standard Edition 6 JavaServer Faces 2.0 o Apache MyFaces 2.0 Apache Orchestration Director Engine (ODE) 1.34 Scalable Vector Graphics (SVG) 1.2 Cascading Style Sheets (CSS) Level 2 WS-BPEL 2.0 Eingesetzte Werkzeuge Apache Tomcat [6] Eclipse 3.5 (Galileo) Java EE Version [] MySQL 5.1 [37] 4.2 Resultierende Architektur Abbildung 3 zeigt die Architektur der Anwendung, die in dieser Diplomarbeit entwickelt wurde. Wie bereits beschrieben handelt es sich um eine dreischichtige Architektur mit einem Client, einem Webserver und einem WfMS. Alle drei Schichten können in getrennten Umgebungen laufen, da alle Daten über das Netzwerk abgerufen werden können. Da eine Rich Internet Application entwickelt wird, reicht auf der Clientseite ein Webbrowser für die Bedienung der Anwendung (siehe Client5.1). Dieser ruft die Prozessdaten (Prozessmodelle und Prozessinstanzen) und die Graphen (SVG-Grafiken) vom Webserver ab. Auf dem Webserver läuft eine Java Webanwendung, die sich in drei beziehungsweise vier Komponenten unterteilt. Die nicht abgebildete Komponente BPI Model (siehe 5.2) beinhaltet das Datenmodell der Anwendung und wird von den anderen drei Komponenten verwendet. Für das Verständnis der Architektur ist sie nicht entscheidend und wird deshalb hier nicht dargestellt. Das BPI Frontend enthält die XHTML-Seiten, Ressourcen (wie z.b. Bilder und CSS) und Java-Klassen, die für die Darstellung der Daten (Prozessmodelle, Prozessinstanzen und Graphen) auf der Oberfläche und das Behandeln und Weiterleiten der Benutzeraktionen notwendig sind. 22

23 Die zentrale Komponente ist der BPI Service. Er ruft die Prozessdaten und Ereignisse, die anschließend zu Statusinformationen aggregiert werden, über den BPI Service Adapter vom WfMS ab. Die Prozessdaten gibt der BPI Service an die BPI Frontend Komponenten weiter. Eine weitere Aufgabe besteht darin die Graphen, für die die Statusinformationen benötigt werden, zu generieren. Die letzte Komponente auf dem Webserver ist der BPI Service Adapter ODE. Dabei handelt es sich um eine Implementierung des BPI Service Adapters. Dieser Adapter wird verwendet, um die Funktionalität, die für den Abruf der Prozessdaten und Ereignisse vom WfMS notwendig ist, vor der restlichen Anwendung zu verbergen. Welche Funktionen bereitgestellt werden müssen, bestimmt der BPI Service Adapter, der Teil des BPI Service ist. Auf diese Weise können beliebige WfMS eingesetzt werden, da nur der Adapter den speziell benötigten Code enthält (siehe auch [19]). Welche Implementierung geladen werden soll, wird zur Laufzeit bestimmt. In Abbildung 3 ist der Adapter für Apache ODE abgebildet, da dieser in der Diplomarbeit auch realisiert wird. Natürlich können auch weitere Adapter implementiert werden. Allerdings wird nur ein Adapter gleichzeitig verwendet. Die Aufteilung in vier Komponenten (die Komponente BPI Model ist nicht abgebildet) ist aus folgenden Gründen zweckmäßig: Jede Komponente hat nur Kenntnisse von der direkt benachbarten rechten Komponenten (BPI Frontend also von BPI Service und BPI Service von BPI Service Adapter ODE). Daher ist es sinnvoll, das Datenmodell in eine eigene Komponente, dem BPI Model, auszulagern. Die Trennung von Adapter und BPI Service erlaubt einen einfachen Austausch und wurde bereits im vorherigen Abschnitt erläutert. Durch die Unterteilung in BPI Frontend und BPI Service kann sehr einfach eine andere Oberfläche implementiert werden, da eine Schnittstelle vorliegt gegen die programmiert (5.4) werden kann. Auch eine Bereitstellung des BPI Service als Webservice wäre somit problemlos möglich. Als letzter Teil in der Architektur folgt das WfMS. In dieser Diplomarbeit wird Apache ODE (siehe 5.6) eingesetzt, über deren Management API die Prozessdaten und Ereignisse abgerufen werden können. Die Schnittstelle kann über Webservices aufgerufen werden. Allerdings fehlt in der genutzten Version die Implementierung der Operation zum Abruf der Ereignisse. Deshalb greift der Adapter auf diese Informationen direkt über die Datenbank der ODE zu. Abbildung 3 - Architektur (Komponentendiagramm) Abbildung 4 zeigt eine beispielhafte Sequenz, wie die Anwendung genutzt werden kann. Zunächst werden die Prozessmodelle mit den Prozessinstanzen geladen. Der Aufruf wird vom BPI Frontend an 23

24 den BPI Service weitergeleitet. Dieser trennt die Anfrage in zwei auf: Zunächst werden die Prozessmodelle geladen und die zugehörigen BPEL-Dokumente geparst, um die enthaltenen Aktivitäten zu ermitteln. Im Anschluss werden alle Prozessinstanzen der Prozessmodelle abgerufen. Diese beiden Anfragen an das WfMS werden über den BPI Service Adapter, der hier der Übersichtlichkeit wegen nicht dargestellt ist, weitergeleitet. Sind alle Prozessmodelle und deren Prozessinstanzen geladen, kann der Benutzer ein Prozessmodell und eine Prozessinstanz auswählen, zu denen ein Graph generiert werden soll. Für die bereits ermittelten Aktivitäten werden die Ereignisse vom WfMS abgerufen und diese im Anschluss zu Statusinformationen aggregiert. Im letzten Schritt wird der Graph generiert und dem Client zurück gegeben. Auf die Konzepte, die hinter den hier aufgeführten Aktionen stehen, wird im nächsten Kapitel detailliert eingegangen. Abbildung 4 - Architektur (Sequenzdiagramm) 24

25 5 Konzepte In diesem Kapitel werden die entwickelten Konzepte dargestellt. Diese sind natürlich von den Technologien abhängig, die im vorigen Kapitel vorgestellt und ausgewählt wurden. Die Aufteilung richtet sich an den, in der Architektur beschriebenen, Komponenten aus. 5.1 Client Durch die Entscheidung eine Rich Internet Application zu erstellen werden die Anforderungen an den Client stark reduziert. Es wird nur ein Webbrowser benötigt, der die Ausgabe der Daten übernimmt und die Eingabe des Benutzers an den Server sendet. Dem Benutzer soll das Gefühl geben werden, dass er eine lokale Anwendung bedient. Es wird jedoch keine Installation benötigt und die Anwendung kann somit von jedem Rechner mit Webbrowser und Internetzugang bedient werden. Natürlich erhöht der Einsatz von JavaScript die Anforderungen an den Client, indes werden aber keine aufwändigen Berechnungen durchgeführt, sondern nur Informationen asynchron versendet und angefordert. Auch ist der Einsatz von AJAX mittlerweile Standard und entsprechend leistungsfähige Hardware kann vorausgesetzt werden. Für die Darstellung des Graphen des Prozessmodells wird SVG verwendet, was nahezu alle gängigen Browser unterstützen (für den Internet Explorer existiert ein entsprechendes Plug-In 11 ). Auf diese Weise kann die Anwendung unabhängig vom eingesetzten Betriebssystem und genutzten Rechner verwendet werden. 5.2 BPI Model Bei der Komponente BPI Model handelt es sich um das Datenmodell der Anwendung, das von allen Komponenten auf dem Webserver (BPI Frontend, BPI Service und BPI Service Adapter ODE) genutzt wird. Das Datenmodel soll möglichst unabhängig von der tatsächlich verwendeten Beschreibungssprache der Geschäftsprozesse und den denkbaren Darstellungsoptionen sein. So kann das Datenmodel sowohl BPEL- als auch BPMN-Prozesse beschreiben. Grafisch könnte das Prozessmodell zum Beispiel als SVG-Grafik oder generiertes Bild dargestellt werden. Das Klassendiagramm (siehe Abbildung 5) zeigt die wichtigsten Klassen und deren Beziehungen untereinander. Die unterschiedlichen BPEL-Aktivitäten und deren Abbildung auf das Datenmodell werden in Abschnitt beschrieben

26 5.2.1 Prozessmodell Abbildung 5 - Klassendiagramm des Datenmodells Das Prozessmodell (ProcessModel) besitzt eine Identifikationsbezeichnung (pid process id), einen Namen und eine Version. Außerdem wird eine URL zum dazugehörigen Dokument gespeichert. Diese URL wird vom Parser benötigt, der die Aktivitäten des Prozessmodells anhand des Dokuments erzeugt. Diese URL liefert der Apache ODE; sollte ein anderes WfMS diese Information nicht bereitstellen muss der Adapter dies übernehmen. Zusätzlich besitzt ein Prozessmodell einen Status (Process- ModelStatus). Dieser gibt an, ob weitere Instanzen erzeugt werden können (ACTIVE) oder ob nur noch bereits erstellte Instanzen zu Ende laufen können (RETIRED) Prozessinstanz Zu einem Prozessmodell können beliebig viele Prozessinstanzen (ProcessInstance) gehören, die ebenfalls über eine Identifikationsbezeichnung (iid instance id) verfügen. Außerdem werden das Startdatum, das Datum der letzten Aktivität und der Zeitpunkt seit dem ein Fehler aufgetreten ist gespeichert. Eine Prozessinstanz kann sich in einem der folgenden Status (ProcessInstanceStatus) befinden: 26

27 Name Icon Beschreibung ACTIVE Die Ausführung ist aktiv. SUSPENDED COMPLETED TERMINATED FAILED ERROR Die Ausführung wurde unterbrochen. Die Ausführung wurde erfolgreich abgeschlossen. Die Ausführung wurde durch einen Administrator abgebrochen. Die Ausführung wurde aufgrund eines Fehlers beim Ausführen einer Aktivität beendet. Die Ausführung wurde aufgrund eines Fehlers des WfMS beendet. Tabelle 2 - Statusmodell der Prozessinstanzen Die Status-Icons stammen von [10] und können problemlos ausgetauscht werden. Abbildung 6 zeigt die möglichen Übergänge der Prozessinstanz-Status. Das Statusmodell der Prozessinstanzen basiert auf dem Modell der Apache ODE [4] und dem BPEL Event Modell [24] (siehe auch [46]). Die Abbildung der Informationen aus der WfMS auf den konkreten Status übernimmt der BPI Service Adapter (5.5) Aktivität Abbildung 6 - Statusübergänge der Prozessinstanzen Bei der Aktivität (Activity) handelt es sich um eine abstrakte Basisklasse. Sie besitzt einen Namen, der als Identifikationsbezeichnung benutzt wird, und einen Typ, der vom Parser festgelegt wird. Dieser Typ wird verwendet, um später in der grafischen Darstellung unterschiedliche Icons und Beschriftungen einzufügen. Außerdem wird beim Parsen die aktuelle Tiefe einer Aktivität in der hierarchischen Anordnung wie sie zum Beispiel bei BPEL auftritt gespeichert. Eine Aktivität wird unterteilt in simple Aktivitäten (ActivitySimple) und komplexe Aktivitäten (ActivityComplex). Letztere können im Gegensatz zu den erst genannten weitere Aktivitäten als Kind-Aktvititäten beinhalten. Die komplexe Aktivität teilt sich weiter auf in ActivityChoice, ActivitySequence und ActivityFlow. Bei einer ActivityChoice handelt es sich um eine Aktivität, bei der nur eine oder zumindest eine Auswahl der Kind-Aktivitäten ausgeführt wird. Bei der ActivitySequence werden alle Kind-Aktivitäten nacheinander also sequenziell - ausgeführt. Bei der ActivityFlow kann die Ausführung der Kind-Aktivitäten beliebig erfolgen. Sie werden durch Links verbunden und können somit sequenziell oder parallel ausgeführt werden. Eine Ausführung einzelner Aktivitäten wie bei der ActivityChoice ist ebenfalls möglich. Innerhalb einer ActivityFlow können weitere ActivityChoice oder ActivitySequence verwendet werden. 27

28 Bei der Wurzelaktivität (ActivityRoot) handelt es sich um eine besondere ActivityChoice. Sie wird verwendet, um einige Informationen, die während des Parsens ermittelt werden, zu speichern. Dazu gehören alle verwendeten Typen und Namen der Aktivitäten sowie die maximale Verschachtelungstiefe. Natürlich könnten diese Informationen auch im Prozessmodell abgelegt werden, aber auf diese Weise erhält das Prozessmodell nur einen Verweise zur Wurzelaktivität und bleibt ansonsten relativ schlank. Die Wurzelaktivität kann im Graph als Start- bzw. Endpunkt verwendet werden. Typischerweise werden Kind-Aktivitäten bei einer ActivityChoice nebeneinander und bei einer ActivitySequence nacheinander angeordnet. Für die ActivityFlow wird ein komplexerer Algorithmus benötigt. Weitere Details zu diesem Thema finden sich im Abschnitt Link Die Links zwischen Aktivitäten (Link) innerhalb einer Flow-Aktivität werden gesammelt in der Wurzelaktivität gespeichert; können aber, da alle Aktivitäten einen Verweis zur Wurzel haben, überall abgerufen werden. Zu einem Link gehören ein Name, der als Identifikationsbezeichnung verwendet wird, eine Quelle und ein Ziel. Durch die globale Speicherung in der Wurzel können Probleme mit Links von Aktivitäten innerhalb einer Flow-Aktivität zu geschachtelten Aktivitäten oder umgekehrt vermieden werden Ereignisse und Statusinformationen Die Ereignisse (ActivityExecEvent), die aus dem WfMS abgerufen werden, beinhalten den Namen der zugehörigen Aktivität und das Aufzeichnungsdatum. Diese Ereignisse werden später zu Statusinformationen (ActivityExecData) mit Start- und Endzeitpunkt aggregiert. Beide sind einer Prozessinstanz zugeordnet und befinden sich in einem der folgenden Status: Name Icon Beschreibung OUSTANDING Die Aktivität wurde noch nicht ausgeführt oder es existieren keine Informationen über den Status. SKIPPED Die Aktivität wurde übersprungen. ENABLED STARTED RECOVERY FAILURE COMPLETED Die Aktivität ist aktiviert, aber noch nicht gestartet. Die Aktivität ist gestartet. Die Aktivität ist fehlgeschlagen, der Ausgangszustand wird wieder hergestellt. Die Aktivität ist fehlgeschlagen, der Ausgangszustand sollte wieder hergestellt werden. Die Aktivität wurde erfolgreich beendet. Tabelle 3 Statusmodell der Aktivitäten Die verwendeten Icons stammen ebenfalls von [10] und können zum Beispiel durch Änderung der Einstellungen (siehe ) ausgetauscht werden. Abbildung 7 zeigt die möglichen Übergänge der Aktivitätsstatus. Das Statusmodell der Aktivitäten basiert auf dem Modell der Apache ODE [4] und dem BPEL Event Modell [24] (siehe auch [46]). Die Abbildung der Informationen aus dem WfMS auf den konkreten Status übernimmt der BPI Service Adapter (5.5). 28

29 5.3 BPI Frontend Abbildung 7 - Statusübergänge der Aktivitäten Die Komponente BPI Frontend wird in zwei Abschnitten beschrieben. Im ersten wird aufgezeigt wie die Oberfläche aussehen kann, welche Daten angezeigt werden sollen und welche Funktionen dem Benutzer bereit gestellt werden. Anschließend wird im zweiten Abschnitt erläutert, wie diese Oberfläche mit JavaServer Faces realisiert werden kann Konzept für die Oberfläche Die Grundidee für das Aussehen der Anwendung stammt wie auch die Darstellung des Prozessmodells vom BPEL2SVG Generator von Sun [47]. Abbildung 8 zeigt einen Screenshot aus dieser Anwendung. In der oberen Tabelle sind die Prozessinstanzen und in der unteren Tabelle die Aktivitäten mit ihrem Status zu finden. Darunter befindet sich die grafische Darstellung des Prozessmodells. Allerdings kann diese Vorlage nicht alle Anforderungen erfüllen. Die Sortierung der Prozessinstanzen ist zwar möglich, allerdings lassen sich die Einträge nicht filtern, sodass diese Ansicht sehr schnell unübersichtlich wird. Die Prozessmodelle, die auf dem WfMS installiert sind, können nicht separat gefiltert werden, sondern sind nur indirekt in der Tabelle der Prozessinstanzen sichtbar. Die Liste der Aktivitäten ist zudem in diesem Konzept nicht notwendig, da die grafische Darstellung des Prozessmodells diese Informationen ebenfalls liefert (siehe ). 29

30 Abbildung 8 - Vorlage für die Oberfläche Das hier präsentierte Konzept verwendet ebenfalls zwei Tabellen. Allerdings wird die erste für die Darstellung der Prozessmodelle und die zweite für die der Prozessinstanzen verwendet. Abbildung 9 zeigt die Umsetzung einer solchen Tabelle (in diesem Fall die Tabelle der Prozessinstanzen). In der oberen Leiste wird auf der linken Seite die Überschrift und die Anzahl der momentan dargestellten Elemente angegeben. Im rechten oberen Eck befinden sich die Option zum Einstellen der maximal angezeigten Elemente pro Seite, ein Button zum Aktualisieren der Daten (d.h. erneutes Abrufen der Daten von dem WfMS) und ein Button zum Minimieren bzw. Maximieren dieser Tabelle. Auf diese Weise kann der Benutzer die dargestellten Informationen sehr stark einschränken, um sich auf das für ihn Wesentliche konzentrieren zu können. In der unteren Leiste befinden sich Buttons zum Wechseln der Seite. So ist es möglich auch sehr viele Elemente abrufen, ohne unnötig viel Platz zu verbrauchen. In der Mitte werden die Informationen der Elemente spaltenweise angezeigt. Jede Spalte kann aufoder absteigend sortiert werden. Einige bieten die Möglichkeit einen Filter einzustellen. Es kann entweder nach einem bestimmten Text oder einem Status gefiltert werden. In jeder Zeile befinden sich auf der rechten Seite noch Buttons zum Aus- oder Abwählen eines Prozessmodells oder zum Anzeigen der SVG-Grafik im selben oder in einem neuen Fenster. In der Tabelle der Prozessinstanzen werden nur solche angezeigt, die zu einem ausgewählten Prozessmodell gehören. Unter den Tabellen kann nur eine SVG-Grafik gleichzeitig angezeigt werden. Dafür können beliebig viele Fenster geöffnet werden, die alle ihre eigenen Einstellungen haben und unabhängig voneinander verwendet werden können. 30

31 Abbildung 9 - Tabelle in der Oberfläche Tabelle 4 und Tabelle 5 zeigen die Daten der Prozessmodelle und Prozessinstanzen, die auf der Oberfläche angezeigt werden. Spalte Sortierung Filter PID (Prozessmodell ID) Ja Textfilter (PID enthält eingegeben Text) Name Ja Textfilter (Name enthält eingegeben Text) Version Ja - Status Ja Statusfilter (Auswahl eines Status) Prozessinstanz Anzahl Ja - Tabelle 4 - Dargestellte Daten Prozessmodell Spalte Sortierung Filter Name des Prozessmodell Ja Textfilter (Name enthält eingegeben Text) IID (Prozessinstanz ID) Ja Textfilter (IID enthält eingegeben Text) Status Ja Statusfilter (Auswahl eines Status) Startdatum Ja - Datum der letzten Aktivität Ja - Tabelle 5 - Dargestellte Daten Prozessinstanz Abbildung 10 zeigt den Kasten, der um die eingebettete SVG-Grafik gelegt wird. Wie auch bei den Tabellen existiert eine Kopfzeile. Auf der linken Seite befindet sich eine Zusammenfassung, welches Prozessmodell mit den Statusinformationen welcher Prozessinstanz angezeigt wird. Auf der anderen Seite kann das Intervall für das automatische Neuladen der SVG-Grafik eingestellt werden. Ein manuelles Neuladen ist mit Hilfe des Buttons daneben möglich. Auch dieser Kasten kann maximiert bzw. minimiert werden. Darunter befinden sich die verschiedenen Möglichkeiten zum Anpassen der Darstellung. An dieser Stelle sollen nur die Bedienungsmöglichkeiten beschrieben werden. Die Auswirkungen der Funktionen werden im Kapitel erläutert. In diesem Beispiel ist die Box zum Hervorheben der Aktivitätstypen aufgeklappt. Die anderen drei Boxen, die identisch aussehen, können ebenfalls maximiert werden. In der linken Spalte wird die Auswahlmöglichkeit angezeigt. In der rechten die aktuell ausgewählten Aktivitätstypen. Es ist möglich einzelne oder mehrere Typen hinzuzufügen oder zu entfernen. Unter diesen vier Boxen befinden sich die Slider (Schieberegler). Die Auswirkungen dieser Slider werden in Kapitel beschrieben. Als letztes wird die SVG-Grafik eingebettet. 31

32 Abbildung 10 - Einbettung der SVG-Grafik Die vollständige grafische Oberfläche mit beiden Tabellen und dem Kasten für die SVG-Grafik wird in Abbildung 11 gezeigt. Auf das Aussehen der grafischen Darstellung des Prozessmodells wird in Kapitel eingegangen Realisierung der Oberfläche Abbildung 11 - Vollständige Oberfläche Wie die Oberfläche aussehen soll und welche Möglichkeiten es für den Benutzer gibt, selbst Einfluss auf die Darstellung zu nehmen, wurde im vorherigen Abschnitt erläutert. Wie kann dies nun aber mit JavaServer Faces realisiert werden? Diese Frage soll in diesem Abschnitt beantwortet werden. Durch den Einsatz von JSF 2.0 und den damit eingeführten AJAX Funktionen, die einen dynamischen Aufbau der Seiten und Austausch einzelner Elemente erlauben, existieren in der gesamten Anwendung nur zwei Managed Beans und zugehörige Facelets. Bei den Managed Beans handelt es sich um 32

33 spezielle Java Beans, deren Lebensdauer sich entweder an eine Anfrage, an eine Session oder an die Lebensdauer der gesamten Anwendung richtet. Facelets sind normale XHTML-Dateien, die aber im Gegensatz zu JSP-Seiten keinen Java Code mehr enthalten können. Wie bereits im vorherigen Kapitel beschrieben, sind viele Elemente und Funktionen sehr ähnlich, sodass sich die Wiederverwendung dieser Teile anbietet. Hierfür bietet JSF die sogenannten Composite Components (Verbundkomponenten oder zusammengesetzte Komponenten). Diese erlauben wiederum wie schon der Name sagt Komponenten aus anderen Komponenten zusammen zusetzen und beliebig zu schachteln. Eine Composite Component ist eine XHTML-Seite die eine Schnittstelle definiert und die zugehörige Implementierung besitzt. Im abschließenden Beispiel wird dies genauer erklärt. Zwar gab es ein ähnliches Konzept schon in JSF 1.2, allerdings waren sie dort sehr umständlich gelöst und aufwändig umzusetzen. Zunächst mussten entsprechende Java Klassen implementiert werden, dann eine eigene Tag-Library erstellt werden und außerdem auch noch die zugehörige Konfiguration (faces-config.xml) angepasst werden. Die JSF 2.0 Composite Components sind zwar nicht ganz so mächtig, da sie nur auf bestehenden Tags aufbauen können, für die meisten Anforderungen reichen diese aber aus. Das alte Konzept kann aber weiterhin verwendet werden, um spezielle Komponenten zu erstellen, welche wiederum in den Composite Components verwendet werden. Die Oberfläche zeigt auf den ersten Blick bereits viele Stellen, welche sehr ähnlich aufgebaut sind und bei denen es sich lohnt Komponenten einzusetzen. Dazu gehören alle Buttons zum Minimieren oder Maximieren einer Tabelle oder eines Kastens, die Text- oder Statusfilter, die Sortierfunktion und auch Seiteneinstellungen. Für alle diese Teile können JSF Komponenten angelegt werden, allerdings reicht dies nicht aus. Es müssen auch entsprechende Java-Klassen erstellt werden, die die Funktionalität im Hintergrund übernehmen. Wie dies genau aussieht wird im Kapitel 6.2 der Implementierung beleuchtet. Bei den bisher genannten Komponenten handelt es sich um sehr kleine Teile. Es ist aber auch möglich, größere Teile (wie zum Beispiel die Tabellenköpfe oder die Boxen zum Anpassen des Graphen) als wiederverwendbare Komponenten anzulegen. Diese können dann wiederum die kleineren Komponenten (zum Beispiel Minimieren/Maximieren) enthalten. Alle Ressourcen, wie zum Beispiel Grafiken, CSS Dateien und auch Komponenten, sollten bei JSF 2.0 in einen speziellen Ordner gelegt werden, da sie dann über die neue Bibliotheksfunktion einfach geladen werden können. Listing 1 zeigt, wie ein Stylesheet eingebunden werden kann. Dieser Tag erlaubt es die Datei aus jedem Facelet zu importieren. Auf relative Pfade muss nicht geachtet werden. Das Einbinden von Grafiken oder JavaScript Dateien erfolgt analog. Die Komponenten werden auf eine etwas andere Weise verwendet (siehe Beispiel). // Pfad:./WebContent/resources/main/styles/main.css <h:outputstylesheet name="main.css" library="main/styles" /> Listing 1 - Einbinden von CSS in JSF 2.0 Eine weitere wichtige Funktion von JSF ist die Unterstützung verschiedener Sprachen. Die entsprechenden Texte werden in Java Properties Dateien abgelegt, entsprechend benannt und über die Konfigurationsdatei eingebunden. JSF wählt die Sprache automatisch anhand der Browsereinstellung. Eine manuelle Umstellung ist aber auch möglich. Selbst wenn nur eine Sprache angeboten werden 33

34 soll, bietet dieses System einen gewissen Vorteil, da alle Texte in einer Datei gesammelt werden und somit leichter angepasst werden können. Auch diese Funktion wird im Beispiel demonstriert. Das Einbinden der SVG-Grafik wird nicht mit Hilfe von JSF realisiert. Die erste Idee, die HTML [52] beziehungsweise XHTML [51] Tags <frame> oder <iframe> zu verwenden, lässt sich nicht realisieren, da beide nur die Einbettung von HTML-Dateien unterstützen. Allerdings existieren zwei andere Optionen. Die erste Möglichkeit wäre die direkte Verwendung von SVG-Code innerhalb eines XHTML- Dokuments. Theoretisch wäre dies durch Angabe des Namensraums möglich, da es sich bei SVG auch um XML basierte Beschreibungssprache handelt. Allerdings unterstützen dies nicht alle Webbrowser. Die verbliebene Möglichkeit ist die Verwendung des <object> Tags. Dieser erlaubt es beliebige Inhalte in eine Webseite ähnlich wie bei einem <iframe> zu integrieren. Die SVG-Grafik wird dynamisch (d.h. beim Aufruf) von einem Servlet erzeugt Beispiel Dieses Beispiel soll einen Einblick in die Verwendung der Composite Components geben. Aus Gründen der Übersichtlichkeit werden hier nicht alle benötigten, aber für diese Ausführung nicht wichtigen, Inhalte dargestellt. Die Lebensdauer der folgenden Managed Bean ist an eine Anfrage gebunden (RequestScoped), besitzt ein Attribut für die Ein- oder Ausgabe und eine Methode, die eine Aktion ausführt. // Pfad public class Bean { private String input = "Test"; public String dosomething() { dosomethingelse(); } return OK ; } // Getter und Setter für input Listing 2 - JSF Managed Bean Das Facelet enthält ein einfaches Formular mit einer Eingabe und einem Button zum Absenden. Bei der Eingabe handelt es sich um eine Komponente (siehe Listing 4). Diese erhält als Parameter den Eingabewert der Bean (#{bean.input}). Der Zugriff erfolgt über die Getter-Methode des Attributs. Nach diesem Schema erfolgt auch der Zugriff auf die Einträge der Properties-Datei. Die Komponente wird mit Hilfe des XML Namensraums eingebunden, welcher immer mit beginnen muss. Anschließend folgt der Pfad zu der Komponente, deren Dateiname wiederum den Tag-Namen angibt. 34

35 Außerdem wird ein Kind-Element eingebettet, welches einen Text ausgibt. Dieser stammt aus einer Properties-Datei und kann in unterschiedlichen Sprachen vorliegen. Auch der Button erhält als Beschriftung einen solchen Text. Die entsprechende Methode der Bean wird als Aktion, die beim Drücken des Buttons ausgeführt wird, angegeben. Um die Ausführung des Formulars dynamisch zu machen, wird ein AJAX Tag eingefügt. Dieses gibt an, dass alle Werte der Eingabefelder mit gesendet werden sollen und dass alle Ausgabefelder mit aktualisieren Werten neu gezeichnet werden sollen. Es können aber auch explizit verschiedene Elemente über deren ID angegeben werden. // Pfad zur Datei:./WebContent/index.xhtml <html xmlns=" xmlns:f=" xmlns:h=" xmlns:test=" <h:body <h:form> <test:input value="#{bean.input}"> <h:outputtext value= #{msg.label}" /> </test:input> <h:commandbutton value="#{msg.dosomething}" action="#{bean.dosomething}"> <f:ajax /> </h:commandbutton> </h:form> </h:body> </html> Listing 3 - JSF Facelet In Listing 4 ist die zugehörige Komponente abgebildet. Zunächst wird die Schnittstelle (d.h. die Attribute des Tags) definiert. Anschließend folgt die Implementierung. Dort wird ein Eingabefeld definiert, welches als Wert das zuvor definierte Attribut erhält. Welcher konkrete Wert beziehungsweise welche Referenz hinterlegt ist, muss die Komponente nicht wissen. Der Zugriff erfolgt über eine Liste aller definierten Attribute (cc.attrs). Zuvor können jedoch ein oder mehrere Kind-Elemente mit Hilfe des Tags <composite:insertchildren /> eingefügt werden. // Pfad zur Datei:./WebContent/resources/test/input.xhtml <html xmlns=" xmlns:h=" xmlns:composite=" <body> <composite:interface> <composite:attribute name="value" required="true" /> </composite:interface> <composite:implementation> <b><composite:insertchildren />:</b> <h:inputtext value="#{cc.attrs.value}" /> </composite:implementation> </body> </html> Listing 4 - JSF Composite Component 35

36 Abbildung 12 zeigt die Ausgabe des Facelets im Webbrowser. Das Eingabefeld ist mit dem Wert aus der Bean initialisiert. 5.4 BPI Service Abbildung 12 - JSF Facelets im Webbrowser Bei der BPI Service Komponente handelt es sich um den zentralen Bestandteil der Anwendung. Sie ist für den Abruf der Prozessmodelle und Prozessinstanzen von dem WfMS und dem Generieren der SVG-Grafik zuständig. Zum BPI Frontend hin gibt es eine klare Schnittstelle (siehe Abbildung 13), die die entsprechenden Methoden bereitstellt. Die Klasse BPIService erweitert das Interface Service, welches auch von den Interfaces des Services Adapters erweitert wird (siehe 5.5). Eine Instanz des BPIService wird mit Hilfe der BPIServiceFactory erzeugt, bei der es sich um eine innere Klasse handelt. Der Einsatz dieser Fabrikmethode (Entwurfsmuster der Gang of Four [16]) ist sinnvoll, da es möglich sein soll die konkrete Implementierung dynamisch zu ermitteln. Abbildung 13 - Klassendiagramm der BPI Service Schnittstelle Die Prozessinstanzen werden direkt mit den Prozessmodellen geladen, sodass direkt sämtliche Daten für die Anzeige bereitstehen. In dieser Methode werden außerdem die geladenen Prozessmodelle geparst und die Aktivitäten gespeichert. Beim Generieren der SVG-Grafik werden zunächst die Statusinformationen geladen und anschließend der Generator aufgerufen. Die BPI Service Komponente enthält außerdem die Schnittstellen für die konkrete Implementierung des BPI Service Adapters. Im Folgenden werden die bereits genannten Funktionen genauer erläutert Abfrage der Prozessmodelle Zunächst werden alle Prozessmodelle vom WfMS abgerufen. An dieser Stelle kann ein Caching Algorithmus, der die Daten für alle Benutzer bereit hält, sehr viel Zeit und auch Speicherplatz sparen: Es muss keine Adapter-Implementierung und die dahinter liegende WfMS aufgerufen werden und die Daten können global für alle Sitzungen gespeichert werden. Da nur selten neue Prozessmodelle hinterlegt werden, kann die Lebensdauer der gespeicherten Informationen vergleichsweise hoch angesetzt werden. Probleme mit Prozessmodellen, die im Cache noch vorkommen, aber nicht mehr auf dem WfMS hinterlegt sind, können hier vernachlässigt werden. Dies liegt zum einen daran, dass Prozessmodelle sehr selten gelöscht werden (in den meisten Fällen gibt es eine neue Version). Zum anderen wären für diese dann keine Prozessinstanzen mehr hinterlegt, die für die Generierung einer 36

37 SVG-Grafik herangezogen werden könnten. Ein erneutes Befüllen des Caches könnte beispielsweise nur manuell durch den Benutzer angestoßen werden. Zusätzlich könnten diese Daten auch in größeren Abständen automatisch überprüft werden. Im nächsten Schritt werden die Prozessinstanzen abgerufen. Dies kann mit einer einzigen Anfrage für alle Prozessmodelle geschehen oder für jedes Prozessmodell einzeln. Die Entscheidung für eine der beiden Möglichkeiten ist einerseits von dem eingesetzten WfMS und dem dazugehörigen Adapter, andererseits vom Einsatz eines Caching Algorithmus abhängig. Im Gegensatz zum Caching der Prozessmodelle muss hier die Lebensdauer wesentlich geringer sein, da ständig neue Prozessinstanzen erzeugt werden können und sich der Zustand bestehender schnell verändern kann. Auch wird nur sehr selten der Fall auftreten, dass Daten nur noch im Cache und nicht mehr im WfMS gespeichert sind. Zudem kann dies zu keinen Problemen führen, da die Daten nur gelesen und in keiner Weise zurückgesendet werden Prozessmodell Parser Der Parser wird nach dem Laden der Prozessmodelle und der Prozessinstanzen aufgerufen. Eine Validierung des Dokuments, das die Beschreibung des Prozessmodells enthält, ist nicht notwendig, da es bereits vom WfMS geprüft wurde. Sollte die Datei allerdings vom Adapter über einen anderen Weg bereitgestellt werden, muss der Parser dies ebenfalls übernehmen. Der nächste Schritt ist die Extraktion der relevanten Daten (z.b. Aktivitäten des Prozessmodells). Dafür wird ein DOM 12 (Document Object Model) erzeugt und anschließend rekursiv durchlaufen. Ein DOM bezeichnet eine Schnittstelle zum Zugriff auf XML-Dokumente. Die Struktur des Dokuments wird als Baum repräsentiert, der mit Hilfe von Rekursion durchlaufen werden kann. Falls eine Aktivität oder ein Link gefunden wird, wird eine entsprechende Instanz der zugehörigen Klasse (siehe 5.2.3) erzeugt und abgelegt. Die Ergebnisse des Parsers können entweder über die Prozessmodelle, die eine Referenz zur Wurzel aller Aktivitäten besitzen, oder aber über einen separaten Cache abgerufen werden. Letzteres kann dann eingesetzt werden, wenn kein Caching der Prozessmodelle durchgeführt wird. In diesem Fall wird die ID des Prozessmodells verwendet, um die Aktivitäten zuzuordnen. Dieses Verfahren kann für jeden Parser eingesetzt werden, der umgesetzt werden soll (also eine andere Beschreibungssprache für Geschäftsprozesse wie z.b. BPMN oder WSFL). In jedem Fall ist es die Aufgabe des Parsers die entsprechenden Aktivitätstypen (simpel, komplex etc.) zu erzeugen. Im Folgenden werden die Besonderheiten eines BPEL Parsers erläutert, der in dieser Umsetzung verwendet wird BPEL Parser Der BPEL Parser muss zunächst die erste Aktivität finden, in der alle weiteren verschachtelt sind. Alle anderen Informationen wie beispielsweise PartnerLinks oder Variables werden in dieser Arbeit nicht betrachtet. Allerdings kann diese durchaus eine wichtige Erweiterung darstellen (siehe 7.2) Die zugeordneten Klassen werden anhand der Daten in Tabelle 6 gefunden und anschließend wird eine Instanz erzeugt. Hierfür kann auf eine Fabrikmethode (Entwurfsmuster der Gang of Four [16]) zurückgegriffen werden. In der Tabelle befinden sich ebenfalls die zugehörigen Icons. Diese können mit Hilfe der Einstellungen (siehe Abschnitt ) problemlos ausgetauscht werden

38 Name Icon Typ Assign ActivitySimple Catch ActivitySequence CatchAll ActivitySequence Compensate ActivitySimple CompensateScope ActivitySimple CompensationHandler ActivityChoice Else ActivitySequence ElseIf ActivitySequence Empty ActivitySimple EventHandlers ActivityChoice Exit ActivitySimple ExtensionActivity ActivitySimple FaultHandlers ActivityChoice Flow ActivityFlow ForEach ActivitySequence If ActivityChoice Invoke ActivityChoice OnAlarm ActivitySequence OnEvent ActivitySequence OnMessage ActivitySequence OpaqueActivity ActivitySimple Pick ActivityChoice Receive ActivitySimple RepeatUntil ActivitySequence Reply ActivitySimple Rethrow ActivitySimple Scope ActivityChoice Sequence ActivitySequence TerminationHandler ActivityChoice Throw ActivitySimple Validate ActivitySimple Wait ActivitySimple While ActivitySequence Tabelle 6 - Aktivitätstypen mit Klassenzuordnung Die Icons für die Aktivitätstypen stammten aus dem Eclipse BPEL Editor [11]. Falls es sich um eine komplexe Aktivität handelt, werden die Kind-Aktivitäten untersucht. Bei einer Flow-Aktivität werden die hinterlegten Links global in der Wurzelaktivität abgespeichert. Die gegebenenfalls vorhandenen Einträge für die Quelle oder das Ziel eines Links werden nicht bei der Aktivität gespeichert, sondern der entsprechende Link bei der Wurzelaktivität gesucht. Dort werden die Quelle oder das Ziel angepasst. Dadurch muss nicht der zugehörige Flow gesucht werden. Der Zugriff auf die Wurzel ist somit ausreichend Abfrage der Ereignisse und Aggregation der Statusinformationen Vor dem Generieren der SVG-Grafik werden die Ereignisse zu einer Prozessinstanz vom WfMS abgerufen. Da für jeden Statusübergang einer Aktivität ein Ereignis erzeugt wird, müssen diese zu einer Statusinformation aggregiert werden. Dafür werden die Ereignisse nach dem Zeitpunkt und dem 38

39 enthaltenen Status sortiert. Anschließend wird der Zeitpunkt des ersten Ereignisses als Startzeitpunkt und der Zeitpunkt des letzten als Endzeitpunkt sowie der Status gespeichert. Aus diesen Daten wird eine Statusinformation erstellt und mit dem Namen der Aktivität als Schlüssel abgelegt. Das Caching dieser Daten ist nur wenig sinnvoll, da einerseits nur wenige gleichzeitig verwendet werden, andererseits sehr schnell neue hinzu kommen Generierung der SVG-Grafik Für das Generieren der SVG-Grafik werden mehrere Konzepte miteinander verbunden. Dazu gehören das spezielle SVG-Datenmodell, die Darstellungsform der Aktivitäten in der SVG-Grafik, die globalen und lokalen Einstellungen, der Layout-Algorithmus sowie die Anwendung der Process Views. Gemeinsam bilden diese Konzepte das Kernstück der gesamten Diplomarbeit aus SVG-Datenmodell Das allgemeine Datenmodell (Abschnitt 5.2) ist generisch aufgebaut und kann somit als Grundlage für verschiedene Darstellungen verwendet werden. Zur Generierung der SVG-Grafik existiert ein eigenes Datenmodell, welches die Struktur der Aktivitäten abbildet. Das bedeutet, dass jedes Klasse ein entsprechendes Pendant hat (z.b. ActivitySimple und ActivitySimpleElement). Abbildung 14 zeigt das zugehörige Klassendiagramm. Die Vererbungshierarchie ist identisch und der Zugriff auf die Links erfolgt wieder global über die Wurzel (ActivityRootElement). Die Links der Aktivitäten werden in gleicher Weise abgebildet. Alle ActivityElements haben eine Größe und eine Position und speichern die gekapselte Aktivität [47]. Während der Generierung der SVG-Grafik werden die Daten in der Klasse SVG gespeichert (hier nicht abgebildet). Diese Klasse besitzt ebenfalls eine Größe und der Inhalt kann beliebig erweitert werden. Außerdem existiert eine zusätzliche Klasse Grid (engl. Gitter, Netz), die für das Layout von Flow- Aktivitäten verwendet wird [25]. Innerhalb des Gitters können Platzhalter (PlaceHolderElement) genutzt werden. Das Grid speichert die ActivityElements zeilenweise. Dies bedeutet, dass eine Liste für jede Zeile existiert. Für jede Zeile existiert wiederum eine Liste mit den ActivityElements der jeweiligen Spalten. 39

40 Abbildung 14 Klassendiagramm des SVG-Datenmodells Darstellung der Aktivitäten Für die Darstellung aller Aktivitäten in der SVG-Grafik wird eine einheitliche Box verwendet (siehe Abbildung 15). Sie ist in fünf Teile unterteilt. Oben links wird der Typ der Aktivität als Icon und Text dargestellt (siehe 5.4.2). Im Feld rechts daneben befindet in gleicher Weise der Status der Aktivität (siehe 5.2.5). In der Mitte steht der Name der Aktivität, welcher gekürzt dargestellt wird, wenn mehr Platz benötigt wird, als die Box in der Breite bietet. Allerdings kann der vollständige Name dann über einen Tooltip angezeigt werden. Falls kein Name vorhanden ist, wird an dieser Stelle der Typ der Aktivität angezeigt. In der untersten Zeile befindet sich auf der linken Seite der Startzeitpunkt der Aktivität und auf der rechten Seite der Endzeitpunkt. Abbildung 16 zeigt eine kompakte Darstellung einer Aktivität. Um Platz in der grafischen Darstellung zu sparen, werden Start- und Endzeitpunkt sowie die Beschreibung der Icons entfernt und die Schrift verkleinert. Die Beschreibung der Icons lässt sich aber über einen Tooltip abrufen. Diese Darstellung bietet zwar nicht so viele Informationen, ist dafür aber wesentlich kompakter und übersichtlicher. Abbildung 15 - Box einer Aktivität Abbildung 16 - Kompaktbox einer Aktivität Zwar gelten die oben gezeigten Darstellungen auch für komplexe Aktivitäten, allerdings sind in ihnen weiter Aktivitäten verschachtelt. Abbildung 17 und Abbildung 18 zeigen die normale beziehungsweise kompakte Darstellung einer solchen Aktivität. Zusätzlich zur Box wird ein Rahmen um alle enthal- 40

41 tenen Kind-Aktivitäten gezogen und der Bereich wird grau hinterlegt. Gerade bei einer komplexen Aktivität zeigt sich der enorme Platzgewinn bei der kompakten Ansicht. Abbildung 17 - Box einer komplexen Aktivität Abbildung 18 - Kompaktbox einer komplexen Aktivität Welche Ansicht für die Darstellung gewählt wird, wird in den Einstellungen festgelegt (siehe nächster Abschnitt). Das Aussehen der Box, der Texte und des Rahmens kann via CSS angepasst werden. Die angezeigten Icons befinden sich in den jeweiligen Ordnern (Typ, Status und Datum) und können somit ohne Probleme ausgetauscht werden. Wenn die Größe der Box oder der Bilder geändert werden soll, müssen dafür die globalen Einstellungen angepasst werden. Abbildung 19 zeigt die möglichen Positionen für ein- oder ausgehende Links bei einer Kompaktbox (für die große Box gilt dasselbe). Abbildung 19 - Ein- und Ausgangspunkte für Links 41

42 Punkt Blau Lila Rot Orange Grün Beschreibung Position für eingehende Links. Position für ausgehende Links innerhalb eines ActivitySequenceElements oder eines ActivityChoiceElement. Position für ein- und ausgehende Links innerhalb eines ActivityFlowElements. Position für eingehende Links innerhalb eines ActivitySequenceElements oder eines ActivityChoiceElement. Position für ausgehende Links. Tabelle 7 - Ein- und Ausgangspunkte für Links In Abbildung 20 werden alle zuvor beschriebenen Positionen verwendet. Die Start- und Endpunkte links beziehungsweise rechts von den Kästen reduzieren die Länge der gezeichneten Pfeile und verbessern so die Übersicht. Der gesamte Flow kann auf diese Weise kleiner gestaltet werden, da ansonsten die Reply-Aktivität weiter nach unten verschoben werden müsste Einstellungen Abbildung 20 - Ein- und Ausgangspunkte für Links (Beispiel) Es gibt zwei Arten von Einstellungen, die bei der Generierung der SVG-Grafik verwendet werden. Zum einen die globalen Einstellungen, die für alle Vorgänge identisch sind und beim Start der Anwendung festgelegt werden. Zum anderen die lokalen Einstellungen, die nur für einen Generierungsvorgang gelten. Nur das spezielle SVG-Datenmodell hat Zugriff auf diese Informationen. Globale Einstellungen Zu den globalen Einstellungen gehören die Pfade zu den CSS- und JavaScript-Dateien, die Größe der Boxen der Aktivitäten (Normal- und Kompaktansicht) sowie die Pfade und Größen der verwendeten Bilder. All diese Informationen werden beim Generieren der SVG-Grafik benötigt und können zum Beispiel über eine Konfigurationsdatei festgelegt werden. Statischer Zugriff erlaubt es, die Konfiguration nur einmal beim Start der Anwendung laden zu müssen. Wenn beispielsweise die Größe der Boxen geändert werden soll, muss allerdings auch das verlinkte CSS angepasst werden. 42

43 Lokale Einstellungen Die lokalen Einstellungen werden für jede Generierung neu gesammelt und enthalten alle Konfigurationen, die der Benutzer über die Oberfläche festlegen kann. Somit können sie nicht in einer Konfigurationsdatei gespeichert werden. Zu den Einstellungsmöglichkeiten gehören die Namen und Typen der Aktivitäten, die hervorgehoben oder ausgeblendet werden sollen, und die aktuellen Stufen der beiden Slider (siehe ). Welche Ansicht für die Box der Aktivitäten verwendet werden soll, wird ebenfalls hier gespeichert. Außerdem werden in den lokalen Einstellungen auch die ermittelten Statusinformationen abgelegt. Der Zugriff auf all diese Daten erfolgt über eine Referenz, welche jedes ActivityElement beim Generieren der SVG-Grafik erhält Layout-Algorithmus Wie auch schon bei der Vorstellung des SVG-Datenmodells erwähnt, ist die grundlegende Idee eine Anordnung der Aktivitäten untereinander. Dies entspricht der Gewohnheit der Benutzer, die im Webbrowser überwiegend vertikales Scrollen durchführen. Das Datenmodell ist definiert, das Aussehen festgelegt, aber wie werden die einzelnen Aktivitäten nun genau angeordnet? Die Idee hinter dem Layout-Algorithmus basiert auf dem BPEL2SVG Generator von Sun [47]. Dieser stammt aus dem Jahr 2008 und gründet auf einem Monitoring Werkzeug [22] für den Open ESB. Er kann für das direkte Generieren einer SVG-Grafik aus einer BPEL-Datei verwendet werden. Alternativ ist es auch möglich die Anwendung mit dem Open ESB zu betreiben, um Monitoring Informationen abzurufen. Die Darstellung unterscheidet allerdings nur zwischen inaktiven (transparentes Bild) und aktiven (normales Bild) Aktivitäten. Zudem unterstützt der BPEL2SVG Generator die Anordnung von Aktivitäten innerhalb eines Flows nicht. Zudem ist das zugrundeliegende Datenmodell sehr stark auf BPEL zugeschnitten und lässt sich nur schwer anpassen. Dies sind Gründe, warum in dieser Diplomarbeit ein eigener Ansatz entwickelt wurde, dessen Grundidee allerdings auf dem SVG-Generator von Sun basiert. Dieser Generator hat jedoch den Vorteil, dass es möglich ist die Standardanordnung der Aktivitäten (von links nach rechts) auf eine Anordnung von oben nach unten umzustellen. Der hier präsentierte Ansatz unterstützt nur eine Anordnung von unten nach oben, die dem Nutzerverhalten entspricht. Allerdings könnte der Algorithmus an dieser Stelle erweitert werden. Der Layout-Algorithmus besteht aus zwei Teilen: Die Berechnung der Größe der Box einer Aktivität inklusive eventuell vorhandener Kind-Aktivitäten und der Positionierung dieser Box. Diese zwei Daten werden schrittweise berechnet. Zuerst wird die Größe ermittelt. Begonnen wird bei der Wurzel, die als Start- und Endpunkt fungiert. Die Größe der vorhandenen Kind-Aktivitäten wird bei der Berechnung abgefragt und der Vorgang rekursiv wiederholt, bis ein ActivitySimpleElement gefunden wird oder keine weiteren Kind-Aktivitäten mehr vorhanden sind. Durch die normale und kompakte Darstellung gibt es zwei mögliche Größen für ein ActivitySimpleElement. Beide sind in den globalen Einstellungen definiert. Welche der beiden verwendet wird, wird mit Hilfe der lokalen Einstellungen ermittelt. Zusätzlich zur eigentlichen Größe der Box einer Aktivität wird ein Wert hinzufügt, der den Außenabstand angibt. Dies verbessert die Übersicht in der grafischen Darstellung ungemein. Für ActivityChoiceElement oder ActivitySequenceElement ist die Berechnung der Größe vergleichsweise einfach, denn die Breite beziehungsweise Höhe der Kind-Aktivitäten kann einfach aufaddiert 43

44 werden. Die Ermittlung der Größe einer ActivityFlowElement ist allerdings wesentlich komplexer, da hier die Aktivitäten frei angeordnet werden können. Im zweiten Schritt werden die Aktivitäten positioniert und im gleichen Zuge die SVG-Grafik aufgebaut. Auch hier werden die Aktivitäten, die absolut angeordnet werden, wieder rekursiv durchlaufen. Im Folgenden wird auf die drei komplexen Typen (ActivitySequenceElement, ActivityChoiceElement und ActivityFlowElement) eingegangen. Zum Abschluss wird ein ausführliches Beispiel präsentiert. ActivitySequenceElement Größenberechnung Bei einem ActivitySequenceElement wird die Höhe ihrer Kind-Aktivitäten einfach aufsummiert, da alle Kinder untereinander angeordnet werden. Die Breite ergibt sich aus der größten Breite eines der Kinder. Falls die Aktivität keine Kind-Aktivitäten haben sollte, wird auf die Standardgröße zurückgegriffen. In der Darstellung wird auch nur die Standardbox (ohne Rahmen) verwendet. Im anderen Fall wird zusätzlich die Standardhöhe aufaddiert, um Platz für die Box der Aktivität zu schaffen. Das nachfolgende Code-Listing zeigt den Algorithmus. Die Rekursion wird indirekt beim ersten Aufruf der Breite oder Höhe einer Kind-Aktivität angestoßen. int width = 0; int height = 0; // Iteriere über Kind-Aktivitäten for each (child : CHILDREN) { // Wenn die Breite der Kind-Aktivität größer ist als die bisher berechnete, diese speichern if (child.width > width) width = child.width; } // Höhe der Kind-Aktivität aufaddieren height += child.height; // Für den Fall, dass keine Kind-Aktivität vorhanden sind, wird die Standardgröße verwendet if (CHILDREN.size == 0) { width = DEFAULT_WIDTH; height = DEFAULT_HEIGHT; } else height += DEFAULT_HEIGHT; return [width, height]; Listing 5 - Größenberechnung bei ActivitySequenceElement Positionierung und SVG-Generierung Da bei einem ActivitySequenceElement alle Aktivitäten untereinander angeordnet werden, werden im Positionierungsschritt also nur noch konkrete Werte für die absolute Position der Kind-Aktivitäten berechnet. Außerdem werden Pfeile zwischen den Kind-Aktivitäten eingefügt. Die Idee bei diesem Algorithmus, der im nachfolgenden Code-Listing gezeigt wird, ist das Speichern der Position für die 44

45 nächsten Kind-Aktivitäten und für den Startpunkt des nächsten Pfeils. Beide Werte werden am Ende einer Iteration für die nächste neu berechnet. Auf diese Weise wird von der Box ausgehend ein Pfeil zur Kind-Aktivität und von dieser zur nächsten gezeichnet. Allerdings fehlt dann ein Pfeil von der letzten Kind-Aktivität zum Rahmen. Dieser wird abschließend noch eingefügt. Im Beispiel am Ende dieses Abschnitts wird dieses Problem anhand einer Abbildung verdeutlicht. Jede Kind-Aktivität wird horizontal im Vergleich zum umliegenden Rahmen zentriert und die eigene Höhe wird zur Position für das nächste Kind aufaddiert. // Erzeuge SVG inklusive Box und Rahmen SVG svg = CREATE_SVG(); // Nur wenn Kind-Aktivitäten vorhanden sind, weiter Berechnung durchführen if (CHILDREN.size > 0) { // Nächste Position einer Kind-Aktivität Position nextchildpos = FIRST_CHILD_POSITION; // Startposition des nächsten Pfeils Position arrowsource = FIRST_ARROW_SOURCE; // Über Kind-Aktivitäten iterieren for each (child : CHILDREN) { // Berechnung der genauen Kind-Position child.position = CALCULATE_CHILD_POSITION(nextChildPos); // Füge Pfeil ein svg += CREATE_ARROW(arrowSource, child.arrowtarget); // Füge SVG-Code der Kind-Aktivität ein svg += child.svg; } // Positionen für nächstes Kind-Aktivität und nächsten Pfeil anpassen nextchildpos.y += child.height; arrowsource = child.arrowsource; } // Abschließender Pfeil svg += CREATE_ARROW(arrowSource, ARROW_TARGET); Listing 6 - Positionierung und SVG-Generierung bei ActivitySequenceElement ActivityChoiceElement Größenberechnung Die Berechnung der Größe eines ActivityChoiceElements erfolgt auf fast identische Weise wie bei einem ActivitySequenceElement. Da hier allerdings die Kind-Aktivitäten nebeneinander angeordnet werden sollen, wird die Breite summiert und die größte Höhe ermittelt. Wenn keine Kinder vorhan- 45

46 den sind, wird auch hier die Standardgröße verwendet und im anderen Fall der Platz für die Box der Aktivität hinzugefügt. Das nachfolgende Code-Listing zeigt den Algorithmus zu Berechnung der Größe. int width = 0; int height = 0; // Iteriere über Kind-Aktivitäten for each (child : CHILDREN) { // Breite der Kind-Aktivität aufaddieren width += child. width; } // Wenn die Höhe der Kind-Aktivität größer ist als die bisher berechnete, diese speichern if (child. height > height) height = child.height; // Für den Fall, dass keine Kind-Aktivitäten vorhanden sind, wird die Standardgröße verwendet if (CHILDREN.size == 0) { width = DEFAULT_WIDTH; height = DEFAULT_HEIGHT; } else height += DEFAULT_HEIGHT; return [width, height]; Positionierung und SVG-Generierung Listing 7 - Größenberechnung bei ActivityChoiceElement Im Positionierungsalgorithmus, der im nachfolgenden Code-Listing aufgeführt ist, werden lediglich die exakten Werte für die Position in X- und Y-Richtung berechnet, da die generelle Anordnung untereinander durch den Typ ActivityChoiceElement schon vorgegeben ist. Im Gegensatz zu einem ActivitySequenceElement muss in diesem Fall kein Zeiger für die Startposition des Pfeils mitgeführt werden. Hier werden für jede Kind-Aktivität zwei Pfeile gezeichnet. Der erste von der Box zu der Kind- Aktivität und der zweite von der Kind-Aktivität zum Rahmen. Für die Position des nächsten Kindes muss nur die Breite der aktuellen Kind-Aktivität aufaddiert werden. Natürlich werden auch bei diesem Typ der SVG-Code der Kind-Aktivitäten hinzugefügt. 46

47 // Erzeuge SVG inklusive Box und Rahmen SVG svg = CREATE_SVG(); // Nur wenn Kind-Aktivitäten vorhanden sind, weiter Berechnung durchführen if (CHILDREN.size > 0) { // Nächste Position einer Kind-Aktivität Position nextchildpos = FIRST_CHILD_POSITION; // Über Kind-Aktivitäten iterieren For each (child : CHILDREN) { // Berechnung der genauen Kind-Position child.position = CALCULATE_CHILD_POSITION(nextChildPos); // Füge Pfeil ein (von der Aktivität zur Kind-Aktivität) svg += CREATE_TOP_ARROW(child); // Füge SVG-Code der Kind-Aktivität ein svg += child.svg; // Füge Pfeil ein (von der Kind-Aktivität zur Aktivität) svg += CREATE_BOTTOM_ARROW(child); } } // Positionen für nächste Kind-Aktivität nextchildpos.x += child.width; Listing 8 - Positionierung und SVG-Generierung bei ActivityChoiceElement ActivityFlowElement Größenberechnung Da die Kind-Aktivitäten einer Flow-Aktivität frei angeordnet werden können, reicht hier eine einfache Anordnung neben- oder untereinander nicht aus. Sowohl für die Berechnung der Größe der Aktivität als auch für die Positionierung der Kind-Aktivitäten wird ein Gitter eingesetzt. Dieses basiert auf einem Layout-Algorithmus für BPMN-Prozessmodelle [25]. Auch in diesem Fall wird zunächst eine Abbildungsregel für die Aktivitäten des Prozessmodells definiert. Jede Aktivität des Gitters erhält einen Spalten- und Zeilenindex und somit auch eine feste Position. Zunächst kann mit einer Zeile und einer Spalte begonnen werden. Wenn die einzelnen Aktivitäten eingefügt werden, kann das Gitter nach und nach vergrößert werden. Bestehende Aktivitäten bleiben auf diese Weise beim Erzeugen neuer Spalten oder Zeilen relativ gesehen auf der gleichen Position. Um die Aktivitäten aber überhaupt in der korrekten Reihenfolge einfügen zu können, müssen sie sortiert werden. Dafür wird eine spezielle topologische Sortierung notwendig, wie sie auch in [25] verwendet wird. 47

48 In dem Konzept, welches als Grundlage dient, wird dieser Sortieralgorithmus als gesonderter Schritt durchgeführt. Im hier gezeigten Algorithmus wird diese Sortierung direkt beim Aufbau des Gitters beachtet. Dies ist auch aufgrund der Tatsache, dass ein lauffähiger BPEL-Prozess keine Zyklen haben darf, erleichtert. Das Konzept beschreibt einige Besonderheiten für die Positionierung der BPMN- Elemente (wie zum Beispiel Split oder Join). Diese werden in der Adaption des Ansatzes aber nicht betrachtet, da sie für BPEL keine Rolle spielen. Abbildung 21 zeigt ein beispielhaftes Gitter, bei dem die Zeile mit Index 0 deutlich höher ist als die Zeile darunter, in welcher nur eine Aktivität vorhanden ist. Die endgültige Darstellung auf der Oberfläche (inklusive der Links) wird im Folgenden erklärt und dargestellt. Abbildung 21 - Gitter (Beispiel) Listing 9 zeigt die Berechnung der Größe des ActivityFlowElements. Dafür wird die Größe des Gitters verwendet und im Falle, dass keine Kind-Aktivitäten vorhanden sind (das Gitter also leer ist), die Standardgröße verwendet. Im anderen Fall wird, wie auch bei der Berechnung der anderen Typen, zusätzlicher Platz für die Box hinzugefügt. // Wenn keine Kind-Aktivitäten vorhanden sind verwende Standardgröße if (CHILDREN.size == 0 ) return [DEFAULT_WIDTH, DEFAULT_HEIGHT]; // Übernehme Größe des Gitters int width = GRID.width; int height = GRID.height + DEFAULT_HEIGHT; return [width, height]; Listing 9 - Größenberechnung bei ActivityFlowElement (Teil 1) Nun ist natürlich interessant, wie das Gitter selbst seine Größe berechnet. Zunächst muss gesagt werden, dass die Zellen (also der Schnittpunkt einer Spalte und einer Zeile) nicht auf eine einheitliche Größe festgelegt sind, sondern unterschiedliche Breiten oder Höhen aufweisen können. Listing 10 zeigt die Größenberechnung des Gitters. Bei diesem wird über die Zeilen iteriert, der Wert der breitesten ermittelt und die Höhe aufaddiert. Die Breite einer Zeile wird durch das Aufsummieren der Zellenbreiten berechnet. Für die Zeilenhöhe wird die größte Höhe der Zellen dieser Zeile verwendet. 48

49 int width = 0; int height = 0; // Iteriere über Zeilen for (int i = 0; i < ROW_COUNT; i++) { // Wenn die Breite einer Zeile größer ist als die bisher berechnete, diese speichern int rowwidth = ROW_WIDTH(i); if (rowwidth > width) { width = rowwidth; } } // Höhe der Zeile aufaddieren height += ROW_HEIGHT(i); return [width, height]; Listing 10 - Größenberechnung bei ActivityFlowElement (Teil 2) Zwar ist nun klar, wie die Größe eines ActivityFlowElements berechnet wird, allerdings muss noch darauf eingegangen werden wie das verwendete Gitter erzeugt wird. Listing 11 zeigt den ersten Schritt beim Anordnen der Aktivitäten im Gitter. Für jede Kind-Aktivität des ActivityFlowElements, das dem Gitter zugeordnet ist, wird geprüft, ob es sich um eine Startaktivität handelt. Alle Startaktivitäten werden in die erste Zeile eingefügt und das Gitter für diese Aktivität wird weiter aufgebaut. Eine solche Aktivität darf entweder keine eingehenden Links haben oder es handelt sich bei den Eltern-Aktivitäten der Startpunkte aller eingehenden Links nicht um das ActivityFlowElement. //Iteriere über Kind-Aktivitäten des zugeordneten ActivityFlowElements for each (child : FLOW_ELEMENT.children) { // Ist das Kind-Aktivität eine Start-Aktivität if (IS_START_ELEMENT(child)) { // Zur ersten Zeile hinzufügen ADD_TO_FIRST_ROW(child); } } // Für diese Aktivität das Gitter weiter aufbauen. CREATE_GRID(child); Listing 11 - Größenberechnung bei ActivityFlowElement (Teil 3) Das in Abbildung 22 dargestellte Prozessmodell zeigt einen solchen Fall. Die Sequence-Aktivität wird in die erste Zeile eingeordnet, da es keine eingehenden Links hat. Dies trifft zwar nicht auf das Element Receive zu, allerdings greift hier der Fall, dass der Link von einer Aktivität (Wait) ausgeht, welches nicht die gleiche Vater-Aktivität (in diesem Fall Sequence) hat. Diese Sonderregelung ist notwendig, um trotz der Eigenheiten von BPEL bei der Kombination von Flow-Aktivitäten und anderen komplexen Aktivitäten eine ansprechend Darstellung zu erreichen. Links, die nicht von einer Kind-Aktivität 49

50 ausgehen und zu einer anderen Kind-Aktivität der Flow-Aktivität führen, werden beim Anordnen der Aktivitäten nicht beachtet. Damit wird dieser Vorgang ungemein erleichtert. Allerdings kann dies aber auch zu einigen Darstellungen führen, die noch verbessert werden können. Abbildung 22 - Startaktivitäten bei ActivityFlowElement Somit werden in der ersten Zeile alle Aktivitäten ohne Abhängigkeiten platziert. Anschließend werden die ausgehenden Links einer eingefügten Aktivität geprüft, gegebenenfalls deren Endpunkte hinzugefügt und dieser Vorgang rekursiv wiederholt (siehe Listing 12). Auf diese Weise wird das Gitter so weit wie möglich in die Tiefe aufgebaut, bevor es in der Breite vergrößert wird. Jeder ausgehende Link einer Aktivität wird zunächst verbraucht, das heißt sein Status wird geändert, damit die topologische Sortierung weiter gehen kann. Im nächsten Schritt wird geprüft, ob alle eingehenden Links der Zielaktivität bereits verwendet wurden. Falls dies der Fall ist, werden für diese Aktivität ebenfalls die ausgehenden Links geprüft und so weiter. Aber nur wenn es sich bei der Eltern-Aktivität der Zielaktivität auch um das zugehörige ActivityFlowElement handelt, wird dieses zum Gitter hinzugefügt. Diese Unterscheidung verhindert, dass geschachtelte Aktivitäten mehrfach eingefügt werden. 50

51 // Über die ausgehenden Links iterieren for each (link : ELEMENT.outgoingLinks) { Element target = link.target; // Benutze Link, damit die topologische Sortierung weiter gehen kann USE_LINK(link); // Alle eingehenden Links müssen benutzt worden sein if (ALL_SOURCE_LINKS_USED(target.incomingLinks)) { // Nur in Gitter aufnehmen, wenn das ActivityFlowElement das Eltern-Aktivität ist if (target.parent == FLOW_ELEMENT) ADD_TO_ROW(target); } } CREATE_GRID(target); Listing 12 - Größenberechnung bei ActivityFlowElement (Teil 4) Abbildung 23 zeigt die korrekte Anordnung der Aktivitäten. Nur die Sequence-Aktivität wird in das Gitter als Start-Aktivität aufgenommen. Die Invoke-Aktivität wird nicht abgelegt. Im Gegensatz dazu zeigt Abbildung 24 die Anordnung ohne diese Prüfung. In diesem Fall wird die Invoke-Aktivität doppelt dargestellt: einmal als Kind-Aktivität der Sequence-Aktivität und ein andermal als Teil des Gitters. Wenn allerdings an dieser Stelle die Rekursion einfach abgebrochen werden würde, könnte der gesamte Layout-Algorithmus möglicherweise nicht korrekt beendet werden, da gegebenenfalls einige Links nicht betrachtet würden. Abbildung 23 - Anordnung bei Schachtelung (korrekt) Abbildung 24 - Anordnung bei Schachtelung (falsch) Zum Einfügen einer Aktivität wird zunächst der höchste Zeilenindex der Start-Aktivitäten der eingehenden Links gesucht. Dieser Wert wird daraufhin um eins erhöht. Falls eine Zeile mit diesem Index noch nicht existiert wird eine neue Zeile eingefügt. Anschließend wird die Aktivität der ermittelten 51

52 Zeile hinzugefügt. Der spezielle Fall, dass eine Aktivität zwei eingehende Links besitzt, deren Start- Aktivitäten in unterschiedliche Zeilen eingeteilt sind, wird im nächsten Abschnitt gesondert behandelt. int rowindex = -1; // Über alle eingehenden Links iterieren und höchsten Wert bestimmen for each (link : ELEMENT.incomingLinks) { int currentrowindex = GET_ROW_INDEX(link.source); } if (currentrowindex > rowindex) rowindex = currentrowindex; // Index um eins erhöhen, damit die neue Aktivitäten immer unterhalb ist rowindex++; // Neue Zeile anlegen, wenn diese nicht vorhanden ist if (ROWS.size - 1 < rowindex) CREATE_NEW_ROW(); // Spezialfall: zwei eingehende Links mit unterschiedlichem Index TWO_INCOMING_LINKS(ELEMENT, rowindex); // Aktivität hinzufügen ADD_ELEMENT(ELEMENT, rowindex); Listing 13 - Größenberechnung bei ActivityFlowElement (Teil 5) Listing 14 zeigt den speziellen Algorithmus, der verwendet wird, um Elemente zu positionieren, die zwei eingehende Links mit Startpunkten aus unterschiedlichen Zeilen besitzen. Somit existieren eine obere (erste) und eine untere (zweite) Aktivität, welche die Ausgangspunkte der Links darstellen. Zunächst wird die maximale Anzahl an Spalten zwischen der Zeile der oberen Aktivität und der Zeile der einzufügenden Aktivität berechnet. Anschließend werden Platzhalter in die Zeile der oberen Aktivität eingefügt. Die Anzahl ergibt sich aus der maximalen Spaltenanzahl und der eigenen Spaltenanzahl. Alle Platzhalter werden vor der oberen Aktivität eingefügt. Somit rückt dieses weiter nach rechts. Im letzten Schritt werden für alle Zeilen zwischen der oberen Aktivität (exklusiv) und der Zeile der einfügenden Aktivität (inklusiv) Platzhalter rechts von der Aktivität ergänzt. Damit ist dieser Spezialfall abgeschlossen und die neue Aktivität wird regulär eingefügt (siehe Listing 13). Natürlich ließe sich dieses Verfahren auch auf Aktivitäten mit mehr als zwei eingehenden Links anwenden. Allerdings würde in diesen Fällen die Übersicht nicht verbessert. Hilfreicher wäre hier eine bessere Anordnung der Pfeile, sodass diese keine Boxen oder andere Pfeile überschneiden. Ein solches Konzept wird in dieser Diplomarbeit nicht näher beschrieben. Abbildung 25 zeigt die Anordnung einer Aktivität mit zwei eingehenden Links aus unterschiedlichen Zeilen. Die Platzhalter sind nur zur Verdeutlichung der Funktionsweise eingefügt. 52

53 // Index der ersten (oberen) und zweiten (untern) Zeile int rowindex1, rowindex2; // Berechne maximale Spaltenanzahl int maxcolumncount = CALCULATE_MAX_COLUMN_COUNT(rowIndex1, ROW_INDEX_NEW_ELEMENT); // Anzahl der Platzhalter für die erste Zeile int placeholderamount = maxcolumncount + 1 GET_COLUMN_COUNT(rowIndex1); // Wenn Platzhalter angelegt werden sollen, entsprechende Anzahl vor der letzten Aktivität // einfügen (Die letzte Aktivität ist der Ausgangspunkt des ersten Links) if (placeholderamount > 0) ADD_PLACE_HOLDERS_BEFORE_LAST_ELEMENT(rowIndex1, placeholderamount); // Platzhalter in jeder Zeile zwischen rowindex1 + 1 und ROW_INDEX_NEW_ELEMENT einfügen for (int i = rowindex1 + 1; i <= ROW_INDEX_NEW_ELEMENT; i++) { placeholderamount = maxcolumncount GET_COLUMN_COUNT(i); // Zusätzlicher Platzhalter für Zeile mit zweiter Aktivität if (i == rowindex2) placeholderamount++; } ADD_PLACE_HOLDERS_AFTER_LAST_ELEMENT(i, placeholderamount); Listing 14 - Größenberechnung bei ActivityFlowElement (Teil 6) Platzhalter Platzhalter Platzhalter Abbildung 25 - Anordnung mit zwei eingehenden Links 53

54 Positionierung und SVG-Generierung Nach der Erzeugung des Gitters, bereitet die exakte Positionierung der Kind-Aktivitäten und das Zusammenfügen der SVG Datei wesentlich weniger Aufwand. In Listing 15 wird dieser Algorithmus beschrieben. Das Grundprinzip sind zwei verschachtelte for-schleifen. In der äußeren wird über die Zeilen des Gitters iteriert; in der inneren über die Spalten einer Zeile. Auch hier wird wieder ein Zeiger verwendet, um der nächsten Kind-Aktivität die Position vorzugeben. Nach jeder Spalte wird dem Zeiger wie auch beim ActivityChoiceElement die Breite der aktuellen Aktivität hinzugefügt. Dadurch werden die Aktivitäten von links nach rechts positioniert. Allerdings muss der Zeiger nach jeder Zeile gesondert angepasst werden. Hierfür wird zunächst die horizontale Position auf den Standardwert (d.h. den Wert des ActivityFlowElements) gesetzt und anschließend der vertikale Wert um die Höhe der Zeile erweitert. // Erzeuge SVG inklusive Box und Rahmen SVG svg = CREATE_SVG(); // Nur wenn Kind-Aktivitäten vorhanden sind, weiter Berechnung durchführen if (CHILDREN.size > 0) { // Nächste Position einer Kind-Aktivität Position nextchildpos = FIRST_CHILD_POSITION; // Über Zeilen des Gitters iterieren for each (row : GRID.rows) { // Abstand berechnen, um Kind-Aktivität in dieser Zeile zu zentrieren CALCULATE_MARGIN(row); // Über Spalten der Zeile iterieren for each (data : row.columns) { // Berechnung der genauen Kind-Position child.position = CALCULATE_CHILD_POSITION(nextChildPos); // Füge SVG-Code der Kind-Aktivität ein svg += child.svg; } // Positionen für nächste Kind-Aktivität in dieser Zeile nextchildpos.x += child.width; } } // Positionen für nächste Kind-Aktivität in neuer Zeile // (x auf Standardwert setzen, auf y Höhe der Zeile addieren) nextchildpos.x = DEFAULT_POSITION.x; nextchildpos.y += row.height; Listing 15 - Positionierung und SVG-Generierung bei ActivityFlowElement 54

55 Die Höhe der Zeile ergibt sich aus der maximalen Höhe der zugehörigen Aktivitäten. Einen größeren Unterschied zu den beiden anderen komplexen Aktivitätstypen gibt es auch bei der Erstellung der Pfeile zwischen den Aktivitäten. Diese werden nicht während der SVG-Generierung hinzugefügt, sondern für alle ActivityFlowElemente gleichzeitig in der Wurzel (ActivityRootElement). Auf diese Weise wird sichergestellt, dass wirklich jeder Link angezeigt wird, da hier über die Gesamtmenge aller Links iteriert werden kann. Beispiel Schritt 1 - Modellierung Zunächst wird das Prozessmodell modelliert. Dies kann zum Bespiel mit dem Eclipse BPEL Editor [11] erfolgen. Zu sehen ist eine Flow-Aktivität (großer Kasten) mit zwei Zweigen. Das Prozessmodell erhält den Namen Beispiel. Wie der Deploy des Prozessmodells auf dem WfMS durchzuführen ist, wird an dieser Stelle nicht erläutert. Im nächsten Schritt ist davon auszugehen, dass dies geschehen ist und mindestens eine Prozessinstanz zu diesem Prozessmodell existiert. Schritt 2 - Parsen des BPEL-Dokuments Abbildung 26 - SVG-Generierung (Beispiel 1) Das BPEL-Dokument, welches von dem WfMS abgerufen wird, muss zunächst geparst werden. Daraus resultiert das rechts abgebildete Datenmodell. Die Namen der Aktivitäten sind fett gedruckt. In Klammern dahinter sind die jeweiligen Klassen- Namen angegeben. Die Sortierung der Aktivitäten innerhalb des Flows ergibt sich aus der Anordnung im BPEL-Dokument. Auf das spätere Layout haben dies keinen Einfluss. Listing 16 - SVG Generierung (Beispiel 2) Schritt 3 - Umwandlung in SVG-Datenmodell Root (ActivityRoot) Flow (ActivityFlow) Receive (ActivitySimple) Reply 2 (ActivitySimple) Sequence (ActivitySequence) Validate (ActivitySimple) Assign 1 (ActivitySimple) Reply 1 (ActivitySimple) Assign 2 (ActivitySimple) Die Umwandlung vom allgemeinen in das SVG- Root (ActivityRootElement) Datenmodell ist relativ trivial, da hier keine Aktivitäten ausgelassen werden (siehe nächstes Kapitel) Receive (ActivitySimpleElement) Flow (ActivityFlowElement) und das Gitter für die Anordnung der Aktivitäten Reply 2 (ActivitySimpleElement) Sequence (ActivitySequenceEle.) innerhalb des Flows erst im nächsten Schritt erzeugt wird. Assign 1 (ActivitySimpleEle.) Validate (ActivitySimpleEle.) Die Statusinformationen sind hier ebenfalls bereits Reply 1 (ActivitySimpleEle.) gegeben. Die Abfrage wurde zwischen dem Parsen Assign 2 (ActivitySimpleElement) des Dokuments und diesem Schritt durchgeführt. Listing 17 - SVG Generierung (Beispiel 3) 55

56 Schritt 4 - Berechnung der Größe Die Berechnung der Größe wir in mehreren Schritten durchgeführt. Zunächst werden die Größen der Aktivitäten mit der höchsten Verschachtelungstiefe berechnet. In diesem Beispiel hat jedes ActivitySimpleElement eine Breite von drei und eine Höhe von eins. Die Abstände zwischen den Aktivitäten werden hier nicht betrachtet. Hinter dem Namen der Aktivität wird vor dem Komma die Breite und nach dem Komma die Höhe angegeben. Teilschritt 1 Im ersten Teilschritt wird die Größe der Sequence- Aktivität berechnet. Diese hat insgesamt eine Breite von drei und eine Höhe von vier, da die maximale Breite der Kind-Aktivitäten verwendet und die Höhe der einzelnen Aktivitäten aufaddiert werden. Anschließend wird noch die eigene Höhe dazu addiert. Sequence (3,4) Validate (3,1) Assign 1 (3,1) Reply 1 (3,1) Listing 18 - SVG Generierung (Beispiel 4) Teilschritt 2 In diesem Berechnungsschritt muss das Gitter der Flow-Aktivität erzeugt werden. Als Start-Aktivität kann nur Receive verwendet werden. In die zweite Zeile kommen die Assign2 und Sequence. Die Aktivität Reply2 wird in der dritten Zeile abgelegt. Die Flow-Aktivität ist damit sechs Einheiten breit und sieben Einheiten hoch. Die Breite ergibt sich aus der breitesten Zeile (in diesem Fall die zweite). Die Höhe wird durch Aufaddieren der höchsten Aktivität einer jeden Zeile ermittelt. Abbildung 27 - SVG Generierung (Beispiel 5) Flow (6, 7) Receive (3,1) Reply 2 (3,1) Sequence (3,4) Validate (3,1) Assign 1 (3,1) Reply 1 (3,1) Assign 2 (3,1) Listing 19 - SVG Generierung (Beispiel 6) 56

57 Teilschritt 3 Beim letzten Schritt wird die Gesamtgröße der zu generierenden SVG-Grafik ermittelt. Dies gestaltet sich einfach, da die Root-Aktivität nur eine Kind- Aktivität hat und hier auch wieder nur die eigene Höhe dazu addiert wird. Root (6,8) Flow (6,7) Receive (3,1) Reply 2 (3,1) Sequence (3,4) Validate (3,1) Assign 1 (3,1) Reply 1 (3,1) Assign 2 (3,1) Listing 20 - SVG Generierung (Beispiel 7) Schritt 5 - Positionierung Nach der Berechnung der Größe müssen die Aktivitäten nur noch fest positioniert und die SVG- Grafik zusammengesetzt werden. Dieser Vorgang wird ebenfalls wieder in mehreren Teilschritten ausgeführt. Teilschritt 1 Auch hier wird wieder mit der Aktivität, welche die höchste Verschachtelungstiefe besitzt, begonnen. Alle Kind-Aktivitäten innerhalb der Sequence- Aktivität werden untereinander angeordnet und mit Pfeilen verbunden. Abbildung 28 - SVG-Generierung (Beispiel 8) Teilschritt 2 Die Kind-Aktivitäten des Flows werden in jeder Zeile horizontal zentriert. Dadurch sind die Receive-Aktivität aus der ersten und die Reply2-Aktivität aus der letzten Zeile mittig angeordnet. Die Links zwischen den Aktivitäten werden erst im letzten Teilschritt hinzugefügt. Abbildung 29 - SVG-Generierung (Beispiel 9) 57

58 Teilschritt 3 Der dritte und letzte Teilschritt betrifft die Wurzel- Aktivität. Es werden Start- und Endpunkt des Prozessmodells sowie die Links des Flows eingefügt. Damit ist die gesamte SVG-Grafik fertig gestellt und kann angezeigt werden Anwendung Process Views Abbildung 30 - SVG-Generierung (Beispiel 10) Der letzte Schritt, der bei der Generierung der SVG-Grafik durchgeführt wird, ist die Anwendung der Process Views. Obwohl er im tatsächlichen technischen Ablauf teilweise vor dem Layout stattfindet, wird er dennoch nach diesem erläutert, damit die hier benötigten Grundlagen bereits geklärt sind. Im Folgenden werden zwei Vorgehen dargestellt, um Process Views umzusetzen. Das erste ist simples Hervorheben einer Aktivität durch eine andere grafische Darstellung. Beim zweiten Vorgehen werden ganze Aktivitäten aus der Ansicht entfernt. In beiden Fällen ist es möglich dies anhand des Typs oder anhand des Namens einer Aktivität durchzuführen. Eine Kombination dieser Konzepte bieten die sogenannten Slider (Schieberegler). Diese ermöglichen es mit Hilfe von unterschiedlichen Abstraktionsstufen die Darstellung des Prozessmodells anzupassen. Hervorheben von Aktivitäten Das Hervorheben der Aktivitäten (beziehungsweise dessen grafische Repräsentation) erfolgt über eine andere Hintergrundfarbe der Box. In Abbildung 31 und Abbildung 32 werden die entsprechenden Kästen dargestellt. Welche Aktivität hervorgehoben wird, bestimmt der Benutzer über zwei Auswahlboxen auf der Oberfläche (siehe 5.3). Neben dieser Auswahl wird die Funktion auch indirekt von den Slidern (siehe übernächsten Abschnitt) aufgerufen. Abbildung 31 - Box einer hervorgehobenen Aktivität Abbildung 32 - Kompaktbox einer hervorgehobenen Aktivität Jedes ActivityElement ruft zum Prüfen, ob es hervorgehoben wird, eine Funktion aus den lokalen Einstellungen (siehe ) auf. Dort sind alle Namen oder Typen, die besonders gekennzeichnet werden sollen, bekannt. Die Aktivität wählt dann beim Generieren der SVG-Grafik, je nach Ergebnis 58

59 der Prüfung, ein anderes CSS-Element. Die Farbe, welche für das Hervorheben verwendet wird, kann somit leicht angepasst werden. Auslassen von Aktivitäten Welche Aktivitäten ausgelassen werden sollen, wird vor der Durchführung des Layout-Algorithmus bestimmt. Auch hier stehen zwei Auswahlboxen für den Benutzer zur Verfügung. Außerdem werden in Abhängigkeit von der Stufe der Slider ebenfalls Aktivitäten entfernt. Konkret wird die Funktion nach dem Übertragen des Datenmodells in das SVG-Datenmodell aufgerufen; also noch bevor die Berechnung der Größe oder die Positionierung durchführt wird. Auf diese Weise stehen für die Generierung nur noch die wirklich benötigten Daten zur Verfügung. Alternativ wäre auch eine Markierung denkbar, die angibt, ob eine Aktivität ausgelassen werden soll. Somit könnte auch an dieser Stelle in gewissen Umfang Caching betrieben werden. Wobei hier nur Messungen zeigen könnten, ob ein wesentlich komplexeres Datenmodell sowie die Caching-Funktionen wirklich Vorteile im Einsatz bringen würden. Wie schon beim Hervorheben, so wird auch beim Auslassen eine Funktion der lokalen Einstellung genutzt, um zu prüfen, ob eine Aktivität nicht dargestellt werden soll. Die Prüfung ist sehr simpel: Wenn der Typ oder Name einer Aktivität mit der Auswahl übereinstimmt muss sie entfernt werden. Listing 21 zeigt den Algorithmus, der für das Entfernen der Aktivitäten genutzt wird. Für jede Kind- Aktivität wird geprüft, ob sie selbst Kind-Aktivitäten besitzt, die Prüfung also rekursiv fortgesetzt werden soll. Anschließend wird geprüft, ob die Kind-Aktivität ausgelassen werden soll. Aktivitäten ohne Links können ohne Probleme entfernt werden, da sie entweder Teil eines Activity- SequenceElements oder ActivityChoiceElements sind. Bei diesen beiden Typen ist der Kontrollfluss bereits vorgegeben und es spielt keine Rolle, welche Kind-Aktivität entfernt wird. Nur wenn eine Aktivität ein- oder ausgehende Links besitzt, müssen diese umgesetzt werden. Dafür wird über diese Links in zwei Schleifen iteriert und für jede Kombination ein neuer Link erzeugt. Dieser erhält als Startpunkt den des eingehenden und als Endpunkt den des ausgehenden Links. Für m eingehende und n ausgehende (insgesamt m + n) werden demnach m x n neue Links erzeugt. Bei entweder wenigen ein- oder wenigen ausgehenden Links bleibt die Zahl neuer Links niedrig (teilweise sogar weniger als zuvor). Bei vielen Links führt dies zu einer sehr großen Anzahl. Als nächstes werden die bestehenden Links der zu entfernenden Aktivität gelöscht; zum Schluss die Aktivität selbst. 59

60 // Über Kind-Aktivitäten iterieren for each (child :CHILDREN) { // Wenn es sich bei der Kind-Aktivität um ein ActivityComplexElement handelt, rekursiv // fortsetzen if (HAS_CHILDREN(child)) OMIT_ELEMENTS(child); // Prüfen, ob die Aktivität entfernt werden soll if (OMIT(child)) { // Über die ein- und ausgehenden Links der Aktivität iterieren // Jedes Start- bzw. End-Punkt der Links wird neu verbunden for each (incominglink : child.incominglinks) { for each (outgoinglink : child.outgoinglinks) { CREATE_NEW_LINK(incomingLink.source, outgoinglink.target); } } // Links der zu entfernenden Aktivität löschen DELETE_LINKS(child.incomingLink, child.outgoinglink); } } // Kind-Aktivität entfernen REMOVE_CHILD (child); Listing 21 - Auslassen von Aktivitäten Abbildung 33 zeigt die Ausgangsdarstellung des Prozessmodells. In Abbildung 34 wurde die Assign- Aktivität entfernt. Receive hat nun direkte Links zu den Aktivitäten Validate und Reply 2. Abbildung 33 - Prozessmodell vor Entfernen von Assign Abbildung 34 - Prozessmodell nach Entfernen von Assign 60

61 Slider Das Aussehen und die Bedienweise der beiden Slider wurde bereits im Kapitel über die Oberfläche vorgestellt. Die Grundidee für diese Slider basiert auf [40]. Dort wird ein Konzept beschrieben, bei dem Aktivitäten eines Prozessmodells schrittweise entfernt werden, so dass nur noch eine Grundstruktur bestehen bleibt. Dieses Konzept wird teilweise mit dem ersten Slider umgesetzt, der das Prozessmodell nur mit Hilfe von definierten Regeln, die sich auf einen konkreten Aktivitätstyp beziehen, anpasst. Im Folgenden wird er als Prozessmodell-Slider bezeichnet. Der zweite Slider verwendet Monitoring-Daten, um die Darstellung des Prozessmodells anzupassen. Dieser wird auch als Prozessinstanz-Slider bezeichnet. Beide Slider lassen sich beliebig miteinander kombinieren. Das Entfernen einer Aktivität steht bei der Kombination der Slider immer an erster Stelle, auch wenn diese zum Beispiel hervorgehoben werden soll. In den nächsten Abschnitten wird genauer auf die beiden Slider eingegangen. Abschließend verdeutlicht ein Beispiel die Auswirkungen auf die Darstellung. Prozessmodell-Slider Dieser Slider umfasst mindestens sechs Stufen. Weitere Stufen werden dynamisch anhand der maximalen Verschachtelungstiefe des Prozessmodells ergänzt. Der Slider zu einem Prozessmodell ohne Aktivitäten hat demnach nur sechs Stufen, der zum Prozessmodell aus Abbildung 33 dagegen acht Stufen. Die nullte Stufe kennzeichnet den Ausgangszustand. Alle anderen Stufen bauen aufeinander auf. Das bedeutet, dass sie alle Eigenschaften der darunterliegenden Stufen übernehmen. Die Aktivitätstypen, welche entfernt werden sollen, können ohne Probleme angepasst werden, da die Prüfung über eine Funktion in den lokalen Einstellungen erfolgt. Eine Aktivität kann auch zusammengefasst werden. Darunter ist das Entfernen aller Kind-Aktivitäten zu verstehen. Es bleibt also nur noch ein Rumpf stehen. Für die Aktivitäten, die ab Stufe 6 oder höher entfernt werden sollen, muss Folgendes gelten: [Maximale Tiefe] - [Eigene Tiefe] < [Aktuelles Level] - 5 Stufe Beschreibung 0 Ausgangszustand: Aktivitäten in der Vollansicht anzeigen. 1 Aktivitäten in der Kompaktansicht anzeigen. 2 Assign-Aktivitäten entfernen Empty-Aktivitäten entfernen 3 Rethrow-Aktivitäten entfernen Throw-Aktivitäten entfernen Validate-Aktivitäten entfernen 4 CompenstationHandler-Aktivitäten zusammenfassen TerminationHandler-Aktivitäten zusammenfassen 5 Catch-Aktivitäten zusammenfassen CatchAll-Aktivitäten zusammenfassen OnAlarm-Aktivitäten zusammenfassen OnEvent-Aktivitäten zusammenfassen OnMessage-Aktivitäten zusammenfassen 6 und höher Aktivitäten mit entsprechender Verschachtelungstiefe entfernen. Tabelle 8 - Abstraktionsstufen des Prozessmodell-Sliders 61

62 Prozessinstanz-Slider Im Gegensatz zum Prozessmodell-Slider besitzt der Prozessinstanz-Slider genau 4 Stufen. Auch hier beschreibt die nullte Stufe wieder der Ausgangszustand. Alle anderen Stufen haben ebenfalls die Eigenschaften aller vorherigen. Tabelle 9 beschreibt kurz die Eigenschaften der Stufen. Anschließend werden diese genauer erläutert. Stufe Beschreibung 0 Ausgangszustand: Alle Aktivitäten anzeigen. 1 Ausgeführte Aktivitäten sowie die Pfeile zu diesen farblich hervorheben. 2 Dauer der Ausführung einer Aktivität farblich hervorheben. 3 Nicht ausgeführte Aktivitäten sowie die Pfeile von und zu diesen entfernen, wenn keine Möglichkeit mehr besteht, dass sie ausgeführt werden können. Tabelle 9 - Abstraktionsstufen des Prozessinstanz-Sliders Für die Stufe 1 wird der bereits erläuterte Hervorhebungsmechanismus verwendet. Allerdings werden noch weitere Prüfungen durchgeführt, wenn der Status einer Aktivität nicht bekannt ist, sich aber ableiten lässt. Dies kann durch fehlende Identifikationsbezeichner entstehen, die laut der BPEL Spezifikation [38] leider nicht verpflichtend sind. Somit enthalten auch die Ereignisse, die während der Ausführung einer Prozessinstanz erzeugt werden, keine eindeutige Bezeichnung und es ist nicht möglich einer Aktivität einen Status zuzuordnen. Die Funktion, die in Listing 22 gezeigt wird, wird ebenfalls verwendet, um die zugehörigen Links hervorzuheben. Die erste Prüfung ist am einfachsten und wird an anderen Stellen ebenfalls verwendet. Dort wird geprüft, ob der Status der Aktivität nicht OUTSTANDING (d.h. nicht bekannt oder ausstehend) und nicht SKIPPED (d.h. übersprungen) ist. Falls die Aktivität nicht in einem der beiden Status ist, ist die gesamte Überprüfung beendet und die Aktivität wird in Folge hervorgehoben. Alle weiteren Schritte funktionieren nach demselben Prinzip: Sobald der Test positiv verläuft wird dieser Wert zurückgegeben und die gesamte Überprüfung ist damit beendet. Im nächsten Test wird geprüft, ob die Aktivität nachfolgende Geschwister-Aktivitäten hat, welche hervorgehoben werden sollen. Dies gilt aber nur für Kind-Aktivitäten innerhalb einer ActivitySequence. Danach werden alle ausgehenden Links überprüft. Falls eine zugehörige Zielaktivität hervorgehoben wird, die nur einen eingehenden Link besitzt, wird auch die zu prüfende Aktivität herausgestellt. Die letzte Prüfung ist für die komplexen Aktivitäten vorgesehen. Wird eine Kind-Aktivität hervorgehoben, kann auch die Eltern-Aktivität herausgestellt werden. Wenn kein einziger dieser Tests ein positives Ergebnis liefert, wird die Aktivität in der Darstellung nicht hervorgehoben. 62

63 // Wenn der Status der Aktivität bekannt ist und nicht OUSTANDING oder SKIPPED ist // => hervorheben if (STATUS_HIGHLIGHTED(activity)) return true; // Wenn es sich um eine ActivitySequence handelt muss es mindestens ein nachfolgende Aktivität // geben, welches hervorgehoben wird if (IS_SEQUENCE_ACTIVITY(activity)) { // Eigener Index in der Liste der Geschwister- Aktivität en int index = INDEX_OF(activity.parent.children, activity) + 1; } // Mit eigenem Index starten und bis zum Ende der Liste iterieren while (index < siblings.size) { if (HIGHLIGHTED(activity.parent.children[index])) return true; index++; } // Ausgehende Links prüfen, Zielaktivität muss hervorgehoben werden und nur einen // eingehenden Link haben for each (outgoinglink : activity.outgoinglinkks) { if (HIGHLIGHTED(target) && outgoinglink.target.incominglinks.size == 1) return true; } // Prüfe Kind-Aktivitäten, wenn die Aktivität Kind-Aktivitäten hat if (IS_COMPLEX_ACTIVITY(activity)) { for each (child : activity.children){ if (HIGHLIGHTED(child)) return true; } } // Alle Prüfungen negativ return false; Listing 22 - Hervorheben von Aktivitäten und Links Stufe 2 nutzt ein ähnliches Konzept. Allerdings werden hier die aktuelle Gesamtdauer der Prozessinstanz und die Durchführungsdauer der Aktivitäten in Verhältnis gesetzt. Mit Hilfe dieses Wertes kann für jede Aktivität ein Farbwert zwischen hellem und dunklem Orange berechnet werden. Das Konzept hinter der letzten Stufe ist wieder relativ aufwändig, da hier geprüft werden muss, welche Aktivität nicht mehr ausgeführt werden kann. Zunächst wird untersucht, ob die Aktivität nicht hervorgehoben wird. Wenn dies nicht der Fall ist, kann weiter getestet werden. Als nächstes werden die eingehenden Links untersucht. Nur wenn alle Start-Aktivitäten der Links ausgeführt wurden und die Aktivität selbst nicht, kann weiter geprüft werden. Dieser Test wird auch rekursiv für die Kind-Aktivitäten durchgeführt, wenn es sich um eine komplexe Aktivität handelt. Der letzte Testschritt unterscheidet sich in Bezug auf den jeweiligen Typ der Eltern-Aktivität. Bei einer 63

64 ActivityChoice wird geprüft, ob mindestens eine andere Geschwister-Aktivität hervorgehoben wird. Falls dies der Fall ist, kann die Aktivität entfernt werden. Handelt es sich bei der Eltern-Aktivität um eine ActivitySequence wird für diese geprüft, ob sie ausgelassen werden kann. Wenn dies so ist, kann die Aktivität selbst auch entfernt werden. Beim dritten Typ, der ActivityFlow, wird geprüft, ob sie bereits ausgeführt wurde. Wenn dem so ist, kann die Aktivität selbst nicht mehr ausgeführt werden und kann somit aus der Darstellung entfernt werden. // Nur wenn die Aktivität nicht hervorgehoben wird und alle eingehenden Links nicht vollständig // ausgeführt werden, darf weiter geprüft werden if (!HIGHLIGHTED(activity) && CHECK_INCOMING_LINKS(activity)) { // ActivityChoice ist Eltern-Aktivität: Mindestens eine Geschwister-Aktivität muss // hervorgehoben weden if (IS_ACTIVITY_CHOICE(activity.parent)) { boolean siblinghighlighted = false; for each (child : activity.parent.children) { siblinghighlighted = siblinghighlighted HIGHLIGHTED(child); } } return siblinghighlighted; // ActivitySequence ist Eltern-Aktivität: Eltern-Aktivität prüfen if (IS_ACTIVITY_SEQUENCE(activity.parent)) return IS_OMITTED(activity.parent); } // ActivityFlow ist Eltern-Aktivität: Eltern-Aktivität muss vollständig ausgeführt worden // sein if (IS_ACTIVITY_FLOW(activity.parent)) return IS_FINISHED(activity.parent); return false; Beispiel Listing 23 - Entfernen von nicht ausgeführten Aktivitäten Das folgende Beispiel zeigt die Darstellung eines Prozessmodells mit unterschiedlichen Slider-Stufen. Dieses wird aus Gründen der Übersichtlichkeit auch im Ausgangszustand in der kompakten Form (Prozessmodell-Slider auf Stufe 1) dargestellt. Die Unterscheide zwischen der normalen und der kompakten Form sind in Kapitel dargestellt. 64

65 Schritt 1 Prozessmodell-Slider: Stufe 1 Prozessinstanz-Slider: Stufe 0 Abbildung 35 zeigt das Prozessmodell im Ausgangszustand. Nur der rechte Zweig in der Flow-Aktivität wurde ausgeführt. Für die Sequence-Aktivität und ihre Kind- Aktivitäten liegen keine Statusinformationen vor. Abbildung 35 - Process Views (Beispiel 1) Schritt 2 Prozessmodell-Slider: Stufe 1 Prozessinstanz-Slider: Stufe 1 Die Struktur des Prozessmodells ist in Abbildung 36 gleich geblieben. Mit Orange werden die Boxen der Aktivitäten hinterlegt, die bereits ausgeführt wurden. Abbildung 36 - Process Views (Beispiel 2) Schritt 3 Prozessmodell-Slider: Stufe 3 Prozessinstanz-Slider: Stufe 1 Auch in Schritt 3 werden die ausgeführten Aktivitäten hervorgehoben. Allerdings fehlen die Validate- und Assign-Aktivitäten. Die Links zu und von Assign2 werden durch einen neuen Link von Receive zu Reply2 ersetzt. Abbildung 37 - Process Views (Beispiel 3) 65

66 Schritt 4 Prozessmodell-Slider: Stufe 3 Prozessinstanz-Slider: Stufe 2 Die Struktur des Prozessmodells ist identisch mit der aus Schritt 4. Allerdings sind hier Farbabstufungen für die ausgeführten Aktivitäten vorhanden. Sie zeigen an, dass die Receive-Aktivität in kürzerer Zeit beendet wurde als die Aktivität Reply2. Diese benötigte wiederum weniger Zeit für die Ausführung als die Flow-Aktivität. Abbildung 38 - Process Views (Beispiel 4) Schritt 5 Prozessmodell-Slider: Stufe 6 Prozessinstanz-Slider: Stufe 2 Durch die Verkleinerung der Verschachtelungstiefe (ab Prozessmodell-Slider Stufe 6) werden die Kind- Aktivitäten der Sequence-Aktivität entfernt. Abbildung 39 - Process Views (Beispiel 5) Schritt 6 Prozessmodell-Slider: Stufe 6 Prozessinstanz-Slider: Stufe 3 In Abbildung 40 werden nur noch die bereits ausgeführten Aktivitäten angezeigt. Gäbe es noch Aktivitäten, die ausführbar wären, würden diese auch angezeigt. Abbildung 40 - Process Views (Beispiel 6) 5.5 BPI Service Adapter ODE Der BPI Service Adapter wird von der BPI Service Komponente aufgerufen und kapselt die dahinter liegende Logik zum Zugriff auf die Daten des WfMS ab. Auf diese Weise kann der BPI Service die Methoden der einheitlich definierten Schnittstelle aufrufen und erhält alle Informationen bereits im einheitlichen Datenformat (siehe 5.2). Die dahinter liegende Implementierung kann jederzeit getauscht werden. So ist es problemlos möglich einen Adapter für ein anderes WfMS oder aber einen Ersatz für den BPI Service Adapter der Apache ODE zu integrieren. Durch dynamisches Laden der Klassen kann dies sogar während Laufzeit durchgeführt werden. Hierfür muss nur das Java Archive (JAR) des entsprechenden Adapters in das passende Verzeichnis kopiert und die Konfiguration angepasst werden. Abbildung 41 zeigt die durch den Adapter zu implementierenden Methoden. Die Schnittstelle teilt sich auf drei Java Interfaces auf: ProcessModelService: Abruf aller Prozessmodelle oder eines einzelnen Prozessmodells. ProcessInstanceService: Abruf aller Prozessinstanzen eines bzw. mehrerer Prozessmodelle. EventService: Abruf aller Ereignisse zu einer Prozessinstanz. 66

67 Wie schon bei der BPI Service Schnittstelle (siehe 5.4) wird auch hier die ServiceFactory verwendet (siehe 5.4), um Instanzen der entsprechenden Services zu erzeugen. Abbildung 41 - Klassendiagramm der BPI Service Adapter Schnittstelle Der Adapter kann beispielsweise direkt auf die Datenbank des WfMS zugreifen, eine vorhandene Management API aus der Geschäftslogik nutzen oder aber sogar Daten aus der grafischen Oberfläche einer Verwaltungskonsole extrahieren. Die Apache ODE erlaubt sogar das Einbinden von so genannten Event-Listenern. Diese werden direkt aufgerufen und erhalten als Parameter das entsprechende Ereignis, welches ab dieser Stelle beliebig weiter verarbeitet werden kann (vgl. Observer Entwurfsmuster [16]). Allerdings muss dafür in die Konfiguration des WfMS eingegriffen werden. Vorzuziehen ist in diesem Fall die Abfrage der Daten über die Management API. Diese wird im nächsten Abschnitt (5.6) genauer beschrieben. In jedem Fall ist es die Aufgabe des Adapters die abgerufenen Daten in das Datenmodell der Anwendung zu konvertieren. Die Abbildung der Status eines Prozessmodells, einer Prozessinstanz oder einer Aktivität ist in diesem Zusammenhang die komplexeste Aufgabe. Die Statusmodelle für diesen Prototypen orientieren sich sehr stark an dem der Apache ODE. Dadurch wird die Abbildung in diesem Fall gut beherrschbar. Wenn ein weiterer Adapter erstellt werden soll, kann sich dies als komplexer erweisen. 5.6 Apache ODE In dieser Diplomarbeit wird für die prototypische Implementierung die Apache ODE verwendet. Natürlich kann ein entsprechender Adapter vorausgesetzt auch jedes anderes WfMS eingesetzt werden. Die Vorzüge der Apache ODE wurden bereits im Kapitel über die Technologien behandelt. An dieser Stelle soll auf die Management API und die Persistierung der Ereignisse in der zugehörigen Datenbank eingegangen werden. Das Listener-Konzept, das ODE ebenfalls anbietet, wird hier nicht weiter behandelt, da der direkte Eingriff in die Anwendung nicht wünschenswert ist und dem Konzept des BPI Service Adapters widerspricht. 67

68 5.6.1 Management API Die Spezifikation der Management API wird in [5] erläutert. Allerdings werden an dieser Stelle nicht alle Operation vorgestellt. Es wird jedoch s das System hinter den Abfragen dargestellt. Ein Blick in die JavaDoc Spezifikation liefert weitere Details. Im Wesentlichen besteht die Management API aus zwei Webservices: Dem ProcessManagement, der für das Abfragen oder Manipulieren der Prozessmodelle verwendet wird, und dem InstanceManagement, der zum Abrufen und Administrieren der Prozessinstanzen genutzt wird. Bei den abgerufenen Daten handelt es sich um XML. Allerdings bietet Apache ODE bereits einen Webservice Client, sodass kein Stub generiert werden muss. Dieser liefert die Daten in einer Axiom 13 -Struktur, die aber ebenfalls geparst werden muss. Alternativ können diese Daten auch in Objekte überführt werden. Dafür existiert bereits ein entsprechender Parser. Dieses Datenmodell müsste dann aber ebenfalls in das der Anwendung umgewandelt werden. Unteranderem können folgende Operationen mit den entsprechenden Parametern ausgeführt werden: ProcessManagement Aktivieren/deaktivieren eines/mehrerer Prozessmodells (Prozessmodell ID bzw. Paketname) Abruf aller Prozessmodelle Abruf einer Liste von Prozessmodellen ( Filter und Sortierung) Abruf von detaillierten Informationen zu einem Prozessmodell ( Prozessmodell ID) Abruf einer Liste von Aktivitäten von einem Prozessmodell (Prozessmodell ID) InstanceManagement Löschen einer oder mehrerer Prozessinstanzen (Filter) Ändern des Zustands einer Prozessinstanz (Prozessinstanz ID) Abruf einer Liste von Prozessinstanzen (Filter und Sortierung) Abruf von detaillierten Informationen zu einer Prozessinstanz (Prozessinstanz ID) Abruf der Ereignissen zu einer/mehrerer Prozessinstanzen (Filter und Sortierung) Abruf von detaillierten Informationen zu einer Scope eines Prozessinstanz (Scope ID) Neben den Methoden zum Abruf der Informationen über Prozessmodell und Prozessinstanzen stehen auch weitere bereit, mit deren Hilfe eine vollständige Administrationskonsole erstellt werden könnte Beispiel Dieses Beispiel zeigt den Abruf aller Prozessmodelle mit Hilfe des bereitgestellten Webservice Clients. In der zweiten Code-Zeile wird die Anfrage-Nachricht erzeugt. Der erste Parameter gibt den Namen der Operation an, der zweite liefert die Namen der Parameter und im dritten stehen die zugehörigen Werte. In diesem Fall werden aber keine benötigt. Sowohl die Anfrage als auch das Ergebnis sind Axiom-OMElemente, das heißt sie repräsentieren ein XML-Infoset-Element

69 ServiceClientUtil client = new ServiceClientUtil(); OMElement root = client.buildmessage("listallprocesses", new String[] {}, new String[] {}); OMElement result = client.send(msg, " Listing 24 - Apache ODE Management API (Beispiel 1) Die Axiom-Elemente können entweder wie DOM-Elemente geparst und in das eigene Datenmodell übertragen werden oder aber mit Parser von Apache ODE in ein entsprechendes Document, welches die Daten enthält, umgewandelt werden. Von diesem ausgehend könnten sehr einfach Objekte des eigenen Datenmodells erzeugt werden. Allerdings funktionierte dies während einiger Tests nicht, sodass die Axiom-Elemente selbständig geparst werden müssen. ScopeInfoDocument scopeindodoc = ScopeInfoDocument.Factory.parse(result.getXMLStreamReader()); Persistierung der Ereignisse Listing 25 - Apache ODE Management API (Beispiel 2) Die Ereignisse, die während des Betriebs der WfMS entstehen, werden von Apache ODE in einer Datenbank gespeichert. Außerdem sind in dieser noch die Prozessmodelle, Prozessinstanzen und Daten, die während des Betriebs persistent gespeichert werden müssen, zu finden. Somit ist ein direkter Zugriff auf diese Ereignisse möglich; vorausgesetzt die Datenbank ist von außen erreichbar. In der Standardkonfiguration speichert ODE die Daten in einer Derby 14 Datenbank, auf die aber nur von der Anwendung selbst zugegriffen werden kann. Allerdings lässt sich mit Hilfe einer Properties-Datei die Konfiguration ändern und so eine externe Datenbank wie beispielsweise MySQL einbinden. Der direkte Zugriff des Adapters auf die Datenbank ist notwendig, da die Webservice Operation zum Abruf der Ereignisse einer Prozessinstanz nicht implementiert ist. Alternativ kann der Zugriff auf diese Informationen über die Scopes eines Prozessmodells erfolgen. Dies ist jedoch mit erheblichem Aufwand verbunden. Der direkte Abruf der Daten aus der Datenbank ist vergleichsweise gut umsetzbar, hat aber etwas mehr Konfigurationsaufwand zur Folge. Im laufenden Betrieb ist allerdings nicht zu erwarten, dass die Derby Datenbank verwendet wird, da sie nur begrenzte Leistungsfähigkeit besitzt. Wenn diese Operation implementiert werden sollte, kann der Adapter entsprechend angepasst werden und nutzt dann ausschließlich die Management Webservices

70 6 Implementierung Die Konzepte, auf die sich die Implementierung stützt, wurden im vorangegangenen Kapitel beschrieben. Aus diesem Grund orientiert sich auch dieser Abschnitt an den, in der Architektur beschriebenen, Komponenten. Allerdings werden nur die Komponenten betrachtet, die auf dem Webserver betrieben werden. Alle anderen sind nicht Teil der Implementierung. Außerdem werden die Projektstruktur beleuchtet sowie einige Hilfsanwendungen vorgestellt (zum Beispiel für das Testen). Dieses Kapitel soll nicht auf jedes Implementierungsdetail eingehen, sondern die im Zusammenhang mit dieser Arbeit interessanten Aspekte hervorheben. 6.1 BPI Model Das bereits vorgestellte Datenmodell beinhaltet mehr oder minder alles, was diese Komponente ausmacht. Es werden Getter und Setter für die Attribute erzeugt und einige weitere Standard- Methoden (wie tostring oder equals), wie sie für Java Beans benötigt werden. Das Java-Interface Status, welches von allen Statusaufzählungen implementiert wird, wurde im entsprechenden Kapitel in den Konzepten nicht vorgestellt, da es lediglich die Implementierung erleichtert. Dieses Interface definiert einige Methoden, mit denen der Name eines Status mit unterschiedlicher Schreibweise ausgegeben wird. Außerdem können mit Hilfe dieses Interfaces die Statusfilter generisch gehalten werden. Gleiches gilt auch für das ProcessItem, welches von ProcessModel und ProcessInstance implementiert wird. Dieses Interface gibt nur vor, dass beide Klassen einen Status besitzen und dass dieser abgefragt werden kann. Dies erleichtert die Erstellung der Statusfilter und ermöglich ein gemeinsames Datenmodell für die Darstellung auf der Oberfläche (siehe 6.2). Der letzte interessante Aspekt in der Model Komponente ist die Klasse BPIException. Sie wird verwendet um alle spezifischen Fehlermeldungen zu kapseln, sodass eine einheitliche Schnittstelle entsteht. 6.2 BPI Frontend Die BPI Frontend Komponente enthält wesentlich mehr interessante Implementierungsdetails als das BPI Model. Im Folgenden sollen vier Aspekte genauer aufgezeigt werden. Dazu gehört der Einsatz von JavaScript für das automatische Neuladen der SVG-Grafik und für die Umsetzung der Slider. Ebenfalls die bereits erwähnten JSF Komponenten sollen an dieser Stelle genauer dargestellt werden. Außerdem wird auf die Realisierung der Einzelseiten mit der Darstellung des Prozessmodells als SVG-Grafik eingegangen. Zuletzt wird erläutert, wie die Ablagestruktur der Grafiken (zum Beispiel die Status- Icons) aufgebaut ist und wie diese ausgetauscht werden können JavaScript Einsatz Automatisches Neuladen der SVG-Grafik Damit die SVG-Grafik immer die neusten Statusinformationen zu dem dargestellten Prozessmodell anzeigt, muss vom Client aus eine neue Anfrage gestellt werden. Dies ist notwendig, da für das Abrufen der Ereignisse von der WfMS ein Polling-Mechanismus verwendet wird. Entweder kann der Benutzer den Abruf anstoßen oder der Abruf erfolgt automatisch durch eine entsprechende JavaScript Funktion. Die in Listing 26 vorgestellten Variablen speichern zum Einen das Neuladeintervall, welches mit einer Minute initialisiert wird und vom Benutzer umgestellt werden kann, zum Anderen den Zeit- 70

71 punkt des nächsten Aufrufs. Die Funktion checkreloadinterval wird beim Laden der Seite zum ersten Mal ausgeführt und ruft sich jede Sekunde neu auf, um zu prüfen, ob die SVG-Grafik neugeladen werden soll. Dies ist dann der Fall, wenn der aktuelle Zeitpunkt nach dem der nächsten Ausführung liegt oder mit diesem identisch ist. Beim Neuladen wird zunächst der nächste Zeitpunkt bestimmt und anschließend die aktuelle Position auf der Seite gespeichert. Im nächsten Schritt wird die AJAX Anfrage an den Server gestellt. Als Parameter werden die IDs der Elemente übergeben, welche die auf dem Server benötigten Daten enthalten. Diese werden im Anschluss mit aktualisierten Daten neugeneriert. Außerdem wird der Name einer sogenannten Callback-Funktion mitgegeben. Diese wird nach dem Ausführen der Anfrage und dem Erhalt der Antwort ausgeführt. Da der Kontrollfluss nach dem Absenden der asynchronen Anfrage weiter geht, kann diese Funktion nicht einfach in der nächsten Zeile stehen. Es wäre nicht sichergestellt, dass sie zum korrekten Zeitpunkt ausgeführt wird; vermutlich würde sie zu früh ausgeführt werden. Die asynchrone Kommunikation hat aber auch erhebliche Vorteile (siehe [19]). Allerdings muss selbst innerhalb der Callback-Funktion noch eine kurze Verzögerung eingebaut werden, da ansonsten der DOM-Baum noch nicht erneuert ist. Die gespeicherte Position könnte somit an eine Stelle zeigen, die zu diesem Zeitpunkt noch gar nicht vorhanden ist oder nicht der beabsichtigten Position entspricht. Aufgrund der Unterschiede zwischen den Webbrowsern muss das Auslesen der aktuellen Stelle auf der Webseite entsprechend auf verschiedene Arten erfolgen (siehe [2]). Das Wiederherstellen der gespeicherten Position funktioniert bei allen wiederum identisch. var reloadinterval = 60 * 1000; var reloadtimestamp = CURRENT_TIME + reloadinterval; // Jede Sekunde prüfen, ob Neuladen durchgeführt werden muss function checkreloadinterval() { if (CURRENT_TIME >= reloadtimestamp) doreload(); } settimeout("checkreloadinterval()", 1000); // Ausführen des Neuladen function doreload() { reloadtimestamp = CURRENT_TIME + reloadinterval; var element = document.getelementbyid(element_id); // Aktuelle Position auf der Seite speichern savescrollposition(); } // AJAX Anfrage jsf.ajax.request(element, null, {execute : EXECUTE_ID, render : RENDER_ID, onevent : restorescrollposition }); Listing 26 - Automatisches Neuladen der SVG-Grafik 71

72 Slider Da Schieberegler erst in HTML 5 [53] native unterstützt werden, wird hier auf eine vorgefertigte Implementierung zurückgegriffen [14]. Diese setzt auf einem einfachen Eingabefeld auf und verändert dessen Darstellung und Verhaltensweise durch JavaScript. Der Vorteil dieser Umsetzung ist, dass er sich in die JSF Komponenten integrieren lässt und eine einfache Konfiguration ermöglicht. Die Implementierung besteht aus einer JavaScript-Datei, einem CSS und einigen Grafiken. Listing 27 zeigt den Code, der benötigt wird, um den Slider einzubinden. Dieses Eingabefeld wird innerhalb einer JSF Komponente verwendet, sodass dieser Code nur einmal geschrieben werden muss. Als Parameter wird eine entsprechende Java-Klasse übergeben, die sowohl den aktuellen (cc.attrs.slider.selection) als auch den maximalen Wert (cc.attrs.slider.maxrange) beinhaltet. Der Name und die ID werden zum Einen innerhalb der Slider Implementierung verwendet, zum Anderen innerhalb der Callback- Funktion. Diese Funktion wird als Parameter (fd_callback_<name der Funktion>) zusammen mit Auswahlbereich (fd_range_<von>_<bis>) über das StyleClass-Attribut übergeben. Dieses Attribut wird nur zum Konfigurieren des Sliders verwendet. Wenn das Aussehen angepasst werden soll, muss das mitgelieferte CSS ebenfalls angepasst werden. Der Parameter fd_hide_input gibt an, dass der aktuelle Wert nicht in einem separatem Feld angezeigt werden soll. <h:inputtext name="slider" id="slider" value="#{cc.attrs.slider.selection}" styleclass="fd_range_0_#{cc.attrs.slider.maxrange} fd_hide_input fd_callback_updateslider" /> Listing 27 - Einbinden des Sliders in JSF Um den Slider verwenden zu können, müssen somit die JavaScript-Datei und das CSS eingebunden werden. Dies kann beispielsweise über den bereits vorgestellten Mechanismus erfolgen, der mit JSF 2.0 eingeführt wurde. Die Callback-Funktion ist für beide Slider identisch und ruft, sobald der Wert einer der beiden sich verändert, die im vorherigen Abschnitt vorgestellte Funktion doreload auf. Da die ID des Vater-Elements angegeben wird, werden auch die Werte der beiden Slider an die Server übermittelt. Dort wird auf Basis dieser Werte die SVG-Grafik neu generiert und kann anschließend abgerufen werden. Als zusätzliches Problem kommt hinzu, dass Eingabefelder nur beim Laden der Seite umgestaltet werden. Durch den AJAX-Einsatz kann es aber passieren, dass diese Felder zu diesem Zeitpunkt gar nicht existieren, sondern erst nachträglich eingefügt werden. Aus diesem Grund wird die Umwandlung zu den angezeigten Slidern extra aufgerufen. Abbildung 42 zeigt das Eingabefeld, dass durch JavaScript in die endgültige Darstellungsform (Abbildung 43) gebracht wird. Abbildung 42 - Slider vor zusätzlichen Rendering Abbildung 43 - Slider nach zusätzlichen Rendering 72

73 6.2.2 JSF Komponenten Abbildung 44 zeigt die eingesetzten JSF Managed Beans. Die Lebensdauer der MainBean ist an die der Sitzung gebunden; es handelt sich um eine sogenannte Sessionbean. Sie wird für das Anzeigen der Hauptseite verwendet und enthält die Datenhalter, die für die beiden Tabellen mit den Prozessmodelle und Prozessinstanzen sowie für den Graphen benötigt werden. Außerdem existieren noch eine Liste mit SVGDataModels, die mit Hilfe einer ID aufgefunden werden können, und eine Methode, um die gespeicherten Prozessmodelle und Prozessinstanzen neuzuladen und die zugehörigen Datenhalter zu aktualisieren. Die SVGBean wird zum Anzeigen eines einzelnen Graphen und der zugehörigen Einstellungsmöglichkeiten verwendet. Bei dieser Bean handelt es sich um eine sogenannte Requestbean, die an die Lebensdauer eines Seitenaufrufs gebunden ist. Damit nicht nach jedem Aufruf die gemachten Einstellungen verloren gehen, wird eine ID generiert. Diese wird zusammen mit dem SVGDataModel in der entsprechenden Liste in der MainBean abgespeichert. Die ID muss bei jedem Aufruf mitgeliefert werden. Auf diese Weise können beliebig viele Fenster mit den Graphen und deren Einstellungsmöglichkeiten geöffnet werden, die sich untereinander nicht beeinflussen. Abbildung 44 - Klassendiagramm der Managed Beans Abbildung 45 zeigt die bereits vorgestellten Datenhalter, deren Vater-Klasse das AbstractDataModel ist. Diese enthält eine Referenz zum untergeordneten Datenhalter. In der MainBean werden diese so initialisiert, dass dem ProcessModelDataModel das ProcessInstanceDataModel und dem ProcessInstanceDataModel das SVGDataModel zugeordnet ist. Diese Hierarchie erlaubt es, dass bei Änderungen in der Auswahl der Prozessmodelle oder Prozessinstanzen die zugehörigen Platzhalter entsprechend aktualisiert werden. Dies geschieht über die Methode update, bei der die relevanten Daten als Parameter übergeben werden. Außerdem enthält diese Basisklasse noch die Information, ob der Datenhalter maximiert oder minimiert ist. 73

74 Abbildung 45 Klassendiagramm der Datenhalter Die Kind-Klasse SVGDataModel enthält die ausgewählte Prozessinstanz und die generierte SVG- Grafik. Zum Anpassen des Graphen gibt es entsprechende Komponenten. Dazu gehören die vier Kästen zum Hervorheben beziehungsweise Auslassen von Aktivitäten sowie die beiden Slider (siehe Abbildung 46). Der ProcessModelSlider und der ProcessInstanceSlider haben die Vater-Klasse Slider. Diese erbt, wie auch ActivityAdjuster, von der Vater-Klasse SVGAdjuster. Durch diese Vererbungshierarchie kann der Java-Code deutlich reduziert werden. Bei Änderungen innerhalb der Komponenten können diese die generierte SVG-Grafik mit Hilfe der Methode updatesvg anpassen. Abbildung 46 - Einstellungsmöglichkeiten des Graphen In Listing 28 sind alle JSF Komponenten des Graphen und der Einstellungsmöglichkeiten aufgeführt. Die Einrückung soll die Verschachtelung verdeutlichen. So enthält TableHeader die Komponenten Summary, ReloadInterval, Refresh und ViewMode. In Klammern hinter den Namen sind die gegebenenfalls existierenden Java-Klassen aufgeführt, die zu dieser gehören. Wenn keine Klassen angeben 74

75 sind, enthalten die JSF Komponenten entweder nur Text (z.b. Summary) oder die Funktionalität wird durch JavaScript realisiert (z.b. ReloadInterval). SVGTable (SVGDataModel) TableHeader Summary ReloadInterval Refresh ViewMode (ViewMode) ActivityAdjuster (ActivityAdjuster) ActivityAdjuster (ActivityAdjuster) ActivityAdjuster (ActivityAdjuster) ActivityAdjuster (ActivityAdjuster) Slider (ProcessModelSlider) Slider (ProcessInstanceSlider) Listing 28 - JSF Komponenten des Graphen Die zweite Kind-Klasse von AbstractDataModel ist das SelectionDataModel, von der es wiederum zwei Ausprägungen für die Darstellung von Prozessmodellen (ProcessModelDataModel) und Prozessinstanzen (ProcessInstanceDataModel) gibt. Sie enthält die anzuzeigenden Elemente und Komponenten zum Sortieren, Wechseln der Seiten und Filtern (siehe Abbildung 47). Die Auswahl kann über die Methode getselection abgerufen und durch select verändert werden. Diese werden von den beiden Kind-Klassen entsprechend implementiert. TextFilter und StatusFilter erben von der Klasse Filter. Diese hat zusammen mit Sorter und Pager die Vater-Klasse Adjuster. Diese Vererbungshierarchie erlaubt auch in diesem Fall eine erhebliche Codeersparnis. Abbildung 47 - Prozessinstanz-Tabelle Listing 29 enthält die JSF Komponenten der Prozessinstanz-Tabelle. Die Zusammensetzung der Prozessmodell-Tabelle erfolgt analog. Für jede Spalte existiert ein eigener Spaltenkopf (ColumnHeader). Dieser kann einen TextFilter, StatusFilter oder auch gar keinen Filter enthalten. Bei der rechten Spalte (siehe Abbildung 47) entfällt das Kopf-Element komplett. 75