Antes y después de GXflow en GeneXus Rocha

Quiero aprovechar la oportunidad para reflexionar sobre GXflow y en este caso comparar el antes y después que tendremos a partir de la versión Rocha de GeneXus donde obviamente se abre un nuevo camino en cuanto a productividad y flexibilidad para el desarrollo basado en procesos.

¿Qué tenía que hacer hasta hoy para desarrollar un sistema basado en GXflow?

• Modelar el proceso por fuera de GeneXus
• Pensar que objetos son necesarios desarrollar para asociar a cada actividad en el diagrama
• Dichos objetos debían recibir ciertos parámetros fijos
• Las condiciones necesariamente se debían resolver asociando un procedimiento a las mismas
• Tenía que setear los datos relevantes usando APIs, por ejemplo si el primer paso es dar de alta una orden de compra entonces tenía que setear ese dato para que en la siguiente tarea a través del API pudiera recuperar ese valor e instanciar esa orden
• A medida que se iba desarrollando se debía asociar desde el modelador los objetos a cada nodo del diagrama.
• Una vez que se tienen todos los objetos (o al menos cada nodo con algo asociado) se podía impactar y comenzar a prototipar.
• Es decir, era necesario ser mucho más consciente de lo que tenía que hacer para poder desarrollar una aplicación basada en Workflow, pues a la hora de desarrollar en GeneXus tenía que tener en cuenta si el objeto se utilizaría o no dentro de un proceso.

¿Qué gano hoy con la integración de GeneXus Rocha y GXflow?

• El modelado de procesos es parte de la KB, es decir se agrega más conocimiento de alto nivel sobre el negocio en la propia KB
• A priori no es necesario ser consciente cuando estoy modelando mis reglas de negocios a través de las transacciones u otros objetos si los mismos serán utilizados o no en un proceso de Workflow.
• Al realizar un Drag & Drop de un objeto sobre un diagrama de actividades GeneXus me asegura que la invocación de ese objeto por parte del motor será posible sin tener que realizar ninguna programación adicional.
• Automáticamente al “tirar” un objeto en el diagrama se estarán mapeando los parámetros del objeto como datos relevantes para el proceso
• Puedo expresar condiciones a través de un editor que permite describir las reglas de transición en base a los atributos y datos relevantes.
• Se cuenta con todas las funcionalidades de “cross-reference” dado que los diagramas son un objeto más de la KB
• Proceso de build integrado lo cual permite hacer un Run del diagrama y que en ese momento ocurra todo lo necesario para poder ejecutar el diagrama, desde el impacto del proceso en la metadata hasta la generación y compilación de los objetos asociados al mismo.
• El GXflow Prototyper que permite ejecutar rápidamente el diagrama de manera de ir realizando el prototipado incrementalmente. Es decir, a medida que voy armando el diagrama puedo ejecutarlo simplemente con la función F5
• El motor y cliente de GXflow será un componente externo a la KB por lo cual no pesará en el proceso de build de la misma
• Es decir, nos podemos concentrar en modelar mejor nuestras reglas de negocio y procesos y no tanto en los aspectos técnicos para hacer funcionar nuestras aplicaciones basadas en Workflow.