Introducción
Los Subprocesos transaccionales son ofrecidos para facilitar la implementación de escenarios de negocio con transacciones cuya ejecución podría durar días o semanas hasta que el conjunto de Actividades se complete.
Desde una perspectiva de negocio, una transacción es un conjunto de actividades que constituyen una unidad lógica de operación que debe realizarse atómicamente (indivisible). Ésta es soportada por un protocolo especial que asegura que todas las partes involucradas tengan acuerdo completo: la actividad debería ser completada o cancelada.
Una transacción o Subproceso transaccional es realizado satisfactoriamente cuando los cambios a ser implementados (actualización, adición o eliminación de registros) son salvados en la base de datos; en otras palabras, la terminación de los cambios se realiza una vez la transacción ha terminado.
Los Eventos de Excepciones o Cancelaciones son lanzados sin afectar la información o integración de la base de datos cuando la transacción no se completó satisfactoriamente. Las transacciones pueden ser cortas o largas dependiendo del tipo de tareas a ser ejecutadas, que pueden ser automáticas o manuales.
Las transacciones de larga duración modeladas con BPMN tienen tres posibles salidas:
•La primera salida se presenta cuando todas las actividades del proceso son ejecutadas satisfactoriamente, en este caso, el proceso continúa por el flujo normal.
•La segunda salida se presenta cuando ocurre una falla y es necesario reversar las Actividades que ya fueron completadas dentro del proceso. Esto se realiza a través de la compensación de actividades. Cada actividad que necesite compensación tiene una actividad asociada a ella. La compensación es ejecutada cuando es necesario retornar al estado inicial de algo y solo es realizada cuando una actividad ha terminado de forma exitosa.
•La última salida ocurre cuando se presenta un error inesperado, las Actividades del Subproceso transaccional son interrumpidas sin realizar ninguna compensación y el Proceso continúa con la ejecución del Evento intermedio de error.
Para modelar un Proceso transaccional es necesario adjuntar los eventos de Error y de Cancelación al Subproceso. Si alguno de los dos eventos ocurre, el flujo del proceso podrá continuar.
El borde de la figura del Subproceso transaccional se muestra con una doble línea.
Figura Subproceso transaccional
Modelado de un Subproceso transaccional
Imagine un Proceso de traslado de fondo entre cuentas, el cual es un ejemplo típico de transacciones.
El débito se realiza en una cuenta y el crédito se realiza en otra cuenta. Las acciones de debitar y acreditar se realiza a través de una interfaz que utilizan los dos bancos de forma independiente.
El débito debe ser reversado si ocurre un problema (número de cuenta erróneo, cliente inactivo, etc.) y la ejecución de una acción es requerida para reversar o compensar la transacción. Es este caso la transacción se termina sin realizar transferencia de fondos.
El diagrama del proceso será:
El proceso de traslado de fondos puede tener tres salidas diferentes: la normal, cancelación y excepción.
Normal
En el flujo normal del proceso las operaciones de crédito y débito se realizan de forma correcta. Bizagi guarda los cambios realizados en la base de datos (se realiza commit) y el proceso continúa por el flujo normal, este escenario considera que la transacción ha sido realizada de forma exitosa.
En la imagen de abajo, el proceso realiza las transferencias de fondos utilizando una interfaz implementada con Servicios Web, la cual debita una cantidad y acredita otra. El proceso continúa por el flujo normal, es decir, la actividad Activar Crédito se realiza tan pronto el Proceso transaccional termina de forma correcta.
Cancelación
El Evento de Cancelación es activado cuando ocurre una falla y se lanza una excepción (se realiza la cancelación). En este caso, el Proceso ejecuta las actividades de compensación requeridas y abandona el Subproceso transaccional ejecutando el flujo de cancelación. Los datos modificados durante la ejecución del Subproceso no serán guardados en la base de datos; por lo tanto, el proceso será reversado a la etapa anterior a la ejecución del Subproceso.
Los siguientes flujos de proceso ayudan a entender el evento de cancelación.
1.Una cuenta se debita de forma exitosa por medio de la ejecución de una interfaz.
2.El crédito a la cuenta del cliente se intento, pero el número de cuenta esta erróneo por lo que la operación fue rechazada. La segunda interfaz genera un error y el Evento de Cancelación es lanzado.
3.Bizagi ejecuta las actividades de compensación en orden contrario a como fueron ejecutadas. En este caso solamente la actividad Compensar Débito es actividad de compensación y es la encargada de deshacer lo ejecutado en la tarea Débito, por lo tanto, una interfaz tiene que acreditar la cantidad previamente debitada.
4.La suspensión del crédito se realiza por que la transferencia de fondos no puedo ser completada.
|
Los eventos de cancelación solo pueden ser definidos para Subprocesos transaccionales. |
Actividades de compensación
Las Actividades de compensación deben restaurar la información que fue cambiada en las actividades que fueron ejecutadas de forma satisfactoria. Usualmente las Actividades de Compensación son realizadas a través de un sistema externo. Las Actividades de Compensación son creadas utilizando el Evento Intermedio de compensación:
Excepción
Un error de excepción en lanzado cuando existe un error que no puede ser manejado por el Subproceso transaccional el cual no permite que el Subproceso continúe; las actividades son interrumpidas sin compensación. La información de la base datos es restaurada a su estado inicial (rolled back) y el Proceso continúa por el Evento Intermedio de Error. El manejo de la excepción se realiza utilizando el Evento de Error Intermedio.
Los siguientes flujos de proceso ayudan a entender el evento de cancelación:
1.Se trata de realizar un débito de la cuenta del cliente, sin embargo el servidor no responde. La interface genera un error y el Evento de Error es lanzado.
2.La transferencia se realiza por teléfono y la transacción es concluida.
|
Tenga en cuenta las siguientes consideraciones: •Las interfaces externas deben ser compensadas adecuadamente cuando se ejecutan en un proceso para realizar modificaciones en datos externos a Bizagi a través de Servicios Web o de Librería de componentes. Se deben evitar actividades que realicen reversiones en muchos casos porque la actividad no sabrá cuales fueron satisfactorias y cuales deben ser revertidas de nuevo. •Los eventos de error solo pueden ser definidos en Subprocesos transaccionales. |
Last Updated 7/16/2024 10:01:01 AM