Photo by Glenn Carstens-Peters

Am Anfang steht der Wunsch, schnell und einfach den Auftragsdatenaustausch mit einem wichtigen Kunden zu automatisieren. Gesagt, getan. Dateninhalte werden abgestimmt, Formate festgelegt und technische Protokolle sowie Zugangsdaten ausgetauscht. Alles läuft nach Plan. Die Entwickler verstehen den fachlichen Sachverhalt rasch und die gewünschte Lösung wird unversehens implementiert. Die Integrationstests laufen erfolgreich. Der Go-Live ist ein voller Erfolg. So stellt sich jede Führungskraft die Digitalisierung seiner Abläufe vor. Koordiniert, zielgerichtet, frei von Widrigkeiten und Problemen.

Nach einigen Monaten steigt die Anzahl der ausgetauschten Aufträge. Das weckt Freude und macht Lust auf Mehr. Wenn da nicht die wachsenden Nachfragen wären, warum einige Aufträge nicht bearbeitet worden seien und die Ware nicht geliefert wurde.

Die IT versichert, dass keinerlei Fehler aufgetreten seien, die Disposition betont, dass die reklamierten Aufträge niemals im System angekommen seien. Jetzt ist guter Rat teuer. Die Frage nach der "Schuld" liegt auf der Zunge.

Um ruhig schlafen zu können und im Problemfall immer aussagefähig zu sein, gibt es ein ehernes Prinzip in der Geschäftsprozessautomatisierung: Dokumentiere und halte nach. Konkret: Logge die Datenströme über alle Systemgrenzen hinweg. Was hat welcher Prozess wann wohin mit welchem Inhalt in welchem Format gesendet. Die klassischen W-Fragen helfen auch hier weiter.

| Was hat welcher Prozess wann wohin mit welchem Inhalt in welchem Format gesendet?

Der erfahrene Prozessmanager und Systemarchitekt wird daher bei jeder Automatisierung Wert auf mindestens diese Fragen legen:

1. Wie erfährt die andere Partei, was mein System erhalten hat?

2. Wie protokolliere ich minutiös, was ich mit den erhaltenen Daten getan habe - und zwar systemübergreifend?

3. Wie kann ich den Sachverhalt ad-hoc im Problemfall prüfen und einer etwaigen Nachweispflicht nachkommen?

Die Rückmeldung an den Sender (Punkt 1) wird bei bidirektionalen Protokollen (REST, SOAP) durch eine aussagekräftige Antwortnachricht bestätigt. Findige Entwickler schicken einen Hash-Wert der erhaltenen Daten als Fingerabdruck an die sendende Partei, sodass ein etwaiger partieller Datenverlust evident wird. Problematisch wird es nur, wenn dokumenten-orientierte Protokolle wie SFTP eingesetzt werden. Dann empfiehlt es sich, die erhaltenen Dateien in einem Archiv(ordner) abzulegen, um im Bedarfsfall zumindest Einblick darin nehmen zu können bzw. der anderen Partei Zugriff darauf geben zu können.

Die Protokollierung der Verarbeitung (Punkt 2) in den eigenen Systemen sollte je Verarbeitungsschritt erfolgen, welcher fehlerbehaftet sein könnte. In der Regel bezieht sich das auf den Versand bzw. den Empfang von Daten, die am gegenständlichen Automatisierungsablauf teilhaben. Jedoch können auch Eingangswerte und Ausgangswerte einer Transformation ein Logging rechtfertigen. Entscheidend ist, dass die zu protokollierenden Sachverhalte klug gewählt und erschöpfend erfasst werden.

Der Nachweis der beiden vorgenannten Punkte muss schnell gehen - auch für den Laien. Zugang über einen beliebigen Webbrowser von jedem Gerät aus ist selbstverständlich. Am besten muss kein neues Benutzerkonto angelegt werden, um Einsicht in die Daten zu nehmen. Zudem sollte der Anwender die Daten mühelos kopieren und per E-Mail versenden können.

| Rückmeldung, Protokollierung und Nachweis sind die Pfeiler eines funktionierenden Loggings

Wie lassen sich diese drei Punkte umsetzen?

Professionelle Automatisierungsplattformen bieten out-of-the-box eine Lösung, um Automatisierungs-Jobs im Detail zu analysieren. Jeder Schritt der Automatisierung kann so in Hinblick auf Input-Werte und Output-Werte sowie etwaige Fehler nachvollzogen werden. Zudem kann die Job-Oberfläche zumeist so konfiguriert werden, dass in den Jobs nach verwendeten Werten wie z.B. Auftragsnummer, Rechnungsnummer oder Artikelnummer gesucht und gefiltert werden kann. Diese Job-Logs samt Suchfelder sind ein ideales Hilfsmittel für Entwickler, jedoch ungeeignet für den "normalen" Anwender.

Excel sei das beste IT-System der Geschicht - heißt es. Dieses bon-mot hält sich nicht grundlos selbst im Cloud-Zeitalter. Viel einfacher lässt sich jedoch Google Sheet als tabellarische Logging-Lösung innerhalb von Automatisierungsprozessen nutzen. So gibt es eine robuste API, eine kostenlose Oberfläche für Fremdanwender und eine einfache Möglichkeit, die Tabellen mit Geschäftspartnern zu teilen. Eine geradezu ideale Lösung für den Logging-Einsatz mit überschaubarer Datenfrequenz. Aufwändiger wird es, wenn viele Daten in kurzen Zeiträumen protokolliert werden müssen oder automatisiert gelesen werden müssen, da Google seine API mit einem Limit von 60 Aufrufen innerhalb von 60 Sekunden belegt. Mit einem kurzen Warten vor dem Aufruf einer Google-Sheet Logging-Aktion kann man sich zwar (wörtlich) etwas Zeit verschaffen, jedoch sollte diese Lösung ab einem gewissen Volumen durch eine performantere Alternative ersetzt werden. Die Verarbeitungszeit würde sonst einfach zu lange dauern. Wer wartet schon gerne?

| Einfach und komfortabel im Alltag, jedoch unpassend bei Massendaten

SQL- sowie NoSQL-Datenbanken stellen die nächst mächtigere Alternative dar. Ob on-premise oder aus der Cloud konsumiert - Datenbankdienste lassen sich einfach in die Automatisierung einbinden und alle Standardfeatures einer Datenbank nutzen. So können einfache web-basierte Oberflächen auf das meist sehr einfache Logging-Datenbankschema aufgesetzt werden. Alternative kann der etwas individuellere, wenn auch anspruchsvollere, Zugriff über SQL-Clientprogramme wie HeidiSQL oder Oracle SQL Developer oder auch BI Programme wie PowerBI oder Qlik erfolgen, um zu den gewünschten Daten in beliebiger Aggregation und Schüttung zu gelangen.

Interessant ist vor allem der Einsatz von NoSQL-Datenbanken wie MongoDB, da diese nicht nur als Service via API eingebunden werden können, sondern aufgrund ihrer Datenbankschemenlosigkeit deutlich mehr Flexibilität beim Logging zulassen. Nicht jeder Datensatz muss exakt dem anderen gleichen. Wurden einmal mehr oder weniger Felder vom Kommunikationspartner übermittelt, so kann dies exakt so in die Datenbank geschrieben zu werden, ohne sich um Leerfelder kümmern zu müssen.

| Ob SQL- oder NoSQL-Datenbank: Sie stellen den Gold-Standard im Logging dar

Monitoring- und Analyseplattformen wie Splunk, Log.it oder Datadog stellen einen weiteres probates Mittel dar, um vor allem aufwändige Analysen auf Basis von Protokolldaten zu bewältigen. Auch wenn sie großteils als Cloud-Service nutzbar sind, liegen ihre Kosten für eine längere Datenhaltung deutlich über den vorgenannten Alternativen. Der große Vorteil in diesen Enterprise-Lösungen besteht in der hohen Anpassbarkeit in Hinblick auf spezifische wiederkehrende Auswertungen. Dashboards können zumeist mit einfachen Skriptsprachen realisiert werden, Abfragen analog zu Datenbanken in jedem Komplexitätsgrad erstellt und performant ausgeführt werden. Fachbereichsbenutzern kann ein eigener Bereich mit aussagekräftigen Berichten zur Verfügung gestellt werden.

Als eigenständige Variante zu diesen Datenplattformen seien mächtige Low-code Plattformen wie OutSystems, Mendix oder Build.one genannt. Sie bieten leistungsfähige Datenbanken, professionelle Business Logik Entwicklungsmöglichkeiten sowie professionelle Benutzeroberflächen. Die Entwicklungszeit für eine Logging-Lösung ist oftmals sehr kurz und das Ergebnis atemberaubend. Wird eine solche Entwicklungsplattform bereits im Hause genutzt, ist sie sicherlich ein erster Kandidate für das eigene Logging. Oftmals gibt es Standardkonnektoren zwischen den Automatisierungsplattformen und den Low-Code Anwendungsentwicklungsplattformen.

| Datenplattformen und Low-Code Anwendungsentwicklungsplattformen sind mächtige One-Stop-Lösungen auch für Logging und Monitoring

Welche Lösung die jeweils beste ist, entscheiden die konkreten Anforderungen. Denkbar ist auch ein inkrementeller Weg: Wächst das Volumen der geloggten Daten oder die Zahl an Anwendungsfällen, so kann von einer Lösung in die nächst mächtige gewechselt werden. Ein kluges API-Design vermeidet Doppelaufwände. Leistungsfähige Automatisierungsplattformen helfen gleichzeitig bei der Migration der Daten von der initialen Lösung zu nächst mächtigeren Lösung, sodass einer runden Lösung nichts mehr im Weg steht.

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.