zylk.net

First steps on a digital signature android app integrated with alfresco

2012-04-03T16:51:32Z

We continue developing features for sinadura android client. Last week we added browsing and downloading documents from an Alfresco repository.

So now we can, browse repository, download a remote PDF to the mobile client, sign it with our p12 certificate with timestamp, and update the document in the repo.

Another step/part in Alfresco integration is the validation module for checking signatures, that we showed some weeks ago, using Alfresco as a Digital Signature Validation Service.

http://www.zylk.net/web/guest/web-2-0/blog/-/blogs/alfresco-ecm-working-as-a-simple-digital-signing-service

Creando y gestionando de manera dinámica propiedades de tipo constraint en Alfresco

2012-04-02T07:29:07Z

Basándonos en este artículo del blog de Alfresco relativo a propiedades dinámicas en tipos de contenido, hemos desarrollado un sencillo componente para utilizar y gestionar listas dinámicas en uno de nuestros modelos de contenido utilizados en zylk.net.

En nuestro caso, tenemos un modelo de contenido para gestionar incidencias o tickets, con un tipo base bug:incidencia, del cual tenemos el siguiente extracto:

<type name="bug:incidencia">

<title>Incidencia</title>

<parent>cm:folder</parent>

<properties>

<property name="bug:incidencia_asignar">

<title>Asignar a</title>

<type>d:text</type>

<constraints>

<constraint ref="bug:AsignarIssue" />

</constraints>

</property>

<property name="bug:incidencia_estado">

<title>Estado</title>

<type>d:text</type>

<constraints>

<constraint ref="bug:EstadosIssue" />

</constraints>

</property>

<property name="bug:incidencia_prioridad">

<title>Prioridad</title>

<type>d:text</type>

<constraints>

<constraint ref="bug:PrioridadesIssue" />

</constraints>

</property>

</type>

Para las tres propiedades anteriores se utilizan un conjunto de constrains que se definen de manera dinamica a continuación, a partir de una query de lucene sobre el repositorio. Es decir, gestionamos las propiedades en el repositorio (y no en un archivo xml del modelo), y las consumimos mediante querys de lucene.

Para asignar incidencia a usuario (person):

<constraint name="bug:AsignarIssue"

type="zylk.net.constraints.SearchBasedListConstraint" >

<parameter name="query">

<value>TYPE:"{http://www.alfresco.org/model/content/1.0}person"</value>

</parameter>

</constraint>

Para definir los estados de la incidencia (categorías):

<constraint name="bug:EstadosIssue"

type="zylk.net.constraints.SearchBasedListConstraint" >

<parameter name="query">

<value>PATH:"/cm:generalclassifiable/cm:Aplicaciones/cm:Bugtracker/cm:Estados//."</value>

</parameter>

</constraint>

Para establecer la prioridad de la incidencia (folders):

<constraint name="bug:PrioridadesIssue"

type="zylk.net.constraints.SearchBasedListConstraint" >

<parameter name="query">

<value>PATH:"/app:company_home/app:dictionary/cm:Aplicaciones/cm:Bugtracker/cm:Prioridades//."</value>

</parameter>

</constraint>

El caso de uso es el siguiente:

Tenemos un tipo de contenido con una propiedad definida que es variable bug:EstadosIssue y necesita de una administración propia, porque el administrador requiere añadir nuevos valores a esa constraint con cierta frecuencia. Esta problemática se puede gestionar con categorias en Alfresco (pero solo el administrador puede acceder a través de las interfaces de Alfresco Explorer y Share).
Tenemos un tipo de contenido con una propiedad definida que es variable bug:PrioridadesIssue y necesita de una administración propia y donde no sólo por los administradores sino un grupo de usuarios va a añadir valores con cierta frecuencia. Esta problemática se puede gestionar con una estructura de carpetas virtual creada por ejemplo en Data Dictionary (con permisos de edicion para el conjunto de usuarios editores)

La clase que implementará la carga de valores extiende de ListOfValuesConstraint (ver wiki)

public class SearchBasedListConstraint extends ListOfValuesConstraint implements Serializable

haremos uso del ServiceRegistry para poder llamar a los servicios que necesitamos (SearchService, NodeService...)

private static ServiceRegistry registry;
public ServiceRegistry getServiceRegistry()
{
return registry;
}
public void setServiceRegistry(ServiceRegistry registry)
{
SearchBasedListConstraint.registry = registry;
}

tendremos un método que realizará una búsqueda Lucene con una query que pasaremos como parámetro desde el modelo de contenido.

protected List<String> getResults()
{
   getServiceRegistry().getAuthenticationService().authenticate("admin", "admin".toCharArray());

   List<String> allowedValues = new ArrayList<String>();
   for (ResultSetRow row : resultSet)
   {
     if(nodeSvc.getType(row.getNodeRef()).equals(ContentModel.TYPE_PERSON)){
     allowedValues.add((String)nodeSvc.getProperty(row.getNodeRef(), ContentModel.PROP_FIRSTNAME) + " "
      + (String)nodeSvc.getProperty(row.getNodeRef(), ContentModel.PROP_LASTNAME));
      }else{
     allowedValues.add((String)nodeSvc.getProperty(row.getNodeRef(), ContentModel.PROP_NAME));
    }
   } 
   if (allowedValues.size() == 0)
    allowedValues.add("");
return allowedValues;
}

también es necesario sobreescribir el método getAllowedValues para que cargue los valores obtenidos en la búsqueda:

@Override
public List<String> getAllowedValues()
{
List<String> allowedValues = getResults();
super.setAllowedValues(allowedValues);
return allowedValues;
}

y por último, tendremos que tener definido el bean en el contexto:

(bug-model-context.xml)

<bean id="SearchBasedListConstraintInitializer"

class="zylk.net.constraints.SearchBasedListConstraint">

<property name="serviceRegistry">

<ref bean="ServiceRegistry"/>

</property>

</bean>

PS: Para desplegar la clase java hemos creado un jar y lo hemos copiado en $ALF_HOME$/tomcat/webapps/alfresco/WEB-INF/lib.

Ejemplos:

Constraint para usuarios:

Constraint de categorías:

Constraint de carpetas:

Desarrollando aplicaciones J2EE sobre Alfresco IV – Aplicativo final

2012-03-27T14:34:29Z

Como colofón a la entrega de 'Desarrollando aplicaciones J2EE sobre Alfresco' [1] [2] [3] , vamos a comentar el caso de éxito de la creación de un aplicativo final para uno de nuestros clientes.

En su antigua vertiente, el cliente hacía uso del software propietario Lotus Notes, sistema cliente/servidor de colaboración y correo electrónico.

El principal uso que daban a esta aplicación consistía en:

Cliente de correo
Gestor de conocimiento, albergando los registros entrantes y salientes de la oficina, así como la generación de expedientes asociados a estos.
Almacenamiento de correos electrónicos (con sus correspondientes adjuntos) relacionados con los registros y expedientes en el gestor de conocimiento.

Con la colaboración de Irontec se remplazó dicho software por una combinación basada en software libre; Zimbra 7.1.1 y una aplicación J2EE a medida bajo Alfresco Community 3.4.0.

Aplicación a medida

Alfresco Community 3.4d

Desde Zylk.net tenemos una amplia experiencia con este gestor documental, y aunque nuestra primera aproximación fue desarrollar la aplicación sobre el share de Alfresco, optamos por trabajar sobre un terreno conocido, J2EE, mientras nos familiarizábamos con las tecnologías de Alfresco Share; YUI, Surf, Freemarker, JS avanzado, ...

Aplicación web J2EE

La aplicación web, consta de 2 interfaces para dar servicio a un zimlet y a las peticiones síncronas y asíncronas de la aplicación web.

Desde el core de la aplicación tendremos el módulo Alfresco, que se compondrá de una paquetería para las operaciones CMIS (OpenCMIS) y para aquellas operaciones que requieran del uso de los webscripts a medida, un paquete para la gestión de conexiones HTTP (Apache HTTP Commons)

Desde Alfresco haremos uso, desde el binding Atompub, del servicio CMIS que se nos ofrece.

Como comentamos en anteriores entradas, dado que ciertas funcionalidades no las veíamos cubiertas desde este interfaz, optamos por crearnos webscripts Alfresco a medida.

El mapa funcional de la aplicación se podría definir en:

Registros
- Listado de registros E/S disponibles en el sistema, paginados y ordenados, con un buscador simple y otro avanzado, para poder realizar una búsqueda por metadatos.
- Alta de registro de entrada / salida
- Detalle de registro E/S
  - Características generales
  - Datos de origen/destino
  - Estado de archivado; revisor, responsable de archivo y registros asociados
  - Archivos e Emails relacionados.
Expedientes
- Listado de expedientes disponibles en el sistema, paginados y ordenados, con un buscador simple y otro avanzado, para poder realizar una búsqueda por metadatos.
- Detalle del expediente
  - Características generales
  - Registros asociados
  - Archivos e Emails relacionados

Os dejamos unas cuantas imágenes de la aplicación.

Creación de un nuevo registro

Resultados y buscador simple de registros

Búsqueda avanzada de registros

Asociación entre un registro y expediente

Petaña de revisión en el detalle de un registro

Registros asociados a un expediente

Pestaña 'Documentos de interés' en el detalle de un expediente, en donde se pueden ver documentos e emails adjuntos

Zimlet

Para la integración del gestor de correo con el gestor documental, desarrollamos junto con Irontec un componente zimlet para Zimbra y mediante una capa intermedia en nuestra aplicación J2EE relacionamos el zimlet y Alfresco.

Migración de datos

Para la migración de datos desde un sistema Lotus ↔ Alfresco, hicimos uso de la librería DIIOP (Domino Internet Inter-Orb Protocol) que nos ofrece el mismo producto, para comunicar aplicaciones Java con el servicio de datos Lotus Domino.

Si como ocurrió en nuestro caso, desconocéis el modelo de datos empleado en la aplicación y este ha sufrido variaciones en el transcurso de su uso, el proceso de migración os resultará algo cansino, ya que sólo podréis conocer el contenido de los documentos (objeto genérico de Lotus) con una iteración de propiedades.

Sin embargo, la API DIIOP es muy utilizable, y apenas tendréis problemas en la parte técnica.

Tras las 38 horas que tardó todo el proceso de migración, conseguimos migrar 27.605 documentos con un peso total aproximado de 20Gb.

Signing PDF documents with Sinadura Mobile

2012-04-03T11:30:59Z

Last week we finished the implementation of a mobile client for android devices in sinadura project (still in beta). We have implemented some of the main features of sinadura Desktop application for PDF documents, like TSA signatures with p12 certificates. Other interesting features are related with the share possibilities of the mobile client with external services like Gmail, Google Docs or Dropbox.

The next steps are related with the validation of signatures, the cmis integration with Alfresco respositories, the implemetation of XaDES signatures or even a sync service for the client with a CMIS repository.

http://www.slideshare.net/zylk/sinadura-mobile

Formando un perfil "Community manager"

2012-03-23T11:06:23Z

La pasada semana parte del equipo de Zylk acudió a un curso de "Funciones del comunity manager en la empresa" organizado por Enpresa digitala e impartido por Miguel Fernández Arrieta de la Universidad de Mondragón.

Miguel nos dió a conocer, los valores de las redes sociales y para que se utilizan, como por ejemplo: el twitter, facebook, youtube,linkedin...etc...

Ahora os cuento un poco mi experiencia en primera persona, ya que acudí al curso.

En este curso nos enseñaron como cuidar la identidad digital de la empresa. Para todo esto, Miguel comenzó informándonos a cerca de la importancia en darnos de alta en "alertas de google", y de esta manera ver en todo momento las publicaciones que se realicen con nuestro nombre.

Esto mejorarará la relación de la empresa con las personas y a su vez la propia relación interna.

Nos dió a conocer como utilizar un cliente web, en este caso llamado "hootsuite" con el que podremos controlar y gestionar, los movimientos en el twitter, facebook y todas las páginas de las redes sociales en las que la empresa se encuentre logeado. Comentaros, que esta herramienta me pareció bastante interesante.

Si realizamos algún otro curso en relación a esto, no dudaré en contároslo. :-)

En el CeBIT 2012

2012-03-11T10:55:41Z

La semana pasada estuvimos en CeBIT 2012 en una acción de internacionalización de las empresas vascas de software libre promocionada por ESLE. Durante los días de la exposición pudimos observar las tendencias del sector TIC, así como la visión y comercialización de las empresas, institutos de investigación y gobiernos de referencia. Un total de 4200 empresas y 70 paises representados. Por parte de ESLE, Irontec, Codesyntax y Zylk.net se reunieron con diferentes empresas y asociaciones presentando una muestra de soluciones de software libre de voz sobre IP, información geográfica, portales corporativos [1] [2] [3] y firma digital, entre otras.

Brasil era el país invitado a esta cita alemana de Hannover. Acudieron a la inaguración las jefas de estado de Alemania y Brasil, conscientes de la importancia de la cita para establecer vínculos entre empresas europeas y países emergentes en un contexto cada vez mas global e internacional. Casi todos los países, emergentes o no, presentaron una muestra de su sector y de su tecnología. Con tristeza pudimos observar la poca presencia de la expedición española con apenas 20 empresas en toda la feria.

El software libre también estuvo representado a través empresas, partners de producto y asociaciones que promueven y apoyan el software libre. Tuvimos ocasión de conversar con gente que trabaja en tecnologías del software libre como Liferay, Alfresco, Plone o SugarCRM, y con asociaciones como la Free Software Foundation Europea (FSFE), entre muchos otros, que nos contaron de primera mano sus novedades. Con las empresas que trabajaban en tecnologías similares a las nuestras pudimos intercambiar orientaciones e impresiones de nuestras soluciones y quien sabe si alguna colaboración en el futuro.

Alfresco ECM working as a simple Digital Signing Service

2012-03-04T11:14:53Z

Recently, we have developed an Alfresco ECM module, for signature validation of documents with the help of Sinadura libraries. Sinadura is an open source java suite for signing and validating any type of documents, with advanced signature properties.

The module allows the possibility of checking the validity of signatures, timestamps, and corresponding chain certificates. All the signature information is represented with an aspect with the following metadata properties (in spanish):

So now, we can store and preserve in our CMIS repository all of those important signed documents of our organization, and automatically check the validity of their signature properties with the help of an Alfresco content rule.

The module is used in the core of a signature BPM process, where desktop, web and smartphone clients are involved and working against Alfresco Repository.

Accediendo a repositorios de maven securizados

2012-02-23T16:29:46Z

Hace unos meses en zylk.net cambiamos toda la arquitectura de servicios a una estructura centralizada y virtualizada. Donde antes había urls de tipo

mantis.zylk.net
sugarcrm.zylk.net
zimbra.zylk.net
nexus.zylk.net
etc...

ahora hay un punto común de acceso, securizado por https services.zylk.net/mantis|nexus|zimbra, uno de los servicios que se ofrecía y ofrece a terceros es un respositorio maven servido por el producto nexus de sontartype. Se usa principalmente para el desarrollo de los productos de la suite de sinadura.

La semana pasada empezamos a desarrollar una nueva versión de firmador de ficheros, en la que vamos a incorporar el proyecto de apache-vfs para poder firmar documentos en remoto, webdav, ftp, etc.. cuando empezamos con el desarrollo nos encontramos con un pequeño problema de comunicación con el repositior de maven ya que los certificados de services.zylk.net no son confiables para la jvm. Para solventarlo basta con ejecutar el siguiente comando desde una terminal

sudo keytool -import -alias services.zylk.net -file Escritorio/services.zylk.net -keystore /usr/lib/jvm/java-6-sun/jre/lib/security/cacert

El cacert por defecto tiene el password "changeit". Dejo aqui el certificado services.zylk.net.

Para poder reconocer el problema es útil usar el siguiente flag de la maquina virtual en maven

-Djavax.net.debug=ssl

Carga avanzada de properties desde java con control de cache y de encoding

2012-02-16T15:39:48Z

En el último mes en varios proyectos hemos tenido que solventar varios problemas relacionados con la carga de properties de idioma o configuracion desde java, las distintas problemáticas era

Cargar un ResourceBundle desde un path de filesystem y no desde el classloader
Cargar properties codificados en UTF8 sin que estos hayan sido pasados por el native2ascii
Gestionar el ciclo de vida de los properties para que estén cacheados pero que se recarguen cada x-tiempo

Buscando alternativas para resolver estos problemas encontré un artículo relacionado con el tema, que ahora no encuentro, en el que se explicaba que en la jdk 1.6 se puede crear un controlador "custom" para la carga de los ResourceBundels, para ello basta con extender la siguiente clase java

ResourceBundle.Control

desde la que precisamente se pueden controlar los tres temas comentados.

A continuación se muestra una implementación de ejemplo que carga los ficheros de filesystem y gestiona el tiempo que cada properties permanece en la cache. También en este link se puede ver el código de carga para el tema del UTF8

Espero que este breve ejemplo os sirva, basta con cambiar las carga habitual del properties de

ResourceBundle.getBundle(name, new Locale("es", "ES"));

a

ResourceBundle.getBundle(name, new Locale("es", "ES"), new ZylkControl());

La ejecución de este ejemplo demuestra que

Los ficheros se cargan directamente de filesystem
Solo se accede a la lectura del fichero si el time-to-live así lo indica

Dejo también el código fuente de la clase de ejemplo linkada en el post

Portlet de sincronizacion flexible y programada de usuarios de LDAP en comunidades de Liferay Portal EE

2012-01-25T10:10:33Z

Durante los últimos dos meses un equipo mixto de zylk y Bilbomatica ha estado desarrollando, conjuntamente con personal de la UPV/EHU (Gabriel Maqueda y Alberto Soto), un portlet para la sincronización de usuarios en las comunidades de Liferay(version 6 EE). El escenario es el de una organización o universidad con miles de usuarios potenciales, administrados y centralizados en un sistema de directorio activo o LDAP corporativo, que necesita asignar de una manera flexible, ágil y programada un conjunto de usuarios en las diferentes comunidades de un portal Liferay.

Los requisitos que se pretendía cubrir eran los siguientes:

Poder delegar en los administradores de las comunidades la sincronización de los usuarios que pertenezcan a las mismas, siendo el origen de la sincronización el LDAP corporativo de la UPV/EHU.
Permitir que los administradores de las comunidades puedan, sin tener conocimientos de la estructura del LDAP ni de la sintaxis de las querys, definir filtros para realizar la sincronización de dichos usuarios
Permitir la planificación de las sincronizaciones con periodicidad variable y seleccionable por el propio administrador de la comunidad.
Enviar informes cada vez que se ejecute una sincronización a una lista de usuarios definidos por el propio administrador.
Traducción al euskera, tanto del interfaz como del asistente para las querys del LDAP, así como del informe resultante tras la sincronización de los usuarios de comunidades.

Nos planteamos primero resolver la duda técnica que teníamos antes de empezar el proyecto

Usar o no el planificador de tareas que Liferay integra, basado en quartz.

La conclusión fue que se podría hacer uso del planificador de tareas de Liferay con su modelo, lo cual permitía no tener que instanciar dos planificadores y que el propio portal sea capaz de gestionar parte de las tareas de manera transparente. Para ello el porltet se desplegó implementando el scheduler de Liferay con una periodicidad diaria y en la implementación del scheduler es donde se realiza la lógica de qué tareas de sincronización se deben ejecutar cada día.

Una vez decidida la arquitectura de la solución procedimos a su implementación. Desde un punto de vista funcional las características del desarrollo son las siguientes:

Altas en comunidad
Bajas en comunidad.
Importar del LDAP

El portlet permite personalizar los informes de la siguiente forma:

Seleccionar el idioma en que se generarán los informes. Los informes se podrán obtener tanto en castellano como en euskera.
Seleccionar el momento preciso en el que se va a realizar el informe o informes dependiendo del modo en que este se configure.
Obtener informes personalizados atendiendo a características y a valores concretos.
Gestionar y añadir destinatarios. Estos destinatarios recibirán los informes a través de su correo electrónico.
Enviar el mismo informe a múltiples destinatarios.
Seleccionar los datos que mostrará el informe.

En cuanto a la gestión de la expresión de LDAP de la cual se obtienen los usuarios que se van a sincronizar, el portlet dispone de un editor, desde donde el administrador de la comunidad puede seleccionar una característica y un valor. Además el usuario dispone de operadores lógicos ( AND, OR & NOT ), para poder realizar expresiones más complejas.
Cada comunidad dispone de una tarea que puede configurar para la sincronización como se muestra en la siguiente imagen:

El portlet está accesible desde el panel de control de cada comunidad, para los usuarios con rol de administrador de la comunidad.

La configuración se realiza desde la siguiente pantalla:

Además se puede definir la query de LDAP que nos devolverá los usuarios que se vayan a sincronizar:

También se pueden gestionar los destinatarios de las notificaciones:

Como temas destacables habría que resaltar:

La gestión de los atributos del LDAP es fácilmente extendible para que se pueda utilizar en un conjunto amplio de estructuras de LDAP. En el caso de la UPV/EHU el LDAP está basado en atributos, pero se podría usar en una estructura jerárquica. En zylk lo hemos probado con nuestro LDAP con resultados satisfactorios.
En una evolución de este desarrollo, se podría ampliar la parte de edición de receptores del informe, de manera que se pudieran añadir nuevos receptores a partir de los usuarios existentes en el portal. Así pues, la selección del idioma del informe se realizaría de manera transparente para el usuario del portlet y a partir de la configuración personal de idioma seleccionada por el usuario.
Se intentó crear un hook para que el portlet se integrara como una nueva acción en el portlet de comunidades pero no funcionó correctamente, así que se descartó esa posibilidad. Nos faltó mirar los listas blancas de portlets que se pueden añadir en tiempo de ejecución para ver si esa opción era viable.

ubuntu 10.04 LTS y algunos problemas con los applets

2012-01-16T09:05:46Z

Lunes por la mañana y no se que ha pasado pero en el firefox de mi ubuntu, y en el de todos los de la empresa (usamos la 10.04 LTS), los applets han dejado de funciona. No he encontrado mucha información al respecto por internet pero he lincado a mano la librería y parece que todo vuelve a funcionar correctamente. Lo dejo aqui escrito por si puede servir a alguien más.

ln -s /usr/lib/jvm/java-6-sun/jre/lib/i386/libnpjp2.so $HOME/.mozilla/plugins/libnpjp2.so

Algo tiene que ver con el plugin de java (sun-java6-plugin) porque usando el icedTea los applets funciona, el problema es que el icedTea usa una implementación de java que no es la de sun y en algunos temas de firma no funciona todo lo bien que me gustaría...

Seguiré investigando un poco más sobre el tema durante la semana, pero justo hoy necesitaba que los applets funcionaran para poder seguir con un proyecto, así que temporalmente me voy a quedar con la solución del link manual...

Desarrollando aplicaciones J2EE sobre Alfresco III - campos tipo datetime

2012-01-13T10:38:40Z

Además de las particularidades sorteadas durante el desarrollo bajo Alfresco Community 3.4d, un curioso problema con el que nos encontramos fue el uso del tipo CMIS 'd:datetime'.

Por defecto, el analizador de tipo 'datetime' para Lucene de Alfresco tiene una implementación en donde sólo se contempla el 'date', dejando a un lado el 'time'. Como consecuencia de esto, las búsquedas 'ORDER BY cmis:creationDate' no conseguían resultados reales.

En la wiki nos recomiendan configurar un analizador tipo Datetime

				#d_dictionary.datatype.d_datetime.analyzer=org.alfresco.repo.search.impl.lucene.analysis.DateAnalyser
d_dictionary.datatype.d_datetime.analyzer=org.alfresco.repo.search.impl.lucene.analysis.DateTimeAnalyser

Tras reconstruir los índices todo funciona como debería. Lamentablemente, tener este tipo de analizador nos modificó el comportamiento de las búsquedas por fecha, no permitiendo encontrar objetos mediante el uso de predicados CMIS-SQL tipo:

				SELECT * FROM eu:registro WHERE cmis:creationDate > '2011-01-10T09:09:55.965Z'

SELECT * FROM eu:registro WHERE cmis:creationDate > '2011-01-10T09:09:55.965Z' 
AND cmis:creationDate < '2011-01-12T09:09:55.965Z'

SELECT * FROM eu:registro WHERE cmis:creationDate>TIMESTAMP'2010-09-23T16:56:49.925+02:00'

Tras probar varias sugerencias leídas en la comunidad Alfresco [1] [2] [3] y no conseguir solución decidimos cambiar de estrategia.

Decidimos abandonar el uso del tipo 'd:datetime' a favor de 'd:long' para almacenar las fecha como TimeMiliseconds desde la fecha base de un calendario J2EE , denominado época (1 January 1970 00:00:00 GMT)

				<property name="eu:FechaInicioTimeMiliSeconds">
    <title>Fecha de inicio miliseconds</title>
    <type>d:long</type>
</property>

				metadatos.put(
  METADATA_FECHA_REGISTRO_MILISECONDS,
  Formatters.convertTimeToMiliseconds(io.getFechaRegistro())
);

Y ya lo tendríamos todo casi solucionado, si no fuera porque en la implementación CMIS de Alfresco el tipo d:long de CMIS no se interpretaba como tal, si no como un entero tipo d:integer que al intentar recibir un 'timemiliseconds' nos generaba la excepción.

				Caused by: java.lang.NumberFormatException: For input string: "1320361200000"
    at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
    at java.lang.Integer.parseInt(Integer.java:461)

Con un cambio de 'd:long' a 'd:string' todo solucionado!

Usando hadoop para intercambio masivo de ficheros en un contexto de big data

2012-01-05T11:30:16Z

Durante los últimos tres meses en zylk hemos estado desarrollando, conjuntamente con personal de EJIE (Oscar Guadilla en la definición de la arquitectura y gestión del proyecto, Carlos Gonzalez de Zarate y Roberto Tajada en la parte de platea integración y Juan Uralde en la parte de xlnets) , una aplicación horizontal para el intercambio temporal de ficheros. La problemática que se quería resolver era la siguiente:

Disponer de un sistema para que las distintas aplicaciones, situadas en los distintos entornos (extra, intra, inter etc..), pudieran intercambiar ficheros.
Disponer de un sistema de trazas/auditoria, consultable en tiempo real capaz de almacenar la información de millones de transacciones.
Disponer de un sistema de eventos que permitiera la comunicación asíncrona entre las distintas aplicaciones (en lo que a intercambio de ficheros hace referencia)
Disponer de una librería de cliente, para navegadores, que mejorara la experiencia de usuario a la hora de gestionar ficheros en aplicaciones web.
Disponer de un API java que sirviera tanto para jdk 1.4, como para jdk 1.5+
Disponer de un API batch.
Disponer de un API WebService

El proyecto se dividió en dos partes.

Una primera en la que se hicieron las pruebas pertinentes para seleccionar las tecnologías y los patrones necesarios para el desarrollo. (Tres semanas de trabajo)
Una segunda en la que se realizó la implementación de la solución y se depuraron todos los aspectos que no se habían tenido en cuenta en la fase de análisis/pruebas (Nueve semanas de trabajo)

A continuación se muestra un gráfico de los distintos componentes que conforman las solución.

Y los distintos métodos que se pensaba crear y exponer en cada canal. Como eje principal de la solución se optó por usar hdfs (hadoop distributed file system1).
La idea original era crear una API java recubriendo el API original de hadoop para exponer los siguientes métodos:

move
info
copy
list
put
get

La primera pega que nos encontramos fue que el API de HADOOP solo se puede ejecutar con java 1.5+ lo que nos obligó a crear un nuevo canal de comunicación para exponer el API java 1.4. Para ello expusimos los métodos por medio de un API REST y creamos un cliente compatible con java 1.4 para dichos métodos. Tanto el API para java 1.4 como el de 1.5 se instancian usando una factoría abstracta que permite cambiar del API 1.4 al API 1.5 con tan solo cambiar las implementaciones ya que creemos que en un futuro próximo todas las aplicaciones correrán con java 1.5+
A continuación mostramos un diagrama de como se han creado las implementaciones y las interfaces relacionadas con el proyecto.

Una vez tuvimos el core creado y consensuado nos centramos en el resto de las partes, a saber

Sistema de trazas.
Eventos (platea integración).
API WS.
Widget para upload.

A continuación presentamos un gráfico que resume todos los canales de comunicación entre los distintos APIs y componentes.

Donde se pude ver que al core se le han añadido las funcionalidades de trazas, metadatos y seguridad basada en xlnets.

Para el sistema de trazas se han utilizado colas JMS con un MDB que publica los mensajes en una base de datos noSQL como mongo-db. Se optó por esta solución porque después de hacer pruebas de rendimiento se conseguían un rendimiento entre 5-10 veces superior que en tablas relacionales. Hay que decir de todas formas que en este caso el concepto de noSQL encajaba a la perfección con el problema que se quería solventar al igual que los conceptos de listas finitas, orden natural inverso etc..

Para la parte de metadatos se ha optado por almacenar los mismos serializados en json en el propio hadoop, por un tema de auto-consistencia del filesystem. Aunque creemos que a esta parte habría que darle todavía una vuelta más e ir a un modelo de tablón basado en HBASE, por ejemplo. Si se hiciera esto se estudiaría también la posibilidad de cambiar el sistema de trazas a HBASE también.

Para el componente de upload se ha usado SWFUPLOAD, ya que se intentó usar los blobs de javascript que permiten no usar flash, pero internet-explorer en su versión 8 no los implementa todavía. Hay que destacar que para poder usar SWFUPLOAD en un entorno seguro que use las cookies para mantener la sesión hay que sortear unos pequeños problemas de flash con las cookies … pero eso es otra historia.

Para la parte de seguridad, simplemente se han usado las librerías de xlnets.

Para la parte de eventos se uso platea integración.

Otra de las partes que se usó, fue el map-and-reduce para el expurgo de ficheros, para lo que hadoop evidentemente nos sirvió.

Creo que esto es más o menos todo, la verdad es que la solución final es bastante potente y creemos que puede evolucionar satisfactoriamente y cubrir las necesidades para las que se ha diseñado.

Desarrollando aplicaciones J2EE sobre Alfresco II - pequeños consejos

2012-01-02T12:19:00Z

Siguiendo el post de básicos para el desarrollo de aplicaciones J2EE sobre Alfresco, os dejamos una lista de pequeños consejos para el desarrollo con Alfresco, y en concreto para búsquedas con OpenCMIS.

Búsquedas con OpenCMIS

Para realizar las búsquedas, podemos seguir el consejo que os dimos en el post de básicos de Alfresco y usar la utilidad QueryStatement que nos ofrece la librería de OpenCMIS, o podéis construirlas a mano.

Comparadores CMIS-SQL

Si se requiere el uso de comparaciones case-sensitive, hacer uso del predicado CONTAINS() de CMIS-SQL para establecer cláusulas Full Text Search, en vez de el comparador básico provisto por CMIS-SQL =' '. Ejemplo:

								SELECT * FROM eu:registro as r join cm:titled as t on r.cmis:objectId=t.cmis:objectId 
join cmis:folder as f on r.cmis:objectId = f.cmis:objectId 
WHERE CONTAINS(t,'cm:title:\'*convenio*\'') 
ORDER BY r.cmis:lastModificationDate DESC

Para las búsquedas de campos marcados como constraints, el predicado '=' de CMIS-SQL funciona como si utilizáramos el predicado LIKE. Es por eso que por ejemplo; buscando

								SELECT eu:EstadoArchivo FROM eu:registro  WHERE eu:EstadoArchivo='Expedientar'

Bajo el modelo

								<property name="eu:EstadoArchivo">
	<title>Estado Archivo</title>
	<type>d:text</type>
	<constraints>
		<constraint ref="eu:listaEstadosArchivo" />
	</constraints>
</property>

<constraint name="eu:listaEstadosArchivo" type="LIST">
	<parameter name="allowedValues">
		<list>
			<value>Pendiente revisar</value>
			<value>Expedientar</value>
			<value>No expedientar</value>
		</list>
	</parameter>
</constraint

Se encuentran tanto los valores de 'Expedientar' como 'No expedientar'.

En nuestro caso arreglamos el problema cambiando el valor de 'Expedientar' por 'Si expedientar'

						SELECT eu:EstadoArchivo FROM eu:registro WHERE eu:EstadoArchivo='Sí Expedientar'

Uso del predicado IN_TREE

Para agilizar las búsquedas, el uso del predicado IN_TREE resulta de gran ayuda, ya que nos asegura buscar objetos dentro del árbol de un nodo determinado. Ejemplo:

						SELECT * FROM eu:registro as r 
join cm:titled as t on r.cmis:objectId=t.cmis:objectId 
join cmis:folder as f on r.cmis:objectId = f.cmis:objectId 
WHERE IN_TREE(f, 'workspace://SpacesStore/8d18d03a-8fe6-4ede-bfcd-5f6435d78b9e') ORDER 
BY r.cmis:lastModificationDate DESC

Métodos de paginación

La interfaz ItemIterable que nos ofrece OpenCMIS nos da todo lo necesario para realizar una paginación en servidor, gracias al los métodos skipTo(posición) y getPage().

Con esto la búsqueda paginada nos quedaría algo tal que

					public ItemIterable<QueryResult> doQuery(String query, int delta, int page) {		

log.trace("doQuery | delta: " + delta + " | page: " + page);
Session session = this.getSession(this.username);

OperationContext contexto = session.createOperationContext();

if (delta != -1){
  contexto.setMaxItemsPerPage(delta);
}
		
log.debug("doQuery | " + query);
ItemIterable<QueryResult> results = session.query(query, false, contexto);
log.trace("doQuery | nº resultados: " + results.getTotalNumItems());

if (page > 1){
  log.trace("skip to " + (page*delta-delta));
  results = results.skipTo(page*delta-delta);
}
  return results.getPage();
}

Otros consejos

Uso de caracteres especiales

A la hora de crear ficheros / directorios en Alfresco, es conveniente recordar que existen ciertos caracteres que no son válidos. Sin embargo, es útil saber que no tenemos porqué deshacernos del nombre original de lo que queremos guardar (a pesar de que incluya alguno de estos caracteres), ya que podemos hacer uso del metadato 'Title', para insertar estos caracteres, y luego recuperarlos desde nuestra aplicación.

Construir URLs para edición online y acceso a CIFS en Alfresco

2011-12-26T10:17:50Z

En un post anterior hemos visto como podíamos editar documentos de office y openoffice online con una url de tipo dav://. Para construir esas urls y mostrarlas en la vista del repositorio en Alfresco Share hemos modificado los ficheros:

$ALF_HOME$/tomcat/webapps/share/components/documentlibrary/repo-documentlist.js
$ALF_HOME$/tomcat/webapps/share/components/documentlibrary/repo-documentlist-min.js

Para los documentos, hemos de filtrar previamente para que sólo sea visible para documentos de tipo office u openoffice:

var webdavPath = "dav://" + window.location.host + "/alfresco"+ record.webdavUrl;

/**
* Url WebDav para Edición Online
**/

//Comprobar que el documento (record) sea del mimetype especifico

desc += '<div class="detail">';
desc += '<span class="url"><em>Editar online: </em><a href="'+webdavPath+'">';
desc += '<img src="http://www.zylk.net/alfresco/images/icons/edit_online.gif" style="border-width:0px; padding-left:3px;" alt="Editar online"></a></span>';
desc += '</div>';

Resultado en Share:

Además, otra opción para la edición online es mostrar la url de CIFS en los detalles de las carpetas:

var cifsPath = "smb://WORKGROUP;"+Alfresco.constants.USERNAME+"@"+window.location.host+"/alfresco"+encodeURIComponent($combine(locn.path, locn.file)).replace(/%2F/g,"/");

if (type == "folder"){

....

desc += '<div class="detail">';
desc += '<span class="url"><a href="'+cifsPath+'">Ver en CIFS</a></span>';
desc += '</div>';

}

Resultado:

Desarrollando aplicaciones J2EE sobre Alfresco I - los básicos

2012-01-02T10:35:59Z

Si estáis pensando en empezar una aplicación J2EE sobre Alfresco, os dejamos unos cuantos consejos e ideas que hemos adoptado en un recién finalizado proyecto.

OpenCMIS y para todo lo demás Webscripts

Tomamos la determinación de que intentaríamos adaptarnos a lo que CMIS nos diera (OpenCMIS para Java , en nuestro caso v0.4) , y que para aquellas partes que no se pudieran cubrir con la implementación del estándar, desarrollaríamos servicios personalizados mediante webscripts.

Con el proyecto finalizado, la implementación CMIS de Alfresco junto con OpenCMIS nos ha provisto de todo lo necesario para nuestro desarrollo con las siguientes pequeñas excepciones en forma de webscript:
- Notificaciones Email; Webscript para la generación de notificaciones vía email dada cierta casuística, debido a que el sistemas de reglas y acciones para el envío de notificaciones proporcionada por Alfresco desde su interfaz no se ajustaba a nuestras necesidades.
- Categorías; Obtención de las subcategorías que pertenezcan a las categorías establecidas en el modelo de desarrollo.
- Asociaciones; Con la versión 0.4 de OpenCMIS no pudimos hacer gran cosa a la hora de trabajar con asociaciones. Aunque el establecimiento de estas sí fue posible, no pudimos realizar búsquedas sobre estos campos, por lo que acabamos adoptando la medida de crear un webscript para relacionar objetos tipo folder ↔ folder y folder ↔ person.
Herramientas para el desarrollo de webscripts
- Consola Javascript
  
  Las ventajas de usar la consola ya lo hemos comentado en previas entradas.
  
  Si como nosotros, tenéis la necesidad de crear webscripts, la consola Javascript de Alfresco Share os permitirá probar la parte servidora de Javascript.
- Eclipse Freemarker plugin
  - Crear plantillas Freemarker puede resultar cansino si no se tiene una forma de validar la sintaxis básica. Es por ello que el freemarker.jar del plugin JBoss Tools Project os será de gran utilidad. Contiene syntax-highlight, así como autocompletado de su API.
    
    En nuestro caso lo instalamos desde el Marketplace de Eclipse sin problemas.
Uso de paquetería OpenCMIS

Antes de empezar el proyecto es conveniente conocer la paquetería que tenemos a nuestra disposición, para así evitar trabajo de más. En nuestro caso, encontramos de utilidad los siguientes objetos:
- PropertyIds; Listado de propiedades de objetos OpenCMIS (cmis:name, cmis:objectId, cmis:createdBy…)
- Interfaz CmisObjectProperties con los métodos básicos de objetos OpenCMIS (getName(), getProperties(), getProperty(String), getCreatedBy(), getId(), …)
- Uso de QueryStatements; El hermano de los PreparedStatements de JDBC http://chemistry.apache.org/java/0.5.0/maven/apidocs/org/apache/chemistry/opencmis/client/api/QueryStatement.html
CMIS Workbench

Un amigo necesario para entender cómo se almacena la información bajo CMIS y realizar búsquedas mediante CMIS-SQL.

Si vosotros también tenéis vuestros 'básicos', compartirlos con nosotros ;)

Feliz navidad y prospero 2012

2011-12-24T10:29:05Z

¡Desde el equipo de zylk.net os deseamos que paséis unas felices fiestas!

Zylkeko lantaldetik gabon zoriontsuak opa dizkizuegu!

P.S: Gracias Silvia por la composición

Edicion online de documentos de Office y Openoffice en Alfresco via webdav

2011-12-19T07:13:02Z

Una de las funcionalidades más deseadas en Alfresco y en todo gestor documental es la denominada edición online de documentos desde su interfaz web. Esto es la posibilidad de abrir, editar y guardar un documento de office desde Alfresco Share sin la descarga y el guardado local del mismo. Esta funcionalidad la hemos implementado en zylk.net a través del stack Alfresco + Firefox + OpenOffice mediante la definición y asignación de OpenOffice como cliente de webdav a ciertos enlaces creados en la interfaz de Alfresco Share. Estos enlaces son del tipo dav:// y los hemos generado en las vistas del navegador de documentos y carpetas para los archivos con extensión de OpenOffice y M$ Office, tal que así:

Desde Firefox podemos asociar un protocolo a una aplicación externa en about:config

http://kb.mozillazine.org/Register_protocol#Firefox_versions_up_to_3.0

network.protocol-handler.app.dav --> /usr/bin/soffice
network.protocol-handler.external.dav --> true
network.protocol-handler.expose-all --> true

Esto permite abrir directamente OpenOffice y editar el documento pinchando en el link creado. Otra opción para abrir esos enlaces es usar extensiones de Firefox como launchy:

http://gemal.dk/mozilla/launchy.html

con una configuracion de launchy.xml similar a esta:

<?xml version="1.0" encoding="UTF-8"?>
<configurations xmlns="http://launchy.mozdev.org/configurations">
<application>
    <label>OpenOffice as Browser</label>
    <type>1</type>
    <command>/usr/bin/soffice</command>
</application>

<application>
    <label>OpenOffice as Media Client</label>
    <type>3</type>
    <command>/usr/bin/soffice</command>
</application>
</configurations>

De este modo, podemos implementar la edición online en Alfresco Share fácilmente, y con el administrador de contraseñas de OpenOffice sólo nos autenticaremos al pinchar en el enlace tipo dav al abrir el primer documento por primera vez. El guardado en el servidor Alfresco se llevará a cabo directamente desde OpenOffice.

Por otro lado, a las carpetas les podemos crear unos links tipo smb:// y que lo abra un programa como nautilus en Linux, con lo que si nuestro servidor tiene activo el protocolo CIFS de unidad compartida, podremos acceder directamente a una unidad compartida desde Alfresco Share.

La modificación de las vistas de navegación de documentos y archivos creando los links se realiza en repo-documentlist.js para lo cual, lo más indicado es desplegar un jar en shared/lib con el archivo javascript correspondiente de manera que no sustituyamos el archivo original por debajo de la ruta WEB-INF de Alfresco. Una prueba de concepto sencilla de todo esto es crear un enlace tipo dav y smb en los enlaces de un Sitio de Share a documentos y carpetas, y comprobar que OpenOffice es capaz de abrir directamente esos enlaces, guardando los cambios en el servidor (una vez configurado Firefox).

Subsistemas de autenticacion extendidos en Alfresco, LDAP compatible con CIFS

2011-12-09T16:44:56Z

En la terminología de Alfresco, un susbsistema es un módulo configurable y responsable de una subparte de la funcionalidad de Alfresco, lo cual engloba áreas funcionales como los servidores de ficheros, la autenticación, la sincronización o la replicación. Están disponibles como core del producto desde la version 3.2 del producto y cada subsistema puede iniciarse, pararse (via JMX por ejemplo) y configurarse independientemente con su configuración aislada en su contexto de Spring.

Las diferentes categorías y tipos de subsistemas por defecto se pueden consultar en:

$ALF_PATH/tomcat/webapps/alfresco/WEB-INF/classes/alfresco/subsystems/<category>/<type>

en donde generalmente se definen el fichero de contexto de Spring y sus correspondientes archivos de properties.

Una categoría importante de subsistemas son aquellos que se refieren a la autenticación, como stack de componentes de la cadena de autenticación del servidor Alfresco. Alfresco ofrece numerosas alternativas por defecto, que comentaremos a continuación,

alfrescoNtlm: Autenticación nativa de Alfresco
ldap: Autenticación y exportación de usuarios via protocolo LDAP (e.g. OpenLDAP)
ldap-ad: Autenticación y exportación de usuarios desde un Active Directoy via protocolo LDAP
passthru: Autenticación a través de un servidor de dominio de Windows
kerberos: Autenticación via Kerberos Realm
external: Autenticación via un sistema de SSO (e.g. CAS)

con las cuales uno puede configurar un cadena de autenticación a medida para los usuarios de una organización.

Hay que tener en cuenta, que la exportación de los usuarios sólo es posible a través de los subsistemas ldap y ldap-ad, que el protocolo CIFS únicamente se soporta con los subsistemas alfrescoNtlm, passthru y kerberos, y que el SSO de usuarios está disponible a través de kerberos, passthu y external.

Esto implica en la práctica considerar diferentes cadenas de autenticación en el alfresco-global.properties para contemplar un escenario como este:

Los usuarios nativos de Alfresco y usuarios de Windows podrán loguearse, con preferencia los usuarios de Windows.
El servidor de dominio de Windows además gestionará la autenticación en unidades de red compartidas via CIFS directamente
El LDAP de directorio activo se utilizará para sincronizar usuarios y grupos
Tendremos un SSO de credenciales de red (NTLM v.1) con los usuarios del dominio, con lo cual los usuarios de Windows no necesitarán loguearse en Alfresco, si sus navegadores marcan el servidor como sitio de confianza.

chain.authentication=alfrescoNtlm1:alfrescoNtlm,passthru1:passthru,ldap1:ldap-ad

donde hay propiedades específicas como:

alfrescoNtlm1
    ntlm.authentication.sso.enabled=false
    alfresco.authentication.authenticateCIFS=false
passthru1
    ntlm.authentication.sso.enabled=true
    passthru.authentication.authenticateCIFS=true
ldap1
    ldap.authentication.active=false
    ldap.synchronization.active=true

Además, existen otras situaciones, como utilizar un sistema externo de SSO, como CAS, o bien conectarse a varios servidores LDAP o servidores de directorio, por ejemplo, para contemplar a los usuarios externos de una organización (y no incluirlos en el directorio corporativo).

En nuestro caso particular, tenemos un servidor OpenLDAP con el que trabajamos en zylk.net y una de las problemáticas encontradas es que no podemos utilizar por defecto, unidades CIFS/SAMBA para acceder a los documentos corporativos de nuestro gestor documental Alfresco. Esto lo hemos solventado, extendiendo un subsistema de autenticación ldapSamba que permite validar a nuestros usuarios del LDAP via CIFS, con un atributo de nuestro LDAP. La clave de la validación de un subsistema de autenticación con CIFS, es que la password original debe estar codificada con MD4 (UTF16LE), y esto es posible guardarlo en un esquema de usuarios Samba para LDAP. De este modo, una vez implementado el subsistema, empaquetado en su jar correspondiente y desplegado el directorio lib de Alfresco, en el alfresco-global.properties tendremos:

#
# Chain Authentication
#

authentication.chain=alfrescoNtlm1:alfrescoNtlm,ldap1:ldap,ldapSamba1:ldapSamba

Y su correspondiente configuración en el directorio extension de shared:

zylk@alf:/opt/alfresco34/tomcat/shared/classes/alfresco/extension/subsystems$ tree
. └── Authentication     ├── jdbc     │   └── myjdbc     │       ├── jdbc-authentication-context.xml     │       └── jdbc-authentication.properties     └── ldapSamba         └── ldapSamba1             ├── ldap-samba-account-authentication-context.xml             └── ldap-samba-account-authentication.properties

donde definimos el archivo de contexto del subsistema y sus propiedades

ldap.samba.authentication.java.naming.provider.url=ldap://ldap-alf.zylk.net:389
ldap.samba.authentication.base=dc=zylk,dc=net
ldap.samba.authentication.userbase=ou=People
ldap.samba.java.naming.security.principal=cn=administrator,dc=zylk,dc=net
ldap.samba.java.naming.security.credentials=secret
ldap.samba.authentication.authenticateCIFS=true
ldap.samba.authentication.allowGuestLogin=false

No dejo aquí detalles del código fuente del subsistema, que dejaremos para otra ocasión, pero aprovecho para comentar otro de los subsistemas de autenticación que hemos implementado recientemente. Este subsistema permite autenticar a los usuarios de Alfresco contra una tabla de usuarios a medida de un esquema de base de datos via JDBC, lo que es tremendamente util, porque nos permite integrar fácilmente los usuarios de Alfresco con cualquier aplicación de terceros que se autentique contra una base de datos relacional, y que por ejemplo quiera integrarse con Alfresco via repositorio CMIS. Lo comentaremos en un próximo artículo.

Enlaces:

La consola Javascript de Alfresco Share

2011-11-27T16:14:04Z

La consola de Javascript de Alfresco Share conforma una herramienta precisa y eficaz, no sólo para desarrolladores de aplicaciones y servicios via API Javascript y webscripts de Alfresco Share, sino para otro tipo de tareas de mantenimiento de sistema, proporcionando una potente shell con acceso a la información de nuestra instancia de Alfresco via Javascript API.

La ultima versión de la consola de Javascript disponible en el paquete Share Extras permite además el acceso a los métodos de los principales objetos mediante la combinación de Ctrl+Space. Esta empaquetada en un simple jar que se añade al directorio tomcat/shared/lib de la instancia de alfresco.

A continuación muestro algunos ejemplos sencillos que pueden ser interesantes en el contexto de una migración entre instancias de Alfresco y que implementan busquedas en el repositorio.

El primer ejemplo permite exportar las categorias de una instancia a un CSV (para hacer una carga posterior en otra instancia de Alfresco via javascript API tambien):

var nodes = search.luceneSearch("PATH:\"cm:generalclassifiable//*\"");

for each(n in nodes) {
print(n.nodeRef + ";" + n.displayPath + '/' +n.name);
}

También es posible facilmente exportar los usuarios a un CSV, que es interesante en el contexto de una migración de una instancia de Alfresco a otra, utilizando el componente de importación de usuarios CSV de Share:

var nodes = search.luceneSearch("TYPE:\"cm:person\"");

for each(n in nodes) {
print(n.name+';'+n.properties["userName"]+';'+n.properties["email"]);
}

Para esto también hay otros procedimientos:

http://code.google.com/p/share-import-export/
https://forums.alfresco.com/en/viewtopic.php?f=9&t=18732

Otra tarea similar atiende a los grupos de usuarios:

var nodes = search.xpathSearch("/sys:system/sys:authorities/*");

for each(n in nodes) {
var aux = n.children;
var users = ""
for each(m in aux) {
users = users + m.properties["userName"] + ","
}
users = users.substr(0,users.length-1);
print(n.properties["authorityName"]+";"+users+";"+n.nodeRef)
}

Para extraer las referencias de los nodos de los documentos del repositorio se pueden invocar funciones recursivas como:

recurse(space, function(node) {
if (node.type != "{http://www.alfresco.org/model/content/1.0}folder"){
print(node.nodeRef+";"+node.displayPath + "/" + node.name);
}
});

que se pueden utilizar para reports de permisos como se hace en:

http://www.techbits.de/2011/11/06/using-the-javascript-console-permission-reporting/

o para precargar una estructura de objetos documentales:

http://www.techbits.de/2011/10/18/using-the-javascript-console-creating-and-populating-datalists/

Enlaces:

http://wiki.alfresco.com/wiki/3.4_JavaScript_API
http://code.google.com/p/share-extras/wiki/JavascriptConsole