Resume Workflows
If a workflow fails to finish successfully or the server shuts down while the workflow is being executed, it is possible to resume the workflow from the last known state. The resume operation is available for workflow executions which meet the following requirements:
-
There is state-tracking information available.
-
There are some resumable nodes in the state-tracking information.
State-tracking information
Each workflow execution can track its progress to the storage provided by stateStorageProvider as configured in the Workflow Component in the server configuration file.
When resuming, state-tracking data contains all information about the last known state of the workflow (task states, overall state, variable values, and so on) required to resume the workflow.
All current storage implementations (XML, database) can be used as the state-tracking information storage for resuming workflow executions.
Resumable nodes
A workflow is resumable if some of its nodes are resumable. Resumability of the node depends on the workflow execution mode.
continueOnFailure=false
In this mode, any task in the state FINISHED_FAILURE represents an immediate stop to the processing. So tasks in the following states are selected as the resumable nodes:
-
FINISHED_FAILURE - Processing has stopped on this node.
-
RUNNING - Abnormal server shutdown; the server quit when the task was in the RUNNING state.
-
UNKNOWN - Undetermined state, similar to the RUNNING. RUNNING state is corrected to the UNKNOWN state once the state-tracking information is reloaded.
-
IN_QUEUE - Already selected for execution (link evaluations are completed) but not executed yet.
Tasks in the WAITING state are also processed: if there is a task in the WAITING state all of those predecessors were processed, but the execution has stopped before the current task was evaluated, the task is planned for reevaluation. This is different from the resume action: the task’s incoming conditions are to be reevaluated first, and, only if they allow to process the task, the task is set for processing.
continueOnFailure=true
In this mode, FINISHED_FAILURE does not represent the end of the workflow processing. Therefore, tasks in this state are not included into resumable nodes.
All other states (nodes) are processed as in the continueOnFailure=false mode.
If the execution is resumable, then RESUME and FORCED RESUME options appear in the listing of the executions on the WebConsole Workflow details screen.
Resume workflow
ONE Runtime Server Admin
When running workflow using a server, state tracking is performed automatically using the storage provider defined in the server configuration file. State-tracking information is managed by the server, which decides whether the tracking information should be kept or deleted.
The server deletes the state-tracking information in the following cases:
-
There is no room for new state tracking information. The server keeps only limited history of execution state trackings, which is currently limited to the last 15 executions per workflow.
For example, if you run the same workflow 16 times, the oldest tracking information is deleted before the 16th workflow execution is launched. The history depth size can be set in Workflow Runtime Parameters.
-
The related workflow definition file was deleted. If the tracking information relates to the workflow which cannot be found in the server workflow configuration folder, the state-tracking information is deleted. This matching is performed on the server startup and every time when launching a new workflow instance.
-
The state-tracking information does not match the current state of the workflow configuration file. This means thatthe workflow configuration has changed and the stored tracking information does not match the current state of the workflow configuration. A match is determined by comparing the stored task IDs against the configuration ones.
If the tracking information contains the task whose ID which cannot be found among the workflow configuration task IDs, the tracking information is considered invalid and therefore deleted.
This matching is performed on the server startup and every time when launching a new workflow instance.
This task ID matching currently considers only regular task IDs, the compensation transaction IDs are not used in the comparison. This is done in order to preserve state trackings as long as possible and delete them only if they are explicitly wrong.
All available state tracking information is listed by the WebConsole on the Workflow details screen. So if state tracking is not listed in the console, it cannot be resumed anymore.
Shell console
If you want to use the resume functionality in this run type, make sure that you run the original execution with the stateFile parameter defined (see Execute Workflows).
Execution then performs state tracking to the defined file using the XML backend (database is not available in this run type).
If a workflow runs without the stateFile parameter, state tracking is not performed and therefore further resuming of such execution is not possible.
Resume workflow from the command line
runewf.sh -runtimeConfig="../project/Files/etc/dqc.runtimeConfig" -resume="../project/Files/etc/state_log.xml" -forceResume=true -state="../project/Files/etc/state_log_resumed.xml" -log=true -vars.var1="Hello World!" -vars.var2="Welcome!" "../project/Files/workflows/workflow.ewf"Was this page useful?