Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Excerpt

The Workflow Monitor controls workflow execution and presents a detailed view of the workflow execution status. 

...

Note
titleNote!

The Workflow Monitor can apply commands on to 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.

...

To open the monitor from a workflow configuration:

  1. Click on the  (Run) button 
  2. From the Run Workflow dialog, Select the workflow you want to view in the workflow monitor.
  3. Click the Run button to open the selected workflow in the workflow monitor. The workflow will only run once you click on the Start button in the workflow monitor.

...

Workflow Monitor

To open the monitor from from the Execution Manager, see the section , The Right-Click Menu, in in the Execution Manager.

Anchor
Viewing_Agent_Events
Viewing_Agent_Events
Viewing Agent Events

While a workflow is running, agents report progress in terms of events. These events can be monitored in the two Agent debug panels at the bottom. You can also Enable Debug to view more events or messages from the debug command in the Analysis or Aggregation agents.

Note
titleNote!

When you Enable Debug, it might may slow down the workflow due to log filinglogging, especially if you set it to log debug into files in the workflow properties. For more regarding debug in workflow properties, refer to Debug Type in the Execution Tab.

...

  • To view events for all agents in the workflow, click Select All from either of the Agent debug panels.
  • To only view events for some selected agents, click on Select agent(s) to monitor event from either of the Agent debug panels and select only the agents you want to view events for.

...


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 the Building state.

When a workflow is in the Building state, in the worklow monitor, the text "Workflow is building will " is 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:


Running:

A successful execution has been is 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 user stopped the execution.


Note
titleNote!
This is a transient state, after the workflow has run, where cleanup is handled. This state is not reached if the workflow gets is aborted. In the GUI, the workflow is shown as Stopped even after it has reached the idle 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 Hold Execution , enters - 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 the 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 idleIdle, the state space on the display might may remain as one of the following states:

AbortedAt 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.
CompletedThe workflow has executed and gone back to the Idle state with no errors.
Not startedThe 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
titleNote!

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 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 changes 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


...

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 can be used in each state, see Analysis Agent.

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 emits 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 differs 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 calls for the endBatch state when all UDRs or the byte arrays have been are 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 the ECS, 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  defines how the workflow should act. For more information regarding the Workflow Properties, see Error Tab in Workflow Properties.

Note
titleNote!

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.


Viewing Abort Reasons

In most cases if a workflow has aborted, one of its agents will have has a red square outline surrounding it. Double-clicking such an agent will display displays the Agent Status dialog containing with 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 is 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 aborts 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
titleNote!

Although a workflow has aborted, its scheduling will is still be valid. Thus, if it is scheduled to execute periodically, it will be is 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 may be available again later. Therefore, a periodically scheduled workflow, which has aborted, is treated as Active until it is manually deactivated.

...


StateDescription

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 workflowworkflows.

Running

The agent has received data and is executing. For agents that are running, there will be is a green square outline surrounding the agentsthem.

Stopped

The agent has successfully finished processing data.

Aborted

The agent has terminated erroneously. For an agent that has is aborted, there will be is a red square outline surrounding the aborted agent.

The error reason can be tracked either by double-clicking the agent or by examining the System Log.


Agent Configuration

Some agents allows allow 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.

Anchor
DynamicUpdate
DynamicUpdate
Dynamic Update

...

Example of the TCP/IP configuration in a running Realtime workflow.

To be able to dynamically update TCP/IP Host and Port parameters, you need to set them to either Default or Per Workflow in the Workflow Properties dialog box. See the figure The Workflow Table Tab in Workflow Table Tab.

To update, click on Dynamic Update. On the bottom left of the workflow monitor, the text Dynamic Update followed by a number appears. It represents the number of times that you have updated the workflow configuration while running it, that is, since the last time you started it.

...

Example of a dynamic update status after clicking on the Dynamic Update button.

Anchor
Transactions
Transactions
Transactions

...