Skip to main content

Passing Parameters and Variables to Child Jobs in Talend Open Studio

Jobs written in Talend Open Studio communicate with child jobs using Context Variables.  To return data from a child job using a Context Variable, define an Object variable that is a java.util.Map.

Off-the-shelf, Talend Open Studio's Context Variable facility supports passing parameters from a parent job into a child job.  However, because of Java's language semantics, the reverse (return values out of the child job) needs extra code.

Something like 'context.MYVAR="newvalue"' works within a job, but if done in a child job, the setting isn't retained.  globalMap doesn't help.  Every job has its own globalMap, including child jobs.

To overcome this, use a Map which gets around the Java language limitation.  You can't set a variable in a child job, but you can manipulate an Object.

Consider the following job.
Job Creating Subjob Context Used in Child Job
The Job uses three components: 2 tJavas and a tRunJob.  The first tJava creates a java.util.Map object and sets it to a context variable defined as an Object.

Context Variable Defined as Object
Set Child Job Context

In the first tMap, "Set Subjob Param", add the following Java code to the Basic setting.  You'll also need to import java.util.Map and java.util.HashMap in the Advanced tab.

context.SUBJOB_CONTEXT = new HashMap<String, String>();

((Map<String, String>)context.SUBJOB_CONTEXT).put("param", "value1");


This will create a Map object that can be accessed throughout the job and its child jobs.  This code block sets a single entry "param" which will be an input parameter for the child job.  Note that only "param" was set here; other components and child jobs can add to this.

tRunJob

The tRunJob component is configured to "Transmit whole context".  It must NOT use an independent process for this technique to work.  I believe that all separate process params must be strings.  (Look for a future post on this.)

tRunJob Config


The Child Job

The Child Job is defined as a single tJava.  It is configured with an identical Context View as the parent.  See the "Context Variable Defined as Object" screenshot.

Child Job

The tJava component prints the input parameter, unpacks the context.SUBJOB_CONTEXT map, and puts its own return value on it.  Remember to also import java.util.Map on the Advanced tab.

// print input param

System.out.println("param=" + ((Map<String, String>)context.SUBJOB_CONTEXT).get("param"));

// set ret val
((Map<String, String>)context.SUBJOB_CONTEXT).put("retVal", "Ok");

Using an indirect approach, you can create a context for your child jobs.  This introduces a global scope for all your jobs so watch for side effects.

Comments

Popular posts from this blog

ODI KM Adding Order by Option

You can add Order by statement to queries by editing KM.I have edited IKM SQL Control Append to provide Order by.  1) Add an option to KM named USE_ORDER_BY, its type is Checkbox and default value is False. This option determines you want an order by statement at your query. 2)Add second option to KM named ORDER_BY, type is Text. You will get order by values to your query by this option. 3) Editing Insert New Rows detail of KM. Adding below three line code after having clause. That's it! <% if (odiRef.getOption("USE_ORDER_ BY").equals("1")) { %> ORDER BY <%=odiRef.getOption("ORDER_BY" )%> <%} %>  If USE_ORDER_BY option is not used, empty value of ORDER_BY option get error. And executions of KM appears as such below; At this execution, I checked the KM to not get errors if ORDER_BY option value is null. There is no prove of ORDER BY I'm glad.  Second execution to get  Ord

Creating Yellow Interface in ODI

Hello everyone! In Oracle data integrator (ODI), an  interface  is an object which populates one datastore, called the  target , with data coming from one or more other datastores, known as  sources . The fields of the source datastore are linked to those in the target datastore using the concept of  Mapping . Temporary interfaces used in ODI are popularly known as  Yellow Interfaces . It is because ODI generates a yellow icon at the time of creation of a yellow interface as opposed to the blue icon of a regular interface. The advantage of using a yellow interface is to avoid the creation of  Models each time you need to use it in an interface. Since they are temporary, they are not a part of the data model and hence don’t need to be in the Model. So let’s begin and start creating our yellow interface! Pre-requisites : Oracle 10g Express Edition with *SQL Plus, Oracle Data Integrator 11g. Open *SQL Plus and create a new table  Sales  in Oracle. You can use any existing ta

Running Count in Talend Open Studio

Most Talend components keep a count of the records processed using variables like NB_LINE or NB_LINE_OK.  But these are only available after all processing is completed.  Define your own counter variable to keep a running count for use in a tMap. Variables like tFilterRow.NB_LINE or tAccessOutput.NB_LINE_INSERTED can be used to report the number of affected lines after a subjob's processing.  However, it may be of use to get the current line index for use in a tMap.  The index variables used to form NB_LINE aren't available during processing; they're only written out the globalMap at the end of processing. In this example, staging records are loaded from Excel to Access.  The order in which the Excel records are read is preserved in a database column called DISPLAY_SEQ_NB.  Note that there is an auto-increment column used for record ID in the Access table.  This could be used to infer a loading order, but this job uses a separate column to keep the ID as a meaningless surr