jBPM Form Builder: generación de formularios para jBPM5 y su integración en Guvnor.

0
7880

jBPM Form Builder: generación de formularios para jBPM5 y su integración en Guvnor.

0. Índice de contenidos.


1. Introducción

En este tutorial vamos a ver una pieza más del ecosistema BPMS de jBPM5, jBPM Form Builder, la pieza que nos va a permitir generar formularios
para nuestras tareas de usuario dentro de un proceso BPMN2, mediante una interfaz visual tipo drag&drop.

jBPM Form Builder es una aplicación web más que desplegaremos sobre un Apache Tomcat 7, solo para diferenciarla del núcleo del motor de procesos que
sí lo tenemos corriendo en un Jboss AS 7 y que se comunica con el repositorio de conocimiento, con Guvnor, haciendo uso del API REST de éste último.
Gracias a dicha integración, vamos a poder:

  • asociar un formulario a la ejecución de una tarea humana concreta de un flujo de trabajo, y
  • generar un formulario de forma automática conforme a la definición de parámetros de entrada y salida de un tarea humana.

Lo más interesante de la suite es precisamente este componente, que nos va a permitir generar los fomularios de cada una de las tareas particulares
almacenándolos directamente en Guvnor, junto con el resto de «assets» (reglas de negocio, flujos de trabajo,…) relacionados con nuestros procesos de negocio.

jBPM Form Builder puede trabajar de dos formas distintas, como una aplicación web normal o integrada en Guvnor. En este tutorial vamos a analizar los
pasos necesarios para configurar dicha integración y poder crear y modificar formularios directamente desde Guvnor.


2. Consideraciones previas.

Nos hemos encontrado con varios comportamientos anómalos, realizando las pruebas en el entorno en el que veníamos trabajando hasta ahora (jBPM 5.4.0.Final, Drools 5.5.0.Final y JDK 1.7.37 en MAC OS 10.7.5):

  • si quisiéramos desplegar todo el ecosistema en Jboss 7, hay problemas de comunicaciones, de los que ya hemos hablado, y la causa es correr Jboss sobre
    la versión 7 de la JDK que nos ha obligado a bajar a la versión 1.6.0_37,
  • errores de integración entre Guvnor y el Form Builder, que nos han obligado a bajar a la versión 5.3.0.Final de jBPM
    y a la versión 5.4.0-SNAPSHOT de Drools, con la versión 5.4.0-Final no están resueltos, véase:

    • en el Form Builder incrustado en Guvnor se muestran las opciones de «logout» y «guardar» cuando deberían estar ocultas, solo deberían mostrarse las del menú superior, el de Guvnor,
    • no se muestra la paleta de componentes de control, justo los interesantes para crear los formularios,
    • no crea el fichero -taskform autogenerado que asocia el formulario personalizado con la tarea, con lo cuál no puedes hacer uso del mismo desde la consola,
    • no descrubre los procesos hasta que no guardas la primera vez el formulario porque por defecto busca en el paquete defaultPackage (esto no es una peora de la versión 5.4, en la 5.3 tampoco funciona si tienes tu propia estructura de paquetes) y
    • al crear un flujo de trabajo no asigna el paquete seleccionado en el dialogo de creación y, del mismo modo, al crear un formulario no antepone el nombre del paquete al nombre del fichero;
      aunque termina funcionando no guarda coherencia con la estructura de paquete.
  • nos hemos encontrado con métodos por implementar //fixme que dejan incompleta parte del API de comunicaciones con el motor;
    este punto no está aún solucionado, lo que nos obligaría en su caso a acceder directamente nosotros al LDAP para obtener esa información si la necesitásemos.

Con todo ello, hemos tenido que modificar el entorno de las pruebas al que enumeramos en el siguiente punto.

Un último apunte relacionado con el estado del proyecto lo podemos encontrar en los
recursos de la comunidad,
más que en el roadmap que está
desactualizado; el desarrollo de las aplicaciones web está basado en GWT, algunas con Seam3 y otras con el soporte de Spring y se están migrando a
UberFire,
un framework para generar interfaces visuales basado en GWT, Errai y CDI,
que aún está en Alpha1; se está desarrollando en parelelo.

La versión 6 se basará en el core de todo este ecosistema, pero tendremos nuevas implementaciones.


3. Entorno.

El tutorial está escrito usando el siguiente entorno:

  • Hardware: Portátil MacBook Pro 15′ (2.4 GHz Intel Core i7, 8GB DDR3 SDRAM).
  • Sistema Operativo: Mac OS X Lion 10.7.4
  • jBPM 5.3.0.Final
  • Drools Guvnor 5.4.0-SNAPSHOT
  • JDK 1.6.0_37
  • Apache Tomcat 7.0.35


4. Instalación.

Sobre el proyecto en el que venimos trabajando, con el soporte de maven, deberíamos añadir un módulo más al pom.xml del proyecto tnt-jbpm,
modificando las propiedades de las versiones como hemos comentado (también hemos renombrado los proyectos en relación a la versión del
tutorial anterior):

El proyecto tnt-jbpm-gwt-form-builder tendría un pom.xml con el siguiente contenido:

El proyecto no tiene más configuracion que esta, lo que si debemos hacer es revisar la configuración de Guvnor, que contiene los parámetros de integración.


5. Integración en Guvnor.

Debemos añadir añadir un fichero preferences.properties en el directorio
src/main/resources del proyecto tnt-drools-guvnor, con el siguiente contenido:

El contenido es muy similar al original, pero debemos asegurarnos de que las propiedades oryx-bpmn-editor y asset.format.enabled.formdef están activadas,
porque en caso contrario el enlace que permite crear un formulario aparecería deshabilitado.

En este punto ya podríamos generar formularios desde Guvnor.


6. Creación de un formulario basado en la definición de una tarea humana.

Para crear un formulario basta con pulsar en «Crear Nuevo» > «Form Definitions» y se mostrará un diálogo como el siguiente:

Asignamos un nombre al formulario y tras pulsar ok, debería mostrarse la interfaz de usuario de creación del formulario, si bien antes nos solicita autenticación.
Revisando la petición que se realiza y los parámetros que recibe el servlet que permite hacer uso de la interfaz embebida del Form Builder puede que haya un error en el envío o recepción de los
parámetros de autenticación o esa parte está securizada cuando no debería serlo.

En cualquie caso, se mostrará un formulario de autenticación:

Tras incluir usuario y contraseña se mostrará la interfaz del Form Builder:

Como podéis comprobar, guarda coherencia porque se muestra una opción de logout; aunque creemos que no debería.
Así mismo la opción de «Form», puesto que está en modo embebido, tampoco debería mostrarse.

Lo interesante es la pestaña «IO Data» que permite seleccionar un proceso de negocio y, de él, una tarea:

El problema en este punto es que, guardando una estructura de paquete, como la que venimos usando, debemos guardar primero el formulario para que se persista
la información del paquete en el que estamos; por defecto busca en el paquete defaultPackage, pero tras guardarlo la primera vez sí se asignará. Además,
no nos permite almacenar un formulario vacío, con lo que debemos añadir un título, por ejemplo, guardarlo y volver a abrirlo para que «funcione correctamente».

Sobre la tarea podemos pulsar «botón derecho» > «Select IO object» y el formulario se asignará automáticamente a la tarea del proceso correspondiente.

Una vez seleccionado podemos generar un formulario en base a los parámetros de entrada y salida pulsando de nuevo «botón derecho» > «Quick Form from IO object»

Se mostrará un diálogo como el siguiente desde el cuál podemos seleccionar los campos que nos interesen y el contenido del formulario se sobreescribirá con esta información:

Se debería generar un formulario similar al siguiente:

Tras pulsar «Guardar» o «Guardar y cerrar» en el listado de recursos deberíamos tener lo siguiente:

Se crea un formulario autogenerado que apunta al formulario editable, y es en este punto donde tenemos el último error relacionado
con la ubicación de los recursos; parece que no se está anteponiendo el nombre del paquete, aunque no es seguro que sea ese el problema; la cuestión es
que hay escenearios en las pruebas en las que no muestra el formulario desde la consola. Hasta que no generas los formularios de forma automática desde la
interfaz del diseñador de procesos:

y vuelves a guardar el formulario desde el Form Builder, no se verá el formulario correctamente en la consola.

Si todo va bien, deberíamos ver algo como esto:


7. Referencias.


8. Conclusiones.

Quizás originados por la migración que comentábamos o directamente porque el producto tiene bugs, como todos los productos, pero se hace dificil
trabajar fuera del escenario de las demos que vemos y que tanto llaman nuestra atención. ¿Podríamos vivir sin el generador de formularios?, por supuesto,
pero es lo interesante de la solución, ahorrarnos tener que generar manualmente las interfaces de cada una de las tareas del flujo desde nuestras aplicaciones,
que son las que van a hacer uso del motor de estados.

Aún nos queda explorar cómo realizar la integración con sistemas externos desde el motor, creando nuestra propia librería
de componentes de definición de tareas dentro de un flujo.

Como en ocasiones anteriores, os dejo aquí el proyecto mavenizado por si queréis jugar con él.

Stay tuned.

Un saludo.

Jose

jmsanchez@autentia.com

Dejar respuesta

Please enter your comment!
Please enter your name here