Chaining request not working when the collection is scheduled to run

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.

@mdjones 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.

Screenshot 2022-12-08 at 5.48.32 PM

As mentioned, change the variable to collection or environment as I suspect it the variable scope when its running as a scheduled job.

@mdjones
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"));

@mdjones 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.

@mdjones 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. :face_with_open_eyes_and_hand_over_mouth:

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.

1 Like

@mdjones Thanks for your time. Looking for postman team to resolve this in the future releases. :grin: