Inhalt

Metadata
Newsletter	20070917
Sprache	deutsch
Version	1.0
Veröffentlicht von	pcnewsletter
Veröffentlichungsdatum	18.10.2007 17:05:16

XPDL - XML Process Definition Language

Normen & Standards

Dritter Teil der Artikelserie von Dr. Martin Bartonitz zum Thema Business Process Management Standards. Der erste Teil zum Thema BPMN erschien im PROJECT CONSULT Newsletter 20070720Newsletter 20070720 und der zweite Teil erschien im PROJECT CONSULT Newsletter 20070816Newsletter 20070816. Martin Bartonitz ist bei der SAPERION AG für das Thema BPM Business Process Management Produkte verantwortlich. Vor seinem Wechsel nach Berlin war Dr. Martin Bartonitz als Senior-Berater in BPM-Pro-jekten von PROJECT CONSULT tätig. E-Mail: martin@bartonitz.net. Der Artikel zu BPEL war ursprünglich für das Standardlexikon „Telekommunikation von A-Z“ der Firma INTEREST verfasst worden.

Die XPDL ist eine XML-basierte Prozessbeschreibungs-sprache zur Ausführung durch Workflow Management Systeme – WMS. Verantwortlich für die Spezifikation der XPDL ist die Workflow Management Coalition – WfMC, eine in 1993 gegründete Allianz zwischen Anwendern, Herstellern und Beratern zum Zwecke von Standardisierungen von Begriffen und Schnittstellen im Umfeld von technisch unterstützten Geschäftsprozessen.

Inzwischen hat sich die Anwendbarkeit des Formats mit der seit 2005 vorliegenden Version 2.0 noch erweitert. Die erste Version war noch nicht XML-basiert und wurde im Jahr 2000 veröffentlicht. Die Erweiterungen der Version 2.0 erlauben einen bi-direktionalen Austausch mit der grafischen Prozessdarstellung der Business Process Modeling Notation, kurz BPMN. Die BPMN wird verantwortlich durch die Object Management Group – OMG – spezifiziert.

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 Quadrant 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

WfMC-Referenzmodell

Geschäftsprozessunterstützenden Anwendungen, wie z.B. den grafischen Prozessdarstellungswerkzeugen ARIS Toolset oder Bonapart sowie Simulatoren, verwendet.

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 Arbeitslisten 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 Werkzeuge.

Schnittstelle 4
dient der Integration von anderen Workflow Management Systemen. Die Spezifikation sieht den Aufruf entfernt stattfindender Aktivitäten, Datentransfer sowie Möglichkeiten zur Synchronisation zwischen verschiedenen Workflow Enactment Services vor. Weitere Details hierzu können der WfMC Spezifikation Wf-XML Version 2.0 entnommen erden.

Schnittstelle 5
beschreibt die Kommunikation zwischen Workflow-Enactment-Dienstleistungen und externen Kontroll- bzw. Verwaltungswerkzeugen.

Unterschiede zwischen WSBPEL 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 Bearbeitung 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 schnelllebiger 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 wird.

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 vor.

XPDL Metamodell

Das Konzept der XPDL mit seinen Zusammenhängen zwischen den Sprachelementen ist übersichtlich in einem Metamodell (siehe nachfolgende 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ährend 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 werden. Das Erstellen von neuen Datensätzen oder das Digitalisieren von Dokumenten sind mögliche Datenquellen im Workflow-Kontext. Beispiele für externe Datenquellen sind gemeinsame Datenbanken, die relevante Daten für ein Unternehmen enthalten.

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 einer 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 betriebliche 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 Entwicklungsumgebungen oder -sprachen selbst erstellt werden.

WfMC Process MetaModell der XPDL 2.0 mit BPMN-spezifischen Erweiterungen (grau)

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 (Participant) unter Verwendung bestimmter Anwendungssoftware und relevanter Daten ausgeführt wird. Zudem 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 Transaktion 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' ausgewertet wurden.

Beispiel eines Diagramms nach der BPM-Notation mit Swim Lanes, Activities, Transitions und Events

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ätigkeitsblock 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.

Die in der oberen Grafik in grau dargestellten Entitäten Pool, Lane, Gateway und Event sind ebenfalls mit der Version 2.0 hinzugekommen und sind das Ergebnis der Absprachen zwischen der WfMC und der OMG, die den bidirektionalen Austausch zwischen dem texturellen Modell der XPDL und des grafischen Modells der BPMN regelt. Die folgende Grafik zeigt ein Beispiel eines BPMN-Digramms, das 2 Pools enthält. Der obere Pool Bank enthält nur eine Swimlane, während der untere Pool Lieferant die Swimlanes Distribution und Versand enthält und gruppiert.

Prozesse laufen jeweils nur innerhalb von Pools. Synchronisationen zwischen diesen Prozessen erfolgen durch Informationsaustausch, dargestellt über gestrichelte, gerichtete Grafen. Die Kästchen stellen Aktivitäten dar. Das plus in drei der Kästchen signalisiert, dass hier Sub-Prozesse hinterlegt sind. Die Kreise sind Ereignisse, hier Start und Ende. In diesem Fall ist kein Gateway enthalten. Gateways werden als Raute mit unterschiedlichen inneren Symbolen dargestellt und dienen der Verzweigung und Zusammenführung derselben.

XPDL Entity-Details

Bei dem Entwurf von XPDL hat man aufgrund der durch die Zielsetzung benötigten Vielseitigkeit den Schwerpunkt auf eine höchstmögliche Flexibilität gelegt.

Übersicht der Elemente der wichtigsten Entitäten der XPDL

Diese Flexibilität wird über das Element ExtendedAttribute erreicht, das in jeder Entität zur freien Gestaltung genutzt werden kann. So ist es z.B. möglich, verschiedene Ressourcetypen zu beschreiben und in den Workflow einzubinden, unabhängig davon, ob Mensch oder Maschine. Man kann in Verbindung mit dem Element ExtendedAttribute Ressourcen beliebigen Typs nach einmaliger Definition in einer Geschäftsprozessdefinition nutzen. Zusätzlich können mit diesem Element auch beliebige Informationstypen innerhalb des Workflows verwendet werden. Bei Bedarf ist es sogar möglich, neue Datentypen zusätzlich zu den Standarddatentypen zu definieren, die in einer XPDL Workflow-Definition anschließend wie originäre Datentypen behandelt werden können.

Allen Entitäten gleich, ist ihre in der Prozess-Definition eindeutige ID, ein beschreibender Name sowie eine ausführliche Beschreibung zum Zwecke der Dokumentation.

Die Entität Package dient dem Transport von mehreren Prozess-Definitionen (Workflow Process) zwischen den unterschiedlichen Applikationen, daher ist auch der Name des Herstellers enthalten (Source Vendor ID), wie grafischen Modellierungswerkzeugen, Workflow Enactment Systemen, Simulatoren und Analysatoren.

Für den einzelnen Workflow ist besonders wichtig der Publikationsstatus, der zumindest zwischen den Zuständen Test und Produktion unterscheidet, sowie das Datum, von wann bis wann die Definition für den Betrieb genutzt werden soll.

Für die Entität Activity ist besonders die Deadline hervor zu heben. An diesem Beispiel möchte ich auf die z.T. sehr starken Unterschiede von Produkten aus dem Bereich Workflow Management eingehen. Mit der Deadline wird kenntlich gemacht, bis zu welchem Termin die Bearbeitung dieser Aktivität abgeschlossen sein soll. Dem Anwender wird dieses Datum in seiner Worklist (Eingangskorb) kenntlich gemacht. Anhand des folgenden konkreten Beispiels auf Basis des Produktes SAPERION Workflow (das allerdings noch nicht den XPDL-Standard unterstützt) sei die Vielfalt von Terminfunktionen geschildert:

SAPERION lässt für eine Aktivität mehr als einen Termin zu, zu denen jeweils unterschiedliche Aktionen im Falle der Terminüberschreitung ausgeführt werden können. Häufig ist gewünscht, dass im Falle der Terminüberschreitung zuerst der Adressat selbst auf die Situation aufmerksam gemacht wird, z.B. indem in seinem Eingangskorb der Geschäftsfall wieder dick schwarz markiert wird. Nach der Überschreitung eines zweiten Termins könnte eine Meldung an seinen Vorgesetzten erfolgen. Alternativ könnte der Geschäftsfall auch gleich direkt an eine andere Person derselben Gruppe zur Bearbeitung geschickt werden. Bleibt in diesem Fall die Bearbeitung wieder liegen, könnte der Fall an einen Sonderabeitsplatz geroutet werden. Nach einem letzten Termin könnte dann aber auch die vorliegende Aktivität übersprungen und über einen Ausnahmeweg zur nächsten Aktivität weitergeleitet werden. Was aber dann auch schon das Ende des Falls sein könnte, da nach Verfall von so viel Zeit der angefragte Kleinkredit vermutlich schon längst von der Konkurrenz bearbeitet ist.

Ein Termin kann relativ oder absolut sein. Im letzteren Fall z.B. immer am Ende des laufenden Monats. Der relative Fall könnte immer bedeuten, die Bearbeitung innerhalb von 2 Wochen oder aber Kalenderwochen erfolgen soll. Der Termin könnte aber auch dynamisch bestimmt werden und von Daten der Workflow-Instanz (Geschäftsfall / Vorgang) abhängen. In diesem Fall muss er zum Zeitpunkt der Instanziierung der Aktivität berechnet werden.

Das vorherige kleine Beispiel verdeutlicht, dass gerade aufgrund der großen Flexibilität von XPDL festgestellt werden muss, dass das Ergebnis der Spezifikation dem kleinsten gemeinsamen Nenner der Bedürfnisse aller Mitglieder der WfMC genügt. Diese Tatsache bedeutet, dass bei einer möglichen Realisation in großem Maße Anpassungsarbeiten anfallen, um Besonderheiten des jeweiligen Workflows zu definieren. Diese Arbeit könnte bei einem Produkt, das auf den Bedarf einer Branche unter Ausnutzung spezialisiert ist, geringer sein. D.h. man wird auch bei Herstellern, die behaupten, XPDL-Standard umgesetzt zu haben, das betreffende Produkt in Pilot auf Herz und Nieren prüfen müssen, um die versteckten Aufwände aufzudecken.

XPDL Definitionsbeispiele

Den kompletten Satz der Spezifikation zu erklären würde diesen Artikel sprengen, dennoch soll eine kleine Auswahl an Beispielen einen Überblick geben. Da XPDL sämtliche für eine Workflow-Anwendung notwendigen einzelnen Prozessdefinitionen in einem Paket anbietet, folgt zuerst ein Beispiel, das den Aufbau eines Pakets (zur besseren Übersichtlichkeit sind einige Information ausgelassen worden) verdeutlicht. Nach einem Header folgen sämtliche Deklarationen wie Typen, Ressourcen und Applikation, erst zum Schluss folgen nacheinander die Prozessdefinitionen.

</PackageHeader>

…

<xsd:schema attributeFormDefault="unqualified"

elementFormDefault="qualified" … >

<xsd:simpleType name="Status">

<xsd:restriction base="xsd:string">

<xsd:enumeration value="ValidData"/>

<xsd:enumeration value="InvalidData"/>

<xsd:enumeration value="Accept"/>

<xsd:enumeration value="BadCredit"/>

<xsd:enumeration value="OverLimit"/>

<xsd:enumeration value="BadDataFormat"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:schema>

</SchemaType>

</TypeDeclaration>

</TypeDeclarations>

<WorkflowProcess AccessLevel="PUBLIC" Id="wfmc-wf-1"

Name="EOrder">

…

</WorkflowProcess>

</WorkflowProcesses>

</ExtendedAttributes>

</Package>

Beispiel (COSA BPM Suite) für die Definition von Prozessteilnehmern, auf die innerhalb der einzelnen Aktivitäten referenziert wird. Das Beispiel zeigt zwei Teilnehmer, eine vom Typ „Rolle“ und eine vom Typ „System“. Über die ExtendedAttributs werden COSA-spezifische Attribute gesetzt. Als Vorgesetzter der Rolle ist „Koenig“ definiert. Die Rolle ist unter „Finanzen“ aufgehängt und hat die Mitglieder „Moneypenny“ und „Sparsam“.

<Description>Buchhaltung</Description>

</ExtendedAttribute>

</ExtendedAttribute>

</ExtendedAttribute>

</ExtendedAttributes>

</Participant>

<Description>Reference to Database Resource

</Description>

</Participant>

…

</Participants>

Beispiel (COSA BPM) für die Definition einer Anwendung, die während der Durchführung einer Aktivität ausgeführt werden soll. In diesem Fall wird in der Aktivität mittels eines Coda-spezifischen Scripts (ExtendedParameters) als Anwendung eine Nachricht über eine Terminüberschreitung ausgegeben und anschließend direkt weitergeleitet (autoconfirm) zur nächsten Aktivität.

</FormalParameter>

</FormalParameters>

GUI.MessageBox("Der Termin für die Rechnungs

bearbeitung Nr. " + invoiceNo + " ist abgelaufen -

bitte prüfen.", "Terminablauf")

activity.autoConfirm()

</SCRIPT>

</ExtendedAttribute>

</ExtendedAttributes>

</Application>

…

(Aktivitätsdefinition einer manuellen ersten Aktivität am Beispiel von COSA BPM)

<Description>Buchen der Rechnung</Description>

Kommentar: Es folgt ein Block Simulationsinformationen über die geschätzte Gesamtdauer, Arbeitszeit und Liegezeit

</TimeEstimation>

</SimulationInformation>

<Icon…/inssheet.gif</Icon>

Buchhaltung</Performer>

</Performers>

Kommentar: Es folgt der Block mit den System-spezifischen Daten, die das Verhalten der Aktivität zur Laufzeit festlegen, z.B. ob die Priorität durch den Anwender geändert werden darf. Der Text, der im Eingangskorb angezeigt werden soll, wird in Deutsch und Englisch hinterlegt. Welche Applikationen zur Durchführung der Aufgabe gestartet werden sollen, werden im Script hinterlegt.

<ExtendedAttribute Name="ChangePriorityAllowed"

Value="true"/>

<MemoText Language="de">Rechnungsdaten buchen

</MemoText>

<MemoText Language="en">post invoice data

</MemoText>

</ExtendedAttribute>

task.call("BuchungDurchfuehren", instance.AppDir

+ "Kunde.mdb", "Rechnungen",

instance.Rechnungsnummer, instance.Auftragsnummer,

instance.Lieferant, instance.Rechnungsbetrag,

instance.ObjektVorgang)

task.call("RechnungAbschliessen", Instance.ObjektRech,

Instance.ObjektVorgang, Instance.ObjektAuftrag)

activity.autoconfirm()

</Script>

</ExtendedAttribute>

Buchhaltung</Performer>

</ExtendedAttribute>

<ExtendedAttribute Name="URL" Value=

"http://localhost/.../Activity_1391_help.html"/>

</ExtendedAttributes>

Kommentar: Und zum Schluss auch noch die grafischen Details zur Anzeige im Modellierungswerkzeug:

<Coordinates XCoordinate="87" YCoordinate="89"

xpos="87" ypos="89"/>

</NodeGraphicsInfo>

</NodeGraphicsInfos>

</Activity>

…

</Activities>

Die folgenden beiden Beispiele zeigen den Unterschied zwischen einer sequentiellen Abfolge von Aktivität A nach B und einer parallelen Abfolge von A nach B und C mit einem Join in D. Es sind nur die für den Ablauf zum Verständnis notwendigsten Zeilen dargestellt. Da der Rest selbsterklärend ist, soll er nicht weiter ausgeführt werden.

...

</Activity>

...

</Activity>

</Activities>

</Transitions>

</WorkflowProcess>

...

</TransitionRefs>

</Split>

</TransitionRestriction>

</TransitionRestrictions>

</Activity>

...

</Activity>

....

</Activity>

...

</TransitionRestriction>

</TransitionRestrictions>

</Activity>

</Activities>

</Transitions>

</WorkflowProcess>

Validierung der XPDL-Konformität

Ein noch relativ offenes Feld ist die Prüfung von XPDL-Dateien, die von unterschiedlichen Anwendungen erzeugt wurden, auf die Konformität zur Spezifikation der WfMC. Da dies so ist, sind die Behauptungen der Hersteller (siehe Liste am Ende des Artikels) noch mit Vorsicht zu genießen.

Das weiter unten kurz beschriebene Modellierungswerkzeug von Together prüft zwar nach eigenen Angaben intern die korrekte Erstellung der XPDL-Prozessstrukturen, gibt aber leider keine detaillierte Fehlerbeschreibung aus, wenn eine XPDL-Datei einer anderen Anwendung eingelesen wird und es Probleme dabei gibt.

Auf der Web-Site der WfMC wird allein ein Tool – von der Fa. itp commerce - genannt, das die Validierung von XPDL-Dateien nach der 1.0 Spezifikation durchführt. Genauer betrachtet heißt dies jedoch nur, dass während der Modellierung der BPMN-Diagramme und der zugehörigen Attribute beim Einschalten des Modus XPDL laufend die Syntax gecheckt wird. D.h. auch hier wird vermutlich das Tool scheitern, wenn es fremde XPDL-Dateien einliest, die nicht genau auf die eigenen Sturkturen passen.

Die WfMC hat mittlerweile auch die Wichtigkeit der Verfügbarkeit eines Tools zur Einhaltung der Konformität erkannt. D.h. es wird aktuell daran gearbeitet, so dass hier kurzfristig noch Neues zu erwarten ist.

Simulation

Da in der XPDL pro Prozess und Aktivität auch Angaben zu den Liegezeiten, Bearbeitungszeiten und Durchlaufzeiten hinterlegt werden können, lassen sich die Packages auch in Simulatoren einlesen und in ihrem Verhalten simulieren. Die folgende Grafik zeigt ein Beispiel der Simulationsdatenpräsentation innerhalb eines BPMN-Diagramms.

Darstellungsform von Prozesssimulationsdaten

XPDL-fähige Anwendungen

Für den Leser, der etwas Übung mit Modellierungswerkzeugen hat, empfehlt sich, die Demoversion des Together Workflow Editors zu installieren und sich mit der XPDL vertraut zu machen. Das Tool ist weitestgehend intuitiv zu benutzen und führt daher schnell zu Ergebnissen und Aha-Erlebnissen. Der Link lautet:

http://www.together.at/together/demo/index.html

Die folgende Grafik zeigt eine Ansicht des Tools. In dem linken oberen Fenster wird eine kleine Ansicht des Prozesses gezeigt. Darunter wird in Exploreransicht die Struktur der Pakete mit den Prozessen angezeigt. Rechts oben befindet sich das Bearbeitungsfenster, in dem entweder der Prozessgraf angezeigt wird oder wie hier dargestellt die XML-Struktur der XPDL. Das Fenster darunter dient der Anzeige von aktuellen Fehlern in der Definition. Es gibt eine Reihe von Dialogen, in den u.a. die Ressourcen und Applikationen vorab definiert werden und auf die dann in den Aktivitäten referenziert wird.

XPDL-fähiger Workflow Editor von Together

Anwendungen, die XPDL unterstützen, können grundsätzlich in 3 Typen eingeteilt werden. Der eine Typ von Anwendungen unterstützt allein die Dokumentation von Geschäftsprozessen, die andere führt im Sinne der WfMC-Referenzmodells die Prozesse als Workflow Enactment Engine aus, der dritte simuliert und analysiert diese.

Workflow-Anwendungen, die XPDL unterstützen:


	·	COSA® BPM Die Prozessdiagramme werden BPMN-nah grafisch erstellt, in XPDL 2.0 gespeichert und beim Übertragen in die Workflow-Engine in Petri-Netze konvertiert. Der Simulator lädt die XPDL und die aktuellen Prozessdaten zur Analyse.
	·	EMC Documentum Process Suite Modellierung von BPMN-Diagrammen mit Export nach XPDL und BPEL. XPDL kann vom eigenen Analyzer als auch der Engine verarbeitet werden.
	·	IBM FileNet Business Process Manager voller Support von XPDL Version 1. 0 und 2.0 als auch BPMN.
	·	Fujitsu Interstage® Business Process ManagerTM *(i-Flow) erstes Modellierungswerkzeug, das ab 2006 BPMN-Diagramme nach XPDL 2.0 gespeichert hat und mit der Engine verarbeitet hat.
	·	Global 360 Enterprise Business Suite Modellierung von BPMN mit dem SketchPad, Speicherung nach XPDL 2.0, Simulation mit dem Process Simulator sowie Ausführung durch G360 Case Management.
	·	Sungard CARNOT Process Engine Export und Import von XPDL Version 2.0.
	·	Software AG Crossvision BPM voller Support von XPDL Version 2.0.
	·	TIBCO BusinessWorks Eine Erweiterung implementiert die Unterstützung von XPDL Version 1.0 und 2.0.


	·	Enhydra Shark (Open Source) Shark ist komplett auf den Standards der WfMC und OMG aufgebaut und nutzt XPDL als ihr natives Workflow-Definitionsformat. Die Prozesse werden modelliert mit JaWE, die Aktivitäten werden in Enhydra DODS gespeichert.

Dokumentations- und Simulationsanwendungen, die XPDL unterstützen


	·	BOC Adonis Werkzeug zur Dokumentation und Analyse von Geschäftsprozessen mit Unterstützung der Modellierung in BPMN und der Speicherung in XPDL.
	·	CACI Simprocess Grafisch-orientiertes Werkzeug zur Modellierung von Arbeitsabläufen zum Zwecke der Simulation und Kostenanalyse in Bezug auf Aktivitäten. Ein Export und Import von XPDL wird unterstützt. Die grafische Darstellung erfolgt auf Basis einer eigenen Notation.
	·	IDS Scheer Business Architect IDS Scheer ist der Marktführer im Bereich der Geschäftsprozessanalyse. Das Modellierungswerkzeug exportiert und importiert XPDL Version 1.0 und 2.0. Exportiert auch BPEL und stellt neben der eigenen grafischen Darstellung von Ereignisgesteuerten Prozessketten diese in BPMN-Diagrammen dar.
	·	itp commerce Process Modeler for Microsoft Visio Werkzeug zur Dokumentation von Geschäftsprozessen, das komplett auf die Darstellung von BPMN-Diagrammen spezialisiert ist. Export von XPDL und BPEL. Sehr gute Erweiterung für individuelle Attribute. Direkte Unterstützung für die Workflow bzw. Process Engines von Microsoft BizTalk-Server, Carnot, ORACLE Process Manager und BEA AquaLogic.
	·	Enhydra Shark / Together Workflow Editor Allgemeines Modellierungswerkzeug zur Erzeugung von XPDL unabhängig von der Ausprägung einer speziellen Workflow Engine. Die grafische Darstellung der Prozesse basiert auf BPMN.

Literatur

Aalst, Wil M.P. van der: “Patterns and XPDL: A Critical Evaluation of the XML Process Definition Language”, Department of Technology Management Eindhoven University of Technology, The Netherlands

Frank, U.; Laak, Bodo van: „Anforderungen an Sprachen zur Modellierung von Geschäftsprozessen, Research Report of the IS Research Institute“, University of Koblenz, Nr. 34, 2003

Hollingsworth, D.: „The Workflow Reference Model“, Document Number TC00-1003, Winchester: Workflow Management Coalition, 1995

Pyke, Jon : WfMC Chairman, “XPDL the silent workhorse of BPM”, WfMC Web Site

Shapiro , Robert M.: XPDL 2.0: Integrating ProcessInterchange and BPMN

Wf-XML Version 2.0 Spezifikation

WSBPEL Version 2.0 Draft-Spezifikation

XPDL Version 2.0 Spezifikation

Internetressourcen

http://www.oasis-open.org Organization for the advancement of Structured Information Standards

http://www.omg.org
Object Management Group

http://www.wfmc.org
Workflow Management Coalition

http://www.kswenson.com/wiki/
Workflow und BPM Wiki Site im Entstehen von Keith Swenson, aktivesMitglied der WfMC

BPMN-Poster: http://sourceforge.net/project/showfiles.php?group_id=194824&package_id=229811