00196840-01_IM_EDM_1.9_DE.pdf - 第48页
Installations anleitung SIPLACE Engin eering Data Manager ( EDM) Version 1.9 Ausgabe 0 2/2011 48 Client W orkflow-Konfiguration ). Dabei handelt es sich um eine Da tei im XML-Form at. Auf den Inhalt dieser Datei und den …
Installationsanleitung SIPLACE Engineering Data Manager (EDM) Version 1.9 Ausgabe 02/2011
47
5.3 Konfiguration des Workflows
Der Produktionsprozess wird von Kunde zu Kunde sehr unterschiedlich ausgestaltet und damit variiert
auch der Prozess der Datenhaltung. Dabei treten zwei Aspekte besonders deutlich hervor:
• Der eigentliche Prozess des Datenflusses – der dynamische Anteil – zwischen dem zentralen Server
(EDM Master-Server) und den dezentralen Clients (EDM Linien-Server) und
• Art und Umfang der zu übertragenden Daten – der statische Teil.
Kundenprozesse können sich in einem, aber auch in beiden Teilen des Prozesses unterscheiden. Dieser
Abschnitt beschäftigt sich mit dem dynamischen Anteil, der eigentlichen Datenflusssteuerung. Auf die
Konfiguration des statischen Anteils – die Application Templates – wird in 5.4.1 Application Templates
eingegangen.
HINWEIS:
Der Workflow muss nur konfiguriert werden, falls die Standardwerte in der Umgebung
nicht funktionieren.
5.3.1 Theorie …
Die Abbildung des Produktionsprozesses des Kunden wird mit Hilfe eines Zustandsautomaten in einen
Workflow abgebildet. Ein Automat ist ein Konstrukt, das aus der theoretischen Informatik kommt. Zum
Verständnis der folgenden Punkte ist es von Nutzen, einige Begriffe zu kennen.
Ein Zustandautomat besteht im Allgemeinen aus:
• Einer Menge von Zuständen. Im folgenden Q genannt
• Genau einem zu Q zugehörigen Startzustand.
• Eine Teilmenge von Q, die die gültigen Endzustände enthält.
• Eine Teilmenge von Q, die Fehlerzustände enthält.
• Einer Menge von Ereignissen
1
• Eine Menge von Zustandsübergängen – Transitionen – die von einem Zustand q
1
bei Eintreten eines
bestimmten Ereignisses in einen Zustand q
2
übergeht. Pro Zustands-Ereignis-Paar kann höchstens
eine Transition definiert sein.
5.3.2 … und Praxis
5.3.2.1 Syntax und Möglichkeiten
Die Theorie des vorigen Abschnittes muss jetzt in einer praktisch handhabbaren Form umgesetzt werden.
Dies geschieht in der Client Workflowkonfigurationsdatei (vgl. auch 5.2.3.21
1
Diese Menge von Ereignissen wird in der Theoretischen Informatik „Eingabealphabet“ genannt. Dies nur für die
Interessierten.
Installationsanleitung SIPLACE Engineering Data Manager (EDM) Version 1.9 Ausgabe 02/2011
48
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.
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:
Installationsanleitung SIPLACE Engineering Data Manager (EDM) Version 1.9 Ausgabe 02/2011
49
<transition name="getTemplateList" currentState="clientIdle" event="pullData">
<newState name="waitTemplateList">
<action
class="Siemens.SiplacePro.EDM.DataExchange.Actions.AcquireTempl
ateListAction,DataExchange" />
<action
class="Siemens.SiplacePro.EDM.DataExchange.Actions.SendRequestA
ction,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.AskForTemplateAction,D
ataExchange">
<newState name="waitTemplate" value="OK">
<action
class="Siemens.SiplacePro.EDM.DataExchange.Actions.AcquireTempl
ateAction,DataExchange" />
<action
class="Siemens.SiplacePro.EDM.DataExchange.Actions.SendRequestA
ction,DataExchange" />
</newState>
<newState name="canceled" value="Cancel" />
</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.