EAI Prozessmodellierung. Diplomarbeit

Transkript

1 EAI Prozessmodellierung Analyse der Unterschiede zwischen den sprachlichen Konzepten XML Process Definition Language und Business Process Modelling Language mit Erstellung eines Konverters zwischen beiden Konzepten Eingereicht von: Florian Schweiger Diplomarbeit zur Erlangung des akademischen Grades Magister rerum socialium oeconomicarumque Magister der Sozial- und Wirtschaftswissenschaften (Mag. rer. soc. oec.) Fakultät für Wirtschaftswissenschaften und Informatik, Universität Wien Fakultät für Technische Naturwissenschaften und Informatik, Technische Universität Wien Studienrichtung: Wirtschaftsinformatik (E175) Begutachter: a.o. Univ. Prof. Dr. Ing. Jürgen Dorn Wien, im April 2004

2 1 INHALT 1 INHALT Einleitung Konzeptvergleich zwischen XPDL und BPML Detaillierter Vergleich Kontext Aktivitäten Verbindung von Aktivitäten Prozessinstanzierungsarten Variablen Zeitelemente Dokumentation Workflow Unterstützung Simulation Ausnahmebehandlung Spracherweiterung Transformationsregeln und Algorithmen Umwandlung von XPDL zu BPML Allgemein Element Package Element WorkflowProcess Aktivitäten BPML zu XPDL Element package Element process Aktivitätstypen Implementation Eingesetzte Technologie Design Realisierung Testprozess Modellierung des Testprozesses Darstellung des Beispielprozesses mit XPDL Darstellung des Beispielprozesses mit BPML Transformation Vergleich zwischen modelliertem und umgewandeltem Prozess Zusammenfassung Literaturverzeichnis Seite 2

3 2 Einleitung EAI (Enterprise Application Integration) ist laut einer Studie der Gartner Group eine jener Technologien mit beinahe 100%iger Umsatzwachstumschance im Zeitraum 2002 bis Es werden Zuwächse in Höhe von 1,275 Milliarden Dollar in Europa erwartet. (vgl. [Bisc02]) Viele Betriebe setzen bereits heute Geschäftsprozessmodellierungswerkzeuge (GPMW) wie ADONIS oder ARIS ein, um ihre Prozesse dokumentieren, analysieren und auch optimieren zu können. Um EAI erfolgreich in die Unternehmensumwelt integrieren zu können, ist es notwendig Geschäftsprozesse zu modellieren. Dies kann entweder in programmtechnischer Form, zum Beispiel durch Verwendung einer objektorientierten Programmiersprache oder durch Einsatz von graphischen Prozessmodellierungswerkzeugen erfolgen. Letztere werden heute von allen größeren EAI Applikationsherstellern zur Verfügung gestellt, nicht zuletzt um die Akzeptanz von EAI zu erhöhen. Während GPMW jegliche Art von Geschäftsprozessen modellieren können, ist es bei EAI Werkzeugen nicht notwendig eine solche Vielfalt zu ermöglichen. EAI Applikationen dienen rein zur Abbildung und Automatisierung von Informationsflüssen, sowohl im Sinne einer kompletten Automatisierung aber auch im Sinne von Teilautomatisierungen in Kombination mit manuellen Eingriffen. Die vorliegende Diplomarbeit geht aus einer Anstellung des Autors bei GFT Technologies hervor. Ein Kunde des Unternehmens setzt zur Modellierung seiner Prozesse das Prozessmodellierungswerkzeug ADONIS ein. Weiters war von Seiten des Kunden geplant eine noch näher zu bestimmende EAI Applikation einzuführen. Um zu vermeiden, bereits modellierte Prozesse abermals mit einem EAI Prozessmodellierungswerkzeug modellieren zu müssen, wurde GFT Technologies beauftragt eine Schnittstelle zwischen EAI Prozessmodellierungswerkzeug und ADONIS herzustellen. Die Erstellung einer Schnittstelle zwischen ADONIS und einer EAI Applikation erfordert eine Konvertierung in beiden Richtungen. ADONIS bietet, laut Herstellerinformation, die Möglichkeit, Prozesse mit XPDL (XML Process Definition Language) zu modellieren. Die kooperierenden EAI Applikationshersteller von GFT Technologies werden in Zukunft wahrscheinlich BPML (Business Process Modelling Language) als Importsprache unterstützen. In dieser Arbeit wird daher ein Konverter zwischen XPDL und BPML definiert und implementiert. Auf eine Auflistung der verwendeten EAI Applikationen muss aus Geheimhaltungsgründen verzichtet werden. Zielsetzung dieser Arbeit ist es, zwei Algorithmen bereitzustellen, welche verwendet werden können BPML in XPDL und XPDL in BPML zu transformieren. Um eine bloße theoretische Definition zu vermeiden, ist der ermittelte Algorithmus in Form einer Applikation umzusetzen. Ferner gilt es die Frage zu beantworten, ob es sinnvoll bzw. überhaupt machbar ist eine Übersetzung durchzuführen. Seite 3

4 Die Diplomarbeit wurde wie folgt gegliedert: 3. Konzeptvergleich zwischen XPDL und BPML Es soll dargelegt werden, welche speziellen Konstrukte in jeder Sprache modellierbar sind und wie die entsprechenden Gegenstücke, falls vorhanden, aufgebaut sind. 4. Transformationsregeln und Algorithmen Hier werden zwei Algorithmen präsentiert, welche eine Umwandlung eines XPDL Dokumentes in ein BPML Dokument und umgekehrt ermöglichen. 5. Implementation In diesem Kapitel werden die Architektur des Konverters und die verwendeten Applikationen und Applikationsschnittstellen vorgestellt. Weiters erfolgt die Definition eines Testprozesses, welcher in jeder der beiden Prozessgrammatiken abgebildet wird. Am Ende des Kapitels wird die Anwendung der definierten Algorithmen auf die modellierten Prozesse und ein Vergleich zwischen den manuell modellierten und den automatisch generierten Prozessen beschrieben. 6. Zusammenfassung Als Conclusio schließt die Diplomarbeit mit einer Zusammenfassung der erarbeiteten Ergebnisse, möglichen Erweiterungen des Konverterkonzeptes, sowie der dargestellten Algorithmen. Die Begriffe Prozessmodellierungsgrammatik, Prozessmodellierungssprache, Prozessgrammatik und Sprache werden in diesem Dokument synonym verwendet. Die Begriffe XPDL Engine und BPML Engine repräsentieren Applikationen, welche XPDL bzw. BPML Syntax interpretieren und ausführen. Sie sind in ihrer Funktion mit einem Workflow Management System vergleichbar. (vgl. [Alle01]) XML Elemente werden durch den Begriff Element in Kombination mit dem Elementnamen wiedergegeben. Das Element <XYZ>Inhalt</XYZ> wird zum Beispiel durch den Text Element XYZ beschrieben. Zusätzlich erfolgt für jedes Element die Angabe der Prozessgrammatik. Seite 4

5 3 Konzeptvergleich zwischen XPDL und BPML Ausgangsbasis für den Konzeptvergleich bilden die XML Schema Elemente der jeweiligen Sprache. Nicht berücksichtigt werden Sprachkonzepte, welche von Sprachinterpretern implementiert werden und nicht durch die Syntax gegeben sind. Unter Sprachinterpreter versteht man ein Programm, welches als Eingabe Prozessinstruktionen erhält, die in einer Prozessmodellierungsgrammatik ausgedrückt werden, und die dieser interpretiert und ausführt. Für einen abstrakteren Vergleich, welcher fundamentale sprachimanente Konzepte beinhaltet, sei auf [El-B03] verwiesen. BPML (Business Process Modelling Language) ([Arki02]), in der dieser Arbeit zu Grunde liegenden Version 1.0, ist eine blockorientierte Sprache. XPDL (XML Process Definition Language) ([MaNo02]) hingegen ist graphorientiert. Während der Erstellung dieser Arbeit, wurde vom betreuenden Professor eingebracht, dass bereits eine aktuellere Version der BPML Spezifikation existiert. Laut seiner Aussage ist es mit dieser Version bereits möglich Transitionen in BPML darzustellen. Da auf der Website des Konsortiums (vgl. [BPML04]), welches die BPML Spezifikation erstellt hat, keine entsprechende Spezifikation verfügbar war, bleibt das Konzept der Transitionen unter BPML unberücksichtigt. Unter Blockorientierung soll das Ausführungskonzept einer Programmiersprache wie zum Beispiel JAVA verstanden werden, d.h. aufeinander folgende Befehle werden hintereinander ausgeführt, ohne dass eine explizite Verbindung zwischen den Befehlen besteht. Graphorientierte Sprachen arbeiten hingegen mit Transitionen. D.h. es muss jeweils eine explizite Transition zwischen zwei Aktivitäten gesetzt werden, damit diese hintereinander ausgeführt werden können. (für eine Definition von Graph siehe [DorKa96]) Laut [Shap02] ist eine Umwandlung von Blockstruktur in Graphenstruktur kein Problem, die Umkehrung aber sehr wohl. Eine Umwandlung ist nur möglich, wenn gewisse Einschränkungen beachtet werden. Welche Einschränkungen notwendig sind, wurde im Rahmen dieser Arbeit ermittelt. Translation of blocked-structured flow control (routing) into a graph structure presents no fundamental difficulties. The reverse is more problematic. This can be facilitated by imposing a set of restrictions on the graph structure that guarantee it to be well-structured. [Shap02] Oberstes Element in beiden Sprachen ist das Paket. Während XPDL beliebig viele Pakete pro Dokument erlaubt, beschränkt BPML jedes Dokument auf ein einziges Paket. Innerhalb eines Paketes ist es möglich Prozesse, Variablen, etc. zu definieren. Eine weitere Gemeinsamkeit stellt die Subsummierung von Aktivitäten zu Prozessen dar. Damit Aktivitäten automatisiert abgewickelt werden können, ist es möglich Applikationen zu definieren. XPDL ist diesbezüglich mächtiger, da sämtliche Applikationen darstellbar sind. BPML beschränkt sich auf eine Verwendung von Webservice (vgl. [Boot04]) Applikationen. Seite 5

6 3.1 Detaillierter Vergleich Kontext Der Begriff Kontext bezeichnet ein BPML Konstrukt, welches eine Umgebung für alle Aktivitäten und Prozesse innerhalb des Kontextes definiert. Durch dieses Konstrukt ist es möglich, Variablen, Signale, etc. auf einen bestimmten Bereich einzuschränken. context s define an environment for the execution of related activities. Activities that execute within the same context use the context to exchange information and coordinate their execution. An activity can access and modify the value of properties defined within that context, instantiate a nested process, raise and synchronize signals, and so forth. [Arki02] Ein Kontext kann entweder explizit durch das context Element modelliert werden oder implizit durch die Definition eines process oder package Elementes gegeben sein. Es wird von einer Eltern-Kind Beziehung gesprochen, falls ein Kontext einen anderen einschließt. Definitionen, welche innerhalb des Vater-Kontextes definiert sind, stehen innerhalb des Kind-Kontextes zur Verfügung. The hierarchical composition of activities creates a relationship between contexts. When a context definition encapsulates another context definition, we refer to the encapsulating definition as the parent context and to the encapsulated definition as the child context. The child context shares all the definitions of the parent context and, recursively, any of its parent contexts. It can also add local definitions of its own. The child context does not share any of its local definitions with the parent context and, by definition, with any sibling context. [Arki02] In XPDL existiert kein entsprechendes Konstrukt Aktivitäten Während XPDL nur eine einzige Art von Aktivität vorsieht, gibt es unter BPML verschiedene Aktivitätstypen. Diese werden in der nachfolgenden Tabelle dargestellt. Aktivitätstyp action assign call compensate delay empty fault raise spawn Beschreibung des Aktivitätstypes Greift auf ein Webservice zu, wobei Eingabe- und Ausgabevariablen übergeben werden können. Weist einer Variablen einen neuen Wert zu. Instanziert einen Prozess und wartet bis dieser endet. Führt für den laufenden Prozess Kompensation aus. Kompensation bezeichnet die Umkehrung von allen bereits ausgeführten Prozessschritten für den jeweiligen Prozess. D.h. es werden alle Änderungen rückgängig gemacht. Führt zu einer Verzögerung um eine gewisse Zeitdauer. Diese Aktivität ist ohne Inhalt. Erzeugt einen Fehler. Erzeugt ein Signal. Instanziert einen Prozess, ohne darauf zu warten, dass dieser fertig gestellt wird. Seite 6

7 synch all choice foreach sequence switch until while Wartet auf das Auftreten eines vordefinierten Signals, welches zur Instanzierung eines Prozesses führt. Führt alle Aktivitäten parallel aus. Führt eines von mehreren möglichen Aktivitätssets auf Grund des Auftretens eines Ereignisses aus. (zur Definition von Aktivitätsset vgl. Element activityset in Abschnitt 4.2.2) Führt Aktivitäten für jedes Element einer Liste aus. Führt Aktivitäten sequentiell aus. Führt eines von mehreren möglichen Aktivitätssets auf Grund der Erfüllung einer Bedingung aus. Führt Aktivitäten ein- oder mehrmals aus, solange eine gewisse Bedingung nicht erfüllt ist. Führt Aktivitäten null oder mehrmals aus, solange eine gewisse Bedingung erfüllt ist. XPDL bietet nicht so viele verschiedene Aktivitätstypen. Eine Aktivität in XPDL entspricht am ehesten einer action Aktivität in BPML. Dies deswegen, da XPDL Aktivitäten auf Applikationen zugreifen können und somit auch auf Webservices. Die BPML Aktivitäten assign, compensate und empty können ebenfalls mit einer XPDL Aktivität modelliert werden. Allerdings gilt es zu beachten, dass die Aktivität compensate Teil des Transaktionskonzeptes von BPML ist. XPDL unterstützt Transaktionen nicht explizit, weshalb eine Umsetzung unter XPDL nicht sinnvoll erscheint. BPML call Aktivitäten können unter XPDL als Aktivitäten mit Implementationsart Subflow realisiert werden. Diese Aktivitätsart ermöglicht es, einen Prozess an Stelle der Aktivität auszuführen. Signale werden in XPDL nicht unterstützt, wodurch die BPML Aktivitäten raise und synch kein entsprechendes Pendant in XPDL vorfinden. Die BPML Aktivitäten all, choice, switch, until und while lassen sich in XPDL als Transitionen abbilden. Für die BPML Aktivität sequence gibt es unter XPDL mehrere Darstellungsarten, wobei sie sich direkt mittels einer XPDL Aktivität umsetzen lässt. Dabei muss definiert werden, dass es sich bei der verwendeten XPDL Aktivität um eine BlockActivity handelt. BlockActivity bezeichnet eine Aktivität, welche andere Aktivitäten beinhalten kann. Innerhalb der XPDL BlockActivity muss ein XPDL ActivitySet definiert werden, welches mehrere Aktivitäten beinhalten kann, wobei eine sequentielle Ausführung stattfindet. Seite 7

8 In XPDL gibt es folgende Aktivitätsstrukturen: Abbildung 1 Aktivitätsstrukturen in XPDL [MaNo02] Wie in Abbildung 1 ersichtlich, gibt es neben der erwähnten BlockActivity auch eine Route Aktivität. Diese Aktivität soll dazu dienen, eine Kombination mehrerer Transitionen, welche im Abschnitt Transitionen weiter unten behandelt werden, zu ermöglichen Verbindung von Aktivitäten XPDL verwendet für den Übergang von einer zur nächsten Aktivität Transitionen. Hierbei handelt es sich um ein zweiteiliges Konzept. Einerseits gibt es explizite Transitionen, welche die Verbindungen zwischen Aktivitäten bestimmen, andererseits gibt es so genannte TransitionRestriction Elemente. Diese sind Teil der Aktivitäten selbst und bestimmen, wie mit ein- und ausgehenden Verbindungen zu verfahren ist. Abbildung 2 Einschränkung von ein- und ausgehenden Transitionen durch TransitionRestriction Elemente Sowohl für eingehende als für ausgehende Verbindungen existieren zwei Möglichkeiten der Synchronisation. Für eingehende Verbindungen ( Join ) ist es möglich darauf zu warten bis alle vorhergehenden Aktivitäten beendet wurden ( AND Seite 8

9 Restriction ) oder bis eine vorhergehende Aktivität beendet wurde ( XOR Restriction ). Bei ausgehenden Verbindungen ( Split ) können mehrere Aktivitäten gleichzeitig (parallel; AND Restriction ) oder eine von mehren Aktivitäten verfolgt werden ( XOR Restriction ). Explizite Verbindungen zwischen Aktivitäten können nur mittels Transitionen und folglich mit XPDL modelliert werden. Durch die angewandte Blockstruktur in BPML ist eine implizite Reihenfolge und somit Verbindung der Aktivitäten gegeben. Ist eine Wiederholung von Aktivitäten notwendig, so müssen spracheigene Konstrukte wie zum Beispiel until Elemente angewandt werden. Explizite Aufrufe sind nur für process Elemente, welche Prozesse modellieren, definiert. Prozesse sind [ ] eine Summe von logisch zusammenhängenden Aktivitäten, [ ]. ([Wojd02]) Von dieser Definition muss für eine erfolgreiche Umwandlung des Transitionskonzeptes nach BPML Abstand genommen werden. Wird jede XPDL Aktivität als BPML Prozess modelliert, so ist eine Transformation realisierbar. process Elemente, welche BPML Prozesse repräsentieren, können per call Element instanziert werden und ermöglichen somit einen expliziten Aufruf. Nachteilig an dieser Art der Verbindung ist allerdings, dass bei jeder Anwendung dieses Elementes ein eigener Prozess instanziert wird, d.h. es existiert eine eigene Instanz dieses Prozesses. Problematisch ist dies deshalb, da eine Synchronisation von parallel ausgeführten Aktivitäten in Geschäftsprozesse möglich sein muss. Nachfolgend wird dieser Sachverhalt detailierter analysiert. Zwei Aktivitäten werden parallel ausgeführt, wobei sich im Anschluss eine sequentielle Aktivität befindet. Alle Aktivitäten werden als Prozesse modelliert. Da auch die sequentielle Aktivität als process Element repräsentiert wird, ist ein Aufruf durch ein call Element erforderlich. Jede der beiden parallelen Aktivitäten führt diesen Aufruf durch und demzufolge existieren zwei Instanzen der sequentiellen Aktivität. Somit resultiert diese Art der Verbindung in einer fehlerhaften Umsetzung. Es wäre lediglich möglich sequentielle Abläufe fehlerfrei darzustellen. Abbildung 3 Synchronisation von zwei parallelen Aktivitäten Wird für Prozesse eine andere Instanzierungsart gewählt, so ist es dennoch möglich Parallelität zu modellieren. Prozesse sind dann per Signal zu instanzieren. Hierbei ist es möglich mehrere Signale zu definieren, welche für eine Instanzierung eines Prozesses notwendig sind. Für das vorher genannte Beispiel würde dies bedeuten, dass jede der parallen Aktivitäten jeweils ein Signal auslöst und die serielle Aktivität auf diese zwei Signale warten muss, bis sie ausgeführt werden darf. (Zu beachten ist, dass die Aktivitäten als Prozesse modelliert werden und nur deshalb ein Aufruf über Signale erfolgen kann.) Seite 9

10 3.1.4 Prozessinstanzierungsarten Explizite Instanzierungsarten für Prozesse sieht ausschließlich BPML vor. Es existieren drei verschiedene Arten, nämlich Aktivität Ein Prozess dieses Instanzierungstypes kann vom gleichen Kontext (vgl. Abschnitt Kontext weiter unten) aus, mittels der BPML Aktivitäten call, spawn und compensate aufgerufen werden. Nachricht Ein Prozess dieses Instanzierungstypes ist die unabhängigste Art einen Prozess zu instanzieren. Der zugehörige Prozess wartet auf das Eintreffen einer Nachricht, welche nicht im selben Kontext (vgl. Abschnitt Kontext weiter unten) erstellt werden muss. Diese Art der Instanzierung ermöglicht Webservices zur Instanzierung von Prozessen. Signal Ein Prozess dieses Instanzierungstypes ist darauf beschränkt vom selben Kontext (vgl. Abschnitt Kontext weiter unten) aus instanziert zu werden. Sobald das erwartete Signal auftritt, kommt es zur Instanzierung des entsprechenden Prozesses. Im Gegensatz zur Instanzierungsart Aktivität ist es allerdings möglich, dass mehrere Signale für eine Instanzierung definiert werden können. Hierdurch können mehrere vorhergehende Prozesse synchronisiert werden. In XPDL ist die Instanzierungsart nicht näher spezifiziert. Allerdings gibt es bei XPDL die Möglichkeit den AccessLevel eines Prozesses zu spezifizieren. Diese kann entweder öffentlich ( PUBLIC ) (d.h. der Prozess kann von einem externen System bzw. einer externen Applikation aufgerufen werden) oder privat ( PRIVATE ) (d.h. der Prozess kann nur von einer Aktivität mit Implementationsart Subflow aufgerufen werden) sein. XPDL bietet auf Aktivitätsebene die Möglichkeit an, den Implementierungstyp zu spezifizieren. Eine Aktivität kann entweder manuell, durch eine Applikation oder durch einen Prozess implementiert sein. BPML sieht auf dieser Ebene keine entsprechende Angabe vor Variablen Variablen werden in BPML über Property Elemente definiert. Drei Grundtypen können unterschieden werden: simpletype complextype element Diese drei Grundtypen entsprechen XML Schema Typen. (vgl. [Fall01]) In XPDL werden Variablen über Datafield Elemente dargestellt. DataType Elemente spezifizieren um welchen Datentyp es sich handelt. Es existieren die folgenden Datentypen: Seite 10

11 Array Type Hierbei handelt es sich um ein Datenfeld ( Array ) an Datentypen, wobei die einzelnen Elemente dieses Datenfeldes vom gleichen Datentyp sein müssen. Basic Type Hierbei handelt es sich um XSD (XML Schema Definition) simpletype Datentypen. (vgl. [Fall01]) Declared Type Referenziert auf einen definierten Datentyp, welcher in einer Typdefinition deklariert wurde. Enumeration Type Ermöglicht die Darstellung von Aufzählungen. External Reference Referenziert auf ein externes Dokument, welches den gewünschten Datentyp definiert. List Type Dieser Datentyp hat die gleiche Funktion wie der Datentyp Array Type, allerdings findet keine Beschränkung der Anzahl der Elemente statt. Record Type Repräsentiert eine Menge an Elementen, welche von unterschiedlichem Datentyp sein können. Schema Type Ermöglicht die Definition eines Datentyps nach XSD. Union Type Definiert eine Menge an Datentypen, wobei einer davon für eine Dateninstanz verwendet wird Zeitelemente Unter Zeitelementen werden Zeitgeber verstanden, welche bei Erreichen eines bestimmten Zeitpunktes bzw. nach Ablauf einer Zeitspanne einen Prozess oder eine Aktivität ausführen. Beide Sprachen sehen Elemente für diesen Zweck vor. In XPDL ist dies durch so genannte Deadline Elemente möglich. Nach Ablauf einer bestimmten Zeitdauer wird eine Ausnahme ausgelöst, welche dazu führt, dass einer Transition gefolgt wird. Somit dient dieses Element unter XPDL rein zur Festlegung von Maximaldauern für Aktivitäten. BPML sieht für die Abbildung von Zeitdauern das Element Schedule vor. Dieses Element dient im Gegensatz zu XPDL nicht zur Ausnahmebehandlung. Es instanziert einen Prozess zum angegebenen Zeitpunkt und ermöglicht hierdurch die Ausführung einer Aktivität Dokumentation Aktivitäten können in beiden Sprachen dokumentiert werden. Während XPDL hierfür eine eigene Datei vorsieht, in welcher sich eine Beschreibung der jeweiligen Aktivität befindet, ist die Dokumentation unter BPML Bestandteil des jeweiligen Aktivitätselementes. Seite 11

12 3.1.8 Workflow Unterstützung Unter Workflow soll folgende Definition verstanden werden: The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules. [Alle01] XPDL ist darauf ausgelegt Workflows zu unterstützen. Über das Element Implementation wird festgelegt, wie eine Aktivität implementiert ist. Es existieren hierfür drei verschiedene Möglichkeiten, nämlich manuell, Werkzeug unterstützt oder als Subflow. Ist eine Aktivität manuell implementiert, so wird diese Aktivität nicht durch eine XPDL-Engine unterstützt. Ist die Implementationsart gleich Werkzeug unterstützt, so bedeutet dies, dass diese Aktivität auf eine Applikation zugreift und somit durch diese realisiert wird. Subflow, die dritte Art der Implementation, dient dazu, einen Prozess aufzurufen, welcher die entsprechende Aktivität ausführt. Applikationen und Prozessteilnehmer sind durch eigene Elemente abbildbar. BPML unterstützt das Workflowkonzept nicht Simulation XPDL ermöglicht es Simulationsvariablen zu definieren. Diese Variablen sollen es ermöglichen, den Ablauf von Workflowprozessen zu simulieren. Es ist möglich die Dauer, die Kosten, die Wartezeit, die Kapazitätsauslastung (indirekt über das Attribut Instantiation ), etc. zu definieren. BPML kennt kein derartiges Konzept Ausnahmebehandlung BPML stellt ein umfangreiches Paket an Reaktionsmöglichkeiten für die Behandlung von Fehlern zur Verfügung. Es gibt Ausnahmeprozesse, welche auf eingehende Nachrichten hin instanziert werden. Gleichzeitig geht mit der Instanzierung die Beendigung aller gerade ausgeführten Kontextprozesse einher. Unter Kontextprozessen werden all jene Prozesse verstanden, welche innerhalb desselben Kontextes modelliert wurden. Die zweite Ebene des Ausnahmekonzeptes von BPML wird durch Fehlerroutinen ( fault handler ) dargestellt. Diese werden im jeweiligen Kontext definiert und können bei Auftreten von Fehlercodes entsprechende Aktivitäten zur Fehlerbehandlung aufrufen. Kompensationsprozesse stellen die dritte Stufe der Ausnahmebehandlung dar. Änderungen, welche vom fehlerhaften Prozess verursacht wurden, können durch diesen Prozess rückgängig gemacht werden. XPDL hat kein eigenes Ausnahmekonzept. Deadline Elemente sind die einzige Möglichkeit auf fehlerhaftes Verhalten (im Falle des Überschreitens einer bestimmten Zeitspanne bei der Ausführung einer Aktivität) zu reagieren. Nach Überschreiten einer gewissen Zeitspanne, wird ein Fehler ausgelöst. Dies führt dazu, dass eine Transition verfolgt wird. Seite 12

13 Spracherweiterung Die Möglichkeit einer individuellen Spracherweiterung um beliebige Elemente ist nur unter XPDL gegeben. Anforderungen spezifischer Hersteller können in XPDL zusätzlich zu den bereits vorhandenen Elementen über Extended Attributes Elemente definiert werden. Die Sprache ist somit individuell erweiterbar und im Gegensatz zu BPML an nahezu sämtliche Anforderungen anpassbar. Seite 13

14 4 Transformationsregeln und Algorithmen In diesem Kapitel werden zwei Algorithmen dargestellt, welche eine Umwandlung der beiden Prozessgrammatiken ermöglichen. Zuerst wird die Umwandlungsrichtung XPDL zu BPML behandelt, anschließend wird die Umwandlung in entgegengesetzter Richtung dargestellt. Ausgangsbasis für die Erstellung der Algorithmen bilden die jeweiligen XSD Elemente der Prozessmodellierungsgrammatiken. 4.1 Umwandlung von XPDL zu BPML Der folgende Algorithmus beschreibt, wie ein XPDL Dokument in ein BPML Dokument umgewandelt werden kann. Die Elemente des XPDL Dokumentes werden hierarchisch abgearbeitet und in entsprechende BPML Elemente umgewandelt. Es ist folgende Reihenfolge einzuhalten. 1. Es ist das XPDL Package Element zu ermitteln. 2. Es ist ein BPML package Element zu erzeugen. Das Attribut namespace ist gleich zu setzen. 3. Es sind alle XPDL WorkflowProcess Elemente, welche sich im Inhalt des XPDL Package Elementes befinden, zu ermitteln, und für jedes gefundene Element sind die nachfolgenden, untergeordneten Punkte auszuführen. a. Das Attribut AccessLevel, welches dem XPDL WorkflowProcess Element zugeordnet ist, muss je nach Wert folgendermaßen umgesetzt werden. i. Wenn es den Wert PRIVATE besitzt, ist keine Umwandlung notwendig. ii. Wenn es den Wert PUBLIC besitzt, ist ein process Element zu erzeugen, wobei das Attribut name gleich dem Attribut Id des XPDL WorkflowProcess Elementes zu setzen ist. Dem Wert des Attributes name ist der Text I anzufügen. 1. Im Inhalt des BPML process Elementes ist ein BPML event Element zu erzeugen, wobei das Attribut activity gleich dem Attribut Id des XPDL WorkflowProcess Elementes zu setzen ist. Dem Wert des Attributes activity ist der Text invoke voranzustellen. 2. Im Inhalt des BPML process Elementes ist ein BPML action Element zu erzeugen, wobei das Attribut name gleich dem Attribut activity des BPML event Elementes gesetzt wird. Das Attribut porttype ist gleich dem Text xpdlservicetype zu setzen. Das Attribut operation ist gleich dem Attribut name des BPML action Elementes zu setzen. a. Im Inhalt des BPML action Elementes ist ein BPML call Element zu erzeugen. Das Attribut name ist gleich dem Attribut Id des WorkflowProcess Elementes zu setzen. Dem Wert des Attributes name ist der Text call voranzustellen. Das Attribut process ist gleich dem Attribut Id des XPDL WorkflowProcess Elementes zu setzen. Seite 14

15 b. Es ist ein BPML process Element zu erzeugen. Das Attribut name ist gleich dem Attribut Id des XPDL WorkflowProcess Elementes zu setzen. Es ist ein BPML context Element im Inhalt des BPML process Elementes zu erzeugen, welches alle, im Inhalt des XPDL WorkflowProcess Elementes befindlichen, Elemente abbildet. Es ist ein BPML call Element im Inhalt des BPML process Elementes zu erzeugen. Das Attribut process ist gleich dem Attribut name jenes BPML process Elementes zu setzen, welches dem öffnenden Tag des BPML context Elementes am nächsten ist und sich in dessen Inhalt befindet. Das Attribut name ist gleich dem Attribut process zu setzen, wobei der Text call voranzustellen ist. i. Für jedes Activity Element, welches sich im Inhalt des XPDL WorkflowProcess Elementes befindet, ist Algorithmuspunkt 4 (Aktivitäten), welcher weiter unten beschrieben ist, anzuwenden. ii. Für jedes XPDL ActivitySet Element, welches sich im Inhalt des XPDL WorkflowProcess Elementes befindet, sind die nachfolgenden, untergeordneten Punkte auszuführen. Es ist ein BPML call Element im Inhalt des BPML process Elementes zu erzeugen. Das Attribut process ist gleich dem Attribut name jenes BPML process Elementes zu setzen, welches dem öffnenden Tag des BPML context Elementes am nächsten ist und sich in dessen Inhalt befindet. Das Attribut name ist gleich dem Attribut process zu setzen, wobei der Text call voranzustellen ist. 1. Es ist ein BPML process Element zu erzeugen, wobei das Attribut name gleich dem Attribut Id des XPDL ActivitySet Elementes gesetzt wird. 2. Es ist ein BPML context Element zu erzeugen, welches dem Inhalt des BPML process Elementes hinzuzufügen ist. 3. Für jedes XPDL Activity Element, welches sich im Inhalt des XPDL ActivitySet Elementes befindet, ist ein BPML process Element zu erzeugen, welches dem Inhalt des BPML context Elementes hinzuzufügen ist. a. Die einzelnen Elemente sind entsprechend Algorithmusschritt 4 (Umwandlung von Activity Elementen) zu modellieren. iii. Für jedes XPDL Element DataField sind die nachfolgenden, untergeordneten Punkte auszuführen. 1. Es ist ein BPML property Element zu erzeugen. Das Attribut name dieses Elementes ist gleich dem Attribut Id des DataField Elementes zu setzen. Das Attribut type ist gleich dem Attribut Type des XPDL Elementes BasicType, welches sich im Inhalt des XPDL Elementes DataType befindet, zu setzen. Das XPDL Element DataType befindet sich im Inhalt des XPDL Elementes DataField. Der Text xsd: ist dem Wert des Attributes type voranzustellen. Es ist darauf zu achten, dass der Wert des type Attributes ausschließlich Kleinbuchstaben enthält. iv. Für jedes XPDL FormalParameter Element sind die nachfolgenden, untergeordneten Punkte auszuführen. 1. Jedes Element ist als BPML property Element im Inhalt des BPML package Elementes zu modellieren. Seite 15