XPDL - XML Process Definition Language

XPDL XML Process Definition Language Dr. Martin Bartonitz Product Manager SAPERION AG Vorsitzender des Aufsichtsrates: Dieter Matheis | Vorstand: Rudolf Gessinger (Vorstandsvorsitzender), Andreas Kunze | Amtsgericht Berlin-Charlottenburg HRB Nr. 78848 | XPDL – XML Process Definition Language Die XPDL ist eine XML-basierte Prozessbeschreibungssprache zur Ausführung durch Workflow Manage- ment Systeme – WMS. Verantwortlich für die Spezifikation der XPDL ist die Workflow Management Coali- tion – WfMC, eine in 1993 gegründete Allianz zwischen Anwendern, Herstellern und Beratern zum Zwe- cke von Standardisierungen von Begriffen und Schnittstellen im Umfeld von technisch unterstützten Ge- schäftsprozessen ist. Inzwischen hat sich die Anwendbarkeit des Formats mit der seit 2005 vorliegenden Version 2.0 noch er- weitert. Die erste Version war noch nicht XML-basiert und wurde im Jahr 2000 veröffentlicht. Die Erwei- terungen der Version 2.0 erlauben einen bi-direktionalen Austausch mit der grafischen Prozessdarstel- lung der Business Process Modeling Notation, kurz BPMN. Die BPMN wird verantwortlich durch die Object Management Group – OMG – spezifiziert. Abbildung 1: XPDL als Austauschformat zwischen Prozessanwendungen XPDL als Austauschformat zwischen Prozessanwendungen Auf der Web-Site der WfMC sind mittlerweile an die 60 Anwendungen gelistet, die XDPL zum Speichern ihrer Prozessdefinitionen verwenden. 8 der 11 Top-BPMS-Leader im rechten, oberen Gartner Magic Qua- drant unterstützen XPDL. Zum Abschluss dieses Artikels folgt eine kleine Liste weiterer repräsentativer Anwendungen. Während die XPDL anfangs nur für die Unterstützung der Schnittstelle 1 des Referenzmodells der WfMC, die den Austausch von Modellen eines grafischen Modellierungstool zur ausführenden Workflow-Engine beschreibt, gedacht war, wird das Datenformat mittlerweile als generelles Austauschformat zwischen den geschäftsprozessunterstützenden Anwendungen wie grafischen Prozessdarstellungswerkzeugen wie ARIS Toolset oder Bonapart sowie wie Simulatoren verwendet. 21.02.2008 Seite 2 von 13 Abbildung 2: WfMC-Referenzmodell Die anderen Interfaces des Referenzmodells sind wie folgt: Schnittstelle 2 beschreibt den Datenaustausch zwischen einem WMS (Workflow Enactment Service) und einer Workflow-Client-Anwendung, die grundlegende Funktionalitäten wie die Darstellung von Arbeitslis- ten zur Verfügung stellen, über die die Anwender sich an der Bearbeitung von anliegenden Aufgaben in Geschäftsfällen beteiligen können. Schnittstelle 3 setzt die notwendige Integration von externen Programmen um. Üblicherweise werden die notwendigen Fachfunktionen nicht vollständig durch das WMS zur Verfügung gestellt. Folglich muss es eine Schnittstelle zu anderen Programmen geben, die bereits im Unternehmen eingesetzt werden. Beispiele für solche Programme sind betriebliche Anwendungen wie z.B. ERP, CRM und spezifische Werk- zeuge. Schnittstelle 4 dient der Integration von anderen Workflow Management Systemen. Die Spezifikation sieht den Aufruf entfernt statt-findender Aktivitäten, Datentransfer sowie Möglichkeiten zur Syn- chronisation zwischen verschiedenen Workflow Enactment Services vor. Weitere Details hierzu können der WfMC Spezifikation Wf-XML Version 2.0 entnommen Schnittstelle 5 beschreibt die Kommunikation zwischen Workflow-Enactment-Dienstleistungen und ex- ternen Kontroll- bzw. Verwaltungswerkzeugen. Unterschiede zwischen WSPBEL und XPDL Neben der XPDL gibt es eine weitere wichtige Prozessbeschreibungssprache, die WSBPEL -Web-Service Business Process Execution Language, kurz BPEL. Während für die Spezifikation der XPDL die Bearbei- tung von Dokumenten durch Menschen im Vordergrund steht, liegt der Schwerpunkt der Spezifikation für die BPEL (Kurzform für WSBPEL) in der Orchestrierung von Web-Services, die zum überwiegenden Teil als Hintergrundprogramme auf Servern laufen, ohne dass ein Mensch beteiligt ist. D.h. eine BPEL- Beschreibung weiß über die Beteiligung durch einen Menschen nichts, da diese in den aufgerufenen Web-Services selbst stattfindet. BPEL ist ein Kind des Internet-Hypes Ende der 1990er Jahre. In dieser Zeit wurden verstärkt so genannte End-to-End-Prozesse zwischen Business-Partnern auf Basis von Web-Technologien umgesetzt. Daraus entwickelt hat sich eine neue Sicht auf Software-Architekturen, mit dem besonderen Schwerpunkt der Agilität. Prozesse über unterschiedliche Plattformen und Applikationen hinweg werden immer schnelle- biger und müssen daher immer schneller angepasst werden. Die Antwort lautet SOA: Service Oriented Architecture. Im Kontext von SOA sind die Services im Wesentlichen Web-Services, allgemein ist jedoch damit gemeint, das Applikationen zukünftig keine Software-Monolithen sein werden sondern in sinnvoll große Services unterteilt werden, deren Business-Logik wo nötig in andere Komponenten eingebunden werden. 21.02.2008 Seite 3 von 13 Die Unterschiede der beiden technischen Beschreibungssprachen für Geschäftsprozesse XPDL und WSBPEL kann unter BPEL nachgelesen werden. Verfechter der BPEL werfen der XPDL Spezifikation im Wesentlichen das Fehlen der Fehlerbehandlung und Kompensationsmechanismen. XPDL Metamodell Das Konzept der XPDL mit seinen Zusammenhängen zwischen den Sprachelementen ist übersichtlich in einem Metamodell (siehe nach-folgende Grafik) dargestellt. Dieses Metamodell enthält statische Entitä- ten (z.B. Daten oder Anwendungen) und dynamische Konzepte (Prozesse). Statische Entitäten werden repräsentiert durch die Metatypen + Workflow Relevant Data (Workflow-relevante Daten), + Workflow Participant Specification (Workflow-Teilnehmer-Spezifikation) und + Workflow Application Declaration (Workflow-Anwendungsdeklaration). Workflow-relevante Daten werden initialisiert, erzeugt, von externen Anwendungen gelesen und wäh- rend des Ablaufs des Workflows verwendet. Sie können bspw. durch einen Vorgang in einem Workflow erstellt oder aus externen Datenquellen (z.B. einem Unternehmensinformationssystem) gewonnen wer- den. Das Erstellen von neuen Datensätzen oder das Digitalisieren von Dokumenten sind mögliche Daten- quellen im Workflow-Kontext. Beispiele für externe Datenquellen sind gemeinsame Datenbanken, die relevante Daten für ein Unternehmen enthalten. Abbildung 3: WfMC Process MetaModell der XPDL 2.0 mit BPMN-spezifischen Erweiterungen (grau) Die Workflow-Teilnehmer-Spezifikation beschreibt die Ressourcen, die einen gegebenen Prozessschritt (Activity) ausführen. Sie muss sich nicht zwangsläufig auf Menschen oder eine einzelne Person beziehen. Sie repräsentiert vielmehr eine abstrakte Ressource oder Rolle, die von einer oder mehreren Personen sowie einer Maschine ausgefüllt werden kann. Dennoch steht Workflow Participant immer für eine in ei- ner Organisation verfügbare Ressource bzw. für eine Entität in einem Organisationsdiagramm. Die Workflow-Anwendungsdeklaration beschreibt die Softwareanwendungen, die für die Ausführung von Workflow-Prozessen benötigt werden. Diese Anwendungen werden in der Regel durch die Workflow- Engine initiiert und Workflow-relevante Daten werden dabei als Parameter übergeben. Beispiele für Workflow-Anwendungen sind interne Anwendungen sowie externe Anwendungen wie zum Beispiel be- 21.02.2008 Seite 4 von 13 triebliche Informationssysteme oder gemeinsame Büroanwendungen. Interne Anwendungen werden i.d.R. als Teil des Workflow-Management-Systems bereitgestellt oder können mit Hilfe proprietärer Ent- wicklungsumgebungen oder -sprachen selbst erstellt werden. Dynamische Aspekte des Metamodells werden durch die Entitätstypen Transition Information sowie Workflow Process Activity und ihren konkreten Subtypen repräsentiert: + Block Activity (Blockaktivität), + Atomic Activity (Einzelaktivität) und + Sub-Process Definition (Subprozessdefinition). Unter einer Aktivität wird eine bestimmte Arbeitseinheit verstanden, die von einem Teilnehmer (Parti- cipant) unter Verwendung bestimmter Anwendungssoftware und relevanter Daten ausgeführt wird. Zu- dem ist jede Tätigkeit durch einen Anfangs- und Endzeitpunkt charakterisiert, ob sie automatisch durch das WMS ausgeführt werden kann oder durch einen Workflow-Teilnehmer ausgeführt werden muss. Die Transitionsinformation (Transition Information) spezifiziert den Kontrollfluss zwischen den einzelnen Aktivitäten. Sie besteht aus einer Anfangs- und Endaktivität und einer Bedingung, unter der die Transak- tion durchgeführt wird. Mit Hilfe der Bedingung wird im Falle von Verzweigung gesteuert, ob dies logisch mit UND, OR oder XOR erfolgt. Es gibt die folgenden vier Bedingungen: + CONDITION: diese Transition kann erfolgen, wenn die Bedingung als wahr ausgewertet wird. + OTHERWISE: diese Transition erfolgt immer dann, wenn keine andere Transition sich als wahr erweist. + EXCEPTION: diese Transition erfolgt in Ausnahmesituationen + DEFAULTEXCEPTION: diese Transition erfolgt, wenn alle anderen EXCEPTION conditions als 'false' aus- gewertet wurden. Eine atomare Tätigkeit ist eine unteilbare Arbeitseinheit, die in einem Durchgang erledigt werden muss. Eine Subprozess-Definition erlaubt das Einbetten einer anderen Workflow-Prozess-Definition. Ein Tätig- keitsblock besteht aus einem Satz von mehreren Tätigkeiten (Typ Activity Set). Die Semantik eines Tä- tigkeiten-Satzes ist ähnlich zu dem eines Makros. Wenn ein Satz von Tätigkeiten während der Ausführung eines Workflow-Prozesses aufgerufen wird, werden die Tätigkeiten, die in dem Satz enthalten sind, in die aufrufende Prozessdefinition kopiert.