Collection Runner for the Logistics Blockchain
API integration goes hand in hand with integration testing. Automating multi-stage request-response cycles with the Postman Collection Runner, using TradeLens as an example.
API integration is always accompanied by integration tests in tools like Postman or SoapUI. Developers use these to check API functionality step-by-step, ensuring that the data exchange between systems is correct in terms of both content and technical implementation. Error states can be triggered in isolation and intercepted before the API is used, without a massive flow of data obscuring the view of critical points.
Since modern corporate environments usually involve multiple systems in data exchange, it is often necessary to perform several interrelated queries. Accuracy can then only be assessed based on the result of an end-to-end data flow. The automation of this multi-stage request-response cycle will be described using the Postman Collection Runner, with the logistics platform TradeLens as an example.
TradeLens - The Maritime Blockchain
TradeLens was initiated by the world's largest shipping company, Maersk, and is based on IBM's blockchain technology. Its core task is the secure and trustworthy logging of all logistics events between the original shipper and the final recipient within the global transport chain.
This allows all participants in this blockchain to reliably and tamper-proof use data in their own supply chain management to ensure an efficient flow of goods. Tracking and tracing becomes a breeze.
API development always requires meaningful documentation, which usually consists of a blog-like implementation guide and a technical description; the latter is regularly created using the tool Swagger (now OpenAPI). In the case of TradeLens, both have been done excellently: detailed, comprehensive, understandable, and technically sophisticated.
Collection Runner in Postman
A Collection Runner is a sequence of individual queries that are chained together using pre-request scripts and test scripts. A query can use and process the result of a previous query to compare it with an expected value. If the actual value matches the expected value, a green icon is displayed; otherwise, a red one appears.
In this specific example, we have selected a TradeLens event where a rail carrier reports the loading of a container to the blockchain. Three individual steps are required for this:
- Authorization in the IBM Cloud - Receiving an Access and Refresh Token
- Authorization in TradeLens - Exchanging the token from the Solution Manager
- Submission of event content - POST request with transport data
OAuth 2.0 Authentication
In the first step, the IBM Cloud provides an Access and Refresh Token in exchange for a valid API key created during onboarding on TradeLens. With this token, you request an Exchange Token from the TradeLens Solution Manager, which is ultimately used to report the specific event to the TradeLens platform.
The two-stage token creation process allows the event publisher to assign the authorization for using the TradeLens API on their own behalf within the IBM Cloud user management (Identity and Access Management, or IAM). This separation of authentication responsibility from service responsibility follows the modern OAuth 2.0 standard.
1. Authentication in the IBM Cloud IAM
As soon as the Postman client has sent the first POST request to the IBM Cloud IAM with the API token in the message body, the Access and Refresh Token from the response should be written into a collection variable. This will be used in the subsequent step.
For automation, Postman offers the ability to execute JavaScript programs before and after a request. This is done via the "Pre-request Script" or "Test Script" tabs. Postman provides numerous methods and properties in the pm object for this interaction.
2. Authentication with TradeLens
Once the Access and Refresh Token has been saved in a collection variable, it can be accessed directly in the second POST request—in the body using two curly braces with the variable name: {{AccessRefreshToken}}.
Analogous to the first step, we save the response again in a collection variable for further use. This time, it is the Exchange Token, which TradeLens refers to as the onboarding_token in the JSON document.
3. Submitting an event with logistics data
After the security-related preparatory steps, we come to the essential point: submitting the transport event to TradeLens.
Unlike the previous steps, three automation steps must be performed:
- Insert the Onboarding Token as an Authentication Header in the Pre-request script
- Load the body dynamically from a JSON file (sideloading test data)
- Check the response for success
The "sideloading" of test data in Postman is a welcome feature for separating the creation of automations by a test automation engineer from the usage by business department staff.
Conclusion
Postman is a wonderful tool for understanding APIs and for their step-by-step implementation and test automation. Once this first hurdle has been cleared, nothing stands in the way of automation and integration into production systems.
For productive automation, more powerful tools are then used, such as the cloud-based low-code integration and automation platform Workato, which is also excellently suited for API test automation.
