Similar questions regular like - "we do the same in Informatica (Mulesoft, ODI, Pentaho ... ) and want exactly this"
It wrong ways of course.
Thanks for your reply. Considering Talend is relatively new in the ETL space comparison is inevitable. We could argue that comparing is wrong, I am of the opinion if something works for one should be scope for improvement for the other.
Yup we could do this, but then again I am sure you would agree, defining/computing the above expression at one place using it at the rest sounds a better approach.
First of all, never use Contexts other than default. Many people confuse the Context terminology. A context is your set of context variables (DEV, TEST, PROD, default, etc). A Context Group is a batch of related context variables. A Context variables is....well you know that. Using multiple Contexts just adds risk to process. You can mitigate this if you want to have multiple environments by using flat files or a database with the Implicit Context Load. You can make the Implicit Context Load as simple or as complicated (and secure, tailorable, etc) as you like. It is briefly described here https://help.talend.com/display/TalendOpenStudioforDataIntegrationUserGuide60EN/C.3.4+Configuring+th...
in case when each job has it own context file - it easy to change file, but in case when many jobs share connection and other information ... better to have
TAC allow change single variable for single Job, with Community version it not true, so You will need or add command line parameter for point to different context file (database).
other case - my client work on windows server, I'm on Mac - file path will be different, so we have 2 Context at least, 1 point to my local context file, other point to his
on different projects - meet with all possible variant, but not sure which better
Many of those issues (file paths, for example) can be resolved with operating system Environment Variables. My current use of Context Variables only uses default, makes use of environment variables and encrypted db parameters and Java routines in the Implicit Context Load config (yes, routines work there) allowing a pretty secure but easily malleable Context system. My Prod and Test environments cannot be changed without access to the context db, while the developers can all share context settings or set their own. This is pretty complicated, but once configured all it requires is administration of the context db.
The reason I dislike Contexs (Prod, Test, Dev, etc) is that if you have child jobs being called by parent jobs (who doesn't) you can easily run into issues when the Contexts are set incorrectly. This doesn't need to even be thought about with the system I use.
You have to set the context variables up in the Job. Have you done this? By that I mean simply either add your Context Group (if you have them grouped) or create each variable in the contexts section of your job. Once they exist, the implicit context load will bring them in.
