Rollbacks

Rollbacks restore Workflows, or tasks in a Workflow, to an earlier stage in the execution process. The rollback function lets you resolve errors and undo modifications. As a developer and object designer, you configure the rollback procedure on the Rollback Page of objects that can be part of a Workflow. As a developer and object designer, or as an operator or manager, you perform rollbacks on Workflows or on tasks in Workflows in the Workflow monitor.

Important! Rolling back is possible as long as the task is not yet deactivated, and is still visible in the Workflow Monitor. The execution can be either fully or partially completed. If the Workflow that you are rolling back is a child Workflow, the top Workflow must not have ended yet.

Overview

The execution of a task in a Workflow depends on the execution of its predecessor. A task cannot end successfully if its predecessor fails or does not produce the expected result. A rollback restores tasks and Workflows to their latest successful status and lets you rerun the tasks that failed.

Types of Rollbacks

Create your own custom objects to process backups and rollbacks, or use file-based processes that are available out of the box. You can combine custom and file-based rollbacks.

• Custom

  You create the executable objects that carry out backup and rollback operations. You assign them to the executable objects that you want to enable for rollback.

• (UNIX and Windows Jobs, and File Transfers only) File-based

  Preconfigured file backup processes. The files processed by a task are automatically stored in a backup folder (<Backup folder>/<Client>/<Date>/<RunID>). When the task is rolled back, the system copies the files. to the directory that is specified on the Rollback page. If the Delete before Restore option has been activated on the Rollback page, the content of the destination directory is deleted before the rollback process takes place. This prevents copying errors. Subfolders are deleted only if the option Include sub-directories is activated.

  Prerequisite: Set Windows PowerShell as the interpreter in the INI file of the affected Windows agent. Use the ECPEXE= and EXPEXT= parameters in the [GLOBAL] section of the INI file. For more information, see Agent Windows 64-bit.

  Example

  ECPEXE=C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe -file

  ECPEXT=ps1

  Note: The system uses the FILE.BACKUP.WINDOWS and FILE.ROLLBACK.WINDOWS objects, which are supplied by default in Client 0. If you must change the Powershell script rights, open a Powershell Window on the affected Windows computer and enter the following command:

  Set-ExecutionPolicy remotesigned

Note: File-based rollbacks are processed after custom backup and rollback tasks when you have defined both types for the task.

Stages of the Rollback Process

When you define an executable object that you can insert in a Workflow, you configure its rollback process on the Rollback Page. A rollback process consists of the following stages:

1. Backing up the status of the tasks and of the Workflows before their execution.

   Backup tasks are always executed and they occur after the object is activated, but before it is generated. How the object is activated does not matter. The object only starts after the backup tasks complete successfully.

   If the backup task ends successfully, the &RB_CBACKUP_RUNID# Object properties variable is automatically created in the task that triggers the backup process. This variable stores the RunID of the backup task.

2. Rolling back the execution.

   Specify the object that undoes the modifications that caused the execution error. Rollbacks are started only after user request. Rollbacks can only be processed when the task is in rollback mode.

Automating Rollbacks

You can automate rollbacks in the following ways:

• Use the ROLLBACK_UC_OBJECT script function to carry out rollbacks in your scripts.
• Define postconditions in the task properties to automate rollback actions, such as rolling back the parent or top Workflow automatically.

For more information, see:

• Script Elements for Handling Tasks
• Precondition and Postcondition Tabs
• List of Statements to Build Conditions

Triggering a Rollback

Prerequisites:

• The Enable Rollback option is activated on the Rollback page of the affected task.
• The backup task has created the required backups (if the task requires backups).
• The task has already ended.
• If the task is in a Workflow, the parent or top Workflow must still be active.
• If you are rolling back a Workflow, the Workflow itself must still be active. When you roll back a child Workflow, the top Workflow must still be active

Carry out one of the following actions in the Process Monitoring perspective to start a rollback:

• Right-click the task in the Workflow Monitor, and select Rollback Task or Rollback to this Task
• Right-click the task in the Tasks list, and select Rollback Task

For more information, see Working with Tasks and Available Functions Depending on the Task Status.

The rollback process executes the rollback object and restores the state before the task ran. After you have rolled back the task or Workflow, and have remedied the situation that caused you to roll back, rerun the task or Workflow.

Note: You can execute rollbacks repeatedly, except for tasks that have FAULT_*_BACKUP status.

Task Statuses During Backup and Rollback

Tasks that are rolled back are in Active status, as can be seen in the Workflow Monitor (see Monitoring Workflows). When the rollback process is complete, the task also ends. Tasks without a rollback definition end with the ENDED_ROLLBACK_EMPTY status.

Tasks have the following statuses during custom backup and rollback processes:

• Custom Backup
  Custom backup object is running
• FAULT_CUSTOM_BACKUP
  Task has aborted due to an error during the run
• Custom Rollback
  Custom rollback object is running
• FAULT_CUSTOM_ROLLBACK
  Task has aborted due to an error during the run

The task has the following statuses during file-based backup and rollback processes:

• File Backup
  File-based backup object is running
• FAULT_FILE_BACKUP
  Task has aborted due to an error during the run

Important! Rollback objects cannot start when the task aborts with the FAULT_CUSTOM_BACKUP or FAULT_FILE_BACKUP status. Resolve the errors and restart the task.

Rolling Back Workflows

Tasks in Workflows are rolled back in reverse order: the rollback starts at the end of the Workflow, and finishes at the start. The same behavior applies to all child Workflows. The procedure is complete when the rollback actions of the Workflow start

When the rollback process of a task fails (FAULT_CUSTOM_ROLLBACK/FAULT_FILE_ROLLBACK), the rollback procedure stops at the affected branch of the Workflow. Remove the error and restart the rollback process for the aborted task.

Note: Rollback processes ignore the properties of the Workflow tasks (such as the latest start time), but keep the logical date.

Partial Rollback

Use the Rollback to this Task command to roll a Workflow back to a selected task. The command retrieves the rollback path, which includes all direct and indirect successors of the task within the Workflow. If a task is still active, the system waits until it has finished and then performs its rollback.

Nested Workflows

If the task itself is a Workflow, the rollback also rolls back all child tasks of the Workflow. The nesting depth is not limited. When the rollback for a child Workflow starts, the child tasks of the nested Workflow switch to Waiting for rollback status.

ForEach Workflows

Tasks in looped Workflows are processed in reverse order when you roll back. The rollback actions that you define for the Workflow take place after the tasks are processed.

IF Workflows

The rollback process takes place for the task branch that was selected during the last run. The rollback actions that you define for the Workflow take place after the task branch has rolled back.

Deactivated Tasks

The rollback process stops when a task has been deactivated and is no longer visible in the Process Monitoring perspective. To continue the rollback process when a task has been deactivated, restart or skip the task.

Variables in Backup and Rollback Tasks

The Automation Engine provides predefined object variables that help you configure backup and rollback tasks. For more information, see Using Variables in Backup and Rollback Tasks.

Stopping a Rollback

You can stop and cancel a rollback in the same manner as you stop or cancel a Workflow.

If the rollback fails, the rollback on this path is stopped. Predecessors keep their status WAITING_FOR_ROLLBACK. Upon rollback on a predecessor, automatic rollback continues with rollback of all marked tasks. Successors of tasks with status FAULT_ROLLBACK do not start rolling back.

Tip: Combine features such as skipping tasks and breakpoints with rollbacks to prevent Workflow paths from executing again.

Important! Stopping the Client or stopping the Workflow also stops the rollback.

Rerunning Tasks after a Rollback

Use the Rerun command in the context menu to restart tasks after a rollback. To rerun a complete Workflow, the Workflow must still be active. You can restart single tasks such as Jobs at any time.

The Rerun command restarts all tasks in the Workflow that have the following statuses:

• ENDED_ROLLBACKED

  Tasks whose rollback process has been successfully completed

  Note: The Rerun command is only useful if at least one task has ENDED_ROLLBACKED status.

• ENDED_ROLLBACK_EMPTY

  Tasks whose rollback process could not take place because of missing definitions

• Waiting for rollback

  Tasks which are waiting for the rollback process to take place

Notes:

• IF conditions are evaluated again, and the respective tasks are executed
• You cannot rerun a Workflow that has rolled back completely (status ENDED_ROLLBACK). You can restart the Workflow.
• The Go command does not start a rerun. Go checks the pre-conditions for all tasks, and starts the tasks in either direction. Tasks that were rolled back continue the rollback.
• Task properties such as the latest start time are considered when you rerun the Workflow. The logical date is kept.

Variables in Reruns

• Variables are not reset or re-initialized when you rerun a task.
• PromptSet variables reuse the values from the last run.
• Object variables use the value that is set in the object definition.

See also:

• Rollback Page
• Modifying Workflows at Runtime