Open IT Experts for Enterprise

Zylk empresa de desarrollo de ecommerce

Migrando contenidos de Sharepoint a Alfresco

Cesar Capillas
Cesar Capillas

Migrando contenidos de Sharepoint a Alfresco

El otro día caía en el blog de
Yerbabuena en un post sobre las «5
razones para no usar Sharepoint 2010
» y me encontraba en
una problemática de proyecto relacionada con este producto de
Microsoft. Recordé una presentación/workshop del noviembre pasado en
el Círculo de Empresarios de Bizkaia (CEBEK), y en donde presentamos
una matriz comparativa entre Alfresco y Sharepoint junto con otra
empresa (partner de Microsoft) en un coloquio de soluciones de gestión
documental. No añadiré más razones que las expuestas por los chicos de
Yerbabuena: seguridad, precio, interoperabilidad, escalabilidad y
comunidad, sino unas notas sobre una experiencia personal en un
proyecto reciente en relación a los puntos comentados.

En mi opinión, una de las principales contras que tiene una
implantación de Sharepoint en cuanto a la escalabilidad se refiere es
que únicamente en la versión 2010 y con las licencias más caras, se
pueden alojar los datos en un filesystem en vez de en la base de datos
(SQL Server). Esto es un ** must ** en un gestor documental
empresarial que se precie, o de cualquier aplicación que guarde
documentos, porque el rendimiento de la base de datos cuando el
repositorio es muy grande puede ser realmente malo (pensad en un
repositorio de teras de información y en una base de datos SQL Server
con ese tamaño, y con una concurrencia seria de usuarios accediendo a
ese servidor).

En mi caso concreto, estaba utilizando Sharepoint 2003 y
pretendía extraer una copia del repositorio, para migrarlo a Alfresco
ECM. Finalmente encontre un código C# que permite hacer esta tarea SPIEFolder
(desde el servidor), y que es conocido en el mundillo de Sharepoint
(hay también versiones diferentes del conector para 2007 y 2010). De
esa manera descargué la estructura de documentos via Webdav a
Alfresco. Pero es que resulta difícil, una tarea tan sencilla como un
backup incremental de ficheros o un simple y llano («copiame por
favor en un cd los documentos de mis oficinas colaborativas»).
Esto es un ejemplo típico de lo que ocurre con un producto cerrado,
que si que es verdad que hay ciertos servicios web (contados), ciertas
API’s expuestas para interaccionar (en su stack), pero resulta en
general difícil y tedioso hacer cualquier cosa. Si es cierto, que
Microsoft esta involucrado en el estándar CMIS, y que recientemente
también tengo noticias de un conector SQL Server para Linux. En
Alfresco por ejemplo, la carga de documentos se realizó utilizando el
repositorio como unidad compartida Webdav (que es un protocolo
estándar). Pero se podía haber hecho también a través de otros canales
estándar como FTP o CIFS, desde módulos de Alfresco especializados
para cargas masivas, o desde programación con REST, Web Services y
CMIS. En el caso de las API’s, la diferencia estriba en estas son
mucho más completas, y exponen gran parte del core, además de
extensibles proporcionando de más libertad y flexibilidad al
desarrollador. Y por esta razón, un producto de software libre va a
proporcionar muchísima mas interoperabilidad que otros productos
privativos, incluso más que Sharepoint con otros productos de Microsoft.

Otros problemas de la migración derivaron de obtener los
usuarios y permisos de las oficinas colaborativas, y en este caso
tuvimos que atacar directamente a la base de datos de Sharepoint para
via ACP’s generar un mapeo de permisos de directorio para Alfresco con
los usuarios y roles correspondientes. También se podía haber
orientado via Webscript creando un servicio para cada site de
Sharepoint, pero finalmente nos decantamos por crear la estructura de
carpetas y permisos via ACP, para hacer posteriormente la carga de
datos via Webdav. En el caso de los usuarios , teníamos dos conjuntos
en Sharepoint, los internos, que se migraron configurando el
directorio activo de Windows como subsistema de autenticación de
Alfresco (Sharepoint se autenticaba contra el AD), y los usuarios
externos, que se gestionaban en el propio Sharepoint y se migraron a
otro servidor de directorio LDAP externo.

Enlaces:

http://blog.yerbabuena.es/2011/03/5-razones-para-no-usar-sharepoint-2010.html

http://blog.krichie.com/2011/06/02/spiefolder-for-sharepoint-2010/

http://blog.krichie.com/2011/08/26/spiefolder-for-sharepoint-20072010/

Si te ha parecido interesante comparte este post en RRS

Facebook
LinkedIn
Telegram
Email

Leer más sobre temas relacionados

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *