





















































(For more resources related to this topic, see here.)
To get ready for this article, we first need to check that our Java environment is configured properly; to do this, check that the JAVA_HOME environment variable is set. Even if all the PDI scripts, when started, call other scripts that try to find out about our Java execution environment to get the values of the JAVA_HOME variable, it is always a good rule of thumb to have that variable set properly anytime we work with a Java application.
The Kitchen script is in the PDI home directory, so the best thing to do to launch the script in the easiest way is to add the path to the PDI home directory to the PATH variable. This gives you the ability to start the Kitchen script from any place without specifying the absolute path to the Kitchen file location. If you do not do this, you will always have to specify the complete path to the Kitchen script file.
To play with this article, we will use the samples in the directory <book_samples>/sample1; here, <book_samples> is the directory where you unpacked all the samples of the article.
For starting a PDI job in Linux or Mac, use the following steps:
–file: <complete_filename_to_job_file>
Remember to specify either an absolute path or a relative path by properly setting the correct path to the file. The simplest way to start the job is with the following syntax:
$ kitchen.sh –file:./export-job.kjb
$ kitchen.sh –file:/home/sramazzina/tmp/samples/export-job.kjb
–dir: <complete_path_to_ job_file_directory>
So, if we're located in the same directory where the job resides, to start the job, we can use the following new syntax:
$ kitchen.sh – dir:. –file:export-job.kjb
$ kitchen.sh –dir:/home/sramazzina/tmp/samples –file:export-job.kjb
For starting a PDI job with parameters in Linux or Mac, perform the following steps:
-param: <parameter_name>= <parameter_value>
$ kitchen.sh –param:p_country=USA -file=./export-job.kjb
Of course, you can apply the –param switch to all the other three cases we detailed previously.
For starting a PDI job in Windows, use the following steps:
-file: <complete_filename_to_job_file>
Will become:
/file: <complete_filename_to_job_file>
And:
–dir: <complete_path_to_ job_file_directory>
Will become:
/dir: <complete_path_to_ job_file_directory>
C:tempsamples>Kitchen.bat /file:./export-job.kjb
–param: <parameter_name>= <parameter_value>
Will become:
/param: <parameter_name>: <parameter_value>
C:tempsamples>Kitchen.bat /param:p_country:USA /file:./exportjob.
kjb
For starting the PDI transformations, perform the following steps:
$ pan.sh –file:./read-customers.ktr
$ pan.sh –param:p_country=USA –file:./read-customers.ktr
C:tempsamples>Pan.bat /file:./read-customers.ktr
C:tempsamples>Pan.bat /param:p_country=USA /file:./readcustomers.
ktr
IIn this article, you were guided through simply starting a PDI job using the script Kitchen. In this case, the PDI job we started were stored locally in the computer filesystem, but it could be anywhere in the network in any place that is directly accessible. You learned how to start simple jobs both with and without a set of input parameters previously defined in the job.
Using command-line scripts was a fast way to start batches, but it was also the easiest way to schedule our jobs using our operating system's scheduler. The script accepted a set of inline arguments to pass the proper options required by the program to run our job in any specific situation.