The Rollback tab is available in all executable objects that can be part of a workflowAn object of the Automation Engine that can include several executable objects and which runs them in a specified order. [Formerly called "ProcessFlow" and "JobPlan."]. 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 taskAn executable object that is running. Tasks are also referred to as activities. in error. A rollback process in the Automation EngineThis component drives an Automation Engine system and consists of different types of server processes. 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 scriptA particular Automation Engine object type. functionPre-defined run book template in the Automation Engine. One single step only, e.g. Start Windows Service, Copy file,… ROLLBACK_UC_OBJECT.
When backup actions are defined, they will automatically be processed after the objectAutomation Engine controlled activities and processes are structured in the form of objects. See also: Task 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 statusThis represents the condition of a task (such as active, blocked, generating). "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 folderTop level entities such as Environment, Deployment Target, Activity, … are stored in folders. The permissions a user has on an entity depend on the permissions that are set on the folder for the entities.>/<Client>/<Date>/<RunIDShort for "run number". It is a number that provides unique information about a task's execution. The RunID can include 7 to 10 digits. It is assigned by the Automation Engine component .>/
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:
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-workflowA workflow that is part of a different 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 dateThe logical date is used as a comparison date for checking Calendar conditions. 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 restartA restart refers to the repetition of an object's execution. This action differs from a new start in some parts. 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 agentA program that enables the de-centralized execution of processes (such as deployments) on target systems (computers or business solutions) or a service that provides connectivity to a target system (such as for databases or middleware). An agent is also an object type in the Automation Engine. [Formerly called "Executor."] See also: host'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 clientA closed environment within an Automation Engine system where you can create and run objects. A client name consists of a 4-digit number that must be indicated when a user logs on to the Automation Engine system. Users and their rights are also defined in clients. A particular Automation Engine object type. 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 stateThe state a package or a task currently is in. starts. The actions of the Backup object depend on the task or the Backup object and must be defined by the userIn the Automation Engine, a user is an instance of a User object, and generally the user is a specific person who works with Automic products. The User object is assigned a user ID and then a set of access rights to various parts of the Automation Engine system and product suite. These access rights come in the form of Automation Engine authorizations and privileges, Decision user roles and EventBase rights and ARA web application object rights. You can manage all these centrally in the ECC user management functions. See also, Unified user management..
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 variablesPlaceholder for values that are stored in an object's "Variables & Prompts" tab/section..
The task properties (such as the latest start time) are considered for the command "Rerun". The logical date is kept.
Automic Documentation - Tutorials - Automic Blog - Resources - Training & Services - Automic YouTube Channel - Download Center - Support |
Copyright © 2016 Automic Software GmbH |