MuleSoft - Tratamento de erros do Mule
O novo tratamento de erros do Mule é uma das maiores e principais mudanças feitas no Mule 4. O novo tratamento de erros pode parecer complexo, mas é melhor e mais eficiente. Neste capítulo, vamos discutir sobre os componentes do erro Mule, tipos de erro, categorias de erro Mule e componentes para lidar com erros Mule.
Componentes do erro de mula
O erro de mula é o resultado de uma falha de exceção de mula com os seguintes componentes -
Descrição
É um componente importante do erro Mule que fornecerá a descrição do problema. Sua expressão é a seguinte -
#[error.description]Tipo
O componente Tipo do erro Mule é usado para caracterizar o problema. Ele também permite o roteamento em um manipulador de erros. Sua expressão é a seguinte -
#[error.errorType]Causa
O componente de Causa do erro Mule fornece o java subjacente descartável que causa a falha. Sua expressão é a seguinte -
#[error.cause]mensagem
O componente Mensagem do erro Mule mostra uma mensagem opcional sobre o erro. Sua expressão é a seguinte -
#[error.errorMessage]Erros Filhos
O componente Child Errors de Mule error fornece uma coleção opcional de erros internos. Esses erros internos são usados principalmente por elementos como Scatter-Gather para fornecer erros de rota agregados. Sua expressão é a seguinte -
#[error.childErrors]Exemplo
Em caso de falha de solicitação HTTP com um código de status 401, os Erros Mule são os seguintes -
Description: HTTP GET on resource ‘http://localhost:8181/TestApp’
failed: unauthorized (401)
Type: HTTP:UNAUTHORIZED
Cause: a ResponseValidatorTypedException instance
Error Message: { "message" : "Could not authorize the user." }| Sr. Não | Tipo e descrição do erro |
|---|---|
| 1 | TRANSFORMATION Este tipo de erro indica que ocorreu um erro ao transformar um valor. A transformação é a transformação interna do Mule Runtime e não as transformações DataWeave. |
| 2 | EXPRESSION Este tipo de tipo de erro indica que ocorreu um erro ao avaliar uma expressão. |
| 3 | VALIDATION Este tipo de tipo de erro indica que ocorreu um erro de validação. |
| 4 | DUPLICATE_MESSAGE Um tipo de erro de validação que ocorre quando uma mensagem é processada duas vezes. |
| 5 | REDELIVERY_EXHAUSTED Este tipo de tipo de erro ocorre quando o número máximo de tentativas de reprocessar uma mensagem de uma origem foi esgotado. |
| 6 | CONNECTIVITY Este tipo de erro indica um problema ao estabelecer uma conexão. |
| 7 | ROUTING Este tipo de erro indica que ocorreu um erro ao encaminhar uma mensagem. |
| 8 | SECURITY Este tipo de erro indica que ocorreu um erro de segurança. Por exemplo, credenciais inválidas recebidas. |
| 9 | STREAM_MAXIMUM_SIZE_EXCEEDED Este tipo de erro ocorre quando o tamanho máximo permitido para um fluxo se esgota. |
| 10 | TIMEOUT Indica o tempo limite durante o processamento de uma mensagem. |
| 11 | UNKNOWN Este tipo de erro indica que ocorreu um erro inesperado. |
| 12 | SOURCE Representa a ocorrência de um erro na origem do fluxo. |
| 13 | SOURCE_RESPONSE Ele representa a ocorrência de um erro na origem do fluxo durante o processamento de uma resposta bem-sucedida. |
No exemplo acima, você pode ver o componente de mensagem de erro de mula.
Tipos de Erro
Vamos entender os tipos de erro com a ajuda de suas características -
As primeiras características dos tipos de erro Mule é que ele consiste em ambos, a namespace and an identifier. Isso nos permite distinguir os tipos de acordo com seu domínio. No exemplo acima, o tipo de erro éHTTP: UNAUTHORIZED.
A segunda e importante característica é que o tipo de erro pode ter um tipo pai. Por exemplo, o tipo de erroHTTP: UNAUTHORIZED tem MULE:CLIENT_SECURITY como pai, que por sua vez também tem um pai chamado MULE:SECURITY. Esta característica estabelece o Tipo de Erro como especificação de item mais global.
Tipos de tipos de erro
A seguir estão as categorias nas quais todos os erros se enquadram -
QUALQUER
Os erros nesta categoria são os erros que podem ocorrer em um fluxo. Eles não são tão graves e podem ser manuseados facilmente.
CRÍTICO
Os erros nesta categoria são os erros graves que não podem ser tratados. A seguir está a lista de tipos de erro nesta categoria -
| Sr. Não | Tipo e descrição do erro |
|---|---|
| 1 | OVERLOAD Este tipo de erro indica que ocorreu um erro devido ao problema de sobrecarga. Nesse caso, a execução será rejeitada. |
| 2 | FATAL_JVM_ERROR Este tipo de tipo de erro indica a ocorrência de um erro fatal. Por exemplo, estouro de pilha. |
Tipo de erro PERSONALIZADO
Os tipos de erro CUSTOM são os erros que são definidos por nós. Eles podem ser definidos ao mapear ou ao levantar os erros. Devemos fornecer um namespace personalizado específico para esses tipos de erro para distingui-los dos outros tipos de erro existentes no aplicativo Mule. Por exemplo, no aplicativo Mule usando HTTP, não podemos usar HTTP como o tipo de erro personalizado.
Categorias de erro de mula
Em sentido amplo, os erros no Mule podem ser divididos em duas categorias, a saber, Messaging Errors and System Errors.
Erro de mensagem
Esta categoria de erro de Mula está relacionada ao fluxo de Mula. Sempre que um problema ocorre dentro de um fluxo Mule, Mule lança um erro de mensagem. Podemos configurarOn Error componente dentro do componente manipulador de erros para lidar com esses erros do Mule.
Erro no sistema
O erro do sistema indica uma exceção ocorrendo no nível do sistema. Se não houver evento Mule, o erro do sistema é tratado por um manipulador de erros do sistema. O seguinte tipo de exceção é tratado por um gerenciador de erros do sistema -
- Exceção que ocorre durante a inicialização do aplicativo.
- Exceção que ocorre quando uma conexão com um sistema externo falha.
No caso de ocorrer um erro de sistema, o Mule envia uma notificação de erro para os ouvintes registrados. Ele também registra o erro. Por outro lado, o Mule executa uma estratégia de reconexão se o erro foi causado por uma falha de conexão.
Tratamento de erros de mula
Mule tem os seguintes dois manipuladores de erro para lidar com os erros -
Manipuladores de erros por erro
O primeiro manipulador de erros Mule é o componente On-Error, que define os tipos de erros que eles podem manipular. Conforme discutido anteriormente, podemos configurar componentes On-Error dentro do componente Error Handler semelhante ao escopo. Cada fluxo Mule contém apenas um manipulador de erro, mas esse manipulador de erro pode conter tantos escopos On-Error quantos forem necessários. As etapas para lidar com o erro Mule dentro do fluxo, com a ajuda do componente On-Error, são as seguintes -
Primeiro, sempre que um fluxo de Mula gera um erro, a execução do fluxo normal para.
Em seguida, o processo será transferido para o Error Handler Component que já tem On Error component para corresponder aos tipos e expressões de erro.
Por fim, o componente Error Handler encaminha o erro para o primeiro On Error scope que corresponde ao erro.
A seguir estão os dois tipos de componentes On-Error suportados pelo Mule -
Propagação em caso de erro
O componente On-Error Propagate executa, mas propaga o erro para o próximo nível e interrompe a execução do proprietário. A transação será revertida se for tratada porOn Error Propagate componente.
Em caso de erro continuar
Como o componente On-Error Propagate, o componente On-Error Continue também executa a transação. A única condição é que, se o proprietário tiver concluído a execução com êxito, este componente usará o resultado da execução como resultado de seu proprietário. A transação será confirmada se for tratada pelo componente On-Error Continue.
Experimente o componente de escopo
Try Scope é uma das muitas novidades disponíveis no Mule 4. Funciona de forma semelhante ao bloco try do JAVA no qual costumávamos encerrar o código tendo a possibilidade de ser uma exceção, para que possa ser tratado sem quebrar todo o código.
Podemos envolver um ou mais processadores de evento Mule em Try Scope e, a partir daí, try scope irá capturar e tratar qualquer exceção lançada por esses processadores de evento. O principal trabalho do escopo try gira em torno de sua própria estratégia de tratamento de erros, que oferece suporte ao tratamento de erros em seu componente interno, em vez de no fluxo inteiro. É por isso que não precisamos extrair o fluxo em um fluxo separado.
Example
A seguir está um exemplo do uso do escopo try -
Configurando o escopo de teste para lidar com transações
Como sabemos, uma transação é uma série de ações que nunca devem ser executadas parcialmente. Todas as operações dentro do escopo de uma transação são executadas no mesmo encadeamento e se ocorrer um erro, ele deve levar a uma reversão ou confirmação. Podemos configurar o escopo try, da seguinte maneira, para que ele trate operações filho como uma transação.
INDIFFERENT [Default]- Se escolhermos esta configuração no bloco try, então as ações filho não serão tratadas como uma transação. Neste caso, o erro não causa rollback nem commits.
ALWAYS_BEGIN - Indica que uma nova transação será iniciada toda vez que o escopo for executado.
BEGIN_OR_JOIN- Indica que se o processamento atual do fluxo já iniciou uma transação, participe dela. Caso contrário, comece um novo.