Both workflows and agents can be in various states, as listed in this section.
Workflow States
All running workflows are monitored by the workflow server on the Platform. A workflow can be in any one of the following states:
...
Excerpt |
---|
All running workflows are monitored by the workflow server on the Platform. A workflow can be in any one of the following states: State | Description | Building | When a workflow, or any of a workflow's referenced configurations, are being re-built, for example when saving or recompiling, the workflow will be in Building state. When a workflow is in Building state, the Configuration Monitor icon in the status bar will indicate that operations are in progress, and in the Worklow Monitor, the text Workflow is building will also be displayed. Workflows started by scheduling configurations will wait until the workflow leaves the Building state before they start. | Executed | A Workflow becomes Executed after one of the following: State | Description |
---|
Running | A successful execution has been completed. | Unreachable | After the Platform re-establishes connection with the Execution Context, and the workflow has finished execution during the period of disconnection. | Manual stop | A User stopped the execution. |
Note |
---|
| This is a transient state, after the workflow has run, where cleanup is handled. This state is not reached if the workflow gets aborted. In the GUI, the workflow is shown as Stopped even after it has reached the idle state. |
| Hold | A workflow that is in the Idle state and is being imported either by the mzsh systemimport r | sr | sir | wr or by the System Importer configured to , enters the Hold state until the import activity is finished. The Workflow group then resumes its Idle state. | Idle | A workflow is in Idle state if there is no activity going on in the workflow. It means that workflow is not running, or, not in process of starting or stopping or not in any other state (Invalid or Hold). After execution, although the workflow is indeed idle, the state space on the display might remain as one of the following states: State | Description |
---|
Aborted | At least one of the workflow agents has aborted. You can track the reason for the error either by double-clicking the aborted agent, or by examining the System Log. | Completed | The workflow has executed and gone back to the Idle state with no errors. | Not started | The workflow has not run since the platform has started. |
| Invalid | The workflow configuration is erroneous. Once you correct the error, the workflow assumes the Idle state. Note |
---|
| The workflow cannot be executed if it is in invalid state. |
| Loading | The platform is uploading the workflow to the Execution Context. When the transfer is complete, the Execution Context initializes the agents. When the workflow starts running the state changes to Running. | Running | The workflow is currently executing. | Unreachable | If the Platform fails to establish connection with the EC where a workflow is executing, the workflow enters the unreachable state. When the workflow server successfully reestablishes the connection, the workflow is marked as Running, Aborted, or Executed, depending on the state that the workflow is in. An Unreachable workflow may require manual intervention if the workflow is not running any more. | Waiting | The Waiting state applies only to workflows that are included as members in a workflow group. In the Waiting state, the workflow cannot start execution due to two parameters in the workflow group configuration: The Startup Delay parameter, and the Max Simultaneous Running quota. A workflow in the Waiting state will change to Running when triggered either by a user, the scheduling criteria of its parent workflow group, or by a more distant ancestor's scheduling criteria. |
|
Viewing Abort Reasons
In most cases if a workflow has aborted, one of its agents will have the state Aborted displayed above it. Double-clicking such an agent will display a dialog containing the abort reason. The System Log also holds valid information for these cases.
...
Click Show Trace; the Stack Trace Viewer opens. Use the information that it provides when consulting Global consulting Usage Engine Global Support.
Agent States
An agent state is displayed above the agent icon in the workflow. An agent can have one of the following states:
...
State | Description |
---|
Created | The agent is starting up. No data may be received during this phase. This state only exists for a short while during workflow startup. |
Idle | The agent is started, awaiting data to process. This state is not available for a real-time workflow. |
Running | The agent has received data and is executing. |
Stopped | The agent has successfully finished processing data. |
Aborted | The agent has terminated erroneously. The error reason can be tracked either by double-clicking the agent or by examining the System Log. |
Workflow Execution State
Anchor |
---|
| WF_execution_state |
---|
| WF_execution_state |
---|
|
The workflow execution state provides granular information about a workflow's current execution status. In APL, there are function blocks that are called for each workflow execution state. For more information about which APL functions that may be used in each state, see Analysis (2.3) .
Real-time agents only have three different execution states, that will occur at every execution of the workflow.
...
State | Description |
---|
initialize
| The initialize state is entered once for each invocation of the workflow. During this phase the workflow is being instantiated and all agents are set up according to their configuration. |
beginBatch
| This state is only applicable for batch workflows. At every start of a new batch, the batch collection agent will emit a beginBatch call. All agents will then prepare for a new batch. This is normally done every time a new file is collected, but can differ depending on the collection agent. |
consume
| The agents will handle all incoming UDRs or bytearrays during the consume state. |
drain
| This state is only applicable for batch workflows. When all UDRs within a batch have been executed, the agents enter the drain state. This state can be seen as a final consume state with the difference that there is no incoming UDR or bytearray. The agent may however send additional information before the endBatch state. |
endBatch
| This state is only applicable for batch workflows. The collection agent will call for the endBatch state when all UDRs or the byte arrays have been transferred into the workflow. This is normally done at the file end, but is dependent on the collection agent or when a hintEndBatch call is received from any agent capable of utilizing APL code. |
commit
| This state is only applicable for batch workflows. Once the batch is successfully processed or sent to Data Veracity, the commit state is entered. During this phase, all actions that concern transaction safety are executed. |
deinitialize
| This is the last execution state for each workflow invocation. The agents clean and release resources, such as memory and ports, and stop execution. |
cancelBatch
| This state is only applicable for batch workflows. If an agent fails the processing of a batch it may emit a cancelBatch call and the setting in Workflow Properties will define how the workflow should act. For more information regarding the Workflow Properties, see Error Tab in Workflow Properties [hide](2.3[/hide]). Note |
---|
| The execution states cancelBatch and endBatch are mutually exclusive - only one per batch can be executed. |
|
rollback
| This state is only applicable for batch workflows. If the last execution of the workflow aborted, the agents will enter the rollback execution state right after the initialize state. The agents will recover the state prior to the failing transaction and then enter beginBatch or deinitialize depending on if there are additional batches to process. |
...