Main Settings (Workflows)
(1) The name of the workflow (i.e. the workflow definition).
(2) If this option is set, the workflow is also displayed and can be started in the add-on module DataCockpit.
(3) Files can be assigned to the workflow. See also section Rights for Workflow Files.
(4) These _data users (login name) and DataCockpit users are allowed to start jobs for this workflow.
(5) Either any number of workflow jobs of this workflow can run simultaneously or only one. If a workflow job is already running and only one is allowed, no further workflow job can be started. The attempt is then either ignored or it generates an error (depending on this setting).
(6) If this checkbox is set, jobs of this workflow can be controlled via REST (HTTP method GET). Logs for requests of this kind can be found in the Server Logs under internal/message.log. Note: See also section System Interaction via HTTP (REST API).
The <URL key> can be found below (6), the <Display name> can be assigned freely (later it can be found in the workflow system variable VAR_SYS_WF_DISPLAYNAME).
The <Workflow job link> can be found in the Control Center → Jobs → Workflows → Context menu of the workflow job → Current information → Workflow system variable VAR_SYS_WF_LINK, or in the response of the create call (→ id).
|
Method |
Description |
||
|
create |
Starts a job for this workflow.
Example: https://localhost/dw/wf/v1/create/V0YtLTI4NDAyMTExMw?display=MyWorkflow_1 |
||
|
kill |
Ends the workflow job. A final action is not executed.
|
||
|
dump |
Returns information about the workflow job (name, state, _data-/DataCockpit user list for state, workflow variables, etc.).
|
||
|
action |
Checks a specific transition. For this to have an effect, the workflow job must currently be in the state from which this transition originates.
Alternatively, you can trigger the automatic transition check, i.e. all transitions of the current state of the workflow job are checked. This requires the option Find and execute next transition automatically to be set in the current state.
In addition, workflow variables can be set using the HTTP method POST. Use the following JSON format in the request body (the request URL remains the same). { "variables": [ { "name": "VAR_DEMO", "type": "String", "value": "hello" }, { "name": "VAR_DEMO2", "type": "String", "value": "world" } ]} |
(7) Here you can set whether authentication is required for a REST request (6). A _data user can be used for this. Alternatively, a user and password can be defined here directly. Authentication is done either via Basic Authentication (i.e. in the header) or directly in the URL. Example: https://localhost/dw/wf/v1/create/V0YtLTI4NDAyMTExMw?user=myuser&passwd=mypassword&display=MyWorkflow
If a _data user is selected, its login name and password must be used. In addition this _data user must have one of the user rights Administrator, Administration via REST, Workflow administration or Workflow.
(8) You can specify any URL that contains a documentation of this workflow, which can be called via (9). You can use (10) to insert system constants into the URL.
(11) If you you assign an image, it will be displayed by all jobs of this workflow. On the one hand, this can serve visual clarity or simply the adaptation to your corporate identity.
(12) A backup can be loaded here. A backup is always created when the workflow is saved.
(13) Here you can display the search index of the workflow. These values can be queried in the expert search.