Collection Runner für die Logistik Blockchain

Mit der Integration von APIs gehen Integrationstests in Tools wie Postman oder SoapUI einher. Entwickler prüfen so schrittweise die API-Funktionsweise und stellen sicher, dass der Datenaustausch zwischen den Systemen inhaltlich und technisch korrekt erfolgt. Fehlerzustände können in Isolation provoziert und vor Nutzung der API abgefangen werden, ohne dass ein massenhafter Datenfluss den Blick auf kritische Stellen vernebelt.

Da in modernen Unternehmensumgebungen meist mehrere Systeme am Datenaustausch beteiligt sind, müssen regelmäßig auch mehrere inhaltlich zusammenhängende Abfragen durchgeführt werden. Fehlerfreiheit lässt sich dann nur im Resultat eines End-to-End Datenflusses beurteilen. Die Automatisierung dieses mehrstufigen Request-Response-Zyklus soll mithilfe von Postman Collection Runner beispielhaft anhand der Logistikplattform TradeLens beschrieben werden.

TradeLens - Die maritime Blockchain

TradeLens wurde vom weltweit größten Reeder Maersk ins Leben gerufen und basiert auf der Blockchain-Technologie von IBM. Kernaufgabe ist die sichere und vertrauenswürdige Protokollierung aller logistischen Ereignisse zwischen Urversender und Endemfänger im Rahmen der globalen Transportkette.

So können alle Teilnehmer dieser Blockchain zuverlässig und fälschungssicher Daten in ihrem eigenen Supply-Chain-Management nutzen, um ihrerseits einen effizienten Warenfluss zu gewährleisten. Tracking und Tracing wird zum Kinderspiel.

Zur API-Entwicklung gehört immer eine aussagekräftige Dokumentation, die zumeist aus einer Blog-artigen Implementierungsanleitung sowie einer technischen Beschreibung besteht; letztere wird regelmäßig mit dem Tool Swagger (heute OpenAPI) erstellt. Bei TradeLens ist beides geradezu hervorragend geschehen: Ausführlich, umfassend, verständlich, technisch ausgereizt.

Collection Runner in Postman

Ein Collection Runner ist eine Folge von Einzelabfragen, die dank Pre-request-Script und Test-Script zu einer Kette zusammengefügt werden. Eine Abfrage kann das Ergebnis einer vorhergehenden Abfrage nutzen und weiterverarbeiten, um es mit einem Erwartungswert zu vergleichen. Entspricht der tatsächliche Wert dem Erwartungswert, wird ein grünes Symbol angezeigt, anderenfalls ein rotes.

Im konkreten Beispiel haben wir uns ein TradeLens Event herausgesucht, bei dem ein Schienentransporteur die Verladung eines Containers an die Blockchain meldet. Dafür sind drei Einzelschritte nötig:

1. Autorisierung in der IBM Cloud - Erhalt von Access und Refresh Token
2. Autorisierung in TradeLens - Exchange Token vom Solution Manager
3. Übermittlung der Eventinhalte - POST-Request mit Transportdaten

OAuth 2.0 Authentifizierung

Im ersten Schritt liefert die IBM Cloud im Austausch für einen gültigen API-Key, der während des Onboarding auf TradeLens erstellt wurde, einen Access und Refresh Token. Mit diesem Token fordert man beim TradeLens Solution Manager einen Exchange Token an, mit dem letztlich das konkrete Event an die TradeLens Plattform gemeldet wird.

Die zweistufige Token-Erstellung ermöglicht, dass der Event-Publisher die Berechtigung für die Nutzung der TradeLens API in seinem Namen selbst in der IBM Cloud Benutzerverwaltung vergeben kann (Identity and Access Management, kurz IAM). Diese Trennung der Authentisierungsverantwortung von der Serviceverantwortung folgt dem modernen OAuth 2.0 Standard.

1. Authentication in der IBM Cloud IAM

Sobald der Postman Client den ersten POST-Request an das IBM Cloud IAM mit dem API Token im Message Body abgesetzt hat, soll der Access und Refresh Token aus der Response in eine Collection Variable geschrieben werden. Diese soll im darauffolgenden Schritt weiterverwendet werden.

Postman bietet für Automatisierungen die Möglichkeit, JavaScript Programme vor und nach einem Request auszuführen. Das geht über die Reiter "Pre-request Script" oder "Test Script". Postman stellt für die Interaktion zahlreiche Methoden und Eigenschaften im pm-Objekt zur Verfügung.

2. Authentication gegenüber TradeLens

Nachdem der Access und Refresh Token in einer Collection Variable gespeichert wurde, kann auf diesen im zweiten POST-Request direkt zugegriffen werden - im Body über zwei geschwungene Klammern mit dem Variablennamen: {{AccessRefreshToken}}.

Analog zum ersten Schritt speichern wir die Response wieder in einer Collection Variable für die weitere Verwendung. Diesmal handelt es sich um den Exchange Token, den TradeLens im JSON Dokument als onboarding_token bezeichnet.

3. Event mit logistischen Daten übermitteln

Nach den sicherheitstechnisch vorbereitenden Schritten kommen wir zum wesentlichen Punkt: der Übermittlung des Transportereignisses an TradeLens.

Im Gegensatz zu den vorangegangenen Schritten müssen drei Automatisierungsschritte vorgenommen werden:

1. Im Pre-request Skript den Onboarding Token als Authentication Header einfügen
2. Den Body dynamisch aus einer JSON Datei laden (Sideloading von Testdaten)
3. Die Response auf ihren Erfolg prüfen

Das "Sideloading" von Testdaten in Postman ist ein willkommenes Feature, um die Erstellung von Automatisierungen durch einen Testautomatisierer von der Verwendung durch Fachbereichsmitarbeiter zu trennen.

Fazit

Postman stellt ein wunderbares Tool zum Verständnis von APIs und zu deren schrittweisen Implementierung und Testautomatisierung dar. Hat man diese erste Hürde genommen, so steht der Automatisierung und Integration in die Produktionssysteme nichts mehr im Weg.

Für die produktive Automatisierung kommen dann mächtigere Tools wie die cloudbasierte Low-Code Integrations- und Automatisierungsplattform Workato zum Einsatz, die sich auch hervorragend für die Testautomatisierung von APIs eignet.