Introduction
To be added
Downloads
Configuration Monitor
Question: How can I define parameters at one place and reference them?
...
- configuration.zip - configuration files
Instructions
...
- Unzip all files into the
./config
folder of your JobScheduler installation. - Open
config/scheduler.xml
and add the lines
...
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 JavaScript job which reads all order parameters and logs them on info
-level.
The java 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 FTP to host a, 2.transfer file by ftp 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 showsparam1
as10
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 parametersparam3
andparam4
.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 toabc
.
...
- The third is the
global_test_var
parameter
...
- that is a variable defined in
config/scheduler_global_vars.xml
.
By configuring the global scheduler variableglobal_configuration_params
inscheduler.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. Inconfig/scheduler_global_vars.xml
the value forglobal_test_var
is set todef
, so the reference inparam4
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 theparam2
parameter and sets it toxyz
.param3
is not set at all, thus it doesn't appear in the log for statesecond
. param4
is defined in the same way as in statefirst
, but this time the resulting value is different becauseparam2
has been overwritten for this state.
In job chain parameter files the ${paramname}
-synthax syntax can be used to reference
- order parameters
- order parameters defined in the job chain parameter file
- global scheduler variables
- environment variables