|
Modifications to Active Workflows |
Workflow |
Working with Objects |
|
Processing a RollbackThe Rollback tab is available in all executable objects that can be part of a workflow. On the Rollback tab you can define the actions that are required to store (by backing up) or restore (by rolling back) a certain condition. This allows you to undo modifications that you have made in a task in error. A rollback process in the Automation Engine can take place only in a workflow. This document explains the details of the rollback process.
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 and file transfers.
Rollbacks can also be executed via the script function ROLLBACK_UC_OBJECT.
When backup actions are defined, they will automatically be processed after the object has been activated but before it runs, regardless of how the object was activated. The task will start only if the backup actions have been successfully completed.
Custom backup processes will be processed before file-based backup processes (if both kinds are defined).
Custom Backup
For a custom backup process, you just start the specified Backup object. While a custom Backup object is running, it has the status "Custom Backup".
If an error occurs during the run, the task aborts with the status FAULT_CUSTOM_BACKUP. Note that in this situation the Rollback object cannot start.
File Backup
A file-based backup process copies the directory or the files that are specified in the Rollback tab to the following directory:
<Backup folder>/<Client>/<Date>/<RunID>/
You define the backup folder in the INI files of the agents (in the [VARIABLES] section) with the agent variable UC_EX_PATH_BACKUP. 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 status "File Backup". If an error occurs during the run, the task aborts with the status FAULT_FILE_BACKUP. Note that in this situation the Rollback object cannot start.
Unlike a backup process, you can start a rollback process only for workflow tasks that have already ended. You can start a rollback process in one of the following ways:
This menu item only appears if the rollback is activated in the task properties and if the task has already ended (normally or abnormally).To run a rollback process, you must activate the option "Enable Rollback". This is available in the properties of workflow tasks in the General tab. If this option is not active, the context-menu command does not appear, the Rollback button in the toolbar is disabled and the Post-Condition ROLLBACK will not be processed. By default, this option is set.
Make sure that the settings are activated and defined in the Rollback tab.
In a rollback process, the system first runs the file-based rollback (if it is available and defined) and then the custom rollback (if defined).
Tasks that start in rollback mode have an active status and the Workflow Monitor displays them in purple. When the rollback process is complete, the task also ends.
Starting a rollback for a sub-workflow includes that all subordinate tasks are affected (see below in the section Rollback of Workflows).
Tasks without a rollback definition end with the status ENDED_ROLLBACK_EMPTY.
Rollback processes ignore the properties of the workflow tasks (such as the latest start time). The logical date is kept.
The Rollback object cannot start when the task has aborted with the status FAULT_CUSTOM_BACKUP or FAULT_FILE_BACKUP. If this happens, you must resolve the errors and restart the task.
After a successful rollback process, the task obtains the end status ENDED_ROLLBACKED.
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 tab. If the option "Delete before restore" is active, 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 active.
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 status "File Rollback". If an error occurs during the run, the task aborts with the status FAULT_FILE_ROLLBACK.
In order to use the file-based rollback under Windows, Windows Powershell must be entered as the interpreter using the parameters ECPEXE= and EXPEXT= in the affected Windows agent's INI file([GLOBAL] section). These parameters are set by default. An example from a Windows agent's INI file is shown below::
ECPEXE=C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe -file
ECPEXT=ps1
For the backup and rollback actions, the system uses the objects FILE.BACKUP.WINDOWS and FILE.ROLLBACK.WINDOWS which are by default supplied 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, for example:
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 task has the status "Custom Rollback". If an error occurs during the run, the task aborts with the status FAULT_CUSTOM_ROLLBACK.
When the task is a workflow, the rollback process takes also place for all its subordinate tasks. The nesting depth is not limited.
When you start the rollback process for a sub-workflow, its subordinate tasks switch to the status "Waiting for rollback". If this sub-workflow includes active subordinate tasks, their states will only be changed when the sub-workflow has ended.
The tasks are rolled back in reversed order which means that 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.
A rollback process stops when a task has been deactivated and is no longer visible in the Activity Window. In this case, you must restart the task or skip it in order to continue the rollback process.
The exact rollback procedure for each individual task is described above in the Rollback section.
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.
Rollback of FOREACH workflows
In a rollback process of FOREACH workflows, the tasks are processed in reversed order and then, the workflow's rollback actions take place.
Rollback of IF workflows
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 afterwards.
Rollback to this task
This command is available in the context menu that can be called in the monitor of active workflows for tasks that have already ended (modify task).
When you use this command, 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.
When 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 Rollback of Workflows).
The rollback actions of the workflow itself (if there are any) are not processed if you activate the option "Rollback to this Task".
Rerun
The command "Rerun" is available in the context menu (Modify Workflow) that opens when you right-click an empty position in the Workflow Monitor. This command is only available in active workflows and it is only useful when this workflow includes at least one task with the status ENDED_ROLLBACKED.
You use the command "Rerun" in order to start all the relevant workflow's tasks
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.