martes, 28 de enero de 2014



En la primera entrada de esta serie con el BPMS Bonita habíamos visto como modelar el proceso de la figura anterior.
En la segunda entrada  vimos cómo crear tanto variables globales como locales para actividades en particular.
En la tercera entrada  vimos cómo definir condiciones y transiciones que nos permitían dar un mejor sentido a las posibles variantes que el proceso puede seguir en función de las decisiones que se tomen.
En la cuarta entrada  vimos cómo definir los roles participantes en el proyecto y ejecutar el proyecto visualizándolo desde una aplicación web ofrecida por Bonita.
En la quinta entrada  vimos cómo iniciar la mejora de las interfaces gráficas de los formularios.
En la sexta entrada vimos cómo seguir la mejora del resto de las UI, User Interfaces o Interfaces Gráficas, realizando cambios en dependencia del formulario en que nos encontremos.


Ahora veremos 2 pendientes de la entrada anterior:
  • Permitir la selección múltiple de los productos a comprar. 
  • Cargar los productos desde una BD.

Comencemos.!!!!

El primer cambio involucra sustituir el componente donde se muestran los productos. Antes era un select, ahora debe ser una lista  de checkbox, tal y como se muestra en la siguiente imagen.

Ya de esta manera se nos mostrarán todos los productos y podremos marcar los que queramos.

Ahora para el segundo cambio, manteniendo seleccionado este componente nos vamos a la pestaña de “Datos” y ahí en donde dice “Valores Disponibles” damos clic encima del lápiz de editar, y veremos lo siguiente luego de hacer los cambios:



Básicamente hemos creado un script en Groovy que se conecta a nuestra BD, donde tenemos los productos, y nos devuelve el nombre de los productos que se están vendiendo.
Cuando damos clic en aceptar veremos lo siguiente.


Vean que en “Valores Disponibles” tenemos nuestro script recién creado y hemos creado una nueva variable a la cual le asignamos los valores seleccionados en el listado de checkboxs. Esta variable la podemos ver a continuación.





Para crearla solo dimos clic en “Agregar” y les muestro como quedó.




De esta manera cuando instanciamos el proceso veremos lo siguiente:





Como pueden ver se ha podido seleccionar todos los productos ofertados. Luego cuando se muestra esta información al revisor veremos lo siguiente:




Lo que hemos hecho es ir al al formulario de la tarea “Revisión por Ventas” y sustituir el Text que teníamos antes por un List o Lista en español. Lo podemos ver en esta imagen.

Y en la pestaña de “Datos” de este componente en la  parte de “Valores Disponibles”  seleccionamos la variable “producto_seleccionado”. Además en la pestaña de “Opciones” lo marcamos como de solo lectura. Y eso es todo.

lunes, 27 de enero de 2014



En la primera entrada  de esta serie con el BPMS Bonita habíamos visto como modelar el proceso de la figura anterior.
En la segunda entrada  vimos cómo crear tanto variables globales como locales para actividades en particular.
En la tercera entrada  vimos cómo definir condiciones y transiciones que nos permitían dar un mejor sentido a las posibles variantes que el proceso puede seguir en función de las decisiones que se tomen.
En la cuarta entrada  vimos cómo definir los roles participantes en el proyecto y ejecutar el proyecto visualizándolo desde una aplicación web ofrecida por Bonita.
En la quinta entrada  vimos como iniciar la mejora de las interfaces gráficas de los formularios.

En esta 6 entrega veremos cómo seguir la mejora del resto de las UI, User Interfaces o Interfaces Gráficas, realizando cambios en dependencia del formulario en que nos encontremos.

Comencemos.!!!!

Como se puede apreciar en la imagen inicial de esta entrada, tenemos varias actividades que llevan intervención humana. Para continuar nuestro ejemplo modificaremos la UI par la actividad “Revisión por ventas”. Los pasos iniciales son los mismos que los de la entrada anterior, así que nos lo saltaremos y ya estamos en el diseño de la nueva UI.

Lo primero es dejar el diseño igual al de la entrada anterior, por un tema de uniformidad.

Luego debemos notar que este formulario no es para entrar información, si no para que el vendedor revise la información y tome una decisión por lo que los widgets deberían ser de solo lectura.

Para hacer esto es realmente sencillo:

  • Los campos que son de tipo “Caja de Texto” deben ser cambiado a “Texto”.
  • En el caso del Widget de los productos pues debemos eliminar el Widget y agregar uno de la paleta de componentes que sea de tipo texto. 

Lo importante aquí es indicarle de donde obtendrá la información. Los pasos son los siguientes:
  1. Eliminar el Widget. 
  2. Agregar una nueva fila en la misma posición. 
  3. Seleccionar el componente Texto de la paleta de componentes y arrastrarlo a la fila recién creada. 
  4. Ponerle como nombre “productos” y como etiqueta “Productos Seleccionados”. 

 Manteniendo seleccionado este Widget vamos a la opción “Datos” y como valor inicial seleccionamos “productos” tal y como se muestra en la siguiente imagen.




Para probar lo hecho ejecutamos el proceso.



Y al enviar la solicitud vemos lo siguiente:



Como se puede apreciar los campos no son seleccionables y se nos muestran las posibles decisiones a seleccionar.

Aprovechando esta  entrada les comento otras mejoras que se le han realizado a las UI:
  1. Como se podía apreciar en las imágenes, los campos estaban muy para la izquierda. La solución más rápida es en el diseño del formulario agregar una columna a la izquierda de la columna en la que tenemos los widgets. 
  2. El otro problema era que las cajas de texto eran muy grandes. Así que seleccionando un Widget, vamos a la pestaña de “Apariencia” y ahí podemos modificar las propiedades. En este  caso en particular cada Widget tiene esta definición de su ancho.




Ahora se ve mucho mejor, aunque se le pueden seguir haciendo mejoras.



Llegado a este punto algunos señalamientos:
  • La vista previa en nuestro caso no se corresponde luego de hacer los últimos cambios con lo que se muestra una vez ejecutado el proceso. 
  • Existe la necesidad de agregar una nueva columna para que los widgets se vean en el medio. Puede ser que exista alguna propiedad que no se ha encontrado aún.
  • La documentación de Bonita en español es bastante pobre e incluso en inglés deja bastante que desear aun.

Posibles mejoras a incluir:
  • Poder seleccionar varios productos en una misma orden de compra. 
  • Cargar los datos de los productos ofertados desde una BD o servicio web, y no como se hace hoy que son estáticos.
  • Usar CSS para las UI.
Estas mejoras las estaremos viendo en futuras entrada.

viernes, 24 de enero de 2014



En la primera entrada  de esta serie con el BPMS Bonita habíamos visto como modelar el proceso de la figura anterior.
En la segunda entrada  vimos cómo crear tanto variables globales como locales para actividades en particular.
En la tercera entrada  vimos cómo definir condiciones y transiciones que nos permitían dar un mejor sentido a las posibles variantes que el proceso puede seguir en función de las decisiones que se tomen.
En la cuarta entrada  vimos cómo definir los roles participantes en el proyecto y ejecutar el proyecto visualizándolo desde una aplicación web ofrecida por Bonita.

En la última entrada vimos como las interfaces de usuario estaban bastante pobres, sin ningún diseño ni usabilidad. Por este motivo en esta entrada estaremos viendo cómo mejorar este asunto.

Comencemos.!!!!

Lo primer es ir al formulario que inicia el proceso. Para eso damos clic en el pool del proceso, seleccionamos la pestaña de “Aplicación”, y luego seleccionamos “Pageflow de captura” tal y como se muestra en la siguiente imagen.




Ahora damos clic en el botón “Agregar” y veremos lo siguiente:



Como se puede apreciar se muestran las variables que se deben llenar al inicio del proceso y el tipo de componente que se usa para visualizarlas. Las dejamos todas seleccionadas y damos clic en “Finalizar”.
Ahora se nos muestra un nuevo elemento, es el formulario que acabamos de crear pero esta vez nos deja manipular la forma en que se visualizará y los componentes que contiene. Verán una paleta de componentes y podemos realizar mejoras a la interfaz gráfica.



Cada componente está dentro de un Widget y es fácilmente configurable su posición. Si quieren ver todo el formulario minimicen las otras pestañas.

Los signos de + y  –  si se paran encima de ellos les indican las acciones que realizan. En mi caso hice las siguientes:
  • Agregué una fila arriba. 
  • Arrastre el Widget de nombre de cliente a esa fila. 
  • Cree una fila encima de email y arrastré para ella el Widget de numerotelefono. 
  • El Widget de productos que se visualizaba como botones de radio, lo cambié a “seleccionar” modificando el tipo de campo como se puede apreciar en la siguiente imagen.




Luego de estos cambios como me interesa ver qué tal va quedando, le doy a la pestaña “preview” y selecciono el navegador que quiero usar para ver el formulario. Y va quedando así:



Pruebo de nuevo con los productos como botones de radio a ver qué tal, y se ve así:



Como se puede observar en las imágenes se está mostrando el nombre de las variables, así que ahora mostraremos unos nombres más amigables. Para eso seleccionamos el Widget y vamos a la pestaña general, donde podemos modificar la etiqueta, tal y como se observa en la siguiente imagen.



Hacemos lo mismo para el resto de los campos.
Volvemos a ver el preview y ya ha mejorado algo.



Luego de estos cambios podemos trabajar sobre algunas validaciones. Les mostraré como validar el Widget que contiene el número de teléfono. Para eso debe seleccionar el Widget y dar clic en “Validadores”, dar clic en el botón “Agregar”, y seleccionar el tipo de validador “Phone Number” y poner algo como lo siguiente:




Otra cosa que podemos hacer es seleccionar “Opciones” y marcar cada Widget como requerido para forzar al usuario a que introduzca información en los campos.
Ahora podemos instanciar nuevamente el proceso ejecutándolo para ver los cambios realizados. Está claro que usaré valores no válidos para probar las cosas que se han hecho, veamos como se ve:



Podemos ver que donde no hemos introducido un valor nos dice que es “mandatory” o sea obligado, y cuando se ha puesto un valor que no se corresponde con un número telefónico nos alerta al respecto.
Luego de esta prueba haré otros cambios más:

  • Pondré un validador Email al Widget del correo electrónico.
  • Cambiaré los productos ofertados a un seleccionar. 
  • Cambiaré el nombre del botón.

Volvemos a probar ejecutando el proceso.


Y como se puede ver ya se valida el campo del correo electrónico y los productos se muestran en un seleccionar.

Como se ha podido apreciar, con Bonita es muy fácil mejorar las interfaces de usuario y agregar validadores a los cambios así como organizarlos mejor para el usuario final. En la siguiente entrada seguiremos trabajando con las otras interfaces de usuario viendo casos en particular que nos interesa explicar.

jueves, 23 de enero de 2014



En la primera entrada  de esta serie con el BPMS Bonita habíamos visto como modelar el proceso de la figura anterior.
En la segunda entrada  vimos cómo crear tanto variables globales como locales para actividades en particular.
En la tercera entrada  vimos cómo definir condiciones y transiciones que nos permitían dar un mejor sentido a las posibles variantes que el proceso puede seguir en función de las decisiones que se tomen.

En esta entrada veremos cómo definir los actores y ejecutar el proceso.

Empecemos.!!!

Los actores, son aquellas personas que interactúan con el proceso a través de las actividades humanas, introduciendo o modificando de alguna forma la información. En los BPMS los actores son seleccionados dinámicamente en base a determinados criterios. En nuestro caso introducimos la restricción de crear una lista estática de los mismos para facilitar la comprensión inicial del funcionamiento de la herramienta Bonita, ya más adelante mostraremos como eliminar esta restricción.
En este proceso se requieren 2 tipos de actores:
  • El iniciador del proceso. 
  • Los empleados de ventas.

Así que debemos:
  • Definir ambos grupos al nivel del proceso. 
  • Ir a cada actividad que lo requiera y asignarles el grupo según se necesite.

Para realizar el primer paso damos clic en cualquier parte del pool y seleccionamos  General y luego Actores.  Veremos lo siguiente:



Por defecto la herramienta nos ha creado un actor y lo ha definido como iniciador, informándonos de que en caso de que no se defina uno, pues el proceso solo se puede iniciar desde el código.

En versiones anteriores como la 5.1 desde aquí mismo se podían crear grupos y dentro de cada grupo los actores. Ahora Bonita incluye desde hace algunas versiones el concepto de Organización entro de la cual se pueden crear los grupos, roles y usuarios de una organización.

Para este ejemplo lo primero que deben hacer es ir a menú superior y dar clic en la opción Organización y luego dan clic en Administrar.

Les saldrá una pestaña con una organización por defecto “Acme” pero para crear la de esta aplicación BPM pueden dar clic en “Añadir” e introducir los datos, tal y como se muestra a continuación.



Como ven solo le he puesto un nombre y una descripción, si quieren que aparezca como activa, es necesario que la publiquen en el portal, ya veremos cómo.

Una vez que marquen la organización que acaban de crear podrán dar clic en el botón “Siguiente” y entonces se debe crear el grupo o los grupos que contendrá nuestra organización. A fines de este ejemplo solo he creado un grupo.



Pero como pueden ver se pueden crear múltiples grupo e incluso subgrupos, eso queda a consideración de los analistas del proyecto.
Luego dan clic en “Siguiente” y creamos dentro del grupo anterior los roles necesarios para nuestra aplicación. Nos quedaría algo como lo siguiente:



Damos clic en “Siguiente” y pasamos a crear los usuarios. Importante que se fijen como un usuario se vincula con un grupo y a su vez con un rol dentro de dicho grupo.



Y hasta aquí esta primera parte, dan clic en Finalizar y listo.
Si vuelven a dar clic en el menú “Organización”  pueden seleccionar la opción “Publicar”.



Seleccionan la organización que acaban de crear y si quieren le dan clic a “Siguiente” y de esta manera definen que usuario será usado automáticamente para acceder desde el portal a esta organización.
Para finalizar le dan clic al botón “Publicar”. Y ya está publicada la organización en el portal.



Llegado este momento si le dan clic al botón que dice “Ejecutar”.



Lo más seguro es que les dé un error pues falta algunos pasos por configurar. Veámoslos.
Deben dar clic en el botón que dice “Configurar” y entonces verán un mensaje que dice que el actor no está asignado a ningún grupo o rol, deben dar clic en “Grupos” y seleccionar el grupo correspondiente. Esto para cada usuario que no esté asociado a un grupo.



Luego deben dar clic donde dice “Autenticación” y poner el usuario y la contraseña con la que se accederá a la aplicación BPM una vez iniciada.



Ya pueden dar “Finalizar”  y ejecutar el proceso.
Como no nos hemos dedicado aun a las interfaces gráficas pues todo está muy verde aun, pero lo importante es que está funcional. Cuando el proceso es ejecutado veremos estas pantallas:



El primer problema que vemos es que no se listan los artículos que están disponibles. Es algo que se arreglará después.  Los datos que ven lo hemos introducido para este ejemplo.


Le damos “SUBMIT”


Y se nos informa que tenemos una tarea disponible.
Se nos muestra la información introducida por pepe el comprador en la página 1.



Y en la página 2:



Aparece por defecto la decisión de “Aprobar”, como ven no se nos muestran las otras opciones posibles de decisión y será otro problema a solucionar.

Le damos “SUBMIT


Y se nos informa que hay otra tarea disponible, le damos “Pagar”.

Se nos vuelve a mostrar la información de la venta en la página 1.



Y en la página 2 podemos decidir si el envío es express, poner la fecha de vencimiento y el número de la tarjeta con que se pagará.



Llegado este punto pueden darle al botón “SUBMIT” pero si quieren pueden darle al botón que tienen en la esquina superior derecha y que los lleva al portal de bonita, donde podrán navegar por los diferentes elementos y ver las tareas ya hechas, los comentarios, las tareas asignadas y pendientes, etc.



Al darle a “DO IT” se nos muestra la misma interface anterior y le podemos dar a “SUBMIT


Terminando así la ejecución de este proceso.

Como ven el proceso es funcional y hace lo que diseñamos pero quedan varias cuestiones de diseño que deben ser solucionadas. Esto lo veremos en próximas entradas.
Cualquier duda pueden dejar un comentario.

miércoles, 22 de enero de 2014



En la primera entrada  de esta serie con el BPMS Bonita habíamos visto como modelar el proceso de la figura anterior.
En la segunda entrada  vimos cómo crear tanto variables globales como locales para actividades en particular.

Y en esta entrada veremos cómo definir las condiciones y transiciones dentro del proceso para darle un poco más de funcionalidad al mismo.

Empecemos.!!!
Cuando vemos la actividad de “Revisión por ventas” notamos que tiene 3 salidas, y podríamos preguntarnos como el proceso sabe qué salida tomar. Y ese es el objetivo de las condiciones, definir cuándo tomar una salida u otra.
Para ello seleccionamos la actividad “Revisión por ventas” y damos clic en General y luego en Datos.



Creamos una nueva variable local, como se aprendió en la entrada anterior, con la siguiente información:

Variable: decision.
  • Descripción: múltiples opciones requieren una decisión.
  • Tipo de dato: lista de opciones (ya sabemos cómo crearla) y sus valores son: 
  1. Aprobar. 
  2. Rechazar. 
  3. Más información.



Y finalmente se ve así:




Ahora viene la parte interesante porque debemos realizar lo siguiente:
Seleccionar cada una de las transiciones, las líneas con saetas al final que van de la actividad “Revisión por ventas” hacia:

  • Pagar” cuando el valor de la decisión sea “Aprobar 
  • Rechazar” cuando el valor de la decisión sea “Rechazar 
  • Más Información” cuando el valor de la decisión sea “Más Información

Para hacer esto damos clic encima de una de las líneas, en este caso la que va de “Revisión por ventas” hacia “Pagar”.



Ahí debemos especificar un nombre, y el resto de los campos que se nos piden, de la siguiente manera:



Se debe hacer lo mismo para las otras 2 líneas. Solo tengan en cuenta que a la hora de introducir la condición debe de poner bien el nombre de la variable “decision” y el nombre del valor que debe tomar.
En nuestro caso quedó de la siguiente manera el proceso luego de hacer estos cambios:



Como pueden apreciar ya se ven las condiciones saliendo de la actividad “Revisión por ventas” y en cada condición se muestra cuál es su nombre. En versiones anteriores se mostrada el valor de la condición, ya en esta versión se muestra su nombre lo cual lo hace más fácil de entender.

Ahora podemos ver que la actividad de “Pagar” tiene 2 condiciones también, una que se ejecuta cuando el cliente selecciona el envío Express y otra cuando el envío es regular, por lo que se deben realizar los mismos pasos anteriores para definir cuando el proceso se va por una y cuando se va por la otra.
Recuerden que para esta actividad “Pagar” ya tenemos una variable que toma valor true, en caso de que el envío sea Express y false en caso de que el  envío sea regular. Solo deben definir las condiciones.

En nuestro caso queda así:



Lo interesante es que la variable que definimos en la actividad “Pagar” de nombre “escogerEntregaExpress” es de tipo boolean, o sea que tiene valores true o false, así que solo poniendo su nombre en la condición esta es evaluada usando Groovy y con eso basta.

Para el caso de la entrega regular ponemos lo siguiente:



Vean el signo ! antes del nombre de la variable en la condición, eso es para el caso en que su valor sea false, indicando que la entrega será regular, el resultado final sea evaluado de true y se vaya por este camino.
El proceso queda de la siguiente manera:



Como ven en cada iteración se va haciendo más comprensible, incluso para el personal no técnico que es la idea que se busca, y va quedando clara cada una de las posibles alternativas que se pueden presentar durante su ejecución.

Hasta aquí esta entrada, cuyo objetivo era mostrarle como definir condiciones y las transiciones entre distintas actividades para darle más sentido al proceso completo.

En la siguiente entrada de esta serie veremos  como definimos los actores que participarán en el proceso y ejecutaremos una primera corrida del mismo.