...
Whilst the possibilities offered by SSH execution are limited (see What is the difference between SSH job execution and remote JobScheduler Agents?), the possibilities offered by Agents or remote JobSchedulers require some prerequisites as they rely on Process Classes. Process classes have the disadvantage that instances of the job chain and job have to exist (and to be maintained) on every JobScheduler that the job is to be (potentially) executed on.
The scheduler.remote_scheduler technique described on this page allows a job in a job chain to be executed on a remote JobScheduler without the need for a job chain or the job itself to be installed in the live folder of the remote JobScheduler. 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 of this method means that job execution on remote JobSchedulers can be 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 be made dynamically, for example, depending on the result of the preceeding 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.
...
- The remote JobScheduler can be either a workload instance or an Agent.
- Job, job chain and order configuration data is only transferred to the remote JobScheduler as required, JobScheduler objects are not saved on the remote JobScheduler.
- The operations carried out on the remote JobScheduler are recorded in log files in the
$SCHEDULER_DATA/logsdirectory as defined in the JobScheduler Master - Installation Guide. - Log information for the operations carried out on the remote JobScheduler is also saved in the
$SCHEDULER_DATA/logsdirectory of the 'main' JobScheduler.
...