Tag Archives: Alfresco

Módulo de Alfresco para sugerir contenido de interés

Actualmente en la empresa, a diferencia que fuera de ella, las redes sociales no son tan comunes. Derivado de esta situación, no encontramos sistemas de ayuda al trabajador sobre determinadas acciones que puede realizar para ayudarse en su trabajo y, por tanto, de sistemas que propicien recomendaciones sobre la toma de decisiones. Por ejemplo, Facebook recomienda amigos o contactos derivados del conjunto de acciones y actividades desarrolladas por el usuario en esta red social.
Al igual que ha pasado con la llamada “gamificación” en la que se traslada la mecánica de los juegos al ámbito profesional con el fin de conseguir mejores resultados, el sistema de recomendaciones para facilitar determinadas acciones puede resultar en un gran beneficio para la productividad del trabajador.

Alfresco, como muchos sistemas de gestión documental usados como herramientas para la gestión del conocimiento, no tienen herramientas que analicen las relaciones establecidas entre las acciones que realizan los usuarios que usan estas aplicaciones. Por tanto, no pueden ofrecer sugerencias o indicaciones del trabajo que están realizando el resto de compañeros que tienen en el mismo departamento o que están solicitando o trabajando con la misma información.

MASCI es un sistema que añade un control donde se visualizan sugerencias sobre documentos que pueden ser de interés a un usuario según las relaciones que se han producido entre otros usuarios que tienen algún tipo de relación con él.

El sistema consiste en un módulo instalable para Alfresco y Share así como un middleware que realiza la conexión entre Alfresco y Neo4j.

El proyecto, en su primera fase, puede encontrarse en: https://gitlab.com/fegor/masci

New release of Alfviral (Alfresco Virus Alert)

I have published a new revision of Alfviral (version 1.4.0), with a restructuring of the code, with the following characteristics:
  • Switching from module to subsystem: Now, Alfviral, behaves as a subsystem so that hot parameters can be modified by JMX, such as JConsole, and reset to read the new values.
  • Added the use of templates for email notifications.
  • General code refactoring.

 

The code is in: https://github.com/fegorama/alfviral/releases/tag/v1.4.0-SNAPSHOT

 

Solucionar el error “Found 1 integrity violations” en Alfresco 5.0.2

Cuando se instala Alfresco 5.0.2 y 5.1.EA, si esta instalación recoge los parámetros para español, se produce un error como el siguiente:

 

Caused by: org.alfresco.repo.node.integrity.IntegrityException: 00270001 Found 1 integrity violations:

Invalid property value:

Node: workspace://SpacesStore/141296a2-92d5-4160-82ec-828421bd8a4a

Name: Rep. Dem.

Type: {http://www.alfresco.org/model/content/1.0}category

Property: {http://www.alfresco.org/model/content/1.0}name

 

Este error ya se resuelve en la incidencia https://issues.alfresco.com/jira/browse/ALF-21423 por Angel Borroy y lo que voy a explicar es, simplemente, como arreglarlo en el propio fichero WAR, de forma que, si instalamos de nuevo, no se produzca de nuevo el error.

 

Primero descomprimimos el fichero alfresco.war:

cd tomcat/webapps

mkdir fix

cp alfresco.war fix

unzip alfresco.war

 

Descomprimimos el fichero alfresco-repository-5.0.x.x.jar (cambia las x por el número que tenga):

cd WEB-INF/lib

mkdir fix

cd fix

jar -xvf ../alfresco-repository-5.0.2.5.jar

 

Cambiamos el mensaje que falla en bootstrap-messages_es.properties:

vi alfresco/messages/bootstrap-messages_es.properties

[Buscar dentro de vi, p.e. /Rep\.\ Dem\.]

[Cambiar “Rep. Dem.” por “Rep\u00fablica”]

Nota: Se podría hacer de una vez sustituyendo en vi, pero eso os lo dejo a vosotros 😉

[Guardar con ESC+:wq]

 

Volvemos a crear el JAR (cuidado con los números de revisión), sobreescribimos el original y borramos este directorio:

jar cvf alfresco-repository-5.0.2.5.jar

cp alfresco-repository-5.0.2.25.jar ../

cd ..

rm -rf fix

 

Volvemos a crear el WAR, creamos una copia del original, otra del nuevo, sustituimos el original y borramos el directorio de trabajo:

cd ../../

zip -r alfresco.war *

cd ..

cp alfresco.war alfresco.war-orig

cp fix/alfresco.war .

cp alfresco.war alfresco.war-fix

mv alfresco.war-orig ../../

mv alfresco.war-fix ../../

rm -rf fix

cd ../../

 

Reiniciamos el servicio de Alfresco y, si todo ha ido bien, arrancará sin problemas.

 

Nota: No olvidéis borrar previamente el despliegue (webapps/alfresco) así como el contenido del directorio work.

 

Eso es todo, solo me queda dar las gracias a Angel Borroy por su aportación en la resolución de este problema.

 

Más información:

https://forums.alfresco.com/es/forum/usu%C3%A1rio-alfresco/instalaci%C3%B3n/value-rep-dem-not-valid-file-name-10202015-1558

https://issues.alfresco.com/jira/browse/ALF-21423

 

Errores de red con Windows 10 y Alfresco

Con la actualización de Windows 10 pueden volver algunos errores que en otras versiones y sistemas operativos ya estaban solucionadas.

Estos errores vienen derivados principalmente de las nuevas configuraciones de red implementadas en Windows, a partir de la versión 7 en realidad, y que en su versión 10 han sufrido un gran cambio.

Por ejemplo, una vez instalado Alfresco puede presentarse el siguiente error:

— log —
ERROR [sf.ehcache.Cache] [main] Unable to set localhost. This prevents creation of a GUID. Cause was: Mordor: Mordor
 java.net.UnknownHostException: Mordor: Mordor
at java.net.InetAddress.getLocalHost(Unknown Source)
at net.sf.ehcache.Cache.(Cache.java:155)
[…]
— log —

Si se realiza una investigación sobre este error se encuentran muchas páginas donde la solución es introducir la dirección IP 127.0.0.1 y el nombre del host o “hostname” en el fichero hosts, tanto en Linux, Windows y Mac OSX, pero esta solución ya no funciona en Windows, debido principalmente a dos cuestiones:
1. El uso de DNSSEC 
2. El uso de IPv6 sobre IPv4
Por lo tanto, para solucionarlo, no basta con poner nada en el fichero %SystemRoot%system32Driversetchosts, de hecho, no hace falta.
La solución es más sencilla que esto, hay que usar IPv4. Se puede hacer (tocando el registro de Windows) que la versión 4 tenga prevalencia sobre la versión 6 del TCP/IP, pero también, y creo que esto es mejor, se puede arrancar la máquina virtual de Java para que use la versión de TCP/IP que se necesita. El parámetro es: 
-Djava.net.preferIPv4Stack=true
Con este parámetro se solucionan los posibles errores de detección del host que es necesario para el arranque de Alfresco.
Además, hay que incluirlo también en otros sitios donde se utilicen descargas o llamadas a direcciones de Internet, como el caso de maven, eclipse, etc.
Por ejemplo, mi variable MAVEN_OPTS es la siguiente:
-Xms256m -Xmx1024m -XX:PermSize=320m -Xss1024k -Djava.net.preferIPv4Stack=true
Y que es la misma que tengo en la configuración de eclipse (Servers) para cada servidor de Tomcat y para cada llamada de maven.
Evidentemente hay que usar este parámetro también en el fichero eclipse.ini si se necesitan instalar plugins.

Nueva revisión de Alfviral (Alfresco Virus Alert)

Hace unos días, recibí un correo electrónico donde se me avisaba de un error de Alfviral cuando se intentaba actualizar un documento desde Share en la versión 4.2.

Al parecer, en esta versión se usa un nuevo sistema de actualización asíncrona y cuando se actualiza un documento se produce un borrado de nodo para crear otro que es el actualizado. El sistema de eventos salta con cada paso por lo que hay que verificar antes de nada que el nodo sigue todavía “vivo” y no ha sido borrado por el propio sistema de actualización. Esto, curiosamente no pasa en el contexto del Explorer (Alfresco).

En resumen, he re-factorizado algo más el código, he arreglado el problema y he reorganizado el proyecto tipo all-in-one como dos submódulos de repositorio y otro para share, así creo que está más claro y es más sencillo de instalar.

La nueva revisión se puede descargar desde: https://github.com/fegorama/alfviral/releases/tag/v1.3.2-SNAPSHOT

Alfresco y aplicaciones de los DataList

— Entorno —

Sistema: GNU/Linux Mint 17.1 Rebbeca (x86_64)
Versión Alfresco: 4.2.2 Enterprise
Base de datos: MySQL 5
Cliente Web: Google Chrome 40.0.2214.115 (64-bit)
Indexador: Apache-Lucene

Las pruebas se han realizado con Apache-Lucene así pues en Solr podrían ser distintas.

— Introducción —

Los DataList en Alfresco son un sistema de mantener “tablas” de datos para ser usadas de forma básica. Estas “tablas” tienen en el repositorio una estructura donde una carpeta representa el DataList y como “hijos” contiene cada uno de los “items” u opciones que vamos añadiendo. A mi parecer no es un sistema muy eficiente en lo que respecta a la forma de gestionarlo posteriormente ya que seguramente usando como persistencia tablas de la base de datos que se use en la instancia de Alfresco seguramente serían más rápidas y estables, pensemos en alguna DataList que necesitemos con 5000 registros (items). Dicho esto, es al menos una nueva forma con la que podemos contar para gestionar datos tabulados en Alfresco.

— Aplicaciones —

Las aplicaciones van en principio por la creación de DataList que hay ya preconfigurados como la lista de contactos, eventos, agenda, etc. pero también podemos crearnos nuestra propia DataList que permita ayudarnos en la posterior gestión o en tareas como carga dinámica de nuevos controles. La creación de un nuevo tipo de DataList es muy sencillo, basta con crear un tipo que herede de “dl:dataListItem” y añadir las propiedades que necesitamos guardar.

Hasta aquí bien, de hecho es muy fácil crearnos tipos nuevos muy sencillos con uno o dos propiedades y que nos sirvan para guardar información de “datos maestros” como provincias, municipios, temperaturas, cantidades, etc.

Aquí es donde viene una posible aplicación, cuando necesitamos recoger datos de fuentes externas en muchas ocasiones estas fuentes van a ser sustituidas por Alfresco o bien solo se necesitan en determinadas ocasiones por lo que tenerlas como fuente de datos desde Alfresco es un posible problema por si se eliminan, paran o cambian. Aquí se puede recoger esa información y crear DataList con ella de forma que luego podamos usarla simplemente haciendo una serie de consultas y recorridos por la propia DataList.

— Problema —

Bien, ¿sencillo verdad?, en realidad si, pero hay algunos problemas que solventar, el primero es que al crear nuestro tipo de datos y al heredar de “dl:dataListItem”, cuando creamos un DataList de nuestro propio tipo, el nombre junto con el prefijo quedan en una propiedad llamada “dl:dataListItemType” de la siguiente forma:

Efectivamente su valor es “dh:listasClara”, pero ¿que pasa entonces?, ¿todo bien, verdad?, bueno, no del todo, ya que resulta que cuando queremos buscar por este término para poder acotar solamente la búsqueda a este tipo de DataList nos encontramos con un problema, no se encuentra…

¿Por que?

Esto es debido al tipo de indexación que tiene por defecto esta propiedad, podemos verlo mejor si usamos la herramienta LukeAll:

Como podemos ver, los valores tomados por la propiedad están divididos, de forma que realizando una búsqueda directamente como @dl:dataListItemType:”dh:listasClara” no obtendremos ningún resultado, también podemos verlo realizando la búsqueda en la propia utilidad:

Aquí se encuentran los registros porque LukeAll parte el valor como “dh” y “listasClara”, de forma que en Alfresco si usamos una consulta que solo busque “dh” la encontraremos:

Pero claro, esto ni es elegante ni fiable ya que no estamos buscando por todo el término completo. Esto nos interesa para, como digo, encontrar un tipo solamente de DataList, ya que buscando como tipo dataList encontraría todas las DataList de todos los sites.

¿Como se soluciona?

En concreto esto podemos solucionarlo pero hay que modificar el propio modelo de datos de Alfresco de la siguiente forma:

Donde se ha incluido la indexación desactivando la capacidad “tokenised”, de esta forma cuando volvemos a reindexar todo y comprobamos obtenemos:

Que es el resultado correcto y por tanto se puede buscar:

Pero esto implica, si, que tenemos que modificar el fichero original o sobrecargarlo para que funcione correctamente. Esto además es para todos los tipos, incluidos los que ya vienen predefinidos en Alfresco así que cuidado.

Bien, solucionado ¿no?, pues no, resulta que además para poder posicionarnos en el propio DataList que necesitamos (es un “folder”) debemos buscar por algo más, en principio podría ser por el nombre, pero Alfresco no nos deja que pongamos cualquier nombre, le pone uno de forma automática y poco descriptivo:

Lo que nos dificulta la búsqueda. Podemos cambiarlo, si, pero seguimos con el mismo problema que teníamos con el tipo “dl:dataListItemType”. Bueno, pues como si nos deja poner un título por ahí, igual, seguimos en las mismas…

— Solución —

La solución sencilla que he encontrado a esto es crear un aspecto nuevo y que lo asignemos a los DataList que necesitamos, por ejemplo:

De esta forma asignamos el aspecto y en “dh:nameOfDataList” podemos incluir cualquier nombre que buscará como tal, como cadena de texto.

Por ejemplo, si creando la siguiente DataList:

Y ahora buscando su “folder” en el repositorio:

Podemos asignarle directamente el aspecto:

Y el valor del campo que necesitamos:

Recomiendo un nombre bastante descriptivo como dl + site + nombre, por ejemplo para un site llamado Personal y una lista de Oficinas podría ser “dlPersonalOficinas”. Ahora ya solo nos queda comprobar que se indexa correctamente:

Y que se encuentra en Alfresco de forma correcta:

Con lo que ya tendríamos el “folder” del DataList y solo tendríamos que recorrer los “hijos” para cargar por ejemplo un control personalizado para rellenar alguna propiedad que nos interese.

Esta solución es viable para, como he comentado, usar tablas de datos maestros que se quieran tener directamente almacenadas en Alfresco (repositorio) y no tener que leerlas de fuentes externas como bases de datos o ficheros.

Además proporciona una ventaja adicional sobre la solución de leer datos de documentos que podemos tener también en Alfresco y es la facilidad que ya nos ofrece de crear nuevos “items” del DataList, modificarlos y borrarlos.

— Enlaces de interés —

https://code.google.com/p/luke/downloads/detail?name=lukeall-3.5.0.jar&

Alfviral 1.3.1-beta

Este puente de 3 días de fiesta los he dedicado, entre otras cosas, a crear mis proyectos y pasarlos de Google Code (¡gracias Google!) a GitHub y a refactorizar el código del módulo para la detección de virus en Alfresco, aunque las versiones anteriores, hasta la 1.3.0-420 seguirán estando en Google Code incluido el código fuente.

Entre las cosas que quedaban pendientes me ha dado tiempo a incluir 3 características principales aunque mi “hoja de ruta” va cambiando conforme tengo tiempo disponible así como las funcionalidades que los propios usuarios me vais pidiendo.
Las características principales añadidas a esta versión son:

  1. Incorporación del protocolo ICAP
  2. Notificaciones de infecciones a usuario y administrador
  3. Refactorización del código y creación del servicio AntivirusService

1. Incorporación del protocolo ICAP

El protocolo ICAP (Internet Content Adaptation Protocol) es un protocolo abierto para la redirección de contenidos con fines de filtrado y conversión. Este es muy usado para reenviar tráfico hacia antivirus, traducción, etc. En este caso, evidentemente, se utiliza para el envío de documentos de Alfresco hacia un servidor ICAP que se conecte a un antivirus, si bien, en realidad también podría utilizarse para más cosas, entre ellas traducción del documento, compresión, transformación, etc.

Se encuentra estandarizado en la RFC 3507 y para obtener más información se puede ir aquí.

Ahora, en Alfviral se puede configurar este modo como ICAP y con 3 parámetros de configuración que serán el servidor, puerto y servicio al que se necesita conectar. P.e. si usamos el servicor c-icap y lo configuramos para que utilice ClamAV podemos configurar el fichero alfviral.properties como:
alfviral.mode=ICAP
alfviral.icap.host=192.168.56.101
alfviral.icap.port=1344
alfviral.icap.service=srv_clamav
Aunque este sistema creo que es el mejor para casi todos los casos de uso he dejado los métodos anteriores para que puedan seguir siendo utilizados.

2. Notificaciones de infecciones a usuario y administrador

Aunque se podía realizar vía reglas de contenido, por ejemplo si hacíamos que los documentos infectados se movieran a una carpeta de cuarentena o infectados y ahí creábamos una acción de envío de correo, ahora se puede automatizar de forma general en la configuración de Alfviral. Por ahora se envían notificaciones al usuario que ha subido el documento y/o al administrador (admin) en forma de texto plano (text/plain) pero estoy trabajando para poder asignarle una plantilla personalizada según el caso. 
Por ahora para configurarlo basta con indicar a quién queremos enviarle las notificaciones.
alfviral.notify.user=true
alfviral.notify.admin=true

3. Refactorización del código y creación del servicio AntivirusService

Esto era algo que quería hacer hace tiempo. Hasta ahora todo el peso lo llevaba la clase VirusScan que era una acción, ahora ha pasado a llamarse VirusScanAction y he pasado la mayor parte del código a una nueva clase llamada AntivirusService y que funciona como servicio público, de hecho también he creado AntivirusServiceDescriptorRegistry y AntivirusServiceRegistry.
Esto hará más sencilla la actualización y extensión del módulo y la posibilidad de añadirle más métodos al servicio.
El módulo para descargar está disponible en el siguiente enlace: https://github.com/fegorama/alfviral/releases/download/v1.3.1-beta/alfviral-1.3.1-beta.zip
El código fuente se puede descargar de: https://github.com/fegorama/alfviral/archive/v1.3.1-beta.zip
El repositorio está en: https://github.com/fegorama/alfviral

Entrando por la “puerta de atrás” en Alfresco

Entre la arquitectura de funcionamiento de Alfresco se encuentra la capa de persistencia donde se guardan los datos necesarios para realizar las operaciones y tareas que hacen falta. Esta capa se divide a su vez en 4 elementos, la parte de configuración con ficheros de propiedades, la parte de almacenamiento de los documentos, el almacenamiento de los índices y el almacenamiento de las propiedades y otros valores (incluidas también configuraciones).

Esta última parte es guardada en un SGBD o Sistema de Gestión de Base de Datos (relacional) que puede ser MySQL, PostgreSQL, Oracle, SQL-Server, etc.
A veces, por determinadas circunstancias o necesidades debemos hacer uso de consultas directas a la base de datos para obtener datos, también sería posible modificar estos datos directamente pero no es aconsejable debido a que el control de lo que se guarda, modifica y borra lo tiene exclusivamente la aplicación de Alfresco. Como digo, en determinadas ocasiones es una posibilidad más el poder consultar directamente a la base de datos determinados datos que sean necesarios y de esta forma evitar pasar por la aplicación, por ejemplo en casos de que el servidor de aplicaciones (Alfresco) no levante correctamente, en casos de pérdidas de documentos y datos o de integridad que paren el servidor de aplicaciones o para monitorización por parte de algún programa externo.
Evidentemente este tipo de acciones son muy dependientes de la versión del esquema (schema) de Alfresco ya que este cambia con cada versión si bien, al estar en la capa del modelo de datos (no confundir con el modelo documental) cambia relativamente poco, sobre todo determinadas tablas muy importantes. De todas formas, es bueno tener el mapa de tablas y relaciones entre ellas para poder realizar bien cualquier consulta y tener la seguridad de que los datos proporcionados son coherentes. Hay que tener en cuenta que este modelo ha ido creciendo desde las primeras versiones, por ejemplo en la versión 2.1.0 Community había 24 tablas con el prefijo ALF, en la 3.4.11 había 46 y en la versión 4.2.2 hay 48 (solo dos tablas más con prefijo ALF). No se han tenido en cuenta las tablas usadas para el repositorio AVM, para el motor jBMP ni las utilizadas para Activiti.
Versión 2.1.0

Versión 2.2.6
Versión 3.4.11

Versión 4.2.2

Seguidamente voy a poner una serie de ejemplos en SQL lo más estándar posible, si bien, incluso lo más básico es dependiente también de la base de datos que use Alfresco en determinado momento. Estos son solo unos cuantos ejemplos de extracción de datos a través de la base de datos pero se pueden realizar muchas más operaciones de consulta según la necesidad concreta de cada uno.

Stores disponibles

Aunque no es muy necesario sí que a veces resulta interesante saber cuantos “almacenes” tiene nuestro repositorio, esto se podría realizar con la siguiente consulta:
SELECT * 
FROM alf_store;

Nodos disponibles

En Alfresco casi cualquier cosa es un nodo, un usuario, un grupo, una carpeta o un documento por ejemplo, para sacar los nodos disponibles podemos hacerlo como:
SELECT * 
FROM alf_node;
Pero no vamos a quedarnos aquí, podemos saber a que almacén pertenece cada nodo como:
SELECT uuid, protocol, identifier, alf_store.version 
FROM alf_node, alf_store
WHERE alf_node.store_id = alf_store.id;
Y ahora vamos a realizar una consulta que nos devuelva el nodo con la nomenclatura del tipo NodeRef, pero para esto ya nos encontramos con problemas, con la misma concatenación de campos, ya que dependerá de cada sistema de base de datos:
— Para Oracle
SELECT protocol || ‘://’ || identifier || ‘/’ || uuid AS nodeRef, 
alf_store.version, local_name   
FROM alf_node, 
alf_store, 
alf_qname   
WHERE alf_node.store_id = alf_store.id
AND   alf_node.type_qname_id = alf_qname.id;
— Para MySQL
SELECT CONCAT(protocol, ‘://’, identifier, ‘/’, uuid) AS nodeRef, 
alf_store.version, 
local_name   
FROM alf_node, 
alf_store, 
alf_qname   
WHERE alf_node.store_id = alf_store.id
AND   alf_node.type_qname_id = alf_qname.id;
— Para SQL-Server
SELECT protocol + ‘://’ + identifier + ‘/’ + uuid AS nodeRef, 
alf_store.version, 
local_name   
FROM alf_node, 
alf_store, 
alf_qname   
WHERE alf_node.store_id = alf_store.id
AND   alf_node.type_qname_id = alf_qname.id;

Extrayendo metadatos

La tabla más importante en Alfresco es alf_data_properties, esta es la que mantiene los valores de todas la propiedades de todos los nodos disponibles y es la que es más utilizada para devolver información ya que generalmente casi cualquier dato en Alfresco será una propiedad de un nodo. Por tanto, las siguientes tablas podríamos decir que son las básicas a la hora de realizar consultas directas:
  • alf_store : Guarda la información de los almacenes disponibles
  • alf_node : Guarda los nodos, aquí obtenemos el uuid que corresponde (con otros campos) al llamado NodeRef (referencia de nodo)
  • alf_qname : En versiones posteriores a 2.1 (2.2.x, 3.1.x, 3.2.x, 3.4.x, etc.) contiene los nombres identificativos de los tipos de propiedades, en versiones anteriores se almacenaba en un campo llamado alf_qname de la tabla alf_node_properties
  • alf_node_properties : Sin duda la tabla más importante a la hora de extraer datos en Alfresco, guarda los valores de las propiedades de los modelos de datos documentales de Alfresco, incluyendo los datos de las carpetas, documentos, usuarios, grupos, etc.
Con estas y alguna más de forma auxiliar podremos obtener la información necesaria.
Es interesante el uso de la tabla alf_qname (en versiones 2.2.x en adelante) porque con esta podemos posteriormente determinar que tipo de propiedad queremos, por tanto es buena idea tener un listado de los posibles nombres cualificados posibles:
— Versiones 2.2.x y siguientes
SELECT
FROM    alf_qname;
— Versiones 2.1.x
SELECT alf_node_properties.qname 
FROM alf_node_properties;
Veamos dos ejemplos sobre el uso de extraer propiedades, uno sobre los usuarios y otro sobre los documentos:
En ocasiones necesitamos saber los datos de un usuario en particular, las siguientes consultas nos devuelven un listado de usuarios:
— Versiones 2.2.x y siguientes
SELECT
    alf_node_properties.node_id,
    alf_node_properties.string_value
FROM
    alf_node_properties,
    alf_qname
WHERE
    alf_node_properties.qname_id = alf_qname.id
AND
    alf_qname.local_name = ‘userName’;
— Versiones 2.1.x
SELECT
    alf_node_properties.node_id,
    alf_node_properties.string_value 
FROM
    alf_node_properties 
WHERE
    alf_node_properties.qname = ‘{http://www.alfresco.org/model/content/1.0}userName’;
Y las siguientes (según la versión de Alfresco) nos devolverán la propiedades de un usuario concreto (sustituir NOMBRE-DEL-USUARIO por el nombre del usuario a buscar)
— Versiones 2.2.x y siguientes
SELECT
    alf_node_properties.node_id,
    alf_qname.local_name,
    alf_node_properties.string_value
FROM
    alf_node_properties,
    alf_qname
WHERE
    alf_node_properties.qname_id = alf_qname.id
AND
    alf_node_properties.node_id = (
        SELECT
            alf_node_properties.node_id
        FROM
            alf_node_properties,
            alf_qname
        WHERE
            alf_node_properties.qname_id = alf_qname.id
        AND
            alf_qname.local_name = ‘userName’
        AND
            alf_node_properties.string_value = ‘admin’
        );
— Versiones 2.1.x
SELECT
    alf_node_properties.node_id,
    alf_node_properties.qname, 
    alf_node_properties.string_value 
FROM
    alf_node_properties 
WHERE
    alf_node_properties.node_id = (
        SELECT
            alf_node_properties.node_id
        FROM
            alf_node_properties 
        WHERE
            alf_node_properties.qname = ‘{http://www.alfresco.org/model/content/1.0}userName’
        AND
            alf_node_properties.string_value = ‘NOMBRE-DEL-USUARIO’
        );
Y por último una aplicación real cuando se necesita el nombre que Alfresco ha puesto en el repositorio. En casos de recuperación de documentos necesitamos saber donde está guardado el fichero en el repositorio a partir del nombre del documento guardado en Alfresco. Esta consulta nos devuelve esta información a partir del nombre del documento. Es para la versión 3.4.x y 4.x
— Versiones 3.4.x y 4.x
SELECT alf_node_properties.node_id,
alf_node_properties.string_value,
alf_content_url.content_url
FROM alf_node_properties,
alf_qname,
alf_content_data,
alf_node_properties,
alf_content_url
WHERE alf_node_properties.string_value = ‘NOMBRE-DEL-DOCUMENTO’ 
AND alf_node_properties.qname_id = alf_qname.id 
AND alf_qname.local_name = ‘name’ 
AND alf_content_data.id = alf_node_properties.long_value 
AND alf_node_properties.node_id = alf_node_properties.node_id 
AND alf_node_properties.long_value = alf_content_data.id 
AND alf_content_data.content_url_id = alf_content_url.id;

Cluster con Hazelcast en Alfresco One 4.2.2

Si hay algo en lo que Alfresco ha trabajado en cada una de las versiones que han visto la luz ha sido el tema de cluster y la comunicación entre los nodos. En las versiones 2.x con EHCache y un sistema de multicast que era bastante pobre, usando JGroups en la 3.x hasta llegar a la 4.2.x con Hazelcast.

Pero, ¿qué es Hazelcast?

Es según la propia página web oficial un “Open Source In-Memory Data Grid”, es decir, una plataforma para la distribución de datos de código abierto. Entre sus características podemos encontrar:

  • Implementaciones distribuidas de Set, List, Map, Lock, MultiMap
  • Mensajería distribuida P/S
  • Soporte transaccional e integración JEE vía JCA
  • Soporte encriptación a nivel de sockets
  • Persistencia síncrona o asíncrona
  • Clusterizado Sesión HTTP
  • Discovery dinámico
  • Monitorización JMX
  • Escalado dinámico
  • Particionado dinámico
  • Fail-over dinámico

Como se puede ver, es una herramienta fantástica para cumplir las especificaciones de cluster que necesita Alfresco.

Las funciones de las que se sirve Alfresco y que son comunes a Hazelcast están:

  • Compartir datos/estados entre varios servidores: como compartición sesión Web
  • Cacheo distribuido de datos
  • Comunicación segura entre servidores
  • Particionado de datos en memoria
  • Distribución de trabajo entre servidores
  • Procesamiento paralelo
  • Gestión fail-safe de datos

Además se lleva muy bien con Hibernate como caché de segundo nivel y con Spring.

¿Cómo configuramos el cluster de Alfresco 4.2.2?

Para configurar un sistema de cluster en Alfresco 4.2.2 es tan fácil como cuando se configuraba con EHCache o JGroups e incluso más todavía y eso sí, se comprueba la fiabilidad que tiene este producto integrado en Alfresco.

Hay que entender que aquí explico solamente como montar el cluster, es decir, que ambos nodos se comuniquen entre sí, un sistema completo de alta disponibilidad requiere de un balanceador ya sea hardware o software, un sistema de cluster en la base de datos, etc.

Lo primero que hay que hacer es quitar cualquier referencia a EHCache y JGroups antiguos, esto va orientado a sistemas que han ido siendo actualizados desde versiones antiguas principalmente:

Por ejemplo, el fichero que está dentro de {alfrescoRoot}/tomcat/shared/clases/alfresco/extensión:

ehcache-custom.xml

También en dicha localización (si existe) el fichero:

hazelcastConfig.xml

Este fichero se ha incluido ya dentro del fichero alfresco.war con lo que no hace falta.

Así como las siguientes propiedades que están dentro de {alfrescoRoot}/tomcat/shared/clases/alfresco-global.properties:

alfresco.cluster.name
alfresco.ehcache.rmi.hostname
alfresco.ehcache.rmi.port
alfresco.ehcache.rmi.remoteObjectPort
alfresco.jgroups.defaultProtocol
alfresco.jgroups.bind_address
alfresco.jgroups.bind_interface
alfresco.tcp.start_port
alfresco.tcp.initial_hosts
alfresco.tcp.port_range
alfresco.udp.mcast_addr
alfresco.udp.mcast_port
alfresco.udp.ip_ttl
filesystem.cluster.enabled
filesystem.cluster.configFile

Configuración del cluster para el repositorio

Por defecto si apuntamos dos instancias de Alfresco al mismo repositorio y base de datos, estos formarán de forma automática un grupo de repositorio, no obstante hay que realizar una pequeña configuración para que todo funcione correctamente.

Montar el repositorio de forma compartida y visible para todos los nodos, por ejemplo vía NAS o SAN a través de protocolo NFS.

Configurar el acceso a la base de datos para la misma base de datos en cada uno de los nodos.

Abrir el puerto 5701 TCP en el cortafuegos de los nodos para que puedan ser accesibles entre ellos.

Especificar correctamente la IP (sea en wildcard como por ejemplo 192.168.1.*) de la tarjeta de red del cluster:

alfresco.cluster.interface=192.168.1.101

Fijar la propiedad para activar Hazelcast en JMX

hazelcast.jxm=true

Y por razones de seguridad se debería fijar la contraseña con la siguiente propiedad:

alfresco.hazelcast.password=

Un ejemplo de la parte del fichero alfresco-global.properties para la configuración del cluster puede ser la siguiente:

alfresco.cluster.enabled=true
alfresco.cluster.interface=192.168.1.101
alfresco.hazelcast.password=clavehazelcast
alfresco.hazelcast.port=5701
alfresco.hazelcast.autoinc.port=false
alfresco.hazelcast.mancenter.enabled=false
alfresco.hazelcast.max.no.heartbeat.seconds=15

Una vez arrancada la primera instancia se puede observar un mensaje como el siguiente:

2014-06-30 22:38:36,148 INFO [cluster.core.ClusteringBootstrap] [localhost-startStop-1] Cluster started, name: MainRepository-fea9ebdf-04f3-495e-9456-cf43c24b8e91
2014-06-30 22:38:36,152 INFO [cluster.core.ClusteringBootstrap] [localhost-startStop-1] Current cluster members:
192.168.1.101:5701 (hostname: alfnode1.localdomain)

Finalmente al arrancar el segundo en este se observará lo siguiente:

2014-07-02 10:58:12,108 INFO [cluster.core.ClusteringBootstrap] [localhost-startStop-1] Cluster started, name: MainRepository-fea9ebdf-04f3-495e-9456-cf43c24b8e91
2014-07-02 10:58:12,111 INFO [cluster.core.ClusteringBootstrap] [localhost-startStop-1] Current cluster members:
192.168.1.102:5701 (hostname: alfnode2.localdomain)
192.168.1.101:5701 (hostname: alfnode1.localdomain)

También se puede ver que el cluster está bien configurado mediante la nueva consola de administración cuya URL es:

http://
:8080/alfresco/service/enterprise/admin

En “Servicio de repositorio” y dentro de este en “Agrupación de servidores del repositorio” se puede ver toda la información del cluster, además se puede validar con el botón “Validar grupo” que realiza las comprobaciones necesarias para saber si ambos nodos se están comunicando correctamente:

Propiedades de Hazelcast

Todas las propiedades admitidas por Hazelcast en alfresco-global.properties son:

alfresco.cluster.enabled
Ejemplo: true
Descripción: Activa el cluster de Alfresco para este nodo

alfresco.cluster.interface
Ejemplo: 192.168.80.1
Descripción: Especifica la tarjeta de red usada para el cluster. Se puede usar tipo de dirección wildcard, por ejemplo 192.168.80.*

alfresco.cluster.nodetype
Ejemplo: NodoDesconectado001
Descripción: Especifica un nombre “amigable” para ese nodo del cluster, generalmente utilizado para servidores que se han unido al repositorio pero no forman parte del cluster (p.e. servidores de indexación)

alfresco.hazelcast.password
Ejemplo: mipasswd
Descripción: Define el password que usarán los nodos del cluster

alfresco.hazelcast.port
Ejemplo: 5701
Descripción: Establece el puerto de comunicación entre nodos del cluster

alfresco.hazelcast.autoinc.port
Ejemplo: false
Descripción: Realiza varios intentos de puertos para hayar uno libre desde la configuración alfresco.hazelcast.port. Alfresco no recomienda establecer esta propiedad

alfresco.hazelcast.mancenter.enabled
Ejemplo: false
Descripción: Activa las estadísticas y otros valores del cluster donde se puede acceder a través del Centro de gestión de Hazelcast

alfresco.hazelcast.mancenter.url
Ejemplo: http://localhost:8080/mancenter
Descripción: URL de acceso al centro de gestión de Hazelcast, evidentemente alfresco.hazelcast.mancenter.enabled debe estar en valor true

alfresco.hazelcast.max.no.heartbeat.seconds
Ejemplo: 15
Descripción: Tiempo máximo de monitorización para que se de por hecho que un nodo no está respondiendo

Configuración de Hazelcast en Share

En un entorno de cluster, Alfresco Share ahora utiliza Hazelcast para proporcionar mensajes entre los nodos de la capa web. Como resultado, las cachés ya no necesitan estar deshabilitadas para cualquier nodo. Cada uno funciona prácticamente tan rápido como una sola instancia de Share, mejorando así su rendimiento general.

Se pueden realizar dos configuraciones según las necesidades, con multicast o a nivel de TCP directo.

En todo caso, en balanceadores hay que seguir usando el sistema de Sticky-Session para funcionar correctamente. Hay que configurar correctamente el fichero share-config-custom.xml dentro de {extensionRoot}/alfresco/classes/web-extension poniendo correctamente el host y puerto de acceso al repositorio en caso necesario.

También hay que tener en cuenta que si se usa autenticación Kerberos o NTML con SSO las sesiones utilizarán la cookie JSESSIONID por lo que habrá que tenerla en cuenta por parte del balanceador.

Para esto hay que configurar el fichero custom-slingshot-application-context.xml
que hay en {extensionRoot}/alfresco/classes/web-extension (quitándole la extensión .sample)

Ejemplo para multicast:

 <!– Hazelcast distributed messaging configuration – Share web-tier cluster
    config (3.4.8 and 4.0.1) – see http://www.hazelcast.com/docs.jsp – and specifically
    http://www.hazelcast.com/docs/1.9.4/manual/single_html/#SpringIntegration –>
<!– Configure cluster to use either Multicast or direct TCP-IP messaging
    – multicast is default –>
<!– Optionally specify network interfaces – server machines likely to have
    more than one interface –>
<!– The messaging topic – the "name" is also used by the persister config
    below –>
<hz:topic id="topic" instance-ref="webframework.cluster.slingshot"
    name=”slingshot-topic” />

    
        
        
            
                <hz:multicast enabled="true" multicast-group="224.2.2.5"
                    multicast-port=”54327″ />
                
                    
                
            
            
                192.168.1.*
            
        
    

<bean id="webframework.slingshot.persister.remote"
    class=”org.alfresco.web.site.ClusterAwarePathStoreObjectPersister”
    parent=”webframework.sitedata.persister.abstract”>
    
    
        alfresco/site-data/${objectTypeIds}
    
    
    
        slingshot-topic
    

<bean id="webframework.factory.requestcontext.servlet" class="org.alfresco.web.site.ClusterAwareRequestContextFactory"
    parent=”webframework.factory.base”>
    
    
    
    

Ejemplo para conexión directa TCP:

<!– Hazelcast distributed messaging configuration – Share web-tier cluster
    config (3.4.8 and 4.0.1) – see http://www.hazelcast.com/docs.jsp – and specifically
    http://www.hazelcast.com/docs/1.9.4/manual/single_html/#SpringIntegration –>
<!– Configure cluster to use either Multicast or direct TCP-IP messaging
    – multicast is default –>
<!– Optionally specify network interfaces – server machines likely to have
    more than one interface –>
<!– The messaging topic – the "name" is also used by the persister config
    below –>
<hz:topic id="topic" instance-ref="webframework.cluster.slingshot"
    name=”slingshot-topic” />

    
        
        
            
                <hz:multicast enabled="false" multicast-group="224.2.2.5"
                    multicast-port=”54327″ />
                
                    alfnode1,alfnode2
                
            
            
                192.168.1.*
            
        
    

<bean id="webframework.slingshot.persister.remote"
    class=”org.alfresco.web.site.ClusterAwarePathStoreObjectPersister”
    parent=”webframework.sitedata.persister.abstract”>
    
    
        alfresco/site-data/${objectTypeIds}
    
    
    
        slingshot-topic
    

<bean id="webframework.factory.requestcontext.servlet" class="org.alfresco.web.site.ClusterAwareRequestContextFactory"
    parent=”webframework.factory.base”>
    
    
    
    

Centro de gestión Hazelcast (mancenter):

El centro de gestión Hazelcast (mancenter) permite monitorizar y administrar los servidores que ejecutan Hazelcast. Además, mancenter permite supervisar el estado general de los clústeres, y analizar y examinar las estructuras de datos en detalle.

Para instalarlo, se puede instalar tanto en un tomcat distinto como en el mismo de Alfresco. Solo hay que bajar una versión de Hazelcast (mancenter) y copiar el fichero mancenter-x.x.x.war al directorio de aplicaciones de tomcat.

Por ejemplo:

cp mancenter-2.4.1.war /opt/Alfresco422/tomcat/webapps/mancenter.war

Establecer la propiedad hazelcast.mancenter.home con el directorio donde se almacenan los datos, aquí se puede poner en la misma línea de opciones de Java (JAVA_OPTS), por ejemplo:

-Dhazelcast.mancenter.home=/opt/Alfresco422/tomcat/mancenter_data

Acordarse de activarlo en alfresco-global.properties:

alfresco.hazelcast.mancenter.enabled=true

Establecer la url de acceso, por ejemplo:

alfresco.hazelcast.mancenter.url=http://192.168.1.101:8080/mancenter

Por último, si se produce un error de serialización en el arranque, descomentar la siguiente línea en el contex.xml del servidor Tomcat:


 

Monitorización del funcionamiento de Hazelcast en Alfresco

La mejor forma como siempre es usando Log4j y para esto se puede usar la siguiente propiedad:

log4j.logger.org.alfresco.enterprise.repo.cluster=info

Para monitorizar la caché también se usan las siguientes propiedades:

log4j.logger.org.alfresco.enterprise.repo.cluster.cache=DEBUG
log4j.logger.org.alfresco.repo.cache=DEBUG

A nivel del propio Hazelcast:

log4j.logger.com.hazelcast=info

Y para aumentar el registro de seguimiento también se puede usar:

log4j.logger.com.hazelcast.impl.TcpIpJoiner=debug

Para finalizar

Las pruebas realizadas con un cluster de Alfresco One 4.2.2 usando Hazelcast han resultado ser muy satisfactorias, he realizado pruebas de subida de documentos, cambios de propiedades, etc. y eran instantáneas en ambos nodos.

Hay que tener en cuenta además que hay que configurar Solr (si se usa esta opción de indexado) correctamente para que se use de forma compartida, siempre y cuando no se utilize protocolo NFS para estos recursos compartidos de red ya que no está aconsejado. En este cado (uso de NFS) también se puede seguir usando una configuración similar a la que se utilizaba con Lucene, es decir, mantener índices locales por cada nodo.

Más información

http://docs.alfresco.com/4.2/concepts/ha-intro.html
http://hazelcast.org
http://unpocodejava.wordpress.com/2013/01/21/que-es-hazelcast/