Dieser Artikel behandelt den Vergleich von 2 DMS-Lösungen sowie der Migration zu einer OSS-Lösung.
Disclaimer / Haftungsausschluss
Die in diesem Artikel geäußerten Ansichten und Meinungen sind ausschließlich meine eigenen und spiegeln nicht notwendigerweise die Ansichten der Entwickler oder Unternehmen hinter den genannten Softwarelösungen wider. Es besteht keine geschäftliche oder finanzielle Beziehung zu einem der genannten Hersteller – insbesondere wurde ich weder bezahlt noch anderweitig für die Erstellung dieses Vergleichs kompensiert.
Alle genannten Produktnamen, Logos und Marken sind Eigentum der jeweiligen Rechteinhaber. Die Verwendung dieser Marken erfolgt ausschließlich zu Vergleichs- und Informationszwecken und stellt keine Verletzung der Markenrechte dar.
Trotz sorgfältiger Recherche kann ich keine Gewähr für die Richtigkeit, Vollständigkeit und Aktualität der Inhalte übernehmen. Die Informationen stellen keine rechtliche Beratung dar.
Ein Hinweis vorab: Ich hatte bei dem Vergleich bereits ein bestehende ecoDMS-Instanz (Version 24.02). Ziel war es, bei aktiv genutzten Features dies auch so in paperless-ngx abbilden zu können. Workarounds sind hier natürlich auch bedacht worden, aber es durfte zu keinem erheblichen Mehraufwand kommen bzw. die tägliche Bedienung nicht sehr darunter leiden.
Ausgangslage sowie zu betrachtende Funktionen
Da es sich um eine bestehende Umgebung handelt, wurden bereits div. Funktionen verwendet, welche an sich als Notwendig erachtet werden mussten. Wichtig: Je nach Anwendung und persönlichen Anforderungen kann dies natürlich stark unterschiedlich sein:
- Automatische Klassifizierung eines Dokuments anhand von Barcode/OCR
- Erkennung von Duplikaten
- Verarbeitung von Dokumenten in einem Ordner (Scan mittels Dokumenten-Scanner über SMB)
- Vollständiges OCR für PDF sowie Office-Dokumente und E-Mails (Nachrichtentext + Anhänge)
- Unterstützung für Revisionen (alle Änderungen sind nachvollziehbar, es wird immer die neuste Revision geöffnet)
- Speicherung des Originals ohne Änderungen an der Datei im System
- Volltextsuche mit direktem "Abspringen" in das Dokument und der jeweiligen Seite
- Multi-User-Fähigkeiten mit gruppenbasiertem Berechtigungssystem (RBAC) + Zuweisen von Gruppen als Eigentümer des Dokuments
- Das endgültige Löschen von Dokumenten darf nur durch Administratoren möglich sein
Nach einer ersten Analyse der beiden Systeme fällt eine grundlegender Unterschied bei der Organisation auf: ecoDMS setzt auf Ordner sowie auf bereits vorgegebene Klassifizierungsattribute, welche nach belieben angepasst werden können. In paperless-ngx ist es inzwischen auch möglich so genannte "custom fields" zu definieren, allerdings funktioniert die primäre Erkennung über so genannte "Tags". Jedes Dokument kann eine beliebige Anzahl von Tags haben.
Technisch werden die Dokumente in ecoDMS in proprietären Container-Dateien abgelegt, in paperless-ngx liegen diese als Dateien mit der korrekten Dateiendung im Dateisystem. Es wird zusätzlich mittels Prüfsummen sichergestellt, das die Dokumente nicht verändert worden sind. Beide Lösungen verwenden eine relationale Datenbank für die Speicherung der Metainformationen, paperless-ngx verwendet in der empfohlenen Konfiguration PostgreSQL, ecoDMS hingegen MySQL.
In grundlegenden Bedienung für den Endanwender finden sich auch größere Unterschiede: ecoDMS setzt primär auf einen proprietären Client, welcher für Windows, Linux sowie MacOS verfügbar ist. Es existiert auch eine Web-GUI, welcher allerdings nicht wirklich als Alternative ist und eher als Notlösung zu betrachten ist. Paperless-ngx setzt ausschließlich auf eine Web-GUI, welche sich auf allen gängigen Browsern auch dynamisch an die Auflösung anpasst. Eine Nutzung mit einem Smartphone im Browser funktioniert somit grundsätzlich auch.
| Funktion | ecoDMS (24.02 burns) | paperless-ngx (2.15.3) |
Verfügbare Plattformen Server | Windows, Linux, Docker (primär für Synology NAS, aber auch für "vanilla" Linux nutzbar) | Linux (Bare-Install), Linux (Docker), Windows (mit Docker Desktop und WSL) |
Verfügbare Plattformen Client | Windows, Linux, MacOS (andere Systeme eingeschränkt mittels Web-GUI) | Alle Systeme mit einem modernen HTML5-Fähigen Browser |
| Automatische Klassifizierung eines Dokuments anhand von Barcode/OCR | Ja, es können Klassifizierungs-Vorlagen erstellt werden. Extraktion eines Inhalts aus einem spezifischen Teil des Dokuments, Unterstützung von allen gängigen Barcode-Typen. Prüfung des Wertes mittels RegEx, Attribute können als notwendig markiert werden, Verknüpfung der Vorlagen mit einem spezifischen QR-Code. Grafische Bearbeitung der Vorlagen, optional können bei spezifischen Vorlagen auch direkt Anpassungen an den ACLs der Dokumente vorgenommen werden. | Sehr eingeschränkt. Barcodes werden nur zum Trennen von Dokumenten unterstützt oder zum Zuordnen des ASN (Archive Serial Number). Auslesen von spezifischen Barcodes für custom fields nicht möglich. Keine Vorlagenverwaltung für die Klassifizierung, keine QR-Codes für die Zuordnung Dokumententypen oder ACLs, custom fields können nicht als notwendig markiert werden, keine Unterstützung für RegEx. |
| Erkennung von Duplikaten | Ja. | Ja. |
| Verarbeitung von Dokumenten in einem Ordner (Scan mittels Dokumenten-Scanner über SMB) | Ja, mit dem "scaninput"-Ordner. Zusätzlich ist mit einem zusätzlichen Add-In die Verarbeitung von E-Mails aus einem Postfach mittels IMAP möglich. Ohne Add-In funktioniert dies allerdings auch mit Einschränkungen direkt aus Outlook oder Thunderbird mit einem zusätzlichen Add-In, welches zusätzlich zu dem Client installiert werden muss. Die Verarbeitung erfolgt dann allerdings lokal auf dem Client. Hierbei werden allerdings die E-Mail sowie der Anhang archiviert. Die Anhänge werden dem Dokument in ecoDMS als Anhang angefügt, die Zugehörigkeit E-Mail zu den Anhängen ist immer klar ersichtlich. | Ja, mit dem "consume"-Ordner. Die Verarbeitung von E-Mails aus einem Postfach mittels IMAP oder OAuth ist ohne weitere Zusatzkomponenten möglich. Archivierung von E-Mail-Body oder der Anhänge möglich. Über Umwege auch beide Inhalte, allerdings dann als eigene eigenständige Dokumente ohne direkten Verweis. Keine Möglichkeit, Anhänge an Dokumente zu hängen. |
| Vollständiges OCR für PDF sowie Office-Dokumente und E-Mails (Nachrichtentext + Anhänge) | Ja, Erkennung sowie Unterstützung für alle gängigen Sprachen. Unterstützung für alle gängigen Office-Dokumente. | Ja, Erkennung sowie Unterstützung für alle gängigen Sprachen. Unterstützung für alle gängigen Office-Dokumente, falls mit den Komponenten "tika" und "gotenberg" installiert. |
| Unterstützung für Revisionen (alle Änderungen sind nachvollziehbar, es wird immer die neuste Revision geöffnet) | Ja, mit Anzeige der Revisions-Nummer (beginnt mit 1.0) | Nein, die Änderungen am Inhalt sowie den Metainformationen ist allerdings transparent sichtbar. |
| Speicherung des Originals ohne Änderungen an der Datei im System | Ja. | Ja. |
| Volltextsuche mit direktem "Abspringen" in das Dokument und der jeweiligen Seite | Ja. Es werden alle Treffer in der Suche angezeigt. Bei Auswahl eines Treffers wird direkt eine Vorschau des Dokumentes sichtbar, auf die spezifische Seite des Dokuments gewechselt und der gefundene Text grün hervorgehoben. | Nein (nur mit Zwischenschritt möglich). Es wird nur das jeweilige Dokument in den Suchergebnissen gefunden, aber die genaue Position wird nicht ersichtlich. Es muss somit erneut im Dokument eine erneute Suche gestartet werden. |
| Multi-User-Fähigkeiten mit gruppenbasiertem Berechtigungssystem (RBAC) + Zuweisen von Gruppen als Eigentümer des Dokuments | Ja. Dokumente können Benutzern sowie Gruppen zugewiesen werden. Benutzern und/oder Gruppen können spezifische Berechtigungen zugewiesen werden. | Eingeschränkt. Dokumente können nur Benutzern zugewiesen werden, aber keinen Gruppen. Benutzern und/oder Gruppen können spezifische Berechtigungen zugewiesen werden. Berechtigungen können etwas feinkörniger als bei ecoDMS definiert werden. |
| Das endgültige Löschen von Dokumenten darf nur durch Administratoren möglich sein | Ja. Benutzer ohne Superuser-Berechtigung können nur einen Löschvermerk setzen, das Dokument wird dann in der regulären Ansicht ausgeblendet. Alle Klassifizierungs-Attribute bleiben erhalten. | Ja, mit zusätzlichen Vorkehrungen. Eine Anpassung der Berechtigungen ist notwendig, um Benutzern nicht das Löschen von Dokumenten und das Leeren des Papierkorbs zu ermöglichen. Alle Klassifizierungs-Attribute bleiben erhalten. |
Migration der Daten zu paperless-ngx
Um die Bedienung von paperless-ngx auch möglichst realitätsnah zu testen, habe alle Bestandsdokumente von ecoDMS zu paperless-ngx migriert. Beide Systeme haben eine RESTful API, welche ich bei paperless-ngx auch für den Import verwendet habe, bei ecoDMS kommt die Export-Funktion zu Einsatz.
Hier findet sich das hierfür verwendete Skript: MichaelKirgus/ecodmstopaperlessngx-ng: A script to import an ecodms export to paperless ngx. Forked from eingemaischt/ecodmstopaperlessngx
Das Skript muss natürlich an die verwendeten Klassifizierungs-Attribute angepasst werden. Ich habe es etwas aufgebohrt, um z.B. auch die Authentifizierung mittels Token zu ermöglichen.
Hierbei kamen einige Unzulänglichkeiten der API von paperlesss-ngx für den Import zum Vorschein: Da ich gerne die benutzerdefinierten Klassifizierungsattribute von ecoDMS als custom fields in paperless importiert haben möchte, musste ich natürlich auch diese über die API setzen.
Leider unterstützt die API für den POST des Dokuments keine custom fields. Genauer: Es können zwar custom fields angegeben werden, diese sind aber alle leer, es kann also nicht direkt ein Wert zugewiesen werden. Workaround: POST des Dokuments, Warten auf Abschluss des Imports mittels Pulling der API, Extrahieren der ID in paperless-ngx, setzen der custom fields in einem 2. Aufruf. Dies macht den Import der Dokumente bei ca. 7.000 Elementen zu einem relativ zeitaufwendigen Vorgang.
Erfahrungen aus dem Import:
- Parallelisieren der Import-Prozesse auf 6 Instanzen (DocID 1-1000, 1001-2000, etc.)
- Möglichst hohes Limit des nutzbaren Speichers des PostgreSQL-Containers
Optimierung der Umgebungsvariablen PAPERLESS_TASK_WORKERS, PAPERLESS_THREADS_PER_WORKER, PAPERLESS_WORKER_TIMEOUT, PAPERLESS_WEBSERVER_WORKERS ist zu empfehlen.
Für den Importvorgang habe ich folgende Werte gesetzt:
- PAPERLESS_TASK_WORKERS=4 - PAPERLESS_THREADS_PER_WORKER=8 - PAPERLESS_WORKER_TIMEOUT=4000 - PAPERLESS_WEBSERVER_WORKERS=4Eine weitere Optimierung kann das definieren eines tempfs für den Pfad "/tmp" darstellen, da die Daten dort nur zwischengespeichert werden:
tmpfs: - /tmp
Testumgebung, verwendete Hardware:
Das System, auf welchem beide Lösungen getestet wurden, ist ein EPYC3451D4U-2L2T2O8R von ASRock Rack, mit einem AMD EPYC Embedded 3451 (16 Cores, 32 Threads). Im System kommen 512 GB DDR4 RDIMM Arbeitsspeicher zum Einsatz. EcoDMS sowie paperless-ngx laufen mittels docker-compose auf dem System. Als Betriebssystem wird TrueNAS Scale ElectricEel-24.10.2.1 verwendet. Es handelt sich um ein All-Flash-System, allerdings mit SATA-SSDs. Als Dateisystem kommt daher natürlich ZFS zum Einsatz, mit einem maximalen 64 GB ARC.
Beide Lösungen wurden mittels docker-compose auf 32 GB nutzbaren Arbeitsspeicher limitiert, die CPU-Nutzung wurde nicht explizit eingeschränkt.
Performance (der Kampf der Monolithen):
Am Anfang lief der Import recht zügig, doch ab ca. 5.000 Dokumenten wurde der Import merklich langsamer. Eine Erhöhung des Speichers für die Datenbank hat hier zu kaum einer Änderung geführt. Die Skalierung bei mehr als 10.000 Dokumenten ist vermutlich nicht besonders gut. Allerdings werden nicht alle 2 Tage viele tausend Dokumente auf einmal importiert, in der Praxis würde es wahrscheinlich kaum einen Unterschied für den Endbenutzer machen.
Beide Appliances sind an sich mehr oder weniger Monolithen, sie verwenden zwar eine eigene relationale Datenbank, eine Clusterung/HA mittels Kubernetes oder spezifische Container für z.B. die OCR-Verarbeitung, Duplikat-Erkennung, Webserver, etc. sind nicht vorgesehen. EcoDMS scheint allerdings hier bei einer größeren Anzahl von Dokumenten besser zu skalieren. Auffällig ist, dass ecoDMS Lucene (Apache Lucene - Welcome to Apache Lucene) als Text-Vektorsuche verwendet, paperless-ngx verwendet eine andere Implementierung in Python namens "Woosh" (Introduction to Whoosh — Whoosh 2.7.4 documentation).
Es existieren hier zwar Stellschrauben in paperless-ngx, diese haben auch bis zu einem gewissen Punkt durchaus einen Effekt, skalieren aber ab einem gewissen Punkt kaum noch weiter.
Fazit
Auch nach mehreren Wochen kann sich paperless-ngx leider nicht vollständig durchsetzen. Dies hat primär mit 2 wichtigen Punkten zu tun:
- Volltextsuche mit direktem "Abspringen" in das Dokument und der jeweiligen Seite
- In paperless-ngx leider zu umständlich
- Multi-User-Fähigkeiten mit gruppenbasiertem Berechtigungssystem (RBAC) + Zuweisen von Gruppen als Eigentümer des Dokuments
- Hier besonders ärgerlich: Das rollenbasierte Zugriffssystem ist grundsätzlich sogar besser als bei ecoDMS, leider fehlt die Möglichkeit, Gruppen als Eigentümer von Dokumenten zuzuweisen. Gerade bei Umgebungen, in welchen verschiedene Personen Zugriff auf Dokumente benötigen, leider ein "Show-Stopper".
Wichtig ist immer der genaue Use-Case. Für die Ablage von persönlichen Dokumenten ist paperless-ngx eine super Lösung, welche mit einer aufgeräumten aber sehr funktionalen Weboberfläche wirklich ecoDMS abhängt und zudem auch noch mit jedem Client-Betriebssystem nutzbar ist.
Sobald aber die Nutzung der Lösung durch verschiedene Personen mit Gruppen und wie oben beschrieben mehrere Personen die selben Zugriffe auf Dokumente benötigen wird es schwieriger. Die Funktion, Dokumenten auch Gruppen als Eigentümer zuzuweisen würde hier einen großen Mehrwert darstellen, es existiert hierfür bereits eine Diskussion auf der Projektseite:
Wäre die Thematik mit den Gruppen nicht, ist da aber das Thema der Performance und der Art und Weise, wie paperless-ngx die OCR-Daten speichert. Nach meiner Ansicht soll mir ein DMS eine möglichst schnelle Übersicht sowie Suche der Dokumente ermöglichen. Dies sollte möglichst schnell, benutzerfreundlich und selbsterklärend sein. Die Benutzerfreundlichkeit bekommt paperless-ngx sehr gut hin, sogar etwas besser als ecoDMS. Aber bei der Performance und der Suche wird es schwierig: Im Schnitt dauert es mindestens doppelt so lange, bis paperless-ngx Ergebnisse liefert. Das an sich wäre nicht schlimm, aber dann fehlt es auch noch an Präzision. Bei der Volltextsuche wird nur das jeweilige Dokument zurückgegeben, welches den Suchtext beinhaltet. Das führt dann zum doppelten Suche (Dokument suchen, Dokument öffnen, mit STRG + F erneut suchen). Das richtige Dokument doch nicht gefunden? Wieder zurück, Suche wiederholen, und so weiter. Ich habe dazu einen Feature Request eröffnet, er ist hier finden:
Vermutlich ist hier paperless-ngx einfach mit einem anderen Grundgedanken als Lösung für die persönliche Ablage an den Start gegangen. Ich sehe aber erhebliches Potenzial für die Lösung in der Zukunft. Die Web-Oberfläche ist super, es gibt Workflows, die Lösung kann E-Mails direkt verarbeiten. Unter der Haube gibt es bereits Unterstützung für SSO, was es dann ja schon wieder in den Enterprise-Bereich verschiebt.
paperless-ngx wird definitiv auf meiner "Watchlist" bleiben, bis dahin bleibt ecoDMS für meine spezifischen Anforderungen das System der Wahl.