When a deactivation request is issued from the Execution Manager (or directly from the Workflow Monitor), different dialogs appear depending on the type of workflow to deactivate.

Some agents are designed to wait for acknowledgment from sources that they communicate with. Thus, a stop request may take a while before acknowledged. If a network element connected to a collection agent has terminated in a bad state, causing the collection agent to hang, the Execution Context on which the workflow is running must be restarted.

UDRs already in the workflow, will be processed if they can be processed within the time interval set in the Execution Context property ec.shutdown.time.

The parameter specifies the maximum time in milliseconds that the EC will wait before a real-time workflow stops after a shutdown has been initiated. This is to enable the workflow to stop all input and drain all UDRs in the workflow before stopping.

The parameter can be changed at any time, but the EC must be restarted before the changes take effect. For further information see the System Administration user guide.

If the workflow is unable to drain the data within the specified time, the workflow still stops and any remaining data in the workflow is lost. If this occurs, a log note is added in the System Log.

Real-Time Workflows

Real-time workflows are deactivated immediately, accepting no more input data.

If an Inter Workflow forwarding agent is included in the workflow, the last file may be incomplete. For such cases, the error handling is taken care of by the corresponding Inter Workflow collection agent.

Batch Workflows

Batch workflows have two termination possibilities, indicating whether to wait for the End Batch or not. If the batches are large, and the batch is being loaded by the workflow, the Immediate option will terminate the workflow without waiting for the current batch to finish.

Confirmation dialog when batch workflows are deactivated