Context is how Talend allows you to specify the runtime parameters of your Jobs.
With the Framework, you specify the runtime parameters of your Job in Context Files. You only need to specify the values that are an exception to any default or inherited values.
The construction of a Context File is similar to that of a traditional INI File.
Context Files may have an hierarchical structure, meaning that you only need to specify any exceptions, at lower-levels. This means, for example, that if you have many Jobs that connect to the same Database instance, you need specify the connection details only once. If one of your Jobs is to use a different Username and Password, you may specify those values for that specific Job, and still inherit the location of the Database from a higher-level Context File.
Context Values are loaded by the Context Loader. For now, we will not look at how it works, we will concentrate on the construction of the files that allow it to perform its function. For more information on the Context Loader, read this article.
Creating a Job’s Context File
Each Job has it’s own Context File. When you first run your Job, its Context File will be created if it does not already exist. For a Job that does very little, this may be sufficient; however, in many case, you will need to do a little more work.
The construction of a Context File is Context + Job Name + “.context”, for example:-
Dev.MyJob.context Test.MyJob.context Prod.MyJob.context
As discussed in Context, you have control over the Context Names, should you choose.
Auto-creation of a Job’s Context File
As discussed above, the first time you run your Job, its Context File will be created if it does not already exist.
The Framework will add all of the values from the Framework Context Groups, that you are permitted to modify. These will be added, showing their default values; but they will be commented-out. If you wish to change any of these values at Job-level, then simply un-comment the relevant parameter and modify its value. Modifying values at Job-level should be an exception. In most cases, you should be using default or inherited values, as discussed later in this article.
The following example shows the first few lines of an auto-created Context File.
# Context file for MyJob version 1.0 # Created by LibContextReader version 0.7 on Fri Oct 23 16:23:58 BST 2015 #confirmExecution="false" #debug="false" #deleteLockFileInHandledError="true" #enableEmailErrorReporting="true" #enableEmailOnSuccess="false" #enableErrorOnLockFileExists="true" #enableJobReporting="true" #enableLockFile="true" #enablePersistence="false" #enableShowContext="true" #persistenceMaxIterations="99999999" #persistenceSleepBetweenExecutions="30" #runBetweenEnd="00:00" #runBetweenStart="00:00" #baseDir="C:\Users\alan/project/talend/Default/MYPROJECT/MyJob" #archiveDir="C:\Users\alan/project/talend/Default/MYPROJECT/MyJob/archive" ...
Auto-load Context Files
Auto-load Context Files allow you to have one Context File to instruct the Context Loader to load parameters from another Context File. This allows you to have discreet Context Files that, for example, have Database connection details that may be used by multiple Jobs.
If a parameter is specified in multiple Context Files, precedence is given to the last auto-load file processed, and then to the Job’s Context File that made the auto-load request. The current version of the Framework only allows Auto-load requests to be made from the top-level Context File.