Cuando vamos a tener un sistema con gran cantidad de usuarios (miles) y con necesidades importantes de transformación de formatos o incluso para lanzar una reindexación completa de ficheros, metadatos y contenido de los ficheros, puede ser útil escalar, ampliar nuestra infraestructura de Alfresco para usar recursos que tengamos disponibles en otras máquinas.

En este artículo voy a enseñar como configurar Alfresco Enterprise para usar un Open Office corriendo como servidor en un servidor remoto.

[bash]
/usr/bin/soffice -headless -nofirststartwizard -accept="socket,host=192.168.0.30,port=8100;urp;StarOffice.ServiceManager" &
[/bash]

[bash]
### External executable locations ###
ooo.exe=/backup/alfresco/alfresco-enterprise-3.4.3/openoffice/program/soffice.bin
ooo.enabled=false
ooo.port=8100
ooo.server=192.168.0.30
img.root=/backup/alfresco/alfresco-enterprise-3.4.3/common
img.dyn=${img.root}/lib
img.exe=${img.root}/bin/convert
swf.exe=/backup/alfresco/alfresco-enterprise-3.4.3/common/bin/pdf2swf
jodconverter.enabled=true
jodconverter.officeHome=/backup/alfresco/alfresco-enterprise-3.4.3/openoffice
jodconverter.portNumbers=8100
[/bash]

Recuerda, en el archivo anterior, activar “jodconverter.enabled=true” y añadir el valor “ooo.server” con la IP donde estará el servidor dedicado con Open Office.

[xml]
<?xml version=’1.0′ encoding=’UTF-8′ ?>
<!DOCTYPE beans PUBLIC ‘-//SPRING//DTD BEAN//EN’ ‘http://www.springframework.org/dtd/spring-beans.dtd’>

<beans>

<bean id="openOfficeConnection" class="net.sf.jooreports.openoffice.connection.SocketOpenOfficeConnection">
<constructor-arg type="java.lang.String" value="${ooo.server}"/>
<constructor-arg type="int" value="${ooo.port}"/>
</bean>

<bean id="transformer.OpenOffice" class="org.alfresco.repo.content.transform.RemoteOpenOfficeContentTransformer" parent="baseContentTransformer" >
<property name="connection">
<ref bean="openOfficeConnection" />
</property>
<property name="documentFormatsConfiguration">
<value>classpath:alfresco/mimetype/openoffice-document-formats.xml</value>
</property>
</bean>

<bean id="openOfficeConnectionTester" class="org.alfresco.util.OpenOfficeConnectionTester">
<property name="connection">
<ref bean="openOfficeConnection"/>
</property>
<property name="strict">
<value>false</value>
</property>
</bean>

</beans>
[/xml]

Hechos esos cambios debemos reiniciar el servidor de aplicaciones y listo. Asegúrate que desde el servidor de Alfresco se llega al puerto de OpenOffice remoto por ejemplo haciendo “telnet 192.168.0.30 8100”, también puedes ver el tráfico que se genera entre los servidores lanzando el comando “tcpdump -nni eth0|grep 8100” en el servidor de OpenOffice.

Recuerda que esta es una funcionalidad de escalabilidad adicional que está disponible en Alfresco Enterprise. Yo la he probado con la versión 3.4.3.

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

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

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

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

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

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

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

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

para especificar la siguiente:

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

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

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

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

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

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

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

Y cambiamos la ruta de CATALINA_OUT por la ruta deseada:

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

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

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

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

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

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

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

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

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