Más sobre digitalización y escaneo en Alfresco: tabla con opciones existentes

Durante mi visita a algunos partners en LATAM he estado hablando de características y nuevas funcionalidades de Alfresco, aparte de todo eso, la mayoría de ellos me preguntaron qué opciones ofrece Alfresco para resolver el problema de escaneo o el paradigma “paperless”. Dibujé en varias ocasiones un diagrama con las opciones existentes y he querido ponerlo en digital para compartirlo con vosotros. Este diagrama será la base para el webinar que haremos en dentro de unos meses sobre “Soluciones de escaneo con Alfresco”, al que puedes registrarte desde aquí. En los comentarios podéis compartir vuestra opinión o añadir otras opciones que no haya tenido en cuenta. Espero que os sea útil y con vuestras dudas o comentarios hacer un webinar más completo y atractivo.

Pincha en la imagen para verlo a tamaño completo

Video del webinar “Alfresco Share para usuarios: teoría y práctica”

En este webinar repasamos las características más destacadas de Alfresco Share y una hacemos una parte práctica a nivel de usuario para comenzar a usar Alfresco y poder aprovechar todo su potencial. Configuración del panel de inicio, Creación de sitios, uso de reglas, metadatos, transformaciones, etc. Gracias a Jose Pereira que me ayudó tanto a la preparación de la presentación como la parte de la demo. Te recomiendo mirar su web ya que ha publicado documentos muy buenos sobre Alfresco en español.

Alfresco Share para usuarios: teoria y práctica from Alfresco Spain Portugal on Vimeo.

Alfresco scheduled jobs, tareas automáticas de mantenimiento

Con el objetivo de ampliar el conocimiento en Alfresco y enseñar algunos aspectos que no se suelen tratar a menudo, en esta ocasión quiero explicar unos procesos que intervienen cada día en el mantenimiento de Alfresco y que generalmente desconocemos o no los tenemos en cuenta. Se trata de los “scheduled jobs”.
En Alfresco se ejecutan una serie de procesos automáticos de mantenimiento, algunos de ellos son nocturnos y otras se lanzan automáticamente cada cierto tiempo. Estas tareas son ajenas al usuario final pero no deberían serlo para los administradores de la plataforma. En docs.alfresco.com podréis encontrar información que os voy a resumir en este artículo.
Todos esas tareas están definidas en <configRoot>/scheduled-jobs-context.xml (cuando hablo de <configroot> me estoy refiriendo a la configuración dentro del fichero alfresco.war, ahí no debes tocarla, más abajo cuento como modificarlo, si fuese necesario). Algunas de las expresiones cron de estas tareas están definidas en <configRoot>/repository.properties. Recuerda que la sintaxis de este cron es diferente a la de UNIX, es Quartz y puedes ver ejemplos para entenderlo mejor aquí. si quieres cambiar algunas puedes hacerlo en alfresco-global.properties. Estas son las tareas de las que hablo:
  • contentStoreCleanerTrigger: Lanza el bean contentStoreCleaner, que identifica, borra o purga contenidos huérfanos del contentstore. Un contenido es huérfano cuando todas las referencias en la base de datos al binario se han eliminado. En un entorno en cluster este proceso se puede activar en un sólo nodo, con lo que se mejora el rendimiento durante el proceso. Por defecto se ejecuta a las 4:00 AM cada día (0 0 4 * * ?). El parámetro “ProtectDays” establece el número mínimo de días que el contenido debe ser huérfano antes de poder eliminarlo, el valor predeterminado es de 14 días.
  • nodeServiceCleanupTrigger: Realiza operaciones de limpieza en los nodos del DM, incluyendo transacciones antiguas y nodos antiguos eliminados. En un entorno en cluster este proceso se puede activar en un sólo nodo, con lo que se mejora el rendimiento durante el proceso. Se ejecuta a las 21:00h de cada día (0 0 21 * * ?).
  • openOfficeConnectionTesterTrigger: Monitoriza y mantiene la conexión con OpenOffice. Se ejecuta cada minuto (0 * * * * ?).
  • indexBackupTrigger: Hace un backup seguro de los directorios de Lucene. Crea el directorio “backup-lucene-indexes” y copia de forma segura la información de Lucene. Para conocer mejor como restaurarlo de forma incremental y evitar “FULL indexes” mira aquí. En un entorno en cluster este proceso se debe ejecutar en todos los nodos. Se ejecuta todos los días a las 3:00 AM (0 0 3 * * ?).
  • tempFileCleanerTrigger: Limpia todos los ficheros temporales de Alfresco cada cierto tiempo. También se vacían directorios temporales y sus subdirectorios. Existe un parámetro llamado “protectHours” que permite indicar el tiempo de conservación de un fichero temporal desde su última modificación. Por ejemplo, ficheros resultantes de transformaciones, extractores, temporales de OpenOffice, etc., generalmente almacenado en <tomcat>/temp/Alfresco. Se ejecuta cada hora en el minuto 30 (0 30 * * * ?).
  • avmOrphanReaperJob y avmExpiredContentTrigger: la primera tarea se ejecuta cada minuto para eliminar nodos huérfanos en el repositorio AVM y la segunda tarea sirve buscar contenido caducado en cada Web Project de WCM, se ejecuta cada día a las 3:30 AM. Si no has instalado AVM no te debes preocupar de esto, ya no se instala por defecto. Es el repositorio que usaba la implementación anterior de WCM.
  • ehCacheTracerJob: Recoge las estadísticas detalladas de uso de la caché y las salidas por consola, dependiendo de la configuración de logs del servidor. Por defecto, no está activado. Para activarlo hay que eliminar el comentario correspondiente en el xml de configuración. Si se activa, se ejecuta en intervalos de 60 minutos.
  • ftsIndexerTrigger: Esta tarea, aunque está en el fichero anterior, no es una tarea planificada en un momento concreto como tal, es para mantener los índices continuamente, se ejecuta cada minuto.
  • Cuando Alfresco está configurado en cluster hay un proceso llamado “index.tracking” que se lanza cada 5 segundos y se encarga de mantener los índices de todos los nodos del cluster sincronizados.
  • Sincronización de usuarios con LDAP: No es una tarea que que se gestione desde este fichero, pero es algo a tener en cuenta dentro de los trabajos planificados ya que dependiendo de la cantidad de usuarios que se sincronicen y la periodicidad de la sincronización, podría afectar al rendimiento de la plataforma. Una o dos veces al día, serían suficientes.
Recuerda que todos los detalles a bajo nivel de estas tareas específicas están descritas en el Java Doc de Alfresco en http://dev.alfresco.com/resource/docs/java/.
Estos trabajos planificados se pueden monitorizar mediante JXM en el bean Alfresco:Name=Schedule,Group=*,Type=*,Trigger=*
¿Cómo puedo cambiar el horario o configuración de estas tareas existentes? Hay dos formas de acceder a dicha información pero sólo una para modificarlos que es mediante archivos de configuración xml. Aunque si accedemos por JMX con la utilidad, por ejemplo, jconsole, podremos lanzar bajo demanda los procesos que necesitemos en cada momento o forzar la ejecución algún proceso concreto. Para cambiarlo modificando ficheros de configuración deberás copiar el fichero <configRoot>/alfresco/scheduled-jobs-context.xml a <extension>/custom-scheduled-jobs-context.xml y editarlo a tu gusto o necesidad.
Para ver los valores de las tareas y forzar su ejecución mediante JMX accede a tu servidor Alfresco con jconsole, aquí ves dos capturas, la primera es la vista general del bean:
y en la segunda vemos el ejemplo de la tarea que hace backup de los índices cada noche a las 3AM:
En la sección “Operations” de cada “Trigger” encontrarás un botón llamado “executeNow“, adivina para que sirve 😉 Cada tarea o trigger tiene una serie de propiedades que se explican por si solas, aunque me gustaría destacar la propiedad “Priority” que permite ejecutar una tarea sobre otra en caso de coincidir.
¿Cómo puedo hacer mi propia tarea planificada? Es algo que igual podría cubrir en un próximo artículo, de cualquier forma, puedes ver como hacerlo en esta página de la wiki. Y también puedes echar un vistazo al fichero <extension>/scheduled-action-services-context.xml.sample que es bastante ilustrativo.

Video del webinar “Gestión del almacenamiento en Alfresco”

En este webinar sobre “Gestión de almacenamiento en Alfresco” veremos cómo configurar y usar Content Store Selector para implementar ILM (Information Lifecycle Management), XAM-CAS connector para poder conectar Alfresco en sistemas de almacenamiento específicos como Centera, Hitachi, HP u otros con soporte XAM y por último veremos qué es y cómo funciona Transfer y Replication Services para poder transferir contenidos entre repositorios de Alfresco.

Consejos sobre los logs en Alfresco

Como muchos ya sabréis, Alfresco utiliza Log4j para los logs. Log4j es una herramienta Open Source para gestionar logs y permite a programadores y administradores controlar lo que ocurre en la aplicación de forma granular y a diferentes niveles de detalle.

Controlar cómo funcionan los logs en Alfresco es la mejor forma de conocer como funciona el sistema tanto para administradores como programadores y poder detectar/solucionar problemas en una instalación.

Se configura mediante un fichero de texto llamado log4j.properties que se encuentra dentro de alfresco.war concretamente en el caso de Tomcat en ${TOMCAT_HOME}/webapps/alfresco/WEB-INF/classes. En este fichero se especifica qué queremos que registre el log y cómo queremos que lo muestre (mayor o menor detalle). También es donde se establece el nombre del fichero de log (alfresco.log) y los ficheros de log anteriores a los que le añade fecha (alfresco.log.YYYY-MM-DD). Estos ficheros de logs generados los encontraremos en la raíz del directorio donde hemos instalado Alfresco también conocido como ${ALFRESCO_HOME}, ojo, ni esta variable ni ${TOMCAT_HOME} existen salvo que se declaren, se usa para indicar el directorio raíz de instalación de Alfresco y de Tomcat respectivamente.

Vamos a ver como cambiar la ubicación del fichero de log de Alfresco. Copiamos el fichero log4j.properties al directorio extension con otro nombre, por ejemplo custom-log4j.properties:

[bash]
# cp ${TOMCAT_HOME}/webapps/alfresco/WEB-INF/classes/log4j.properties ${TOMCAT_HOME}/tomcat/shared/classes/alfresco/extension/custom-log4j.properties
[/bash]

Este cambio nos permitirá tener siempre la misma configuración de logs independientemente de que actualicemos Alfresco y despleguemos un nuevo alfresco.war donde se sobreescribiría la configuración personalizada si la hacemos dentro del war desplegado.

Editamos el fichero custom-log4j.properties y localizamos la línea:

[bash]
log4j.appender.File.File=alfresco.log
[/bash]

para especificar la siguiente:

[bash]
log4j.appender.File.File=/var/log/alfresco/alfresco.log
[/bash]

Como veis, este ejemplo está orientado a un sistema Linux o Unix, hay que tener en cuenta que si queréis poner los logs como he indicado hay que crear el directorio /var/log/alfresco y darle los permisos necesarios para que el usuario con el que se ejecuta Alfresco pueda escribir. También podríais poner los logs en alf_data/logs y así tener todo más centralizado. Para Windows habría que cambiar la ruta absoluta en el siguiente formato, por ejemplo “D:\logs\alfresco\alfresco.log”. Una recomendación de índole general para cualquier aplicativo y sus logs es disponer de una partición independiente encargado de almacenar estos ficheros (generalmente /var/log), de forma que si nos quedamos sin espacio en disco tanto en la aplicación como en los logs, no afecte al funcionamiento y podamos detectarlo de forma anticipada ya sea chequeando manualmente o con un sistema de monitorización, evidentemente también podemos poner una partición dedicada a los logs de Alfresco. Recuerda hacer backup de los logs regularmente.

Para entender mejor la sintaxis y opciones que encontramos en el fichero de configuración os recomiendo leer esta entrada en la Wikipedia. Destacaría el parámetro log4j.appender.File que especifica la rotación diaria del fichero de log y log4j.appender.File.File que permite indicar el nombre y path del fichero de log.

En cuanto a los niveles de detalle es importante conocer que existen los siguientes (de menos a mas detalle): OFF, FATAL, ERROR, WARN, INFO, DEBUG, TRACE y ALL. Así que hay que tener cuidado con tener DEBUG, TRACE o ALL en un sistema en producción, salvo que sea necesario para solucionar un problema. Aquí puedes ver más información al respecto.

Si usáis un servidor de aplicaciones Tomcat, también es recomendable cambiar la ubicación del fichero de logs de Tomcat (o cualquier otro servidor de aplicaciones soportado), aquí vemos como cambiar el sitio donde se almacena el fichero catalina.out:

Editamos el fichero ${TOMCAT_HOME}/bin/catalina.sh, localizamos las líneas:

[bash]
if [ -z "$CATALINA_OUT" ] ; then
CATALINA_OUT="$CATALINA_BASE"/logs/catalina.out
fi
[/bash]

Y cambiamos la ruta de CATALINA_OUT por la ruta deseada:

[bash]
if [ -z "$CATALINA_OUT" ] ; then
CATALINA_OUT="/var/log/alfresco/catalina.out"
fi
[/bash]

Para que los cambios anteriores surtan efecto hay que reiniciar el servidor de aplicaciones. Una vez reiniciado ya veremos los ficheros creados en el directorio correspondiente.

Todo lo que hemos visto anteriormente se puede hacer de una forma más sencilla accediendo al servidor con jconsole mediante RMI y sin tener que reiniciar el servidor. En Alfresco Enterprise 3.4 ya está activado el acceso remoto. Aquí expliqué como acceder por jconsole a Alfresco.

Como vemos en la siguiente captura de pantalla, en la sección MBeans podemos encontrar un grupo llamado “log4j” y desplegado podemos ver todas sus opciones.

Concretamente en la captura anterior vemos los “Attributes” del bean “File“, y ahí podemos cambiar las opciones como por ejemplo “file”, el fichero y ruta de log. Una vez cambiado a nuestro gusto, para que tenga efecto vamos a “Operations“, hacemos clic en “activateOptions” y listo.

Por ejemplo, los logs de Webdav por defecto están configurados como detalle tipo “ERROR”, si queremos hacer un análisis más exhaustivo podríamos localizar el bean “org.alfresco.webdav.protocol” y desplegamos el menú “Attributes” y hacemos clic en “priority“, doble clic en “ERROR” para editarlo y lo cambiamos por “DEBUG” (sin comillas), a continuación guardamos simplemente pulsando la tecla “Enter” y ya tendríamos configurado el nivel de log del componente de turno. Fácil ¿no?

Para terminar quiero mencionar este pequeño desarrollo que ha realizado Tjarda Peelen – @tpeelen que permite ver los logs en la propia interfaz de la aplicación. Puede ser útil.

También se podría usar Log4mongo u otras aplicaciones para presentar logs vía web, pero eso ya es otra historia.

¿Algún consejo más? ¡Cualquier comentario es bienvenido!

Video del webinar “Personalizando Alfresco Share”

Aquí está a vuestra disposición el video del webinar celebrado sobre “Personalización de Alfresco Share”. Os recuerdo el abstract: “Webinar donde aprenderemos a personalizar Alfresco Share con dashlets de diferentes tipos, integrarlo con aplicaciones externas como Flickr, Twitter, Google News y otros recursos externos o cómo personalizar tu propio tema (diseño) y sacar el máximo partido a la plataforma.”

Screencast sobre integración de Alfresco y Google Docs

En colaboración con Fernando Gonzalez hemos preparado el siguiente screencast para mostrar como funciona Alfresco en colaboración con Google Docs, ya sea con tus cuentas de Gmail o con tu propio dominio de Google Apps.

Los objetivos principales de esta integración son:

  • Permitir el acceso a documentos, su edición y colaboración desde cualquier navegador.
  • Colaboración en tiempo real con documentos ofimáticos existentes en Alfresco o creados directamente en Alfresco con Google Docs.
  • Disfrutar de todas las capacidades de colaboración de Google Docs junto con las funcionalidades de gestión de metadatos y seguridad de Alfresco.

Aquí tienes el video y en el blog de Fernando Gonzalez más información, detalles sobre su configuración y puesta en marcha.

Recuerda en la configuración debes indicar el parámetro “googledocs.url” con HTTPS: https://docs.google.com/feeds/default/private/full. Más info aquí http://googleappsdeveloper.blogspot.com/2011/09/requiring-ssl-for-documents-list.html

Conoce el estándar CMIS: Trabajar con CMIS

CMIS soporta SOAP y también REST a través del protocolo AtomPub. Atom o AtomPub es un estándar del IETF para la creación y actualización de los recursos web. Está basado en REST y es muy flexible en la extensión de los metadatos que maneja. Este protocolo es la base para la API REST.
CMIS está hecho pensado en los sistemas existentes y para permitir casos uso básicos, tales como:
    • Permite a los usuarios la creación colaborativa de contenido, por ejemplo para hacer uno o más documentos, páginas web, etc.
    • Una forma de acceso a portales, con CMIS se permite visualizar y mostrar contenidos desde múltiples fuentes.
    • Mashups de contenidos en sitios web, sitios web que usan CMIS pueden crear aplicaciones compuestas o integrar los datos y las funcionalidades de uno o varios repositorios.
    • Búsqueda paralela contra múltiples interfaces de repositorios CMIS.
  • Repositorio CMIS
CMIS se centra en servicios que puede ofrecer un repositorio para ser realmente interoperable. Estos servicios están basados en gestión de contenidos, metadatos e índices.
El repositorio CMIS, es la forma que tiene Alfresco de mostrar todos los contenidos cumpliendo los requerimientos del estándar. Mediante CMIS podemos ver las capacidades CMIS de nuestro Alfresco en este enlace http://localhost:8080/alfresco/service/cmis/index.html. Vamos a ver con más detalle tres conceptos fundamentales:
    • Consultas CMIS
    • Servicios CMIS
    • Modelo de objetos CMIS
  • Consultas CMIS:
Una consulta CMIS se basa en SQL-92. La consulta es de sólo lectura y no permite manipulación de datos.
En la sintaxis que se puede utilizar están las siguientes cláusulas:
    • SELECT con una lista de objetos
    • FROM con los tipos de objeto que se consultan
    • JOIN para realizar una combinación entre los tipos de objetos (aspectos).
    • WHERE con especificar una condición
    • IN y ANY para consultar propiedades multi-valuadas.
    • CONTAINS para especificar un texto concreto en la búsqueda.
    • IN_FOLDER y IN_TREE para buscar dentro de una jerarquía de carpetas.
    • ORDERBY para ordenar los resultados.
Para hacernos una idea, podríamos entender una consulta CMIS en una estructura relacional donde el tipo de objeto sería como una tabla, el objeto como una fila y la propiedad como una columna que puede tener varios valores. Además se puede consultar el contenido binario real mediante una consulta de texto completo e información de ruta de la carpeta con ayuda de las funciones in_tree y in_folder. Las consultas también se pueden paginar para crear la interfaz de presentación al usuario. Estos son algunos ejemplos de consultas:

[sql]
SELECT * FROM cmis:document
SELECT * FROM cmis:document WHERE cmis:name = ‘invite-email.ftl’
SELECT * FROM cmis:document WHERE cmis:creationDate > TIMESTAMP ‘2011-04-01T00:00:00.000+00:00’
SELECT * FROM cmis:document WHERE CONTAINS(‘alfresco’)
[/sql]

  • Servicios CMIS:
Como hemos comentado, CMIS proporciona servicios a los que puede acceder mediante SOAP o AtomPub (REST), que se pueden usar dependiendo de la preferencia o caso de uso. Estos son los servicios CMIS soportados:
    • Servicios del Repositorio: permiten descubrir repositorios disponibles, obtener la capacidad de estos repositorios y proporcionar información de los tipos disponibles en el repositorio desde el Diccionario de Datos.
    • Servicios de Navegación: permiten navegar por el repositorio mediante el acceso al árbol de carpetas. Se pueden utilizar estos servicios para saber elementos padres e hijos de un objeto concreto.
    • Servicios de Objeto: proporcionan CRUD (Crear, Leer, Actualizar, Borrar) y control de los servicios en cualquier objeto, incluyendo documento, carpeta, política y objetos relacionados. Para los documentos, esto incluye establecer y obtener de sus propiedades, políticas y el contenido en si mismo. Estos servicios se pueden usar mediante la ruta al objeto o el identificador único del objeto. También se pueden saber para qué acciones están autorizados los usuarios.
    • Multifiling Services: permiten establecer jerarquías añadiendo o eliminando un objeto de una carpeta.
    • Servicios de Descubrimiento (discovery services): permiten los servicios de consultas y cambios, adicionalmente permiten paginación de los resultados de las consultas.
    • Servicios de Cambios: permiten saber lo que el contenido ha cambiado desde la última vez que se ha marcado el contenido. Se pueden utilizar estos servicios de cambio para la indexación externa y para servicios de replicación.
    • Servicios de Control de Versiones: funcionan en paralelo a los servicios objeto y proporcionan los servicios de check-in y check-out, además de el historial de versiones de los objetos versionados.
    • Servicios de Relación: permiten crear, gestionar y acceder a las relaciones o asociaciones entre objetos.
    • Servicios de Políticas: se aplican sobre los objetos del repositorio. Las políticas son los objetos utilizados para implementar seguridad, registro o control.
    • Servicios de ACL: permiten crear, gestionar y acceder a las listas de control para controlar quién puede realizar ciertas operaciones sobre un objeto.
  • Modelo de objetos CMIS:
El modelo de objetos CMIS es similar al modelo de objetos de Alfresco excepto en cuanto a los aspectos. CMIS soporta tipos de objetos que definen las propiedades asociadas a cada tipo. Cada objeto tiene un tipo de objeto, propiedades definidas por ese tipo de objeto y un identificador de objeto.
Los tipos de objetos soportan herencia y pueden tener subtipos tanto para documentos como para carpetas. Los tipos de objetos de documento puede tener flujos de contenido para almacenar y acceder a los datos binarios. Los tipos de objetos también puede estar relacionados entre sí con relaciones de tipos.
    • Objeto Política o Directiva CMIS:
Un objeto de directiva representa una política administrativa que puede aplicarse a un repositorio, como una política de gestión de retención de información.
Una lista de control de acceso es un tipo de objeto de directiva. CMIS permite a las aplicaciones crear o aplicar ACLs. El repositorio de Alfresco también utiliza objetos de directiva para aplicar aspectos.
    • Objeto documento CMIS:
Los objetos documento tienen propiedades y enlaces para acceder a la información binaria que es el documento en si, pueden tener propiedades multivaluadas y versiones. También pueden tener transformaciones que los representan como por ejemplo un thumbnail.
    • Versiones:
Las versiones en CMIS son sencillamente la forma de controlar versiones de varios formas en diferentes implementaciones CMIS. Cada versión es un objeto independiente con su propia identificación de objeto. Con el identificador de un objeto determinado se puede obtener la versión actual o todas las versiones del objeto, así como eliminar una o varias versiones de un objeto.
    • Objeto carpeta:
Los objetos documento se almacenan en una jerarquía de carpetas. Al igual que en Alfresco, una carpeta puede estar dentro de otra para crear la jerarquía. La relación entre carpeta y documento es de muchos a muchos, si el repositorio soporta multi-presentación (multifiling), un documento puede estar presente en más de una carpeta.
  • Enlaces que te pueden interesar:
Os recuerdo que el próximo miércoles 27 de abril hacemos un webinar en español sobre Introducción a CMIS, te puedes registrar aquí http://www.alfresco.com/es/about/events/2011/04/introduccion_cmis/

Video del webinar sobre “Subsistemas y Autenticación en Alfresco”

Los subsistemas de Alfresco permiten tener más control y modularidad sobre la aplicación, también nos aportan flexibilidad y facilidad de administración. Durante este webinar vamos a aprender qué son, cómo funcionan internamente y cómo se crean. Revisaremos opciones de configuración del servidor de ficheros, aplicaciones externas y profundizaremos en el subsistema de autenticación y sincronización.