Product Knowledge Base

Space shortcuts

Page tree

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Introduction

To be added

Downloads

Instructions

  • Unzip all files into the ./config folder of your JobScheduler installation.

  • Open config/scheduler.xml and add the following lines right before the <security> element:

    <params> 
  <param name="global_configuration_params" value="config/scheduler_global_vars.xml"/> 
</params>

A window will open showing the log of the order. As the order isn't running yet, the window will show nothing more than a line indicating the next start time of this order. Leave the window open and move it to a place where you can see it along with the main browser window.

  • Start the order by choosing "Start order now" from the Order menu.
  • Watch the log grow in the other window

The order will run through both steps of the job chain. In each step the order parameters will be logged by the job. The parameters param1 - param4 should have the following values:

State:first
       param1=10
       param2=abc
       param3=foo
       param4=abc---def


State:second
       param1=10
       param2=xyz
       param4=xyz---def

Nothing special so far. The next section explains how these resulting parameters were configured.

How it works

The job chain chain_a is very simple. It consists of two steps, "first" and "second". Both steps use the same job readparam. The readparam job is a small JavaScript job which reads all order parameters and logs them on info-level.

The Java monitor implementation sos.scheduler.managed.configuration.ConfigurationOrderMonitor is configured as a monitor for the job. This is a special pre/post-execution script which is included in the JobScheduler distribution. It can be used for all jobs. It reads special job chain parameter files which set parameters for a job chain and are able to configure each node of a job chain individually. This cannot be done using normal order parameters. It could be achieved by using job parameters, but if the same job is used at multiple steps of a job chain or in different job chains you would have to define multiple instances of that job, although it's the same job implementation. (E.g. a job chain consist of three steps: 1.transfer file by FTP to host a, 2.transfer file by FTP to host b, 3.delete file. You could use the same job for steps 1 and two, but you would need different parameters.) So, in this example we use the same job twice, but as you have seen from the log, with different parameters.

When using hot folders, the configuration monitor looks for the job chain parameter file in the current hot folder and expects the name job_chain_name.config.xml. So in this case, the name of the job chain parameter file is chain_a.config.xml.

chain_a.config.xml has three <params> elements:

  • The first one is a child of the <order> element. It configures parameters for all steps of the job chain. That's why the log shows param1 as 10 in both steps.
  • The second <params> element is a child of <process state="first">. It configures parameters for the first node (called "first") of the job chain. It sets two additional parameters param3 and param4. param4 uses a special ${paramname}-syntax to reference other parameters. It references param2 which was set in the first params element. As you see in the log, this part is later resolved to abc.
  • The third is the global_test_var parameter that is a variable defined in config/scheduler_global_vars.xml.
    By configuring the global scheduler variable global_configuration_params in scheduler.xml to point to that file (scheduler_global_vars.xml), we tell the configuration monitor to always read that file and process it's parameters. In config/scheduler_global_vars.xml the value for global_test_var is set to def, so the reference in param4 is resolved to that value.

Note that:

  • The second <params> element is a child of <process state="second">. It configures parameters for the second node (called "second") of the job chain. It overwrites the param2 parameter and sets it to xyz. param3 is not set at all, thus it doesn't appear in the log for state second. 
  • param4 is defined in the same way as in state first, but this time the resulting value is different because param2 has been overwritten for this state.

In job chain parameter files the ${paramname}-syntax can be used to reference

  • order parameters
  • order parameters defined in the job chain parameter file
  • global scheduler variables
  • environment variables

 

  • No labels