00196455-02_IM_EDM_1.7SP1_de.pdf - 第48页
Installationsanleitung SIPLACE EDM 1.7 Service Pack 1 SP 1 Ausgabe 10/2009 Sie bestimmen die Reaktion auf eingehende Ereigni sse. Jede Transition kann dabei durch ihre Auslösung eine beliebige Anzahl so genannter Actions…
Installationsanleitung SIPLACE EDM 1.7 Service Pack 1SP 1 Ausgabe 10/2009
Client Workflow-Konfiguration). Dabei handelt es sich um eine Datei im XML-Format. Auf den Inhalt
dieser Datei und den Bezug zur Theorie will ich im Folgenden eingehen.
Am Anfang ist es zunächst notwendig, alle Zustände, Ereignisse und Transitionen zu deklarieren
Dies ist notwendig, damit die Workflowengine, die auf der Konfigurationsdatei arbeitet, den
Automaten leichter verifizieren kann.
Wir definieren zunächst den Startzustand:
<state name="clientIdle" isStartState="true" />
In den nun folgenden Zustandsdeklarationen darf nun isStartState=“true“ nicht mehr auftauchen, da
ein Automat ja genau einen Startzustand besitzt.
Ein „normaler“ Zustand wird deklariert:
<state name="selectObjects" />
Will man einen Zustand als Endzustand markieren:
<state name="done" isEndState="true" />
Fehlerzustände werden wie folgt gekennzeichnet:
<state name="timedOut" isErrorState="true" />
Ein Zustand kann gleichzeitig sowohl Fehler- als auch Endzustand sein:
<state name="failed" isErrorState="true" isEndState="true" />
Die Namen der Zustände müssen eindeutig sein. Als nächstes folgt in der Konfigurationsdatei die
Deklaration der Ereignisse, auf die die Workflowengine reagieren kann:
<event name="pullData" />
Die Namen der Ereignisse müssen ebenfalls eindeutig sein, da diese wie die Zustände bei der
Definition der Transitionen referenziert werden.
Die Transitionen stellen das Herzstück der Workflowdefinition dar. Sie stellen eine Art „Legostein“
dar, aus denen ein Kundenworkflow zusammengesetzt werden kann.
47 von 68
Installationsanleitung SIPLACE EDM 1.7 Service Pack 1 SP 1 Ausgabe 10/2009
Sie bestimmen die Reaktion auf eingehende Ereignisse. Jede Transition kann dabei durch ihre
Auslösung eine beliebige Anzahl so genannter Actions ausführen. Um ein gewisses Maß an
Kontrollfluss zu ermöglichen kann eine Transition mit einer speziellen Action versehen werden, die
einen Rückgabewert besitzt. Solche Actions heißen Controller. Dann wird aus Ausgangszustand,
Ereignis und Ergebnis der Action der Folgezustand ermittelt. Am Beispiel sieht das so aus:
<transition name="getTemplateList" currentState="clientIdle" event="pullData">
<newState name="waitTemplateList">
<action
class="Siemens.SiplacePro.EDM.DataExchange.Actions.AcquireT
emplateListAction,DataExchange
" />
<action
class="Siemens.SiplacePro.EDM.DataExchange.Actions.SendReq
uestAction,DataExchange
" />
</newState>
</transition>
Abbildung 12 Beispiel einer einfachen Transition
Diese Transition geht vom Zustand clientIdle in den Zustand waitTemplateList über, wenn das
Ereignis pullData ausgelöst wird. Beim Übergang werden zwei Aktionen ausgeführt, die jeweils in
der bereits aus der Applikationskonfiguration bekannten Notation für Klassen angegeben werden.
Die Aktionen werden in der Reihenfolge ihres Auftretens in der Datei ausgeführt.
<transition name="selectTemplate" currentState="waitTemplateList"
event
="templateList"
class
="Siemens.SiplacePro.EDM.DataExchange.Actions.AskForTemplateAct
ion,DataExchange
">
<newState name="waitTemplate" value="OK">
<action
class
="Siemens.SiplacePro.EDM.DataExchange.Actions.AcquireT
emplateAction,DataExchange
" />
<action
class
="Siemens.SiplacePro.EDM.DataExchange.Actions.SendReq
uestAction,DataExchange
" />
</newState>
<newState name="canceled" value="Cancel" />
48 von 68
Installationsanleitung SIPLACE EDM 1.7 Service Pack 1SP 1 Ausgabe 10/2009
</transition>
Abbildung 13 Beispiel einer bedingten Transition
Diese Transition führt den Zustandsübergang unter Berücksichtigung eines Controllers aus. Diese
spezielle Aktion wird über das Attribut „class“ in der Notation für Klassen angegeben. In diesem Fall
existiert nicht nur wie im ersten Beispiel in
Abbildung 12 ein „newState“-Tag, sondern für jedes
mögliche Ergebnis des Controllers eines. Um dies handhaben zu können, wird das „newState“-Tag
um ein Attribut „value“ erweitert. Ein Controller liefert immer einen Zeichenkettenwert zurück, so
dass das Ergebnis auf jeden Fall in der XML-Datei darstellbar ist.
Um Anwendungsfälle, wie das Auftreten von für alle Zustände gültigen Fehlerzustände – wie Sie in
EDM durch die asynchrone Kommunikation in Form von Timeouts auftreten – für den Ersteller der
Workflowkonfiguration leichter handhaben zu können, besteht die Möglichkeit Transitionen wie in
Abbildung 14 zu definieren:
<transition name="timeoutDefault" currentState="all" event="timeOut">
<newState name="timedOut" />
</transition>
Abbildung 14 Defaulttransition
Durch die Angabe von „all“ als Ausgangszustand wird diese Transition für alle Zustände
übernommen. Obige Transition definiert ergo ein allgemeines Timeoutverhalten. Eine
Defaulttransition wird nur ausgeführt, wenn für das jeweilige Ereignis keine spezifische Transition
definiert ist. Hiermit besteht implizit die Möglichkeit mehrere Transition für ein Zustands/Ereignispaar
zu definieren. Es ist jedoch nicht möglich, mehrere Defaulttransitionen für ein Ereignis zu
beschreiben.
49 von 68