Introducción al diseño e implementación de un proceso con la herramienta BPMS Bonita. VI

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”.
5. Y como etiqueta “Productos Seleccionados”.
6. 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.

Posibles mejoras a incluir:

• Poder seleccionar varios productos en una misma orden de compra.
• Cargar los datos de los productos ofertados desde una BD, y no como se hace hoy que son estáticos.

Estas mejoras las estaremos viendo en futuras entrada.

---

{ Leer Más }

Título: Introducción al diseño e implementación de un proceso con la herramienta BPMS Bonita. V

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 cuarta 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:

1. Agregué una fila arriba.

2. Arrastre el Widget de nombre de cliente a esa fila.

3. Cree una fila encima de email y arrastré para ella el Widget de numerotelefono.

4. 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:

1. Pondré un validador Email al Widget del correo electrónico,

2. cambiaré los productos ofertados a un seleccionar.

3. Cambiamos 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

---

{ Leer Más }

Introducción al diseño e implementación de un proceso con la herramienta BPMS Bonita. IV

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.

Y 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:

1. Definir ambos grupos al nivel del proceso.

2. 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 no dejen de dejarnos un comentario.

---

{ Leer Más }

Introducción al diseño e implementación de un proceso con la herramienta BPMS Bonita. III

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:

o Aprobar.

o Rechazar.

o 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:

a. “Pagar” cuando el valor de la decisión sea “Aprobar”

b. “Rechazar” cuando el valor de la decisión sea “Rechazar”

c. “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.

Cualquier duda no dejen de escribirnos.

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.

---

{ Leer Más }

Introducción al diseño e implementación de un proceso con la herramienta BPMS Bonita. II

En la entrada anterior  habíamos visto como iniciar el trabajo con la herramienta BPMS Bonita y como se podía modelar un proceso básico usando sus distintos elementos quedando como en la imagen que da inicio a esta entrada.

Para recordar el proceso aquí se les deja nuevamente su descripción.

Descripción del proceso:

El proceso se encarga de permitir que un cliente de una tienda pueda acceder al sitio online de la tienda, seleccionar varios artículos los cuales deben ser aprobados por un empleado de forma manual, esto puede llevar a que el cliente compre los artículos con su tarjeta de crédito, o a que rechace la compra o a que se pida más información sobre los artículos a comprar. Si se ejecuta el pago entonces los artículos serán enviados al cliente en 3 días hábiles y la transacción será archivada, en caso de que se rechace la compra también se archiva la transacción. En cualquier caso se da por terminado el proceso.

En el estado en que quedó el proceso en la entrada anterior aun no es funcional, eso se debe a que no se han definido:

· No se ha definido la forma en que se capturará y se manejará la información.

· Las pantallas que verán los actores y trabajadores de este proceso.

Por lo que en esta entrada nuestro objetivo será mostrar como capturar y manejar la información usando variables dentro del proceso. Para luego en la siguiente entrada ver como se manejan las condiciones y transiciones que determinan el flujo del proceso.

Empecemos.!!!

Las variables se usan para:

1. Capturar información en los formularios de los usuarios, y pueden ser globales cuando esta información se necesita a lo largo de todo el proceso o locales cuando solo se necesitan dentro de una actividad.

2. Definir condiciones o transiciones entre actividades.

Para comenzar el proceso necesitamos una ventana donde se capture información del usuario:

· Nombre.

· Número de teléfono.

· Dirección de correo electrónico.

Para crear las variables que almacenen esta información debemos dar clic en el pool del proceso y luego en la pestaña General, y seleccionar Datos.

Ahí damos clic en Agregar y veremos la siguiente ventana.

Este es el mecanismo que estaremos usando siempre para crear variables.

Y lo llenamos de esta manera para la variable nombreCliente.

Será lo mismo para las otras dos variables.

Y terminaremos viendo lo siguiente:

Ahora bien, como no estamos obteniendo el listado de los productos que el cliente puede comprar de una fuente de datos, o sea dinámicamente, debemos crear una variable que contenga este listado de productos. Así que volvemos a crear otra variable de la siguiente manera:

Cuando llegamos a definir el tipo de dato ninguno cumple con nuestras necesidades así que damos clic en Lista de opciones… y se nos muestra la siguiente ventana.

Damos clic en Añadir y debemos crear nuestra lista de productos. Quedando como sigue:

Damos Aceptar.

Nuestra variable quedaría de la siguiente manera:

Vean que incluso definimos un valor por defecto para este escenario.

Finalizamos y ya tenemos lo siguiente:

Ahora debemos añadir nuevas variables para las actividades de “Más Información” y “Pagar”.

Los pasos son los mismos así que solo les dejo la información a introducir y tengan en cuenta que ahora en vez de seleccionar el pool del proceso como hicimos anteriormente, debemos seleccionar la actividad en la que queremos exista esta variable, pues será una variable local.

Para “Más Información”:

· Variable: comentario.

· Descripción: información adicional introducida por el empleado de ventas.

· Tipo de dato: Texto.

· Multiplicidad: simple.

Para “Pagar”:

• Variable 1: numeroTarjetaCredito.
• Descripción: tarjeta de crédito del cliente.
• Tipo de dato: Texto.
• Multiplicidad: simple.
• Variable 2: fechaExpiracion.
• Descripción: fecha de expiración de la tarjeta de crédito del cliente.
• Tipo de dato: Fecha(Date).
• Multiplicidad: simple.
• Variable 3: escogerEntregaExpress.
• Descripción: si es true se envía express, si es false se envía de forma normal.
• Tipo de dato: Booleano(boolean).
• Multiplicidad: simple.

Quedaría así:

Como se ha podido apreciar toda la información que se maneje dentro del proceso debe ser recopilada en variables, y estas pueden ser tanto globales si es de interés para el proceso en general, o locales si solo interesan a una actividad en particular.

Hemos identificado una restricción en este proceso y tiene que ver con la forma en que obtenemos el listado de productos a mostrar a los clientes. De la forma actual no es eficiente y tendría más sentido que el listado se obtuviera dinámicamente de una BD o servicio web, ya que el mismo puede cambiar en dependencia de la disponibilidad de productos en los almacenes e incluso su información propia como puede ser el precio. Ya esto será objeto de otra entrada más adelante cuando tengamos una primera versión de este proceso funcional y probado.

El objetivo de esta entrada era, como se dijo al inicio, mostrar como la información puede ser capturada en variables, y espero que haya quedado cumplido. Cualquier duda que tengan pregunten sin problema.

{ Leer Más }