In der Registerkarte Rollback, die bei allen ausführbaren Objekten zu finden ist, die in einem Workflow enthalten sein dürfen, können Aktionen für die Sicherung (Backup) und Wiederherstellung (Rollback) eines bestimmten Zustandes definiert werden. So haben Sie die Möglichkeit, die Änderungen durch eine Aufgabe im Fehlerfall wieder rückgängig zu machen. Die Durchführung des Rollbacks ist in der Automation Engine nur über einen Workflow möglich und in diesem Dokument genauer erläutert.
Grundsätzlich wird zwischen benutzerdefiniertem und dateibasiertem Backup / Rollback unterschieden.
Beim benutzerdefinierten Rollback übernimmt ein Objekt das Backup und ein anderes Objekt das Rollback. Das dateibasierte Rollback sichert ein Verzeichnis bzw. bestimmte Dateien und stellt diese im Rollback-Fall wieder her. Es werden beide Rollback-Arten durchgeführt, wenn definiert.
Das dateibasierte Backup und Rollback ist nur bei Unix-/Windows-Jobs und FileTransfers möglich.
Das Rollback kann auch mittels Sprachmittel ROLLBACK_UC_OBJECT gestartet werden.
Sind Backup-Aktionen definiert, so werden diese automatisch nach Aktivierung aber vor Durchführung des Objektes abgearbeitet. Dabei spielt es keine Rolle wie das Objekt aktiviert wurde. Die Durchführung der Aufgabe wird erst begonnen, wenn die Backup-Aktionen erfolgreich abgeschlossen wurden.
Das benutzerdefinierte Backup wird vor dem dateibasierten Backup (wenn definiert) durchgeführt.
Benutzerdefiniertes Backup
Beim benutzerdefinierten Backup wird das angegebene Backup-Objekt gestartet. Während der Durchführung des Backup-Objektes besitzt die Aufgabe den Wartezustand "Benutzerdefiniertes Backup".
Kommt es zu einem Fehler beim Ausführen des Backup-Objektes, so bricht die Aufgabe mit dem Status FAULT_CUSTOM_BACKUP ab. In diesem Fall kann das Rollback nicht gestartet werden!
Dateibasiertes Backup
Das dateibasierte Backup kopiert das in der Registerkarte Rollback angegebene Verzeichnis bzw. die angegebenen Dateien in folgendes Verzeichnis:
<Backup-Ordner>/<Mandant>/<Datum>/<RunID>/
Der Backup-Ordner kann in der INI-Datei der Agenten (Sektion [VARIABLES]) über die Agenten-Variable UC_EX_PATH_BACKUP definiert werden. Standardmäßig wird "..\BACKUP" (Windows) bzw. "../backup" (Unix) als Backup-Ordner verwendet - ausgehend vom zu sichernden Verzeichnis.
Während der Durchführung des dateibasierten Backups besitzt die Aufgabe den Status "Dateibasiertes Backup". Tritt dabei ein Fehler auf, bricht die Aufgabe mit dem Status FAULT_FILE_BACKUP ab. In diesem Fall kann das Rollback nicht gestartet werden!
Im Gegensatz zum Backup kann das Rollback nur für abgeschlossene Workflow-Aufgaben gestartet werden, die noch nicht deaktiviert wurden. Dafür gibt es folgende Möglichkeiten:
Voraussetzung für die Durchführung von Rollbacks ist die Option "Rollback ermöglichen", die in den Eigenschaften von Workflow-Aufgaben in der Registerkarte Allgemein zu finden ist. Ist diese Option nicht gesetzt, wird der Kontextmenü-Befehl Rollback nicht angezeigt, die Schaltlfäche "Rollback" in der Symbolleiste des Aktivitätenfensters ausgegraut und die Post-Condition ROLLBACK nicht ausgeführt. Standardmäßig ist diese Option aktiviert.
Achten Sie weiters darauf, dass die Einstellungen in der Registerkarte Rollback aktiviert und definiert wurden.
Im Rollback-Fall wird zuerst das dateibasierte (wenn verfügbar und definiert) und anschließend das benutzerdefinierte Rollback (wenn definiert) durchgeführt.
Aufgaben, die im Rollback-Modus gestartet wurden, erhalten einen Aktiv-Status und werden im Workflow-Monitor violett gekennzeichnet. Nach Abschluss des Rollbacks, gilt auch die Aufgabe als beendet.
Wird das Rollback für einen Sub-Workflow gestartet, so betrifft dies auch alle untergeordneten Aufgaben (siehe Rollback für Workflows unten).
Aufgaben ohne Rollback-Definition enden mit dem Status ENDED_ROLLBACK_EMPTY.
Eigenschaften der Workflow-Aufgaben, wie beispielsweise der späteste Startzeitpunkt, wird im Rollback-Fall ignoriert. Das logische Datum wird beibehalten.
Das Rollback-Objekt kann nur dann gestartet werden, wenn die Aufgabe nicht mit dem Status FAULT_CUSTOM_BACKUP oder FAULT_FILE_BACKUP abgebrochen ist. Beheben Sie in diesem Fall den Fehler und führen Sie einen Wiederanlauf der Aufgabe durch.
War die Rollback-Prozedur erfolgreich, erhält die Aufgabe den Ende-Status ENDED_ROLLBACKED.
Dateibasiertes Rollback
Beim dateibasierten Rollback werden die Dateien, die im Backup-Ordner für diese Aufgabe abgelegt wurden (<Backup-Ordner>/<Mandant>/<Datum>/<RunID>), in das Verzeichnis zurück-kopiert, welches in der Registerkarte Rollback angegeben ist. Ist die Option "Vor dem Wiederherstellen löschen" gesetzt, so wird der Inhalt des Ziel-Verzeichnisses davor gelöscht, um Fehler beim Kopieren zu vermeiden. Abhängig von der Option Unterverzeichnisse einbeziehen werden dabei auch Unterordner berücksichtigt.
Durch diese Prozedur wird das Verzeichnis so wiederhergestellt, wie vor der Durchführung der Aufgabe.
Während des dateibasierten Rollbacks besitzt die Aufgabe den Status "Dateibasiertes Rollback". Tritt dabei ein Fehler auf, so bricht die Aufgabe mit FAULT_FILE_ROLLBACK ab.
Um das dateibasierte Rollback unter Windows zu verwenden, muss die Windows Powershell als Standard-Interpreter aufgeführt sein und die Parameter ECPEXE= und EXPEXT= in der betreffenden INI-Datei des Windows-Agenten (Abschnitt [GLOBAL]) nutzen. Dieses Parameter sind standardmäßig gesetzt. Ein Beispiel aus der INI-Datei eines Windows-Agenten ist hier unten angeführt:
ECPEXE=C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe -file
ECPEXT=ps1
Das Backup / Rollback wird mit Objekten (FILE.BACKUP.WINDOWS bzw. FILE.ROLLBACK.WINDOWS ) durchgeführt, die standardmäßig im Mandant 0 mitgeliefert werden.
Zusätzlich ist darauf zu achten, dass das Ausführen unsignierter Scripte unter Powershell erlaubt ist. Dazu muss die Policy ggf. von restricted auf z.B. remotesigned geändert werden.
Zur Änderung der Powershell Script-Berechtigung öffnen Sie auf dem betreffenden Windows-Rechner ein Powershell-Fenster und geben z.B. die folgenden Befehle ein:
Benutzerdefiniertes Rollback
Beim benutzerdefinierten Rollback, wird das Rollback-Objekt gestartet, welches die Wiederherstellung eines ursprünglichen, funktionierenden Zustands übernehmen soll. Die Aktionen des Backup-Objektes hängen von der Aufgabe bzw. dem Backup-Objekt ab und sind vom Benutzer zu definieren.
Während der Durchführung des Rollback-Objektes besitzt die Aufgabe den Status "Benutzerdefiniertes Rollback". Kommt es dabei zu einem Fehler, bricht die Aufgabe mit FAULT_CUSTOM_ROLLBACK ab.
Handelt es sich bei der Aufgabe um einen Workflow, so wird das Rollback auch für alle untergeordneten Aufgaben durchgeführt. Dabei gibt es keine Beschränkung für die Verschachtelungstiefe.
Wird das Rollback für einen Sub-Workflow gestartet, so wechseln dessen untergeordnete Aufgaben in den Status "Wartet auf Rollback". Bei aktiven Aufgaben wird zuerst auf dessen Ende gewartet, bevor der Status geändert wird.
Danach wird das Rollback für die Aufgaben durchgeführt, wobei die Abarbeitung in umgekehrter Reihenfolge erfolgt. Begonnen wird beim Workflow-Ende und abgeschlossen beim Start. Für alle untergeordneten Workflows gilt das selbe Verhalten. Zum Abschluss werden die Rollback-Aktionen des Workflows selbst gestartet.
Falls eine Aufgabe deaktiviert wurde (d.h. sie befindet sich nicht mehr im Aktivitätenfenster), bleibt die Rollback-Durchführung an dieser Stelle stehen. Führen Sie in diesem Fall einen Wiederanlauf der Aufgabe durch oder überspringen Sie diese, um das Rollback fortzusetzen.
Der genaue Ablauf des Rollbacks pro Einzelaufgabe ist oben unter "Rollback" beschrieben.
Schlägt das Rollback einer Aufgabe fehl (FAULT_CUSTOM_ROLLBACK / FAULT_FILE_ROLLBACK), so wird die Rollback-Durchführung am betreffenden Workflow-Zeig angehalten. Sie können den Fehler beheben und anschließend das Rollback für die Aufgabe erneut starten.
Rollback von FOREACH Workflows
Beim Rollback von FOREACH-Workflows werden die Aufgaben einmal rückwarts abgearbeitet und anschließend die Rollback-Aktionen des Workflows durchgeführt.
Rollback von IF Workflows
Bei IF-Workflows wird das Rollback für jenen Aufgabenzweig vorgenommen, welcher bei der letzten Durchführung selektiert wurde. Danach werden die Rollback-Aktionen des Workflows durchgeführt.
Rollback bis zu dieser Aufgabe
Der Befehl ist im Kontextmenü enthalten, welches im Monitor aktiver Workflow für beendete Aufgaben aufgerufen wird (Aufgabe modifizieren).
Rufen Sie diesen Befehl auf, so wird zuerst der Rollback-Pfad ermittelt. Dabei handelt es sich um alle direkten und indirekten Nachfolger der Aufgabe innerhalb des Workflows. Vorgänger und parallele Aufgabe sind nicht betroffen.
Anschließend erhalten die Aufgaben auf dem Rollback-Pfad den Status "Wartet auf Rollback". Bei aktiven Aufgaben wird zuerst auf dessen Ende gewartet, bevor der Status geändert wird. Danach wird das Rollback für die betroffenen Aufgaben in umgekehrter Reihenfolge, wie diese im Workflow angeordnet sind, durchgeführt. Begonnen wird das Rollback daher beim letzten Nachfolger und abgeschlossen bei der gewählten Aufgabe.
Kommt es beim Rollback zu einem Fehler, bleibt die Durchführung am Rollback-Pfad bei der jeweiligen Aufgabe stehen. Beheben Sie den Fehler und starten Sie das Rollback der betreffenden Aufgabe erneut.
Befinden sich Workflows auf dem Rollback-Pfad, so werden diese inklusive aller untergeordneten Aufgaben zurückgerollt (siehe: Rollback von Workflows).
Die Rollback-Aktionen des Workflows selbst (wenn vorhanden), werden durch "Rollback bis zu dieser Aufgabe" nicht durchgeführt.
Fortsetzen
Der Befehl "Fortsetzen" ist im Kontextmenü (Workflow modifzieren) zu finden, welches durch Rechtsklick auf eine leere Stelle im Workflow-Monitor geöffnet wird. Der Befehl ist nur verfügbar wenn der Workflow aktiv ist und nur sinnvoll, wenn dieser mindestens eine Aufgabe mit dem Status ENDED_ROLLBACKED enthält.
Verwenden Sie den Befehl "Fortsetzen", um alle Aufgaben des betreffenden Workflows zu starten,
Für PromptSet-Variablen werden dabei die Werte der letzten Durchführung verwendet, für Objektvariablen die Werte der Objektdefinition.
Bei "Fortsetzen" spielen die Aufgaben-Eigenschaften (wie spätester Startzeitpunkt) eine Rolle. Das logische Datum wird beibehalten.
Automic Documentation - Tutorials - Automic Blog - Resources - Training & Services - Automic YouTube Channel - Download Center - Support |
Copyright © 2016 Automic Software GmbH |