Start, pause, stop a workflow starting-a-workflow

Start

This action lets you start the execution of a workflow: a workflow that is Finished, Being edited or Paused changes status to Started. The workflow engine then handles the execution of this workflow. If the workflow was paused, it is resumed, otherwise the workflow is started from the beginning and the initial activities are activated.

Starting is an asynchronous process: The request is saved and is processed as soon as possible by a workflow server.

Pause

This action sets the status of the workflow to Paused. No activities are activated until the workflow is resumed; however the operations in progress are not paused.

Stop

This action stops a workflow currently being executed. The status of the instance is set to Finished. Operations in progress are stopped, if possible. Imports and SQL queries are canceled immediately.

Unconditional stop

This option changes the workflow status to Finished. This action should only be used as a last resort if the normal stop process fails after several minutes. Only use the unconditional stop if you are sure there are no actual workflow jobs in progress.

Restart

This action stops then restarts the workflow. In most cases, it makes it possible to restart faster. It is also useful to automate restarting when stopping takes a certain amount of time: this is because the ‘Stop’ command is not available when the workflow is being stopped.

Note that the Restart action does not clear the workflow instance variables compared to Execution, Stop, and Start actions (the instance variables clearing happening upon Start action). When restarting a workflow, instance variables are still available for use with preserved values. To clear them, you can either:

• Perform Stop and Start actions.

• Add below javascript code at the end of your workflow execution:

  code language-none
  var wkf = xtk.workflow.load(instance.id) wkf.variables='<variables/>' wkf.save()

Purge history

This action lets you purge the workflow history. For more on this, refer to Purging the logs.

Start in simulation mode

This option lets you start the workflow in simulation mode as opposed to real mode. This means that when you enable this mode, only activities that do not impact the database or the file system are executed (e.g. Query, Union, Intersection, etc.). Activities that do have an impact (e.g. Export, Import, etc.) as well as those after them (in the same branch) are not executed.

Execute pending tasks now

This action lets you start all pending tasks as soon as possible. To start a specific task, right-click its activity and select Execute pending task(s) now.

Save as template

This action creates a new workflow template based on the selected workflow. You need to specify the folder where it will be saved (in the Folder field).

Do not to schedule a workflow to run more than every 15 minutes because it may impede overall system performance and create blocks in the database.

Avoid leaving your workflows in a paused state. If you create a temporary workflow, make sure it will be able to finish correctly and not stay in a paused state. If it is paused, it would imply that you need to keep the temporary tables and thus increase the size of the database. Assign Workflow Supervisors under Workflow Properties to send an alert when a workflow fails or is paused by the system.

To avoid having workflows in a paused state:

• Check your workflows on a regular basis to ensure there are no unexpected errors.
• Keep your workflows as simple as possible, for example by splitting large workflows in several different workflows. You can use External signal activities trigger their execution based on other workflows’ execution.
• Avoid having disabled activities with flows in your workflows leaving threads open and leading to many temporary tables that can consume a lot of space. Do not keep activities in Do not enable or Enable but do not execute states in your workflows.

Stop unused workflows. Workflows that keep running maintain connections to the database.

Only use unconditional stop in the rarest cases. This option is restricted to Admin users. Do not use this action on a regular basis. Not performing a clean closure on connections generated by workflows to the database impacts performance.

Do not perform multiple stop requests on the same workflow. Stopping a workflow is an asynchronous process: The request is registered, then the workflow server or servers cancel operations in progress. Stopping a workflow instance can therefore take time, especially if the workflow is running on multiple servers, each one of which must take control to cancel the tasks in progress. To avoid any issue, wait for the stop operation to be completed and avoid stopping a workflow multiple times.