Any way for tRunjob to launch the subjob with its current context??

One Star jds
One Star

Any way for tRunjob to launch the subjob with its current context??

We have a series of similar jobs (happens to be 16 of them currently, but likely to grow) that we may run independently but also we want to be able to run them all as a group. To run them all, we created a simple 'Master' job that is just a sequence of tRunjob widgets. For this entire setup, we have 3 contexts: Dev, QA and Prod (Default too so appears to be 4 within Talend Studio).
Issue we are having is that in tRunjob, the drop down selection for each job provides only a way to select one of the 4 contexts explicitly. But what we want, is to select the context at run time for the 'Master' job and have that selected context be the context that all the subjobs use. However, there does not seem to be a way say in the tRunjob widgets to use the current context, so if we want to switch from Dev to QA, or QA to Prod, we currently would need to go into all 16 (and soon more) tRunjobs and change the setting, vs. just setting the context 'Master' job is running as. This seems both counter-intuitive and quite cumbersome to us...
Are we missing some straightforward way to do this?
Thanks.
Five Stars

Re: Any way for tRunjob to launch the subjob with its current context??

tRunJob has a checkbox "Transmit whole context". I think that this is what you're looking for.
One Star jds
One Star

Re: Any way for tRunjob to launch the subjob with its current context??

tRunJob has a checkbox "Transmit whole context". I think that this is what you're looking for.

Thanks for your reply. Unfortunately, that would not not solve the issue as we in fact have the "Transmit Whole Context" checked in all the tRunjobs. 
Despite this setting, within the child jobs, the value of contextStr always matches the setting in the parent job's tRunjob selector, not the context selected in the parent job's Run window, which is what we expected (and need) it to be.
Sixteen Stars

Re: Any way for tRunjob to launch the subjob with its current context??

What tal00000 suggested is right, but I think you are using the context variables slightly wrong. First we have to describe the contexts so that we are all on the same page (Talend do a really bad job of this).
Context Variables are the actual variables. A Context Variable can have a different value per Context (DEV, UAT, TEST, PROD, etc). A Context Group is just a grouping of Context Variables that can have multiple Contexts (.....the names could be so much better).
The problem you have is that you cannot dynamically change the Context of a job at runtime. These should only really used to separate environments. What you can do is ensure that you parent job holds all of the context variables that your child will use and use the "Transmit whole context" option on the child job. This will ensure that the values you pass to your child job will correspond to those in your parent job. No matter what is in your context variables in the your child job, if a context variable value is passed in, it will overwrite whatever is set as a default.
I would recommend completely forgetting about Contexts and only having 1 (default). Clear all context variable values and store the values in a file or database. Then use either a tContextLoad to read in the context variable values from a file or a database table or use the implicit context load. This method gives you far more control. 
One Star jds
One Star

Re: Any way for tRunjob to launch the subjob with its current context??

What tal00000 suggested is right, but I think you are using the context variables slightly wrong. First we have to describe the contexts so that we are all on the same page (Talend do a really bad job of this).
Context Variables are the actual variables. A Context Variable can have a different value per Context (DEV, UAT, TEST, PROD, etc). A Context Group is just a grouping of Context Variables that can have multiple Contexts (.....the names could be so much better).
The problem you have is that you cannot dynamically change the Context of a job at runtime. These should only really used to separate environments. What you can do is ensure that you parent job holds all of the context variables that your child will use and use the "Transmit whole context" option on the child job. This will ensure that the values you pass to your child job will correspond to those in your parent job. No matter what is in your context variables in the your child job, if a context variable value is passed in, it will overwrite whatever is set as a default.
I would recommend completely forgetting about Contexts and only having 1 (default). Clear all context variable values and store the values in a file or database. Then use either a tContextLoad to read in the context variable values from a file or a database table or use the implicit context load. This method gives you far more control. 

Apologies for the delay in responding, been busy on other aspects of our project, but today we were able to run some test and figure out what was happening here. Thanks for your response rhall2.0, I certainly appreciate the effort for any help, but I do not think your response is quite correct... 

First off, I do 100% (more if possible) agree with rhall2.0 that Talend's documentation does not do as good a job as it should of explaining context variables and context groups. However, I do think we understand them pretty well at this point and that we are using them correctly.
Re rhall2.0's suggesting that we could gain more control by utilizing tContextLoad etc., I believe that could have been made to work but would have entailed quite a bit of added effort, including having each child job potentially try to detect when it was being run as a child or when it was be run independently.
tal00000's suggestion to transmit the whole context is indeed correct, and as mentioned we were in fact already trying just that, but it appeared not to be working because the value of contextStr in the child was showing the context value of the setting from the calling tRunjob widget, not the context setting the parent job was being run as. However: the value of contextStr in the child job is WRONG.
(IMHO, A) BUG: contextStr in a child ALWAYS shows the value of the setting from the parent's rRunjob widget, even though the entire context HAS been sent down, and the context variables themselves DO contain the correct values that match the running context of the parent.

Example: 

We have 3 contexts, Dev, QA, and Prod, plus Default which has the same settings as Dev, and several context groups (Files, SQL_Server, PB_Server, Master_Server, etc.)  and with the context group SQL_Server, there is a variable 'SQL_SERVER_ServerName', that depending on context could have values : Default/Dev: devnymssql02, QA: qanymssql02, Prod: mcgnymssql02
Parent job is running with a context of 'QA', and contains a tRunjob widget launching Child job with 'transmit whole context' set and context of 'Default' selected. 
In Parent job, contextStr is 'QA', and SQL_SERVER_ServerName is 'qanymssql02'
In Child job, contextStr is 'Default' (this is why we didn't think things were working), but SQL_SERVER_ServerName is 'qanymssql02' as hoped/expected.

So: with 'transmit whole context' selected, the proper context values are being delivered to the child, but the contextStr within the child does not accurately reflect that.
Sixteen Stars

Re: Any way for tRunjob to launch the subjob with its current context??

Hi jds, I'm not sure I understand you issue here. You said....
Example: 
We have 3 contexts, Dev, QA, and Prod, plus Default which has the same settings as Dev, and several context groups (Files, SQL_Server, PB_Server, Master_Server, etc.)  and with the context group SQL_Server, there is a variable 'SQL_SERVER_ServerName', that depending on context could have values : Default/Dev: devnymssql02, QA: qanymssql02, Prod: mcgnymssql02
Parent job is running with a context of 'QA', and contains a tRunjob widget launching Child job with 'transmit whole context' set and context of 'Default' selected. 
In Parent job, contextStr is 'QA', and SQL_SERVER_ServerName is 'qanymssql02'
In Child job, contextStr is 'Default' (this is why we didn't think things were working), but SQL_SERVER_ServerName is 'qanymssql02' as hoped/expected.
So: with 'transmit whole context' selected, the proper context values are being delivered to the child, but the contextStr within the child does not accurately reflect that.

This suggests that it is working. Your value for contextStr in the Child job is "as hoped/expected". What exactly do you think is the issue? 
Sorry, I'm not meaning to be difficult, I just don't see the problem and you may well have one that I am not getting.
With regard to identifying whether a job is parent or child, that is pretty easy. All Talend jobs have public variables called "fatherPid" and "pid" (amongst others, but they aren't important here). If the fatherPid holds the same value as the pid, then the job is a parent. If they are different, then the job is a child.
                                                                                                                                                                                                                                 
One Star jds
One Star

Re: Any way for tRunjob to launch the subjob with its current context??

Hi jds, I'm not sure I understand you issue here. You said....
...
In Child job, contextStr is 'Default' (this is why we didn't think things were working), but SQL_SERVER_ServerName is 'qanymssql02' as hoped/expected.
So: with 'transmit whole context' selected, the proper context values are being delivered to the child, but the contextStr within the child does not accurately reflect that.

This suggests that it is working. Your value for contextStr in the Child job is "as hoped/expected". What exactly do you think is the issue? 
Sorry, I'm not meaning to be difficult, I just don't see the problem and you may well have one that I am not getting.
With regard to identifying whether a job is parent or child, that is pretty easy. All Talend jobs have public variables called "fatherPid" and "pid" (amongst others, but they aren't important here). If the fatherPid holds the same value as the pid, then the job is a parent. If they are different, then the job is a child.
                                                                                                                                                                                                                                 

Apologies rhall2.0 if I wasn't clear enough; I put this out to help other folks who might be experiencing the same issue. So no worries, I don't think you are being difficult at all, as if you didn't understand part of what I said and you are quite knowledgeable on Talend, very likely others would not get it either. 
YES: the jobs and contexts are  now working as we wanted, so for us there is no problem at this point. But there is what I think is a bug in the behavior of contextStr, which we are working around by just totally ignoring contextStr and only using the context variables themselves.
SPECIFICALLY: I did not say that our value for contextStr in the Child job is "as hoped/expected", in fact I said the reverse: only the context variables had the expected/hoped for/correct values. contextStr on the other hand had the wrong value, at least to my way of thinking and certainly regardless of one's view it indisputably has a value that diverges from the parallel values in the actual context variables.
I hope that is clearer.
Best,
JDS
Sixteen Stars

Re: Any way for tRunjob to launch the subjob with its current context??

Sorry I misunderstood what you were saying. I am working with teams that don't speak English as a first language and I am suffering from it :-)
I think your expectation that the contextStr be changed dynamically is wrong here. It is actually hardcoded in the Java when you set it (take a look at the Java). There may be a way in which this can be changed by using code, but I haven't really had the time to look into this in great detail.
This is not a bug, this is just poorly documented functionality. You are not supposed to change this at runtime. It is supposed to be set pre-runtime. However it seems that you have solved your issue by passing the whole context between jobs.