OPEN SOURCE - Job Scheduler - Lösungen

• Einen Job erstellen
• Was ist das Konzept der Job-Ketten und der Auftragsverarbeitung?
• Wo finde ich ein einfaches Beispiel für eine Job-Kette?
• Ereignisse für Job-Starts
  
  

• Lizenzschlüssel für den Job Scheduler
• eMail-Versand durch den Job Scheduler funktioniert nicht
• Datenbankverbindung mit MySQL geht verloren
• Warum wird ein Log File im GUI mit Verzögerung angezeigt?
• Warum wird der Job Scheduler langsamer und verzögert die Ausführung von Jobs?
  
  

• Betrieb mit MySQL 4.0.x
• JDBC Verbindung mit SQL Server
• Datenbankverbindung mit MySQL geht verloren
• Wie können Log Files konfiguriert werden, damit sie in die Datenbank geschrieben werden?
  
  

• Wann empfiehlt sich eine Open Source oder Closed Source Lizenz?
• Wie funktionieren Support-Optionen für mehrfache Job Scheduler Installationen?
  
  

• Job-Abhängigkeiten herstellen
• Mehrere Jobs gleichzeitig ablaufen lassen
• Parametrisierbarkeit von Jobs
• Job-Ketten
• Benachrichtung nach Verarbeitung
• Verzögerte und wiederholte Verarbeitung
• Sichtbarkeit der Zeitplanung
• Ad-Hoc Änderungen von Job-Ketten
• Triggern von Fehlerzuständen
• Drag & Drop zur Job-Konfiguration
• Sichtbarkeit von Jobs
• Benutzerfreundliche Oberfläche mit drop-down Listen
• Routing der Ausgaben von Jobs
• Verzeichnisse überwachen und Jobs automatisch starten
• Jobs in unterschiedlichen Benutzerkennungen ablaufen lassen
• Überwachung und Kontrolle von Jobs
• Job-Spezifikationen aus Textformaten importieren
• Lastverteilung und Ausfallsicherheit
• Job Agenten auf verschiedenen Rechnern
• Script Jobs mit Standard Unix Script-Sprachen
• Neustart des Job Schedulers
• Sichere Datenübertragung mit dem Job Scheduler
• Wie implementiert man Jobs with Perl?
• Wiederherstellen von eingereihten Aufträgen und Jobs in Job-Ketten
• Wir werden Ferieneinstellungen im Job Scheduler konfiguriert?
• Die Master- und Slave-Beziehungen im Job Scheduler
• Wann werden Änderungen an einer Job-Kette wirksam?
• Können Jobs und Aufträge in mehreren Job Scheduler Instanzen ausgeführt werden?
• Was ist der Unterschied zwischen Verzeichnisüberwachung und Dateiaufträgen?
• Können doppelte Anführungszeichen in Job- oder Auftragsparametern enthalten sein?
• Wie kann man einen einzelnen Job manuell starten, der Knoten einer Job-Kette ist?
• Wie kann der Job Scheduler ein Programm ausführen, das ein GUI anzeigt?
• Kann Job Scheduler für 32bit und für 64bit Plattformen eingesetzt werden?

<?xml version="1.0" encoding="iso-8859-1"?>
<spooler>
  <config>
    <jobs>

       <job name = "my_shell_script">
          <process file  = "my_shell_script.sh"
                   param = ""/>
          <run_time repeat = "3600"
                    begin  = "00:00"
                    end    = "24:00"/>
       </job>

     </jobs>
   </config>
</spooler>
              

1. Einsatz von Job-Ketten
   
   Die sequentielle Verarbeitung von Jobs kann in Form von Job-Ketten eingerichtet werden, die sicherstellen, dass ein Folgejob nicht gestartet wird, wenn ein vorhergehender Job einen Fehler erzeugt. Job-Fehler können per Konfiguration automatisch erkannt werden anhand des Ausführungsstatus (return code für ausführbare Dateien), von Signalen (nur für Unix), des Vorhandenseins von Ausgaben in stderr und von Fehlern, die durch Methoden des API oder durch SQL-Exceptions (und anderer SQL-Fehler) ausgelöst wurden.
   
   Job-Ketten sind Job-Knoten, die in einer Reihe organisiert sind und in der jedem Knoten ein bestimmter Zustand zugeordnet ist. Ein Auftrag wird nacheinander von den einzelnen Jobs einer Job-Kette abgearbeitet. Falls ein Verarbeitungsfehler auftritt, wird der Auftrag gestoppt und aus der Job-Kette entfernt.
   Siehe die Beispiele zur Frage Was ist das Konzept der Job-Ketten und der Auftragsverarbeitung"?
   
   Darüber hinaus können Monitor-Skripte eingesetzt werden, um komplexe Bedingungen für den Start von Jobs in den Sprachen Java, Javascript, Perl und VBScript zu implementieren. Das Job Scheduler API bietet die Methode scheduler_job.start() an, die in Skripten verwendet werden kann, die individuelle Geschätslogik für bedingte Job-Starts implementieren.
   
   Für die Ausführung von Datenbank-Statements können die API-Methoden direkt in PL/SQL Prozeduren von Oracle verwendet werden. Hierzu werden PL/SQL Wrapper-Funktionen für die Java-Klassen des API eingesetzt, die es ermöglichen Jobs transaktionssicher innerhalb von Triggern oder PL/SQL Prozeduren zu starten, d.h. erst nach Abschluß einer Transaktion mittels commit.
   
   
2. Verwendung von Folge-Jobs
   
   Sie können beliebige Jobs konfigurieren, dass die Folge-Jobs abhängig vom aktuellen Job-Ergebnis ausgeführt werden:

   <job>
     <process file="..."> or <script language="...">
       <!-- in case of success the exit code=0, let's start this job -->
       <commands on_exit_code="success">
         <start_job job="ftp_get_files"><params/></start_job>
       </commands>
       <!-- in case of error the exit code!=0 -->
       <commands on_exit_code="error">...</commands>
       <!-- other exit codes could be handled individually -->
       <commands on_exit_code="1 2 4 8">...</commands>
     </process>
   </job>
   

   Sie können jeden Job so konfigurieren, dass er beliebige Folge-Jobs und Aufträge startet. (ab Job Scheduler Release 1.2.7)
   
   

• Ereignisse des Dateisystems: Hinzufügen oder Entfernen einer Datei; die Dateien können mit regulären Ausdrücken gefiltert werden;
• Kalenderereignisse: zu einem Datum, Wochentag, Tag im Monat und Ultimo; Ausnahmen können in Form von Ferientagen konfiguriert werden;
• API Ereignisse: mit der API Methode spooler_job.start(); diese Methode kann von Jobs in einer der Sprachen Java, Javascript, Perl, VBScript verwendet werden;
• XML-Kommandos können via TCP/IP oder UDP Datagramm an den Job Scheduler gesendet werden. Jobs können mittels einfacher XML-Kommandos gestartet, gestoppt, angehalten, fortgesetzt und abgebrochen werden, z.B. <start_job job="cleanup_tmp_files" at="now">.
• Ereignisse, die durch die Web-Oberfläche des Job Schedulers ausgelöst werden: diese Ereignisse verwenden die o.g. XML-Kommandos.

<job name = "cleanup_sos_files" title = "Remove temporary files">
  <params>
    <!-- remove temporary files from the given directory otherwise 
    from the users temp directory  --> 
    <param name = "file_path" value = "/tmp"/> 
    <!-- remove temporary files with the given prefix --> 
    <param name = "file_specification" value = "^(sos.*)"/> 
  </params> 
  <script language = "java"
          java_class = "sos.scheduler.job.JobSchedulerCleanupFiles"/> 

  <!-- cleanup files in the given interval of seconds (4 hours) --> 
  <run_time let_run = "yes"
            begin   = "06:00"
            end     = "22:00"
            repeat  = "04:00:00"/> 
</job> 


<job name = "cleanup_tmp_files" title = "Remove temporary files"/> 
  <params/> 
    <param name = "file_path" value = "/tmp"/> 
    <param name = "file_specification" value = "^(tmp.*)"/> 
  </params/> 

  <script language = "java"
          java_class = "sos.scheduler.job.JobSchedulerCleanupFiles"/> 

  <!-- cleanup files in the given interval of seconds (24 hours)--> 
  <run_time let_run= "yes"
            begin   = "00:00"
            end     = "24:00"
            repeat  = "24:00:00"/> 
</job> 
              

• mail_on_error
• mail_on_warning
• mail_on_success
• mail_on_process (reserviert für Job-Implementierungen mit dem API)

• Eine einfache Möglichkeit einen Job schlafen zu legen und wieder aufzuwecken besteht darin, ein Wiederholungsintervall in Stunden, Minuten und Sekunden zu konfigurieren. Der Job wird im Prinzip nicht verzögert, sondern startet nach Ablauf des Wiederholungsintervalls erneut.
  
  
• Ein Job kann mit der API-Methode delay_spooler_process(seconds_or_hhmmss) veranlasst werden, den nächsten Job-Schritt später auszuführen. In diesem Fall bleibt der Job geladen, d.h. er ist in Verarbeitung, benötigt aber keine CPU-Zeit bis zum Ablauf des Verzögerungsintervalls.
  
  Diese Möglichkeit existiert nur für Jobs, die die API-Methode spooler_process() implementieren.
  
• Einem Job kann ein Wiederholungsintervall nach Auftreten eines Fehler zugewiesen werden, z.B. per Konfiguration oder API-Methoden:
  
  spooler_job.delay_after_error( 2 ) = 10; // 10 Sekunden
spooler_job.delay_after_error( 5 ) = "00:01"; // eine Minute
spooler_job.delay_after_error( 10 ) = "24:00"; // ein Tag
spooler_job.delay_after_error( 20 ) = "STOP";
  
  In diesem Beispiel wiederholt der Job Scheduler den Job sofort nach dem ersten Fehler. Nach zwei bis vier aufeinanderfolgenden Fehlern erfolgt der Neustart jeweils nach 10 Sekunden; zwischen fünf bis neun aufeinanderfolgenden Fehlern beträgt das Zeitintervall eine Minute. zwischen 10 und 19 Fehlern beträgt das Zeitintervall 24 Stunden. Nach 20 aufeinanderfolgenden Fehlern wird der Job gestoppt.
  
  Als Wert des Arguments seconds_or_hhmm_ss kann "STOP" angegeben werden, um die Anzahl fehlerhafter Job-Wiederholungen zu begrenzen. Der Job wird anschließend gestoppt, d.h. er läuft nach Erreichen der Fehlerzahl nicht mehr automatisch an.
  
  

<show_state job="scheduler_cleanup_sos_files" what="all"/>

<job job="scheduler_rotate_log" state="pending" title="Rotate 
  and compress logfiles"
     all_steps="0" all_tasks="0"
     log_file="c:/scheduler/logs/job.scheduler_rotate_log.log"
     order="no" tasks="1" in_period="yes" next_start_time="2005-10-18 01:00:00">
  <tasks count="0"/> 
  <queued_tasks length="0"/> 
  <log level="info" highest_level="debug3" last_info=""
       mail_on_error="yes"
       mail_on_warning="yes" smtp="localhost"
       mail_from="scheduler@sos-berlin.com"
       mail_to="info@sos-berlin.com"/> 
</job>

    <job stop_on_error="no">
    ...
      <commands on_exit_code="error">
        <start_job job="my_error_handler"><params/></start_job>
      </commands>
    </job>
               

<security ignore_unknown_hosts = "yes">
  <allowed_host host = "192.11.0.0"  level = "info"/>
  <allowed_host host = "192.11.0.99" level = "none"/>
  <allowed_host host = "192.11.0.27" level = "all"/>
</security>

• alle Rechner im Netzwerk 192.11.0.0 können lesend auf den Job Scheduler zugreifen, d.h. Protokolle und Zeitplanung einsehen
• der Rechner 192.11.0.99 hat keinen Zugriff
• der Rechner 192.11.0.27 hat vollen Zugriff, d.h. kann Jobs und Aufträge starten, entfernen etc.

• nach stdout geschrieben werden,
• nach stderr geschrieben werden,
• mit den Logging-Methoden des API (info, warning, error, debug) erzeugt werden,
• durch SQL-Fehler oder Verwendung des Oracle-Pakets dbms_output erzeugt werden,
• die in externe Protokoll-Dateien geschrieben werden, die für ausführbare Programme konfiguriert sind

<job name = "sample_job">
  <process file  = "/home/test/scheduler/jobs/sample_script.pl"
           param = "-f ${SCHEDULER_TASK_TRIGGER_FILES}"/>
  <start_when_directory_changed directory = "/tmp/input" regex = ".*"/>
</job>

• Jobs auf demselben Rechner: setuid
  
  In der Auslieferung ist das Programm setuid enthalten, das das Umschalten der Benutzerkennung für einen Job ermöglicht ohne dass in der Job Scheduler Konfiguration ein Kennwort hinterlegt werden müsste. Dazu wird das Programm ./bin/setuid mit den Rechten der Zielkennung, z.B. "nobody" kopiert:
  
  cd ~/scheduler/bin
mkdir nobody
chmod go-rwx nobody
cp setuid nobody/setuid-nobody
chown nobody nobody/setuid-nobody (has to be done by root)
chmod u+s,a-r nobody/setuid-nobody (has to be done by root)

  
  Das Beispiel geht davon aus, dass der Job Scheduler in der Kennung "test" betrieben wird und Jobs in der Kennung "nobody" ausführen soll: mit der obigen Kommandofolge erzeugen Sie ein schreibgeschütztes Verzeichnis mit einer Kopie von setuid für die Kennung "nobody"; die Datei setuid-nobody ist für die Kennung "test" ausführbar", gehört aber dem Benutzer "nobody". Mit dem Programm setuid-nobody lassen sich beliebige Kommandos in der Kennung "nobody" ausführen ohne dass ein Kennwort für die Zielkennung angegeben werden muss. setuid-nobody prüft, ob die o.g. Rechte gesetzt sind und bricht andernfalls ab.
  
  Die Konfiguration eines Jobs in der Konfigurationsdatei scheduler.xml, der in der Zielkennung ausgeführt wird, lautet dann etwa so:

  
  <job name = "sample_setuid_job">
    <process file  = "$SCHEDULER_HOME/bin/nobody/setuid-nobody"
             param = "/home/test/scheduler/jobs/sample_script_notification.pl"/>
  </job>
  

• Jobs auf demselben oder anderen Rechnern: ssh
  
  Um ausführbare Dateien mit ssh zu verarbeiten, müssen Sie folgendes einrichten:
  
  • shh client und ssh server installieren
  • ein Schlüsselpaar bestehend aus privatem und öffentlichem Schlüssel auf dem Client-Rechner erzeugen; den öffentlichen Schlüssel publizieren Sie im Verzeichnis .ssh des Zielrechners.
  • Jobs mit der Konfiguration <process file="ssh" params="..."/> einrichten: die Kommandozeilenparameter geben Sie im Attribut param= an.
  
  
  ssh kann zum Ausführen von Kommandos auf dem lokalen oder anderen Rechnern verwendet werden. Alternativ kann eine weitere Instanz des Job Schedulers auf dem anderen Rechner installiert werden, falls Sie über keinen ssh Server verfügen und den Aufwand einer Public Key Infrastruktur vermeiden wollen.
  
  

• Job-Fehler: Jobs können so konfiguriert werden, dass im Falle eine Fehlers eine automatische Wiederholung mit einer ebenfalls konfigurierbaren Anzahl von Versuchen gestartet wird.
  
  
• Scheduler-Fehler: wird der Job Scheduler mit einer Datenbank betrieben (nicht unbedingt erforderlich), dann werden automatisch wiederholt Versuche zum Aufbau der Datenbankverbindung gestartet, die Anzahl der Versuche ist konfigurierbar. Folgende Mechanismen zur Fehlerbehandlung sind verfügbar:
  • Überwachungsfehler, z.B. mehrfache Job Scheduler Instanzen laufen auf dem selben Server und senden Lebendsignale (heartbeats) an einen Master Job Scheduler, der ausschließlich für die Überwachung zuständig ist;
  • Neustart einer fehlerhaften Job Scheduler Instanz;
  • "sanity checking" zur Überprüfung von Hauptspeicher- und Plattenplatz durch automatisierte Wartungs-Jobs.
  
  Fehlertoleranz im Sinne von automatischer, rechner-übergreifender Ausfallsicherung ist nicht verfügbar. Sollten die Ressourcen (Plattenplatz, Datenbank etc.) knapp werden, dann schaltet sich der Job Scheduler nach einer konfigurierbaren Wartezeit ab. Derzeit gibt es keine Backup-Instanz des Job Schedulers, die automatisch Jobs auf einem alternativen Server weiterverarbeitet, falls eine Scheduler-Instanz ausfällt.
  
  

• um Job Scheduler Logs zu schreiben, die in der Web-Schnittstelle sichtbar sind (und die im Falle von Fehlern, Warnungen oder Erfolg automatisch per eMail verschickt werden),
• um den Job-Verarbeitungsstatus zu bestimmen,
• um weitere Jobs mittels API zu starten und um Job-Parameter zu verarbeiten.

• Java,
• Javascript, die Mozilla (SpiderMonkey) Laufzeit Umgebung ist für die o.g. Plattformen integriert.
• unter Windows wird zusätzlich VBScript unterstützt.
• Perl Jobs mit API-Support können zusätzlich unter Windows ablaufen, vorausgesetzt, dass eine Activestate Implementierung für Perl installiert ist. Für Linux und Solaris gibt es Einschränkungen, da Perl nicht "threadsafe" implementiert ist, d.h. nebenläufige Prozesse nicht unterstützt werden. Für beide Plattformen müssen die Perl-Bibliotheken mit dem Job Scheduler gebunden werden.

1. das dezentrale Server-Betriebssystem nicht vom Job Scheduler unterstützt wird?
   
   
2. wenn wir uns nicht auf ein Programm verlassen wollen, dass das Job Scheduler API über eine dezentrale Verbindung nutzt um Ereignisse mitzuteilen (wir sind nicht in der Lage zusätzliche Programme auf dem dezentralen Server einzusetzen und zu betreiben).
   
   

1. Vorgeschlagene Lösung: Signalling
   
   Wenn der dezentrale Host dafür verantwortlich sein soll, ein Signal zu senden, um das Eintreffen einer Datei mitzuteilen, dann:
   • sollten Sie keine Bedenken haben, das Job Scheduler API zu nutzen, da dies so einfach sein kann, wie im folgenden Beispiel:
     
     telnet [scheduler_host] [scheduler_port]
<start_job job="ftp_get_files"></params></start_job>
     
     Dieser einfache Befehl ist aller Wahrscheinlichkeit nach für den dezentralen Host verfügbar. Mit einem TCP Stack können Sie einen XML-Befehl an den Job Scheduler senden, der ankündigt, was als nächstes getan werden soll, beispielsweise einen Job starten. Große Teile des API sind als XML-Befehle verfügbar, die mittels TCP oder UDP an den Job Scheduler gesendet werden können. telnet ist nicht die einzige TCP-Lösung, die Sie einsetzen können, es ist ein Beispiel für die Befehlszeile.
     
     
   • können Sie das Job Scheduler API auch ohne Installation nutzen
     wir liefern Java-Klassen aus, die ohne die Installation des Job Schedulers genutzt werden können, beispielsweise mit einer Befehlszeile wie folgt:
     
     java -cp ./sos.scheduler.jar:./sos.util.jar sos.scheduler.SOSSchedulerCommand [scheduler_host] [scheduler_port] [xml command]
     
     Java ist für die meisten Betriebssysteme verfügbar, d.h. der dezentrale Host kann diese Befehlszeile nutzen, um einen XML-Befehl an den Job Scheduler zu senden, auch dann wenn kein Job Scheduler auf dem dezentralen Host installiert ist. Ein Standard JRE 1.4.2++ und das obige .jar Archiv reichen für den dezentralen Host aus.
     
     
   • können Sie einen alternativen TCP/UDP Stack nutzen
     Jede Programm- oder Scripting-Sparche, die TCP oder UDP unterstützt, kann genutzt werden, um XML-Befehle zu senden.
     
     
   Die oben benannten Szenarien bedeuten jedoch nicht, dass Sie die jeweiligen Programme/Scripte auf dem dezentralen Host pflegen müssen, da dies mit den Standardfunktionen des Betriebssystems erledigt werden kann. Wie Sie sehen, empfehlen wir für den Einsatz UDP, da dies ein non-blocking Protokoll ist. Das bedeutet, dass der dezentrale Host unberührt bleibt von Fehlern, die beispielsweise durch Netzwerkprobleme ausgelöst werden. Das signalling sollte als zusätzliche Option in der Kommunikation zwischen dezentralem Host und Job Scheduler eingesetzt werden, weil es die Abwicklungsgeschwindigkeit erhöht, es kann jedoch das polling nicht ersetzen.
   
   
2. Vorgeschlagene Lösung: Polling
   
   Wir empfehlen diese Lösung, da sie sicher und einfach zu implentieren ist, wenn man überprüfen möchte, ob eine Datei auf einem dezentralen Host existiert:
   
   • Mit FTP prüfen
     Mehr Information über das Thema 'Standard-Jobs' finden Sie im Kapitel 'FTP-Verarbeitung' Job Scheduler Standard-Jobs und in der Job-Dokumentation in Job Scheduler FTP Receive. Der bestehende Code kann angepasst werden, damit bestimmte exit codes signalisieren, ob Daten im dezentralen Verzeichniss verfügbar sind oder nicht.
     
     
   • Mit ssh prüfen
     Für diese Lösung benötigt man auf dem dezentralen Host einen Shell Script oder Befehl für das Betriebssystem. Ein Job wird mittels ssh gestartet und prüft, ob Datein verfügbar sind. Der Script/Befehl kann implementiert werden, um mit einem bestimmten exit code zu signalisieren, dass Daten für die Übertragung bereitstehen.
     
     So könnte eine Pseudo-Konfiguration für die Datei scheduler.xml aussehen:

     <job>
       <process file="ssh" param="-l [user]@[host] [script_or_command]">
         <!-- restart this job if an error occurs, e.g. file not present, 
              server unavailable etc. -->
         <delay_after_error error_count="1" delay="60"/> 
         <!-- repeat this job every 60s after the first error occurred -->
         <delay_after_error error_count="10" delay="600"/> 
         <!-- repeat this job every 600s after the 10th error occurred -->
         <delay_after_error error_count="50" delay="stop"/> 
         <!-- stop this job after 50 subsequent errors -->
         <!-- in case of files found: exit code=0, let's fetch the files -->
         <commands on_exit_code="success">
         <start_job job="ftp_get_files"><params/></start_job></commands>
         <!-- in case of absence of files: exit code=1 -->
         <!-- let's ignore this return code -->
         <commands on_exit_code="1"/>
         <!-- other exit codes are automatically handled as errors, 
              otherwise you could start individual jobs to handle errors -->
         <!-- <commands on_exit_code="error">...</commands> -->
       </process>
     </job>
     

     Die Fähigkeit, Folge-Jobs zu starten, die auf exit codes basieren, ist nicht auf ssh oder <process file=""/> beschränkt, sondern Sie können jeden Job so konfigurieren, dass beliebige Folge-Jobs und Aufträge vom Job Scheduler (ab 1.2.7) ausgelöst werden.
     
     
3. Konkurrierende Zugriffe
   
   Ein einfacher Weg um konkurrierende Zugriffe zu verhindern ist, den Client zu veranlassen, Dateinamen wie filename~ nach der Übertragung in filename umzubenennen, da dann die überwachten Dateinamen automatisch erscheinen.
   
   Etwas anspruchsvollere Lösungen werden benötigt für die folgenden Situationen:
   • Was soll passieren, wenn eine Eingabedatei über einen längeren Zeitraum nicht übertragen werden kann, gleichtzeitig aber bereits neue Daten auf dem dezentralen Host bereitstehen?
   • Wie sollen mehrere Eingabedateien gehandhabt werden, die in einer einzelnen Übertragung vom Client verarbeitet werden sollen, z.B. beim Import in ein DBMS?
     
     
   Wir haben kommerzielle Lösungen für diese Situationen implementiert, die auf Ampel-Regeln beruhen. Sollten Sie an dieser Lösung interessiert sein, schreiben Sie ein eMail.
   
   

• für Windows liefern wir keine Bibliothek aus, statt dessen nutzen wir Script-Bibliotheken aus der existierenden ActiveState Perl Impelementierung. Schauen Sie hier nach: http://www.activestate.com.
  
  
• für Unix muss die Bibliothek libsosperlscript.so vom Installierer in das lib-Verzeichnis kopiert werden. Weiter befindet sich im Verzeichniss die libperl.so-Bibliothek, die durch Ihre Perl-Installation ersetzt werden kann. Dieses Unter-Programm muss zu den thread-Optionen passen, mit denen Perl kompiliert wurde. Im Setup wird die Perl-Version 5.8.0 zur Verfügung gestellt, die für multithreading ausgelegt ist.
  
  

• Sie können folgende Konfiguration benutzen
  <job><process file="my_script.pl"/></job>
  um Perl genau wie von der Kommandozeile zu verwenden (my_script.pl eine ausführbare Datei sein). Das funktioniert mit allen Versionen von Perl, API-Methoden des Job Schedulers können jedoch nicht genutzt werden.
  
  
• Sie können diese Konfiguration benutzen
  <job><script language="perlscript"><include file="my_api_script.pl"/></job>
  für ein Perl Script, das das Job Scheduler API nutzt und die obigen Bibliotheken für Unix benötigt.
  
  

• verfügbar über die integrierte Web-Schnittstelle des Job Schedulers
• http://www.sos-berlin.com/doc/de/scheduler.doc/api/api-perl.xml

  # ...um Objektvariablen zur Verfügung zu stellen 
  use vars qw ($spooler $spooler_log $spooler_job $spooler_task);
  
  # ... benutzen Sie die Objekte und Methoden, z.B. um auf Job-Parameter zuzugreifen
  $spooler_task->params->value("request_stylesheet")

  <spooler>
    <config>
      <jobs>
      ...       
      </jobs>
      <job_chains>
        <job_chain name="TestGetandPut">
        <job_chain_node state="1"     
            job="TestGet"     
            next_state="100"     
            error_state="999"/> 
        <job_chain_node state="100" 
            job="GetPut"     
            next_state="200"     
            error_state="999"/> 
        <job_chain_node state="200" /> 
        <job_chain_node state="999" />
      </job_chain>
       ...      
      </job_chains>
      <commands>
        <!-- here you add an order for your job chain>
        <add_order job_chain=" TestGetandPut" 
        title="sample order" replace="yes">
          <params/>
            <!-- sample run time: repeat the execution of this order 
                every day at the given hour -->
            <!-- without run time specification an order is fired just 
                once and will not be repeated -->    
            <run_time><period single_start="23:36"/></run_time>
        </add_order>
      </commands>
    </config>
  </spooler>

• Aufträge können simultan verarbeitet werden und die Jobs können (z.B. nach <job tasks="3"/>) in parallelen Tasks Aufträge verarbeiten.
• Aufträge können Parameter haben, d.h. Sie verwenden die selbe Job-Implementierung, die für den Ausführungszeitpunkt eines jeweiligen Auftrags parametrisiert wird, z.B. indem die Auftragsparameter Einstellungen beinhalten, die für die FTP-Verbindung benötigt werden.
• Aufträge können eine Nutzlast (payload) haben, d.h. beliebige xml Strukturen, die für jeden Job in einer Job-Kette zur Verfügung stehen, können auf diese Weise genutzt werden, um Ausfühungsergebnisse von einen Job zum nächsten in der Job-Kette weiterzugeben.
• Aufträge können zurückgesetzt werden, d.h. sie können in ihrer Position in der Job-Kette zurückgesetzt werden, um an einer bestimmten Stelle wieder gestartet zu werden.
• Jeder Auftrag hat seine eigene Protokolldatei, die alle Informationen aller Jobs beinhaltet, die in der Job-Kette für den Auftrag durchlaufen wurden.

• Zunächst ein Blick auf die Job-Implementierung. Beliebige Jobs können in Ketten verwendet werden, sie müssen das Attribut order="yes" aufweisen:
  
  

    <spooler>
      <config>
        <jobs>
          <job name="command_1" title="sample_command" order="yes">
            <script language="shell">
              <![CDATA[
               C:\Programme\Samples\Scripts\command_sample_1.cmd
              ]]>
            <script>
          </job>
  
          <job name="command_2" title="sample_command" order="yes">
            <script language="shell">
              <![CDATA[
               C:\Programme\Samples\Scripts\command_sample_2.cmd
              ]]>
            <script>
          </job>
        </jobs>
      </config>
    </spooler>
  

• Als nächstes wird eine Job-Kette benötigt, die den Jobs jeweils einen Status und Job-Knoten zuweist:
  
  

    <spooler>
      <config>
        <job_chains>
          <job_chain name="command_sequence">
            <job_chain_node state="first"     
                job="command_1"     
                next_state="second"     
                error_state="error"/> 
            <job_chain_node state="second" 
                job="command_2"     
                next_state="success"     
                error_state="error"/> 
            <job_chain_node state="success"/> 
            <job_chain_node state="errror"/>
          </job_chain>
        </job_chains>
      </config>
    </spooler>
  

  Das Beispiel weist dem obigen Job command_1 den ersten Knoten in der Job-Kette und dem Job command_2 den zweiten Knoten zu, der ausgeführt wird, wenn der erste Job-Knoten erfolgreich abgeschlossen wurde. Die Verkettung erfolgt mit den Attributen next_state, das den Status des nächsten auszuführenden Job-Knotens in der Kette bestimmt, und error_state, das den Job-Knoten bestimmt, der im Fehlerfall ausgeführt wird. Job-Knoten für Endzustände können ohne Implementierung bleiben wie im Fall von success und error, darüber hinaus können individuelle Job-Implementierungen für die Fehlerbehandlung erfolgen.
  
  
• Schließlich wird ein Auftrag benötigt, der die Ausführung der Job-Kette veranlasst:
  
  

    <spooler>
      <config>
        <commands>
          <add_order job_chain="command_sequence" 
            title="sample command sequence" replace="yes">
            <params/>
              <!-- sample run time: repeat the execution of this order 
                   every day at the given hour -->
              <run_time><period single_start="23:36"/></run_time>
          </add_order>
        </commands>
      </config>
    </spooler>
  

  Der Auftrag wird für folgende Zwecke eingesetzt:
  • Die Ausführung der Job-Kette veranlassen:
    Eine Job-Kette wird nicht durch das Starten des ersten Job-Knotens ausgeführt, sondern durch das Starten eines Auftrags. Die eingebaute HTML-Oberfläche des Job Schedulers bietet die entsprechenden Operationen für Aufträge an. Mehrere Aufträge können die parallele Ausführung von Jobs in einer Job-Kette veranlassen. Der Job Scheduler wird dann dynamisch Tasks zur parallelen Ausführung bereitstellen.
  • Den Jobs einer Job-Kette Parameter hinzufügen:
    Parameter aus Aufträgen werden mit Priorität den Parametern einer Job-Konfiguration hinzugefügt (<job><params><param name="sample_name" value="sample_value"></params></job>).
  • Startzeit für automatische Ausführung angeben:
    Beliebige Perioden für die wiederholte Ausführung können angegeben werden.

• die Methode spooler_process() ist für Jobs beabsichtigt, die das API mittels <script/> nutzen.
• eine ausführbare Datei beendet wurde, die mit dem <process/> gestartet wurde.
  
  

• Werden Tasks während der Bearbeitung gestoppt, weil der Master Job Scheduler gestoppt wird, dann werden diese nach einem Neustart des Job Schedulers nicht automatisch neu gestartet (der Grund hierfür ist, dass der Job Scheduler nicht entscheiden kann, ob es sinnvoll ist den Job noch einmal auszuführen in Hinsicht auf Laufzeiten und korresponierende Anfangs- und Endzeiten).
  
  
• Wird eine Task für ein zukünftiges Datum eingereiht, z.B. mit
  <start_job job="..." at="now+3600"/><params/></start_job>
  oder mit den entsprechenden API-Methoden, dann ist die Startzeit dieser Task in der Datenbank erfasst (in der Tabelle SCHEDULER_TASKS). Für Aufträge und Jobs liest der Job Scheduler die entsprechenden Tabellen beim Start und reiht diese dann für den vorgegebenen Zeitpunkt wieder ein.

  <config>
      <holidays>
          <holiday date="2006-12-25"/>
          ...
          <holiday date="2006-12-26"/>
      </holidays>
      <jobs/>
      <job_chains/>
  </config>

  <job>
    <run_time let_run="no">
        <period single_start = "08:00"/>
        <holidays>
            <holiday date="2006-06-19"/>
            ...
            <holiday date="2006-07-19"/>
        </holidays>
    </run_time>
  </job>              

  <config main_scheduler        = "remotehost:4444">
  ...
  </config>

  <config>
      <script language = "java"
             java_class = "sos.scheduler.managed.JobSchedulerManagedStarter"/>
      <jobs/>
      <job_chains/>
  </config>

  ;                         enable job history, if set to yes the 
  ;                         scheduler keeps a job history in 
  ;                         csv files or database tables
  history                 = yes
  ;                         store job protocol for task history 
  ;                         (yes|no|gzip, default: no)
  history_with_log        = gzip
  ;                         store job protocol for order history 
  ;                         (yes|no|gzip, default: no)
  order_history_with_log  = gzip
  ;                         store protocol for scheduler history 
  ;                        (yes|no|gzip, default: no)
  history_archive         = gzip