Migración de Docuware

Migración de Docuware

Escrito por Josep Llort el 4 de enero de 2018

En este artículo nos ocuparemos de describir la migración entre Docuware y OpenKM. En una publicación anterior, ya describí un proceso de migración; en ese caso entre Knowledgetree y  OpenKM.

Docuware es un sistema de gestión documental, que entre otras muchas diferencias con respecto a OpenKM, no dispone de una versión open source; es decir, es una aplicación que se ofrece únicamente bajo un licenciamento comercial. Docuware Gmbh., es el fabricante alemán de esta solución de gestión documental.

Seguidamente, realizaré un breve repaso a las principales características del software de gestión documental de Docuware y las contrastaré con la solución enterprise content management que ofrece OpenKM.

En primer lugar, destacaría que Docuware es una solución que se instala únicamente en un sistema operativo de Microsoft Windows; es decir, que por su arquitectura es una solución nativa del ecosistema de Microsoft. A diferencia del gestor documental de OpenKM, cuya arquitectura se basa en JAVA, por lo que es un entorno multiplataforma.

En OpenKM y creo que podemos extenderlo a la mayoría de fabricantes de soluciones de gestión documental, gestión de registros y enterprise content management; aconsejamos a nuestros clientes que siempre que sea posible, se utilice Linux como sistema operativo en sus distintas distribuciones. Nosotros recomendamos Ubuntu, Debian, Centos y Red Hat. La razón es sencilla; con el mismo hardware, Linux nos proporcionará siempre un rendimiento mayor, debido a que el sistema de entrada salida ( I/O ) es más eficiente. Adicionalmente, observaremos que un servidor con Windows tiene una tendencia natural a consumir un mínimo de 2GB de memoria, mientras que en Linux el consumo de recursos por parte del SO por defecto, es mucho menor.

En definitiva, si nos encontramos en un escenario donde el “performance” sea un factor crítico, deberíamos siempre tener en cuenta la posibilidad de instalar Linux en vez de Windows. Con esto no estamos negando la posibilidad de montar entornos de alto rendimiento bajo Windows. Simplemente queremos poner de manifiesto un dato objetivo; en igualdad de condiciones, con Linux vamos a tener un rendimiento extra.

Otra diferencia, como he comentado ya al principio es el tipo de licenciamiento. Mientras que el sistema de gestión de OpenKM tiene un licenciamento dual ( “comercial” y “open source” ), Docuware se ofrece únicamente bajo un único modelo ( “comercial” ).

Respecto a las bases de datos, podemos comprobar que tanto la solución de gestión documental de Docuware como OpenKM, pueden configurarse para funcionar con Microsoft SQL Server, Oracle y MySQL Server. En el caso de OpenKM, también se puede utilizar PostgreSQL. Con respecto a las bases de datos, podemos observar que tanto OpenKM como Docuware o la mayoría de fabricantes de soluciones de content management, optan por alguna de estas 4 bases de datos de relacionales.

En general, nos encontraremos con usuarios que desean utilizar la base de datos Microsoft SQL server, en entornos básicamente de Windows Server; mientras que las bases de datos PostgreSQL, Oracle, MySQL Server y MariaDB, nos las encontraremos en entornos basados en Linux.

Segmetaría los repositorios de gestión documental en dos grandes grupos: aquellos como OpenKM, que utilizan una taxonomía y los que no utilizan este paradigma. La palabra taxonomía tiene su origen en la ciencia, en concreto en la biología, donde se precisa un mecanismo para jerarquizar y sistematizar los grupos de animales y vegetales. Llamaremos taxonomía, a un sistema que nos permite la clasificación u ordenación en grupos, de cosas que tienen características comunes.

Aplicaciones de gestión documental como OpenKM, Nuxeo o Alfresco, utilizan el concepto de taxonomía para clasificar la información. En definitiva, la taxonomía en lenguaje popular es una jerarquía de carpetas que nos permite ordenar y clasificar los documentos.

Otros sistemas de gestión documental como Documentum ( ahora ECM2 ), OnBase, entre los cuales se encuentra también Docuware, utilizan una catalogación basada en el concepto de “cajas”. Para el caso de Docuware el nombre correcto serían los “Cabinets”. Un “Cabinet” vendría a ser un armario o un cajón en el mundo real, donde se almacena un único tipo de documento ( una única serie documental ). En el caso de estos sistemas de gestión de documentos, nos encontraremos que para cada tipo de documento disponen de una “caja” ( “Cabinet” ) por separado; con los correspondientes metadatos para el tipo documental asignado a cada una de las cajas.

Pongamos un ejemplo: una compañía que almacena Facturas y Contratos. En el caso de una solución de gestión documental como OpenKM, podríamos navegar por un árbol de directorios hasta localizar la información:

• /okm:root/Dept gestión/Contratos/2019
• /okm:root/Dept gestión/Contratos/2018
• /okm:root/Dept gestión/Facturas/2019
• /okm:root/Dept gestión/Facturas/2018

En el caso de Docuware, Documentum u Onbase, debemos previamente seleccionar el tipo de documento para acceder a una pantalla de listado que nos permite refinar la búsqueda. No existe propiamente una navegación, sino que se accede a la documentación previo conocimiento del tipo de documento al que queremos acceder.

Las primeras soluciones de gestión documental, tales como Documentum y OnBase aparecieron bajo este paradigma; probablemente influidas por trasladar el problema del mundo real de una forma exacta, a las soluciones informáticas. En el mundo real, la información se encuentra archivada en estantes y en cada estante por el tipo de documentación. Inspirados en esta solución, las primeras aplicaciones ofrecieron el mismo formato conceptual en un entorno digital.

Posteriormente, las aplicaciones de gestión documental, content management y enterprise content management más modernas, han optado por un modelo basado en clasificar la información dentro de una taxonomía.

Ambos modelos a mi entender, presentan ventajas y algunos inconvenientes. En el caso de las soluciones basadas en taxonomías, más allá de alguna ventaja a nivel de usabilidad de usuario, el punto mas significativo es romper con el aislamiento de la información que suponen los Cabinents. Es decir; cuando nos enfrentamos no sólo a un problema de gestión documental, sino a un problema de gestión de registros ( gestión de expedientes o business case ) donde distintos tipos documentales tienen un ciclo de vida interrelacionado, la aproximación a la solución basada en “Cabinets” resulta problemática.

En un escenario donde el gestor documental no es un simple contenedor de evidencias de la compañía, sino que existen workflow que controlan el ciclo de vida de los documentos; y a la vez existen expedientes en curso ,donde varios documentos están involucrados ( business case ) la solución basada en “Cabinets”, desde mi punto de vista no es la más óptima.

En general, las empresas cada vez van más allá de disponer de un simple contenedor de documentos y desean controlar de una forma más activa la información. Ahí es donde aparecen tanto los Workflows como el Plan de Archivo ( file plan y disposition ). El problema ya no es sólo el almacenamiento, sino que se trata de controlar la vigencia, los cambios, así como la distribución y el acceso a la información cuando ésta es requerida. Y todo esto integrado activamente en la actividad de la empresa ( aquí nos encontramos casos típicos de integraciones con CRM, ERP, entre otros ). Las aplicaciones de gestión documental pasan de ser un mero contenedor, a formar parte activa del ecosistema de software con el que la compañía opera.

Podemos encontrar más información en Docuware Knowledge Center.

En el caso de Docuware, que es el que ahora nos ocupa; desde OpenKM hemos realizado varias migraciones. En concreto, en el momento que estoy escribiendo este artículo hemos realizado migraciones tanto de la versión 6.x, como de la versión 7.x.

Como siempre, no hemos encontrado ninguna información por parte del fabricante, para que el cliente pueda extraer los datos de su repositorio. El punto de partida se repite nuevamente como en el caso de las migraciones que hemos realizado con otras soluciones de gestión documental. El cliente se encuentra prisionero de la solución informática.

Por eso desde aquí quiero hacer nuevamente un llamamiento, como ya hice en su día en el artículo sobre la migración de Knowledgetree a OpenKM. 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 la evaluación de un tema que yo consideraría clave; cómo poder sacar nuestros datos de este sistema, en el futuro.

El caso de Docuware es muy parecido, al menos conceptualmente al de OnBase. Para cada “Cabinet”, es decir para cada tipo de documento, se crean un conjunto de tablas específicas, donde se almacenará la información de forma separada. Es decir; si tenemos 50 tipos de documentos, la aplicación nos creará un mínimo de 50 tablas, cada una de las cuales contendrá la información y metadatos de cada tipo de documento.

Algo también significativo en el caso de Docuware es cómo se almacenan los datos en el sistema de ficheros. Existe la posibilidad de que cada tipo de documento se almacene en un destino distinto, es decir, que los documentos binarios en función del tipo pueden almacenarse en distintas unidades. Esta flexibilidad en la configuración, nos puede complicar la vida en el proceso de migración, porque en función del tipo de documento tenemos que tener en cuenta dónde se encuentra físicamente la información en el disco.

Otra curiosidad de Docuware es cómo se almacenan los archivos en el sistema de ficheros. Por ejemplo, un fichero PDF de 32 páginas lo encontraremos separado en 32 ficheros de una página cada uno, es decir; cuando subimos un fichero PDF ( en función de la configuración de Docuware ) éste será procesado y almacenado en la forma de 32 documentos con una página en cada uno de ellos. En cuanto a la forma de almacenamiento de los documentos, nos hemos encontrado con variaciones en función de si la versión era la 6.x o la 7.x y también en función del tipo de documento PDF o TIFF multipágina.

Otro problema que se presenta es la forma en que se almacenan los metadatos, en especial los de tipo fecha. Este es un problema clásico, que nos hemos encontrado en prácticamente todos los procesos de migración de otras aplicaciones de gestión documental y que precisa de una especial atención, para capturar el valor de la fecha en el formato correspondiente, para posteriormente almacenarlo en OpenKM en formato ISO8601.
Finalmente, la última curiosidad de Docuware se encuentra en que el repositorio del disco contiene un fichero por cada documento, con toda la información del documento. Es decir; todo parece indicar que el repositorio de Docuware en local, funciona como una exportación en vivo del repositorio con sus metadatos. Esto implica obviamente, que cualquier cambio que vayamos a realizar desde la aplicación en un documento, tendrá sus efectos tanto a nivel de la base de datos, como de estos ficheros locales. Esto tiene la ventaja de que en el repositorio ya disponemos de un backup ( exportación en caliente ); pero a la vez, estamos duplicando todos los datos ( base de datos y sistema de ficheros ) con el correspondiente consumo de hardware que todo esto implica. Esto también implica una lógica compleja del lado de la aplicación, para sincronizar constantemente estos datos.

En el momento que el departamento de I+D de OpenKM realizó el análisis de ingeniería inversa para realizar la migración de los datos, consideramos que era mucho más cómodo afrontar el proceso de migración mediante un script JAVA, que funcionase en combinación con la base de datos y el sistema de ficheros, conectándose éste con OpenKM mediante el SDK de JAVA. Descartamos de entrada, procesar los ficheros de texto que contienen la estructura de metadatos de Docuware, porque el formato en el que se almacena esta información no resultaba obvia, a diferencia de OpenKM; que cuando se exporta la estructura de metadatos en ficheros, lo realizamos con ficheros en formato JSON, lo cual facilita enormemente su posterior procesamiento.

Desde el departamento de I+D investigamos también, el soporte de CMIS en Docuware. Aunque no nos declaramos fans del CMIS es una opción a considerar y en el momento de la redacción de este artículo no está disponible. Encontramos algunos ejemplos de conexión a través de .NET con el API de Docuware, como podemos observar en este ejemplo API de Docuware .Es un camino que en su momento descartamos, en parte por todo el entorno de desarrollo de Microsoft que es necesario montar, pero que consideramos que es un opción a tener en cuenta para todos aquellos que quieran migrar su repositorio. Todo parece indicar, que el paquete DocuWarePlatformApi conforman un conjunto de librerías ( similares a lo que disponemos en OpenKM bajo el nombre de SDK’s para JAVA, .NET y PHP ) que permiten acceder de una forma muy fácil a todas las funcionalidades del repositorio, a través de los Webservices en REST.

En general, siempre que sea posible y dispongamos de un API desde el que poder atacar un repositorio, va a ser aconsejable utilizarlo como una primera aproximación a la solución del problema.

Echamos en falta un servicio de REST mejor documentado; no nos fue posible localizar documentación en línea. En OpenKM, al igual que otros fabricantes, hemos optado por la opción de que la propia documentación del servicio REST se encuentre disponible mediante Swagger.io; desde la propia documentación tal y como se indica en esta sección: swagger

Espero que este artículo pueda servir de introducción para todos aquellos usuarios que deseen en un futuro migrar sus datos desde Docuware. Y que la experiencia que aquí intentamos compartir les facilite de algún modo la solución del problema. El proceso de migración de los repositorios de Docuware que hemos migrado han sido muy parecidos, pero no exactamente iguales, por lo que no podemos proporcionarles una receta mágica que sea útil en todos los casos. En este artículo he intentado compartir un conocimiento “común” que considero re-utilizable en todos los escenarios en los que, al menos nosotros, nos hemos encontrado.

Algunas URL de interés:

• Docuware Platform .NET API
• Code Examples
• Platform as REST Service