Setting the output of one request as input to another.
I have a request which generates the token. I am using the token present in the response to set the global variable.
It works fine and sets the global variable when I run the collection manually. But the problem is when I schedule the collection for an example every hour. I see that the collection runs but the global variable would not be set.
This is weird. Please help
Is my question wrong?? Or is it not understandable??
How are you scheduling the collection? Through the monitor? Newman?
Console.log the variables to see if this helps determine why they are not being set.
This includes ensuring that the token is returning correct before you set the variable.
When you set the variable, you should add a line that retrieves it immediately with a test to ensure its not undefined. (You can remove all of this once you have it working).
However, why have you set this is a global variable? This means its available to all collections which is probably not needed. If you are scheduling the collection, Iām not even sure global variables will be available to you.
It should be a collection variable. Against the collection you are trying to schedule (or an environment).
Iād change the variables to the collection scope in the first instance, and see if that makes any differences.
Otherwise, the troubleshooting steps would be via better use of console logs.
@michaelderekjones I am just clicking on run collection and we get 3 options, run manually, schedule runs and automate runs via cli. I am selecting the 2nd one Schedule runs.
As mentioned, change the variable to collection or environment as I suspect it the variable scope when its running as a scheduled job.
@michaelderekjones
I set the variable as environment variable and checked it. The variable gets updated if I run manually but when I schedule it, the request would be successful but the variable will not be set.
The same is happening when I set as collection variable.
I did a console.log and the token is printed in the console.
So the token is being retrieved, but the collection\environment variables is not being set?
Have you tried console logging the retrieval of the variable (just after you set it). Or wrap it in a test to check if its been set.
console.log(pm.collectionVariables.get("variableName"));
// or
pm.test("Variable exists", () => {
pm.expect(pm.collectionVariables.get("variableName")).to.be.an("string");
});
I canāt think of any reason why you canāt retrieve the variables.
How about if you run the āscheduleā manually? Is this working?
Is it possible to share the code you have produced?
@mdjones Yes, if I run it manually it is working.
Below is the code:
const bodyData = pm.response.json();
token_value = bodyData.data.token.access_token
pm.globals.set(āBearerTokenā,token_value);
pm.collectionVariables.set(āAutoTokenā, token_value);
pm.environment.set(āEnvTokenā, token_value);
console.log(token_value);
console log each of these as well.
console.log(pm.global.get("BearerToken"));
console.log(pm.collectionVariables.get("AutoToken"));
console.log(pm.environment.get("EnvToken"));
@michaelderekjones I got the below error:
TypeError:ā Cannot read property āgetā of undefined
{
āstatuscodeā: ā200 OKā,
āstatusā: āSUCCESSā,
āmethodā: āPOSTā,
ātimestampā: ā2022-12-08 14:37:27ā,
āclientNameā: āAbcā,
āurlā: ā/api/abc/xyz/q1/oauth2/tokenā,
āmessageCodeā: āABCā,
ādataā: {
ātokenā: {
āaccess_tokenā: āABCXYZABCXYZā,
āexpires_inā: 86400,
ātoken_typeā: āBearerā
}
}
}
My response would look similar to the above JSON
Iāve quickly setup a collection and tested this, and the collection variables are persisting for the scheduled run.
They donāt seem to persist outside of the run, so you canāt view them at the collection level using the GUI, but they do as far as I can tell persist within the requests in the collection during the run and can be viewed in the run history.
Where are you seeing the error messages. In the run history like the following screenshot?
#2 Create Test Data is the name of my first request which is a POST to Postman echo to generate some test data.
The tests tab of that has the following to set a collection variable called ānameā with a value from the response.
pm.collectionVariables.set("name", pm.response.json().data.contacts[0].name);
console.log("Create Test Data - Collection Variable: Name=" + pm.collectionVariables.get("name"))
#5 R1 is a simple GET request also using Postman Echo with the collectionVariable parameterised in the request.
(https://postman-echo.com/post?name={{name})
Which can be seen in action under #6. Itās using the name from the previous request.
That request is also console logging the collection variable in its test tab.
console.log("R1 - Collection Variable: Name=" + pm.collectionVariables.get("name"))
The screenshot is showing that the variables are being populated.
Therefore this does seem to work, so I canāt ascertain why you are getting undefined. (but please confirm that this is within the run history).
Sorry, its globals, not global.
@michaelderekjones Now I see that the collection variable is updated with the token_value in the console. This token_value goes as an authorization token to another collection. Over there I see that the collection variable is not set to the latest one.
To another collection? You never mentioned that before. 
I donāt think that will work as it appears that the variables only persist within the collection run.
Makes more sense now in why you had this as a global variables to begin with.
A bit of testing advice here. A test should not rely on another test to run.
Within Postman, think of the Collection as the Test Suite. The folders as the Test Case, and the requests as the test steps. I would recommend using that logic to break down your test cases.
Re-usability is a feature that is still lacking (to create steps that can be re-used). You can create functions within the same collection to a certain extent, but not in a way that you get in most other test tools. Fingers crossed for a future enhancement.
@michaelderekjones Thanks for your time. Looking for postman team to resolve this in the future releases. 