# Caso de uso: Exception Handler en transacciones financieras

* [**Contexto**](#contexto)
* [**Regla de negocio**](#regla-de-negocio)
  * [**Diccionario técnico**](#diccionario-tecnico)
* [**Escenario sin Exception Handler**](#escenario-sin-exception-handler)
* [**Escenario con Exception Handler**](#escenario-con-exception-handler)
* [**Configurando el Exception Handler en la práctica**](#configurando-el-exception-handler-en-la-practica)
  * [**Status code 422:** Unprocessable Entity](#status-code-422-unprocessable-entity)
  * [**Status code 400:** Bad Request](#status-code-400-bad-request)
  * [**Agregando Exception Handler en el componente**](#anadiendo-exception-handler-en-el-componente)
  * [**Resultado de la ejecución**](#resultado-de-la-ejecucion)

#### 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](https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Reference/Status/422)
* **HTTP Status code 400:** [Bad Request](#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.

<figure><img src="/files/W6idO76MRzPBhiK74Sl1" alt=""><figcaption></figcaption></figure>

#### **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.

<figure><img src="/files/ZvsoqrpSIbbZSQxA4wgb" alt=""><figcaption></figcaption></figure>

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

<figure><img src="/files/2Z1sFD0fdd28BrL9wZmg" alt=""><figcaption></figcaption></figure>

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:

<figure><img src="/files/cBHa78LOQPzInH3tetsZ" alt=""><figcaption></figcaption></figure>

**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:

<figure><img src="/files/5MRsRmDEuPheHdqm9ZFQ" alt=""><figcaption></figcaption></figure>

* **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”**.

{% hint style="warning" %}
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**](/espanol/skyone-studio/vision-general/configuraciones-y-preferencias/notificaciones.md)**”**.

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

#### **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.

<figure><img src="/files/NF9qxbMIVPiUPuUjrsR5" alt=""><figcaption></figcaption></figure>

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**

<figure><img src="/files/6X4KAZ3sfguTiPQulutm" alt=""><figcaption></figcaption></figure>

#### **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

<figure><img src="/files/SRD0vDAuxabYEfPHdK29" alt=""><figcaption></figcaption></figure>

* Transaction Bad Request

<figure><img src="/files/qX5LFzijjrRfH1SCEdi6" alt=""><figcaption></figcaption></figure>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.skyone.cloud/espanol/skyone-studio/how-to/caso-de-uso-exception-handler-en-transacciones-financieras.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
