using environment variables ($xxx) in a transformer

[rcanaran]

Is there a way to use the Project-defined environment variables in the transformers of a parallel job?

eg $envVAR is defined as a string having a value "\home" in Administrator.

In a job, in the parameters, I add the environmnt variable to the parameter list with a value of $PROJDEF. In any other stage, i can use the variable by referencing #$envVAR#.

In the StageVariables of a transformer or by using GetEnvironment, I can use the other prarameter names just by referecning them (not wrapped in #). So I would expect to be able to use just $envVAR in the same way. As a matter of fact, i can pick the $envVAR from the list when I use a GetEnvironment or I can just pick it from the "Job Parameters" list in the target derivation column.

However, at compile time, any environment variable (or variable starting with a $ (dollar sign) causes a compiler error :

##E TFCP 000001 16:58:13(011) <transform> Error when checking composite operator: Unexpected tokens: ; [line 11,character 7].

0009: global {
0010: // Job parameter declaration
0011: string $envVAR;
0012: string jobParm;


The only suggestion we've had so far is to use a Sequence to get the project environment variable and pass it to the parallel job as the value of another parameter (without the $ in the name). Seems a bit "kuldged". Is there a better solution -- like use some sort of escape sequence when referecing the variables starting with $ ?

[chulett]

Do not include the dollar sign with GetEnvironment(), it assumes that part and just wants the actual name of the variable.

[rcanaran]

Thanks, I just tried this and when I use GetEnvironment($envVAR), the derivation LOOKS ok, but doesn't compile. I pick the variable from the JobParameter list and it automatically puts the $ there.

If I remove the $, the derivation highlights in red (invalid derivation) and still does not compile.

This is DS EE 7.5.1 on an AIX Server, Client is on Win XP.

[chulett]

You don't need the function if the environment variable is already being passed in as a job parameter. And the function is expecting a literal, so enclose it in quotes to get the red out.

[rcanaran]

If I code "envVAR" in the derivation is the value in the target is envVAR.
I don't want envVar in the target or $envVAR in the target. I need the value of $envVAR in the target -- this value in this case is "\home".

But if the DS Admin wants to change it later to have the value "\home\etc" I need this picked up.

So in the derivation column, if I code '$envVAR' will the target value be $envVAR or \home ??

[jgreve]

To use the function, what happens if you try it this way:

Code: Select all

GetEnvironment('envVAR')

Note the quote marks around the variable name envVar; that is because, as Craig said, the function wants a string.

You might want to read this as well; search is your friend.
viewtopic.php?t=127973&highlight=GetEnvironment

To really understand this, it would help to know a little about expression language components: literals, variables, parameters, functions, operators - all that fun stuff. Then this will make more sense.
John G.

If I code "envVAR" in the derivation is the value in the target is envVAR.
I don't want envVar in the target or $envVAR in the target. I need the value of $envVAR in the target -- this value in this case is "\home".

But if the DS Admin wants to change it later to have the value "\home\etc" I need this picked up.

So in the derivation column, if I code '$envVAR' will the target value be $envVAR or \home ??

[chulett]

So in the derivation column, if I code '$envVAR' will the target value be $envVAR or \home ??

You should be picking this up from the ellipsis (...) Parameter Helper rather than 'coding' it yourself as it knows what syntax to use when. You've said it's a job parameter, what do you get when you populate the derivation that way?

And if you've set the default value of that parameter in the job to $PROJDEF it will automatically pick up any changes to the value that your admin makes.

[rcanaran]

I DO pick the environment variable from the ellipses of the GetEnvironment. When I do, I can pick ANY parameter I have soecified in the Job Parameters. One of them is $envVAR. The $ is put into the ellipse as well. This does not create an invalid derivation at this time. But this DOES create the "line 11, position 7" compile error. If I remove the $, I get an invalid derivation (red highlight). If I put the name in quotes, I get an empty string in the output and not the value of $envVAR. $envVAR is set to $PROJDEF in the job parameters.

When I get back to the office, I will try putting the variable in the dervation column directly without a GetEnvironment. I will also try to populate a stage variable with the value from $envVAR and then move that value to the derivation.

I beleive I already tried some of these yesterday, but I will try again and update with my results. The solutions in the linked forums so far have not helped and I was hoping that there might be another solution, The getEnvironment or direct derivation works for all other job parameters, except ones that start with $, and so I thought there may be some sort of patch that needs to be applied.

And yes I did search the forums and tried the suggestions there, but they do not appear to work.

[chulett]

I'm a little lost as to what is going on. Been testing this myself tonight and it works fine for me in a Server job / transformer but is being cantakerous in a PX job.

I can use the job parameter directly in a Server transformer derivation ($envVAR) and it works fine. While the ellipsis will also put that value in a PX transformer derivation and (as you noted) it looks fine it will not compile, seemingly not liking the $ which you cannot remove. It only works when I do GetEnvironment('envVAR') as the derivation.

The fact that I can't simply refer to the Job Parameter but instead must use a special function to retrieve it is a little ridiculous to me. I thought from experience and reading here you only needed the function to retrieve environment variables that were not passed in as job parameters, and is something I've done in the past. For people that actually need to refer to "environment variable based job parameters" in derivations (which I haven't had a need to yet) is this the only way it works?

[rcanaran]

Ahhhh, the single quotes and correct spelling -- yes I'm a horrible typist. GetEnvironment('envVAR') WORKS. Now to move the GetEnvironment to a stagevar initial value so I only fetch the value once instead of for each row.

Resolved.

:D Thank you. Thank you. Thank you. :D