Derived Context Variables

[Anonymous]

Hi Team,

Lets say I have a context variables var1 and var2.

var1="abc"

I need var2 to be var1+" def"

Both var1 and var2 are on the same context group. How can I achieve that?

[TRF]

Hi,
Just write context.var2 = context.var1 + " def" in a tJavaRow (or tJavaXxx) component.

[Anonymous]

Hi TRF,

I needed to use it inside the context group itself and assign to another
variable!
Is that possible?

[TRF]

No, you cannot have code in the place where context variable are defined. Dynamic values must come from tJavaXxx components. You may also define global variables in a PreJob wich is a good practice to achieve initialization tasks when job starts.

[Anonymous]

Thanks TRF.
To me it sounds inefficient. Just because Talend allows only literal values
over there, we have to do the overhead of writing all those prejob codes.

[TRF]

You have no choice

[Anonymous]

I don't understand what is inefficient about this. Maybe I am misunderstanding? The only limitation regarding this issue is that you cannot add code to be performed by the Context variables themselves, however you can write a job that can be used in ALL of your jobs to carry out this code. If you are happy writing Java you can perform this sort of functionality with Java Routines or a tJavaXXX (suggested by @TRF) as well. You can also store the context variables in a database and perform any config calculations on this data during import before the jobs start.

If you can elaborate on why this is problematic I believe that myself or @TRF can point you towards an elegant solution to your problem. 

[vapukov]

---

@rhall wrote:

I don't understand what is inefficient about this. Maybe I am misunderstanding?... 

---

It normal situation, when anybody try to implement logic in new tools exactly as it was somewhere else, or exactly as it designed

Similar questions regular like - "we do the same in Informatica (Mulesoft, ODI, Pentaho ... ) and want exactly this"

It wrong ways of course.

Unfortunately - not possible to give full answer without understanding expected logic, there are many ways (including suggested by You)

for example source idea:

var1="abc"
I need var2 to be var1+" def"

could be transformed to:

baseVar1="abc" in context group

and on feature steps in Job:
var2=baseVar+" def"

[Anonymous]

Hi @rhall

Thanks for your reply. Actually no it is not problematic and Thanks @TRF and Yourself for the suggested solutions.

Why I say it is inefficient is, we are setting up parameters on the context groups and therefore would expect them to be self contained and not require some other prejobs to complete their interpretation. What we are having to work with is workarounds, which I am happy to do if there are no other alternatives but should be at-least raised for future releases.

Coming to the ask, I would want to compute my data directories according to a particular flag that helps me have different working areas on the same server for parallel testing.

For e.g. /a/b/c/uat1/data and /a/b/c/uat2/data

Now the approaches I am able to think off are (Am Open to suggestions) :

1.) Different Context Groups for each uat1/uat2 -- I am not too keen on this, because for 5-6 parameters I will have to re-do all 300 odd parameters. More headache for the developer(unless there are any sleek shortcuts to do it) and also bulkier builds!

2.) Using Prejob with tJava components -- I might have to go with this approach. But the problem I can think off is, even for parameter interpretation, all the code is not in one place. We have our contexts that create placeholders and then again another job that actually interprets values, which makes it less than desirable for me.

P.S: I have switched to a different username, but still the same user.

Thanks 

Rabi Panda

[vapukov]

for this I use only 1 context variable! 🙂

it name - context.env (I use 3 primary context group, but no limits at all)

prod - "prod"

qual - "qual"

dev - "dev"

in all other components (where it necessary ) all names concat like:

source_path == context.sourcefolder+"_"+context.env+"/data"

target_path == context.targetfolder+"_"+context.env+"/data"

and etc

same context.env used and run SubJob with dynamic context

When I need more than 3 - I just initialise context.env with individual value

Plus this variables used for load context values from csv file as part of filename

context.contextfilepath+"context_"+context.env+".csv"

and in any Job only 2 variables have value

- context.contextfilepath

- context.env

it give extremely flexibility