Passing information between jobs
In order to identify a particular job, either to gain access to
it's properties, or to perform some action on it (run, stop, schedule etc)
a job is given an
'id'. An id must be unique and must not contain the
characters .()[]. or /.
To demonstrate using a jobs id lets change the Oddjob configuration we created in the previous section so that our batch file is automatically scheduled when we run the Oddjob. Open the configuration in Oddjob Designer and select the 'Execute a Command' node. In the id field on the right enter 'my-job'.
Next select the 'A Scheduler' node and in the Schedules table on the right select the topmost cell in the 'Type' column. From the drop down selection choose 'ojschedule'.
Click the edit button and the familiar 'Schedule Details' dialog will appear. This time the 'Job To Schedule' field is blank. We must now tell Oddjob, via the configuration, which job to schedule. We do this using the notation ${job-id} in the configuration field. Oddjob will recognize a ${ } character sequence and takes what is between the curly brackets to be the id of job we wish to schedule. This happens every time the scheduler job is run.
So in the 'Job to Schedule' field enter the text ${my-job}. In the other fields enter values as per the previous section.
Save the configuration and open it in Oddjob Explorer again. Expand the tree and you should see that our job has been automatically scheduled.
The configuration settings made in Oddjob Designer set what are known as the job's properties. The 'Command' field of the <exec> job set a property called 'command'. Some properties such as this one are set during configuration, some such as 'nextDue' on the schedule are set by the job when it runs. Some are read only and can't be changed by the user. Some like 'nextDue' can be changed by the user between job executions. Some must be set in the configuration or the job won't work. The reference lists every property of every job and indicates how it can be used.
Just as you can reference a job in the configuration file, you can also reference a property of a job. The notation for accessing a property is ${job-id.job-property}.
As an example lets create a simple configuration. Create a new configuration. Set a sequential job as Oddjobs only job, and then add an echo job to it (from the assorted section). Set the id of the job to something like "my-echo" and the 'Text' field (or 'text' property) to "This will be displayed twice!".
Add another echo job to the 'A Sequence of Jobs' node but in this echo jobs text property enter the value "${my-echo.text}".
Save the configuration and then open it in Oddjob Explorer. The jobs will run immediately and in the console you should see that the text has been displayed twice.
When setting the text property of the second job, Oddjob looked up the job with the id of 'my-echo' and then looked up the property 'text' of that job.
This substitution is the first thing that happens when a job is run. Altering the order of the jobs in the example would be OK because the fixed text of the first job is set when the job is loaded. Adding a third job to run before the other two which relied on the second jobs text property wouldn't work because the second job hadn't run and therefore hadn't had it's text property set. Adding the third job after the first two would be OK.
Oddjob supports more complicated property specifications but for most simple situations ${id.property} is all that is needed.
When discussing the properties of a job there is one job that deserves special attention and that is the variables job. While most jobs have a fixed properties with names that never change the variables job has properties which are defined dynamically at runtime.
As an example we'll replace our first echo job in the previous example with a variables job. Delete the first echo job (from the job menu). Select the 'A Sequence of Jobs' and add a new variables job from the Add Job menu. The variables job appears at the end of the list which isn't very useful because as it's properties are created when it runs so we need it to run first. To move it, select the job then use Cut from the Edit menu. Select the echo job and then Paste. Click OK for insert and the job should be moved. Now configure the variables job by giving it an 'Id', say 'vars' and in the Named Values section select a type of 'value', and enter a name of 'greeting' and then enter 'hello' in the value cell.
We have created a variables job that has property called 'greeting' that will be available when the job runs. The type of the property depends on where it is to be used. The value property is the most common type and can be used for text, numbers etc. When a more complicated type is required as the property of job then this will be documented in the reference.
We need to change our runtime property in the echo job to match our new variables configuration i.e. '${vars.greeting}' and then we can save and open or reload the new file in Oddjob Explorer and hopefully see in the console output 'hello'
As you saw in the examples, an Oddjob job can be nested within another Oddjob job. Is it possible to access a job within the nested Oddjob? Yes it is. You use the notation ${oddjob-id/job-id.property}.
Is it possible to access a property in the outer Oddjob from the nested Oddjob? Only if the outer Oddjob passes the property down as an 'argument' of the nested Oddjob. It can then be accessed using the notation ${inner-oddjob-id[index]}
But we are now into advanced configuration territory and so we shall leave this section with just this taste of what lies ahead...