Caso de uso: Exception Handler en transacciones financieras

• Contexto

• Regla de negocio

  • Diccionario técnico

• Escenario sin Exception Handler

• Escenario con Exception Handler

• Configurando el Exception Handler en la práctica

  • Status code 422: Unprocessable Entity

  • Status code 400: Bad Request

  • Agregando Exception Handler en el componente

  • Resultado de la ejecución

Contexto

Imagina que el sector financiero de una empresa necesita confirmar si cada transacción procesada por el sistema de pagos fue realmente completada con éxito.

Para ello, cuenta con los siguientes aliados: la API del banco (módulo REST), la base de datos y Skyone Studio.

Sabemos que, en cualquier operación, pueden surgir imprevistos, como fallos de autorización de pago o información inconsistente. Sin embargo, para el sector financiero, es crucial garantizar la verificación de cada transacción, asegurando que los pagos sean procesados correctamente y que el equipo sea notificado en caso de errores, lo que facilita el seguimiento y optimiza la gestión de las operaciones.

En esta documentación explicaremos cómo utilizar el recurso “Exception Handler” para manejar escenarios en los que el flujo de integración debe continuar, incluso si algunos ítems presentan errores. Además, veremos cómo notificar adecuadamente los errores ocurridos durante la ejecución.

---

Regla de negocio

• Cuando el módulo REST retorne el status code 422, significa que la información es inconsistente.

• Cuando el módulo REST retorne el status code 400, se espera que la ejecución sea finalizada.

---

Diccionario técnico

• HTTP Status code 422: Unprocessable Entity

• HTTP Status code 400: Bad Request

Escenario sin Exception Handler

Aunque el status code indique un error, Skyone Studio, por defecto, no lo considera como tal en casos de REST. De esta manera, la transacción se inserta en la base de datos de pagos completados, generando una inconsistencia con la información real.

Escenario con Exception Handler

Con la funcionalidad “Exception Handler”, cualquier error de HTTP será capturado y gestionado. Al crear dos Exception Handlers independientes, se puede diferenciar el tratamiento: en caso de error 422, el sistema simplemente pasa a la siguiente transacción de la lista, mientras que, en caso de error 400, el flujo se interrumpe.

Configurando el Exception Handler en la práctica

Observa en la imagen que tenemos un flujo compuesto por:

• Webhook Trigger: punto de partida y entrada de la lista de transacciones que será procesada.

• Loop For: módulo herramental que facilita el procesamiento de listas.

• Módulo REST: valida la transacción bancaria recibida como elemento del Loop.

• PostgreSQL: registra los pagos completados.

Al hacer clic en “Exception Handlers”, seleccionamos “Adicionar Exception Handler”. Se mostrará la siguiente pantalla:

De acuerdo con las reglas de negocio mencionadas anteriormente, vamos a agregar 2 Exception Handlers:

Status code 422: Unprocessable Entity

En “Configuraciones generales del Handler”, completamos con los datos necesarios:

Nombre del Handler: Unprocessable Entity

Disponibilidad del Handler: Flujo

A continuación, vamos a crear una regla. Para ello, hacemos clic en “Agregar regla” y completamos los siguientes campos:

• Nombre de la regla: Status code 422

• Intentos: 0

• Tiempo de espera: 0

• Código regex: "status": 422

• Notificaciones de la regla: Local y Correo electrónico

• Mensaje: Transacción no procesada

• Enviar parámetros en el mensaje? Sí

• Acción final: Continuar el loop

Finalizamos la configuración haciendo clic en “Guardar”.

Status code 400: Bad Request

En “Configuraciones generales del Handler”, completamos con los datos necesarios:

• Nombre del Handler: Transaction Bad Request

• Disponibilidad del Handler: Flujo

A continuación, vamos a crear una regla. Para ello, hacemos clic en “Agregar regla” y completamos los siguientes campos:

• Nombre de la regla: Status code 400

• Intentos: 1 vez

• Tiempo de espera: 1 s

• Código regex: "status": 400

• Notificaciones de la regla: Local y Correo electrónico

• Mensaje: Ocurrió un error en el proceso de la transacción.

• Enviar parámetros en el mensaje? Sí

• Acción final: Detener

Finalizamos la configuración haciendo clic en “Guardar”.

Al marcar la opción “Correo electrónico” en la sección “Notificaciones de la regla”, asegúrate de que tu correo esté configurado como “Canal” para recibir notificaciones y que la opción “Flujos” esté activada en la configuración de “Notificaciones de elementos”. Para más información, consulta el artículo “Notificaciones”.

Además, asegúrate de agregar el correo en la pestaña “Alertas” dentro de la configuración del flujo

Agregando Exception Handler en el componente

Después de crear los Exception Handlers, es momento de activarlos en el componente. En este ejemplo, vamos a activar los Exception Handlers en el módulo “Validar transacción financiera”. Para ello, solo hay que hacer clic en “Editar” de este componente.

A continuación, en la esquina izquierda, observa que las reglas previamente creadas aparecen en la sección “Exception Handlers”.

Para nuestro caso de uso, vamos a activar los Exception Handlers recién creados y organizar el orden de la siguiente manera:

• Unprocessable Entity

• Transaction Bad Request

Resultado de la ejecución

Después de configurar todo, ejecutamos nuestro flujo. En “Logs” podemos verificar el resultado de la ejecución:

• Unprocessable Entity

• Transaction Bad Request