Migration de Docuware

Migration de Docuware

Écrit par Josep Llort le 4 janvier 2018

Dans cet article, nous allons décrire la migration entre Docuware et OpenKM. Dans une publication précédente, j'avais déjà décrit un processus de migration. dans ce cas, entre Knowledgetree et OpenKM.

Docuware est un système de gestion de documents qui, entre autres différences par rapport à OpenKM, ne possède pas de version open source. c'est-à-dire qu'il s'agit d'une application proposée uniquement sous licence commerciale. Docuware Gmbh., Est le fabricant allemand de cette solution de gestion de documents.

Ensuite, je passerai brièvement en revue les principales fonctionnalités du logiciel de gestion de documents Docuware et les comparerai avec la solution de gestion de contenu d'entreprise proposée par OpenKM.

Tout d'abord, je voudrais souligner que Docuware est une solution installée uniquement dans un système d'exploitation Microsoft Windows. c'est-à-dire qu'en raison de son architecture, il s'agit d'une solution native de l'écosystème Microsoft. Contrairement au gestionnaire de documents OpenKM, dont l’architecture est basée sur JAVA, il s’agit donc d’un environnement multiplate-forme.

Dans OpenKM et je pense que nous pouvons l’étendre à la majorité des fabricants de solutions de gestion de documents, de gestion des enregistrements et de gestion de contenu d’entreprise; Nous conseillons à nos clients que, chaque fois que cela est possible, Linux soit utilisé comme système d'exploitation, dans ses différentes distributions. Nous recommandons Ubuntu, Debian, Centos et Red Hat. La raison est simple. avec le même matériel, Linux nous fournira toujours une performance supérieure, car le système d’entrée (E / S) est plus efficace. De plus, nous remarquerons qu'un serveur fonctionnant sous Windows a naturellement tendance à consommer au minimum 2 Go de mémoire, alors que sous Linux, la consommation de ressources par le système d'exploitation est beaucoup plus faible par défaut.

En bref, si nous nous trouvons dans un scénario où la "performance" est un facteur critique, nous devrions toujours envisager la possibilité d’installer Linux au lieu de Windows. Avec cela, nous ne nions pas la possibilité de configurer des environnements hautes performances sous Windows. Nous voulons simplement révéler une donnée objective; toutes choses étant égales par ailleurs, avec Linux, nous aurons des performances supplémentaires.

Comme je l'ai dit au début, une autre différence est le type de licence. Alors que le système de gestion d’OpenKM possède une double licence ("commerciale" et "open source"), Docuware n’est proposé que sous un seul modèle ("commercial").

En ce qui concerne les bases de données, nous pouvons vérifier que la solution de gestion de documents Docuware et OpenKM peuvent être configurés pour fonctionner avec Microsoft SQL Server, Oracle et MySQL Server. Dans le cas d’OpenKM, PostgreSQL peut également être utilisé. En ce qui concerne les bases de données, nous pouvons constater qu'OpenKM et Docuware, ou la majorité des fabricants de solutions de gestion de contenu, choisissent l'une de ces 4 bases de données relationnelles.

En général, nous trouverons des utilisateurs souhaitant utiliser la base de données Microsoft SQL Server, essentiellement dans des environnements Windows Server. Les bases de données PostgreSQL, Oracle, MySQL Server et MariaDB, nous les trouverons dans des environnements basés sur Linux.

Répartissez les référentiels de la gestion documentaire en deux grands groupes: ceux qui, comme OpenKM, utilisent une taxonomie et ceux qui n'utilisent pas ce paradigme. Le mot taxonomie a son origine dans la science, en particulier dans la biologie, où un mécanisme est nécessaire pour hiérarchiser et systématiser les groupes d'animaux et de plantes. Nous appellerons taxonomie, un système qui nous permet de classifier ou de classer par groupes les choses ayant des caractéristiques communes.

Les applications de gestion de documents telles que OpenKM, Nuxeo ou Alfresco utilisent le concept de taxonomie pour classifier les informations. En bref, la taxonomie en langage courant est une hiérarchie de dossiers qui nous permettent de trier et de classer les documents.

D'autres systèmes de gestion de documents tels que Documentum (maintenant ECM2), OnBase, y compris Docuware, utilisent le catalogage basé sur le concept de "boîtes". Dans le cas de Docuware, le nom correct serait "Cabinets". Un «cabinet» serait un placard ou un tiroir dans le monde réel, où un seul type de document est stocké (une seule série documentaire). Dans le cas de ces systèmes de gestion de documents, nous constaterons que pour chaque type de document, ils ont une "boîte" distincte ("Cabinet"); avec les métadonnées correspondantes pour le type de document attribué à chacune des cases.

Prenons un exemple: une entreprise qui stocke des factures et des contrats. Dans le cas d'une solution de gestion de documents telle qu'OpenKM, nous pourrions naviguer dans une arborescence de répertoires pour localiser les informations:

• / okm: root / Gestion de service / Contrats / 2019
• / okm: root / Gestion de service / Contrats / 2018
• / okm: root / Gestion de service / Factures / 2019
• / okm: root / Gestion de service / Factures / 2018

Dans le cas de Docuware, Documentum ou Onbase, nous devons au préalable sélectionner le type de document pour accéder à un écran de liste nous permettant d'affiner la recherche. Il n’y a pas de navigation en soi, mais un accès à la documentation, une connaissance préalable du type de document auquel nous souhaitons avoir accès.

Les premières solutions de gestion de documents, telles que Documentum et OnBase, sont apparues sous ce paradigme; probablement influencé par le déplacement exact du problème du monde réel vers des solutions informatiques. Dans le monde réel, les informations sont archivées sur des étagères et sur chaque étagère en fonction du type de documentation. Inspirées par cette solution, les premières applications offraient le même format conceptuel dans un environnement numérique.

Par la suite, les applications de gestion de documents, de gestion de contenu et de gestion de contenu d'entreprise les plus modernes ont opté pour un modèle basé sur la classification des informations dans une taxonomie.

À mon avis, les deux modèles présentent des avantages et des inconvénients. Dans le cas de solutions basées sur des taxonomies, au-delà de tout avantage au niveau de la facilité d'utilisation par l'utilisateur, le point le plus important est de rompre avec l'isolement des informations supposées par les Cabinets. C'est-à-dire; lorsque nous sommes confrontés non seulement à un problème de gestion de documents, mais à un problème de gestion des enregistrements (gestion de cas ou analyse de rentabilisation) où différents types de documents ont un cycle de vie interdépendant, l'approche de la solution basée sur les résultats "Cabinets" problématique

Dans un scénario où le gestionnaire de documents n'est pas un simple conteneur d'éléments de preuve de l'entreprise, mais il existe des workflows qui contrôlent le cycle de vie des documents; et en même temps, il y a des fichiers en cours, où plusieurs documents sont impliqués (analyse de rentabilisation), la solution basée sur les "Cabinets", de mon point de vue n’est pas la meilleure.

En général, les entreprises vont de plus en plus au-delà d’un simple conteneur de documents et souhaitent contrôler plus activement les informations. C’est là que les flux de travail et le plan de fichiers (plan de classification) apparaissent. Le problème ne concerne pas seulement le stockage, mais plutôt le contrôle de la validité, des modifications, ainsi que de la distribution et de l’accès à l’information au besoin. Et tout cela activement intégré dans l’activité de la société (nous trouvons ici des cas typiques d’intégration avec CRM, ERP, entre autres). Les applications de gestion de documents vont d'un simple conteneur à une partie active de l'écosystème logiciel avec lequel la société évolue.

Vous pouvez trouver plus d'informations dans le centre de connaissances Docuware .

Dans le cas de Docuware, qui est celui qui nous occupe maintenant; Depuis OpenKM, nous avons effectué plusieurs migrations. En particulier, au moment où j'écris cet article, nous avons effectué des migrations de la version 6.x et de la version 7.x.

Comme toujours, nous n'avons trouvé aucune information du fabricant afin que le client puisse extraire les données de leur référentiel. Le point de départ est répété comme dans le cas des migrations effectuées avec d'autres solutions de gestion de documents. Le client est emprisonné dans la solution informatique.

C'est pourquoi à partir d'ici, je veux faire appel de nouveau, comme je l'ai fait dans l'article sur la migration de Knowledgetree vers OpenKM. De mon point de vue, dans les processus d’acquisition d’un logiciel de gestion de documents, les futurs utilisateurs de ces outils concentrent tous leurs efforts sur les fonctionnalités de ces outils; La technologie sur laquelle ils sont basés, ainsi que les coûts. Laissant de côté l'évaluation d'un sujet que je considérerais comme clé; comment extraire nos données de ce système, dans le futur.

Le cas de Docuware est très similaire, du moins conceptuellement, à celui d’OnBase. Pour chaque "Cabinet", c'est-à-dire pour chaque type de document, un ensemble de tables spécifiques est créé, où les informations sont stockées séparément. C'est-à-dire; si nous avons 50 types de documents, l'application créera un minimum de 50 tables, chacune contenant les informations et les métadonnées de chaque type de document.

Un autre élément important dans le cas de Docuware est la manière dont les données sont stockées dans le système de fichiers. Il est possible que chaque type de document soit stocké dans une destination différente, c'est-à-dire que les documents binaires dépendant de ce type peuvent être stockés dans différentes unités. Cette flexibilité dans la configuration peut compliquer notre vie dans le processus de migration, car, en fonction du type de document, nous devons tenir compte du lieu où les informations se trouvent physiquement sur le disque.

Une autre curiosité de Docuware est la manière dont les fichiers sont stockés dans le système de fichiers. Par exemple, un fichier PDF de 32 pages se trouve séparément dans 32 fichiers d’une page chacun, c’est-à-dire; lorsque nous téléchargeons un fichier PDF (selon la configuration de Docuware), il est traité et stocké sous forme de 32 documents avec une page dans chacun d’eux. En ce qui concerne la manière de stocker les documents, nous avons constaté des variations selon que la version était 6.x ou 7.x et également selon le type de document PDF ou de fichier TIFF multipage.

Un autre problème qui se pose concerne la manière dont les métadonnées sont stockées, en particulier celles de type date. C’est un problème classique, que nous avons constaté dans pratiquement tous les processus de migration d’autres applications de gestion de documents et qui nécessite une attention particulière, afin de saisir la valeur de la date dans le format correspondant, puis de la stocker dans OpenKM dans un format. ISO8601.

Enfin, dernière curiosité de Docuware, le référentiel de disque contient un fichier pour chaque document, avec toutes les informations qu'il contient. C'est-à-dire; tout semble indiquer que le référentiel Docuware local fonctionne comme une exportation en direct du référentiel avec ses métadonnées. Cela implique évidemment que toute modification que nous allons apporter à l'application dans un document aura des effets à la fois au niveau de la base de données et de ces fichiers locaux. Cela a l'avantage que dans le référentiel, nous avons déjà une sauvegarde (exportation à chaud); mais en même temps, nous dupliquons toutes les données (base de données et système de fichiers) avec la consommation matérielle correspondante que cela implique. Cela implique également une logique complexe côté application,

Au moment où le département R & D d’OpenKM a procédé à l’analyse par reverse engineering pour effectuer la migration des données, nous avons jugé beaucoup plus pratique de traiter le processus de migration par le biais d’un script JAVA, qui fonctionne en combinaison avec la base de données et le système de fichiers, en le connectant à OpenKM via le SDK JAVA. Nous ignorons les entrées et traitons les fichiers texte contenant la structure de métadonnées de Docuware, car le format dans lequel ces informations sont stockées n’était pas évident, contrairement à OpenKM;  lorsque nous exportons la structure de métadonnées dans des fichiers, nous le faisons avec des fichiers au format JSON, ce qui facilite grandement leur traitement ultérieur.

Depuis le département R & D, nous étudions également le support de CMIS dans Docuware. Bien que nous ne nous déclarions pas fans de CMIS, il s'agit d'une option à envisager et, au moment de la rédaction de cet article, cet article n'était pas disponible. Nous avons trouvé quelques exemples de connexion via .NET avec l'API Docuware, comme nous pouvons le voir dans cet exemple d'  API Docuware. C’est un chemin que nous avons jeté à l’époque, en partie à cause de l’environnement de développement Microsoft complet à assembler, mais que nous considérons comme une option à prendre en compte pour tous ceux qui souhaitent migrer leur référentiel. Tout semble indiquer que le package DocuWarePlatformApi consiste en un ensemble de bibliothèques (similaire à ce que nous avons dans OpenKM sous le nom de SDK pour JAVA, .NET et PHP) qui permettent d'accéder très facilement à toutes les fonctionnalités du référentiel, via les Webservices dans REST.

En général, lorsque cela est possible et que nous disposons d’une API pour attaquer un référentiel, il est conseillé de l’utiliser comme première approche pour résoudre le problème.

Nous manquons d'un service REST mieux documenté; nous n'avons pas pu localiser la documentation en ligne. Sous OpenKM, comme d’autres fabricants, nous avons opté pour l’option permettant à la documentation du service REST d’être disponible via Swagger.io; de la documentation elle-même comme indiquée dans cette section:  swagger

J'espère que cet article pourra servir d'introduction à tous les utilisateurs qui souhaitent migrer à l'avenir leurs données depuis Docuware. Et que l'expérience que nous essayons de partager ici facilitera en quelque sorte la solution du problème. Le processus de migration des référentiels Docuware que nous avons migrés était très similaire, mais pas exactement identique. Nous ne pouvons donc pas vous fournir une recette magique utile dans tous les cas. Dans cet article, j'ai essayé de partager une connaissance "commune" que je considère réutilisable dans tous les scénarios dans lesquels, du moins, nous nous sommes rencontrés.

Quelques URL d'intérêt:

• API Docuware Platform .NET
• Exemples de code
• Plate-forme en tant que service REST