Standard Operating Procedure

Alfresco 4 y Solr

2011-11-08T23:50:00.000+01:00

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

2011-07-20T18:07:00.000+02:00

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:

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

connectionTimeout="20000"

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-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

2011-04-21T14:13:00.019+02:00

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:

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.
Hacer la copia de seguridad de la base de datos utilizando las herramientas proporcionadas por el fabricante del RDBMS.
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

2011-04-18T12:12:00.000+02:00

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

2011-04-11T13:26:00.000+02:00

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

2011-04-04T12:00:00.003+02:00

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:

Crear el modelo en un fichero con extensión .xml. Por ejemplo my-model.xml.
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.
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.
Modificar el fichero web-client-config-custom.xml de la carpeta extension e incluir la representación del modelo creado en el paso 1.
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.
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

2011-03-25T08:28:00.004+01:00

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.

Auditar con Alfresco

2011-01-05T15:01:00.006+01:00

Una de las funcionalidades que más habitualmente se pide a un sistema gestor ECM es la capacidad de auditar las acciones realizadas sobre el repositorio de documentos y la obtención de estadísticas sobre los movimientos realizados en lo documentos almacenados.

Alfresco ECM incluye un framework para crear una pista de auditoría que permita recopilar la información necesaria para obtener estadísticas e informes sobre los movimientos en el repositorio de documentos. Este framework se aprovecha de la arquitectura Spring de la aplicación para utilizar un conjunto de interceptores que permiten controlar los servicios de Alfresco a nivel de método. La configuración de la auditoría se hace mediante un fichero XML donde se definen cuales serán los métodos que se auditarán.

Activación y configuración de la auditoría

La auditoría de Alfresco viene desactivada por defecto. Para activar la pista de auditoría hay que añadir las siguientes líneas al fichero alfresco-global.properties (versión 3.2 y superiores).

audit.enabled=true
audit.useNewConfig=false

Además se tiene que habilitar la configuración del servicio en el fichero tomcat/webapps/alfresco/WEB-INF/classes/alfresco/auditConfig.xml de la siguiente forma:

<Audit xmlns="http://www.alfresco.org/model/audit/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" enabled="true" auditInternal="false" mode ="all">

La configuración de qué servicios y métodos se van auditar también se hace en el fichero auditConfig.xml. Por cada servicio se crea un bloque donde se indican cuales son los métodos a auditar. Por ejemplo:

<Service name="ContentService" mode="none">
<Method name="getWriter" mode="all"/>
<Method name="getReader" mode="all"/>
<Method name="transform" mode="none"/>
</Service>

En este elemento se indica que se quieren auditar los métodos getWriter y getReader del ContentService. En cambio el método transform no se auditará.

Si se quieren auditar todos los métodos de un servicio hay que darle el valor all al atributo mode del elemento Service. Así:

<Service name="ContentService" mode="all">
</Service>

Consideraciones

La información de la auditoría se guarda en base de datos y es bastante cuantiosa, por este motivo hay que estudiar bien qué es lo que se quiere auditar antes de habilitarlo. Si el uso que se le va a dar al Alfresco es bastante elevado es mejor auditar sólo aquello que realmente se vaya a explotar de alguna forma.

Podeís encontrar más información en la wiki de Alfresco o en este interesante artículo (en francés).

Audit Surf

Precisamente leyendo uno de esos artículos descubrí una interesante utilidad para monitorizar la actividad de un Alfresco. Esta utilidad se llama Audit Surf y está disponible en la forja de Alfresco.

Esta utilidad es una aplicación Surf, que se despliega en el mismo servidor de aplicaciones donde está desplegado Alfresco Share. La aplicación presenta las siguientes funcionalidades:

Gráficos: presenta de forma gráfica información de conexiones de usuarios, creación de usuarios y workflows y estadísticas sobre creaciones, modificaciones y lecturas de documentos.
Cuadro de mandos: presenta una vista única con información sobre actividad de ficheros tal como los más leídos y modificados, las últimas incorporaciones y modificaciones. También da información sobre usuarios conectados y añadidos.
Monitorización: presenta información en tiempo real sobre el estado del servidor, de los repositorios y de los índices.
Exportación: permite generar un fichero CSV, XML o JSON con información de auditoría filtrada por fechas y por indicadores.

Esta herramienta me parece una muy buena solución para controlar la actividad del repositorio y obtener buenas estadísticas de uso de una instalación de Alfresco.

Importación masiva de documentos en Alfresco

2010-12-28T17:41:00.004+01:00

Una de las cuestiones habituales en los proyectos de implantación de un gestor documental es la carga inicial de documentos o la migración de los mismos desde el sistema documental anterior. En el caso de Alfresco hay varias alternativas para encarar este problema.

Los clientes web de Alfresco ofrecen un conjunto de herramientas para la gestión documental muy amplio y cómodo para los usuarios pero presentan una importante carencia cuando se trata de cargar grandes volúmenes de documentos. Alfresco Explorer sólo permite la importación de ficheros .acp, que es un formato propio de Alfresco y sólo se puede generar desde otro sistema Alfresco. Alfresco Share ofrece un mecanismo de upload de múltiples ficheros pero no es práctico para mucho ficheros no para estructuras más complejas (carpetas).

La solución habitual para cargar una gran cantidad de documentos en Alfresco es utilizar alguna de las interfaces de acceso proporcionadas por el servidor JLAN que lleva incorporado. Normalmente, en sistemas Windows, se opta por la interfaz CIFS o por la WebDAV, y en otros sistemas se utiliza FTP. Estas soluciones permiten utilizar estratégias más finas para la carga de documentos pero requieren de un esfuerzo de desarrollo considerable y en algunos casos el rendimiento puede no ser el mejor.

Hay una tercera vía que es la utilización de herramientas de importación como OpenMigrate o alfresco-bulk-filesystem-import. Detrás de este nombre tan largo se encuentra una solución sencilla y elegante que permite cargar documentos y metadatos de una forma eficiente y con poco coste.

alfresco-bulk-filesystem-import

Esta herramienta se distribuye como un fichero AMP de Alfresco por lo que instalarla es muy sencillo. Es suficiente con:

1. Descargarse el módulo adecuado a la versión de Alfresco y copiarlo en /amps

2. Ejecutar el comando apply_amps en la raíz del Alfresco.

Este módulo permite cargar toda un estructura de ficheros (documentos y carpetas) de un disco en un espacio de Alfresco, respetando la estructura original. Además permite también cargar metadatos asociados a los documentos importados. Cómo funciona esta carga de metadatos es bien sencillo. Primero hay que crear un fichero de metadatos para cada documento que se vaya a importar. Este fichero se ha de llamar exactamente igual que el fichero del documento añadiendo la extensión .metadata.properties. Por ejemplo, si el documento se llama my_document.docx el fichero de metadatos se tendrá que llamar my_document.docs.metadata.properties.

La estrucutra interna del fichero de metadatos sigue la estructura de los fichero de propieades de Java. Primero hay que incluir una referencia al tipo que queremos que tenga el documento cuando se cargue, luego la lista de aspectos que hay que añadir al documento y por último cada una de las propiedades que queramos añadir, siempre respetando el formato de QName. Por ejemplo:

type=cm:content
aspects=kb:article
kb\:articletype=FAQ
kb\:status=Draft

Este ejemplo importa un documento de tipo cm:content, le añade el aspecto kb:article e informa dos propiedades kb:articletype y kb:status.

Hay algunas limitaciones a la hora de definir metadatos como que no están soportadas las propiedades multivaluadas o las asociaciones y que el formato de las fechas ha de cumplir el estándar ISO8601.

La ejecución del módulo se hace a través de un webscript que está disponible en la URL http:///alfresco/service/bulk/import/filesystem . Este webscript tiene tres parámetros:

- Import directory: que es el directorio donde se encuentra la estructura de ficheros que hay que importar. Ha de ser un directorio local al Alfresco.

- Target space: que es el espacio de Alfresco donde se va a importar la documentación. El webscript lleva incorporado una ayuda contextual que facilita la elección del espacio destino.

- Update existing files: que es un flag que indica si está permitido modificar documentos en caso de que ya existan en la carpeta destino.

El resultado de la importación se muestra como un cuadro resumen que informa del número de documentos y carpetas creados, el tiempo empleado y los fallos, si los hubiera.

Novedades de Alfresco 3.3 - WCM

2010-09-12T23:23:00.006+02:00

La versión 3.3 de Alfresco ya lleva unos meses disponible y en esta serie de artículos me gustaría repasar algunas de las novedades incluídas en ella. Empezaré por las mejoras incluídas en el módulo de Web Content Management.

Alfresco incorporó el módulo de WCM hace ya varios años y su uso se ha extendido en tres áreas concretas:

Aplicaciones web: aplicaciones personalizadas basadas en frameworks populares (Java, Spring+Surf, PHP,...) y en los servicios de contenidos de Alfresco.
Publicación simplificada: para descargas en masa, pequeños cambios, despliegues rápidos y aceleración del tiempo de ejecución de Alfresco.
Intranets y portales: servicios de contenidos centralizados para agilizar la colaboración, contenidos sociales, búsquedas,...

En esta última release han añadido un conjunto de funcionalidades demandadas desde hace tiempo.

Nuevo editor web

Este nuevo editor permite la edición de contenidos en el contexto donde se publican. Esta funcionalidad está destinada a que los usuarios no técnicos sean capaces de editar los contenidos directamente en la página donde se muestram avitando así que dichos usuarios tengan que conocer la estructura interna de los contenidos.

La nueva forma de edición contextual es un complemento a la edición actual de manera que los diferentes perfiles implicados en la creación de contenidos y maquetación para las aplicaciones publicadas mediante WCM puedan trabajar de la forma que les sea más cómoda: editando en línea, descargando el contenido y editándolo offline o vía CIFS.

La edición de cada componente se hace mediante un editor HTML que proporciona las herramientas más frecuentes para la creación de contenidos HTML avanzados.

El editor está basado en tecnología javascript y forma parte de un framework de edición extensible con funcionalidades diseñadas ad-hoc para los gestores de las aplicaciones.

Servicio de transferencia y publicación

Este nuevo servicio permite la publicación de contenidos y el despliegue de aplicaciones a servidores remotos. Entre las características de este transferencia destacan:

La publicación de documentos durante la ejecución sin necesidad de parar las aplicaciones accedidas por los usuarios finales.
El mantenimiento de las estructuras y de las relaciones entre contenidos.
Configuración de la seguridad y del acceso a los contenidos.
Contenido dinámico y búsquedas de contenidos personalizadas.

Nueva API de presentación

El objetivo de esta API es fomentar el concepto de contenido como unidad de información independiente de su representación de forma que un mismo contenido pueda ser visualizado por tantos canales como sea necesario, cada uno de ellos con su propio sistema de representación.

Esta API permite definir formatos automáticos para los diferentes canales de entrega y la manipulación de contenido flexible a través de conversiones en cadena.

Las transformaciones para la presentación de los contenidos se pueden hacer mediante plantillas XSLT, un formato estándar de transformación XML muy extendido en los mundos web y J2EE. También se pueden usar plantillas Freemarker, una tecnología intergada en Alfresco tanto en su vertiente WCM como DM.

Webinar de novedades de Alfresco 3.3

2010-07-29T10:36:00.004+02:00

Herramientas de scanner para Alfresco

2010-06-08T00:01:00.004+02:00

Uno de los requerimientos más habituales que aparecen cuando se inicia la instalación de un gestor documental en una organización acostumbrada a trabajar con mucho material en formato papel es la posibilidad de incorporar documentos escaneados directamente al gestor documental.

Alfresco ofrece algunas alternativas interesantes para resolver este tema que se pueden ajustar a las diferentes necesidades de las organizaciones interesadas en implantar Alfresco.

Kofax Release Script

Esta es quizás la solución más antigua que ofrece Alfresco para resolver el problema y se basa en la suite de productos de escaneo de Kofax. El script en si es gratuito pero los sistemas de Kofax tiene coste de licencia. Mediante la API de webservices de Alfresco, este script permite subir documentos escaneados mediante Kofax a un espacio de Alfresco y mapear la información capturada por Kofax al modelo de contenidos de Alfresco.

Micro Strategies: Integración con Kofax

Esta es otra suite de pago que permite la captura de documentos mediante Kofax y su incorporación directa a Alfresco. Además de las funciones de escaneo también indorpora la integración con otras aplicaciones de negocio como Oracle Financials y Google Search Appliance.

OA Solutions

Esta empresa canadiense proporciona una solución de pago que permite escanear documentos directamente en Alfresco usando dispositivos de red multi función (escaners, impresoras, fax). Esta solución tiene una potente capacidad de detección y extracción de metadatos. Además proporciona un cliente flash para gestionar la calidad del escaneo y otras funcionalidades como el zoom, paginación automática, scroll,...

Capturesco

Esta es una solución open source que permite capturar documentos e imágenes usando escaneres o cámaras digitales y subirlos directamente a Alfresco. Esta solución utiliza la API de webservices de Alfresco desde un cliente C# y tiene un cliente para escanear escrito en VB.net.

Otras soluciones

Alfresco proporciona un gran número de interfaces e implementa varios protocolos que se pueden usar para cubrir esta funcionalidad:

SharePoint Protocol: cualquier herramienta que pueda utilizar el protocolo SharePoint para escanear documentos directamente en SharePoint (como Fujitsu Scansanp), también se puede utilizar para scanear directamente en Alfresco porque, desde la versión 3.0, también implementa este protocolo.
Email Server: muchas herramientas de escaneo permiten enviar los documentos escaneados por mail. Alfresco implementa un servidor de email que permite la incorporación de documentos utilizando el protocolo SMTP y definiendo alias de email para los espacios del repositorio.
CIFS: al publicar el repositorio mediante esta interfaz, los documentos escaneados con cualquier herramienta se pueden guardar directamente en Alfresco.

Una vez más, la flexibilidad de Alfresco queda patente en el amplio abanico de soluciones disponibles que existen para resolver un problema común de la gestión documental.

Alfresco Web Scripts

2010-04-12T00:06:00.005+02:00

Alfresco incluyó en su versión 2.1 el framework de web scripts, una API basada en tecnología RESTful que proporcionó una forma fácil, rápida y potente de interactuar con el repositorio de contenidos y de integrar Alfresco con otros sistemas. Desde entonces Alfresco ha seguido apostanto por esta solución y la ha convertido en la principal herramienta de desarrollo e integración de su última versión.

Cada web script está vinculado a un método HTTP y a una URL y puede devolver resultados en múltiples formatos, desde HTML hasta JSON, pasando por XML o RSS.

Tipos de web scripts

Hay dos tipos de web scripts:

Web scripts de datos: que devuelven información en cualquier formato, como CSV, XML u objetos JS. Estos web scripts permiten hacer llamadas a Alfresco desde otras aplicaciones u otras extensiones de Alfresco. Por ejemplo, el componente de OpenSearch está construido como una serie de web scripts.
Web scripts de interfaz de usuario: permiten construir dinámicamente interfaces de usuario dentro del cliente de Alfresco o en otras aplicaciones. Se pueden crear componentes ricos, cada uno con su propia apariencia. Estos web scripts pueden funcionar de forma independiente o combinados con web scripts de datos.

Componentes de un web script

Los componentes básicos de los web scripts son tres, aunque no son todos obligatorios:

Descripción: es un fichero XML que describe la URL que iniciará el script. Entre los datos que se pueden informar están el nombre, la descripción y las necesidades de autentiación y transaccionalidad del script. Este componente es obligatorio.
Script de ejecución: es un fichero Javascript que será el encargado de ejecutar la lógica del script. El script tiene acceso a todos los argumentos de la URL, los servicios del repositorio y la mayoría de los objetos de la API Javascript de Alfresco. Esto es posible porque ALfresco utiliza Mozilla Rhino para Java que permite a los fichero JS acceder a los objetos java utilizando una notación simple de beans. Este componente no es obligatorio.
Plantillas de salida: pueden ser varias, para diferentes formatos de salida. Son plantillas de freemaker que construyen la salida del script en los formatos deseados. La respuesta de la URL se construye a partir de una de las plantillas proporcionadas al web scripts y se escoge la adecuada en función de tipo de contenido especificado en la petición. Las plantillas tienen acceso a todos los argumentos de la URL y los puntos de acceso habituales al repositorio de Alfresco. Cómo mínimo ha de existir una plantilla por web script.

La forma que tienen estos componentes de interactuar es la siguiente:

La URL con la petición llega al Web Script REST dispatcher.
El dispathcer localiza el Web Script adecuado para la URL, se autentica si es necesario y ejecuta el script. En caso de no localizar el web script o no conseguir autenticarse, devuelve un código de error HTTP.
Desde el script se tiene acceso a todos los servicios del repositorio de contenidos para buscar, modificar, borra y crear información.
El resultado del script se renderiza utilizando las plantillas freemaker proporcionadas al Web Script y según el tipo de respuesta solicitado o con el formato por defecto en caso de que no se indique el tipo de respuesta preferido.
El dispatcher envía la respuesta renderizada utilizando el mismo protocolo de la petición.
El cliente del web script recibe la respuesta en el formato de la petición.

Java-backed web scripts

En ocasiones los scripts y las plantillas no son suficiente para implementar la funcionalidad requerida. En estos casos es posible recurrir a un bean de Java definido en el contexto de Spring de Alfresco. Estos beans pueden tomar el control de la ejecución o trabajar conjuntamente con el script y las plantillas.

La definición de estos beans en el contexto de Spring está estrechamente ligada con el fichero de descripción del Web Script y, como cualquier otro bean de Spring de Alfresco, otros servicios del nucleo de Alfresco pueden utilizarse en el bean mediante inyección de dependecias.

En definitiva, este framework supone una herramienta muy potente y flexible para abrir el repositorio de Alfresco utilizando estándares al alcance de cualquier equipo de desarrollo

PHP y CAS

2010-01-27T09:00:00.001+01:00

El sistema de web SSO CAS es uno de los más extendidos entre la comunidad Open Source. Originalmete creado por la Universidad de Yale sirve para proporcionar a las aplicaciones un modo fiable de autenticar usuarios.

Existen muchos clientes de CAS para integrarse con aplicaciones de diferentes tecnologías como Java, .Net, Perl, Apache y PHP. Para este último caso, el cliente se llama phpCAS. Este cliente ofrece un forma fácil de proteger cualquier aplicación escrita en PHP.

Los requisitos para instalar phpCAS son:

CURL 7.5+
PHP 4.3.1+, PEAR DB
Apache 2.0.44+

Con las últimas versiones de Apache 2.2.x y PHP 5.x el cliente es muy fácil de usar porque tdos estos componentes ya están incluídos.

Un ejemplo de la forma más básica de usar del cliente phpCAS para proteger una aplicación es la siguiente:

<?php
include_once('CAS.php');
phpCAS::setDebug();
phpCAS::client(CAS_VERSION_2_0,'my_cs_server',443,'/cas');
// no SSL validation for the CAS server
phpCAS::setNoCasServerValidation();

// force CAS authentication
phpCAS::forceAuthentication();

// at this step, the user has been authenticated by the CAS server
// and the user's login name can be read with phpCAS::getUser().

// logout if desired
if (isset($_REQUEST['logout'])) {
phpCAS::logout();
}
echo phpCAS::getUser();
?>

En este ejemplo es importante destacar la forma de crear el cliente, donde se usa el nombre del servidor de CAS, el puerto del servicio CAS y la URI de CAS ('/cas'). En este último caso la URI ha de corresponder a la aplicación y nunca a la página de login ('/cas/login').

Ahora bien, este ejemplo puede no funcionar porque hay un problema a la hora de crear la sesión de la aplicación. Si se usa este ejemplo, la creación de la sesión de usuario está implícita en la creación del cliente. En muchos casos este comportamiento puede no ser el deseado ya que se pierde el control sobre la sesión o no se crea bien. Para solucionarlo hay que modificar el ejemplo de la siguiente forma:

<?php
include_once('CAS.php');
session_start();
phpCAS::setDebug();
phpCAS::client(CAS_VERSION_2_0,'my_cs_server',443,'/cas',false);
// no SSL validation for the CAS server
phpCAS::setNoCasServerValidation();

// force CAS authentication
phpCAS::forceAuthentication();

// at this step, the user has been authenticated by the CAS server
// and the user's login name can be read with phpCAS::getUser().

// logout if desired
if (isset($_REQUEST['logout'])) {
phpCAS::logout();
}
echo phpCAS::getUser();
?>

Con estos dos cambios, la sesión se crea de forma explícita y se le informa al cliente de CAS de que no ha de crear una nueva.

Caso de éxito : Publicación de documentación para la CMT

2010-01-15T20:15:00.000+01:00

El pasado més de Octubre, una de las principales empresas españolas proveedoras de servicios de telecomunicaciones, puso en marcha su portal para la publicación de la documentación de sus centros de servicios. Dicho portal ha sido desarrollado por IN2.

Octubre de este año era la fecha límite para que las empresas proveedoras de servicios de telecomunicaciones hicieran pública la información relativa a los centros de coubicación e interconexión. Nuestro cliente, al ser la principal empresa de este tipo en España, estaba obligado a publicar una gran cantidad de información en formato de documentos digitales e imagenes dentro de un plazo de tiempo muy ajustado.

Para el desarrollo del portal, esta empresa solicitó los servicios de IN2, con quien ya había trabajado en otros proyectos relacionados con gestión documental y calidad de desarrollo de aplicaciones J2EE. In2 aceptó el reto de realizar este proyecto en un plazo de 6 a 8 semanas para cumplir con el requerimiento legal de la CMT.

La solución propuesta por IN2 consistió en el desarrollo de una aplicación web para la publicación de la documentación y la implementación sobre Alfresco de los principales elementos de gestión documental.

La aplicación web se ha desarrollado usando tecnologías J2EE, en concreto una combinación de struts, spring e hibernate. La aplicación consta de dos partes:

Una parte pública donde se ofrece la información de los centros y la descarga de la documentación en formato digital, además de la parte pública de la gestión de usuarios de la aplicación.
Una parte privada que hace backoffice de la aplicación donde los usuarios administradores gestionan la información de los centros y la administración de usuarios de la aplicación.

Toda la aplicación está asegurada usado spring security.

La parte de gestión documental se ha montado sobre el gestor documental corporativo, Alfresco. Se han definido nuevos tipos de documentos para almacenar los metadatos relativos a los documentos y se ha creado un workflow jbpm para la aprobación y publicación de la documentación en la web. La integración de la aplicación web con Alfresco se ha hecho a través de los webservices que Alfresco proporciona.

El desarrollo de la aplicación se llevó a cabo en el plazo previsto y se publicó dentro del plazo legal previsto por la CMT, proporcionando al público información sobre más de 400 centros y más de 15.000 documentos e imágenes.

Alfresco 3.2 ya está aquí

2009-07-19T14:08:00.006+02:00

Alfresco, en su proceso de mejora continua de su producto ECM, ha publicado recientemente la versión 3.2 Community de Alfresco que ya está disponible para su descarga y evaluación.

Esta nueva versión incluye algunas mejoras muy interesantes que merece la pena destacar.

1. Mejoras en el cliente Share.

Alfresco ha expresado su intención de seguir con la evolución de la plataforma surf y el cliente Share como línea de trabajo futura. En esta nueva versión, el cliente Share ha sido mejorado y por fin incluye algunas de las características que se echaban de menos en las versiones anteriores. De las nuevas funcionalidades de Share, destacaría las siguientes:

Soporte para tipos, aspectos y metadatos personalizdos.
Nuevos formularios para la edición de metadatos.
Una consola para la creación y gestión de usuarios y grupos.
Nuevos dashlets de previsualización de imágenes, contenidos en edición y documentos favoritos.
Personalización de temas.
Asignación de grupos de sites.
Previsualización de documentos a pantalla completa.

2. Cliente para dispositivos móviles.

Esta nueva versión incluye un cliente penado para ser usado por dispositivos móviles, como teléfonos inteligentes. Este nuevo cliente es más sencillo y da acceso a algunas de las funcionalidades básicas de Alfresco Share como :

Navegación por sites.
Revisión de tareas.
Inicio de workflows.
Acceso a la biblioteca de documentos.

3. Simplificación de la configuración del servidor.

El equipo de Alfresco ha hecho una revisión de los mecanismos de configuración de Alfresco simplificando los mecanismos de autenticación y sincronización de usuarios. Este cambio es muy de agradecer ya que éste era uno de los puntos más complicados y de mayor fuente de problemas que tenía Alfresco.

Otras mejoras incluyen la configuración de los File Servers (CIFS, FTP,NFS) y la integración con otras aplicaciones como OpenOffice o ImageMagick.

4. Mejor soporte a estándares como CMIS e IMAP.

En su apuesta por la integración y el cumplimiento de estándares, Alfresco incorpora en esta nueva versión una implementación más completa del protocolo CMIS cumpliendo con la versión 0.61 de dicho protocolo.

Otro protocolo incorporado en la última versión es IMAP. Gracias a esta nueva integración los clientesd e correo que cumplan con este protocolo pueden navegar y ver documentos del repositorio de Alfresco. También se pueden guardar mail directamente en el repositorio, incluyendo la extracción de metadatos y de ficheros adjuntos a los mails.

5. Mejoras en el repositorio.

Se han hecho otras muchas mejoras directamente en el repositorio como:

Actualizar la versión del indexador Lucene a la 2.4.1, la versión más reciente (Marzo 2009) de este popular indexador.
Actualizar el motor de procesos jBPM a la versión 3.3.1.
Mejoras en las búsquedas incluyendo el lenguaje de consultas de CMIS.
Optimización de la operación de copia.
Purga de contenidos para eliminarlos directamente del sistema de ficheros.

Mis primeras pruebas con esta versión me han dejado una sensación muy positiva. Habrá que esperar a la versión Enterprise, pero las mejoras que han incorporado en esta nueva versión hacen evolucionar al producto en la línea correcta y cubren algunas de las necesidades de muchos usuarios que hasta el momento no estaban contempladas y que permitirán a Alfresco seguir siendo un jugador de primera línea en el competitivo mercado de los gestores documentales empresariales.

Alfresco y NTLM

2009-06-29T23:29:00.009+02:00

Uno de los requisitos más habituales cuando se instala una herramienta en el ámbito de una empresa es la integración de la seguridad corporativa con la de la nueva aplicación. En muchos escenarios el requisito consiste en establecer un mecanismo de Single Sing-On entre la seguridad de la red corporativa y la nueva aplicación, de forma que los usuarios sólo tengan que autenticarse cuando inician su sesión de sistema operativo y puedan acceder al resto de aplicaciones sin tener que volver a proporcionar su usuario y contraseña.

Alfresco es una aplicación que, por sus características de aplicación de ámbito corporativo, es idónea para una integración como la descrita anteriormente. Así mismo, Windows es el sistema operativo más extendido entre los ordenadores personales de las empresas. Por este motivo, las útlimas versiones de Alfresco vienen preparadas para poder hacer esta integración de forma fácil con un mínimo de configuración.

En este detallado artículo, se describen los pasos necesarios para habilitar la autenticación mediante NTLM en modo passthru. El apartado dedicado a la activación de los filtros de autenticación en el fichero web.xml es claro y no necesita más explicaciones. La configuración de la autenticación passthru con NTLM necesita algunas aclaraciones.

La definición del SSO con ntlm se hace en el fichero ntlm-authentication-context.xml situado en el directorio de extensiones de Alfresco. En este caso es un controlador de dominio el encargado de realizar la auteticación y proporcionar la lista de usuarios disponibles en Alfresco. Es necesario configurar el bean authenticationComponent con los valores adecuados para que reconozca al servidor de dominio. Por ejemplo:

<bean id="authenticationComponent"
class="org.alfresco.repo.security.authentication.ntlm.NTLMAuthenticationComponentImpl"
parent="authenticationComponentBase">
<property name="useLocalServer">
<value>false</value>
</property>
<property name="servers">
<value>drake.in2.es,IN2\drake</value>
</property>
<property name="personService">
<ref bean="personService" />
</property>
<property name="nodeService">
<ref bean="nodeService" />
</property>
<property name="transactionService">
<ref bean="transactionComponent" />
</property>
<property name="guestAccess">
<value>false</value>
</property>
</bean>

La propiedad servers es la usada para definir el controlador de dominio. Es importante destacar que hay que proporcionar el dominio del servidor para que el SSO tenga efecto. En caso contrario aparecerá este mensaje de error cuando se intente acceder al Alfresco mediante SSO:

net.sf.acegisecurity.AuthenticationServiceException: Failed to open passthru auth session

Si además del cliente web de Alfresco se quiere utilizar CIFS para acceder a los contenidos, también hay que aplicar una configuración concreta. De los diferentes mecanismos de autenticación disponibles (alfresco, passthru o enterprise), el más adecuado es passthru usando el mismo servidor de dominio que el usado en el caso anterior. En este caso no hace falta especificar el dominio de los usuarios. Por ejemplo:

<authenticator type="passthru">
<Server>drake.in2.es</Server>
</authenticator>

Un detalle que hay que tener en cuenta con esta configuración es que sólo funciona si el sistema operativo del cliente envía las credenciales de autenticación usando NTLMv1. Si el sistema sólo usa NTLMv2, no será posible hacer el SSO ya que las caracterísitcas de este protocolo lo impiden.

En Windows se puede modificar este comportamiento siguiendo estos pasos:

Desde el panel de control (vista clásica), abrir Herramientas Administrativas -> Política de seguridad Local.
En la ventana de Política de seguridad local, seleccionar la carpeta Políticas Locales y luego Opciones de Seguridad.
En la lista de opciones de seguridad, seleccionar 'Network Security : nivel de autenticación del controlador LAN'.
Cambiar el valor por defecto por 'Enviar LM & NTLM - usar seguridad de sesión NTLMv2 si se negocia'.

Con estas configuraciones de Alfresco y Windows se consigue un acceso transparente a Alfresco solo con haber iniciado una sesión de red corporativa.

Diez formas de integrarse con Alfresco

2009-05-29T09:16:00.016+02:00

En este blog hemos comentado otra veces las virtudes de Alfresco como ECM. Uno de los puntos que siempre se destaca de esta solución es la gran capacidad de integración que tiene el producto con otros sistemas y la gran variedad de interficies de acceso que proporciona para trabajar con él. Vamos a hacer un repaso de las diez opciones más importantes y de los componentes que participan en cada una de ellas.

1. SOAP

Es un estándar abierto basado en XML pensado para la integración de aplicaciones. Típicamente funciona sobre http y existen herramientas de desarrollo para casi cualquier lenguaje, incluyendo toolkits muy potentes para .NET y Java. Alfresco proporciona de serie una capa de web services que cubren la mayor parte de la funcionalidad requerida para trabajar con el repositorio documental.

2. CMIS
Es el estándar de servicios de interoperabilidad entre gestores de contenidos. Es una iniciativa bastante reciente pero que cuenta con el apoyo de las principales empresas fabricantes de CM, como IBM, EMC, Microsoft o la propia Alfresco. También está basado en web services. Desde su versión 3.0, Alfresco incorpora una implementación de CMIS.

3. JCR
Es la implementación de Alfresco del estándar JSR-170, que define los repositorios de contenidos en Java. Alfresco cumple con los niveles 1 y 2 de este estándar. En el caso de Alfresco el acceso al repositorio mediante esta API se hace mediante beans de Spring.

4. AJAX/Mashups/Webscripts
Alfresco incorpora una API de Webscripts basada en tecnología REST, que consiste en llamadas HTTP que interactuan con el repositorio de contenidos. El resultado de estas llamadas se puede devolver en gran variedad de formatos como HTML, JSON, RSS y otros formatos web, lo que facilita mucho la integración de servicios de Alfresco con otras aplicaciones web. Esta integración está muy orientada al mundo del web 2.0 y es una de las grandes apuestas de Alfresco para el futuro.

5. Java Foundation API

Esta API proporciona todos los servicios para interactuar con el repositorio de contenidos. En realidad lo que se proporciona es un conjunto de interfaces que representan funcionalidades del repositorio. Las implementaciones de estas interfaces están proporcionadas por bean de Spring Framework. Es la API más extensa para interactuar con Alfresco pero tiene la importante restricción de que sólo se puede usar por clientes que corran en el mismo proceso de el repositorio

6. OpenSearch

OpenSearch es una colección de formatos para compartir resultados de búsquedas cuya ejecución está soportada vía peticiones HTTP. Alfresco expone su motor de búsquedas a través de OpenSearch de forma que otras aplicaciones pueden consultar y obtener documentos del repositorio. Alfresco Explorer incluye un componente en para agregar a las búsquedas otros motores que cumplan con estos formatos.

7. WCM

El Web Content Management permite integrar un amplia abánico de recursos externos al repositorio como XForms, recursos REST, PHP, JSF, Ruby o Struts. Además se puede integrar con portales corporativos que cumplan el estándar JSR-168.

8. BPEL Workflows

Este lenguaje permite definir workflows que relacionen diferentes sistemas con capacidad de integrar la interacción humana. Los eventos del workflow se pueden comunicar con Alfresco a través de webservices de forma que las funcionalidades del gestor de contenidos estarán disponibles para ser usadas en cualquier paso del proceso.

9. Portal

Es posible integrar la funcionalidad de Alfresco en servidores de portal como Liferay. Hay diferentes formas de hacerlo. Una de ellas es usar la API REST de Alfresco y publicando los webscripts como portlets. Se pueden aprovechar los web scripts existentes y que cubren gran parte de la funcionalidad del gestor documental o bien se pueden desarrollar nuevos web scritps para cubrir funcionalidades concretas. Otra aproximación posible es usar los servicios CMIS para obtener respuestas en XML y formatearlas usando plantillas XSLT

10. Protocolo Sharepoint

En sus últimas versiones, Alfresco incluye una implementación del protocolo Sharepoint para comunicarse con las aplicaciones del paquete ofimático Office de Microsoft. De esta forma los usuarios de las aplicaciones de Office pueden compartir documentos como si estuvieran usando espacios de Sharepoint de forma totalmente transparente para ellos.

Alfresco ha demostrado ser una solución adecuada para implementar la gestión documental completa de cualquier empresa, proporcionando un servicio transversal disponible para la integración con la gran mayoría de los sistemas de la empresa.

Oracle compra Sun

2009-04-28T12:00:00.001+02:00

Esta semana ha saltado una noticia que seguro que alterará el actual panorama del software Open Source : Oracle comprará Sun.

Esta compra supone para Oracle posicionarse como un gigante de la industria informática, comparable a IBM. La adquisición de Sun, abrirá para Oracle nuevos segmentos de negocio con los que hasta el momento no había tenido nada que ver como los servidores, redes, microelectrónica y sistemas operativos. En este sentido, la compra no la veo como un intento de constituir un monopolio sino como la creación de un nuevo competidor capaz de ofrecer un stack completo que abarque desde la plataforma hardware hasta las aplicaciones de negocio pasando por el sistema operativo, la base de datos y el servidor de aplicaciones.

Otra cuestión es como se va a efectuar la fusión de los diferentes productos de Sun con los de Oracle y el roadmap que van a seguir. Este punto suele ser bastante delicado y provoca periodos de incertidumbre sobre el futuro de algunos productos que a la larga puede ser perjudicial para la propia empresa. Un ejemplo de esto que también tiene a Oracle como protagonista, es la fusión de las suites de aplicaciones de BEA Systems, que empezó el año pasado y aun hoy en día no está del todo clara.

Es precisamente esta incertidumbre la que genera las dudas más difíciles de responder. ¿Ahora que Oracle había pensado abandonar los servidores de aplicaciones OC4j y adoptar Weblogic, donde encajará Glassfish? ¿Mantendrá Oracle soporte para JRockit y JDK o fusionará ambas JVM? ¿Cual será el futuro de MySQL? Éstas y otras muchas dudas de este estilo seguro que rondan por la cabeza de miles de usuarios y clientes de Oracle y Sun .

Al margen de estas cuestiones más comerciales quizás hay otra de mayor alcance, ¿qué será de Java? Hasta la fecha, Java ha sido uno de los pilares del mundo Open Source sobre el cual se han construido infinidad de aplicaciones, librerías y otras soluciones y del cual existe una amplísima comunidad de desarrolladores y contribuidores que ha permitido a Java convertirse en la tecnología estrella del mundo de las aplicaciones web empresariales. Con el cambio de dueño, ¿se mantendrá este apoyo? ¿Seguirán las empresas que tanto han apostado por Java, como IBM, contribuyendo y desarrollando en una tecnología cuyo futuro está manos de una competidora directa?

Hasta la fecha, la evolución de Java estaba en manos de una empresa comercial como Sun, que casi siempre ha mostrado una vocación bastante abierta a la hora de permitir que otras empresas contribuyeran a la misma. Oracle, por su parte, lleva muchos años apostando por esta tecnología pero con una aproximación más propietaria (¿ADF?) a pesar de haber hecho algunas contribuciones a la comunidad.

Aun falta tiempo para que estas dudas y otras se aclaren. Habrá que esperar a que Oracle haga públicos sus planes, como enfocará la fusión y la reacción del resto de empresas. En mi opinión, las principales víctimas serán NetBeans, Glassfish y MySQL, que son los productos que más entran en conflicto con los de Oracle. Creo que Java seguirá evolucionando como siempre y a lo mejor nos llevamos alguna sorpresa agradable al respecto. Esperemos...

Alfresco y OpenOffice

2009-04-08T12:51:00.007+02:00

El gestor documental Alfresco nació con la vocación de ser un referente tecnológico en el mundo de los gestores documentales y ser el estandarte de una nueva generación de productos open source para la empresa actual. Con este objetivo, el equipo de desarrollo de Alfresco centró sus esfuerzos en conseguir una implementación puntera del repositorio y aprovechó un conjunto de tecnologías open source ya existentes, probadas y de gran aceptación para acabar de construir el producto que es hoy en día.

Una gran ventaja de este enfoque es que la responsabilidad de ciertas acciones que realiza Alfresco recae en software bien probado y que no se ha "reinventado la rueda" para hacer algo que ya hacía un producto consolidado en el mercado. La arquitectura de Alfresco es lo suficientemente abierta y flexible como para delegar estas tareas en aplicaciones de terceros como puedan ser ImageMagik u OpenOffice.

La parte negativa de esto es que cuando falla alguna de las tareas ejecutadas por aplicaciones externas, cuesta saber si el error está en Alfresco o en la aplicación. Recientemente, nos hemos encontrado con un caso de este tipo que implicaba OpenOffice.

En una instalación de Alfresco de uno de nuestros clientes, tienen una regla en un espacio que hace la conversión a PDF de determinados tipos de ficheros. Esta regla acostumbraba a ir bien hasta cierto momento en el que dejaba de funcionar y cesaba la conversión a PDF. Había que reiniciar la aplicación para que la regla volviera a funcionar y siempre acababa por fallar.

Después de muchas pruebas, Bea, compañera de IN2, encontró la causa del problema y la solución. La conversión a PDF dejaba de funcionar porque OpenOffice se quedaba sin memoria para ejecutar la transformación. La solución a este problema está en modificar la configuración inicial de OpenOffice para aumentar el máximo de memoria caché permitida.

Este parámetro de ha de definir en el fichero Common.xcu de OpenOffice, que se suele encontrar en /Data/settings/user/registry/data/org/openoffice/Office. Para definir la memoria que se permite usar hay que añadir el siguiente bloque antes del final del fichero:

<oor:component-data xmlns:oor="...>

</prop>

</prop>

</node>

</oor:component-data>

Con estos valores hay suficiente para tratar la mayoría de las transformaciones.

2ª Edición del curso de Alfresco en La Llacuna

2009-03-15T14:05:00.004+01:00

Este fin de semana ha tenido lugar la segunda edición del curso de Alfresco en La Llacuna. Dentro del plan de formación continua de IN2, las jornadas de La Llacuna sirven para estar al día de las tecnologías más utilizadas por IN2 y para fomentar el trabajo en equipo.

Hace unos meses tuvo lugar el primer curso de Alfresco en La Llacuna y esta semana hemos celebrado el segundo. Mientras que el primero estuvo centrado en la instalación, configuración e integración del producto, este segundo curso ha estado orientado a la personalización y extensión de Alfresco.

El temario dado comprendía los siguientes puntos:

Preparación del entorno de desarrollo.
Extensión del modelo documental.
Adaptación del cliente web para el nuevo modelo documental.
Tratamiento automático de contenidos: acciones y behaviours.
Extensión del cliente web: botones y diálogos.
Webscripts.

El curso ha tenido un marcado carácter práctico y los participantes han tenido que resolver ejercicios de cada uno de los puntos del temario. Además hemos tenido la posibilidad de explicar experiencias reales que nos hemos encontrado en los diferentes proyectos realizados con Alfresco por IN2.

Además de aprender, el curso también ha servido para que los colaboradores de IN2 podamos conocernos mejor, compartir nuestras experiencias y fomentar el trabajo en equipo.

Este año he tenido la suerte de compartir este curso con un gran grupo de gente con la que me lo he pasado muy bien: Óscar, Javi, Jordi, Milton, Pedro, Jesús, Fabio, Marta, Raquel y Lenin. Además he tenido la suerte (o privilegio) de compartir la labor de profesor con Xavi, que ha hecho un gran trabajo y ha compartido con nosotros su gran experiencia con Alfresco.

Como colofón del curso, tuvimos una actividad de trabajo en grupo que sirvió para relajarnos después de las clases y explorar las posibilidades del trabajo en equipo. Fué una sesión con momentos muy divertidos y nos reimos mucho.

Espero que el curso haya resultado útil a mis compañeros y que haya disfrutado de estas jornadas en compañía del grupo. Ojalá que podamos seguir con esta iniciativa y que el año que viene podamos celebrar la tercera edición del curso.

Caso de éxito: Operador de telecomunicaciones

2009-03-12T08:00:00.002+01:00

Esta semana se ha dado por concluido el proyecto de migración de la gestión documental de uno de los principales operadores de telecomunicaciones.

Esta empresa forma parte de un grupo líder europeo en gestión de infraestructuras, con una fuerte presencia en los sectores de autopistas, aeropuertos, telecomunicaciones, aparcamientos y parques logísticos. actualmente cuenta con presencia en 17 países y tiene una plantilla de casi 11.000 empleados.

Dentro del grupo, nuestro cliente era la empresa encargada de las infraestructuras y servicios de telecomunicaciones, siendo la principal red de difusión de radio y televisión de España. También es una importante operadora de servios por satélite.

Esta empresa tenía parte de su gestión documental externalizada de forma que no tenía mucho control sobre la forma que se trataba y almacenaba dicha información. Con el objetivo de tener un mayor control sobre esta información y de no depender de terceros para la gestión de información tan sensible, se decidió integrar esta gestión documental en sus propios sistemas.

Aquí fué donde IN2, gracias a su amplia experiencia en proyectos con el gestor documental Alfresco, empezó su colaboración con el operador de telecomunicaciones para conseguir los objetivos mencionados.

El proyecto consistió en configurar y parametrizar el gestor documental corporativo Alfresco para que pudiera soportar la gestión de la documentación y toda su información asociada. Se creó un nuevo modelo documental y se añadieron acciones especiales para la extracción de metainformación para incorporarla a los documentos. También se realizó la migración de toda la documentación almacenada en la antigua herramienta de gestión documental al Alfresco.

El resultado, ha permitido a nuestro cliente tomar el control de su documentación y ampliar las posibilidades de explotación de toda la información almacenada.

Gracias al esfuerzo de Xavi y Mónica y la guía de Porfi y Josefí, el proyecto ha sido un éxito notable y el cliente ha expresado su satisfacción con el resultado. Enhorabuena a todos.

Primera parte de SCEA, ¡ aprobada !

2009-03-10T00:15:00.003+01:00

Hace unos meses empecé a prepararme, junto a otros compañeros de IN2, para la certificación de Sun Certified Enterprise Architect for Java EE (SCEA). Es la certificación de más alto nivel de las que ofrece Sun dentro del marco de tecnología Java, y está compuesta por dos exámenes y un trabajo práctico.

La semana pasada me presenté al primer examen y.. ¡ lo aprobé a la primera !

De momento ya somos dos los que hemos aprobado este examen, ya que Emmerson lo aprobó antes, y espero que el resto de compañeros también lo aprueben pronto.

Han sido dos meses de estudio, recopilando y leyendo material diverso sobre arquitectura, patrones y tecnologías Java. Han sido dos meses de quedarnos los viernes por la tarde haciendo exámenes e intercambiando opiniones. Al final el esfuerzo ha valido la pena.

Leer el material de Sun me ha hecho pensar en la una entrada que escribí hace unos meses, donde daba una visión de lo que podría definirse como un arquitecto de software. En ese marco, la visión que tiene Sun de lo que debería ser un arquitecto de software encaja más con ese perfil de técnico avanzado o especialista dentro de una organización. Es una visión legítima de lo que debería ser un arquitecto pero, desde mi punto de vista, demasiado orientada a la tecnología y alejada del negocio.

Las nuevas tendencias, con SOA al frente, hacen que esta visión de lo que es un arquitecto de software esté quedando un poco obsoleta, o mejor dicho, un poco limitada, ya que las responsabilidades que puede adopatar un arquitecto son mucho más amplias.

De cualquier forma, yo voy a seguir esforzándome para obtener la certificación completa ya que aprender algo nuevo siempre está bien y en el fondo la tecnología me sigue gustando mucho.

Caso de éxito: CRM Protocolo

2009-02-15T23:09:00.008+01:00

Ya está en producción el último fruto de la colaboración entre IN2 y Fira de Barcelona. Se trata de la aplicación de CRM de Protocolo o, como se la conocido durante su desarrollo, Protocolo VIP.

Fira de Barcelona, con más de 70 años de historia, cuenta hoy en día con la mayor superficie firal de España (365.000 m2 brutos para exposición) y una de las primeras de Europa. Con una cartera de 80 salones, reúne 40.500 empresas directas y representadas y recibe 3,5 millones de visitantes. 15 de sus salones son referentes europeos, figurando entre los tres primeros de la especialidad. Lidera los salones industriales - profesionales españoles, su aportación anual a la economía es de unos 2.500 millones de euros y contribuye a crear 41.000 puestos de trabajo.

Dada la naturaleza del negocio de Fira de Barcelona, las actividades protocolarias y de representación son sumamente importantes, por lo que es necesario contar con una herramienta de ayuda a la gestión y mantenimiento de la información relativa de todas las autoridades de los diferentes salones y organismos que componen Fira de Barcelona.

Hasta el momento esta gestión se hacía mediante la herramienta CRM de SAP, pero el alto coste de mantenimiento de esta solución, tanto económico como tecnológico, hizo que se buscara una alternativa más económica y flexible. Se evaluaron diferentes opciones y se acabó deciendo desarrollar una aplicación a medida usando tecnología JavaEE.

IN2, con su gran experiencia en el desarrollo de aplicaciones con esta tecnología, participó en el proyecto desde una fase muy temprana, y contribuyó en el análisis y diseño del nuevo sistema, así como en toda la fase de desarrollo e implantación.

El objetivo de la aplicación es disponer de una herramienta de fácil uso que proporcione potentes prestaciones de búsqueda para obtener la máxima información útil de los VIPs de Fira de Barcelona. También ha de permitir realizar el mantenimiento de la información de los VIPs y de las relaciones con las organizaciones a las que representan, así como de la información relativa a la comunicación institucional con Fira de Barcelona. Complementariamente, también debe dar soporte al mantenimiento de información común al negocio de Fira de Barcelona.

El resultado han sido dos aplicaciones con arquitectura de tres capas, donde se ha aplicado Hibernate y el patrón DAO para la capa de persistencia, Spring Framework para la capa de servicios y Spring MVC para la presentación. Además se ha utilizado Spring Security para la autenticación y librerías POI para la generación de documentos compatibles con Microsoft Office. En combinación con estas aplicaciones se ha dotado a Fira de Barcelona de una capa de servicios de acceso a datos que podrá ser usada por otras aplicaciones de la empresa.

Gracias al esfuerzo de Naiara, Albert y Victor el nuevo CRM de Protocolo de Fira está listo. Ahora Fira de Barcelona cuenta con una herramienta que cubre todas sus necesidades, basada en una tecnología actual y con una arquitectura flexible que permitirá añadir nuevas funcionalidades cuando sea necesario.

Tipos de proyectos SOA

2009-01-26T01:00:00.000+01:00

Hay muchas formas de clasificar los proyectos dependiendo de los parámetros que se tengan en cuenta. Esto también es aplicable a los proyectos SOA.

Esta clasificación pretende catalogar las formas más comunes de adoptar SOA por parte de una empresa. Hay tres posibles acercamientos:

Orientado a proyecto.
Orientado a sistemas.
Corporativo.

Orientado a proyecto

Este tipo de acercamiento corresponde al escenario en el que un departamento de una empresa decide solucionar una necesidad de negocio aplicando técnicas y tecnologías de SOA.

En muchos casos la solución consiste en definir algunos procesos de negocio e implantarlos mediante un BPM, o bien, habilitar la comunicación de dos sistemas mediante webservices y un service bus.

En estos casos el resultado inmediato suele ser satisfactorio y se obtiene un beneficio rápido. A fin de cuentas las tecnologías usadas por SOA tienen mucho ámbitos de aplicación, son fiables y dan buen rendimiento.

El problema radica en que no se está haciendo una verdadera implantación de SOA ya que no tiene un alcance corporativo, sólo implica a un departamento, y no se ha hecho pensando en las necesidades de toda la empresa. Como consecuencia de esta aproximación, los problemas de flexibilidad e interacción entre sistemas permanecerán.

Orientado a sistemas

En este caso el promotor del proyecto suele ser el departamento de IT, que busca una solución para comunicar los diferentes sistemas usados por la compañía.

Esta aproximación puede parecer que tiene una alcance corporativo pero tampoco es un proyecto SOA ya que se trata de un proyecto estrictamente tecnológico. El objetivo de una buena implantación de SOA en una empresa es alinear el negocio con la tecnología .

Orientado a la empresa

Esta es la implantación ideal de SOA. Estos proyectos están promovidos por la dirección de la empresa y tienen un alcance corporativo que afecta a todos los departamentos.

En estos escenarios la dirección y el departamento IT van coordinados y forman el gobierno SOA, pieza imprescindible para el éxito de cualquier implantación SOA.

Este enfoque quizás sea el que tarde más en obtener beneficios, pero a la larga es el que más se beneficia de las ventajas proporcionadas por SOA, como la flexibilidad, capacidad de adaptación y crecimiento y ahorro de costes (a largo plazo).

Libros sobre Alfresco

2008-12-29T11:00:00.000+01:00

Recientemente he leído dos libros sobre Alfresco que me han parecido bastante interesantes porque son una buena referencia para la gente que quiera desarrollar sobre Alfresco.

El libro 'Alfresco - ECM Implementation', de Munwar Shariff, es una introducción bastante completa al desarrollo sobre Alfresco. Afronta los temas desde la perspectiva de un usuario con poca experiencia en Alfresco y sigue un guión que va desde la instalación y configuración básica de Alfresco hasta la personalización del cliente web y workflows.

Es especialmente interesante toda la parte de instalación y configuración del producto ya que aporta un buen conjunto de buenas prácticas para la definición de la gestión documental con Alfresco.

También dedica bastante atención a la implementación de la seguridad, la gestión documental y la búsqueda, así como a las diferentes opciones disponibles en el cliente web para manejar estos elementos.

La parte de personalización del modelo documental y del cliente web es introductoria y da una visión de lo más básico que se puede hacer pero para el nivel del libro ya está bien.

Como curiosidad, incluye un capítulo dedicado a la gestión de imágenes y a la integración con fuentes OCR y otros escaners que da consejos muy prácticos sobre este tema, incluyendo ejemplos con fabricantes concretos como Kofax o eCopy.

En resumen, este es un buen libro para empezar a administrar y configurar Alfresco y tener una visión general de lo que se puede llegar a hacer a nivel de personalización e integración de la herramienta.

El otro libro es 'Alfresco Developer Guide', de Jeff Potts. Éste libro profundiza más en los temas de personalización y extensión de Alfresco además de dedicar capítulos enteros a los Web Scripts, los Workflows avanzados y al WCM de Alfresco.

Aunque este libro sea más complejo y entre en más detalle, su estilo es claro y fácil de seguir y los ejemplos propuestos son muy completos y útiles.

Incluye capítulos para la extensión del modelo documental, la personalización del cliente web y el manejo automático de contenidos. Además proporciona dos completas referencias para la configuración y la API de Alfresco.

En definitiva este libro es una guía bastante completa para aquellos que quieran profundizar en la extensión de Alfresco y las posibilidades que ofrece esta herramienta.

Estos dos libros vienen a demostrar el interés que existe por Alfresco y las enormes posibilidades que ofrece este completo ECM.

¡Feliz Navidad!

2008-12-24T11:00:00.001+01:00

Como dice el villancico, esta noche es Nochebuena y mañana Navidad, así que me gustaría felicitar a todo el mundo por estas fiestas y desear un fliz año nuevo 2009.

El arquitecto de software de IN2

2008-12-15T17:07:00.000+01:00

A principios de Diciembre, nos reunimos en la Llacuna los componentes del gabinete de arquitectura de IN2 para establecer las líneas generales de actuación para el próximo año.

Esta vez, nos reunimos: Daniel Flores, como director de tecnología de IN2, José Luís Latorre y Luis Felipe Fernández por parte del mundo Microsoft y .Net, y José Luis Carrasco, Juan Carlos Fernández y un servidor por parte de Java y el mundo Open Source. También estuvo presente el departamento de capital humano con Gabriel Monreal a la cabeza.

Uno de los temas que se trataron durante la reunión fue la definición del rol de los arquitectos dentro de la organización. Fue una discusión interesante y obtuvimos algunas conclusiones que me gustaría comentar.

Para empezar la definición de lo que es un arqutiecto de software es algo un tanto difuso, y se suele concretar en función de las necesidades de la organización donde el arquitecto desempeñará sus funciones. Así pues es importante conocer cuales son las atribuciones de un arquitecto.

La principal responsabilidad de un arquitecto software es la de ser el referente tecnológico de los proyectos, definir las líneas de diseño y ser responsable de las arquitecturas aplicadas. Además de los aspectos técnicos, un arquitecto ha de representar el papel del enlace entre los equipos de desarrollo y los gestores del proyecto, encargándose de proporcionar las guías de calidad, buenas prácticas y documentación que garanticen el cumplimiento de la arquitectura del proyecto. A todo esto, la incorporación de nuevas estrategías de las TI, como SOA, han incorporado un amplio rango de funciones a la figura del arquitecto.

En grandes empresas u organizaciones, con proyectos de amplio alcance, los arquitectos pueden permitirse la especialización en algunas de las areas mencionadas. Incluso para la empresa, esta especialización es beneficiosa ya que facilita la distribución de tareas entre los diferentes arquitectos. En estos casos, los arquitectos se pueden convertir en técnicos de alto nivel o en elementos de gestión con una visión técnica, según sus responsabilidades.

En una organización de menor envergadura, la figura del arquitecto ha de adquirir más funciones y por ello ha de cubrir más áreas dentro de los proyectos y de la misma empresa. Este arquitecto más 'todoterreno' debería tener las siguientes habilidades:

Una visión horizontal de la tecnología, que le permita conocer un amplio rango de tecnologías y la integración entre ellas.
Un dominio de la solución tecnológica, que le permita ser un referente técnico en los proyectos en los que participe.
Un conocimiento de la empresa, de los puntos fuertes adquiridos en proyectos anteriores y de las estrategias de negocio a seguir.
Una visión de mercado, que le permita adelantar tendencias y adquirir nuevas tecnologías útiles para la empresa.
Una buena capacidad de comunicación, para poder transmitir de forma clara sus puntos de vistas a desarrolladores, gestores y clientes.
Una capacidad de trabajar y hacer equipo para que sea referente y guía de sus compañeros.
Conocimientos para evaluar los costes y los riesgos de los proyectos en los que participa.

Es precisamente este tipo de arquitecto el que interesa a IN2, una persona que por su perfil y sus funciones está más implicado con la empresa y con sus compañeros, además de aportar la visión tecnológica inherente a su papel.

Este podría ser el resumen de las conclusiones obtenidas durante la reunión sobre este tema. Fue un debate muy interesante donde profundizamos en muchos de los aspectos mencionados y donde se plantearon ideas que ojalá podamos poner en práctica durante el próximo año.

Alfresco Enterprise 3.0 ya está aquí

2008-11-14T04:00:00.000+01:00

A principios de este mes, Alfresco lanzó la esperada nueva versión de su ECM, renovado y ampliado con nuevas funcionalidades y una nueva apariencia.

Entre las nuevas funcionalidades destacan:

Alfresco Share
Soporte al protocolo de SharePoint de Microsoft
La primera implementación de CMIS

Alfresco Share

La principal novedad de esta nueva versión es Alfresco Share, un nuevo web client orientado al trabajo colaborativo. Construido sobre la plataforma de desarrollo Surf y siguiendo las directrices de la web 2.0, este nuevo cliente incorpora a la gestión documental de Alfresco algunas utilidades muy interesantes:

Creación de comunidades virtuales.
Feeds de actividades, tareas, eventos,...
Blogs, wikis, foros.
Búsqueda ampliadas.
Visualizador de documentos en Flash
Y mucho más...

SharePoint Protocol

La nueva versión de Alfresco incorpora soporte al protocolo SharePoint que permite integrar los programas de Office con Alfresco de igual forma que lo hacen con SharePoint. Esta nueva funcionalidad lleva un paso más allá la integración de Alfresco con los productos de la popular suite de Microsoft.

CMIS

Alfresco 3.0 incluye la primera implementación comercial de este prometedor estándar del que ya hablé hace unas semanas. Alfresco es uno de los fabricantes de ECM que más se ha implicado en el desarrollo de esta solución y proporciona en esta nueva versión una plataforma para desarrollar y probar aplicaciones.

En definitiva, esta nueva versión es una buena noticia para toda la comunidad de Alfresco, y permite a Alfresco a mantenerse en la cresta de la ola de la tecnología de gestión documental de alto nivel.

Alfresco Roadshow en Barcelona

2008-10-16T10:00:00.000+02:00

El pasado 16 de Octubre se celebró en Barcelona la Iberia Roadshow de Alfresco con la esponsorización de IN2.

Dentro de la iniciativa de presentación de la nueva versión Alfresco Enterprise 3.0, Alfresco ha organizado la Iberia Roadshow, una serie de eventos para el encuentro de la gente de Alfresco con sus partners y personas interesadas en el producto. Se han celebrado encuentros en Sevilla, Cádiz, Badajoz, Mallorca, Valencia y Barcelona. IN2 ha colaborado en estos tres últimos.

Cada evento ha constado de una presentación a cargo de Bill Brooks y Andrés Lozano donde se ha presentado a Alfresco como compañia, su estrategia de negocio y su relación con clientes y partners. También presetaban la versión 3.0 de Alfresco.

Bill Brooks, de Alfresco, presentando la versión 3.0

Entre las novedades destacadas que se han presentado tenemos:

Alfresco Share : Una nueva aplicación que trabaja con el gestor documental y que potencia las herramientas colaborativas de Alfresco, muy en la línea de las webs sociales.
Alfresco Surf : Un framework para el desarrollo de aplicaciones que trabajen sobre Alfresco. Ya se ha utilizado para la creación de Alfresco Share.
Protocolo SharePoint : Alfresco 3.0 será el primer ECM que incluya el protocola de colaboración con Microsoft SharePoint y que se utiliza para la integración con Microsoft Office.
CMIS : Este nuevo estándar tendrá su primera implementación en la nueva versión de Alfresco.

El resto de presentaciones del evento han corrido a cargo de IN2 y se han dividido en dos bloques: las soluciones técnicas y los casos de éxito.

La primera de las soluciones técnicas ha sido la integración de Alfresco con Google Appliance para potenciar la indexación y búsqueda de contenidos desde Alfresco.

Carrasco, arquitecto en IN2, y la integración de Google

La segunda presentación técnica desmostraba como se puede integrar la firma digital en los workflows y acciones de Alfresco. Esta presentación ha incluído una demo de la solución usando tanto firma delegada como firma en el cliente.

Juan Carlos, arquitecto JavaEE, demostrando como firmar desde Alfresco

Los casos de éxito que hemos presentado son ejemplos de la amplia experiencia que tiene IN2 intalando e integrando Alfresco. El primer caso ha sido la Caja Andorrana de la Seguridad Social, una plataforma de tramitación en la que se usó Alfresco como repositorio documental y motor de workflows.

Josefí Subirats, directora de proyectos en IN2, presentando la CASS

El segundo caso de éxito ha sido el gestor documental implantado en el Instituto Geográfico Nacional, donde se instaló un Alfresco en cluster pensado para dar servicio a un gran número de usuarios y gestionar documentos de gran tamaño (más de 10Gb cada uno).

Yo presentando el caso del IGN

La iniciativa parece haber tenido éxito y todos los eventos han agotado las plazas disponibles, lo que demuestra el gran interés que despiertan las soluciones de gestión documental y Alfresco en particular.

...

Gracias a Porfi por la fotos y a Mónica por la presentación de Mallorca

CMIS: Un estándar esperado

2008-09-29T10:02:00.000+02:00

En el mundo de la integración de aplicaciones siempre existe la necesidad de comunicar diferentes sistemas que hablan lenguajes diferentes. Hace algunos años estas integraciones solían ser difíciles, costosas y, a veces, imposibles. Con el paso de los años se han ido imponiendo soluciones más o menos estandarizadas que facilitan la comunicación entre las aplicaciones. Este es el caso de los Web Services, tecnología ampliamente extendida y muy en boga gracias a SOA. Pero no siempre es suficiente con que los sistemas se puedan comunicar sino que también es necesario que se puedan entender hablando el mismo "idioma". Bajo este prisma es como nace CMIS.

Content Management Interoperability Services (CMIS) es un conjunto de Web Services pensados para compartir información entre repositorios de contenidos y que buscan la interoperabilidad de los diferentes sisitemas ECM. Aun no se trata de un estándar, pero ya existe una propuesta conjunta elaborada por los principales fabricantes de ECM entre los que se encuentran IBM, Alfresco, EMC, Microsost, Open Text, SAP y Oracle.

CMIS está compuesto de los siguientes elementos:

Un modelo de dominio, para definir los objetos y relaciones que pueden existir en el repositorio.
Un conjunto de APIs de comunicación, Web Services y REST, que permiten a las aplicaciones conectarse, navegar, leer y crear contenidos en los diferentes repositorios.
Un lenguaje de consultas, similar a SQL, capaz de definir criterios de búsqueda sobre propiedades, ubicación o "full-text" de los objetos.

Particularmente esta iniciativa me parece muy interesante. Siempre es una buena noticia disponer de nuevas herramientas que nos hagan más grato el trabajo, y ésta en concreto será muy bien recibida. El mundo de los ECM está experimentando un gran crecimiento en los últimos años y grandes empresas como Microsoft o IBM apuestan por ello. La llegada de este nuevo estándar supondrá un gran respaldo para toda la comunidad de desarrolladores e integradores que trabajamos con estas soluciones y ojalá que acabe gozando de tanta popularidad como el SQL, desarrollado hace ya dos décadas.

Alfresco, en su última versión community labs, ya ofrece una implementación preliminar de CMIS.

Para más información, podeis leer este completo artículo.

Usar isAccessAllowed con BEA WLP10

2008-09-07T20:00:00.000+02:00

Recientemente nos hemos visto en la necesidad de añadir seguridad en un portlet que se iba a desplegar en un portal Weblogic Portal 10. La modificación consistía en dar una funcionalidad concreta a un rol determinado dentro la aplicación.

Después de valorar diferentes alternativas, decidimos aplicar el tag isAccessAllowed de la taglib xmlns:auth="http://www.bea.com/servers/p13n/tags/auth" . Este tag proporciona la comprobación primaria para autorizar el acceso a recursos de WLP. Si el resultado de la comprobación es negativo, el cuerpo del tag no se renderiza.

Este tag espera los siguientes parámetros:

id. El nombre de la variable donde se almacena el resultado de la comprobación. Es de tipo booleano. Es obligatorio
resourceId. Representa la taxonomía definida para el recurso dentro de la aplicación. Es de tipo String y es obligatorio.
capability. Este no es obligatorio y representa el permiso concreto (view, edit, remove,...) que se quiere autorizar.

El problema de esta solución estaba en la construcción de la taxonomía del recurso que queríamos proteger (en este caso un portlet). No encontramos documentación de referencia de como construir esta cadena y tuvimos que investigar un poco hasta dar con la forma correcta.

Para construir el identificador de un recurso se debe concatenar los siguientes elementos:

Tipo_objeto + Etiqueta_de_portal + Etiqueta_de_desktop + Etiqueta_de_recurso

Donde:

Tipo_objeto es una constante: Portlet para los portlets y Page para las páginas.
Etiqueta_de_portal corresponde al Portal Path del portal.
Etiqueta_de_desktop es el Desktop Path del desktop donde está instanciado el portlet.
Etiqueta_de_recurso es el atributo Label de la instancia del portlet.

Todos estos valores se pueden obtener de forma bastante sencilla a partir de los elementos de presentación contextuales del portal. Por ejemplo:

<>
AppContext ac = AppContext.getAppContext(request);

AbstractButtonPresentationContext absBut =(AbstractButtonPresentationContext) pageContext.getAttribute("abstractbuttonpc");

StringBuffer resourceId = new StringBuffer("Portlet");

resourceId.append(EntitlementConstants.RESOURCE_ID_DELIMITER)
.append(ac.getPortalPath())
.append(EntitlementConstants.RESOURCE_ID_DELIMITER)
.append(ac.getDesktopPath())
.append(EntitlementConstants.RESOURCE_ID_DELIMITER)
.append(absBut.getWindowLabel());
< /jsp:scriptlet >

Además de a portlets y páginas, esta seguridad se puede aplicar a otro tipo de recursos siguiendo una nomenclatura similar.

Un posible inconveniente de esta solución estriba en el rendimiento, ya que el cálculo del resource id se hace a nivel de la capa de presentación. De todas formas, hay técnicas sencillas para evitar este problema.

WSRP en BEA Weblogic Portal

2008-08-17T17:00:00.000+02:00

Hace unos días, mi compañero en IN2, Juan Carlos, hablaba del despliegue de portlets en shared library para Weblogic Portal. La idea es buena ya que permite independizar el desarrollo de portlets de la administración y mantenimiento del portal. Aun así, algunos aspectos de esta solución no acaban de convencerme como, por ejemplo, que haya que detener la aplicación de portal cada vez que se despliega una actualización de la shared libary.

Una alternativa para la distribución de portlets es usar portlets remotos que cumplan el estándar WSRP.

El estándar WSRP se presenta como una herramienta muy útil para la distribución y consumo de portlets entre diferentes portales, independizando la presentación del portlet de la ubicación donde esté desplegado.

El portal de Weblogic está preparado para trabajar con WSRP de forma que se puedan añadir nuevos portlets sin necesidad de detener la aplicación ya que se pueden añadir nuevos productores de portlets desde la consola de administración del portal. Los pasos a seguir son los siguientes:

Localizar el productor del portlet.
Rellenar la información del productor
Registrar el productor (opcional)
Seleccionar los portlets a incorporar en nuestro portal
Utilizar los portlets en las páginas de nuestro portal

Esta aproximación puede que no sea adecuada para todos los escenarios de portal pero es la única que independiza del todo la aplicación de portal de los portlets. Además es una estrategia alineada con SOA ya que en este caso el portlet es el servicio que se quiere compartir y reutilizar.

El portal de Weblogic también permite usar portlets remotos desde el IDE Workshop, de forma que las definiciones de los productores de portlets se incluyen en el fichero .portal y se despliegan junto con el resto de la aplicación.

Porque sigo trabajando en IN2

2008-08-15T17:00:00.000+02:00

Este mes de Agosto ha hecho ocho años que colaboro con IN2. En el mundo en el que nos movemos esto puede parecer mucho tiempo y hay gente que me lo comenta y me pregunta '¿No tienes ganas de cambiar?' .

Entré en IN2 como becario gracias a mi amigo Fede y mi primera asignación fué participar en un proyecto de migración de una aplicación de Oracle forms 5 a 6. Un trabajo digno de un becario, que es lo que yo era. Durante esos primeros meses tuve la oportunidad de participar en varios proyectos con diferentes tecnologías, algunas nuevas para mi y otras conocidas. Fue en este periodo donde entré en contacto con las tecnologías que han marcado mi carrera profesional : Java, Oracle y Web.

También tuve la ocasión de conocer a gente que a la larga sería muy importante para mi profesionalmente. Algunos todavía siguen conmigo en IN2 y otros decidieron probar suerte en nuevos proyectos personales o profesionales.

Después de este periodo necesario de aprendizaje empezó mi periplo por clientes que dura ya casi siete años. Sacarme de la oficina y enviarme solo a trabajar con los clientes significó para mi una muestra de la confianza que habían depositado en mi y me motivó para hacer un buen trabajo.

Durante esos primeros años en IN2 cada proyecto era un nuevo reto para mi, implicaba aprender alguna nueva tecnología o herramienta y la experiencia adquirida era muy valiosa tanto profesional como personalmente. En este periodo pasé de trabajar 6 horas a trabajar jornada completa y dejé de ser becario para convertirme en colaborador de IN2 de pleno derecho.

Este periodo inicial en IN2 coincidió con el final del boom de las .com y fue una época mala para todas las empresas del sector. IN2 no fue la excepción. La empresa contó conmigo y me dió la oportunidad de seguir aprendiendo y trabajando en nuevos proyectos y clientes y fue en este momento cuando me di cuenta de que si quería y me esforzaba podía tener una carrera en IN2.

Estuve mucho tiempo trabajando en clientes y un poco alejado de las oficinas de IN2. La empresa sufrió un cambio de dirección y empezó el camino de la recuperación que la ha llevado a ser como es hoy. Durante estos años recibí ofertas para dejar IN2 pero valoré la confianza depositada en mi y lo que aun tenía por aprender y hacer en la empresa y decidí continuar en IN2. Puede que no fuera le mejor de las elecciones, pero sí sé que fue una buena elección.

Respondiendo a la pregunta planteada al principio de este artículo, no, aun no tengo ganas de cambiar de trabajo. Mientras me siga gustando lo que hago, mientras tenga cosas por aprender, mientras la empresa confíe en mi y me lo demuestre y mientras los compañeros de IN2 sigan siendo tan fantásticos, yo seguiré queriendo trabajar en IN2.

Evaluando la calidad del código

2008-08-05T13:00:00.000+02:00

Recientemente participé junto a mi compañero de IN2 José Luís Carrasco en la auditoría de la aplicación NEO de Abertis Telecom. El objetivo de la auditoría era determinar la calidad del código desarrollado, centrándonos en evaluar el diseño y la mantenibilidad.

La código a estudiar correspondía a una aplicación Java EE, construida sobre el bastidor OpenFrame. La aplicación está compuesta por diversos módulos web y servicios de integración con otros sistemas.

Con esta premisa, enfocamos la revisión del código en dos fases sucesivas :

La adecuación a la arquitectura propuesta y el diseño de la apliación, comparado con los requerimientos iniciales del proyecto. De esta forma podríamos medir el cumplimiento de estándares Java EE y best practices del framework utilizado.
Identificación del código problemático y gestión del código fuente con el objetivo de evaluar su mantenibilidad, flexibilidad y reutilización.

Una vez fijados los objetivos, el siguiente paso era escoger las herramientas adecuadas para realizar la tarea. Como este proyecto se distanciaba un poco de las auditorías que habitualmente hacemos en IN2, más centradas en el rendimiento, decidimos incorporar dos herramientas de análisis nuevas : JBuilder de CodeGear y Swat4j de CodeSwat.

La validación de la arquitectura y el diseño la realizamos revisando el código manualmente ,con el apoyo de los diagramas de secuencias automáticos generados con JBuilder a partir del código fuente.

En la revisión del código iba a ser una tarea bastante ardúa ya que teníamos que tratar casi 800 ficheros repartidos en más de 40 packages. Gracias a las nuevas herramientas de análisis este trabajo fue más sencillo.

Usamos el analizador de JBuilder para obtener un buen conjunto de métricas. Estás métricas se basan en reglas y cubren más de 200 variables del código.

Swat4j lo usamos para estudiar la aplicación de best practices de Java EE y analizar el código agrupando los resultados por objetos, packages y proyectos.

Estas dos herramientas están pensadas para trabajar bien integradas con Eclipse, es más, JBuilder es un Eclipse extendido y Swat4j es un plugin de Eclipse.

El resultado de la revisión fue bastante favorable, ya que el código tenía un nivel de calidad aceptable teniendo en cuenta el grado de madurez del proyecto. Apareció algún problema con la serialización de la sesión, algo bastante frecuente, y poca cosa más.

En definitiva, este fué un proyecto interesante que nos permitió experimentar con nuevas herramientas que seguro nos serán muy útiles en próximos proyectos.

Google gadgets de Alfresco

2008-07-22T02:36:00.000+02:00

Alfresco incluyó en su versión 2.1 la tecnología de WebScripts, pequeños componentes que hacen accesible a Alfresco desde otras aplicaciones. Cada WebScript está asociado a un método HTTP y a una URL única por lo que pueden invocarse desde cualquier navegador. Además, los WebScripts se almacenan en el repositorio de Alfesco, por lo que se pueden actualizar y desplegar sin necesidad de reiniciar el servidor de Alfresco.

Una de las funcionalidades que ofrecen los WebScripts es que se pueden usar para crear gadgets de google y así tener acceso a tu Alfresco desde tu página inicial de Google. Esta puede ser una opción interesante para aquellas empresas que usan Google Apps y quieran abrir su gestor documental a sus empleados sin tener que usar el cliente web de Alfresco.

Los pasos para publicar estos gadgets son los siguientes:

Escribir el WebScript.
Importar el WebScript en el repositorio.
Registrar el WebScript para activarlo.
Crear la definición del gadget en iGoogle.
Incluir el gadget en la página de iGoogle.

Veamos en detalle cada uno de estos pasos:

Escribir el WebScript.

Un WebScript se compone de tres elementos: una descripción, un script de ejecución y una plantilla de respuesta.

La descripción es un fichero XML que describe el método y mapea la URL a la que responde el WebScript.

El script se codifica usando JavaScript y es el encargado de realizar las operaciones con el repositorio. También es el encargado de crear el modelo que se proporciona a la plantilla de respuesta para la renderización de la respuesta.

Por último la plantilla es la encargada de crear la respuesta HTTP que puede soportar diferentes formatos. Estas plantillas son plantillas de FreeMarker (.ftl).

La API para trabajar con WebScripts es lo bastante potente como para implementar un cliente completo de Alfresco usando sólo esta tecnología, por lo que las posibilidades que ofrecen son muy amplias.

Importar el WebScript en el repositorio.

Un aspecto muy positivo de los WebScripts es que se despliegan directamente en el repositorio de Alfresco por lo que no hay que parar el servicio y se puede hacer desde cualquier ubicación.

Por defecto, los WebScripts se despliegan en la carpeta:

Empresa > Diccionario de datos > Web Scripts > org > alfresco

El despliegue del WebScript consiste en copiar los ficheros (descripción, script y plantilla) en esta carpeta o en uno de sus subdirectorios.

Registrar el WebScript para activarlo.

Antes de poder acceder al WebScript hay que activarlo. Para ello tenemos que acceder a la página inicial de WebScripts. Normalmente se encuentra en esta URL :

http://localhost:8080/alfresco/service/index

Al pulsar el botón Refresh list of Web Scripts se registrará el nuevo WebScript y ya será accesible mediante la URL que se haya indicado. Por ejemplo, si se ha registrado un WebScript con la URL /mygadget/browse, se podrá acceder a él mediante la URL :

http://localhost:8080/alfresco/service/mygadget/browse

Crear la definición del gadget en iGoogle.

Hasta el momento, todos los pasos que se han aplicado servirían para usar el WebScript tanto desde iGoogle como desde un navegador web cualquiera o desde una aplicación Java.

Para poder usar el WebScript desde iGoogle hay que registrarlo. El primer paso para registrar es crear la definición XML del gadget. Esta definición puede ser tan sencilla como:

Se puede ampliar la definición del gadget si se añaden preferencias de usuario u opciones de personalización.

Incluir el gadget en la página de iGoogle.

Una vez se tiene la definición, hay que registrarla en el directorio de iGoogle. Una buena forma de probar el gadget y publicarlo es usar el editor de Gadgets de Google.

Una vez hayamos registrado el gadget ya lo tendremos disponible en nuestra página de iGoogle.

En definitiva, la combinación de los WebScripts de Alfresco y los Gadgets de Google ofrece una nueva vía para compartir la información alamcenada en el gestor documental de Alfresco, confirmando que es una de las soluciones ECM más abiertas y fáciles de integrar que hay en el mercado.

Curso de Alfresco

2008-07-13T20:21:00.000+02:00

Desde hace años, IN2 intenta que sus colaboradores estén al día de las últimas tecnologías y por ello sigue un plan de formación contínua que ofrece periódicamente cursos y sesiones formativas. Siguiendo esta línea la semana pasada se organizó un nuevo curso de Alfresco y yo me encargué de impartirlo.

La particularidad de este curso ha sido que no se ha impartido en una aula de formación convencional sino que se hizo en una preciosa casa rural situada en el tranquilo pueblo de La Llacuna.

El objetivo del curso era doble, por un lado estaba el estrictamente formativo, basado en el curso ALF2110 de instalación y configuración de Alfresco, y por el otro estaba el social, para que los colaboradores de IN2 pudieran conocerse mejor y compartir sus experiencias.

Durante las sesiones del curso tatamos los temas básicos de administración de sistemas Alfresco, incluyendo la instalación, seguridad, backup y configuración de clusters. El temario que seguimos
se basa en el curso ALF2110 - System Administration (In2 está certificada por Alfresco para impartir este curso) y nos sirvió de base para practicar diferentes aspectos de la administración del producto. Las sesiones de trabajo fueron muy prácticas y se fomentó la participación de todo el grupo. Otros temas que discutimos fueron la integración de Alfresco con otras aplicaciones usando Webscripts, portlets y web services.

Además de aprender, este curso también ha servido para que los colaboradores de IN2 intercambiáramos nuestras experiencias con Alfresco y así diéramos visibilidad a todo el trabajo que se ha hecho ya en la casa con pasadas integraciones y desarrollos. Este aspecto fue muy importante y enriquecedor para todos.

Pero no todo durante estos días fue estudiar y hablar de trabajo, también hubo tiempo para pasarlo bien y divertirnos haciendo otras cosas.

Estoy particularmente contento con el grupo de gente que asistió al curso ya que han sido estupendos y ha sido un placer compartir con ellos estos días. Antes de este curso no había tenido la ocasión de conocer a algunos de ellos y me alegro de haberlo podido hacer ahora. Este fantástico grupo estaba formado por Carolina, Fredy, Alberto, Octavio, Walter, Javier, Andrés, Bea, Naiara y Andrés "Andresito" Tuells.

Además, para culminar el fin de semana, se sumaron a la reunión nuestras parejas, Judith, Rosa, María y Áurea, y celebramos el final del curso como un gran grupo de amigos más que como compañeros de trabajo.

Esta experiencia ha sido muy positiva para mi y espero que también lo haya sido para ellos. Ojalá que se puedan repetir iniciativas de este tipo y que nos lo pasemos todos igual de bien.

Y no puedo olvidarme de Gabriel y Zaira por organizarlo todo y escoger un sitio tan estupendo para el curso. Y Gabriel, la paella la dejamos para la próxima vez ;)

Estresando aplicaciones

2008-07-02T21:08:00.000+02:00

Una de las pruebas clásicas para determinar el rendimiento de una aplicación web es la prueba de estrés.

Las pruebas de estrés sirven para obtener una medida del rendimiento de la aplicación en diferentes escenarios de carga haciendo especial énfasis en la robustez, disponibilidad y tolerancia a fallos. El objetivo de estas pruebas es comprobar que la aplicación es capaz de seguir funcionando en situaciones de servicio extremas con mucha concurrencia o poca capacidad computacional.

Tipos de prueba

Existen varios tipos de pruebas de estrés, dependiendo de como se modeliza la carga de prueba:

- Pruebas con carga constante, que estresan la aplicación aplicando un volumen de usuarios concurrentes constante en el tiempo. Este tipo de prueba es el típico y sirve para comprobar como se comporta el sistema bajo una carga elevada (o no).

- Pruebas con carga creciente, donde el número de usuarios concurrente se va incrementando con el tiempo. Estas pruebas son útiles para detectar los puntos de saturación de una aplicación.

- Pruebas de carga variable, donde el número de usuarios concurrentes varía con el tiempo. SOn similares a las primeras pero permiten estudiar el comportamiento de una aplicación ante picos de carga.

Métricas

A la hora de hacer las pruebas de estrés lo que nos interesa es recoger información suficiente para valorar el rendimiento y la robustez del aplicativo analizado.

Hay muchas métricas posibles cuando se estudia la respuesta de una aplicación web, pero las más utilizadas son:

Tiempo de respuesta.
Número de páginas servidas por segundo.
Número de sesiones por segundo.
% de errores.
Número de hits por segundo

Otro tipo de métricas interesante a la hora de evaluar el rendimiento de una aplicación, corresponde al comportamiento del servidor de aplicaciones. Estás métricas incluyen:

Número de sesiones creadas.
Número de transacciones
Comportamiento de los pools de conexiones
Respuesta de la CPU
Consumo de memoria

Herramientas

Para hacer las pruebas y obtener los datos deseados es necesario escoger una buena herramienta.

Las características principales que debería tener una buena herramenta de estrés serían : flexibilidad para definir escenarios de prueba, potencia y versatilidad para crear los scripts de prueba y amplia recolección de datos de respuesta.

Entre las muchas herramientas disponibles destacaría las siguientes:

- JMeter de Apache. Viene a ser la herramienta estándar para las pruebas de estrés de aplicaciones web. Esta hecho en Java por lo que corre sobre cualquier entorno. Es bastante potente en el aspecto de creación de scripts. Además es extensible y gratuito.

- BadBoy también es muy popular y más fácil de usar que JMeter. La interficie gráfica es bastante amigable y las herramientas para crear scripts y escenarios son versátiles. Tiene versiones de pago y gratuita.

- WAPT de SoftLogica. La apuesta de la casa. Es una herramienta de pago que proporciona unos resultados numéricos y gráficos muy potentes y fáciles de comprender. Además permite la ejecución el paralelo de diferentes escenarios.

En definitiva, como un paso más para garantizar la calidad de una aplicación web, es importante realizar este tipo ed pruebas, con el doble objetivo de encontrar posibles problemas en la implementación de la aplicación y demostrar la robustez de la solución final.

BEA SOA Adoption & Implementation

2008-04-29T17:08:00.000+02:00

Hace un par de semanas un grupo de compañeros de IN2 y yo, llevamos a cabo una pequeña concentración en una casa rural para preparar el examen de certificación de BEA SOA Adoption & Implementation. Durante la semana siguiente realizamos los dos exámenes necesarios para conseguir el título y todos conseguimos aprobar. Así que, Felicidades Jose, Juan Carlos y Carrasco!

Esta ha sido muy interesante porque me ha permitido adquirir una visión más amplia sobre ese mundo tan lleno de posibilidades que es SOA, y estoy impaciente por poner en práctica algunas de las cosas que aprendí durante la preparación del examen.

Además la concentración fue muy divertida y me permitió pasar unos días con una gente estupenda con la que me encanta trabajar.

Migración de datos en Weblogic Portal

2008-04-27T20:37:00.000+02:00

El traspaso de información entre entornos de desarrollo y de producción puede ser una tarea difícil dependiendo de las herramientas utilizadas.

Recientemente me he visto en la necesidad de crear un nuevo dominio de producción de BEA Weblogic Portal que debiera aprovechar los contenidos introducidos en el Content Management de un dominio anterior. Había tres posibles formas de afrontar la tarea:

Creando un nuevo dominio desde cero y utilizar las herramientas de propagación de contenido proporcionadas por WLP.
Creando una nueva instancia en el cluster del dominio anterior, para copiar su configuración, y luego sacándola del cluster para que funcionara de forma independiente.
Creando un dominio nuevo desde cero y cambiar el acceso a datos para que utilizara el esquema de base de datos del dominio anterior.

La primera opción quedó descartada por el tiempo que implica y los problemas técnicos que presenta la propagación de contenidos de WLP. La segunda opción parecía buena idea pero añade un elemento de inestabilidad que amenaza la consistencia de la aplicación de Portal.

La última opción fue la que se llevo a cabo pero con una variante. El nuevo dominio se creó de cero, con el mismo nombre que el anterior, sobre un nuevo esquema de base de datos (la BD es una Oracle 10g). A continuación se hizo una exportación del esquema del dominio antiguo y una importación sobre el nuevo. Y funcionó !

Gracias a esta técnica conseguimos replicar el entorno de producción, nos permitió apagar el entorno antiguo y seguir trabajando con el nuevo con toda la información disponible.

Calidad del código

2008-03-30T23:59:00.000+02:00

Una de las medidas de la calidad de una aplicación es la calidad de su código. Muchas veces éste es un aspecto que se olvida porque no parece tan importante como la funcionalidad o la eficiencia. Puede que sea así, pero también es cierto que un código de calidad ayudará a conseguir esos otros factores clave.

No es habitual aplicar reglas de calidad del código durante la fase de desarrollo de un proyecto, pero creo que sería una buena medida para garantizar un resultado final satisfactorio. Al igual que se asume desarrollar test unitarios para validar la funcionalidad de los módulos terminados, se podría asumir la ejecución de herramientas automáticas que revisaran la corrección del código. De esta forma se podrían detectar y corregir antes los posibles errores y evitar llegar a situaciones donde el volumen de código a revisar y corregir sea tan elevado que no valga la pena ni intentar arreglarlo.

Herramientas de análisis

PMD

Es una herramienta que analiza código Java y se basa en reglas para detectar posibles errores. Entre ellos encontramos:

Incumplimiento de estándares de códificación
Bloques vacíos (try/cath/finally, switch, if,...)
Código no usado
Duplicación o importación inecesaria de paquetes
Problemas con el tamaño del código
Optimizaciones
Complejidad ciclomática (CCN)

Además, gracias al componente CPD (Copy paste Detector), podemos detectar patrones de código repetido.

Hammurapi

Otra herramienta muy útil para la revisión de código. Usa una base de reglas extensible para analizar el código. Los resultados obtenidos por esta herramienta son más comprensibles que los de PMD porque agrupa la información por niveles de severidad.

También obtiene métricas del código.

Métricas

Una forma rápida y fácil de hacer una primera valoración de la calidad de un código es obteniendo métricas. Buenos indicadores de la calidad son:

Número de línes de código de un método
Número de métodos de una clase
Número de parámetros de un método
Profundidad del árbol de herencia
Acomplamiento intra y inter packages

Estas herramientas se pueden integrar fácilmente con los entornos de desarrollo (Eclipse) y las herramientas de control (Maven), por lo que aplicarlas durante el desarrollo tiene poco coste. Hacer que los equipos de desarrollo utilicen estos automátismos para controlar la calidad del código que producen, contribuye positivamente al éxito del proyecto.

Presentación

2008-03-26T17:18:00.000+01:00

S.O.P. (Standard Operating Procedure) : best practice approach to executing tasks related to hardware and software maintenance, as well as incident and change management

A lo largo de los años me he visto en la necesidad de recurrir muchas veces a Internet en busca de ayuda y soluciones para los problemas que me encontraba en mi trabajo. Ya es hora de que empiece a devolver el favor con mi granito de arena.

Quiero usar este blog para hablar de aspectos de arquitectura de software, detalles técnicos y demás temas con los que me voy encontrando en mi día a día en el mundo del desarrollo de software y contribuir así a la gran comunidad de gente que ayuda a los demás con su experiencia.

Empecemos.