¿Cómo desarrollamos aplicaciones basadas en Workflow con GeneXus Evolution 2?

Notas del editor

• #3: Desde el punto de vista de la empresa los beneficios de automatizar procesos de negocio son muchos pero también lo son desde el punto de vista del desarrollo pues nos da mucho mas productividad y en definitiva logramos darle a nuestros clientes una solución que realmente aporta valor al negocio.Nosotros vemos que la adopción de BPM y Workflow en el desarrollo de los sistemas en general es mucho más bajo de lo que estiman consultores como Gartner y creemos que en definitiva estamos perdiendo una oportunidad de aportar más valor a las empresas para las cuales trabajamos.Mi objetivo en esta charla es mostrarles que desarrollar sistemas basados en BPM no es ingeniería espacial y que los beneficios que nos trae esto tanto para la empresa como para el proceso de desarrollo realmente valen la pena.Para esto mi idea es mostrarles como es el ciclo de modelado, desarrollo, prototipación y test.
• #4: La disciplina de BPM propone un ciclo de mejora continua donde primero debemos entender la realidad y modelarla, luego automatizar aquellos procesos que sean automatizables para obtener un sistema que nos guie en la ejecución de los procesos y con la información estadística que esto nos deja poder analizar que cosas podemos mejorar.Desde el punto de vista del ciclo de vida de desarrollo lo que vamos a hacer es un ciclo incremental de la misma forma que hacemos el desarrollo con GeneXus pero agregamos una etapa previa de modelado de los procesos que luego en la etapa de desarrollo se completará asociando los distintos programas que participaran de dichos procesos. Vamos a ver a continuación cada una de estas etapas cómo las vamos realizando y con qué herramientas contamos para que al final del camino tengamos nuestro proceso de negocio automatizado.
• #6: Para modelar los procesos contamos con el BusinessProcessDiagram, se trata de un objeto GeneXus que nos permite dibujar los diagramas de los procesos de negocio que estemos modelando.Esta basado en el estándar de notación gráfica BPMN 2.0 lo cual además de darnos un lenguaje visual entendible por cualquier usuario nos da un lenguaje común del cual hoy se cuenta con una variedad interesante de bibliografía, si buscan en Amazon van a encontrar varios libros que hablan del tema.Esto nos permite entonces tener un nivel de abstracción muy alto para representar los procesos y documentarlos para que luego en la etapa de desarrollo se complete dicho modelo con los programas que vamos a invocar en cada paso del proceso.Otro elemento importante de este modelador es que soporta la posibilidad de exportar e importar diagramas en formato XPDL que es el estándar para intercambio de este tipo de diagramas entre herramientas de modelados de proceso.
• #8: En la demo previa vimos como modelar dentro del propio IDE de GeneXus, una novedad que tenemos sobre este tema es que ya tenemos disponible la primera beta del GeneXus Business ProcessModeler que básicamente se trata de una herramienta enfocado en poder modelar procesos y hasta poder usarla conectada al ambiente de producción para impactar los cambios que se hagan a nivel de los procesos.Esta herramienta se distribuirá gratuitamente y ya la pueden bajar desde esa URL y los invito a la charla de mañana donde se mostrará en detalle el funcionamiento de este modelador.
• #10: Al igual que el desarrollo de cualquier aplicación con GeneXus se trata de un ciclo incremental donde la velocidad en poder obtener prototipos funcionando rápidamente aporta valor no sólo a la agilidad en el desarrollo sino a la calidad final que vamos a obtener.El cambio fundamental en el paradigma de desarrollo cuando estamos automatizando un proceso de negocio es que logramos separar la lógica que es propia de la aplicación de la lógica que se encarga del control del flujo de los procesos dado que esto último esta expresado en los diagramas y en ejecución va a ser interpretado por un motor de Workflow. Esto hace que el proceso de desarrollo se acelera dado que logramos resolver muchas cosas de manera declarativa y el código de nuestras aplicaciones queda mucho mas “limpio” y por lo tanto mucho más entendible y a futuro mucho más mantenible.Otro aspecto importante es que vamos a poder reutilizar programas que están siendo usados desde otros lugares de mi sistema sin siquiera tener que modificarlo o cambiarles parámetros lo cual nos da una grado de reutilización muy bueno.
• #12: Además de contar con el cliente web que vimos en la demo, contamos con acceso al API de Workflow que nos da acceso a interactuar con todas las operaciones posibles del motor de Workflow.Por lo tanto podemos construir nuestra propia interfaz y hacer nuestra propia bandeja de entrada o cualquiera de las otras opciones disponibles del clientes de GXflow.Para facilitar esta tarea ya damos varias opciones para que no partan desde cero, una de ellas es el User Control GXflow Entry Point que les da la posibilidad de embeber en sus webpanels el inbox, outbox y las demás opciones que pueden acceder desde el cliente de GXflow.Por otro lado si quieren hacer su propia interfaz web totalmente diferente a lo que ofrece el GXflow Client les damos un XPZ con una serie de ejemplos de como armarlos a esto le llamamos el CustomClient Web. Y lo mismo tenemos para el caso de que quieran hacer su interfaz de bandeja de entrada y salida para Smart Devices.Veamos algunas de estas cosas en funcionamiento.
• #13: A través de la Workflow API se puede acceder a todos los métodos para interactuar con el motor de Workflow. Se trata de un tipo de datos en GeneXus que se habilita una vez que se comienza a modelar el primer Business ProcessDiagram en la KB.En la captura se muestra como esta programado el evento load del Inbox que viene en el XPZ del CustomClient.
• #15: Una vez que hemos avanzado en el desarrollo y tenemos asociados los programas a cada paso del proceso y hemos pasado los test unitarios estamos en condiciones de hacer pruebas en un ambiente mas parecido a lo que va a ser el ambiente de producción.Para esto necesitamos definir diferentes usuarios y asociarles los diferentes roles que actúan durante el proceso y de esta forma poder probar la ejecución del proceso desde el inicio hasta su fin. En caso de que el proceso sea usado en diferentes sucursales es recomendable que se configuren en las Unidades Organizacionales en la metadata del Workflow para representar estas sucursales y los usuarios que van a participar de estas y así poder probar el proceso en diferentes sucursales.Además en esta etapa se debe preveer pruebas de stress para evaluar la performance general simulando una carga similar del sistema funcionando en producción. Esto nos servirá para dimensionar los servidores para el ambiente de producción.
• #18: Para la puesta en producción de los procesos de negocio contamos con el Business ProcessDeployer el cual nos permite crear, inicializar la base de datos de Workflow además de impactar los procesos de negocio modelados.Luego de hacer el deploy de la aplicación GeneXus se usa esta herramienta para realizar el deploy de los procesos.Tenemos la posibilidad de indicar en cada impacto si queremos generar una versión nueva de los procesos que ya están impactados en la base de Workflow o si queremos sobreescribir los existentes. En caso de generar una versión nueva, los procesos que ya estuviesen ejecutando van a seguir haciéndolo con la definición anterior del proceso y las nuevas instancias lo harán basadas en la nueva versión.Como ya vimos un usuario con rol de administrador puede visualizar como esta el estado actual de cada proceso y tarea y actuar para reasignar y delegar trabajo. A través de los diferentes dashboards puede tener información que le permita controlar y actuar en el balanceo de las cargas de trabajo.