Processing a Rollback

The Rollback page is available in all executable objects that can be part of a workflow. It allows you to define the actions that are required to store (by backing up) or restore (by rolling back) a certain condition. This allows you to undo erroneous task modifications. Rollbacks are only possible for workflows.

This topic provides information on the following:

• Custom vs File-Based Backup and Rollback
• To Define a Rollback Process
• Consideration on the Status of Tasks/Rollbacks
• File Rollback
• Note for Windows Users
• Custom Rollback
• Rollback of Workflows
• Specific Rollback Commands

Custom vs File-Based Backup and Rollback

Backups and rollbacks are available in both custom and file-based form.

• A custom rollback process involves two objects, one that is responsible for the backup and another one that is responsible for the rollback.
• A file-based rollback backs up a directory or files and then restores them in a rollback process. Both rollback types will be processed if they have been defined.

  File-based backup and rollback processes are available only for Unix/Window jobs (JOBS) and file transfers (JOBF).

If both types are defined, custom backup processes will be processed before file-based ones.

Rollbacks can also be executed via the ROLLBACK_UC_OBJECT script function.

To Define a Rollback Process

These instructions assume that both processes (backup and rollback) have been defined.

1. Start the backup process.

   Backup actions are processed after the object has been activated but before it runs, regardless of how the object was activated. The task starts only if the backup actions have been successfully completed.

   Custom Backup

   For a custom backup process, you just start the specified backup object. While it is running, it has the Custom Backup status. If an error occurs during the run, the task aborts with FAULT_CUSTOM_BACKUP status . Note that in this situation the rollback object cannot start.

   File-Based Backup

   File-based backup processes copy the directory or the specified files to the following directory:
   <Backup folder>/<Client>/<Date>/<RunID>/

   You define the backup folder in the in the [VARIABLES] section of the agents' INI files using the with the UC_EX_PATH_BACKUP agent variable (see Agent Variables). By default, the system uses "..\BACKUP" (Windows) or "../backup" (Unix) as its backup folder.

   While a file-based backup object is running, it has the File Backup status . If an error occurs during the run, the task aborts with the FAULT_FILE_BACKUP status . Note that in this situation the rollback object cannot start.

    

2. Start the rollback process.

   You can start a rollback process only if the Enable Rollback option is activated on the Rollback page of the affected object; otherwise, this function is not available. Unlike a backup process, rollback processes can be started only for workflow tasks that have already ended. You can do it as follows:

   • Manually from the Workflow Monitor in the Process Monitoring perspective:

     

   • Manually from the Tasks list in the Process Monitoring perspective:

     

   • Automatically with a ROLLBACK statement that you can define in the task properties of the Preconditions, Postconditions, Conditions page.

   Consideration on the Status of Tasks/Rollbacks

   The status of a task that starts in rollback is Active and can be clearly identified 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 status ENDED_ROLLBACK_EMPTY.

   The rollback object cannot start when the task has aborted with the FAULT_CUSTOM_BACKUP or FAULT_FILE_BACKUP status. If this happens, you must resolve the errors and restart the task.

   File Rollback

   In a file-based rollback process, the system copies the task's files, which are stored in the backup folder (<Backup folder>/<Client>/<Date>/<RunID>) back to the directory that is specified in the Rollback page. If the Delete before Restoreoption has been activated (also on the Rollback page), the content of the destination directory will be deleted before the rollback process takes place. This prevents copying errors. Subfolders will be deleted only if the option Include sub-directories is activated.

   This procedure restores the directory to its previous status before the task has run.

   While the file-based rollback process is running, the task has the File Rollback status. If an error occurs during the run, the task aborts with the FAULT_FILE_ROLLBACK status.

   Note for Windows Users

   To use the file-based rollback under Windows, Windows Powershell must be entered as the interpreter using the ECPEXE= and EXPEXT= parameters in the affected Windows agent's INI file ([GLOBAL] section). These parameters are set by default.

   For example:

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

   ECPEXT=ps1

   For the backup and rollback actions, the system uses the FILE.BACKUP.WINDOWS and FILE.ROLLBACK.WINDOWS objects, which are supplied by default in client 0.

   Also make sure that unsigned scripts can run under Powershell if required. Change the policy from restricted to remotesigned, for example.

   To change the Powershell script rights, open a Powershell Window on the affected Windows computer and specify the following command:

   

   Custom Rollback

   In a custom rollback process, the Rollback object that is responsible for restoring the original working state starts. The actions of the Backup object depend on the task or the Backup object and must be defined by the user.

   While the Rollback object is running, the status of the task is Custom Rollback. If an error occurs during the run, the task aborts with the FAULT_CUSTOM_ROLLBACK status.

Rollback of Workflows

Rollback processes ignore the properties of the workflow tasks (such as the latest start time). The logical date is kept.

Tasks are rolled back in reversed order, that is, the rollback process starts at the workflow's end and finishes at the workflow's start. The same behavior applies to all subordinate workflows. The procedure is complete when the rollback actions of the workflow start.

If the task is a workflow, the rollback process takes also place for all its subordinate tasks; the nesting depth is not limited. If ou start the rollback process for a sub-workflow, its subordinate tasks switch to the Waiting for rollback status. f this sub-workflow includes active subordinate tasks, their states will only be changed when the sub-workflow has ended.

A rollback process stops when a task has been deactivated and is no longer visible in the Process Monitoring perspective. In this case, you must restart the task or skip it in order to continue the rollback process.

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. You can remove the error and then restart the rollback process for this task.

Special Cases: Rollback of FOREACH and IF workflows

In a rollback process of FOREACH workflows, the tasks are processed in reversed order. Then, the workflow's rollback actions take place.

In IF workflows, a rollback process takes place for the task branch that has been selected during the last run. The workflow's rollback actions take place afterward.

Specific Rollback Commands

Open the workflow monitor in the Process Monitoring perspective and right-clik on it to open the context menu containing the rollback-specific commands available for the workflow:

Command	Description
Rollback to this Task	The rollback path is retrieved first. This path includes all direct and indirect successors of the task within the workflow. Predecessors and parallel tasks are not affected. In a next step, the tasks that are in the rollback path obtain the status "Waiting for rollback". When a task is active, the system waits until it has ended and only then, its status will change. Subsequently, the rollback takes place for the relevant tasks in an order that is reversed to their order in the workflow. This means that the rollback starts with the last successor and ends with the selected task. If an error occurs during the rollback process the execution stops at the rollback path of the relevant task. You can now remove the error and restart the rollback process of the affected task. Workflows that are included in the rollback path including their subordinate tasks will also be rolled back (see above). The rollback actions of the workflow itself (if there are any) are not processed if you activate the Rollback to this Task option .
Rerun	Only available in active workflows. It is only useful if the workflow includes at least one task in ENDED_ROLLBACKED status Select this command to start all the relevant tasks whose rollback process has been successfully completed (status: ENDED_ROLLBACKED), whose rollback process could not take place because of missing definitions (status: ENDED_ROLLBACK_EMPTY), or which are waiting for the rollback process to take place (status: Waiting for rollback). The values of the last run are used for PromptSet variables, the values of the object definition are used for object variables. The task properties (such as the latest start time) are considered for the command "Rerun". The logical date is kept.

See also:

• Rollback Page
• Modifying Active Workflows at Runtime