# Use case: Exception Handler in financial transactions

* [Context](#context)
* [Business Rule](#business-rule)
  * [Technical Dictionary](#technical-dictionary)
* [Scenario without Exception Handler](#scenario-without-exception-handler)
* [Scenario with Exception Handler](#scenario-with-exception-handler)
* [Configuring the Exception Handler in practice](#configuring-the-exception-handler-in-practice)
  * [Status code 422: Unprocessable Entity](#status-code-422-unprocessable-entity)
  * [Status code 400: Bad Request](#status-code-400-bad-request)
  * [Adding Exception Handler to the component](#adding-exception-handler-to-the-component)
  * [Execution result](#execution-result)

### Context

Imagine that a company's finance department needs to confirm whether each transaction processed by the payment system was successfully completed.

To do this, they rely on the following tools: the bank's API (REST module), the database, and the **Skyone Studio**.

We know that, in any operation, unexpected issues may arise, such as payment authorization failures or inconsistent information. However, for the finance department, it is crucial to verify each transaction, ensuring that payments are processed correctly and that the team is notified in case of errors, which facilitates monitoring and optimizes operational management.

In this documentation, we will explain how to use the "**Exception Handler**" feature to handle scenarios where the integration flow needs to continue even if some items encounter errors. Additionally, we will cover how to properly notify errors that occur throughout the flow execution.

### **Business Rule**

When the REST module returns status code 422, it means the information is inconsistent.

When the REST module returns status code 400, the execution is expected to be terminated.

#### **Technical Dictionary**

HTTP Status code 422: [Unprocessable Entity ](https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Status/422)

HTTP Status code 400: [Bad Request](https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Status/400)

### **Scenario Without Exception Handler**

Even if the status code indicates an error, Skyone Studio does not treat it as such by default in REST cases. As a result, the transaction is recorded in the completed payments database, leading to inconsistencies with the actual information.

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

### **Scenario with Exception Handler**

With the "**Exception Handler**" functionality, any HTTP error will be captured and handled. By creating two independent Exception Handlers, we can differentiate the treatment: in the case of a 422 error, the system simply skips to the next transaction in the list, while in the case of a 400 error, the flow is interrupted.

### **Configuring the Exception Handler in Practice**

After contextualizing our case, it's time to set up our flow.

Notice in the image below that we have a flow consisting of:

* **Webhook Trigger**: The starting point and entry for the list of transactions to be processed by our flow.
* **Loop For**: A tool module that facilitates the processing of lists of information.
* **REST Module**: Validates the bank transaction, which will come as an element of the Loop For.
* **PostgreSQL**: Records the completed payments.

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

When clicking on "**Exception Handlers**", we should click on "**Add Exception Handler"**. The following screen will be displayed:

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

Based on the business rules mentioned above, we will add two Exception Handlers:

#### **Status code 422: Unprocessable Entity**

In "**Handler General Settings**", fill in the necessary details:

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

* **Handler Name**: Unprocessable Entity
* **Handler Availability**: Flow

Next, we will create a rule. To do this, click on "**Add Rule**" and fill in the following fields:

* **Rule Name**: Status code 422
* **Attempts**: 0
* **Waiting Time**: 0
* **Regex code**: `"status": 422`
* **Rule notifications**: Local and Email
* **Message**: Transaction not processed
* **Send parameters in the message?** Yes
* **Final action**: Continue loop

We finish the configuration by clicking "**Save**".

#### Status code 400: Bad Request

In "**Handler General Settings**", fill in the necessary details:

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

* **Handler Name**: Transaction Bad Request
* **Handler Availability**: Flow

Next, we will create a rule. To do this, click on "**Add Rule**" and fill in the following fields:

* **Rule Name**: Status code 400
* **Attempts**: 1
* **Waiting Time**: 1s
* **Regex Code**: `"status": 400`
* **Rule Notifications**: Local and Email
* **Message**: An error occurred during the transaction process.
* **Send parameters in the message?** Yes
* **Final Action**: Stop

We finish the configuration by clicking "**Save**".

{% hint style="warning" %}
When selecting the "**Email**" option in the "**Rule Notifications**" section, ensure that your email is set as the "**Channel**" to receive notifications and that the "Flows" option is enabled in the "**Element Notifications**" settings. For more information, see the "[Notifications](/english/skyone-studio/overview/settings-and-preferences/notifications.md)" article.

Additionally, make sure to add the email in the "**Alerts**" tab in the flow configuration. [Read more here](/english/skyone-studio/integrations/flows/flow-management/flow-canva-configuring-and-editing-the-flow/flow-settings.md#alerts).
{% endhint %}

#### **Adding Exception Handler to the Component**

After the Exception Handlers are created, it's time to activate them in the component.\
In this example, we will activate the Exception Handlers in the "Validate Financial Transaction" module. To do this, simply click "**edit**" on this component.

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

Next, on the left-hand side, you will see that the previously created rules appear in the "**Exception Handlers**" section.&#x20;

For our use case, we will activate the newly created **"Exception Handlers"** and organize them in the following order:

1. Unprocessable Entity
2. Transaction Bad Request

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

**Execution Result**

After everything is set up, we run our flow. In "Logs", we can check the execution result.

* Unprocessable Entity

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

* Transaction Bad Request

<figure><img src="/files/WTg2l3yeEe3d7KMXoss0" 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/english/skyone-studio/how-to/use-case-exception-handler-in-financial-transactions.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.