# Caso de uso: Exception Handler em transações financeiras

* [Contexto](#contexto)
* [Regra de negócio](#regra-de-negocio)
  * [Dicionário técnico](#dicionario-tecnico)
* [Cenário sem Exception Handler](#cenario-sem-exception-handler)
* [Cenário com Exception Handler](#cenario-com-exception-handler)
* [Configurando o Exception Handler na prática](#configurando-o-exception-handler-na-pratica)
  * [Status code 422: Unprocessable Entity](#status-code-422-unprocessable-entity)
  * [Status code 400: Bad Request](#status-code-400-bad-request)
  * [Adicionando Exception Handler no componente](#adicionando-exception-handler-no-componente)
  * [Resultado da execução](#resultado-da-execucao)

### Contexto

Imagine que o setor financeiro de uma empresa precisa confirmar se cada transação processada pelo sistema de pagamentos foi realmente concluída com sucesso.&#x20;

Para isso, conta com os seguintes aliados: a API do banco (módulo REST), Banco de dados e o **Skyone Studio**.

Sabemos que, em qualquer operação, podem surgir imprevistos, como falhas de autorização de pagamento ou informações inconsistentes. No entanto, para o setor financeiro, é crucial garantir a verificação de cada transação, assegurando que os pagamentos sejam processados corretamente e que a equipe seja notificada em caso de erros, o que facilita o acompanhamento e otimiza a gestão das operações.

Nesta documentação, vamos explicar como utilizar o recurso "**Exception Handler**" para lidar com cenários onde o fluxo de integração deve continuar, mesmo que alguns itens apresentem erros. Além disso, veremos como notificar adequadamente os erros ocorridos ao longo da execução do fluxo.

### Regra de negócio

Quando o módulo REST retornar o status code 422 quer dizer que as informações estão inconsistentes.

Quando o módulo REST retornar o status code 400 é esperado que a execução seja finalizada.

#### Dicionário técnico

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)

### Cenário sem Exception Handler

Mesmo que o status code indique erro, o **Skyone Studio**, por padrão, não considera isso como tal em casos de REST. Dessa forma, a transação é inserida no banco de dados de pagamentos concluídos, gerando uma inconsistência em relação às informações reais.

<figure><img src="https://2406186417-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlGHvosl2xodpQaXzCzxY%2Fuploads%2FEISSMfRCWvKYxEwC1H1V%2FC2468F55-5106-4A1C-B898-E822A2F2BEF9.png?alt=media&#x26;token=cf6e185f-9327-44ed-a9cf-62b4daea2f7b" alt=""><figcaption></figcaption></figure>

### Cenário com Exception Handler

Com a funcionalidade "**Exception Handler**", qualquer erro de HTTP será capturado e tratado. Ao criar dois Exception Handlers independentes, conseguimos diferenciar o tratamento: no caso de erro 422, o sistema apenas pula para a próxima transação da lista, enquanto, em caso de erro 400, o fluxo é interrompido.

### Configurando o Exception Handler na prática

Após a contextualização do nosso caso, é hora de configurar o nosso fluxo.

Observe na imagem abaixo que temos um fluxo composto por:

* **Gatilho Webhook:** o ponto de partida e entrada da lista de transações que será processada do nosso fluxo.
* **Loop For:** Módulo ferramental que facilita o processamento de listas de informações.
* **Módulo Rest:** Valida a transação bancária, que virá como elemento do Loop For.
* **PostgreSQL:** Registra os pagamentos concluídos.

<figure><img src="https://2406186417-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlGHvosl2xodpQaXzCzxY%2Fuploads%2FeEf8ezQUhq2LswUYivdF%2F561C4569-163C-442E-A962-E4489DDA7E48.png?alt=media&#x26;token=d9ece0a5-ee38-4a5a-8d55-4fe76d9e7e00" alt=""><figcaption></figcaption></figure>

Ao clicar em "**Exception Handlers**", devemos clicar em "**Adicionar Exception Handler**". A seguinte tela será apresentada:

<figure><img src="https://2406186417-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlGHvosl2xodpQaXzCzxY%2Fuploads%2FixA5rfSIGXtWL8e0LCxd%2FAF03FE74-51F2-4297-9674-070BCBC95975.png?alt=media&#x26;token=aa01847b-018b-441e-8e21-3cf9b6669023" alt=""><figcaption></figcaption></figure>

De acordo com as regras de negócio citadas acima, vamos adicionar 2 Exception Handlers:&#x20;

#### Status code 422: Unprocessable Entity

Em "**Configurações gerais do Handler"**, preenchemos com os dados necessários:

<figure><img src="https://2406186417-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlGHvosl2xodpQaXzCzxY%2Fuploads%2FjhlZQgAELOexyBPFEH7Z%2F311D715B-ED15-4917-8C0B-4FB11B066DF1.png?alt=media&#x26;token=a00cbd71-011d-4236-88ca-b44b94f70857" alt=""><figcaption></figcaption></figure>

* **Nome do Handler:** Unprocessable Entity
* **Disponibilidade do Handler:** Fluxo

Em seguida, vamos criar uma regra. Para isso, clicamos em "**Adicionar regra**" e preenchemos os seguintes campos:

* **Nome da regra:** Status code 422&#x20;
* **Tentativas**: 0
* **Tempo de espera:** 0
* **Código regex:** `"status": 422`&#x20;
* **Notificações da regra:** Local e E-mail
* **Mensagem**: Transação não processada
* **Enviar parâmetros na mensagem?** Sim
* **Ação final:** Continuar loop

Finalizamos a nossa configuração clicando em "**Salvar**".&#x20;

#### Status code 400: Bad Request

Em "**Configurações gerais do Handler**", preenchemos com os dados necessários:

<figure><img src="https://2406186417-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlGHvosl2xodpQaXzCzxY%2Fuploads%2FpGFf9qHx5TbpZo8DSU68%2F879747A6-6E49-487A-A3D1-102093176669.png?alt=media&#x26;token=187401bc-a17c-4f8b-94ce-a1f8b220192f" alt=""><figcaption></figcaption></figure>

* **Nome do Handler:** Transaction Bad Request&#x20;
* **Disponibilidade do Handler:** Fluxo

Em seguida, vamos criar uma regra. Para isso, clicamos em "**Adicionar regra**" e preenchemos os seguintes campos:

* **Nome da regra:** Status code 400
* **Tentativas:** 1x
* **Tempo de espera:** 1s
* **Código regex:** `"status": 400`
* **Notificações da regra:** Local e E-mail
* **Mensagem**: No processo da transação ocorreu um erro.
* **Enviar parâmetros na mensagem?** Sim
* **Ação final:** Parar

Finalizamos a nossa configuração clicando em "**Salvar**".

{% hint style="warning" %}
Ao marcar a opção "**E-mail**" na seção "**Notificações da Regra**", certifique-se de que seu e-mail está configurado como "**Canal**" para receber notificações e que a opção "Fluxos" está ativada nas configurações de "**Notificações de elementos**". Para mais informações, consulte o artigo "[**Notificações**](https://docs.skyone.cloud/skyone-studio/visao-geral/configuracoes-e-preferencias/notificacoes)".&#x20;

Além disso, certifique-se de adicionar o e-mail na aba "**Alertas**" na configuração do fluxo. [Leia mais aqui](https://docs.integrasky.cloud/skyone/v/portugues/dados/integracoes/fluxos/gestao-dos-fluxos/flow-canva-configuracao-e-edicao-do-fluxo/configuracao-do-fluxo#alertas-de-fluxo).
{% endhint %}

#### Adicionando Exception Handler no componente

Após os Exception Handlers criados, é hora de ativá-los no componente.\
Neste nosso exemplo, vamos ativar os Exception Handlers no módulo "Validar transação financeira". Para isso, basta clicar em "**editar**" deste componente.&#x20;

<figure><img src="https://2406186417-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlGHvosl2xodpQaXzCzxY%2Fuploads%2Fuu5goI8lNFuQwYQG2xQ0%2Fcaso-uso-eh.gif?alt=media&#x26;token=62ce8261-58ea-4702-8f41-1d65dc466b82" alt=""><figcaption></figcaption></figure>

Em seguida, no canto esquerdo, observe que as regras previamente criadas aparecem na seção "**Exception Handlers**".

Para o nosso caso de uso, vamos ativar os "**Exception Handlers**" recém-criados e organizar a ordem da seguinte forma:

1. Unprocessable Entity
2. Transaction Bad Request

<figure><img src="https://2406186417-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlGHvosl2xodpQaXzCzxY%2Fuploads%2F3WmjMUtWDyxoa5jmxYdW%2FFA333451-8AFC-4E72-AA59-048C680670CC.png?alt=media&#x26;token=27ce389c-e39e-48d0-a97f-4b0e05f4f1ce" alt=""><figcaption></figcaption></figure>

#### Resultado da execução

Após tudo configurado, executamos o nosso fluxo. Em "**Logs**" podemos conferir o resultado da execução:

* Unprocessable Entity

<figure><img src="https://2406186417-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlGHvosl2xodpQaXzCzxY%2Fuploads%2FaVCZmIEMojYdOfId5x8V%2F8B126E21-346E-4B48-BB58-A8442667BC1B.png?alt=media&#x26;token=8347d83d-fbc4-413c-a38a-d012a7a4c075" alt=""><figcaption></figcaption></figure>

* Transaction Bad Request

<figure><img src="https://2406186417-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlGHvosl2xodpQaXzCzxY%2Fuploads%2FQJfrYKMgeLKDEMIkZufe%2F3F4AC61E-4C0C-4F9E-8884-B9F73C79786C.png?alt=media&#x26;token=691c2f51-3568-494f-94fe-3a809e16233c" alt=""><figcaption></figcaption></figure>
