Migration Knowledge Tree

Migration Knowledge Tree

Ecrit par Josep Llort le 24 Août 2018

Lors de l’achat d’un logiciel de gestion de documents, les futurs utilisateurs de ces outils concentrent trop souvent tous leurs efforts sur les fonctionnalités des systèmes pour améliorer leur expérience utilisateur. Certains peuvent se préoccuper de la technologie utilisée pour créer leur base de connaissances ainsi que des coûts, mais laisser de côté l'évaluation d'un sujet que nous considérons comme essentiel; comment obtenir nos données de ce système dans le futur.

Dans la citation précédente, nous pouvons étendre à d'autres types de logiciels tels que ERP ou CRM, entre autres. En général, lorsque nous acquérons un logiciel, une relation "presque à vie" est établie, ce que nous pourrions parfois appeler " un mariage". Ce fait peut passer inaperçu au début, mais avec le temps, il devient plus évident. Et c’est parce que le logiciel arrive en peu de temps à occuper un point central de la société, créant une forte dépendance sur laquelle il n’est pas si simple, ni facile de se débarrasser.

Enfin, ce choix simple fait il y a des années peut devenir une prison. Avoir le logiciel doté de "notre base d'informations ou de connaissances" (information or knowledge base), à laquelle nous pouvons accéder, gérer et presque rien de plus. Nous pouvons utiliser la métaphore suivante; "Nous mettons l'argent dans une banque, nous pouvons retirer de petites sommes via le guichet automatique, mais nous ne pouvons pas transférer tout notre capital vers une autre entité."

Je me concentrerai particulièrement sur les logiciels de gestion documentaire, qu'ils soient open source ou non; Bien que, comme je l'ai dit précédemment, cet article puisse être appliqué à la plupart des solutions informatiques.

Un cas paradigmatique - sans oublier l’extrême - que nous avons trouvé avec KnowledgeTree, un logiciel de gestion de documents sous la forme d’une application Web, avec une architecture classique basée sur le langage open source de PHP et une base de données MySQL (l’architecture classique de LAMP).

En raison de sa facilité d'installation et de sa simplicité, il a été bien accueilli par la communauté des utilisateurs open source. L'utilisation de cette application a donc été un succès. Jusque-là, tout était parfait.

Fin 2012, la société derrière KnowledgeTree a décidé de retirer le logiciel de gestion de documents open source Community Edition, éliminant ainsi sa distribution, ainsi que le code source sur SourceForge et autres serveurs de logiciels libres.

Depuis cette décision, les utilisateurs ont essentiellement trois options: continuer avec une application open source sans aucun type de support, dans lequel aucune nouvelle version ni aucun correctif ne seront publiés; passez à la version SaaS de KnowledgeTree ou simplement passer à la compétition. Nous pouvons nous questionner sur la décision de l’entreprise. Tout cela est très légal, bien que cela déplaise à beaucoup mais éthiquement discutable…

Un jour, nous nous réveillons et nous avons notre système de gestion de documents obsolète, sans correctifs pour les bugs (avec le risque que cela implique), nos informations sont emprisonnées dans le logiciel et nous ne savons pas comment les récupérer. Nous devrions en tirer une leçon: lors de la sélection d'un logiciel, il est important de prendre en compte les possibilités et les coûts, associé à la récupération des données, car nous devrons peut-être migrer nos données à nouveau. Par conséquent, il est tout à fait judicieux d'évaluer ce scénario et de garder à l'esprit la manière dont ces processus de migration sont établis et les installations fournies par le fabricant afin de le mener à bien.

Dans OpenKM, nous partons toujours du principe que les informations appartiennent à l'utilisateur et que notre logiciel doit en être le dépositaire, mais pas le geôlier. Pour cette raison, depuis la première version d'OpenKM, nous disposons par défaut d'un système d'importation et d'exportation de fichiers et de métadonnées. De plus, dans le cadre de la documentation de l'application, nous expliquons la structure de base de la base de données au cas où quelqu'un aurait besoin d'accéder à l'application au niveau de la base de données. De plus, avec l'API Webservices complète, il est possible d'implémenter la logique nécessaire pour exporter les données de manière très simple.

En général, un processus de migration d’un système de gestion de documents peut être proposé d’au moins trois manières:

1. L'outil a un utilitaire d'exportation.
2. L'outil a dans la documentation le "DER" des parties fondamentales de la base de données.
3. L'outil dispose d'une API à travers laquelle et avec une logique minimale, il est possible d'extraire toutes les informations. Nous ne parlons pas seulement de fichiers mais de métadonnées, de sécurité, etc.

Chez OpenKM, il est assez courant que les utilisateurs d'autres gestionnaires de documents nous demandent de migrer leurs données vers OpenKM - dans d'autres articles, je développerai d'autres cas particuliers -. Dans la plupart des cas, les utilisateurs ignorent si leur gestionnaire de documents dispose d'une API. En aucun cas, sauf avec OpenKM, nous avons trouvé un fabricant doté d'un utilitaire d'exportation simple et intégré, tout en vous permettant d'extraire toutes les données. Quand je parle de toutes les données, je ne parle pas seulement des documents, mais de toutes les versions des documents; ainsi que les métadonnées associées, la sécurité appliquée, le nom de l'utilisateur et le moment, les notes, etc.

Je me souviens parfaitement d'avoir testé un utilitaire Alfresco il y a quelques années pour exporter le référentiel. L’invention a généré un fichier ZIP de 20 Go, totalement infumable avec leur code XML respectif et, pour un cauchemar plus grand, elle l’a incorporé dans le gestionnaire de documents. Quelqu'un, un jour, devra m'expliquer la logique de l'esprit qui a conçu un système d'exportation grâce auquel le fichier d'exportation finit par entrer dans le système de gestion de documents lui-même. La déclaration "Si ce n'est pas compliqué et bizarre" ne semble pas être bonne, je pense que nous devrions travailler à bannir cette tendance.

Pour revenir au fil de la question, il est évident que le DER de la base de données doit être fourni par le fabricant ou indiquer quelles sont les principales tables à prendre en compte pour identifier nos données dans l’application, en général; ils ne nous le donneront pas non plus. Dans la plupart des licences de logiciels, sinon toutes, il est explicitement interdit de procéder au reverse engineering des applications. Mais soyons clairs, ces restrictions sont spécifiées afin que le concours n'incorpore pas avec joie les fonctionnalités tierces, ce qui se produit malheureusement aussi. Voici un autre avis pour les navigateurs, je me méfierais de ceux qui sont plus dédiés à la copie du voisin, que de mettre en œuvre leur propre solution.

Dans le cas de la solution de gestion de documents KnowledgeTree, nous n’avons pas d’utilitaire d’exportation. Nous avons une API dans laquelle nous allons trouver des services basés sur CMIS et RESTful: http://orion.knowledgetree.com/KnowledgeTree_API_Documentation

Si nous voulons migrer toutes les informations, nous ne parlons pas seulement de documents mais également de métadonnées. Nous verrons que dans les deux cas, la mise en œuvre de l'API, à la fois dans RESTful et dans CMIS, est insuffisante à cet effet. Personnellement, je trouve le CMIS décevant - dans un article, je vais essayer de parler de notre expérience avec cette API qui se veut un mécanisme d’interopérabilité entre différentes applications de gestion de documents, mais qui pour moi est courte et ne pose pas de gros problèmes -.

En fin de compte, nous n’aurons pas d’autre choix que d’examiner la structure de la base de données pour déterminer où se trouve l’information, sous quels formats et sous quelle forme son exportation devrait-elle être envisagée.

Chez OpenKM, nous avons effectué des migrations de différentes applications de gestion documentaire de KnowledgeTree via Docuware, Cannon Document Management ou IBM Content Management, entre autres. Dans le cas de KnowledgeTree, il a été possible de développer un outil de migration DMS vers OpenKM, qui automatise ce processus. Malheureusement, il n'est pas possible dans tous les cas de créer un processus de migration unique. Les raisons sont diverses.

Au final, comme dans de nombreuses autres applications, la récupération de documents électroniques à partir de ce gestionnaire de documents dépendra de notre capacité à identifier au niveau de la base de données où se trouvent les informations.

Description de la base de données

À ce stade de l'article, la plupart des rédacteurs nous laissent votre destin avec notre application de gestion de documents KnowledgeTree et sa base de données. Nous essaierons de fournir tous les indices dont nous disposons pour interpréter cette base de données à partir de la dernière version disponible de KnowledgeTree, en particulier la version 3.7.

Il semble que dans les tableaux suivants, vous trouverez les commentaires concernant les nœuds (en général, il est fort probable que cette information ne soit pas très pertinente pour nous):

• comment_searchable_text
• discussion_comments
• discussion_threads

Nous allons trouver les types de documents dans le tableau:

• document_types_lookup

Les documents sont dans la table (l'application fonctionne avec les versions de document):

• document_content_version

Les métadonnées des documents se trouvent dans les tableaux (si nous avons de la chance, notre référentiel n'aura pas de métadonnées, car cette partie de la structure est un peu fastidieuse):

• document_fields
• document_fields_link
• document_metadata_version
• document_type_fieldsets_link
• fieldsets
• metadata_lookup
• metadata_lookup_tree

Les relations entre les documents se trouvent dans les tableaux:

• document_link_types
• document_link

Les utilisateurs abonnés aux documents et aux dossiers se trouvent dans les tableaux:

• document_subscriptions
• folder_subscriptions

Les mots-clés, mots-clés ou balises (selon la façon dont nous voulons les appeler) peuvent être trouvés dans le tableau:

• document_tags

Titres dans les dossiers, dans le tableau:

• folder_searchable_text

Les privilèges dans la table:

• permissions

La partie privilèges est complexe à comprendre. Il y a plus d’un tableau, mais ceux que nous considérons vraiment pertinents sont ceux que nous avons détaillés précédemment.

Conclusion

Au moment d'acquérir une DMS, il serait vraiment intéressant de vous donner une description minimale du DER de la base de données. Si nous observions une application sous la forme d'un organisme du corps humain, nous pourrions identifier la base de données comme étant la partie du cerveau humain où les informations sont stockées. Un stockage incorrect rendra difficile non seulement l'accès, mais également la performance du processus de données. (DER manquant ou incomplet).

Lorsque nous examinons certaines bases de données, nous nous trouvons avec des choses plutôt curieuses qui nous inciteraient probablement à repenser, dans de nombreux cas, les choix. En général, une DER - relation d'entité de diagramme - d'une base de données extrêmement complexe à comprendre, devrait au moins déclencher une certaine alarme. Dans certains cas, cela peut être justifié. Dans d'autres, c'est dû - de mon point de vue - qu'il a été basé sur des idées incorrectes ou une mauvaise exécution. S'il est vrai que les bases de données évoluent au fil du temps, il est également vrai que s’il y’a de graves erreurs de conception au niveau de la base de données, il n’est pas facile de les résoudre et le temps les mettra en évidence.

Liens utiles :

http://orion.KnowledgeTree.com/Main_Page
https://tramullas.com/KnowledgeTree-desaparecido-en-combate/
https://boyter.org/2015/09/exporting-documents-KnowledgeTree-3-7-0-2/