Dokumentenmanagement

- 7 Minuten - 1313 Wörter

Als Quelle werden die Dokumente als 1-bit-TIFFs mit 300-400 ppi mit dem Flachbettscanner EPSON Perfection Photo 3200 und dem Scanfrontend XSANE eingescannt und anschließend an das Dokumentenmanagement-Programm übergeben.

ecoDMS

Das erste, das Verwendung fand, war ecoDMS – ein zwar auf OpenSource-Werkzeugen (postgreSQL, Ghostscript, tesseract) basierendes aber selbst proprietäres Produkt der ecoDMS GmbH aus Aachen. Preislich recht günstig (49 EUR/Benutzer bzw. Verbindung Client→Server), wurde es in der Version 14.08 (krusty) am damals eingesetzen Windows 7 angeschafft.

Es besteht aus einer Server- und Client-Komponente, die bei einer Einzelplatznutzung auch auf dem gleichen Rechner laufen können. Als Datenbank wird PostgreSQL eingesetzt, sodass es praktisch keine Beschränkung in ihrer Größe gibt.
Hier liegt aber das Problem mit proprietärer Software: Die Daten landen nicht einmal als binärer Blob in der Datenbank, sonders als proprietäre Container (eingeführt mit der Folgeversion 16.09), an deren Inhalt man ohne funktionierendes ecoDMS nicht herankommt. Solange das System lauffähig ist, kann man das so benutzen, es besteht aber die Gefahr des totalen Datenverlustes. Auch ein Datenbank-Dump/-Export hilft einem aus dem vorgenannten Grund nicht viel. Nur ein (regelmäßiger) zusätzlicher manueller Export, bei dem PDF/A-Daten und eine XML-Datei mit Klassifizerungsattributen erzeugt werden) erlaubt es, auf die Dokumente außerhalb von ecoDMS zuzugreifen.

Ab dem Upgrade (vergünstigt zum gleichen Preis von 49 EUR) auf Version 16.09 (eleanor) habe ich die Serverkomponente in eine Linux-VM (zuerst ubuntu, später Debian) umgezogen, die auf dem NAS (unter TrueNAS) bei Bedarf gestartet wurde. Die Scans wurden per sFTP in einen Eingangsordner auf dem Server übertragen und mittels OCR mit Text angereichert und in der Datenbank gespeichert.

Am Client wird eine GUI installiert, mit der Dokumente in eine Struktur eingeordnet, verschlagwortet und mit Metadaten angereichert werden können. Das Ganze auch vorlagenbasiert, das heißt für immer gleich aussehende Dokumente erkennt die Software mehr oder weniger gut die Struktur und schlägt eine zuvor zu erstellende Vorlage vor, in der Felder wie Datum, Rechnungsnummer oder Ähnliches definiert werden können. Anschließend kann eine Volltextsuche zum Auffinden benutzt werden.

Aus dem oben aufgeführten Grund (Speicherung der Daten in proprietären Containern), habe ich einen manuellen Export aller erzeugten Dokumente (PDF/A) nach den jeweiligen Kategorien/Speicherordnern erstellt. Es werden zum Glück teilweise die ursprünglichen Dateinamen der Scandokumente zusätzlich zur numerischen ID als Exportnamen verwendet, zudem habe ich direkt in eine händisch erstellte entsprechende Ordnerstruktur exportiert. So konnte ich das Kapitel „Proprietäre Datencontainer für meine Daten“ abschließen und voll auf das im Folgenden beschriebene OpenSource-DMS umstellen.

Der Funktionsumfang von ecoDMS war zwar vergleichbar (mittels Plug-Ins kann man auch seine Mails und/oder Office-Dokumente im DMS sammeln), abgesehen von der grafisch darstellbaren „Ordnerstruktur“ mit Icons für die unterschiedlichen Zuordnungen der Dokumente, habe ich dennoch die Funktionalität – wie so oft – nicht voll ausgenutzt.

Es besteht kein Zweifel, dass ecoDMS eine Daseinsberechtigung hat – zu den Vorteilen zählen die plattformübergreifende Verfügbarkeit des Clients und relativ einfache Installation sowie versprochene Revisionssicherheit – letztere ist aber bei privater Nutzung ziemlich irrelevant und es kann angeblich passieren, dass Dokumente verschwinden und bereits vergebene (eindeutige) IDs mit neuen Dokumenten überschrieben werden können (hierzu ein Blogbeitrag von Christian Süßenguth).

Paperless-ngx

Um nach Möglichkeit eine vollständig OpenSource-basierte Lösung zu nutzen, habe ich nach einer Alternative zum obigen Programm gesucht. Außerdem ist die letzte lizenzierte Version (18.09) mittlerweile aus dem Support gefallen.

Im heise-Forum fand sich in einem Kommentar zu einem eigentlich anderen Thema der Hinweis auf paperless als eigenen Server für Dokumentablage. Nach einer kurzen Recherche fand ich heraus, dass das Programm mittlerweile paperless-ngx heißt (nachdem das ursprüngliche paperless nicht mehr weiterentwickelt und zwischenzeitlich als paperless-ng fortgeführt wurde – Vorteile einer OpenSource-Software).
Auf der Website wird sogar eine Demo-Instanz verlinkt, die man testen kann. Die einfache Bedienung, gute Ergebnisse der Texterkennung und Übersichtlichkeit der Verschlagwortung haben mich überzeugt. Nun musste nur die Installation gemeistert werden: empfohlen wird eine Docker-basierte, und da ich keinerlei Erfahrung damit hatte, ließ ich es lange auf sich beruhen.

Als irgendwann einige Dokumente auf das Scannen warteten, habe ich es gewagt, diese parallel in Paperless-ngx einzupflegen. Also eine Debian-VM schnell aufgesetzt, Docker installiert und mit dem Einzeiler von der oben genannten Dokumentations-Website die Software installiert.

Dann direkt die erste vermeintliche Enttäuschung: der Aufruf der eingestellten URL der Weboberfläche hat nur die Standardmeldung, Apache sei installiert und bereit angezeigt. Bis ich den Port :8000 mit angehängt habe: sofort begrüßte mich der Loginscreen. Wer (die ausführliche Dokumentation) lesen kann ist klar im Vorteil ;-)
Angemeldet und sofort einige Scans auf die dafür vorgesehene Fläche auf der Startseite per Drag-&-Drop gezogen. Sie wurden recht schnell verarbeitet (die VM hat 2 CPU-Kerne und 4 GB RAM erhalten). Dann ein paar erste Tags und Korrespondenten (=Autoren oder Empfänger der Dokumente) zugewiesen und schon kann man nach Tags, Korrespondenten, Datum etc. filtern oder via Volltextsuche die Sammlung duchsuchen.

Da das Programm stetig weiterentwickelt wird, sollten auch Updates eingespielt werden. Mit Docker ganz leicht, doch werden anscheinend die alten Docker-Images nicht gelöscht, sodass der Speicherplatzbedarf mit der Zeit ansteigt. So war die Initiale Installation ca. 6 GiB groß, mit einigen Dokumenten sind es ein paar Hundert MiB mehr doch nach einem Update wurden es plötzlich 14 GiB.
Das Problem mit stetig wachsenden VM-Diskimages ist ein grundsätzliches, man muss ab und zu die alten Docker-Images löschen (docker-compose rmi <Docker-Image-ID>) und die VM dann schrumpfen lassen (zuerst mit zerofree den freien Speicherplatz mit Nullen überschreiben und dann mit VBoxManage modifyhd /pfad/zu/paperless.vdi --compact).

Upgrade der Datenbank

Die verwendeten Komponenten – in diesem Fall das Webframework Django – werden auf neuere Versionen aktualisiert, und in diesem Fall wird die Kompatibilität zur verwendeten Postgres-Datenbank-Version 13 (die Ende 2025 ihr End-of-life erreicht) fallen gelassen. Das zwingt die Nutzer – also auch mich – die Datenbank zu aktualisieren. Leider ist es nicht mit einem Eintrag in der docker-compose.yml-Datei getan: das Programm startet danach nicht, mit einem Fehler, dass die Datenbankdaten mit einer früheren, nicht kompatiblen Version erstellt seien.

Zuerst habe ich gedacht, ich müsste das Upgrade nach dem Postgres-Weg gehen, also mit Datenbank-Dump und mit Datenbankbefehlen. Dem ist aber nicht so, es reicht, ein paar relativ einfache Befehle auszuführen:

  1. Ein reines Datenbackup mit docker compose exec -T webserver document_exporter --data-only ../export erstellen
  2. In der Konfigurationsdatei docker-compose.yml unter dem Eintrag db: image: docker.io/library/postgres:13 die Versionsnummer 13 durch die aktuelle 17 ersetzen
  3. Den Inhalt des Datenbank-Volumes unter /var/lib/docker/volumes/paperless_pgdata/_data/ (nach einer Datensicherung) löschen
  4. Dann die aktuelle Postgres-Datenbank als Docker-Image installieren (docker compose pull erledigt das)
  5. Mit docker compose up kann das paperless-ngx-System gestartet werden, es wird eine neue, leere DB angelegt
  6. Mit docker compose exec -T webserver document_importer ../export die Inhalte der Datenbank in die (noch leere, neue) Datenbank importieren ↦ Fertig!

Fazit

Alles in allem, ein – für technisch versierte Personen – ziemlich einfach zu installierendes und noch einfacher (dank Weboberfläche) zu bedienendes System. Es wird zwar etwas dauern, den Datenbestand von ca. 900 Dokumenten (die aber z.T. eher Unwichtiges wie Quittungen oder alte Rechnungen beinhalten) ins Paperless-ngx zu überführen, aber dank der selbst-lernenden Verschlagwortung un der sehr gut arbeitenden Zuordnung von Erstellungsdatum zum Dokument (inkl. Vorschlägen, die in der Texterkennung gefunden wurden) wird dies einfacher als bei der vorlagengestützten Arbeitsweise von ecoDMS.

Der Post in seiner ursprünglichen Form wurde von ca. 1 Jahr geschrieben (Juni 2023), mittlerweile sind (fast) alle wichtigen Dokumente in Paperless-ngx überführt, bzw. eingepflegt.

Vorteile

  • Alle Dokumente werden im Filesystem gespeichert, die (Postgres-)Datenbank nur für Tags, Schlagworte und die Metadaten verwendet
  • die selbst-lernende Automatik erkennt das Datum recht zuverlässig aus dem Dateinamen des Scans oder aus dem Inhalt selbst (es werden auch Vorschläge angezeigt, falls mehrere Datumsangaben enthalten sind); ich benenne trotzdem bereits die Scans entsprechend
  • das Programm wird stetig verbessert, obwohl es in der Grundfunktionalität als „fertig entwickelt“ angesehen wird
  • die Weboberfläche ist modern, trotz Funktionsfülle übersichtlich und schnell

Nachteile

  • Initiale Installation für nicht-technikaffine (zu) schwierig zu meistern
  • Speicherplatzbedarf steigt nach mehreren Updates enorm (s.o.), ist aber (umständlich) zu meistern
  • grundsätzlich ist es ein Programm, dessen Bedienoberfläche (browserbasiert) zwar einfach bedienbar ist, das zugrunde liegende System aber relativ viel techisches Know-How erfordert (idealerweise Docker- und allgemein Linux-Kenntnisse)