DMS, OpenKM
Migration von Docuware nach OpenKM
Bei OpenKM sind wir davon überzeugt, dass die Informationen dem Benutzer gehören. Deshalb hütet OpenKM die Informationen der Kunden anstatt sie zu verschließen.
Original: Geschrieben von Josep Llort am 4. Januar 2018
In diesem Artikel wird die Migration zwischen DocuWare und OpenKM beschrieben. In einer früheren Veröffentlichung habe ich bereits einen Migrationsprozess beschrieben; in diesem Fall zwischen KnowledgeTree und OpenKM.
DocuWare ist ein Dokumentenmanagement-System, das neben vielen anderen Unterschieden zu OpenKM keine Open-Source-Version hat, d.h. es ist eine Anwendung, die nur unter einer kommerziellen Lizenz angeboten wird. Die DocuWare Gmbh ist der deutsche Hersteller dieser Dokumentenmanagement-Lösung.
Im Folgenden werde ich kurz auf die Hauptmerkmale der Dokumentenmanagement-Software DocuWare eingehen und sie mit der Enterprise-Content-Management-Lösung von OpenKM vergleichen.
Zunächst möchte ich hervorheben, dass DocuWare eine Lösung ist, die nur in einem Microsoft Windows-Betriebssystem installiert wird; das heißt, dass es sich bei seiner Architektur um eine native Lösung des Microsoft-Ökosystems handelt. Im Gegensatz zum OpenKM-Dokumentenmanager, dessen Architektur auf JAVA basiert, handelt es sich also um eine Multiplattformumgebung.
Bei OpenKM, und ich denke wir können dies auf die meisten Hersteller von Dokumentenmanagement-Lösungen, Records Management und Enterprise Content Management ausdehnen, raten wir unseren Kunden, wann immer möglich, Linux in seinen verschiedenen Distributionen als Betriebssystem zu verwenden. Wir empfehlen Ubuntu, Debian, Centos und Red Hat. Der Grund dafür ist einfach: Bei gleicher Hardware bietet Linux immer eine höhere Leistung als andere Betriebssysteme, da das Eingabesystem (I/O) effizienter ist. Darüber hinaus verbrauchen Windows-Server mindestens 2 GB Speicher in der Grundlast, während Linux viel niedrigere Ressourcenverbräuche hat.
Kurz gesagt, wenn wir uns in einem Szenario befinden, in dem „Leistung“ ein kritischer Faktor ist, sollten wir immer die Möglichkeit in Betracht ziehen, Linux anstelle von Windows zu installieren. Damit leugnen wir nicht die Möglichkeit, unter Windows leistungsfähige Umgebungen zu installieren. Wir wollen lediglich objektive Daten aufzeigen; unter allen Umständen werden wir mit Linux eine bessere Leistung erzielen.
Ein weiterer Unterschied ist wie bereits erwähnt, die Art der Lizenz. Während das OpenKM-Managementsystem eine Doppellizenz hat („kommerziell“ und „Open-Source“), wird DocuWare nur unter einem einzigen Modell („kommerziell“) angeboten.
Was die Datenbanken betrifft, so können wir feststellen, dass sowohl die Dokumentenmanagementlösung DocuWare als auch OpenKM für die Arbeit mit Microsoft SQL Server, Oracle und MySQL Server konfiguriert werden können. Im Falle von OpenKM kann auch PostgreSQL verwendet werden. Was die Datenbanken betrifft, so können wir feststellen, dass sowohl OpenKM als auch DocuWare oder die meisten Hersteller von Content-Management-Lösungen eine dieser vier relationalen Datenbanken wählen.
Im Allgemeinen finden wir Benutzer, die die Microsoft SQL Server-Datenbank verwenden möchten, hauptsächlich in Windows Server-Umgebungen, während wir PostgreSQL-, Oracle-, MySQL Server- und MariaDB-Datenbankbenutzer in Linux-basierten Umgebungen finden.
Unterteilen Sie die Repositories für das Dokumentenmanagement in zwei große Gruppen: solche wie OpenKM, die eine Taxonomie verwenden, und solche, die dieses Paradigma nicht verwenden. Das Wort Taxonomie hat seinen Ursprung in der Wissenschaft, insbesondere in der Biologie, wo ein Mechanismus zur Hierarchisierung und Systematisierung der Tier- und Pflanzengruppen benötigt wird. Die Taxonomie ist ein System, das die Klassifizierung oder Einordnung von Dingen, die gemeinsame Merkmale aufweisen, in Gruppen ermöglicht.
Dokumentenmanagement-Anwendungen wie OpenKM, Nuxeo oder Alfresco verwenden das Konzept der Taxonomie, um Informationen zu klassifizieren. Kurz gesagt, ist die Taxonomie in der Umgangssprache eine Hierarchie von Ordnern, die es uns ermöglicht, Dokumente zu sortieren und zu klassifizieren.
Andere Dokumentenmanagementsysteme wie Documentum (jetzt ECM2), OnBase, zu dem auch DocuWare gehört, verwenden eine Katalogisierung, die auf dem Konzept der „Boxen“ basiert. Im Falle von DocuWare wäre die korrekte Bezeichnung „Cabinets“. Ein „Cabinet“ wäre in der realen Welt ein Schrank oder eine Schublade, in der ein einzelner Dokumententyp (eine einzelne Dokumentenserie) abgelegt wird. Bei diesen Dokumentenmanagementsystemen gibt es für jede Dokumentenart eine eigene „Box“ („Cabinet“), wobei jeder Box die entsprechenden Metadaten für die Dokumentenart zugeordnet sind.
Nehmen wir ein Beispiel: ein Unternehmen, das Rechnungen und Verträge speichert. Bei einer Dokumentenmanagementlösung wie OpenKM könnten wir durch einen Verzeichnisbaum navigieren, um die Informationen zu finden:
/ okm: root / Abteilungsleitung / Verträge / 2019
/ okm: Stamm / Abteilungsmanagement / Verträge / 2018
/ okm: Stamm / Abteilungsverwaltung / Rechnungen / 2019
/ okm: Stamm / Abteilungsverwaltung / Rechnungen / 2018
Im Falle von DocuWare, Documentum oder Onbase muss zunächst die Art des Dokuments ausgewählt werden, um zu einem Listenbildschirm zu gelangen, mit dem die Suche verfeinert werden kann. Es gibt keine eigentliche Navigation, aber der Zugriff auf die Dokumentation erfordert die vorherige Kenntnis der Art des Dokuments, auf das man zugreifen möchte.
Die ersten Dokumentenverwaltungslösungen wie Documentum und OnBase entstanden unter diesem Paradigma, wahrscheinlich beeinflusst durch die Übertragung der realen Organisationsstruktur auf Computerlösungen ohne jegliche Änderungen. In der realen Welt werden die Informationen in Regalen archiviert, wobei jedes Regal nach der Art der Dokumentation geordnet ist. Inspiriert von dieser Lösung boten die ersten Anwendungen das gleiche konzeptionelle Format in einer digitalen Umgebung.
In der Folge haben sich die modernsten Anwendungen für Dokumentenmanagement, Content Management und Enterprise Content Management für ein Modell entschieden, das auf der Klassifizierung von Informationen innerhalb einer Taxonomie basiert.
Beide Modelle haben meiner Meinung nach Vorteile und einige Nachteile. Bei Lösungen, die auf Taxonomien beruhen, liegt der wichtigste Punkt, abgesehen von den Vorteilen für die Benutzerfreundlichkeit, darin, dass die Isolierung der Informationen, die die Schränke mit sich bringen, aufgehoben wird. Das heißt: Wenn wir es nicht nur mit einem Problem der Dokumentenverwaltung, sondern mit einem Problem der Aktenverwaltung (Case Management oder Business Case) zu tun haben, bei dem verschiedene Arten von Dokumenten einen miteinander verbundenen Lebenszyklus haben, wird der Lösungsansatz auf der Grundlage von „Cabinets“ problematisch.
Es gibt ein häufiges Szenario, in dem der Dokumentenmanager nicht nur ein einfacher Behälter für Unternehmensdokumente ist, sondern einen Workflow hat, der den Lebenszyklus der Dokumente steuert. Gleichzeitig gibt es Akten in Bearbeitung, an denen mehrere Dokumente beteiligt sind (Geschäftsfall). In diesem Szenario ist die Lösung auf der Basis von „Cabinets“ aus meiner Sicht nicht die Optimalste.
Im Allgemeinen gehen Unternehmen zunehmend über die bloße Ablage von Dokumenten hinaus und wollen Informationen aktiver steuern. An diesem Punkt setzen sowohl die Workflows als auch der Aktenplan (Aktenplan und Disposition) an. Es geht nicht mehr nur um die Aufbewahrung, sondern vielmehr um die Kontrolle der Gültigkeit, der Änderungen sowie der Verteilung und des Zugriffs auf Informationen, wenn diese benötigt werden. Und all dies wird aktiv in die Tätigkeit des Unternehmens integriert (hier finden wir typische Fälle von Integrationen mit CRM und ERP, unter anderem). Anwendungen zur Verwaltung von Dokumenten werden von einem bloßen Container zu einem aktiven Teil des Software-Ökosystems, mit dem das Unternehmen arbeitet.
Weitere Informationen finden Sie im DocuWare Knowledge Center.
Im Falle von DocuWare, um das es hier geht, haben wir mehrere Migrationen zu OpenKM durchgeführt. Insbesondere haben wir in dem Moment, in dem ich diesen Artikel schreibe, Migrationen sowohl von Version 6.x als auch von Version 7.x durchgeführt.
Wie üblich haben wir vom Hersteller keine Informationen gefunden, die seinen Kunden bei der Extraktion ihrer Daten aus seinem Repository helfen. Dieser Punkt wiederholt sich wie bei den Migrationen, die wir mit anderen Dokumentenmanagementlösungen durchgeführt haben. Der Kunde ist in der Computerlösung gefangen.
Deshalb möchte ich von hier aus noch einmal appellieren, so wie ich es in dem Artikel über die Migration von KnowledgeTree zu OpenKM getan habe. Meines Erachtens konzentrieren sich die zukünftigen Nutzer dieser Tools bei der Anschaffung einer Dokumentenmanagement-Software voll und ganz auf die Funktionalitäten der Tools, die Technologie, auf der sie basieren, sowie auf die Kosten. Sie lassen die Bewertung eines Themas beiseite, das ich für entscheidend halte: wie wir unsere Daten in Zukunft aus diesem System herausbekommen.
Der Fall von DocuWare ist sehr ähnlich, zumindest konzeptionell zu OnBase. Für jedes „Cabinet“, d.h. für jede Art von Dokument, wird eine Reihe spezifischer Tabellen erstellt, in denen die Informationen separat gespeichert werden. Das heißt: Wenn wir 50 Dokumenttypen haben, erzeugt die Anwendung mindestens 50 Tabellen, von denen jede die Informationen und Metadaten jedes Dokumenttyps enthält.
Von Bedeutung ist bei DocuWare auch, wie die Daten im Dateisystem abgelegt werden. Es besteht die Möglichkeit, dass jeder Dokumententyp an einem anderen Ort gespeichert wird, d.h. binäre Dokumente können je nach Typ in unterschiedlichen Einheiten gespeichert werden. Diese Flexibilität in der Konfiguration kann das Leben im Migrationsprozess erschweren, denn je nach Art des Dokuments muss berücksichtigt werden, wo sich die Informationen physikalisch auf der Platte befinden.
Ein weiteres Kuriosum von DocuWare ist die Art und Weise, wie Dateien im Dateisystem gespeichert werden. Eine 32-seitige PDF-Datei wird beispielsweise in 32 Dateien zu je einer Seite aufgeteilt; wenn wir eine PDF-Datei hochladen (je nach Konfiguration von Docuware), wird sie in Form von 32 Dokumenten zu je einer Seite verarbeitet und gespeichert. Hinsichtlich der Art und Weise, wie Dokumente gespeichert werden, haben wir Unterschiede festgestellt, je nachdem, ob es sich um die Version 6.x oder 7.x handelt, und auch je nach Art des PDF-Dokuments oder des mehrseitigen TIFFs.
Ein weiteres Problem, das sich stellt, ist die Art und Weise, wie Metadaten gespeichert werden, insbesondere solche vom Typ Datum. Dies ist ein klassisches Problem, das wir bei praktisch allen Migrationsprozessen anderer Dokumentenverwaltungsanwendungen festgestellt haben und das besondere Aufmerksamkeit erfordert, um den Wert des Datums in dem entsprechenden Format zu erfassen und dann in OpenKM in einem Format ISO8601 zu speichern.
Das letzte Kuriosum von DocuWare ist schließlich, dass das Disk-Repository für jedes Dokument eine Datei mit allen Informationen des Dokuments enthält. Das heißt, alles deutet darauf hin, dass das lokale DocuWare-Repository wie ein Live-Export des Repository mit seinen Metadaten funktioniert. Das bedeutet, dass jede Änderung, die wir aus der Anwendung heraus an einem Dokument vornehmen, sich sowohl auf der Datenbankebene als auch in diesen lokalen Dateien auswirkt. Dies hat den Vorteil, dass wir im Repository bereits ein Backup haben (Hot-Export); aber gleichzeitig duplizieren wir alle Daten (Datenbank und Dateisystem) mit dem entsprechenden Hardware-Verbrauch, den all dies mit sich bringt. Dies bedeutet auch eine komplexe Logik auf der Anwendungsseite, um diese Daten regelmäßig zu synchronisieren.
Als die OpenKM-Forschungs- und Entwicklungsabteilung die Reverse-Engineering-Analyse für die Migration der Daten durchführte, hielten wir es für viel bequemer, den Migrationsprozess mit einem JAVA-Skript zu bewältigen, das in Kombination mit der Datenbasis und dem Dateisystem arbeitete und es über das JAVA-SDK mit OpenKM verband. Wir verwerfen die Eingabe und verarbeiten die Textdateien, die die DocuWare-Metadatenstruktur enthalten, da das Format, in dem diese Informationen gespeichert sind, im Gegensatz zu OpenKM nicht sichtbar war. Wenn wir die Struktur der Metadaten in Dateien exportieren, tun wir dies mit Dateien im JSON-Format, was die spätere Verarbeitung erheblich erleichtert.
In der Forschungs- und Entwicklungsabteilung untersuchen wir auch die Unterstützung von CMIS in DocuWare. Obwohl wir uns nicht als CMIS-Fans bezeichnen, ist es eine Option, die man in Betracht ziehen sollte und die zum Zeitpunkt der Erstellung dieses Artikels noch nicht verfügbar ist. Wir haben einige Beispiele für die Verbindung über .NET mit der DocuWare-API gefunden, wie wir in diesem Beispiel sehen können DocuWare-API. Ein Weg, den wir einst verworfen haben, unter anderem wegen der gesamten Microsoft-Entwicklungsumgebung, die aufgebaut werden muss, den wir aber für alle, die ihr Repository migrieren wollen, als eine zu berücksichtigende Option ansehen. Alles deutet darauf hin, dass das DocuWare Platform API-Paket eine Reihe von Bibliotheken umfasst (ähnlich dem, was wir in OpenKM unter dem Namen SDKs für JAVA, .NET und PHP haben), die den mühelosen Zugriff auf alle Funktionalitäten des Repositorys über die Webservices in REST ermöglichen.
Wenn es möglich ist und wir eine API haben, von der aus wir ein Repository ansprechen können, ist es im Allgemeinen ratsam, diese als ersten Ansatz zur Lösung des Problems zu verwenden.
Ohne einen besser dokumentierten REST-Dienst waren wir nicht in der Lage, die Dokumentation online zu finden. In OpenKM haben wir uns, wie andere Hersteller auch, für die Option entschieden, dass die Dokumentation des REST-Dienstes selbst über Swagger.io zur Verfügung steht; aus der Dokumentation selbst, wie in diesem Abschnitt angegeben: swagger
Ich hoffe, dass dieser Artikel all jenen Anwendern als Einführung dienen kann, die in Zukunft ihre Daten aus DocuWare migrieren möchten. Und dass die Erfahrungen, die wir hier versuchen zu teilen, in irgendeiner Weise die Lösung des Problems erleichtern. Die von uns durchgeführten Migrationen der DocuWare-Repositories waren zwar sehr ähnlich, aber nicht gleich, so dass es kein Patentrezept gibt, das in allen Fällen hilfreich ist. In diesem Artikel habe ich versucht, das Allgemeinwissen weiterzugeben, das ich in allen Szenarien, in denen wir uns getroffen haben, für wiederverwendbar halte.
Einige interessante URL’s:
