This topic providesinformation on how to rollback completely executed workflows as well as still executing workflows. For executable objects in that workflow, you can define rollback actions. Rollback requires a backup step before changing objects.
Rollback is available for users with the right to modify (M).
Introduction to Rollback Features in ARA
What to rollback
You can rollback workflows and tasks as long as they are still active and they are still visible in the Workflow Monitor. The execution can be either fully or partially completed which means, that you can rollback still executing workflows.
Preparing for rollback
When the rollback feature is needed, it must be explicitly enabled for each object in scope. Then, the following steps can be performed:
Depending on the object in scope, there are different rollback scenarios:
| Scenario | Available for | Backup | Rollback |
|---|---|---|---|
| File based rollback |
|
A directory or certain files must be specified |
Restore directories or files |
| Custom rollback |
|
A backup script, function or action must be defined individually | Rollback or script, function or action must be defined individually |
| Rollback functionality provided with actions |
|
Actions marked as rollback-ready in the ARA Actions Reference possess appropriate backup and rollback procedures. When an action has no rollback defined (rollback is not enabled), no backup will be done. For more specific information see the documentation of the package where the action belongs to. |
Actions marked as rollback-ready in the ARA Actions Reference possess an appropriate rollback procedure. When an action has no rollback defined (rollback is not enabled), no default restore procedure is available. For more specific information see the documentation of the package where the action belongs to. Optionally, an administrator may create a custom rollback procedure. |
| Manual interaction |
|
N/A | Although it is not desirable, you can always pause workflow execution at a certain point and have an operator or administrator performing corrective tasks. |
Triggering rollback
It is possible to trigger rollback manually from the Workflow Monitor or automatically by a post-condition (see Postconditions in Workflow Designer). The status of all executed tasks on rollback path is set to WAITING_FOR_ROLLBACK.
Rollback
A rollback is always performed
Rollback can be executed repeatedly but not for a task with status FAULT_*_BACKUP.
The various rollback statuses are reflected via color and icons.
Option Rollback Parent
Rollback the parent workflow of this task and all of its children. This option can be set in the Postconditions in Workflow Designer.
Option Rollback Top Workflow
Rollback the top-most parent of this task and all of its children. This option can be set in the Postconditions in Workflow Designer.
Example: When workflow A contains the workflow B containing task C. When post-condition on task C triggers rollback, then rollback is executed with workflow A.
Rollback Loops
When a loop is executed a certain number of tasks are executed for this loop (grouped in "iterations"). Each one of this tasks can have rollback settings. When rolling back a loop, the executed tasks are rolled back in the reverse order by executing their rollback actions.
Rollback IF conditions
When executing an IF, either the TRUE or the FALSE branch is executed. When rolling back that IF condition with its previously selected and executed branch, the tasks executed on the branch have to be rolled back in reverse order. Finally, if the IF object has rollback settings defined, they will be executed afterwards.
If TRUE path is executed first, but after rollback the FALSE path is executed, the previously rolled back tasks from the TRUE path have status UNPROCESSED.
Stopping rollback
The rollback can be for an entire workflow (Rollback Workflow) or only for a part of a workflow (Rollback To), then the rollback stops automatically. Additionally, you can cancel rollback of a task analog to the execution of a task.
If rollback Fails, rollback on this path is stopped. Predecessors keep their status WAITING_FOR_ROLLBACK. Upon rollback on a predecessor, automatic rollback will continue with rollback of all marked tasks. Successors of the task with status FAULT_ROLLBACK will not be started.
If a sub-workflow on the rollback path is deactivated, the rollback stops before the deactivated workflow. You can restart or modify workflow to circumvent deactivated workflow.
Rolled back tasks with rollback settings get status ENDED_ROLLBACKED (rollback was successful) or FAULT_CUSTOM_ROLLBACK / FAULT_FILE_ROLLBACK (rollback was not successful). Rolled back tasks with no rollback settings get status ENDED_ROLLBACK_EMPTY.
Be aware of features which may be used in combination!
For example, skipping tasks and breakpoints can be used to prevent any workflow paths from being executed again if needed.
Stopping the rollback client or a stop of workflow also stops rollback.
Rerun after rollback
Single tasks (e.g. jobs) can be restarted at any given time.
It is only possible to rerun a whole workflow only (not for a single task) to run forward again if three conditions match:
A IF condition is evaluated again and respective tasks are executed.
In case of a task with status FAULT_ROLLBACK rerun will not be started because it is not correctly rollbacked.
If a workflow has been rolled back completely (status ENDED_ROLLBACK), only restart is available.
GO does not start rerun: GO checks the preconditions for all tasks and starts them in either direction, i.e. if they were rollbacked, they start to continue to rollback.
Variables are NOT changed back / re-initialized (e.g. to the value during last run).