Workflow Monitor on the Web Interface(3.0)

Workflow monitor on the web interface works like the workflow monitor on the  desktop where it allows for control of a workflow execution and presents a detailed view of the workflow execution status.

As with monitoring a workflow using  desktop, monitoring a workflow on the web interface 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.


Enabling debug may result in performance degradation when executing the workflow, especially if you have a lot of debug commands in your APL codes. Debug mode is not recommended for the production environment so be sure to disable it after you have done your testing.


File sequence

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.

  1. To view events for all agents in the workflow, click on the Select All button.

  2. To only view events for some selected agents, click on the field below Select Agents and select the agent names that you want to display in the event area. If required, you can rearrange the size and position of each column.

Error rendering macro 'excerpt-include' : User 'null' does not have permission to view the page 'DRXXE:Workflow Monitor[hide]10.3[/hide]'.

Viewing Abort Reasons

In most cases if a workflow has aborted, the State will have Aborted displayed next to it. There will be an Error button that you can click to display a dialog containing the abort reason and the stack trace. 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.


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 reason for this behavior 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.