Archiving en Alfresco 3.2
Toni Febrero 17th, 2010
Actualización 25/Feb/2010: ver demo-config-files para configuración más cómoda incluso desde Share, reglas y demás (doc calentito que me han enviado desde Alfresco, Gracias Paul!!).
¿Que es el archiving/archivado? Un archivo en gestión documental es una colección de documentos históricos, así como el lugar donde se encuentran. Pues bien, vamos a ver como se configura Alfresco para poder almacenar los contenidos en diferentes sistemas de ficheros, particiones o filesystem (como quieras llamarlo). Cada filesystem puede ser de diferente naturaleza, es decir, los contenidos que se trabajan actualmente deberán estar en los discos más rápidos (discos locales o en una SAN) y los contenidos históricos o de acceso poco frecuente pero debemos mantener, podemos almacenarlos en discos más lentos/baratos o por ejemplo en una NAS.
Todo esto se consigue en Alfresco gracias al Content Store Selector. El Content Store Selector ofrece un mecanismo de control que relaciona el contenido lógico con un fichero físico y su ubicación. Usando el aspecto cm:storeSelector y asignándole una propiedad cm:storeName podemos mover el contenido de un Store a otro de forma totalmente transparente tanto para el usuario como para la aplicación a la hora de mostrar los contenidos, claro que previamente tenemos que definirlos. Esto nos permitirá declarar políticas para controlar la capa de almacenamiento y el uso que de ella hace Alfresco en base a regales de negocio.
Veamos como se configura en base al siguiente escenario:
El repositorio y los ficheros de uso diario, los más usados, los tenemos en /opt/alfresco/alf_data/contentstore, supongamos que ese filesystem corresponde a los discos más rápidos. También tenemos un disco local más lento montado en /opt/alfresco/alf_data/storeA, e incluso podemos tener un filesystem de tipo NAS para los datos que ya no usamos pero necesitamos almacenar montado en /opt/alfresco/alf_data/storeB.
¿Cómo lo configuramos?
Creamos un fichero llamado “sample-content-store-selector-context.xml” en shared/classes/alfresco/extension con el siguiente contenido, lee los comentarios para entender la configuración:
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE beans PUBLIC '-//SPRING//DTD BEAN//EN' 'http:// www.springframework.org/dtd/spring-beans.dtd'>
<!-- Define the new file stores -->
<beans>
<bean id="firstSharedFileContentStore" class="org.alfresco.repo.content.filestore.FileContentStore">
<constructor-arg>
<value>${dir.root}/storeA</value>
</constructor-arg>
</bean>
<bean id="secondSharedFileContentStore" class="org.alfresco.repo.content.filestore.FileContentStore">
<constructor-arg>
<value>${dir.root}/storeB</value>
</constructor-arg>
</bean>
<!-- Declare the mapping between store names and store instances -->
<bean id="storeSelectorContentStore" parent="storeSelectorContentStoreBase">
<property name="defaultStoreName">
<value>default</value>
</property>
<property name="storesByName">
<map>
<entry key="default">
<ref bean="fileContentStore" />
</entry>
<entry key="storeA">
<ref bean="firstSharedFileContentStore" />
</entry>
<entry key="storeB">
<ref bean="secondSharedFileContentStore" />
</entry>
</map>
</property>
</bean>
<!-- Point the ContentService to the 'selector' store -->
<bean id="contentService" parent="baseContentService">
<property name="store">
<ref bean="storeSelectorContentStore" />
</property>
</bean>
<!-- Add the other stores to the list of stores for cleaning -->
<bean id="eagerContentStoreCleaner" class="org.alfresco.repo.content.cleanup.EagerContentStoreCleaner" init-method="init">
<property name="eagerOrphanCleanup" >
<value>${system.content.eagerOrphanCleanup}</value>
</property>
<property name="stores" >
<list>
<ref bean="fileContentStore" />
<ref bean="firstSharedFileContentStore" />
<ref bean="secondSharedFileContentStore" />
</list>
</property>
<property name="listeners" >
<ref bean="deletedContentBackupListeners" />
</property>
</bean>
</beans>
Si te fijas en los dos primeros beans, los valores que se especifican están relacionados con la ubicación de los dos Stores adicionales que estamos creando, en esta caso, relativos a ${dir.root} que es un atributo declarado en alfresco-global.properties. Si nuestros nuevos filesystems no están dentro de dir.root podemos poner la ruta absoluta, por ejemplo <value>/mnt/storeA</value>.
Para poder usar los nuevos contentStores debemos configurar el web-client (Alfresco Explorer) y declararlo como aspecto. Editamos web-client-config-custom.xml y añadimos las siguientes lineas:
<!-- Configuring in the cm:storeSelector aspect -->
<config evaluator="aspect-name" condition="cm:storeSelector">
<property-sheet>
<show-property name="cm:storeName" />
</property-sheet>
</config>
<config evaluator="string-compare" condition="Action Wizards">
<aspects>
<aspect name="cm:storeSelector"/>
</aspects>
</config>
Hecho lo anterior ya podemos reiniciar el servidor de aplicaciones para que los cambios surtan efecto.
Ahora vamos a ver como empezar a usarlo. Recuerda que el aspecto, aunque pueden aplicarlo todos los usuarios, sólo el usuario administrador podrá especificar el store correspondiente y sólo es aplicable a contenidos (no a espacios). En este ejemplo veremos como hacerlo de forma manual, para sistemas en producción deberíamos hacer un script que modifique dicho metadato automáticamente en base a las necesidades que tengamos, por ejemplo los que estén dentro de un espacio concreto, los que tengan más de N años en el repositorio, etc. El procedimiento sería el siguiente:
- Localizamos el fichero con el que queremos probar (lo moveremos al storeA).
- Vamos a “Ver detalles” de dicho fichero y pinchamos en “Ejecutar una acción”
- Seleccionamos “Agregar aspecto al contenido” -> “ContentStore Selector” -> Aceptar -> Finalizar
- En las propiedades del fichero ya veremos un nuevo metadato llamado “Store Name”.

Editamos las propiedades y en Store Name especificamos: storeA

Cuando pinchemos en Aceptar, automáticamente el contenido se moverá de forma transparente al filesystem alf_data/storeA/2010/2/17/22/50/4365380f-daf1-494c-b79d-db11480cb171.bin correspondiente, en mi ejemplo, a un fichero pdf.
¿Interesante no?
ACTUALIZACIÓN: para automatizar la clasificación por “Stores” podemos hacer un script en Java Script llamado, por ejemplo, action_storeA.js o B según el sitio donde queramos colocar los ficheros, con el contenido:
document.properties["cm:storeName"]="storeA"; document.save();
Lo guardamos y subimos a Diccionario de datos -> Scripts. Hecho esto podemos ejecutar una acción sobre el fichero de turno y seleccionamos “Ejecutar un script” -> Seleccionamos nuestro script “action_storeA.js” y listo. También podemos incluirlo en una regla y hacer el proceso de forma automática, cuando entren los ficheros a un espacio concreto, o incluso clasificar si son vídeos, imágenes, pdf, cad, etc.
- administración de sistemas
- Comments(16)


Interesante no, interesantísimo por las posibilidades que ofrece no solo para el archiving
Muy interesante. Como bien dices, asignándole un proceso que directamente los coloque en StoreA cuando pase un tiempo, o que avise a los usuarios correspondientes, debe quedar una cosa bastante chula.
Gracias a los dos. La potencia de los scripts en Alfresco, junto con las acciones y las reglas (ejecutar un script) es considerable así como su planificador de tareas, se le puede sacar mucho jugo a todo esto.
Hablándolo con Fernando (fegor), se puede poner ese aspecto como parte del tipo “content” por defecto y de esa forma es más fácil ir clasificando el contenido a posteriori. También se pude mejorar el “Action Wizard” para que mediante una regla más sencilla y sin necesidad de script, podamos clasificar el contenido por stores automáticamente. Por ejemplo, todo lo que entre en un espacio (directorio) concreto, que lo almacene en el storeA.
Interesnate post Toni, pero mas que archiving yo estaria hablando de la posibilidad de realizar ILM en cuanto a la getión del almacenamiento que utiliza el gestor documental Alfresco. Resulta realmente interesante poder priorizar el I/O del online de datos mas utilizado a nivel de aplicación frente al menos utilizado al igual que el online de tipo historico. En cualquier caso habria que considerar igualmente la gestión del almacenamiento como backend de cada uno de este tipo de FileSystems, en este aspecto ZFS incorpora estructuras de tipo pool realmente potentes por la discriminación de la configuración de los niveles de tolerancia a fallos RAID, al igual que las caches de escritura y/o lectura en discos SAS (caros), SATA (mas baratos) e incluso SSD (mas rapidos).
Hola Toni:
Muy interesantes las posibilidades del content store selector combinados con las reglas de contenido de Alfresco. Sabes si esta disponible esta característica con la versión Community 3.2? Y con las versiones 3.1.1 (Enterprise o Community)?
Un saludo.
–C.
Si Victor, la verdad es que sería más apropiado haberlo dicho de otra forma, es decir, como implementar HSM (http://en.wikipedia.org/wiki/Hierarchical_storage_management) basados en la estrategia ILM (http://es.wikipedia.org/wiki/Information_Lifecycle_Management) en Alfresco, no?
Cesar, por lo que he hablado con Alfresco y según la wiki, por ahora sólo está disponible para la versión Enterprise 3.2. Entiendo que este tipo de opciones sólo son útiles para instalaciones en sistemas de producción con gran volumen de datos para los que está destinado la versión Enterprise.
Gracias a los dos por los comentarios!!
Ya tengo como hacerlo de forma automática con un script, actualizo el post con los datos.
Sobre la actualización, exacto, era lo que te comentaba. Es más, puedes hacer que se realice todo al mismo tiempo, es decir, la asignación del aspecto y del valor concreto en el mismo script.
Por ejemplo, en un script llamado StoreB.js
var props = new Array(1);
props["cm:storeName"] = “storeB”;
document.addAspect(“cm:storeSelector”, props);
Realmente interesante
Una breve revisión de Alfresco Enterprise 3.2…
Hace un par de meses salió la versión Enterprise……
Gracias Cesar, buen resumen!!
Muchas gracias Toni por la información.
Soy novata en Alfresco y la verdad es que me esta resultando muy útil.
Pero al intentar ejecutar tu ejemplo, me he encontrado con un problema.
Mi tomcat no es capaz de encontrar el bean storeSelectorContentStoreBase.
Y creo que me va a suceder lo mismo con fileContentStore y baseContentService.
Te agradecería mucho si me pudieras aclarar donde esta definida esta clases.
Y si debe estar definida dentro del propio sample-content-store-selector-context.xml, ¿Podrías facilitarme su código?.
Muchas gracias de antemano y un saludo.
Hola María José, que versión de Alfresco estás utilizando? Recuerda que esta opción es válida para la versión Enterprise solamente, por ahora.
Gracias por comentar en el blog.
Buenos días Toni.
Pues creo que va a ser eso.
Yo estoy usando el Alfresco Community 3.2.
¿Y existe alguna alternativa para hacer esto mismo con Alfresco Community?.
Muchisimas gracias por contestar tan rápido.
Un saludo.
Hola, pues por ahora no existe una alternativa de esa misma forma. Se podría jugar con los directorios de Año/Mes/Día a nivel de file system pero no a nivel de contenidos. No se si el Transfer Service te puede servir aunque no es para eso. El TS está disponible en la 3.3 Community.
Saludos.
Muchísimas gracias Toni.
Un saludo.