Caso de uso: Exception Handler em transações financeiras
PreviousCaso de uso: parâmetros de gatilho API GatewayNextCaso de uso: utilizando Grupos para gerenciar acessos aos fluxos
Last updated
Last updated
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 a plataforma Skyone Dados.
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.
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.
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.
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.
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:
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".
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".
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:
Unprocessable Entity
Transaction Bad Request
Após tudo configurado, executamos o nosso fluxo. Em "Logs" podemos conferir o resultado da execução:
Unprocessable Entity
Transaction Bad Request
HTTP Status code 422:
HTTP Status code 400:
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 "".
Além disso, certifique-se de adicionar o e-mail na aba "Alertas" na configuração do fluxo. .
