[resolved] No way to dynamically override dropdown component settings via parameters

[dan2]

Edited the title to help others in the future and marked the comment with the workaround.

Please see the screenshots below. I have a Joblet triggered by Component Ok in the main Job. The first step in the Joblet sets the parameters dynamically for a tS3Connection. The Debug log shows that the tS3Connection component is failing to read the new context. It should have updated to PROFILE_INHERIT_CREDENTIALS, but instead stays with the default even though the context was definitely updated by the tJava. How can I correct this?

 

 

 

 

I went ahead and output the full context upon failure of the tS3Connection component and can show that the context was updated, so tS3Connection seems to not be reading it. I also tried adding all variables as globals, but this did not work either.

[Anonymous]

Sorry about the delay in responding to this. I'm based in the UK and was just tinkering with some stuff late last night, hence I saw your posts. I haven't been ignoring you 🙂

You are close with your code, but your connection names are off. I should have pointed this out...my omission. The component names will always be in the format {component name}_{number of component}. The name never includes the label. So, in your example above, your components are named...

tS3Connection_1

tS3Connection_2

If you go to the "Code" tab and look at the generated code, you will see that the globalMap keys and object names you should be using are....

conn_tS3Connection_1

conn_tS3Connection_2

If you replace your keys (in quotes) and objects (without quotes), this should work. Also, you are using a not equals on the reference to Object and not the contents by using "!=". This will always be true.

Your code in your Java should look something like this.....

if(!contextStr.equals("Local")){

globalMap.put("conn_tS3Connection_1", conn_tS3Connection_2);

}

The "!" is a logical NOT operator. So that is saying "the contents of the Object is NOT equal to" with the "equals" method. Then within the IF you have the globalMap being set. What is happening here is that the key "conn_tS3Connection_1" is being assigned the conn_tS3Connection_2 Object.

[dan2]

@Richard Hall​ Because it is a joblet in a joblet, the connection for the Local environment manifests itself as conn_GetSecretsAndDefaults_1_S3Connection_1_tS3Connection_2. All subsequent components are set to use conn_GetSecretsAndDefaults_1_S3Connection_1_tS3Connection_2. The Cloud connection would create conn_GetSecretsAndDefaults_1_S3Connection_1_tS3Connection_1 when the RunIf builds that component instead. I currently get the error below because the logic only runs if in the cloud environment therefore the debugger is looking for something that isn't created in the local Code:

 

[Anonymous]

Sorry, I overlooked the Joblet part to this. I was recreating this in a single job to look at the underlying code. The easiest way for me to give you what you need is for you to send me the contents of the "Code" tab for you job. If you have any passwords, credentials, etc hardcoded in there, remove those first. I just need to see what you are working with. I'll send you a private a message on here with my email address. That way it will just remain between you me.

[dan2 · Accepted solution]

@Richard Hall​ Got it working! Thanks again for your help. The answer appears to have been to first set a dummy copy of conn_GetSecretsAndDefaults_1_S3Connection_1_tS3Connection_1 before overwriting it per the screenshot below.

On a separate topic. I had set up Context Groups with each environment and named the Dev environment as such in Talend Cloud, however, even though the names match, the job is not picking up the environment-specific context group. Any ideas regarding that would be helpful.

 

Regarding the Context Environment issue:

 

[Anonymous]

Glad you got it working. It can be a little tricky to work out exactly what is going on or what is needed when working in this way, so I'm pleased you were able to fill in what I had left out.

With regard to the environments it sounds like you are doing this correctly. I presume that when you published the job you selected the correct environment? I have just tried this to test it here and it worked for me. Unfortunately I cannot offer a Zoom session to go over this with you, but if you raise a Support case I am sure they can follow what you are doing and spot anything that is either missing or maybe a bug in the process.

[dan2]

When I publish it to Cloud it calls it a workspace instead of an environment. The instructions that I followed seem to only apply to Integration Cloud where we appear to be using Management Console with triggered Tasks. Is there another place to specifify the environment in the context of the publish. Thought the idea was that this was supposed to be dynamic..

[Anonymous]

In your screenshot above the workspaces sit underneath the environments (when publishing). Workspaces belong to users and sit underneath environments. If this isn't doing what you expect, it is probably going to be easiest to raise a Support call. As I said, they can hold a Zoom call with you and talk you through the process and see if you are experiencing anything we wouldn't expect.

[dan2]

I've gone ahead and raised support request # 00256631. I was following the instructions from here https://community.talend.com/s/article/Talend-Cloud-Contextualization-cQjcP?language=en_US. This article appears to indicate that my labelling the Context Environments to match the Cloud Evironments should cause the Cloud Job to inherit the appropriate contexts, but that does not appear to be the case. As a workaround, if I wanted to use implicit tContextLoad from a server file, which seems to be what is recommended, how do I configure that to work correctly whether in Windows (local machine) or Linux (Talend Cloud Engines)?

[Anonymous]

If the contexts appear you in your job (with all of the required environments), then publishing the job to a workspace within an environment should cause the correct context values to be automatically passed over. I have tested this at my end across 3 environments and it has been fine. However, if it isn't working for you, you could manually add those context variable values to your task after it is published. That would be the workaround that I would use to get me going. But as I say, this should work. Hopefully Support will be able to track down what is causing this not to work.

[dan2]

Support simply provided the documentation links. I took that to mean that I must be missing something obvious since they did not provide any additional insights. Nonetheless, updated all context variables to start with parameter_ and deleted then recreated my Task in Cloud. The new parameters displaying had the correct environment specificity. It is worth noting that the contextStr variable does not update as well to reflect the proper environment, so I had to create a context variable called paramter_env to reference instead. This user had the same finding: https://community.talend.com/s/feed/0D53p00007vCrJSCA0?language=en_US.