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 Job Scheduler automatisch nach Änderung übernimmt. Der Job Scheduler ü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.

Konfigurationsverzeichnis

Die Dateien liest der Job Scheduler aus dem Konfigurationsvereichnis und dessen Unterverzeichnissen. Das Konfigurationsverzeichnis kann eingestellt werden mit

• <config configuration_directory="…">, voreingestellt ist das Verzeichnis ./config/live im Verzeichnis der Konfigurationsdatei.
• -config. Die Konfigurationsdatei erwartet der Scheduler dann im Konfigurationsverzeichnis (Voreinstellung ./config) unter dem Namen scheduler.xml.

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

Unter Windows verwendet der Job Scheduler die Verzeichnisüberwachung des Betriebsystems, bemerkt Änderungen also sofort. Außerdem prüft er die Verzeichnisse im Minutenabstand.

Unter Unix überwacht der Job Scheduler 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.

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.

<job order="yes">
    <script language="shell"><![CDATA[
      echo hello world
    ]]></script>
</job>

<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>

<order>
    <run_time>
      <period repeat="3600"/>
    </run_time>
</order>

Spiegelung des Verzeichnisses im Job Scheduler

Der Job Scheduler legt für jede Datei mit bekannter Dateinamensendung (.job usw.) ein entsprechendes Objekt im Job Scheduler an und verbindet es mit der Datei. Der Job Scheduler überwacht den Zeitstempel der Datei und geht bei Änderung wie folgt vor.

• Ein hinzugefügter Dateiname führt zur Anlage eines neuen, noch leeren Objekts im Job Scheduler, das mit der Datei verbunden ist. Das Objekt ist mit <show_state> sichtbar. Z.B. wird eine Datei xxx.job.xml im Job Scheduler 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 Job Scheduler wie bei einer geänderten Datei vor.
• Nach einer Änderung einer Datei (der Zeitstempel hat sich geändert) liest der Job Scheduler 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 Job Scheduler 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 Job Scheduler 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.

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").

Verhalten der einzelnen Objekttypen

Prozessklassen

Änderungen an einer Prozessklasse übernimmt der Job Scheduler sofort.

Beim Löschen einer Prozessklasse beendet der Job Scheduler alle zugehörigen Tasks. Erst wenn keine Task mehr läuft, löscht er die Prozessklasse. Bis dahin startet der Job Scheduler keine weiteren Tasks, uns verhält sich als ob die Prozessklasse erschöpft wäre.

Sperren

Änderungen an einer Sperre übernimmt der Job Scheduler sofort.

Beim Löschen einer Sperre beendet der Job Scheduler alle zugehörigen Tasks. Erst wenn keine Task mehr läuft, löscht er die Sperre. Bis dahin startet der Job Scheduler keine weiteren Tasks, und verhält sich als ob die Sperre belegt wäre.

Jobs

Einen geänderten Job übernimmt der Job Scheduler, nachdem er alle Tasks beendet hat.

Beim Löschen verfährt der Job Scheduler 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.

Job-Ketten

Eine geänderte Job-Kette übernimmt der Job Scheduler, 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 Job Scheduler in die geänderte Job-Kette.

Beim Löschen verfährt der Job Scheduler 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.

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 Job Scheduler die Eindeutigkeit der Auftragskennungen sicherstellen kann.

Ebenso wird eine untergeordnete Job-Kette erst gelöscht, wenn auch die übergeordnete Job-Kette gelöscht ist.

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.

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.