_edited_edited.png)
In the second part of the blog, we will be deep diving into requests execution in the collection in multiple ways without manual intervention. But let’s start with some basics first.
The sequence of requests to be executed in the collection could be specified both programmatically and manually. Let’s look how this could be achieved programmatically from scripts first.
pm.sendRequest()
Goal
The goal is to find out total number of users before and after the POST call and ensuring the total count has increased by 1.
Code explanation
Line 36-59: In the example above, after all the response test validation is done for POST request, the GET call for all Users is invoked again using pm.sendRequest() method. Any GET/POST/PUT/DEL request can be created the way it has been built in lines 39-43. Once the response is successfully received in line 49, total users value again was retrieved using array.length after which the last test validation of “Total Users increased by 1” was executed.
This whole block of code from Line 36-59 essentially achieves the same flow of execution if the requests were placed sequentially in the collection below. But the below approach introduces the risk of flow interruption (and thereby, “Total Users increased by 1” test execution) if somehow the second or third “GET All Users” accidentally misplaced or dragged anywhere else.
pm.execution.setNextRequest ()
Another way to achieve request chaining is by the use of pm.execution.setNextRequest () method. All we have to do is pass the request name “GET All Users” or request ID as input parameter. But issues with this method are:
1) pm.execution.setNextRequest () doesn’t return a response. As such, in this particular example, we won’t be able to execute the test “Total Users increased by 1”
2) Secondly, pm.execution.setNextRequest () is ignored when the request is executed on its own by clicking on “Send” button. This method only gets activated during Collection run
However, pm.execution.setNextRequest () is very powerful and we’ll see how it plays a pivotal part of request chaining at collection run level.
As seen in part 1, the collection is ready for execution. The sequence of requests is same as it was in collection folder. The objective is to execute one POST call, so the rest of the subsequent calls work on that one created user. Hence, only one DELETE call can be executed. As a result, two requests have been unselected – one POST and one DELETE call.
But the problem is next time, when we want a different sequence of APIs in the collection to be executed, the requests have to be manually selected/deselected again . This manual repetition could be automated by mentioning all different pathways in a json file in the following manner:
As seen in the data set, in the first iteration, POST call for both mandatory and optional fields and DELETE call by user’s first name have been chosen and for second iteration, the other set has been listed. This file needs to be read programmatically and has been written in post-res Script at collection level for this example.
Select the json file from “Data” section and click Run User Collection
One behavior to be noted is that the very first GET call “GET All Users” keeps getting executed in both iterations despite not being mentioned in the json file for routes. This happens again because of “Execution order of scripts”:
Let’s observe the flow:
1) User Collection has no folder and nothing has been written in pre-req script for Collection or any of the Requests. So the control will jump to Request execution for the first available request, which is the “GET All Users”. The way everything has been designed thus far, “GET All Users” will always be executed as the first request for every iteration
2) Once Response is received, control will now control will go to post-response script at Collection level where we have the script for reading json file for routes. Here it gets the first request name to be executed next from json file’s first data set (i.e. "Mandatory and Optional Fields")
3) Then it goes to the current Request’s (i.e. “GET All Users”) post-response script and executes any test over there
4) Finally control goes to "Mandatory and Optional Fields" POST call (request name picked up from step 2) and executes it as second call for first iteration and the whole cycle is repeated for second iteration as well
One may intuitively think of writing the script for reading next request name in Pre-request script at Collection level. This could be done but the result will still be the same. This is because pm.execution.setNextRequest () is always executed at the end of current request execution. Hence, the location of those codes won’t matter at collection level.
Hope this blog was resourceful. Any feedback is much appreciated.
Git:
Reference:
Postman Learning Center, Use scripts to add logic and tests to Postman requests in Postman. Retrieved from
This webpage discusses the execution order of scripts
Advanced workflows (request chaining) with Postman. Retrieved from
This YouTube video advanced workflows using request chaining