Wie man die maritime Blockchain Tradelens binnen Stunden integriert

Der weltweit größte Reeder Maersk hat mit seiner IT-Tochter GTD Solution sowie dem Technologiegiganten IBM eine auf Blockchain basierende maritime Track & Trace Plattform ins Leben gerufen, an der alle Partner teilnehmen können — TradeLens. TradeLens soll die Effizienz in Lieferketten der Containerlogistik steigern, indem Interaktionen mit mehreren Parteien automatisiert und digitalisiert werden. 

Dazu hat TradeLens mehr als 100 Events definiert, an denen im Verlauf der globalen Supply Chain Daten und Dokumente ausgetauscht werden, vom geplanten Verschiffungszeitpunkt, über die Bill of Lading bis hin zur Verzollung und Versicherungspolizzen. Diese Events werden von den Teilnehmern der Blockchain laufend befüllt und neue Informationen automatisch konsumiert. Ein stetiges Geben und Nehmen.

Quelle:

TradeLens folgt einem rollenbasierten Berechtigungskonzept, in das jeder teilnehmende Partner während des Onboarding auf die Plattform eingeordnet wird. So gibt es Ocean Carriers, Rail oder Truck Operator, die in die Gruppe der Transport Service Provider fallen, Zoll und Zolldienstleister, Depots und Terminals sowie zahlreiche weitere Teilnehmer des Logistikgeschehens wie Banken und Versicherungen. Jeder Rolle sind Berechtigungen auf die einzelnen Events zugewiesen. So wird die Containerbe- und -entladung regelmäßig von Reedern oder 3PLs gemeldet, während Schienentransportunternehmen die Verladung im Umschlagbahnhof melden und Depotbetreiber Gate-in/-out Meldungen liefern. Alle diese Zuordnungen sind im sogenannten Data Sharing Specification Sheet zusammengefasst. Es dient dem Überblick während des Onboarding, welche Informationen erwartet und welche Informationen konsumiert werden können.

Quelle:

Besteht Klarheit über die relevanten Events, so wird eine sogenannte Organisation für den teilnehmenden Partner in TradeLens sowie ein Account in der IBM Bluemix IAM Cloud angelegt (Identity Access Management); dies geschieht während des Onboarding, welches von GTD Solution vorgenommen wird. Danach hat man Zugriff auf TradeLens über das Web-Frontend. Um die APIs jedoch in die eigenen IT-Systeme einbinden zu können, muss der teilnehmende Partner im IBM Bluemix IAM einen technischen Benutzer mit einem API-Key anlegen und dessen Service ID in TradeLens bekannt machen. So wird erreicht, dass der Partner seine Accounts für die Nutzung von TradeLens völlig autark verwalten kann und TradeLens keinerlei Benutzernamen und Passwörter kennt bzw. Authentisieren muss. Dieses Konzept entspricht dem OAuth 2.0 Standard, gemäß dem der Ressource Server (TradeLens) vom Authorization Server (hier vom Partner verwalteten IBM Bluemix IAM Account) getrennt ist, damit der Ressource Owner (Partner) bestimmen kann, welcher Client (IT-Anwendungen für die Publikation bzw. Subskription von Events) auf TradeLens in welchem Ausmaß zugreifen dürfen sollen — ein ausgeklügeltes und sicheres Konzept der Kompetenz- und Verantwortungsteilung.

Quelle:

Ist all das Organisatorische erledigt, kann es an die Implementierung der Event-Publikationen in den eigenen IT-Systemen gehen — dem technisch interessantesten Punkt.

Regelmäßig werden Logistikdienstleister, Infrastrukturbetreiber sowie Behörden und Finanzdienstleister sich fragen, wie sie diesen Ablauf am aufwandärmsten in ihre bestehenden IT-Systeme integrieren soll; am besten so, dass der gesamte Datenaustausch vollautomatisiert, sicher, skalierbar und überprüfbar abläuft.

TradeLens bietet in seiner technischen Dokumentation eine hervorragende Anleitung, wie erste Integrationstests mithilfe von Postman durchgeführt werden können. Anhand zahlreicher Screenshots wird erklärt, wie die zweistufige Authentisierung realisiert wird und wie JSON-Dokumente an die entsprechenden API-Endpunkte geschickt werden sollen. Eine weitere Erläuterung erübrigt sich daher. Postman-Kenner werden diese Tests mithilfe von Collection Runner sowie JavaScript Methoden so automatisieren, dass sie die relevanten API-Endpunkte ohne manuelle Interaktion prüfen können.

Quelle:

Wurden diese sehr gut dokumentierten ersten Integrationtests mit Testdaten erfolgreich abgeschlossen, steht man vor der eigentlichen Aufgabe: Der automatisierten Übertragung von Daten an TradeLens aus den eigenen Kernsystemen. Vielerorts wird der Ruf nach dem Enterprise Service Bus (ESB) Team laut. Dieses implementiert und verwaltet in vielen Unternehmen sämtliche API-Integrationen mit Umsystemen. Zumeist wird für eine neue Integration ein Projekt aufgesetzt, das aus IT-Fachleuten unterschiedlicher Abteilungen sowie Fachbereichen für die funktionalen Anforderungen besteht — ein organisatorisch und technisch meist aufwändiger Prozess, welcher aus der agilen und transaktionalen Realität vieler Logistikunternehmen gefallen zu sein scheint.

• intuitiv zu bedienen
• skalierbar nach aktuellem Bedarf (technisch wie ökonomisch)
• flexibel hinsichtlich der anzubindenden, meist heterogenen Systeme
• vertrauenswürdig hinblicklich der Datennutzung 
• sicher vor Angriffen und Missbrauch
• stabil und robust in Bezug auf Verfügbarkeit
• aufwandsarm zu betreiben sein — am besten als Cloud-Dienst (SaaS)

Workato erfüllt mit seinem auf Low-Code ausgelegten Trigger-Action-Prinzip genau diese Anforderungen. Seine Gründer bringen jahrzehntelange Erfahrung in Integration und Automatisierung von Geschäftsprozessen im Enterprise- Umfeld mit und haben dieses Wissen mit dem Trend zur Ermächtigung des “Citizen Developer”, dem technisch interessierten und versierten Mitarbeiter jeglicher Organisationseinheit, in einer nativen Cloud-Lösung realisiert. Das enorme Kundenwachstum von Workato trotz COVID-19 Pandemie zeigt, dass sie damit ins Schwarze getroffen haben: 

| Integrationen beschleunigen, Prozesse automatisieren

Die Research-Giganten Forrester und Gartner zählen Workato zwischenzeitlich zu den führenden Integrations- und Automatisierungsplattformen überhaupt. Laut Deloitte hält Workato den 17ten Platz der am stärksten wachsenden Unternehmen in der Bay Area, den 96ten Platz in ganz Nordamerika. Workato integriert sowohl Cloud-Anwendungen als auch on-premise Anwendungen, ob Legacy Systeme oder modernste Microservices — und das selbstverständlich auf Enterprise-Niveau. In Zahlen ausgedrückt werden mehr als 4 Mrd. Events pro Jahr bei über 4.300 Kunden mit einer Verfügbarkeit von 99,99% verarbeitet.

Quelle:

Häufige Integrationen werden als fertige Recipes angeboten, wie Workato seine Automatisierungsabläufe nennt. Jedes Recipe besteht aus einem Trigger, der eine Abfolge von Actions auslöst. Genial einfach, jedoch überaus mächtig! 

Out-of-the-box finden sich zahlreiche Trigger und Actions z.B. für die Rechnungserstellung mit TradeShift, die Erfassung eines Kundenvorgangs in Salesforce, die Aktualisierung eines Customer Service Tickets in ServiceNow oder der Zugriff auf IoT Daten in Splunk. Das ist aber nur ein winziges, beispielhaftes Subset. Es könnte leicht um Begriffe wie AWS, SAP, Oracle, PostgresSQL, MySQL, Snowflake, Slack, MS Teams, Sharepoint, Magento usw. ergänzt werden.

Zudem lässt sich Workato durch ein einfach bedienbares aber universell nutzbares Connector SDK um beliebige weitere Plattformen funktional erweitern. Wird beispielsweise eine in der Transportlogistik häufig verwendete EDIfact oder X12 Anbindung benötigt, so gibt es einen mit diesem SDK entwickelten Connector zum SaaS-Anbieter Orderful. Will man lieber eine andere Plattform als fertiges Recipe einbinden, so ist dies auf demselben Weg möglich — hochinteressant gerade für wiederkehrende Automatisierungen.

So lassen sich die einzelnen Schritte eines Recipe innerhalb eines einzigen Triggers “verstecken”, z.B. das TradeLens Event “Actual discharge from vessel” wurde ausgelöst, oder in einer oder mehreren Actions kapseln, z.B. publiziere TradeLens Event “Consignment bill of lading issued”. Diese Möglichkeit der eigenen Connectorerstellung werden wir in einem separaten Beitrag vertiefen. Jetzt zurück zum TradeLens Recipe, welches die einzelnen Event-Publikationsschritte sichtbar macht.

Trigger für die Auslösung eines Events in TradeLens soll ein neues File auf einem SFTP Server sein. Im konkreten Anwendungsfall erhält ein führender europäischer Intermodal-Operateur aus diversen Quellen Statusmitteilungen über den Transportablauf von Containern: Wurde ein Container auf einen Zug verladen, hat ein Container den Umschlagbahnhof per LKW verlassen, ist ein Zug an einem Hafenterminal angekommen, wurde ein neuer Transportauftrag erteilt, um einige Beispiele zu nennen. Sobald eine solche Statusmitteilung auf einem SFTP Server im Private Cloud Rechenzentrum des Intermodal-Operateurs abgelegt wurden, löst der Trigger im Workato-Recipe aus. Eine Selektion auf bestimmte Trigger-Inhalte wie Dateinamensteile wäre auch möglich, ist im konkreten Fall aber nicht nötig.

Die Verbindung über SFTP ist in Workato ein Kinderspiel: Einfach eine Connection hinzufügen, SFTP auswählen, die Login-Parameter angehen wie z.B. Benutzername, Passwort, Hostkey Fingerprint zwecks Vermeidung von Man-in-the-middle Attacken, IP-Adresse und Port — und auf Connect klicken. Fertig! Die Daten werden verschlüsselt gespeichert und gemäß GDPR sicher behandelt.

Dasselbe macht man mit weiteren Anwendungsverbindungen, die innerhalb von Actions im Recipe verwendet werden sollen wie z.B. Splunk oder im konkreten Fall Google Sheets. 

Ist der Trigger konfiguriert, kann es mit den Actions weitergehen. TradeLens verlangt als Erstes eine Authentication in IBM Cloud IAM mit dem zuvor über die Oberfläche erstellten API Key. Ist dieser korrekt, erhält man einen Access und Refresh Token, mit dem man sich in der nächsten Action im TradeLens Solution Manager authentisiert. 

Dieser HTTP-Request ist ganz einfach per Drag&Drop zu konfigurieren. Konstante wie z.B. den IBM Cloud IAM Link sowie den API Key sollte man zuvor als Property definieren und dann in den entsprechenden Action-Feldern als Element einfügen, um diese vertraulichen Daten im Recipe nicht ausschreiben zu müssen. Workato macht die Werte in Properties unkenntlich , sobald man Schlüsselwörter wie “Key” oder “Password” im Property-Namen verwendet. Hilfreich, gerade wenn man die Lösung mit Screen-Sharing durchdiskutiert.

Den Access und Refresh Token, die Response dieses HTTP-Requests, fügt man dann als Request Body in die Authentisierung beim TradeLens Solution Manager ein, dem dritten Schritt in diesem Recipe. Auch das geht per Drag&Drop, indem der Response-“Body” des zweiten Schrittes in den Request body des dritten Schritts gezogen wird — kinderleicht. Die Request URL setzt sich wiederum aus zuvor definierten statischen Properties zusammen.

Als nächstes wird der Inhalt der Statusmeldung, welche den Trigger ausgelöst hat, vom SFTP Server heruntergeladen (Download File), inhaltlich aufbereitet (Parse CSV) und anhand einer Lookup-Tabelle geprüft (Search Entries), wie viele Events diese Statusmeldung in TradeLens auslösen soll. Letzteres ergibt sich aus einem inhaltlichen Vergleich, der während des Onboardings durchgeführt wurde. Letztlich werden noch Variable angelegt, da die folgenden Actions in einer Wiederholungsschleife (For-Each) möglichst wiederverwendet werden sollen, indem die zuvor definierten Variablen für die TradeLens Event URL sowie den Event-Inhalt je nach eingegangener Statusmeldung neu befüllt werden.

Interessantes Detail dabei ist, wie einfach ein CSV-File zu einem strukturierten Objekt aufgebaut werden kann, dessen Elemente in weiteren Actions verwendet werden können. Dazu muss lediglich die Überschriftenzeile des CSV in die Parse CSV Action kopiert werden — fertig.

Darauf folgt eine For-Each Schleife, in der je Statusmeldung-TradeLens Event-Kombination eine JSON-Nachricht inhaltlich aufgebaut wird. Im konkreten Fall sind das 4 verschiedene Kombinationen, die sich vor allem in der Transportrichtung (Import, Export), dem Transportmedium (Zug, LKW) und im übergebenen Zeitpunkt des Events unterscheiden. Zudem muss noch der TradeLens API-Endpunkt korrekt zugeordnet werden, was durch ein Update der dafür zuvor angelegten Variable geschieht.

Bei Enterprise-Integrationen stellt üblicherweise das Mapping von Ausgangs- sowie Zielschema eine zeitaufwändige Herausforderung dar. In Workato ist das über eine Map-Action effizient gelöst, in welcher das Zielschema entweder feldweise definiert werden kann oder aber durch Hochladen oder Copy&Paste eines JSON Zieldokuments automatisch erstellt wird. Weil TradeLens die Eventinhalte in Swagger (OpenAPI 2.0) ausführlich dokumentiert hat und das Nachrichtenmodell von dort einfach kopiert werden kann, kam hier die dritte Option zum Einsatz. Es wird also ein Custom Data Model (Schema) per Copy&Paste angelegt, welche innerhalb einer Map-Action als Zielstruktur verwendet wird — kinderleicht und in Sekunden erledigt.

Das Mapping von Ausgangsdatenstruktur in die Zieldatenstruktur ist ebenfalls sehr einfach. Workato hat jedoch auch einen eingebauten Formula-Modus, sodass je Feld aufwändigere Berechnungen erfolgen können, sofern dies nötig sein sollte. Die anspruchsvollsten Berechnungen erfordert TradeLens in den Event Occurrence sowie Terminal Feldern. Bei ersterem muss der Timestamp in ISO 8601 Format, also UTC-konform, angegeben werden; bei zweiterem verlangt TradeLens das Seehafenterminal als Zusammensetzung von UN/LOCODE und SMDG-Terminal Zeichenfolge. Da die entsprechenden Ausgangsdatenfelder nicht so vorliegen, muss im Falle des Zeitstempels eine Konvertierung in UTC unter Angabe der gegenständlichen Zeitzone erfolgen, während im Falle des Terminals zuerst geprüft werden muss, ob es sich überhaupt um ein Seehafenterminal handelt, an dem das Event stattgefunden hat; wenn ja, dann wird beim Schienentransport die DIUM-Bahnhofsnummer des internationalen Eisenbahnverbandes UIC anhand einer Lookup Tabelle in die gewünschte Zeichenfolge konvertiert. Der Formula-Modus bedient sich der Sprache Ruby; er ähnelt sehr stark dem allbekannten Formel-Modus in Microsoft Excel.

Zum Schluss wird das aufgebaute TradeLens Event Objekt in JSON konvertiert — eine Einzeilerformel — und an den entsprechenden TradeLens API-Pfad übertragen, der sich aus der oben beschriebenen Statusmeldung-TradeLens Event-Kombination ergeben hat.

Auch wenn Workato grundsätzlich alle Jobs samt Input und Output je Schritt protokolliert, sofern man dies aus Datenschutzgründen nicht (wahlweise) ausgeschaltet hat, so empfiehlt sich die Protokollierung in einer externen Quelle. Üblicherweise kommen hier Logging-Lösungen wie Splunk oder Datadog zum Einsatz, für die Workato fertige Actions anbietet. Im vorliegenden Fall fiel die Wahl hingegen aus Einfachheitsgründen auf Google Sheets, in dem neben dem Zeitstempel der Übertragung an TradeLens die Ausgangswerte aus dem Transportmanagement System, die übertragenen TradeLens Event Inhalte sowie er TradeLens API-Endpunkt und der Workato Job-Link gespeichert wurden. Zudem wurde die TradeLens Event ID gespeichert, welche TradeLens je Event Message an den Absender übergibt, damit im Problemfall das TradeLens Team die Transaktion auch wiederfindet. All das ist dank Google Sheets Connector eine Angelegenheit von Minuten.

Schnelligkeit, Einfachheit und Zuverlässigkeit. Moderne Technologien müssen gerade diese Tugenden in sich tragen, damit sie ihre positive Wirkung entfalten können. Gerade die Transportlogistik als Motor des globalen Handels und Wohlstandes muss diesen Dreiklang beherzigen, um den Marktanforderungen gerecht zu werden und die Digitalisierungsanforderungen an das eignen Geschäft erfolgreich zu bewältigen. Die Vielzahl an nötigen Integrationen und Automatisierungen, um relevant und profitabel zu bleiben, darf daher kein Problem darstellen sondern muss vielmehr als willkommene Chance erscheinen. Mit den richtigen Tools und Technologien ist das kein Problem sondern ein Genuss, wie selbst globale Projekte in der Dimension von TradeLens zeigen. Wir dürfen uns folglich auf die Zukunft freuen! 

Business Automatica senkt Prozesskosten durch Automatisierung manueller Tätigkeiten, hebt die Qualität beim Datenaustausch in komplexen Systemarchitekturen und verbindet On-premise Systeme mit modernen Cloud- und SaaS-Architekturen.