Page History

...

In the JobScheduler Object Editor, JOE, the monitor implementation 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. These parameter files are named by default according to the pattern myJobChain.config.xml.

The screenshot below shows the monitor configuration in JOE.

Image Added

The XML code generated by JOE for the readparam.job is:

<?xml version="1.0" encoding="ISO-8859-1"?>

<job  order="yes" stop_on_error="no">
    <params />

    <script  language="javax.script:ecmascript">
        <![CDATA[
function spooler_process(){
      var orderparams = spooler_task.order().params();
      spooler_log.info("State: "+spooler_task.order().state());
      spooler_log.info("Params:");
      var paramNames = orderparams.names().split(";");      
      for( var i in paramNames ) {
        spooler_log.info( "  "+paramNames[i] + "=" + orderparams.value( paramNames[i] ) );
      }
      
      return true;
    }
        ]]>
    </script>

    <monitor  name="configuration_monitor" ordering="1">
        <script  language="java" java_class_path="" java_class="sos.scheduler.managed.configuration.ConfigurationOrderMonitor"/>
    </monitor>

    <run_time />
</job>

The following screen-shot shows the job chain node parameters for the example:Image Removed

Note:

Image Added

The next screen-shot shows the job chain node parameter form for the example. This form is opened with the Parameter button shown in the previous screenshot (top right):

Image Added

Usage Notes

This flexible use of parameters cannot be achieved using normal order parameters. It could be achieved by using job parameters, but if the same job is used at multiple steps in a job chain or in different job chains you would have to define multiple instances of that job, although it is the same job implementation.(

For example, if a job chain consists consisted of three steps:

• 1.transfer a file by FTP to host a,
• 2.transfer a file by FTP to host b,
• 3.delete file.

You could use the same job for steps 1 and two , but you would need using different parameters for each job.

In the current .) So, in this example we use the same job twice, but as you have seen from the log, with different parameters.

...

• 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.

The full chain_a.config.xml file is listed in the following block:

<?xml version="1.0" encoding="ISO-8859-1"?>
<?xml-stylesheet type="text/xsl" href="scheduler_configuration_documentation.xsl"?>
<settings>
  <job_chain name="chain_a">    
   <order>
     <params>       
       <param name="param1"                  value="10"/>
       <param name="param2"                  value="abc"/>                
     </params>
     <process state="first">
       <params>
         <!-- create parameter only for this state -->
         <param name="param3"                  value="foo"/>      
         <!-- use global and chain parameter in value of new parameter -->
         <param name="param4"                  value="${param2}---${global_test_var}"/>                
       </params>  
     </process>
     <process state="second">
       <params>
         <!-- overwrite param2 parameter -->
         <param name="param2"                  value="xyz"/>      
         <!-- use global and chain parameter in value of new parameter -->
         <param name="param4"                  value="${param2}---${global_test_var}"/>                
       </params>  
     </process>
   </order>   
  </job_chain>
</settings>

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

...