...
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 be shown in the log with the following values:
Code Block | ||
---|---|---|
| ||
State:first param1=10 param2=abc param3=foo param4=abc---def |
and
Code Block | ||
---|---|---|
| ||
State:second param1=10 param2=xyz param4=xyz---def |
...
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 . In the JobScheduler Object Editor, JOE, it is called under JobScheduler Objects.Jobs.Jobname.Pre-/Post-Processing as a Java configuration_monitor. The monitor 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.
Note:
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 in a job chain or in different job chains you would have to define multiple instances of that job, although it 's is the same job implementation. (E.g.
(For example, if a job chain consist consists 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.
The example in detail:
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
.
...