zylk.net

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

Nace sinadura servicios de firma digital

2011-09-05T16:46:40Z

Nace el proyecto sinadura, un software promovido por la asociación ESLE y financiado dentro del programa KZ Lankidetza de SPRI. Es un proyecto licenciado GPL y que permite firmar pdfs en entornos multiplataforma.

Migrando contenidos de Sharepoint a Alfresco

2011-10-26T17:12:40Z

El otro día caía en el blog de Yerbabuena en un post sobre las "5 razones para no usar Sharepoint 2010" y me encontraba en una problemática de proyecto relacionada con este producto de Microsoft. Recordé una presentación/workshop del noviembre pasado en el Círculo de Empresarios de Bizkaia (CEBEK), y en donde presentamos una matriz comparativa entre Alfresco y Sharepoint junto con otra empresa (partner de Microsoft) en un coloquio de soluciones de gestión documental. No añadiré más razones que las expuestas por los chicos de Yerbabuena: seguridad, precio, interoperabilidad, escalabilidad y comunidad, sino unas notas sobre una experiencia personal en un proyecto reciente en relación a los puntos comentados.

En mi opinión, una de las principales contras que tiene una implantación de Sharepoint en cuanto a la escalabilidad se refiere es que únicamente en la versión 2010 y con las licencias más caras, se pueden alojar los datos en un filesystem en vez de en la base de datos (SQL Server). Esto es un ** must ** en un gestor documental empresarial que se precie, o de cualquier aplicación que guarde documentos, porque el rendimiento de la base de datos cuando el repositorio es muy grande puede ser realmente malo (pensad en un repositorio de teras de información y en una base de datos SQL Server con ese tamaño, y con una concurrencia seria de usuarios accediendo a ese servidor).

En mi caso concreto, estaba utilizando Sharepoint 2003 y pretendía extraer una copia del repositorio, para migrarlo a Alfresco ECM. Finalmente encontre un código C# que permite hacer esta tarea SPIEFolder (desde el servidor), y que es conocido en el mundillo de Sharepoint (hay también versiones diferentes del conector para 2007 y 2010). De esa manera descargué la estructura de documentos via Webdav a Alfresco. Pero es que resulta difícil, una tarea tan sencilla como un backup incremental de ficheros o un simple y llano ("copiame por favor en un cd los documentos de mis oficinas colaborativas"). Esto es un ejemplo típico de lo que ocurre con un producto cerrado, que si que es verdad que hay ciertos servicios web (contados), ciertas API's expuestas para interaccionar (en su stack), pero resulta en general difícil y tedioso hacer cualquier cosa. Si es cierto, que Microsoft esta involucrado en el estándar CMIS, y que recientemente también tengo noticias de un conector SQL Server para Linux. En Alfresco por ejemplo, la carga de documentos se realizó utilizando el repositorio como unidad compartida Webdav (que es un protocolo estándar). Pero se podía haber hecho también a través de otros canales estándar como FTP o CIFS, desde módulos de Alfresco especializados para cargas masivas, o desde programación con REST, Web Services y CMIS. En el caso de las API's, la diferencia estriba en estas son mucho más completas, y exponen gran parte del core, además de extensibles proporcionando de más libertad y flexibilidad al desarrollador. Y por esta razón, un producto de software libre va a proporcionar muchísima mas interoperabilidad que otros productos privativos, incluso más que Sharepoint con otros productos de Microsoft.

Otros problemas de la migración derivaron de obtener los usuarios y permisos de las oficinas colaborativas, y en este caso tuvimos que atacar directamente a la base de datos de Sharepoint para via ACP's generar un mapeo de permisos de directorio para Alfresco con los usuarios y roles correspondientes. También se podía haber orientado via Webscript creando un servicio para cada site de Sharepoint, pero finalmente nos decantamos por crear la estructura de carpetas y permisos via ACP, para hacer posteriormente la carga de datos via Webdav. En el caso de los usuarios , teníamos dos conjuntos en Sharepoint, los internos, que se migraron configurando el directorio activo de Windows como subsistema de autenticación de Alfresco (Sharepoint se autenticaba contra el AD), y los usuarios externos, que se gestionaban en el propio Sharepoint y se migraron a otro servidor de directorio LDAP externo.

Enlaces:

http://blog.yerbabuena.es/2011/03/5-razones-para-no-usar-sharepoint-2010.html
http://blog.krichie.com/2011/06/02/spiefolder-for-sharepoint-2010/
http://blog.krichie.com/2011/08/26/spiefolder-for-sharepoint-20072010/

normalizando nombres en java

2011-10-24T16:24:21Z

Un problema típico en los programas que gestionan uploads/downloads de ficheros es el nombre del fichero que los usuarios dan a los ficheros. Es decir, existe la no muy buena costumbre, entre los usuarios de windows y mac principalmente, de usar nombres de ficheros con tíldes espacios en blanco etc... que suele originar problemas a la hora de almacenarlos en los filesystems ya que la codificación en bytes de algunos caracteres en los distintos encodings no es la misma. Es decir no se codifica de la misma manera en UTF-8 que en ISO-8859-1. Por tanto suele ser una buena práctica normalizar esos nombres sustituyendo las tildes por sus equivalente sin tilde y las ñ por n. Además también es una buena idea evitar los espacios en blanco para que las urls no tengan la pinta de %20% etc... En java para realizar esa tarea se puede hacer uso de una expresión regular y de un Normalizador de texto. El código es el siguiente:

private static String normalizador(String str)
{
return Normalizer.normalize(str, Normalizer.Form.NFD).replaceAll("\\p{InCombiningDiacriticalMarks}+", "").replaceAll(" ", "+");
}

Que dado un string como "camión con Ñ" devuelve camion+con+n. Este método es preferible al tipico replaceAll("é","e").replaceAll("á","a") etc.. ya que además de servir para otros idiomas evita la problematica de que en el código fuente é está codificada en un encódigo concreto que puede hace que el replaceAll no haga nada.

Dejo el link de un artículo interesante relacionado con el tema, http://www.rgagnon.com/javadetails/java-0456.html

Conferencia Firma e identidad digital con Sinadura Suite en el proximo Libre software world conference

2011-10-20T11:39:38Z

Los próximos 9 y 10 de Noviembre zylk.net presentará Firma e identidad digital con Sinadura Suite en el libre software world conference de Zaragoza.

La ponencia pretende ofrecer una visión general de la firma digital en entornos de software libre concretamente en sistemas operativos GNU/Linux.

Una herramienta en la toma de decisiones por votaciones y actas.

Un repositorio donde almacenar las distintas contraseñas que vamos utilizando.

En la Alfresco Community Meetup de Madrid 2011

2011-10-16T15:18:26Z

El pasado martes asistí en Madrid a la Alfresco Community Meetup 2011, una reunión de la comunidad de Alfresco donde tuve la oportunidad de conocer a distintos bloggers, foreros, desarrolladores y empresas que trabajan con el gestor documental Alfresco, y hacernos eco de las distintas novedades de la nueva versión de Alfresco 4.0 Community. Fue una reunión muy especial, donde pusimos cara a mucha de la gente que contribuye en el foro de Alfresco, y a la que en muchos casos sólo conocíamos a través de las firmas de los usuarios, y en algunos casos sólo a través del nick.

Entre los asistentes, por parte de Alfresco, estuvieron Toni de la Fuente y Rui Monteiro. Toni nos hizo una demostración de las nuevas características de la interfaz de Alfresco Share, como el drag and drop de documentos, las mejoras en las vistas de detalle de metadatos, o el visor html5 para los documentos. También nos enseñó un servicio social interesante para publicar desde Alfresco en diversos servicios externos, como blogs (wordpress y typepad), videos (youtube), fotos (flickr)..... y su correspondiente difusión en redes sociales como twitter, facebook o linkedin. Y por ultimo, vimos en acción la nueva aplicación de Alfresco para el iPad.

Os dejo un par de enlaces con esas novedades:

http://wiki.alfresco.com/wiki/Alfresco_Community_4.0.a
http://www.slideshare.net/alfresco/get-ready-for-alfresco-40

En la reunión pudimos discutir (en el sentido inglés de la palabra) sobre diferentes orientaciones en proyectos de gestión documental de los asistentes, aportando en muchos casos un feedback muy positivo y por otro lado necesario en una comunidad de usuarios y desarrolladores. Y tuvimos oportunidad de comentar directamente con Toni y Rui aquellas de las características que anhelamos en nuestras implantaciones de Alfresco, y el tipo proyectos que afrontamos. También hablamos de otras características incluidas en la nueva versión de Alfresco, como el administrador de categorías de Alfresco Share y la gestión de la papelera. O desde el punto de vista de la arquitectura, la posibilidad de externalizar una parte crítica del repositorio como son los índices de Lucene a un servidor externo SOLR.

http://ecmarchitect.com/archives/2011/10/09/1473

Posteriormente Cristina Martín y Patricia Yagüe nos enseñaron sus primeras experiencias de comunidad con un proyecto de google code para implementar una capa de servicios basada en CMIS.

http://code.google.com/p/capa-de-servicios-cmis

Y siguiendo con CMIS, un servidor comento dos de los proyectos de desarrollo con Alfresco como repositorio CMIS y algunas de las problemáticas surgidas y que ya comentaré próximamente en otro post.
- Sinadura ECM: Es un conector de gestión documental para la herramienta de firma digital sinadura, que implementa las principales acciones de descarga, navegación, upload y actualización de documentos en Alfresco ECM, que ya hemos comentado aquí en otras ocasiones.

- Udala ECM: Es una aplicación J2EE que gestiona del ciclo de vida de un registro de entrada/salida y expedientes de un Ayuntamiento y que utiliza Alfresco ECM como backend documental, el cual es consumido como repositorio CMIS. La aplicación incorpora un conjunto de formularios en donde se definen los metadatos y documentos de las carpetas de registros y expedientes, así como un buscador especializado en base a los metadatos personalizados de los tipos registro y expediente.

Como colofón, la parte surrealista como dijo Toni, la puso nuestro encuentro fortuito tras la reunión con los componentes de Muchachada Nui, que de esto de Al fresco saben un rato :)

Os dejo así mismo, un enlace al blog de Cristina donde hay algunas de las fotos del evento.

Abierta al público la versión 3 de Sinadura Desktop

2011-09-30T11:57:55Z

Tras estar casi seis meses a disposición de los miembros de la comunidad de Sinadura, la versión 3 de Sinadura Desktop ha sido abierta al público para su uso.

Estos seis meses han servido para probar la estabilidad de la nueva versión y para recibir propuestas y mejoras. La herramienta cuenta con la suficiente madurez para su apertura pública a todo el mundo.

Sinadura Desktop, junto al proyecto Sinadura en general, ha ido creciendo con el paso del tiempo, esto ha hecho que crezca la demanda tanto de los productos y servicios de Sinadura, como de necesidades de la comunidad. En respuesta a esta demanda y coincidiendo con la publicación de la nueva versión, hemos comenzado un proceso de reestructuración y remodelado del sitio web. Ahora la comunidad tiene más información y herramientas para participar en el proyecto y las empresas e instituciones tienen más recursos enterprise en sus manos. El sitio web y los recursos y herramientas que el mismo ofrece seguirán mejorando según avance el proyecto.

Os animamos, a los que aún no lo hayais hecho, a descargar y probar Sinadura Desktop 3.0, seguiremos recibiendo con agradecimiento informes de posibles bugs y propuestas de mejora o colaboración en el proyecto.

¡Que lo disfrutéis!

Nace Sinadura servicios de firma digital

2011-09-05T16:46:11Z

Nace Sinadura, servicios de firma digital. Para más información visita nuestra web y fíjate en las nuevas secciones como productos y servicios, partners, comunidad...

En breve publicaremos la versión completa 3.0 de Sinadura Desktop y también la de Votos y actas versión 1.0, ambos con su código fuente.

Nodos raiz o rootPaths de unidades compartidas y Alfresco Share

2011-08-04T15:23:35Z

En la raiz del repositorio de Alfresco, en lo que usualmente se denomina Espacio de Empresa (Company Home), se disponen por defecto una serie de directorios esenciales en toda instalación y que con frecuencia los usuarios/clientes no quieren en la aplicación web, o en los clientes de unidad compartida FTP, CIFS o Webdav. Es el caso de los espacios:

Diccionario de datos
Sites
Espacios personales
Espacio personal del invitado

con mencion especial a los dos primeros, ya que su borrado accidental por desconocimiento deriva en numerosos problemas.

Para solventar esta problematica y quitar/ocultar el acceso a estos espacios es común definir unas raices del repositorio por debajo de las cuales se trabajará en el cliente web colaborativo (Alfresco Share), o en los accesos via sistema virtual de ficheros, ya sea CIFS, FTP o Webdav.

Consideremos en adelante que los contenidos se disponen bajo el espacio ACME, por debajo de Espacio de Empresa. En el caso de Alfresco Share, el nodo raiz se configura en el archivo de configuación del directorio de extensiones web (share-config-custom.xml). Ahi podemos definir el root-node:

<config evaluator="string-compare" condition="RepositoryLibrary" replace="true">

<!--

Root nodeRef or xpath expression for top-level folder.

e.g. alfresco://user/home, /app:company_home/st:sites/cm:site1

If using an xpath expression, ensure it is properly ISO9075 encoded here.

-->

<root-node>/app:company_home/cm:ACME</root-node>

Con respecto a esta configuración, es necesario considerar el problema del buscador de Alfresco Share 3.4 cuando se define el root-node, que ya comentamos aquí.

En el caso del Webdav, es necesario definir el rootPath en el web.xml de Alfresco. De esta manera en $ALF_HOME/tomcat/webapps/alfresco/WEB-INF/web.xml

<context-param>

<param-name>rootPath</param-name>

<param-value>/app:company_home/cm:ACME</param-value>

</context-param>

Y en el caso, de los subsistemas de ficheros (fileServer) se puede llevar a cabo esta config mediante un archivo custom-file-servers-context.xml en el directorio extension, en la ruta:

En $ALF_HOME/tomcat/shared/classes/alfresco/extension/subsystems/fileServers/default/default/custom-file-servers-context.xml

<filesystem name="${filesystem.name}">

<store>workspace://SpacesStore</store>

<rootPath>/app:company_home/cm:ACME</rootPath>

Este archivo es una copia modificada del archivo file-servers-context.xml en la ruta de la aplicacion de alfresco. Ahi es posible editar el rootPath y configurar otras cosas interesantes como las acciones de escritorio en CIFS (que usualmente nos piden también que desaparezcan). Tambien es usual como requisito, que solo aparezca el repositorio y no el directorio AVM, con lo cual es necesario comentar el bean correspondiente.

Enlaces:

http://www.zylk.net/web/guest/web-2-0/blog/-/blogs/busquedas-de-tipos-de-contenidos-en-alfresco-share

Creación de contenidos personalizados en Alfresco Share

2011-07-20T08:34:16Z

Alfresco Share presenta en sus ultimas versiones (Community y Enterprise 3.4) importantes mejoras en la definición de formularios de tipos de contenidos, permitiendo definir plantillas personalizadas para los diferentes componentes o definir estilos css. La configuración básica se realiza por un lado en el archivo del esquema del modelo, donde definimos los tipos, aspectos, propiedades, asociaciones y constrains, y por otro, en el archivo de configuración de Alfresco Share, donde se configuran las visualizaciones de los formularios de creación, edición y búsqueda asociadas a los tipos de contenido.

El proceso básico de creación de un tipo de contenido especializado en Alfresco Share, es añadir un documento o carpeta base, y especializar el tipo a uno definido por el usuario. Posteriormente, en un segundo paso, es necesario rellenar sus metadatos. Este proceso en general es más bien poco usable, y se recurre en ocasiones a reglas de contenido que automaticen la especialización del tipo (al menos), en el proceso de creación. En este sentido, sorprende un poco, que en el proceso de subida de documentos o en el de creación de carpetas no se contemplen tipos especializados como se hacia en los wizards de contenido de Alfresco Explorer. Existen un par de workarounds para aliviar estas situaciones.

El primero es definir en un fichero de js las opciones (los diferentes tipos) de un combo con los tipos en el componente de upload de Alfresco Share. Esto se hace en:

$ALF_HOME/tomcat/webapps/share/WEB-INF/classes/alfresco/site-webscripts/org/alfresco/components/upload/flash-upload.get.js

var contentTypes = [
   {
      id: "cm:content",
      value: "cm_content"
   },
    {
      id: "ac:acta",
      value: "ac_acta"
   },
   {
      id: "fac:facturae",
      value: "fac_facturae"
   }
   {
      id: "bug:incidencia",
      value: "bug_incidencia"
   }
    ];

El resultado es el siguiente:

Con esta ligera modificación podemos subir un conjunto de documentos y asignar a cada uno los diferentes tipos documentales, como los definidos en el ejemplo, Acta, Factura o Incidencia. Eso sí, en un paso posterior tendremos que editar los metadatos. El componente de Records Management también modifica un poco el uploader de flash, y añade la posibilidad de definir un tipo seleccionable de un combo desplegable, que se aplica a todos los documentos que se suben a un espacio, y no individualmente como en este caso.

El segundo es a través de tipos de contenido con mimetype editable digamos, como documentos de texto, html o xml. Estos se pueden definir en un archivo de configuracion xml (repo-toolbar.get.config.xml). Para tipos de contenido tipo folder la cosa esta aún peor, ya que tenemos que servirnos en principio de las reglas de contenido. Sin embargo, podemos llegar a utilizar este componente create-content, ignorar el mimetype y asignarle un itemId relativo a nuestro tipo de contenido tipo carpeta. Con la configuración de formularios correcta en share-config-custom.xml el proceso de creación de una carpeta dará paso a un formulario de inserción de metadatos.

De este modo en:

$ALF_HOME/tomcat/webapps/share/WEB-INF/classes/alfresco/site-webscripts/org/alfresco/components/documentlibrary/repo-toolbar.get.config.xml

<toolbar>
   <createContent>
      <content mimetype="text/plain" icon="plain-text" label="menu.create-content.text" />
      <content mimetype="text/html" icon="html" label="menu.create-content.html" />
      <content mimetype="text/xml" icon="xml" label="menu.create-content.xml" />
      <content icon="plain-text" label="Registro E/S" itemid="ud:registro"/>
   </createContent>
   <actionSets>
      <actionSet id="default">
         <action type="action-link" id="onActionCopyTo" label="menu.selected-items.copy" />
         <action type="action-link" id="onActionMoveTo" permission="delete" label="menu.selected-items.move" />
         <action type="action-link" id="onActionDelete" permission="delete" label="menu.selected-items.delete" />
         <action type="action-link" id="onActionAssignWorkflow" asset="document" label="menu.selected-items.assign-workflow" />
      </actionSet>
   </actionSets>
</toolbar>

donde Registro E/S es un tipo de contenido basado en cm:folder

La unica pega es que no esta del todo pensado para eso y una vez creado el formulario, el js de create-content-mgr lo redirige a las propiedades del documento (document-details). Podemos modificar un poco el js para que en cualquiera de los casos se redirija a la pantalla anterior, en vez de a las propiedades y listo. Esto se hace en los archivos:

$ALF_HOME/tomcat/webapps/share/components/create-content$ vim create-content-mgr.js
$ALF_HOME/tomcat/webapps/share/components/create-content$ vim create-content-mgr-min.js

//window.location.href = $siteURL("document-details?nodeRef=" + nodeRef.toString());
history.go(-1);

Enlaces:

http://loftux.com/2010/03/22/set-the-document-type-on-file-upload/
http://www.iptech-offshore.net/blog/2010/06/15/alfresco-share-tip-content-type-selection-when-uploading-a-document/