Conector Error Handler Plugin
Continuando nossa série sobre tratamento de erro, vamos para a parte 2, onde vou mostrar um pouco do conector Error Handler Plugin para padronização do tratamento de erro, espero que ele esse artigo ajude na padronização e velocidade das análises de erro.
Porque utilizar o conector?
Um dos problemas encontrados no dia a dia do ciclo de desenvolvimento e no suporte às APIs criadas é uma rápida e correta análise de erro, para que possamos encontrar logo a causa raiz e poder seguir uma solução de tratamento seja na API, no consumidor ou no sistema alvo, com o conector a ideia é que ele seja utilizado de uma forma que facilite o dia a dia, utilizando padrões que aumente a eficiência de um troubleshooting.
Utilizando o conector fará com que as mensagens de erros tenham o mesmo padrão ou seja o mesmo Json de erro e com isso facilitará a identificação dessas mensagens nos logs e também na análise, até mesmo por uma pessoa que não foi a desenvolvedora.
Instalação
Para começar é necessário baixar o conector, pois o conector não está no Exchange, com isso é preciso fazer o download do código do conector para sua máquina e depois enviá-lo para o Anypoint Plataform (Exchange). Para baixar acesse o git do catalyst que está no código https://github.com/mulesoft-catalyst/error-handler-plugin.
Para o exemplo que vamos mostrar aqui, estamos utilizando a versão 6, segue a tabela de versão X runtime.
Depois de baixar o código é necessário configurar o arquivo settings.xml para que ele possa se conectar e enviar o conector para o Exchange.
O settings costuma ficar na %pasta do usuário windows%\.m2\settings.xml.
Ponto importante é ter configurado de forma correta:
Releases — ee: Informações do usuário nexus.
Exchange2: Informações de conexão ao Anypoint Plataform (use o Connected apps).
Importante verificar se o ID so server é o mesmo que está dentro do POM do conector, no caso mantivemos o mesmo valor padrão do POM.
Depois da configuração do settings, é necessário executar um script que já está no projeto, mas é necessário pegar o ID da organização (Org id).
Para executar script basta executar o comando, ./build.sh <org id> deploy, após a execução do comando a seguinte mensagem deve aparecer.
Utilizando o conector
Após a instalação o conector estará disponível no Exchange e você precisa adicioná-lo no projeto, baixe o RAML (da aplicação que pretende desenvolver) para o seu Anypoint Studio normalmente, após a inicialização do desenvolvimento do projeto, crie um novo “Mule Configuration File” para que seja o .XML do conector em seu projeto.
Adicione ao projeto um Error Handler e o On Error Continue.
Após isso procure no seu Exchange o conector (pelo Search Exchange e será necessário estar logado na sua conta).
Após trazer o conector você deve estar visualizando algo como a na imagem acima. Continuando as configurações você deve ir até o API KIT e tirar do main todos os Error Handler criados automaticamente e fazer referência ao Error Handler criado com o conector.
Volta para o XML de erro e adicione um Set Variable com variableName=”httpStatus” e value=”#[attributes.httpStatus]”, e também um log.
Dentro do conector Process Error
Na aba “Common erros” existem os erros padrões com mensagens pré definidas, você pode escolher em usá-los ou não, no caso também você pode editá-las. Veja que como padrão vem marcado a opção “True”.
Mas também pode customizar outros erros e também as próprias mensagens, como sugestão e padronização é indicado a utilização de um dwl.
Um dwl já criado pode ser encontrado no link do catalyst onde foi possível ter acesso ao conector.
Nesse dwl existem mensagens para erros pré definidas, onde podemos fazer alguns ajustes para facilitar em um momento de análise de erro, como por exemplo:
Erro 500 pré definido:
Com a alteração, veja que no retorno da chamada adiciona esse campo novo “testes”.
Veja que podemos colocar informações que nos ajude, como por exemplo data e hora.
Também podemos criar mensagens de erros padronizadas que não estão mapeados no dwl, com isso podemos criá-los de acordo com a necessidade, no exemplo peguei um exemplo simples para ilustração:
Conclusão
Com o plugin do conector de erro é possível padronizá-lo para que todos de um projeto ou empresa possa utilizá-lo, evitando assim mensagens diferentes, falta de informação para uma correta análise do erro além do que dessa forma todos os desenvolvedores possam usar os mesmos padrões, aumentando a reutilização de código agilizando o desenvolvimento e aumentando a assertividade das análises.
