Die proprietäre Software ecoDMS zählt leider zu den weniger schönen Dokumenten-Management Systemen. Unterschiedliche OCR-Engines im Server und Desktop-Client mit abweichenden Ergebnissen bei der Kategorisierung von PDFs. Keine Online-Datensicherungen, obwohl diese technisch möglich wären.1 Und vor einiger Zeit kam für einen Kunden ein weiteres Problem hinzu: Rechnungen in der Scaninput-Warteschlange blieben liegen.
Einschlägigen Foren zufolge ein bekanntes Problem.2 Die Ursache: Eine korrupte PDF-Datei.3 Der konkrete Schaden: Skontoerträge4 konnten nicht geltend gemacht werden und Mehr- und Nacharbeiten sind angefallen.
Da das jederzeit erneut passieren kann musste eine schnelle und zuverlässige Lösung her. Eine ohne zusätzliche Abhängigkeiten, Problemen oder gar technischen Schulden.5
Lösung erster Klasse
Natürlich wäre die beste Lösung, wenn der Hersteller seine Software einfach fixen und weniger von KI bloggen würde. Es ist kein Hexenwerk, korrupte Dateien zu identifizieren und dem Anwender mindestens einen Hinweis zu geben. Doch dafür müsste ecoDMS die offensichtlich single-threaded6 Abarbeitung von Warteschlangen anpassen. You have had one job!
Wir müssen uns leider mit einer zweitklassigen Lösung zufrieden geben: Eine zusätzliche Software muss her, um die Probleme der ersten zu fixen.
Lösung dritter Klasse
Der erste Gedanke: Ein PowerShell-Skript als Retter in der Not. Zeitgesteuert prüft es den Rechnungsordner, zählt die Dateien und gibt bei Überschreiten einer bestimmten Anzahl von liegengebliebenen Dateien Alarm per Email. Klingt nach schneller und einfacher Problemlösung. Copilot und ChatGPT spucken da schnell was raus, ganz im Sinne von Entscheidern, die mit dem Paretoprinzip7 operieren.
Warum es das genau nicht ist, wird bei Betrachtung der Abhängigkeiten und impliziten Voraussetzungen deutlich.
Was, wenn der Job in der Windows-Aufgabenverwaltung nicht startet? Oder startet, aber dann crasht noch bevor es etwas melden kann? Wird das abgefangen und überwacht? Wenn nicht, geht es zurück zur Ausgangssituation: Niemand bekommt etwas mit, bis eines Tages der Rechnungsordner wieder voll läuft.
Auch die nächste Abhängigkeit ist problematisch: Die Benachrichtigung per Email. Was wenn ein Mailserver verzögert oder diese als Spam identifiziert? Es geht noch profaner: Was, wenn sich Protokolle oder Zugangsdaten zum Mailversand ändern. Irgendwann, wenn niemand mehr sich dieser improvisierte Script-Lösung Gewahr ist? Stichwort Zugangsdaten: Diese müssten im Klartext im Skript oder als Textdatei irgendwo auf dem Host hinterlegt werden.
Unternehmen mit etablierten Monitoring ihrer IT Infrastruktur wollen im Operations eines ganz bestimmt nicht: Lösungen, die sich an unternehmensweiten Prozessen und Standards vorbei wuseln und ein Sicherheitsniveau verschlechtern. Und so kann ein Powershell-Skript in einem solchen Szenario bestenfalls drittklassig sein.
Lösung zweiter Klasse
Eine Lösung muss genau hier ansetzen und sich in ein bestehendes Monitoring integrieren. In der Regel erfolgt sowas über REST APIs.8 Periodisch vom Monitoring abgefragt, gibt es die Antwort JSON-formatiert9 zurück. Alles weitere, von Berechtigungen, Alarmketten bis zu verschiedenen Kommunikations-Kanälen ist im Monitoring festgelegt. Da braucht sich unsere Lösung nicht mehr mit zu beschäftigen.
Eine REST-API läuft mit ihrem lauschenden Webservice auf dem ecoDMS Host und zählt bei Aufruf Dateien. Sollte diese crashen, bekommt es das Monitoring mit.
Idealerweise kommt eine solche REST-API schlank als Single-File-Executable ohne ein komplexes Framework, das tief in ein Zielsystem eingreift. Das jedoch ist genau ein Problem moderner Programmiersprachen. Runtimes und Frameworks reichen von mehreren 100 MB für Java oder .NET bis immerhin “nur” 25-50 MB für Python oder node.js Weitergabepakete.
Im Operations wiegt dieser Umstand schwer. Systeme werden komplexer und die Fehlerrate steigt. Updates müssen laufend nachgezogen werden und die Angriffsoberfläche10 erhöht sich signifikant, wenn plötzlich Javascripts ausführbar werden. Und so kommt es, dass ich bevorzugt auf weniger bekannte Programmiersprachen zurück greife. Wo Software noch nativ compiliert wird und keine Runtimes benötigt.
Wie groß darf ein RFC-konformer, multi-threaded Webserver mit Workern,11 TLS und Basic-Auth12 sein? Ich komme auf schlanke 1,7 MB für die Single-File-Executable. Ohne TLS war die EXE anfangs sogar nur 200 KB groß.
Das ist die Geschichte hinter der kürzlich auf Codeberg veröffentlichten REST-API.13 Ich bin mir sicher, dass diese im Operations als “Sensor” auch für andere Problemstellungen dienlich sein kann.
Die Integration in Zabbix, dem Monitoring System des von ecoDMS geplagten Kunden, ist nur noch Handwerk. Zuverlässig werden nun liegen gebliebene Rechnungen im zentralen Dashboard rot hervorgehoben. Mit der höchsten Alarm-Kategorie “Desaster” erfolgt die Benachrichtigung über die hinterlegten Kommunikationskanäle an die Beteiligten.
Als “old fart” freut es mich besonders, dass diese Lösung gepackt auf eine 3,5" Diskette passt. Eine krude Heuristik von mir: Wirklich gute Tools müssen auf eine Diskette passen, auch wenn diese nur “zeitklassig” sind.
In diesem Sinne,
Euer Tomas Jakobs