XML-Element  <config>     (Konfiguration)

Voreingestellt ist das Verzeichnis remote im Verzeichnis der Konfigurationsdatei, siehe -config.

Das Verzeichnis ist für den Supervisor-Betrieb, bei dem andere Scheduler sich anmelden mit <config supervisor="…">. Das Verzeichnis kann für jeden Scheduler ein Unterverzeichnis mit Konfigurationsdateien enthalten, die der Supervisor zum Scheduler laufend repliziert.

Scheduler 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 Scheduler kein Verzeichnis anzugeben. Dann wird nur die Konfiguration aus dem Verzeichnis _all, falls vorhanden, übertragen.

Meldungen

Voreingestellt ist das Verzeichnis live im Verzeichnis der Konfigurationsdatei, siehe -config.

Diesem Verzeichnis entnimmt der Scheduler die Definitionen der Jobs usw., siehe »Konfiguration aus Hot Folders«.

Der angegebene Job wird gestartet, wenn der Scheduler 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 Scheduler das Konfigurationsverzeichnis liest.

Die gestartete Task hat drei Parameter (erreichbar über spooler_task.params):

Diese Task-Parameter stehen auch bereit als Umgebungsvariablen SCHEDULER_LIVE_EVENT, SCHEDULER_LIVE_FILEPATH und SCHEDULER_LIVE_FILEBASE.

Der angegebene Job wird gestartet, wenn der Scheduler eine geänderte 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 Scheduler das Konfigurationsverzeichnis liest.

Parameter und Umgebungsvariablen sind gesetzt wie bei <config configuration_add_event="…">.

Der angegebene Job wird gestartet, wenn aus dem Konfigurationsverzeichnis eine im Scheduler geladene Datei entfernt worden ist.

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 Scheduler das Konfigurationsverzeichnis liest.

Parameter und Umgebungsvariablen sind gesetzt wie bei <config configuration_add_event="…">.

Der Supervisor, bei dem sich dieser Scheduler 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 Scheduler sich bei ihn anmelden.

Der Supervisor kann für den Scheduler die Konfiguration bestimmen, s. <config central_configuration_directory="…">. Die übernommene Konfiguration hält der Scheduler im Verzeichnis cache.

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.

Fasst die Einstellungen tcp_port und udp_port zusammen.

Siehe auch <config tcp_port="…">. und <config udp_port="…">.

Beispiel  

<config port="4444">

Der Job Scheduler 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 Job Scheduler einen HTTP/HTML-Server, so dass er über einen Browser ansprechbar ist, z.B. http://localhost:4444.

Bei tcp_port=0 (voreingestellt) ist der Job Scheduler nicht über TCP oder HTTP ansprechbar. Damit kann die Steuerung des Job Schedulers per TCP-Kommando, z.B. über eine Web-Seite, unterbunden werden.

Siehe auch <config port="…">.

Beispiel  

<config tcp_port="4444">

Auch über UDP kann der Job Scheduler Kommandos entgegennehmen. Hier wird die Portnummer angegeben. Ein Kommando muss in eine Nachricht passen. Der Job Scheduler schickt keine Antwort.

Bei udp_port=0 (voreingestellt) öffnet der Job Scheduler keinen UDP-Port.

Siehe auch <config port="…">.

Beispiel  

<config udp_port="4444">

Setzt spooler.param (Objekt spooler, Eigenschaft param). Zur freien Verwendung in den Skripten.

Gibt das Verzeichnis an, an das der Scheduler die Protokoll schreibt.

log_dir="*stderr" lässt den Scheduler das Hauptprotokoll nach stderr schreiben.

Verzeichnis der Dateien, die mit <include> eingezogen werden.

Umgebungsvariablen (z.B. $HOME) werden ersetzt (siehe hier).

Der Pfad eines XSLT-Stylesheets. Der Job Scheduler verwendet das XSLT-Stylesheet zum Aufbereiten der eMails. (Die Dokumentation hierzu ist noch nicht geschrieben.)

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 Job Scheduler 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.

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=…).

Umgebungsvariablen (z.B. $HOME) werden ersetzt (siehe hier).

Beispiel  

class_path = s:\prod\bind\sos.*.jar;c:\jar\my.jar;c:\jar\*

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=…).

Umgebungsvariablen (z.B. $HOME) werden ersetzt (siehe hier).

Beispiel  

options = -Xdebug -Djava.library.path=s:/prod/bind

Die IP-Adresse, an die TCP- und UDP-Port gebunden werden. Der Job Scheduler 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 Job Scheduler nicht über localhost erreicht werden.

Eine Basiskonfigurationsdatei kann hier angegeben werden, die der Scheduler zuerst auswertet. Die Einstellungen darin bilden die Voreinstellungen für die Konfigurationsdatei, die das Element <base> enthält.

<base> kann wiederholt werden.

Die eingestellten Parameter können mit Spooler.variables abgerufen werden.

Jede Prozessklasse stellt eine Anzahl Prozesse zum Betrieb der Jobs bereit.

Dieses Element sollte angegeben werden, denn sonst laufen die Jobs im Prozess des Schedulers, was nur zum Debuggen empfehlenswert ist.

Beispiel  

<process_classes/>

Wie <scheduler_script><script>, siehe unten.

Das hierin enthaltene Skript führt der Scheduler beim Start, vor jedem Job aus. Wenn die Methode spooler_init() implementiert ist, ruft der Scheduler sie auf. Es eignet sich zum Setzen von Scheduler-Variablen.

Bei einem Fehler bricht der Scheduler ab.

Das Skript wird erst geschlossen, wenn der Scheduler endet.

Beispiel  

<scheduler_script>
    <script language="javascript"><![CDATA[

        spooler.variables( "database_name" ) = "db7";

    ]]></script>
</scheduler_script>

Grundsätzliche Einstellung der Feiertage (an denen Jobs nicht laufen sollen).

Enthält die Jobs als Folge von <job>-Elementen.

Beispiel  

<script language="javascript"><![CDATA[

    spooler.variables( "database_name" ) = "db7";

]]></script>

Die Kommandos werden beim Start des Schedulers vor dem Scheduler-Skript ausgeführt. Ein Fehler führt zum Abbruch des Schedulers.