Perspectivas en el Modelado BPMN

Cuando iniciamos un proyecto BPM, una de las actividades que debemos abordar es el modelamiento. Durante esta tarea, es importante entender y convivir con la presencia de diversas perspectivas y el grado de ambigüedad presente en cada etapa del modelado.

El proceso de modelado debe reducir la ambigüedad del diagrama adaptándose a las diversas perspectivas que introduce su análisis. Para aclarar este punto:

Niveles en el modelado

1. Diagrama nivel 0: Este modelo contiene un solo pool (participante), y en las actividades se describen los actores, entradas y salidas. En este nivel, podemos modelar un proceso de negocio solo con dos tipos de artefactos gráficos: actividades y bifurcaciones.
2. Diagrama nivel 1: Este modelo contiene diversos pools que representan los roles en un proceso. En este momento, es importante entender la diferencia entre orquestación y coreografía. En líneas generales debemos centrarnos en la orquestación, donde un pool ejecutable orquesta todas las interacciones entre los participantes.
3. En los siguientes niveles, debemos detallar las reglas de negocio requeridas en el modelado; por ejemplo: actividades de escalamiento, control de variables, captura de excepciones de negocio, condiciones para cancelar un proceso, ciclo de vida, etc.
   

Cuando trabajamos en un proyecto BPM con un proveedor, puede existir la tendencia de entregar como insumo para su automatización el diagrama de nivel 0 o nivel 1, pero esta aproximación tiene claras desventajas, que pueden poner en riesgo la ejecución del proyecto.

Desventajas

1. Existe un grado importante de ambigüedad en el proceso de negocio modelado.
2. No se utilizan todas las potencialidades de modelamiento necesarias para disminuir el grado de ambigüedad.
3. El cliente no garantiza el cumplimiento de los estándares mínimos de modelado de proceso.
4. El conocimiento de modelado no lo tiene la empresa, sino el proveedor de TI...
   

El mensaje

Es importante entender que el proceso de modelado debe adaptarse a las perspectivas y análisis. Un analista de proceso, tiene una perspectiva distinta a un arquitecto o desarrollador. En BPMN existen todos los artefactos gráficos (notación grafica), requeridas.

Diversas perspectivas, introducen diferentes niveles de modelado, la clave es que esta experiencia no se separe para ir desarrollando un marco de patrones de modelado.

Taller de Intalio BPP en Venezuela Cantv

Hace algunos días, tuve la oportunidad de dictar un taller de Intalio BPP, en Cantv, con integrantes de la Plataforma de Integracion Corporativa, Proyecto IPTV, y el proyecto convergencia. El primer día conversamos sobre los estilos de arquitectura SOA y ESB como estrategia para proporcionar mayor agilidad operativa en una plataforma de TI. El mensaje primordial, es que existe una relación muy estrecha entre estos estilos de arquitectura y BPM.

Ambos estilos aceleran, sustentan y aseguran la aplicacion de practicas que garanticen el éxito de una implantación BPM. Otro elementos importante fue dar a conocer las diversas disciplinas que comprenden BPM, su relación y las mejores practicas.

Luego, conversamos sobre la necesidad de contar con un framework de patrones para el modelado de procesos, que fortalezca las técnicas necesarias para utilizar todo el universo de elementos graficos de la notación BPMN. Se requieren patrones por ejemplo para:

1. Manejo de excepciones
2. Manejo de timeouts.
3. Manejo de reintentos.
4. Manejo de variables
5. Manejo de interacciones.
6. Tecnicas para la reutilizacion de procesos.
   
7. Tecnicas para el manejo de correlaciones.
   
8. Tecnicas para el manejo de reglas de negocio.
9. etc.

Estos son los temas generales que abordamos en el taller:

1. Introducción a SOA
2. Introducción a ESB
3. Introducción a BPM
4. Disciplinas de BPM.
5. Armando el rompecabezas de TI.
   
6. Notación Gráfica BPM (tareas, pools, lanes, eventos, etc.)
7. Practicas generales de Modelamiento (joins, sincronizacion, paralelos, etc.)
8. Casos prácticos para el modelado de procesos.
9. Orquestacion de Servicios.
10. Orquestacion de Procesos.
11. Practicas de BPMN
12. Introduccion a Intalio|BPP (componentes y estándares soportados).
13. Intalio|Designer.
14. Componentes de un proceso (contexto, eventos, bifurcaciones, etc.).
15. Procesos ejecutables.
16. Otros.
    

Saludos;

Looping Subprocess en Intalio BPMS - BPMN

El "looping subprocess" son subprocesos que pueden ser iterados, basado en condiciones que limitan el numero de iteraciones requeridas, generalmente llamados bucles. En este post, podemos ver los criterios necesarios para utilizar un subproceso con actividades que requieren ser iteradas un numero de veces, y la utilizacion de expresiones Xpath para acceder a los datos (nodos) que comprenden un array.

En este ejemlpo, tenemos un web services expuesto por Mule ESB, el cual retorna un maestro detalle. Es necesario iterar cada nodo del array, e invocar otro servicio.

Para poder iterar, debemos establecer las condiciones para limitar el numero de iteraciones. Específicamente, en el ejemplo utilizamos la funcion Xpath count() para obtener en numero de nodos, y almacenarlos en una variable.

Establecemos las condiciones que limitaran el numero de iteraciones en el bucle.


Mapeamos la salida,


Para finalizar, existen actualmente tres tipos de bucles: For Each, While y Repeat Until, las cuales se utilizan en las siguientes condiciones:

1. Iterar un subproceso hasta que se cumpla una condición (While).
2. Iterar un subproceso hasta que se cumpla una condición (Repeat Until).
3. Iterar un subproceso un numero de veces (contador inicial, contador final) (For Each).

Fallas, Excepciones y Compensacion II

Actualmente existen tres tipos de mecanismos para gestionar errores en un proceso de negocio: Transacciones, Excepciones, y Compensaciones. Estos tres mecanismos, trabajan juntos para evitar que los procesos fallen.

Este esquema se basa en el principio transaccional basado en el modelo “todo o nada”, ofreciendo flujos o rutas (paths) alternativos cuando se producen excepciones, las cuales pueden desencadenar acciones compensatorias para deshacer las operaciones fallidas.

Transacciones: Una transacción, es una secuencia de operaciones agrupadas en una unidad indivisible, en la cual se ejecutan todas las tareas o ninguna. Si una tarea, se encuentra dentro de una transacción y esta no puede ser ejecutada, todas las tareas anteriores que ya han sido ejecutadas deben ser devueltas a su estado original. En un diagrama del proceso (notación BPMN), se utiliza el sub-proceso para agrupar las actividades dentro de una transacción.

Manejo de Excepciones: Una excepciones de negocio reorienta el flujo o ruta del proceso cuando se detecta una excepción. Por ejemplo, una tarea que debe realizar una operación de debito, pero la cuenta carece de fondos suficientes. Como resultado de ello, una excepción puede ser lanzada, y el flujo del proceso es afectado. En un diagrama del proceso, el manejo de excepciones se realiza adjuntado una excepción a un sub-proceso, conectándola con una actividad que la manejara, para luego retornar a su ruta normal, sino finaliza el proceso antes esta condición.

Compensaciones: Las compensaciones establecen reglas para deshacer tareas si una tarea falla. Por ejemplo, una tarea recibe una transacción y es completada. Posteriormente, sin embargo, una tarea relacionada no se ejecuta. La tarea de compensación asociada a la primera actividad se ejecuta, restituyendo la transacción. La compensación no se ejecuta si la tarea no tiene asignada una excepción.

Este es un ejemplo donde podemos ver la secuencia o ruta del proceso ante diversos escenarios:

Descripción de Secuencia

Sin Excepcion

1. La Tarea A se ejecuta y completa.
2. La Tarea B Falla, debido a una excepcion de negocio.
3. El proceso de negocio falla porque no hay un manejo de excepciones configurado para el subproceso AB.
   

Con Excepcion

1. La Tarea A se ejecuta y completa.
2. La Tarea B se ejecuta y completa.
3. La Tarea C se ejecuta y completa.
4. La Tarea D Falla, debido a una excepcion de negocio.
5. Se ejecuta la Excepcion 1, y luego el proceso de negocio, sigue su ruta (no falla el proceso, porque se considero una excepcion).
   

Con Compensacion

1. La Tarea A se ejecuta y completa.
2. La Tarea B se ejecuta y completa.
3. La Tarea C se ejecuta y completa.
4. La Tarea D se ejecuta y completa.
5. La Tarea E se ejecuta y completa.
6. La Tarea F se ejecuta y completa.
7. La Tarea G Falla, debido a una excepcion de negocio.
8. Se ejecuta la actividad de Compensacion 1.
9. A pesar que la tarea de compensacion 1 se ejecuta, el proceso de negocio falla. Para evitar este comportamiento, podemos incluir todas estas actividades dentro de un subproceso.
   

Saludos;

Fallas, Excepciones y Compensacion I

Uno de los elementos más importantes, dentro de la notación BPMN es el manejo de excepciones de negocio, fallas, y operaciones de compensación. Actualmente existen diversos tipos de excepciones que pueden ser modeladas con la notación BPMN.

Existen tres tipos de excepciones:

Fallas Técnicas: Estos son eventos que se generan fuera del contexto de ejecución de un proceso de negocio; el cual puede causar que el proceso no este disponible. Ejemplo de este tipo de fallas: mal funcionamiento del disco, errores de CPU, etc. Por su naturaleza, este tipo de fallas técnicas generan la interrupción del proceso de negocio.

Excepciones Temporales: Estos son eventos temporales que pueden ser resueltos con el tiempo. Por Ejemplo: la red no esta disponible, servicio web no disponible, o base de datos no disponible. En estos casos, el proceso será suspendido después de una serie de intentos fallidos y, a continuación, el proceso puede reanudarse manualmente una vez que el problema ha sido resuelto. En este tipo de eventos, el proceso puede realizar el rollback de cualquier actividad, o intentar una acción para un número especifico de veces. Si los reintentos no tienen éxito, el proceso puede ser suspendido (pero no finaliza).

Excepciones de Negocio: Este tipo de excepciones suelen estar relacionados con datos, por ejemplo: código ciudad no valido, número de cuenta no valido, fondos insuficientes para esta transacción, etc.

En el próximo post, hablaremos de las herramientas que tenemos en la notación para representar este tipo de excepciones.

Intalio Eventos Multiples

Como hemos descrito en notas anteriores, un evento es algo que afecta el flujo de ejecución de un proceso de negocio. Según la notación BPMN tenemos tres tipos de eventos inicio, intermedios, y fin. En este ejemplo podemos ver diversos tipos de eventos.

Primero, podemos ver la utilización de un evento denominado “múltiple intermediate event”, que opera como un gateway exclusivo basado en eventos. En este tipo de gateway, solo un evento podrá ejecutarse. En nuestro diagrama utilizamos un evento intermedio o timer. Cuando el mensaje es recibido antes de una fecha determinada, el proceso continua su ejecución normal (Tarea G), de lo contrario se ejecuta la tarea F y se lanza un error.

Por ultimo, podemos ver un ejemplo de la utilización de un “messages end event”, para enviar un mensaje al participante que ejecuta la tarea C.

Manejo de Eventos Intermedios Timer en Intalio

En el post anterior, un amigo realizo algunas preguntas relacionadas con el control de tiempos. La notación BPMN, introduce un símbolo para el manejo de eventos timers, también conocidos como temporizadores. En la notación, se les conoce como “Timer Intermediate Event”.

Los timer intermediate Event, o eventos intermedios de tiempo, se utilizan para controlar el tiempo de una actividad ejecutada por un participante humano o por un servicio (Web Services). Con frecuencia se utilizan, para tareas de escalamiento, notificaciones y cancelación de procesos.

Un ejemplo de este tipo de operaciones: si una actividad no se ejecuta en un periodo de tiempo, podemos romper el flujo o ruta de proceso normal, para cancelar una orden de servicio, o notificar a un cliente. Se pueden utilizar expresiones timers como : PT20S que establece 20 seg, PT50S establece 50 seg y PT2M establece 2 min.

En el ejemplo, tenemos un subproceso que ejecutar dos actividades, adiciono un timers para controlar el tiempo y así permitir que se dispare un evento: “si el tiempo de ejecución del subproceso sobrepasa un valor, ejecuto la actividad Timeout”.