Tratamento de erro — parte 1

Este é um primeiro artigo de uma série que falará sobre tratamentos de erros no MuleSoft, e nesse primeiro a vamos explicar o que é o tratamento de erro e suas diferenças.

Durante o desenvolvimento existe um costume de focar no “caminho feliz”, com isso algumas situações que podem ocorrer no dia a dia, podendo prejudicar o funcionamento correto das APIs e até mesmo gerando algum problema para o negócio podem ser esquecidos, por exemplo uma regra não prevista na lógica ou na solução como um todo.

Erros são comuns e existe a necessidade de tratarmos para evitar problemas como a perda de dados, mal funcionamento da APIs, entre outros.

Mas antes precisamos saber o que é tratamento de erro (ou error handling), esse mecanismo é responsável pelo tratamento de situações que alteram o fluxo esperado do que está sendo desenvolvido.

Para os erros possíveis de tratamento temos dois possíveis tipos o “On Error Continue” e “On Error Propagate”

On Error Continue: Neste modo o fluxo assume que a execução foi realizada com sucesso. Para cenários de APIs, irá retornar HTTP Status 200.

On Error Propagate: O erro será propagado para quem realizou a chamada do fluxo. Para cenários de APIs, irá retornar HTTP 500..

Observação: Lembrando que esses retornos são para APIs, ou seja, as interfaces que tem o HTTP Listener.

Uma forma para facilitar o entendimento do tratamento de erros no MuleSoft é fazer uma analogia com o Java, pois o MuleSoft segue a mesma lógica.

Fluxo sem tratamento de erro

Antes de começarmos vamos fazer um teste usando um flow simples, e sem nenhum dos dois tipos de tratamento de erro para vermos seu comportamento.

Mensagem utilizada para o teste:

Usando o modo debug do Anypoint Studio é possível ver as informações que são retornadas durante quando um erro acontece, como por exemplo o erroType e sua descrição, que são informações importantes para que seja possível criar tratamentos e mitigar os problemas que podem acontecer durante a execução.

Error On Continue

Agora depois que vimos o comportamento caso ocorra um erro vamos verificar o que acontecer quando utilizamos o On Error Continue :

Veja que no fluxo acima no componente de tratamento de erro , colocamos um “Transform Message” para retornarmos uma mensagem do nosso interesse.

Mensagem com tratamento:

Para continuar com a especificação e aumentar a tolerância à falha e rastreabilidade nas próprias configurações do tratamento de erro é possível escolher tipos de erros para ter tratamento diferentes.

Dentro do “type” é possível filtrar os tipos de erros e assim criar diferentes cenários de tratamento de erros.

No caso do exemplo podemos escolher as opções todos “ANY” (tendo um tratamento único) ou customizar para cada uma das opções um retorno que melhor atenda o que está sendo desenvolvido

Agora vamos fazer o teste com solicitando uma informação de um serviço externo:

Veja que no caso recebemos o erro 404.

Percebam que o erro foi especificado (“type)” para vir um tratamento específico no caso, no Postman a mensagem de retorno é a que foi especificada dentro do Transform que foi adicionado no “On error Continue”.

Error Propagate

Utilizando a mesma mensagem do exemplo do tratamento “onContinue”, podemos ver o comportamento no “onPropagete”

Veja que a mensagem do conector de validação é retornada junto com o status code 500 ou seja retorna o erro para quem consumiu.

Usando os dois escopos de erro

Agora colocamos um flow que faz referência a outro flow para fazer um request que receberá um erro, nesse segundo flow temos um escopo de error “On propagate”.

Quando o Request retorna o erro, o flow_exemplo cai no “On Error propagate” e envia para o flow principal que tratará o mesmo no “On error continue”, e retornará a resposta para o consumidor.

Veja que o Flow Reference retorna para o flow principal o “mesmo” erro que recebeu, fazendo que o escopo do “on Error Continue” seja executado e envie a mensagem tratada para o consumidor.

Conclusão

Como podemos ver, existem algumas formas de tratamento de erro onde podemos customizar, para caso o erro ocorra durante a execução das nossas interfaces possa diminuir os impactos negativos para a solução como um todo, o importante é que não existe o “melhor jeito” o que existe é o que melhor se adere para a solução da API e do projeto.

Para o próximo trarei o ”Error Handler Plugin” para ajudar na padronização dos erros.