00196840-01_IM_EDM_1.9_DE.pdf - 第47页
Installations anleitung SIPLACE Engin eering Data Manager ( EDM) Version 1.9 Ausgabe 0 2/2011 47 5.3 Konfiguration des Workf lows Der Produktion sprozess w ird v on Kunde zu Kunde s ehr unterschiedlic h ausgestaltet und …
Installationsanleitung SIPLACE Engineering Data Manager (EDM) Version 1.9 Ausgabe 02/2011
46
t
ClearCommentAfterDataTransfer false Datentransfer
-Manager
Legt fest, ob nach dem Push das Kommentarfenster
gelöscht wird.
ClearDisplayNameAfterDataTransfer false Datentransfer
-Manager
Legt fest, ob nach dem Push der Anzeigename
gelöscht wird.
ClearLineSelectionAfterDataTransfer false Datentransfer
-Manager
Legt fest, ob nach dem Push die Auswahl der Linien
zurückgesetzt wird.
ClearObjectSelectionAfterDataTransfer true Datentransfer
-Manager
Legt fest, ob nach dem Push die Auswahl der Objekte
zurückgesetzt wird.
5.2.4.5.2 Parameter
Einstellung Default Gültig für Erläuterung
LineDataTransferStatusMonitor.OldEntriesThreshold 30 days Datentransfer-
Manager
Gibt an, ab welcher Zeitspanne ein Eintrag im
Status Monitor des Datentransfer-Manager als
„alt“ eingestuft (und damit durch den „Lösche alte
Einträge“-Button entfernt) wird.
History.MaxiumLength 10 Datentransfer-
Manager
Maximale Anzahl von Verlaufs-Einträgen in dem
Datentransfer-Manager
5.2.5 Konfiguration der VDM Blob-Funktionen
Für die Benutzung der VDM-Blobfunktionen müssen bei jedem Line-Server die Namen der ihm zugeordneten
SPI-Linien in seine Konfigurationsdatei eingetragen werden (siehe 5.2.3.24 Zugeordnete SPI Linien). Wird diese
Sektion leer gelassen, werden Blobs für alle Linien akzeptiert.
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: