Jeden Tag treffen diverse Excel Listen mit Wagennummern, Containernummern, Zusatzinformationen sowie Ankunftszeiten per E-Mail ein, welche die Operations-Mitarbeiter zähneknirschend in das IBM i basierte Transportmanagement System übertragen – mit Copy & Paste; einmal Excel, dann Green Screen, dann wieder Excel usw.. Gleichzeitig wird die Mehrzahl solcher Ankunftsmeldungen von anderen Quellen über eine EDIfact Schnittstelle automatisch importiert. Der Gedanke liegt nahe, die ungeliebten aber nötigen E-Mails doch irgendwie automatisiert auszulesen und die gewünschten Informationen über diese bereits bestehende EDIfact Schnittstelle ebenfalls automatisiert in das IBM i System einzulesen. Das muss doch möglich sein!? In Zeiten volatiler und stark überlasteter Logistikketten wäre das ein willkommener Weg, den kreativen und produktiven Mitarbeiter zu entlasten; stattdessen kann er sich anspruchsvollen Aufgaben stellen, die seiner Fähigkeiten bedürfen, z.B. einer vorausschauenden Planung oder einem noch besseren Kundenservice. Copy & Paste kann der Computer auch selbst – ohne sich langzuweilen oder frustiert zu werden.

So weit, so gut. Das Tückische an dieser Aufgabe ist die Struktur der Excel Daten und das proprietäre Excel-Format an sich. Zwar sind die enthaltenen Blätter und Daten halbwegs homogen aufgebaut, d.h. in unserem Fall auf jedem Wagen können maximal vier Container transportiert werden, deren Kerndaten wie Containernummer, Auftragsnummer sowie Größe und Gesamtgewicht spaltenweise notiert sind. Jedoch erkennt man bei genauerem Hinsehen eine Variabilität an Leerzeichen in den Containernummern, des Weiteren eine unterschiedliche Bedeutungen der Auftragsnummern in der Spalte “Bemerkungen” je nach Auftraggeber sowie am Ende ab und an extra Zeilen und Notizen, in denen die Disponenten eines anderen Dienstleisters verschiedene, für uns irrelevante Informationen eintragen haben. Zudem sollen die Track & Trace Statusmeldungen erst dann versendet werden, wenn deren actual-time-of-arrival (ATA) erreicht ist – selbst wenn sie vorzeitig ankommen. Man weiß leider nicht, ob deren Entladung auch vorzeitig stattfinden konnte; da fehlen die Informationen noch. Zu guter Letzt kann der Excel-Aufbau nicht verändert werden, da die Excel Datei seit Jahren genau so an mehrere Transportunternehmen verschickt wird. Man weiß nicht, ob mit einer Änderung die anderen Kunden in Probleme laufen würden. Kurz und gut:

Die Automatisierung muss auf alle Eventualitäten Rücksicht nehmen

Was ist jetzt genau zu tun – und vor allem wie? Es stellen sich folgende Einzelaufgaben:

1. Mitbekommen, wenn eine neue, relevante (!) Excel Datei per E-Mail eintrifft
2. Excel Datei (XLSX) in ein verarbeitbares Format umwandeln (CSV, JSON o.ä.)
3. Relevante Excel Arbeitsblätter auswählen und andere verwerfen
4. T&T Daten um ungewünschte Leerzeichen u.ä. bereinigen, d.h. normalisieren
5. T&T Daten in einzelne EDIfact Datensätze für die IBM i überführen (Fixed Record Format)
6. EDIfact Datensätze in einzelne Textdateien speichern (so will es das IBM i ERP)
7. Textdateien zum entsprechenden ATA-Zeitpunkt an das IBM i ERP übertragen

Das alles klingt schon etwas aufwändiger: Excel ist ein prorietäres Format, die Variabilität in den Excel Arbeitsmappen sowie den Daten verlangt nach logischer Abstraktion, um das Relevante zu selektieren sowie zu vereinheitlichen. Alte Datenformate wie EDIfact erfordern eine exakte Positionierung von Feldinhalten in einer Zeichenkette. Letztlich muss das alles noch zeitlich richtig gesteuert werden, damit ein Kunde keine Ankunftsmeldung erhält, bevor der Container nicht abholbereit ist. Das wäre fatal.

Ad arma! Zu den Waffen! – wie der Römer sagen würde. Die “Waffe der Wahl” ist die cloudbasierte Low-Code Automatisierungs- und Integrationsplattform Workato. Die Plattform des gleichnamigen kalifornischen Unicorns verspricht die Lösung nahezu aller Automatisierungsaufgaben, in denen Daten zwischen zahlreichen Systemen ausgetausch und angepasst werden müssen. Dabei greifen die einzelnen Arbeitsschritte so in einander, dass keine menschliche Interaktion mehr nötig ist, wo sie nicht explizit erwünscht ist. Über die Grundprinzipien von Workato haben wir andererorts schon berichtet.

Als Trigger für einen Automationsdurchlauf (Job) dient das Eintreffen einer E-Mail im Office 365 Postfach – genauer gesagt Exchange Online Postfach der Operations Abteilung -, sofern es sich um eine relevante E-Mail handelt; das wird über die Prüfung des Absenders und der Anhänge sichergestellt. So kann das Recipe, wie Workato seine Automatisierungsabläufe nennt, entweder nur speziell für einen Fall entwickelt werden (wie hier), oder in Module und Varianten verzweigen (z.B. mittels Callable Recipes oder IF-Verzweigungen). Die erste Einzeaufgabe wäre damit erfüllt.

Anschließend muss die Excel Arbeitsmappe in ein verarbeitbares Format konvertiert werden. Dabei soll nur jenes Excel Arbeitsblatt ausgewählt werden, das für den Versand der T&T Information relevant ist – in unserem Fall der aktuelle Tag bzw. der letzte Samstag, wenn gerade ein Wochenende zu Ende gegangen ist. Wenn die Excel Arbeitsmappe auch Arbeitsblätter mit alten Daten enthalten sollte, wie in unserem Fall, müssen diese selbstverständlich ignoriert werden. Sonst entsteht eventuell ein Dupletten-Chaos bei den Empfängern (Kunden).

Zu diesem Zweck nutzen wir Cloudmersive, einen führenden Clouddienst für eine Vielzahl an Konvertierungen. Dessen API-Spezifikation sagt, dass er XLSX Arbeitsmappen vereinzeln und in CSV konvertieren könne. CSV können wir in Workato wiederum aufwandsarm weiterverarbeiten. Wunderbar! Genau das suchen wir.

Man wäre jetzt verlockt, sofort eine HTTP-Action seinem Recipe in Workato hinzuzufügen, wenn da nicht eine Kleinigkeit wäre. Ja die berühmte Kleinigkeit kannte schon Inspektor Columbo und bracht so viele (un)ehrenwerte Menschen zu Fall. Hier ist diese Kleinigkeit die Forderung des Cloudmersive API-Endpunkts, das XLSX File als formData zu erhalten. Damit ist multipart/form-data als MIME-Type gemeint, den das W3C folgendermaßen erklärt:

| The content type “multipart/form-data” should be used for submitting forms that contain files, non-ASCII data,    and binary data.

Soweit, sogut. Will man diesen Content Type in der Workato HTTP-Action einstellen, wird man jedoch nicht fündig. Workato bietet indes eine elegante Lösung über sein Connector SDK. Im Ergebnis erstellen wir einen Connector, hier für die Cloudmersive API, in dem wir Trigger, Actions, konfigurierbare Felder usw. spezifizieren können. In unserem Fall implementieren wir eine Action zur Konvertierung von XLSX Arbeitsmappen in CSV.

Das Connector SDK ist eine rein web-basierte Entwicklungsumgebung für individuelle Connectoren; keine extra Software muss dafür installiert werden. Ein Connector folgt einem Standardaufbau samt dokumentiertem Beispielcode und bietet (fast) alle Freiheiten von Ruby, der im SDK bevorzugten Programmiersprache. JavaScript Freunde können alternativ ihren Code über eine JavaScript Action einbinden, würden dann aber auf die Vorteile des Connector SDK verzichten, welches die Erzeugung konfigurierbarer (!) Trigger, Actions, Connections, Webhooks, Konfigurationsfelder usw. in einem Connector ermöglichen. Da Ruby intuitiv erlernbar und gleichzeitig mächtig ist, bleiben wir aber gerne beim Connector SDK. Es ist zudem das Tor zur Connector Community Library, einer Art App-Store für Konnektoren, über welchen man seine eigenen Konnektoren einfach teilen kann (aber nicht muss).

Mithilfe einer Ruby-Methode können wir im Connector SDK spielend leicht das XLSX an Cloudmersive übertragen und erhalten postwendend mehrere Links zum Download aller konvertierten Arbeitsblätter im CSV Format zurück. Einzelaufgabe 2 wäre somit erledigt.

Jetzt müssen wir die aktuelle CSV-Liste mit den ATA-Daten noch identifizieren und maschinenlesbar machen; in Workato bedeutet das, die CSV-Datei zu parsen und somit als JSON-Objekt allen weiteren Schritten zur Verfügung zu stellen. Hierbei hilft uns Ruby erneut, diesmal mit einer Formel bei der Bestückung von drei Variablen mit Daten aus dem aktuellen CSV-Blatt. Alle anderen CSV-Blätter bleiben unberücksichtigt, ganz wie es Einzelaufgabe 3 erfordert.

Nach der Bereinigung unerwünschter Leerzeichen während wir für jeden Container einen eigenen T&T Datensatz aufbauen und in einer internen Liste zwischenspeichern, sind vorerst alle aufbereitenden Einzelaufgaben inkl. Nummer 4 erledigt.

Nun wird es nochmals etwas kniffelig: Workato führt die aufbereiteten Daten intern als Ruby Objekte mit. Diese an einen weiteren Dienst als JSON zu schicken, wäre ein Leichtes, reicht aber im vorliegenden Fall nicht aus. Das IBM i basierte ERP fordert die Datensätze in einem ganz bestimmten EDIfact Format, das zudem vom Standard leicht abweicht. Diese Herausforderung bewältigen wir in der 5. Einzelaufgabe, indem wir mittels Ruby String-Interpolationen den Inhalt des zu speichernden Objekts in das gewünschte Fixed Record Format bringen.

Zum Schluss speichern wir jeden EDIfact Datensatz als eigenen Textdatei in einem Amazon Web Services S3 Bucket in der datenschutzrechtlichen Region unseres Vertrauen, von wo ein zweites Workato Recipe die erzeugten EDIfact Dateien abholt, um sie in das IBM i Kernsystem einzuspielen und die Kunden mit den benötigten Track & Trace Informationen zum richtigen Zeitpunkt zu versorgen. Et voilà: Einzelaufgabe 6 erledigt und 7 vorbereitet. Den siebenten Schritt werden wir in einem separaten Artikel besprechen, in dem wir uns mit individuellen Triggern, Cron-Jobs und Trigger-Conditions beschäftigen werden.

Was haben wir gelernt? Dieses konkrete Beispiel zeigt uns drei Merkmale moderner Automatisierung und Integration von Arbeitsabläufen:

1. Automatisierung ist ein Zusammenspiel mehrerer verteilter Dienste und Anwendungen (hier Workato, Office 365, Exchange Online, Cloudmersive, AWS, IBM); es gibt nicht “die eine Plattform”, die alles in sich autark erledigt. Dafür sind die Aufgaben zu vielfältig.
2. Low-Code kann wunderbar durch High-Code ergänzt werden, wo passgenaue Algorithmen oder spezialisierte Bibliotheken von Nöten sind, um selbst komplexe Anforderungen in heterogenen Umgebungen zu meistern.
3. Das Connector SDK bietet jedem interessierte “Macher” die Möglichkeit, regelmäßig wiederkehrende Actions für jeden Workato-Nutzer zugänglich zu machen, sowie das eigene Angebot seinen Kunden über den Marktplatz zur Verfügung zu stellen. Zudem eröffnet es die weite Welt von Ruby und dessen Funktionalitäten.

Der eigenen Kreativität sind keine Grenzen gesetzt. Gepaart mit den zugrunde liegenden Standardfähigkeiten in Bezug auf Sicherheit, Skalierbarkeit, Performance, Wartbarkeit, Versionierung, CI/CD und Job-Kontrolle muss niemand mehr darauf warten, Automatisierungs- und Integrationsaufgaben in allen Facetten umzusetzen. Workato ist als cloud-basiertes SaaS “auf Knopfdruck” verfügbar und sofort einsetzbar – egal ob in modernsten Microservice-Architekturen, in klassischen Host-Systemen oder ergänzend zum bestehenden Enterprise Service Bus. Der Charme ist, Workato verbindet alle Dienste und Welten miteinander, ohne dabei dogmatisch zu sein. Und darauf kommt es an: Get your job done!

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.