The source section of the job file format is probably the most interesting one to manually edit or review. Here's an example source section:
<source> <data-context ref="orderdb" /> <columns> <column path="PUBLIC.EMPLOYEES.EMPLOYEENUMBER" id="col_0" type="INTEGER" /> <column path="PUBLIC.EMPLOYEES.LASTNAME" id="col_1" type="VARCHAR" /> <column path="PUBLIC.EMPLOYEES.FIRSTNAME" id="col_2" type="VARCHAR" /> <column path="PUBLIC.EMPLOYEES.EXTENSION" id="col_3" type="VARCHAR" /> <column path="PUBLIC.EMPLOYEES.EMAIL" id="col_4" type="VARCHAR" /> <column path="PUBLIC.EMPLOYEES.OFFICECODE" id="col_5" type="VARCHAR" /> <column path="PUBLIC.EMPLOYEES.REPORTSTO" id="col_6" type="INTEGER" /> <column path="PUBLIC.EMPLOYEES.JOBTITLE" id="col_7" type="VARCHAR" /> </columns> <variables> <variable id="employee type" value="Sales Rep" /> </variables> </source>
From this source section we can derive these interesting facts:
The job is using the datastore called 'orderdb'. How this datastore is configured, the job is not aware of, since it is defined in the configuration . Potentially the job could be used with multiple similar datastores, as long as their name was 'orderdb'.
The columns defined make up the base of the source query that the job will fire. Each column is assigned an artificial ID, and a hint about it's data type is provided. This information is there to be able to detach or replace a column with a new definition. That means that if you've spend a long time building the perfect job, but want to apply it to a different column, you can potentially "just" change the column definition here and retain the original column ID.
In this source section we also see some variables. This is an optional sub-section and not that common. The variables are property values that can be replaced at runtime with new values. See the chapter Parameterizable jobs for more information and examples.