Hello,
I have a relatively straight-forward question - is it possible to overwrite/ammend an action parameter within the same action? Ex.
parameter “var”=“A”
…
parameter “var”=“B” OR something like parameter “var”="{parameter “var” & “; B”}"
I am getting errors when I try any of the above, so just wanted to see if that is acceptable and if it is not, is there some kind of action variable that I can use instead?
Thank you,
ageorgiev
I get confused about this as well.
This should work:
parameter "varA"="A"
parameter "varB"="{parameter "varA"}; B"
Are you only testing this in the Fixlet Debugger? This might be one of those cases where it doesn’t work in the Fixlet Debugger, but it does work through the console. (I’m not certain)
Testing it through running a task with the code against a machine, not through Fixlet Debugger.
Yes, that works as long as you haven’t defined “varB” somewhere prior to that. It seems that once you set up a parameter it doesn’t let you overwrite it any more which is what I was hoping to use it for.
Yes you should treat it as a const variable in C terms. Once set you can’t alter it.
The main reason for this is these are used in different time periods during action evaluation. These parameters are set during the download check phase so they can’t be dependent on conditional flows etc.
That’s what I was thinking, thanks for confirming the behaviour.
Will try to use a dummy client setting to store the information instead and see if that works.
If you are generating the information using relevance anyway… then you can just keep generating it with relevance substitution instead of storing it into a parameter.
You could also write the information to a file and read it back if you wanted.
Can you explain your use case in general terms?
Yes, I was trying to write a single task to automate the dynamic assignment of relay affiliation seek list (_BESClient_Register_Affiliation_SeekList) dependent on different criterias. Something like:
If {criteria 1}
parameter “var”="{parameter “var”}; ListA"
endif
If {criteria 2}
parameter “var”="{parameter “var”}; ListB"
endif
If {criteria 3}
parameter “var”="{parameter “var”}; ListC"
endif
…
setting “_BESClient_Register_Affiliation_SeekList”="{parameter “var”}" …
We have very complex relay affiliation groups, so a lot of criterias will have to be added and appending a variable/paramer made sense but since that’s not how they are working a client setting would probably be best. Reading/writing to a file would work but there will be too much overhead to do for simple append of an one line string.
You could write it in such a way that it appends onto the existing seeklist directly as each criteria is satisfied. The biggest difficulty would be the order in which this happens to have the correct order in the seeklist that you actually want to be followed.
If I were to build a seek list in this way, then I would actually have a separate task for each entry that should be added to the seek list with the relevance in place that it is only relevant on machines that should have that entry and don’t already have it and have all higher level assignments already. Then the task would append to the front of the existing seek list it’s entry, then more specific ones would become relevant and do the same. This would dynamically build the seek list.
We also have some complicated seek lists. We currently map a unit to a seek list and have a large relevance substitution in a static task that we update periodically to make this happen.
That’s exactly what I was trying to avoid. Since the criteria would’ve been in very specific order then at all times those orders will be the way we wanted them. The benefit of a separate variable that gradually builds the seeklist in the exact order is that you can actually compare the list to the current seeklist of the client without having to blindly overwrite it.
For example, you have a specific order for ClientA of “ListA;ListB;ListC”. A MO as a part of troubleshooting efforts (let’s say there is too big of a delay in deployments; not reporing in; etc) modifis the seeklist by adding another entry and it’s now “ListD;ListA;ListB;ListC” - you can easily write a statement at then end that since parameter “var” is contained within the seeklist already (in the same exact order as it’s built), then not to overwrite it. Just gives you a bit more error-checking options.
What I was suggesting would not involve blindly over writing the seeklist, only appending it, but a single task/fixlet to append a single entry.
Relevance 1:
not exists values whose(it contains "GroupA;") of settings whose(name of it = "_BESClient_Register_Affiliation_SeekList") of client
Relevance 2:
exists values whose(it contains "RequiredHigherLevelGroupToBeAddedBeforeGroupA;") of settings whose(name of it = "_BESClient_Register_Affiliation_SeekList") of client
Relevance 3:
( whatever relevance would determine GroupA should be added )
ActionScript:
setting "_BESClient_Register_Affiliation_SeekList"="GroupA;{ (it as string as trimmed string) of value of settings whose(name of it = "_BESClient_Register_Affiliation_SeekList") of client }"
Then just copy and tweak the above task for every dynamically allocated group.
I personally prefer that fixlets/tasks are broken down into their smallest possible pieces, which could be grouped together with a baseline, or just with simultaneous individual actions that have proper relevance to cause them to sequence in the right order automatically. This makes the success criteria easier to create and have it properly evaluate if the change has been properly made.
Quick tip for this relevance. Instead of saying setting whose (name it = “x”), it’s much more efficient to say setting “x”.
Example:
q: not exists values whose(it contains “GroupA;”) of settings whose(name of it = “_BESClient_Register_Affiliation_SeekList”) of client
A: True
T: 4.908 ms
I: singular boolean
q: not exists values whose(it contains “GroupA;”) of setting “_BESClient_Register_Affiliation_SeekList” of client
A: True
T: 0.290 ms
I: singular Boolean
Notice the evaluation time difference.
While your suggestion is correct, be careful of the times that are listed in QnA or the Fixlet debugger as the first execution has some load time to it. When I ran the query the 2nd time the caches inside the client were hit so the time is shorter.
And just remember to multiply the times listed by 50 for the standard settings of the client 
Be sure to use the plural “settings” in case the named setting does not exist; that would throw an evaluation error with the singular “setting”.
And when comparing evaluation times, the first evaluation often takes longer, as the second evaluation may use cached results. Run the evaluation a few times to be sure the first query doesn’t suffer an “unfair disadvantage”