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
• Job Scheduler mit Windows 2008 betreiben
• Wie können Log Files konfiguriert werden, damit sie in die Datenbank geschrieben werden?
  
  

• 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?
• Funktionieren Web Services und das GUI des Job Scheduler mit IIS?

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

        <process_classes>
            <process_class max_processes="20"/>
            <process_class name="many_processes" max_processes="30"/>
            ...
        </process_classes>

1. Wenn Sie den Inhalt eines Jobs verändern, z.B. den Inhalt der Befehlsdatei, die Laufzeitkonfiguration oder die Konfiguration der Parameter, dann werden die Änderung sofort vom Job Scheduler akzeptiert.
   
   
2. Ändern Sie den Namen eines Jobs (oder den Input/Output/Error Level), dann ist diese Änderung nicht nur für einen Job gültig, sondern für die gesamte Job-Kette. In diesem Fall können Ihre Änderungen nicht sofort übergeben werden, weil sonst das folgende Verhalten eintritt:
   • Aufträge in der Warteschlange für den Start benötigen die vorgegebene Struktur der Job-Verknüpfungen in der Job-Kette und den Status des ersten Job-Knotens.
     
   • Aufträge, die sich in Verarbeitung befinden, müssen auf die vorgegebene Struktur der Verknüpfungen in der Job-Kette zugreifen können, weil sonst veränderte Input/Output/Error Levels dazu führen, dass es keinen entsprechenden Endstatus zu einer Job-Verknüpfung gibt.
     
     
   Ein derartiger Auftrag kann nicht erfolgreich beendet werden, was auf das Transaktionsverhalten der Web-Oberfläche zurückgeht, die einen Job nach dem anderen speichern muss und nicht all gleichzeitig speichern kann.
   
   Über die Web-Oberfläche der "Managed Jobs" wird in diesen Fällen asynchron ein Job gestartet, der die Job-Kette entfernt und neu einrichtet. Dieser Job berücksichtigt evtl. laufende Aufträge, es kann daher zur kurzern Verzögerungen kommen bis die Änderung an der Job-Kette wirksam wird.
   
   

1. Sie können ab Release 1.2.9 den Standard-Job scheduler_remote_execution der Auslieferung verwenden, um Jobs und Aufträge in anderen Job Scheduler Instanzen auszulösen, siehe Lösungen mit Standard-Jobs.
   
   Der Job kann bspw. eingesetzt werden, um als Folge-Job eine nachfolgende Verarbeitung in einer anderen Job Scheduler Instanz zu aktivieren. Dabei können zu startende Jobs, Aufträge und beliebige XML Kommandos übergeben werden.
   
   
2. Aktuell stehen Ihnen zwei Möglichkeiten zur Verfügung, das Auslösen von Jobs und Aufträgen in anderen Instanzen und das Verteilen mehrerer gleichartiger Konfigurationen für Jobs und Job-Ketten in unterschiedlichen Instanzen:
   • Der o.g. Job scheduler_remote_execution kann auftragsgesteuert in einer Job-Kette verwendet werden, um einen Verarbeitungsschritt in einer anderen Job Scheduler Instanz auszuführen. Dabei wird aktuell nicht das Ende der Verarbeitung in der Job-Kette der anderen Instanz abgewartet, sondern die erfolgreiche Auslösung quittiert und die Verarbeitung in der lokalen Job-Kette fortgesetzt.
     
     Um Ergebnisse (payload) von Aufträgen aus einer anderen Instanz in die lokale Instanz zu übertragen, müssen Sie in der anderen Instanz denselben Job scheduler_remote_execution konfigurieren und den Auftrag an die lokale Instanz zurückgeben.
     
     
   • Um gleichartige Konfigurationen für Jobs und Job-Ketten auf mehreren Rechnern zu betreiben, können Sie die Installations-Komponente Managed Jobs verwenden. Dabei werden Konfigurationen in einer zentralen Datenbank vorgehalten und beim Start der jeweiligen Job Scheduler Instanz automatisch übernommen, siehe Dokumentation Managed Jobs.
     
     
   Dieser Punkt wird im Rahmen der Roadmap erweitert werden.
   
   

1. Verzeichnisüberwachung für Job-Starts
   
   Sie können beliebige Jobs automatisch starten lassen sobald Änderungen in einem oder mehreren Verzeichnissen erfolgen, indem Sie das <start_when_directory_changed> Element Ihrer Job-Konfiguration hinzufügen. Der Job Scheduler startet den Job, wenn ein entsprechendes Ereignis für eine Datei eintritt, die einem angebbaren regulären Ausdruck entspricht.
   
   Ihre Job Implementierung muss allerdings berücksichtigen, dass mehrere Dateien gleichzeitig eintreffen können. Der Job Scheduler übergibt die Dateienamen an den Job mittels der Umgebungsvariablen SCHEDULER_TASK_TRIGGER_FILES bzw. der API Methode spooler_task.trigger_files(). Mehrere Dateinamen sind durch ";" getrennt. Außerdem sollte Ihr Job ggf. Dateinamen verarbeiten können, die Leerzeichen enthalten, siehe untenstehende Beispiele für Implementierungen mit der Shell.
   
   Darüber hinaus ist es Aufgabe Ihrer Job-Implementierung Dateien aus dem überwachten Verzeichnis zu verschieben bzw. zu löschen und ggf. Fehler zu behandeln. Es kann für diese Aufgaben angemessener sein, Dateiaufträge einzusetzen.
   
   Beispiel:

   
   <job name="my_job">
     <!-- for unix shell -->
     <script language = "shell"><![CDATA[
       IFS=";"
       for trigger_file in ${SCHEDULER_TASK_TRIGGER_FILES}
       do
         echo $trigger_file
         mv "$trigger_file" /tmp/output
       done
       IFS=$' \t\n' 
       exit 0
     ]]</script>
   
     <!-- for windows shell -->
     <--
     <script language = "shell"><![CDATA[
       @echo off
       if not defined SCHEDULER_TASK_TRIGGER_FILES exit 0
       set trigger_files=%SCHEDULER_TASK_TRIGGER_FILES:;=?%
       :loop
       for /F "usebackq tokens=1* delims=?" %%i in ('%trigger_files%') do (
         set trigger_files=%%j
         @echo %%~fi
         move /y "%%~fi" \tmp\output
         goto loop
       )
       exit 0
     ]]></script>
     -->
   
     <start_when_directory_changed directory="/tmp" regex="sos.*"/>
   </job>
                     

2. Verzeichnisüberwachung mit Dateiaufträgen
   
   Ab Release 1.2.9 können Sie automatisch Aufträge für einzelne Dateien erzeugen lassen, die in einem oder mehreren überwachten Verzeichnissen erscheinen. Fügen Sie dazu ein oder mehrere <file_order_source/> Elemente als erste Job-Knoten Ihrer Job-Kette hinzu. Zum Konzept der Aufträge siehe Was ist das Konzept der Job-Ketten und der Auftragsverarbeitung?
   
   Für jedes Verzeichnis, das von einem <file_order_source> Element überwacht ist, wird automatisch ein Auftrag generiert, wenn eine Datei dem angebbaren regulären Ausdruck entspricht. Sie müssen keine konkurriernden Zugriffe berücksichtigen: ein Auftrag wird pro Datei einmal erzeugt und der Dateiname wird im Auftragsparameter order.params().value("scheduler_file_path") geliefert. Nachdem die Datei von Ihren Jobs verarbeitet wurde, wird sie von einem <file_order_sink> Element am Ende der Job-Kette verschoben bzw. entfernt. Wird die Datei manuell entfernt, dann entfernt der Job Scheduler den Auftrag automatisch, falls er noch nicht angelaufen ist.
   
   Da Aufträge persistent in der Job Scheduler Datenbank gespeichert werden können, kann die Verarbeitung nach dem Neustart des Job Schedulers fortgesetzt werden. Das gleiche gilt im Fall von Fehlern während der Verarbeitung in Job-Knoten: der Auftrag kann im jeweiligen Job-Knoten nach einer konfigurierbaren Verzögerung zurückgestellt oder wiederholt werden.
   
   Beispiel:

   
   <job_chain  name = "inbound_files">
     <file_order_source  directory = "/tmp/inbound"      regex = "[^~]$"          
                            delay_after_error = "5"/>
     <file_order_source  directory = "/tmp/inbound.add"  regex = "[^~]$"          
                            delay_after_error = "5"/>
     <job_chain_node         state = "convert"           next_state = "transfer"  
                                error_state = "error"
                               job = "file_convert"/>
     <job_chain_node         state = "transfer"          next_state = "success"   
                                error_state = "error"/>
                               job = "file_transfer"/>  
     <file_order_sink      move_to = "/tmp/inbound.success"  state = "success"/>
     <file_order_sink      move_to = "/tmp/inbound.error"    state = "error"/>
   </job_chain>
                     

• <process file"... cmd.exe" param="/c echo 'hello world' "/>
• <process file"... cmd.exe" param='/c echo "hello world" '/>
• <process file"... cmd.exe" param="/c echo &quot;hello&quot; &apos;world&apos; "/>

<job name="job_1">
  <script language="shell">
    <include file="my_shell_commands.cmd"/>
  </script>
</job>
              

• Zusätzlich zu Job-Parameteren, die nur für den betreffenden Job sichtbar sind, können Aufträge Parameter enthalten, die für alle Jobs der Job-Kette sichtbar sind.
  
  
• Der return code von Jobs mit API-Implementierung verwendet true in der Methode spooler_process(), um eine wiederholte Verarbeitung des Jobs zu veranlassen, während auftragsgesteuerte Jobs die erfolgreiche Verarbeitung eines Job-Knotens mit true und Fehler mit false signalisieren.

• Das Programm liefert keinen passenden Exit Code im Fall von Fehlern oder Warnungen; passend bezeichnet einen Exit Code != 0. Daher kann der Job Scheduler keinen Fehler bemerken. Darüber hinaus würden Fehler bemerkt, falls das Programm Meldungen nach stderr schreibt.
  
  
• Sie sagen, das Programm zeigt normalerweise ein GUI - das kann Probleme verursachen: der Job Scheduler führt Programme im Batch aus, d.h. ohne Benutzerinteraktion, da es keinen Benutzer gibt, der auf Eingabeaufforderungen antworten könnte.
  
  Um das zu verifizieren, können Sie den Job Scheduler manuell starten: stoppen Sie den Job Scheduler als Dienst und starten Sie ihn in einer DOS-Box an der Kommandozeile mit .\bin\jobscheduler.cmd start
  
  Sollte das Programm sich jetzt korrekt verhalten, dann können Sie die Einstellungen in der Windows Dienstesteuerung für den Job Scheduler anpassen: im Dienstefenster gibt es den Karteireiter Anmelden, in dem normalerweise das lokale Systemkonto zugewiesen ist. Hier finden Sie eine Check-Box, die vereinbart, dass der Datenaustausch zwischen Dienst und Desktop zugelassen ist.

• Job Scheduler ist ein 32bit Programm
  
  Der Job Scheduler ist als 32bit Programm entwickelt worden. Sie könnten jetzt fragen, weshalb die Software nicht für 64bit portiert wird? Die Anwort ist einfach: es gibt keinen Bedarf für diese Portierung.
  
  
  • Sie können die ausführbare 32bit Datei des Job Schedulers auf jeder der unterstützten 64bit Plattformen ablaufen lassen (Windows, Linux, Solaris, HP-UX PA-RISC, HP-UX Itanium). Der Betrieb des Job Schedulers erfolgt unabhängig von der Tatsache, dass Sie vermutlich 64bit Programme innerhalb Ihrer Job-Implementierungen ablaufen lassen wollen, da der Job Scheduler plattformspezifische Prozesse startet.
    
    
  • Der mögliche Gewinn an Ausführungsgeschwindigkeit zwischen einer 32bit Version und einer 64bit Version des Job Schedulers ist vernachlässigbar. Der bei weitem höhere Anteil der Ausführungszeit wird durch Jobs verbraucht, nicht durch den Job Scheduler.
    
    
  • Für eine 64bit Version des Job Schedulers ist ein forking des Codes erforderlich. Aktuell stellen die 32bit Plattformen (Windows) den größten Anteil der Downloads dar und müssen weiter unterstützt werden. Wir würden daher zusätzliche Entwicklerkapazitäten für die Pflege zweier Versionen über einen längeren Zeitraum aufwenden müssen, was effektiv die Roadmap des Job Schedulers verlangsamen würde. Wir schätzen den Nutzen neuer Features höher ein als den Nutzen aus einer vereinfachten Installation durch einen nativen 64bit Job Scheduler.
  
  
• Java 32bit JRE
  
  Ein Java 32bit JRE wird für die Ausführung des Setups und für den Betrieb des Job Schedulers benötigt.
  
  Unserer Erfahrung nach ist es keine schlechte Idee ein von SUN bereitgestelltes JRE zu verwenden, da JREs anderer Distributionen, z.B. IBM Websphere, in manchen Punkten weniger vollständig bzw. für das jeweilige Produkt in einer Weise abgeändert sind, die keine ausreichende Kompatibilität mit Java Standards gewährleistet.
  
  
  • Windows 64bit
    
    Sie können das im entsprechenden Job Scheduler Download enthaltene JRE 1.5 verwenden oder ein separates 32bit JRE installieren. Sie sollten das neu installierte JRE auf keinen Fall permanent in Ihre PATH Systemvariable aufnehmen (oder eine ggf. vorhandene JDK JAVA_HOME Systemvariable ändern), da dies das Verhalten anderer Programme beeinflussen würde, die auf den Betrieb mit einem 64bit JRE angewiesen sind. Die Installation können Sie in folgenden Schritten vornehmen:
    
    
    1. Führen Sie Download und Installation des 32bit JRE durch.
    2. Öffnen Sie ein Konsolenfenster und fügen Sie den Pfad des gerade installierten JRE Ihrer PATH Variablen hinzu, z.B.:
       C:\>SET PATH=C:\Program Files (x86)\Java\jre1.5.0_01\bin;%PATH%
    3. Entpacken Sie das Archiv des Job Scheduler Downloads in ein temporäres Verzeichnis, z.B. C:\temp\scheduler.
    4. Starten Sie im Konsolenfenster Java mit dem Job Scheduler Setup aus dem temporären Verzeichnis, z.B.:
       C:\>java -jar C:\temp\scheduler\scheduler_win32.jar
    5. Nach Abschluss des Setups fügen Sie bitte den Pfad der Java Virtual Machine Ihrer Job Scheduler Konfigurationsdatei .\config\sos.ini hinzu, z.B.:
       [java]
vm = C:/Program Files (x86)/Java/jre1.5.0_01/bin/client/jvm.dll
    
    
  • Unix/Linux 64bit
    
    Sie müssen ein 32bit JRE per Download beziehen, falls keines auf dem Rechner verfügbar ist.
    
    
    1. Führen Sie Download und Installation des 32bit JRE durch.
    2. Fügen Sie den Pfad des gerade installierten JRE Ihrer PATH Variablen hinzu, z.B.:
       PATH=$HOME/jdk1.5.0_06/jre/bin:$PATH
    3. Entpacken Sie das Archiv des Job Scheduler Downloads in ein temporäres Verzeichnis, z.B. /tmp/scheduler. md /tmp/scheduler
cd /tmp/scheduler
tar xzf scheduler_linux.1.3.1.tar.gz .
    4. Starten Sie Java mit dem Job Scheduler Setup aus dem temporären Verzeichnis, z.B.:
       java -jar /tmp/scheduler/scheduler_linux32.jar
    5. Nach Abschluss des Setups fügen Sie bitte den Pfad der Java Virtual Machine der Umgebungsvariable LD_LIBRARY_PATH im Startup Script ./bin/jobscheduler.sh hinzu, z.B.:
       LD_LIBRARY_PATH=$SCHEDULER_HOME/lib:/usr/local/lib:
$HOME/jdk1.5.0_06/jre/lib/i386:
$HOME/jdk1.5.0_06/jre/lib/i386/client:
$LD_LIBRARY_PATH
    
    
  
  
• Job Scheduler Setup für 64bit Plattform
  
  Stellen Sie bitte sicher, dass bei Ausführung des Job Scheduler Setups ein 32bit JRE verwendet wird. In Abhängigkeit von der Zielplattform kann es Unterschiede in der Installation des Job Schedulers geben:
  
  
  • Windows 64bit
    
    Wie jedes andere 32bit Programm müssen Sie den Job Scheduler und das Java JRE im Verzeichnis C:\Program Files (x86) (bzw. dem sprachspezifischen Verzeichnisnamen) für 32bit Programme installieren. Eine Installation in andere Verzeichnisse wird nicht funktionieren.
    
    Falls dieses Verzeichnis nicht der ideale Aufbewahrungsort für Ihre Job Scheduler Konfigurations- und Protokolldateien ist, dann können Sie die Pfade für diese Dateein im Script .\bin\jobscheduler.cmd anpassen, indem Sie die entsprechenden Kommandozeilenoptionen ändern (-config, -log-dir, -log etc.). Damit die Änderungen für den Betrieb des Job Schedulers als Windows-Dienst wirksam werden, sollten Sie die folgenden Kommandos verwenden (das Beispiel verwendet C:\Program Files (x86)\scheduler als Installationsverzeichnis):
    
    C:\>cd "C:\Program Files (x86)\scheduler\bin"
C:\Program Files (x86)\scheduler\bin>jobscheduler.cmd remove
C:\Program Files (x86)\scheduler\bin>jobscheduler.cmd install
    
    
  • Unix/Linux 64bit
    
    Es gibt keinen Unterschied bzgl. der Installation des 32bit Job Schedulers für diese Plattform. Allerdings müssen Sie ggf. Änderungen am Startup Script bzgl. des JRE Installationsverzeichnisses vornehmen (siehe oben).
  
  

• Stellen Sie sicher, dass der Job Scheduler so eingestellt ist, dass er die Erlaubnis zum Zugriff auf Netzwerklaufwerk(e) hat (Prüfen Sie die Services Konfiguration um einen unterschiedlichen Nutzer einzustellen).
  
  
• Konfigurieren Sie einen Scheduler Start Skript um das Netzwerklaufwerk einzubinden:

  <scheduler_script name = "mount_drives">
  <script language="VBScript">
  <![CDATA[
  Function spooler_init
  Dim ws, return_code, command
  
  *command = "net.exe use X: **\\server\dir* <file://%5C%5Cserver%5Cdir>*"
  *Set ws = CreateObject("Wscript.shell")
  return_code = ws.run( command, 0, 1 )
  Set ws = Nothing
  
  If return_code > 0 Then spooler_log.warn("Failed to mount drives: " & return_code)
  spooler_init = true
  End Function
  ]]>
  </script>
  
  </scheduler_script>                              
  

• Legen Sie das <script> Element in config/scheduler.xml zwischen die <process_classes> und <http_server> Elemente.
  
  
• Starten Sie den Job Scheduler neu.