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.
