Mehr über Daten-Input und Daten-Output

 

Die Zeichnung zeigt wie Daten aus Task A über eine Datenassoziation in das Datenobjekt „WData“ fliessen um dann wieder mittels Datenassoziation von Task B eingelesen werden. Da die Daten aus Task A HINAUS fliessen, ist das eine Daten-OUTPUT-Assoziation, bei Task B fliessen sie HINEIN, also ein Daten-INPUT-Assoziation. Soweit nichts Aufregendes bis jetzt. Aber es wird spannend, wenn man sich folgendes überlegt: obwohl beide Assoziationen grafisch ausserhalb der Tasks gezeichnet werden, sind sie in Wirklichkeit Elemente des Tasks, d.h. Kind-Elemente des jeweiligen angehängten Tasks. Weiter ist es so, dass obwohl die Tasks bildlich als Quelle bzw. Ziel der Assoziationen erscheinen, dies nicht wirklich der Fall ist. Gemäss BPMN Regeln können Daten-Assoziationen nur Daten-Objekte verbinden.

Im Task A braucht es deshalb nun ein zusätzliches Element vom Typ „Daten-Output“, das für die eigentlichen Daten steht. Somit ist die Quelle der Daten-Output-Assoziation also eigentlich das Daten-Output-Element, das sich ebenfalls innerhalb des Tasks (als Kind-Element) befindet. Analog dazu, enthält Task B ein Daten-Input-Element, das die einfliessenden Daten repräsentiert. Dieses Element ist das Ziel der Daten-Input-Assoziation, die visuell mit Task B verbunden ist.

Die XML Repräsentation von Task A dokumentiert dies:

<task id=“_77fc4d8e-0828-4ef6-9a51-47b768f907ee“ name=“A“>
<ioSpecification>
          <dataOutput id=“_46d1f813-f68a-46ff-b584-d4d82f86a3d7″>
</dataOutput>
          <inputSet />
<outputSet>
<dataOutputRefs>
_46d1f813-f68a-46ff-b584-d4d82f86a3d7</dataOutputRefs>
</outputSet>
</ioSpecification>
<dataOutputAssociation id=“_ff64b8da-2f1c-4b12-9403-8ee5e7c251e2″>
<sourceRef>_46d1f813-f68a-46ff-b584-d4d82f86a3d7</sourceRef>
<targetRef>_c765114b-9ce5-4f4b-be94-fd709da2a167</targetRef>
</dataOutputAssociation>
</task>