My first post here, so please don’t be upset when things are not clear or wrongly formatted
Description:
I am not able to set and get a variable in requests when using the Collection Runner.
Those requests are outside the currently running Collection Runner.
The Collection Runner only uses local/temporary variables and is only capable of saving variables, after the Collection Runner has finished (‘Keep variable values’), not during.
Background:
I run a Collection that retrieves an access_token and a refresh_token, and it should keep the REST session running.
Every 60 minutes it needs to get a new access_token (using the refresh_token), that needs to be used by other REST calls (Authorization - Token: {{access_token}}) .
The other REST calls are in other Collections (run as single requests).
I ran extensive tests in order to find out that
pm.variables.set()
pm.environment.set()
pm.globals.set()
and their ‘get’ counterparts have no influence whatsoever on the environment Variables and Globals whilst the Collection Runner is active.
It would be nice if this could be fixed / enhanced or perhaps a workaround exists to use dynamic variables in a Collection Runner environment.
Postman for Windows
Version 7.3.6
win32 10.0.16299 / x64
Welcome to the Postman community! I think your question was well formulated.
If I understand you correctly, you are running multiple instances of the collection runner at the same time (one the for keeping the token valid, and others running actual collections).
If you ask me, you are kind of stretching the capabilities of the runner. I would rather go in the direction of using newman and a CI server to automate this.
If this the above does not work for you, consider putting everything in a single collection and handling token renewal from there. I am not sure what is the advantage of having two collections.
Actually I am running 1 instance of the collection runner. This runner gets the access token and refreshes it regularly. Sort of a background job to keep the session open/valid. Then I have several other collections where I run requests as single requests or as a collection (mostly as a single request). These requests need the access token in order to work. At this moment the collection runner for the session cannot pass the refreshed access token to the other requests by means of setting it as a variable. As a result I get 401 Unauthorized when the token is expired and the game is over.
Till now I have used this method for similar testing, but here I only need to refresh the session and do not need a new token in my authorization string.
Overall, it means that I only can test for the period the first token is valid and when I get 401 I need to get a new token manually or refresh it in time manually. Perhaps newman is a solution, but I like using Postman because then I can alter the requests on-the-fly and save the ones I would like to use later.
Newman is more for when the requests have been build and tested successfully.
I was a bit surprised to notice that variables in runners cannot be saved whilst the runner is active, probably due to the sand-boxed manner of operating, Being able to save a variable really dynamical, during run-time, would help me a lot here.
Hopefully it is a bit more clear now.
@evroom Just jumping in here to add to what @vdespa touched on. I think this is a bit of a different scenario that what we have typically seen other users do with the Collection runner.
I think there are various approaches here but adding in an idea of my own.
You could potentially add these refresh call(s) to the collection and using a combination of simple conditional checks and the Postman Sandbox, make a call to get a new token when needed.
To give a bit of an example, in the Test tab you could add an if statement to check the response code that comes back. If its a 401, then you could make a call to get a new token via pm.sendRequest More info here. If its anything else, keep executing as expected.
Hopefully this helps. Let us know how you make out
@tmccann
The pm.sendRequest function is interesting, but unfortunateley will not help for 100% in my case.
When 401 is returned, it is already too late; the server will have terminated the session and will send a 401 for the refresh request.
In most REST API interfaces, you can just send refresh using the valid API key, which resets the expiration timer. In this particular case, the REST API is using this access_token & refresh_token method, expecting new requests to use the new access_token.
I will however use your suggestion to send a refresh in every manual request, just to minimise the risk of getting a 401 whilst testing / developping. The real interface is written in PHP anyhow and there I do not have this issue as I can save the new token at run-time.
Thanks for taking time to think of a solution.
