usage: wfstart <pattern match expression for workflow names>... [-w <timeout s>] [-b]
This command executes one or more workflows.
Note!
If the workflow(s) is/are in building state when running the wfstart
command, "Configuration is building." will be displayed and the workflow(s) will not start unless you have used any of the -w or -b options described below.
With this command you compare a single pattern match expression, or several, with the full workflow name, <folder>.<workflowconfigurationname>.<workflowname>
, of all the workflows.
The command accepts standard wild cards, such as '*' and '?'. For further information see 3. Textual Pattern Matches.
Example - Activate all workflows in the folder myFolder starting with the letter D.
MZ>> mzsh wfstart myFolder.D*
Only workflows in Idle
or Waiting
state will be started. If the workflow is in another state, an error message will be shown stating why it did not start.
Option | Description |
---|---|
[-w] | Use this option to wait for workflow completion, that is wait for whichever comes first of either a timeout or received exit code declaring the status of the workflow; completed, aborted etc. For further information about exit codes, see Appendix 1 . If the workflow is in building state, "Configuration is building." will be displayed, and the workflow will not be started until finished building. A timeout may then occur if the building takes too long. Note! The [-w] option does only allow one workflow to be started at the time. |
[-b] | Use this option (block) to wait for the return code that indicates that workflow has for example completed, aborted or another code. For further information about exit codes, see Appendix 1 . If the workflow is in building state, "Configuration is building." will be displayed, and the workflow will not be started until finished building. Note! The [-b] option only allows one workflow to be started at the time. The [-w] option has precedence over the [-b] option. If both are used at the same time the [-w] will be active. |
Note!
If the connection to the Platform is down the mzsh
command will continue to run. The command will however not receive any exit codes until the Platform is up again. Timeouts will still occur. If the workflow is aborted or finished while the Platform was down, the correct exit code will be returned as soon as the Platform is up again.
If a connection problem with the EC occurs during the workflow execution causing the workflow to become unreachable the mzsh
command will wait for the workflow to either complete or abort. If workflows do not reconnect and are automatically reachable again the workflow must be handled manually. The standard alarm functionality can be used to detect unreachable workflows.
Return Codes
Listed below are the different return codes for the wfstart
command:
Code | Description |
---|---|
0 | Will be returned if the command was successful. |
50 | Will be returned if the argument count is incorrect. |
51 | Will be returned if the argument parse fails. |
70 | Will be returned if the workflow is not found.* |
80 | Will be returned if no user is logged in. |
90 | Will be returned if an unexpected error occurred. |
230 | Will be returned if the workflow is already running. |
231 | Will be returned if permission is denied (no execute permission). |
232 | Will be returned if the workflow does not exist.* |
240 | Will be returned if the workflow is invalid |
* The difference between return code 70 and 232 is that 70 is returned if a workflow is not found during validation of parameters, and 232 is returned if a workflow is not found when trying to start the workflow. In theory, the workflow could be deleted during the extremely short time between the validation and the start, but in practice it will happen very rarely.