Was ist in der BPMN 2.0 eigentlich mit den Daten geschehen?

Die Daten, in BPMN 1.2 eine einfache Sache – Datenobjekte für allen und jedes. Datenobjekte werden sehr oft ein wenig „salopp“ behandelt, als Dokumentations-Zusatz verwendet oder ganz einfach ignoriert oder sogar falsch angewendet. Was ist nun aber genau mit den Daten und Datenflüssen in der BPMN 2.0 geschehen? Spielen Daten wirklich keine Rolle in einem Prozessmodell?

Nun, seit BPMN 2.0 haben es die Datenobjekte zu einer eigenen Kategorie gebracht, mit dem sinngemässen Namen „Data“. Unter Daten fallen:

1. Data Objects
2. Data Inputs
3. Data Outputs
4. Data Stores

Aha, Datenobjekte sind nun offenbar etwas anderes wie Daten Inputs oder Outputs, ganz zu schweigen davon, dass es nun offenbar auch noch Datenbanken gibt. Nun, dass muss genauer erklärt werden.

Zuerst einmal fällt auf, dass wir Datenobjekte wie im BPMN 1.2 nicht mehr mit einfachen oder gerichteten Assoziationen verbinden können, macht Validierungsfehler. Also muss ich eine gerichtete Datenassoziation verwenden – das ist neu! Leuchtet aber irgendwie noch ein. Stellt sich nur die Frage, für was genau brauche ich denn nun die herkömmliche Assoziation noch? Antwort: zum Verbinden von Artefakten (der 5ten Elementkategorie), um genau zu sein von Text-Annotationen und nicht zu vergessen, zum Verbinden der Kompensations-Aktivität (welche natürlich nicht zu den Artefakten gehört). So weit so gut, zurück zur Ursprungsfrage: Wir verbinden „Data“ mit Daten-Assoziationen. Weiter haben wir 3 Elemente, die quasi gleich aussehen und sich nur durch die Markers unterscheiden:

Das spezielle an den „neuen“ Datenobjekten ist nun, dass man sie gar nicht sehen kann, also die Objekte einfach nur im Speicher irgendwo existieren. Was im Diagramm sichtbar ist, sind Referenzen, welche auf ein Datenobjekt „zeigen“. Objekt wie Referenz sind eigene BPMN Elemente und verfügen über ihre XML Beschreibung. Die korrekte Benützung dieser Objekte sollte demzufolge durch das Modellierungswerkzeug unterstützt werden. Nachfolgendes Bild zweigt drei Referenzen, welche auf ein Datenobjekt zeigen. Das Datenobjekt ist nicht sichtbar auf der Zeichnung, befindet sich irgendwo Speicher und ist als sogenannte „Workflow Data“ verfügbar.

Dies bringt nun noch das Thema hoch. Was sind „Workflow Data“ und wie ist ihr Geltungsbereich? Nun „Workflow Data“ sind im Prinzip Instanz-Daten des gerade ablaufenden Prozesses (oder Unterprozesses). Demzufolge ist der Sichtbereich von Instanz-Daten auf die gerade ausgeführte Prozess-Ebene und deren Kinder beschränkt. Nachfolgendes Bild verdeutlicht den Sichtbarkeitsbereich von Datenobjekt „Kundendaten“ und „Bestellung“:

Die „Kundendaten“ sind sowohl auf dem Top-Level wie in den Unterpressen sichtbar, weil das korrespondierende Datenobjekt im Top-Level angelegt wurde. Die Bestellung allerdings ist für den Unterprozess „Express ausführen“ nicht sichtbar, weil das korrespondierende Datenobjekt im Unterprozess angelegt wurde.

Das BPMN2 XML für das Datenobjekt „DO_Kundendaten“ in BPMN2 XML ausgedrückt:

XML Source: Datenobjekt “DO_Kundendaten”

<dataObjectReference
id=“_c7613ba0-06e1-4cc9-86e0-45e370b0a56e“
name=“Kundendaten“
dataObjectRef=“_f6f8c7cb-3847-40aa-a4f3-9473874d30b1„>
<extensionElements>
<itp:systemDefinedAttributes
xmlns:itp=“www.itp-commerce.com/BPMN2.0„>
<attribute name=“Hyperlinks“ type=“String“ value=“0 Hyperlinks“ />
<attribute name=“ExternalId“ type=“String“ />
</itp:systemDefinedAttributes>
<itp:localization xmlns:itp=“www.itp-commerce.com/BPMN2.0„>
<itp:label lang=“unspecified“ text=“Kundendaten“ default=“True“ />
</itp:localization>
</extensionElements>
<dataState name=“APPROVED“ />
</dataObjectReference>

XML Source: DatenobjektRefern “ Kundendaten”

Die Verbindung zwischen den Elementen ist über die Referenzierung (grau hinterlegt) durch die Datenobjekt-Referenz.

Wie man nun erkennen kann, gibt es einen Grund dafür, dass die Referenzen als eigenständige „Objekte“ auf dem Diagramm eingezeichnet werden. Die DO-Referenz „Kundendaten“ im Unterprozess hat einen anderen Status (DataState) wie die Referenz im Vaterprozess.

Weiter zeigt der obige Ausschnitt nur einen Teil der Informationen, welche für eine Prozessausführung relevant wäre. In der Tat können zur Automatisierung noch weitere Felder in der XML-Beschreibung dazukommen (siehe dazu die Spezifikation Fig. 10.51 und das BPMN 2.0 XML Schema). Für die Instanziierung und den „Cleanup“ der Datenobjekte ist letztlich bei einer Prozessausführung die Infrastruktur zuständig (sogenannte Process Engine).

Es zeigt sich, wie wertvoll eine korrekte Werkzeugunterstützung für die Datenobjekte sein kann. Wir entschliessen uns als Beispiel, die Kundendaten als Liste mit Kundeneinträgen zu definieren. Dies ist eine Eigenschaft des Datenobjektes, also nicht der verschiedenen Datenobjekt-Referenzen. Das Werkzeug Process Modeler for Microsoft Visio (–> http://www.itp-commerce.com) erlaubt es nun, die Eigenschaft für das Objekt an einer Stelle zu modifizieren, so dass alle Referenzen diese Eigenschaft anzeigen können. Der Ausschnitt würdedann wie folgt aussehen:

Was nun aber nochmals ein Staunen auslöst, ist der Umstand, dass die BPMN 2.0 sogenannte Daten Ein- und Ausgaben als eigenständige Elemente definiert. Sind das nun keine Datenobjekte oder Datenobjekt-Referenzen? Nein, sind sie nicht. Was sind sie dann? Und wozu kann man sie gebrauchen?

DataInput und DataOutput ist ein Element, welches die „Datenschnittstelle“ an der Prozess-, Unterprozess oder Aktivitäts-Grenze beschreibt. Nehmen wir also an, ein Aufruf Aktivität vom Typ Unterprozess  ruft einen Prozess auf, kann die Datenschnittstelle für die Eingangsdaten beim Prozessstart oder bei einer Aktivität mit einem DataInput beschrieben werden.

Das Interessante an dieser Situation ist nun, wie die BPMN die Umsetzung in XML vorsieht. Zunächst einmal wird der DataInput in der Aktivität gespeichert, auf welche er zeigt. Das bedeutet, dass der DataInput (und Output) eigentlich nur im Zusammenhang mit einer Aktivität oder eines Ereignisses in XML serialisiert werden kann.

Weiter ist bemerkenswert, dass es zwischen dem Datenobjekt „Bestellung“ bei der Aufruf-Aktivität und dem DataInout „Bestellung“ keine offensichtlich direkte Beziehung gibt. Es bleibt also der Prozessausführungsumgebung überlassen, wie diese Daten „zusammengebracht“ werden können.

Das vierte Elemente der ‚Data‘-Gruppe ist der Datenspeicher. Datenspeicher sind ebenfalls neu seit  der Version 2.0 der BPMN. Gemeint sind damit Daten, welche dauerhaft gespeichert sind und die Prozessinstanz überdauern. Das bedeutet, dass Datenspeicher jederzeit global zur Verfügung stehen. Wie bei den Datenobjekten sind die Formen, welche auf dem Diagramm modelliert werden letztlich nur Referenzen auf einen konkreten Datenspeicher.

Datenspeicher können durch ihre Dauerhaftigkeit helfen, bestimmte Steuerinformationen in Prozesskollaborationen zur Verfügung zu stellen. So kann in folgendem Beispiel die Bestellverarbeitung dazu genützt werden, den Status der Bestellung in die „Order-DB“ zu stellen und dem Aufrufer-Prozess anzuzeigen, dass die Bestellung ausgeführt wurde. Natürlich kann man dies auch mit den klassischen Zwischenereignissen modellieren.