jobscheduler - Flipbeets.com

Transcription

Job Automation
Job Scheduling
JOBSCHEDULER
Technical Description
August 2014
Software- und Organisations-Service GmbH
Giesebrechtstr. 15
10629 Berlin Germany
Telephone +49 30 86 47 90-0
JobScheduler
2
Impressum
Giesebrechtstr. 15
D-10629 Berlin
Telefon +49 (30) 86 47 90-0
Telefax +49 (30) 8 61 33 35
Mail [email protected]
Web www.sos-berlin.com
Letzte Aktualisierung: August 2014
August 2014
JobScheduler
3
Inhaltsverzeichnis
1 ...............................................................................................................7
1.1 Konfiguration in XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1.1 Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1.2 Codierung der XML-Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1.3 Schema der Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
1.2 Konfiguration aus Hot Folders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
1.2.1 Konfigurationsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
1.2.2 Dateien für Prozessklassen, Sperren, Jobs, Job-Ketten und Daueraufträge . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
1.2.3 Spiegelung des Verzeichnisses im JobScheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
1.2.4 Wirkung der Kommandos zum Ändern und Löschen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
1.2.5 Verhalten der einzelnen Objekttypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
1.2.5.1 Prozessklassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80
1.2.5.2 Sperren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
1.2.5.3 Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80
1.2.5.4 Job-Ketten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
1.2.5.5 Verschachtelte Job-Ketten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
1.2.5.6 Daueraufträge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
1.2.6 Kommando <show_state> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
1.3 Zentrale Konfiguration durch einen Supervisor JobScheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
1.3.1 Eine typische Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
1.3.2 Der Supervisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
1.3.3 Einen JobScheduler an den Supervisor anmelden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
1.3.4 Wirksamkeit von lokalen Änderungen an der Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
1.3.5 Übernehmen einer vorhandenen Konfiguration in die zentrale Verwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
1.3.6 Verhalten der JobScheduler beim Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
1.3.6.1 Workload JobScheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
1.3.6.2 Supervisor JobScheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
1.4 Datei factory.ini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
1.5 Datei sos.ini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
1.6 Einstellungen, die den Abruf von Umgebungsvariablen mit ${…} erlauben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95
1.6.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
1.6.2 factory.ini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
1.6.3 sos.ini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
1.7 Der Scheduler von der Kommandozeile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
1.8 JobScheduler Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
1.8.1 GUI für Konfiguration und Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
1.8.1.1 Aufruf JobScheduler Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
1.8.1.2 Scheduler Konfiguration erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
1.8.1.3 Vorhandene Konfigurationsdatei öffnen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
1.8.1.4 Empfohlene Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
1.8.1.5 Job Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
1.8.1.6 Scheduler Job Dokumentation erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
1.8.1.7 Hot Folder editieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
1.8.1.8 Remote Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
1.9 Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
1.9.1 Einstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130
1.9.2 Programmschnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
1.9.3 Kommandos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131
1.9.4 Fehlertoleranz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
1.10 Historie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
1.10.1 1. Gegenstand der Historie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
1.10.2 2. Historiendatei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
August 2014
JobScheduler
4
1.10.2.1 2.1 Einfache Dateien (tabulierte Dateien) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133
1.10.2.2 2.2 Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133
1.10.2.3 2.3 Konfiguration in der Datei factory.ini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
1.10.2.4 2.4 Startanlässe (cause) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
1.10.3 3. Task-Kennung und extra Felder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
1.10.3.1 3.1 Extra Felder in der tabulierten Datei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
1.10.3.2 3.2 Extra Felder in der Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
1.10.4 4. Lesen der Historie über die TCP-Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
1.10.5 5. Fehlerbehandlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137
1.11 Der JobScheduler als Dienst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137
1.12 Backup JobScheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
1.12.1 JobScheduler Backup Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
1.12.1.1 Voraussetzungen für den JobScheduler Backup Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140
1.12.1.2 Starten des JobScheduler Backup Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
1.12.1.3 Kommandozeilenparameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
1.12.1.4 Beenden von JobSchedulern im Backup Cluster mit den Funktionen der Web-Oberfläche . . . . . . 141
1.12.1.5 Primären JobScheduler nach Ausfall reaktivieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
1.12.1.6 Backup JobScheduler übernimmt die Verarbeitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142
1.12.1.7 Verhalten des Dienstes unter Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
1.12.1.8 Verhalten beim Neustart des Rechners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
1.12.1.9 Einen inaktiven Backup JobScheduler zum aktiven primären JobScheduler machen . . . . . . . . . . . . 143
1.12.1.10 Kommandos des Startscript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
1.12.1.11 Weiterführende Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
2 Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
2.1 Was ist ein Job? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
2.1.1 Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
2.1.2 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
2.1.3 Zustand eines Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .146
2.1.4 Zustand des Jobs ändern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
2.1.5 Eine Task starten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
2.1.6 Sperren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
2.1.7 Verzeichnisüberwachung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
2.1.8 Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .147
2.2 Spooler-Skripte als COM-Klassen implementieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148
2.3 Sperren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
2.3.1 Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
2.3.2 Sperren in Job-Ketten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
2.4 Externe Job-Verarbeitung mit Agenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
2.4.1 Verwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .154
2.4.2 Voraussetzungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
2.4.3 Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
2.4.4 Monitor-Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
2.4.5 Kontext der API-Aufrufe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
2.4.6 Konfigurations-Dateien> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
2.4.7 Protokolldateien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
3 Auftragssteuerung und Dateiverarbeitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
3.1 Aufträge und Job-Ketten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
3.1.1 Job-Ketten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
3.1.2 Auftragswarteschlange und Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .158
3.1.3 Verzeichnisüberwachung mit Dateiaufträgen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
3.1.4 Priorität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
3.1.5 Wann enden die Tasks? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
3.1.6 Beschleunigung des Auftragsdurchlaufs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .158
3.1.7 Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
3.2 Verzeichnisüberwachung mit Dateiaufträgen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
3.2.1 Dateiauftragsquelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
August 2014
JobScheduler
5
3.2.1.1 Reihenfolge der Dateiaufträge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
3.2.1.2 Mehrere Auftragsquellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
3.2.2 Der Dateiauftrag überwacht die Datei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
3.2.3 Auftragssenke: Datei verschieben oder entfernen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .160
3.2.3.1 Datei verschieben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
3.2.3.2 Datei entfernen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .160
3.2.4 Schwarze Liste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
3.2.5 Verzeichnis-Fehler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161
3.2.5.1 Fehler beim Erstellen des Dateiauftrags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
3.2.6 Wann wird das Verzeichnis gelesen? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
3.2.6.1 Verzeichnisüberwachung durch Microsoft® Windows® . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
3.2.7 Auftragsgesteuerte Nicht-API-Jobs (<process> und <script language="shell">) . . . . . . . . . . . . . . . . . . . . . . 162
3.3 Verzeichnisüberwachung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
3.3.1 Was ist eine Änderung eines Verzeichnisses? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
3.3.2 Mit Regulärem Ausdruck filtern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
3.3.3 Welches Verzeichnis hat sich geändert? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
3.3.4 Welche Dateien stehen im Verzeichnis? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162
3.3.5 Fehler bei der Verzeichnisüberwachung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163
3.3.6 Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
3.4 Verteilte Aufträge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
3.4.1 Load Balancing mit verteilten Aufträgen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
3.4.1.1 Voraussetzungen für Verteilte Aufträge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
3.4.1.2 Starten des JobScheduler Clusters für verteilte Aufträge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
3.4.1.3 Erzeugen verteilter Aufträge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
3.4.1.4 Verteilte Aufträge durch add_order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
3.4.1.5 Verteilte Dateiaufträge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
3.4.1.6 Standalone-Jobs in verteilten Schedulern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
3.4.1.7 Verteilungsalgorithmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .167
4 Protokolle und eMail-Versand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
4.1 Protokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
4.1.1 Umfang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
4.1.2 Meldungs-Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
4.1.3 Plattenplatzmangel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
4.1.4 Ablage in den Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
4.1.5 Programmschnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
4.1.6 eMail-Versand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
4.1.7 Anzeigen der Protokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
4.2 eMail-Versand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
4.2.1 Einstellungen zur eMail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
4.2.2 eMails nach dem Ende einer Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
4.2.3 Rangfolge der Einstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
4.2.4 eMails, wenn der JobScheduler wegen eines Fehlers sich beendet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
4.2.5 Installation mit JavaMail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171
4.3 Log Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
5 Kommunikation und Bedienung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
5.1 HTTP Server und Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
5.1.1 Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
5.1.2 Bedienung über einen Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
5.1.3 Zugriffsschutz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
5.1.4 Protokolle mit einem Browser zeigen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .174
5.1.5 Job-Beschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
5.1.6 Built-In Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
5.2 XML-Kommandos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
5.2.1 XML-Antworten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .206
5.3 Beendigung des Schedulers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
5.3.1 Ordentliches Beenden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
August 2014
JobScheduler
6
5.3.2 Ordentliches Beenden mit Frist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
5.3.3 Abbruch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Anhang A: Meldungen des Schedulers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
A.1 Messages für Paket Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
A.2 Messages für Paket Separate processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
A.3 Messages für Paket Charset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Anhang B: Änderungsprotokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Anhang C: Vom JobScheduler verwendete SQL-Anweisungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
C.1 Vom JobScheduler verwendete SQL-Anweisungen für DB2® . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
C.2 Vom JobScheduler verwendete SQL-Anweisungen für Microsoft SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
C.3 Vom JobScheduler verwendete SQL-Anweisungen für MySQL® . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
C.4 Vom JobScheduler verwendete SQL-Anweisungen für Oracle® . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
C.5 Vom JobScheduler verwendete SQL-Anweisungen für PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
C.6 Vom JobScheduler verwendete SQL-Anweisungen für Sybase ASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Anhang D: Skripte in JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
D.1 Java-Exceptions in Spidermonkey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Stichwortverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
August 2014
7
1
1.1 Konfiguration in XML
Beim Start des JobScheduler geben Sie die Datei an, die die mit XML formulierte Konfiguration enthält.
1.1.1 Beispiel
Eine einfache Konfigurationsdatei mit einem Shell Job:
<?xml version="1.0"?>
<spooler>
<config>
<jobs>
<job name="hallo_welt">
<script language="shell"><![CDATA[
echo hallo welt
]]></script>
<run_time repeat="10"/>
</job>
</jobs>
</config>
</spooler>
Konfiguriert ist hier der Job hallo_welt, den der JobScheduler alle 10 Sekunden wiederholen wird.
Wenn diese Konfiguration in der Datei hallo_welt.xml abgelegt ist, können Sie den JobScheduler so starten (für
Windows):
…scheduler installation path…\bin\scheduler.exe -config=hallo_welt.xml
Ein gestarteter JobScheduler kann mit Ctrl-C abgebrochen werden.
Alternativ können individuelle Konfigurationsdateien pro Job, Jobkette etc. gebildet werden, die nur die von diesem
Objekt benötigten Elemente enthalten:
<?xml version="1.0">
<job>
echo hallo welt
]]></script>
<run_time repeat="10"/>
</job>
Wenn diese Konfiguration in der Datei scheduler installation path/config/live/hallo_welt.job.xml
abgelegt ist, wird sie automatisch von einem laufenden JobScheduler verwendet:
August 2014
8
1.1.2 Codierung der XML-Konfiguration
<?xml encoding="UTF-8"?> und
<?xml encoding="ISO-8859-1"?> sind möglich.
Der JobScheduler verarbeitet nur 8bit-Zeichen (ISO-8859-1).
1.1.3 Schema der Konfiguration
Der JobScheduler prüft die XML-Konfiguration gegen das XML-Schema des Schedulers (Nur im IE korekt
dargestellt.)
Klicken Sie auf ein XML-Element, um dessen Beschreibung zu sehen.
<spooler>
<config central_configuration_directory = "…"
configuration_add_event
= "…"
configuration_delete_event = "…"
configuration_directory
= "…"
configuration_update_event = "…"
include_path
= "…"
ip_address
= "…"
log_dir
= "…"
mail_xslt_stylesheet = "…"
param
= "…"
port
= "4444"
priority_max
= "1000"
spooler_id
= ""
supervisor
= "hostname:4444"
tcp_port
= "4444"
udp_port
= "4444"
time_zone
= "...">
<base file="…"/>
<params>
<param name="…" value="…"/>
</params>
<security>
<allowed_host name="…" level="…"/>
…
</security>
<cluster heart_beat_own_timeout = "…"
heart_beat_timeout
= "…"
heart_beat_warn_timeout = "…"/>
<process_classes ignore = "no">
<process_class max_processes = "…"
name
= "…"
spooler_id
= "…"/>
…
</process_classes>
August 2014
9
<schedules>
<schedule name
substitute
valid_from
valid_to
…
</schedules>
=
=
=
=
"…"
"…"
"…"
"…"/>
<locks>
<lock name= "…" …/>
…
</locks>
<script com_class = "…"
filename
= "…"
java_class = "…"
language
= "…" >
<include file="…"/>
<![CDATA[
programm-code…
]]>
</script>
<http_server>
<http.authentication scheme="basic">
<http.users>
<http.user name="…" password_md5="…"/>
…
</http.users>
</http.authentication>
<http_directory path="…" url_path="…"/>
<web_service job_chain="…" url_path="…" …>
<params>
…
</params>
</web_service>
…
</http_server>
<holidays>
<holiday date="…"/>
<weekdays date="…"/>
</holidays>
<jobs>
<job
force_idle_timeout = "yes|no"
idle_timeout
= "…"
ignore_signals = "…"
java_options
= "…"
min_tasks
= "…"
August 2014
10
name
order
priority
process_class
spooler_id
stop_on_error
tasks
temporary
timeout
title
visible
=
=
=
=
=
=
=
=
=
=
=
"…"
"no"
"…"
"…"
"…"
"yes"
"1"
"no"
"…"
"…"
"yes"
>
<settings>
…
</settings>
<description> … </description>
<lock.use lock="…" …/>
<environment>
<variable name="…" value="…"/>
…
</environment>
<params>
…
</params>
<script com_class = "…"
filename
= "…"
java_class = "…"
language
= "…" >
<![CDATA[ programm-code… ]]>
</script>
oder
<process file
= "…"
ignore_error = "no"
ignore_signal= "no"
log_file
= ""
param
= "" >
</process>
<monitor name
= "…"
ordering
= "…">
<script language="…" …>…<script/>
</monitor>
<start_when_directory_changed
directory="…"
<delay_after_error
error_count="…" />
delay="…"
<delay_order_after_setback
delay="…"
regex="…" />
is_maximum="yes|no"
August 2014
11
setback_count="…" />
<run_time let_run="no">
<period begin
end
let_run
repeat
single_start
when_holiday
=
=
=
=
=
=
"00:00"
"24:00"
"…"
"…"
"…"
"…"
/>
<date date="yyyy-mm-dd"/>
…
<weekdays>
<day day="…">
<period …/>
…
</day>
…
</weekdays>
<monthdays>
<day day="…">
<period …/>
…
</day>
<weekday weekday="…" which="…">
<period …/>
…
</weekday>
…
</monthdays>
<ultimos>
<day day="…">
<period …/>
…
</day>
…
</ultimos>
<month month="…">
<period begin
end
let_run
repeat
single_start
<weekdays>
<day day="…">
<period …/>
…
</day>
…
</weekdays>
<monthdays>
<day day="…">
=
=
=
=
=
"00:00"
"24:00"
"…"
"…"
"…"
/>
August 2014
12
<period …/>
…
</day>
<weekday weekday="…" which="…">
<period …/>
…
</weekday>
…
</monthdays>
<ultimos>
<day day="…">
<period …/>
…
</day>
…
</ultimos>
…
</month>
<holidays>
<holiday date="yyyy-mm-dd"/>
…
</holidays>
<at at="yyyy-mm-dd HH:MM:SS"/>
</run_time>
<commands on_exit_code="…">
<start_job job="…" …>
<params>
<copy_params from="task"/>
<copy_params from="order"/>
…
</params>
</start_job>
<add_order job_chain="…" …>
<params>
<copy_params from="task"/>
<copy_params from="order"/>
…
</params>
</add_order>
…
</commands>
</job>
…
</jobs>
<job_chains>
<job_chain
distributed
= "no"
August 2014
13
name
=
orders_recoverable=
title
=
visible
=
"…"
"yes"
"…"
"yes"
>
<file_order_source
delay_after_error = "…"
directory
= "…"
max
= "…"
next_state
= "…"
regex
= "…"
repeat
= "…"
/>
…
<job_chain_node
delay
= "…"
error_state = "…"
job
= "…"
next_state = "…"
on_error
= "suspend|resume"
state
= "…"
/>
…
<file_order_sink
move_to
= "…"
remove
= "yes"
state
= "…"
/>
…
</job_chain>
<job_chain name="…">
<job_chain_node.job_chain
job_chain
= "…"
error_state = "…"
next_state = "…"
state
= "…"
/>
…
<job_chain_node.end
state
= "…"
/>
…
</job_chain>
…
</job_chains>
<commands>
…
</commands>
</config>
</spooler>
August 2014
14
XML-Elemente
XML-Element <add_order>
<add_order
job_chain
id
replace
priority
title
state
web_service
at
end_state
= "name"
= "id"
= "yes|no"
= "zahl"
= "text"
= "text"
= "name"
= "timestamp"
= "text"
Startzeit des Auftrags
Zustand, vor dessen erfolgreichen Verlassen
der Auftrag enden soll
>
params
run_time
xml_payload
</add_order>
Parameter
Laufzeiten
Fügt einen neuen Auftrag hinzu.
Wenn Sie das Element <params> angegeben, erstellt der JobScheduler ein Variable_set und stellt es dem Job in
Order.payload() zur Verfügung.
Beispiel:
<add_order job_chain="jobkette" id="1234" title="Mein erster Auftrag" state="100"
at="now+3:00">
<params>
<param name="ein_parameter" value="ein Wert"/>
</params>
</add_order>
Eltern Elemente
<commands> - XML-Kommandos
Attribute
job_chain="name"
Die Jobkette, in die der Auftrag eingetragen werden soll.
id="id"
Die Kennung des Auftrags (alphanumerisch).
replace="yes|no" (Initialwert:yes)
replace="no": Job_chain.add_order() wird gerufen.
replace="yes": Job_chain.add_or_replace_order() wird gerufen.
August 2014
15
priority="zahl"
title="text"
Der Titel des Auftrags.
state="text"
web_service="name"
Wenn der Auftrag ausgeführt worden ist (das Ende der Jobkette erreicht hat), wird er mit einem Stylesheet
transformiert und einem Web-Dienst übergeben.
Siehe <web_service> (Seite 73).
at="timestamp" (Initialwert:now) Startzeit des Auftrags
"now", "yyyy-mm-dd HH:MM[:SS]", "now + HH:MM[:SS]" und "now + SECONDS" sind möglich.
Siehe auch Order.at .
end_state="text" Zustand, vor dessen erfolgreichen Verlassen der Auftrag enden soll
Wie Order.end_state .
XML-Element <allowed_host>
<allowed_host
host
level
> </allowed_host>
= "host"
= "level"
<allowed_host> gibt den Namen oder die IP-Nummer eines Rechners an, der Verbindung mit dem JobScheduler
aufnehmen darf.
Die IP-Nummer kann eine Netzwerkadresse sein (Klasse A, B oder C). Dann werden alle Rechner des Netzwerks
zugelassen. Das ist der Fall, wenn der letzte Teil der IP-Nummer 0 ist. Der JobScheduler beachtet eine genau
angegebene IP-Nummer vor einer Netzwerkadresse.
Beispiel:
<security>
<allowed_host host="127.0.0.1"
level="all"/>
<allowed_host host="admin.company.com" level="all"/>
<allowed_host host="192.168.1.0"
level="info"/>
</security>
Die IP-Adressen 127.0.0.1 und admin.company.com und die Adressen im Klasse-C-Netzwerk 192.168.1 dürfen sich
mit dem JobScheduler verbinden. Der letzte Eintrag beschränkt die Kommandos auf die, die Informationen liefern.
August 2014
16
Beispiel:
<security>
<allowed_host host="0.0.0.0" level="all"/>
</security>
Jeder Rechner hat vollen Zugriff.
Verhalten mit <base>
Ergänzt ein Element <allowed_host> an der entsprechenden Stelle mit gleichem Attribut host= aus der
Basiskonfiguration. Hier angegebene Attribute überschreiben die aus der Basiskonfiguration.
Eltern Elemente
<security> - Zugriffsschutz für TCP, HTTP und UDP
Attribute
host="host"
host ist der Name oder die IP-Adresse des Rechners, für den der Zugriffsschutz eingestellt werden soll. Es kann
auch die IP-Nummer eines Netzwerks sein.
Ein Eintrag mit host="0.0.0.0" gilt für alle sonst hier nicht angegebenen Hosts.
level="level"
level="none"
Der Rechner hat keinen Zugriff.
level="signal"
Der Rechner darf signalisierende Kommandos ausführen.
level="info"
Der Rechner darf Kommandos ausführen, die Informationen liefern, aber den Zustand des Schedulers nicht
ändern.
level="no_add"
Der Rechner hat vollen Zugriff, nur <add_jobs> , <job> und <add_order> sind gesperrt.
level="all"
Der Rechner hat vollen Zugriff.
XML-Element <at>
<at
at
> </at>
= "yyyy-mm-dd hh:mm[:ss]"
August 2014
17
Eltern Elemente
<run_time> - Laufzeiten
Attribute
at="yyyy-mm-dd hh:mm[:ss]"
Legt einen Startzeitpunkt mit Datum und Uhrzeit fest.
XML-Element <base>
<base
file
> </base>
= "filename"
Mit <base> können Sie eine Basiskonfiguration angegeben. Eine Basiskonfiguration liegt in einer eigenen Datei mit
demselben Aufbau einer XML-Konfiguration (Seite 7) (sie beginnt also wieder mit <spooler> ). In der
Basiskonfiguration können Sie Einstellungen vornehmen, die die übergeordnete Konfiguration (die das Element <
base> enthält) ergänzt oder überschreibt.
Der JobScheduler verarbeitet die Basiskonfiguration zuerst.
Zum Beispiel kann die Basiskonfiguration die Jobs definieren, während die übergeordnete Konfiguration die
Laufzeiten ( <run_time> ) einstellt.
Eine Basiskonfiguration kann auf eine weitere Basiskonfiguration verweisen. Der JobScheduler prüft nicht, ob eine
Basiskonfiguration selbstbezüglich aufgerufen wird.
<base> können Sie wiederholt angeben. Der JobScheduler arbeitet sie der Reihe nach ab. Die zweite
Basiskonfiguration ergänzt oder überschreibt die Einstellungen der ersten.
Eltern Elemente
<config> - Konfiguration
Attribute
file="filename"
filename gibt den Dateinamen der Basiskonfiguration an.
Wenn der Dateiname nicht absolut ist, geht der JobScheduler vom Verzeichnis der Konfigurationsdatei aus, die das
<base>-Element enthält.
Die XML-Elemente in der Basiskonfiguration werden mit dem Recht <allowed_host level="all"> ausgeführt.
Umgebungsvariablen (z.B. $HOME) werden ersetzt (s. Ersetzung von Umgebungsvariablen (Seite 95)).
XML-Element <cluster>
<cluster
heart_beat_timeout
heart_beat_own_timeout
heart_beat_warn_timeout
> </cluster>
= "seconds"
= "seconds"
= "seconds"
August 2014
18
Das Elememt wirkt nur in Verbindung mit den Optionen -exclusive oder -distributed-orders .
Ergänzt ein Element <cluster> an der entsprechenden Stelle aus der Basiskonfiguration. Hier angegebene
Attribute überschreiben die aus der Basiskonfiguration.
Eltern Elemente
Attribute
heart_beat_timeout="seconds" (Initialwert:60)
Wenn der Herzschlag eines anderen aktiven Schedulers im Cluster sich um diese Frist verspätet, wird der dieser
JobScheduler für tot erklärt.
Wenn der eigene JobScheduler inaktiv ist und mit der Option -exclusive betrieben wird, kann er anschließend
aktiv werden.
Meldungen
[warn]
SCHEDULER-836
Deactivating that dead Scheduler [warn]
SCHEDULER-996
No heart beat for seconds (time) - JobScheduler seems to be dead heart_beat_own_timeout="seconds" (Initialwert:55)
Die Einstellung dient zur Selbstkontrolle des Schedulers. Wenn der eigene Herzschlag sich um diese Frist
verspätet, bricht der JobScheduler sofort ab und startet sich neu. Damit kommt der JobScheduler der
Deaktivierung durch einen anderen JobScheduler zuvor, und verhindert den kurzzeitigen Parallelbetrieb wegen
verzögerten Herzschlags.
Meldungen
[ERROR]
SCHEDULER-386
Last heart beat was time, seconds ago. Something is delaying JobScheduler
execution, the JobScheduler is aborted immediately heart_beat_warn_timeout="seconds" (Initialwert:10)
Wenn der Herzschlag eines Schedulers sich um diese Frist verspätet, wird eine Warnung ausgegeben.
Meldungen
[warn]
SCHEDULER-994
No heart beat for seconds (time), expecting heart beat within seconds [warn]
SCHEDULER-995
No heart beat for seconds (time), ignored for seconds because of recent
database reconnect Software- und Organisations-Service GmbH
August 2014
19
XML-Element <commands>
<commands
on_exit_code
= "exitcodes"
>
add_jobs
add_order
Auftrag hinzufügen
licence.use
modify_job
modify_order
modify_spooler
scheduler_log.log_categ
ories.reset
ories.set
ories.show
show_history
show_job
show_jobs
show_job_chains
show_state
start_job
Eine Task starten
terminate
</commands>
Das Element fasst eine Folge von Kommandos zusammen. Wann die Kommandos ausgeführt werden, hängt vom
Eltern-Element ab.
Eltern Elemente
<job> - Definition eines Jobs
Attribute
on_exit_code="exitcodes"
Innerhalb von <job> ist dieses Attribut Pflicht, woanders kann es nicht verwendet werden.
Gibt die Exit-Codes an, die zur Ausführung der hier aufgeführten Kommandos führen sollen. Als Wert kann
angegeben werden:
•
•
•
•
•
Eine Liste von Exit-Codes, die einzelnen Zahlen durch Blanks getrennt.
on_exit_code="success" ist dasselbe wie on_exit_code="0".
on_exit_code="error" gilt für alle Exit-Codes außer 0 und außer der bereits in anderen <commands
exit_code="…"> angegeben Exit-Codes.
Nur Unix: Eine mit Signal beendete Task (durch kill oder Programmfehler) hat einen Exit-Code mit dem
negativen Wert des Signals. Bei dem Betriebssystem-Kommando kill auf die Task wäre das -15.
Die Signalnamen können angegeben werden: SIGHUP, SIGINT, SIGQUIT, SIGILL, SIGTRAP, SIGABRT, SIGIOT,
SIGBUS, SIGFPE, SIGKILL, SIGUSR1, SIGSEGV, SIGUSR2, SIGPIPE, SIGALRM, SIGTERM, SIGSTKFLT, SIGCHLD,
SIGCONT, SIGSTOP, SIGTSTP, SIGTTIN, SIGTTOU, SIGURG, SIGXCPU, SIGXFSZ, SIGVTALRM, SIGPROF, SIGWINCH,
SIGPOLL, SIGIO, SIGPWR und SIGSYS. Signal-Namen, die das Betriebsystem nicht kennt, werden mit Warnung
ignoriert.
Siehe auch <job ignore_signals="…"> (Seite 37).
August 2014
20
Beispiel:
on_exit_code="0"
on_exit_code="1 2 3 99"
on_exit_code="error"
on_exit_code="SIGTERM SIGKILL"
Meldungen
[ERROR]
SCHEDULER-324
Invalid value for attribute exit_code="" in <commands> [ERROR]
SCHEDULER-325
Attribute exit_code is not applicable here [ERROR]
SCHEDULER-326
<commands on_exit_code="">: <commands> for exit code is already defined [ERROR]
SCHEDULER-327
Last error occurred when executing command: xml_command [warn]
SCHEDULER-337
Signal is unknown on this operating system and is ignored [info]
SCHEDULER-328
Executing <commands on_exit_code="">: XML-Element <config>
<config
central_configuration_direc
tory
configuration_directory
configuration_add_event
configuration_modify_event
= "path"
= "path"
= "job_path"
= "job_path"
configuration_delete_event = "job_path"
supervisor
spooler_id
port
tcp_port
= "host:port"
= "spooler_id"
= "number"
= "number"
udp_port
= "number"
param
log_dir
time_zone
include_path
mail_xslt_stylesheet
= "text"
= "verzeichnis"
= "text"
= "verzeichnis"
= "path"
ip_address
= "ip_number"
Lokales Konfigurationsverzeichnis
Job für neue Konfigurationsdatei
Job
für
geänderte
Konfigurationsdatei
Job
für
gelöschte
Konfigurationsdatei
Portnummer für TCP und UDP
HTTP- und TCP-Port für
Kommandos an den JobScheduler
UDP-Port für Kommandos an den
JobScheduler
Zur freien Verwendung
Verzeichnis der Protokolle
Zeitzone des JobSchedulers
Verzeichnispfad für <include>
Pfad des XSLT-Stylesheets zur
eMail-Aufbereitung
IP-Adresse der Schnittstelle für
TCP und UDP
>
base
params
security
cluster
process_classes
script
scheduler_script
http_server
holidays
Basiskonfiguration
Parameter
Zugriffsschutz für TCP, HTTP und UDP
Einstellungen für den Cluster-Betrieb
Prozessklassen
Programm-Code
HTTP-Server
Feiertage
August 2014
21
jobs
job_chains
commands
</config>
Jobs
Jobketten
XML-Kommandos
<config> enthält die Konfiguration des Schedulers, vor allem die Jobs. Das Element kann wiederholt werden,
wenn das Attribut spooler_id wechselt. Wenn bei Scheduler-Start der Parameter -id= nicht angegeben worden
ist, ist das erste <config>, sonst das mit gleichem Wert im Attribut spooler_id wirksam.
Ergänzt ein Element <config> an der entsprechenden Stelle mit gleichem Attribut spooler_id= aus der
Eltern Elemente
<spooler> - Wurzelelement des XML-Dokuments
Attribute
central_configuration_directory="path" (Initialwert:remote)
Voreingestellt ist das Verzeichnis remote im Verzeichnis der Konfigurationsdatei, siehe -config .
Das Verzeichnis ist für den Supervisor-Betrieb, bei dem andere JobScheduler sich anmelden mit <config
supervisor="…"> . Das Verzeichnis kann für jeden JobScheduler ein Unterverzeichnis mit Konfigurationsdateien
enthalten, die der Supervisor zum JobScheduler laufend repliziert.
JobScheduler in einem Cluster ( -exclusive oder -distributed-orders ) erhalten ihre Konfiguration aus einem
Verzeichnis mit dem Namen der Scheduler-ID ( -id ).
Scheduler, die nicht zu einem Cluster gehören, erhalten Ihre Konfiguration aus einem Verzeichnis, dessen Name
aus Rechnername und TCP-Portnummer ( <config tcp_port="…"> ) gebildet wird: hostname#tcpport .
Für beide Fälle gilt, dass zusätzlich Dateien aus dem Verzeichnis _all übertragen werden. Diese Dateien sind
nachrangig.
Es ist möglich, für einen JobScheduler kein Verzeichnis anzugeben. Dann wird nur die Konfiguration aus dem
Verzeichnis _all, falls vorhanden, übertragen.
Meldungen
[warn]
SCHEDULER-454
Remote configuration directories '' and '' refer to the same IP number [warn]
SCHEDULER-457
Remote JobScheduler '' has not been registered [info]
SCHEDULER-455
No configuration directory for '' configuration_directory="path" (Initialwert:live) Lokales Konfigurationsverzeichnis
Voreingestellt ist das Verzeichnis live im Verzeichnis der Konfigurationsdatei, siehe -config .
Diesem Verzeichnis entnimmt der JobScheduler die Definitionen der Jobs usw., siehe (Seite 78).
configuration_add_event="job_path" Job für neue Konfigurationsdatei
August 2014
22
Der angegebene Job wird gestartet, wenn der JobScheduler eine neue Datei aus dem Konfigurationsverzeichnis
geladen hat.
Der Job wird gestartet, so wie es seine <run_time> zulässt. Er sollte in der Scheduler-Konfigurationsdatei definiert
sein, damit er bekannt ist, wenn der JobScheduler das Konfigurationsverzeichnis liest.
Die gestartete Task hat drei Parameter (erreichbar über Task.params ):
Diese
Task-Parameter
stehen
auch
bereit
als
Umgebungsvariablen
SCHEDULER_LIVE_EVENT,
SCHEDULER_LIVE_FILEPATH und SCHEDULER_LIVE_FILEBASE.
configuration_modify_event="job_path" Job für geänderte Konfigurationsdatei
Der angegebene Job wird gestartet, wenn der JobScheduler eine geänderte Datei aus dem
Konfigurationsverzeichnis geladen hat.
Parameter und Umgebungsvariablen sind gesetzt wie bei <config configuration_add_event="…"> .
configuration_delete_event="job_path" Job für gelöschte Konfigurationsdatei
Der angegebene Job wird gestartet, wenn aus dem Konfigurationsverzeichnis eine im JobScheduler geladene
Datei entfernt worden ist.
Parameter und Umgebungsvariablen sind gesetzt wie bei <config configuration_add_event="…"> .
supervisor="host:port"
Der Supervisor, bei dem sich dieser JobScheduler an- und abmelden soll. Das geschieht asynchron und Fehler
beeinträchtigen nicht den Betrieb.
Wenn der Haupt-Scheduler unter Windows läuft, sollten nicht mehr als vier JobScheduler sich bei ihn anmelden.
Der
Supervisor kann für den JobScheduler die Konfiguration bestimmen, s. <c o n f i g
central_configuration_directory="…"> . Die übernommene Konfiguration hält der JobScheduler im
Verzeichnis cache.
spooler_id="spooler_id"
Das Element ist nur wirksam, wenn dieses Attribut gleich dem Parameter -id= vom Scheduler-Start ist, oder wenn
beim Scheduler-Start der Parameter -id= nicht angegeben worden ist.
port="number" (Initialwert:0) Portnummer für TCP und UDP
Fasst die Einstellungen tcp_port und udp_port zusammen.
Siehe auch <config tcp_port="…"> (Seite 20). und <config udp_port="…"> (Seite 20).
August 2014
23
Beispiel:
<config port="4444">
Die Option -port hat Vorrang.
tcp_port="number" (Initialwert:0) HTTP- und TCP-Port für Kommandos an den JobScheduler
Der JobScheduler kann auf einem TCP-Port während des Betriebs Kommandos entgegennehmen. Hier kann eine
Portnummer eingestellt werden. Die Portnummer ist eine Zahl zwischen 2048 (betriebssystemabhängig) und
65535. Die Voreinstellung lautet 4444.
Über denselben Port betreibt der JobScheduler einen HTTP/HTML-Server, so dass er über einen Browser
ansprechbar ist, z.B. http://localhost:4444.
Bei tcp_port=0 (voreingestellt) ist der JobScheduler nicht über TCP oder HTTP ansprechbar. Damit kann die
Steuerung des JobSchedulers per TCP-Kommando, z.B. über eine Web-Seite, unterbunden werden.
Siehe auch <config port="…"> (Seite 20).
Beispiel:
<config tcp_port="4444">
Die Option -tcp-port hat Vorrang.
udp_port="number" (Initialwert:0) UDP-Port für Kommandos an den JobScheduler
Auch über UDP kann der JobScheduler Kommandos entgegennehmen. Hier wird die Portnummer angegeben. Ein
Kommando muss in eine Nachricht passen. Der JobScheduler schickt keine Antwort.
Bei udp_port=0 (voreingestellt) öffnet der JobScheduler keinen UDP-Port.
Siehe auch <config port="…"> (Seite 20).
Beispiel:
<config udp_port="4444">
Die Option -udp-port hat Vorrang.
param="text" Zur freien Verwendung
Setzt spooler.param (Objekt spooler, Eigenschaft param). Zur freien Verwendung in den Skripten.
log_dir="verzeichnis" Verzeichnis der Protokolle
Gibt das Verzeichnis an, an das der JobScheduler die Protokoll schreibt.
log_dir="*stderr" lässt den JobScheduler das Hauptprotokoll nach stderr schreiben.
time_zone="text" Zeitzone des JobSchedulers
August 2014
24
Bestimmt nach welcher Zeitzone ein Auftrag bzw. Job startet. Die Angabe einer Zeitzone folgt dabei der tz
Datenbank. Eine Liste möglicher Zeitzonen befindet sich in der Dokumentation der Joda API, welche für die
Zeitfunktionen verwendet wird.
Fehlt die Angabe einer Zeitzone, arbeitet der JobScheduler mit der locale Einstellung des Rechners.
Beispiel:
<config time_zone="Europe/Berlin">
Die Option -time-zone hat Vorrang.
include_path="verzeichnis" Verzeichnispfad für <include>
Verzeichnis der Dateien, die mit <include> eingezogen werden.
Die Option -include-path hat Vorrang.
Die Einstellung factory.ini (Abschnitt [spooler], Eintrag include_path= …) wird damit überschrieben.
mail_xslt_stylesheet="path" Pfad des XSLT-Stylesheets zur eMail-Aufbereitung
Der Pfad eines XSLT-Stylesheets. Der JobScheduler verwendet das XSLT-Stylesheet zum Aufbereiten der eMails.
(Die Dokumentation hierzu ist noch nicht geschrieben.)
ip_address="ip_number" (Initialwert:0.0.0.0) IP-Adresse der Schnittstelle für TCP und UDP
Die IP-Adresse, an die TCP- und UDP-Port gebunden werden. Der JobScheduler ist dann nur über diese
IP-Adresse erreichbar.
Ein Hostname kann angegeben werden.
Default ist 0.0.0.0, was für alle IP-Adressen steht.
Wenn eine andere IP-Adresse als 127.0.0.1 oder localhost angegeben ist, kann der JobScheduler nicht über
localhost erreicht werden.
Die Option -ip-address hat Vorrang.
XML-Element <content>
<content > </content>
Eltern Elemente
<service_request> - Web-Dienst-Anforderung
XML-Element <copy_params>
<copy_params
from
> </copy_params>
= ""
Quelle der Parameter
August 2014
25
Das Element übernimmt die Parameter der Task oder des Auftrags. Es kann in <start_job> und <add_order> in
folgender Hierarchie verwendet werden:
<job>
…
<commands on_exit_value="…">
…
<start_job>
oder <add_order>
…
<params>
…
<copy_params from="order">
Bei doppelten Parameternamen entscheidet die Reihenfolge von <copy_params> und <param> , welcher
Parameterwert verwendet wird. Ein nachfolgender Parameter überschreibt einen vorangehenden mit gleichen
Namen.
Eltern Elemente
<params> - Parameter
Attribute
from="" Quelle der Parameter
from="task"
Die Parameter der Task ( Task.params ) werden übernommen.
from="order"
Die Parameter des zuletzt ausgeführten Auftrags ( Order.params ) werden übernommen. Der Auftrag steht
am Ende der Task nur zur Verfügung, wenn
•
•
•
der Job mit <process> oder <script language="shell"> implementiert ist,
während der Ausführung Task.end() aufgerufen worden ist oder
während der Ausführung ein Fehler aufgetreten ist.
Es ist ein Fehler ( SCHEDULER-329 ), wenn der Job nicht auftragsgesteuert ist ( <job order="no"> ).
Meldungen
[ERROR]
SCHEDULER-329
<copy_params from=""/>: requested parameters are not available Software- und Organisations-Service GmbH
August 2014
26
XML-Element <date>
<date
date
>
period
</date>
= "yyyy-mm-dd"
Periode
setzt die Perioden für einen bestimmten Tag fest.
Siehe auch <at> (Seite 16).
Beispiel:
<date date="2004-08-22">
<period begin="10:00" end="12:00"/>
</date>
Beispiel:
<date date="2004-09-02" begin="14:00" end="18:00"/>
Ersetzt ein Element <date> an der entsprechenden Stelle mit gleichem Attribut date= aus der Basiskonfiguration.
Eltern Elemente
Attribute
date="yyyy-mm-dd"
Das Datum.
XML-Element <day>
<day
day
>
period
</day>
= "zahl"
Periode
Setzt die Perioden für einen bestimmten Tag fest.
Ersetzt ein Element <day> an der entsprechenden Stelle mit gleichem Attribut day= aus der Basiskonfiguration.
August 2014
27
Eltern Elemente
<weekdays> - Perioden für bestimmte Wochentage
<monthdays> - Perioden für bestimmte Tage des Monats
<ultimos> - Perioden für bestimmte Tage des Monats, vom Ende her gezählt
Attribute
day="zahl"
Gibt die Nummer des Tages an, abhängig vom Eltern-Element, bei Wochentagen auch die englischen Namen.
Mehrere Tage können durch Leerzeichen getrennt angegeben werden.
XML-Element <delay_after_error>
<delay_after_error
error_count
delay
= "integer"
=
"seconds|HH:MM|HH:MM:SS|stop"
> </delay_after_error>
Siehe Job.delay_after_error .
Beispiel:
<job …>
<script …>…</script>
<delay_after_error error_count= "2"
<delay_after_error error_count= "5"
<delay_after_error error_count="10"
<delay_after_error error_count="20"
</job>
delay="10"
delay="00:01"
delay="24:00"
delay="STOP"
/>
/>
/>
/>



Nach einem Fehler wiederholt der JobScheduler den Job sofort.
Nach dem zweiten bis zum vierten Fehler verzögert der JobScheduler den Job um 10 Sekunden,
nach dem fünften bis zum neunten Fehler um eine Minute,
nach dem zehnten bis zum neunzehnten um 24 Stunden,
nach dem zwanzigsten aufeinanderfolgenden Fehler schließlich stoppt der Job.
Eltern Elemente
Attribute
error_count="integer"
Anzahl der aufeinanderfolgenden Jobfehler, ab der die Verzögerung gilt.
delay="seconds|HH:MM|HH:MM:SS|stop"
Frist, nach der der Job wiederholt wird.
August 2014
28
delay="stop" oder delay="STOP" lässt den Job bei dieser Anzahl aufeinanderfolgender Fehler stoppen.
XML-Element <delay_order_after_setback>
<delay_order_after_setback
setback_count
= "integer"
delay
= "seconds|HH:MM|HH:MM:SS"
is_maximum
= "yes|no"
> </delay_order_after_setback>
- nach dem ersten Fehlversuch wird der Job im Abstand von 10min erneut ausgeführt.
- nach dem fünften Fehlversuch wird der Job nur noch im Abstand von 30min ausgeführt.
- Nach dem zehnten Fehlversuch läuft der Job noch 1x und bricht bei erneutem Fehler ab.
Beispiel:
<delay_order_after_setback setback_count="1" is_maximum="no" delay="00:10"/>
<delay_order_after_setback setback_count="5" is_maximum="no" delay="00:30"/>
<delay_order_after_setback setback_count="10" is_maximum="yes" />
Siehe Job.delay_order_after_setback , Job.max_order_setbacks und Order.setback() .
Eltern Elemente
Attribute
setback_count="integer"
Für die 1., 2. usw. aufeinanderfolgende Rückstellung desselben Auftrags können verschiedene Fristen eingestellt
werden.
Gibt an, ab der wievielten Rückstellung des Auftrags dieses XML-Element gilt.
Z.B. bei setback_count=5 gilt das Element erst ab der 5. Rückstellung.
delay="seconds|HH:MM|HH:MM:SS"
Frist für die Rückstellung. Nach Ablauf der Frist kommt der Auftrag erneut in diesem Job zu Ausführung.
is_maximum="yes|no" (Initialwert:no)
Attribut setback_count= gibt die maximale Anzahl aufeinanderfolgender Rückstellungen an. Bei einer weiteren
Rückstellung ( Order.setback() ) versetzt der JobScheduler den Auftrag in den Fehlerzustand
Job_chain_node.error_state .
Siehe Job.max_order_setbacks .
XML-Element <description>
<description >
include
</description>
Fügt Text aus einer Datei ein
August 2014
29
Eine Beschreibung des Jobs, die in der HTML-Oberfläche gezeigt wird. Der Text sollte in HTML codiert sein (das ist
wegen der strikten DTD des Schedulers nur möglich, wenn Sie <![CDATA[...]]> oder <include> verwenden).
Beispiel:
<job name="my_job">
<description>
Here follows the description of the job:
<include file="description_of_my_job.txt"/>
</description>
...
</job>
Ersetzt ein Element <description> an der entsprechenden Stelle aus der Basiskonfiguration.
Eltern Elemente
XML-Element <environment>
<environment >
variable
</environment>
Eine Variable
Bestimmt die zusätzlichen Umgebungsvariablen für einen Prozess.
Eltern Elemente
<process> - Externes Programm (alternativ zu <script>)
<start_job> - Eine Task starten
XML-Element <file_order_sink>
<file_order_sink
state
remove
move_to
> </file_order_sink>
= "string"
= "yes|no"
= "directory_path"
<file_order_sink> ist mit dem internen Job scheduler_file_order_sink implementiert.
Der Auftrag ist nach der Operation erledigt.
Wenn die Datei nicht entfernt oder verschoben werden kann, gelangt der Auftrag auf die Schwarze Liste. Damit
wird verhindert, dass die noch vorhandene Datei erneut zu einem Dateiauftrag wird. Aufträge auf der Schwarzen
Liste können mit <remove_order> entfernt werden. Wenn der JobScheduler bemerkt, dass die Datei entfernt
August 2014
30
worden ist, streicht er den Auftrag von der Schwarzen Liste. Die Datei kann dann erneut ins Verzeichnis gestellt
werden.
Siehe auch Verzeichnisüberwachung mit Dateiaufträgen (Seite 159) und <file_order_source> (Seite 30).
Eltern Elemente
<job_chain> - Jobkette
Attribute
state="string"
Zustand, für den dieser Jobkettenknoten gilt. Der Zustand ist ein Endzustand.
remove="yes|no"
remove="yes" entfernt die Datei.
Meldungen
[info]
SCHEDULER-979
Removing file move_to="directory_path"
Die Datei wird in das Verzeichnis verschoben. Eine gleichnamige vorhandene Datei wird überschrieben.
Unter Unix wird die Datei nur im selben Dateisystem verschoben.
Meldungen
[info]
SCHEDULER-980
Moving file to XML-Element <file_order_source>
<file_order_source
directory
regex
delay_after_error
repeat
max
next_state
> </file_order_source>
= "directory_path"
= "regex"
= "seconds"
= "no|seconds"
= "integer"
= "string"
Fügt einer Jobkette eine Dateiauftragsquelle hinzu. Jeder Dateiname in dem Verzeichnis, der dem Regulären
entspricht, wird der Jobkette als Dateiauftrag hinzugefügt.
Siehe auch Verzeichnisüberwachung mit Dateiaufträgen (Seite 159) und <file_order_sink> (Seite 29).
August 2014
31
Beispiel:
<job_chain name="my_job_chain">
<file_order_source directory="/tmp/input"/>
<job_chain_node state="first" job="process_file" error_state="ERROR"/>
<file_order_sink state="remove" remove="yes"/>
<file_order_sink state="ERROR" move_to="/tmp/input.error"/>
</job_chain>
Eltern Elemente
Attribute
directory="directory_path"
Pfad des Verzeichnisses, dass die Dateien enthält.
regex="regex"
Wenn Sie hier einen Regulären Ausdruck angeben, werden nur Dateinamen beachtet, die ihm entsprechen.
delay_after_error="seconds" (Initialwert:repeat)
Voreingestellt ist der Wert des Attributs repeat="…".
Wenn das Verzeichnis nicht lesbar ist, verschickt er eine eMail und versucht der JobScheduler es periodisch
erneut, bis er Erfolg hat. Dann verschickt er eine weitere eMail.
Meldungen
[info]
SCHEDULER-984
Recovered from previous error in directory repeat="no|seconds"
Der JobScheduler prüft periodisch das Verzeichnis auf Veränderung. Die Länge der Periode kann hier angegeben
werden.
Unter Windows ist repeat="60" voreingestellt. Außerdem nutzt der JobScheduler zusätzlich die in Windows
integrierte Verzeichnisüberwachung, so dass er auf eine Änderung des Verzeichnisses sofort reagiert. Sie wird
nach Ablauf des Wiederholungsintervalls erneuert.
Unter Unix ist repeat="10" voreingestellt. Das Verzeichnis wird alle 10 Sekunden auf Veränderung geprüft.
Meldungen
[info]
SCHEDULER-984
Recovered from previous error in directory max="integer" (Initialwert:100)
August 2014
32
Die Zahl der in einem Zug als Aufträge zu übernehmenden Dateien. Wenn mehr Dateien vorliegen, übernimmt er
sie, sobald der erste Job der Jobkette einen weiteren Auftrag ausführen kann.
Meldungen
[info]
SCHEDULER-985
number more file orders will be added later, after previous orders have been
processed [info]
SCHEDULER-986
Continuing reading buffered directory (as of time) next_state="string"
Wenn die Aufträge nicht in den ersten Job der Jobkette gespeist werden sollen, kann hier der anfängliche Zustand
der Aufträge angegeben werden.
XML-Element <holiday>
<holiday
date
> </holiday>
= "yyyy-mm-dd"
Setzt einen Feiertag fest, an dem der JobScheduler einen Job nicht laufen lassen soll.
Beispiel:
<holiday date="2004-12-24"/>
Ersetzt ein Element <holiday> an der entsprechenden Stelle mit gleichem Attribut date= aus der
Basiskonfiguration.
Eltern Elemente
<holidays> - Feiertage
Attribute
date="yyyy-mm-dd"
Das Datum des Feiertags.
XML-Element <holidays>
<holidays >
weekdays
holiday
include
</holidays>
Perioden für bestimmte Wochentage
Feiertag, an dem ein Job nicht laufen soll
August 2014
33
Beispiel:
<holidays>
<weekdays>
<day day="saturday sunday"/>
</weekdays>
<holiday date="2004-12-24"/>
<holiday date="2004-12-25"/>
<holiday date="2004-12-26"/>
<holiday date="2004-12-31"/>
<include file="holidays-2007.xml"/>
<include file="holidays-2008.xml"/>
</holidays>
Eltern Elemente
XML-Element <http.authentication>
<http.authentication
scheme
>
http.users
= "scheme"
Authentifizierungsverfahren
Benutzer zur HTTP-Authentifizierung
Mit diesem Element verlangt der JobScheduler vom HTTP-Client (Browser) eine Authentifizierung nach RFC 2617,
Verfahren »Basic«.
Die Authentifizierung gilt auch für die <web_service> .
Beispiel:
<http_server>
<http.authentication>
<http.users>
<http.user name="Rose Kemp"
password_md5="701d051b67bc5fc7c7c919d01f0aa7cb"/>
<http.user name="Jeff Beck"
password_md5="eb6801a466d5376639e29cd1d11ecb9f"/>
</http.users>
…
</http_server>
Ergänzt ein Element <http.authentication> an der entsprechenden Stelle aus der Basiskonfiguration. Hier
angegebene Attribute überschreiben die aus der Basiskonfiguration.
Eltern Elemente
<http_server> - HTTP-Server
August 2014
34
Attribute
scheme="scheme" (Initialwert:basic) Authentifizierungsverfahren
Nur scheme="basic" ist möglich.
XML-Element <http.user>
<http.user
name
password_md5
> </http.user>
= "name"
= "string"
Benutzerkennung zur Authentifizierung
MD5-Summe des Kennworts
Siehe <http.authentication> (Seite 33).
Ersetzt ein Element <http.user> an der entsprechenden Stelle mit gleichem Attribut name= aus der
Basiskonfiguration.
Eltern Elemente
<http.users> - Benutzer zur HTTP-Authentifizierung
Attribute
name="name" Benutzerkennung zur Authentifizierung
password_md5="string" MD5-Summe des Kennworts
Unter Unix kann die MD5-Summe des Kennworts gewöhnlich mit dem Kommando md5sum ermittelt werden:
echo -n 'password' | md5sum
Die MD5-Summe besteht nur aus den Hexadezimalziffern 0-9, a-f und A-F und ist 32 Zeichen lang.
Meldungen
[ERROR]
SCHEDULER-427
Invalid MD5 hexadecimal coded password for HTTP user '' XML-Element <http.users>
<http.users >
http.user
</http.users>
Benutzer zur HTTP-Authentifizierung
Siehe <http.authentication> (Seite 33).
August 2014
35
Ergänzt ein Element <http.users> an der entsprechenden Stelle aus der Basiskonfiguration. Hier angegebene
Eltern Elemente
<http.authentication> - HTTP-Authentifizierung
XML-Element <http_directory>
<http_directory
url_path
path
> </http_directory>
= "url_path"
= "path"
Erstes Verzeichnis im URL-Pfad
Pfad des Dateisystems
Bestimmt ein Verzeichnis des Dateisystems, das auf ein Verzeichnis im URL-Pfad abgebildet werden soll.
Im Beispiel liefert der URL http://host:port/doc/xml/http_directory.html
die Datei c:\pub\html\doc\xml/http_directory.html.
Ergänzt ein Element <http_directory> an der entsprechenden Stelle aus der Basiskonfiguration. Hier
Eltern Elemente
Attribute
url_path="url_path" Erstes Verzeichnis im URL-Pfad
Gibt das erste Verzeichnis im URL-Pfad an, auf das ein Verzeichnis des Dateisystems abgebildet werden soll.
Das Verzeichnis wird mit Schrägstrich am Beginn angegeben.
Beispiel:
<http_directory url_path="/doc/" path="c:/html/my_doc/" />
Bildet das Verzeichnis c:/html/my_doc/ ab auf URL-Pfade, die mit /doc/ beginnen.
path="path" Pfad des Dateisystems
Der Pfad im Dateisystem, der auf das url_path="" angegebene Verzeichnis abgebildet werden soll.
Beispiel:
path="c:\pub\html\doc\"
August 2014
36
XML-Element <http_server>
<http_server >
http_directory
web_service
</http_server>
HTTP-Dateiverzeichnis
Web-Dienst
Ergänzt ein Element <http_server> an der entsprechenden Stelle aus der Basiskonfiguration. Hier angegebene
Eltern Elemente
XML-Element <include>
<include
file
live_file
node
> </include>
= "filename"
= "path"
= "xpath"
Pfad der einzufügenden Datei
Pfad der einzufügenden Datei aus dem
Konfigurationsverzeichnis
XPath-Ausdruck
Dieses Element kann in den Text gestreut werden (aber außerhalb von <![CDATA[ und ]]>), um Quell-Code, der
in anderen Dateien steht, einzuziehen.
Wenn der JobScheduler die einzuziehende Datei nicht lesen kann:
•
•
Im Element <description>: Der JobScheduler ignoriert Fehler, fügt aber die Fehlermeldung in die <
description> ein.
Im Element <script>: Der JobScheduler versetzt den Job in den Zustand read_error. Das Kommando <
modify_job cmd="reread"> lässt den JobScheduler das Skript erneut lesen.
Eltern Elemente
<script> - Programm-Code
<description> - Beschreibung
<holidays> - Feiertage
Attribute
file="filename" Pfad der einzufügenden Datei
Der Name der Datei, deren Inhalt eingefügt werden soll. Wenn der Dateiname nicht absolut ist, dann geht der
JobScheduler abhängig vom umgebenden XML-Element von verschiedenen Verzeichnissen aus:
live_file="path" Pfad der einzufügenden Datei aus dem Konfigurationsverzeichnis
August 2014
37
Das Attribut kann verwendet werden direkt unter
•
•
•
•
<job><description>
<job><params>
<holidays>
<script>
und gibt den Pfad der Datei an, deren Inhalt eingefügt werden soll, relativ zum Verzeichnis der Datei, aus der das <
include> stammt. Er muss sich innerhalb des Konfigurationsverzeichnisbaums befinden. " /" am Anfang
bezeichnet die Wurzel des Konfigurationsverzeichnisses. Windows-Laufwerksbuchstaben können nicht verwendet
werden.
Wenn die Datei, die das <include> enthält, nicht aus einem Konfigurationsverzeichnis stammt, geht der
JobScheduler von der Wurzel des Konfigurationsverzeichnisses aus.
Unter <job><params> und <order><params> führt eine Änderung der Datei zum erneuten Lesen des Jobs bzw.
Auftrags, falls er dateibasiert ist, also aus einem Konfigurationsverzeichnis stammt.
[ERROR]
SCHEDULER-461
Path reaches beyond root (too many '..'):
[ERROR]
SCHEDULER-417
Invalid name: ''
node="xpath" XPath-Ausdruck
Wirkt nur für <include> in <params> und wählt die einzulesenden <param> -Elemente aus. Voreingestellt ist
xpath="params/*".
XML-Element <job>
<job
spooler_id
name
title
order
process_class
tasks
min_tasks
= ""
= "jobname"
= "text"
= "yes_no"
= "prozessklasse"
= "zahl"
= "zahl"
timeout
idle_timeout
= "dauer"
= "dauer"
force_idle_timeout
= "yes_no"
priority
temporary
java_options
visible
ignore_signals
stop_on_error
replace
warn_if_shorter_than
= "process_priority"
= "yes_no"
= "string"
= "yes|no|never"
= "all|signalnames"
= "yes|no"
= "yes|no"
=
"HH:MM:SS|seconds|percentage%"
=
"HH:MM:SS|seconds|percentage%"
warn_if_longer_than
Auftragsgesteuerter Job
Maximale Anzahl Tasks
Mindeste Anzahl der stets
laufenden Tasks
Frist für eine Operation
Frist für den Zustand
waiting_for_order
idle_timeout beendet Task
trotz min_task
August 2014
38
enabled
= "yes|no"
Deaktiviert einen Job.
>
settings
description
lock.use
params
environment
script
process
monitor
start_when_directory_ch
anged
delay_after_error
delay_order_after_setba
ck
run_time
commands
</job>
Einstellungen für einen Job
Beschreibung
Deklaration einer Sperre
Parameter
Umgebungsvariablen
Programm-Code
Externes Programm (alternativ zu <script>)
Monitor, zum Überwachen des Jobs
Verzeichnis überwachen
Job nach Fehler verzögern
Auftrag nach Rückstellung verzögern
Laufzeiten
XML-Kommandos
Definiert einen Job mit Programmcode, Laufzeit usw.
Ergänzt ein Element <job> an der entsprechenden Stelle mit gleichem Attribut name= aus der Basiskonfiguration.
Hier angegebene Attribute überschreiben die aus der Basiskonfiguration.
Eltern Elemente
<jobs> - Jobs
Attribute
spooler_id=""
name="jobname"
Jeder Job hat einen eigenen Namen.
Wenn ein Job mit demselben Namen in einer Basiskonfiguration bereit definiert worden ist, können hier die
Einstellungen des Jobs geändert oder ergänzt werden.
title="text"
Eine einzeilige Beschreibung des Jobs.
order="yes_no" Auftragsgesteuerter Job
Bei order="yes" ist der Job auftragsgesteuert. Der JobScheduler startet diesen Job nur, wenn ein Auftrag vorliegt.
Ein Skript kann mit Job.order_queue das Attribut prüfen.
process_class="prozessklasse"
August 2014
39
Gibt den Namen der Prozessklasse an, in der Tasks dieses Jobs laufen sollen. Die Prozessklassen werden mit <
process_classes> definiert.
tasks="zahl" (Initialwert:1) Maximale Anzahl Tasks
Von einem Job können mehrere Tasks gleichzeitig laufen. Dieses Attribut begrenzt deren Anzahl.
<lock.use> : Zusammen mit einer exklusiven Sperre ist nur tasks="1" sinnvoll, sie erlaubt nur eine Task.
min_tasks="zahl" (Initialwert:0) Mindeste Anzahl der stets laufenden Tasks
Der JobScheduler sorgt dafür, das wenigstens die angegebene Anzahl Tasks läuft. So lassen sich
auftragsgesteuerte Tasks in Bereitschaft bringen, die sehr lange für ihre Initialisierung brauchen.
<job tasks="…"> muss groß genug sein.
Der JobScheduler startet weitere Tasks, wenn
•
•
•
•
•
•
der JobScheduler startet
oder eine Task sich beendet hat
oder eine neue Periode ( <run_time> ) beginnt
oder bei <modify_job cmd="unstop"> : der Job wird entstoppt
oder bei <modify_job cmd="continue"> : alle Tasks des Jobs werden fortgesetzt
oder bei <modify_job cmd="wake"> : der Job wird geweckt
•
•
•
und weniger Tasks laufen als mit min_tasks verlangt
und die <run_time> mit einer Periode den Start zulässt
und der Job im Zustand pending oder running ist (also nicht gestoppt wird oder gestoppt ist).
Um ein Heißlaufen zu verhindern, startet der JobScheduler keine neuen Tasks, nachdem sich eine sofort beendet
hat. Nur in folgenden Fällen führt das Ende einer Task zum Start einer neuen:
•
•
•
•
spooler_process() wurde aufgerufen.
Die Task wartete eine Zeitlang auf einen Auftrag (Zustand running_waiting_for_order, nicht wenn <job
idle_timeout="0"> ).
Die Task startete, wurde aber mit Task.delay_spooler_process verzögert.
Die Task ist ein Prozess ( <process> oder <script language="shell"> ) und der Prozess hat sich nicht
sofort nach Start beendet.
Meldungen
[ERROR]
SCHEDULER-322
min_tasks= is greater than max_tasks= [warn]
SCHEDULER-970
task ended immediately after start, so min_tasks= doesn't lead to new tasks [debug3] SCHEDULER-969
Less than min_tasks= are running. New tasks will be started. Reason: timeout="dauer" Frist für eine Operation
Befristet eine Task-Operation (spooler_open, spooler_process etc.) oder bei einer Nicht-API-Task ( <process> oder
<script language="shell"> ) die ganze Task. Nach Ablauf der Frist bricht der JobScheduler die Task ab.
dauer kann in Sekunden oder im Format HH:MM oder HH:MM:SS angegeben werden.
idle_timeout="dauer" (Initialwert:5) Frist für den Zustand waiting_for_order
August 2014
40
Begrenzt den Leerlauf eines auftragsgesteuerten Jobs (order="yes"). Wenn eine Task auf den nächsten Auftrag
wartet und in der Frist kein Auftrag eintrifft, beendet der JobScheduler sie.
dauer kann in Sekunden oder im Format HH:MM oder HH:MM:SS angegeben werden.
idle_timeout="never" lässt den Job unbegrenzt laufen, nur noch abhängig von <run_time> .
Siehe auch <job force_idle_timeout="…"> (Seite 37).
force_idle_timeout="yes_no" (Initialwert:no) idle_timeout beendet Task trotz min_task
Nur wirksam mit <job min_tasks ≥ "0"> und <job idle_timeout="…"> .
force_idle_timeout="yes" beendet nach Ablauf von idle_timeout die Task, auch wenn daraufhin min_tasks
unterschritten wird. Erst anschließend führt min_tasks zum Start einer neuen Task.
Damit lassen sich Tasks beenden, die im Leerlauf eine Ressource (z.B. eine Datenbank) nicht zu lange belegen
dürfen, weil diese sich sonst abkoppelt.
priority="process_priority"
Eingestellt können die Werte idle, below_normal, normal, above_normal und high oder die numerischen Werte
des Betriebsystems.
Wenn die Priorität nicht gesetzt werden kann, führt das nicht zu einem Fehler.
Ein Prozess mit hoher Priorität kann Ihren Rechner blockieren.
Siehe Task.priority_class .
temporary="yes_no"
Bei temporary="yes" ist der Job temporär. Nur für <add_jobs> . Nach der Ausführung wird der Job gelöscht und
ist dann unbekannt.
java_options="string"
Wirkt nur, wenn der Job als eigener Prozess ausgeführt wird (s. <process_classes> ) und der Job oder der
Monitor in Java implementiert ist. Die Optionen werden zusammen mit den Optionen aus dem
Kommandozeilenparameter -job-java-options Java übergeben. Wie gleichnamige Optionen interpretiert
werden, hängt von Java ab.
visible="yes|no|never" (Initialwert:yes)
visible="no" und visible="never" lassen den Job im Ergebnis von <show_jobs> und <show_state>
unsichtbar.
Bei visible="no" setzt der JobScheduler den Job sichtbar, sobald eine Task eingereiht wird. Bei
visible="never" ist das nicht der Fall.
ignore_signals="all|signalnames" (Initialwert:no)
Wirksam nur unter Unix.
August 2014
41
Ein Job, dessen Task-Prozess mit Signal abbricht, führt zum Stopp des Jobs. Ursache eines Signals ist ein
Abbruch der Task durch das System-Kommando kill oder durch einen Programmabbruch.
Wenn ignore_signals nicht angegeben ist, stoppt eine mit Signal abbrechene Task den Job (mit Meldung
SCHEDULER-279 ).
ignore_signals="all" lässt den Job nicht stoppen.
Statt "all" können Sie auch eine Liste von Signalnamen angeben (durch Leerzeichen getrennt). Dabei sind,
abhängig vom Betriebssystem, diese Signalnamen bekannt: SIGHUP, SIGINT, SIGQUIT, SIGILL, SIGTRAP, SIGABRT,
SIGIOT, SIGBUS, SIGFPE, SIGKILL, SIGUSR1, SIGSEGV, SIGUSR2, SIGPIPE, SIGALRM, SIGTERM, SIGSTKFLT, SIGCHLD
, SIGCONT, SIGSTOP, SIGTSTP, SIGTTIN, SIGTTOU, SIGURG, SIGXCPU, SIGXFSZ, SIGVTALRM, SIGPROF, SIGWINCH,
SIGPOLL, SIGIO, SIGPWR und SIGSYS. Signal-Namen, die das Betriebsystem nicht kennt, werden mit Warnung
ignoriert.
Weil eine mit einem zu ignorierenden Signal abbrechende Task trotzdem zuerst einen TCP-Verbindungsfehler (
ECONNRESET) hervorruft, führen TCP-Verbindungsfehler nur dann zum Stopp des Jobs, wenn ignore_signals="…"
nicht zutrifft. Der JobScheduler weist mit der Meldung SCHEDULER-974 darauf hin.
Siehe auch <commands on_exit_code="SIGTERM"> (Seite 19) und das Gnu-Kommando man 7 signal.
Beispiel:
<job name="my_job" ignore_signals="SIGTERM SIGKILL">
Meldungen
[warn]
SCHEDULER-279
Process terminated with signal (name) [warn]
SCHEDULER-337
Signal is unknown on this operating system and is ignored [info]
SCHEDULER-974
Last error does not stop the job if the task aborts (after kill or crash) with any
signal listed in ignore_signals="". In this case, expect warning
SCHEDULER-279 stop_on_error="yes|no" (Initialwert:yes)
Die Voreinstellung stop_on_error="yes" stoppt den Job, wenn eine Task mit Exception oder mit einer
Fehlermeldung "[ERROR]" in ihrem Task-Protokoll endet. Eine Fehlermeldung kann z.B. mit Log.error()
geschrieben werden.
stop_on_error="no" lässt den Job in diesen Fällen nicht stoppen. Endet spooler_process() mit Exception,
versetzt der JobScheduler den Auftrag in den Fehlerzustand ( <job_chain_node error_state="…"> ).
Die Einstellung hat keine Wirkung, wenn <delay_after_error> oder Job.delay_after_error verwendet wird.
Meldungen
[warn]
SCHEDULER-846
After task exception and due to stop_on_error='no', the order has been moved
to error_state='' [debug3] SCHEDULER-977
Job is not stopping because of <job stop_on_error="no">. Task error was: [debug3] SCHEDULER-978
Job is stopping because of <job stop_on_error="yes">. Task error was: replace="yes|no" (Initialwert:yes)
August 2014
42
replace="yes" lässt diese Job-Definition eine evtl. bereits vorhandene ersetzen. Wenn das nicht möglich ist, weil
z.B. gerade eine Task läuft, dann ersetzt der JobScheduler den Job später.
Ein auftragsgesteuerte Job ( <job order="yes"> ) kann nicht ersetzt werden.
warn_if_shorter_than="HH:MM:SS|seconds|percentage%"
Wenn ein Jobschritt vor der angegebenen Zeit beendet wird, gibt der JobScheduler die Warnung SCHEDULER-711
aus.
Die Zeit kann im den Formaten HH:MM, HH:MM:SS, als Sekundenzahl oder als Prozentangabe angegeben werden.
Dabei sind 100% die durchschnittliche Laufzeit der bisherigen Jobschritte, ermittelt aus der Datenbanktabelle
SCHEDULER_HISTORY.
warn_if_longer_than="HH:MM:SS|seconds|percentage%"
Wenn ein Jobschritt länger als die angegebenen Zeit dauert, gibt der JobScheduler die Warnung SCHEDULER-711
aus.
Die Zeit kann im den Formaten HH:MM, HH:MM:SS, als Sekundenzahl oder als Prozentangabe angegeben werden.
Dabei sind 100% die durchschnittliche Laufzeit der bisherigen Jobschritte, ermittelt aus der Datenbanktabelle
SCHEDULER_HISTORY.
enabled="yes|no" (Initialwert:yes) Deaktiviert einen Job.
Mit diesem Attribut kann ein Job deaktiviert werden. Es wirkt so, als ob der Job gestoppt wird. Im Operations GUI
ist er aber vom Stopp-Zustand unterscheidbar.
XML-Element <job_chain>
<job_chain
name
visible
orders_recoverable
distributed
title
max_orders
= "name"
= "yes|no"
= "yes|no"
= "yes|no"
= "String"
= "postive integer"
max. Anzahl parallel laufender
order
>
file_order_source
job_chain_node
file_order_sink
job_chain_node.job_chai
n
job_chain_node.end
</job_chain>
Dateiauftragsquelle
Jobkettenknoten
Dateiauftragssenke
Jobkettenknoten
Ende einer Jobkette
Führt eine neue Jobkette (siehe Klasse Job_chain ) ein.
Siehe Aufträge (Seite 157), Job_chain , Spooler.create_job_chain() und Spooler.add_job_chain()
Einfache Jobkette - Eine Kette von Jobs
August 2014
43
Einfache Jobketten enthalten Jobs und werden mit den XML-Elementen <job_chain_node> , <
file_order_source> und <file_order_sink> beschrieben.
Übergeordente Jobkette - Eine Kette von Jobketten
Übergeordnete Jobketten verweisen auf andere Jobketten und werden mit den XML-Elementen <
job_chain_node.job_chain> . <job_chain_node.end> beschrieben. Die aufgeführten Jobketten müssen
einfache Jobketten sein.
Übergeordnete Jobketten arbeiten nicht mit verteilten Aufträgen.
Beispiel:
<job_chains>
<job_chain name="Kette_A">
<job_chain_node state=
<job_chain_node state=
"1" job="job_a" next_state=
"2" error_state="999" />
"2" job="job_b" next_state="100" error_state="999" />
<job_chain_node state="100" />
<job_chain_node state="999" />
</job_chain>
</job_chains>
Das ist dasselbe wie folgendes Scheduler-Skript:
<script language="javascript"><![CDATA[
var job_chain = spooler.create_job_chain();
job_chain.name = "Kette_A";
job_chain.add_job( "job_a", 1,
2, 999 );
job_chain.add_job( "job_b", 2, 100, 999 );
job_chain.add_end_state( 100 );
job_chain.add_end_state( 999 );
spooler.add_job_chain( job_chain );
]]></script>
Beispiel:
<job_chains>
<job_chain name="superchain">
<job_chain_node.job_chain state="A" job_chain="job_chain_a"
next_state="B" error_state="ERROR" />
<job_chain_node.job_chain state="B" job_chain="job_chain_b"
next_state="OK" error_state="ERROR" />
<job_chain_node.end state="OK" />
<job_chain_node.end state="ERROR" />
</job_chain>
</job_chains>
Das Element darf nicht angegeben werden, wenn es bereits in der Basiskonfiguration steht.
<job_chain name="Name"> mit verschiedenen Namen können hinzugefügt werden.
Eltern Elemente
<job_chains> - Jobketten
August 2014
44
Attribute
name="name"
Name der Jobkette. Jede Jobkette kann nur einmal definiert werden.
visible="yes|no" (Initialwert:yes)
visible="no" und visible="never" lassen die Jobkette im Ergebnis von <show_job_chains> und <show_state
> unsichtbar.
Bei visible="no" setzt der JobScheduler die Jobkette sichtbar, sobald eine Task eingereiht wird. Bei
visible="never" ist das nicht der Fall.
orders_recoverable="yes|no" (Initialwert:yes)
orders_recoverable="yes"
Der JobScheduler hält die Aufträge in der Datenbank. Sobald ein Auftrag in die Auftragswarteschlange eines Jobs
eingereiht wird, speichert der JobScheduler ihn auch in der Datenbank. Wenn der Auftrag die Jobkette durchlaufen
hat, wird er aus der Datenbank entfernt.
Beim Einrichten der Jobkette (beim Start des Schedulers) lädt der JobScheduler die Aufträge aus der Datenbank.
Siehe Spooler.add_job_chain() .
Wirkungslos, wenn der JobScheduler ohne Datenbank arbeitet, siehe factory.ini (Abschnitt [spooler], Eintrag
db= …) (Seite 87).
orders_recoverable="no"
Der JobScheduler hält nicht die Aufträge in der Datenbank und lädt sie auch nicht daraus.
Siehe Datenbank (Seite 130).
distributed="yes|no" (Initialwert:no)
Wirkt nur mit der Kommandozeilenoption -distributed-orders und lässt die Aufträge von mehreren Schedulern
verteilt ausführen.
distributed="no" lässt die Jobkette nicht verteilt, sondern nur auf diesem JobScheduler ausführen, wie bei
einem nicht-verteiltem Scheduler. Der Name der Jobkette muss in diesem Fall im Cluster eindeutig sein (das wird
nicht geprüft).
title="String"
Der Jobkette kann ein Titel gegeben werden.
Siehe auch Job_chain.title .
max_orders="postive integer" max. Anzahl parallel laufender order
Grundsätzlich können von einer Jobkette beliebig viele Instanzen (durch verschiedene Order gestartet) parallel
laufen. Mit max_orders kann diese Anzahl begrenzt werden. max_orders='1' bedeutet z.B., dass eine order diese
August 2014
45
Jobkette exklusiv für sich beansprucht. Eine weitere order für diese Jobkette können erst ausgeführt werden, wenn
die erste order beendet worden ist.
Fehlt diese Angabe, ist die Anzahl der parallel laufenden Order einer Jobkette nicht begrenzt.
Diese Einstellung gilt nur für order, die mit dem ersten Knoten der Jobkette starten.
XML-Element <job_chain_node>
<job_chain_node
state
job
next_state
error_state
delay
on_error
> </job_chain_node>
= "string"
= "job_name"
= "string"
= "string"
= "seconds"
= "suspend|resume"
Fügt einer Jobkette einen neuen Jobkettenknoten hinzu (siehe Klasse Job_chain_node ).
Die XML-Elemente
<job_chain_node state="STATE"
job="JOB" next_state="NEXT_STATE"
error_state="ERROR_STATE"/>
<job_chain_node state="ERROR_STATE" />
entsprechen den API-Aufrufen
job_chain.add_job( "JOB", "STATE", "NEXT_STATE", "ERROR_STATE" );
job_chain.add_end_state( "ERROR_STATE" );
Siehe Job_chain_node , Job_chain.add_job() und Job_chain.add_end_state() .
Eltern Elemente
Attribute
state="string"
Zustand, für den dieser Jobkettenknoten gilt.
job="job_name"
Job, der aufgerufen werden soll, wenn ein Auftrag den Zustand erreicht.
Wenn der Zustand einen Endzustand ist, dann geben Sie dieses Attribut nicht an.
Beispiel:
<job_chain_node state="1" job="my_job"/>
<job_chain_node state="2" job="../job_in_parent_folder"/>
next_state="string"
August 2014
46
spooler_process() des Jobs mit return true versetzt einen Auftrag in diesen Folgezustand.
Voreingestellt ist der Wert des Attributes state= des folgenden <job_chain_node>.
error_state="string"
spooler_process() des Jobs mit return false versetzt einen Auftrag in diesen Fehlerzustand.
delay="seconds" (Initialwert:0)
Verzögert den Auftrag vor Übergabe an den Job.
on_error="suspend|resume"
Nach einem Auftragsschritt, der den Auftrag als fehlerhaft gekennzeichnet hat, versetzt der JobScheduler den
Auftrag in den Fehlerzustand error_state. Das kann mit diesem Attribut geändert werden.
on_error="suspend" wirkt wie Order.suspended =true: Der JobScheduler belässt den Auftrag in seinem
Zustand, er bleibt also vor dem Job stehen und wird suspendiert.
on_error="setback" wirkt wie Order.setback() : Der JobScheduler belässt den Auftrag in seinem Zustand, er
bleibt also vor dem Job stehen, so wie es im Job mit <delay_order_after_setback> eingestellt ist.
XML-Element <job_chain_node.end>
<job_chain_node.end
state
> </job_chain_node.end>
= "string"
Endzustand
Fügt einer Kette von Jobketten einen Endzustand hinzu.
Eltern Elemente
Attribute
state="string" Endzustand
XML-Element <job_chain_node.job_chain>
state
= "string"
job_chain
= "job_chain_name"
next_state
= "string"
error_state
= "string"
> </job_chain_node.job_chain>
Fügt einer Kette von Jobketten einen neuen Jobkettenknoten hinzu, der eine verschachtelte Jobkette bezeichnet.
August 2014
47
Jobketten, die verschachtelte Jobketten enthalten, können selbst nicht in anderen Jobketten als verschachtelte
Jobketten verwendet werden.
Miteinander durch Verschachtelung verbundene Jobkettenn bilden einen gemeinsamen Order_id_space, um beim
Einfügen eines Auftrags die Eindeutigkeit der Auftragskennung sicherstellen zu können.
Der JobScheduler lehnt das Einfügen eines Auftrags in eine Jobkette ab, wenn die Auftragskennung im
Order_id_space bereits vergeben ist.
Beim Ersetzen eines Auftrags wird auch ein Auftrag in einer anderen Jobkette, die demselben Order_id_space
angehört, ersetzt.
Eltern Elemente
Attribute
state="string"
job_chain="job_chain_name"
Jobkette, der der Auftrag übergeben werden soll, wenn er den Zustand erreicht.
next_state="string"
spooler_process() mit return true des zuletzt durchlaufenden Jobs versetzt einen Auftrag in diesen
Folgezustand.
Voreingestellt ist der Wert des Attributes state= des folgenden Jobkettenknotens.
error_state="string"
spooler_process() mit return false des zuletzt durchlaufenden Jobs versetzt einen Auftrag in diesen
Fehlerzustand.
XML-Element <job_chains>
<job_chains >
job_chain
</job_chains>
Jobkette
Beispiel:
Siehe <job_chain> (Seite 42).
Ergänzt ein Element <job_chains> an der entsprechenden Stelle aus der Basiskonfiguration. Hier angegebene
August 2014
48
Eltern Elemente
XML-Element <jobs>
<jobs >
job
</jobs>
Definition eines Jobs
Ergänzt ein Element <jobs> an der entsprechenden Stelle aus der Basiskonfiguration. Hier angegebene Attribute
überschreiben die aus der Basiskonfiguration.
Eltern Elemente
XML-Element <lock>
<lock
name
max_non_exclusive
= "name"
= "integer"
Name der Sperre
Begrenzung der
Belegungen
nicht-exklusiven
> </lock>
Mit einer Sperre kann verhindert werden, dass zwei Tasks gleichzeitig laufen.
Siehe (Seite 152).
Zur Verwendung einer Sperre siehe <lock.use> (Seite 49)
Siehe auch <lock.remove> (Seite 186), Lock .
Beispiel:
<locks>
<lock name="switching_database"/>
<lock name="only_three_tasks" max_non_exclusive="3"/>
</locks>
Ergänzt ein Element <lock> an der entsprechenden Stelle aus der Basiskonfiguration. Hier angegebene Attribute
Eltern Elemente
<locks> - Deklaration der Sperren
Attribute
August 2014
49
name="name" Name der Sperre
Siehe auch Lock.name .
max_non_exclusive="integer" Begrenzung der nicht-exklusiven Belegungen
Die Voreinstellung ist unbegrenzt, es können also mit <lock.use exclusive="no"> beliebig viele nicht-exklusive
Tasks gestartet werden (aber nur eine exklusive).
Siehe auch Lock.max_non_exclusive .
Meldungen
[warn]
SCHEDULER-887
More lock holders than new max_non_exclusive=: holders XML-Element <lock.use>
<lock.use
lock
exclusive
= "name"
= "yes|no"
Name der Sperre
Exklusive oder nicht-exklusive Belegung ist
möglich
> </lock.use>
Siehe auch <locks> (Seite 50) und <lock> (Seite 48).
Beispiel:
<locks>
<lock name="my_file"/>
</lock>
<job name="my_file_reader" tasks="3">
<lock.use lock="my_file" exclusive="no"/>
…
</job>
<job name="my_other_file_reader">
<lock.use lock="my_file" exclusive="no"/>
…
</job>
<job name="my_file_writer">
<lock.use lock="my_file"/>
…
</job>
Die Jobs my_file_reader und my_other_file_reads belegen die Sperre nicht-exklusiv und können gleichzeitig
mit mehreren Tasks laufen.
Der Job my_file_writer setzt die Sperre exklusiv und startet nur, wenn kein anderer Job läuft. Der Job kann einen
Datenbestand ändern und sich darauf verlassen, dass währenddessen keiner der beiden anderen Jobs den
Datenbestand liest.
Siehe auch Task.try_hold_lock() .
August 2014
50
Ergänzt ein Element <lock.use> an der entsprechenden Stelle aus der Basiskonfiguration. Hier angegebene
Eltern Elemente
Attribute
lock="name" Name der Sperre
Die Sperre muss mit <lock> deklariert worden sein.
exclusive="yes|no" (Initialwert:yes) Exklusive oder nicht-exklusive Belegung ist möglich
exclusive="yes" ist voreingestellt. Damit wird die Sperre exklusiv gesetzt und nur eine Task wird gestartet. Alle
anderen Jobs, die dieselbe Sperre angegeben, werden in eine Warteschlange eingereiht. Jobs mit
exclusive="yes" werden vor Jobs mit exclusive="no" gestartet.
exclusive="no" sperrt nur gegen exklusive Verwendung (exclusive="yes"). Task mit exclusive="no"
schließen nur Tasks mit exclusive="yes" aus. Die Zahl von mit exclusive="no" insgesamt laufender Tasks kann
mit <lock max_non_exclusive="…"> begrenzt werden.
XML-Element <locks>
<locks >
lock
</locks>
Ergänzt ein Element <locks> an der entsprechenden Stelle aus der Basiskonfiguration. Hier angegebene Attribute
Eltern Elemente
XML-Element <monitor>
<monitor
name
ordering
>
script
</monitor>
= "Name"
= "Number"
Programm-Code
Ein Monitor stellt Funktionen bereit, die vor und nach der Task sowie vor und nach von spooler_process()
gerufen werden.
August 2014
51
Der Monitor kann den Start der Task oder die Ausführung von spooler_process() verhindern.
Siehe Oberklasse Monitor_impl , deren Methoden ein Monitor implementieren kann.
Beispiel:
<monitor>
<script java_class="spooler_job.Java_monitor"><![CDATA[
package spooler_job;
import sos.spooler.*;
public class Java_monitor extends sos.spooler.Monitor_impl
{
public boolean spooler_task_before() throws Exception
{
spooler_log.info( "SPOOLER_TASK_BEFORE()" );
return true;
}
public void spooler_task_after() throws Exception
{
spooler_log.info( "SPOOLER_TASK_AFTER()" );
}
public boolean spooler_process_before() throws Exception
{
spooler_log.info( "SPOOLER_PROCESS_BEFORE()" );
return true;
}
public boolean spooler_process_after( boolean spooler_process_result )
throws Exception
{
spooler_log.info( "SPOOLER_PROCESS_AFTER(" + spooler_process_result +
")" );
return spooler_process_result;
}
}
]]></script>
</monitor>
Eltern Elemente
Attribute
name="Name"
Mehrere Monitor können angegeben werden, wenn sie unterschiedliche Namen erhalten.
Die Monitor werden in der Reihenfolge des Attributes ordering aufgerufen. spooler_process_after() und
spooler_task_after() in der rückwärtigen Reihenfolge.
August 2014
52
ordering="Number"
Gibt die Rangfolge der Monitore an.
XML-Element <month>
<month
month
>
period
monthdays
ultimos
weekdays
</month>
= "month"
Periode
Perioden für bestimmte Tage des Monats
Perioden für bestimmte Tage des Monats, vom Ende her gezählt
Setzt die Perioden für einen bestimmten Tag des Monats fest.
Im Gegensatz zu anderen Elementen übernimmt <month> nicht die Attribute von <run_time> oder die darin
voreingestellten <period> .
Wenn <month> für einen Monat gilt, dann gelten solange nicht die direkt unter <run_time> stehenden <weekdays>
, <monthdays> oder <ultimos> .
Eltern Elemente
Attribute
month="month"
Eine oder mehrere, durch Leerzeichen getrennte Monatsnamen: "january", "february", "march", "april",
"may", "june", "july", "august", "september", "october", "november", "december".
XML-Element <monthdays>
<monthdays >
day
weekday
</monthdays>
Perioden für bestimmte Tage
Perioden für einen bestimmten Wochentag
August 2014
53
Beispiel:
<monthdays>
<day day="1">
</day>
<day day="2">
</day>
<weekday day="monday" which="1">
<period single_start="02:00"/>
</weekday>
</monthdays>
Setzt die Laufzeiten fest für den Ersten eines Monats 10:00 bis 12:00 und für den Zweiten eines Monats 08:00 bis
12:00 und 15:00 bis 18:00. Außerdem wird der Job am jeweils ersten Montag eines Monats um 2 Uhr morgens
gestartet.
Beispiel:
<monthdays>
<day day="5">
</day>
</monthdays>
Startet den Job an jedem 5. eines Monats um 16 Uhr.
Ergänzt ein Element <monthdays> an der entsprechenden Stelle aus der Basiskonfiguration. Hier angegebene
Eltern Elemente
XML-Element <param>
<param
name
value
> </param>
= ""
= ""
Eindeutiger Name
Siehe <params> (Seite 54).
Bestimmt einen einzelnen Parameter für den Scheduler, einen Job oder einen Auftrag. Grundsätzlich sind alle
Parameter über die API Aufrufe Spooler.variables() , Task.params() bzw. Order.payload() oder in shell Jobs
als environment Variable (mit vorangestelltem SCHEDULER_PARAM_) verfügbar.
Gleichnamige Parameter in der JobScheduler Konfiguration, am Job und am Auftrag gelten in der folgenden
Reihenfolge:
•
Auftrag
•
Job
•
Scheduler
August 2014
54
Es wird empfohlen keine eigenen Parameter einzustellen, die mit der Zeichenfolge scheduler. beginnen, da dieser
Namensraum für Konfigurationseinstellungen des JobScheduler reserviert ist.
Die Parameter können zur Laufzeit überschrieben und erweitert werden.
Siehe auch die Klasse Variable_set .
Scheduler-Parameter
Folgende Scheduler-Parameter könnnen für die Konfiguration des JobScheduler verwendet werden:
•
scheduler.variable_name_prefix
•
scheduler.max_kbyte_of_db_log_entry
•
scheduler.order.keep_order_content_on_reschedule
•
scheduler.order.distributed.balanced
Job-Parameter
Job-Parameter können mit der Methode Task.params() abgerufen werden.
Auftrags-Parameter
Parameter eines Auftrags können mit der Methode Order.params() abgerufen werden.
Ergänzt ein Element <param> an der entsprechenden Stelle mit gleichem Attribut name= aus der Basiskonfiguration.
Eltern Elemente
Attribute
name="" Eindeutiger Name
value=""
XML-Element <params>
<params >
param
copy_params
include
</params>
Ein Parameter
Parameter übernehmen
Bestimmt Parameter für den Scheduler, einen Job oder einen Auftrag. Die Parameter können zur Laufzeit
überschrieben und erweitert werden.
Scheduler-Parameter können mit der Methode Spooler.variables() abgerufen werden.
August 2014
55
Parameter eines Auftrags können mit der Methode Order.payload() abgerufen werden.
Siehe auch die Klasse Variable_set und <sos.spooler.variable_set> (Seite 69).
Ergänzt ein Element <params> an der entsprechenden Stelle aus der Basiskonfiguration. Hier angegebene
Eltern Elemente
<add_order> - Auftrag hinzufügen
<modify_order> <payload> <queued_task> <web_service> - Web-Dienst
XML-Element <period>
<period
begin
end
repeat
absolute_repeat
single_start
let_run
when_holiday
= "hh:mm[:ss]"
= "hh:mm[:ss]"
= "hh:mm[:ss] oder sekunden"
= "hh:mm[:ss] | seconds"
= "hh:mm[:ss]"
= "yes_no"
= ""
Umgang
Feiertagen
mit
> </period>
Eine Periode gibt an, wann ein Job laufen darf. Sie kann einen Zeitraum innerhalb eines Tages umfassen (Attribute
begin und end) oder einen Zeitpunkt (Attribut single_start).
Eltern Elemente
Attribute
begin="hh:mm[:ss]" (Initialwert:00:00)
Ab dieser Uhrzeit darf der Job laufen.
end="hh:mm[:ss]" (Initialwert:24:00)
Um diese Zeit endet die Periode. Wenn dann let_run="no" gesetzt ist und keine weitere Periode gilt, beendet der
JobScheduler laufende Tasks (durch Aufruf von spooler_close()).
repeat="hh:mm[:ss] oder sekunden"
August 2014
56
Der Job wird, wenn er nicht schon läuft, zu Beginn der Periode gestartet. Nach Jobende soll der JobScheduler den
Job nach ablauf der angegebenen Zeit erneut starten, soweit die <run_time> das zulässt. Die Wiederholung kann
im Format hh:mm oder hh:mm:ss oder in Sekunden angegeben werden.
Kann nicht mit dem Attribut single_start= kombiniert werden.
Bei repeat="0" wird der Job nicht wiederholt (default).
absolute_repeat="hh:mm[:ss] | seconds"
Der Job wird, wenn er nicht schon läuft, zu Beginn der Periode gestartet. Danach wird er zu den Zeitpunkten
gestartet, die sich aus den Vielfachen von absolute_repeat nach begin errechnen. Die Wiederholung kann im
Format hh:mm oder hh:mm:ss oder in Sekunden angegeben werden.
Kann nicht mit dem Attribut single_start= kombiniert werden.
single_start="hh:mm[:ss]"
Der Job soll zu der angegebenen Uhrzeit starten.
Nicht zusammen mit den Attributen begin=, end= und repeat= zu verwenden.
let_run="yes_no"
Das Attribut kann nur für Jobs, nicht für Aufträge angegeben werden. Für auftragsgesteuerte Jobs sollte Einstellung
let_run="no" eingestellt werden.
let_run="yes" gibt an, dass der JobScheduler die Task weiterlaufen lassen soll, auch wenn die <run_time> das
eigentlich nicht mehr zulässt.
Bei let_run="no" beendet der JobScheduler die Task (ruft also nicht mehr spooler_process, sondern
spooler_close auf), sobald die <run_time> nicht mehr gilt.
when_holiday="" Umgang mit Feiertagen
Normalerweise wird eine Periode, die auf einen Feiertag <holidays> fällt, unterdrückt. Aber es gibt noch weitere
Möglichkeiten.
when_holiday="suppress"
Voreinstellung. Wenn die Periode auf einen Feiertag fällt, wird sie unterdrückt.
when_holiday="ignore_holiday"
Wenn die Periode auf einen Feiertag fällt, wird sie nicht unterdrückt.
when_holiday="previous_non_holiday"
Wenn die Periode auf einen Feiertag fällt, wird sie auf den vorangehenden Nicht-Feiertag verschoben.
when_holiday="next_non_holiday"
Wenn die Periode auf einen Feiertag fällt, wird sie auf den nachfolgenden Nicht-Feiertag verschoben.
August 2014
57
XML-Element <process>
<process
file
= "filename"
param
log_file
ignore_error
ignore_signal
= "text"
= "dateiname"
= "yes|no"
= "yes|no"
Pfad
des
Programms
Parameterzeile
auszuführenden
>
environment
</process>
Umgebungsvariablen
Beim Start des Jobs, also zu Beginn einer Task, wird ein Prozess eingerichtet. Der JobScheduler überwacht den
Prozess und beendet die Task nachdem der Prozess sich beendet hat.
Exit-Code
•
•
Ein Exit-Code verschieden von 0 wird als Fehler ( SCHEDULER-280 ) interpretiert.
Unter Unix setzt der JobScheduler den Exit-Codes eines mit Signal abgebrochenen Prozesses auf den
negativen Wert des Signals.
•
Der Exit-Code wird in Task.exit_code bereitgestellt und entscheidet über die anschließend auszuführenden
Kommandos. Siehe hierzu <job> <commands on_exit_code="…"> .
Umgebungsvariablen
Der JobScheduler übergibt Umgebungsvariablen:
SCHEDULER_CONFIGURATION_DIRECTORY
Dasselbe wie Spooler.configuration_directory .
SCHEDULER_HOST
Dasselbe wie Spooler.hostname .
SCHEDULER_JOB_CHAIN
Bei einem auftragsgesteuerten Job ( <job order="yes"> ) Task.order . Order.job_chain .
Job_chain.name .
SCHEDULER_JOB_CHAIN_CONFIGURATION_DIRECTORY
Pfad des Konfigurationsverzeichnisses der Jobkette; "", wenn die Jobkette nicht aus einem
Konfigurationsverzeichnis stammt oder kein Auftrag vorliegt
SCHEDULER_JOB_CONFIGURATION_DIRECTORY
Dasselbe wie Job.configuration_directory .
SCHEDULER_JOB_NAME
Der Name des Jobs
SCHEDULER_ORDER_ID
Bei einem auftragsgesteuerten Job ( <job order="yes"> ) Task.order . Order.id .
SCHEDULER_SUPERVISOR_HOST
Rechnername aus <config supervisor="…">
SCHEDULER_SUPERVISOR_PORT
Portnummer aus <config supervisor="…">
August 2014
58
SCHEDULER_TASK_ID
Dassselbe wie Task.id .
SCHEDULER_TASK_TRIGGER_FILES
Dasselbe wie Task.trigger_files .
SCHEDULER_TCP_PORT
Wie Spooler.tcp_port oder leer, wenn kein Port festgelegt ist.
SCHEDULER_UDP_PORT
Wie Spooler.udp_port oder leer, wenn kein Port festgelegt ist.
Eltern Elemente
Attribute
file="filename" Pfad des auszuführenden Programms
Name der Datei, die das Programm oder das Skript enthält, mit dem der Prozess gestartet werden soll. Die Datei
muss vom Betriebssystem ausführbar sein.
param="text" Parameterzeile
Gibt den Parameterstring an, der dem Prozess übergeben wird. Außer den Umgebungsvariablen werden können
auch die Task-Parameter mit $ name oder ${ name } abgerufen werden.
Die in <environment> aufgeführten Variablen haben keinen Einfluss auf die Ersetzung.
Beispiel:
<process file="/tmp/test.cmd" param="EINS=$EINS ZWEI=$ZWEI HOME=$HOME LOG=$LOG
PATH=$PATH">
<environment>
<variable name="PATH" value="$PATH;/extra"/>

</environment>
</process>
var params = spooler.create_variable_set();
params.value( "EINS" ) = "1";
params.value( "ZWEI" ) = "2";
spooler.job( "process" ).start( params );
log_file="dateiname"
August 2014
59
Der JobScheduler übernimmt nach Prozessende den Inhalt dieser Datei in sein Protokoll.
ignore_error="yes|no" (Initialwert:no)
Bei ignore_error="no" (Voreinstellung) führt ein Exit code ≠ 0 zu einem Jobfehler. Der Job wird gestoppt.
Bei ignore_error="yes" führt ein Exit code ≠ 0 nicht zu einem Jobfehler.
ignore_signal="yes|no" (Initialwert:no)
Wirkt nur unter Unix. (Unter Windows liefert ein abgebrochener Prozess einen Exit code, der von
ignore_error="" berücksichtigt wird.)
Bei ignore_signal="no" (Voreinstellung) führt ein Signal (d.h. ein Abbruch des Prozesses, z.B. durch kill) zu
einem Jobfehler. Der Job wird gestoppt.
Bei ignore_signal="yes" führt ein Signal nicht zu einem Jobfehler.
ignore_signal="yes" hat dieselbe Wirkung wie <job ignore_signals="all"> .
XML-Element <process_class>
<process_class
spooler_id
name
max_processes
remote_scheduler
replace
> </process_class>
= "scheduler_id"
= "name"
= "zahl"
= "host:port"
Ausführung der Tasks auf entferntem
Rechner
= "yes|no"
Definiert oder ändert eine Prozessklasse.
Siehe auch <process_class.remove> (Seite 195).
Ergänzt ein Element <process_class> an der entsprechenden Stelle aus der Basiskonfiguration. Hier angegebene
Eltern Elemente
<process_classes> - Prozessklassen
Attribute
spooler_id="scheduler_id"
Das Element ist nur wirksam, wenn dieses Attribut leer oder gleich dem Parameter -id= vom JobScheduler Start
ist, oder wenn beim JobScheduler Start die Option -id nicht angegeben worden ist.
name="name"
August 2014
60
Name der Prozessklasse. Wenn das Attribut fehlt oder leer ("") ist, dann wird die Default-Prozessklasse geändert.
Siehe <job> (Seite 37), Attribut process_class=.
max_processes="zahl" (Initialwert:30)
Begrenzt die Zahl der Prozesse.
Manche Betriebsysteme limitieren die Zahl der Prozesse, die der JobScheduler starten darf. Es sollten nicht mehr
Prozesse konfiguriert werden als das Betriebssystem erlaubt.
Für Microsoft Windows Betriebssysteme gilt derzeit eine Beschränkung von max. 30 für die parallele Ausführung
zugelassenen Prozessen.
remote_scheduler="host:port" Ausführung der Tasks auf entferntem Rechner
Bestimmt den entfernten Scheduler, auf dem die Tasks dieser Prozessklasse ausgeführt werden sollen, durch
Hostnamen oder IP-Nummer und TCP-Port (s. <config tcp_port="…"> ).
Der entfernte JobScheduler muss den Zugriff mit <allowed_host level="all"> erlauben.
Die ausgeführten Tasks kommunizieren über die API mit dem steuernden Scheduler. Dabei gibt es einige
Besonderheiten:
•
•
•
<include> innerhalb von <script> wird vom Task-Prozess ausgeführt. Die einzuschließende Datei wird also
vom Rechner, der die Task ausführt, gelesen.
Subprocess.timeout und Task.add_pid() wirken nicht. Der JobScheduler kann entfernte Subprozesse,
deren Frist abgelaufen ist, nicht abbrechen.
Log.log_file() wird, wie fast alle Methoden, auf dem Rechner des Schedulers ausgeführt, greift also auf
die Dateien des dortigen Dateisystems zu.
Einige Einstellungen werden vom entfernten statt vom eigenen JobScheduler übernommen:
•
•
•
•
•
sos.ini (Abschnitt [java], Eintrag javac= …)
factory.ini (Abschnitt [spooler], Eintrag tmp= …)
<config java_options="…">
<config java_class_path="…">
<config include_path="…">
Meldungen
[warn]
SCHEDULER-849
Timeout is not possible for a subprocess running on a remote host (it cannot be
killed), pid= [warn]
SCHEDULER-850
After lost connection to remote scheduler, process is going to be killed [info]
SCHEDULER-848
Task pid= started for remote scheduler replace="yes|no" (Initialwert:yes)
replace="yes" ersetzt die vorhandene Prozessklasse.
replace="no" ändert nur die gesetzten Attribute der Prozessklasse.
August 2014
61
XML-Element <process_classes>
<process_classes
ignore
>
process_class
</process_classes>
= "yes|no"
Prozessklasse
Ergänzt ein Element <process_classes> an der entsprechenden Stelle aus der Basiskonfiguration. Hier
Eltern Elemente
Attribute
ignore="yes|no" (Initialwert:no)
ignore="yes" unterdrückt den Betrieb mit Prozessklassen, d.h. die Tasks laufen im Prozess des Schedulers, was
nur zum Debuggen geeignet ist.
XML-Element <run_time>
<run_time
time_zone
schedule
start_time_function
once
begin
end
repeat
single_start
let_run
when_holiday
= "text"
= ""
= "name"
= "yes_no"
= "hh:mm[:ss]"
= "hh:mm[:ss]"
= "hh:mm[:ss] oder sekunden"
= "hh:mm[:ss]"
= "yes_no"
= ""
Zeitzone des Auftrages / des Jobs
/ des Schedules
Abzurufender Zeitplan
>
period
at
date
weekdays
month
monthdays
ultimos
holidays
</run_time>
Periode
Startzeitpunkt
Perioden für ein bestimmtes Datum
Perioden für einen Monat
Perioden für bestimmte Tage des Monats
Perioden für bestimmte Tage des Monats, vom Ende her gezählt
Feiertage
<run_time> gibt an, zu welchen Zeiten der JobScheduler Tasks dieses Jobs laufen lässt. Das wird realisiert durch
Perioden (s. <period> ). Der JobScheduler wählt die erste Periode aus, die zu einer Zeit gilt (deren Ende noch
nicht abgelaufen ist). Diese Periode gilt bis zu ihrem Ende. Dann wählt der JobScheduler erneut eine Periode aus.
August 2014
62
Eine Periode mit single_start gilt nur für einen Zeitpunkt.
<show_calendar> zeigt das Ergebnis.
Sommer- und Winterzeit
Der JobScheduler berücksichtigt die Zeitumstellung zu Beginn und Ende der Sommerzeit. Es gilt stets die lokale
Zeit. Ein Job, der eine Startzeit zwischen 2 und 3 Uhr hat, kann zum Ende der Sommerzeit zweimal gestartet werden.
Verkürzte Schreibweise mit <period> und den Attributen begin=, end=, repeat=, let_run=, single_start= und
when_holiday=
<period> innerhalb von <run_time> werden verwendet für die Elemente <date> , <weekdays> , <monthdays> und
<ultimos> , wenn diese keine eigenen <period> haben. Ausgenommen ist also <month> .
<run_time>
<monthdays>
<day day="1"/>
<day day="2">
</day>
</monthdays>
</run_time>
wird zu
<run_time>
<monthdays>
<day day="1">
</day>
<day day="2">
</day>
</monthdays>
</run_time>
Wenn dagegen keins der Elemente <date> , <weekdays> , <monthdays> und <ultimos> aufgeführt ist, gelten die <
period> für jeden Tag der Woche.
Die Attribute begin=, end=, repeat=, let_run= und single_start= wirken, wenn kein <period> angegeben ist,
und lassen den JobScheduler eins mit denselben Attributen erzeugen.
<run_time begin="07:00" end="09:00"/>
wird zu
<run_time>
<run_time>
August 2014
63
Beispiel:
<run_time/>
ist, wegen der Voreinstellungen für begin= und end=, dasselbe wie
<run_time begin="00:00" end="24:00"/>
ist, weil <run_time> leer ist, dasselbe wie
<run_time>
</run_time>
also eine Periode für jeden Tag rund um die Uhr. Der Job kann immer laufen.
Eltern Elemente
<add_order> - Auftrag hinzufügen
<order> Attribute
time_zone="text" Zeitzone des Auftrages / des Jobs / des Schedules
Überschreibt die globale Einstellung der Zeitzone für ein JobScheduler Objekt (Auftrag, Job, Schedule).
Siehe <config time_zone="…"> (Seite 20).
schedule="" Abzurufender Zeitplan
Gibt den benannten <schedule> an, der verwendet werden soll.
Alle anderen Attribute und Kindelement werden nicht beachtet.
start_time_function="name"
Gibt gibt den Namen einer Funktion im Scheduler-Skript an, die die nächste Startzeit liefert.
Der JobScheduler übergibt der Funktion im ersten Parameter den Zeitpunkt, ab dem sie eine Startzeit liefern soll,
als Zeichenkette im Format "yyyy-mm-dd HH:MM:SS".
Im zweiten Parameter erhält die Funktion den Jobnamen bzw. die Auftragskennung.
Rückgabe der Funktion ist ein Zeitpunkt, der nicht vor dem ersten Parameter liegen darf, oder nichts (d.h. "" oder
Empty). Der JobScheduler erwartet als Rückgabe eine Zeichenkette im Format "yyyy-mm-dd hh:mm:ss".
Meldungen
[ERROR]
SCHEDULER-393
Error when calling <run_time> function '': [warn]
SCHEDULER-394
<run_time>-Function '' returned start time which is earlier than the requested
beginning once="yes_no" (Initialwert:no)
August 2014
64
Bei once="yes" startet der Scheduler den Job einmal nach Start des Schedulers, sobald die <run_time> dies
zulässt. Außerdem werden persistente Jobs mit once="yes" sofort gestartet, wenn sie während der Laufzeit des
JobSchedulers zu einem Live-Folder hinzugefügt werden und ihre <run_time> dies zulässt.
begin="hh:mm[:ss]" (Initialwert:00:00)
Wenn das Element leer ist (also kein <period> enthält), generiert der JobScheduler eine Periode mit dieser
Einstellung, andernfalls ist es die Voreinstellung für die Kind-Elemente (siehe oben Verkürzte Schreibweise (Seite
62)).
end="hh:mm[:ss]" (Initialwert:24:00)
62)).
repeat="hh:mm[:ss] oder sekunden"
62)).
single_start="hh:mm[:ss]"
62)).
let_run="yes_no"
Hiermit wird bestimmt, ob ein laufender Task nach Ablauf einer Periode weitere Process-Schritte ausführen soll
oder nicht. Per Default führt ein Job keine weiteren Process-Schritte mit Ablauf der Periode aus und wird beendet
(let_run="no").
Für auftragsgesteuerte Jobs gilt:
Wenn ein auftragsgesteuerter Job eine Periode definiert (z.B. 12:00 - 14:00) und während dieser Periode ein
Auftrag eintrifft, wird der Auftrag ausgeführt. Nach Beendigung der Ausführung entscheidet der Wert für
idle_timeout, ob die Task gestartet bleibt und mögliche weitere Aufträge entgegennimmt. Wenn die Task gestartet
bleibt und einen Auftrag entgegennimmt, wird der Wert für let_run geprüft.
let_run="yes": Der Auftrag wird ausgeführt.
let_run="no": Der Auftrag wird nur ausgeführt, wenn der Startzeitpunkt innerhalb der Periode des Jobs liegt.
62)).
when_holiday=""
August 2014
65
62)).
XML-Element <schedule>
<schedule
name
substitute
= "name"
= "schedule_path"
valid_from
valid_to
> </schedule>
Zeitweilig
Zeitplan
zu
überdeckender
= "yyyy-mm-dd HH:MM[:ss]"
= "yyyy-mm-dd HH:MM[:ss]"
Außer den hier beschriebenen Attributen und Elementen können die von <run_time> angegeben werden, aber
nicht schedule=.
Bei verteilten Aufträgen wirkt die Änderung eines <schedule> erst, wenn der Auftrag das nächste Mal die Jobkette
durchlaufen hat.
Eltern Elemente
<schedules> - Zeitpläne
Attribute
name="name"
Der Name des Zeitplans.
Ein so benannter Zeitplan kann mit <run_time schedule="…"> abgerufen werden.
substitute="schedule_path" Zeitweilig zu überdeckender Zeitplan
Der mit substitute="schedule_path" angegebene Zeitplan soll zeitweilig durch den hier definierten überdeckt
werden.
Die Zeitspanne wird mit den Attributen valid_from= und valid_to= angegeben.
Ein überdeckender Zeitplan kann nicht direkt mit <run_time schedule="…"> abgerufen werden.
Meldungen
[ERROR]
SCHEDULER-463
schedule: substituted 'schedule' is a substitute [info]
SCHEDULER-705
Substitute 'schedule' is valid now [info]
SCHEDULER-706
Standard 'schedule' is valid now valid_from="yyyy-mm-dd HH:MM[:ss]"
Ist substitute= angegeben und fehlt valid_from=, dann wird der angegebene Schedule ab sofort überdeckt.
Meldungen
August 2014
66
[ERROR]
SCHEDULER-465
'schedule' overlaps schedule [ERROR]
SCHEDULER-466
'schedule' is a substitute for another schedule and cannot be used directly valid_to="yyyy-mm-dd HH:MM[:ss]"
Ist substitute= angegeben und fehlt valid_to=, dann endet die Überdeckung nicht.
Meldungen
[ERROR]
SCHEDULER-464
schedule: valid_from=""> is not before valid_to="" [ERROR]
SCHEDULER-465
'schedule' overlaps schedule [ERROR]
SCHEDULER-466
'schedule' is a substitute for another schedule and cannot be used directly XML-Element <schedules>
<schedules >
schedule
</schedules>
Zeitplan
Ergänzt ein Element <schedules> an der entsprechenden Stelle aus der Basiskonfiguration. Hier angegebene
Eltern Elemente
XML-Element <script>
<script
language
com_class
encoding
filename
java_class
java_class_path
>
include
</script>
= "language"
= "com_class_name"
= "encoding"
= "filename"
= "java_class_name"
= "java_class_path"
Hier wird der auszuführende Programm-Code angegeben, entweder direkt als Text oder indirekt als Verweis auf
Binär-Code.
<script> kann den Quell-Code als Text enthalten. Er kann in <![CDATA[ und ]]> eingeschlossen sein.
August 2014
67
Das Skript wird dem in einer Basiskonfiguration definierten Skript angehängt.
Eltern Elemente
<scheduler_script> <job> - Definition eines Jobs
<monitor> - Monitor, zum Überwachen des Jobs
Attribute
language="language"
Sprache des Programm-Codes. Wird nicht zusammen mit dem Attribute com_class verwendet. Die
Großschreibung spielt keine Rolle.
com_class="com_class_name"
Name einer COM-Klasse (nur Windows). Die COM-Klasse kann die Methoden spooler_open(), spooler_process()
etc. bereitstellen.
encoding="encoding"
Nur unter Windows für language="shell": Gibt die Codierung an, in der der JobScheduler die temporäre .cmd
-Datei erstellt. Windows verlangt für Batch-Dateien encoding="oem", was voreingestellt ist. Außerdem möglich:
"cp850", "cp437" und "latin1".
filename="filename"
Zusammen mit dem Attribut com_class können Sie hier den Namen der DLL angeben, die die COM-Klasse
implementiert, falls diese nicht registriert ist.
java_class="java_class_name"
Wenn der Job als Java-Klasse realisiert ist, dann geben Sie mit diesem Attribut deren Namen an.
Ein in einer Basiskonfiguration angegebener Name kann überschrieben werden. Die nächste Task (die in einem
eigenen Prozess läuft) verwendet die neue Klasse.
java_class_path="java_class_path"
Erlaubt einen jobspezifischen Java Klassenpfad.
Dieser Klassenpfad wird dem Klassenpfad (factory-ini) davorgesetzt.
XML-Element <security>
<security
ignore_unknown_hosts
>
allowed_host
</security>
= "yes_no"
Rechner, der Verbindung aufnehmen darf
August 2014
68
<security> gibt die Rechner und Netzwerke an, die per TCP und UDP Kommandos ausführen dürfen.
Ergänzt ein Element <security> an der entsprechenden Stelle aus der Basiskonfiguration. Hier angegebene
Eltern Elemente
Attribute
ignore_unknown_hosts="yes_no" (Initialwert:no)
Mit ignore_unknown_hosts="yes" ignoriert der JobScheduler unbekannte oder nicht auflösbare Hostnamen in <
allowed_host>.
Das Attribut wirkt nur auf die hier angegebenen <allowed_host>, nicht auf die Basiskonfiguration.
XML-Element <service_request>
<service_request
url
>
web_service
content
</service_request>
= "url"
Web-Dienst
Inhalt einer Web-Dienst-Anforderung
Beispiel:
<service_request url="http://host.company.com:80/web_service">
<content>
<my_request>
…
</my_request>
</content>
</service_request>
<service_request> tritt an zwei Stellen auf:
•
•
Als Eingabe einer XLST-Transformation mit <web_service request_xslt_stylesheet="…"> .
Als Ergebnis einer XLST-Transformation mit <web_service forward_xslt_stylesheet="…"> .
Attribute
url="url"
URL des Web-Dienstes
August 2014
69
XML-Element <service_response>
<service_response >
content
</service_response>
Inhalt einer Web-Dienst-Anforderung
XML-Element <settings>
<settings >
mail_on_error
mail_on_warning
mail_on_success
mail_on_process
mail_on_delay_after_err
or
log_mail_to
log_mail_cc
log_mail_bcc
log_level
history
history_on_process
history_with_log
</settings>
Ergänzt ein Element <settings> an der entsprechenden Stelle mit gleichem Attribut name= aus der
Eltern Elemente
XML-Element <sos.spooler.variable_set>
<sos.spooler.variable_set >
variable
Eine Variable
</sos.spooler.variable_set>
Beispiel:
<sos.spooler.variable_set>
<variable name="param1" value="11111">
<variable name="param2" value="2222">
</sos.spooler.variable_set>
<sos.spooler.variable_set> wird beim Speichern der Order.payload in der Datenbank verwendet.
Siehe auch <params> (Seite 54).
August 2014
70
XML-Element <spooler>
<spooler >
config
</spooler>
Konfiguration
XML-Element <start_job>
<start_job
job
name
after
at
force
web_service
= "job_name"
= "name"
= "zahl"
= "yyyy-mm-dd hh:mm:ss | now |
period"
= "yes|no"
= "name"
>
params
</start_job>
Parameter
Beispiel:
<start_job job="mein_job" at="now">
<params>
<param name="anzahl" value="100"/>
</params>
</start_job>
Eltern Elemente
<commands> - XML-Kommandos
Attribute
job="job_name"
Der Jobname.
name="name"
Hier kann der Task ein Name gegeben werden.
after="zahl"
Eine Anzahl Sekunden, nach deren Ablauf erst die Task gestartet werden soll.
at="yyyy-mm-dd hh:mm:ss | now | period" (Initialwert:now)
Zeitpunkt, zu dem die Task gestartet werden soll. Die Voreinstellung force="yes" setzt <run_time> ist außer
Kraft.
Relative Zeitangaben "now", "now + HH:MM[:SS]" und "now + SECONDS" sind möglich.
August 2014
71
at="period" lässt den Job erst Starten, wenn die <run_time> dies zulässt (also in der laufenden oder der
nächsten Periode).
force="yes|no" (Initialwert:yes)
force="no":
•
•
•
Wenn der Job gestoppt ist, bleibt er gestoppt.
Wenn mit at= eine Startzeit angegeben ist, zu dem Zeitpunkt <run_time> oder <schedule> keine Start
zulassen, dann verschiebt der JobScheduler den Start bis zur nächsten Periode.
Daraus ergibt sich, dass at="now" wie at="period" wirkt.
force="yes":
•
•
Der Job wird sofort entstoppt (falls er gestoppt ist)
Eine mit at= angegebene Startzeit nimmt keine Rücksicht auf <run_time> oder <schedule> , die Task wird
also auch zu dem Zeitpunkt gestartet, wenn keine Periode vorliegt.
web_service="name"
Wenn die Task ausgeführt worden ist, wird sie mit einem Stylesheet transformiert und einem Web-Dienst
übergeben.
XML-Element <start_when_directory_changed>
<start_when_directory_changed
directory
= "path"
regex
= "regex"
> </start_when_directory_changed>
<start_when_directory_changed directory="directory" regex="regex"/> wirkt wie der programmierte
Aufruf
start_when_directory_changed( "directory", "regex" ).
Wenn das Verzeichnis nach dem Start des Schedulers entfernt wird, also nicht mehr überwacht werden kann,
startet eine Task, während der Job gestoppt wird. Weitere Tasks werden nicht gestartet (weil der Job gestoppt ist).
Der Job sollte mit <run_time repeat="…"> periodisch gestartet und mit <delay_after_error> versehen werden.
Siehe Verzeichnisüberwachung mit Dateiaufträgen (Seite 159) und Job.start_when_directory_changed() .
Eltern Elemente
Attribute
directory="path"
Eine Änderung des Verzeichnisses (Datei wird hinzugefügt oder gelöscht) führt zum Start einer Task. Ebenso,
wenn das Verzeichnis entfernt wird.
August 2014
72
regex="regex"
Wenn Sie hier einen Regulären Ausdruck angeben, werden nur Dateinamen beachtet, die ihm entsprechen.
Das Löschen einer Datei, deren Namen dem Regulären Ausdruck entsprach, führt nicht zum Start des Jobs.
XML-Element <ultimos>
<ultimos >
day
</ultimos>
Setzt die Perioden für einen bestimmten Tag des Monats fest, vom Ende her gezählt.
Beispiel:
<ultimos>
<day day="0">
</day>
<day day="1">
</day>
</ultimos>
Setzt die Laufzeiten fest für den Letzten eines Monats 10:00 bis 12:00 und für den Vorletzten eines Monats 08:00 bis
12:00 und 15:00 bis 18:00.
Ergänzt ein Element <ultimos> an der entsprechenden Stelle aus der Basiskonfiguration. Hier angegebene
Eltern Elemente
XML-Element <variable>
<variable
name
value
> </variable>
= ""
= ""
Name der Umgebungsvariablen
Wert der Umgebungsvariablen
Ergänzt ein Element <variable> an der entsprechenden Stelle mit gleichem Attribut name= aus der
Eltern Elemente
<environment> - Umgebungsvariablen
August 2014
73
<sos.spooler.variable_set> - Variablenmenge
Attribute
name="" Name der Umgebungsvariablen
Der Name der Umgebungsvariablen. Unter Windows ist die Großschreibung nicht relevant.
Derselbe Name kann mehrmals verwendet werden, wenn der Wert erweitert werden soll (s. Beispiel mit PATH).
value="" Wert der Umgebungsvariablen
Mit '$' kann der Wert einer Umgebungsvariablen abgerufen werden, die auch eine vorher mit <variable> gesetzte
sein kann.
XML-Element <web_service>
<web_service
name
url_path
= "name"
= "url_path"
job_chain
= "job_chain"
timeout
request_xslt_stylesheet
= "seconds"
= "path"
response_xslt_stylesheet
= "path"
forward_xslt_stylesheet
= "path"
debug
= "yes|no"
Name des Dienstes im Scheduler
URL-Pfad, unter dem der Web-Dienst
ansprechbar ist
Jobkette, die Web-Service-Operationen
ausführt
Frist
Transformiert die Anforderung in ein
Scheduler-Kommando
Transformiert die Antwort des Kommandos
in die Antwort des Web-Dienstes
Zur Weiterleitung am Ende des Auftrags
bzw. der Task
>
params
</web_service>
Parameter
Web-Dienste lassen sich einrichten, um Aufträge oder Tasks zu erzeugen. Die angenommene Anforderung wird
sofort beantwortet. Das Ergebnis des Auftrags oder der Task kann zu einem anderen Web-Dienst weitergeleitet
werden.
Der TCP-Port des HTTP-Servers wird mit <config tcp_port="…"> festgelegt.
Zwei Arten von Web-Services werden unterschieden:
•
Web-Service mit job_chain
•
Web-Service mit request_xslt_stylesheet
Web-Service mit job_chain
<web_service
name
url_path
job_chain
timeout
/>
=
=
=
=
"my_web_service"
"/web_service"
"web_service"
"900"
August 2014
74
Ein HTTP-POST auf den URL-Pfad des Web-Dienstes lässt den JobScheduler einen Auftrag erzeugen und ihn in
die angegebene Jobkette einreihen. Die Jobs haben Zugriff auf die HTTP-Daten über
Order.web_service_operation . Die HTTP-Anfrage wird mit Web_service_response.send() beantwortet.
Web-Service mit request_xslt_stylesheet
<web_service
name
url_path
request_xslt_stylesheet
response_xslt_stylesheet
forward_xslt_stylesheet
/>
=
=
=
=
=
"my_web_service"
"/web_service"
"$SCHEDULER_DIR/web_service_request.xsl"
"$SCHEDULER_DIR/web_service_response.xsl"
"$SCHEDULER_DIR/web_service_forward.xsl"
Ein HTTP-POST auf den URL-Pfad des Web-Dienstes löst folgende Schritte aus.
1.
Das mit HTTP-POST übergebene XML-Dokument packt der JobScheduler in ein <service_request> .
<service_request>
<web_service name="service_name" url_path="url_path"/>
<content>…xmldata…</content>
</service_request>
2.
3.
4.
Das <service_request> wird mit dem Stylesheet request_xslt_stylesheet in ein XML-Kommando
transformiert, in der Regel <add_order> oder <start_job> .
Der JobScheduler führt das XML-Kommando aus.
Die Antwort des XML-Kommandos (<spooler> <answer> , die auch eine Fehlermeldung <ERROR> enthalten
kann) wird mit dem response_xslt_stylesheet zu einem <service_response> transformiert. Der
JobScheduler liefert den Inhalt von <content> über die offene HTTP-Verbindung zurück.
<service_response>
<content>…xmldata…</content>
</service_response>
5.
Um eine ungültige Anforderung zu beantworten, kann das Stylesheet request_xslt_stylesheet sofort ein <
service_response> liefern.
Fehlerbehandlung
Wenn mit POST kein XML-Dokument übergeben worden ist, führt das zum HTTP-Fehlercode "404 Bad Request".
Ein Fehler in der Transformation führt zum HTTP-Fehlercode "500 Internal Server Error".
Ergebnis der Ausführung weiterleiten (Forwarding)
Aufträge und Tasks können einem Web-Dienst zugeordnet sein. Die Kommandos <add_order> und <start_job>
erhalten dazu das neue Attribut web_service="service_name".
Solche Aufträge und Tasks werden, wenn sie enden und dem Web-Dienst ein forward_xslt_stylesheet
zugeordnet ist, mit diesem als <order> bzw. <task> übergeben:
<order service="service_name" last_job="job_name" …>
<payload>
<params>
…
</params>
</payload>
<log last_error="…" last_warning="…"/>
…
</order>
bzw.
August 2014
75
<task job="…" …>
<log last_error="…" last_warning="…"/>
…
</task>
Ergebnis der Transformation ist ein <service_request> :
<service_request url="url">
<content>…data…</content>
</service_request>
Jobkette scheduler_service_forwarding
Der JobScheduler packt das <service_request> in die Payload eines neuen Auftrags und übergibt diesen der
vordefinierten Jobkette scheduler_service_forwarding.
JobScheduler_service_forwarder
Der einzige Job der Jobkette, scheduler_service_forwarder, baut mit dem URL eine HTTP-Verbindung auf,
überträgt mit POST die Daten, wartet die Antwort ab und protokolliert sie.
Eigenschaften des Jobs können in der Konfigurationsdatei eingestellt werden, wie wenn der Job mit <base>
bekannt gemacht worden wäre. Ein Beispiel:
<job name="scheduler_service_forwarder">
<delay_order_after_setback setback_count="1" delay="00:01"/>
<run_time>
</run_time>
</job>
Implementiert ist der Job in Java (siehe auch <web_service forward_xslt_stylesheet="…"> (Seite 73)).
Ergänzt ein Element <web_service> an der entsprechenden Stelle aus der Basiskonfiguration. Hier angegebene
Eltern Elemente
Attribute
name="name" Name des Dienstes im Scheduler
url_path="url_path" URL-Pfad, unter dem der Web-Dienst ansprechbar ist
Er soll mit einem Schrägstrich beginnen.
job_chain="job_chain" Jobkette, die Web-Service-Operationen ausführt
August 2014
76
Eine Web-Service-Anforderung erzeugt einen Auftrag, der in diese Jobkette eingereiht wird. Die Nutzdaten der
Anforderung stehen in spooler_task.order.web_service_operation.request.binary_content.
Nicht zusammen mit den Attributen request_xslt_stylesheet und response_xslt_stylesheet verwendbar.
Für den Zugriff auf die Web-Anforderung siehe Order.web_service_operation .
timeout="seconds" Frist
Wenn innerhalb der Frist der Auftrag nicht dem ersten Job zur Ausführung übergeben wird, lehnt der JobScheduler
die HTTP-Anforderung mit "504 Gateway Timeout" ab und zieht den Auftrag mit der Meldung SCHEDULER-290
zurück.
request_xslt_stylesheet="path" Transformiert die Anforderung in ein Scheduler-Kommando
Pfad des XSLT-Stylesheets, das das mit HTTP-POST übergebene XML-Dokument in ein Scheduler-Kommando
wandelt.
Nicht zusammen mit dem Attribut job_chain verwendbar.
response_xslt_stylesheet="path" Transformiert die Antwort des Kommandos in die Antwort des
Web-Dienstes
Pfad des XSLT-Stylesheets, das das XML-Ergebnis des Scheduler-Kommandos in ein XML-Dokument wandelt, mit
der der JobScheduler die Web-Dienst-Anfrage beantwortet.
forward_xslt_stylesheet="path" Zur Weiterleitung am Ende des Auftrags bzw. der Task
Wenn ein mit <add_order web_service="…"> gestarteter Auftrag oder eine mit <start_job web_service="…">
gestartete Task endet und ein forward_xslt_stylesheet angegeben ist, dann wird der Auftrag bzw. die Task mit
dem Stylesheet zu einem <service_request> transformiert, das den Aufruf eines anderen Web-Dienstes auslöst.
Benötigt
Java
und
das
Klassen-Archiv
xercesImpl.jar
im
CLASS_PATH
(s.
<c o n f i g
java_class_path="…/xercesImpl.jar"> ).
debug="yes|no" (Initialwert:no)
Nur, wenn request_xslt_stylesheet angegeben ist:
debug="yes" lässt den JobScheduler die intern erzeugten XML-Dokumente in Dateien im mit -log-dir
festgelegten Verzeichnis ablegen:
Der JobScheduler räumt die Dateien nicht ab.
August 2014
77
XML-Element <weekday>
<weekday
day
which
>
period
</weekday>
= "weekday"
= "integer"
Periode
Beispiel:
<monthdays>
<day day="1">
</day>
<day day="2">
</day>
</monthdays>
Setzt die Laufzeiten fest für den Ersten eines Monats 10:00 bis 12:00 und für den Zweiten eines Monats 08:00 bis
12:00 und 15:00 bis 18:00.
Beispiel:
<monthdays>
<day day="5">
</day>
</monthdays>
Startet den Job an jedem 5. eines Monats um 16 Uhr.
Ergänzt ein Element <weekday> an der entsprechenden Stelle aus der Basiskonfiguration. Hier angegebene
Eltern Elemente
<monthdays> - Perioden für bestimmte Tage des Monats
Attribute
day="weekday"
Name des Wochentags: "monday", "tuesday", "wednesday", "thursday", "friday", "saturday" und "sunday".
Mehrere Tage können durch Leerzeichen getrennt angegeben werden.
which="integer"
which="1" bis which="4": Der erste bis vierte Wochentag eines jeden Monats.
August 2014
78
which="-1" bis which="-4": Der letzte bis viertletzte Wochentag eines jeden Monats.
XML-Element <weekdays>
<weekdays >
day
</weekdays>
Setzt die Perioden für bestimmten Wochentage fest.
Beispiel:
<weekdays>
<day day="1">
</day>
<day day="2">
</day>
</weekdays>
Setzt die Laufzeit fest für Montags 10:00 bis 12:00 und Dienstags 08:00 bis 12:00 und 15:00 bis 18:00.
Ergänzt ein Element <weekdays> an der entsprechenden Stelle aus der Basiskonfiguration. Hier angegebene
Eltern Elemente
1.2 Konfiguration aus Hot Folders
Jobs, Job-Ketten, Daueraufträge, Prozessklassen und Sperren (im folgenden Objekte genannt) können in
einzelnen Dateien gehalten werden, die der JobScheduler automatisch nach Änderung übernimmt. Der
JobScheduler überwacht Verzeichnisse (Hot Folders), für die hinzugefügte, geänderte und gelöschte Dateien als
entsprechende Operationen zum Hinzufügen, Ändern und Entfernen von Jobs, Job-Ketten etc. ausgeführt werden.
1.2.1 Konfigurationsverzeichnis
Die Dateien liest der JobScheduler aus dem Konfigurationsvereichnis und dessen Unterverzeichnissen. Das
Konfigurationsverzeichnis kann eingestellt werden mit
•
•
configuration_directory="…"> , voreingestellt ist das Verzeichnis ./config/live im
Verzeichnis der Konfigurationsdatei.
-config . Die Konfigurationsdatei erwartet der JobScheduler dann im Konfigurationsverzeichnis
(Voreinstellung ./config) unter dem Namen scheduler.xml.
<config
Der JobScheduler überwacht das Konfigurationsverzeichnis und seine Unterverzeichnisse und übernimmt
hinzugefügte und geänderte Dateien. Löschen einer Datei führt zum Löschen des entsprechenden Objekts im
JobScheduler.
August 2014
79
Unter Windows verwendet der JobScheduler die Verzeichnisüberwachung des Betriebsystems, bemerkt
Änderungen also sofort. Außerdem prüft er die Verzeichnisse im Minutenabstand.
Unter Unix überwacht der JobScheduler die Verzeichnisse im Abstand von zwischen 5 und 60 Sekunden. Nach
einer Änderung verkürzt er den Abstand auf fünf Sekunden und verlängert ihn, wenn keine Änderung vorliegt, bis
auf 60 Sekunden.
Achtung!
Seit Version 1.5.xx der JobScheduler engine werden Ordner, deren Name mit einem . (Punkt) beginnt, nicht
überwacht. Konfigurationsdateien, die sich in einem solchen Ordner befinden, werden ignoriert.
1.2.2 Dateien für Prozessklassen, Sperren, Jobs, Job-Ketten und Daueraufträge
Die Dateien enthalten die XML-Elemente für die Definition des Objekts und werden aufgrund folgender
Namenskonventionen verarbeitet:
Das Attribut name= sollte nicht angegeben werden. Wird es angegeben, muss es dem Dateinamen entsprechen.
Die Attribute replace= und spooler_id= sind nicht zulässsig.
Beispiel eines Jobs (auftragsgesteuert): Datei hello_world.job.xml:
<job order="yes">
echo hello world
]]></script>
</job>
Beispiel einer Job-Kette: Datei echo_hello.job_chain.xml:
<job_chain>
<job_chain_node state="start" job="hello_world" next_state="success"
error_state="error"/>
<job_chain_node state="success"/>
<job_chain_node state="error"/>
</job_chain>
Beispiel eines Auftrags: Datei echo_hello,echo_trigger.order.xml:
<order>
<run_time>
<period repeat="3600"/>
</run_time>
</order>
1.2.3 Spiegelung des Verzeichnisses im JobScheduler
Der JobScheduler legt für jede Datei mit bekannter Dateinamensendung ( .job usw.) ein entsprechendes Objekt im
JobScheduler an und verbindet es mit der Datei. Der JobScheduler überwacht den Zeitstempel der Datei und geht
bei Änderung wie folgt vor.
August 2014
80
•
•
•
•
•
•
Ein hinzugefügter Dateiname führt zur Anlage eines neuen, noch leeren Objekts im JobScheduler, das mit der
Datei verbunden ist. Das Objekt ist mit <show_state> sichtbar. Z.B. wird eine Datei xxx.job.xml im
JobScheduler gespiegelt als ein Job <job name="xxx"> , auch wenn die Datei nicht lesbar ist.
Eine gelöschte Datei führt zum Löschen des Objekts. Das Löschen wird in der Regel verzögert, weil z.B. bei
einem Job das Ende der Tasks abgewartet werden muss.
Wenn während des Löschens die Datei wieder angelegt wird, geht der JobScheduler wie bei einer
geänderten Datei vor.
Nach einer Änderung einer Datei (der Zeitstempel hat sich geändert) liest der JobScheduler die Datei. Kann
die Datei geladen werden, dann tauscht er Prozessklassen und Sperren direkt, während er Jobs, Job-Klassen
und Daueraufträge verzögert tauscht, weil noch die laufenden Operationen des zu ersetzenden Objekts
abgewartet werden müssen (Details unten).
Ein Fehler beim Lesen einer Datei beeinflusst nicht ein bereits vorhandenes Objekt. Der JobScheduler
vermerkt den Fehler im Objekt und verschickt eine eMail. <show_state> zeigt den Fehler.
Objekte mit denselben (Datei)Namen können mehrfach in unterschiedlichen Verzeichnissen vorhanden sein.
Der JobScheduler unterscheidet diese Objekte anhand ihres Pfads. Wenn auf Objekte aus anderen
Verzeichnissen verwiesen wird, z.B.
<job
process_class="/my_project/multi.process_class.xml"/>
<job_chain_node job="/other_project/hello_world"/>
dann müssen absolute oder relative Pfade angegeben werden.
1.2.4 Wirkung der Kommandos zum Ändern und Löschen
Kommandos zum Ändern von Objekten ändern nicht die Dateien.
Kommandos zum Löschen von Objekten löschen die zugrundliegende Datei (die Debug-Version des Schedulers
versieht den Dateinamen mit dem Anhängsel "-REMOVED").
1.2.5 Verhalten der einzelnen Objekttypen
1.2.5.1 Prozessklassen
Änderungen an einer Prozessklasse übernimmt der JobScheduler sofort.
Beim Löschen einer Prozessklasse beendet der JobScheduler alle zugehörigen Tasks. Erst wenn keine Task mehr
läuft, löscht er die Prozessklasse. Bis dahin startet der JobScheduler keine weiteren Tasks, uns verhält sich als ob
die Prozessklasse erschöpft wäre.
1.2.5.2 Sperren
Änderungen an einer Sperre übernimmt der JobScheduler sofort.
Beim Löschen einer Sperre beendet der JobScheduler alle zugehörigen Tasks. Erst wenn keine Task mehr läuft,
löscht er die Sperre. Bis dahin startet der JobScheduler keine weiteren Tasks, und verhält sich als ob die Sperre
belegt wäre.
1.2.5.3 Jobs
Einen geänderten Job übernimmt der JobScheduler, nachdem er alle Tasks beendet hat.
August 2014
81
Beim Löschen verfährt der JobScheduler ebenso. Keine neue Tasks werden gestartet.
Fehlt dem Job die Prozessklasse oder eine Sperre, wirkt das so, als ob die Prozessklasse erschöpft oder die
Sperre nicht verfügbar wäre.
1.2.5.4 Job-Ketten
Eine geänderte Job-Kette übernimmt der JobScheduler, nachdem alle Aufträge ihren Job-Schritt beendet haben.
Weitere Job-Schritte werden solange verhindert.
Aufträge in Job-Kettenknoten mit gleichem Auftragszustand übernimmt der JobScheduler in die geänderte
Job-Kette.
Beim Löschen verfährt der JobScheduler ebenso.
Fehlt der Job-Kette ein Job, dann sammeln sich die Aufträge im Job-Kettenknoten, als wäre der Job nicht zur
Auftragsausführung bereit.
1.2.5.5 Verschachtelte Job-Ketten
Fehlt der Job-Kette eine verschachtelte Job-Kette <job_chain_node.job_chain> , dann ist die gesamte Job-Kette
nicht bereit. Alle untergeordneten Job-Ketten müssen bekannt sein, damit der JobScheduler die Eindeutigkeit der
Auftragskennungen sicherstellen kann.
Ebenso wird eine untergeordnete Job-Kette erst gelöscht, wenn auch die übergeordnete Job-Kette gelöscht ist.
1.2.5.6 Daueraufträge
Daueraufträge werden anders behandelt als die anderen Objekte. Zum einen haben sie einen zusammengesetzten
Namen (job_chain= und id= statt name=), zum anderen werden Dateiänderungen nicht jederzeit beachtet. Eine
gelöschte oder geänderte Auftragsdatei wird nur beachtet, wenn
•
•
•
der Auftrag nicht bekannt,
der Auftrag noch nicht gestartet worden oder
der Auftrag wegen <run_time> wiederholt, aber noch nicht gestartet worden ist.
1.2.6 Kommando <show_state>
Das Kommando liefert zu jedem dateibasiertem Objekt ein <file_based> mit Angaben zur Datei.
Wenn eine Ersetzung im Gang ist, zeigt <replacement> dies an.
Wenn eine Datei gelöscht ist, aber das dazugehörige Objekt noch nicht, wird <removed> geliefert.
1.3 Zentrale Konfiguration durch einen Supervisor JobScheduler
Bei der zentralen Administration von Konfigurationen für Objekte (Jobs, Job-Ketten, Aufträgen und Sperren)
melden sich sogenannte "Workload JobScheduler" an einem zentralen JobScheduler, dem "Supervisor" an und
werden von ihm mit den Konfigurationsdateien für Objekte versorgt. Zusätzlich zu der vom Supervisor
bereitgestellten Konfiguration werden die lokalen Konfigurationen aus den Hot Folders (Seite 78) der Workload
JobScheduler (./config/live) sowie der Konfigurationsdatei ./config/scheduler.xml eingelesen.
August 2014
82
1.3.1 Eine typische Konfiguration
Ein Supervisor JobScheduler mit dem Verzeichnis ./config/remote. Darin gibt es einen Ordner _all, der
allgemeine Objekte für alle Workload JobScheduler bereitstellt. Für die Workload JobScheduler gibt es jeweils ein
Verzeichnis mit den zu replizierenden Objekten.
1.3.2 Der Supervisor
Der Supervisor verwaltet die Konfigurationen für die Workload JobScheduler in dem Verzeichnis ./config/remote.
Beim Start des Supervisors sowie bei Änderungen an den Konfigurationsdateien werden diese an die betroffenen,
laufenden Workload JobScheduler in deren Verzeichnis ./config/cache repliziert. Die Workload JobScheduler
überwachen dieses lokale Verzeichnis und übernehmen die Konfigurationen daraus (siehe Hot Folders (Seite 78)).
Im zentralen Konfigurationsverzeichnis ./config/remote wird dazu pro Workload JobScheduler ein Verzeichnis
mit dem Namen host#port angelegt. Außerdem wird pro vorhandenem JobScheduler Cluster siehe Backup
Clusters (Seite 138) und Load Balancing (Seite 164), ein Verzeichnis mit der Scheduler ID des Clusters angelegt.
Die in den jeweiligen Verzeichnissen enthaltene Verzeichnisstruktur wird an die zugehörigen Workload
JobScheduler bzw. an den zugehörigen JobScheduler Cluster repliziert.
Zusätzlich wird die Verzeichnisstruktur, die im Ordner _all vorliegt, an alle Workload JobScheduler repliziert.
Damit ist es möglich Definitionen für Objekte, die für alle Workload JobScheduler gültig sein sollen, an einer Stelle
zu verwalten.
Fällt der Supervisor aus, können die Workload JobScheduler mit der zuletzt erfolgreich replizierten Konfiguration
problemlos gestartet werden.
August 2014
83
1.3.3 Einen JobScheduler an den Supervisor anmelden
Ein Workload JobScheduler meldet sich am Supervisor mit einem Eintrag in der Konfigurationsdatei
./config/scheduler.xml an. Das Attribut <config supervisor="…"> im Element config bezeichnet den Host
und den Port des Supervisors in der Syntax host:port.
Wenn der Supervisor nicht erreichbar ist, startet der Workload JobScheduler mit der zuletzt erfolgreich replizierten
Konfiguration.
1.3.4 Wirksamkeit von lokalen Änderungen an der Konfiguration
Lokale Konfigurationen können zusätzlich zu der Konfiguration, die durch den Supervisor bereitgestellt wurde,
angelegt werden.
Die JobScheduler Konfigurationsdatei ./config/scheduler.xml eines Workload Schedulers kann Definitionen für
lokale Objekte beinhalten. Ebenso können im Hot Folder ./config/live lokale Objekte definiert werden.
Die zentral beim Supervisor gespeicherte und erfolgreich replizierte Konfiguration hat Vorrang vor lokalen
Konfigurationen. Bei Namensgleichheit wird die zentrale Konfiguration verwendet. Wenn ein bereits in der
zentralen Konfiguration vorhandenes Element in der lokalen Konfiguration hinzugefügt wird, wird das vom
Workload JobScheduler bemerkt und abgewiesen. Im Protokoll wird dann eine entsprechende Warnung
eingetragen.
Wenn beim Supervisor ein Objekt hinzugefügt wird, das bereits in der lokalen Konfiguration vorhanden ist, wird die
lokale Konfiguration überschrieben. Die lokale Konfigurationsdatei bleibt erhalten, wird aber nicht mehr verwendet
(stattdessen wird eine Warnung ins Protokoll geschrieben s.o.).
Wird ein Objekt beim Supervisor gelöscht, das auch in der lokalen ´Konfiguration vorhanden ist, wird der Job aus
dem Workload JobScheduler entfernt:
a) Der Job ist im Hot Folder (Seite 78) ./config/live lokal konfiguriert: die lokale Konfiguration wird eingelesen
b) Der Job ist in ./config/scheduler.xml konfiguriert: der Job wird beim nächsten Start des JobSchedulers
eingelesen.
1.3.5 Übernehmen einer vorhandenen Konfiguration in die zentrale Verwaltung
Wenn ein vorhandener, lokal administrierter JobScheduler in die zentrale Verwaltung eines Supervisors
aufgenommen werden soll, sind folgende Schritte notwendig.
•
•
•
•
Ordner für Workload JobScheduler beim Supervisor anlegen (./config/remote/host#port)
Ordner ./config/cache beim Workload JobScheduler anlegen
Inhalt von Ordner ./config/live des Workload JobSchedulers nach ./config/remote/host#port des
Supervisors kopieren
Anmeldung an an Supervisor konfigurieren. Dazu Eintrag <config supervisor="…"> in
./config/scheduler.xml des Workload JobSchedulers anlegen
1.3.6 Verhalten der JobScheduler beim Start
August 2014
84
1.3.6.1 Workload JobScheduler
Der JobScheduler baut die Verbindung zum Supervisor auf und bestellt die Konfiguration. Erst nach der Replikation
beginnt er den Betrieb. Wenn der Supervisor nicht erreichbar ist, verwendet der JobScheduler die vorhandene
Konfiguration. Falls die Replikation später möglich wird, wird sie durchgeführt. Änderungen an der zentralen
Konfiguration werden dann sofort wirksam.
1.3.6.2 Supervisor JobScheduler
Wenn der Supervisor startet, repliziert er die Konfigurationen für die Workload JobScheduler.
1.4 Datei factory.ini
In der Datei factory.ini können Einstellungen für den JobScheduler vorgenommen werden.
Hinweis: Leere Einträge "eintrag=" gelten als nicht vorhanden und überschreiben keine Einstellung der
XML-Konfiguration (Seite 7).
Beim Aufruf des JobSchedulers können Sie den Pfad dieser Datei mit der Option -ini angeben, z.B.:
…scheduler installation path…\bin\scheduler.exe
-ini=C:/Programme/scheduler/config/factory.ini
Bei der Installation durch das Setup-Programm des JobSchedulers wird die Datei factory.ini im Verzeichnis
…scheduler installation path…\config
abgelegt. Aufrufe über das Startskript setzen den Pfad automatisch richtig.
Falls beim Aufruf des JobSchedulers der Pfad zur Datei sos.ini nicht angegeben wird, gelten folgende Vorgaben:
Unter Windows sollte die Datei dort angelegt werden, wo Windows seine .ini-Dateien erwartet. Das ist
normalerweise im Verzeichnis c:\windows. Sonst wird die Datei im Heimverzeichnis des Benutzers erwartet.
Einstellungen
Sektion: java
class_path = class_path Für Java
Hier können Sie den class_path um Verzeichnisse oder Jars erweitern, die nur für den JobScheduler gelten. Die
Angaben werden der Einstellung in sos.ini (Abschnitt [java], Eintrag class_path= …) vorangestellt.
Sektion: job
history = yes|no Historie schreiben?
Gibt an, ob eine Task-Historie geschrieben werden soll. Der JobScheduler schreibt dann für jede Task einen Satz in
die Datenbank, oder, wenn der JobScheduler ohne Datenbank arbeitet, in eine Datei im mit -log-dir
angegebenen Verzeichnis.
Die Einstellung factory.ini (Abschnitt [spooler], Eintrag history= yes) wird damit überschrieben.
history_archive = yes|no|gzip Historiendateien archivieren?
August 2014
85
Wenn die Historie in einer Datei, d.h. nicht in einer Datenbank, geführt wird, kann der JobScheduler die Historien
des letzten JobScheduler Laufs archivieren und mit gzip komprimieren.
Die Einstellung factory.ini (Abschnitt [spooler], Eintrag history_archive= no) wird damit überschrieben.
history_columns = name, name, ... Zusätzliche Spalten in der Historie
Eine Task kann mit der Methode Task.set_history_field() die hier angegebenen Felder der Datenbanktabelle
für die Task-Historie setzen.
Die Einstellung factory.ini (Abschnitt [spooler], Eintrag history_columns= …) wird damit überschrieben.
history_file = dateiname Dateiname der Historie (für datenbanklosen Betrieb)
(Seit Version 1.5 wird keine dateibasierte Historie mehr geschrieben. Die databank-basierte Historie ist weiterhin
möglich.)
Die Einstellung factory.ini (Abschnitt [spooler], Eintrag history_file= …) wird damit überschrieben.
history_on_process = yes|no|zahl Nach spooler_process() Historiensatz schreiben?
Bei history_on_process=no oder =0 schreibt der JobScheduler beim Start der Task einen Satz in die Historie,
wenn eine geführt wird.
Bei history_on_process=yes oder =1 schreibt der JobScheduler erst beim ersten Aufruf von spooler_process()
den Satz. Damit wird kein Satz geschrieben, wenn spooler_open() false liefert.
Wenn eine Zahl angegeben ist, schreibt der JobScheduler erst vor der angegebenen Anzahl von Aufrufen von
spooler_process() einen Satz in die Historie.
Die Einstellung factory.ini (Abschnitt [spooler], Eintrag history_on_process= 0) wird damit überschrieben.
Meldungen
[ERROR]
SCHEDULER-335
Only "yes", "no" and a number are allowed with ="": error history_with_log = yes|no|gzip Protokoll in die Historie schreiben?
Der JobScheduler kann das Task-Protokoll in die Historie in der Datenbank schreiben, auch mit gzip komprimiert.
Siehe Kommando <show_task what="log"> (Seite 203).
Die Einstellung factory.ini (Abschnitt [spooler], Eintrag history_with_log= no) wird damit überschrieben.
log_level = log_level Protokollausgaben beschränken
Legt fest, ab welcher Stufe der JobScheduler Protokollzeilen ausgibt. Jede Protokollzeile ist auf einer der
folgenden Stufen: error, warn, info, debug1 bis debug9 (debug1 ist dasselbe wie debug).
Die Option -log-level hat Vorrang.
Die Einstellung factory.ini (Abschnitt [spooler], Eintrag log_level= info) wird damit überschrieben.
log_mail_bcc = email_address Bcc-Empfänger der eMails
Die Einstellung factory.ini (Abschnitt [spooler], Eintrag log_mail_bcc= …) wird damit überschrieben.
log_mail_cc = email_address Cc-Empfänger der eMails
August 2014
86
Die Einstellung factory.ini (Abschnitt [spooler], Eintrag log_mail_cc= …) wird damit überschrieben.
log_mail_from = email_address Absender der eMails
Die Einstellung factory.ini (Abschnitt [spooler], Eintrag log_mail_from= …) wird damit überschrieben.
log_mail_subject = text Betreff der eMails
Die Einstellung factory.ini (Abschnitt [spooler], Eintrag log_mail_subject= …) wird damit überschrieben.
log_mail_to = email_address To-Empfänger der eMails
Die Einstellung factory.ini (Abschnitt [spooler], Eintrag log_mail_to= …) wird damit überschrieben.
mail_on_delay_after_error = Unterdrückung der eMail bei <delay_after_error>
Voraussetzung: mail_on_error=yes oder mail_on_warning=yes
Wenn ein Job wegen <delay_after_error> erneut startet, werden mit dieser Einstellungen die zahlreichen eMails
reduziert.
Die Einstellung wirkt nicht, wenn für den Job kein <delay_after_error> angegeben ist (dann gilt
mail_on_delay_after_error=all).
Die
Einstellung factory.ini
(Abschnitt [spooler],
first_and_last_only) wird damit überschrieben.
Eintrag
mail_on_delay_after_error=
mail_on_error = yes|no Mit Fehler beendete Task verschickt eMail
Die Einstellung factory.ini (Abschnitt [spooler], Eintrag mail_on_error= no) wird damit überschrieben.
mail_on_process = yes|no|zahl Task mit spooler_process() verschickt eMail
Veranlasst den Versand des Task-Protokolls, wenn die Task wenigstens die angegebene Anzahl Schritte, also
Aufrufe von spooler_process() , ausgeführt hat. Weil Nicht-API-Tasks keine Schritte haben, zählt der
JobScheduler für sie immer einen Schritt.
yes entspricht 1, no entspricht 0.
Die Einstellung factory.ini (Abschnitt [spooler], Eintrag mail_on_process= 0) wird damit überschrieben.
mail_on_success = yes|no Erfolgreich gelaufende Task verschickt eMail
Die Einstellung factory.ini (Abschnitt [spooler], Eintrag mail_on_success= no) wird damit überschrieben.
mail_queue_dir = verzeichnis Verzeichnis der zeitweilig nicht versendbaren eMails
eMails, die der JobScheduler nicht verschicken kann (weil z.B. der SMTP-Server nicht erreichbar ist), werden hier
abgelegt.
Um diese eMails später zu verschicken, muss ein Job geschrieben werden, der die Methode Mail.dequeue()
aufruft.
Der allgemeine Platz für diese Einstellung ist sos.ini (Abschnitt [mail], Eintrag queue_dir= …).
Die Einstellung factory.ini (Abschnitt [spooler], Eintrag mail_queue_dir= …) wird damit überschrieben.
August 2014
87
Die Einstellung sos.ini (Abschnitt [mail], Eintrag queue_dir= …) wird damit überschrieben.
smtp = host_address Hostname oder IP-Nummer des SMTP-Servers für eMail Versand
Der allgemeine Platz für diese Einstellung ist sos.ini (Abschnitt [mail], Eintrag smtp= …).
Die Einstellung factory.ini (Abschnitt [spooler], Eintrag smtp= …) wird damit überschrieben.
Die Einstellung sos.ini (Abschnitt [mail], Eintrag smtp= …) wird damit überschrieben.
Sektion: smtp
mail.smtp.password = password Kennwort für Authentifizierung am SMTP-Server
Das Kennwort wird zusammen mit dem Eintrag mail.smtp.user beim eMail-Versand dem SMTP-Server zur
Anmeldung übergeben.
mail.smtp.user = name Name für Authentifizierung am SMTP-Server
Sektion: spooler
config = dateiname Konfigurationsdatei
Gibt die Konfigurationsdatei (Seite 7) an.
Die Option -config hat Vorrang.
db = verbindungszeichenfolge Verbindungszeichenfolge der Datenbank
Verbindungszeichenfolge der Datenbank für die Historienführung. Der JobScheduler unterstützt ODBC (Windows)
und JDBC für den Zugriff auf Datenbanken. Ohne Eintrag werden Dateien im .csv-Format erzeugt, siehe
factory.ini (Abschnitt [spooler], Eintrag history_file= …) (Seite 89).
Unter Windows kann ein einfacher Dateiname angegebenen werden, der auf .mdb endet (z.B. scheduler.mdb).
Der JobScheduler verwendet dann eine Microsoft MS-Access Datenbank dieses Namens, die im
Protokollverzeichnis (s. Option -log-dir ) liegt. Der JobScheduler richtet die Datei ein, wenn sie fehlt.
Der JobScheduler richtet die Tabellen selbständig ein.
August 2014
88
Beispiel:
;
SQL Server 2000 via msbase.jar, msutil.jar, mssqlserver.jar
db = jdbc -class=com.microsoft.jdbc.sqlserver.SQLServerDriver
jdbc:microsoft:sqlserver://localhost:1433;selectMethod=Cursor;databaseName=scheduler
-user=scheduler -password=secret
;
SQL Server 2000, 2005 via sqljdbc.jar
db = jdbc -class=com.microsoft.sqlserver.jdbc.SQLServerDriver
jdbc:sqlserver://localhost:1433;sendStringParametersAsUnicode=false;selectMethod=cursor
;databaseName=scheduler -user=scheduler -password=secret
;
MySQL 4.1.7, 5.x
db = jdbc -class=com.mysql.jdbc.Driver jdbc:mysql://localhost/scheduler:3306
;
Oracle 8.1.7, 9i, 10g
db = jdbc -class=oracle.jdbc.driver.OracleDriver jdbc:oracle:thin:@localhost:1521:orcl
;
PostgreSQL 8.x
db
= jdbc -class=org.postgresql.Driver jdbc:postgresql://localhost:5432/scheduler
;
IBM DB2 8
db
= jdbc -class=com.ibm.db2.jcc.DB2Driver
jdbc:db2://localhost:50000/scheduler:driverType=2;retrieveMessagesFromServerOnGetMessag
e=true; -user=scheduler -password=secret
;
Firebird 1.5
db
= jdbc -class=org.firebirdsql.jdbc.FBDriver
jdbc:firebirdsql://localhost:3050/scheduler -user=scheduler -password=secret
;
ODBC
db = odbc -db=scheduler_datasource -user=scheduler -password=secret
;
MS Access Datenbank
db = scheduler.mdb
db_check_integrity = yes|no
Der JobScheduler führt zusätzliche Prüfungen der Datenbank-Integrität durch.
db_history_table = name Name der Datenbanktabelle für die Historie
db_members_table =
db_order_history_table = name Name der Datenbanktabelle für die Auftragshistorie
db_order_step_history_table = name Name der Datenbanktabelle für die Schritte der Auftragshistorie
db_orders_table = name Name der Datenbanktabelle für die Aufträge
db_tasks_table = name Name der Datenbanktabelle für die Tasks
db_variables_table = name Name der Datenbanktabelle für die internen Variablen des JobSchedulers
Der JobScheduler hält in dieser Tabelle interne Zähler, zum Beispiel für die nächste freie Task-ID.
history = yes|no Historie schreiben?
August 2014
89
Gibt an, ob eine Task-Historie geschrieben werden soll. Der JobScheduler schreibt dann für jede Task einen Satz in
die Datenbank, oder, wenn der JobScheduler ohne Datenbank arbeitet, in eine Datei im mit -log-dir
angegebenen Verzeichnis.
Die Einstellung factory.ini (Abschnitt [job], Eintrag history= yes) hat Vorrang.
history_archive = yes|no|gzip Historiendateien archivieren?
Wenn die Historie in einer Datei, d.h. nicht in einer Datenbank, geführt wird, kann der JobScheduler die Historien
des letzten JobScheduler Laufs archivieren und mit gzip komprimieren.
Die Einstellung factory.ini (Abschnitt [job], Eintrag history_archive= no) hat Vorrang.
history_columns = name, name, ... Zusätzliche Spalten in der Historie
Eine Task kann mit der Methode Task.set_history_field() die hier angegebenen Felder der Datenbanktabelle
für die Task-Historie setzen.
Die Einstellung factory.ini (Abschnitt [job], Eintrag history_columns= …) hat Vorrang.
history_file = dateiname Dateiname der Historie (für datenbanklosen Betrieb)
(Seit Version 1.5 wird keine dateibasierte Historie mehr geschrieben. Die databank-basierte Historie ist weiterhin
möglich.)
Die Einstellung factory.ini (Abschnitt [job], Eintrag history_file= …) hat Vorrang.
history_on_process = yes|no|zahl Nach spooler_process() Historiensatz schreiben?
Bei history_on_process=no oder =0 schreibt der JobScheduler beim Start der Task einen Satz in die Historie,
wenn eine geführt wird.
Bei history_on_process=yes oder =1 schreibt der JobScheduler erst beim ersten Aufruf von spooler_process()
den Satz. Damit wird kein Satz geschrieben, wenn spooler_open() false liefert.
Wenn eine Zahl angegeben ist, schreibt der JobScheduler erst vor der angegebenen Anzahl von Aufrufen von
spooler_process() einen Satz in die Historie.
Die Einstellung factory.ini (Abschnitt [job], Eintrag history_on_process= 0) hat Vorrang.
Meldungen
[ERROR]
SCHEDULER-335
Only "yes", "no" and a number are allowed with ="": error history_with_log = yes|no|gzip Protokoll in die Historie schreiben?
Der JobScheduler kann das Task-Protokoll in die Historie in der Datenbank schreiben, auch mit gzip komprimiert.
Siehe Kommando <show_task what="log"> (Seite 203).
Die Einstellung factory.ini (Abschnitt [job], Eintrag history_with_log= no) hat Vorrang.
html_dir = verzeichnis Verzeichnis der HTML-Dateien
In diesem Verzeichnis stehen die HTML-Dateien für den HTTP-Server im JobScheduler.
Wenn die Angabe fehlt, nimmt der JobScheduler das Verzeichnis html im Verzeichnis der Konfigurationsdatei.
August 2014
90
id = scheduler_id Kennung des JobSchedulers
Der JobScheduler wählt nur die Elemente der XML-Konfiguration aus, deren Attribut spooler_id leer ist oder
denselben Wert wie in dieser Einstellung enthält.
Wenn die Scheduler-ID nicht angegeben ist, beachtet der JobScheduler das XML-Attribut spooler_id= nicht und
wählt alle Elemente der XML-Konfiguration aus.
Siehe z.B. <config> (Seite 20).
Die Option -id hat Vorrang.
include_path = verzeichnis Verzeichnispfad für <include>
Die Option -include-path hat Vorrang.
<config include_path="…"> wird damit überschrieben.
log = dateiname Dateiname des Protokolls scheduler.log
Wenn diese Einstellung gesetzt ist, schreibt der JobScheduler ein detailliertes Protokoll zur Fehlerdiagnose in die
Datei. Geben Sie den Dateinamen absolut an (als vollständigen Pfad).
Ein Plus (+) direkt vor dem Dateinamen lässt ein vorhandenenes Protokoll fortsetzen. Sonst wird es überschrieben.
Sie können das Protokoll mit Kategorien erweitern oder einschränken. Schreiben Sie die Namen der Kategorien
mit Zwischenräumen getrennt vor den Dateinamen, den Sie mit einem Größerzeichen (>) einleiten.
Hier ist die Liste der Kategorien (Seite 171).
Beispiel:
log = c:/tmp/scheduler.log
log = scheduler.wait >scheduler.log
log = scheduler.wait com_server.* >scheduler.log
Die Option -log hat Vorrang.
log_dir = verzeichnis Verzeichnis der Protokolle
In dieses Verzeichnis schreibt der JobScheduler seine Protokolle.
log_dir= *stderr lässt den JobScheduler die Protokollausgabe nach stderr (auf den Bildschirm) schreiben.
Die Option -log-dir hat Vorrang.
log_level = log_level Protokollausgaben beschränken
Die Option -log-level hat Vorrang.
August 2014
91
Die Einstellung factory.ini (Abschnitt [job], Eintrag log_level= info) hat Vorrang.
log_mail_bcc = email_address Bcc-Empfänger der eMails
Die Einstellung factory.ini (Abschnitt [job], Eintrag log_mail_bcc= …) hat Vorrang.
log_mail_cc = email_address Cc-Empfänger der eMails
Die Einstellung factory.ini (Abschnitt [job], Eintrag log_mail_cc= …) hat Vorrang.
log_mail_from = email_address Absender der eMails
Die Einstellung factory.ini (Abschnitt [job], Eintrag log_mail_from= …) hat Vorrang.
log_mail_subject = text Betreff der eMails
Die Einstellung factory.ini (Abschnitt [job], Eintrag log_mail_subject= …) hat Vorrang.
log_mail_to = email_address To-Empfänger der eMails
Die Einstellung factory.ini (Abschnitt [job], Eintrag log_mail_to= …) hat Vorrang.
mail_encoding =
mail_on_delay_after_error = Unterdrückung der eMail bei <delay_after_error>
Voraussetzung: mail_on_error=yes oder mail_on_warning=yes
Wenn ein Job wegen <delay_after_error> erneut startet, werden mit dieser Einstellungen die zahlreichen eMails
reduziert.
Die Einstellung wirkt nicht, wenn für den Job kein <delay_after_error> angegeben ist (dann gilt
mail_on_delay_after_error=all).
Die Einstellung factory.ini (Abschnitt [job], Eintrag mail_on_delay_after_error= first_and_last_only)
hat Vorrang.
mail_on_error = yes|no Mit Fehler beendete Task verschickt eMail
Die Einstellung factory.ini (Abschnitt [job], Eintrag mail_on_error= no) hat Vorrang.
mail_on_process = yes|no|zahl Task mit spooler_process() verschickt eMail
Veranlasst den Versand des Task-Protokolls, wenn die Task wenigstens die angegebene Anzahl Schritte, also
Aufrufe von spooler_process() , ausgeführt hat. Weil Nicht-API-Tasks keine Schritte haben, zählt der
JobScheduler für sie immer einen Schritt.
yes entspricht 1, no entspricht 0.
Die Einstellung factory.ini (Abschnitt [job], Eintrag mail_on_process= 0) hat Vorrang.
mail_on_success = yes|no Erfolgreich gelaufende Task verschickt eMail
Die Einstellung factory.ini (Abschnitt [job], Eintrag mail_on_success= no) hat Vorrang.
mail_on_warning = yes|no Wenn eine Warnung ausgegeben worden ist, wird am Task-Ende eine eMail
verschickt
August 2014
92
Damit im Fehlerfall eine Mail verschickt wird, ist mail_on_error=yes explizit zu setzen.
mail_queue_dir = verzeichnis Verzeichnis der zeitweilig nicht versendbaren eMails
abgelegt.
aufruft.
Die Einstellung factory.ini (Abschnitt [job], Eintrag mail_queue_dir= …) hat Vorrang.
Die Einstellung sos.ini (Abschnitt [mail], Eintrag queue_dir= …) wird damit überschrieben.
mail_queue_only = yes|no eMail nicht versenden, nur in die eMail-Warteschlange hängen
Wenn yes, dann werden eMails nicht versendet, sondern in die eMail-Warteschlange geschrieben, siehe sos.ini
(Abschnitt [mail], Eintrag queue_dir= …).
Der allgemeine Platz für diese Einstellung ist sos.ini (Abschnitt [mail], Eintrag queue_only= …).
Die Einstellung sos.ini (Abschnitt [mail], Eintrag queue_only= …) wird damit überschrieben.
max_db_errors = zahl Anzahl Datenbank-Fehler, bevor JobScheduler aufgibt
Der JobScheduler toleriert diese Anzahl Datenbankfehler. Wird sie überschritten, dann setzt er bei need_db=no
ohne Datenbank fort, anderfalls beendet er sich sofort.
Bei need_db= yes werden Fehler, die beim Versuch, die Datenbank zu öffnen, auftreten, nicht gezählt. Damit kann
er JobScheduler auf eine Datenbank warten, die noch nicht angelaufen ist.
need_db = yes|no|strict Ist die Datenbank notwendig?
need_db=no
Wenn die Einstellung db= fehlt, gibt der JobScheduler eine Warnung aus und arbeitet ohne Datenbank.
Wenn das Öffnen der Datenbank oder das automatische Anlegen der Tabellen fehlschlägt, gibt der
JobScheduler eine Warnung aus und arbeitet ohne Datenbank.
Bei einem Datenbankfehler während des Betriebs schließt der JobScheduler die Datenbank und öffnet sie
erneut. Wenn das fehlschlägt, arbeitet der JobScheduler ohne Datenbank weiter.
Im Cluster-Betrieb ( -exclusive oder -distributed-orders ) lehnt der JobScheduler need_db=no ab mit
der Meldung:
SCHEDUL This is a member
ER-358
of a cluster (option
-exclusive or
-distributed-orders)
, and therefore
needs a database.
need_db= is not
allowed
August 2014
93
need_db=yes
Wenn die Einstellung db= fehlt, startet der JobScheduler nicht und gibt die Meldung aus.
Bei einem Datenbankfehler schließt der JobScheduler die Datenbank und öffnet sie erneut. Wenn das
fehlschlägt, versucht der JobScheduler endlos im Abstand von einer Minute die Datenbank erneut zu öffnen.
Die Tasks werden währenddessen nicht bedient.
Wenn sich die Datenbank nicht erneut öffnen lässt, schickt er eine eMail (Seite 169).
need_db=strict
Wie need_db=yes mit folgender Ausnahme.
Bei einem Datenbankfehler während des Betriebs schließt der JobScheduler die Datenbank und öffnet sie
erneut. Bei einem erneuten Fehler wiederholt der JobScheduler den Versuch so oft, wie mit
max_db_errors= eingestellt. Wenn das fehlschlägt, beendet sich der Scheduler.
order_history = yes_no Aufträge in die Historie schreiben?
Für die Aufträge gibt es eine eigene Historie.
order_history_with_log = yes|no|gzip Auftragsprotokolle in die Historie schreiben?
Der JobScheduler kann das Auftragsprotokoll in die Datenbank schreiben, auch mit gzip komprimiert.
Siehe Kommando <show_order what="log"> (Seite 202).
param = text Zur freien Verwendung
Zur freien Verwendung. Der Parameter ist in den Skripten über spooler.param lesbar.
Die Option -param hat Vorrang.
Die Einstellung factory.ini (Abschnitt [job], Eintrag smtp= …) hat Vorrang.
Die Einstellung sos.ini (Abschnitt [mail], Eintrag smtp= …) wird damit überschrieben.
subprocess.own_process_group = yes|no Subprozesse in eigener Prozessgruppe starten
Voreinstellung für Subprocess.own_process_group
1.5 Datei sos.ini
In der Datei sos.ini wird der SOS-Lizenzschlüssel eingetragen.
Außerdem können hier allgemeine Einstellungen für Java oder Mail stehen. Einstellungen für Java sind auch in der
Datei factory.ini, Abschnitt [java] (Seite 87) möglich.
Beim Aufruf des Schedulers können Sie den Pfad dieser Datei mit der Option -sos.ini angeben, z.B.:
…scheduler installation path…\bin\scheduler.exe
-sos.ini=C:/Programme/scheduler/config/sos.ini
August 2014
94
Bei der Installation durch den Scheduler-Setup wird die Datei sos.ini im Verzeichnis
…scheduler installation path…\config
abgelegt. Aufrufe über das Startskript setzen den Pfad automatisch richtig.
Sollen Einstellungen aus sos.ini neben dem JobScheduler auch für andere SOS-Produkte gelten, kann diese
Ini-Datei zentral abgelegt werden.
Falls beim Scheduler-Aufruf der Pfad zur Datei sos.ini nicht angegeben wird, gelten folgende Vorgaben:
Unter Windows sollte die Datei dort angelegt werden, wo Windows seine .ini-Dateien erwartet. Das ist
normalerweise im Verzeichnis c:\windows. Sonst wird die Datei im Heimverzeichnis des Benutzers erwartet.
Einstellungen
Sektion: java
class_path =
debug = yes_no
debug=yes lässt die Aufruf an Java ins scheduler.log protokollieren Außerdem versetzt die Einstellung Java in
den Debug-Modus, wodurch z.B. bei einer Exception der Aufruf-Stack nach stdout (oder stderr) geschrieben wird.
javac = path Pfad zum Java-Compiler
Wenn zum Entwickeln von Java-Jobs der Quell-Code direkt in <script> notiert wird, übersetzt der JobScheduler
mit dem hier eingestellten Java-Compiler.
options = text
vm = path Dateipfad der Java virtual machine
Voreingestellt ist für HP-UX jvm.sl und für andere Unix-Varianten jvm.so.
Die Voreinstellung für Windows wird aus der Registrierung gelesen. Aus dem Schlüssel
HKEY_LOCAL_MACHINE\software\JavaSoft\Java Runtime Environment
wird der Eintrag CurrentVersion gelesen, der die aktuelle Versionsnummer enthält, z.B. "1.5". Anschließend wird
der Schlüssel der Version gelesen, z.B.
HKEY_LOCAL_MACHINE\software\JavaSoft\Java Runtime Environment\1.5
und dem dortigen Eintrag RuntimeLib der Pfad der jvm.dll entnommen.
Sektion: licence
key1 = licence_key Lizenzschlüssel
Wenn Sie mehrere Lizenzschlüssel haben, können Sie weitere unter key2=, key3= usw. eintragen. Achten Sie
darauf, dass die Nummerierung lückenlos ist.
Siehe auch <licence.use> (Seite 184).
Sektion: mail
queue_dir = verzeichnis Verzeichnis der zeitweilig nicht versendbaren eMails
August 2014
95
abgelegt.
aufruft.
Die Einstellung factory.ini (Abschnitt [job], Eintrag mail_queue_dir= …) hat Vorrang.
Die Einstellung factory.ini (Abschnitt [spooler], Eintrag mail_queue_dir= …) hat Vorrang.
queue_only = yes|no eMail nicht versenden, nur in die eMail-Warteschlange hängen
Wenn yes, dann werden eMails nicht versendet, sondern in die eMail-Warteschlange geschrieben, siehe sos.ini
(Abschnitt [mail], Eintrag queue_dir= …).
Der allgemeine Platz für diese Einstellung ist sos.ini (Abschnitt [mail], Eintrag queue_only= …).
Die Einstellung factory.ini (Abschnitt [spooler], Eintrag mail_queue_only= …) hat Vorrang.
Die Einstellung factory.ini (Abschnitt [job], Eintrag smtp= …) hat Vorrang.
Die Einstellung factory.ini (Abschnitt [spooler], Eintrag smtp= …) hat Vorrang.
1.6 Einstellungen, die den Abruf von Umgebungsvariablen mit ${…} erlauben
In manchen XML-Attributen und .ini-Dateieinträgen können Umgebungsvariablen mit der Syntax ${ name }
abgerufen werden. Die Kurzform $ name ist auch möglich, wenn auf dem Variablennamen ein Sonderzeichen
(außer dem Unterstrich _) folgt.
Das Zeichen »$« bleibt stehen, wenn kein »{« oder Buchstabe folgt. Ebenso, wenn ein »\« vorangestellt ist: »\$«
liefert »$«.
Es gelten die Werte der Umgebungsvariablen vom Start des Schedulers.
Variablen können auch programmiert ersetzt werden mit Variable_set.substitute() .
Beispiel:
# File factory.ini
[java]
class_path = ${SCHEDULER_HOME}/lib/sos.spooler.jar
class_path = $SCHEDULER_HOME/lib/sos.spooler.jar
class_path = \\otherhost\C$\lib\classes.jar
<params>
<param name="txt_file_regex" value="\.txt$"/>
</params>
August 2014
96
1.6.1
<base file="…">
Basiskonfiguration <config include_path="…">
Konfiguration, Verzeichnispfad für <include> <file_order_sink move_to="…">
Dateiauftragssenke <file_order_source directory="…">
Dateiauftragsquelle <http_directory path="…">
HTTP-Dateiverzeichnis, Pfad des Dateisystems <include file="…">
Fügt Text aus einer Datei ein, Pfad der einzufügenden
Datei <include live_file="…">
Fügt Text aus einer Datei ein, Pfad der einzufügenden
Datei aus dem Konfigurationsverzeichnis <param value="…">
Ein Parameter <process file="…">
Externes Programm (alternativ zu <script>), Pfad des
auszuführenden Programms <process param="…">
Externes Programm (alternativ zu <script>),
Parameterzeile <process log_file="…">
Externes Programm (alternativ zu <script>) <start_when_directory_changed directory="…">
Verzeichnis überwachen <variable value="…">
Eine Variable, Wert der Umgebungsvariablen <web_service url_path="…">
Web-Dienst, URL-Pfad, unter dem der Web-Dienst
ansprechbar ist <web_service request_xslt_stylesheet="…">
Web-Dienst, Transformiert die Anforderung in ein
Scheduler-Kommando <web_service response_xslt_stylesheet="…">
Web-Dienst, Transformiert die Antwort des Kommandos
in die Antwort des Web-Dienstes <web_service forward_xslt_stylesheet="…">
Web-Dienst, Zur Weiterleitung am Ende des Auftrags
bzw. der Task 1.6.2 factory.ini
[spooler] factory.ini (Abschnitt [spooler],
Eintrag html_dir= …)
Verzeichnis der HTML-Dateien [spooler] factory.ini (Abschnitt [spooler],
Eintrag include_path= …)
Verzeichnispfad für <include> [spooler] factory.ini (Abschnitt [spooler],
Eintrag log_dir= …)
Verzeichnis der Protokolle [spooler] factory.ini (Abschnitt [spooler],
Eintrag mail_queue_dir= …)
Verzeichnis der zeitweilig nicht versendbaren eMails [job] factory.ini (Abschnitt [job], Eintrag
mail_queue_dir= …)
Verzeichnis der zeitweilig nicht versendbaren eMails [java] factory.ini (Abschnitt [java], Eintrag
class_path= …)
Für Java Software- und Organisations-Service GmbH
August 2014
97
1.6.3 sos.ini
[mail] sos.ini (Abschnitt [mail], Eintrag
queue_dir= …)
Verzeichnis der zeitweilig nicht versendbaren eMails 1.7 Der Scheduler von der Kommandozeile
Der JobScheduler kann durch einen einfachen Aufruf gestartet werden:
C:\>…scheduler installation path…\bin\scheduler.exe …\my_scheduler_configuration.xml
…
user@host:~>…installation path…/bin/scheduler …/my_scheduler_configuration.xml …
Die Parameter (rechts vom Gleichheitszeichen) der hier beschriebenen Kommandozeilenoptionen können in
Anführungszeichen oder in Apostrophe gesetzt werden.
Das
Installationsprogramm erzeugt das Startskript .\bin\jobscheduler.cmd (Windows) bzw.
./bin/jobscheduler.sh (Unix), in dem Kommandozeilenoptionen und Umgebungsvariablen bereits gesetzt
werden. Das Startskript kann bei Bedarf angepasst werden.
Startskript und Umgebungsvariablen sind im Handbuch »Installation und Konfiguration« beschrieben.
Folgende Varianten des Aufrufs werden unterschieden:
•
Start des JobSchedulers
•
Installation eines Windows-Dienstes
•
Laufendem JobScheduler einen Job übergeben
•
Laufendem JobScheduler einen Auftrag übergeben
•
XML-Kommando an laufenden JobScheduler übergeben
•
Laufenden JobScheduler mit kill abbrechen
•
Java-Classpath expandieren
•
Versionsnummer zeigen
Start des JobSchedulers
scheduler
-backup
-backup-precedence=integer
-cd=verzeichnis
-cmd=xmlkommando
-config=dateiname
-distributed-orders
-env=name=value
-exclusive
-id=scheduler_id
-include-path=verzeichnis
-ini=dateiname
-ip-address=ip_number
Startet den JobScheduler im Backup-Betrieb
(Initialwert: 1) Vorrang unter den Backup JobSchedulern
Arbeitsverzeichnis
Sofort auszuführendes Kommando
Konfigurationsdatei
Verteilte Aufträge
Umgebungsvariable setzen
Startet den JobScheduler für die exklusive Ausführung
Kennung des JobSchedulers
Verzeichnispfad für <include>
Anderer Pfad/ Name für Datei factory.ini
(Initialwert: 0.0.0.0) IP-Adresse der Schnittstelle für TCP
und UDP
-java-classpath=dateinamen
Java-Classpath für den JobScheduler
-java-options=text
Java-Optionen für den JobScheduler
-job-java-classpath=dateinamen Java-Classpath für Jobs
-job-java-options=text
Java-Optionen für Jobs
August 2014
98
-log-dir=verzeichnis
-log-level=log_level
-log=dateiname
-param=text
-pid-file=dateiname
-port=number
-program-file=dateiname
-reuse-port
-service
-sos.ini=dateiname
-tcp-port=number
-time-zone=text
-udp-port=number
-use-xml-schema=dateiname
-validate-xml
Verzeichnis der Protokolle
(Initialwert: info) Protokollausgaben beschränken
Dateiname des Protokolls scheduler.log
Zur freien Verwendung
Dateiname für Prozess-ID
(Initialwert: 0) HTTP-, TCP- und UDP-Port für
Kommandos an den JobSchedulers
Dateiname des Schedulers
TCP- und UDP-Port wiederverwenden
Als Daemon starten
Anderer Pfad/ Name für Datei sos.ini
(Initialwert: 0) HTTP- und TCP-Port für Kommandos an
den JobScheduler
Zeitzone des JobSchedulers
(Initialwert: 0) UDP-Port für Kommandos an den
JobScheduler
Schema für die Validierung der JobScheduler Konfiguration
XML-Dokumente gegen eingebettetes Schema validieren
Der Programmdateiname scheduler muss absolut und vollständig angegeben werden. Für Windows muss die
Endung ".exe" angegeben werden, da der JobScheduler den vollständigen Dateinamen benötigt, um einen Job
oder sich selbst neu zu starten.
Beispiel:
c:\bin\scheduler.exe c:\scheduler\config.xml -log-dir=c:\scheduler\logs
Installation eines Windows-Dienstes
scheduler
-install-service=name
-remove-service=name
-service-name=name
-service-display=text
-service-descr=text
-need-service=name
Als Windows-Dienst installieren
Windows-Dienst entfernen
(Initialwert: sos_scheduler) Interner Name des
Windows-Dienstes
Angezeigter Name des Windows-Dienstes
Beschreibung des Windows-Dienstes
Vom JobScheduler vorausgesetzter Dienst
Laufendem JobScheduler einen Job übergeben
scheduler
-scheduler=host:port
-log=dateiname
-process-class=name
-language=script_language
-at=yyyy-mm-dd HH:MM
TCP-Adresse des Schedulers
Dateiname des Protokolls scheduler.log
(Initialwert: shell) Skriptsprache des Jobs
(Initialwert: now) Startzeitpunkt
Dem mit -scheduler =host:port adressierten JobScheduler wird ein temporärer Job übergeben.
Bei einem Neustart des JobSchedulers geht der Job verloren.
August 2014
99
Beispiel:
echo ls -l | scheduler -scheduler=localhost:4444 -at="2006-04-04 12:00"
Laufendem JobScheduler einen Auftrag übergeben
scheduler
-scheduler
-log
-job-chain=name
-order-id=id
-title=text
Job-Kette
Kennung des Auftrags
Titel des Auftrags
Dem mit -scheduler =host:port adressierten JobScheduler wird ein Auftrag übergeben.
Die Parameter des Auftrags (s. Order.payload ) können an der Kommandozeile in der Form name = value
übergeben werden.
Beispiel:
scheduler -scheduler=localhost:4444 -job-chain=my_job_chain -order-id=123 city=Berlin
phone="+4930 864790-0"
XML-Kommando an laufenden JobScheduler übergeben
scheduler
-tcp-port
-send-cmd=xmlkommando
Anderem JobScheduler zu schickendes Kommando
scheduler
-kill
-kill=pid
-pid-file=dateiname
Beispiel:
scheduler -kill -pid-file=/home/scheduler/scheduler.pid
scheduler
-expand-classpath
scheduler
-V
August 2014
100
-?
-h
Optionen zeigen
Optionen zeigen
Optionen
-backup Startet den JobScheduler im Backup-Betrieb
Nur mit -exclusive möglich.
Ein Backup JobScheduler übernimmt den Betrieb nur, beginnt aber keinen neuen Betrieb. D.h. nach <
terminate continue_exclusive_operation="no"> läuft er nicht an, sondern wartet auf einen anderen
JobScheduler, der den Betrieb startet.
Zusammem mit -install-service und -remove-service führt -backup zu einem eigenen Dienstenamen, so
dass der Backup JobScheduler als eigener Dienst auf demselben Rechner installiert werden kann.
Der Dateiname des Hauptprotokolls (Seite 168) erhält den Zusatz "_backup".
-backup-precedence=integer (Initialwert: 1) Vorrang unter den Backup JobSchedulern
Nur mit -exclusive möglich.
Wenn mehrere inaktive Backup JobScheduler einen ausgefallenen JobScheduler ersetzen können, übernimmt
der mit dem kleinsten Wert von -backup-precedence .
Wenn die Uhren nicht gleichlaufen, kann ein anderer JobScheduler als der mit dem vorderen Rang den
Betrieb übernehmen.
Mit der Option -backup ist die Voreinstellung 1, sonst 0.
-cd=verzeichnis Arbeitsverzeichnis
Ändert das Arbeitsverzeichnis.
-cmd=xmlkommando Sofort auszuführendes Kommando
Der JobScheduler führt beim Start das XML-Kommando aus. Das kann z.B. ein <start_job> sein.
-config=dateiname Konfigurationsdatei
Gibt die Konfigurationsdatei (Seite 7) an.
"-config=" vor dem Dateinamen kann weggelassen werden.
Die Option gibt die Konfigurationsdatei oder das Konfigurationsverzeichnis an. Im letzteren Fall erwartet der
JobScheduler die Konfigurationsdatei im Konfigurationsverzeichnis unter dem Namen scheduler.xml.
Die Einstellung factory.ini (Abschnitt [spooler], Eintrag config= …) wird damit überschrieben.
-distributed-orders Verteilte Aufträge
Voraussetzung ist Datenbankbetrieb (). Mehrere JobScheduler mit derselben Scheduler-Id ( -id ), derselben
Datenbank und derselben Konfiguration können gestartet werden, die sich die Ausführung der Aufträge teilen.
Mit <job_chain distributed="yes"> lassen sie eine Job-Kette für den verteilten Betrieb zu.
Meldungen
[ERROR]
SCHEDULER-357
This is a member of a cluster (option -exclusive or -distributed-orders), and
therefore needs a database August 2014
101
[ERROR]
SCHEDULER-358
therefore needs a database. need_db= is not allowed [ERROR]
SCHEDULER-361
No database [ERROR]
SCHEDULER-370
Operation can only be performed on a distributed orders Scheduler [ERROR]
SCHEDULER-373
UNEXPECTED DEACTIVATION BY JOBSCHEDULER MEMBER [ERROR]
SCHEDULER-375
Order is distributed and therefore does not support operation '' [ERROR]
SCHEDULER-378
After own late heart beat, this JobScheduler has been deactivated and the
occupied orders have been freed by JobScheduler member '' [ERROR]
SCHEDULER-379
order is occupied by JobScheduler member '' [ERROR]
SCHEDULER-380
job_chain orders_recoverable="no" cannot be combined with
distributed="yes", in [ERROR]
SCHEDULER-384
job_chain is distributed and therefore does not support operation '' [ERROR]
SCHEDULER-385
Deletion of order in database has failed [warn]
SCHEDULER-812
Just before processing, order record in database has been occupied or
removed [warn]
SCHEDULER-816
Unable to release occupation in database [warn]
SCHEDULER-817
Missing order record in database [warn]
SCHEDULER-879
Deactivating old cluster member with same ID [info]
SCHEDULER-813
Order is occupied by JobScheduler '' [info]
SCHEDULER-815
Task should end but it has just been started with an order attached, so one
step will be done [info]
SCHEDULER-829
Releasing occupied order job_chain:id [info]
SCHEDULER-830
Because all JobScheduler tasks have been killed, the order in database has
not been updated. Only the occupation has been released -env=name=value Umgebungsvariable setzen
-env=NAME=VALUE setzt die Umgebungsvariable NAME.
Meldungen
[ERROR]
SCHEDULER-318
Option -env=NAME=VALUE: missing '=' between name and value: -env="" -exclusive Startet den JobScheduler für die exklusive Ausführung
Voraussetzung ist Datenbankbetrieb, siehe factory.ini (Abschnitt [spooler], Eintrag db= …) (Seite 87).
Mehrere JobScheduler mit derselben Scheduler-Id ( -id ) und derselben Datenbank können mit -exclusive
gestartet werden, wobei nur einer aktiv wird. Erst wenn der aktive JobScheduler ausfällt oder einzeln beendet
wird ( <terminate continue_exclusive_operation="yes"> ), wird ein anderer JobScheduler aktiv. Die
Übernahme kann einige Minuten dauern.
Vorsicht: Alle beteiligten JobScheduler müssen mit -exclusive oder -distributed-orders gestartet werden.
Wenn ein JobScheduler mit und einer ohne die Einstellung gestartet wird, laufen zwei JobScheduler
gleichzeitig, was zu unerwarteten Ergebnissen führen kann.
Siehe auch -backup .
Meldungen
August 2014
102
[ERROR]
SCHEDULER-357
therefore needs a database [ERROR]
SCHEDULER-358
therefore needs a database. need_db= is not allowed [ERROR]
SCHEDULER-359
For an exclusive or distributed Scheduler, the database is not supported [ERROR]
SCHEDULER-362
Scheduler is aborting because it has become inactive [ERROR]
SCHEDULER-365
Illegal character in -id= [ERROR]
SCHEDULER-367
Scheduler is aborting because it has lost its exclusivity [ERROR]
SCHEDULER-371
DATABASE INTEGRITY IS BROKEN [ERROR]
SCHEDULER-372
Exclusivity has been stolen by JobScheduler member '' [ERROR]
SCHEDULER-377
After own late heart beat, JobScheduler member '' has taken exclusiveness [ERROR]
SCHEDULER-381
Scheduler is not yet active and cannot execute the operation [ERROR]
SCHEDULER-386
Last heart beat was time, seconds ago. Something is delaying JobScheduler
execution, the JobScheduler is aborted immediately [warn]
SCHEDULER-823
Dead JobScheduler member 'cluster_member_id' has resurrected [warn]
SCHEDULER-827
Own heart beat is late: next_heart_beat has been announced for (this is
seconds late) [warn]
SCHEDULER-836
Deactivating that dead Scheduler [warn]
SCHEDULER-837
Taking exclusiveness from that Scheduler [warn]
SCHEDULER-994
No heart beat for seconds (time), expecting heart beat within seconds [warn]
SCHEDULER-996
No heart beat for seconds (time) - JobScheduler seems to be dead [warn]
SCHEDULER-997
Making up an extra heart beat [info]
SCHEDULER-805
No JobScheduler is active [info]
SCHEDULER-807
Using database product [info]
SCHEDULER-811
Executing command read from database: [info]
SCHEDULER-814
Inactive JobScheduler '' has the higher backup precedence (http_url) [info]
SCHEDULER-819
Scheduler becomes active [info]
SCHEDULER-820
Watching heart beat of that Scheduler [info]
SCHEDULER-821
Scheduler member 'cluster_member_id' seems to be active, claiming its last
heart beat was s ago (pid=, url) [info]
SCHEDULER-822
Scheduler member 'cluster_member_id' seems to be exclusive, claiming its
last heart beat was s ago (pid=, url) [info]
SCHEDULER-825
No exclusive JobScheduler is running [info]
SCHEDULER-826
That JobScheduler has terminated [info]
SCHEDULER-831
Waiting s for start of non-backup Scheduler [info]
SCHEDULER-832
This is a backup Scheduler, waiting for a non-backup Scheduler [info]
SCHEDULER-833
Watching heart beat of that exclusive Scheduler, standing by to take over
operation [info]
SCHEDULER-834
Active JobScheduler has terminated properly [info]
SCHEDULER-835
This JobScheduler is becoming exclusive now Software- und Organisations-Service GmbH
August 2014
103
[info]
SCHEDULER-838
. heart beat detected [info]
SCHEDULER-995
No heart beat for seconds (time), ignored for seconds because of recent
database reconnect -id=scheduler_id Kennung des JobSchedulers
Der JobScheduler wählt nur die Elemente der XML-Konfiguration aus, deren Attribut spooler_id leer ist oder
denselben Wert wie in dieser Einstellung enthält.
Wenn die Scheduler-ID nicht angegeben ist, beachtet der JobScheduler das XML-Attribut spooler_id= nicht
und wählt alle Elemente der XML-Konfiguration aus.
Siehe z.B. <config> (Seite 20).
Die Einstellung factory.ini (Abschnitt [spooler], Eintrag id= …) wird damit überschrieben.
-include-path=verzeichnis Verzeichnispfad für <include>
Die Einstellung factory.ini (Abschnitt [spooler], Eintrag include_path= …) wird damit überschrieben.
<config include_path="…"> wird damit überschrieben.
-ini=dateiname Anderer Pfad/ Name für Datei factory.ini
Wählt eine andere Datei für die Datei factory.ini (Seite 84) aus.
In dieser Dokumentation ist dann mit der Datei factory.ini die hier eingestellte gemeint.
Siehe auch Spooler.ini_path
-ip-address=ip_number (Initialwert: 0.0.0.0) IP-Adresse der Schnittstelle für TCP und UDP
Die IP-Adresse, an die TCP- und UDP-Port gebunden werden. Der JobScheduler ist dann nur über diese
IP-Adresse erreichbar.
Ein Hostname kann angegeben werden.
Default ist 0.0.0.0, was für alle IP-Adressen steht.
Wenn eine andere IP-Adresse als 127.0.0.1 oder localhost angegeben ist, kann der JobScheduler nicht über
localhost erreicht werden.
<config ip_address="…"> wird damit überschrieben.
-java-classpath=dateinamen Java-Classpath für den JobScheduler
Für Java kann hier der CLASS_PATH eingestellt werden. Das ist eine Liste von Pfaden, in Windows durch
Semikolons (;), in Unix durch Doppelpunkte getrennt.
In den einzelnen Pfaden können Joker benutzt werden. Der JobScheduler ersetzt diese Pfade durch die
tatsächlichen, im Dateisystem vorhandenen.
•
•
•
Unter Windows sind hinter dem letzten Verzeichnisstrich die Zeichen * und ? möglich.
Unter Unix außerdem die Zeichen [ und ]; die Joker können auch in jedem Verzeichnis des Pfads
auftreten (wie in der Shell csh).
Linux (Gnu) kennt außerdem die Zeichen {,} in der Syntax "xxx { alternative1 , alternative2 ,...} xxx",
z.B. /dir/sos.{hostware,mail.spooler}.jar.
August 2014
104
Dabei gilt für jeden Pfad in class_path:
•
•
•
•
•
Ein Pfad ohne Joker wird unverändert an Java übergeben.
Ein Pfad mit Joker wird in die tatsächlichen, im Dateisystem vorhandenen Pfade aufgelöst.
Wenn auf den Pfad mit Joker kein tatsächlicher Pfad passt, wird er ignoriert.
Wenn ein Pfad mit ein nicht lesbares Verzeichnis bezeichnet, wird es ignoriert.
Umgebungsvariablen (z.B. ${HOME}) werden vorher ersetzt.
Der allgemeine Platz für diese Einstellung ist sos.ini (Abschnitt [java], Eintrag class_path= …).
Beispiel:
scheduler -java-classpath = s:\prod\bind\sos.*.jar;c:\jar\my.jar;c:\jar\*
-java-options=text Java-Optionen für den JobScheduler
Hier können Sie z.B. mit -Djava.library.path= das Verzeichnis angeben, in dem HostJava installiert ist.
Die Optionen werden der Java Virtual Machine übergeben.
Der allgemeine Platz für diese Einstellung ist sos.ini (Abschnitt [java], Eintrag options= …).
Beispiel:
options = -Xdebug -Djava.library.path=s:/prod/bind
-job-java-classpath=dateinamen Java-Classpath für Jobs
Siehe -java-classpath
-job-java-options=text Java-Optionen für Jobs
Siehe -java-options
Siehe auch <job java-options="…"> (Seite 37).
-log-dir=verzeichnis Verzeichnis der Protokolle
In dieses Verzeichnis schreibt der JobScheduler seine Protokolle.
log_dir= *stderr lässt den JobScheduler die Protokollausgabe nach stderr (auf den Bildschirm) schreiben.
Die Einstellung factory.ini (Abschnitt [spooler], Eintrag log_dir= …) wird damit überschrieben.
-log-level=log_level (Initialwert: info) Protokollausgaben beschränken
Die Einstellung factory.ini (Abschnitt [job], Eintrag log_level= info) wird damit überschrieben.
August 2014
105
Die Einstellung factory.ini (Abschnitt [spooler], Eintrag log_level= info) wird damit überschrieben.
-log=dateiname Dateiname des Protokolls scheduler.log
Wenn diese Einstellung gesetzt ist, schreibt der JobScheduler ein detailliertes Protokoll zur Fehlerdiagnose in
die Datei. Geben Sie den Dateinamen absolut an (als vollständigen Pfad).
Ein Plus (+) direkt vor dem Dateinamen lässt ein vorhandenenes Protokoll fortsetzen. Sonst wird es
überschrieben.
Sie können das Protokoll mit Kategorien erweitern oder einschränken. Schreiben Sie die Namen der
Kategorien mit Zwischenräumen getrennt vor den Dateinamen, den Sie mit einem Größerzeichen (>) einleiten.
Beispiel:
Die Einstellung factory.ini (Abschnitt [spooler], Eintrag log= …) wird damit überschrieben.
-param=text Zur freien Verwendung
Zur freien Verwendung. Der Parameter ist in den Skripten über spooler.param lesbar.
Die Einstellung factory.ini (Abschnitt [spooler], Eintrag param= …) wird damit überschrieben.
-pid-file=dateiname Dateiname für Prozess-ID
Für Unix: In diese Datei schreibt der JobScheduler seine PID. Beim Beenden löscht der JobScheduler die
Datei.
-port=number (Initialwert: 0) HTTP-, TCP- und UDP-Port für Kommandos an den JobSchedulers
Fasst die Einstellungen tcp_port und udp_port zusammen.
Siehe auch -tcp-port und -udp-port .
Wenn der Port blockiert ist, versucht der JobScheduler zwei Minuten lang, ihn zu belegen, bevor er aufgibt.
<config port="…"> wird damit überschrieben.
-program-file=dateiname Dateiname des Schedulers
Beim Aufruf des JobSchedulers aus einer Java-Klasse heraus (zum Debuggen) geben Sie hier den
Programmdateinamen an, wenn der JobScheduler Jobs in eigenen Prozessen starten können soll.
-reuse-port TCP- und UDP-Port wiederverwenden
Die Option soll nur in Ausnahmefällen benutzt werden, sie schaltet die Prüfung ab, ob ein Port vom
Betriebssystem freigegeben ist.
Ruft setsockopt(socket,SOL_SOCKET,SO_REUSEADDR,true).
Die Option sollte nur im Notfall benutzt werden, falls das Betriebssystem den Port dauerhaft sperrt, obwohl
keine Anwendung ihn mehr belegt. Das kann unter Windows XP passieren, wenn die Anwendung mit einem
Debugger abgebrochen wird. Unix kann ggf. fast eine Minute benötigen, um einen Port freizugeben.
August 2014
106
U.U. ist der JobScheduler mit -reuse-port über TCP oder UDP nicht erreichbar, wenn statt dessen der Port
einer anderen Anwendung angesprochen wird.
-service Als Daemon starten
Unter Unix versetzt sich der JobScheduler in den Hintergrund und trennt sich vom Terminal.
Unter Unix schließt der JobScheduler stdin, stdout und stderr und leitet die Ausgaben in die Datei
scheduler.out, die beschreibbar sein muss.
-sos.ini=dateiname Anderer Pfad/ Name für Datei sos.ini
Wählt eine andere Datei für globale Konfigurationen sos.ini (Seite 93) aus. Diese Datei enthält u.a. den
Lizenzschlüssel.
-tcp-port=number (Initialwert: 0) HTTP- und TCP-Port für Kommandos an den JobScheduler
Der JobScheduler kann auf einem TCP-Port während des Betriebs Kommandos entgegennehmen. Hier kann
eine Portnummer eingestellt werden. Die Portnummer ist eine Zahl zwischen 2048 (betriebssystemabhängig)
und 65535. Die Voreinstellung lautet 4444.
Über denselben Port betreibt der JobScheduler einen HTTP/HTML-Server, so dass er über einen Browser
ansprechbar ist, z.B. http://localhost:4444.
Bei tcp_port=0 (voreingestellt) ist der JobScheduler nicht über TCP oder HTTP ansprechbar. Damit kann die
Steuerung des JobSchedulers per TCP-Kommando, z.B. über eine Web-Seite, unterbunden werden.
Siehe auch -port .
<config tcp_port="…"> wird damit überschrieben.
-time-zone=text Zeitzone des JobSchedulers
Bestimmt nach welcher Zeitzone ein Auftrag bzw. Job startet. Die Angabe einer Zeitzone folgt dabei der tz
Datenbank. Eine Liste möglicher Zeitzonen befindet sich in der Dokumentation der Joda API, welche für die
Zeitfunktionen verwendet wird.
Fehlt die Angabe einer Zeitzone, arbeitet der JobScheduler mit der locale Einstellung des Rechners.
Beispiel:
<config time_zone="Europe/Berlin">
<config time_zone="…"> wird damit überschrieben.
-udp-port=number (Initialwert: 0) UDP-Port für Kommandos an den JobScheduler
Auch über UDP kann der JobScheduler Kommandos entgegennehmen. Hier wird die Portnummer angegeben.
Ein Kommando muss in eine Nachricht passen. Der JobScheduler schickt keine Antwort.
Bei udp_port=0 (voreingestellt) öffnet der JobScheduler keinen UDP-Port.
Siehe auch -port .
<config udp_port="…"> wird damit überschrieben.
-use-xml-schema=dateiname Schema für die Validierung der JobScheduler Konfiguration
Mit dieser Option kann das durch den JobScheduler verwendete Schema überschrieben werden.
-validate-xml XML-Dokumente gegen eingebettetes Schema validieren
August 2014
107
-validate-xml- schaltet die Validierung ab (für den Fall, dass das Schema fehlerhaft ist).
-install-service=name Als Windows-Dienst installieren
Die Option startet nicht den JobScheduler, sondern installiert ihn als Windows-Dienst. Dabei werden folgende
Optionen aus der Kommandozeile übernommen:
-cd
-config
-id
-ini
-log
-pid-file
-sos.ini
-env
-install-service= name ist dasselbe wie -install-service -service-name= name.
-remove-service=name Windows-Dienst entfernen
Entfernt einen zuvor mit -install-service installierten Dienst.
-remove-service= name ist dasselbe wie -remove-service -service-name= name.
-service-name=name (Initialwert: sos_scheduler) Interner Name des Windows-Dienstes
Nur in Verbindung mit -install-service oder -remove-service. Wenn diese Option fehlt und -id=
angegeben ist, verwendet der JobScheduler den Namen sos_scheduler_ scheduler_id. Bei -backup fügt er
_backup hinzu.
-service-display=text Angezeigter Name des Windows-Dienstes
Nur in Verbindung mit -install-service. Die Dienstesteuerung von Windows zeigt diesen Namen. Er darf
Leerzeichen enthalten. Wenn die Option fehlt, erzeugt der JobScheduler einen aus dem Dienstnamen (s.
-service-name=).
-service-descr=text Beschreibung des Windows-Dienstes
Nur in Verbindung mit -install-service.
-need-service=name Vom JobScheduler vorausgesetzter Dienst
In Verbindung mit -install-service können Sie hier einen anderen Dienst angegeben, der laufen soll, bevor
Windows den JobScheduler Dienst startet. Das kann z.B. ein Datenbank-Server sein.
Diese Option kann wiederholt angegeben werden, wenn der JobScheduler mehrere Dienste voraussetzt.
-scheduler=host:port TCP-Adresse des Schedulers
Rechnername (oder IP-Nummer) und Portnummer des anzusprechenden JobSchedulers.
-log=dateiname Dateiname des Protokolls scheduler.log
Wenn diese Einstellung gesetzt ist, schreibt der JobScheduler ein detailliertes Protokoll zur Fehlerdiagnose in
die Datei. Geben Sie den Dateinamen absolut an (als vollständigen Pfad).
August 2014
108
Ein Plus (+) direkt vor dem Dateinamen lässt ein vorhandenenes Protokoll fortsetzen. Sonst wird es
überschrieben.
Sie können das Protokoll mit Kategorien erweitern oder einschränken. Schreiben Sie die Namen der
Kategorien mit Zwischenräumen getrennt vor den Dateinamen, den Sie mit einem Größerzeichen (>) einleiten.
Beispiel:
Die Einstellung factory.ini (Abschnitt [spooler], Eintrag log= …) wird damit überschrieben.
-process-class=name
Name der Prozessklasse für den temporären Job, siehe <job process_class="…"> (Seite 37).
-language=script_language (Initialwert: shell) Skriptsprache des Jobs
Skriptsprache, siehe <script language="…"> (Seite 66).
-at=yyyy-mm-dd HH:MM (Initialwert: now) Startzeitpunkt
Startzeitpunkt in der Form "yyyy-mm-dd HH:MM[:SS]". Siehe <at at="…"> (Seite 16).
Der Job wird nicht gestartet, wenn der Startzeitpunkt in der Vergangenheit liegt.
Maßgeblich ist die Uhr des Rechners, auf dem der JobScheduler läuft.
-at=now ist voreingestellt und lässt den Job sofort starten.
-scheduler
-log
-job-chain=name Job-Kette
Name der Job-Kette für den Auftrag, siehe <add_order job_chain="…"> (Seite 14).
-order-id=id Kennung des Auftrags
Kennung des Auftrags, siehe <add_order id="…"> (Seite 14).
-title=text Titel des Auftrags
Dem Auftrag kann ein Titel gegeben werden. Siehe <add_order title="…"> (Seite 14).
-tcp-port
-send-cmd=xmlkommando Anderem JobScheduler zu schickendes Kommando
Mit dieser Option startet der JobScheduler nicht, sondern schickt einem anderen JobScheduler mit gleicher
Option -tcp-port= auf demselben Rechner das XML-Kommando. Das kann z.B. ein <terminate> sein:
-send-cmd="<terminate/>"
Das Kommando wird an die mit <config ip_address="…"> eingestellte IP-Adresse geschickt, oder, wenn
diese fehlt, an 127.0.0.1.
-kill Laufenden JobScheduler mit kill abbrechen
August 2014
109
Bricht den JobScheduler mit kill -SIGKILL ab, dessen Prozess-Id in der mit -pid-file angegebenen Datei
steht.
-kill=pid Laufenden JobScheduler mit kill abbrechen
Bricht den Prozess mit der PID mit kill -SIGKILL ab.
-pid-file=dateiname
-expand-classpath Java-Classpath expandieren
Expandiert den als Parameter angegebenen Java-Classpath, d.h. die Joker werden verarbeitet wie sos.ini
(Abschnitt [java], Eintrag class_path= …).
Das Ergebnis schreibt der JobScheduler nach stdout. Wenn keine weiteren Optionen es verlangen, beendet
sich der JobScheduler ohne weitere Ausgaben.
Beispiel:
export CLASSPATH="`scheduler -expand-classpath='/opt/java/lib/*.jar'`"
-V Versionsnummer zeigen
Lässt den JobScheduler beim Start Versionsnummer und Versionsdatum ausgeben.
-? Optionen zeigen
Zeigt die Kommandozeilenoptionen.
-h Optionen zeigen
Zeigt die Kommandozeilenoptionen.
1.8 JobScheduler Editor
1.8.1 GUI für Konfiguration und Dokumentation
Der JobScheduler liest seine Konfiguration aus XML-Dateien, die mit einem Text-Editor erstellt und bearbeitet
werden können.
Alternativ kann die XML-Konfiguration mit dem JobScheduler Editor gepflegt werden. Der Editor stellt eine
grafische Benutzeroberfläche mit Formularen für alle Elemente der Scheduler-Konfiguration zur Verfügung.
Anwender werden durch Tooltips und Wizards unterstützt.
Der JobScheduler Editor erzeugt für jeden Eintrag in eines seiner Formulare das entsprechende XML-Element der
Scheduler-Konfiguration. Beim Speichern wird jeweils die Konfigurationsdatei des Schedulers, in der Regel die
Datei scheduler.xml, neu geschrieben. Der Editor validiert alle Einträge mit dem aktuellen Schema des Schedulers
- Fehler in der XML-Konfiguration werden sofort bemerkt.
Scheduler Jobs können mit dem Editor dokumentiert werden - der Editor generiert die Dokumentation in einem
XML-Format, das über ein entsprechendes Stylesheet als HTML mit Navigationselementen im Browser dargestellt
werden kann.
August 2014
110
1.8.1.1 Aufruf JobScheduler Editor
Der JobScheduler Editor gehört zur Standard-Auslieferung des JobSchedulers. Das Installationsverzeichnis des
Schedulers enthält die Datei bin/jobeditor.cmd zum Aufruf des Editors. In dieser Datei ist für INSTALL_PATH das
Scheduler-Installationsverzeichnis einzutragen.
1.8.1.2 Scheduler Konfiguration erstellen
Um eine neue Konfiguration zu erstellen, wählen Sie den Menüpunkt File/New/Configuration:
Der Editor öffnet sein Hauptfenster mit einer Baumansicht für einzelne Elemente, z.B. Config, Jobs, Job Chains
etc.
August 2014
111
Für alle Formularfelder und Steuerelemente sind Tooltips verfügbar. Mit der Taste F1 wird als Hilfe die
XML-Dokumentation des Schedulers angezeigt, die Hilfe ist auf den Kontext bezogen und steuert das
XML-Element an, das gerade im Formular bearbeitet wird.
Ein Beispiel:
Das Formular zur Konfiguration eines Jobs ist geöffnet:
August 2014
112
Mit F1 erreichen Sie die Dokumentation des XML-Elements <job>:
August 2014
113
1.8.1.3 Vorhandene Konfigurationsdatei öffnen
Existierende Konfigurationsdateien öffnen Sie mit dem Menüpunkt File/Open:
Beispiel - Öffnen der Datei scheduler.xml aus der Auslieferung, Ansicht der Base-File Konfiguration:
August 2014
114
1.8.1.4 Empfohlene Vorgehensweise
•
•
•
•
•
Öffnen Sie die Konfigurationsdatei scheduler.xml der Auslieferung.
Tragen Sie im Formular Security die Rechner bzw. Netzwerke ein, die per TCP und UDP Kommandos
ausführen dürfen.
Tragen Sie im Formular Jobs die Jobs mit den Job-Parametern ein, die der JobScheduler ausführen soll. Der
Editor erstellt für jeden Job einen Zweig in der Baumansicht aller Jobs. Jeder Job hat zusätzliche Formulare,
in die weitere Eigenschaften, z.B. der auszuführende Programm-Code, die Startzeiten etc. einzutragen sind.
Sie können zum Erstellen eines Jobs auf Basis eines Standard-Jobs auch den Job Wizard verwenden.
Hinweis: wenn Jobs in XML-Dateien definiert werden sollen, die mit <base> inkludiert werden, ist die
inkludierte XML-Datei mit den Job-Definitionen im Editor zu öffnen.
Wenn Jobs innerhalb einer Job-Kette ausgeführt werden sollen, tragen Sie die Job-Kette im Formular Job
Chains ein. Für jede Job-Kette sind die einzelnen Job-Ketten-Knoten zu definieren. Jedem Job-Ketten-Knoten
ist ein Job zuzuordnen.
Hinweis: wenn Job-Ketten in XML-Dateien definiert werden sollen, die mit <base> inkludiert werden, ist die
inkludierte XML-Datei mit den Job-Ketten Definitionen zu öffnen.
Wenn Sie auftragsgesteuerte Jobs in Job-Ketten verwenden, muss festgelegt werden, wie die Aufträge
entstehen:
Aufträge können durch Verzeichnisüberwachung erzeugt werden - definieren Sie hierfür Dateiaufträge im
Formualar Job Chains.
Sie können Aufträge direkt mit einem <add_order>-Kommando erstellen - definieren Sie solche Aufträge im
Formular Orders. Der Editor generiert aus diesem Eintrag ein <add_order>-Element, das Sie sich über das
Formular Commands anzeigen lassen können.
1.8.1.5 Job Wizard
Mit dem Job Wizard kann ein neuer Job auf Basis eines bereits dokumentierten Standards-Jobs erstellt werden.
August 2014
115
Vorhandene Job-Dokumentationen liegen als XML-Dateien im Unterverzeichnis /jobs des
Scheduler-Installationsverzeichnisses. Mit der Scheduler-Auslieferung steht bereits eine Reihe von dokumentierten
Standard-Jobs zur Verfügung.
Der Job Wizard liest das /jobs-Verzeichnis und bietet alle Jobs zum Import an. Ein importierter Job hat die gleichen
Eigenschaften wie das Vorbild, insbesondere die Sprache der Implementierung. Job-Parameter werden ebenfalls
übernommen, können aber editiert werden. Weitere Eigenschaften wie die Anzahl der Tasks, Startzeiten,
Timeout-Einstellungen etc. können Schritt für Schritt erfolgen. Dabei unterstützt der Wizard die Eingaben durch
erläuternden Text.
Um den Assistenten zu starten, wählen Sie Job Wizard im Formular Jobs:
Der Wizard erstellt einen neuen Job in folgenden Schritten:
1.8.1.6 Scheduler Job Dokumentation erstellen
Für jeden Scheduler-Job kann eine Dokumentation in einem festgelegten XML-Format erstellt werden.
Die Dokumentation wird in der Regel vom Entwickler eines Jobs erstellt und dient dem Anwender/ Deployer, die
Job-Konfiguration für konkrete Job-Implementierungen vorzunehmen.
Mit dem Editor können Sie die XML-Datei zur Job-Dokumentation formularbasiert erstellen, ohne das XML-Format
zu kennen. Mit Hilfe eines Stylesheets scheduler_job_documentation.xsl kann die Dokumentation für den
Anwender im Browser als HTML-Seite angezeigt werden.
Ein dokumentierter Job wird im /jobs-Verzeichnis des Schedulers gespeichert und ist damit als Vorbild für neue
Jobs mit Hilfe des Job Wizards verfügbar.
Wählen Sie den Menüpunkt File/New/Documentation:
August 2014
116
Zu jedem Formular ist eine kontextbezogene Hilfe mit F1 erreichbar:
1.8.1.7 Hot Folder editieren
Der JobScheduler Editor kann einen ganzen hot folder öffnen und bearbeiten. Dazu wird im File Menü mit dem
Befehl Open Hot Folder der live folder oder einer seiner Unterordner geöffnet.
Links in der Baumansicht werden nun alle Objekte angezeigt, die in diesem Hot Folder definiert sind:
August 2014
117
Um ein neues Objekt (z.B. einen Job) anzulegen, wählen Sie im linken Baum den Elternknoten aus(1), drücken Sie
den "new" Knopf(2), wählen das neu enstandene Objekt(3) und geben diesem einen Namen(4):
August 2014
118
August 2014
119
Wenn Sie nun Save aus dem File Menü wählen, speichert der JobScheduler Editor alle in diesem Verzeichnis
geänderten oder hinzugefügten Objekte. Dateinamen müssen dabei nicht angegeben werden. Diese erzeugt der
JobScheduler Editor aus den Objektnamen selbstständig.
1.8.1.8 Remote Connection
1.8.1.8.1 FTP/SFTP
Der JobScheduler kann eine XML-Konfigurationsdateien per FTP (File Transfer Protocol) bzw. SFTP (Secure FTP)
öffnen bzw.eine offene Datei per FTP/SFTP speichern. Sie können über den Menüpunkt File -> FTP oder über den
Toolbar den FTP Dialog öffnen:
August 2014
120
Es erscheint ein Dialog, indem Sie die zu öffnenden Profile (FTP-Verbindung) und anschließend die zu öffnenden
Dateien auswählen können.
August 2014
121
1.8.1.8.1.1 Die Bedienelemente
1.8.1.8.1.1.1 FTP Zugang auswählen
In diesem Auswahllisten können Sie einen bereits konfigurierten FTP Zugang auswählen
1.8.1.8.1.2 Verzeichniswechsel
Hier steht als erstes das konfigurierte Verzeichnis auf dem FTP Server. Sobald Sie sich mit dem FTP Server
verbinden, wird zum Verzeichnis auf dem FTP Server gesprungen. Wenn Sie in der Dateiliste navigieren, dann
steht in diesem Textfeld das aktuelle Verzeichnis am FTP Server, in dem Sie sich befinden. Sie haben die
Möglichkeit jederzeit ein neues Verzeichnis anzugeben, indem Sie im Textfeld einen neuen Verzeichnisnamen
angeben und auf den Button "Change Directory" klicken.
1.8.1.8.1.3 Refresh
Aktualistert alle Verzeichnis- und Dateiinformationen vom FTP Server
August 2014
122
1.8.1.8.1.4 New Folder
Legt ein neues Verzeichnis auf dem FTP Server an.
1.8.1.8.1.5 Remove
Eine ausgewählte Datei bzw. ein Verzeichnis in der Dateiliste wird auf dem FTP Server gelöscht.
1.8.1.8.1.6 Open
Wurde der FTP Dialog unter der Menüpunkt "Open by FTP" ausgewählt, dann wird beim Betätigen des Buttons
"Open" die XML-Datei vom FTP Server heruntergeladen und im Editor geöffnet.
Wurde der FTP Dialog unter der Menüpunkt "Open Hot Folder by FTP" ausgewählt, dann sind nur Verzeichnisse
zu sehen. Dateien werden nicht in der Dateiliste angezeigt. Beim Auswählen eines Verzeichnisses werden vom
FTP Server alle Dateien dieses Hot Folders heruntergeladen und im Editor geöffnet.
1.8.1.8.1.7 Close
Schliesst den FTP Dialog
1.8.1.8.1.8 Log
Zeigt den Protokolldialog. Hier können Sie alle Befehle, die an den FTP Server geschickt wurden, und die
Antworten vom FTP Server sehen.
1.8.1.8.1.9 Profiles
Hier sehen Sie alle konfigurierten FTP Zugänge. Sie haben die Möglichkeit neue FTP Zugänge anzulegen bzw.
vorhandene FTP Zugänge zu editieren oder zu löschen.
August 2014
123
August 2014
124
August 2014
125
Alle FTP Zugänge werden in einer Konfigurationsdatei gespeichert. Die Konfigurationsdatei liegt unter
scheduler_install_directory/config/factory.ini und hat folgende Sektion und Einträge:
[profile profilename]
host=
port=
user=
root=
localdirectory=
transfermode=
save_password=
protocol=SFTP
use_proxy=
proxy_server=
proxy_port=
August 2014
126
auth_method=
auth_file=
1.8.1.8.2 WebDAV
Der JobScheduler kann eine XML-Konfigurationsdateien per WebDAV öffnen bzw. eine offene Datei per WebDAV
speichern. Sie können über den Menüpunkt File -> WebDAV den WebDAV Dialog öffnen:
Der Menüpunkt WebDAV ist nur aktiv, wenn die notwendigen Bibliotheken für die WebDAV-Verbindungen
vorhanden sind. Diese Bibliotheken sind aus Lizenzgründen nicht Teil der JobScheduler Distribution. Sie können
z.B. vom Sourceforge Projekt webdavclient4j unter https://sourceforge.net/projects/webdavclient4j/
heruntergeladen werden.
Es müssen folgende Bibliotheken im Verzeichnis scheduler_installation_directory/lib vorhanden sein,
dabei können ggf. anderen Bibliotheksnamen oder Versionsnummern zum Einsatz kommen.
•
•
•
•
Der
commons-logging.jar
webdavclient4j-core-0.92.jar
commons-codec-1.3.jar
commons-httpclient-3.0.1.jar
JobScheduler
Editor
wird
über
eine
Kommandodatei
aufgerufen,
die
sich
unter
scheduler_installation_directory/bin befindet. Hier muss der CLASSPATH um die oben genannten
Bibliotheken erweitert werden.
Es erscheint ein Dialog, indem Sie das zu öffnenden Profil (WebDAV-Verbindung) und anschließend die zu
öffnenden Dateien auswählen können.
August 2014
127
1.8.1.8.2.1 Die Bedienelemente
1.8.1.8.2.1.1 WebDAV Zugang auswählen
In diesen Auswahllisten können Sie einen bereits konfigurierten WebDAV Zugang auswählen
1.8.1.8.2.2 URL Wechsel
Hier steht als erstes die konfigurierte URL auf dem WebDAV Server. Sobald Sie mit dem WebDAV Server
verbunden sind, werden alle Dateien und Verzeichnisse dieser URL angezeigt. Wenn Sie im Dateiliste navigieren
steht dann in diesem Textfeld der aktuelle URL auf der WebDAV Server. Sie haben aber auch die Möglichkeit
jederzeit eine neue URL anzugeben, in dem Sie im Textfeld eine neue URL angeben und auf den Button "Change
Directory" klicken.
1.8.1.8.2.3 Refresh
Aktualistert alle Verzeichnis- und Dateinformationen vom WebDAV Server
August 2014
128
1.8.1.8.2.4 New Folder
Legt einen neuen Verzeichnis auf dem WebDAV Server an.
1.8.1.8.2.5 Remove
Eine ausgewählte Datei bzw. ein Verzeichnis in der Dateiliste wird auf dem WebDAV Server gelöscht.
1.8.1.8.2.6 Open
Wurde der WebDAV Dialog unter dem Menüpunkt "Open by WebDAV" ausgewählt, dann wird beim Betätigen des
Button "Open" die XML-Datei vom WebDAV Server heruntergeladen und im Editor geöffnet.
Wurde der WebDAV Dialog unter dem Menüpunkt "Open Hot Folder by WebDAV" ausgewählt, dann sind nur
Verzeichnisse zu sehen. Dateien werden nicht in der Dateiliste angezeigt. Beim Auswählen eines Verzeichnisses
werden vom WebDAV Server alle Dateien des Hot Folders heruntergeladen und im Editor geöffnet.
1.8.1.8.2.7 Close
Schließt den WebDAV Dialog
1.8.1.8.2.8 Log
Zeigt den Protokolldialog. Hier können Sie alle Befehle, die an den WebDAV Server geschickt wurden, und die
Antworten vom WebDAV Server sehen.
1.8.1.8.2.9 Profiles
Hier sehen Sie alle konfigurierte WebDAV Zugänge. Sie haben die Möglichkeit neue WebDAV Zugänge anzulegen
bzw. vorhandene WebDAV Zugänge zu editieren oder zu löschen.
August 2014
129
Alle WebDAV Zugänge werden in einer Konfigurationsdatei gespeichert. Die Konfigurationsdatei liegt unter
scheduler_installation_directory/config/factory.ini und hat folgende Sektion und Einträge:
[webdav_profile profilename]
url =
user =
August 2014
130
password =
localdirectory=
save_password=
use_proxy=
proxy_server=
proxy_port=
debug=
1.9 Datenbank
Der JobScheduler kann mit und ohne Datenbank betrieben werden. Der Betrieb mit Datenbank hat folgende
Vorteile:
Task-Warteschlange
Der JobScheduler speichert die in den Warteschlangen eingereihten Tasks in einer Tabelle unter seiner
Scheduler-ID (Option -id ). Sobald der JobScheduler erneut startet, liest er die Warteschlange aus der
Datenbank.
Aufträge
Der JobScheduler speichert jeden Auftrag in einer Tabelle unter seiner Scheduler-ID (Option -id ). Sobald
der JobScheduler erneut startet, liest er die Aufträge aus der Datenbank.
Task-Historie
Für jede Task schreibt der JobScheduler einen Satz, außerdem bei Start und Ende des JobSchedulers.
Auftragshistorie
Der JobScheduler hält den Lauf der Aufträge durch die Job-Ketten in der Auftragshistorie fest.
Hier lesen Sie weiteres zur Historie (Seite 132).
Wie die Tabellen angelegt werden, steht hier: »Vom JobScheduler verwendete SQL-Anweisungen« (Seite 348).
1.9.1 Einstellungen
Datenbank und Fehlerbehandlung
factory.ini (Abschnitt [spooler], Eintrag db= …)
factory.ini (Abschnitt [spooler], Eintrag need_db= …)
factory.ini (Abschnitt [spooler], Eintrag max_db_errors= …)
Die Namen der Tabellen
factory.ini (Abschnitt [spooler], Eintrag db_variables_table= …)
factory.ini (Abschnitt [spooler], Eintrag db_tasks_table= …)
August 2014
131
factory.ini (Abschnitt [spooler], Eintrag db_orders_table= …)
factory.ini (Abschnitt [spooler], Eintrag db_history_table= …)
factory.ini (Abschnitt [spooler], Eintrag db_order_history_table= …)
Ob eine Historie geschrieben werden soll
factory.ini (Abschnitt [spooler], Eintrag history= …)
factory.ini (Abschnitt [spooler], Eintrag order_history= …)
factory.ini (Abschnitt [job], Eintrag history= …)
Ob die Protokolle in der Historie aufgenommen werden sollen
factory.ini (Abschnitt [spooler], Eintrag history_with_log= …)
factory.ini (Abschnitt [spooler], Eintrag order_history_with_log= …)
factory.ini (Abschnitt [job], Eintrag history_with_log= …)
Der Task-Historie können Sie eigene Spalten hinzufügen
factory.ini (Abschnitt [spooler], Eintrag history_columns= …)
factory.ini (Abschnitt [job], Eintrag history_columns= …)
Task.set_history_field()
Die Bedingungen für einen Eintrag in die Task-Historie
factory.ini (Abschnitt [spooler], Eintrag history_on_process= …)
1.9.2 Programmschnittstelle
Das Objekt spooler stellt die Tabellennamen bereit
Spooler.db_variables_table_name()
Spooler.db_tasks_table_name()
Spooler.db_orders_table_name()
Spooler.db_history_table_name()
Spooler.db_order_history_table_name()
Eigene Felder der Historie beschreiben ( factory.ini (Abschnitt [job], Eintrag history_columns= …))
Task.set_history_field()
1.9.3 Kommandos
Historie zeigen
Kommando <show_history>
August 2014
132
Kommando <show_task>
Kommando <show_order>
1.9.4 Fehlertoleranz
Der JobScheduler toleriert Datenbankfehler. Dadurch kann er mit einer vorübergehend heruntergefahrenen
Datenbank umgehen. Näheres hierzu finden sie hier: factory.ini (Abschnitt [spooler], Eintrag need_db= …).
Wenn eingestellt ist, dass der JobScheduler nach Verbindungsverlust auf eine erneute Verbindung zur Datenbank
warten soll, hält der JobScheduler solange an. Nur Kommandos über TCP oder HTTP verarbeitet er. Er kann nicht
beendet, nur abgebrochen werden (s. Beendigung (Seite 225)).
1.10 Historie
1.10.1 1. Gegenstand der Historie
Jeder Job-Lauf wird verzeichnet. Festgehalten werden
•
•
•
•
•
•
•
•
•
•
•
•
Satzkennung: ID der für einen Job gestarteten Task, eindeutig für die Task
Scheduler-ID
Jobname
Startzeit
Endzeit (falls erreicht)
Anlass des Starts (falls es mehrere Start-Anlässe gibt, wird der möglicherweise wichtigste Anlass genommen)
Parameter (in XML)
Anzahl Job-Schritte (Anzahl der spooler_process-Aufrufe)
Fehler-Flag
Fehler-Code und Fehlertext
Job-Protokoll (nur, wenn das Protokoll in eine Datenbank geschrieben wird)
Extra Felder
An der TCP-Schnittstelle sind Auszüge der Historie lesbar.
Spalten der Historie
id
Eindeutige Kennung der Task (Tabellenschlüssel)
spooler_id
Scheduler-ID
job_name
Job-Name
start_time
Startzeit (yyyy-mm-dd HH:MM:SS)
end_time
Endezeit (yyyy-mm-dd HH:MM:SS)
steps
Anzahl Aufgerufener spooler_process()
cause
Anlass des Starts
error
0: Kein Fehler; 1: Fehler
error_code
Fehlercode
August 2014
133
error_text
Fehlertext
parameters
Parameter des Jobs (wenn vorhanden) als XML-Dokument (Clob)
log
Job-Protokoll (nicht in der tabulierten Datei bei Verwendung ohne Datenbank)
1.10.2 2. Historiendatei
Die Historie kann in einfache Dateien oder in eine Datenbank geschrieben werden.
1.10.2.1 2.1 Einfache Dateien (tabulierte Dateien)
Für jeden Job wird im Verzeichnis der Protokolldateien (Option -log-dir=) eine Datei fortgeschrieben. Die
Datenfelder werden durch Tabulator getrennt. Beim Start eines Jobs wird ein Satz geschrieben, der beim Ende mit
den vollständigen Daten überschrieben wird.
Dateiname ist log_dir /history. scheduler_id .job. jobname .txt
Die Datei wird beim JobScheduler Start neu angelegt. Eine bereits vorhandene Datei kann zurvor umbenannt und
komprimiert werden.
Der JobScheduler schreibt in die erste Zeile die Spaltennamen.
Tabulatoren in den Daten (v.a. Fehlermeldung) werden unterdrückt.
Jedes Feld hat für 1024 Zeichen Platz. Längere Einträge werden abschnitten.
Archivierung
Beim Start des JobSchedulers werden die Historien der Jobs überschrieben. Die vorhandenen Historien können
mit dem Eintrag history_archive in der Konfigurationsdatei factory.ini (Seite 84) archiviert werden:
[spooler]
history_archive = yes|no|gzip
[Job jobname]
history_archive = yes|no|gzip
history_archive=yes benennt die Datei um. Dazu wird der Dateiname um einen Zeitstempel (sekundengenau)
ergänzt.
history_archive=gzip komprimiert die Datei mit zlib (gzip) von Jean-loup Gailly (http://www.gzip.org/zlib/).
Der Dateiname wird neben dem Zeitstempel um die Endung .gz ergänzt. Die Datei kann mit gzip dekomprimiert
werden. Sie lässt sich auch mit der Hostware mit "nl | gzip | history.gz" lesen.
1.10.2.2 2.2 Datenbank
Alle Daten werden in eine Tabelle geschrieben. Das Task-Protokoll wird in ein Blob geschrieben. Die Tabellennamen können in der Konfigurationsdatei factory.ini (Seite 84) eingestellt werden:
[spooler]
db_history_table
= tabellenname | SCHEDULER_HISTORY
db_variables_table = tabellenname | SCHEDULER_VARIABLES
August 2014
134
In der Tabelle SCHEDULER_VARIABLES wird in einem Eintrag die nächste freie Job-Nummer gehalten.
need_db
Mit dem Eintrag need_db=no kann eingestellt werden, dass der JobScheduler auch starten soll, wenn die
Datenbank sich nicht öffnen lässt. Voreingestellt ist need_db=yes. [spooler]
db = odbc -db=scheduler
need_db = no
Wenn mit db= nur ein Datenbankdateiname und log_dir=*stderr eingestellt sind, kann die Datenbank mangels
Verzeichnis nicht geöffnet werden. Bei need_db=yes startet dann der JobScheduler nicht.
Microsoft-Access-Datenbank wird automatisch angelegt
Wenn bei db= nur ein einfacher Dateiname angegeben ist, stellt der JobScheduler ihm "odbc -create"
voran. Damit wird eine Microsoft MS-Access automatisch angelegt (s. Dateityp ODBC).
In der Datenbank werden die Tabellen SCHEDULER_HISTORY und SCHEDULER_VARIABLES verwendet. Sie werden bei
Bedarf eingerichtet, wobei die SQL-Syntax von MS-Access verwendet wird.
Satz für JobScheduler Start
Der JobScheduler schreibt beim Start einen Satz mit einer eigenen ID in die Historie. Beim Beenden trägt er in
diesem Satz die Zeit ein, so dass ein Satz mit Start- und Endezeitpunkt des JobSchedulers vorliegt. Job-Name ist "
(Spooler)". 1.10.2.3 2.3 Konfiguration in der Datei factory.ini
In der Konfigurationsdatei factory.ini (Seite 84) lassen sich einstellen:
[spooler]
db
db_history_table
db_variables_table
history
history_columns
history_on_process
history_with_log
history_archive
=
=
=
=
=
=
=
=
datenbank
SCHEDULER_HISTORY
SCHEDULER_VARIABLES
no|yes
feld1, feld2,
yes|1|2
no|yes|gzip
no|yes|gzip
[Job jobname]
history
history_columns
history_on_process
history_with_log
history_archive
=
=
=
=
=
no|yes
feld1, feld2,
yes|1|2
no|yes|gzip
no|yes|gzip
Die Einstellungen unter [Job jobname ] haben Vorrang vor [spooler].
history=no unterdrückt die Historie. Wenn eine Datenbank angegeben ist, wird dennoch der Satz für den
JobScheduler Start geschrieben.
history_on_process gibt die Anzahl der Aufrufe von spooler_process() an, ab der ein Eintrag in die Historie
geschrieben werden soll. Bei 1 wird ein Satz nicht geschrieben, wenn spooler_open false liefert.
August 2014
135
history_with_log lässt das Task-Protokoll in die Datenbank mit aufnehmen. Wahlweise komprimiert.
1.10.2.4 2.4 Startanlässe (cause)
In der Historie enthält die Spalte cause den Anlass des Job-Laufs:
none Task ist nicht gestartet (das kommt in der Historie nicht vor) period_once <run_time once="yes"> period_single <run_time single_start="..."> period_repeat <run_time repeat="..."> job_repeat spooler_job.repeat=... queue spooler_job.start() oder <start_job> queue_at wie queue, aber mit bestimmter Zeitangabe (Option at)
directory eine Verzeichnisüberwachung (start_when_directory_changed)lässt den Job
starten
signal <signal_object> delay_after_error spooler_job.delay_after_error 1.10.3 3. Task-Kennung und extra Felder
Jede Task, die für einen Job gestartet wurde, erhält eine Kennung. Wenn eine Datenbank verwendet wird, ermittelt
der JobScheduler sie aus der Tabelle SCHEDULER_VARIABLES. Die Kennung ist dann für alle JobScheduler
eindeutig, die diese Datenbanktabelle nutzen. Andernfalls wird eine fortlaufende Nummer vergeben. Die erste Task
hat die Nummer 1.
Die Kennung kann im Skripten, die das JobScheduler API verwenden, mit der Eigenschaft id abgefragt werden:
meine_id = spooler_task.id
Die Historie kann weitere beliebige Felder aufnehmen, die der Job füllen kann:
spooler_task.history_field( "feldname" ) = wert
Das Feld feldname muss als Spalte in der tabulierten Datei oder in der Historientabelle bekannt sein. Groß-/
Kleinschreibung spielt keine Rolle.
Wenn die Historie in einer Datenbank geführt wird, kann es eine Rolle spielen, von welchem Typ wert ist,
insbesondere ob Zahl oder Zeichenkette.
1.10.3.1 3.1 Extra Felder in der tabulierten Datei
Die zusätzlichen Spalten werden in der Konfigurationsdatei factory.ini (Seite 84) bekannt gemacht [spooler]
history_columns = spalteniste
August 2014
136
[Job jobname]
history_columns = spaltenliste
Die spaltenliste ist eine durch Komma getrennte Liste von Spaltennamen, die der tabulierten Datei hinzugefügt
werden sollen.
1.10.3.2 3.2 Extra Felder in der Datenbank
Die zusätzlichen Spalten in der Historientabelle werden automatisch erkannt. Wenn der JobScheduler die Tabelle SCHEDULER_HISTORY anlegt, richtet er auch die extra Spalten ein, die in
history_columns aufgeführt sind. Als Typ wird char(250) verwendet.
1.10.4 4. Lesen der Historie über die TCP-Schnittstelle
<show_history job="jobname" prev="anzahl|all "what="all"/>
liefert rückwärts geordnet die letzten anzahl Einträge der Historie des angegeben Jobs jobname. Voreinstellung für
anzahl ist 10. Alle Einträge werden mit tail="all" gelesen. Die Funktion benötigt viel Speicherplatz, denn die
Historie wird als XML-Dokument mit DOM im Speicher aufgebaut. Max. 1000 Einträge werden geliefert.
what="all" liefert auch die Job-Protokolle.
Mit folgenden Varianten lassen sich Ausschnitte der Historie lesen. Das Attribut what kann immer angegeben
werden.
Um anzahl Einträge vor der id zu erhalten:
<show_history job="jobname" id="id" prev="anzahl"/>
Um anzahl Einträge nach der id zu erhalten:
<show_history job="jobname" id="id" next="anzahl"/>
Um nur den Eintrag der id zu bekommen. Gut, wenn mit what="all" das Jobprotokoll einer bestimmten Task
gelesen werden soll.
<show_history job="jobname" id="id"/>
Das Ergebnis sind dann so aus:
<history>
<history.entry id="kennung" job="jobname" start_time="startzeit" end_time="
endezeit" ...>
<variableset>
<variable name="name1" value="wert1"/>
<variable name="name2" value="wert2"/>
</variableset>
<log>Jobprotokoll</log>
</history.entry>
<history.entry ...>
August 2014
137
...
</history.entry>
...
</history>
1.10.5 5. Fehlerbehandlung
Fehler beim Öffnen oder Schreiben der Historie werden ins JobScheduler Protokoll geschrieben und ignoriert.
1.11 Der JobScheduler als Dienst
Der JobScheduler wird unter Windows als Dienst betrieben. Die Einrichtung erfolgt automatisch mit dem
Installationsprogramm. Nachstehend sind die Kommandozeilenoptionen beschrieben, die für die Einrichtung
relevant sind. Diese Optionen werden vom Installationsprogramm ins Start-Script .\bin\jobscheduler.cmd
(Windows) bzw. ./bin/jobscheduler.sh (Unix) übernommen.
Aufruf
scheduler -remove-service [-service-name= name] [-id= id]
scheduler [-remove-service] -install-service
[-service-name= name] [-service-display= gezeigtername] [-service-descr= beschreibung]
[-need-service= name]
[optionen]
Parameter
-remove-service
Entfernt den Dienst. Der Dienst muss vorhanden sein.
-install-service
Installiert den Dienst. Weitere Kommandozeilenoptionen, die hier nicht aufgeführt sind, werden beim Start des
Dienstes dem JobScheduler übergeben (v.a. -id=, -log-dir=)
-service-name= name
Stellt den (internen) Dienstnamen ein für -remove-service oder -install-service.
Voreinstellung ist sos_scheduler. Wenn die Option -id= angegeben ist: sos_scheduler_ id
-service-display= gezeigtername
Gibt den angezeigten Namen des Dienstes an.
Voreinstellung bei nicht angegebenen -service-name ist "SOS JobScheduler". Wenn die Option -id= angegeben
ist: "SOS JobScheduler -id=id". Wenn -service-name= angegeben ist, ist dies als angezeigter Name voreinstellt.
-service-descr= beschreibung
Setzt die Beschreibung des Dienstes. Voreinstellung ist "Job Automation Processor". Software- und Organisations-Service GmbH
August 2014
138
In Windows NT 4 ignoriert der JobScheduler diese Option.
-need-service= dienst
Gibt einen anderen Dienst an, von dem dieser Dienst abhängig ist. Windows startet diesen Dienst erst, wenn der
andere Dienst läuft. Die Option kann mehrfach angegeben werden. Ein unbekannter Dienstname wird von
Windows nicht bemängelt. Diese Option kann bspw. eingesetzt werden, wenn JobScheduler und Datenbank auf demselben Server ablaufen
und sichergestellt werden soll, dass die Datenbank zuerst gestartet ist bevor der JobScheduler startet.
Der Name eines Dienstes wird in der Dialogbox zum Dienst in der Dienststeuerung angezeigt.
Fehler beim Start
Die Dienststeuerung in Windows erlaubt es dem Dienst nicht, eine Fehlermeldung zurückzugeben, wenn der
Dienst nicht starten kann. Deshalb schreibt der Dienst einen einfachen Eintrag in die Ereignissteuerung.
Außerdem wird eine E-Mail mit der Fehlermeldung verschickt. Dazu werden die Einträge aus der Datei
factory.ini log_mail_from, log_mail_to, log_mail_cc, log_mail_bcc und smtp verwendet. Eine mit -ini=
eingestellte Konfigurationsdatei wird nicht verwendet. Die Einstellungen in der Datei sos.ini, Abschnitt [mail]
werden alternativ verwendet (s.a. sos.ini, Abschnitt [spooler] (Seite 169)).
1.12 Backup JobScheduler
1.12.1 JobScheduler Backup Cluster
Ein JobScheduler Backup-Cluster sorgt für Ausfallsicherheit für einen JobScheduler indem ein oder mehrere
Ersatz-Scheduler (Backup Scheduler) auf anderen Rechnern gestartet werden. Eine ausfallsicheres System
besteht demnach aus einem primären JobScheduler und mindestens einem Backup Scheduler.
In einem Backup-Cluster zeigen alle JobScheduler ihre Verfügbarkeit durch das Versenden von Herzschlägen an.
Alle JobScheduler prüfen, ob die jeweils anderen JobScheduler verfügbar sind. Stellt ein Backup JobScheduler
fest, dass vom primären JobScheduler die Herzschläge über einen längeren Zeitraum (ca. 1-2 Minuten)
ausbleiben, übernimmt dieser die Verarbeitung. Dabei werden die offenen Aufträge und laufenden Jobs fortgeführt
und entsprechend der Konfiguration neue Jobs gestartet
In einem Backup Cluster ist maximal ein JobScheduler aktiv, d.h. der primäre JobScheduler startet Jobs bzw.
verarbeitet Aufträge. Die anderen JobScheduler sind inaktiv, d.h. die Backup JobScheduler warten darauf, bei
Ausfall des primären JobSchedulers die Verarbeitung zu übernehmen.
Die Voraussetzungen für die Operation eines Backup Clusters sind schematisch in der folgende Zeichnung
abgebildet, und werden im Detail in den nächsten Abschnitt beschreiben.
August 2014
139
Die Übernahme der Verarbeitung durch eines Backup JobSchedulers ist schematisch in der folgende Zeichnung
abgebildet:
August 2014
140
1.12.1.1 Voraussetzungen für den JobScheduler Backup Cluster
•
•
•
•
Alle JobScheduler des Clusters verwenden die selbe Datenbank. Es werden die Datenbanksysteme Oracle,
DB2, MySQL und Postgres unterstützt.
Alle JobScheduler verwenden die selbe Konfigurationsdatei bzw. eine genaue Kopie.
Der primäre JobScheduler und die Backup JobScheduler werden mit der gleichen Scheduler-ID gestartet.
Der primäre JobScheduler und die Backup JobScheduler werden mit der Option -exclusive gestartet.
1.12.1.2 Starten des JobScheduler Backup Clusters
Die JobScheduler, die den Cluster bilden, werden in beliebiger Reihenfolge gestartet. Der erste JobScheduler, der
nicht mit der Option -backup gestartet wurde, wird aktiv.
August 2014
141
1.12.1.3 Kommandozeilenparameter
Folgende Kommandozeilenparameter konfigurieren einen JobScheduler als Mitglied des Backup Clusters:
•
•
•
-exclusive bestimmt, dass der JobScheduler Mitglied des Backup Cluster ist.
-backup bestimmt, dass es sich um einen Backup JobScheduler handelt. Fehlt das Attribut, dann handelt es
sich um einen primären JobScheduler. Es kann mehrere Backup JobScheduler geben, die alle die gleiche
Startpriorität im Falle eines Ausfalls des aktiven JobSchedulers haben
-backup-precedence bestimmt die Rangfolge, mit der Backup JobScheduler aktiv werden. Es wird jeweils
der JobScheduler mit dem kleinstem Wert aktiv, wenn der primäre JobScheduler ausfällt.
1.12.1.4 Beenden von JobSchedulern im Backup Cluster mit den Funktionen der Web-Oberfläche
Beim Beenden werden die laufenden Prozessschritte von Jobs noch ausgeführt, allerdings keine neuen
Prozessschritte veranlasst. Mit dem Parameter -timeout =<wert> kann das Beenden laufender Prozessschritte
nach Ablauf einer Zeit erzwungen werden.
1.12.1.4.1 Beenden aller JobScheduler im Backup Cluster
Alle JobScheduler im Cluster werden beendet, indem in der JobScheduler Web-Oberfläche das Kommando
"terminate cluster" aufgerufen wird.
Entspricht dem XML-Kommando <terminate all_schedulers="yes">
1.12.1.4.2 Beenden aller JobScheduler im Backup Cluster mit Timeout
"terminate cluster within 60s" aufgerufen wird. Nach Ablauf von 60 Sekunden werden alle noch laufenden
Prozessschritte abgebrochen.
Entspricht dem XML-Kommando <terminate all_schedulers="yes" timeout="60">
1.12.1.4.3 Beenden aller JobScheduler im Backup Cluster mit Neustart
"terminate and restart cluster" aufgerufen wird. Anschließend starten sie neu. Der primäre JobScheduler ist nach
dem Neustart wieder aktiv.
Werden alle JobScheduler neu gestartet, so ist anschließend der primäre JobScheduler der aktive JobScheduler.
Entspricht dem XML-Kommando <terminate all_schedulers="yes" restart="yes">
1.12.1.4.4 Beenden aller JobScheduler im Backup Cluster mit Timeout und Neustart
"terminate and restart cluster" aufgerufen wird. Die JobScheduler starten anschließend neu. Der primäre
JobScheduler ist nach dem Neustart wieder aktiv. Nach Ablauf von 60 Sekunden werden alle noch laufenden
Prozessschritte abgebrochen.
Werden alle JobScheduler neu gestartet, so ist anschließend der primäre JobScheduler der aktive JobScheduler
Entspricht dem XML-Kommando <terminate all_schedulers="yes" restart="yes" timeout="60">
August 2014
142
1.12.1.4.5 Beenden des aktiven JobSchedulers. Die Backup JobScheduler bleiben gestartet ohne Jobs
und Aufträge zu verarbeiten
Ein aktiver JobScheduler wird beendet, indem in der JobScheduler Web-Oberfläche das Kommando "terminate"
aufgerufen wird. Das Kommando hat keinen Einfluss auf Backup JobScheduler, es erfolgt kein Failover, da kein
Fehlerzustand im primären JobScheduler eingetreten ist.
Entspricht dem XML-Kommando <terminate>
1.12.1.4.6 Beenden des aktiven JobSchedulers mit Neustart. Die Backup JobScheduler bleiben gestartet
ohne Jobs und Aufträge zu verarbeiten
Ein aktiver JobScheduler wird beendet und anschließend neu gestartet, indem in der JobScheduler
Web-Oberfläche das Kommando "terminate and restart" aufgerufen wird. Das Kommando hat keinen Einfluss auf
Backup JobScheduler, es erfolgt kein Failover, da kein Fehlerzustand im primären JobScheduler eingetreten ist.
Entspricht dem XML-Kommando <terminate restart="yes">
1.12.1.4.7 Beenden eines Backup JobSchedulers mit Neustart.
Ein JobScheduler wird beendet und anschließend neu gestartet, indem in der JobScheduler Web-Oberfläche das
Kommando "terminate and restart" aufgerufen wird.
Der Backup JobScheduler wird nach dem Neustart nicht aktiv. Ist im Cluster ein inaktiver primärer JobScheduler
gestartet, so wird dieser aktiv.
Entspricht dem XML-Kommando <terminate restart="yes">
1.12.1.5 Primären JobScheduler nach Ausfall reaktivieren
1.
2.
Der primäre JobScheduler wird nach einem Ausfall gestartet. Falls bereits ein Backup JobScheduler läuft,
übernimmt der primäre JobScheduler nicht die Verarbeitung.
Der Backup JobScheduler wird neu gestartet ("terminate and restart"). Der primäre, bislang inaktive,
JobScheduler wird aktiv und übernimmt die Verarbeitung. Wenn mehrere primäre JobScheduler vorhanden
sind, bestimmt -backup-precedence welcher JobScheduler aktiv wird.
1.12.1.6 Backup JobScheduler übernimmt die Verarbeitung
Der primäre JobScheduler wird mit "terminate fail-safe" beendet. Ein bereits laufender Backup JobScheduler
übernimmt automatisch nach ca. 1-2 Minuten die Verarbeitung.
1.12.1.7 Verhalten des Dienstes unter Windows
•
•
Das Beenden des Dienstes entspricht dem Kommando <terminate>. Die Backup JobScheduler laufen nicht
an. Wird ein Backup JobScheduler beendet und gibt es einen inaktiven primären JobScheduler, so wird der
primäre JobScheduler aktiv.
Das Starten des Dienstes entspricht dem Kommando <terminate restart="yes"> . Die Backup-Scheduler
laufen nicht an. Der primäre JobScheduler wird aktiv.
August 2014
143
1.12.1.8 Verhalten beim Neustart des Rechners
•
•
Wenn der Rechner heruntergefahren wird, übernimmt ein Backup JobScheduler auf einem zweiten Rechner
(continue_exclusive_operation="yes")
Wenn primärer JobScheduler und Backup JobScheduler neu gestartet werden, z.B. wg. Neustart der Server,
dann kann es sein, dass der Backup JobScheduler zuerst startet. Er übernimmt dann nicht sofort die
Verarbeitung sondern wartet, ob vom primären JobScheduler ein Herzschlag kommt. Nur wenn nach 60s kein
Herzschlag kommt, übernimmt der Backup JobScheduler die Verarbeitung. Dies entspricht dem
Standardverhalten beim Ausbleiben eines Herzschlags des aktiven JobSchedulers.
1.12.1.9 Einen inaktiven Backup JobScheduler zum aktiven primären JobScheduler machen
Wenn ein aktiver Backup JobScheduler beendet wird, dann wird er beim Neustart inaktiv sein. Falls der primäre
JobScheduler längere Zeit ausfällt, muss der Backup JobScheduler als primärer JobScheduler gestartet werden.
Ein Backup JobScheduler wird als primärer JobScheduler gestartet, indem beim Aufruf von jobscheduler.cmd der
Parameter "start -exclusive" anstelle von "start" angegeben wird.
1.12.1.10 Kommandos des Startscript
Wenn beim Start nur der Parameter "start" angegeben wird, damm wird der JobScheduler so gestartet wie es beim
Setup eingerichtet wurde.
Folgende zusätzliche Kommandos gibt es für den Betrieb eines JobScheduler im Backup Cluster
•
•
•
•
•
•
terminate_cluster Fährt alle JobScheduler des Backup Clusters herunter
restart_cluster Startet alle JobScheduler des Backup Clusters neu. Anschließend ist der primäre
JobScheduler aktiv.
terminate_fail-safe Beendet den JobScheduler. Ein anderer, inaktiver JobScheduler im Backup Cluster wird
aktiv.
start -exclusive Startet einen primären JobScheduler im Backup Cluster.
start -exclusive -backup Startet einen Backup JobScheduler im Cluster.
start -exclusive -backup -backup-precedence=[n] Startet einen Backup JobScheduler im Cluster mit der
Rangfolge [n].
1.12.1.11 Weiterführende Links
•
Watchdog-Monitor für Cluster Failover.
August 2014
Jobs
144
2 Jobs
2.1 Was ist ein Job?
Ein Job bestimmt das auszuführende Programm, seine Laufzeit und das Verhalten im Fehlerfall. Darüber hinaus
können die Parametrisierung, Vor- und Nachverarbeitung, konkurrierender Zugriff auf Sperren und mögliche
Folge-Jobs Teil einer Job-Konfiguration sein.
Ein Job wird definiert in der XML-Konfiguration mit <job> .
2.1.1 Konfiguration
Die XML-Konfiguration eines Jobs kann in der zentralen Startkonfigurationsdatei (meist ./config/scheduler.xml)
oder in Form einer separaten Datei in dem vom JobScheduler überwachten Konfigurationsverzeichnis (meist
./config/live) vorgenommen werden, siehe (Seite 78)
2.1.2 Implementierung
Der JobScheduler startet ausführbare Programme und kann Jobs mit individuellen Implementierungen starten, die
das API des JobSchedulers nutzen.
Ausführbare Programme
Sie können beliebig implementiert sein als executable, shell scripte, batch files. Dies bezieht Programme ein, z.B.
JavaScript, VBScript, Perl, PHP, Ruby etc., für die ggf. ein Interpreter mit der auszuführenden Programmdatei
gestartet werden muss. Java-Klassen können mit der für den JobScheduler konfigurierten JVM gestartet werden.
Ausführbare Programme können mit folgenden Elementen konfiguriert werden:
<script language="…">
<script language="shell">
Der JobScheduler erzeugt eine Shell für die Ausführung des Programms.
Beispiele:
<job name="simple_shell">
echo hello world
call my_script.cmd
my_prog.exe
]]></script>
</job>
<job name="simple_command">
<include file="my_script.cmd"/>
</script>
</job>
August 2014
Jobs
145
Kommandos des Kommandozeileninterpreters können direkt als Inhalt des <script> Elements einngegeben
werden. Alternativ können Shell Scripte mittels <include> angegeben werden.
<script language="java">
Der JobScheduler startet eine JVM für die Ausführung der Java-Klasse.
Beispiel:
<job name="simple_java">
<script language
= "java"
java_class = "sos.scheduler.ftp.JobSchedulerFTPReceive"/>
</job>
<process file="…">
Der JobScheduler startet das Programm ohne separate Shell.
Beispiele:
<job name="simple_job">
<process file="c:\my_prog.exe"/>
</job>
<job name="interpreter_job">
<process file="c:\php\php.exe"
param="-f 'c:\test\phpinfo.php'"/>
</job>
Für Programmdateien, die per Interpreter gestartet werden, muss dieser als auszuführendes Programm konfiguriert
sein.
Implementierungen mit dem JobScheduler API
Job-Implementierungen können das API des JobSchedulers nutzen, z.B. zur Protokollierung, Benachrichtigung per
eMail, Zugriff auf Job-, Task- und Auftragsobjekte etc.
Der JobScheduler startet diese Scripte nicht per Interpreter (s.o.) sondern implementiert eine
Unterprogrammschnittstelle für den Aufruf von Scripten in diesen Sprachen und stellt ihnen Objekte und Methoden
zur Verfügung.
Java
Ein Job in Java ist eine Implementierung der abstrakten Oberklasse sos.spooler.Job_impl.
Die Java-Schnittstelle stellt weitere Klassen bereit. Sie gilt entsprechend für die COM- und Perl-Schnittstellen,
wenn Sie Ihren Job in einer anderen Sprache implementieren.
Den Pfad der implementierten Klasse geben Sie in sos.ini (Abschnitt [java], Eintrag class_path= …) an.
JavaScript und JScript (Seite 361)
JavaScript ist in der Implementierung von SpiderMonkey (http://developer.mozilla.org/en/docs/SpiderMonkey) im
Auslieferungsumfang des JobSchedulers für alle Plattformen enthalten.
Microsoft JScript ist auf Windows Plattformen verfügbar.
VBScript
Microsoft VBScript ist auf Windows Plattformen verfügbar.
August 2014
Jobs
146
Perl
Perl ist auf Unix-Plattformen i.d.R. vorinstalliert. Das Installationsprogramm des JobSchedulers versucht die
Unterprogrammschnittstelle passend zur vorhandenen Perl Version zu installieren.
Auf Windows-Plattformen kann eine Perl-Implementierung, z.B. von http://www.activestate.com, nachinstalliert
werden.
COM (Seite 148)
Sie können auch (unter Windows) einen Job in jeder beliebigen Programmiersprache als COM-Server
implementieren. Weiteres siehe hier (Seite 148).
2.1.3 Zustand eines Jobs
Ein Job ist in einem der folgenden Zustände.
pending
Keine Task läuft. Das ist der anfängliche Zustand.
running
Wenigstens eine Task läuft.
stopping
Der Job stoppt. Der JobScheduler startet keine weitere Task und die laufenden
Tasks werden beendet. Sobald alle Tasks des Jobs beendet sind, wechselt der Job
in den Zustand stopped.
Siehe das Kommando <modify_job cmd="stop"> .
stopped
Keine Task läuft und der JobScheduler startet keine weitere Task.
Siehe das Kommando <modify_job cmd="stop"> .
read_error
Das Kommando reread hat zu einem Fehler geführt, und der Job ist unbrauchbar,
weil der Programmcode nicht gelesen werden konnte.
Siehe das Kommando <modify_job cmd="reread"> .
error
Wenn eine Task mit Fehler geendet hat, startet der JobScheduler keine weitere
Task.
2.1.4 Zustand des Jobs ändern
Mit dem Kommando <modify_job> können Sie den Zustand des Jobs ändern. Die eingebaute HTML-Oberfläche
(Seite 174) des JobSchedulers bietet hierfür die entsprechenden Operationen an.
2.1.5 Eine Task starten
In der Konfiguration können Sie mit <run_time> einstellen, dass eine Task einmal oder periodisch gestartet werden
soll.
Das Kommando <start_job> startet eine Task, ebenso die API-Methode Job.start() .
Eine Task wird automatisch gestartet, wenn noch keine Task läuft und eine der folgenden Bedingungen gilt.
•
•
Zu Beginn einer <period> , wenn in ihr repeat= oder single_start= angegeben ist.
Wenn ein vorangehender Lauf Task.repeat gesetzt hat und die Zeit erreicht ist.
August 2014
Jobs
•
•
•
147
Wenn ein vorangehender Lauf fehlerhaft war und Job.delay_after_error abgelaufen ist.
Wenn das mit <period repeat="…"> angegebene Intervall nach dem Ende der zuletzt gelaufenen Task
abgelaufen ist.
Wenn die Verzeichnisüberwachung (Seite 162) aktiv ist und das überwachte Verzeichnis geändert worden ist.
Außerdem startet eine Task
•
wenn ein Auftrag für den Job vorliegt, und noch nicht soviele Tasks laufen, wie mit <job tasks="…">
zugelassen.
Eine Task läuft aber nur an, wenn sie eine Startzeit (at) hat oder
•
•
•
der Job nicht gestoppt ist,
es eine Periode für die aktuelle Zeit gibt,
und die Verzögerung nach Fehler ( Job.delay_after_error ) nicht wirkt.
2.1.6 Sperren
Jobs können mit Sperren versehen werden, um den gleichzeitigen Lauf zweier Tasks zu verhindern. Siehe (Seite
152).
2.1.7 Verzeichnisüberwachung
Der JobScheduler kann einen Job bei Änderungen in einem Dateiverzeichnis starten. Näheres im Kapitel
Verzeichnisüberwachung (Seite 162).
2.1.8 Monitor
Für einen Job kann ein Monitor Script konfiguriert werden. Der JobScheduler ruft Funktionen des Monitor Scripts
bei Start und Ende der Task auf sowie vor und nach der Methode spooler_process() .
Den Monitor bestimmen Sie mit <monitor> .
Beispiel:
<job name = "simple_ftp"
<params>
<param name = "ftp_host"
<param name = "ftp_user"
<param name = "ftp_password"
</params>
value = "localhost"/>
value = "anonymous"/>
value = "anonymous"/>
<script language
= "java"
java_class = "sos.scheduler.ftp.JobSchedulerFTPReceive"/>
<monitor>
<script language="javascript"><![CDATA[
function spooler_task_before() {
var today = yy = mm = dd = "";
today = new Date();
yy = today.getYear() + 1900;
mm = today.getMonth() + 1;
August 2014
Jobs
148
dd = today.getDate();
if (parseInt(mm) < 10) mm = "0" + mm;
if (parseInt(dd) < 10) dd = "0" + dd;
spooler_task.params.set_var("ftp_file_path", "^test_" + yy + "-" + mm + "-" +
dd + "\.csv$" );
return true;
}
]]></script>
</monitor>
</job>
Das Monitor Script verwendet einen Standard-Job der Auslieferung für den FTP-Transfer einer Datei. Dabei wird
der Job-Parameter für den Namen der zu übertragenden Datei dynamisch aus dem Tagesdatum
zusammengesetzt.
2.2 Spooler-Skripte als COM-Klassen implementieren
Bisher wird ein Skript im Spooler mit einer Scripting Engine realisiert. Das Skript in einer Skriptsprache (VBScript,
JScript, PerlScript) wird direkt im Element <script> angegeben.
Ein Spooler-Skript lässt sich auch als com-Klasse implementieren. Die com-Klasse kann in jeder Sprache, die com
unterstützt, implementiert werden, u.a. C++, Delphi und VisualBasic. Mit Hilfe von "Windows Script Component"
lässt sich die com-Klasse auch mit VBScript, JScript und PerlScript realisieren.
Die Klasse stellt die Methoden eines Jobs, Thread-Skripts oder Spooler-Skripts bereit, also:
spooler_init()
spooler_exit()
spooler_open()
spooler_close()
spooler_process()
spooler_on_success()
spooler_on_error()
Jede Methode ist optional. Ist sie nicht implementiert, wird wie bei den bisherigen Spooler-Skripten verfahren.
Die Klasse sollte außerdem eine Methode bereitstellen, mit der der Spooler-Kontext übergeben wird:
spooler_set_context(context)
Dieser Kontext ist ein com-Objekt (IDispatch) mit folgenden Eigenschaften:
log
spooler
thread
job
task
Diese Eigenschaften liefern die aus dem Spooler-Skripten bekannten Objekte spooler_log, spooler_task,
spooler_job, spooler_thread und spooler.
August 2014
Jobs
149
Gemeinsamkeiten von Skript in Scripting Engine und com-Klasse
•
•
•
•
Attribut use_engine="task" und use_engine ="job" möglich.
Als Job-Skript, Thread-Skript und Spooler-Skript (bzw. -Klasse) verwendbar
Aufrufe (spooler_init(), spooler_open() etc.) sind gleich
Die Aufrufe sind optional
Unterschiede zwischen Skript in Scripting Engine und com-Klasse
Skript mit Scripting Engine
COM-Klasse
Quellcode wird in der Konfiguration angegeben (oder
extern mit <include>).
Implementierung ist unabhänging vom Spooler. Jede
Sprache, die COM-Klassen mit später Bindung (
IDispatch) generiert, kann verwendet werden.
Der Kontext steht dem Skript mit den vordefinierten
Variablen spooler_log, spooler, spooler_thread,
spooler_job und spooler_task zur Verfügung. Der Spooler übergibt den Kontext dem com-Objekt mit
dessen Methode spooler_set_context().
Dasselbe Skript kann, wenn es in einer eigenen Datei
vorliegt, mit <include> an mehreren Stellen verwendet
werden.
Die Klasse kann an mehreren Stellen verwendet
werden. Es werden getrennte Objekte der Klasse
angelegt.
Attribut use_engine="task" und ="job" möglich
Attribut use_engine="task" und ="job" möglich
Deklaration in der Spooler-Konfiguration Der als com-Klasse registrierte Job kann über seinen Klassennamen angegeben werden:
<job name="delphijob">
<script com_class="meine_spooler_job_klasse"/>
</job>
Statt des Klassennamens kann auch die eindeutige clSID angegeben werden:
<script com_class="{F44FF458-D4DE-4cef-AA1A-CCC507346581}"/>
</job>
Attribut use_engine
Das Attribut use_engine kann auch für ein COM-Objekt verwendet werden. Bei use_engine="job" wird das
Objekt für mehrere Tasks beibehalten. Wie bisher wird spooler_init() nur einmal, spooler_open() aber für jede
Task (jeden Jobstart) aufgerufen. Die Bedeutung ist dieselbe wie bisher.
Direkte Angabe der DLL
Wenn die DLL eine weitere DLL braucht, die nicht geladen werden kann, hält Windows den Spooler mit einer
Messagebox an. Erst wenn der OK-Knopf gedrückt wird, setzt der Spooler fort. Die Angabe der DLL ist also nicht
für den unbeaufsichtigten Betrieb geeignet.
Wenn die com-Klasse nicht registiert werden soll, kann auch die DLL direkt angegeben werden. Die Klasse wird
dann als hexadezimale CLSID angegeben.
August 2014
Jobs
150
<script com_class="{xxxx-xx-...}" filename="meine_delphi.dll"/>
</job>
Beispiel
Die com-Klasse wird mit "Windows Script Component" realisiert. Die Quelle ist:
<?XML version="1.0"?>
<component>
<registration
progid = "Joacim.Component"
classid = "{F44FF458-D4DE-4cef-AA1A-CCC507346581}"
description = "Joacims Script Component"
version = "1"
/>
<public>
<method name="spooler_set_context"/>
<method name="spooler_init"/>
<method name="spooler_exit"/>
<method name="spooler_open"/>
<method name="spooler_process"/>
</public>
<script language="VBScript">
<![CDATA[
dim spooler_log
dim spooler_task
dim i
function spooler_set_context(c)
set spooler_log = c.log
set spooler_task = c.task
spooler_log "Script component spooler_set_context"
end function
function spooler_init
August 2014
Jobs
151
spooler_log "Script component spooler_init"
end function
function spooler_exit
spooler_log "Script component spooler_exit"
end function
function spooler_open
spooler_log "Script component spooler_open"
i = 3
end function
function spooler_process
spooler_log "Script component spooler_process i=" & i
i = i - 1
spooler_process = i > 0
end function
]]>
</script>
</component>
Diese Quelle wird in die Datei job.wsc geschrieben und mit folgendem Kommando als COM-Server registriert.
regsvr32 job.wsc In der Spooler-Konfiguration kann der Server mit seinem Klassennamen angegeben werden:
<job name="component">
<script com_class="Joacim.Component"/>
<run_time once="yes"/>
</job>
Oder mit seiner eindeutigen CLSID:
<job name="component">
<script com_class="{F44FF458-D4DE-4cef-AA1A-CCC507346581}"/>
<run_time once="yes"/>
</job>
Unix
Die Portierung auf Unix ist trotz com prinzipiell möglich. Statt der späten Bindung über die Schnittstelle IDispatch
wird die frühe Bindung verwendet. Das heißt:
August 2014
Jobs
•
•
•
•
•
•
152
Bindung zur Compile-Zeit über Header-Dateien statt Verwendung von IDispatch.
Die com-Klasse erbt von der Klasse Spooler.Job
Sie implementiert alle Aufrufe. Die Aufrufe sind nicht mehr optional (Fehlercode E_NOTIMPL kann
zurückgegeben werden)
Die com-Unterstützung von Delphi kann möglichweise nicht verwendet werden, wenn sie zuviel voraussetzt.
Stattdessen werden die com-Aufrufe direkt verwendet. Für die Job-Implementierung heißt das, dass die
Rückgabe einer Fehlermeldung mit dem Aufruf SetErrorInfo() codiert wird.
Das Modul (shared object) wird nicht registriert, sondern direkt mit <script filename="..."/> angegeben
Die für Unix geänderte Implementierung des Jobs wird auch in Windows ablauffähig sein. Ein #ifdef wird
wahrscheinlich nicht gebraucht. Der Job wird wegen der frühen Bindung sogar schneller laufen.
2.3 Sperren
Sperren im JobScheduler verhindern die Ausführung eines Jobs, solange eine bestimmte Sperre von einem oder
mehreren anderen Job(s) belegt ist. Sperren stehen für Jobs in Job-Ketten und für einzelne Jobs zur Verfügung.
Wartet ein Job auf die Freigabe einer Sperre, wird er automatisch gestartet, sobald die Sperre freigegeben wird.
Ein beispielhaftes Problem: Jobs benutzen eine Datenbank. Ein weiterer Job aber schaltet die Datenbank um. Er
darf das nur tun, wenn die ersten Jobs nicht laufen.
2.3.1 Konfiguration
Damit Jobs Sperren belegen können, müssen die Sperren zunächst bekanntgemacht werden.
<config>
<locks>
<lock name="lock_name"/>
<lock name="lock_name2"/>
…
</locks>
Beim einzelnen Job werden die anzuwendenden Sperren deklariert
<job>
<lock.use lock="lock_name"/>
<lock.use lock="lock_name2"/>
Sperren können exklusiv und nicht exklusiv verwendet werden. Bei nicht exklusiver Verwendung einer Sperre kann
die Zahl der nicht exklusiven Belegungen begrenzt werden. Die Voreinstellung für die Verwendung einer Sperre ist
die exklusive Belegung
Wenn eine Sperre verwendet wird, die nicht deklariert wurde, startet der JobScheduler den Job nicht.
Achtung: Bei Namen von Sperren wird Groß- und Kleinschreibung unterschieden!
Die Belegung einer Sperre beginnt mit dem Start einer Task und endet mit ihr. Eine exklusive Sperre erlaubt nur
eine Task.
Exklusives Sperren
August 2014
Jobs
153
Eine Task, die eine Sperre belegt, lässt keine andere Task zu, die dieselbe Sperre beansprucht.
Deklaration:
<config>
<locks>
<lock name="lock_name"/>
…
</locks>
Anwendung:
<job>
<lock.use lock="lock_name"/>
Nicht exklusives Sperren
Eine Sperre kann nicht-exklusiv von mehreren Jobs belegt werden.
Die Zahl der nicht-exklusiven Belegungen lässt sich begrenzen.
<lock name="lock_name" max_non_exclusive="2"/>
<job name="my_database_job">
<lock.use lock="lock_name" exclusive="no"/> …</job>
<job name="my_other_database_job">
<lock.use lock="lock_name" exclusive="no"/> …</job>
<job name="switch_database">
<lock.use lock="lock_name"/> …</job>
Die ersten beiden Jobs können gleichzeitig ablaufen, aber keiner der ersten beiden Jobs kann mit dem dritten
zusammen ablaufen, der die Sperre exklusiv beansprucht.
2.3.2 Sperren in Job-Ketten
Da Sperren von Tasks belegt werden, können sie in Job-Ketten verwendet werden, wenn die Tasks der einzelnen
Job-Knoten sich nach Ausführung beenden. Dazu muss das Attribut idle_timeout idealerweise auf 0 gesetzt sein.
August 2014
Jobs
154
2.4 Externe Job-Verarbeitung mit Agenten
Jobs können auf einem entfernten JobScheduler ausgeführt werden, wenn dieser als Agent konfiguriert ist. Nur
Agenten erlauben es, remote Kommandos von aufrufenden Schedulern entgegen zu nehmen.
Agenten zeichnen sich durch folgenden Merkmale aus:
•
Agenten müssen keinen live-folder haben.
•
Evtl. vorhandene lokale Jobs werden nicht ausgeführt. Das gilt auch für JobScheduler Standardjobs wie
scheduler_event_service.
•
Wird die Ausführung lokaler Jobs unterdrückt, wird dies mit einer entsprechenden Meldung protokolliert.
•
Interne Jobs (scheduler_file_order_sink und scheduler_web_service) werden nicht ausgeführt.
•
Nur Agenten sind in der Lage, remote Kommandos aufrufender JobScheduler auszuführen. Wird versucht ein
remote Kommando auf einem JobScheduler auszuführen, der kein Agent ist, wird dies mit einer
Fehlermeldung protokolliert.
Entfernt ausgeführte Jobs verhalten sich gegenüber dem aufrufenden JobScheduler so wie lokal ausgeführte Jobs.
Lediglich die Rechenlast wird auf einen anderen JobScheduler übertragen.
Das bedeutet z.B., dass alle API-Aufrufe sich auf das lokale JobScheduler Objekt beziehen.
Die Protokollausgaben des Jobs, sowie der Endzustand und eventuelle Fehler werden an den aufrufenden
JobScheduler geleitet.
Es ist möglich dass eine JobScheduler Installation gleichzeitig JobScheduler und JobScheduler Agent ist, indem
sie mit den entsprechenden Lizenzschlüsseln gestartet wird.
2.4.1 Verwendung
Überwiegend werden JobScheduler mit der Ausführung von Jobs beauftragt, die auf einem anderen physikalischen
Rechner installiert sind.
Beispiele für die Verwendung:
1.
Das Verfahren dient dem Load Balancing.
2.
Es können Software-Installationen verwendet werden, die sich nicht auf dem lokalen Rechner befinden.
3.
Es können Hardware-Komponenten verwendet werden, die nur von einem anderen Rechner erreichbar sind
(z.B. Drucker).
2.4.2 Voraussetzungen
1.
Einstellungen in der Firewall
Der lokale JobScheduler muss den Agenten erreichen können. Alle Sicherheitseinstellungen in den Firewalls
müssen das berücksichtigen. Für die Kommunikation in Richtung Agent muss der Port des Agenten in der
Firewall freigeschaltet sein. In der entgegengesetzten Richtung verbindet sich die Task mit dem aufrufenden
JobScheduler über einen Port <=59999 abwärts zählend pro laufende Task. Entsprechend der erwarteten
Anzahl Tasks müssen diese Ports in der Firewall freigeschaltet sein.
2.
Security-Einstellungen in der JobScheduler Konfiguration
Der Agent muss im Security Element den aufrufenden JobScheduler legitimieren.
Beispiel
<security ignore_unknown_hosts="no">
August 2014
Jobs
155
<allowed_host host="123.456.89.1" level="all"/>
</security>
3.
Beide JobScheduler müssen gestartet sein.
2.4.3 Konfiguration
Die Job-Definition steht in der Konfigurationsdatei des lokalen, aufrufenden JobScheduler.
Um einen Job auf einem Agenten ausführen zu lassen, sind beim lokalen, aufrufenden JobScheduler folgende
Konfigurationen nötig:
1.
Es muss eine Prozessklasse angelegt werden, und in ihr das Attribut <process_class
remote_scheduler=""> gesetzt sein. Dadurch werden alle Jobs, die dieser Prozessklasse zugeordnet sind,
extern ausgeführt.
Beispiel
<process_classes>
<process_class name="remote"
max_processes="3"
remote_scheduler="remoteHost:4445"/>
</process_classes>
2.
Der Job muss der Prozessklasse zugeordnet werden,
siehe <job process_class="…">
2.4.4 Monitor-Script
Die zu einem Job gehörenden Monitor-Scripte werden ebenfalls am Agenten ausgeführt. So gibt z.B. dieses
Testscript den Rechnernamen des Agenten aus.
function spooler_process_before() {
spooler_log.info("host:tcp_port:" + spooler.tcp_port);
var localhost = new java.net.InetAddress.getLocalHost();
hostname = localhost.getHostName();
ip = localhost.getHostAddress();
spooler_log.info("==>" + hostname + ":::"+ ip);
return true;
}
2.4.5 Kontext der API-Aufrufe
Alle API-Aufrufe beziehen sich auf den lokalen, aufrufenden JobScheduler. Allerdings liefern einige Methoden
Werte des Agenten und nicht des aufrufenden JobSchedulers zurück:
August 2014
Jobs
•
•
•
•
156
Spooler.directory
Spooler.log_dir
Spooler.ini_path
Spooler.include_path
2.4.6 Konfigurations-Dateien>
Alle Einstellungen werden beim lokalen, aufrufenden JobScheduler gelesen.
Einige Einstellungen werden vom Agenten statt vom lokalen, aufrufenden JobScheduler übernommen:
•
•
•
•
•
sos.ini (Abschnitt [java], Eintrag javac=…)
factory.ini (Abschnitt [spooler], Eintrag tmp=…)
2.4.7 Protokolldateien
Protokollausgaben werden in die Dateien des lokalen, aufrufenden JobSchedulers geschrieben. Das betrifft sowohl
das Auftragsprotokoll als auch das Task-Protokoll. Ausgaben nach stdout und stderr werden in die
Protokolldateien des lokalen, aufrufenden JobSchedulers übernommen. Andere Protokollausgaben, die der
JobScheduler protokolliert, werden in die Protokolldatei des Agenten geschrieben.
August 2014
Auftragssteuerung und Dateiverarbeitung
157
3 Auftragssteuerung und Dateiverarbeitung
3.1 Aufträge und Job-Ketten
Ein Auftrag ist die Anweisung eine Job-Kette eine Reihe von Jobs auszuführen. Ein Auftrag kann sofort ausgeführt
werden oder zu einem konfigurierbaren Ereignis, z.B. zu bestimmten Terminen, Wochentagen etc. oder bei
Eintreffen von Dateien in einem Verzeichnis.
Eine Job-Kette ist wie ein Fließband, durch das die Aufträge laufen, die von einzelnen Maschinen, den Jobs,
nacheinander verarbeitet werden. Zur Verarbeitung eines Auftrags führt ein Job genau einen Schritt aus. Dabei
ändert sich der Zustand des Auftrags, der über die nächste Stelle in der Job-Kette entscheidet, bis das Ende der
Job-Kette erreicht ist.
Innerhalb der Job-Kette hat ein Auftrag eine Kennung, die ihn identifiziert sowie einen lesbaren Titel. Er hat einen
Zustand, der sich nach jeder Verarbeitung durch einen Job ändert. Ein Auftrag kann Parameter beinhalten, die an
alle Jobs einer Job-Kette weitergegeben werden und er kann eine Nutzlast tragen, d.h. ein individuelles XML
Dokument, das er den Jobs zur Verfügung stellt.
Aufträge ermöglichen die Wiederverwendbarkeit von Jobs und Job-Ketten: Einer Job-Kette kann exakt ein Auftrag
zugeordnet sein und den Zeitpunkt von deren Ausführung definieren. Diese Konfiguration wird häufig verwendet,
wenn jeder Job nur in einer einzigen Job-Kette auftritt und die Parametrisierung pro Job erfolgt.
Es können allerdings auch mehrere Aufträge für dieselbe Job-Kette konfiguriert werden, in diesem Fall können den
Aufträgen unterschiedliche Parameter mitgegeben werden, die an die Jobs durchgereicht werden, so dass
dieselben Jobs für unterschiedliche Zwecke eingesetzt werden können.
Siehe die Klasse Order .
Aufträge können per TCP mit dem Kommando <add_order> übergeben werden.
Darüber hinaus bietet die HTML-Oberfläche (Seite 174) des JobSchedulers Operationen zum manuellen Starten
von Aufträgen.
3.1.1 Job-Ketten
Job-Ketten definieren eine Abfolge von Jobs, deren Ausführung durch einen Auftrag ausgelöst wird. Sie definieren
Job-Abhängigkeiten für die erfolgreiche und fehlerhafte Ausführung von Jobs. Sie sind wiederanlauffähig, d.h. der
JobScheduler speichert den Zustand eines Auftrags innerhalb einer Job-Kette persistent in einer Datenbank und
restauriert einen Auftrag nach dem Wiederanlaufen innerhalb der Job-Kette für den Job, an dem die Verarbeitung
abgebrochen wurde.
Die Job-Ketten sind bei den Klassen Job_chain und Job_chain_node beschrieben.
Siehe auch <job_chains> (Seite 47).
Zur Verwendung innerhalb von Job-Ketten müssen Jobs mit <job order="yes"> definiert sein. Andernfalls sind
sie als standalone Jobs separat aufrufbar.
August 2014
158
3.1.2 Auftragswarteschlange und Tasks
Jeder auftragsgesteuerte Job hat eine Auftragswarteschlange, die die Aufträge aufnimmt, die der Job verarbeiten
soll. Sobald ein Auftrag in der Warteschlange ist und die <run_time> dies zulässt, startet der JobScheduler eine
Task. Wenn mehrere Aufträge in der Warteschlange sind und der Job mehrere Tasks erlaubt ( <job tasks="…"> ),
dann startet der JobScheduler mehrere Tasks.
Der JobScheduler übergibt einen Auftrag einer Task, indem er in Task.order den Auftrag ablegt und
spooler_process() aufruft. spooler_process() endet mit true oder false, was über die nächste Stelle in der
Job-Kette entscheidet (s. Job_chain ).
3.1.3 Verzeichnisüberwachung mit Dateiaufträgen
Zu Aufträgen, die aus Dateien eines Verzeichnisses entstehen, siehe Verzeichnisüberwachung mit Dateiaufträgen
(Seite 159).
3.1.4 Priorität
Aufträge mit höherer Priorität Order.priority stellt der JobScheduler an den Anfang der Warteschlange.
3.1.5 Wann enden die Tasks?
Wenn kein Auftrag mehr zu verarbeiten ist, lässt der JobScheduler die Tasks stehen, solange die <run_time> gilt.
Sie sind dann im Zustand running_waiting_for_order.
Mit <job idle_timeout="dauer"> können Sie eine Frist bestimmen, nach der der JobScheduler eine wartende
Task automatisch beendet. Diese Frist sollte auf z.B. 30 Sekunden eingestellt werden, um während der
Verarbeitungspausen Ressourcen freizugeben.
Wenn der JobScheduler für einen anderen Job eine Task starten will, die Prozessklasse aber erschöpft ist, die die
Anzahl gleichzeitig ablaufender Tasks festlegt, dann beendet er automatisch eine Task mit derselben
Prozessklasse, die im Zustand running_waiting_for_order ist.
Sie können eine Task mit Task.end() , <kill_task> und <modify_job cmd="end"> beenden.
Die Task endet, wenn spooler_process() nicht implementiert ist. Der Auftrag wird in den Folgezustand versetzt.
3.1.6 Beschleunigung des Auftragsdurchlaufs
Auftragsgesteuerte Jobs haben eine eigene Priorisierung. Die Einstellung <job priority="…"> kann hier nicht
verwendet werden, sie wirkt nicht.
Aufträge, die in der Job-Kette weiter fortgeschritten sind, sollen bevorzugt verarbeitet werden. Damit werden Staus
vermieden und die ersten Aufträge werden schneller abgeschlossen. Das erreicht der JobScheduler durch
Bevorzugung der Jobs, die weiter am Ende der Job-Kette stehen als andere. Die Maschinen am Ende des
Fließbands laufen flotter als die am Anfang.
Auftragsgesteuerte Jobs haben Vorrang vor nicht auftragsgesteuerten Jobs.
August 2014
159
3.1.7 Datenbank
Zur persistenten Speicherung der Auftragswarteschlangen und zur Auftragshistorie lesen Sie hier (Seite 130).
3.2 Verzeichnisüberwachung mit Dateiaufträgen
Wenn eine Job-Kette Dateien aus einem Verzeichnis verarbeiten soll, können Sie Dateiaufträge verwenden. Ein
Dateiauftrag ist ein Auftrag mit einem Verweis auf eine Datei. Der JobScheduler überwacht das Verzeichnis und
erzeugt zu jeder neuen Datei einen Dateiauftrag.
<job_chain name="my_job_chain">
<file_order_source directory="path"/>
<file_order_source directory="other_path" regex="regex"/>
<job_chain_node state="100" job="job_1 error_state="error"/>
<job_chain_node state="200" job="job_2 error_state="error"/>
<file_order_sink state="ok" remove="yes"/>
<file_order_sink state="error" move_to="/errorpath.../ "/>
</job_chain>
Siehe <job_chain> (Seite 42), <file_order_source> (Seite 30) und <file_order_sink> (Seite 29).
3.2.1 Dateiauftragsquelle
Eine Dateiauftragsquelle <file_order_source> überwacht ein Verzeichnis. Wenn diesem ein Dateiname
hinzugefügt wird, der dem optionalen Regulären Ausdruck entspricht, führt das zu einem Dateiauftrag.
<job_chain …>
<file_order_source directory="…" regex="…"/>
…
Ein Dateiauftrag ist ein Auftrag Order mit folgenden Eigenschaften:
Order.state
Status des Auftrags ist der des ersten Jobs der Job-Kette oder der mit <file_order_source
next_state="…"> eingestellte Zustand.
Order.id
Kennung des Auftrags ist der Pfad, zusammengesetzt aus Verzeichnisname, wie er in der Auftragsquelle
angegeben ist, und dem Dateinamen.
Order.params . Variable_set.value()
enthält den Pfad, derselbe Wert wie Order.id . Diese für den JobScheduler reservierte Variable macht
einen Auftrag zum Dateiauftrag.
3.2.1.1 Reihenfolge der Dateiaufträge
Die ältesten Dateien (die mit der am weitesten zurückliegenden letzten Änderung) werden zuerst berücksichtigt.
3.2.1.2 Mehrere Auftragsquellen
Eine Job-Kette kann mehrere Auftragsquellen haben. Der JobScheduler berücksichtigt sie in der angegebenen
Reihenfolge.
August 2014
160
3.2.2 Der Dateiauftrag überwacht die Datei
Der JobScheduler entfernt einen Dateiauftrag, wenn die dazugehörige Datei nicht mehr im Verzeichnis steht und
•
der Dateiauftrag noch nicht einem Job übergeben wurde
[warn]
•
File has been removed, so the file order is being removed too
SCHEDULER-982
der Dateiauftrag auf der Schwarzen Liste steht
[info]
SCHEDULER-981
File on blacklist has been removed
Dateiaufträge, die in Ausführung sind, sind nicht betroffen.
Dieser Abgleich wird durchgeführt,
•
•
wenn der JobScheduler das Verzeichnis liest,
wenn der JobScheduler den Dateiauftrag zum ersten Mal einem Job übergibt.
3.2.3 Auftragssenke: Datei verschieben oder entfernen
Am Ende der Ausführung des Auftrags kann die zugehörige Datei entfernt oder verschoben werden. Die mit <
file_order_sink> definierten Zustände sind Endzustände.
Wenn aber die Datei bereits entfernt worden ist, gibt der JobScheduler eine Warnung aus und der Dateiauftrag ist
erledigt.
[warn]
SCHEDULER-339
File does not exist and can therefore neither be moved nor removed:
Wenn die Datei sich nicht entfernen bzw. verschieben lässt, gelangt der Auftrag auf die Schwarze Liste.
3.2.3.1 Datei verschieben
<file_order_sink state="…" move_to="directory_path">
Eine Datei gleichen Namens im Zielverzeichnis wird ohne Warnung überschrieben.
3.2.3.2 Datei entfernen
<file_order_sink state="…" remove="yes">
3.2.4 Schwarze Liste
Wenn ein Dateiauftrag ausgeführt ist (einen Endzustand erreicht hat), aber die Datei noch vorhanden ist, dann
setzt der JobScheduler den Auftrag auf die Schwarze Liste.
[warn]
SCHEDULER-340
File still exists. Order has been set on the blacklist
Dort bleibt er bis
August 2014
•
der JobScheduler beim Lesen des Verzeichnisses feststellt, dass die Datei entfernt worden ist
[info]
•
161
SCHEDULER-981
File on blacklist has been removed
das Kommando <remove_order> ausgeführt wird.
Damit wird verhindert, dass die Datei sofort zu einem neuen Dateiauftrag führt.
3.2.5 Verzeichnis-Fehler
Wenn die Verzeichnisüberwachung auf einen Fehler läuft, zum Beispiel weil das Verzeichnis abgehängt worden ist,
dann gibt der JobScheduler eine Warnung aus und erzeugt eine eMail (die Einstellungen aus factory.ini
(Abschnitt [spooler]) gelten).
Der JobScheduler versucht periodisch die Überwachung erneut zu starten. Fehlermeldungen dabei werden
ignoriert. Die Periode ist einstellbar mit <file_order_source delay_after_error="…"> . Wenn das Verzeichnis
wieder lesbar ist, sendet der JobScheduler eine entsprechende eMail und gibt diese Meldung aus:
[info]
SCHEDULER-984
Recovered from previous error in directory
3.2.5.1 Fehler beim Erstellen des Dateiauftrags
Wenn ein Dateiname nicht zu einem Auftrag gemacht werden kann (weil der Pfad zu lang ist für die
Datenbankspalte ), dann merkt er sich den Pfad, um die Fehlermeldung nicht bei jedem Lesen des Verzeichnisses
zu wiederholen, und setzt fort nach der Meldung
[warn]
SCHEDULER-346
Due to previous error the path will be ignored:
3.2.6 Wann wird das Verzeichnis gelesen?
Sobald der erste Job zum ersten Mal bereit ist, einen Auftrag auszuführen, liest der JobScheduler das Verzeichnis
(mit der Beschränkung durch den Regulären Ausdruck) und erzeugt daraus Dateiaufträge.
Wenn das Verzeichnis viele Dateien enthält (mehr als mit <file_order_source max="…"> eingestellt), dann
verbleibt eine Liste der übrigen Dateien im Speicher, aus der der JobScheduler später die weiteren Dateiaufträge
erzeugt. Die Meldungen dazu sind:
[info]
SCHEDULER-985
number more file orders will be added later, after previous orders have been
processed
[info]
SCHEDULER-986
Continuing reading buffered directory (as of time)
Der JobScheduler liest das Verzeichnis erneut, wenn
•
•
•
alle Dateien dem ersten Job übergeben worden sind,
dieser für einen weiteren Auftrag bereit ist,
und die mit <file_order_source repeat="…"> einstellte Periode abgelaufen ist.
3.2.6.1 Verzeichnisüberwachung durch Microsoft® Windows®
Unter Windows lässt der JobScheduler außerdem das Verzeichnis vom Betriebssystem überwachen. Eine
Signalisierung veranlasst den Scheduler, das Verzeichnis vor Ablauf der Periode zu lesen. Damit reagiert der
JobScheduler sofort auf eine neue Datei.
August 2014
162
Trotzdem sollte für ein Verzeichnis auf einem anderen Rechner das Wiederholungsintervall nicht mit <
file_order_source repeat="no"> abgestellt werden. Die Windows-Verzeichnisüberwachung verstummt, wenn
das Verzeichnis entfernt und wieder angelegt wird. Siehe außerdem Microsofts Article 188321:
FindFirstChangeNotification May Not Notify All Processes on File Changes. Das Wiederholungsintervall erneuert
die Verzeichnisüberwachung periodisch.
3.2.7 Auftragsgesteuerte Nicht-API-Jobs (<process> und <script language="shell">)
Einen auftragsgesteuerten <process> -Job startet der JobScheduler für jeden Dateiauftrag.
Die Umgebungsvariable enthält den Dateipfad.
3.3 Verzeichnisüberwachung
Ein Job, der in einem Verzeichnis eintreffende Dateien verarbeitet, kann sich der Verzeichnisüberwachung
bedienen. Mit dem Aufruf Job.start_when_directory_changed() sorgt der JobScheduler dafür, dass eine Task
läuft, sobald sich das Verzeichnis ändert.
Sie können den Aufruf für mehrere Verzeichnisse wiederholen.
Der Aufruf kann im Scheduler-Skript (Element <script> in <config> ) oder im Job selbst (in spooler_init() )
untergebracht sein. Im letzten Fall muss der Job einmal laufen, damit der Aufruf auch ausgeführt wird (s. <
run_time once="yes"> ).
3.3.1 Was ist eine Änderung eines Verzeichnisses?
Wenn eine Datei oder ein Unterverzeichnis hinzugefügt, gelöscht oder umbenannt wird.
3.3.2 Mit Regulärem Ausdruck filtern
Der Methode Job.start_when_directory_changed() können Sie einen Regulären Ausdruck (nach POSIX
1003.2) übergeben. Der JobScheduler betrachtet dann das Verzeichnis nur als geändert, wenn es nach der
Änderung eine Datei oder ein Verzeichnis enthält, dessen Name zum Regulären Ausdruck passt.
3.3.3 Welches Verzeichnis hat sich geändert?
Wenn Sie mehrere Verzeichnisse überwachen, gibt der Aufruf Task.changed_directories() die Namen der
geänderten Verzeichnisse zurück, durch Semikolon getrennt.
3.3.4 Welche Dateien stehen im Verzeichnis?
Task.trigger_files liefert die aus Verzeichnis und Dateinamen zusammengesetzten Pfade, auf die der Reguläre
Ausdruck (wenn vorhanden) zutrifft.
Nicht-API-Jobs ( <process> und <script language="shell"> ) steht der Inhalt von Task.trigger_files in der
Umgebungsvariablen SCHEDULER_TASK_TRIGGER_FILES zur Verfügung.
August 2014
163
3.3.5 Fehler bei der Verzeichnisüberwachung
Wenn z.B. ein Verzeichnis nicht mehr zugreifbar ist (gelöscht oder nicht mehr erreichbar), gilt das als Änderung
und der JobScheduler startet eine Task.
Ein wiederholter Aufruf von Job.start_when_directory_changed() führt dann zu einem Fehler.
3.3.6 Beispiel
Konfiguration für einen Job, der alle Dateien in einem Verzeichnis verarbeitet und dann löscht (Vorsicht beim Test!
Der Job löscht wirklich!)
<?xml version="1.0"?>
<spooler>
<config>
<process_classes/>
<jobs>
<job name="import">
<script java_class="spooler_job.Import"><![CDATA[
package spooler_job;
import java.io.File;
import sos.spooler.*;
public class Import extends sos.spooler.Job_impl
{
String[] paths;
int
index;
public boolean spooler_open()
{
spooler_log.info( "changed_directories=" +
spooler_task.changed_directories() );
spooler_log.info( "trigger_files=" +
spooler_task.trigger_files() );
paths = spooler_task.trigger_files().split( ";" );
index = 0;
return index < paths.length;
}
public boolean spooler_process()
{
File file = new File( paths[ index++ ] );
spooler_log.info( "Processing file " + file );
file.delete();
return index < paths.length;
}
}
]]></script>
August 2014
164
</job>
</jobs>
</config>
</spooler>
3.4 Verteilte Aufträge
3.4.1 Load Balancing mit verteilten Aufträgen
Ein JobScheduler Cluster kann verwendet werden, um Aufträge auf mehreren Hosts zu verarbeiten. Dies kann zum
Load Balancing genutzt werden, um Verarbeitungszeiten durch einsatz weiterer Hardware zu minimieren.
In einem Cluster zeigen alle JobScheduler ihre Verfügbarkeit durch das Versenden von Herzschlägen an. Alle
JobScheduler prüfen, ob die jeweils anderen JobScheduler verfügbar sind. Stellt ein JobScheduler fest, dass vom
anderen JobScheduler die Herzschläge über einen längeren Zeitraum (ca. 1-2 Minuten) ausbleiben, so übernimmt
dieser die Verarbeitung der angefangenen Aufträge.
Die Voraussetzungen für die Operation eines JobScheduler Clusters für verteilte Aufträge sind schematisch in der
folgende Zeichnung abgebildet, und werden im Detail in den nächsten Abschnitt beschreiben.
August 2014
165
Verteilte Aufträge können während ihres Weges durch die Job-Kette von verschiedenen JobSchedulern verarbeitet
werden. Die Übernahme der Verarbeitung eines Auftrags in einem anderen Job-Knoten durch einen anderen
JobScheduler ist schematisch in der folgende Zeichnung abgebildet:
August 2014
166
3.4.1.1 Voraussetzungen für Verteilte Aufträge
•
•
•
•
•
Alle JobScheduler des Clusters verwenden die selbe Datenbank. Es werden die Datenbanksysteme Oracle,
DB2, MySQL und Postgres unterstützt.
Alle JobScheduler verwenden die selbe Konfigurationsdatei bzw. eine genaue Kopie.
Alle JobScheduler werden mit der gleichen Scheduler-ID gestartet.
Alle JobScheduler werden mit der Option -distributed-orders gestartet.
Alle JobScheduler haben Zugriff auf Resourcen, die von den Jobs der verteilten Job-Kette benötigt werden
(z.B. überwachte Verzeichnisse). Gemeinsam genutzte Verzeichnisse sind auf allen Systemen auf den
gleichen Pfad gemountet (oder verlinkt).
August 2014
167
3.4.1.2 Starten des JobScheduler Clusters für verteilte Aufträge
Die JobScheduler, die den Cluster bilden, werden in beliebiger Reihenfolge gestartet. Es können während der
Laufzeit beliebig JobScheduler entfernt oder hinzugefügt werden. Beim entfernen von JobScheduler Instanzen,
sollten diese, wenn möglich, normal beendet (Terminate) werden, damit sie die Möglichkeit haben, Aufträge zu
beenden, die gerade verarbeitet werden.
3.4.1.3 Erzeugen verteilter Aufträge
Verteilte Aufträge können entweder per <add_order> Befehl oder per Verzeichnisüberwachung erzeugt werden.
3.4.1.4 Verteilte Aufträge durch add_order
Es kann entweder das XML-Kommando <add_order> oder die API-Funktion Job_chain.add_order() verwendet
werden. Es ist dabei egal an welchen JobScheduler das Kommando geschickt wird beziehungsweise auf welchem
JobScheduler der Befehl ausgeführt wird. Der Auftrag wird dem gesamten Cluster zur Verarbeitung bereitgestellt.
3.4.1.5 Verteilte Dateiaufträge
Verteilte Dateiaufträge werden per <file_order_source> in einer verteilten Job-Kette konfiguriert. Jeder
JobScheduler des Clusters überwacht das Verzeichnis und kann Dateiaufträge erstellen. Ein Dateiauftrag wird
nicht notwendigerweise von dem JobScheduler verarbeitet, der ihn erstellt hat.
3.4.1.6 Standalone-Jobs in verteilten Schedulern
Eigenständige Jobs, die keine Aufträge verarbeiten, werden in einem JobScheduler Cluster von dem JobScheduler
ausgeführt, in dem sie konfiguriert werden.
3.4.1.7 Verteilungsalgorithmen
Die Art der Verteilung kann durch das Setzen des globalen Parameters scheduler.order.distributed.balanced
eingestellt werden:
•
Verteilung bei Überlast:
Ein JobScheduler übernimmt die Ausführung eines verteilten Auftrages erst dann, wenn der derzeit
ausführende JobScheduler ausgelastet ist, d.h. wenn die Anzahl der zugelassenen Prozesse erreicht ist. Das
ist das Standardverhalten des JobSchedulers.
siehe auch <job tasks="…"> (Seite 37) und <process_class attribute_max_processes="…"> (Seite 59).
•
Gleichmässige Verteilung:
Die Taks verteilter Aufträge werden gleichmässig auf die JobScheduler des Clusters verteilt.
August 2014
Protokolle und eMail-Versand
168
4 Protokolle und eMail-Versand
4.1 Protokolle
Der JobScheduler schreibt seine Protokolle in das mit der Option -log-dir eingestellte Verzeichnis.
Die Meldungen sind numeriert, siehe »Meldungen des Schedulers« (Seite 226).
Hauptprotokoll
Das Hauptprotokoll fast alle Protokolle zusammen. Der Dateiname wird aus Scheduler-Id, Datum und Uhrzeit
gebildet, z.B. scheduler-2004-08-24-104111.log.
Jobprotokolle
Für jeden Job erstellt der JobScheduler ein Jobprotokoll mit den Starts der Tasks und eingetroffenen Aufträgen.
Beispiel: job.mein_job.log
Zeichen im Jobnamen, die nicht im Dateinamen verwendet werden können, tauscht der JobScheduler gegen "_".
Taskprotokolle
Für jeden Task erstellt der JobScheduler ein Taskprotokoll. Der Dateiname wird aus dem Jobnamen und, wenn
mehrere Tasks zugelassen sind, der Task-Id gebildet, z.B.: task.mein_job.log und task.ein_job.1234.log.
Taskprotokolle mit Task-Id werden nach Ende der Task gelöscht.
Auftragsprotokolle
Für jeden Auftrag erstellt der JobScheduler ein Auftragsprotokoll mit den Ausgaben aller Tasks, die der Auftrag
durchläuft. Der Dateiname wird aus der Job-Kette und der Auftrags-Id gebildet, z.B.:
order.meine_Job-Kette.9876.log. Das Auftragsprotokoll wird nach Ende des Auftrags gelöscht.
scheduler.log
Zur Fehlerdiagnose kann der JobScheduler das scheduler.log schreiben. In factory.ini (Abschnitt [spooler],
Eintrag log= …) stellen sie den Dateinamen ein. In dieser Dokumentation steht factory.ini für den hier
eingestellten Dateinamen.
Hier die Liste der Log-Kategorien (Seite 171).
4.1.1 Umfang
Mit -log-level und Log.level kann die Stufe (error, warn, info, debug bis debug9) eingestellt werden, ab der
Protokollzeilen gelten.
4.1.2 Meldungs-Codes
Die Meldungen sind mit Codes versehen, z.B. SCHEDULER-900. Hier ist eine Liste der Meldungs-Codes (Seite 226)
des Schedulers.
August 2014
169
4.1.3 Plattenplatzmangel
Wenn nicht genug Plattenplatz beim Öffnen einer Protokolldatei vorhanden ist, gibt es einen Fehler. Wenn das
Hauptprotokoll nicht geöffnet werden kann, bricht der JobScheduler ab.
Wenn nicht genug Plattenplatz vorhanden ist, um ein Protokoll fortzuschreiben, hält der JobScheduler an. Er
reagiert auf über TCP, UDP oder HTTP übergebene Kommandos.
Das Kommando <modify_spooler> wirkt nur eingeschränkt.
Wenn wieder Plattenplatz bereit steht, können Sie den JobScheduler fortsetzen mit <modify_scheduler
cmd="continue"/>.
Die Datei scheduler.log ist von diesem Verfahren nicht betroffen. Fehler werden hier ignoriert.
4.1.4 Ablage in den Datenbank
Der JobScheduler kann die Task- und Auftragsprotokolle mit in die Historie schreiben. Voraussetzung sind
•
•
•
•
•
Betrieb mit einer Datenbank (Seite 130),
die Einstellung factory.ini (Abschnitt [spooler], Eintrag history= …)), um die Historie einzuschalten,
die Einstellung factory.ini (Abschnitt [spooler], Eintrag history_with_log= …) fürs Task-Protokoll,
die Einstellung factory.ini (Abschnitt [job], Eintrag history_with_log= …) für bestimmte Jobs,
die Einstellung factory.ini (Abschnitt [spooler], Eintrag order_history_with_log= …) fürs
Auftragsprotokoll.
4.1.5 Programmschnittstelle
Die Klasse Log beschreibt die Protokolle und erlaubt verschiedene Einstellungen.
4.1.6 eMail-Versand
Der JobScheduler kann das Task-Protokoll per eMail verschicken. Lesen Sie weiter im Kapitel eMail (Seite 169).
4.1.7 Anzeigen der Protokolle
Siehe Kommandos <show_state> (Seite 202), <show_task> (Seite 203) und <show_history> (Seite 199).
Mit einem Browser können Sie den eingebauten HTTP-Server (Seite 174) ansprechen und sich ein Protokoll
fortlaufend anzeigen lassen.
4.2 eMail-Versand
4.2.1 Einstellungen zur eMail
Die Einstellungen für eine eMail können Sie hier vornehmen: factory.ini (Abschnitt [spooler], Eintrag smtp= …
)
August 2014
170
factory.ini (Abschnitt [spooler], Eintrag log_mail_subject= …)
factory.ini (Abschnitt [spooler], Eintrag log_mail_from= …)
factory.ini (Abschnitt [spooler], Eintrag log_mail_to= …)
factory.ini (Abschnitt [spooler], Eintrag log_mail_cc= …)
factory.ini (Abschnitt [spooler], Eintrag log_mail_bcc= …)
Oder wenn Sie besondere Einstellungen für einen bestimmten Job vornehmen wollen: factory.ini (Abschnitt
[job], Eintrag log_mail_subject= …)
factory.ini (Abschnitt [job], Eintrag log_mail_from= …)
factory.ini (Abschnitt [job], Eintrag log_mail_to= …)
factory.ini (Abschnitt [job], Eintrag log_mail_cc= …)
factory.ini (Abschnitt [job], Eintrag log_mail_bcc= …)
Oder an der Programmschnittstelle:
spooler_log stellt mit Log.mail das Objekt Mail bereit, über dessen Methoden Sie Absender, Empfänger, Betreff
usw. einstellen können.
Beispiel (in Java)
spooler_log.mail().set_to( "[email protected]" );
4.2.2 eMails nach dem Ende einer Task
Wenn eine Task endet, kann der JobScheduler eine eMail mit dem Task-Protokoll verschicken.
Ob nach Ende einer Task das Protokoll verschickt werden soll, bestimmen Sie mit diesen Einstellungen:
factory.ini (Abschnitt [spooler], Eintrag mail_on_success= …)
factory.ini (Abschnitt [spooler], Eintrag mail_on_process= …)
factory.ini (Abschnitt [spooler], Eintrag mail_on_error= …)
Und speziell für einen Job: factory.ini (Abschnitt [job], Eintrag mail_on_success= …)
factory.ini (Abschnitt [job], Eintrag mail_on_process= …)
factory.ini (Abschnitt [job], Eintrag mail_on_error= …)
Oder an der Programmschnittstelle:
Mit dem Aufruf Log.mail_it können Sie einstellen, ob der JobScheduler beim Ende der Task das Protokoll sendet.
4.2.3 Rangfolge der Einstellungen
1.
2.
3.
4.
Das Job-Skript kann Einstellungen mit der Klasse Mail vornehmen.
Im Fehlerfall setzt der JobScheduler den Betreff, überschreibt also die Einstellung Mail.log_mail_subject
des Jobs.
Das eMail-XSLT-Stylesheet ( <config mail_xslt_stylesheet="…"> ), kann die Einstellungen ändern.
Leere Einstellungen werden mit den Angaben aus
August 2014
171
factory.ini (Abschnitt [job]) und
factory.ini (Abschnitt [spooler]) gefüllt.
4.2.4 eMails, wenn der JobScheduler wegen eines Fehlers sich beendet
Für diese eMails werden die Einstellungen im Abschnit [spooler] der Datei factory.ini verwendet.
Wenn ein Fehler auftritt, bevor die Option -ini berücksichtigt werden konnte, verwendet der JobScheduler die
Einstellungen aus der Datei factory.ini mit unverändertem Namen.
Wenn der JobScheduler als Dienst oder Daemon läuft und ein Fehler auftritt, der so ernst ist, dass der
JobScheduler abbrechen muss, verschickt er eine eMail mit der Fehlermeldung.
Wenn ein Datenbankfehler auftritt, verschickt der JobScheduler eine eMail. Fehler, die bei den Versuchen
auftreten, die Datenbank erneut zu öffnen, führen nicht zu einer eMail.
Wenn der JobScheduler nach einem Fehler den Datenbankbetrieb aufgibt, schickt er eine eMail.
4.2.5 Installation mit JavaMail
Für den eMail-Versand mit JavaMail werden folgende Dateien im class_path benötigt.
sos.mail.jar
(wird mit dem JobScheduler geliefert)
mail.jar
(Sun Microsystems, Inc.)
smtp.jar
activation.jar
Siehe sos.ini (Abschnitt [java], Eintrag class_path= …).
4.3 Log Categories
Kategorie
Default¹
all
All categories (with exception of explicit categories)
com
COM-Operations
com.invoke
Calling a COM object method
env
Environment variables
exception
Particular error codes
exception.*
default
All error codes
exception.D310
nur explizit
End of file
exception.D311
nur explizit
Expression not found
factory
DocumentFactory
factory.parameter
factory.processor
Factory Processor (hostole.dll)
August 2014
Kategorie
172
Default¹
file
file.directory
file.mmap
mmap()
hostole
HostOLE calls (with exception of the factory
processor)
ini
Windows call GetPrivateProfile()
Read the .ini file: GetPrivateProfile().
java
Java
jdbc
JDBC Calls
mail
mutex
nur explizit
Mutual exclusion locks, blocking for thread
serialisation
object_server
JobScheduler interface for tasks running in their
own processes
object_server.call
Method Call
object_server.continue
object_server.Invoke
COM operation
object_server.push
Stack-Operation for nested method calls
object_server.QueryInterface
COM operation
object_server.wait
odbc
ODBC calls
rtf
RTF Processor
rtf.learn
Learned (unknown) RTF codes
rtf.map_next_line
Positions of script line numbers found in RTF
documents
rtf.merge
Merge different templates
scheduler
implizit an
JobScheduler
scheduler.call
implizit an
Start and end call of a job method, e.g.
spooler_process()
scheduler.cluster
Cluster operation
scheduler.directory
Open a directory
scheduler.file_order
<file_order_source>
scheduler.http
HTTP server
scheduler.log
Access to protocol files
scheduler.nothing_done
When a job is idle
scheduler.order
implizit an
Operations on orders (temporary payload setting)
scheduler.service
implizit an
Windows service controller
August 2014
Kategorie
173
Default¹
scheduler.signal
scheduler.wait
The JobScheduler enters the waiting state
scheduler.xml
XML/DOM operations
socket
Socket operations (network)
socket.accept
System call accept(): accept TCP connections
socket.close
System call close(): close socket
socket.connect
System call connect(): establish TCP connection
socket.data
nur explizit
Data from recv() and send()
socket.listen
System call listen(): waiting for TCP connection
request (listening)
socket.recv
System call send(): receive file
socket.select
System call select(): waiting for TCP result
socket.send
System call send(): send file
socket.setsockopt
System call setsockopt()
socket.shutdown
System call shutdown(): end connection
sossql
SQL-Processor (file type sossql)
sossql.get_key
Operation get_key()
spidermonkey
The Spidermonkey JavaScript implementation
spidermonkey.callback
nur explizit
Spidermonkey call backs
spidermonkey.idispatch
nur explizit
COM object management
windows
Betriebssystem Microsoft Windows
windows.PeekMessage
Aufruf PeekMessage()
Many of the entries made in the log file (scheduler.log) are categorised. These categories are used to regulate
whether or not an entry is made in a log file.
A log category is specified in front of the file name, with a ">" symbol inserted between the category and the file
name. Multiple categories are separated by an empty space. For example (in an .ini file): log = scheduler.*
socket.* >c:/tmp/scheduler.log.
The special category all selects all categories other than those which must be explicitly selected.
Log file categories are organised in hierarchies. Categories can be selected together with their subcategories by
appending an asterisk (".*") to the category name thus: scheduler.*.
See also the commands:
August 2014
Kommunikation und Bedienung
174
5 Kommunikation und Bedienung
5.1 HTTP Server und Web Services
5.1.1 Web Services
Der JobScheduler kann die Ausführung von Jobs und Job-Ketten als Web Services kapseln. Dazu nimmt der
JobScheduler über den eingebauten HTTP-Server SOAP Anfragen entgegen.
Mit <web_service> können Web Services eingerichtet werden.
Verwendung und Beispiele zur Konfiguration sind in der Dokumentation »Web Service Tutorial« beschrieben.
5.1.2 Bedienung über einen Browser
Der JobScheduler verfügt über einen HTTP Server und stellt HTML-Seiten zu seiner Bedienung bereit. Sie können
den JobScheduler über einen Browser (Microsoft Internet Explorer und Firefox) steuern. Geben Sie z.B. die
Adresse http://localhost:4444 ein. localhost kann auch ein anderer Rechnername sein, und 4444 ist die
konfigurierte TCP-Portnummer des JobSchedulers.
Siehe <config tcp_port="…"> (Seite 20).
Siehe factory.ini (Abschnitt [spooler], Eintrag html_dir= …) (Seite 89).
The user interface is described in the "Built-In User Interface" section of this chapter (below).
5.1.3 Zugriffsschutz
Der JobScheduler lässt nur TCP- und HTTP-Verbindung zu von Rechnern, die mit <allowed_host> die Erlaubnis
bekommen haben.
Darüber hinaus kann HTTP-Authentifizierung mit dem Element <http.authentication> vereinbart werden.
5.1.4 Protokolle mit einem Browser zeigen
Während der JobScheduler ein Protokoll schreibt, können Sie es sich anzeigen lassen. Sie sehen stets den
neuesten Stand.
Die HTML-Oberfläche des JobSchedulers bietet hierfür die entsprechenden Operationen an. Der JobScheduler
verwendet folgende URLs für Protokolle:
Hauptprotokoll
http://localhost:4444/show_log?
Jobprotokoll
http://localhost:4444/show_log?job=jobname
Taskprotokoll
http://localhost:4444/show_log?task=task_id
Auftragsprotokoll
http://localhost:4444/show_log?job_chain=Job-Kette&order=
order_id
August 2014
175
localhost ist localhost oder 127.0.0.1 oder der Name des Rechners, auf dem der JobScheduler abläuft.
5.1.5 Job-Beschreibung
Die Job-Beschreibung aus <description> kann mit diesem URL abgerufen werden:
http://localhost:4444/job_description?job=job
Die Beschreibung wird in HTML codiert erwartet.
5.1.6 Built-In Graphical User Interface
The JobScheduler can be operated using its own, built-in, web-based graphical user interface (GUI). Instructions
for accessing this interface were provided in the "Operation with a Browser (Seite 174)" section of this chapter
(above).
This interface is automatically installed and updated with the JobScheduler installation package.
The JobScheduler GUI is configured in the custom.js file, which is to be found in the JobScheduler
installation directory\config\html directory
This interface is intended for the operation of the JobScheduler - i.e. starting, monitoring and stopping the
JobScheduler itself, jobs & job chains, orders, and any locks and JobSchedulers operating in a cluster.
This interface should not be confused with the JobScheduler Editor (Seite 109), which is a GUI used to configure
the JobScheduler itself, jobs & job chains, orders using XML.
The JobScheduler GUI should also not be confused with the Managed Jobs Administration interface, which is a
part of the JobScheduler Managed Jobs package. The Managed Jobs Administration interface is a GUI for the
creation and monitoring jobs, job chains & orders and comes with a user administration. Further information about
the Managed Jobs Administration interface can be found in the »Managed Jobs Documentation«.
When first opened, the JobScheduler GUI appears as shown in the screenshot below and comprises three areas:
•
•
•
An upper menu bar, where the general configuration of the interface (language & update) is carried out; any
monitoring functions the JobScheduler is to carry out are shown and the configuration of the JobScheduler
itself in the XML configuration file (Seite 7) is shown.
Note that here the XML configuration file is shown "read-only" - to change the configuration, the JobScheduler
Editor (Seite 109) or an alternative XML editor should be used which has access to the JobScheduler
installation directory.
A central menu and status bar, providing access to the most important JobScheduler menus and status
information about the operation of the JobScheduler.
The "Update periodically" checkbox and the "Update" button are used to update the information shown in the
web interface either at regular intervals (when the checkbox is selected) or manually, as required (using the
button). The interval with which the regular updates of the interface are carried out is set using the Settings
dialog, which is accessed via the "Extras" button.
A working area initially showing a list of the jobs configured for the JobScheduler, which can be used to
provide information about other aspects of the JobScheduler operation such as the job chains, process
classes and locks by selecting the appropriately named menu tabs. Note that, should, for example, no locks
be configured then the "Locks" menu tab will not be shown.
August 2014
176
The main menu for the operation of the JobScheduler is shown in the next screenshot:
Detailed information about the state of one of the jobs listed in the main working area of the interface can be
obtained by clicking on the name of the job. This causes the right hand part of this area to divide and additional
areas showing status information about the job, about the task and about the taks queue to be displayed as can be
seen in the screen shot below:
The job status area also contains a menu providing the main commands necessary for controlling the job as shown
in the next screen shot:
August 2014
177
The "Show description" item in the menu opens a new browser window containing the job description. Job
descriptions such as the one shown below can be written with the Job Editor. This editor combines documentation
of the job, its configuration and a generate function, where the job can be newly generated after changes to its
configuration have been made. It is so integrated in the JobScheduler installation that the JobScheduler
automatically takes account of changes in a job configuration without having to be restarted.
The documentation for the Job Editor can be read in the Job Documentation Editor tutorial.
Information about tasks carrying out a job is shown in the task area of the interface as shown in the next screen
shot:
A task menu is provided as shown in the following screen shot:
August 2014
178
Information about any errors occuring in the execution of a job is shown in the interface job area:
If the JobScheduler is part of a JobScheduler cluster, providing backup, monitoriung and fail-over features, a
corresponding "Cluster" menu tab will be shown in the main working area of the interface. As can be seen in the
next screen shot, a button is provided to a menu for configuring cluster related aspects of the JobScheduler
operation:
The principles for using the JobScheduler GUI and which have been described in conjunction with the features
shown in the preceeding screen shots are followed for the aspects of the interface which have not been shown in
the screen shots. This means, for example, that use of the job chain part of the interface should follow intuitively.
Detailed information about the configuration and operation of the JobScheduler can be found in the following
sections of this documentation:
August 2014
•
•
•
•
•
179
The XML Configuration (Seite 7) of the JobScheduler.
Jobs and Job Chains (Seite 144).
Orders (Seite 157).
Log files and errors (Seite 168).
Error messages (Seite 226).
5.2 XML-Kommandos
Die Kommandos können über TCP (z.B. telnet), über HTTP und über die Kommandozeilenoptionen -cmd und
-send-cmd gegeben werden.
Kommando
Antwort (eingepackt in <spooler><answer>)
<add_jobs>
<ok>
<add_order>
<ok> <order>
<job.why>
<job>
<job_chain.modify>
<ok>
<job_chain_node.modify>
<ok>
<kill_task>
<ok>
<licence.use>
<ok>
<lock>
<ok>
<lock.remove>
<ok>
<modify_hot_folder>
<ok>
<modify_job>
<ok>
<modify_order>
<ok>
<modify_spooler>
<ok>
<param>
<ok>
<param.get>
<param>
<params>
<ok>
<params.get>
<params>
<process_class>
<ok>
<process_class.remove>
<ok>
<remove_job_chain>
<ok>
<remove_order>
<ok>
<schedule.remove>
<ok>
<scheduler_log.log_categories.reset>
<ok>
<scheduler_log.log_categories.set>
<ok>
<scheduler_log.log_categories.show>
<log_categories>
<show_calendar>
<calendar>
<show_history>
<history>
August 2014
180
Kommando
Antwort (eingepackt in <spooler><answer>)
<show_job>
<job>
<show_job_chain>
<job_chain>
<show_job_chains>
<job_chains>
<show_jobs>
<jobs>
<show_order>
<order>
<show_state>
<state>
<show_task>
<task>
<start_job>
<ok> <task>
<terminate>
<ok>
XML-Elemente
XML-Element <add_jobs>
<add_jobs >
job
</add_jobs>
Die Jobs werden mit temporary="yes" hinzugefügt und gestartet. Jeder Job wird gelöscht, sobald er endet.
Die Jobnamen müssen eindeutig sein.
Eltern Elemente
<commands> -
XML-Element <add_order>
<add_order
job_chain
id
replace
priority
title
state
web_service
at
end_state
= "name"
= "id"
= "yes|no"
= "zahl"
= "text"
= "text"
= "name"
= "timestamp"
= "text"
Startzeit des Auftrags
Zustand, vor dessen erfolgreichen Verlassen
der Auftrag enden soll
>
params
run_time
xml_payload
</add_order>
Parameter
XML-Nutzlast
Fügt einen neuen Auftrag hinzu.
August 2014
181
Wenn Sie das Element <params> angegeben, erstellt der JobScheduler ein Variable_set und stellt es dem Job in
Order.payload() zur Verfügung.
Beispiel:
<add_order job_chain="jobkette" id="1234" title="Mein erster Auftrag" state="100"
at="now+3:00">
<params>
<param name="ein_parameter" value="ein Wert"/>
</params>
</add_order>
Eltern Elemente
<commands> Attribute
job_chain="name"
Die Jobkette, in die der Auftrag eingetragen werden soll.
id="id"
replace="yes|no" (Initialwert:yes)
replace="no": Job_chain.add_order() wird gerufen.
replace="yes": Job_chain.add_or_replace_order() wird gerufen.
priority="zahl"
title="text"
Der Titel des Auftrags.
state="text"
web_service="name"
Wenn der Auftrag ausgeführt worden ist (das Ende der Jobkette erreicht hat), wird er mit einem Stylesheet
transformiert und einem Web-Dienst übergeben.
at="timestamp" (Initialwert:now) Startzeit des Auftrags
Siehe auch Order.at .
August 2014
182
XML-Element <check_folders>
<check_folders > </check_folders>
Prüft die Konfigurationsverzeichnisse auf Änderung und aktualisiert die Objekte im JobScheduler. Unter Windows
werden Änderungen in Konfigurationsverzeichnissen sofort erkannt, unter Unix wird dies innerhalb von max. 60s
erkannt.
Das Kommando ist in der HTML-Oberfläche des JobSchedulers verfügbar und wird bspw. eingesetzt, um während
der Entwicklung von Jobs unter Unix die Wartezeit zu verkürzen bis eine Änderung im Konfigurationsverzeichnis
wirkt.
Beispiel:
<check_folders/>
Eltern Elemente
<commands> -
XML-Element <job.why>
<job.why
job
> </job.why>
= "job_name"
Dieses Kommando ermittelt mögliche Ursachen dafür, warum ein Job nicht anläuft. Da diese nicht nur auf den Job
selbst zurück zu führen sind, sondern evtl. auch auf Objekte, die mit dem Job in Zusammenhang stehen
(Jobketten, Aufträge etc.), liefert diese Kommando i.d.R. eine Struktur von XML Elementen, die auf den Job
referenzieren. Allen Elementen ist gemeinsam, dass sie in einem oder mehreren obstacle Elementen münden
müssen, die - jedes für sich - einen Grund angeben, warum der Job nicht anläuft.
Beispiel:
<job.why job="mein_job" />
Eltern Elemente
job="job_name"
Der Jobname.
August 2014
183
XML-Element <job_chain.modify>
<job_chain.modify
job_chain
state
> </job_chain.modify>
= "name"
= "state"
Bestimmt die Jobkette
Beispiel:
<job_chain.modify job_chain="my_job_chain" state="stopped"/>
Eltern Elemente
job_chain="name" Bestimmt die Jobkette
state="state"
Für eine verteilte Jobkette nicht möglich.
Mögliche Angaben sind
Einzelne Jobkettenknoten können gestoppt werden mit <job_chain_node.modify action="stop"> .
Meldungen
[ERROR]
SCHEDULER-384
job_chain is distributed and therefore does not support operation '' [ERROR]
SCHEDULER-405
Setting state='' is not possible while job chain has state '' XML-Element <job_chain_node.modify>
<job_chain_node.modify
job_chain
state
action
> </job_chain_node.modify>
= "name"
= "state"
= "action"
Bestimmt die Jobkette
Bestimmt den Jobkettenknoten
Beispiel:
<job_chain_node.modify job_chain="my_job_chain" state="100" action="stop"/>
Eltern Elemente
job_chain="name" Bestimmt die Jobkette
August 2014
184
state="state" Bestimmt den Jobkettenknoten
action="action"
Für eine verteilte Jobkette nicht möglich.
Mögliche Angaben sind action="process", action="stop" und action="next_state", wie bei
Job_chain_node.action beschrieben.
Eine ganze Jobkette kann gestoppt werden mit <job_chain.modify state="stopped"> .
Meldungen
[info]
SCHEDULER-859
Due to action='next_state' the state '' has been skipped. Next state is '' XML-Element <kill_task>
<kill_task
job
id
immediately
> </kill_task>
= "job_name"
= "zahl"
= "yes|no"
Eine Nicht-API-Task ( <process> oder <script language="shell"> ) wird mitsamt ihren Kindprozessen
abgebrochen. Dazu ermittelt der JobScheduler alle Kindprozesse und bricht sie ab. Unter Unix wird außerdem wird
die Prozessgruppe des Task-Prozesses abgebrochen.
Beispiel:
<kill_task job="mein_job" id="4711"/>
Eltern Elemente
job="job_name"
Der Jobname.
id="zahl"
Die Task-Id. (Das Attribut sollte nicht id heißen, das Wort ist in XML reserviert.)
immediately="yes|no" (Initialwert:no)
XML-Element <licence.use>
<licence.use
key
= "licence_key"
Lizenzschlüssel
August 2014
185
> </licence.use>
Fügt einen Lizenzschlüssel hinzu.
Eltern Elemente
key="licence_key" Lizenzschlüssel
Der Lizenzschlüssel wird dem Lizenzschlüsselbund hinzugefügt.
Siehe auch sos.ini (Abschnitt [licence], Eintrag key1= …) (Seite 94).
XML-Element <lock>
<lock
name
max_non_exclusive
= "name"
= "integer"
Name der Sperre
Begrenzung der
Belegungen
nicht-exklusiven
> </lock>
Mit einer Sperre kann verhindert werden, dass zwei Tasks gleichzeitig laufen.
Siehe (Seite 152).
Zur Verwendung einer Sperre siehe <lock.use> (Seite 49)
Siehe auch <lock.remove> (Seite 186), Lock .
Beispiel:
<locks>
<lock name="switching_database"/>
<lock name="only_three_tasks" max_non_exclusive="3"/>
</locks>
Ergänzt ein Element <lock> an der entsprechenden Stelle aus der Basiskonfiguration. Hier angegebene Attribute
Eltern Elemente
<locks> Attribute
name="name" Name der Sperre
Siehe auch Lock.name .
August 2014
186
max_non_exclusive="integer" Begrenzung der nicht-exklusiven Belegungen
Die Voreinstellung ist unbegrenzt, es können also mit <lock.use exclusive="no"> beliebig viele nicht-exklusive
Tasks gestartet werden (aber nur eine exklusive).
Siehe auch Lock.max_non_exclusive .
Meldungen
[warn]
SCHEDULER-887
More lock holders than new max_non_exclusive=: holders XML-Element <lock.remove>
<lock.remove
lock
> </lock.remove>
= "path"
Name der Sperre
Entfernt eine Sperre.
Siehe auch <lock> (Seite 48).
Eltern Elemente
lock="path" Name der Sperre
Die Sperre kann nur gelöscht werden, wenn sie von keiner Task belegt und von keinem Job gebraucht ( <lock.use
> ) wird.
Siehe auch Lock.remove() .
XML-Element <modify_hot_folder>
<modify_hot_folder
folder
>
job
job_chain
lock
order
process_class
schedule
</modify_hot_folder>
= "path"
Prozessklasse
Das Kommando schreibt das Kind-Element in ein Konfigurationsverzeichnis. Der Dateiname wird nach den Regeln
für die dateibasierte Konfiguration gebildet (s. (Seite 78)).
Eine vorhandene Datei wird überschrieben.
Das Kind-Element (nur eins kann angegeben werden) muss das Attribut name= haben, oder bei einem Auftrag
job_chain= und id=.
August 2014
187
Eltern Elemente
folder="path" (Initialwert:/)
Gibt den Ordner an, in das das XML-Element geschrieben werden soll. Der JobScheduler legt das
Konfigurationsverzeichnis bei Bedarf an (einschließlich aller oberen Verzeichnisse, bis auf das Wurzelverzeichnis).
XML-Element <modify_job>
<modify_job
job
cmd
> </modify_job>
= "jobname"
= "cmd"
Beispiel:
<modify_job job="mein_job" cmd="wake"/>
Eltern Elemente
job="jobname"
Der Name des Jobs, für den das Kommando gilt.
cmd="cmd"
Folgende Subkommandos sind möglich:
XML-Element <modify_order>
<modify_order
job_chain
order
state
title
action
setback
priority
suspended
at
end_state
= "name"
= "id"
= "state"
= "title"
= "action"
= "no"
= "zahl"
= "yes|no"
= "timestamp"
= "text"
Zustand, vor dessen erfolgreichen Verlassen der
Auftrag enden soll
>
params
xml_payload
Parameter
XML-Nutzlast
August 2014
188
run_time
</modify_order>
Beispiel:
<modify_order job_chain="meine_jobkette" order="42" priority="1"/>
Eltern Elemente
job_chain="name"
Die Jobkette, in der sich der Auftrag befindet.
order="id"
state="state"
Ändert den Zustand des Auftrags und damit die Position in der Jobkette. Eine Rückstellung ( Order.setback() )
wird zurückgenommen.
Siehe auch Order.state
title="title"
Ändert Title des Auftrags
Siehe auch Order.title
action="action"
action="reset" setzt den Auftrag zurück: Der Auftrag wird in seinen ursprünglichen Zustand versetzt, er ist nicht
mehr suspendiert und auch setback ist zurückgenommen. Seine nächste Startzeit wird berechnet, als hätte der
Auftrag die Jobkette vollständig durchlaufen.
Die Operation ist nur möglich, wenn der Auftrag gerade nicht von einem Job ausgeführt wird.
Meldungen
[ERROR]
SCHEDULER-217
order is being processed by task setback="no"
Wirksam, nach der Auftrag mit Order.setback() zurückgestellt worden ist. Das Kommando beendet die mit <
delay_order_after_setback> eingestellte Verzögerung, so dass der Auftrag sofort ausgeführt werden kann. Der
Zähler, wie oft der Auftrag zurückgestellt worden ist, bleibt unverändert.
August 2014
189
Siehe auch Order.setback() und <delay_order_after_setback> (Seite 28).
priority="zahl"
suspended="yes|no"
Setzt den Auftrag aus oder setzt ihn fort, siehe Order.suspended .
at="timestamp"
Ändert den nächsten Startzeitpunkt eines wartendenen Auftrags,
•
•
dessen Order.run_time noch nicht erreicht ist, oder
der mit Order.setback() zurückgestellt worden ist.
at="now" setzt einen wegen Order.run_time oder Order.setback() wartenden Auftrag fort.
Siehe auch <add_order at="…"> (Seite 14) und Order.at .
XML-Element <modify_spooler>
<modify_spooler
cmd
timeout
> </modify_spooler>
= "cmd"
= "int"
Wenn der JobScheduler wegen Plattenplatzmangel für ein Protokoll angehalten hat ( <state waiting_errno="…"
> ), werden die Subkommandos pause, reload, terminate, terminate_and_restart,
let_run_terminate_and_restart nicht sofort ausgeführt. Dagegen wirken continue, abort_immediately und
abort_immediately_and_restart sofort.
Beispiel:
<modify_spooler cmd="abort_immediately_and_restart"/>
Eltern Elemente
cmd="cmd"
Folgende Subkommandos sind möglich:
timeout="int"
August 2014
190
Für cmd="terminate" und cmd="terminate_and_restart": Die Frist, nach der der JobScheduler nicht beendete
Prozesse abbrechen soll.
Voreingestellt ist eine endlose Frist.
Siehe Spooler.terminate() .
XML-Element <param>
<param
name
value
> </param>
= ""
= ""
Eindeutiger Name
Siehe <params> (Seite 54).
Bestimmt einen einzelnen Parameter für den Scheduler, einen Job oder einen Auftrag. Grundsätzlich sind alle
Parameter über die API Aufrufe Spooler.variables() , Task.params() bzw. Order.payload() oder in shell Jobs
als environment Variable (mit vorangestelltem SCHEDULER_PARAM_) verfügbar.
Gleichnamige Parameter in der JobScheduler Konfiguration, am Job und am Auftrag gelten in der folgenden
Reihenfolge:
•
Auftrag
•
Job
•
Scheduler
Es wird empfohlen keine eigenen Parameter einzustellen, die mit der Zeichenfolge scheduler. beginnen, da dieser
Namensraum für Konfigurationseinstellungen des JobScheduler reserviert ist.
Die Parameter können zur Laufzeit überschrieben und erweitert werden.
Siehe auch die Klasse Variable_set .
Scheduler-Parameter
Folgende Scheduler-Parameter könnnen für die Konfiguration des JobScheduler verwendet werden:
scheduler.variable_name SCHE
_prefix
DULE
R_
scheduler.max_kbyte_of
_db_log_entry
Prefix der JobScheduler einvironment Variablen (aus Kompatibilitätsgründen
zu älteren Versionen ist auch SCHEDULER_VARIABLE_NAME_PREFIX
gültig).
unbegr Maximale Größe der Orderlogs in der Datenbank.
enzt
scheduler.order.keep_or TRUE
der_content_on_resched
ule
Behält den Zustand der Auftragsparameter nach dessen Ausführung.
scheduler.order.distribut FALSE TRUE: Verteilte Aufträge werden gleichmässig auf die JobScheduler des
ed.balanced
Clusters verteilt.
FALSE: Verteilte Aufträge werden auf einem JobScheduler des Clusters
ausgeführt, bis dieser ausgelastet ist.
•
•
•
scheduler.variable_name_prefix
scheduler.max_kbyte_of_db_log_entry
scheduler.order.keep_order_content_on_reschedule
August 2014
191
•
scheduler.order.distributed.balanced
Job-Parameter
Auftrags-Parameter
Parameter eines Auftrags können mit der Methode Order.params() abgerufen werden.
Ergänzt ein Element <param> an der entsprechenden Stelle mit gleichem Attribut name= aus der Basiskonfiguration.
Eltern Elemente
Attribute
name="" Eindeutiger Name
value=""
XML-Element <param.get>
<param.get
name
> </param.get>
= "name"
Name des Parameters
Liefert <param> mit dem Scheduler-Parameter oder <ok> , wenn er unbekannt ist.
Attribute
name="name" Name des Parameters
<params >
param
copy_params
include
</params>
Ein Parameter
August 2014
192
Eltern Elemente
<job> <add_order> - Auftrag hinzufügen
<config> <modify_order> <payload> - Nutzlast
<queued_task> <web_service> -
<params >
param
copy_params
include
</params>
Ein Parameter
Eltern Elemente
<job> <add_order> - Auftrag hinzufügen
<config> <modify_order> <payload> - Nutzlast
August 2014
193
<queued_task> <web_service> -
XML-Element <params.get>
<params.get
name
> </params.get>
= "name"
Name des Parameters
Liefert <params> mit allen Scheduler-Variablen.
Attribute
name="name" Name des Parameters
XML-Element <payload>
<payload >
params
</payload>
Parameter
Wenn die Nutzlast kein Variable_set ist, wird sie als Text eingefügt.
Eltern Elemente
<order> -
XML-Element <process_class>
<process_class
spooler_id
name
max_processes
remote_scheduler
replace
> </process_class>
= "scheduler_id"
= "name"
= "zahl"
= "host:port"
Ausführung der Tasks auf entferntem
Rechner
= "yes|no"
Definiert oder ändert eine Prozessklasse.
Siehe auch <process_class.remove> (Seite 195).
Ergänzt ein Element <process_class> an der entsprechenden Stelle aus der Basiskonfiguration. Hier angegebene
Eltern Elemente
<process_classes> -
August 2014
194
Attribute
spooler_id="scheduler_id"
Das Element ist nur wirksam, wenn dieses Attribut leer oder gleich dem Parameter -id= vom JobScheduler Start
ist, oder wenn beim JobScheduler Start die Option -id nicht angegeben worden ist.
name="name"
Name der Prozessklasse. Wenn das Attribut fehlt oder leer ("") ist, dann wird die Default-Prozessklasse geändert.
Siehe <job> (Seite 37), Attribut process_class=.
max_processes="zahl" (Initialwert:30)
Begrenzt die Zahl der Prozesse.
Manche Betriebsysteme limitieren die Zahl der Prozesse, die der JobScheduler starten darf. Es sollten nicht mehr
Prozesse konfiguriert werden als das Betriebssystem erlaubt.
Für Microsoft Windows Betriebssysteme gilt derzeit eine Beschränkung von max. 30 für die parallele Ausführung
zugelassenen Prozessen.
remote_scheduler="host:port" Ausführung der Tasks auf entferntem Rechner
Bestimmt den entfernten Scheduler, auf dem die Tasks dieser Prozessklasse ausgeführt werden sollen, durch
Hostnamen oder IP-Nummer und TCP-Port (s. <config tcp_port="…"> ).
Der entfernte JobScheduler muss den Zugriff mit <allowed_host level="all"> erlauben.
Die ausgeführten Tasks kommunizieren über die API mit dem steuernden Scheduler. Dabei gibt es einige
Besonderheiten:
•
•
•
<include> innerhalb von <script> wird vom Task-Prozess ausgeführt. Die einzuschließende Datei wird also
vom Rechner, der die Task ausführt, gelesen.
Subprocess.timeout und Task.add_pid() wirken nicht. Der JobScheduler kann entfernte Subprozesse,
deren Frist abgelaufen ist, nicht abbrechen.
Log.log_file() wird, wie fast alle Methoden, auf dem Rechner des Schedulers ausgeführt, greift also auf
die Dateien des dortigen Dateisystems zu.
Einige Einstellungen werden vom entfernten statt vom eigenen JobScheduler übernommen:
•
•
•
•
•
sos.ini (Abschnitt [java], Eintrag javac= …)
factory.ini (Abschnitt [spooler], Eintrag tmp= …)
Meldungen
[warn]
SCHEDULER-849
Timeout is not possible for a subprocess running on a remote host (it cannot be
killed), pid= [warn]
SCHEDULER-850
After lost connection to remote scheduler, process is going to be killed [info]
SCHEDULER-848
Task pid= started for remote scheduler replace="yes|no" (Initialwert:yes)
August 2014
195
replace="yes" ersetzt die vorhandene Prozessklasse.
replace="no" ändert nur die gesetzten Attribute der Prozessklasse.
XML-Element <process_class.remove>
<process_class.remove
process_class
> </process_class.remove>
= "path"
Name der Sperre
Entfernt eine Prozessklasse.
Siehe auch <process_class> (Seite 59).
Eltern Elemente
process_class="path" Name der Sperre
Wenn noch Tasks in der Prozessklasse laufen, verzögert der JobScheduler das Löschen bis die letzte Task
geendet hat. Solange werden keine neuen Tasks gestartet.
Siehe auch Process_class.remove() .
XML-Element <remove_job_chain>
<remove_job_chain
job_chain
> </remove_job_chain>
= "name"
Entfernt eine Jobkette.
Das Kommando nutzt die Methode Job_chain.remove() .
Beispiel:
<remove_job_chain job_chain="my_job_chain" />
Eltern Elemente
job_chain="name"
August 2014
196
XML-Element <remove_order>
<remove_order
job_chain
order
> </remove_order>
= "name"
= "id"
Entfernt einen Auftrag aus einer Jobkette. Ein gerade den Auftrag ausführender Job bleibt unbeinflusst.
Das Kommando nutzt die Methode Order.remove_from_job_chain() .
Beispiel:
<remove_order job_chain="my_job_chain" order="42" />
Eltern Elemente
job_chain="name"
order="id"
XML-Element <schedule.remove>
<schedule.remove
schedule
> </schedule.remove>
= "path"
Pfad des Schedules
Entfernt ein Schedule.
Siehe auch <schedule> (Seite 65).
Eltern Elemente
schedule="path" Pfad des Schedules
Alle Tasks von Jobs, die den Schedule nutzen, werden beendet.
Aufträge, die den Schedule nutzen, laufen die Jobkette zum Ende durch und werden solange nicht wiederholt, wie
der Schedule fehlt.
August 2014
197
XML-Element <scheduler_log.log_categories.reset>
<scheduler_log.log_categories.reset
delay
= "integer"
> </scheduler_log.log_categories.reset>
Verzögerung in Sekunden
Setzt alle Log-Kategorien auf die für den Scheduler-Start eingestellten Werte zurück.
Siehe auch »Log Categories« (Seite 171)
Beispiel:
<scheduler_log.log_categories.reset delay="360"/>
Eltern Elemente
delay="integer" Verzögerung in Sekunden
Verzögert das Zurücksetzen um die angegebene Zeit.
XML-Element <scheduler_log.log_categories.set>
<scheduler_log.log_categories.set
category
= "name"
value
= "0|1"
> </scheduler_log.log_categories.set>
Name der Kategorie
Beispiel:
<scheduler_log.log_categories.set category="scheduler" value="1"/>
Eltern Elemente
category="name" Name der Kategorie
value="0|1"
1 schaltet die Kategorie an, 0 schaltet sie ab.
XML-Element <scheduler_log.log_categories.show>
<scheduler_log.log_categories.show > </scheduler_log.log_categories.show>
August 2014
198
Beispiel:
<scheduler_log.log_categories.show/>
Eltern Elemente
<commands> -
XML-Element <show_calendar>
<show_calendar
what
limit
from
before
> </show_calendar>
= "what"
= "zahl"
= "yyyy-mm-ddThh:mm:ss"
= "yyyy-mm-ddThh:mm:ss"
Das Kommando liefert die Startzeiten der Jobs und Aufträge. Das Ergebnis ist nicht geordnet.
Das Attribut limit="" ist auf limit="100" voreingestellt und begrenzt die Ergebnismenge. Das Limit sollte groß
genug gewählt werden, um nicht einen löchrigen Kalendar zu bekommen.
Beispiel:
<show_calendar/>
<show_calendar limit="1000" what="orders" from="2007-04-03T00:00:00"
before="2007-05-01T00:00:00"/>
Eltern Elemente
what="what"
what="orders" liefert auch die Startzeiten der Aufträge.
limit="zahl" (Initialwert:100)
Begrenzt zum Schutz vor einem zu großen Ergebnis die Anzahl der Kalendereinträge, die zurückgeliefert werden.
Weil die Kalendereinträge nicht nach Zeit, sondern nach Objekten geordnet sind, liefert das Kommando auch nicht
die nächsten 100 Einträge, sondern irgendwelche.
Das Limit sollte also groß genug eingestellt werden, dass kein Eintrag verloren geht.
from="yyyy-mm-ddThh:mm:ss"
Liefert nur Kalendereinträge ab dem Zeitpunkt.
before="yyyy-mm-ddThh:mm:ss"
August 2014
199
Liefert nur Kalendereinträge vor dem Zeitpunkt. Voreinstellung ist eine Woche nach from= oder eine Woche nach
from.
XML-Element <show_history>
<show_history
job
id
next
prev
what
> </show_history>
= "job_name"
= "zahl"
= "zahl"
= "zahl"
= ""
Beispiel:
<show_history id="4711" next="10"/>
Eltern Elemente
job="job_name"
Der Jobname.
id="zahl"
Die Kennung des Historiensatzes. (Das Attribut sollte nicht id heißen, das Wort ist in XML reserviert.)
next="zahl"
Die nächsten zahl Einträge hinter der Task-Id sollen geliefert werden.
prev="zahl"
Die letzten zahl Einträge vor der Task-id sollen geliefert werden.
what=""
XML-Element <show_job>
<show_job
job
job_chain
what
max_orders
max_task_history
> </show_job>
= "name"
= "name"
= ""
= ""
= ""
August 2014
200
Beispiel:
<show_job job="my_job"/>
Eltern Elemente
job="name"
Der Jobname.
job_chain="name"
Aufträge, die nicht in dieser Jobkette stehen, und Tasks, die solche Aufträge verarbeiten, werden nicht geliefert.
what=""
max_orders=""
max_task_history=""
XML-Element <show_job_chain>
<show_job_chain
job_chain
max_orders
max_order_history
what
> </show_job_chain>
= ""
= ""
= ""
= ""
Name der Jobkette
Beispiel:
<show_job_chains/>
Zeigt die Jobketten
Eltern Elemente
job_chain="" Name der Jobkette
max_orders=""
August 2014
201
max_order_history=""
what=""
XML-Element <show_job_chains>
<show_job_chains
what
max_orders
max_order_history
> </show_job_chains>
= ""
= ""
= ""
Beispiel:
<show_job_chains/>
Unsichtbare Jobketten ( <job_chain visible="no"> ) werden nicht gezeigt.
Eltern Elemente
what=""
max_orders=""
max_order_history=""
XML-Element <show_jobs>
<show_jobs
what
max_orders
max_task_history
> </show_jobs>
= ""
= ""
= ""
Beispiel:
<show_jobs/>
Unsichtbare Jobs ( <job visible="no"> ) werden nicht gezeigt.
Eltern Elemente
August 2014
202
what=""
max_orders=""
max_task_history=""
XML-Element <show_order>
<show_order
job_chain
order
history_id
what
> </show_order>
= "name"
= "id"
= "integer"
= ""
Zeigt einen aktuellen Auftrag oder einen aus der Historie.
Beispiel:
<show_order job_chain="meine_jobkette" order="E4711"/>
Eltern Elemente
job_chain="name"
Der Name der Jobkette.
order="id"
Die Kennung des Auftrags.
history_id="integer"
Abschlossene Aufträge werden in der Historie der Scheduler-Datenbank gespeichert. Dabei können zur selben
Auftragskennung mehrere Einträge vorliegen, z.B. wenn der Auftrag wegen <run_time> wiederholt ausgeführt
wird. Jeder Historien-Eintrag hat eine Historien-Kennung, über die er diesem Attribut abgerufen werden kann. Das
Attribut order= ist dann nicht erforderlich.
Die Historien-Kennung wird von <show_job_chain what="order_history"> geliefert.
what=""
XML-Element <show_state>
<show_state
what
= "what"
August 2014
max_orders
max_order_history
max_task_history
> </show_state>
203
= "integer"
= "integer"
= "integer"
Der Elementname show_state kann zu s abgekürzt werden.
Beispiel:
<show_state/>
<show_state what="job_chain_orders,job_orders"/>
Eltern Elemente
what="what"
(Diese Beschreibung ist für alle Kommandos dieselbe; manche Schlüsselwörter sind nur für bestimmte
Kommandos sinnvoll.)
Damit die Antwort eines Kommandos nicht unnötig groß wird, filtert der JobScheduler sie. Mit einer Kombination
folgender Schlüsselwörter (durch Komma getrennt) können Sie die Antwort erweitern.
max_orders="integer"
Begrenzt die Anzahl der Aufträge, die zurückgeliefert werden.
max_order_history="integer" (Initialwert:0)
Begrenzt die Anzahl der Aufträge aus der Auftragshistorie. max_order_history="0" unterdrückt die
Auftragshistorie.
max_task_history="integer" (Initialwert:20)
Begrenzt die Anzahl der Einträge in <history> .
XML-Element <show_task>
<show_task
id
what
> </show_task>
= "zahl"
= ""
Zeigt Informationen einer laufenden Task oder eine Task aus der Historie.
Beispiel:
<show_task id="4711"/>
August 2014
204
Eltern Elemente
id="zahl"
Die Task-Id.
what=""
XML-Element <start_job>
<start_job
job
name
after
at
force
web_service
= "job_name"
= "name"
= "zahl"
= "yyyy-mm-dd hh:mm:ss | now |
period"
= "yes|no"
= "name"
>
params
</start_job>
Parameter
Beispiel:
<start_job job="mein_job" at="now">
<params>
<param name="anzahl" value="100"/>
</params>
</start_job>
Eltern Elemente
job="job_name"
Der Jobname.
name="name"
Hier kann der Task ein Name gegeben werden.
after="zahl"
Eine Anzahl Sekunden, nach deren Ablauf erst die Task gestartet werden soll.
at="yyyy-mm-dd hh:mm:ss | now | period" (Initialwert:now)
August 2014
205
Zeitpunkt, zu dem die Task gestartet werden soll. Die Voreinstellung force="yes" setzt <run_time> ist außer
Kraft.
Relative Zeitangaben "now", "now + HH:MM[:SS]" und "now + SECONDS" sind möglich.
at="period" lässt den Job erst Starten, wenn die <run_time> dies zulässt (also in der laufenden oder der
nächsten Periode).
force="yes|no" (Initialwert:yes)
force="no":
•
•
•
Wenn der Job gestoppt ist, bleibt er gestoppt.
Wenn mit at= eine Startzeit angegeben ist, zu dem Zeitpunkt <run_time> oder <schedule> keine Start
zulassen, dann verschiebt der JobScheduler den Start bis zur nächsten Periode.
Daraus ergibt sich, dass at="now" wie at="period" wirkt.
force="yes":
•
•
Der Job wird sofort entstoppt (falls er gestoppt ist)
Eine mit at= angegebene Startzeit nimmt keine Rücksicht auf <run_time> oder <schedule> , die Task wird
also auch zu dem Zeitpunkt gestartet, wenn keine Periode vorliegt.
web_service="name"
Wenn die Task ausgeführt worden ist, wird sie mit einem Stylesheet transformiert und einem Web-Dienst
übergeben.
XML-Element <terminate>
<terminate
all_schedulers
restart
continue_exclusive_operat
ion
timeout
> </terminate>
= "yes|no"
= "yes|no"
= "yes|no"
= "seconds"
Beendet den JobScheduler ordentlich (s. Beendigung des Schedulers (Seite 225)).
Beispiel:
<terminate/>
Eltern Elemente
all_schedulers="yes|no" (Initialwert:no)
August 2014
206
In Zusammenhang mit -exclusive werden alle beteiligten JobScheduler beendet.
restart="yes|no" (Initialwert:no)
Lässt den JobScheduler erneut starten.
continue_exclusive_operation="yes|no" (Initialwert:no)
In Zusammenhang mit -exclusive wird eingestellt, dass ein inaktiver JobScheduler den Betrieb übernimmt.
timeout="seconds"
Wenn angegeben, bricht der JobScheduler nach der angegeben Frist alle Tasks ab, die bis dahin nicht beendet
haben.
XML-Element <xml_payload>
<xml_payload > </xml_payload>
<xml_payload> enthält genau ein XML-Element (mit beliebig vielen Kind-Elementen). Die Eigenschaft
Order.xml_payload enthält dieses Element als XML-Text.
Eltern Elemente
<order> <add_order> - Auftrag hinzufügen
<modify_order> -
5.2.1 XML-Antworten
XML-Elemente
XML-Element <answer>
<answer
time
>
ERROR
history
job
job_chain
order
process_classes
ok
log_categories
state
task
</answer>
= "yyyy-mm-dd hh:mm:ss.mmm"
Fehlermeldung
Task-Historie
Job
Jobkette
Auftrag
Prozessklassen
Einfache Antwort
Log-Kategorien
Allgemeiner Zustand des Schedulers
Task
Der JobScheduler liefert nur eins der Kind-Elemente.
August 2014
207
Eltern Elemente
<spooler> Attribute
time="yyyy-mm-dd hh:mm:ss.mmm"
Zeitstempel der Antwort.
XML-Element <ERROR>
<ERROR
time
class
code
text
source
line
col
> </ERROR>
= "yyyy-mm-dd hh:mm:ss"
= "name"
= "text"
= "text"
= "filename"
= "zahl"
= "zahl"
Zeitstempel
Name der Exception-Klasse (C++)
Fehlercode
Fehlercode und Fehlertext
Name der Datei, die den Fehler
enthält
Zeilennummer
Spaltennummer
Eltern Elemente
<answer> - Antwort
<job> - Job
<task> - Task
Attribute
time="yyyy-mm-dd hh:mm:ss" Zeitstempel
class="name" Name der Exception-Klasse (C++)
code="text" Fehlercode
text="text" Fehlercode und Fehlertext
source="filename" Name der Datei, die den Fehler enthält
Wenn der Fehler einer Datei zugeordnet werden konnte.
line="zahl" Zeilennummer
Nummer der Zeile (ab 1), die den Fehler enthält, wenn der Fehler einer Zeile zugeordnet werden konnte.
col="zahl" Spaltennummer
Nummer der Spalte (ab 1), die den Fehler enthält, wenn der Fehler einer Spalte zugeordnet werden konnte.
August 2014
208
XML-Element <file_based>
<file_based
filename
last_write_time
state
>
ERROR
removed
</file_based>
= ""
= ""
= ""
Dateiname
Zeitstempel der Datei in UTC
Fehlermeldung
Noch nicht abgeschlossenes Löschen eines Objekts
Eltern Elemente
<process_class> <lock> <job> - Job
<order> - Auftrag
Attribute
filename="" Dateiname
last_write_time="" Zeitstempel der Datei in UTC
state=""
Eine der Angaben undefined, not_initialized, initialized, loaded, active und closed.
XML-Element <history>
<history >
history.entry
</history>
Eintrag in der Task-Historie
Die Histore wird aus der Datenbank gelesen.
Eltern Elemente
<history> - Task-Historie
XML-Element <history.entry>
<history.entry
task
id
spooler_id
job_name
start_time
end_time
= "zahl"
= "zahl"
= "name"
= "name"
Task-Id
Task-Id (veraltet)
Scheduler-Id
Jobname
Zeitpunkt des Starts der Task
Zeitpunkt des Endes der Task
August 2014
cause
steps
error
error_code
error_text
209
= "cause"
= "zahl"
= "0|1"
= "text"
= "text"
Grund des Starts
Zahl der Jobschritte
"1" bei einem Jobfehler
Fehlercode
Fehlercode mit Fehlertext
>
ERROR
</history.entry>
Fehlermeldung
Die Histore wird aus der Datenbank gelesen.
Eltern Elemente
<history> - Task-Historie
Attribute
task="zahl" Task-Id
id="zahl" Task-Id (veraltet)
Verwenden sie das Attribut task=.
spooler_id="name" Scheduler-Id
Kennung des Schedulers oder "-", wenn der JobScheduler keine Kennung hat.
job_name="name" Jobname
start_time="yyyy-mm-dd hh:mm:ss" Zeitpunkt des Starts der Task
end_time="yyyy-mm-dd hh:mm:ss" Zeitpunkt des Endes der Task
cause="cause" Grund des Starts
Siehe <task cause="…"> (Seite 222)
steps="zahl" Zahl der Jobschritte
error="0|1" "1" bei einem Jobfehler
error_code="text" Fehlercode
Innerhalb von <job> wird anstelle dieses Attributs das Element <ERROR> ausgegeben.
error_text="text" Fehlercode mit Fehlertext
Innerhalb von <job> wird anstelle dieses Attributs das Element <ERROR> ausgegeben.
August 2014
210
XML-Element <job>
<job
job
state
waiting_for_process
all_steps
all_tasks
state_text
log_file
order
tasks
next_start_time
delay_after_error
in_period
has_description
remove
temporary
enabled
= "name"
= "state"
= "yes|no"
Jobname
Zustand
Wenn der Job auf einen Prozess
wartet
= "zahl"
Zahl der Jobschritte aller Tasks
= "zahl"
Zahl aller bisher gestarteten
Tasks
= "text"
Eigenschaft Job.state_text
= "dateiname"
Dateiname des Protokolls
= "yes|no"
Bei auftragsgesteuertem Job
= "zahl"
Anzahl der zugelassenen Tasks
= "yyyy-mm-dd hh:mm:ss.mmm" Voraussichtliche nächste Startzeit
= "yyyy-mm-dd hh:mm:ss.mmm" delay_after_error ist nach einem
Fehler wirksam
= "yes|no"
Wenn gerade eine <period>
wirksam ist
= "yes"
yes, wenn der Job eine <
description> hat
= "yes"
yes, wenn der Job entfernt wird
= "yes"
yes, wenn der Job temporär ist
= "yes|no"
Deaktiviert einen Job.
>
file_based
tasks
description
commands
params
lock.requestor
queued_tasks
history
order_queue
ERROR
</job>
Dem Objekt zugrundliegende Datei
Liste der laufenden Tasks
Tasks in der Warteschlange
Task-Historie
Auftragswarteschlange
Fehlermeldung
Eltern Elemente
<jobs> <answer> - Antwort
Attribute
job="name" Jobname
state="state" Zustand
state="none"
Der anfängliche Status des Jobs beim Start des Schedulers.
state="stopping"
Wenn der Job gestoppt wird und noch nicht alle Tasks beendet sind.
state="stopped"
Der Job ist gestoppt und alle Tasks sind beendet.
state="read_error"
Wenn <script> nicht gelesen werden konnte.
August 2014
211
state="pending"
Keine Task läuft.
state="running"
Wenigstens eine Task läuft.
waiting_for_process="yes|no" (Initialwert:no) Wenn der Job auf einen Prozess wartet
Das ist der Fall, wenn der Job eine Task starten will, aber die Prozessklasse nicht genügend groß ist.
Siehe <job process_class="…"> (Seite 37).
all_steps="zahl" Zahl der Jobschritte aller Tasks
all_tasks="zahl" Zahl aller bisher gestarteten Tasks
state_text="text" Eigenschaft Job.state_text
Siehe Job.state_text .
log_file="dateiname" Dateiname des Protokolls
order="yes|no" (Initialwert:no) Bei auftragsgesteuertem Job
Siehe <job order="…"> (Seite 37).
tasks="zahl" Anzahl der zugelassenen Tasks
Siehe <job tasks="…"> (Seite 37).
next_start_time="yyyy-mm-dd hh:mm:ss.mmm" Voraussichtliche nächste Startzeit
delay_after_error="yyyy-mm-dd hh:mm:ss.mmm" delay_after_error ist nach einem Fehler wirksam
in_period="yes|no" Wenn gerade eine <period> wirksam ist
has_description="yes" yes, wenn der Job eine <description> hat
remove="yes" yes, wenn der Job entfernt wird
Siehe <modify_job cmd="remove"> (Seite 187).
temporary="yes" yes, wenn der Job temporär ist
Siehe <job temporary="yes"> (Seite 37).
enabled="yes|no" (Initialwert:yes) Deaktiviert einen Job.
Siehe <job enabled="yes"> (Seite 37).
August 2014
212
XML-Element <job_chain>
<job_chain
name
orders
state
>
file_based
job_chain_node
</job_chain>
= "name"
= "zahl"
= "Zustand der Jobkette"
Name der Jobkette
Anzahl der Aufträge in der Jobkette
Stelle in einer Jobkette
Eltern Elemente
<job_chains> Attribute
name="name" Name der Jobkette
orders="zahl" Anzahl der Aufträge in der Jobkette
state="Zustand der Jobkette"
state="under_constructio
n"
Der anfängliche Status nach Spooler.create_job_chain() .
state="finished"
Nach Spooler.add_job_chain() .
state="removing"
Nach Job_chain.remove() , solange noch Aufträge ausgeführt werden.
XML-Element <job_chain_node>
<job_chain_node
state
= "text"
next_state
error_state
orders
= "text"
= "text"
= "zahl"
Auftragszustand, dem diese Stelle zugeordnet
ist
Folgezustand
Zustand für den Fehlerfall
Anzahl der Aufträge an dieser Stelle
>
job
</job_chain_node>
Job
Eltern Elemente
Attribute
state="text" Auftragszustand, dem diese Stelle zugeordnet ist
next_state="text" Folgezustand
August 2014
213
error_state="text" Zustand für den Fehlerfall
orders="zahl" Anzahl der Aufträge an dieser Stelle
XML-Element <log>
<log
level
highest_level
last_error
last_warning
mail_on_error
mail_on_warning
mail_on_success
mail_on_process
smtp
mail_from
mail_to
mail_cc
mail_bcc
mail_subject
> </log>
= "log_level"
= "log_level"
= "string"
= "string"
= "boolean"
= "boolean"
= "boolean"
= "integer"
= "name"
= "email_adresse"
= "email_adresse"
= "email_adresse"
= "email_adresse"
= "email_subject"
Mindest-Level, ab dem Ausgaben
durchgelassen werden
Das höchste bisher benutzte Level
Letzter Ausgabe des Levels error
Letzter Ausgabe des Levels warn
Der Inhalt von <log> ist das Protokoll (wenn mit what="log" bestellt).
Eltern Elemente
<job> - Job
<task> - Task
Attribute
level="log_level" Mindest-Level, ab dem Ausgaben durchgelassen werden
Siehe
highest_level="log_level" Das höchste bisher benutzte Level
last_error="string" Letzter Ausgabe des Levels error
last_warning="string" Letzter Ausgabe des Levels warn
mail_on_error="boolean"
Siehe factory.ini (Abschnitt [spooler], Eintrag mail_on_error= …) (Seite 91)
mail_on_warning="boolean"
Siehe factory.ini (Abschnitt [spooler], Eintrag mail_on_warning= …) (Seite 91)
August 2014
214
mail_on_success="boolean"
Siehe factory.ini (Abschnitt [spooler], Eintrag mail_on_success= …) (Seite 91)
mail_on_process="integer"
Siehe factory.ini (Abschnitt [spooler], Eintrag mail_on_process= …) (Seite 91)
smtp="name"
Siehe factory.ini (Abschnitt [spooler], Eintrag smtp= …) (Seite 93)
mail_from="email_adresse"
Siehe factory.ini (Abschnitt [spooler], Eintrag log_mail_from= …) (Seite 91)
mail_to="email_adresse"
Siehe factory.ini (Abschnitt [spooler], Eintrag log_mail_to= …) (Seite 91)
mail_cc="email_adresse"
Siehe factory.ini (Abschnitt [spooler], Eintrag log_mail_cc= …) (Seite 91)
mail_bcc="email_adresse"
Siehe factory.ini (Abschnitt [spooler], Eintrag log_mail_bcc= …) (Seite 91)
mail_subject="email_subject"
Siehe factory.ini (Abschnitt [spooler], Eintrag log_mail_subject= …) (Seite 91)
XML-Element <log_categories>
<log_categories >
log_category
</log_categories>
Eltern Elemente
<answer> - Antwort
XML-Element <ok>
<ok > </ok>
Ein leeres Element, mit dem Kommandos antworten, die kein weiteres Ergebnis liefern.
August 2014
215
Eltern Elemente
<answer> - Antwort
XML-Element <order>
<order
order
title
state
job_chain
job
task
= "id"
= "text"
= "text"
= "name"
= "name"
= "id"
Auftragskennung
Titel
Zustand
Name der Jobkette
Job
Kennung der Task, die den Auftrag
gerade ausführt
=
" y y y y - m m - d dSeit wann die Task den Auftrag
hh:mm:ss.mmm"
ausführt
= "text"
Zustandstext
= "zahl"
Priorität
=
" y y y y - m m - d dWann der Auftrag erzeugt worden
hh:mm:ss.mmm"
ist
= "dateiname"
Name der Protokolldatei
= "hh:mm:ss.mmm"
Wann der Auftrag zurückgestellt
worden ist
=
" y y y y - m m - d dNächster Startzeitpunkt
hh:mm:ss.mmm"
= "yes|no"
Auftrag ist aus der Jobkette entfernt
worden
= "yes|no"
Auftrag ist ersetzt worden
= "yes|no"
Auftrag ersetzt einen anderen
gerade ausgeführten
= "name"
Name
des
zugeordneten
Web-Dienstes
in_process_since
state_text
priority
created
log_file
setback
next_start_time
removed
replaced
replacement
web_service
>
file_based
log
run_time
payload
</order>
Protokoll
Eltern Elemente
<answer> - Antwort
<order_queue> - Auftragswarteschlange
<task> - Task
Attribute
order="id" Auftragskennung
Siehe Order.id
title="text" Titel
Siehe Order.title
August 2014
216
state="text" Zustand
Siehe Order.state
job_chain="name" Name der Jobkette
Siehe Job_chain.add_order()
job="name" Job
Siehe Order.job
task="id" Kennung der Task, die den Auftrag gerade ausführt
in_process_since="yyyy-mm-dd hh:mm:ss.mmm" Seit wann die Task den Auftrag ausführt
state_text="text" Zustandstext
Siehe Order.state_text .
priority="zahl" Priorität
Siehe Order.priority .
created="yyyy-mm-dd hh:mm:ss.mmm" Wann der Auftrag erzeugt worden ist
log_file="dateiname" Name der Protokolldatei
setback="hh:mm:ss.mmm" Wann der Auftrag zurückgestellt worden ist
next_start_time="yyyy-mm-dd hh:mm:ss.mmm" Nächster Startzeitpunkt
Wenn das Attribut fehlt, wird der Auftrag so bald wie möglich ausgeführt.
removed="yes|no" (Initialwert:no) Auftrag ist aus der Jobkette entfernt worden
removed="yes": Der Auftrag ist durch einen Aufruf von Order.remove_from_job_chain() aus der Jobkette
entfernt worden, aber wird noch von einer Task ausgeführt (Elternelement ist <task> ).
replaced="yes|no" (Initialwert:no) Auftrag ist ersetzt worden
replaced="yes": Der Auftrag ist durch einen Aufruf von Job_chain.add_or_replace_order() ersetzt worden,
aber wird noch von einer Task ausgeführt (Elternelement ist <task> ).
August 2014
217
replacement="yes|no" (Initialwert:no) Auftrag ersetzt einen anderen gerade ausgeführten
replacement="yes": Nach Job_chain.add_or_replace_order() wird noch der ersetzte Auftrag von einer Task
ausgeführt.
Dieser Auftrag wird erst ausgeführt, wenn der ersetzte Auftrag ausgeführt worden ist.
web_service="name" Name des zugeordneten Web-Dienstes
XML-Element <order_queue>
<order_queue
length
= "zahl"
next_start_time
= "date"
Anzahl
der Aufträge
Auftragswarteschlange
Startzeit des nächsten Auftrags
in
der
>
order
</order_queue>
Auftrag
Eltern Elemente
<job> - Job
Attribute
length="zahl" Anzahl der Aufträge in der Auftragswarteschlange
Die Anzahl der <order>-Elemente kann geringer oder null sein, wenn sie mit den Attributen max_orders= oder
what="" begrenzt worden ist.
next_start_time="date" Startzeit des nächsten Auftrags
XML-Element <process_classes>
<process_classes >
process_class
</process_classes>
Eltern Elemente
<answer> - Antwort
XML-Element <processes>
<processes >
process
</processes>
Eltern Elemente
<process_class> -
August 2014
218
XML-Element <queued_task>
<queued_task
task
enqueued
start_at
name
= "zahl"
Task-Id
=
" y y y y - m m - d dZeitpunkt der Aufnahme in die
hh:mm:ss.mmm"
Warteschlange
=
" y y y y - m m - d dWann die Task starten soll
hh:mm:ss.mmm"
= "text"
Name der Task
>
params
</queued_task>
Eltern Elemente
<queued_task> - Task in der Warteschlange
Attribute
task="zahl" Task-Id
enqueued="yyyy-mm-dd hh:mm:ss.mmm" Zeitpunkt der Aufnahme in die Warteschlange
start_at="yyyy-mm-dd hh:mm:ss.mmm" Wann die Task starten soll
name="text" Name der Task
XML-Element <queued_tasks>
<queued_tasks
length
>
queued_task
</queued_tasks>
= "zahl"
Anzahl der Tasks in der Warteschlange
Task in der Warteschlange
Eltern Elemente
<job> - Job
Attribute
length="zahl" Anzahl der Tasks in der Warteschlange
XML-Element <removed>
<removed >
ERROR
</removed>
Fehlermeldung
August 2014
219
Eltern Elemente
<file_based> - Dem Objekt zugrundliegende Datei
XML-Element <replacement>
<replacement >
process_class
lock
job
job_chain
order
</replacement>
Job
Jobkette
Auftrag
Das Kind-Element hat denselben Namen wie das Eltern-Element. Bei einem Job zum Beispiel ist die
Verschachtelung <job> <replacement> <job> . Das Kind-Element enthält das neue Objekt, das vorhandene noch
nicht ersetzen kann. Sobald das zu ersetzende Objekt bereit ist, nimmt der JobScheduler die Ersetzung vor.
Eltern Elemente
<process_class> <lock> <job> - Job
<order> - Auftrag
XML-Element <state>
<state
config_file
spooler_id
id
spooler_running_since
wait_until
state
log_file
version
pid
db
db_waiting
waiting_errno
waiting_errno_text
waiting_errno_filename
loop
waits
time
tcp_port
= "filename"
= "name"
= "name"
XML-Konfiguration
Scheduler-Id
Veraltet
Zeitpunkt des Anlaufs des
Schedulers
= "yyyy-mm-dd hh:mm:ss|never" Nächste Aktion des Schedulers
= "state"
Zustand des Schedulers
= "dateiname"
Dateiname des Hauptprotokolls
= "vv.vv.vv yyyy-mm-dd"
= "zahl"
Prozess-Id des Schedulers
= "hostware_dateiname"
Datenbank
= "yes|no"
Scheduler
erneuert
Datenbankverbindung
= "number"
Fehler beim Scheiben eines
Protokolls (Platte voll)
= "text"
Fehlertext
zum
Attribut
waiting_errno
= "filename"
Name der Datei, bei der der
Fehler aufgetreten ist
= "zahl"
Interner Wert: Anzahl der
Server-Zyklen
= "zahl"
Interner Wert: Anzahl der
Wartezustände
veraltet
= "integer"
August 2014
220
udp_port
= "integer"
>
locks
jobs
job_chains
process_classes
subprocesses
remote_schedulers
</state>
Prozessklassen
Subprozesse (abhängige Prozesse)
Eltern Elemente
<answer> - Antwort
Attribute
config_file="filename" XML-Konfiguration
Name der XML-Konfigurationsdatei.
spooler_id="name" Scheduler-Id
Die Scheduler-Id, siehe Option -id .
id="name" Veraltet
Veraltet. Verwenden sie das Attribut spooler_id=.
spooler_running_since="yyyy-mm-dd hh:mm:ss" Zeitpunkt des Anlaufs des Schedulers
wait_until="yyyy-mm-dd hh:mm:ss|never" Nächste Aktion des Schedulers
state="state" Zustand des Schedulers
Der Zustand des Schedulers kann mit dem Kommando <modify_spooler cmd="…"> beeinflusst werden.
log_file="dateiname" Dateiname des Hauptprotokolls
version="vv.vv.vv yyyy-mm-dd"
Version des Schedulers
pid="zahl" Prozess-Id des Schedulers
db="hostware_dateiname" Datenbank
August 2014
221
Verwendete Datenbank als Hostware-Dateiname. Ein mit -password= angegebene Kennwort wird unterdrückt,
außer der Lizenzschlüssel-Code 15 ist gesetzt (siehe sos.ini (Abschnitt [licence], Eintrag key1= …) und <
licence.use> ).
db_waiting="yes|no" (Initialwert:no) Scheduler erneuert Datenbankverbindung
Wenn der JobScheduler die Datenbankverbindung verloren hat und versucht, sie wiederherzustellen, ist
db_waiting="yes" gesetzt. Der JobScheduler führt währenddessen keinen Job aus.
waiting_errno="number" Fehler beim Scheiben eines Protokolls (Platte voll)
Wenn dieses Attribut gesetzt ist, steht der Scheduduler still und reagiert nur noch auf Kommandos über TCP, UDP
und HTTP.
Der JobScheduler kann mit <modify_spooler cmd="continue"> fortgesetzt werden.
waiting_errno_text="text" Fehlertext zum Attribut waiting_errno
waiting_errno_filename="filename" Name der Datei, bei der der Fehler aufgetreten ist
loop="zahl" Interner Wert: Anzahl der Server-Zyklen
Der Wert erhöht sich, wenn der JobScheduler Opertionen ausführt, z.B. ein Jobschritt oder ein Methodenaufruf aus
einem Job heraus.
waits="zahl" Interner Wert: Anzahl der Wartezustände
Der Wert erhöht sich um eins, wenn der JobScheduler im Wartezustand ist, weil gerade nichts zu tun ist.
time="yyyy-mm-dd hh:mm:ss" veraltet
Veraltet. Verwenden sie <answer time="…">
tcp_port="integer"
udp_port="integer"
XML-Element <subprocess>
<subprocess
pid
priority
timeout_at
killed
= "zahl"
Prozess-Id vom Betriebssystems
= "priority"
= "yyyy-mm-dd hh:mm:ss.mmm" Frist des Prozesses
= "yes|no"
W e n n d i e Ta s k g e r a d e
abgebrochen wird
> </subprocess>
Eltern Elemente
August 2014
222
<subprocesses> - Subprozesse (abhängige Prozesse)
Attribute
pid="zahl" Prozess-Id vom Betriebssystems
priority="priority"
Priorität des Prozesses: Unter Unix -20 bis 20, unter Windows idle, below_normal, normal, above_normal oder
high.
timeout_at="yyyy-mm-dd hh:mm:ss.mmm" Frist des Prozesses
Wenn der Prozess mit Task.add_pid() eine Frist bekommen hat.
killed="yes|no" (Initialwert:no) Wenn die Task gerade abgebrochen wird
XML-Element <subprocesses>
<subprocesses >
subprocess
</subprocesses>
Subprozess (abhängiger Prozess)
Eltern Elemente
<state> - Allgemeiner Zustand des Schedulers
<task> - Task
XML-Element <task>
<task
task
id
state
name
running_since
enqueued
start_at
idle_since
in_process_since
cause
steps
log_file
calling
pid
priority
delayed_after_error_task
web_service
= "zahl"
= "zahl"
= "state"
= "name"
= "yyyy-mm-td hh:mm:ss.mmm"
= "cause"
= "zahl"
= "dateiname"
= "text"
= "zahl"
= "priority"
= "zahl"
= "name"
Task-Id
(veraltet)
Zustand der Task
Name des zugeordneten
Web-Dienstes
>
subprocesses
Subprozesse (abhängige Prozesse)
August 2014
log
order
ERROR
</task>
223
Protokoll
Auftrag
Fehlermeldung
Eltern Elemente
<tasks> - Liste der laufenden Tasks
Attribute
task="zahl" Task-Id
id="zahl" (veraltet)
Die Task-Id.
(XML reserviert das Attribut id, es sollte stattdessen task verwendet werden.)
state="state" Zustand der Task
Folgende Werte werden zurückgegeben:
name="name"
Der Name der Task (s. <start_job> ).
running_since="yyyy-mm-td hh:mm:ss.mmm"
Wenn die Task geladen oder gestartet worden ist: Zeitpunkt des Starts der Task.
enqueued="yyyy-mm-td hh:mm:ss.mmm"
Zeitpunkt, wann die Task in die Task-Warteschlange eingereiht worden ist.
start_at="yyyy-mm-td hh:mm:ss.mmm"
Zeitpunkt, wann die Task gestartet werden soll (s. <start_job at="…"> ).
idle_since="yyyy-mm-td hh:mm:ss.mmm"
Zeitpunkt, seit dem die Task im Zustand waiting_for_order ist.
in_process_since="yyyy-mm-td hh:mm:ss.mmm"
Zeitpunkt, seit dem spooler_process(), also der gerade aktive Jobschritt ausgeführt wird.
cause="cause"
August 2014
224
Anlass des Starts.
steps="zahl"
Anzahl abgeschlossener Jobschritte, also Aufrufe von spooler_process() .
log_file="dateiname"
Name der Protokolldatei. Das Attribut ist nur gesetzt solange die Task läuft.
calling="text"
Name der Methode des Jobs, die gerade aufgerufen wird.
pid="zahl"
Kennung des Prozesses, der die Task ausführt.
priority="priority"
Priorität des Prozesses: Unter Unix -20 bis 20, unter Windows idle, below_normal, normal, above_normal oder
high.
delayed_after_error_task="zahl"
Wenn diese Task eine Wiederholung einer mit Fehler abgebrochen Task ist (s. Job.delay_after_error ), dann
gibt dieses Attribut die Kennung der fehlerhaften Task an.
web_service="name" Name des zugeordneten Web-Dienstes
XML-Element <tasks>
<tasks
count
>
task
</tasks>
= "zahl"
Task
Eltern Elemente
<job> - Job
Attribute
count="zahl"
Anzahl der laufenden Tasks.
August 2014
225
XML-Element <waiting_jobs>
<waiting_jobs
job
>
job
</waiting_jobs>
= "name"
Job
Eltern Elemente
<process_class> Attribute
job="name"
5.3 Beendigung des Schedulers
5.3.1 Ordentliches Beenden
Der JobScheduler beendet sich erst, wenn kein Job mehr läuft.
Siehe Spooler.terminate() und <modify_spooler cmd="terminate"> (Seite 189).
5.3.2 Ordentliches Beenden mit Frist
Sie können zum Beenden eine Frist angeben. Wenn nach Ablauf der First noch Tasks laufen, weil sie in z.B.
spooler_process() zu lange verharren, bricht der JobScheduler alle noch laufenden Prozesse ab.
Zuvor verschickt er eine eMail mit dem Hinweis auf Tasks, die abgebrochen werden.
Er wartet dann längstens 30s aufs Ende der Tasks (normalerweise gelingt der Abbruch sofort) und beendet sich
dann.
Siehe Spooler.terminate() und <modify_spooler cmd="terminate"> (Seite 189).
5.3.3 Abbruch
Der JobScheduler bricht allen Prozesse (einschließlich der mit add_pid() registrierten fremden Prozesse) sofort ab
(Unix: kill -s KILL, Windows: TerminateProcess()). Dann bricht er sich selbst ab.
Vorteil: Der Abbruch wirkt sofort.
Nachteil: Sie Software, insbesondere die Jobs können nicht darauf reagieren. Z.B. können temporäre Dateien nicht
gelöscht werden.
August 2014
Meldungen des Schedulers
226
Anhang A: Meldungen des Schedulers
A.1 Messages für Paket Scheduler
Code
Text
SCHEDU
LER-10
4
Beginnzeit (1) liegt nach der Endezeit (2), oder anderer Fehler bei Attributen begin= und end=
- Beispiel für eine nähere Beschreibung Fehlerhaft ist zum Beispiel <period begin="23:00" end="01:00"/>. Eine Periode muss innerhalb
eines Kalendertages liegen, zwischen 00:00 und 24:00.
Siehe <period> (Seite 55).
SCHEDU
LER-10
5
Unbekanntes Kommando: <(1)>
SCHEDU
LER-10
6
Unbekanntes Kommando an eine Task: (1)
SCHEDU
LER-10
7
Skript fehlt
SCHEDU
LER-11
0
Unbekannter Zustand einer Task: (1)
SCHEDU
LER-11
3
XML-Tag (1) ist hier falsch
SCHEDU
LER-11
5
Die XML-Konfigurationsdatei ist nicht angegeben. Option -config=DATEINAME.XML
SCHEDU
LER-11
6
XML-Konfiguration enthält kein Element <config spooler_id=(1)>
SCHEDU
LER-11
7
Verschiedene Skriptsprachen können nicht in derselben Scripting Engine verwendet werden
SCHEDU
LER-11
9
Security level "(1)" gibt es nicht
SCHEDU
LER-12
0
Skript meldet Fehler: (1)
SCHEDU
LER-12
1
Die Sicherheitseinstellungen lassen die Operation nicht zu
SCHEDU
LER-12
2
Task ist beendet
Siehe XML-Kommandos (Seite 179).
August 2014
227
Code
Text
SCHEDU
LER-12
5
task.wait_until_terminated() kann nicht im selben Thread verwendet werden. Deadlock.
SCHEDU
LER-13
0
Job (1) ist bereits definiert
SCHEDU
LER-13
6
Keine Historie
SCHEDU
LER-13
9
Operation bei Historie in Textdatei nicht möglich
SCHEDU
LER-14
0
Task hat Fehler protokolliert: (1)
SCHEDU
LER-14
1
Die Historie für Job (1) ist ausgeschaltet (history=no)
SCHEDU
LER-14
2
Relativer Datenbankdateiname kann bei need_db=yes und log_dir=*stderr nicht verwendet werden
SCHEDU
LER-14
3
Element <run_time> sieht keine Periode für eine Task ohne Startzeit vor
SCHEDU
LER-14
5
<script> com_class= und language= können nicht zugleich angegeben werden
SCHEDU
LER-14
6
Das Skript fehlt
SCHEDU
LER-14
7
SCHEDU
LER-14
8
SCHEDU
LER-14
9
Für den Zustand "(2)" ist kein Job in der Jobkette (1) definiert
SCHEDU
LER-15
0
Für den Zustand "(1)" ist bereits ein Job in der Jobkette (2) definiert
SCHEDU
LER-15
1
Jobkette ist außer Betrieb (add_job_chain() fehlt oder Jobkette wird entfernt)
SCHEDU
LER-15
2
Job "(1)" ist nicht in der Jobkette "(2)"
August 2014
Code
228
Text
SCHEDU
LER-15
3
SCHEDU
LER-15
5
Ein temporärer Job kann keine Aufträge annehmen
SCHEDU
LER-15
6
(1) ist nicht in der Auftragswarteschlange des Jobs "(2)"
SCHEDU
LER-15
7
(1) ist nicht in einer Jobkette
SCHEDU
LER-15
9
Id und Priorität eines Auftrags können nicht mehr geändert werden, wenn er in einer Auftragsliste steht
SCHEDU
LER-16
0
SCHEDU
LER-16
1
SCHEDU
LER-16
2
Auftrag (1) ist nicht in der Jobkette (2)
SCHEDU
LER-16
3
(1) ist nicht einer Auftragswarteschlange
SCHEDU
LER-16
4
<show_... what="(1)">: Ungültige Angabe für Attribut what
SCHEDU
LER-16
6
<script> java_class= und language= können nicht zugleich angegeben werden
SCHEDU
LER-16
7
Bei <script> com_class= oder java_class= kann die Programmquelle nicht angegeben werden
SCHEDU
LER-16
8
In <script> ist com_class= und java_class= zusammen angegeben
SCHEDU
LER-17
2
Die Skriptart (Scripting Engine, Perl, COM oder Java) ist hier nicht möglich
SCHEDU
LER-17
3
Skript fehlt
SCHEDU
LER-17
4
Methode (1) der Klasse (2) fehlt
August 2014
Code
Text
SCHEDU
LER-17
7
Java steht nicht zur Verfügung (siehe Fehler beim Start des Schedulers)
SCHEDU
LER-17
9
<process>-Task hat sich nicht beendet. pid=(1)
229
SCHEDU
LER-18
2
SCHEDU
LER-18
3
SCHEDU
LER-18
4
Die Scheduler-Datenbank ist wegen eines Datenbankproblems gerade nicht geöffnet
SCHEDU
LER-18
6
(1) ist bereits in der Jobkette (2)
SCHEDU
LER-18
7
Order.setback(): Ein Auftrag kann nur zurückgestellt werden, während eine Task ihn ausführt
SCHEDU
LER-18
8
Order.setback() und Order.state= können nicht zusammen gerufen werden, das ist Unsinn
SCHEDU
LER-19
1
separate_process: Unerwarteter Zustand (2) in (1)
SCHEDU
LER-19
4
process_class und separate_process können nicht kombiniert werden
SCHEDU
LER-19
6
use_engine="(1)" ist veraltet
SCHEDU
LER-19
7
Module::java_method_id((1)): Java-Klasse ist unbekannt
SCHEDU
LER-19
8
Variablenname fehlt
SCHEDU
LER-19
9
Die Modulinstanz ist geschlossen
SCHEDU
LER-20
0
Die Remoteinstanz ist geschlossen
SCHEDU
LER-20
1
Das Arbeitsverzeichnis zum Aufruf des Java-Compilers fehlt
August 2014
Code
Text
SCHEDU
LER-20
2
Verbindung zur Task verloren, state=(1): (2)
SCHEDU
LER-20
3
Die Modulinstanz im Server ist geschlossen
SCHEDU
LER-20
4
Der Job "(1)" ist im Fehlerzustand. (2)
230
SCHEDU
LER-20
5
SCHEDU
LER-20
6
need_db=(1), erlaubt sind aber nur yes, no, strict
SCHEDU
LER-20
7
Task (1) unbekannt (auch in der Historie)
SCHEDU
LER-20
8
Hier ist nur ein Datum ohne Uhrzeit möglich
SCHEDU
LER-20
9
Das Microsoft Windows-Limit der Objekte, auf die gewartet werden kann (TCP-Verbindungen,
beobachteten Verzeichnisse etc.) von MAXIMUM_WAIT_OBJECTS-1=(1) ist erreicht. Die Operation ist
nicht ausführbar.
SCHEDU
LER-21
0
Zuviele Prozesse. Die Zahl der Prozesse ist auf (1) begrenzt
SCHEDU
LER-21
2
Eintrag [spooler] html_dir= fehlt in der Datei factory.ini
SCHEDU
LER-21
3
Fehler beim Lesen des HTTP-Kopfs: (1) erwartet
SCHEDU
LER-21
4
Unzulässiger Pfad in HTTP-Anforderung
SCHEDU
LER-21
5
Task (1) unbekannt oder beendet
SCHEDU
LER-21
7
(1) ist in Bearbeitung durch (2)
SCHEDU
LER-21
8
Subprocess pid=(2) hat sich mit exit code=(1) beendet. Command=(3)
SCHEDU
LER-21
9
Subprocess pid=(2) hat sich mit Signal (1) beendet. Command=(3)
August 2014
Code
Text
SCHEDU
LER-22
0
<run_time (1)> ist für einen Auftrag nicht möglich
SCHEDU
LER-22
1
<day day="(1)">: Nur die Tage (2) bis (3) sind möglich
SCHEDU
LER-22
2
Das Kommando <(1)> kann nur über eine TCP-Verbindung gegeben werden
231
SCHEDU
LER-22
3
SCHEDU
LER-22
4
Haupt-Scheduler hat Verbindung geschlossen
SCHEDU
LER-22
5
start_new_file() ist nur fürs Hauptprotokoll möglich
SCHEDU
LER-22
6
Der Auftrag ist nicht verarbeitet worden ist, weil die Task vor dem ersten Jobschritt (spooler_process())
beendet worden ist
SCHEDU
LER-22
7
Scheduler-Skript hat Fehler protokolliert: (1)
SCHEDU
LER-23
0
Der Job "(1)" wird entfernt, er kann nicht mehr verwendet werden
SCHEDU
LER-23
1
Attribut (2) fehlt im XML-Element <(1)>
SCHEDU
LER-23
2
SCHEDU
LER-23
4
<job (1)="..."> Attribut kann nicht überschrieben werden
SCHEDU
LER-23
5
Web-Dienst "(1)" ist unbekannt
SCHEDU
LER-23
6
Web-Dienst "(1)" ist bereits bekannt
SCHEDU
LER-23
7
XSLT-Stylesheet "(1)" liefert kein Ergebnis
SCHEDU
LER-23
8
Web-Dienst für url_path="(1)" ist bereits bekannt
August 2014
Code
232
Text
SCHEDU
LER-23
9
SCHEDU
LER-24
0
Auftrag ist keinem Webdienst zugeordnet
SCHEDU
LER-24
1
Task ist keinem Webdienst zugeordnet
SCHEDU
LER-24
2
forward_xslt_stylesheet (1) liefert nicht <service_request>
SCHEDU
LER-24
3
Eigenschaft (1) ist fixiert, sie kann nicht mehr geändert werden
SCHEDU
LER-24
4
Element <content> fehlt oder ist leer
SCHEDU
LER-24
5
Element <content> hat mehr als ein Element
SCHEDU
LER-24
6
Auftrag gehört nicht zu einer Web-Dienst-Operation
SCHEDU
LER-24
7
HTTP-Antwort wird bereits versendet
SCHEDU
LER-24
8
web_service_operation ist abgeschlossen und nicht mehr gültig
SCHEDU
LER-24
9
Order-Id lässt sich nicht als Zeichenkette darstellen: (1)
SCHEDU
LER-25
0
Order-State lässt sich nicht als Zeichenkette darstellen: (1)
SCHEDU
LER-25
1
Order-Payload lässt sich nicht als Zeichenkette darstellen: (1)
SCHEDU
LER-25
2
Ungültiger Url-Pfad, er muss mit '/' beginnen: (1)
SCHEDU
LER-25
4
(1) Tasks haben sich nicht beendet trotz kill vor (2)s. Die (3)s lange Nachfrist läuft weiter
SCHEDU
LER-25
5
(1) Tasks haben sich nicht beendet trotz kill vor (2) seconds. JobScheduler bricht ab
Nach Web_service_response.send() kann Web_service_response nicht mehr geändert werden.
August 2014
Code
Text
SCHEDU
LER-25
6
Frist zur Beendigung des Schedulers ist abgelaufen, aber (1) Tasks haben sich nicht beendet
SCHEDU
LER-25
7
Job wird jetzt entfernt
SCHEDU
LER-25
8
Job wird entfernt sobald alle Tasks beendet sind
233
SCHEDU
LER-26
0
SCHEDU
LER-26
1
SCHEDU
LER-26
2
Abbruch-Signal ((1)) empfangen. Der JobScheduler wird beendet
SCHEDU
LER-26
3
SCHEDU
LER-26
4
SCHEDU
LER-26
5
SCHEDULER WIRD BEENDET WEGEN FEHLERS BEIM ZUGRIFF AUF DATENBANK
SCHEDU
LER-26
6
Fehler beim Schreiben der Historie: (1)
SCHEDU
LER-26
7
Fehler beim Schreiben des Protokolls in die Tabelle (1): (2)
SCHEDU
LER-26
8
Protokoll der Task (1) lässt sich nicht aus der Datenbank lesen: (2)
SCHEDU
LER-26
9
Fehler beim Schließen der Job-Historie: (1)
SCHEDU
LER-27
0
Historie lässt sich nicht öffnen: (1)
SCHEDU
LER-27
1
Zugunsten des Jobs (1) wird die Task beendet
SCHEDU
LER-27
2
Task wird nach nach Fristablauf von <job timeout="(1)"> abgebrochen
August 2014
234
Code
Text
SCHEDU
LER-27
3
Subprozess (1) wird abgebrochen
SCHEDU
LER-27
4
Subprozess (1) lässt sich nicht abbrechen: (2)
SCHEDU
LER-27
5
Subprozess (1) wird abgebrochen, weil seine Frist überschritten ist
SCHEDU
LER-27
6
Task konnte nicht abgebrochen werden
SCHEDU
LER-27
8
Laufzeitperiode <period> ist abgelaufen, Task wird beendet
SCHEDU
LER-27
9
Prozess hat mit Signal (1) ((2)) geendet
SCHEDU
LER-28
0
Prozess hat mit Exit code (1) (0x(2)) geendet
SCHEDU
LER-28
1
Prozess wird abgebrochen
SCHEDU
LER-28
3
Task (1) aus der Datenbank ist fehlerhaft: (2)
SCHEDU
LER-28
4
cmd='(1)' wird ignoriert, weil Job entfernt wird
SCHEDU
LER-28
5
Max. (1) Historiensätze werden gelesen
SCHEDU
LER-28
7
TCP-Verbindung nicht zugelassen
SCHEDU
LER-28
8
-reuse-port (SO_REUSEADDR): (1) wird verwendet, auch wenn er schon von einer anderen
Anwendung belegt ist
SCHEDU
LER-28
9
(1) ist blockiert. Wir probieren es (2) Sekunden
SCHEDU
LER-29
0
Kein Job hat während der Frist begonnen (1) auszuführen, Auftrag und HTTP-Operation werden
abgebrochen
Siehe <web_service timeout="…"> (Seite 73)
SCHEDU
LER-29
1
Fehler beim Löschen der Protokolldatei: (1)
August 2014
235
Code
Text
SCHEDU
LER-29
2
Email unterdrückt, weil From, To, Subject oder der Nachrichtentext fehlt
SCHEDU
LER-29
3
Warten auf Schließen der Modulinstanz ...
SCHEDU
LER-29
4
Die Java-Klasse (1) konnte nicht geladen werden. Die Java-Quelle wird neu übersetzt, mal sehen, ob's
dann geht
SCHEDU
LER-29
5
Auftrag (1) aus der Datenbank ist fehlerhaft: (2)
SCHEDU
LER-29
7
Auftrag erledigt ohne web_service_operation.send(), Operation wird abgebrochen
SCHEDU
LER-29
8
job=(1) wird ignoriert, weil Auftrag bereits aus der Jobkette entfernt ist
SCHEDU
LER-29
9
Prozess (1) wird nach Fehler entfernt
SCHEDU
LER-30
0
Überwachung des Verzeichnisses (1) wird nach Fehler beendet: (2)
SCHEDU
LER-30
1
UDP-Nachricht von (1) nicht zugelassen
SCHEDU
LER-30
2
Fehler beim eMail-Versand: (1)
SCHEDU
LER-30
3
Fehler beim Zugriff auf die Datenbank: (1)
SCHEDU
LER-30
4
Fehler beim Lesen der nächsten Id (Spalte "(2)"): (1)
SCHEDU
LER-30
5
Fehler beim Einfügen in die Tabelle (1): (2)
SCHEDU
LER-30
6
Fehler beim Update der Tabelle (1): (2)
SCHEDU
LER-30
7
Historiensatz wird wegen vorausgegangenen Datenbankfehlers nicht geschrieben
SCHEDU
LER-30
8
cancel() ignoriert, weil die Antwort schon übertragen wird
August 2014
Code
Text
SCHEDU
LER-30
9
Fehler beim Öffnen der Datenbank: (1)
SCHEDU
LER-31
0
Fehler beim Schließen der Datenbank: (1)
236
SCHEDU
LER-31
1
SCHEDU
LER-31
2
SCHEDU
LER-31
3
SCHEDU
LER-31
4
SCHEDU
LER-31
6
SCHEDU
LER-31
8
SCHEDU
LER-31
9
SCHEDU
LER-32
0
SCHEDU
LER-32
1
SCHEDU
LER-32
2
SCHEDU
LER-32
3
SCHEDU
LER-32
4
SCHEDU
LER-32
5
SCHEDU
LER-32
6
August 2014
Code
237
Text
SCHEDU
LER-32
7
SCHEDU
LER-32
8
SCHEDU
LER-32
9
SCHEDU
LER-33
0
SCHEDU
LER-33
1
SCHEDU
LER-33
2
SCHEDU
LER-33
3
SCHEDU
LER-33
4
SCHEDU
LER-33
5
SCHEDU
LER-33
6
SCHEDU
LER-33
7
SCHEDU
LER-33
8
SCHEDU
LER-33
9
SCHEDU
LER-34
0
SCHEDU
LER-34
2
SCHEDU
LER-34
3
August 2014
Code
238
Text
SCHEDU
LER-34
4
SCHEDU
LER-34
5
SCHEDU
LER-34
6
SCHEDU
LER-34
7
SCHEDU
LER-34
8
SCHEDU
LER-34
9
SCHEDU
LER-35
0
SCHEDU
LER-35
1
SCHEDU
LER-35
3
SCHEDU
LER-35
4
SCHEDU
LER-35
5
SCHEDU
LER-35
7
SCHEDU
LER-35
8
SCHEDU
LER-35
9
SCHEDU
LER-36
0
SCHEDU
LER-36
1
August 2014
Code
239
Text
SCHEDU
LER-36
2
SCHEDU
LER-36
3
SCHEDU
LER-36
5
SCHEDU
LER-36
7
SCHEDU
LER-36
8
SCHEDU
LER-36
9
SCHEDU
LER-37
0
SCHEDU
LER-37
1
SCHEDU
LER-37
2
SCHEDU
LER-37
3
SCHEDU
LER-37
4
SCHEDU
LER-37
5
SCHEDU
LER-37
6
SCHEDU
LER-37
7
SCHEDU
LER-37
8
SCHEDU
LER-37
9
August 2014
Code
240
Text
SCHEDU
LER-38
0
SCHEDU
LER-38
1
SCHEDU
LER-38
4
SCHEDU
LER-38
5
SCHEDU
LER-38
6
SCHEDU
LER-38
9
SCHEDU
LER-39
0
SCHEDU
LER-39
1
SCHEDU
LER-39
2
SCHEDU
LER-39
3
SCHEDU
LER-39
4
SCHEDU
LER-39
6
SCHEDU
LER-39
7
SCHEDU
LER-39
8
SCHEDU
LER-39
9
SCHEDU
LER-40
1
August 2014
Code
241
Text
SCHEDU
LER-40
3
SCHEDU
LER-40
5
SCHEDU
LER-40
6
SCHEDU
LER-40
7
SCHEDU
LER-40
8
SCHEDU
LER-40
9
SCHEDU
LER-41
2
SCHEDU
LER-41
3
SCHEDU
LER-41
4
SCHEDU
LER-41
5
SCHEDU
LER-41
6
SCHEDU
LER-41
7
SCHEDU
LER-41
9
SCHEDU
LER-42
0
SCHEDU
LER-42
2
SCHEDU
LER-42
4
August 2014
Code
242
Text
SCHEDU
LER-42
6
SCHEDU
LER-42
7
SCHEDU
LER-42
8
SCHEDU
LER-42
9
SCHEDU
LER-43
0
SCHEDU
LER-43
1
SCHEDU
LER-43
2
SCHEDU
LER-43
3
SCHEDU
LER-43
4
SCHEDU
LER-43
5
SCHEDU
LER-43
6
SCHEDU
LER-43
7
SCHEDU
LER-43
8
SCHEDU
LER-43
9
SCHEDU
LER-44
0
SCHEDU
LER-44
1
August 2014
Code
243
Text
SCHEDU
LER-44
2
SCHEDU
LER-44
3
SCHEDU
LER-44
5
SCHEDU
LER-44
6
SCHEDU
LER-44
7
SCHEDU
LER-44
8
SCHEDU
LER-44
9
SCHEDU
LER-45
0
SCHEDU
LER-45
1
SCHEDU
LER-45
2
SCHEDU
LER-45
3
SCHEDU
LER-45
4
SCHEDU
LER-45
5
SCHEDU
LER-45
6
SCHEDU
LER-45
7
SCHEDU
LER-45
8
August 2014
Code
244
Text
SCHEDU
LER-45
9
SCHEDU
LER-46
0
SCHEDU
LER-46
1
SCHEDU
LER-46
2
SCHEDU
LER-46
3
SCHEDU
LER-46
4
SCHEDU
LER-46
5
SCHEDU
LER-46
6
SCHEDU
LER-46
7
SCHEDU
LER-46
8
SCHEDU
LER-46
9
SCHEDU
LER-47
0
SCHEDU
LER-47
1
SCHEDU
LER-47
2
SCHEDU
LER-47
3
SCHEDU
LER-47
4
August 2014
Code
245
Text
SCHEDU
LER-47
5
SCHEDU
LER-47
7
SCHEDU
LER-47
8
SCHEDU
LER-47
9
SCHEDU
LER-48
0
SCHEDU
LER-48
1
SCHEDU
LER-48
2
SCHEDU
LER-48
3
SCHEDU
LER-48
4
SCHEDU
LER-48
5
SCHEDU
LER-48
6
SCHEDU
LER-90
0
Scheduler (1) startet mit (2), pid=(3)
SCHEDU
LER-90
2
SCHEDU
LER-90
4
Die Tasks haben (1)s sich zu beenden
SCHEDU
LER-90
6
SCHEDU
LER-90
7
Datenbank wird geöffnet(1)
August 2014
Code
Text
SCHEDU
LER-90
8
Datenbank-Tabelle (1) wird um die Spalte (2) erweitert: (3)
SCHEDU
LER-90
9
Datenbank-Tabelle (1) wird eingerichtet
246
SCHEDU
LER-91
2
SCHEDU
LER-91
3
Bisherige Historie ist archiviert worden unter (1)
SCHEDU
LER-91
4
SCHEDU
LER-91
5
SCHEDU
LER-91
6
idle_timeout ist abgelaufen, Task beendet sich
SCHEDU
LER-91
7
Zu startende Task aus Datenbank geladen: id=(1) start_at=(2)
SCHEDU
LER-91
8
SCHEDU
LER-91
9
Task (1) in Warteschlange eingereiht
SCHEDU
LER-92
0
Skript wird erneut gelesen (<include> wird erneut ausgefhrt)
SCHEDU
LER-92
1
SCHEDU
LER-92
2
Keine weitere Periode
SCHEDU
LER-92
3
Wiederholung wegen delay_after_error: (1)
SCHEDU
LER-92
4
Erster Start zu Beginn der Periode: (1)
SCHEDU
LER-92
5
Wiederholung wegen spooler_job.repeat=(1): (2)
August 2014
Code
Text
SCHEDU
LER-92
6
Nächste Wiederholung wegen <period repeat="(1)">: (2)
SCHEDU
LER-92
7
Nächste Startzeit wird bestimmt zu Beginn der nächsten Periode: (1)
SCHEDU
LER-92
8
Nächster single_start (1)
SCHEDU
LER-93
0
Task (1) gestartet, Anlass: (2)
SCHEDU
LER-93
1
state=(1)
SCHEDU
LER-93
3
TCP-Verbindung angenommen
247
SCHEDU
LER-93
4
SCHEDU
LER-93
5
(1) Aufträge aus der Datenbank gelesen
SCHEDU
LER-93
6
SCHEDU
LER-93
7
SCHEDU
LER-93
8
Auftrag wird ausgeführt um (1)
SCHEDU
LER-93
9
Auftrag mit gleicher Id wird ersetzt: (1)
SCHEDU
LER-94
0
Auftrag wird aus der Jobkette entfernt
SCHEDU
LER-94
1
Auftrag wird aus der Jobkette entfernt, aber weiterhin von (1) ausgeführt
SCHEDU
LER-94
2
add_or_replace_order(): Auftrag wird verzögert bis (1) (2) ausgeführt hat
SCHEDU
LER-94
3
(1) mal zurückgestellt. Der Auftrag wechselt in den Fehlerzustand
August 2014
Code
Text
SCHEDU
LER-94
4
Kein weiterer Job in der Jobkette, der Auftrag wird mit state=(1) wiederholt um (2)
SCHEDU
LER-94
5
Kein weiterer Job in der Jobkette, der Auftrag ist erledigt
SCHEDU
LER-94
6
setback(): Auftrag zum (1). Mal zurückgestellt, bis (2)
SCHEDU
LER-94
7
setback(): Auftrag zum (1). Mal zurückgestellt, das ist über dem Maximum (2) des Jobs
SCHEDU
LER-94
8
Prozess (1) gestartet
248
SCHEDU
LER-94
9
SCHEDU
LER-95
0
Scheduler ist registriert
SCHEDU
LER-95
1
Sommerzeit beginnt
SCHEDU
LER-95
2
Winterzeit beginnt
SCHEDU
LER-95
3
Noch (1) Sekunden schlafen ...
SCHEDU
LER-95
4
XSLT-Stylesheet (1)="(2)" liefert:
SCHEDU
LER-95
5
UDP-Nachricht von (1): (2)
SCHEDU
LER-95
6
Scheduler erwartet Kommandos über (1)-Port (2)
SCHEDU
LER-95
7
Datenbank wird geschlossen
SCHEDU
LER-95
8
(1) Sekunden warten bevor Datenbank erneut geöffnet wird ...
SCHEDU
LER-95
9
Historie wird von Datenbank auf Dateien umgeschaltet
August 2014
Code
249
Text
SCHEDU
LER-96
0
SCHEDU
LER-96
1
SCHEDU
LER-96
2
SCHEDU
LER-96
3
SCHEDU
LER-96
4
Neuer (1)
Der Web-Service hat einen Auftrag erzeugt und der Jobkette übergeben.
SCHEDU
LER-96
5
SCHEDU
LER-96
6
SCHEDU
LER-96
7
SCHEDU
LER-96
8
SCHEDU
LER-96
9
SCHEDU
LER-97
0
SCHEDU
LER-97
2
SCHEDU
LER-97
3
SCHEDU
LER-97
4
SCHEDU
LER-97
5
SCHEDU
LER-97
6
August 2014
Code
250
Text
SCHEDU
LER-97
7
SCHEDU
LER-97
8
SCHEDU
LER-97
9
SCHEDU
LER-98
0
SCHEDU
LER-98
1
SCHEDU
LER-98
2
SCHEDU
LER-98
3
SCHEDU
LER-98
4
SCHEDU
LER-98
5
SCHEDU
LER-98
6
SCHEDU
LER-98
7
SCHEDU
LER-98
9
SCHEDU
LER-99
0
SCHEDU
LER-99
1
SCHEDU
LER-99
2
SCHEDU
LER-99
4
August 2014
Code
251
Text
SCHEDU
LER-99
5
SCHEDU
LER-99
6
SCHEDU
LER-99
7
SCHEDU
LER-99
9
Scheduler ordentlich beendet
SCHEDU
LER-80
5
SCHEDU
LER-80
6
SCHEDU
LER-80
7
SCHEDU
LER-80
9
SCHEDU
LER-81
1
SCHEDU
LER-81
2
SCHEDU
LER-81
3
SCHEDU
LER-81
4
SCHEDU
LER-81
5
SCHEDU
LER-81
6
SCHEDU
LER-81
7
SCHEDU
LER-81
9
August 2014
Code
252
Text
SCHEDU
LER-82
0
SCHEDU
LER-82
1
SCHEDU
LER-82
2
SCHEDU
LER-82
3
SCHEDU
LER-82
5
SCHEDU
LER-82
6
SCHEDU
LER-82
7
SCHEDU
LER-82
9
SCHEDU
LER-83
0
SCHEDU
LER-83
1
SCHEDU
LER-83
2
SCHEDU
LER-83
3
SCHEDU
LER-83
4
SCHEDU
LER-83
5
SCHEDU
LER-83
6
SCHEDU
LER-83
7
August 2014
Code
253
Text
SCHEDU
LER-83
8
SCHEDU
LER-83
9
SCHEDU
LER-84
1
SCHEDU
LER-84
2
SCHEDU
LER-84
3
SCHEDU
LER-84
4
SCHEDU
LER-84
5
SCHEDU
LER-84
6
SCHEDU
LER-84
7
SCHEDU
LER-84
8
SCHEDU
LER-84
9
SCHEDU
LER-85
0
SCHEDU
LER-85
1
SCHEDU
LER-85
2
SCHEDU
LER-85
3
SCHEDU
LER-85
4
August 2014
Code
254
Text
SCHEDU
LER-85
5
SCHEDU
LER-85
6
SCHEDU
LER-85
7
SCHEDU
LER-85
8
SCHEDU
LER-85
9
SCHEDU
LER-86
0
SCHEDU
LER-86
1
SCHEDU
LER-86
2
SCHEDU
LER-86
3
SCHEDU
LER-87
1
SCHEDU
LER-87
2
SCHEDU
LER-87
3
SCHEDU
LER-87
4
SCHEDU
LER-87
5
SCHEDU
LER-87
6
SCHEDU
LER-87
7
August 2014
Code
255
Text
SCHEDU
LER-87
8
SCHEDU
LER-87
9
SCHEDU
LER-88
0
SCHEDU
LER-88
1
SCHEDU
LER-88
2
SCHEDU
LER-88
4
SCHEDU
LER-88
5
SCHEDU
LER-88
6
SCHEDU
LER-88
7
SCHEDU
LER-88
8
SCHEDU
LER-88
9
SCHEDU
LER-89
0
SCHEDU
LER-89
1
SCHEDU
LER-89
2
SCHEDU
LER-89
3
SCHEDU
LER-89
4
August 2014
Code
256
Text
SCHEDU
LER-89
5
SCHEDU
LER-89
7
SCHEDU
LER-89
8
SCHEDU
LER-89
9
SCHEDU
LER-70
1
SCHEDU
LER-70
2
SCHEDU
LER-70
3
SCHEDU
LER-70
4
SCHEDU
LER-70
5
SCHEDU
LER-70
6
SCHEDU
LER-70
7
SCHEDU
LER-70
8
SCHEDU
LER-70
9
SCHEDU
LER-71
0
SCHEDU
LER-71
1
SCHEDU
LER-71
2
August 2014
Code
257
Text
SCHEDU
LER-71
3
SCHEDU
LER-71
4
SCHEDU
LER-71
5
SCHEDU
LER-71
6
SCHEDU
LER-71
7
SCHEDU
LER-71
8
SCHEDU
LER-71
9
SCHEDU
LER-72
0
SCHEDU
LER-72
1
SCHEDU
LER-72
2
SCHEDU
LER-72
3
SCHEDU
LER-72
4
SCHEDU
LER-72
5
A.2 Messages für Paket Separate processes
Code
Text
Z-REMOTE-1 Objectserver: Fehler: (1)
00
Z-REMOTE-1 Objectserver pid=(1): TCP-Verbindung ist abgebrochen
01
August 2014
Code
258
Text
Z-REMOTE-1 Objectserver: Unbekannte Proxy-Id (1)
02
Z-REMOTE-1 Objectserver: Nicht registriertes Objekt (1)
03
Z-REMOTE-1 Objectserver: Session-Id ist nicht korrekt
04
Z-REMOTE-1 Objectserver: Session-Kommando unbekannt (Fehler in der Kommunikation)
05
Z-REMOTE-1 Objectserver: Session-Klasse unbekannt (Fehler in der Kommunikation)
06
Z-REMOTE-1 Objectserver pid=(1): Ungültige Antwort
07
Z-REMOTE-1 Objectserver: Variant-Typ (1) ist nicht übertragbar
08
Z-REMOTE-1 Objectserver: Fehler in der Kommunikation (Nachricht ist zu kurz)
09
Z-REMOTE-1 Objectserver: Zwei Operationen gleichzeitig
11
Z-REMOTE-1 Objectserver: Programm hat Ergebnis der Operation nicht übernommen: (1)
12
Z-REMOTE-1 Objectserver: Programm will Ergebnis einer anderen Operation übernehmen
13
Z-REMOTE-1 Objectserver: Programm will Ergebnis einer nicht abgeschlossenen Operation übernehmen
14
Z-REMOTE-1 Objectserver pid=(1): Nachricht mit zu großer oder ungültiger Länge (2)
15
Z-REMOTE-1 Objectserver pid=(1): Der Objektserver war nicht innerhalb der Wartezeit von (2)s bereit
18
Z-REMOTE-1 Objectserver: Gleichzeitige Operationen auf derselben Verbindung. Erste Operation: (1); Zweite
19
Operation: (2)
Z-REMOTE-1 Objectserver: Objekt-Id ist unbekannt
20
Z-REMOTE-1 Objectserver: pop_operation, aber Stack ist leer, Methode=(1)
21
Z-REMOTE-1 Objectserver pid=(1): Der Prozess ist (vom Aufrufer) abgebrochen worden
22
Z-REMOTE-1 Objectserver pid=(1): Der Prozess hat sich unerwartet beendet
23
Z-REMOTE-1 Objectserver: Benannte Parameter sind nicht möglich
24
Z-REMOTE-1 Objectserver: DISPID (1) nicht bekannt
25
Z-REMOTE-1 Objectserver: Default-Proxy für (1) kennt keine Eigenschaften
26
Z-REMOTE-1 Objectserver: Mehr Daten empfangen als angekündigt. Fehlerhafte Daten empfangen.
27
August 2014
Code
259
Text
Z-REMOTE-1 Objectserver: v.vt stimmt nicht mit SafeArrayGetVartype() überein
28
Z-REMOTE-1
29
Z-REMOTE-1
30
A.3 Messages für Paket Charset
Code
Text
Z-CHARSET-001
Unbekannte Zeichen-Codierung: (1)
Z-CHARSET-002
Zeichen-Codierung ist nicht angegeben
August 2014
Änderungsprotokoll
260
Anhang B: Änderungsprotokoll
Revision
Datum
Bemerkung
2.1.3.6332
2010-10-05
JS-448: warn_if_longer_than
Attribut korrekt verarbeiten
Die Warnung, dass eine Task länger
als geplant läuft
(warn_if_longer_than Attribut), dann
als Mail absenden, wenn der
Zeitpunkt erreicht und nicht erst am
Ende der Task. Außerdem
Behandlung der Angabe in Prozent
korrigiert (s. Jira-Eintrag).
2.1.3.6321
2010-09-29
JS-544: Port for SMTP Mail-Server
cannot be configure
Ist die Eigenschaft smtp sowohl in
sos.ini ([mail].smtp) als auch in
factory.ini [spooler].smtp leer oder
nicht angegeben, wird die
Einstellung in factory.ini [smtp]
mail.smtp.host gelöscht. In der
Dokumentation zu factory.ini [smtp]
ist ein Hinweis auf die Möglichkeit
den SMPT Port einzustellen,
aufgenommen worden.
2.1.3.6308
2010-09-27
JS-456: An persistent order with
single start far in the future will be
deleted, wenn an error occurs
Hat ein Job eine Periode, der
Job-Scheduler startet vor
Periodenbeginn und es befinden
sich zum Start im
Fileorders-Verzeichnis Dateien,
dann wurden dafür keine Aufräge
erzeugt.
2.1.3.6308
2010-09-27
JS-551: Inaktivieren von Jobs
Das Job-Element der XML
Konfiguration hat ein neues Attribut
"enabled". Es kann die Werte yes,
no annehmen. Der Wert "no"
bewirkt, dass intern der Job
gestoppt wird. Die XML-Antwort
enthält auch dieses Attribut und
ermöglicht es dem Operations GUI
diesen Job-Status abweichend vom
gestoppt-Status entsprechend
darzustellen.
August 2014
Änderungsprotokoll
261
Revision
Datum
Bemerkung
2.1.3.6304
2010-09-23
JS-552: Aufträge im Status
suspended sollen bei Änderung
der Konfiguration nicht in Status
resumed wechseln
Aufträge im Status suspended sollen
dort bleiben, auch wenn die
Konfigurationsdatei geändert wird.
2.1.3.6299
2010-09-22
JS-463: Fileorders will not be
handled when the first job in job
chain has a period
Hat ein Job eine Periode, der
Job-Scheduler startet vor
Periodenbeginn und es befinden
sich zum Start im
Fileorders-Verzeichnis Dateien,
dann wurden dafür keine Aufräge
erzeugt.
2.1.3.6295
2010-09-21
JS-425: Im Fehlerfall werden jetzt
nur noch mails versendet, wenn
mail_on_error=yes gesetzt ist
Bei Auftreten eines Fehlers werden
jetzt nur noch Mail versendet, wenn
mail_on_error=yes gesetzt ist. Ein
implizites Setzen von mail_on_error
durch die Angabe von
mail_on_warn=yes findet nicht mehr
statt.
2.1.3.6295
2010-09-21
JS-425: Im Fehlerfall werden jetzt
nur noch mails versendet, wenn
mail_on_error=yes gesetzt ist
Bei Auftreten eines Fehlers werden
jetzt nur noch Mail versendet, wenn
mail_on_error=yes gesetzt ist. Ein
implizites Setzen von mail_on_error
durch die Angabe von
mail_on_warn=yes findet nicht mehr
statt.
August 2014
Änderungsprotokoll
262
Revision
Datum
Bemerkung
2.1.3.6269
2010-09-02
JS-563: exit_code ist jetzt in
spooler_task_after abrufbar
Über spooler_task-after() ist jetzt der
exit_code von spooler_process()
abrufbar. Eine Abfrage des
exit_code in spooler_process_after()
ist nicht möglich, da die task in
dieser Stelle noch nicht beendet ist
und der exit_code damit zu diesem
Zeitpunkt noch nicht zur Verfügung
steht. Der in spooler_process()
gesetzte exit_code kann
überschrieben in zurückgesetzt
werden.
2.1.2.6164
2010-07-07
JS-538: Neues Attribut
max_orders steuert den
Parallellauf von Jobketten
Für das Element job_chain wurde
das Attribut max_orders eingeführt.
Es bestimmt, wie viele Orders
parallel diese Jobkette ausführen
können. Fehlt dieses Attribut können
es beliebig viele sein.
max_orders="1" führt die gesamte
Jobkette exklusiv für eine Order aus,
bevor die nächste Order für diese
Jobkette starten kann.
2.1.1.6132
2010-06-22
JS-462: Die
Kommandozeilenoption
configuration-directory (live
folder) steht zur Verfügung wie
dokumentiert
Das live Verzeichnis kann mit der
Kommandozeilenoption
configuration-directory angegeben
werden.
2.1.1.6103
2010-05-28
JS-506: Kommando <show_state
what='folders no_subfolder'>
zeigt Namen der Unterordner.
Das Kommando <show_state
what='folders no_subfolder'> liefert
die Namen der Unterordner, aber
nicht deren Inhalte.
August 2014
Änderungsprotokoll
263
Revision
Datum
Bemerkung
2.1.1.6101
2010-05-07
JS-343: Die Angabe von
@absolute_repeat berücksichtigt
jetzt auch die erste Startzeit.
Wurde @absolute_repeat in einer
run_time angegeben, ist unter
bestimmten Umständen die erste
Startzeit nicht korrekt ermittelt
worden.
2.1.1.6096
2010-05-04
JS-380: Jobscheduler 'friert' nicht
mehr ein, wenn Job auf 'suspend'
gesetzt wird.
Bei API Jobs kam es gelegentlich zu
dem Problem, dass der gesamte
Jobscheduler 'eingefroren' ist, wenn
ein Job auf 'suspend' gesetzt
worden ist. Das ist immer dann
passiert, wenn das 'suspend'
innerhalb einer Operation
(spooler_start, spooler_process ...)
ausgeführt worden ist.
2.1.1.6089
2010-04-28
JS-481: Nicht mehr benötigte TCP
Verbindungen werden jetzt
zuverlässig freigegeben.
Beim Öffnen einer neuen TCP
Verbindung wird geprüft, ob es
bereits eine nicht mehr benötigte
Verbindung für diesen host/port
registriert ist.
2.1.1.6078
2010-04-27
JS-471: Mehr als 64 paralle
Prozesse unter Windows möglich.
Unter Windows besteaht bisher die
Beschränkung auf 64 parallel
laufende Prozesse. Die mögliche
Anzahl ist jetzt analog zu der unter
Unix.
2.1.0.6078
2010-04-13
JS-409: Startzeitpunkt eines Jobs
kann jetzt beliebig festgelegt
werden.
Der Startzeitpunkt eines Jobs kann
jetzt um mehr als 24 Stunden in die
Zukunft gelegt werden.
August 2014
Änderungsprotokoll
264
Revision
Datum
Bemerkung
2.1.0.6078
2010-04-13
JS-444: Auch für Monitore werden
Includes in der laufenden
Scheduler-Instanz aufgelöst und
an den Monitor-Prozess
übergeben.
Die mit dem Attribute live_file
bezeichnete Datei wird jetzt bei
Änderung nachgeladen, dazu muss
die Datei LOKAL abgelegt sein.
2.1.0.6078
2010-04-13
JS-457: Zeitstempel der
Konfigurationsdateien werden
jetzt als UTC gekennzeichnet
Der Zeitstempel der
Konfigurationsdateien werden jetzt
als UTC gekennzeichnet.
2.1.0.6070
2010-03-23
JS-421:
SCHEDULER_RETURN_VALUES
bei Verwendung von Monitoren
unter UNIX möglich
2.1.0.6065
2010-04-13
JS-421: Umgebungsvariable
zwischen Scripten werden jetzt
richtig übergeben.
Shell-Scripte können
Umgebungsvariablen, die von
vorhergehenden Scripten gesetzt
worden sind, jetzt korrekt auslesen.
2.0.223.6010
2009-06-12
Neue API-Aufrufe
Order.setback_count und
Job.setback_max
•
•
2.0.222.6007
2009-05-07
Order.setback_count
Job.setback_max
<job warn_if_shorter_than und
warn_if_longer_than>
Wenn die Dauer eines Jobschritts
von einer Vorgabe abweicht, gibt der
JobScheduler eine Warnung aus.
•
•
2.0.221.5985
2009-03-20
<job
warn_if_shorter_than="…">
<job
warn_if_longer_than="…">
Windows: kill bricht alle
Kindprozesse ab
Ein <kill_task> auf einen
Shell-Job bricht auch alle Kind- und
Kindeskind-Prozesse ab, wie bereits
unter Unix.
August 2014
Änderungsprotokoll
265
Revision
Datum
Bemerkung
2.0.221.5980
2009-03-10
Monitor für Shell-Jobs
Ein <monitor> kann jetzt auch für
Nicht-API-Jobs angegeben werden.
•
<monitor>
Datenbankproblem mit der
Stunde zwischen Winter- und
Sommerzeit gelöst
2.0.220.5972
2009-03-02
Nach kill -9 wird Dauerauftrag
nicht mehr sofort beim nächsten
Scheduler-Lauf gestartet
<settings> in <job>
•
•
•
•
•
•
•
•
•
•
•
•
•
2.0.220.5970
2009-02-25
<settings>
<mail_on_error>
<mail_on_warning>
<mail_on_success>
<mail_on_process>
<
mail_on_delay_after_error
>
<log_mail_to>
<log_mail_cc>
<log_mail_bcc>
<log_level>
<history>
<history_on_process>
<history_with_log>
Scheduler als Unix-Daemon leitet
stdout/stderr in Datei um
Wie es sich für einen Daemon
gehört, schließt der JobScheduler
stdout und stderr und leitet die
Ausgaben in die Datei
scheduler.out. Diese Datei muss
beschreibbar sein.
•
2.0.219.5968
2009-01-27
Siehe Option -service
libhostjava.so im JobScheduler
für HP-UX/Itanium eingebunden
Im Gegensatz zu HP-UX/PA-RISC
ist jetzt für Itanium die
libhosthava.so in den JobScheduler
eingebunden. Damit tritt das
"com_construct-Problem" nicht mehr
auf.
August 2014
Änderungsprotokoll
266
Revision
Datum
Bemerkung
2.0.219.5966
2009-01-21
Unter Unix mit kill abgebrochene
Task führt zum Task-Fehler
Damit ist das Verhalten unter Unix
wie unter Windows.
JS-321: Backup-Scheduler
übernimmt wieder Job-, Task-,
Jobketten- und
Auftragseinstellungen
Im Betrieb mit einem
Backup-Scheduler werden die
Spalten cluster_member_id nicht
mehr gefüllt. Die Spalten werden nur
nur im Betrieb für verteilte Aufträge
gefüllt, so dass die Datensätze nur
dann den Cluster-Membern fest
zugeordnet sind.
2.0.219.5963
2008-12-12
JS-305: Zurücksetzen eines
Auftrags
•
2.0.218.5961
2008-11-18
<modify_order
action="reset">
<script language="shell">:
.cmd-Datei wird in
OEM-Codierung erstellt
•
<script language="script"
>
Windows verlangt für Batch-Dateien
die OEM-Codierung. Wenn ein
Zeichen aus <script> nicht
umgesetzt werden kann, bricht der
JobScheduler den Job mit der
Meldung SCHEDULER-471 ab. Jedoch
ignoriert der JobScheduler schon
beim Einlesen der
XML-Konfiguration Zeichen, die
nicht in Latin1 sind, siehe .
[
E
R
R
O
R
]
2.0.217.5956
2008-11-12
Not supported character
for encoding ''
JS-316: Neue
Umgebungsvariablen für
Nicht-API-Jobs
•
SCHE
DULE
R-47
1
<process>
August 2014
Änderungsprotokoll
267
Revision
Datum
Bemerkung
2.0.216.5953
2008-11-05
Transaktionsisolation für Sybase
geändert
Für Sybase ist jetzt read committed
eingestellt.
<start_job force="no">: Task
starten, ohne Job zu entstoppen
•
<start_job force="no">
Fehlermeldung
Z-ASYNC-SOCKET-001 unter
Windows korrigiert
Eine interne Sicherheitsprüfung, die
nur für Unix vorgesehen ist,
verhinderte unter Windows
gelegentlich den Start eines Jobs.
Fehler aus 2.0.214.5927 (Jobs in
der Datenbank) korrigiert
Außerdem die Spalten der Tabelle
SCHEDULER_JOB_CHAIN_NODES
verschmälert.
2.0.215.5938
2008-10-28
Kleine Korrektur der
Log-Kategorien
August 2014
Änderungsprotokoll
268
Revision
Datum
Bemerkung
2.0.215.5937
2008-10-22
Bei besonderem Lizenzsschlüssel
liefert der JobScheduler das
Datenbankkennwort
Der Lizenzschlüssel kann per <
licence.use> übergeben werden.
Daraufhin unterdrückt der
JobScheduler nicht länger in der
Antwort von <show_state> die
Zeichenfolge, die mit -password=
beginnt.
•
•
<licence.use> .
<state db="…"> .
Allgemeines zentrales
Konfigurationsverzeichnis kann
gelöscht werden
Wenn das zentrale allgemeine
Konfigurationsverzeichnis gelöscht
wird, lässt der Supervisor in allen
angeschlossenen Schedulern die
entsprechenden Objekte löschen.
•
•
2.0.214.5927
2008-10-16
<config
central_configuration_dir
ectory="…"> .
<config supervisor="…"> .
Gestoppte Jobs, Jobketten und
Jobkettenknoten bleiben über
Scheduler-Neustart hinweg
gestoppt
Der Zustand der Jobs, Jobketten
und Jobkettenknoten wird in der
Datenbank gehalten. Wenn eins
dieser drei Objekte gelöscht wird,
wird auch der dazugehörige
Datenbankeintrag gelöscht.
•
<modify_job cmd="stopped"
> . Wenn der Job wegen
Herunterfahrens des
Schedulers gestoppt wird, wird
das nicht in der Datenbank
vermerkt.
•
•
<job_chain.modify
state="stopped">
<job_chain_node.modify
action="stop"> : Der Wert
von action bleibt erhalten.
August 2014
Änderungsprotokoll
269
Revision
Datum
Bemerkung
2.0.213.5922
2008-10-07
Verschachtelte Jobketten mit
Großbuchstaben funktionieren
Großbuchstaben im Namen der
übergeordneten Jobkette konnten
den JobScheduler abbrechen
lassen. Das ist behoben. In
Jobkettennamen werden große wie
kleine Buchstaben angesehen.
In der Datenbank werden die
Jobkettennamen in Großschreibung
belassen. Aufträge werden nur
wiedergefunden, wenn die
Großschreibung sich nicht ändert.
Jobkettennamen sollten in der
Datenbank normalisiert, also
kleingeschrieben, gespeichert
werden.
2.0.213.5918
2008-10-04
Hauptprotokoll im
Browser-Fenster bricht nicht
mehr ab
Das Hauptprotokoll im
Browser-Fenster bricht jetzt nicht
mehr ab. Das passierte, nachdem
das Hauptprotokoll wegen eines
Fehler beim Scheduler-Start
versendet worden ist.
August 2014
Änderungsprotokoll
270
Revision
Datum
Bemerkung
2.0.213.5914
2008-10-02
$-Substitition mit \ abschaltbar
Das Zeichen »\« vor »$« liefert das
Zeichen »$«, ohne eine Variable zu
ersetzen.
Siehe (Seite 95).
<kill_task> auf
Nicht-API-Prozessen unter Unix
bricht alle Kindprozesse ab
•
<kill_task>
Die Meldungen SCHEDULER-277 und
SCHEDULER-282 werden nicht mehr
ausgegeben.
Neue Kommandos zum Schalten
der Log-Kategorien
•
•
•
2.0.212.5882
2008-09-11
<
scheduler_log.log_categor
ies.show>
<
ies.set>
<
ies.reset>
".." ist in allen Pfaden möglich
Pfade, die auf ein Scheduler-Objekt
verweisen (Job, Jobkette usw.)
können mit ".." ins obere Verzeichnis
verweisen. Zum Beispiel in
•
2.0.211.5876
2008-09-07
<job_chain_node job="…">
Implementierung der
verschachtelten Jobketten
überarbeitet
scheduler.log zeigt Tag des
Monats in der ersten Spalte
Diagnosemeldung beim Fehlstart
eines Prozesses
Wenn ein Nicht-API-Prozess unter
Unix sich nicht starten lässt (Fehler
bei execvp), gibt der JobScheduler
die execvp-Parameterliste und die
Umgebungsvariablen aus.
•
•
<process>
August 2014
Änderungsprotokoll
271
Revision
Datum
Bemerkung
2.0.210.5864
2008-08-22
Anpassung an verschachtelte
Jobketten
<add_order state="…"> und <
add_order end_state="…"> sind
jetzt auf verschachtelte Jobketten
anwendbar.
2.0.210.5860
2008-08-14
Perl-API unter Unix
(libsosperlscript.so) verbessert
•
•
Log.level : $spooler_log->
LetProperty( 'level', ... )
funktioniert.
Die Perl-Schnittstelle versucht
jetzt, jeden unbekannten Typ
als String zu erkennen, so
dass auch folgende Sequenz
funktioniert, deren zweite
Anweisungen $a von einem
SVt_IV in einen SVt_PVIV
wandelt:
my $a = 1;
my $x = "$a";
$spooler_log->info( $a
)
Klasse Run_time für Java
ermöglicht
Run_time kann auch in Java benutzt
werden.
2.0.210.5838
2008-07-25
Neue Umgebungsvariable
SCHEDULER_TASK_ID
Siehe <process> (Seite 57).
August 2014
Änderungsprotokoll
272
Revision
Datum
Bemerkung
2.0.210.5837
2008-07-22
XML-Kommandos zum Setzen
und Lesen der
Scheduler-Parameter
•
•
•
•
<param>
<param.get>
<params>
<params.get>
Umgang mit Feiertagen: <period
when_holiday="…">
•
•
<period when_holiday="…">
<run_time
when_holiday="…">
Der JobScheduler sieht zwanzig
Jahre voraus, längstens aber bis
2038.
Wochentage, zum Beispiel
Samstag und Sonntag, als
Feiertage deklarierbar
•
<holidays><weekdays>
Aufträge mit inkludierten
Parameterdateien
<order> <params><include> ist
möglich. Bei einem dateibasierten
Auftrag kann die inkludierte Datei
überwacht werden.
<job timeout="…"> gilt auch für
Nicht-API-Jobs
•
2.0.208.5817
2008-07-02
<job timeout="…">
Dateiaufträge beschleunigt
Wenn der erste Job der Jobkette
mehrere Tasks erlaubt ( <job
tasks="…"> ), füttert der
JobScheduler die Jobkette jetzt
schneller mit den Dateiaufträgen..
August 2014
Änderungsprotokoll
273
Revision
Datum
Bemerkung
2.0.208.5814
2008-06-30
Doppeltes "To:" aus
Mail-Verzeichnis entfernt
Die im eMail-Verzeichnis (
factory.ini (Abschnitt [spooler],
Eintrag mail_queue_dir= …))
abgelegten Dateien enthielten zur
Kompatibilität mit einer alten
Mail-Software eine zusätzlich
"To:"-Zeile. Die Zeile wird nicht mehr
eingefügt. Es sollte eine aktuelle
Mail-Software (mail.jar oder
w3jmail44.dll) eingesetzt werden.
Variable_set.set_value() auch in
Java möglich
Der schreibende Aufruf von
Variable_set.value ist jetzt auch
in Java möglich.
Der Aufruf ist damit durchgängig
eingeführt und ersetzt
Variable_set.var , der in
JavaScript nicht möglich ist.
spooler_log.new_filename
Log.new_filename kann jetzt auch
unter Unix verwendet werden.
Dokumentation erweitert
Log.mail_on_process ergänzt;
Texte aus settings.xml werden auf
den API-Seiten gezeigt.
2.0.208.5811
2008-06-26
API um Sperren erweitert
•
•
•
•
Task.try_hold_lock()
Task.try_hold_lock_non_ex
clusive()
Task.call_me_again_when_l
ocks_available()
Antwort-Element <task
state="…"> : neue Zustände
opening,
opening_waiting_for_locks
und
running_waiting_for_locks.
2.0.207.5799
2008-06-09
Auf Microsoft Visual Studio 2008
umgestellt
August 2014
Änderungsprotokoll
274
Revision
Datum
Bemerkung
2.0.206.5789
2008-05-25
spidermonkey.dll und
libspidermoneky.so: Verhalten bei
Boole'sch true verbessert
Boole'sch true wird jetzt immer als
derselbe interne Wert geliefert,
sodass folgender Code funktioniert:
spooler_log.mail_on_success
= true;
var a =
spooler_log.mail_on_success
;
if( a != true )
spooler_log.error( a + "!="
+ true ); // Okay ab
Spidermonkey 1.7.0.5789
Dokumentation korrigiert
•
•
Log.last ist nur lesbar.
Log.last_error_line ist nur
lesbar.
2.0.206.5787
2008-05-19
Umstellung der Datenbankspalte
SCHEDULER_HISTORY.END_TIM
E auf NULL
Anpassung an MySQL 5, das
"0000-00-00" für fehlenden Feldwert
schreibt, wenn die Spalte mit NOT
NULL deklariert ist.
Order.priority wird jetzt richtig
interpretiert
•
Order.priority : Höhere
Priorität ordnet einen Auftrag
vorne in die
Auftragswarteschlange ein.
Verteilte Aufträge schreiben
wieder nur einen Historiensatz
Seit Version 2.0.194.8488
(2008-01-05) schrieben verteilte
Aufträge für jeden Schritt einen
Historiensatz. Das ist korrigiert.
August 2014
Änderungsprotokoll
275
Revision
Datum
Bemerkung
2.0.205.5781
2008-05-09
Order.job deleted
•
Order .job ausgebaut.
<show_state what="source"
•
<show_state what="source"
> zeigt XML-Quellen
<schedule.remove> entfernt ein
Schedule
•
<schedule.remove> entfernt
ein Schedule
2.0.204.5773
2008-05-06
JS-279: Weitere
Umgebungsvariablen für
Nicht-API-Jobs
•
2.0.203.5764
2008-04-29
<process>
JS-271: XML-Dokument in einem
Konfigurationsverzeichnis
anlegen: <modify_hot_folder>
•
<modify_hot_folder>
JS-245: Neues XML-Element <
schedule>: Benannte <run_time>
•
•
•
<schedule>
<schedules>
<show_state
what="schedules">
JS-274: Job_chain.title
•
•
2.0.202.5728
2008-04-21
<job_chain title="…">
Job_chain.title
Problem beim gleichzeitigen Start
zweier Cluster-Scheduler
behoben
Beim gleichzeitigen Start zweier
JobScheduler desselben Clusters
konnte ein JobScheduler beim Start
hängen bleiben. Das ist behoben.
2.0.202.5723
2008-04-18
JS-265: Order.end_state
•
•
•
•
2.0.201.5696
2008-04-02
<order end_state="…">
<add_order end_state="…">
<modify_order
end_state="…">
Order.end_state
Anpassungen an Sybase
Adaptive Server Enterprise
August 2014
Änderungsprotokoll
276
Revision
Datum
Bemerkung
2.0.201.5692
2008-03-31
JS-60: <script> </script> wirkt wie
<script/>
Leere Textknoten (nur Leerzeichen,
Zeilenwechsel und Tabulator) im
XML-Element <script> ignoriert der
Scheduler. Wenn das XML-Element
<script> nur einen leeren
Textknoten enthält, gilt das als nicht
angegebener Quell-Code.
2.0.201.5684
2008-03-14
Jobprotokolldatei wird nicht mehr
offengehalten
Wenn der JobScheduler etwas ins
Jobprotokoll schreibt, öffnet er die
Datei zuvor und schließt sie danach
wieder.
2.0.201.5679
2008-03-13
JS-150: Anpassung der Spalte
SCHEDULER_ORDER_HISTORY.E
ND_TIME in einer
Access-Datenbank
Die Datenbank-Spalte
SCHEDULER_ORDER_HISTORY.END_TI
ME muss mit JS-150 NULL
aufnehmen können. Der
JobScheduler prüft das beim Start
und ändert die Spalte. Access
verlangt dazu ein besonders
Verfahren: Der JobScheduler legt
eine Kopie der Spalte an, die er
dann in die erneuerte zurückkopiert.
Diese Operation, die einmal beim
Start des Schedulers durchgeführt
wird, sollte nicht unterbrochen
werden.
2.0.201.5678
2008-03-07
JS-150: Neue Spalten ERROR,
ERROR_CODE und ERROR_TEXT
in der Auftragsschritthistorie
Bei einem Task-Fehler werden die
neuen Felder der Tabelle
SCHEDULER_ORDER_STEP_HISTORY
gefüllt.
August 2014
Änderungsprotokoll
277
Revision
Datum
Bemerkung
2.0.201.5671
2008-02-28
Attribut day= lässt bereits
angegebene Tage zu
In <weekdays> und <monthdays>
können Tage wiederholt angegeben
werden. Der JobScheduler mischt
die Perioden. Die Meldung
SCHEDULER-444 entfällt.
•
•
•
<weekdays> <day day="…">
<monthdays> <day day="…">
<ultimos> <day day="…">
<monthdays>
<day day="12 13">
<period
single_start="13:12"/>
</day>
<day day="12">
<period
single_start="12:00"/>
</day>
</monthdays>
Das ergibt für den 12. eines Monats
zwei Startzeiten: 12:00 und 13:12.
August 2014
Änderungsprotokoll
278
Revision
Datum
Bemerkung
2.0.200.5665
2008-02-25
<include include_path="...">:
Umgebungsvariablen können
abgerufen werden
•
<config
include_path="$HOME/...">
JS-215: <params> mit <include>
In Dateien abgelegte Parameter
können inkludiert werden. Mit einem
XPath-Ausdruck lassen sich die <
param> adressieren.
•
<params><include>
JS-240: <include live_file="…">
•
<include live_file="…">
Das neue Attribut live_file= kann
verwendet werden direkt unter
•
•
•
•
•
•
<job><description>
<job><params>
<job><run_time>
<job> <run_time><holidays>
<holidays>
<script>
Unter <job><params> führt eine
Änderung der mit live_file=
angegebenen Datei zum Erneuten
Lesen des Jobs.
JS-222: Neuer Aufruf
job.folder_path()
•
Job.folder_path
August 2014
Änderungsprotokoll
279
Revision
Datum
Bemerkung
2.0.199.5618
2008-02-11
JS-221: Cache für zentrale
Konfiguration und parallele lokale
Konfiguration
Eine vom Supervisor geladene
zentrale Konfiguration (Seite 81)
wird im neuen Verzeichnis
./config/cache gehalten.
Der JobScheduler mischt die
zentrale mit der lokalen
Konfiguration. Ein zentral
konfiguriertes Objekt kann nicht
lokal überschrieben werden.
Unter Windows sind wegen der
weiteren Verzeichnisüberwachung
noch 25 TCP-Verbindungen
möglich.
•
2.0.198.5596
2008-02-04
JS-222: Neue Aufrufe
Spooler.configuration_directory
und Job.folder_path
•
•
<config supervisor="…">
Spooler.configuration_dir
ectory
Job.configuration_directo
ry
August 2014
Änderungsprotokoll
280
Revision
Datum
Bemerkung
2.0.197.5594
2008-02-04
JS-255: Prozessklassen auch für
Nicht-API Jobs möglich
Nicht-API Jobs können einer
Prozessklasse zugeordnet werden
(Default: die Prozessklasse mit dem
leeren Namen ""). D.h. die in der
Prozessklasse eingestellte
Begrenzung der Prozesse wirkt
auch auf Nicht-API Jobs.
Die voreingestellte Begrenzung ist
von 10 auf 30 erhöht worden.
•
•
<job process_class="…">
<process_class
max_processes="30">
JS-213: Nicht-API Jobs lassen
sich unter entferntem
JobScheduler ausführen
Für Nicht-API Jobs lässt sich eine
Prozessklasse mit entferntem
JobScheduler angeben.
•
•
•
<process>
<script language="script"
>
<process_class
remote_scheduler="…">
JS-205: Job.name liefert den Pfad
des Jobs
Job.name liefert nicht mehr den
Namen, sondern den Pfad des Jobs.
JS-204: Zentrale Konfiguration
Ein als Supervisor laufender
JobScheduler kann
Konfigurationsdateien und
-verzeichnisse einer zentralen
Konfiguration (Seite 81) für andere
JobScheduler bereitstellen.
Änderungen werden laufend
übernommen.
•
•
<config
central_configuration_dir
ectory="…">
•
(Seite 81)
JS-203: stdout und stderr werden
laufend ins Protokoll
übernommen
August 2014
Änderungsprotokoll
Revision
281
Datum
Bemerkung
Ausgaben nach stdout und stderr
werden nicht mehr erst am Ende der
Task, sondern laufend übernommen.
Das geschieht sekündlich. Wenn
keine Ausgabe kommt, verlängert
sich die Periode auf zehn Sekunden.
Bei API-Jobs, deren Tasks auf
einem entfernten JobScheduler
ablaufen ( <process_class
remote_scheduler="…"> ), werden
Ausgaben nach Beendigung des
Skripts (also kurz vor Beendigung
des Prozesses) nicht übernommen.
Datenbank Adaptive Server
Enterprise von Sybase wird
unterstützt
Für alle Datenbanken sind die
Spalten für Auftragskennungen und
Jobkettenamen von 255 auf 250
Zeichen verkürzt worden.
JS-227: Mit <run_time>
wiederholte Aufträge werden nach
Mitternacht fortgesetzt
Bislang endeten die Aufträge um
24:00. (Eine Folge von JS-123 im
Oktober 2007.)
2.0.196.5515
2008-01-14
JobScheduler für AIX
bereitgestellt
2.0.196.5515
2008-01-14
JS-219: HTML-Seiten über
virtuelles Verzeichnis eines
HTTP-Proxys möglich
2.0.196.5515
2008-01-13
JS-220: Spidermonkey 1.7
Das Modul libspidermonkey.so
bzw. spidermonkey.dll ist auf die
Version 1.7.0 umgestellt.
SpiderMonkey 1.7.0 Change Log
2.0.195.5499
2008-01-11
JS-212: Element <params> unter
<config>
Mit <params> unter <config> lassen
sich Scheduler-weite Parameter
setzen, die mit Spooler.variables
abgerufen werden können.
August 2014
Änderungsprotokoll
282
Revision
Datum
Bemerkung
2.0.194.5488
2008-01-05
JS-150: Neue Datenbanktabelle
scheduler_order_step_history
Die Tabelle nimmt für jeden
Auftragsschritt einen Satz auf. Der
Satz wird zu Beginn des Schritts
geschrieben und am Ende
vervollständigt.
Die Tabelle
scheduler_order_history wird
jetzt schon mit dem ersten
Auftragsschritt beschrieben und
nach der Ausführung des Auftrags
vervollständigt.
Die Spalte
scheduler_order_history.end_ti
me nimmt jetzt NULL auf.
Die Tabelle
scheduler_order_step_history
hat folgenden Aufbau (Syntax für
PostgresQL):
CREATE TABLE
SCHEDULER_ORDER_STEP_HISTOR
Y
(
"HISTORY_ID" integer
not null,
//
Verweis zu
SCHEDULER_ORDER_HISTORY.HIS
TORY_ID
"STEP"
integer
not null,
// 1, 2,
3, ...
"TASK_ID"
integer
not null,
//
Verweis zu
SCHEDULER_TASKS.TASK_ID
"STATE"
varchar(100) not null,
// Auftragszustand
"START_TIME" timestamp
not null,
"END_TIME"
timestamp,
primary key(
"HISTORY_ID", "STEP" )
)
•
factory.ini (Abschnitt
[spooler], Eintrag
db_order_step_history_tab
le= …)
August 2014
Änderungsprotokoll
283
Revision
Datum
Bemerkung
2.0.194.5476
2008-01-05
Neue Datenbankspalte
scheduler_history.pid
Die neue Datenbankspalte
scheduler_history.pid nimmt die
Prozesskennung des
Betriebssystems auf.
Datenbank-Deklaration:
"PID" integer
2.0.193.5476
2008-01-02
Zentrale Konfiguration
<config
central_configuration_director
y="…">
Der Supervisor kann jetzt die lokalen
Konfigurationen mit einer zentralen
Konfiguration (Seite 81)
überschreiben.
•
•
2.0.192.5444
2007-12-21
<config
configuration_directory="
…">
<file_order_source> ohne regex=
konnte JobScheduler abbrechen
Bei <file_order_source> mit
leerem Attribut regex= konnte der
JobScheduler abbrechen, nachdem
ein Dateiname auf die Schwarze
Liste gesetzt worden ist (weil er
nach Auftragsführung noch
vorhanden ist). Das ist behoben.
Zwischenlösung im bisherigen
JobScheduler: regex="."
2.0.192.5442
2007-12-20
JS-178: Große Antwort einer
API-Methode ließ Task hängen
Ein Aufruf von z.B.
Spooler.execute_xml() mit einer
großen Rückgabe (etwa >100KB)
konnte hängen bleiben. Das ist
behoben.
August 2014
Änderungsprotokoll
284
Revision
Datum
Bemerkung
2.0.192.5438
2007-12-19
Änderung einer
Job-Konfiguration unter Unix hält
Dateiaufträge nicht mehr an
Unter Unix hielt eine Änderung der
Konfiguration des ersten Jobs der
Jobkette nach <file_order_source
> die Dateiauftragsquelle an. Das ist
behoben.
<show_order>
Das Kommando <show_order>
konnte den JobScheduler
abbrechen, wenn der Auftrag nicht
mehr vorhanden war. Das ist
behoben.
JS-208: modify_job cmd='reread'
als Null-Operation wieder
eingebaut
Das Kommando ist wirkungslos, weil
die <include> ohnehin bei jedem
Job-Start erneut gelesen werden.
2.0.192.5429
2007-12-11
JS-52: XML-Fehler beim Lesen
des Auftrags-XML-Dokument
Je nach Blockung der Datenbank
konnte beim Lesen eines Auftrags
ein XML-Fehler auftreten. Das sollte
behoben sein.
2.0.192.5428
2007-12-11
JS-206: <script language="perl">
meldet Fehler mit Zeilennummer
und Pfad
Ein Fehler in einem ( <script
language="perl"> ) wird jetzt in der
Regel mit Zeilennummer und Pfad
(bei <include> ) gemeldet.
Unter Unix erscheint die Position in
der stderr-Ausgabe.
Unter Windows wird bei machen
Fehlern ("undefined value") die
Zeilennummer der ersten Zeile des
Abschnitts, aber nicht der
fehlerhaften Zeile gemeldet. Das
scheint eine Besonderheit von
ActivePerl zu sein.
August 2014
Änderungsprotokoll
285
Revision
Datum
Bemerkung
2.0.192.5407
2007-11-30
Job.name liefert den ganzen Pfad
Job.name liefert nicht mehr den
Namen, sondern den Pfad des Jobs
ohne beginnenden Schrägstrich.
2.0.192.5402
2007-11-27
Datenbanktest auf ASCII-Zeichen
reduziert
Weil manche
PostgresQL-Installationen Latin-1
nicht unterstützen, prüft der
JobScheduler nur noch den
ASCII-Zeichenvorrat (Basic Latin).
2.0.192.5397
2007-11-20
Variablenwerte mit
Nicht-Latin1-Zeichen
Weil Umgebungsvariablen (z.B.
ERASE) Zeichen enthalten können,
die UNICODE nicht kennt, wurden
interne XML-Dokumente ungültig.
Solche Zeichen codiert der
JobScheduler jetzt hexadezimal.
August 2014
Änderungsprotokoll
286
Revision
Datum
Bemerkung
2.0.192.5394
2007-11-18
PostgresQL wird besser
unterstützt, JobScheduler prüft
Datenbank
Beim Start führt der JobScheduler
einfache Tests des
Datenbankmoduls durch:
•
•
•
ob '\' (Backslash) korrekt
behandelt wird,
ob der Latin1-Zeichenvorrat
und die Steuerzeichen TB
(0x08), CR (0x0D) und NL
(0x0A) geschrieben und
gelesen werden können, und
ob die SQL-Anweisung
rollback auf die Tabelle
SCHEDULER_VARIABLES wirkt.
Bei einem Fehlschlag startet der
JobScheduler nicht.
[
E
R
R
O
R
]
SCHE
DULE
R-45
1
Database check failed,
database is not useable.
error
[
E
R
R
O
R
]
SCHE
DULE
R-45
2
Database does not
correctly store test
values: (written value)
(read value)
[
E
R
R
O
R
]
SCHE
DULE
R-45
3
Database does not
respect rollback
command
Entfernte Task-Ausführung:
Spooler.directory, .log_dir,
.ini_path und .include_path liefern
Werte des entfernten Schedulers
•
•
•
•
Spooler.directory
Spooler.log_dir
Spooler.ini_path
Spooler.include_path
August 2014
Änderungsprotokoll
Revision
287
Datum
Bemerkung
JS-195: Job-Historie für Jobs in
Ordnern korrigiert
<show_job what="task_history">
berücksichtigt jetzt den ganzen Pfad
des Jobs.
JS-196: Einträge in der factory.ini
auch für Jobs in Ordnern möglich
•
factory.ini (Abschnitt [job]
)
2.0.191.5386
2007-11-15
Löschen der Jobkette, auf die
eine übergeordnete verweist,
liefert keine Warnung mehr
Wenn eine Jobkette gelöscht wird,
auf die eine übergeordnete Jobkette
verweist, wird letztere unbrauchbar,
weshalb die Warnung
SCHEDULER-424 'Job_chain xxx'
is being removed before 'yyy'
ausgegeben wurde. Die Meldung
wird jetzt als Info ausgegeben.
JS-180: Java-Quellcode kann jetzt
mit Blank im Classpath übersetzt
werden
Der JobScheduler setzt dazu die
Umgebungsvariable CLASSPATH.
JS-146: Jobstarts bei neuen,
geänderten und gelöschen
Konfigurationsdateien
•
•
•
<config
configuration_add_event="
…">
<config
configuration_modify_even
t="…">
<config
configuration_delete_even
t="…">
August 2014
Änderungsprotokoll
288
Revision
Datum
Bemerkung
2.0.190.5382
2007-11-12
JS-181: Änderung der
Großschreibung einer im
Quellcode angegebenen
Java-Klasse
Unter Windows führte die Änderung
der Großschreibung des Namens
einer Java-Klasse zu einem Fehler,
wenn deren Quell-Code direkt in <
script language="java">
angegeben war. Der JobScheduler
löscht jetzt die generierte .java
-Datei, um Windows zu der
geänderten Großschreibungsweise
zu zwingen.
2.0.190.5379
2007-11-06
Veraltetes <script
process_class="..."> wird nicht
mehr unterstützt
Verwenden Sie <job
process_class="…"> .
2.0.190.5375
2007-11-03
JS-177: Java-Methode
Order.priority() korrigiert
Order.priority ist jetzt unter Java
benutzbar.
2.0.190.5370
2007-10-29
JS-155: Lade- und
Aktivierungsphase der
dynamischen Konfiguration
getrennt
Die Objekte der
Konfigurationsverzeichnisse werden
erst geladen, dann aktiviert. Damit
können für <config
configuration_add_event="…">
usw. Jobs aus den
Konfigurationsverzeichnissen
benutzt werden.
JS-155: Kurzfristiges Löschen
und Wiedereinfügen einer Datei
wird als Änderung angesehen
Wenn eine Datei in sehr kurzer Zeit
gelöscht und wieder eingefügt wird,
interpretiert der JobScheduler das
als Änderung, nicht als Löschen und
Hinzufügen eines Objekts.
August 2014
Änderungsprotokoll
289
Revision
Datum
Bemerkung
2.0.190.5365
2007-10-28
JS-136: Authentifizierung für
SMTP-Server (eMail-Versand)
Der JobScheduler unterstützt
Authentifizierung für den Versand
von Mail via SMTP.
Der JobScheduler läuft nur mit der
neuen Datei sos.mail.jar!
•
[smtp])
JS-153: Neues Kommando <
check_folders>
Das Kommando veranlasst den
JobScheduler, den Inhalt von
Konfigurationsverzeichnissen (Hot
Folders) zu prüfen, um geänderte,
hinzugefügte oder entfernte Dateien
sofort zu erkennen. Unter Windows
wird dies sofort erkannt, unter Unix
wird dies innerhalb von max. 60s
erkannt. Das Kommando ist in der
HTML-Oberfläche des
JobSchedulers verfügbar.
•
<check_folders>
JS-149: Neues Attribut <
job_chain_node
on_error="setback|suspend"
•
2.0.189.5354
2007-10-22
<job_chain_node
on_error="…">
JS-147: Umgebungsvariablen für
Tasks einstellbar
•
•
<job><environment>
<start_job><environment>
JS-148: Task- und
Auftrags-Parameter für
Nicht-API-Jobs
Nicht-API-Jobs erhalten die Taskund Auftrags-Parameter als
Umgebungsvariablen. Die Namen
sind großgeschrieben. "
SCHEDULER_PARAM_" ist den Namen
vorangestellt. Auftragsparameter
überschreiben gleichnamige
Task-Parameter.
August 2014
Änderungsprotokoll
290
Revision
Datum
Bemerkung
2.0.187.5325
2007-10-10
JS-134: Mehrere JobScheduler
Skripte
Mit dem neuen XML-Element <
scheduler_script> lassen sich
mehrere JobScheduler Skripte
angegeben.
JS-68: Mehrere Job-Monitor <
monitor>
•
<monitor>
JS-121: Monate in <run_time>
•
<month>
JS-123: absolute_repeat= in <
run_time>
•
<period>
JS-124: Mehrfache angaben in
day=, monthday= usw.
•
<day>
Neue Voreinstellung <add_order
replace='yes'>
•
<add_order replace="yes">
: replace="yes" ist jetzt
voreingestellt.
JS-155: Dynamische
Konfiguration
•
(Seite 78)
JS-126: HTTP-Authentifizierung
wird auch für Web-Services
verlangt
Die Authentifizierung <
http.authentication> gilt auch für
die über HTTP angesprochenen <
web_service> .
JS-129: Datenbankspalte
EXIT_CODE wird nachträglich
angelegt
JS-116: <run_time> für Aufträge in
verschachtelter Job-Kette
<run_time> wiederholt jetzt einen
Auftrag korrekt, auch wenn er in
August 2014
Änderungsprotokoll
Revision
291
Datum
Bemerkung
einer verschachtelten Job-Kette ( <
job_chain_node.job_chain> ) ist.
2.0.186.5189
2007-08-30
JS-110: Korrektur "bad allocation"
2.0.186.5179
2007-08-27
JS-103: HTTP-Authentifizierung
eingeführt
Neues XML-Element <
http.authentication> eingeführt.
(Dank für den Algorithmus an
Michael Collard, iinet.net.au).
Meldung für verspäteten
Herzschlag wird als Warnung
ausgegeben
•
•
•
[
w
a
r
n
]
SCH
EDU
LER
-82
7
Own heart beat is
late:
next_heart_beat has
been announced for
(this is seconds late)
[
E
R
R
O
R
]
SCH
EDU
LER
-38
6
Last heart beat was
time, seconds ago.
Something is
delaying
JobScheduler
execution, the
JobScheduler is
aborted immediately
[
E
R
R
O
R
]
SCH
EDU
LER
-37
7
After own late heart
beat, JobScheduler
member '' has taken
exclusiveness
August 2014
Änderungsprotokoll
292
Revision
Datum
Bemerkung
2.0.185.5170
2007-08-24
Änderungen an der Datenbank
•
Mit der Tabelle
SCHEDULER_ORDER_HISTORY
wird der neue Index
SCHEDULER_O_HISTORY_JOB_C
HAIN auf die Spalte JOB_CHAIN
•
angelegt.
Der bisherige Index
SCHEDULER_HISTORY_CLUSTME
MBER wird jetzt als
SCHEDULER_H_CLUSTER_MEMBE
R angelegt.
•
Die Datenbankspalte
SCHEDULER_ORDERS.SPOOLER_
ID wird jetzt mit not null
•
angelegt.
Für MySQL werden die
Primärschlüsselfelder von
SCHEDULER_ORDERS mit dem
Zeichensatz Latin1 angelegt.
August 2014
Änderungsprotokoll
293
Revision
Datum
Bemerkung
2.0.184.5167
2007-08-23
JS-92: idle_time="5" ist jetzt
voreingestellt
•
<job idle_timeout="never"
>
JS-88: Neues Attribut
max_order_history
•
•
•
<show_state
max_order_history="…">
<show_job_chains
<show_job_chain
JS-97: Meldungen wegen später
gelöschter Dateien jetzt als
debug3
Zwei Meldung werden mit debug3
statt bisher info ausgegeben:
•
•
[
d
e
b
u
g
3
]
SCH
EDU
LER
-87
6
Temporary files
cannot be deleted.
Still trying ..., paths
[
d
e
b
u
g
3
]
SCH
EDU
LER
-87
7
Temporary files have
been deleted now
JS-96: HTML-codierte Protokolle
über HTTP enthalten wieder die
Zeichen <, > und &
JS-93: Meldung SCHEDULER-846
korrigiert
August 2014
Änderungsprotokoll
Revision
294
Datum
Bemerkung
•
S
C
H
E
D
U
L
E
R
8
4
6
Afte
r
task
exc
epti
on
and
due
to
stop
_on
_err
or='
no',
the
orde
r
has
bee
n
mov
ed
to
erro
r_st
ate=
''
August 2014
Änderungsprotokoll
295
Revision
Datum
Bemerkung
2.0.183.5153
2007-08-10
JS-48: Nicht-API-Jobs versetzen
im Fehlerfall Auftrag in den
Fehlerzustand
Im Fehlerfall eines
auftragsgesteuerten Nicht-API-Jobs
( <process> oder <script
language="shell"> ) wird der
ausgeführte Auftrag in den
Fehlerzustand ( <job_chain_node
error_state="…"> ) versetzt.
Davon unberührt stoppt der Job
(außer bei <job
stop_on_error="no"> oder <
delay_after_error> ).
JS-82: Unix: Viele <
start_when_directory_changed>
blockieren nicht mehr den
Scheduler
Unter Unix konnten viele
Verzeichnisüberwachungen mit <
den JobScheduler so beschäftigen,
dass die Tasks nicht mehr
fortgesetzt wurden. Das ist behoben.
JS-81: Date-Header fehlte beim
Erzeugen der eMail mit JavaMail
ohne Versand
EMails, die der JobScheduler mit
JavaMail erzeugt und im
Mail-Verzeichnis abgelegt, also nicht
versendet hat, haben jetzt auch
einen Date-Header.
2.0.182.5146
2007-07-27
JS-78: Scheduler-Skript wird vor <
commands> ausgeführt
Erst wird das Scheduler-Skript <
config><script> ausgeführt, dann
<config><commands> . Damit kann
<run_time
start_time_function="…">
berechnet werden, bevor die
Aufträge in der Datenbank abgelegt
werden.
JS-78: Verteilte Aufträge mit <
run_time> möglich
Verteilte Aufträge können <run_time
> nutzen.
August 2014
Änderungsprotokoll
296
Revision
Datum
Bemerkung
2.0.181.5143
2007-07-24
JS-49: Für die Datenbank DB2
wird der Datentyp numeric(1) statt
bisher boolean verwendet
JS-55: <job tasks='0'> startet
keine Task mehr
Auch im Zustand pending prüft der
JobScheduler das Attribut <job
tasks="…"> Bei tasks="0" startet
er keine Task.
2.0.180.5139
2007-07-23
JS-39: scheduler.log.gz wird nicht
mehr erzeugt
Solange nicht implementiert ist, dass
der JobScheduler die
scheduler.log.gz im Hintergrund
erzeugt, erzeugt er sie erstmal gar
nicht, weil das den Start zu lange
verzögern kann.
JS-41: Urls im
HTML-Protokollfenster sind
klickbar
Urls in einem über HTTP in HTML
gelieferten Protokoll sind klickbar.
Der JobScheduler erkennt das
Kennzeichen http:// und setzt den
Url in ein <a href="…"
target="_blank">...</a>
2.0.179.5136
2007-07-23
JS-52: Nicht für XML zugelassene
Zeichen werden durch ¿ ersetzt
Die Zeichen U-0 bis U-1F (außer
U-9, U-A, U-D) und U-80 bis U-9F
ersetzt der JobScheduler beim
Erzeugen eines XML-Dokuments
durch ¿, damit es nicht ungültig wird.
Alle anderen Zeichen des
Zeichenvorrats Latin1 (ISO-8859-1)
werden weiter unterstützt.
August 2014
Änderungsprotokoll
297
Revision
Datum
Bemerkung
2.0.178.5132
2007-07-17
JS-42: Prozess-Jobs setzen
Job.state_text und
Order.state_text
Der JobScheduler füllt nach
Beendigung eines Prozess-Jobs ( <
process> und <script
language="shell"> , also nicht
API-Jobs) Job.state_text und
Order.state_text mit der ersten
Zeile von stdout, max. 100 Zeichen.
Datenbank-Indices werden
automatisch angelegt
Der JobScheduler legt jetzt
zusammen mit den
Datenbanktabellen auch die Indices
an.
Create-tables in die
Dokumentation aufgenommen
•
»Vom JobScheduler
verwendete
SQL-Anweisungen« (Seite 348)
Umgang mit Backslash in MySQL
Beim Betrieb mit einer
MySQL-Datenbank berücksichtigt
der JobScheduler die Besonderheit
der Backslashs in MySQL-Strings.
August 2014
Änderungsprotokoll
298
Revision
Datum
Bemerkung
2.0.177.5128
2007-07-13
JS-23: Tasks warten auf gesperrte
temporäre Dateien für stdout und
stderr
Nur Windows: Der JobScheduler
verzögert das Ende einer Task eine
halbe Sekunde, bis die für stdin,
stdout und stderr angelegten
temporären Dateien löschbar sind.
Die Dateien können von
Enkelprozessen blockiert sein, die
der Task-Prozess gestartet hat und
die nach Task-Ende noch
weiterlaufen. Oder ein Virenscanner
hält die Dateien noch einen kurzen
Moment fest.
JS-47: <security> in <base>
nutzbar
<security> in oberer Konfiguration
ersetzt nicht mehr die Einstellung
aus der <base> -Konfiguration
sondern wird mit dieser vermengt.
abort_immediately_and_restart
zögert 2 Sekunden
<modify_spooler
cmd="abort_immediately_and_res
tart"> schließt wie bisher die
TCP-Verbindungen und wartet dann
2 Sekunden, um dem Internet
Explorer die Gelegenheit zu geben,
seinerseits die TCP-Verbindung zu
schließen, um nicht zu blockieren.
distributed='no',
Cluster-Member-ID ist nur noch
für Rechnername und Port
eindeutig
Ein Verteilter JobScheduler (
-distributed-orders ) führt Jobs
lokal im einzelnen JobScheduler
aus.
Für eine Job-Kette kann mit <
job_chain distributed="…">
eingestellt werden, ob sie lokal im
einzelnen JobScheduler oder verteilt
im ganzen Cluster gilt. Lokale
Job-Ketten müssen im Cluster einen
eindeutigen Namen haben (das wird
nicht geprüft).
August 2014
Änderungsprotokoll
Revision
299
Datum
Bemerkung
Bisher war die Cluster-Member-ID
für jeden Lauf eines Schedulers
(eines Cluster-Mitglieds) eindeutig.
Jetzt wird die ID aus Scheduler-ID,
Rechnernamen und
TCP-Portnummer gebildet. Zwei
Rechner im selben Cluster dürfen
nicht denselben Rechnernamen
haben.
2.0.176.5116
2007-07-01
Linux-Scheduler wird unter Suse
9.1 kompiliert
Die ausgelieferten Binär-Dateien
laufen jetzt unter Suse ab Version
9.1 (bisher 8.0). Bisher ist die
Linux-Software unter Suse 8.0
kompiliert worden.
orders_recoverable='no'
unterdrückt nicht mehr
Auftragshistorie
<job_chain
orders_recoverable="no"> .
August 2014
Änderungsprotokoll
300
Revision
Datum
Bemerkung
2.0.176.5105
2007-06-21
Zur Laufzeit hinzugefügtes <
file_order_source> wirkt
Eine zur Laufzeit hinzugefügte <
job_chain> mit <
file_order_source> hat nicht
automatisch gestartet. Das ist
behoben.
need_db=no nicht länger im
Cluster-Betrieb erlaubt
•
•
•
•
2.0.176.5101
2007-06-18
[spooler], Eintrag need_db=
…)
-exclusive
-distributed-orders
S
C
H
E
D
U
L
E
R
3
5
7
This
is a
me
mbe
r of
a
clust
er
(opti
on
-exc
lusiv
e or
-dist
ribut
ed-o
rder
s),
and
ther
efor
e
nee
ds a
data
bas
e
-distributed-orders und
Order.setback()
Ein verteilter Auftrag mit Startzeit
(z.B. durch Order.setback() )
konnte nach Neustart den
JobScheduler in eine Schleife
bringen. Das ist behoben.
August 2014
Änderungsprotokoll
301
Revision
Datum
Bemerkung
2.0.176.5087
2007-06-06
Aufträgskennungen werden in
allen verschachtelten Job-Ketten
auf Eindeutigkeit geprüft
•
>
Miteinander durch Verschachtelung
verbundene Job-Ketten bilden einen
gemeinsamen Order_id_space, um
beim Einfügen eines Auftrags die
Eindeutigkeit der Auftragskennung
sicherstellen zu können.
Der JobScheduler lehnt das
Einfügen eines Auftrags in eine
Job-Kette ab, wenn die
Auftragskennung im Order_id_space
bereits vergeben ist.
Beim Ersetzen eines Auftrags wird
auch ein Auftrag in einer anderen
Job-Kette, die demselben
Order_id_space angehört, ersetzt.
[
E
R
R
O
R
]
SCHE
DULE
R-42
6
'job_chain' and
'job_chain' cannot be
combined, because of
duplicate order id ''
[
i
n
f
o
]
SCHE
DULE
R-87
2
New 'Job_chain' shares
order IDs with
job_chains
[
i
n
f
o
]
SCHE
DULE
R-87
3
Job_chains job_chains
share order IDs because
'Job_chain' has been
removed
[
i
n
f
o
]
SCHE
DULE
R-87
4
Order_id_space has
been closed
August 2014
Änderungsprotokoll
Revision
302
Datum
Bemerkung
[
i
n
f
o
]
SCHE
DULE
R-87
5
Order_id_space has
been closed because
'job_chain' has been
removed
-send-cmd= berücksichtigt
-ip-address=
-send-cmd berücksichtigt <config
ip_address="…"> .
2.0.175.5045
2007-05-09
MySQL-Tabellen werden für
InnoDB angelegt
Wenn der JobScheduler eine
SQL-Tabelle in einer
MySQL-Datenbank automatisch
anlegt, verwendet er jetzt den
transaktions-sicheren Typ InnoDB.
Der JobScheduler läuft nur korrekt
mit transaktions-gesicherten
Datenbanken.
<add_order at='...'>
Die mit dem Auftrag übergebene
Startzeit <add_order at="…"> wird
nicht mehr durch <add_order><
run_time> überschrieben.
Neue Eigenschaft Order.log
•
Order.log liefert das
Auftragsprotokoll.
Neue Klasse Supervisor_client
•
•
Spooler.supervisor_client
Supervisor_client
XML-Kommandos und API für
Prozessklassen
•
•
•
•
•
•
Spooler.process_classes
Process_classes
Process_class
Job.process_class
<process_class>
<process_class.remove>
August 2014
Änderungsprotokoll
303
Revision
Datum
Bemerkung
2.0.174.5001
2007-04-27
API für Sperren
•
•
•
2.0.172.4983
2007-04-16
Spooler.locks
Locks
Lock
Verschachtelte Job-Ketten
Ein Auftrag kann nacheinander
durch mehrere Job-Ketten
geschleust werden. Diese
Job-Ketten werden in einer eigenen,
übergeordneten Job-Kette
aufgeführt.
•
2.0.171.4981
2007-04-16
>
Mehrere Sperren und <
lock.remove>
Ein Job kann mehrere Sperren
setzen und Sperren können gelöscht
werden.
•
•
2.0.171.4961
2007-04-09
<lock.remove>
<job> <lock.use>
Job-Kette und Job-Kettenknoten
stoppen
Eine Job-Kette kann gestoppt
werden, so dass keine Aufträge
mehr ausgeführt werden.
Ein Job-Kettenknoten kann gestoppt
werden, so dass Aufträge nicht mehr
ausgeführt werden. Oder die
Aufträge überspringen den
Job-Kettenknoten.
•
•
•
2.0.170.4951
2007-04-03
<job_chain.modify>
<job_chain_node.modify>
Job_chain_node.action
<show_calendar>
Ein neues Kommando liefert die
Startzeiten der Jobs und Aufträge.
•
2.0.169.4940
2007-04-01
<show_calendar>
Sperren
Mit Sperren kann der Ablauf von
Tasks serialisiert werden, siehe
Kapitel (Seite 152).
•
•
<lock>
<job> <lock.use>
August 2014
Änderungsprotokoll
304
Revision
Datum
Bemerkung
2.0.168.4912
2007-03-19
Ausführung von Tasks auf
entferntem Scheduler
•
2.0.167.4877
2007-03-08
<process_class
remote_scheduler="…">
Auftragsprokolle wurden nicht
immer in die Historie
aufgenommen
Ein Fehler seit 15. Februar, ist
behoben.
2.0.167.4861
2007-02-22
XML-Kommando <modify_order>
erweitert
•
•
<modify_order> kann jetzt
auch Parameter, Xml_payload
und Titel ändern.
<xml_payload> darf jetzt leer
sein.
August 2014
Änderungsprotokoll
305
Revision
Datum
Bemerkung
2.0.166.4860
2007-02-19
XML-Element <web_services>
heißt jetzt <http_server>
•
•
<http_server>
[
i
n
f
o
]
SCH
EDU
LER
-84
7
Please use new
name '' instead of
old ''
mail_on_delay_after_error wirkt
nur noch mit <delay_after_error>
factory.ini (Abschnitt [job],
Eintrag
mail_on_delay_after_error= …)
wirkt nur, wenn für den Job auch ein
<delay_after_error> gesetzt ist.
Meldung SCHEDULER-949
•
[
i
n
f
o
]
SCH
EDU
LER
-94
9
Job will be executed
when a process of
process class ''
becomes available
Die Meldung erscheint jetzt im
Jobprotokoll und, wenn eine Task
gestartet werden soll, mit der
Task-Id.
<script> und <base>
Das Element <script> , in einer <
base> -Konfiguration definiert, wird
jetzt von der übergeordneten
Konfiguration nicht mehr ersetzt,
sondern erweitert. (Das funktioniert
nicht mit Java wegen dessen
Syntax.) Damit können in der <base
> -Konfiguration Funktionen definiert
werden, die in einer übergeordneten
Konfiguration nutzbar sind.
Auftragsprokolle bei
Scheduler-Neustart
l Die Protokolle nicht
abgeschlossener Aufträge bleiben
jetzt bei Scheuler-Neustart erhalten
und werden fortgeschrieben. Dazu
August 2014
Änderungsprotokoll
Revision
306
Datum
Bemerkung
werden sie in der Datenbank
gespeichert.
August 2014
Änderungsprotokoll
307
Revision
Datum
Bemerkung
2.0.165.4846
2007-02-12
Order.state
Wenn Order.state der bisherige
Wert zugewiesen wird, der Zustand
also nicht verändet wird, verhindert
das wie jeder andere Wert die
automatische Weiterschaltung in
den Folgezustand nach
spooler_process() . Stattdessen
durchläuft der Auftrag denselben
Job noch einmal.
HTTP-Server mit
Alias-Verzeichnissen
•
<http_server><
http_directory>
Verzögernde Job-Kettenknoten
•
<job_chain_node delay="…"
>
<show_order> kann
Historien-Einträge zum selben
Auftrag unterscheiden
•
<show_order
history_id="…">
Damit kann die HTML-Oberfläche
das richtige Protokoll zeigen, wenn
ein Auftrag mehreren
Historieneinträge hat.
Das Kommando liefert jetzt auch die
neuen Attribute start_time= (erste
Ausführung) und end_time=
(Abschluss des Auftrags). Die
integrierte HTML-Oberfläche (
http://host:4444/z) zeigt den
Zeitpunkt der Abschlusses.
HTML-Oberfläche zeigt Zeiten
genauer
Die integrierte HTML-Oberfläche (
http://host:4444/z) zeigt
Sekundenzeiten bis 99s und darüber
hinaus Viertelbruchteile.
<job stop_on_error='no'> versetzt
nach Exception Auftrag in
Fehlerzustand
<job stop_on_error="no">
versetzt nach einem Abbruch der
August 2014
Änderungsprotokoll
Revision
308
Datum
Bemerkung
Task mit Exception den Auftrag in
den Fehlerzustand ( <
job_chain_node error_state="…"
> ).
Dokumentation geändert:
stop_on_error="no" gilt auch für
Task-Abbruch mit Exception.
2.0.163.4829
2007-02-01
Address-in-use-Problem unter
Windows gelöst
Enkel-Prozesse, die der
JobScheduler nicht kennt und also
nicht abbrechen kann, blockierten
bislang die Scheduler-Ports. Jetzt
sind diese nicht mehr vererbbar und
können von den Enkeln auch nicht
mehr blockiert werden.
Die temporären Dateien für stdout
und stderr bleiben dagegen unter
Windows in einem solchen Fall
stehen.
Temporäre Dateien bleiben
stehen, wenn Enkel-Prozesse
noch laufen
Windows: Enkel-Prozesse, die der
JobScheduler nicht kennt und also
nicht abbrechen kann, blockieren die
temporären Dateien für stdout und
stderr und können deshalb vom
JobScheduler nicht gelöscht
werden.
2.0.163.4810
2007-01-30
<file_order_sink move_to=""
akzeptiert Umgebungsvariablen
•
2.0.163.4793
2007-01-27
<file_order_sink
move_to="…">
Skript-Funktion für nächste
Startzeit
Mit <run_time
start_time_function="…"> kann
eine Funktion aus dem
Scheduler-Skript angegeben
werden, die die nächste Startzeit
liefert.
August 2014
Änderungsprotokoll
309
Revision
Datum
Bemerkung
2.0.163.4792
2007-01-25
Wochentag im Monat: <
monthdays><weekday>
<run_time> ist erweitert: Mit <
weekday day="…"> können
bestimmte Wochentage im Monat
ausgewählt werden.
Mit <run_time
start_time_function="…"> kann
eine Funktion aus dem
Scheduler-Skript angegeben
werden, die die nächste Startzeit
liefert.
Solaris: Neue Module
libstdc++.so.6.0.8 und
libgcc_s.so.1
Weil der JobScheduler für Solaris
jetzt mit gcc 4.1.1 übersetzt wird,
werden die neuen Module
libstdc++.so.6.0.8 und libgcc_s.so.1
benötigt. Ein symbolischer Link
muss eingerichtet werden:
ln -s libstdc++.so.6.0.8
libstd++.so.6
2.0.163.4781
2007-01-22
Order.params initialisiert sich
automatisch
Order.params initialisiert sich beim
ersten Zugriff automatisch mit einer
Variable_set .
Spooler.terminate() mit
Parametern für Cluster-Betrieb
•
Spooler.terminate()
Jobs ohne <run_time>
berücksichtigen jetzt die <
holidays>
•
<holidays>
Verwaltung der Feiertage in
externer Datei: <holidays> mit <
include>
•
<holidays><include>
August 2014
Änderungsprotokoll
310
Revision
Datum
Bemerkung
2.0.163.4758
2007-01-19
Cluster: Fristen zur Überwachung
des Herzschlags sind einstellbar
•
<cluster>
<file_order_source> lässt
Umgebungsvariablen zu
•
<file_order_source
directory="…">
Neue Einstellung
•
•
[spooler], Eintrag
= …)
Eintrag
= …)
Optionen -?, -h und -V
•
•
•
-? zeigt die möglichen
Optionen
-h zeigt ebenfalls möglichen
Optionen
-V zeigt die Versionsnummer.
Wenn keine anderen Optionen
angegeben sind, beendet sich der
JobScheduler sofort.
Speicherleck in Java geschlossen
Ein winziges, aber stetiges
Speicherleck ist abgedichtet.
Insbesondere bei jeder
Datenbankoperation (über JDBC)
blieben einige Bytes übrig.
Speicherleck bei
stdout/stderr-Dateien
geschlossen
Unter Unix wurden temporäre
Dateien nicht korrekt geschlossen,
wenn eine Task etwas nach stdout
oder stderr geschrieben hat. Das ist
behoben.
August 2014
Änderungsprotokoll
311
Revision
Datum
Bemerkung
2.0.162.4730
2007-01-12
Cluster: Backup-Scheduler und
verteilte Aufträge (noch nicht für
Produktion)
•
•
•
•
•
•
•
•
•
•
•
(Seite 138)
-exclusive
-backup
-backup-precedence
-install-service
-distributed-orders
<terminate restart="…">
<terminate timeout="…">
<terminate
continue_exclusive_operat
ion="…">
<terminate
all_schedulers="…">
<job_chain
distributed="yes">
debug9 protokolliert
SQL-Kommandos
Bei -log-level =debug9 schreibt
der JobScheduler seine
SQL-Kommandos ins
Hauptprotokoll.
Order.xml_payload akzeptiert
ISO-8859-1
Order.xml_payload akzeptiert jetzt
den Zeichensatz ISO-8859-1 auch
im Datenbankbetrieb.
setback() funktioniert korrekt
Korrektur der fehlerhaften Version
2.0.160.4598 2006-11-22.
August 2014
Änderungsprotokoll
312
Revision
Datum
Bemerkung
2.0.161.4619
2006-12-04
<config ip_address="...">
Die IP-Adresse für TCP und UDP
kann angegeben werden.
•
•
-ip-address
<config ip_address="…">
Wartende Aufträge fortsetzen>
<modify_order at="now"> setzt
einen wegen Order.run_time oder
Order.setback() wartenden
Auftrag fort.
Order.suspend()
Aufträge können angehalten
werden.
•
•
Order.suspended
<modify_order
suspended="…">
akzeptiert jetzt auch Aufträge ohne
Parameter.
2.0.160.4598
2006-11-22
Order.setback()
Order.setback() bricht in dieser
Version den JobScheduler ab
(korrigiert in 2.0.162.4705 von
2007-01-05).
<show_order what="log">
Das Kommando liefert jetzt auch
das Protokoll ausgeführten Auftrags
aus der Auftragshistorie.
•
<show_order what="log">
Order.state und Order.run_time
Eine Änderung des Zustands eines
Auftrags ( Order.state ) führt nicht
mehr zur sofortigen Ausführung
desselben, wenn seine
Order.run_time eine spätere
Startzeit vorschreibt.
•
•
•
•
Order.state
Order.run_time
<modify_order state="…">
<modify_order><run_time>
August 2014
Änderungsprotokoll
313
Revision
Datum
Bemerkung
2.0.160.4592
2006-10-06
<show_state what="job_params">
Die XML-Kommandos können jetzt
die <params> eines <job> liefern.
•
2.0.160.4591
2006-10-03
<show_state
what="job_params">
Auftrag ohne Parameter in der
Datenbank ließ JobScheduler
abbrechen
Der Fehler ist mit den
Dateiaufträgen (Version
2.0.158.4484 2006-09-13) in den
JobScheduler gelangt und jetzt
behoben.
Scheduler braucht seit 26.
September 2006 eine aktuelle
sos.mail.jar
Die Datei sos.mail.jar sollte nicht
älter als Version 1.6.131.4555
(Dateidatum 2006-09-25 09:00)
sein.
2.0.160.4586
2006-10-30
Die <run_time> eines Auftrags kann
für den nächsten Durchlauf neu
gesetzt werden.
•
•
Order.run_time
<job replace="yes">
Ein Job kann ersetzt werden.
•
•
<job replace="yes">
<add_jobs>
August 2014
Änderungsprotokoll
314
Revision
Datum
Bemerkung
2.0.159.4578
2006-10-16
Variablenersetzung verfeinert
Alleinstehende $ bleiben stehen.
Das Zeichen wird nur dann ersetzt,
wenn ein Buchstabe oder ein
Unterstrich folgt. Damit kann ein
Dollarzeichen in Windows-Freigaben
("\\HOST\C$") und vielen
Regulären Ausdrücken (".txt$",
"[a-z$]", aber nicht "[$a-z]")
verwendet werden.
•
Kapitel (Seite 95)
<modify_order setback="no"
state="…">
•
•
2.0.158.4569
2006-10-11
<modify_order
setback="no">
<modify_order state="…">
<show_order what='payload'/>
<show_order what="payload">
liefert die Parameter des Auftrags.
Protokolldateien werden früher
gelöscht
Der neue JobScheduler entfernt die
Protokolldateien früher, auch wenn
das entsprechende Objekt (in der
Regel ein Order ) noch gehalten
wird.
Mit einem Javascript-Job konnte
folgendes passieren: Wenn dieselbe
Task nacheinander zwei Aufträge mit
derselben Id bekam, hielt sie wegen
des noch nicht angelaufenen
Garbage Collectors die zwei
Aufträge offen. Erst beim Beenden
der Task wurden die zwei
Auftragsobjekte geschlossen, also
die Destruktoren gerufen, die die
Protokolldateien löschten. Das
führte zu einem Fehler, weil beide
Protokolldateien wegen derselben
Auftragskennung dieselben
Dateinamen haben.
August 2014
Änderungsprotokoll
315
Revision
Datum
Bemerkung
2.0.158.4559
2006-10-04
Änderungen in den
Dokumentationsdateien
•
Die Datei
ersetzung_von_umgebungsva
riablen.xml ist ersetzt
worden durch
variable_substitution.xml
•
(Seite 95). Die Seite enthält
ein Verzeichnis aller Attribute
und .ini-Einstellungen, in
denen Umgebungsvariablen
verwendet werden können.
Das generierte Register steht
jetzt in register_data.xml.
Die Datei register.xml
enthält jetzt einen Text.
Beim Beenden des Schedulers
werden <process>-Prozesse
abgewartet
Bei <terminate> wartete der
JobScheduler das Ende von <
process> -Tasks nicht ab. Jetzt tut
er das.
Variable_set.substitute
Neue Methode zum Ersetzen von
$-Variablen in einem String.
•
Variable_set.substitute()
Subprocess.env
Die Umgebungsvariablen des zu
startenden Subprozesses werden in
einem Variable_set gehalten.
Damit kann die neue Methode
Variable_set.substitute()
genutzt werden.
Der Subprozess erbt die
Umgebungsvariablen vom laufenden
Prozess zum Zeitpunkt des Aufrufs
von Task.create_subprocess() .
•
Subprocess.env
August 2014
Änderungsprotokoll
316
Revision
Datum
Bemerkung
2.0.158.4555
2006-09-26
Umgebungsvariablen in <
add_order><params> und <
start_job><params>
Innerhalb von <add_order> und <
start_job> können in in <param
value="…"> Umgebungsvariablen
abgerufen (Seite 95) werden.
2.0.158.4551
2006-09-24
add_pid() für Prozessgruppe
Task.add_pid() akzeptiert die Pid
auch negativ, um eine
Prozessgruppe zu bezeichnen.
Unter Unix wird dann bei einem
kill die Prozessgruppe
abgebrochen. Unter Windows hat
eine negative Pid zurzeit keine
besondere Wirkung.
Mehrere <commands> aus
Basiskonfigurationen werden
zusammengefügt
Alle <commands> aus der
Konfiguration mit den <base>
-Konfigurationen werden ausgeführt,
<base> zuerst.
August 2014
Änderungsprotokoll
317
Revision
Datum
Bemerkung
2.0.158.4533
2006-09-20
Tabellenspalten werden
verbreitert
Der JobScheduler prüft beim Start
die Spaltenbreiten von
scheduler_orders.id und
scheduler_order_history.order_
id und erweitert sie ggfs. auf 255
Zeichen, damit die
Auftragskennungen der
Dateiaufträge Platz finden. Ein
Fehler dabei wird ignoriert.
Dateiaufträge mit zu langen
Pfaden
Mit den neuen
Datenbankspaltenbreiten verarbeitet
der JobScheduler Pfade bis 255
Zeichen Länge. Längere Pfade
werden mit Warnung ignoriert. Der
JobScheduler merkt sie sich, um die
Fehlermeldung nicht zu
wiederholen.
Mail-Versand nur in
Dateiverzeichnis
Die neue Einstellung verhindert den
Versand und stellt die Nachricht in
das mit sos.ini (Abschnitt [mail],
Eintrag queue_dir= …) eingestellte
Verzeichnis.
Ebenso queue_only in der Datei
sos.ini.
•
•
sos.ini (Abschnitt [mail],
Eintrag queue_only= …)
[spooler], Eintrag
mail_queue_only= …)
start_when_directory_changed
robuster gemacht
Die
Windows-Verzeichnisüberwachung
wird bei jedem Aufruf (bei <
am Ende der Task) erneuert, ohne
das ein Signal verloren geht.
Wenn unter Unix ein Regulärer
Ausdruck angegeben ist, startet
start_when_directory_changed
August 2014
Änderungsprotokoll
Revision
318
Datum
Bemerkung
den Job nur noch, wenn eine Datei
hinzugefügt, aber nicht, wenn eine
Datei entfernt worden ist.
•
•
2.0.158.4505
2006-09-14
<
start_when_directory_chan
ged>
Job.start_when_directory_
changed()
Subprocess.own_process_group
Unter Unix wird der kill() auf
Prozesse jetzt zusätzlich mit
negativer Pid ausgeführt, um die
ganze Prozessgruppe zu beenden.
•
•
Subprocess.own_process_gr
oup
[spooler], Eintrag
subprocess.own_process_gr
oup= …)
August 2014
Änderungsprotokoll
319
Revision
Datum
Bemerkung
2.0.158.4484
2006-09-13
Doppelte Einträge in
spooler_task.changed_directories
Task konnte mehrfache Einträge
enthalten, wenn der JobScheduler
mehrfache Änderungen desselben
Verzeichnisses bemerkte, bevor die
Task gestartet werden konnte. Jetzt
wird jedes Verzeichnis nur einmal
eingetragen.
<process> gibt bei Prozessstart
Kommandozeile aus
•
•
<process>
[
i
n
f
o
]
SCH
EDU
LER
-98
7
Starting process:
program and
arguments
spooler_log.mail.to etc. liefern
Default-Werte
Folgende Aufruf liefern die
Default-Werte aus den .ini-Dateien:
•
•
•
•
•
•
•
Mail.from
Mail.to
Mail.cc
Mail.bcc
Mail.subject
Mail.smtp
Mail.queue_dir
Web_service_operation.peer_ip
und .peer_hostname
Zwei neue Aufrufe:
Web_service_operation.pee
•
•
r_ip
Web_service_operation.pee
r_hostname
Dateiaufträge
In <job_chain> können zwei neue
XML-Elemente angegeben werden,
und ein Kommando liefert die
Schwarze Liste:
<file_order_source>
•
<file_order_sink>
•
<show_job_chains>
•
August 2014
Änderungsprotokoll
320
Revision
Datum
Bemerkung
2.0.157.4442
2006-08-30
<show_state
what="job_commands" liefert alle
<commands>
Bisher lieferte der JobScheduler nur
das erste <commands> eines Jobs.
2.0.157.4439
2006-08-25
-send-cmd=... liefert Ausgabe
ohne Null-Byte
•
-send-cmd gibt die Antwort des
Schedulers ohne das über
TCP übertragene Nullbyte aus.
Damit wird nach stdout ein
wohlgeformtes XML-Dokument
geschrieben.
2.0.157.4436
2006-08-25
Subprocess.start( String[] ) für
Java funktioniert
•
Subprocess.start()
funktionierte in Java nicht mit
einem String-Array. Das ist
behoben.
August 2014
Änderungsprotokoll
321
Revision
Datum
Bemerkung
2.0.157.4424
2006-08-18
•
verhindert den Stopp des Jobs
wegen einer Fehlermeldung
einer Task. Bei -log-level
=debug3 gibt der JobScheduler
am Ende einer fehlerhaften
Task die Meldungen
SCHEDULER-977 oder
SCHEDULER-978 aus.
spooler_task.trigger_files
•
•
Task.trigger_files
<process> : Dem Prozess wird
die Umgebungsvariable
SCHEDULER_TASK_TRIGGER_FI
LES übergeben.
<environment>:
Originalgroßschreibung der
Umgebungsvariablennamen
Der JobScheduler setzte die
Umgebungsvariablennamen in
Kleinschreibung. Jetzt verwendet er
die Schreibung wie in <environment
> angegeben. Unter Windows hat
das keine Auswirkung, weil die
Schreibung keine Rolle spielt.
Aufträge mit <period repeat="...">
: jeder zweite Tag wurde
ausgelassen
Wenn der JobScheduler als
nächsten Startzeit mit repeat= eine
Startzeit errechnete, die außerhalb
der Periode lag (immer nach
Mitternacht), dann nahm er die auf
die errechnete Startzeit folgende
Periode, die aber nicht die nächste,
sondern die übernächste ist.
Bei einem einfachen <run_time
period="300"> führte das um
Mitternacht zum Überspringen des
folgenden Tags. Das ist korrigiert.
Der JobScheduler ermittelt die
folgende Periode aus der Endzeit
der aktuellen Periode.
August 2014
Änderungsprotokoll
322
Revision
Datum
Bemerkung
2.0.156.4406
2006-08-09
Signal einer abgebrochenen Task
wird auch bei nicht <process>
-Jobs zum negativen Exit code
Nur Unix: Bisher ist das Signal einer
abgebrochenen Task nur bei <
process> -Jobs als negativer
Exit-Code übernommen worden.
Jetzt gilt das für alle Jobs.
<job ignore_signals="...">
Eine Task, die mit Signal endet
(durch kill oder Absturz), muss
nicht mehr zum Stopp des Jobs
führen.
•
<job
ignore_signals="SIGTERM
SIGKILL ...">
<commands
on_exit_code="SIGTERM">
Nur Unix: Die Signalnamen können
aufgeführt werden.
•
•
2.0.155.4396
2006-07-27
<commands
on_exit_code="SIGTERM
SIGKILL ...">
<commands
on_exit_code="signal">
<show_job
what="job_commands">
Mit dem Attribut
what="job_commands" liefern die
Kommandos, die das Element <job>
zeigen, auch das Element <
commands> der Job-Konfiguration.
•
•
•
•
<show_job
<show_jobs
<show_job_chains
<show_state
August 2014
Änderungsprotokoll
323
Revision
Datum
Bemerkung
2.0.154.4393
2006-07-27
Datenbankzugriffe auf die Tabelle
scheduler_orders
Der Primärschlüssel der Tabelle
SCHEDULER_ORDERS ist um
SPOOLER_ID erweitert. Alle
Where-Klauseln auf diese Tabelle
sind um SPOOLER_ID und JOB_CHAIN
ergänzt worden.
Clob RUN_TIME wird nur noch bei
gefüllter run_time gesetzt.
2.0.154.4390
2006-06-30
Java-Job ohne Konstruktor
Ein Java-Job ohne parameterlosen
Konstruktor führte zum Abbruch des
Prozesses statt zur Exception
java.lang.NoSuchMethodError.
<config java_class_path="">
Das Attribut java_class_path
wurde im Betrieb mit
Prozessklassen nicht ausgewertet.
•
2.0.154.4379
2006-06-20
<config
java_class_path="…">
history_on_process verhält sich
jetzt wie dokumentiert
Eine falsche Angabe wird nicht mehr
ignoriert, sondern führt zum Fehler.
•
Eintrag history_on_process=
…)
August 2014
Änderungsprotokoll
324
Revision
Datum
Bemerkung
2.0.154.4366
2006-06-19
Ein paar Verbesserungen in der
internen Ereignisverarbeitung
Neues Attribut wait_until liefert
den Zeitpunkt der nächsten
geplanten Aktion. Nach etwa 20
Minuten Nichtstun gibt der
JobScheduler eine Meldung aus, bis
wann und worauf er wartet.
•
•
<state wait_until="…">
SCHEDULER-972
<show_state> lieferte Fehler bei
beendeten Subprozess, deshalb
evt. keine eMail
<show_state> und andere
Kommandos, die den Task-Zustand
zeigen, lieferte einen Fehler, wenn
ein Subprozess oder der
Task-Prozess selbst beendet war
und der JobScheduler dies noch
nicht zur Kenntnis genommmen
hatte. Grund: Der Systemaufruf zum
Lesen der Priorität liefert einen
Fehler.
Das konnte insbesondere bei <
kill_task> mit Subprozess dazu
führen, dass die eMail am Ende der
Task nicht versendet und statt
dessen der Fehler SCHEDULER-302
ausgegeben wird.
•
•
•
<kill_task>
<subprocess priority="…">
Log.mail_on_error
August 2014
Änderungsprotokoll
325
Revision
Datum
Bemerkung
2.0.154.4352
2006-06-16
<process param="">:
Task-Parameter werden ersetzt
Im Attribut param= ersetzt der
JobScheduler jetzt auch
Task-Parameter. Die haben Vorrang
vor den Umgebungsvariablen. Damit
kann für jede Task eine andere
Parameterzeile übergeben werden.
•
<process param="…">
Neue Eigenschaft Order.at
•
Order.at
Strg-C bricht nicht mehr die
Prozesse ab
Strg-C wirkt nur noch auf den
Scheduler-Prozess, aber nicht mehr
auf die Task-Prozesse (außer unter
Windows <process> und <script>
). Damit kann der JobScheduler
nach Strg-C die Tasks ordentlich
beenden. Ein zweites Strg-C führt
nach wie vor zum sofortigen Ende
aller Tasks und des Schedulers.
August 2014
Änderungsprotokoll
326
Revision
Datum
Bemerkung
2.0.154.4339
2006-06-06
-env= korrigiert (Windows)
-env= hat die Variablen für
Kindprozesse gesetzt, aber nicht für
den eigenen. (Das wird nämlich von
Microsofts C unterschieden.)
•
-env
<add_order replace="yes">
Das XML-Schema erlaubt jetzt
replace="yes".
•
<add_order replace="…">
Neue Option -expand-classpath=
Expandiert den als Parameter
angegebenen Java-Classpath, d.h.
die Joker werden verarbeitet wie in
sos.ini (Abschnitt [java], Eintrag
class_path= …).
•
-expand-classpath
<commands on_exit_code="0">
•
•
•
•
Neue Eigenschaft
Task.exit_code (int),
anfänglich 0. Log.error() ,
Task.error() oder eine
Exception der Task setzen
Log.exit_code =1. exit_code
kann auch vom Job selbst
gesetzt werden, wird aber
unter den oben aufgeführten
Bedingungen vom
JobScheduler überschrieben.
Damit liefert jede im
JobScheduler mögliche Task
am Ende einen exit_code.
Der exit_code wird in die
Datenbanktabelle
scheduler_history in die
neue Spalte exit_code
geschrieben, die der
JobScheduler automatisch
anlegt.
Unter Unix liefert ein
abgebrochener Prozess die
Nummer des Signals negativ
als Exit-Code.
<job> wird um <commands
on_exit_code="…"> erweitert.
Für das Attribut on_exit_code
August 2014
Änderungsprotokoll
Revision
327
Datum
Bemerkung
kann eine Folge von
Exit-Codes, "success"
(dasselbe wie 0) oder "error"
angegeben werden. Letztere
Einstellung gilt für alle
Exit-Codes außer 0, die nicht
in anderen <commands
on_exit_code="…">
•
•
aufgeführt sind. Jedem
Exit-Code ist damit nicht mehr
als ein <commands>
zugeordnet.
Ein Fehler bei der
Kommando-Ausführung
verhindert die Ausführung der
folgenden Kommandos und
wird zur Task protokolliert. Der
Job wird gestoppt.
<commands> darf leer sein.
<copy_params>
<params> erhält das neue
Kind-Element <copy_params
from="…"> . Es kann nur unter <job
><commands> in <start_job><
params> und <add_order><params>
verwendet werden und kopiert an
seine Stelle die Parameter der Task
oder des Auftrags.
<copy_params from="order"> ist
ein Fehler, wenn es keinen Auftrag
gibt.
Aufträge mit Startzeit
Aufträge können einen Startzeit
haben, die in der Datenbank
gespeichert wird und somit bei
Scheduler-Neustart erhalten bleibt.
Ein noch nicht ausgeführter Auftrag
mit verstrichener Startzeit wird sofort
gestartet (sofern die <run_time>
des Jobs dies erlaubt).
Das entspricht dem Verhalten von <
start_job at="…"> .
•
<add_order at="…">
Relative Zeitangabe mit
now+HH:MM
•
•
<start_job at="now+...">
<add_order at="now+...">
August 2014
Änderungsprotokoll
Revision
328
Datum
Bemerkung
Mögliche Angaben sind:
•
•
•
•
•
•
now
now + seconds
now + hh:mm
now + hh:mm:ss
yyyy-mm-dd HH:MM
yyyy-mm-dd HH:MM:SS
language="perl" unter Windows
Unter Windows übergab der
JobScheduler nur bei <script
language="perlscript"> die
folgende Anweisung:
Win32::OLE->Option( Warn =>
3 );
<script language="perl"> hat
jetzt dasselbe Verhalten. Damit
ignoriert Perl nicht länger einen
Fehler bei einem Aufruf einer
Scheduler-Methode.
2.0.153.4313
2006-05-29
Joker im Java-Classpath
class_path =
c:\directory\sos.*.jar;...
•
sos.ini (Abschnitt [java],
Eintrag class_path= …)
August 2014
Änderungsprotokoll
329
Revision
Datum
Bemerkung
2.0.151.4305
2006-05-26
Umgebungsvariablen mit ${name}
Dort, wo Umgebungsvariablen mit $
name aufgerufen werden können,
kann jetzt auch ${ name }
geschrieben werden. Damit ist die
Trennung zum anschließenden Text
deutlicher.
In <base file=""> und <include
file=""> lassen sich
Umgebungsvariablen nutzen
•
•
<base file="…">
<include file="…">
Umgebungsvariablen mit ${name}
Dort, wo bisher
Umgebungsvariablen mit $ name
aufgerufen werden können, kann
jetzt auch ${ name } geschrieben
werden. Damit ist die Trennung zum
anschließenden Text deutlicher.
spooler_task.params korrigiert
Der Aufruf konnte zum Abbruch des
Schedulers führen.
•
Variable_set.names
August 2014
Änderungsprotokoll
330
Revision
Datum
Bemerkung
2.0.151.4304
2006-05-26
<job min_tasks=...>
Der JobScheduler kann dafür
sorgen, dass eine minimale Anzahl
Tasks läuft.
•
<job min_tasks="…">
Subprocess.wait_for_termination(
int) funktioniert jetzt unter Unix
Unter Unix wurde der Parameter für
die Wartezeit ignoriert. Das ist
behoben.
•
Subprocess.wait_for_termi
nation()
Perl-Schnittstelle unter Unix um
Objekt- und Array-Parameter
erweitert
Die Perl-Schnittstelle nimmt damit
auch unter Unix die folgenden
Aufrufe an:
•
•
•
•
•
Spooler.add_job_chain()
Job_chain.add_order()
Order.params
Task.create_subprocess()
Subprocess.start()
Betrifft die Datei
libsosperlscript.so.
Neuer Auftrag mit Startzeit weckt
schlafende Task
Ein Auftrag mit Startzeit weckt jetzt
eine schlafende Task (im Zustand
running_waiting_for_order), sodass
der Auftrag sofort zur Startzeit
ausgeführt wird.
August 2014
Änderungsprotokoll
331
Revision
Datum
Bemerkung
2.0.151.4254
2006-04-13
Neue Option -env=NAME=WERT
•
•
-env =NAME=VALUE
-sos.ini setzt die
Umgebungsvariable SOS_INI.
Verhalten bei Fehler von <
geändert
Bisher wurde die
Verzeichnisüberwachung beim Start
jeder Task wiederholt. Bei einem
Fehler in der
Verzeichnisüberwachung (z.B. weil
das Verzeichnis entfernt worden
war) wurde der Job gestoppt,
während die Task zuende laufen
konnte, und keine weitere Task
wurde mehr gestartet.
Jetzt stoppt der JobScheduler den
Job nicht mehr direkt. Die
Verzeichnisüberwachung wird am
Ende der Task (nach
spooler_exit() ) wiederholt. Ein
Fehler dabei führt zum Stopp des
Jobs, der aber mit <
delay_after_error> abgefangen
werden kann.
•
<
start_when_directory_chan
ged>
Web-Service-Parameter werden in
XSLT-Stylesheets übernommen
Parameter, die Apostroph und
Anführungszeichen enthalten,
werden mit Warnung abgewiesen,
da offenbar solche Werte libxslt nicht
übergeben werden können.
•
<web_service><params>
August 2014
Änderungsprotokoll
332
Revision
Datum
Bemerkung
2.0.151.4253
2006-04-12
Neue Eigenschaft Order.params
•
Order.params
Web-Service-Parameter werden in
XSLT-Stylesheets übernommen
Parameter, die Apostroph und
Anführungszeichen enthalten,
werden mit Warnung abgewiesen,
da offenbar solche Werte libxslt nicht
übergeben werden können.
•
2.0.150.4240
2006-04-06
Schema erlaubt wieder <
delay_after_error delay="stop">
•
2.0.150.4233
2006-04-04
<web_service><params>
<delay_after_error
delay="stop">
command_line.xml neu
strukturiert
scheduler_client entfällt wieder. Die
Optionen sind im Programm
scheduler integriert. Die
verschiedenen Aufrufe des
JobSchedulers sind jetzt
dokumentiert, siehe z.B.
"Laufendem JobScheduler einen
Job übergeben".
2.0.150.4225
2006-03-31
scheduler.xsd auf ISO-8859-1
begrenzt
XML-Kommandos können nur
Zeichen aus ISO-8859-1 enthalten.
Prozess-Prioritäten
•
•
•
•
•
<job
priority="below_normal">
Task.priority
Task.priority_class
Subprocess.priority
Subprocess.priority_class
August 2014
Änderungsprotokoll
333
Revision
Datum
Bemerkung
2.0.149.4218
2006-03-25
scheduler_client
Das neue Programm
scheduler_client kann dem
JobScheduler Jobs und Aufträge
übergeben.
Start eines Jobs, dessen Skript über
stdin übergeben wird:
Übergabe eines Auftrags:
<job temporary="true">
Ein temporärer Job wird erst
gelöscht, wenn die <run_time>
keine Startzeit mehr vorsieht und die
Task-Warteschlange leer ist.
Neue Skript-Sprache "shell" erlaubt
es, Shell-Jobs in der
XML-Konfiguration anzugeben. (Für
scheduler_client)
•
Neue Angabe für <run_time>: <at>
•
2.0.148.4199
2006-03-17
<at at="2006-03-24 12:00"
>
Der JobScheduler läuft wieder
unter Windows 2000
Die fehlerhafte Routine
SafeArrayGetVartype() in Windows
2000 wird umgegangen.
August 2014
Änderungsprotokoll
334
Revision
Datum
Bemerkung
2.0.148.4178
2006-03-10
<web_service> mit <params>
Einem Web-Service lassen sich
Parameter geben, die in den Jobs
gelesen werden können.
<web_service>
•
Web_service.params
•
Meldungen ins Englische
übersetzt und mit Codes
versehen
Die Meldungen (außer einige
Debug-Meldungen) sind jetzt
codiert, wie z.B. "SCHEDULER-900
JobScheduler is starting ...".
•
Liste der Meldungs-Codes
(Seite 226)
Neue Eigenschaften
Request|Response.content_type
und .charset_name
•
•
•
•
2.0.148.4155
2006-03-05
Web_service_request.conte
nt_type
Web_service_request.chars
et_name
Web_service_response.cont
ent_type
Web_service_response.char
set_name
<job_chain
orders_recoverable="no">
•
•
<job_chain
orders_recoverable="no">
Job_chain.orders_recovera
ble
<script java_class="–"> ist
überschreibbar
•
<script java_class="…">
August 2014
Änderungsprotokoll
335
Revision
Datum
Bemerkung
2.0.148.4126
2006-03-01
Neuer C++-Compiler für Windows
Ab Revision 4126 ist alle Software
für Windows mit Microsoft Visual
Studio 2005 C++ übersetzt. Es sollte
keine Änderung bemerkbar sein.
XML-Schema eingeführt
Die XML-Konfiguration und die
XML-Kommandos werden gegen ein
eingebautes XML-Schema geprüft.
Die neue Option -show-xml-schema
liefert das XML-Schema. Zum Test
ist eine aktuelle Version übers
Internet erreichbar:
http://www.zschimmer.com/2006/sch
eduler.xsd.
Neue Kommandozeilen-Optionen:
•
•
-show-xml-schema
-validate-xml
Neue Eigenschaft
order.xml_payload
Zusätzlich zur payload kann
Order.xml_payload ein
XML-Dokument aufnehmen.
Eine neue Eigenschaft und ein
neues XML-Element:
•
•
Order.xml_payload
<xml_payload>
<web_service job_chain=''>
Ein Web-Service kann mit einer
Job-Kette implementiert werden.
Neue XML-Elemente, neue
Attribute:
•
•
<web_service
job_chain="…">
<web_service timeout="…">
Neue Klassen und Methoden:
•
•
•
•
Order.web_service_operati
on
Web_service_operation
Web_service_request
Web_service_response
August 2014
Änderungsprotokoll
336
Revision
Datum
Bemerkung
2.0.147.4100
2006-02-21
Dateityp jdbc löscht temporäre
Dateien unter Windows
Beim Schreiben eines LOBs wurde
die temporäre Dateien nicht
gelöscht, weil
FileInputStream.close() nicht
gerufen wurde. Gilt nicht für Oracle.
Das ist korrigiert.
2.0.147.4099
2006-02-20
HTTP-Server korrigiert
2.0.147.4091
2006-02-09
Variable_set.names
Variable_set.names liefert die
Variablennamen, durch Semikolon
getrennt.
2.0.146.4073
2006-02-02
factory.ini queue_dir=
queue_dir kann wieder in der Datei
factory.ini eingestellt werden. Betrifft
JobScheduler ab
2.0.139.3889 (2005-09-15).
Die beste Stelle für diese Einstellung
bleibt in der Datei sos.ini
(Abschnitt [mail], Eintrag
queue_dir= …).
2.0.146.4061
2006-01-30
Web-Dienste
Neue XML-Elemente, neue
Attribute:
•
•
•
•
•
•
•
•
•
•
•
<web_services>
<web_service>
<add_order
web_service="…">
<start_job
web_service="…">
<order web_service="…">
<payload>
<task web_service="…">
<service_request>
<content>
<job_chain visible="no">
<job visible="no">
Neue Klassen und Methoden:
•
•
•
•
Web_service
Order.xml
Order.web_service
Task.web_service
August 2014
Änderungsprotokoll
337
Revision
Datum
Bemerkung
2.0.145.4049
2006-01-15
Job_chain.remove()
Neue Kommandos
Job_chain.remove() und <
remove_job_chain> .
2.0.144.4038
2005-12-15
Order.setback() und
Job.set_max_order_setbacks()
jetzt auch in Java verfügbar
Siehe Order.setback() und
Job.max_order_setbacks .
2.0.144.4036
2005-12-08
eMail-Einstellungen aus
factory.ini [job ...] werden wieder
berücksichtigt
Wenn eine Task mit Fehler oder
Warnung endet, überschreibt der
JobScheduler die Einstellung von
log_mail_subject. Das
eMail-Stylesheet kann dies ändern.
2.0.144.4026
2005-11-11
Auftrag mit <run_time> weckt
jetzt auf Auftrag wartende Task
Bislang hat der JobScheduler einen
wegen run_time wiederholten
Auftrag verschlafen, wenn bereits
eine Task auf den Auftrag wartete
(im Zustand
running_waiting_for_order).
August 2014
Änderungsprotokoll
338
Revision
Datum
Bemerkung
2.0.144.4015
2005-11-08
SQL-Tabellenamen ohne "";
Große order.payload möglich
Die SQL-Anweisungen des
Schedulers verwenden die
Tabellennamen großgeschrieben
ohne Anführungszeichen.
(Ausnahme: Zugriffe über den
Dateityp sql).
Die Order.payload wird mit dem
Hostware-Mechanismus als CLOB
geschrieben und kann damit beliebig
groß sein. Das ist gut für
Variable_set .
HPUX: Hostjava ist im
JobScheduler eingebunden
Weil es ein Problem mit gcc 3.2
beim Nachladen der libhostjava.sl
gibt (die statischen Variablen
werden nicht initialisiert), ist
Hostjava auf HP-UX fest
eingebunden.
system_information() implementiert
für HP-UX die
Plattenplatz-Funktionen bereit.
Tabelle scheduler_variables
geändert
Die Spalte "wert" ist jetzt ein Integer.
Die neue Spalte Textwert ist ein
Varchar(250) (wird vom
JobScheduler zurzeit nicht
verwendet).
2.0.143.4005
2005-11-07
<security
ignore_unknown_hosts="yes">
<security
ignore_unknown_hosts="yes">
funktioniert wieder.
2.0.142.4003
2005-11-03
<job java_options=>
Siehe <job java_options="…">
(Seite 37).
Außerdem wirkt <config
java_options="…"> jetzt auch,
wenn ein Job in einem eigenen
Prozess läuft.
August 2014
Änderungsprotokoll
339
Revision
Datum
Bemerkung
2.0.140.3999
2005-10-31
Job-<script> ist überschreibbar
Siehe <script> (Seite 66).
Die Attribute (language= etc.) sind
nicht änderbar. Nur der Skript-Code
mit <include> ist änderbar. Die
nächste Task verwendet den neuen
Skript-Code.
2.0.140.3995
2005-10-30
Monitor zur Überwachung eines
Jobs
Siehe <monitor> (Seite 50).
Für Monitoren in Javascript muss
die aktuelle spidermonkey.dll bzw.
libspidermonkey.so eingesetzt
werden.
Neues XML-Element <job_chains>
Siehe <job_chains> (Seite 47).
Neues XML-Element <
Siehe <
(Seite 71).
Neues XML-Element <
delay_after_error>
Siehe <delay_after_error> (Seite
27).
Neues XML-Element <
delay_order_after_setback>
Siehe <
delay_order_after_setback>
(Seite 28).
August 2014
Änderungsprotokoll
340
Revision
Datum
Bemerkung
2.0.140.3943
2005-09-25
Wegen <run_time> wiederholter
Auftrag erzeugt eigenen
Historieneintrag
Wenn ein Auftrag mit den
Endzustand erreicht hat und dessen
Order.run_time einen weiteren
Termin vorsieht, dann
•
•
schließt der JobScheduler das
Auftragsprotokoll,
schreibt einen Eintrag in die
Auftragshistorie, siehe
[spooler], Eintrag
db_order_history_table= …)
•
2.0.140.3939
2005-09-24
(Seite 88),
und beginnt ein neues
Auftragsprotokoll.
Windows: Doppeltes Ctrl-C bricht
alle Prozesse ab
Das erste Ctrl-C beendet den
JobScheduler wie <modify_spooler
cmd="terminate"> .
Das zweite Ctrl-C führt dann zum
Abbruch aller Prozesse.
Erst das dritte lässt das
Betriebssystem den JobScheduler
abbrechen.
Terminate mit Frist
Der JobScheduler kann jetzt mit
Frist beendet werden. Wenn
innerhalb der Frist die Tasks nicht
enden, bricht der JobScheduler die
Prozesse der Tasks ab, und wartet
dann längstens weitere 30s auf die
Tasks, bevor er sich beendet.
Siehe <modify_spooler
cmd="terminate"> (Seite 189) und
Spooler.terminate() .
2.0.139.3925
2005-09-21
Fehlerhaftes <include> im <
description> eines Jobs führt zur
Warnung im Jobprotokoll
(Bisher gab's einen Fehler nur im
Hauptprotokoll.)
Siehe <description> (Seite 28).
August 2014
Änderungsprotokoll
341
Revision
Datum
Bemerkung
2.0.139.3889
2005-09-15
Neue Behandlung der
Voreinstellungen für den
eMail-Versand
2.0.138.3866
2005-09-07
spooler_log.debug1() bis
spooler_log.debug9() im
Scheduler-Skript werden nicht
mehr unterdrückt
Datenbanktabellen werden mit
varchar statt char angelegt
2.0.138.3851
2005-09-06
Option -pid-file wird bei
Installation als Windows-Dienst
übernommen
Siehe -pid-file
XSLT-eMail erhält <order>
-Element
Das Element <order> wird bei
einem Abbruch der Task im Element
<task> geliefert.
2.0.137.3844
2005-08-24
-sos.ini= akzeptiert Leerzeichen
im Dateinamen
2.0.137.3839
2005-08-21
Neue Methode Job.remove(),
neues XML-Kommando <
modify_job cmd="remove">
Siehe Job.remove() und <
modify_job cmd="remove"> (Seite
187).
<remove_order> wirkt sofort auf
Datenbank
Fehler-eMails jetzt mit richtigem
Nachrichtentext
2.0.136.3836
2005-08-12
Neue Methoden Task.stdout_path
und Task.stderr_path
Siehe Task.stdout_path und
Task.stderr_path .
<remove_order> wirkt sofort auf
Datenbank
Fehler-eMails jetzt mit richtigem
Nachrichtentext
2.0.136.3834
2005-08-12
Fehler bei SQL-Insert für neue
Task führt nicht mehr zur
eMail-Flut
August 2014
Änderungsprotokoll
342
Revision
Datum
Bemerkung
2.0.134.3832
2005-08-12
Änderung der <run_time> eines
Auftrags wirkt nur am Beginn der
Job-Kette
Eine Änderung der <run_time>
eines Auftrags wirkt nur, wenn er am
Anfang der Job-Kette steht und noch
nicht ausgeführt wird. Sonst wird die
Wirkung verzögert, bis der Auftrag
einen Endzustand erreicht hat.
August 2014
Änderungsprotokoll
343
Revision
Datum
Bemerkung
2.0.135.3824
2005-08-10
Kommando <modify_order> kann
<run_time> ändern
In <modify_order> kann jetzt <
run_time> gesetzt werden.
Methode
Job_chain.add_or_replace_order(
) neu
Job_chain.add_or_replace_order
() wirkt wie
Job_chain.add_order() , wenn die
Job-Kette keinen Auftrag mit
gleicher Kennung hat.
Hat die Job-Kette bereits einen
Auftrag mit gleicher Kennung, dann
wird dieser ersetzt. Genauer: er wird
aus der Job-Kette entfernt (wie mit
Order.remove_from_job_chain()
), und der neue Auftrag wird
hinzugefügt.
Falls der ersetzte Auftrag gerade
von einer Task ausgeführt wird,
dann wartet der JobScheduler die
Ausführung ab, bevor der neue
Auftrag ausgeführt werden kann.
Der ersetzte Auftrag erscheint in der
XML-Antwort als <order
replaced="yes"> . Dies nur
innerhalb von <task> , (nicht von <
order_queue> ), denn der Auftrag ist
nicht mehr in der
Auftragswarteschlange.
Der neue, ersetzende Auftrag
erscheint in der XML-Antwort als <
order replacement="yes"> .
Siehe auch <add_order
replace="yes"> (Seite 14).
Methode
Order.remove_from_job_chain()
geändert
( Order.remove_from_job_chain()
wirkt wie <remove_order> .)
Wenn der Auftrag gerade von einer
Task ausgeführt wird, liefert die
Eigenschaft Order.job_chain
August 2014
Änderungsprotokoll
Revision
344
Datum
Bemerkung
weiterhin die Job-Kette, aus der der
Auftrag gerade entfernt wird. Erst
wenn die Ausführung beendet ist,
liefert die Eigenschaft null (außer
der Auftrag ist wieder in eine
Job-Kette eingetragen worden).
Damit bleibt die Eigenschaft
job_chain während der Ausführung
durch die Task stabil.
Der entfernte, aber noch
ausgeführte Auftrag erscheint in der
XML-Antwort als <order
removed="yes"> . Dies nur
innerhalb von <task> , (nicht von <
order_queue> ), denn der Auftrag ist
nicht mehr in der
Auftragswarteschlange.
Java-Methode sos.spooler.id()
liefert auch Integer als String
Statt einem Cast (String) wird jetzt
.toString() gerufen, so dass auch
eine Auftragskennung, die als
Integer-Variant (o.dgl.) gespeichert
ist, in Java als String geliefert wird.
(Bisher gab es eine
ClassCastException.)
let_run_terminate_and_restart
beendet Tasks im Zustand
running_waiting_for_order
Siehe <modify_spooler
cmd="let_run_terminate_and_res
tart"> (Seite 189).
2.0.134.3818
2005-08-04
Klasse sos.spooler.Mail unter
Unix/Java funktionsfähig
Unter Unix in Java war die Klasse
sos.spooler.Mail nicht benutzbar
(Fehlercode COM-80020009 DISP_E_EXCEPTION).
2.0.134.3817
2005-08-03
Order <period single_start>
korrigiert
Der nächste Single_start bei einem
Auftrag mit <period> wird jetzt
korrekt ausgeführt.
August 2014
Änderungsprotokoll
345
Revision
Datum
Bemerkung
2.0.134.3814
2005-08-01
Subprocess.termination_signal
Subprocess.termination_signal
liefert unter Unix 0 oder die Nummer
des Signals, mit dem der
Subprozess endete.
Unter Windows liefert die Methode
0.
2.0.134.3812
2005-07-30
delay_after_error erzeugt neue
Task
Eine Task, für die nach einem Fehler
Job.delay_after_error wirksam
wird, fügt der JobScheduler jetzt (mit
neuer Kennung) erneut in die
Task-Warteschlange ein. Dabei
werden die Task-Parameter
übernommen.
Das gilt nicht für Auftragsjobs. Für
die wird wie bisher keine neue Task
gestartet, denn der Start wird durch
den evtl. anstehenden Auftrag
angestossen.
Neues Attribut
delayed_after_error_task im
Antwort-XML-Element <task>
Siehe <task
delayed_after_error_task="…">
(Seite 222).
Neue Attribute delay_after_error=
und in_period= im
Antwort-XML-Element <job>
Siehe <job
delay_after_error="…"> (Seite
37)
und <job in_period="…"> (Seite
37).
2.0.133.3786
2005-07-04
XSLT-Stylesheets für eMails
Mail.xslt_stylesheet_path setzt
das XSLT-Stylesheet für eMails.
Neue Klasse Xslt_stylesheet
Spooler.create_xslt_stylesheet
() liefert ein Xslt_stylesheet .
2.0.132.3743
2005-06-25
<order_queue> liefert Attribut
next_start_time
August 2014
Änderungsprotokoll
346
Revision
Datum
Bemerkung
2.0.130.3742
2005-06-24
Fehlendes <run_time> wird
wieder wie leeres <run_time/>
interpretiert
2.0.129.3696
2005-06-08
Auftragsjob stoppt bei return
false in spooler_init() oder
spooler_open()
Ein Auftragsjob, der false in
spooler_init() oder
spooler_open() liefert, wird mit
Fehlermeldung gestoppt.
Das Stoppen kann mit
Job.delay_after_error verhindert
werden.
Der Auftrag bleibt in der
Auftragswarteschlange des Jobs
und wird beim nächsten
erfolgreichen Start des Jobs
verarbeitet.
2.1.3.
2010-09-23
JS-474: Aufräge verhalten sich
wie Standalone-Jobs bzgl.
Runtimes/Perioden
Eine leere Runtime oder eine leere
Periode (keine repeat und kein
single_start Attribut) bewirkt nicht
mehr einen automatischen start des
Auftrags. Ist eine solche
Runtimes/Periode zum start eines
Auftrags genutzt worden, müssen
diese Runtimes umkonfiguriert
werden. Eine Lösung ist das
single_start Attribut zu verwenden.
2.1.3.
2010-08-27
JS-559: Der JobScheduler kann
jetzt als Agent fungieren
Durch die Verwendung eines
speziellen Lizenzschlüssels ist es
möglich, den JobScheduler als
Agenten zu betreiben. Er kann in
dieser Funktion keine eigenen Jobs
starten, sondern nimmt lediglich
Aufträge von remote schedulern
entgegen.
August 2014
Änderungsprotokoll
347
Revision
Datum
Bemerkung
2.1.2.
2010-08-11
JS-540: Weitere script-Attribute
für Java API-Jobs
Das script-Element hat ein weiteres
Atribute 'java_class_path' (s.
Dokumentation). Es wird dem
aktuellen Klassenpfad davorgesetzt.
Die aktuellen Werte für den Java
Klassenpfad und die Java VM
Options werden im Task-Log
ausgegeben.
2.1.2.
2010-07-29
JS-550: on_exit_code 'error' wird
korrekt ausgewertet
Wenn on_exit_code 'error' ist,
werden die Kommandos nur dann
ausgeführt, wenn der OS Exit Code
ungleich 0 ist. Bisher sind die
Kommandos immer ausgeführt
worden.
2.1.2.
2010-07-29
JS-436: Job der ausserhalb der
Periode endet erhält jetzt die
korrekte Startzeit
Auch wenn ein Job über das Ende
einer Periode hinaus läuft, erhält er
jetzt die korrekte nächste Startzeit
(nämlich den Beginn der nächsten
Periode).
August 2014
Vom JobScheduler verwendete SQL-Anweisungen
348
Anhang C: Vom JobScheduler verwendete SQL-Anweisungen
Der JobScheduler richtet beim Start fehlende Tabellen mit folgenden Anweisungen ein. Die Anweisungen
unterscheiden sich nach verwendeter Datenbank-Software.
C.1 Vom JobScheduler verwendete SQL-Anweisungen für DB2®
CREATE TABLE SCHEDULER_VARIABLES
(
"NAME"
"WERT"
integer,
"TEXTWERT" varchar(250),
primary key ( "NAME" )
);
CREATE TABLE SCHEDULER_TASKS
(
"TASK_ID"
integer not null,
"SPOOLER_ID"
"CLUSTER_MEMBER_ID" varchar(100),
"JOB_NAME"
"ENQUEUE_TIME"
timestamp,
"START_AT_TIME"
timestamp,
"PARAMETERS"
clob,
"TASK_XML"
clob,
primary key( "TASK_ID" )
);
CREATE TABLE SCHEDULER_HISTORY
(
"ID"
integer not null,
"SPOOLER_ID"
"JOB_NAME"
"START_TIME"
timestamp not null,
"END_TIME"
timestamp,
"CAUSE"
varchar(50),
"STEPS"
integer,
"EXIT_CODE"
integer,
"ERROR"
numeric(1),
"ERROR_CODE"
varchar(50),
"ERROR_TEXT"
varchar(250),
"PARAMETERS"
clob,
"LOG"
blob,
primary key( "ID" )
);
CREATE
CREATE
CREATE
CREATE
INDEX
INDEX
INDEX
INDEX
SCHEDULER_HIST_1
SCHEDULER_HIST_2
SCHEDULER_HIST_3
SCHEDULER_HIST_4
on
on
on
on
SCHEDULER_HISTORY
SCHEDULER_HISTORY
SCHEDULER_HISTORY
SCHEDULER_HISTORY
(
(
(
(
"START_TIME" );
"SPOOLER_ID" );
"JOB_NAME" );
"CLUSTER_MEMBER_ID" );
CREATE TABLE SCHEDULER_ORDERS
(
August 2014
349
"JOB_CHAIN"
"ID"
"SPOOLER_ID"
"DISTRIBUTED_NEXT_TIME"
timestamp,
"OCCUPYING_CLUSTER_MEMBER_ID" varchar(100),
"PRIORITY"
integer not null,
"STATE"
varchar(100),
"STATE_TEXT"
varchar(100),
"TITLE"
varchar(200),
"CREATED_TIME"
timestamp not null,
"MOD_TIME"
timestamp,
"ORDERING"
integer not null,
"PAYLOAD"
clob,
"INITIAL_STATE"
varchar(100),
"RUN_TIME"
clob,
"ORDER_XML"
clob,
primary key( "SPOOLER_ID", "JOB_CHAIN", "ID" )
);
CREATE TABLE SCHEDULER_ORDER_HISTORY
(
"HISTORY_ID" integer not null,
"JOB_CHAIN" varchar(255) not null,
"ORDER_ID"
"SPOOLER_ID" varchar(100) not null,
"TITLE"
varchar(200),
"STATE"
varchar(100),
"STATE_TEXT" varchar(100),
"START_TIME" timestamp not null,
"END_TIME"
timestamp not null,
"LOG"
blob,
primary key( "HISTORY_ID" )
);
CREATE INDEX SCHED_O_HIST_1 on SCHEDULER_ORDER_HISTORY ( "SPOOLER_ID" );
CREATE INDEX SCHED_O_HIST_2 on SCHEDULER_ORDER_HISTORY ( "JOB_CHAIN" );
CREATE INDEX SCHED_O_HIST_3 on SCHEDULER_ORDER_HISTORY ( "START_TIME" );
CREATE TABLE SCHEDULER_ORDER_STEP_HISTORY
(
"HISTORY_ID"
numeric(9)
not
"STEP"
numeric(9)
not
"TASK_ID"
numeric(9)
not
"STATE"
varchar(100)
"START_TIME"
timestamp
not
"END_TIME"
timestamp
primary key ( "HISTORY_ID","STEP" )
);
null,
null,
null,
,
null,
,
CREATE TABLE SCHEDULER_CLUSTERS
(
"MEMBER_ID"
"SCHEDULER_ID"
"PRECEDENCE"
integer,
"LAST_HEART_BEAT"
integer,
"NEXT_HEART_BEAT"
integer,
"ACTIVE"
numeric(1),
August 2014
"EXCLUSIVE"
"DEAD"
"COMMAND"
"HTTP_URL"
"DEACTIVATING_MEMBER_ID"
"XML"
primary key( "MEMBER_ID"
350
numeric(1),
numeric(1),
varchar(250),
varchar(100),
varchar(100),
clob,
)
);
C.2 Vom JobScheduler verwendete SQL-Anweisungen für Microsoft SQL Server
(
"NAME"
"WERT"
integer,
);
(
"TASK_ID"
integer not null,
"SPOOLER_ID"
"JOB_NAME"
"ENQUEUE_TIME"
datetime,
"START_AT_TIME"
datetime,
"PARAMETERS"
ntext,
"TASK_XML"
ntext,
);
(
"ID"
integer not null,
"SPOOLER_ID"
"JOB_NAME"
"START_TIME"
datetime not null,
"END_TIME"
datetime,
"CAUSE"
varchar(50),
"STEPS"
integer,
"EXIT_CODE"
integer,
"ERROR"
bit,
"ERROR_CODE"
varchar(50),
"ERROR_TEXT"
varchar(250),
"PARAMETERS"
ntext,
"LOG"
image,
primary key( "ID" )
);
CREATE INDEX SCHEDULER_HISTORY_START_TIME on SCHEDULER_HISTORY ( "START_TIME" );
CREATE INDEX SCHEDULER_HISTORY_SPOOLER_ID on SCHEDULER_HISTORY ( "SPOOLER_ID" );
CREATE INDEX SCHEDULER_HISTORY_JOB_NAME
on SCHEDULER_HISTORY ( "JOB_NAME" );
August 2014
CREATE INDEX SCHEDULER_H_CLUSTER_MEMBER
"CLUSTER_MEMBER_ID");
351
on SCHEDULER_HISTORY (
(
"JOB_CHAIN"
"ID"
"SPOOLER_ID"
datetime,
"PRIORITY"
integer not null,
"STATE"
varchar(100),
"STATE_TEXT"
varchar(100),
"TITLE"
varchar(200),
"CREATED_TIME"
datetime not null,
"MOD_TIME"
datetime,
"ORDERING"
integer not null,
"PAYLOAD"
ntext,
"INITIAL_STATE"
varchar(100),
"RUN_TIME"
ntext,
"ORDER_XML"
ntext,
primary key( "SPOOLER_ID", "JOB_CHAIN", "ID" );
);
(
"ORDER_ID"
"TITLE"
varchar(200),
"STATE"
varchar(100),
"START_TIME" datetime not null,
"END_TIME"
datetime not null,
"LOG"
image,
primary key( "HISTORY_ID" );
);
CREATE INDEX SCHEDULER_O_HISTORY_SPOOLER_ID on SCHEDULER_ORDER_HISTORY ( "SPOOLER_ID"
);
CREATE INDEX SCHEDULER_O_HISTORY_JOB_CHAIN on SCHEDULER_ORDER_HISTORY ( "JOB_CHAIN"
);
CREATE INDEX SCHEDULER_O_HISTORY_START_TIME on SCHEDULER_ORDER_HISTORY ( "START_TIME"
);
(
"HISTORY_ID"
numeric(9)
not
"STEP"
numeric(9)
not
"TASK_ID"
numeric(9)
not
"STATE"
varchar(100)
"START_TIME"
datetime
not
"END_TIME"
datetime
);
null,
null,
null,
,
null,
,
August 2014
352
(
"MEMBER_ID"
"SCHEDULER_ID"
"PRECEDENCE"
integer,
"LAST_HEART_BEAT"
integer,
"NEXT_HEART_BEAT"
integer,
"ACTIVE"
numeric(1),
"EXCLUSIVE"
numeric(1),
"DEAD"
numeric(1),
"COMMAND"
varchar(250),
"HTTP_URL"
varchar(100),
"DEACTIVATING_MEMBER_ID" varchar(100),
"XML"
ntext,
primary key( "MEMBER_ID" )
);
C.3 Vom JobScheduler verwendete SQL-Anweisungen für MySQL®
(
"NAME"
"WERT"
integer,
)
Type=InnoDB;
(
"TASK_ID"
integer not null,
"SPOOLER_ID"
"JOB_NAME"
"ENQUEUE_TIME"
datetime,
"START_AT_TIME"
datetime,
"PARAMETERS"
longtext,
"TASK_XML"
longtext,
)
Type=InnoDB;
(
"ID"
integer not null,
"SPOOLER_ID"
"JOB_NAME"
"START_TIME"
datetime not null,
"END_TIME"
datetime,
"CAUSE"
varchar(50),
"STEPS"
integer,
"EXIT_CODE"
integer,
"ERROR"
bool,
August 2014
"ERROR_CODE"
"ERROR_TEXT"
"PARAMETERS"
"LOG"
primary key( "ID" )
353
varchar(50),
varchar(250),
longtext,
longblob,
)
Type=InnoDB;
CREATE
CREATE
CREATE
CREATE
INDEX
INDEX
INDEX
INDEX
SCHEDULER_HISTORY_START_TIME
SCHEDULER_HISTORY_SPOOLER_ID
SCHEDULER_HISTORY_JOB_NAME
SCHEDULER_H_CLUSTER_MEMBER
on
on
on
on
SCHEDULER_HISTORY
SCHEDULER_HISTORY
SCHEDULER_HISTORY
SCHEDULER_HISTORY
("START_TIME"
):
("SPOOLER_ID"
):
("JOB_NAME"
):
("CLUSTER_MEMBER_ID");
(
"JOB_CHAIN"
varchar(255) character set latin1
"ID"
"SPOOLER_ID"
datetime,
"PRIORITY"
integer not null,
"STATE"
varchar(100),
"STATE_TEXT"
varchar(100),
"TITLE"
varchar(200),
"CREATED_TIME"
datetime not null,
"MOD_TIME"
datetime,
"ORDERING"
integer not null,
"PAYLOAD"
longtext,
"INITIAL_STATE"
varchar(100),
"RUN_TIME"
longtext,
"ORDER_XML"
longtext,
primary key ( "SPOOLER_ID", "JOB_CHAIN", "ID" )
)
Type=InnoDB;
not null,
not null,
not null,
(
"ORDER_ID"
"TITLE"
varchar(200),
"STATE"
varchar(100),
"END_TIME"
datetime not null,
"LOG"
longblob,
)
Type=InnoDB;
);
);
);
August 2014
(
"HISTORY_ID"
integer
not
"STEP"
integer
not
"TASK_ID"
integer
not
"STATE"
varchar(100)
"START_TIME"
datetime
not
"END_TIME"
datetime
);
354
null,
null,
null,
,
null,
,
(
"MEMBER_ID"
"SCHEDULER_ID"
"PRECEDENCE"
integer,
"LAST_HEART_BEAT"
integer,
"NEXT_HEART_BEAT"
integer,
"ACTIVE"
bool,
"EXCLUSIVE"
bool,
"DEAD"
bool,
"COMMAND"
varchar(250),
"HTTP_URL"
varchar(100),
"XML"
longtext,
)
Type=InnoDB;
C.4 Vom JobScheduler verwendete SQL-Anweisungen für Oracle®
(
"NAME"
varchar2(100) not null,
"WERT"
integer,
"TEXTWERT" varchar2(250),
);
(
"TASK_ID"
integer not null,
"SPOOLER_ID"
"CLUSTER_MEMBER_ID" varchar2(100),
"JOB_NAME"
"ENQUEUE_TIME"
date,
"START_AT_TIME"
date,
"PARAMETERS"
clob,
"TASK_XML"
clob,
);
(
August 2014
"ID"
"SPOOLER_ID"
"CLUSTER_MEMBER_ID"
"JOB_NAME"
"START_TIME"
"END_TIME"
"CAUSE"
"STEPS"
"EXIT_CODE"
"ERROR"
"ERROR_CODE"
"ERROR_TEXT"
"PARAMETERS"
"LOG"
primary key( "ID" )
355
integer not null,
varchar2(100),
date not null,
date,
varchar2(50),
integer,
integer,
numeric(1),
varchar2(50),
varchar2(250),
clob,
blob,
);
CREATE
CREATE
CREATE
CREATE
INDEX
INDEX
INDEX
INDEX
on
on
on
on
SCHEDULER_HISTORY
SCHEDULER_HISTORY
SCHEDULER_HISTORY
SCHEDULER_HISTORY
("START_TIME"
);
("SPOOLER_ID"
);
("JOB_NAME"
);
(
"JOB_CHAIN"
"ID"
"SPOOLER_ID"
date,
"OCCUPYING_CLUSTER_MEMBER_ID" varchar2(100),
"PRIORITY"
integer not null,
"STATE"
varchar2(100),
"STATE_TEXT"
varchar2(100),
"TITLE"
varchar2(200),
"CREATED_TIME"
date not null,
"MOD_TIME"
date,
"ORDERING"
integer not null,
"PAYLOAD"
clob,
"INITIAL_STATE"
varchar2(100),
"RUN_TIME"
clob,
"ORDER_XML"
clob,
);
(
"JOB_CHAIN" varchar2(255) not null,
"ORDER_ID"
"SPOOLER_ID" varchar2(100) not null,
"TITLE"
varchar2(200),
"STATE"
varchar2(100),
"STATE_TEXT" varchar2(100),
"START_TIME" date not null,
"END_TIME"
date not null,
"LOG"
blob,
);
August 2014
356
);
);
);
(
"HISTORY_ID"
number(9)
not
"STEP"
number(9)
not
"TASK_ID"
number(9)
not
"STATE"
varchar2(100)
"START_TIME"
date
not
"END_TIME"
date
);
null,
null,
null,
,
null,
,
(
"MEMBER_ID"
"SCHEDULER_ID"
"PRECEDENCE"
integer,
"LAST_HEART_BEAT"
integer,
"NEXT_HEART_BEAT"
integer,
"ACTIVE"
numeric(1),
"EXCLUSIVE"
numeric(1),
"DEAD"
numeric(1),
"COMMAND"
varchar2(250),
"HTTP_URL"
varchar2(100),
"DEACTIVATING_MEMBER_ID" varchar2(100),
"XML"
clob,
);
C.5 Vom JobScheduler verwendete SQL-Anweisungen für PostgreSQL
(
"NAME"
"WERT"
integer,
);
(
"TASK_ID"
integer not null,
"SPOOLER_ID"
"JOB_NAME"
"ENQUEUE_TIME"
timestamp,
"START_AT_TIME"
timestamp,
August 2014
357
"PARAMETERS"
text,
"TASK_XML"
text,
);
(
"ID" integer not null,
"SPOOLER_ID"
"JOB_NAME"
"START_TIME"
timestamp not null,
"END_TIME"
timestamp,
"CAUSE"
varchar(50),
"STEPS"
integer,
"EXIT_CODE"
integer,
"ERROR"
numeric(1),
"ERROR_CODE"
varchar(50),
"ERROR_TEXT"
varchar(250),
"PARAMETERS"
text,
"LOG"
bytea,
primary key( "ID" )
)
CREATE
CREATE
CREATE
CREATE
INDEX
INDEX
INDEX
INDEX
on
on
on
on
SCHEDULER_HISTORY
SCHEDULER_HISTORY
SCHEDULER_HISTORY
SCHEDULER_HISTORY
("START_TIME"
);
("SPOOLER_ID"
);
("JOB_NAME"
);
(
"JOB_CHAIN"
"ID"
"SPOOLER_ID"
timestamp,
"PRIORITY"
integer not null,
"STATE"
varchar(100),
"STATE_TEXT"
varchar(100),
"TITLE"
varchar(200),
"CREATED_TIME"
timestamp not null,
"MOD_TIME"
timestamp,
"ORDERING"
integer not null,
"PAYLOAD"
text,
"INITIAL_STATE"
varchar(100),
"RUN_TIME"
text,
"ORDER_XML"
text,
);
(
"ORDER_ID"
"TITLE"
varchar(200),
August 2014
"STATE"
"STATE_TEXT"
"START_TIME"
"END_TIME"
"LOG"
primary key(
358
varchar(100),
varchar(100),
timestamp not null,
timestamp not null,
bytea,
"HISTORY_ID" )
);
);
);
CREATE INDEX SCHEDULER_O_HISTORY_START_TIME ON SCHEDULER_ORDER_HISTORY ( "START_TIME"
);
(
"HISTORY_ID"
numeric(9)
not
"STEP"
numeric(9)
not
"TASK_ID"
numeric(9)
not
"STATE"
varchar(100)
"START_TIME"
timestamp
not
"END_TIME"
timestamp
);
null,
null,
null,
,
null,
,
(
"MEMBER_ID"
"SCHEDULER_ID"
"PRECEDENCE"
integer,
"LAST_HEART_BEAT"
integer,
"NEXT_HEART_BEAT"
integer,
"ACTIVE"
numeric(1),
"EXCLUSIVE"
numeric(1),
"DEAD"
numeric(1),
"COMMAND"
varchar(250),
"HTTP_URL"
varchar(100),
"XML"
text,
);
C.6 Vom JobScheduler verwendete SQL-Anweisungen für Sybase ASE
(
"NAME"
"WERT"
integer,
);
August 2014
359
(
"TASK_ID"
integer not null,
"SPOOLER_ID"
"JOB_NAME"
"ENQUEUE_TIME"
datetime,
"START_AT_TIME"
datetime,
"PARAMETERS"
text,
"TASK_XML"
text,
);
(
"ID"
integer not null,
"SPOOLER_ID"
"JOB_NAME"
"START_TIME"
datetime not null,
"END_TIME"
datetime,
"CAUSE"
varchar(50),
"STEPS"
integer,
"EXIT_CODE"
integer,
"ERROR"
numeric(1),
"ERROR_CODE"
varchar(50),
"ERROR_TEXT"
varchar(250),
"PARAMETERS"
text,
"LOG"
image,
primary key( "ID" )
);
CREATE INDEX SCHEDULER_HISTORY_START_TIME
CREATE INDEX SCHEDULER_HISTORY_SPOOLER_ID
CREATE INDEX SCHEDULER_HISTORY_JOB_NAME
CREATE INDEX SCHEDULER_H_CLUSTER_MEMBER
"CLUSTER_MEMBER_ID");
(
"JOB_CHAIN"
"ID"
"SPOOLER_ID"
"OCCUPYING_CLUSTER_MEMBER_ID"
"PRIORITY"
"STATE"
"STATE_TEXT"
"TITLE"
"CREATED_TIME"
"MOD_TIME"
"ORDERING"
"PAYLOAD"
"INITIAL_STATE"
"RUN_TIME"
"ORDER_XML"
on
on
on
on
SCHEDULER_HISTORY
SCHEDULER_HISTORY
SCHEDULER_HISTORY
SCHEDULER_HISTORY
( "START_TIME" );
( "SPOOLER_ID" );
( "JOB_NAME" );
(
datetime,
varchar(100),
integer not null,
varchar(100),
varchar(100),
varchar(200),
datetime not null,
datetime,
integer not null,
text,
varchar(100),
text,
text,
August 2014
360
primary key( "SPOOLER_ID", "JOB_CHAIN", "ID" );
);
(
"ORDER_ID"
"TITLE"
varchar(200),
"STATE"
varchar(100),
"END_TIME"
datetime not null,
"LOG"
image,
primary key( "HISTORY_ID" );
);
);
);
);
(
"HISTORY_ID"
numeric(9)
not
"STEP"
numeric(9)
not
"TASK_ID"
numeric(9)
not
"STATE"
varchar(100)
"START_TIME"
datetime
not
"END_TIME"
datetime
);
null,
null,
null,
,
null,
,
(
"MEMBER_ID"
"SCHEDULER_ID"
"PRECEDENCE"
integer,
"LAST_HEART_BEAT"
integer,
"NEXT_HEART_BEAT"
integer,
"ACTIVE"
numeric(1),
"EXCLUSIVE"
numeric(1),
"DEAD"
numeric(1),
"COMMAND"
varchar(250),
"HTTP_URL"
varchar(100),
"XML"
text,
);
August 2014
Skripte in JavaScript
361
Anhang D: Skripte in JavaScript
JavaScript liegt in zwei Implementierungen vor:
<script language="JavaScript">
Spidermonkey von Mozilla, wird mit dem JobScheduler ausgeliefert.
<script language="JScript">
Microsoft JScript steht auf auf Windows-Betriebssystemen zur Verfügung (die Version ist abhängig von
Betriebssystem und Internet Explorer).
D.1 Java-Exceptions in Spidermonkey
Bei einer Exception in einem Java-Konstruktor und in einer Java-Methode werden Exception-Objekt
unterschiedlicher Klassen erzeugt. Der Fehlertext kann bei jeder Exception (auch normalen JavaScript-Exception)
so ermittelt werden:
catch( x )
{
var error_text = x + "";
}
Hier ein Beispiel, das auf die verschiedenen Exceptions Rücksicht nimmt:
function log_exception( x )
{
var msg = x + "";
if( x.getMessage
) spooler_log.error(
x.printStackTrace( java.lang.System.out );
else
if( x.message != undefined ) spooler_log.error(
msg );
else
if( x.length != undefined ) spooler_log.error(
Java-Konstruktor-Exception: " + msg );
else
spooler_log.error(
);
}
"Java-Exception: " + msg ),
"Eine JavaScript-Exception: " +
"Anscheinend eine
"Unbekannte Exception: " + msg
try
{
throw new Error( "Ein Javascript-Fehler" );
}
catch( x )
{
log_exception( x );
}
// x ist Error
try
{
var file = java.io.FileInputStream( "gibtsnicht" );
Konstruktor
// Exception im
August 2014
Skripte in JavaScript
}
catch( x )
{
log_exception( x );
}
362
// x ist Character-Array
try
{
java.lang.Class.forName( "blah" );
Java-Methode
}
catch( x )
{
log_exception( x );
}
// Exception in einer
// x ist Java-Exception
August 2014
Stichwortverzeichnis
363
A
absolute_repeat 56
action 184, 188
<add_jobs> 180
<add_order> 14, 180
after 70, 204
Agent 154
all_schedulers 205
all_steps 211
all_tasks 211
<allowed_host> 15
<answer> 206
Arbeitsverzeichnis 100
at 17, 70, 15, 181, 189, 205
<at> 16
Auftragskennung 46
Auftragsprotokoll 168
B
<base> 17
before 198
begin 64, 55
C
calling 224
category 197
cause 223, 209
central_configuration_directory
21
<check_folders> 182
class 207
<cluster> 18
cmd 187, 189
code 207
col 207
COM 148, 148
com_class 67
<commands> 19
-config 87
<config> 21
config_file 220
configuration_add_event 22
configuration_delete_event 22
configuration_directory 21
configuration_modify_event 22
<content> 24
continue_exclusive_operation 206
<copy_params> 24
count 224
create table (SQL) 348
created 216
D
Daemon 137, 137
date 26, 32
<date> 26
Datei 159
Dateiauftragsquelle 159
Dateiauftragssenke 160
Datenbank 130, 169
Datenbanktabellen 348
day 77, 27
<day> 26
db 220
db_waiting 221
debug 76
delay 27, 28, 46, 197
delay_after_error 31, 211
<delay_after_error> 27
<delay_order_after_setback> 28
delayed_after_error_task 224
<description> 29
Dienst 107, 107, 137, 137
directory 71, 31
distributed 44
E
ECMAScript 361
eMail-Versand 169
enabled 42, 211
encoding 67
end 64, 55
end_state 15, 182, 189
end_time 209
enqueued 223, 218
<environment> 29
error 146, 209
<ERROR> 207
error_code 209
error_count 27
error_state 46, 47, 213
error_text 209
Exception (Java) 361
exclusive 50
F
file 17, 58, 36
<file_based> 208
<file_order_sink> 29
<file_order_source> 30
filename 67, 208
finished 212
folder 187
force 71, 205
force_idle_timeout 40
forward_xslt_stylesheet 76
from 25, 198
G
GUI
175
H
has_description 211
Hauptprotokoll 168
heart_beat_own_timeout 18
heart_beat_timeout 18
heart_beat_warn_timeout 18
highest_level 213
Historie 130, 132
<history.entry> 209
<history> 208
history_id 202
<holiday> 32
<holidays> 32
host 16
HTML 174
HTTP Server 174
<http.authentication> 33
<http.user> 34
<http.users> 34
<http_directory> 35
<http_server> 36
I
ID 46
id 14, 181, 184, 199, 204, 220, 223,
209
idle_since 223
idle_timeout 39
ignore 61
ignore_error 59
ignore_signal 59
ignore_signals 40
ignore_unknown_hosts 68
immediately 184
in_period 211
in_process_since 216, 223
-include-path 24, 90
<include> 36
Indices (SQL) 348
-ip-address 24
is_maximum 28
J
java 76
Java-Exception 361
java_class 67
java_class_path 67
java_options 40
JavaScript 361
Job 144
job 70, 45, 182, 184, 187, 199, 200,
204, 210, 216, 225
<job.why> 182
<job> 38, 210
August 2014
364
job_chain
75, 14, 47, 181, 183, mail_on_process 214
183, 188, 196, 196, 200, 200, 202, 216 mail_on_success 214
<job_chain.modify> 183
mail_on_warning 213
<job_chain> 42, 212
mail_subject 214
<job_chain_node.end> 46
mail_to 214
<job_chain_node.job_chain> 46
max 31
<job_chain_node.modify> 183
max_non_exclusive 49, 186
<job_chain_node> 45, 212
max_order_history 201, 201, 203
<job_chains> 47
max_orders 44, 200, 202, 200, 201,
job_name 209
203
Jobprotokoll 168
max_processes 60, 194
<jobs> 48
max_task_history 200, 202, 203
min_tasks 39
K
<modify_hot_folder> 186
key 185
<modify_job> 187
<kill_task> 184
<modify_order> 188
killed 222
<modify_spooler> 189
Konfiguration 7, 17, 87, 100
<monitor> 50
Konfigurationsverzeichnis, lokales
month 52
21
<month> 52
<monthdays> 52
L
move_to 30
language 67
Mozilla 361
last_error 213
Mutex 152
last_warning 213
last_write_time 208
length 217, 218
let_run 64, 56
level 16, 213
<licence.use> 185
limit 198
line 207
live_file 36
Lock 152
lock 50, 186
<lock.remove> 186
<lock.use> 49
<lock> 48, 185
<locks> 50
-log 90
Log-Datei 168
-log-dir 90
-log-level 90, 85
<log> 213
<log_categories> 214
log_dir 23
log_file 58, 211, 216, 220, 224
Lokales Konfigurationsverzeichnis
21
loop 221
M
Mail-Versand 169
mail_bcc 214
mail_cc 214
mail_from 214
mail_on_error 213
N
name
60, 65, 49, 34, 75, 38,
73, 54, 51, 70, 44, 185, 191, 191,
193, 194, 204, 212, 223, 218
next 199
next_start_time 211, 216, 217
next_state 32, 46, 47, 212
node 37
none 210
O
<ok> 214
on_error 46
on_exit_code 19
once 63
order 38, 188, 196, 202, 211, 215
<order> 215
Order_id_space 46
<order_queue> 217
ordering 52
orders 212, 213
orders_recoverable 44
P
param 23, 58,
<param.get> 191
<param> 53, 190
<params.get> 193
<params> 54, 191, 192
password_md5 34
path 35
<payload> 193
pending 146, 211
<period> 55
pid 220, 224, 222
-port 23
prev 199
Priorität 158
priority 40, 15, 181, 189, 216, 224,
222
<process> 57
process_class 38, 195
<process_class.remove> 195
<process_class> 59, 193
<process_classes> 61, 217
<processes> 217
Protokoll 131, 168, 174
Q
<queued_task> 218
<queued_tasks> 218
R
read_error 146, 210
regex 72, 31
Remote 154
Remote Execution 154
remote_scheduler 60, 154, 194
remove 30, 211
<remove_job_chain> 195
<remove_order> 196
removed 216
<removed> 218
removing 212
repeat 64, 55, 31
replace 60, 41, 14, 181, 195
replaced 216
replacement 217
<replacement> 219
request_xslt_stylesheet 76
response_xslt_stylesheet 76
restart 206
<run_time> 61
running 146, 211
running_since 223
S
schedule 63, 196
<schedule.remove> 196
<schedule> 65
scheduler.log 168
SCHEDULER_CONFIGURATION_
DIRECTORY 57
SCHEDULER_HOST 57
SCHEDULER_JOB_CHAIN 57
SCHEDULER_JOB_CHAIN_CONFI
GURATION_DIRECTORY 57
SCHEDULER_JOB_CONFIGURATI
ON_DIRECTORY 57
August 2014
SCHEDULER_JOB_NAME 57
<scheduler_log.log_categories.reset
> 197
<scheduler_log.log_categories.set>
197
<scheduler_log.log_categories.show
> 197
SCHEDULER_ORDER_ID 57
SCHEDULER_SUPERVISOR_HOS
T 57
SCHEDULER_SUPERVISOR_POR
T 57
SCHEDULER_TASK_ID 58
SCHEDULER_TASK_TRIGGER_FI
LES 58
SCHEDULER_TCP_PORT 58
SCHEDULER_UDP_PORT 58
<schedules> 66
scheme 34
Schwarze Liste 160
<script> 66
<security> 68
Semaphor 152
Service 107, 107
<service_request> 68
<service_response> 69
setback 188, 216
setback_count 28
<settings> 69
<show_calendar> 198
<show_history> 199
<show_job> 199
<show_job_chain> 200
<show_job_chains> 201
<show_jobs> 201
<show_order> 202
<show_state> 203
<show_task> 203
single_start 64, 56
smtp 214
sos.ini 93
<sos.spooler.variable_set> 69
source 207
Sperre 152
Spidermonkey 361
<spooler> 70
spooler_id 22, 38, 220, 209
spooler_running_since 220
start_at 223, 218
<start_job> 70, 204
start_time 209
start_time_function 63
<start_when_directory_changed>
71
365
state
15, 45, 30, 47, 46, 181, 183 waiting_for_process 211
, 184, 188, 210, 212, 216, 220, 223, 208,
<waiting_jobs> 225
212
waits 221
<state> 220
warn_if_longer_than 42
state_text 211, 216
warn_if_shorter_than 42
steps 224, 209
Web Interface 175
stop_on_error 41
web_service 71, 15, 181, 205, 217,
stopped 146, 210
224
stopping 146, 210
<web_service> 73
<subprocess> 221
<weekday> 77
<subprocesses> 222
<weekdays> 78
substitute 65
what 198, 199, 200, 202, 201, 201, 202
supervisor 22
, 203, 204
suspended 189
when_holiday 64, 56
which 77
T
task 216, 223, 209, 218
<task> 223
Taskprotokoll 168
tasks 39, 211
<tasks> 224
-tcp-port 23
tcp_port 221
temporary 40, 211
<terminate> 205
text 207
time 207, 207, 221
-time-zone 24
time_zone 63
timeout 76, 39, 190, 206
timeout_at 222
title 38, 15, 44, 181, 188, 215
X
xercesImpl.jar 76
XML-Konfiguration
100
<xml_payload> 206
7, 17, 87,
U
-udp-port 23
udp_port 221
<ultimos> 72
Umgebungsvariablen 57, 57
under_construction 212
url 68
url_path 35, 75
User Interface 175
V
valid_from 65
valid_to 66
value 73, 54, 191, 197
<variable> 72
Verschachtelte Jobketten
version 220
Verzeichnis 100, 159
visible 40, 44
46
W
wait_until 220
waiting_errno 221
waiting_errno_filename 221
waiting_errno_text 221
August 2014

jobscheduler - Flipbeets.com

Transcription

Similar documents

JobScheduler: API - Software- und Organisations

UNSER TÄGLICH BROT

marktview: backup-systeme

Versionshinweise - Xerox Support and Drivers

1 Einführung in die Suite

Thread - Universität Ulm

Personalwirtschaft Extra

den idealen Überblick