Alfresco 4 y Solr

Hace poco se ha presentado en sociedad la versión 4.0 Community de Alfresco que incluye el que posiblemente sea el cambio arquitectónico más importante desde la aparición de este ECM: la desvinculación de los índices del motor de gestión documental mediante la utilización de Solr.

La arquitectura de Alfresco desde su primera versión hasta las últimas versiones Enterprise siempre se ha basado en tres componentes fundamenteles: la base de datos, el repositorio de documentos y los índices de Lucene. Los dos primeros componentes, por su naturaleza y por las tecnologías usadas para implementar Alfresco, han estado desvinculados del núcleo de Alfresco de forma que su instalación se podía hacer de forma independiente a la aplicación Alfresco. No ha sido así en el caso de los índices de Lucene, que siempre se deben desplegar en el mismo servidor físico que la aplicación principal de Alfresco.

La principal repercusión de esta arquitectura es que la escalabilidad global de la plataforma estaba condicionada por uno de los elementos fundamentales. Mientras que la base de datos y el repositorio de documentos se podían escalar de forma independiente a la aplicación principal, los índices siempre tenían que crecer al mismo ritmo que las instancias de Alfresco que formarán la plataforma. Aunque existían mecanismos para paliar esta situación algunos inconvenientes eran inevitables, sobre todo en instalaciones en clúster:

• Más espacio en disco ocupado: los índices completos se deben replicar en todas las instancias de Alfresco. Para un cluster de dos nodos con un repositorio de 40Gb eso representa 8Gb. Para un repositorio de 4Tb estaríamos hablando de casi 800Gb.
• Más tráfico de red: la necesidad de replicar los índices entre los nodos de un clúster incrementa el tráfico de red.Para instalaciones de más de 4 nodos de Alfresco este tráfico supone una cantidad importante y la necesidad de equipos de red dedicados en exclusiva a esta función.
• Más costes de licencias: para incrementar el rendimiento de los índices es necesario utilizar más instancias de Alfresco, lo que implica nuevas licencias para las versiones Enterprise.
• Penalización del rendimiento: las operaciones de indexación de contenidos de texto pueden ser bastante costosas y repercuten en el rendimiento de la aplicación pudiendo causar un aumento de los tiempos de respuesta de las peticiones de los clientes.

La nueva versión de Alfresco ofrece una solución a todos estos inconvenientes y abre una nueva vía para construir implantaciones de Alfresco muchísimo más escalables y con un gran potencial de crecimiento y ahorro de costes.

La solución consiste en sustituir los índices de Lucene que se han utilizado hasta ahora por un nuevo sistema de indexación basado en Apache Solr.

Apache Solr es la plataforma de búsquedas corporativas de Apache Lucene. Sus características principales incluyen potentes búsquedas de texto completo, resaltadao de resultados, búsqueda por facetas, clustering dinámico, integración con bases de datos, documentos ricos (por ejemplo, Word, PDF), manipulación y búsquedas geoespaciales. Solr es altamente escalable, proporcionando búsquedas distribuidas y replicación de índices, y el motor de búsqueda y navegación de muchos de los sitios de internet más grandes del mundo.

Dentro de la arquitectura de Alfresco la inclusión de soporte para Solr quiere decir que la función de los índices ya no está forzosamente vinculada a cada instancia de Alfresco sino que se delega en un sistema separado que se gestiona de forma independiente. A priori, este enfoque ofrece interesantes ventajas:

• Reduce la carga de los servidores de Alfresco: las costosas operaciones de indexación ahora se realizarán en un servidor a parte por lo que los servidores de Alfresco dispondrán de mayor capacidad para servir peticiones.
• Mayor escalabilidad: se puede dar mayor potencia a la herramienta de indexación y búsqueda cuando se necesite, sin tener que aumentar el número de servidores de Alfresco.
• Reducción de costes: se puede conseguir mayor eficiencia con menos licencias de Alfresco y reaprovechando la infraestructura de búsquedas corporativa.
• Reducción del espacio: en caso de tener un cluster, los índices pueden estar en una única ubicación y no replicados en todos los servidores de Alfresco.
• Mayor fiabilidad en los clústers: al tener unos índices compartidos por las diferentes instancias de Alfresco se reduce el riesgo de sufrir problemas de sincronización y de corrupción de índices.

Además de todas estas ventajas, la gente de Alfresco también ha pensado en todos aquellos que están contentos con Lucene o que tienen alguna dependencia de esta solución y por eso ha mantenido el soporte a Lucene. Esto quiere decir que el uso de Solr o de Lucene es una decisión de los implantadores de Alfresco para que puedan escoger la solución que mejor se ajuste a las necesidades de cada uno. De esta forma aumenta la riqueza que el producto ofrece a sus usuarios.

Integración de Alfresco y Liferay

El portlet DocLib de Alfresco proporciona todas las funcionalidades del componente document library de Alfresco Share dentro de un portal. Este portlet se ofrece en tres modalidades: acceso a todo el repositorio de Alfresco, acceso a las document libraries de los sites de los que se es miembro o acceso a la document library de un site en concreto.

Funcionalidades

Estos portlets incluyen casi todas las funcionalidades del Share aunque con las siguientes excepciones:

• No existe la acción "Ver enAlfresco Explorer" para los espacios.
• En la vista de detalles, no semuestra la sección "Compartir".
• Los nombres de los usuarios noestán enlazados a las páginas de sus perfiles.
• Al no mostrarse la cabecera de la aplicación Share, no hay acceso a la barra de herramientas, a otras páginas de los sites ni a los dasboards de la aplicación.

Instalación

El siguiente procedimiento de instalación asume las siguientes condiciones:

• Alfresco está instalado y funcionando. La versión probada es la 3.4 Enterprise pero también debería funcionar con las versiones Community.
• Liferay está instalado y funcionando. La versión probada es la 6 EE pero también se ha probado con éxito es la 6 EE SP1 y 6.0.5 GA.
• Las modificaciones indicadas se han de hacer con Alfresco y Liferay detenidos.
• Tanto Liferay como Alfresco están instalados en Tomcat.

Configuración de Liferay

Si Liferay y Alfresco están en la misma máquina pero en servidores de aplicaciones distintos, hay que cambiar los puertos usados por el Tomcat de Liferay para evitar conflictos. Localizar y modificar el siguiente fichero <LIFERAY_HOME>/tomcat/conf/server.xml como sigue:

<Server port="8105" shutdown="SHUTDOWN">

<Connector port="8180" protocol="HTTP/1.1"

             connectionTimeout="20000"

             redirectPort="8443" URIEncoding="UTF-8" />

<Connector port="8109" protocol="AJP/1.3" redirectPort="8443" URIEncoding="UTF-8" />

Configuración de Alfresco

En el Alfresco hay que añadir los siguientes elementos en el fichero <ALFRESCO_HOME>/tomcat/shared/classes/alfresco-global.properties.

authentication.chain=alfrescoNtlm1:alfrescoNtlm,external1:external

external.authentication.proxyUserName=

Advertencia: La autenticación necesaria para el portlet es incompatible con el mecanismo de autenticación passthru.

Desplegar la aplicación Share en Liferay

Copiar el fichero share.war de la instancia de Alfresco en el directorio deploy del Liferay.

Configurar la aplicación Share en Liferay

Localizar y modificar el fichero <LIFERAY_HOME>/tomcat/conf/catalina.properties con la siguiente línea:

shared.loader=${catalina.home}/shared/classes,${catalina.home}/shared/lib/*.jar

Crear la carpeta <LIFERAY_HOME>/tomcat/shared/classes/alfresco/web-extension y añadir un fichero llamado shared-config-custom.xml con el siguiente contenido:

Nota: en caso de que el Alfresco no esté instalado en la misma máquina que el Liferay o esté instalado en un puerte diferente al 8080, hay que modificar los endpoints para que apunten a la ubicación correcta.

Iniciar Alfresco y Liferay

Arrancar primero la instancia de Alfresco y a continuación la de Liferay. Para que los portlets desplieguen correctamente es necesario que el Alfresco esté arrancado.

Añadir los portlets a una página de Liferay

Los portlets de Alfresco están disponibles bajo la categoría Alfresco del menú Añadir Aplicación de Liferay. Cada uno de los portlets se ha de desplegar en su propia página y no puede haber dos o más portlets en la misma página.

Es necesario que en Alfresco y en Liferay existan los mismos usuarios por lo que es aconsejable que exista algún tipo de sincronización entre ambos repositorios de usuarios y un SSO entre sus sesiones.

Contextualización

El portlet de acceso al repositorio por defecto da acceso a todos los espacios del repositorio. En el ámbito de una integración Liferay-Alfresco más extensa es interesante que el portlet detecte automáticamente en qué comunidad de Liferay está ubicado y muestre directamente el espacio de Alfresco correspondiente a esa comunidad.

El enfoque adoptado para la contextualización del portlet ha sido el siguiente: añadimos una preferencia al portlet con un valor por defecto. Al instanciar el portlet, si la preferencia tiene el valor por defecto, éste mostrará el espacio de la comunidad donde esté ubicado el portlet. En caso de que el portlet esté ubicado en una página personal de usuario, mostrará la carpeta personal del usuario en Alfresco. Si la preferencia del portlet contiene un path de un espacio en Alfresco, este path será el que se mostrará.

Modificar la definición del portlet

El primer paso es modificar el fichero de definición del porlet (portlet.xml) para añadir la preferencia y los parámetros de inicio del portlet:

 

También hay que hacer un cambio en el fichero liferay-portlet.xml para determinar el ámbito de las preferencias que acabamos de definir:

 <portlet>

   <portlet-name>ShareRepoBrowser</portlet-name>

   <preferences-unique-per-layout>true</preferences-unique per-layout>

   <user-principal-strategy>screenName</user-principal-strategy>

 </portlet>

Creación de la página de edición de las preferencias

A continuación hay que crear una página en Alfresco Share que permita editar la preferencia que hemos añadido en el apartado anterior. La definición de la página será la siguiente:

Esta página estará basada en una platilla donde haremos referencia al webscript que permitirá la definición de la preferencia:

Creación del webscript de edición de las preferencias

El webscript de edición de la preferencia presenta un formulario con un campo de texto donde se puede entrar un path de Alfresco. La acción del formulario apuntará de nuevo al portlet para grabar la preferencia.

La definición del web script será:

El controlador del webscript será muy sencillo y sólo lo utilizaremos para capturar el estado del portlet:

La plantilla de visualización será de tipo html:

En esta plantilla es importante el elemento prefSiteId que contiene el valor de la preferencia en el portal.

La presentación del formulario requiere unos estilos para que se visualice correctamente: Estos estilos ya los lleva Alfresco por defecto:

Este webscript se ha de completar con los ficheros de internacionalización que sean necesarios.

Modificar implementación del portlet doclib

La clase que implementa el portlet se llama ProxyPortlet y se puede encontrar en el fichero alfresco-share-3.4.0.jar de la aplicación share.

En la definición de constantes añadiremos:

En el método init hay que incluir:

El método doView lo modificaremos para que localice una preferencia llamada param y, en caso de que aparezca, sustiuirla por el valor de la comunidad en la que se encuentra la instacia del portlet. Este cambio lo hacemos en el bucle que recorre las preferencias del portlet:

Ajustes finales

Hay dos elementos del código de Alfresco Share que impiden que la contextualización funciona tal como está definida.

El primero es el tratamiento de la URLs que hace la plantilla del webscript de la documentlibrary porque necesita que los parámetros le lleguen por la window.location. Para solucionar este problema hay que comentar en la plantilla documentlibrary.inc.ftl el siguiente condicional:

    if (loc.hash === "" && loc.search !== "")

El segundo elemento es un estilo CSS que colisiona con los estilos de Liferay. Este estilo se encuentra en el fichero reset-fonts-grids.css y hay que borrarlo de dicho fichero:

body{text-align:center;}

Soluciones de backup y restore para Alfresco

Uno de los requisitos habituales que piden las organizaciones cuando están estudiando implantar una herramienta de gestión documental, como Alfresco, es que la gestión de los backups de los contenidos sea lo más sencilla posible.

La gestión de los bakups tiene dos vertientes de interés:

• La definición de una política de backup y restore de todo el repositorio de contenidos. Normalmente vinculada a la estrategia de Disaster Recovery del sistema.
• La definición de una estrategia para la recuperación de contenidos individuales "perdidos" durante la operativa habitual del sistema.

En el caso particular de Alfresco, no hay herramientas concretas proporcionadas por el fabricante para ninguna de estas dos tareas. Lo máximo de lo que se dispone es de un conjunto de recomendaciones o best practices para conseguir estos objetivos.

Full backups

Un backup completo de Alfresco implica tres elementos: el repositorio de contenidos, la base de datos y los índices de Lucene.

De los tres elementos mencionados los más importantes son el repositorio de contenidos y la base de datos. Estos dos elementos se han de guardar conjuntamente y recuperar también juntos. Restaurar un elemento sin estar sincronizado con el otro implica acabar con un repositorio corrupto. Los índices no son tan importantes porque siempre se pueden recuperar a partir de la información de la base de datos y el repositorio.

La mejor estrategia de backup consiste en detener el Alfresco y hacer el backup de cada componente usando las herramientas proporcionadas por los fabricantes de cada sistema. Llamaremos a esta estrategia cold bakcup.

En el caso de que no se pueda detener el servicio de Alfresco para hacer la copia se tendrá que proceder a una copia en caliente del sistema. Llamaremos a esta estrategia hot backup. Esta solución es más delicada y depende sobre todo de la capacidad del sistema de base de datos de realizar copias seguras (respetando la transaccionalidad del sistema). En esta solución el orden en el que se guardan los elementos es fundamental y se debe respetar para garantizar una copia consistente de los datos. El orden es el siguiente:

1. Asegurarse de que el backup automático de los índices se ha completado. Ha de existir la carpeta backup-lucene-indexes en el directorio apuntado por dir.root.
2. Hacer la copia de seguridad de la base de datos utilizando las herramientas proporcionadas por el fabricante del RDBMS.
3. Inmediatemente después de guardar la base de datos, hay que copiar los subdirectorios del directorio dir.root. Esta operación se puede hacer con rsync, xcopy, robocopy o cualquier otra herramienta de copia.

La razón de este orden es que los elementos de base de datos que se hayan añadido después de guardar los índices, se pueden regenerar mediante una reindexación (AUTO o FULL) de los índices de Lucene. Los contenidos que se hayan añadido al repositorio después de que se haya guardado la base de datos se consideraran fuera del backup y podrán entrar en el siguiente (si se guardara antes el repositorio que la base de datos, podrían aparecer elementos huérfanos que son más difíciles de recuperar).

La operación de restore consiste en detener el Alfresco y restaurar la copia de la base de datos y la copia del sistema de ficheros. Al arrancar de nuevo el Alfresco, puede ser necesario modificar el parámetro index.recovery.mode y ponerlo a FULL o a AUTO para que regenere los índices que falten.

Restore de ficheros únicos

Cuando un contenido de Alfresco se pierde por el motivo que sea (aunque lo más seguro sea por negligencia del usuario) se puede recuperar de diversas formas:

• Si el documento tiene activado el versionado, se puede recuperar la versión anterior del historial de versiones y guardarla como la versión actual. Esta es una buena práctica para documentos de trabajo con actualizaciones frecuentes.
• Si el documento ha sido borrado accidentalmente, se puede recuperar de la papelera de reciclaje de Alfresco. Esta papelera sólo es accesible desde Alfresco Explorer. Los usuarios o administradores pueden acceder a ella en su Profile.
  
• Si el documento no está versionado y no está en la papelera (porque se ha borrado de ahí) hay que recurrir a los back ups de base de datos y file system.

Alfresco no proporciona ninguna herramienta para recuperar un archivo único de una copia de backup. La única opción "oficial" es restaurar las copias en un entorno independiente/nuevo de Alfresco y recuperar el fichero de dicho entorno. Esta solución es poco práctica cuando el volumen del repositorio es muy grande porque no siempre se dispondrá del espacio y tiempo necesarios para recuperar el file system completo en un nuevo entorno.

La solución al problema consiste en explorar directamente la base de datos de Alfresco y obtener la referencia al documento buscado para poder recuperar el archivo directamente del dispositivo de backup donde esté almacenado. Para ello, el único elemento que se ha de recuperar es la base de datos de Alfresco. Este elemento es más fácil de restaurar porque ocupa mucho menos espacio que el file system.

A partir de la información de un contenido almacenada en la base de datos se puede reconstruir el path del archivo conrrespondiente a dicho contenido. Los datos que se necesitan para hacer esta recuperación son el nombre del fichero y la última fecha en la que el contenido estaba correctamente almacenado en el repositorio. La consulta* que se ha de ejecutar para recuperar la ubicación de un fichero llamado 'demo.txt' sería:

select a.node_id, db.content_url
from
alfresco.ALF_NODE_PROPERTIES a,
alfresco.ALF_QNAME b,
alfresco.ALF_NAMESPACE c,
alfresco.ALF_NODE_PROPERTIES ab,
alfresco.ALF_QNAME bb,
alfresco.ALF_NAMESPACE cb,
alfresco.ALF_CONTENT_URL db
where a.STRING_VALUE='demo.txt'
and a.QNAME_ID = b.ID
and b.NS_ID = c.ID
and a.NODE_ID = ab.NODE_ID
and ab.QNAME_ID = bb.ID
and bb.NS_ID= cb.ID
and ab.LONG_VALUE = db.ID
and b.LOCAL_NAME = 'name'
and c.URI = 'http://www.alfresco.org/model/content/1.0'
and bb.LOCAL_NAME = 'content'
and cb.URI = 'http://www.alfresco.org/model/content/1.0'


Esta consulta devuelve el identificador interno del nodo correspondiente al contenido y la url de la ubicación del fichero en el sistema de ficheros.

La estructura de la url de la ubicación del fichero del ejemplo es la siguiente:

store://2011/2/22/16/21/e7067340-9ca6-4e5b-b53b-b17dfaecf1b7.bin

• store:/ hace referencia al almacén del fichero.
• /2011/2/22/16/21 es el path donde está el fichero a partir del directorio raíz del alf_data contentstore.
• e7067340-9ca6-4e5b-b53b-b17dfaecf1b7.bin es el nombre del fichero en el disco. Este nombre se puede substituir por el nombre original (p.e. demo.txt) y así se recuperaría el archivo perdido.
  

En el caso de que la consulta devuelva más de un registro, correspondientes a las diferentes versiones del documento, se puede utilizar el valor de la columna NODE_ID para recuperar la entrada adecuada a la versión buscada. La siguiente columna es un ejemplo de como recuperar la etiqueta de la versión:

select a.string_value
from alfresco.ALF_NODE_PROPERTIES a,
alfresco.ALF_QNAME b,
alfresco.ALF_NAMESPACE c
where a.NODE_ID = 540
and a.QNAME_ID = b.ID
and b.NS_ID = c.ID
and b.LOCAL_NAME = 'versionLabel'
and c.URI = 'http://www.alfresco.org/model/content/1.0'


A partir de la versión se puede recuperar el fichero correcto.

*Las consultas de este artículo están probadas en una versión 3.4.1 Enterprise.

Porlet de tareas de Alfresco para Liferay

En la versión 3.4 de Alfresco se ha incluido un portlet JSR-168 llamado Doclib portlet que está preparado para ser desplegado en el portal Liferay. Este portlet está basado en Alfresco Share y tres funcionalidades de acceso al repositorio de Alfresco:

• Repository browser: permite navegar por todo el repositorio de Alfresco usando las credenciales del usuario autenticado en el portal.
• Site Document Library: se puede configurar para mostrar la document library de un site concreto de Alfresco Share.
• My Document Libraries: permite acceder a todas las document libraries de los sites a los que pertenece el usuario autenticado en el portal.

La parte de gestión documental queda muy bien cubierta por estas funcionalidades, pero se hecha en falta alguna de las utilidades incorporadas en esta versión de Alfresco como, por ejemplo, la gestión de tareas. Por suerte, Alfresco es una aplicación fácil de ampliar y se puede conseguir disponer de un portlet de tareas de Alfresco integrado en un portal Liferay.

El primer paso consiste en incluir la definición del nuevo portlet en los ficheros de porltets incluídos en Alfresco Share. Empezamos por el liferay-portlet.xml, donde hay que añadir:

<portlet>
<portlet-name>ShareMyTasks</portlet-name>
<user-principal-strategy>screenName</user-principal-strategy>
</portlet>

A continuación editamos el fichero liferay-display.xml e incluimos lo siguiente:

<portlet id="ShareMyTasks"></portlet>

Por último hay que editar el fichero portlet.xml para añadir:

<portlet>
<description>Alfresco Share: My Tasks</description>
<portlet-name>ShareMyTasks</portlet-name>
<portlet-class>org.alfresco.web.portlet.ProxyPortlet</portlet-class>
<init-param>
<name>viewScriptUrl</name>
<value>/page/my-tasks</value>
</init-param>
<supports>
<mime-type>text/html</mime-type>
<portlet-mode>VIEW</portlet-mode>
</supports>
<portlet-info>
<title>Share: My Tasks</title>
<short-title>My Tasks</short-title>
</portlet-info>
<security-role-ref>
<role-name>administrator</role-name>
</security-role-ref>
<security-role-ref>
<role-name>guest</role-name>
</security-role-ref>
<security-role-ref>
<role-name>power-user</role-name>
</security-role-ref>
<security-role-ref>
<role-name>user</role-name>
</security-role-ref>
</portlet>

Estos ficheros se encuentran en la carpeta WEB-INF de la aplicación Share. Cuidado que esta aplicación Share es la que se despliega en el portal, no la que se despliega junto con el repositorio de Alfresco.

A continuación hay que modificar la plantilla de visualización de la página de la lista de tareas para eliminar la barra de cabecera de Alfresco y dejar únicamente los componentes relacionados con la lista de tareas. Esta plantilla se llama my-tasks.ftl y se puede encontrar en la carpeta WEB-INF/classes/alfresco/templates/org/alfresco . El código que hay que comentar o eliminar es el siguiente:

<@region id="header" scope="global" protected=true/>

Por último hay que modificar el fichero web.xml de la aplicación Share para incluir la definición de la implementación del nuevo portlet añadiendo los siguientes elementos. En la sección de servlets:

<servlet>
<servlet-name>ShareMyTasks</servlet-name>
<servlet-class>com.liferay.portal.kernel.servlet.PortletServlet</servlet-class>
<init-param>
<param-name>portlet-class</param-name>
<param-value>org.alfresco.web.portlet.ProxyPortlet</param-value>
</init-param>
<load-on-startup>0</load-on-startup>
</servlet>

y en la sección de servlet-mappings esto:

<servlet-mapping>
<servlet-name>ShareMyTasks</servlet-name>
<url-pattern>/ShareMyTasks/*</url-pattern>
</servlet-mapping>

Una vez hechos todos los cambios hay que volver a desplegar la aplicación Share en Liferay para que reconozca el nuevo portlet. Una vez recargada la aplicación, el nuevo portlet estará listo para ser usado.

Bug en la edicion online de Alfresco usando Office 2010

En la versión 3.4.0 de Alfresco Enterprise hay un bug en la edición online de documentos de Office cuando se utiliza la suite de programas MSOffice 2010. Este bug hace que se pierda el content type de los documentos editados cuando se guardan los cambios hechos sobre el documento.

Este no es un error excesivamente grave ya que es fácil de subsanar volviendo a asignar manualmente el content type al documento. De todas formas obligar a los usuarios a hacer esta asignación cada vez que editan un documento es bastante poco práctico. Además, si se pierde el content type de un documento, hay un efecto secundario en determinados tipos de ficheros (por ejemplo los documentos de MSOffice 2007) que hace que la siguiente vez que se vaya a editar un documento el sistema no sepa como abrirlo al desconocer el content type del que se trata.

Este problema estará resuelto en la versión 3.4.2. Mientras tanto, hay un posible workaround para evitar la pérdida del content type cuando se guardan los cambios de documento editado online.

Lo primero es crear un script con el siguiente código:

if (document.hasAspect("cm:workingcopy") && document.properties["cm:workingCopyMode"]=="onlineEditing") {

var ref = document.properties["cm:source"];


if (ref.mimetype != document.mimetype) {

document.mimetype = ref.mimetype;

document.save();

}

}

La perdida del content type se produce al guardar los cambios, y esto siempre se hace sobre la copia de trabajo. Por este motivo, voy a buscar el content type al documento original y lo actualizo en la copia de trabajo en el caso de que se haya perdido.

A continuación hay que crear una regla en el espacio raíz del repositorio que aplique a todos los items de cualquier tipo que sean modificados en el repositorio, que ejecute el script anterior y que tenga efecto en todas las subcarpetas del espacio raíz.

Carga de modelos en Alfresco

Una de los inconvenientes que siempre he encontrado a como Alfresco trata los modelos documentales ad hoc es la forma de crearlos y cargarlos.

Tener que crear un fichero XML con el modelo, sin ningún tipo de ayuda visual o guía interactiva, hace que la creación de modelos sea una tarea más próxima al desarrollo que a la configuración y por lo tanto más difícil de asumir por perfiles de negocio.

El despliegue del modelo se puede hacer de dos formas, desde el classpath, cosa que obliga a reiniciar la aplicación para obtener los cambios o desde el repositorio, desplegando en fichero del modelo en el espacio Data Dictionary > Models . Este segundo método es dinámico ya que permite incorporar modelos al repositorio sin necesidad de reiniciar la aplicación.

El inconveniente que simpre le vi a este segundo método es que, a pesar de que el modelo sí se puede cargar dinámicamente, su representación en el cliente web (definida en el fichero web-client-config-custom.xml del extension) sí que obligaba a reiniciar la aplicación.

Gracias a este post del gran Toni de la Fuente he visto que ya no es necesario hacerlo así. Existe una forma completamente dinámica de incorporar modelos al repositorio y de verlos en el cliente web sin necesidad de reiniciar la aplicación. Los pasos a seguir son los siguientes:

1. Crear el modelo en un fichero con extensión .xml. Por ejemplo my-model.xml.
2. Copiar el fichero my-model.xml en el espacio Company Home > Data Dictionay > Models . Si el modelo es válido, a los metadatos del fichero se le añadirá uno llamado Model Active.
   
3. Activar el modelo marcando el checkbox del metadato Model Active. A partir de este momento los elementos definidos en el modelo ya se pueden utilizar en el repositorio.
4. Modificar el fichero web-client-config-custom.xml de la carpeta extension e incluir la representación del modelo creado en el paso 1.
5. Acceder a la consola del webclient en la siguiente URL: http://serverhost/alfresco/faces/jsp/admin/webclientconfig-console.jsp . Para acceder a esta consola es necesario tener el usuario administrador de Alfresco.
6. Escribir el comando reload en la caja de comandos y pulsar el botón Submit. El resultado debe ser algo parecido a la siguiente pantalla:

Una vez realizados todos los pasos el modelo estará listo para ser usado desde el cliente web de Alfresco y sin necesidad de reiniciar la aplicación. Esto es una gran ventaja ya que permite ampliar la funcionalidad del gestor documental de una forma más cómodo y con un menos impacto sobre el uso de la aplicación.

Ahora sólo falta conseguir el editor visual de metadatos.

IN2, EMEA partner of the year

Estos días se está celebrando en Orlando el KickOff 2011 de Alfresco. En este evento se están presentando las principales novedades preparadas para este año en las nuevas versiones de Alfresco ECM.

Entre las muchas mejoras que han incluído en su producto podemos encontrar la utilización de Solr para la compartición de índices, la inclusión de Activiti como motor de procesos o el social content management. También se han presentado mejoras en el cliente web Share, como un nuevo panel de administración, la posibilidad de personalizar los temas de los sites o el modelador de procesos de Activiti.

También se ha hablado del nuevo programa de formación y certificación oficial del que tendremos más novedades muy pronto.

Y también se han entregado los premios a los mejores partners mundiales y este año IN2, la empresa con la que colaboro desde hace 10 años, ha conseguido la distinción como mejor partner EMEA del año 2010. Este premio me hace especial ilusión porque desde IN2 llevamos apostando muchos años por Alfresco y hemos hecho un trabajo constante para que dar a conocer las virtudes de un producto y de una forma de hacer software, el open source, que nos gusta y en el que creemos firmemente. Este premio es un reconocimiento a toda la gente que nos hemos esforzado para conseguir un trabajo bien hecho.

Os dejo una foto del premio, cortesía de nuestro compañero FëGoR que, afortunado él, está cubriendo el evento en vivo y en directo.