Primeras impresiones de Bonita 5 (aka Bonita Open Solution)

Bueno después de haber avanzado allá por Octubre la preview de la versión 5 de Bonita me había olvidado un poco de ella, pero hoy he comenzado a instalar y probar la versión 5.0.1 (ya ha salido la 5.02) y quería compartir mis primeras impresiones.

Para empezar diré que la estructura se mantiene más o menos igual. se puede desplegar la aplicación web y personalizar ciertos aspectos o bien desplegar el "runtime" en un servidor de aplicaciones para conectarnos a el mediante RMI.

Les dejo una pequeña valoración inicial con algunos aspectos que he encontrado en este primer acercamiento:

Aspectos positivos:

• A nivel de la API han habido algunos cambios, ya que ha cambiado algo el modelo y se han añadido ciertas funcionalidades como por ejemplo la "reparacion de casos".
• Donde se observan las mayores diferencias es en el cliente web. Han desarrollado un cliente totalmente nuevo, algo muy acertado a mi juicio, ya que el anterior fallaba bastante.
• El BonitaStudio (desarrollado sobre eclipse), parece mucho más completo que las versiones anteriores de las herramientas de diseño.
  

Aspectos negativos:

• El proceso de instalación es el mayor problema que he encontrado hasta el momento, el cuál es complicado y la documentación al respecto es insuficiente. Personalmente he trabajado con versiones anteriores de Bonita y esto parece ser un problema recurrente, imagino como sufrirá un usuario nuevo para llevar a cabo la instalación. Quién haya instalado antes Nova Bonita , no tendrá problemas para isntalar el runtime pero la aplicación web puede que le ed algún que otro problemilla.
  
• No existe documentación para la API, o no esta disponible, tán sólo podemos acceder al javadoc de la API. He podido detectar algunos cambios gracias a los proyectos existentes con librerías (bonita-client) anteriores.
• No hay compatibilidad con flujos anteriores. Esto hay que matizarlo, yo puedo importar un Bar de Bonita 4, pero hay una alta probabilidad de que no funcione si contenía lógica, por ejemplo Hooks. Se puede importar al BonitaStudio pero la importación no es del todo correcta y hay que arreglar los flujos. Además no trabajamos con un fichero XPDL sino que importaríamos el .bar.
  

Una vez que se ha instalado y comprobado que funciona correctamente, es necesario migrar las aplicaciones para usar la nueva API y hay que aprender a usar la nueva herramienta de diseño, ya que ha cambiado completamente. Esto implica que una migración requiere un coste relativamente alto, esto sin hablar de migrar las instancias existentes en un sistema antiguo al nuevo.

Seguiré comentando. Saludos.

Felicidades

Este post, aunque haya tardado un poco, es para celebrar que hay una nueva ingeniera informática en la familia, Felicitaciones a Amelia por haber presentado su proyecto final de carrera, titulado: "Adquisición de datos de una red de anemómetros.", cuya funcionalidad se basa en la recogida de muestras de viento a partir de sensores (anemómetros), para almacenarlas en una base de datos.

A dichos datos puede accederse a partir de una aplicación web rica. Toda la aplicación ha sido desarrollada con tecnologías openSource (Java, Spring, Hibernate en el servidor y Flex con BlazeDS en el cliente).

Espero que de ahora en adelante pueda participar más en el Blog .

BlazeDS: NetConnection.Call.Failed

Bueno como ya había comentado antes, durante las últimas semanas, he tenido una "batalla" con BlazeDS, y parece que finalmente a acabado con un resultado algo inesperado, quedando BlazeDS totalmente exonerado.

El problema consiste en la perdida de conexión entre el cliente y el servidor (Java). Tras realizar una llamada a un servicio si esté se demora mucho (o si colocamos un breakpoint) se pierde la conexión con el servidor y tras el timeout se informa al cliente, con un evento NetStatusEvent con el código NetConnection.Call.Failed, el cuál vuelve a realizar la llamada teniendo así varios hilos ejecutando la misma llamada.

He pasado mucho tiempo comprobando los logs (tanto de servidor como de cliente), variando las configuraciones del BlazeDS, depurando el código de BlazeDS, el código de la librería RPC del FLEX SDK (en varias versiones) sin encontrar un motivo aparente del error, ya que realmente el funcionamiento era correcto. En este proceso siempre llegaba al mismo punto que era la serialización del AMF Request, pero realmente la hacía bien, pero en ese punto era cuando perdía la conexíon.

La sorpresa salta cuando probando en otro entorno con un servidor de aplicaciones Tomcat no se reproduce el error, por lo que decidimos revisar el servidor de aplicaciones Jetty que usamos en desarrollo y encontramos que se debe a una actualización del servidor Jetty que hasta al fecha funcionaba correctamente, pero que había sido actualizado.

El problema radica en la versión 6.1.24 de Jetty, el cuál ha modificado la forma en que se tratan los request HTTP (probablemente exista algún bug). No he profundizado en el tema pues las versiones anteriores de Jetty funcionan correctamente y nos hemos pasado a una anterior, pero creo que el problema anda por la clase HttpParser la cual se encarga de leer (parsear) los request.

Saludos.

Charles (Proxy Depurador Web)

Buenas a tod@s.

Esta semana he tenido una guerra particular con el BlazeDS (de la cuál hablaré en otro momento cuando tenga más tiempo), y en tales circunstancias he encontrado una herramienta que me ha sido bastante útil. Se trata de Charles, una aplicación que sirve de proxy para las peticiones web y que te permite tanto ver los request/response como depurar las peticiones.

Es cierto que para ver las peticiones del BlazeDS tan sólo s necesario activar el login, pero obviamente es menos legible, y ademas Charles te da cierta información acerca de que está sucediendo y porqué.

Desaparecen los imports en Flex Builder 3

Hace un tiempo que un compañero se encontro con este problema y hasta hace poco no sabía porque se daba este comportamiento extraño. El problema en cuestión es que al usar el asistente de código (con Ctrl + Espacio) el Flex builder elimina algunos imports, sobre todo los del paquete flash. Esta situación es bastante molesta, ya que obliga al desarrollador a tener que asegurarse de si los imports están correctos antes de cada guardado suponiendo una falta de eficiencia y una fuente inmensa de errores. Otra problema que se puede apreciar es que no encuentra algunas clases al usar el asitente de código y ni siquiera podemos ver sus métodos.

Indagando un poco he encontrado el porque de éste problema y su solución. El problema realemente es una combinación de circunstancias un poco peculiar, pero que se da con frecuencia.

Por un lado tenemos la opción de "organizar los import" y "eliminar los imports no usados", las cuales las encontramos en "Window->preferences->Flex-> actionScript Code". Dichas opciones suelen estar activadas y yo recomiendo que sigan así. En algunos foros he leíio que hay quien las ha desactivado para evitar el problema, pero de esta forma sólo conseguiremos evitar que elimine los imports pero el problema seguirá "latente", ya que seguiremos sin poder usar el asistente de código.

Por el otro lado tenemos el SDK que usamos en la aplicación, que es el verdadero causante de este problema. Este error suele surgir cuando hemos cambiado de SDK o cuando se crea un proyecto nuevo con un SDK superior al 3.2 y estamos compilando para la maquina Flash Player 10. Se debe a que han cambiado la ruta en la que se encuentra la libreria playerglobal.swc, para tener compatibilidad con la máquina Flash 9 y 10, esto es lo que hace que no se carguen las clases y por tanto no aparezcan el el asistente de código y asímismo, dado que no encuentra las clases, elimina sus imports por no estar siendo utilizados.

Por tanto para solucionarlo tenemos que asegurarnos que se cargue la libreria playerglobal.swc correspondiente a la máquina Flash Player con la que trabajemos. Esto podemos hacerlo de varias formas:

Opción 1
En las propiedades del proyecto ir a "Flex Build Path" -> "Library Path" y eliminamos dicha librería del SDK, para luego añadirla manualmente.

Opción 2

Modificar el fichero ${FLEX_SDK}/frameworks/flex-config.xml para configurarlo correctamente para la la Flash player 10.

1. Editar el tag <target-player>, reemplazando 9.x.x por 10.0.0:
   <target-player>10.0.0</target-player>
2. En el tag , editar el "path-elelment" para el playerglobal.swc reemplazando 9 por 10
   <external-library-path>
   <path-element>libs/player/10/playerglobal.swc</path-element>
   </external-library-path>
3. Hacer lo mismo con el tag <library-path>
   <library-path>
   <path-element>libs</path-element>
   <path-element>libs/player/10</path-element>
   <path-element>locale/{locale}</path-element>
   </library-path>

Si queremos alternar el uso de las versiones 9 y 10 de Flash Player podemos hacerlo reemplazando el 10 por {targetPlayerMajorVersion}, con lo que el usara el "major version" del flash Player que establezcamos en el compilador.

Desde mi punto de vista recomiendo la segunda opción ya que la primera aunque parezca más simple habría que repetirla en cada proyecto que tengamos y nadie garatiza que no se quede alguno atras.

Pueden ver más en el sitio oficial de adobe aqui.