Job Scheduler Erste Seite |
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 des Job Schedulers Operationen zum manuellen Starten von Aufträgen.
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 Job Scheduler 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>.
Zur Verwendung innerhalb von Job-Ketten müssen Jobs mit <job order="yes"> definiert sein. Andernfalls sind sie als standalone Jobs separat aufrufbar.
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 Job Scheduler eine Task. Wenn mehrere Aufträge in der Warteschlange sind und der Job mehrere Tasks erlaubt (<job tasks="…">), dann startet der Job Scheduler mehrere Tasks.
Der Job Scheduler ü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).
Zu Aufträgen, die aus Dateien eines Verzeichnisses entstehen, siehe »Verzeichnisüberwachung mit Dateiaufträgen«.
Aufträge mit höherer Priorität Order.priority stellt der Job Scheduler an den Anfang der Warteschlange.
Wenn kein Auftrag mehr zu verarbeiten ist, lässt der Job Scheduler 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 Job Scheduler eine wartende Task automatisch beendet. Diese Frist sollte auf z.B. 30 Sekunden eingestellt werden, um während der Verarbeitungspausen Ressourcen freizugeben.
Wenn der Job Scheduler 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.
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 Job Scheduler 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.
Zur persistenten Speicherung der Auftragswarteschlangen und zur Auftragshistorie lesen Sie hier.
Zuletzt geändert von aa, 2007-10-09 |