Rollback Page

A rollback returns a workflow to the state before a task that failed was executed. A rollback is not carried out automatically, you must enable it. This page is object-specific and only available for executable objects that can be part of a workflow.

This screenshot depicts the Rollback page of a File Transfer object (JOBF); the File Rollback options are available for Job (JOBS) and File Transfer (JOBF) objects only!

Background/Purpose

Modifications to a task, a wrong implementation or deployment, etc. that lead to task failure may impair the workflow. CA Automic Workload Automation allows you to undo these errors and restore the task to the status it had before failing. In the Rollback page you define which actions store a task (the backup) and which ones restore it (the rollback).

Backup actions are processed before the object is processed; rollback actions can only be started via workflows.

In the case of File Transfers (JOBF), backup and rollback processes are available for Windows/Unix jobs only; a directory or files are backed-up and restored.

Rollbacks can also be executed via the ROLLBACK_UC_OBJECT script function.

Using Variables in Backup/Rollback Tasks

The following object variables are available for the processing of backup and rollback tasks:

• &AGENT# - The name of the agent of the task that is used to trigger the backup or rollback action.
• &LOGIN# - The name of this task's Login object.
• &RB_FBACKUPPATH# - The path for the file-based rollback action (only applies to jobs and file transfers)

• &RB_FDELETEBEFORE# - The handling of tasks before they are restored (file-based rollback actions, only applies to jobs and file transfers).

  Possible values: 

  • "001" - The affected files are deleted
  • "000" - No files are deleted

• &RB_FINCLSUBDIRS# - Handling of subdirectories (file-based rollback actions, only applies to jobs and file transfers)

  Possible values:

  • "001" - Subdirectories are considered
  • "000" - Subdirectories are not considered

Note that variables of the same name will be overwritten in the Backup or Rollback object.

Defining a rollback comprises two steps:

1. Defining the backup tasks.
2. Defining the rollback tasks.

However, in the case of file rollbacks with Job (JOBS) and File Transfer (JOBF) objects, an additional parameter is necessary, namely defining the backup path.

To Define the Rollback Settings

1. Activate the Enable Rollback check box to enable this function and display the available settings.

2. Define the Backup Task.

   Select here the object that will execute the backup process; it contains the actions and steps that will be carried out to backup the tasks performed by the object you are defining. For example, if you use an object to update the database, you should include a database in the backup object.

   Backup tasks are always executed. They are processed after the object has been activated but before it runs. The task starts only after the backup actions have been successfully completed.

   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

3. Define the RollbackTask.

   Select here the object that will execute the rollback process.

   Rollback tasks are responsible for undoing the modifications that caused a task error and restore it to the last successful status. For example, if an error occurs during a database update, the rollback should be able to restore the previously created backup.

   Unlike backup processes, rollbacks are started only after workflows have ended. The rollbacks can only be processed in workflows when the task is in rollback mode. Tasks that are running in rollback mode are active; they end as soon as the rollback process is complete.

4. If you are defining the rollback settings for Job (JOBS) or File Transfer (JOBF) objects, enter the Backup Path. The task files stored in the backup folder are copied to the path you specify here. If you do not include the file name in the path, the complete content of the folder is backed up.

   File rollbacks are available only for Job and File Transfer (JOBF) objects that run on Windows or UNIX. In the case of Jobs, the system uses the job's agent; in the case of File Transfers, it uses the destination agent.

   Examples for Windows:

   • C:\temp\text.txt
   • C:\temp\*.txt
   • C:\temp\ or C:\temp\*
   • C:\temp\text??.*

   In the case of file transfers, Automic recommends using the &$DST_FILE# predefined variable to specify the target.

   The specified directory or files are automatically copied to the following director before the object runs:

   <Backup folder>/<Client>/<Date>/<RunID>/

   Backup folder definition via variable

   You can also define the backup folder in the [VARIABLES] section of the agent INI file using the UC_EX_PATH_BACKUP agent variable. By default, the system uses ..\BACKUP (Windows) or ../backup" (Unix) as backup folder.

   For example:

   Folder to be backed up: C:\AUTOMIC\source\*.txt

   Backup folder: C:\AUTOMIC\backup

   Special case UNIX: The files are not directly stored in the directory above but in a TAR archive that uses the RunID as its name

   Recommendations

   • Make sure that there is enough disk space available for the backup.
   • Make sure that the OS user has the required rights assigned.
   • The backup folder is wiped in regular intervals. You can specify the following two settings for the UC_HOSTCHAR* variable:
     • BACKUP_RETENTION_LIFETIME: Defines the time period, how long a file is kept.
     • BACKUP_RETENTION_CHECK: Defines when the files are checked.

     The files whose lifetime interval has passed are deleted.

   • When you run a file-based backup from a non-existing path, the path is deleted during the rollback process, provided it was previously created during the file transfer process. No errors occur in this case, neither in the backup nor in the rollback process.

5. Optionally, activate Delete before Restore. This checkbox is only visible if you have entered a backup path before.

   If you activate this option, the content of the original directory used to create a backup will be deleted before the backup folder is restored. This ensures that the destination directory is empty before the files are copied from the backup folder, thus avoiding potential errors.

   Sub folders are deleted only if the Include Sub directories option is also activated.

6. Optionally, activate Include Sub directories . This checkbox is only visible if you have entered a backup path before.

   Activate this option if you want to include sub folders in the backup path.

   By default, empty sub directories are not copied during the backup process. If you want to include empty folders in the backup, you must set the &RB_FBACKUP_COPY_EMBTY_DIR Object properties variable to "1" ( see Variables & Prompts Pages).

   If you do not specify a file name here, the complete content of the directory is backed up.

   You can use the following wildcard characters in the name:

   • * ( as placeholder for any number of characters)
   • ? (as placeholder for exactly one character). This allows you to select files with a certain name and ending.

   Wildcard characters can be used in the file name, not within the path.

See also:

• Processing a Rollback
• Rollbacks in the Workflow Monitor