Do Automator variable persist between executions of a workflow?
If a variable is set during the execution of a workflow, can I get the last value assigned to a variable, once the workflow is executed again?
Automator variables are not persistent.
I created a test service from a workflow that outputs the content of a variable, and then sets the variable content to the text selected in the host application; the invocation of the service always returned an error about the variable, which means the variable content was not persistent (differently, the error would have been reported only the first time).
I don't use automator so I'm not sure. However, I know that if you're using applescript then you can have persistent variables by defining them as a property. So instead of using (set myVar to "something") you'd use (property myVar : "something"). Maybe you can do something like that in your automator code. Other than applescript code, you'd probably have to manually write your values to a file and read them back to restore them.
Related
Currently I read properties file by defining a global element like;
> <configuration-properties doc:name="Local Configuration Properties"
> doc:id="899a4f41-f036-4262-8cf2-3b0062dbd740"
> file="config\local_app.properties" />
But this is not enough for me
when try to deal different clients dynamically.
Usecase
I need to pick right configuration file when request comes in. That is, for different clients I have different properties file.( their credentials and all different). When request is received from listener, i'll check with clientid header and based on that value, i'll pick right configuration file. My properties files are added to different location.(Doing deployment through openshift.) Not within mule app. So, we don't need to redeploy the application each time, when our application supports new client.
So, in this case, how to define ? and how to pick right properties file?
eg:
clientid =google, i have properties file defined for google-app.properties.
clientid=yahoo, i have properties file defined for yahoo-app.properties.
clientid=? I'll add properties file ?-app.properties later
Properties files are read deployment time. That means that if you change the values, you to redeploy the application to read the new ones. System properties need a restart of the Mule Runtime instance to be set. And Runtime Manager properties need a restart of the application. In any case the application will restart. Properties can not be used as you want.
There is no way to use configuration properties dynamically like that. What you could do is to create a module using Mule SDK that read properties files and returns the resulting set of properties, so you can assign the result to a variable, and use the values as variables. You will need to find a way to update the values. Maybe set a flow with a scheduler to read the values with a fixed frequency.
I usually set properties within the run in Jmeter. How can remove all these properties after the run without knowing their names?
I usually use props.remove() to remove only one specific property, but how can remove all?
Properties lifetime is limited by the JVM lifetime so it's enough to restart JMeter to remove any custom properties.
Use props.clear() function in any of the JSR223 Test Elements (the syntax assumes Groovy language)
Demo:
However if you want to keep original JMeter properties for whatever reason:
You can store them into and interim object (or to the file) somewhere in setUp Thread Group and restore it in the tearDown Thread Group
I need to access the location of the change log file so that I can get the URL of other files that are in the same directory from a custom task.
The Change interface has a setter for the ChangeSet object which can be used to get the change log file, but the CustomChangeTask interface does not have this method.
From my understanding I need to use CustomChangeTask as my task does not generate SQL.
This is my question. I have decided to implement AbstractChange. It works just fine doing that and returning an empty array of SqlStatements.
This doesn't seem like a situation that is unique to me, but I haven't been able to find an answer anywhere.
I am attempting to build Jmeter scripts that can be executed both in the GUI and command line. The command line is going to need values to pass into the test cases, but the same test cases need to be executed via the GUI as well. I initially had separate scripts for GUI and command line, but it seemed redundant to have the same test cases duplicated with just a couple parameters changed.
For example, the GUI test case has the Web Server name set to:
<!-- ${ENV} set in User Defined Variables -->
<stringProp name="HTTPSampler.domain">${ENV}</stringProp>
The command line test case uses the following for parameters:
<!-- Define via command line w/ -JCMDDEV -->
<stringProp name="HTTPSampler.domain">${__P(CMDENV)}</stringProp>
Both work for their served purpose, but I want to combine the tests to be easier maintained and to have the ability to run them via GUI or command line.
I got passed one hurdle, which was combining the GUI Variables to be used as well as Properties for the command line by setting the User Defined Variable ${ENV} as the following:
Name Value
----- --------
ENV ${__P(ENV,dev.address.com)}
I am now able to run the same test case via GUI and command line (defining a new environment with -JENV)
I'm not sure if I'm overthinking this, but I want to be able to add a variable to the property default in order to avoid typos, etc while handing it off to others. I tried a few variations that didn't seem to work:
Name Value
----- --------
ENV ${__P(ENV,${__V(DEV)})}
DEV dev.address.com
This gave me the following Request:
POST http://DEV/servlet
Instead of:
POST http://dev.address.com/servlet
I also tried using:
${__P(ENV,${DEV})}
${__property(ENV,,${__V(DEV)})}
${__property(ENV,,${DEV})}
I was looking into Jmeter nested variables, but it didn't provide any working solutions.
So to my main question, am I able to use variables as the property defaults. If so, how would I achieve that?
I found a way around this. It's not exactly how I wanted it, but it could work for right now.
I really wanted to keep everything in one place where people had to make edits, but I was able to get the User Defined Variables to work by adding the ${__P(ENV,${DEV})} to the HTTP Request Defaults Web Server Name instead of pre-defining it as a variable.
Now there are two Config Elements that potentially need to be edited with GUI execution, but I think it should work out better in the long run.
Yes, seems the author is right - looks like nested variable can't be evaluated in JMeter from the same variables scope.
I've created a different "User Defined Variables" set, added there "defaultValue" - and after that this option works:
${__P(myProperty, ${defaultValue})}
As described in http://blog.ej-technologies.com/2012/06/migrating-to-install4j-51.html
The variable writing to context should be serialisable and it's because the elevated action need it. The question is that, say, we have an object holding some variable for us, and is saved in the context
{var1:1, var2:true}
When we update var1, do we need to always set the object back to context? or is it safe to just update the object directly and get it later in other script.
So the question is, does the elevated helper
A) retrieve variables each time the variable is accessed
or
B) is the variable transmitted to elevated helper when it is set via context.setVariable()
The answer is B. Installer variables only live in the unelevated process. Each time a variable value is needed in the elevated helper, it requests it from the unelevated process. The variable value is never cached in the elevated helper.