Basis-Daten (Workflows)
(1) Der Name des Workflows (also der Workflow-Definition).
(2) Wenn diese Option gesetzt ist, dann wird der Workflow auch im Zusatzmodul DataCockpit angezeigt und kann dort gestartet werden.
(3) Dem Workflow können Dateien zugeordnet werden. Siehe auch Abschnitt Rechte für Workflow-Dateien.
(4) Diese _data-Benutzer (Anmeldename) und DataCockpit-Benutzer dürfen Jobs für diesen Workflow starten.
(5) Es können entweder beliebig viele Workflow-Jobs dieses Workflows gleichzeitig laufen oder nur einer. Läuft bereits ein Workflow-Job und es ist nur einer erlaubt, dann kann kein weiterer Workflow-Job gestartet werden. Der Versuch wird dann entweder ignoriert oder er erzeugt einen Fehler (je nach Einstellung hier).
(6) Ist diese Checkbox gesetzt, dann können Jobs dieses Workflows per REST (HTTP-Methode GET) gesteuert werden. Logs für Anfragen dieser Art finden Sie in den Server-Logs unter internal/message.log. Hinweis: Siehe allgemein auch den Abschnitt System-Interaktion per HTTP (REST API).
Den <URL-Schlüssel> finden Sie unterhalb von (6), den <Display-Namen> können Sie frei vergeben (später ist dieser zu finden in der Workflow-System-Variable VAR_SYS_WF_DISPLAYNAME).
Den <Workflow-Job-Link> finden Sie über das Control Center → Jobs → Workflows → Kontextmenü des Workflow-Jobs → Aktuelle Informationen → Workflow-System-Variable VAR_SYS_WF_LINK, bzw. in der Response des create-Aufrufs (→ id).
|
Methode |
Beschreibung |
||
|
create |
Starten eines Jobs für diesen Workflow.
Beispiel: https://localhost/dw/wf/v1/create/V0YtLTI4NDAyMTExMw?display=MyWorkflow_1 |
||
|
kill |
Beendet den Workflow-Job. Es wird keine finale Aktion ausgeführt.
|
||
|
dump |
Liefert Informationen zum Workflow-Job zurück (Name, Zustand, _data-/DataCockpit-Benutzer-Liste für Zustand, Workflow-Variablen, usw.).
|
||
|
action |
Geht in die Prüfung einer speziellen Transition. Damit dies einen Effekt hat, muss der Workflow-Job aktuell auch in dem Zustand sein, von dem diese Transition ausgeht.
Alternativ kann in die automatische Transitionsprüfung gegangen werden, d. h. es werden alle Transitionen des aktuellen Zustands des Workflow-Jobs überprüft. Dazu muss aber die Option Nächste Transition automatisch finden & ausführen gesetzt sein im aktuellen Zustand.
Zusätzlich können dabei mit der HTTP-Methode POST Workflow-Variablen gesetzt werden. Verwenden Sie dazu folgendes JSON-Format im Request-Body (die Request-URL bleibt gleich). { "variables": [ { "name": "VAR_DEMO", "type": "String", "value": "hello" }, { "name": "VAR_DEMO2", "type": "String", "value": "world" } ]} |
(7) Hier kann eingestellt werden, ob für einen REST-Request (6) eine Authentifizierung notwendig ist. Dafür kann ein _data-Benutzer verwendet werden. Alternativ kann hier direkt ein Benutzer und ein Passwort definiert werden. Die Authentifizierung erfolgt entweder über Basic Authentication (also im Header) oder direkt in der URL. Beispiel: https://localhost/dw/wf/v1/create/V0YtLTI4NDAyMTExMw?user=myuser&passwd=mypassword&display=MyWorkflow
Ist eine _data-Benutzer ausgewählt, dann muss dabei dessen Anmeldename und Passwort verwendet werden, zudem muss dieser _data-Benutzers eines der Benutzer-Rechte Administrator, Administration via REST, Workflow verwalten oder Workflow haben.
(8) Hier können Sie eine beliebige URL angeben, die eine Dokumentation dieses Workflows enthält. Über (9) kann diese aufgerufen werden. Über (10) können System-Konstanten in die URL eingefügt werden.
(11) Hier können Sie dem Workflow ein Bild zuordnen, das dann von allen Jobs dieses Workflows angezeigt wird. Das kann einerseits der Übersichtlichkeit dienen oder schlicht der Anpassung an Ihre Corporate Identity.
(12) Hier kann ein Backup geladen werden. Ein Backup wird immer erzeugt, wenn der Workflow gespeichert wird.
(13) Hier können Sie den Such-Index des Workflows anzeigen. Diese Werte können in der Expertensuche abgefragt werden.