Subscríbase al boletin de noticias de OpenKM para estar informado

Migración de KnowledgeTree

Escrito por Josep Llort en agosto 24, 2018

Desde mi punto de vista, en los procesos de adquisición de un software de gestión documental, los futuros usuarios de estas herramientas, concentran todos sus esfuerzos en las funcionalidades de las herramientas. La tecnología en la que éstas se sustentan así como los costes, dejando de lado evaluar un tema que yo consideraría clave; cómo poder sacar nuestros datos de este sistema en el futuro.

La anterior afirmación la podemos hacer extensible a otros tipos de software tales como ERP o CRM, entre muchos otros. En general, cuando adquirimos un software se establece una relación, que en algunos casos podríamos llamar de “matrimonio”, casi de por vida. Este hecho nos puede pasar desapercibido en un principio, pero que con el paso del tiempo se hace más evidente. Y esto es debido que el software pasa en poco tiempo a ocupar un punto central de la empresa, creándose una fuerte dependencia de la que no es tan sencillo, ni conveniente librarse.

Al final, aquella feliz elección que hicimos años atrás, se puede convertir en una prisión, habiéndose el software apoderado de “nuestra información” a la cual podemos acceder, gestionar y poco más. Utilizaría la siguiente metáfora; “hemos puesto el dinero en un banco, podemos sacar pequeñas cantidades por el cajero automático, pero nos resulta imposible mover todo nuestro capital a otra entidad”.

Me concentraré en especial, en los software de gestión documental, sean o no de código abierto; aunque como he dicho anteriormente éste artículo, puede aplicarse a la mayoría de soluciones informáticas.

Un caso paradigmático - por no decir extremo - lo encontramos con KnowledgeTree, un software de gestión documental en forma de una aplicación web, con una arquitectura clásica basada en el lenguaje de código abierto de PHP y una base de datos MySQL ( la clásica arquitectura LAMP ).

Por la facilidad de instalación y su simplicidad tuvo una buena acogida entre la comunidad de usuarios open source, por lo que la utilización de esta aplicación se extendió con bastante éxito. Hasta aquí todo perfecto.

A finales de 2012, la empresa detrás de KnowledgeTree decide cerrar el grifo a la comunidad open source, eliminando la distribución del mismo, así como el código fuente en sourceforge y otros servidores de software libre.

En este escenario, los usuarios tienen básicamente dos opciones; continuar con una aplicación de código abierto sin ningún tipo de soporte, en la cual no saldrían ni nuevas releases ni parches;  o bien pasarse a un modelo SaaS ( Software as a Service ). Efectivamente, era el momento de hacer caja; por muy mala prensa que esto te pueda dar, el dólar para algunos va delante de todo lo demás. Todo muy legal, aunque para disgusto de muchos y como mínimo, éticamente discutible.

Una historia desagradable, que algunos habrán sufrido en carne propia. Sea por la razón que sea, al final nos encontramos con una aplicación web de gestión documental – document management – en la cual tenemos prisionero uno de nuestros activos más importantes, los documentos electrónicos. Podemos llegar a este punto por distintos caminos; casos como el anteriormente detallado, empresas que desaparecen de un día para otro, obsolescencia de alguna aplicaciones que no han podido o sabido renovarse o empresas que han decido congelar las aplicaciones. En este último caso nombraré a Activiti, un BPM en el que participa activamente Alfresco, o participaba activamente - no está muy claro - pero los hechos son los hechos. Todo parece indicar que en el último año, todos los esfuerzo han ido a parar a la versión de pago y el proyecto,  en un año y medio ha sido incapaz de salir adelante de más allá de una versión Beta, que parece eterna. Aviso para navegantes; los desarrolladores padres de la criatura, viendo el estado de la nación, han creado su propio fork llamado Flowable, algo que resulta como mínimo inquietante. Es bastante probable que alguien esté pensando en como llenar la caja de dólares.

Un día nos levantamos y tenemos nuestro sistema de gestión documental obsoleto, sin parches para los bugs ( con el riesgo que esto implica ), nuestra información se encuentra prisionera y no sabemos cómo sacarla. Aquí deberíamos aprender una lección: que a la hora de seleccionar un software, tan importante es plantearle las funcionalidades y los costes, como que en un futuro es posible que tengamos que migrar de la misma. Por ello resulta bastante sensato evaluar este escenario y tener presente cómo pueden ser estos procesos de migración y las facilidades que el fabricante nos da, para poder llevarla a cabo.

En OpenKM siempre hemos partido de la premisa de que la información es del usuario y que nuestro software tiene que ser custodio de la misma, pero no carcelero. Por esta razón, ya desde la primera versión de OpenKM disponemos por defecto de un sistema de importación y exportación de los ficheros y los metadatos. Así mismo, como parte de la documentación de la aplicación, explicamos la estructura básica de la base de datos, por si alguien tiene la necesidad de acceder a la aplicación a nivel de base de datos. Adicionalmente, con el completo API de Webservices se puede de una forma muy sencilla, implementar la lógica necesaria y a medida para exportar los datos.

En general, un proceso de migración de un sistema de gestión documental se puede plantear desde tres caminos, como mínimo:

1. La herramienta dispone de una utilidad de exportación.
2. La herramienta dispone en la documentación o el fabricante puede proporcionar el DER de las partes fundamentales de la base de datos.
3. La herramienta dispone de una API mediante la cual y con una mínima lógica es posible extraer toda la información. Hablamos no sólo de ficheros sino de los metadatos, la seguridad etc.

En OpenKM es bastante habitual que usuarios de otros gestores documentales nos soliciten migrar sus datos a OpenKM - en otros artículos me extenderé en otros casos particulares -. En la mayoría de los casos, los usuarios ignoran si su gestor documental tiene un API y en caso de tenerla nunca la han utilizado. En absolutamente ningún caso, excepto con OpenKM, nos hemos encontrado con un fabricante que disponga de una utilidad de exportación sencilla e integrada, a la vez que te permita extraer todos los datos. Cuando hablo de todos, me refiero no sólo a los documentos, sino a todas las versiones de los documentos; así como los metadatos relacionados, la seguridad aplicada, quién creo el usuario y cuándo, las notas, etc.

Me acuerdo perfectamente de haber probado hace un par de años atrás una utilidad de Alfresco para exportar el repositorio. El invento me generó un fichero ZIP de 20GB, totalmente infumable con sus respectivos XML y para mayor pesadilla, lo incorporó como parte del gestor documental. Alguien, algún día, me tendrá que explicar la lógica de la mente pensante que ideó un sistema de exportación por el cual, el fichero de exportación termina entrando en el propio sistema de gestión documental. La afirmación “Si no es complicado y rocambolesco” parece que no es bueno, creo que deberíamos trabajar en ir desterrando esta tendencia.

Volviendo al hilo de la cuestión, obviamente un DER de la base de datos por parte del fabricante o que se te indique cuáles son las tablas principales que deberíamos tener en cuenta para identificar nuestros datos dentro de la aplicación, en general; tampoco nos lo van a proporcionar. En la mayoría de licencias de software, por no decir todas, se explicita que queda prohibido realizar ingeniería inversa de las aplicaciones. Pero seamos claros, estas restricciones se especifican para que la competencia no incorpore alegremente funcionalidades de terceros, cosa que desgraciadamente también pasa. Aquí otro aviso para navegantes, yo desconfiaría de aquellos que se dedican más a copiar al vecino, que no en implementar su propia solución.

En el caso de la solución de gestión documental KnowledgeTree, no disponemos de una utilidad de exportación. Disponemos de una API en la cual encontraremos algunos servicios basados en CMIS y en RESTful: http://orion.knowledgetree.com/KnowledgeTree_API_Documentation

Si lo que deseamos es migrar toda la información, aquí hablamos no sólo de documentos sino de metadatos, veremos que en ambos casos la implementación del API, tanto en RESTful, como en CMIS es insuficiente para este fin. A mi personalmente el CMIS me resulta decepcionante - en un artículo intentaré hablar de nuestra experiencia con esta API que pretende ser un mecanismo para interoperar entre distintas aplicaciones de document management, pero que para mí se queda corta y no exenta de grandes problemas -.

Al final, no nos quedará otra alternativa que investigar la estructura de la base de datos para identificar dónde se encuentra la información, en qué formatos y en qué forma se debería plantear su exportación.

En OpenKM hemos realizado migraciones de distintas aplicaciones de gestión documenal desde KnowledgeTree pasando por Docuware, Cannon Document Management o IBM Content Management, entre otros. En el caso de KnowledgeTree ha sido posible desarrollar una aplicación DMS to OpenKM migration tool, que automatiza este proceso. Desgraciadamente no es posible en todos los casos crear un proceso único de migración; las razones son diversas.

Al final, como en tantas otras aplicaciones, la recuperación de los documentos electrónicos de este gestor documental, dependerá de nuestra habilidad para identificar a nivel de la base de datos dónde se encuentra localizada la información.

Descripción de la base de datos

La mayoría de redactores, llegados a este punto del artículo, nos dejarían abandonados a nuestra suerte con nuestra aplicación de gestión documental KnowledgeTree y su base de datos. Nosotros vamos a intentar proporcionar todas las pistas que tenemos para que podamos interpretar esta base de datos, basándonos en la última versión disponible de KnowledgeTree, en concreto la version 3.7.

Parece que en las siguientes tablas se encontrarían los comentarios que se realizan sobre los nodos ( en general es bastante probable que esta información no sea muy relevante para nosotros  ):

• comment_searchable_text
• discussion_comments
• discussion_threads

Los tipos de documentos los encontraremos en la tabla:

• document_types_lookup

Los documentos se encuentran en la tabla ( la aplicación trabaja con versiones de documentos ):

• document_content_version

Los metadatos de los documentos los encontraremos en las tablas ( si tenemos suerte, nuestro repositorio no tendrá metadatos, porque esta parte de la estructura resulta un tanto tediosa ):

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

Las relaciones entre documentos las podemos encontrar en las tablas:

• document_link_types
• document_link

Los usuaris suscritos a documentos y carpetas los podemos encontrar en las tablas:

• document_subscriptions
• folder_subscriptions

Las palabras clave, keywords o tags ( según como las queramos llamar ) las podemos encontrar en la tabla:

• document_tags

Títulos en las carpetas, en la tabla:

• folder_searchable_text

Los privilegios en la tabla:

• permissions

La parte de los privilegios resulta compleja de entender. Existen más tablas, pero las que realmente consideramos como relevantes son las que hemos detallado anteriormente.

Conclusión

A la hora de adquirir una aplicación, sería realmente muy interesante que nos ofreciesen una mínima descripción del DER de la base de datos. Si observásemos una aplicación bajo la forma de un organismo, podríamos identificar la base de datos como aquella parte del cerebro humano donde se almacena la información. Un incorrecto almacenamiento dificultará no solo el acceso sino también el rendimiento en el proceso de de los datos.

Al observar algunas bases de datos, nos encontraríamos con cosas bastante curiosas que probablemente nos harían replantearnos en muchos casos, nuestra elección. En general un DER – Diagrama Entidad Relación – de una base de datos que resulte tremendamente compleja de entender, debería como mínim,  despertarnos una cierta alarma. En algunos casos puede estar justificado; en otros se debe – desde mi punto de vista – a que se ha partido de ideas incorrectas o de una mala ejecución. Si bien es cierto que las bases de datos en el tiempo van evolucionando, no es menos cierto que si existen errores de diseño graves a nivel de base de datos, no es para nada fácil solucionarlos y el tiempo no hará más que ponerlos en evidencia.

URL de interés

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/