| Table of Contents | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
THIS PAGE IS 'WORK IN PROGRESS'
Introduction
There are a number of methods available for controlling job execution on remote servers with JobScheduler. The most important of these are:
- SSH;
- Using (a) JobScheduler agent(s) (Dynamic (setting of the) JobScheduler agent).
Whilst the possibilities offered by SSH execution are limited (see What is the difference between SSH-Job execution and remote JS-Agents?), the possibilities offered by Agents or remote JobSchedulers has is also somewhat restricted, in that they rely on process classes.
Process classes have had the disadvantage that instances of the job chain and job have to exist (and be maintained) on every JobScheduler that the job is to be (potentially) executed on.
The scheduler.remote_scheduler technique described on this page has been introduced with JobScheduler version 1.7 and allows a job in a job chain to be executed on a remote JobScheduler without neither the need for a job chain or the job itself to be installed in the live folder of the remote JobScheduler nor the need . It is also not necessary for a process class to be defined.
The remote JobScheduler is simply defined by setting the scheduler.remote_scheduler order parameter:
The ease with which this method allows remote JobScheduler's to be set means that job execution on remote JobSchedulers can more flexibly allocated than with process class based methods. In particular, it allows the decision about which JobScheduler a job is to be executed on to depend be made dynamically, for example, depending on the result of the preceding job.
In addition, only one instance of the job and job chain need to be defined in the live folder of the 'main' JobScheduler, thereby considerably increasing flexibility and reducing maintenance.
scheduler.remote_scheduler Example
An A scheduler.remote_scheduler example has been prepared and can be downloaded from:
...
- Order_1_Local
- Order_2_Homer-4432
These objects can be seen in the following screenshot from JOE:
| Graphviz |
|---|
digraph \{
graph [rankdir=TB]
node [shape=Mrecord,style="filled",fillcolor=lightblue]
node [fontsize=10]
ranksep=0.3
subgraph cluster_0 \{
style=filled;
color=lightgrey;
node [style=filled,color=white];
label = "JobScheduler";
labeljust = "l";
pad = 0.1;
StartProcessing[label= "\{<f0>Start\ Processing\}"];
Job1[label= "\{<f0>Job1\}"];
EndProcessing[label= "\{<f0>End\ Processing\}"];
StartProcessing -> Job1 -> EndProcessing [weight=4];
\}
\} |
The job chain itself is quite simple as can be seen in the diagram to the right:TODO: ADD GV DIAGRAM OF JC
When "Order_1_Local" is started - for example, using JobScheduler's JOC interface, "Job_Chain_1" will be executed on the local host - i.e. the JobScheduler in whose file system the demo files were unpacked.
...
The JobScheduler that is to execute the job chain is specified as an order parameter as can be seen shown in the following screenshot below:.
TODO: ADD SCREENSHOT
or, in the XML of the {{Job_Chain_1,Order_2_Homer-4432.order.xml<code> file:
...
To get "Order_2" to be executed on a remote JobScheduler in your network simply change the <code>scheduler.remote_scheduler}} parameter in either JOE or directly in the "Job_Chain_1,Order_2_Homer-4432.order.xml" file to a suitable address and start the order in JOC.
TODO: ADD SCREENSHOT. This was shown in the screenshot above.
Once the order has run, open the log file and you will see that in the example "Job_1" causes either {{COMPUTERNAME = yourConputerName }} (for a Windows computer) or {{HOSTNAME = yourHostName }} (for a Linux computer) to be written to the file.
No A scheduler.remote_scheduler parameter is not set in the "Order_1_Local" order and therefore when started with this order "Job_1" will enter the be executed by default on your local computer. The name of your local computer / host or host (depending on the operating system - see above) will be entered in the log file.
Application in a Production Environment:
...