3.1.11 Workflow Monitor
- Jenni Wallin
- Former user (Deleted)
The Workflow Monitor controls workflow execution and presents a detailed view of the workflow execution status.
Agent states and events can be monitored during workflow execution and the monitor also allows for dynamic updates of the configuration for certain agents by sending commands. A command can, for example, tell an agent to flush or reset data in memory. For further information about applicable commands, see the section for the relevant agent. See also Dynamic Update in 1.2 Administration and Management.
Note!
The Workflow Monitor can apply commands on only one workflow at a time, in one monitor window per workflow. The monitor functionality is not available for groups or the whole workflow configuration. The Workflow Monitor displays the active version of the workflow.
Monitoring a workflow does not imply exclusive rights to start or stop it, the workflow can be activated and deactivated by another user while monitored, or by scheduling.
Opening the Workflow Monitor
You can open the workflow monitor from either a Workflow configuration or the Execution Manager.
To open the monitor from a Workflow configuration:
- Select the workflow(s) to execute.
- Select Open Monitor from the right-click menu.
- Click Start in the Workflow Monitor to start the selected workflow(s).
You can perform steps 2 and 3 in a single operation, by selecting Run in Monitor. If you also want to enable debugging and monitor debug events for all agents in the Workflow configuration, select Debug in Monitor.
Workflow Monitor
To open the monitor from Execution Manager, see the section, The Right-Click Menu, in 6.7 Execution Manager.
Menus
The Workflow Monitor has three different menus: File, Edit and Event, which are all described in more detail below.
The File Menu
| Option | Description |
|---|---|
| Select to print the workflow. |
| Close | Select to close the Workflow Monitor. |
The Edit Menu
| Option | Description |
|---|---|
Start
| Starts the currently loaded workflow. |
Profiler
| Starts the currently loaded workflow using workflow profiling, see the section below, Workflow Profiling. |
Stop
| Stops the currently executing workflow. |
Dynamic Update
| Updates a running workflow with a new configuration that has been entered in monitor mode. Agents that support update of the configuration while running will be updated with the new configuration. Once the update has been introduced to the workflow, the user will be shown if anything was affected. Only the current executing workflow is affected by the dynamic update. See Dynamic Update in 1.2 Administration and Management. |
Toggle Debug Mode On/Off
| Turns on or off debug information for a workflow. Note that turning on the Debug mode might slow down the workflow due to log filing. |
View/Edit Workflow  | Click to open the workflow editor view. |
The Event Menu
| Option | Description |
|---|---|
Events for Selected Agents
| Monitors events for selected agents. For further information, see the section below, Viewing Agent Events. |
| Events for All Agents | Monitors events for all agents. For further information, see the section below, Viewing Agent Events. |
Workflow Profiling
When a workflow is executed using workflow profiling, 
continuously samples the load, i e the amount of processed UDRs, or raw data, per second. The average load for a workflow is calculated on a regular basis and the status for all routes and agents will be determined based on the average.
The Workflow Monitor visually shows the load status for agents and routes using symbols to indicate which agents are the slowest and which routes the data usually takes though the workflow. This way, it is possible to find bottlenecks in the workflow.
Since the load status gives an indication of slow agents and routes, this does not necessarily mean a critical problem. An Aggregation agent, for example, often has a higher load than many other agents, since this agent might access disk storage and can be configured with complex business logic.
Note!
Workflow profiling is only active when executing a workflow from the Workflow Monitor, using the Profiler button (see the section above, The Edit Menu).
When running a workflow through scheduling, see Scheduling in 3.2.2 Managing a Workflow Group, or using the Start button in Workflow Monitor, there is no profiling active.
Profiling for Agents
The following formula is used to calculate the average load for agents:
100 % / Number of agents in the workflow = Average Load
The load status is calculated based on the average load and is indicated by a colored symbol close to the agent symbol:
| Agent with Symbol | Symbol Description |
|---|---|
| Normal Load: Load is lower than Average Load x 2 |
| High Load: Load is equal to Average Load x 2 or between Average Load x 2 and Average Load x 3 |
| Very High Load: Load is equal to or higher than Average Load x 3 |
| Unknown Load: There is no known data load. This could be because the agent is a collection agent which cannot publish statistics, or there is not enough data load to be able to calculate an average. |
Profiling for Routes
The following formula is used to calculate the average load for routes:
100 % / Number of routes in the workflow = Average Load
The load status is calculated based on the average load and is shown using different thickness on the routes:
| Route symbol | Description |
|---|---|
| Normal Load: Load is lower than Average Load x 2 |
| High Load: Load is equal to Average Load x 2 or between Average Load x 2 and Average Load x 3 |
| Very High Load: Load is equal to or higher than Average Load x 3 |
| Unknown Load: There is no known data load. This could be because there is not enough data load to be able to calculate an average. |
Debug Considerations
If Debug is turned on, the profiling result might become misleading since the debugging increases the data load through agents and routes. To get a more correct result, turn off the debug capability using the option Toggle Debug Mode On/Off .
Viewing Agent Events
While a workflow is running, agents report progress in terms of events. These events can be monitored in the event area at the bottom of the window. The following steps must be taken in order to view these events.
To view events for all agents in the workflow, select from the menu.
To only view events for some selected agents, click each agent while holding down the <Ctrl> key on the keyboard.
Select from the menu.
If required, rearrange the size and position of each column.
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:
The workflow state diagram
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:
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 | ||||||
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:
| ||||||
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. For further information see Execution Context in Desktop User's Guide. | ||||||
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. For further information see Scheduling. |
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.
In a batch workflow, a detected error causes the workflow to abort and the detected error will be shown as part of the abort reason and inserted into the System Log. A real-time workflow handles errors by only sending them to the System Log. The only time a real-time workflow will abort is when an internal error has occurred. It is therefore important to pay attention to the System Log or subscribe to workflow error events to fully understand the state of a real-time workflow.
Note!
Although a workflow has aborted, its scheduling will still be valid. Thus, if it is scheduled to execute periodically, it will be automatically started again the next time it is due to commence. This is because the abortion might be a lost connection to a network element, which could be available again later. Therefore, a periodically scheduled workflow, which has aborted, is treated as Active until it is manually deactivated.
Status details for an aborted agent
Click Show Trace; the Stack Trace Viewer opens. Use the information that it provides when consulting 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
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 9.6 Analysis Agent.
Real-time agents only have three different execution states, that will occur at every execution of the workflow.
Execution flow for real-time agents
The batch agents are more complex and contain additional states in order to guarantee transaction safety.
Execution flow for batch agents
State | Description |
|---|---|
| The |
| This state is only applicable for batch workflows. At every start of a new batch, the batch collection agent will emit a |
| The agents will handle all incoming UDRs or bytearrays during the |
| This state is only applicable for batch workflows. When all UDRs within a batch have been executed, the agents enter the |
| This state is only applicable for batch workflows. The collection agent will call for the |
| This state is only applicable for batch workflows. Once the batch is successfully processed or sent to ECS, the |
| This is the last execution state for each workflow invocation. The agents clean and release resources, such as memory and ports, and stop execution. |
| This state is only applicable for batch workflows. If an agent fails the processing of a batch it may emit a Note! The execution states |
| This state is only applicable for batch workflows. If the last execution of the workflow aborted, the agents will enter the |
Agent Configuration
Some agents allows parts of them to be reconfigured while active. When double-clicking the agent in monitor mode, the agent's configuration is shown in the displayed dialog if the agent can be reconfigured. When the configuration has been updated it can be committed to the active workflow using the Dynamic Update button in the toolbar.
Transactions
A workflow operates on a data stream and supplies a transaction model where persistent synchronization is made from the workflow data and agent-specific counters. In theory the synchronization could be performed continuously on a byte level, but in practice this would drastically decrease the performance of the system.
The transaction model is based on the premises that collection agents are free to initiate a transaction to the transaction server. At the moment the complete workflow is frozen and the transaction server saves the state of the workflow data that is queued for each agent. In practice, agents indirectly emit a transaction when an End Batch is propagated. When all data is secured, the workflow continues the execution.