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.
Related
This is about an API handling the validation during saving an object. Which means that the front-end client sends a request to the API to a specific end point, then on the back-end the API creates a new object if the right conditions are meet.
Right now the regular method that we use is that the models has a ruleset for each fields and then the validation is invoked when the save function is invoked, but technically the validation is done right before the object is saved into the database.
Then during today's code review I came across a solution which I wasn't sure if it's a good practice or not. And it was about that the front-end must send a specific parameter to the API every time. This is because other APIs are using our API as well, and we needed to know if the request was sent as and API request or a browser request. If this parameter is present then we want to execute an extra validation function on a specific field.
(1)If I would have to implement it, then I would check the incoming parameter in the service handler or in the controller level, and if I got one, I would invoke the validation right away, and if it fails I would throw an error.
(2)The implementation I saw however adds an extra variable to the model, and sets the model variable when there is an incoming parameter, then validates only when the save function is invoked on the object(which first validates the ruleset defined on the object fields, then saves the object into the database)
So my problem with (2) is that the object now grown bigger with an extra variable that is only related to a specific event. So I would say it's better to implement (1). But (2) also has an advantage, and that is when you create the object on different end point by parsing the parameters, then the validation will work there as well, even if the developer forget to update the code there.
Now this may seems like a silly question because, why would I care about just 1 extra variable, but this is like a bedrock of something good or bad. So if I say this is ok, then from now on the models will start growing with extra variables that are only related to specific events, which I think should be handled on the controller/service handler level. On the other hand the code would be more reliable if it's not the developer who should remember all the 6712537 functionalities and keep them in mind when makes some changes somewhere. Let's say all the devs will get heart attack tomorrow from the excitement of an amazing discovery, and a new developer has to work on the project while he doesn't know about these small details, and then he has to change something on the code that is related to this functionality - so that new feature should be supported by this old one as well.
So my question is if is there any good practice on this, and what do you think what would be the best approach?
So I spent some time on thinking on the solution, and I think the best is to have an array of acceptable trigger variables in the model class. Then when the parameters are passed to the model on the controller level, then the loader function can be modified that it takes the trigger variables from the parameters and save it in the model's associative array variable that stores the trigger variables.
By default this array is empty, and it doesn't matter how much new variables are needed to be created, it will only contain the necessary ones when those are used.
Then of course the loader function needs to be modified in a way that it can filter out the non trigger variables as well as it is done for the regular fields, and there can be even a rule set of validation on the trigger variables if necessary.
So this solves the problem with overgrowing the object with unnecessary variables and the centralized validation part, because now the validation can be always done in the model instead of the controller.
And since the loader function is modified to store the trigger variables in the model's trigger variables array variable, the developer never has to remember that this functionality was created. Which is good, because in the future when he creates a new related function or end point that should handle object creation, he will not miss it to validate it against the old functionality, because the the loader function that he modified in the past like this will handle it for him.
It needs to be noted tho, that since the loader function doesn't differentiate between the parameters, and where to load them other then checking the names of the parameters with the filter functions, these parameter names should be identical from each other, otherwise a buggy functionality can be created accidentally. Like if you forget that a model attribute with the same name was used, then you can accidentally trigger an event that was programmed to be triggered if the trigger variable with the same name is present. However this can be solved by prefixing the trigger variables for example.
I want to change the ASPNETCORE_ENVIRONMENT value from code while initializing the application. This is done with
Environment.SetEnvironmentVariable("ASPNETCORE_ENVIRONMENT", [newValue]);
and happens very early on startup of the application, prior to any calls to Use[XY].
If I check the value with Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT") throughout the lifetime of the application, it returns the desired value.
However, the Environment-Tag helper always uses the initial value which was set at the application's very startup (the old value).
While googling, I found a lot of posts on how to change the "ASPNETCORE_ENVIRONMENT" value from outside of the application, but none on how it is done from within the application.
The background of this question is, that we have the information about which stage the application runs, saved within the database and we want to use this information.
Update
It seems, that I have found the solution, will post it, if it is reliable.
Asp.net Core initializes at the application’s start the IWebHostEnvironment implementing instance and registers it as a singleton. This interface has a read/write property EnvironmentName, which is then used throughout the application’s lifetime as the “environment” value.
Hence the solution was:
var webHostEnvironment = [ServiceCollection].GetRequiredService<IWebHostEnvironment>();
webHostEnvironment.EnvironmentName=[my value];
Important is surely, that the assignment is as early as possible, so that in the Configure-method of the application, it is already set to its target value.
I tested some scenarios and up to now, I haven’t found any problems.
I would like to run one request only once, and get an authorization token from its response using Json extractor and then use that token as header in another request that runs under the same thread group.
I tried to use "setup Thread Group", but the variable value was not available to the main thread group.
So, I used "If Controller" under the same thread group, with below condition:
${__groovy(ctx.getThreadNum() == 0 && vars.getIteration() == 1,)}
This is making the specific request to be executed only once.
However, variable value is available only for one thread for the subsequent requests, but not for all the threads. Below is the picture of results tree:
May I know how to access the variable value set in first request for all the threads instead of just one thread?
As per JMeter Documentation:
Properties are not the same as variables. Variables are local to a thread; properties are common to all threads
So if you want to use a single token for all threads (virtual users) you need to convert it into a JMeter Property first like:
Under the If Controller use __setProperty() function to convert your variable into a property
In your GET request use __P() function to read the property value
Another way of sharing data between threads (even if they're in different thread groups) is using Inter-Thread Communication Plugin
You are not allowed to use the variable created in one thread in other threads this is how JMeter scoping for variables extracted works.
You already near to solution, providing steps so any one can approach problem like this:-
Use If Controller to make sure only once request being made to get Authorization token
Extract the token using post-processor
Save token in the property using post-processor so that same token can get used in multiple threads
Use newly created property instead of a variable in subsequent requests by referring property function instead of variable
You can use one JSR223 post-processor like below to create a property from the variable:
Please note that if you are mimicking multiple users using thread group, ideally you should create different auth token for different users.
P.S.: Balzemeter have an article which uses the BeanShell to demonstrate how to solve this problem
I was asked by the IT Department to write an ABAP program that switches the profile parameter login/server_logon_restriction from 0 to 1 and back automatically triggered (time etc) on all of our SAP servers.
I am not very familiar in the SAP environment yet and until now I managed to get the wanted parameter by using:
RSAN_SYSTEM_PARAMETERS_GET
and
RSAN_SYSTEM_PARAMETERS_READ
But I cannot find anything to change and save them dynamically. Is this even possible?
Cheers, Nils
login/server_logon_restriction parameter dynamic so you can change it via cl_spfl_profile_parameter=>change_value class method.
You can configure background job for automatically trigger it in t-code SM36.
The method don't save the given value to profile file, so the parameter turn back profile value after system restart.
Current logged-in users can continue to use system. May be you can want to inform them with TH_POPUP function then kick from the system.
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.