How to avoid indexing full content in Alfresco

To avoid indexing full content in Alfresco, we have different aproximations:
 
1. From SOLR point of view (tested in SOLR 1.4 and Alfresco 4.2.5): 
 
In solrcore.properties (for workspace and archive store) set: 
 
alfresco.index.transformContent=false 
alfresco.ignore.datatype.1=d:content 
 
This is a general setup (for all content types).
 
2. From Filesystem Bulk Import and/or CMIS APIs point of view: 
 
Add aspect cm:indexControl and use cm:isIndexed=true, and cm:isContentIndexed=false in your XMLs for Bulk import. In APIs, use addAspect and set the corresponding properties. 
 
This is highly customizable, for any given types used in your data imports or APIs.
 
 
3. From a custom model point of view: 
 
Create an aspect overriding cm:indexControl
 
<aspect name="my:doNotIndexContentControl"> 
    <title>Do Not Index Control</title> 
    <parent>cm:indexControl</parent> 
    <overrides> 
       <property name="cm:isIndexed"> 
           <default>true</default> 
       </property>  
       <property name="cm:isContentIndexed"> 
           <default>false</default> 
       </property> 
     </overrides> 
</aspect> 
 
And then, set it as mandatory aspect for the custom content type. This is highly customizable, for a given custom type, defined in the repository.
Entrada publicada en Sin categoría | Comentarios cerrados

El futuro de sinadura (sinadura 5)

El ecosistema de sinadura, que zylk.net lleva gestionando y dinamizando desde hace unos 7 años, va a sufrir este año una transformación, o eso esperamos. Hasta ahora todos los proyectos que componen el ecosistema son proyectos con una base común pero sin una ligazón fuerte. Durante el año 2016 desde zylk.net vamos a tratar de impulsar varias acciones relacionadas con este ecosistema. La intensidad del impulso dependerá bastante de la financiación que consigamos para afontar este nuevo reto.

  • Integración de los dos principales servicios (sinadura desktop, cloudsign)
  • Autenticación en dos fases, basada en un QR y en un móvil, para disparar el proceso de firma delegada
  • Firma de documentos remotos (para la integración con aplicaciones de terceros) con el fin de permitir usar sinadura desktop en aplicaciones web (esto ya lo hace a día de hoy, sinadura desktop, usando webdav y el proyecto apache vfs que se integró en sinadura hace ya varios años. Esto se hizo para permitir la firma de documentos en el gestor documental alfresco).

Como se puede ver hay dos acciones que se encaminan a mejorar los dos productos principales del ecosistema. Y otra acción que se encamina a hacer que los procesos de firma de una organización se coordinen desde un sistema centralizado que controle, quién puede hace qué y desde qué dispositivo.

La integración de ambos desarrollos nos debería permitir la gestión de las firmas desde los siguientes puntos de vista

Firma delegada basada en servicios REST (con una sistema de auntenticación en 2 Fases)

  1. Para permitir realizar firmas corporativas
  2. Para permitir firmas de aplicación

Firmas en PC, integradas con las aplicaciones de una empresa

  1. Para permitir firmas de terceros sin tener que custodiar sus certificados
  2. Para permitir firmas personales con smartcards (dnie electrónico)

En esencia la idea es eliminar del ecosistema, el producto sinadura ECM y ampliar su funcionalidad para que permita firmar documentos no solo almacenados en alfresco ECM. Además perseguimos potenciar el uso de cloudsign, al integrar ambos productos para permitir cubirar las necesidades globales de firma de una empresa.

 

Para poder afrontar este reto, vamos a incorporar un proces de autenticación en dos fases a la plataforma cloudsign. El diagrama base de lo que se pretende hacer es el siguiente

 

 

Con estas dos mejoras de los productos del ecosistema vamos a poder hacer que ambos confluyan en una solución única. La idea de la confluencia es la descrita en el siguiente gráfico:

Veremos como se da el año (2016) y veremos si, desde zylk.net, somos capaces de traccionar esta nueva visión.

Entrada publicada en Sin categoría | Comentarios cerrados

API gateway architecture for microservices

Siguiendo con los anteriores artículos relacionados con los microservicios presentamos un nuevo diagrama de arquitectura de lo que se conoce como API-gateway. Que es una suerte de orquestador (y más) de las llamadas a distintos microservicios. En realidad las operaciones que realizan los microservicios suelen ser operaciones muy atómicas que aunque tienen valor de negocio necesitan ser orquestadas para poder representar una operación de negocio real.

Donde podemos ver a grandes rasgos la función de un API-Gateway. En el caso que nos ocupa en zylk.net para componer esta capa se va a usar, lo ya descrito anteriormente

Y el proyecto Hystrix de netflix. La idea es encapsular los servicios RCP con una capa de comandos hystrix para poder crear el API Gateway. Para la PoC que hemos definido se necesita

  1. Crear un primer comando hystrix que tarde en ejecutarse, pongamos 5 segundos
  2. Crear un segundo comando que tarde en ejecutarse 4 segundos

Una vez que tenemos esto, crearemos un cliente que invoque ambos comandos de dos maneras (existe una tercera basada en programación reactiva, que en este caso no vamos a usar) Síncrona

  • Síncrona

  • Asíncrona

Si ejecutamos ambos clientes podemos ver las diferencias de ejecución en ambos casos.

La verdad es que el proyecto hystrix de netflix es un gran proyecto que nos sirve para encapsular las llamadas a servicios de terceros. En este caso nos permite encapsular nuestros propios microservicios expuestos por yarn/avro-rpc. Además nos permite gestionar las asincronía y también implementa el patrón circuit-breaker, tan importante en los sistemas de información de nueva generación como los que empezamos a desarrollar en zylk.net

En este link os podéis descargar las 4 clases que se han usado para la PoC, para los que prefieren leer código.

Entrada publicada en Sin categoría | Comentarios cerrados

Visión general de una arquitectura de microservicios basada en yarn

Siguiendo con la evolución de las arquitecturas orientadas a servicios ... ahí va un gráfico que completa la visión general explicada en anteriores post

Los servicios son servicios modelados con avro/RP y pueden operar en tres modalidades

  • POJOs
  • Como servicio RPC en local
  • Como servicio RPC en un cluster de yarn (escalado, tolerancia a fallos etc..)
Entrada publicada en Sin categoría | Comentarios cerrados

Prototipando un servicio de validación de tickets usando códigos QR

El otro día me propusieron a ver si era posible desarrollar un servicio de validación de entradas, vamos a llamarlo, que permitiera validar las entradas y fuera ágil. El servicio debía cumplir las siguientes especificaciones

  • Estar en producción en 10-12 días
  • Permitir acceder al recinto usando una entrada impresa en papel
  • Permitir acceder al recinto usando la entrada sin imprimirla en papel
  • Comunicarse con los servicios centrales del cliente para integrar la información de quién había entrado y cuando

Nos pusimos a pensar y planteamos las siguientes ideas

  1. Papel/Móvil y Boli
  2. Papel/Móvil y Ordenador
  3. Papel/Móvil y lector de código de barras
  4. Papel/Móvil y móvil


Si alguna vez has estado en un evento en el que la lista de acceso se valida con papel y boli sabrás que tienen varias desventajas (pese a tener una gran ventaja ... que es no necesita desarrollo):

  • Si acude mucha gente no es fácil que todo el mundo le de tiempo a entrar antes de que empiece el evento
  • Si hay varias puertas …. el sistema tiene puntos de fallo si no se organiza quién entra por qué puerta

Por tanto las dos primeras opciones quedan descartadas.
Las otras dos que nos quedan estarían vinculadas al hecho de disponer de un lector de códigos de barras y un servicio que recoja la lectura y la envíe a algún lado.... Si descartamos la del lector porque habría que comprarlos etc... nos quedamos con que lo mejor sería desarrollar un poco más la cuarta opción a ver hasta donde nos lleva.

La opción cuarta aún así tiene una gran debilidad y es la de desarrollar la APP para el dispositivo móvil que permite validar la entrada. Con esto en mente desarrollamos los siguientes diagramas que nos permitían aclarar un poco el panorama .... pintar siempre es una buena idea




Donde se ve que necesitamos un sistema que genere códigos QR para las entradas y un QR que sirva para registrar el móvil que está haciendo de lector de QR. La idea es olvidarnos de desarrollar una app para el móvil y que de alguna forma cualquier móvil que tenga un cámara se puede usar como lector de QR.
 


Si no vamos a tener una app propia disponible tenemos que hacer que no todos los móviles sirvan para enviar la información al servidor, por un tema de seguridad principalmente. Además como queremos poder dar feedback a la persona que está en la puerta vamos a vincular el móvil con un PC que estará también en la puerta. Este gráfico representa cómo se ha diseñado el protocolo que vincula ambos dispositivos... Esto se haría una vez por cada puerta/persona que está validando los accesos.
Por último la fase de validación de las entradas



Donde vemos que la persona que va a entrar, presenta la entrada en la puerta. Esta entrada se escanea con el lector de QR estándar del móvil (hay muchos en el mercado) y al leer la URL que está en el QR la APP que ha leido el QR lanza el navegador con dicha URL que se procesa en el servidor. Esta URL genera una llamada de vuelta al PC vinculado a este móvil (paso 3.2-3.3) y el proceso de validación y registro se da por finalizado.


Ahora bien esto es en teoría y son papeles pintados … así que para probarlo hemos desarrollado una  PoC que usa los siguientes elementos

  • Librería ZXING para generara códigos QR
  • Servicios REST desarrollados usando JAXRS
  • WebSockets para comunicar eventos del servidor al cliente
  • Servidor tomcat 7

En total hemos desarrollado las siguientes clases java

  • QRGenerator
  • RegistService
  • WebSocketService

Con estas tres clases y el programa de lectura de QRs del móvil hemos hecho una PoC plenamente funcional que cumple los requisitos. (Hemos tardado 8 horas, post incluido). Evidentemente faltaría hacer bastantes cosas para poner el desarrollo en producción pero con esta orientación creemos que se podría hacer el proyecto en 10 -12 días

Las grandes ventajas que creemos que tiene este modelo son

  • Poco código desarrollado
  • No depende de una aplicación específica desarrollada para el móvil
  • Permite usar cualquier dispositivo con cámara como lector de códigos
  • Tiene un modelo de seguridad, que sin ser el más seguro del mundo, sirve.

Tiene muchos puntos de mejora está claro

  • Modelo de seguridad
  • Usar una APP propia para controlar mejor el feedback al usuario

En realidad el punto más fuerte de este modelo creemos que es que es facilmente convertible en un sistema de autenticación de dos fases … Adjunto el código del WAR de la PoC para el que tenga interés en ver el código.

Entrada publicada en Sin categoría | Comentarios cerrados

Timetracking system for taiga using slack integration

En zylk.net llevamos unos diez años gestionando los proyectos y los soportes con el bugtracker (mantis). En este último mes estamos probando distintas herramientas más próximas a la gestión de proyectos que a la gestión de issues/tasks etc.. Hemos probado algunas SAAS otras on premise etc... De momento con la que más a gusto nos estamos encontrando es con taiga...

Una de las cosas que no tiene taiga es la posibilidad de imputar horas reales en las notas de las historias de usuario, issues, tasks etc.. Con lo que hace un poco más compleja la gestión de las horas reales imputadas en un proyecto. Por esa razón y dado que estamos usando también el sistema de mensajería slack a nivel interno he desarrollado este fin de semana un modulo (no lo llamaría módulo de taiga ya que en realidad no lo es) para permitir hacer el seguimiento de tiempos de las tareas definidas en un proyecto del taiga.

Para ello contaba con los siguientes ingredientes

  • Pocos o nulos conocimientos de la arquitectura de taiga (Python pip etc..)
  • Un sistema de mensajería basado en slack con un bot que procesa la información de los canales de slack (Proyecto interno que estamos desarrollando en zylk.net que esperamos poder presentar el año que viene). Hay un montón de post relacionados con el tema en el blog de zylk [1][2][3] que aunque parecen inconexos tiene un objetivo común.
  • Modulo de integración entre taiga y slack

Visto el primer ingrediente ... quedaba descartada la mejor opción a nivel técnico que era hacer un módulo de taiga. Así que lo que diseñe fue lo siguiente

  1. Mandar los mensajes de las acciones realizadas en taiga a un canal de slack, usando el módulo de taiga disponible a tal efecto
  2. Parsear esos mensajes y extraer la información de seguimiento de tiempos, una expresión regular ... [".*<https://taiga.zylk.net/project/(.*?)/task/(.*?)\\|#.*?:(.*)>.*\\n+.*Comment by (.*?):(.*@timetracking\\s{1}(\\S*)\\s?.*)"]
  3. Guardar esa información un backend y notificar que se ha realizar la acción. De momento en una base de datos relacional.

Para ello bastó con diseñar la siguiente tabla

 

CREATE TABLE timetracking
(
   project VARCHAR(255),
   taskId VARCHAR(255),
   task VARCHAR(255),
   channel VARCHAR(255),
   timestamp BIGINT,
   message TEXT,
   timetrack DOUBLE,
   user VARCHAR(255)
);

Y usar el BOT que ya tenemos en zylk para que respondiera a la expresión regular. Con este sencillo modelo hemos conseguido que si se añade la siguiente instrucción (@timetracking 1:00) a un comentario de una tarea en taiga se añada esa imputación a la tabla anteriormente descrita ...

El sistema tiene una enorme cantidad de mejoras posibles... pero tiene una virtud, que no tendría un módulo de taiga, y es que nos permite realizar imputación sobre proyectos tanto desde la interfaz de taiga, como desde el propio sistema de mensajería de slack. A continuación mostramos unas imágenes de cómo sería el flujo de una imputación, el flujo sigue la el siguiente esquema

  1. Se crear una nota en una tarea de un proyecto de taiga, que tenga el texto @timetracking 2:00
  2. El mensaje se envía al canal de slack del proyecto en cuestión
  3. El BOT que tenemos desarrollado en zylk, interpreta ese mensaje, extrae la información necesaria (proyecto, task, timetracking, usuario etc...) y la añade a la tabla
  4. El BOT notifica que ha realizado la acción con éxito

 

Entrada publicada en Sin categoría | Comentarios cerrados

Simulando errores de red o mejorando la calidad de nuestro software

Una de las cosas que no se suelen probar en los proyectos de desarrollo de software es cómo operan los desarrollos realizados antes situaciones en las que la red falla (los famosos micro-cortes de red tan utilizados para justificar el mal funcionamiento de un software)

Hay proyectos, como el ejercito de monos de netflix ... que sirven para probar estas cosas (hay un mono que se dedica a hacer putadas en la red para ver si los componentes son tolerantes a fallos o no y sobre todo si tenemos efecto de bola de nieve, que es el peor de los problemas cuando diseñas sistemas complejos).

Teniendo claro que lo mejor sería integrar el ejército de monos en los sistemas de calidad de zylk, vamos, de momento, a ser un poco menos ambiciosos y vamos a usar únicamente un conjunto de comandos de sistema operativo para simular problemas en la red.

Para ello haremos uso del comando netem desde el que podemos simular caídas de red, latencia variable, perdidas de paquetes etc... Los comandos base que podemos usar son

 

>sudo tc qdisc add dev eth0 root netem delay 900ms 10ms distribution normal

Que nos permite añadir un delay a las peticiones de red (eth0) que corresponde a una distribución gaussiana con un máximo de delay de 900ms y un mínimo de 10ms centrada en el 900 y con una campana de 10 de ancho.

>sudo tc qdisc add dev eth0 root netem loss 0.1%

Que nos permite simular una perdida de paquetes del 0.1%

Existen comandos equivalentes para forzar la corrupción de paquetes, duplicidad de los mismos y un montón de cosas más...

La conclusión, una vez que usas este tipo de técnicas para realizar las QA de los proyectos, es que ... Ohhh dios mio!!! (que dirían en friends) los patrones que usa la gente no suelen ser los correctos y fallan estrepitosamente ante este tipo de problemas. Además ahora hay que tener especial cuidado ya que todo se ve como un servicio y un cliente que se conecta a dicho servicio.... Habrá que repasar este patrón. Y estar más atento a lo que hace la gente de netflix que de este tema parece saber mucho mucho mucho... En zylk ya llevamos algún tiempo usando estas técnicas para probar, en condiciones adveras, algunos de los proyectos que realizamos.

Entrada publicada en Sin categoría | Comentarios cerrados

How to control public shared content in Alfresco

Last day, I was asked for a client about how to control "public" shared content in Alfresco Share in a simple way. These are some of the ideas of the support conversation:
 
[me] First, just write in the Alfresco Share search box, the next querys. You should see your shared content. 
 
ASPECT:"qshare:shared" 
ASPECT:"qshare:shared" AND @cm:creator:"ccl001"
ASPECT:"qshare:shared" AND @qshare:sharedBy:"ccl001"
ASPECT:"qshare:shared" AND @cm:modified:["2014-12-31" TO NOW]
ASPECT:"qshare:shared" AND @cm:modified:[MIN TO "2013-12-31"]
 
[client] OMG! There exists a lot of public documents... What can we do for managing this ? Querys are right but many final users do not understand complex queries, and they are not familiar with aspects.
 
[me] Right, we can implement a document filter query in sites and/or in My documents dashlet, for final users.
 
[client] We are not sure about document library filters... because filters will appear in all sites, for all users. What about for Alfresco Admins ? May we get a list of public nodes ? How can we unshare these public urls ? 
 
[me] Just removing qhare:shared aspect. For alfresco admins, we can run a simple script in Javascript API for getting a brief report in CSV, via Alfresco Javascript Console. This should be valid also for users that create rules on their sites, executing the JS code. This is only valid for 1000 items, although you can run it several times (which is not always possible). 
 
var nodes = search.luceneSearch('ASPECT:"qshare:shared"');
var count = 0;
for each(var node in nodes) {
        count = count + 1;
        logger.log(count + ": "+node.displayPath+"/"+node.name);           
        // Uncomment these two lines for unsharing
        //logger.log("  Cleaning the aspect..");    
        //node.removeAspect("qshare:shared");
        //node.save();
        //logger.log("  Done");                        
}
 
[client] Mmm... I don't see the full picture, yet.
 
[me] Ok, we can filter query by modified date too. You can assume that content is shared before being modified and then to unpublish them if the content was modified many time ago.
 
var nodes = search.luceneSearch('ASPECT:"qshare:shared" AND @cm\\:modified:["2014-12-31" TO NOW]'); 
 
[client] This is a little tricky... but I'm not sure about it.
 
[me] Ok, you can use cm:effectivity aspect in Alfresco content, and use cm:to property for controlling the end lifecycle on your public nodes and urls. So, add aspect Effectivity, to the node to be shared, and then edit effectivity properties.
 
[client] I don't see it, this implies more work for final users.
 
[me] Well, you may also use content rules, for setting cm:to by a default relative date, if the content is shared.
 
[client] Better. Something more ?
 
[me] Then, we can write another script that checks the expiration date cm:to (i.e. today), and then remove the aspect or aspects.
 
var today  = new Date();
var month = today.getMonth() + 1; //months from 1-12
var day     = today.getDate();
var year    = today.getFullYear();
var mydate = year+"-"+month+"-"+day;
var nodes = search.luceneSearch('ASPECT:"qshare:shared" AND @cm\\:to:"'+mydate+'"');
var count = 0;
for each(var node in nodes) {
  count = count + 1;
  logger.log(count + ": "+node.displayPath+"/"+node.name);
  logger.log(" This public url is expired --> "+node.properties["cm:to"]);
  logger.log(" Cleaning the aspect..");
  node.removeAspect("qshare:shared");
  //node.removeAspect("cm:effectivity");
  node.save();
  logger.log("Done");
}
 
[client] It sounds even better.
 
[me] And finally, we can do a daily quartz executing the javascript code, to unshare the public urls.
 
 
[client] Ok, let's do it. 
 
P.S: Tested in Alfresco 4.2.4 EE (although it may work in other versions).
Entrada publicada en Sin categoría | Comentarios cerrados

Avro RCP yarn and slider II

Siguiendo con la visión de una arquitectura basada en yarn y mirco servicios ... os dejo un diagrama completo de los componentes y su comportamiento

 

 

Entrada publicada en Sin categoría | Comentarios cerrados