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

• Contexto

• Regra de negócio

  • Dicionário técnico

• Cenário sem Exception Handler

• Cenário com Exception Handler

• Configurando o Exception Handler na prática

  • Status code 422: Unprocessable Entity

  • Status code 400: Bad Request

  • Adicionando Exception Handler no componente

  • Resultado da execução

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.

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

HTTP Status code 400: Bad Request

Cenário sem Exception Handler

Mesmo que o status code indique erro, a plataforma, 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.

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.

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

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

Status code 422: Unprocessable Entity

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

• 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

• Tentativas: 0

• Tempo de espera: 0

• Código regex: "status": 422

• 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".

Status code 400: Bad Request

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

• Nome do Handler: Transaction Bad Request

• 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".

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.

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

Resultado da execução

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

• Unprocessable Entity

• Transaction Bad Request