Transaccional
De
<keywords content="keywords"> transacción, transaccional, transacciones, transacciones de larga duracion </keywords>
Contenido |
Subproceso Transaccional
La procesos 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 compete.
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 lanzadas 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.
|
Ejemplo: Un ejemplo de una transacción típico es el traslado de fondos entre cuentas, este traslado puede estar dado por la ejecución de dos servicios web diferentes, uno que debita y otro que acredita la otra cuenta; si el segundo servicio web tiene algún problema (número de cuenta errado, cliente inactivo, etc.) el débito ya fue realizado por el primero y es necesario reversarlo. Este proceso de reversión, o compensación, puede consistir en la ejecución de un nuevo Servicio Web que le avise al sistema externo para que acredite de nuevo la cuenta y esta no se vea afectada. |
Con el estándar BPMN se tiene gran versatilidad para modelar estas situaciones de negocio, ofreciendo un conjunto de reglas para su representación gráfica, permitiendo reflejar de una manera más natural el enrutamiento del proceso cuando la transacción no es finalizada con éxito.
Artículos Relacionados: Cómo modelar un Proceso Transaccional
Configuración de Subprocesos Transaccionales o Transacciones
La propiedad “Transaccional” se configura en las propiedades Bizagi de la figura subproceso, en la pestaña de propiedades globales. Al definir esta propiedad en un subproceso el borde de la figura se visualizará con doble línea para indicar gráficamente que este es transaccional.
Para más información acerca de la notación de subprocesos transaccionales ir a BPMN, o Figuras
Ejemplo de Traslado de Fondos para desembolso:
Después de realizar la aprobación del crédito y la autorización en el banco para realizar traslado el subproceso de traslado de fondos realiza el débito de la cuenta de la entidad y el correspondiente crédito en la cuenta del cliente. Estos procesos de interface con el banco se realizan mediante Servicios Web que realizan las transacciones de manera independiente. El diagrama para este proceso sería el siguiente:
El proceso de traslado de fondos puede tener tres salidas diferentes: la normal, cancelación y excepción.
Camino Normal: Cuando una transacción es completada exitosamente Bizagi guarda los cambios ejecutados en la base de datos (se hace commit) y continúa con la secuencia del flujo normal del proceso que lo invoca.
|
Ejemplo: En la gráfica el proceso de Solicitud de Crédito realiza el traslado de fondos del desembolso usando una interface implementada con Servicios Web que debita el valor de las cuentas de la entidad y acredita la del cliente. Debido a que el proceso transaccional se realizó correctamente el proceso continua con su flujo normal activando el crédito. |
Evento Intermedio de cancelación : Este evento ocurre cuando se presentan fallas y es enviada una excepción de cancelación, el proceso ejecuta las actividades de compensación requeridas para cada una de las tareas del subproceso y sale del subproceso ejecutando el flujo de cancelación. Los datos que fueron modificados dentro del subproceso no son almacenados en la base de datos y por tanto el proceso quedará en el estado que se encontraba antes de iniciarse dicho subproceso. Es necesario aclarar que la primera actividad de la salida de cancelación tiene acceso a los datos antes de ser reversados a su estado original, esto permite mostrar información de resultado que indique al usuario la razón de la cancelación, una vez termine esta salida los datos son reversados al estado original.
|
Ejemplo: El siguiente flujo clarifica el funcionamiento de los eventos de cancelación: 1. Se realiza exitosamente el débito de la cuenta del establecimiento mediante la ejecución de un Servicio Web. 2. Se intenta realizar el crédito de la cuenta del cliente, pero el número de cuenta está errado y es rechazado por el servicio web generando un resultado 101 (Error que indica cuenta inexistente), la regla de la tarea "Acreditar" se detecta el código 101 y se dispara el evento de cancelación. 3. Bizagi ejecuta en orden inverso todas las actividades de compensación, para este caso solo hay una asociada a la tarea debitar y se llama "Compensar Débito". Esta tarea "compensa" la transacción realizada por la tarea "Debitar" ejecutando un Servicio Web acreditando la cuenta del establecimiento por el valor correspondiente quedando "reversada" la operación. Debido a que solo hay una actividad de compensación Bizagi inicia el camino de Cancelación que inicia con "Suspender Crédito" 4. En esta operación se realiza la suspensión del crédito debido a que no se pudo realizar el traslado de fondos, posteriormente. |
 |
Evento Intermedio de Error: Cuando ocurre un error dentro del subproceso transaccional que no permite que continúe, es enviada una excepción de error, las actividades son interrumpidas (sin compensación), la información de la base de datos de Bizagi es restaurada a su estado inicial (rolled back) y el proceso continúa por el evento intermedio de error. Si dentro de la transacción son afectados datos de un sistema externo, al ser enviada la excepción de error la información de este sistema no es restaurada a su estado inicial.
|
Nota Cuando se diseñe un proceso que tengan interfaces externas, ya sea mediante Servicios Web o librerías de componentes, que realicen modificaciones sobre datos externos a Bizagi estos deben ser compensados de manera adecuada, definiendo en la tarea de compensación de la tarea su reversión correspondiente. Debe evitarse hacer actividades que realicen la reversión de múltiples pasos en una sola actividad, esto debido, principalmente, a que esta actividad no tiene "conocimiento" de las actividades que realizaron exitosamente y por tanto deben ser reversadas. En el ejemplo la actividad de débito debe tener una tarea de compensación que reverse este débito y el crédito una de compensación que realice su reversión, debe evitarse crear una actividad de compensación en el débito que realice la compensación del debito y el crédito, ya que para esta tarea sería imposible saber si el crédito fue realizado correctamente o no. La regla general es, la reversión de agentes externos debe realizarse mediante actividades de compensación asociadas a la tarea que realizó la acción, no deben usarse tareas normales para esto ya que alteran el flujo normal y tampoco deben realizarse en la actividad de salida del subproceso ya que esta no es la función de esta tarea. |
 |
Las actividades de compensación son usadas para poder realizar reversiones sobre datos no controlados por Bizagi, por ejemplo Servicios Web que se hayan ejecutado o interfaces sobre otros sistemas realizadas mediante componentes de librería. Estas actividades solo deben usarse en subprocesos transaccionales, y solo tendrán utilidad en estos.
Las actividades de compensación se crean usando el evento intermedio de compensación:
Simplemente arrastre el evento de compensación hacia la actividad a ser compensada y luego la tarea que desea usar como compensación: Manual, Servicio o Subproceso (no transaccionales y sin múltiples instancias).
|
Nota: No olvide que la actividad de compensación debe restaurar el estado de los sistemas externos afectados por la actividad a ser compensada, no debe realizarse modificaciones sobre datos de otras actividades diferentes a ésta. |
En caso que los Servicios Web que realizan el débito y el crédito retornan una respuesta de acuerdo a si la transacción fue exitosa o no, esta respuesta seria 0 (cero) en caso de éxito o un número diferente de 0, con el código de error, en caso contrario. El proceso puede usar esta respuesta para decidir si ejecuta la cancelación de las actividades del proceso y por tanto realiza la reversión y compensación de los datos modificados, para ello se usa la figura de cancelación:
El proceso modificado para lanzar la cancelación se vería de la siguiente forma:
|
Ejemplo: En el ejemplo si el Servicio Web de Acreditar retorna un código de error, se en ruta por la figura de Cancelación (Evento de cancelación). Bizagi busca todas las actividades que tengan compensación, y empieza a ejecutar sus tareas de compensación. Finalmente ejecuta el flujo de Cancelación que inicia con la tarea "Mostrar reporte". Una vez que esta tarea finaliza realiza la reversión de los datos modificados por el subproceso retornando el proceso padre al estado original. |
|
Nota: Las excepciones de cancelación o error también pueden ser enviadas a través de reglas de negocio. Ver lanzar cancelación o excepción mediante API. |
Cómo se visualizan los subprocesos transacciones cuando es enviada una excepción de cancelación o error
Los subprocesos transaccionales en los que se envió una excepción de cancelación se visualizan en la web de la siguiente manera.
Los subprocesos transaccionales en los que se envió una excepción de error se visualizan en la web de la siguiente manera.
Si el usuario le da clic en el link del número de radicación en los dos casos, se despliega una pantalla que indica que el proceso fue cancelado por excepción o compensación.
<comments />
