MuleSoft - tratamento de exceções de mula
No caso de todo projeto, o fato das exceções é que elas estão destinadas a acontecer. É por isso que é importante capturar, categorizar e tratar exceções para que o sistema / aplicativo não seja deixado em um estado inconsistente. Existe uma estratégia de exceção padrão que é implicitamente aplicada a todos os aplicativos Mule. Reverter qualquer transação pendente automaticamente é a estratégia de exceção padrão.
Exceções em Mule
Antes de nos aprofundarmos no tratamento de exceções, devemos entender que tipo de exceções podem ocorrer junto com três questões básicas que um desenvolvedor deve ter ao projetar manipuladores de exceção.
Qual transporte é importante?
Esta questão tem ampla relevância antes de projetar manipuladores de exceção porque todos os transportes não suportam transnacionalidade.
File ou HTTPnão suporta transações. Por isso, se ocorrer uma exceção nesses casos, devemos gerenciá-la manualmente.
Databasestransações de suporte. Ao projetar manipuladores de exceção, neste caso, devemos ter em mente que as transações do banco de dados podem reverter automaticamente (se necessário).
No caso de REST APIs, devemos ter em mente que eles devem retornar os códigos de status HTTP corretos. Por exemplo, 404 para um recurso não encontrado.
Qual padrão de troca de mensagens deve ser usado?
Ao projetar manipuladores de exceção, devemos tomar cuidado com o padrão de troca de mensagens. Pode haver um padrão de mensagem síncrona (solicitação-resposta) ou assíncrona (fogo-esquecer).
Synchronous message pattern é baseado no formato de solicitação-resposta, o que significa que esse padrão esperará uma resposta e será bloqueado até que uma resposta seja retornada ou o tempo limite ocorra.
Asynchronous message pattern é baseado no formato Fire-forget, o que significa que esse padrão assume que as solicitações serão processadas.
Que tipo de exceção é?
A regra muito simples é que você tratará a exceção com base em seu tipo. É muito importante saber se a exceção é causada por um problema de sistema / técnico ou um problema de negócios.
Uma exceção ocorreu por system/technical issue (como queda de rede) deve ser tratada automaticamente por um mecanismo de nova tentativa.
Por outro lado, ocorreu uma exceção by a business issue (como dados inválidos) não deve ser resolvido aplicando o mecanismo de repetição, porque não é útil tentar novamente sem corrigir a causa subjacente.
Por que categorizar exceções?
Como sabemos que todas as exceções não são iguais, é muito importante categorizar as exceções. Em alto nível, as exceções podem ser classificadas nos seguintes dois tipos -
Exceções de negócios
Os principais motivos para a ocorrência de exceções de negócios são dados incorretos ou fluxo de processo incorreto. Esses tipos de exceções são normalmente de natureza irreparável e, portanto, não é bom configurar umrollback. Mesmo aplicandoretrymecanismo não faria nenhum sentido porque não é útil tentar novamente sem corrigir a causa subjacente. Para lidar com essas exceções, o processamento deve parar imediatamente e a exceção enviada de volta como uma resposta a uma fila de devoluções. Uma notificação também deve ser enviada às operações.
Exceções não comerciais
Os principais motivos para a ocorrência de exceções não comerciais são problemas de sistema ou problemas técnicos. Esses tipos de exceções podem ser recuperados por natureza e, portanto, é bom configurar umretry mecanismo para resolver essas exceções.
Estratégias de tratamento de exceções
Mule tem as seguintes cinco estratégias de tratamento de exceção -
Estratégia de exceção padrão
O Mule aplica implicitamente essa estratégia aos fluxos do Mule. Ele pode lidar com todas as exceções em nosso fluxo, mas também pode ser substituído adicionando uma estratégia de exceção catch, Choice ou Rollback. Essa estratégia de exceção reverterá todas as transações pendentes e registrará as exceções também. Uma característica importante dessa estratégia de exceção é que ela também registrará a exceção se não houver transação.
Por ser a estratégia padrão, o Mule implementa isso quando ocorre algum erro no fluxo. Não podemos configurar no AnyPoint Studio.
Estratégia de exceção de reversão
Suponha que se não houver uma solução possível para corrigir o erro, o que fazer? Uma solução é usar a Estratégia de Exceção de Rollback, que reverterá a transação junto com o envio de uma mensagem para o conector de entrada do fluxo pai para reprocessar a mensagem. Essa estratégia também é muito útil quando queremos reprocessar uma mensagem.
Example
Essa estratégia pode ser aplicada a transações bancárias em que os fundos são depositados em uma conta corrente / poupança. Podemos configurar uma estratégia de exceção de rollback aqui porque, caso ocorra um erro durante a transação, essa estratégia reverte a mensagem para o início do fluxo para tentar novamente o processamento.
Estratégia de exceção de captura
Essa estratégia captura todas as exceções que são lançadas em seu fluxo pai. Ele substitui a estratégia de exceção padrão do Mule, processando todas as exceções lançadas pelo fluxo pai. Podemos usar uma estratégia de captura de exceções para evitar a propagação de exceções para conectores de entrada e fluxos pai também.
Essa estratégia também garante que uma transação processada pelo fluxo não seja revertida quando ocorrer uma exceção.
Example
Esta estratégia pode ser aplicada ao sistema de reserva de voos em que temos um fluxo de processamento de mensagens de uma fila. Um incrementador de mensagem adiciona uma propriedade à mensagem para atribuição de lugar e, em seguida, envia a mensagem para outra fila.
Agora, se ocorrer algum erro neste fluxo, a mensagem lançará uma exceção. Aqui, nossa estratégia de captura de exceção pode incluir um cabeçalho com uma mensagem apropriada e pode enviar essa mensagem do fluxo para a próxima fila.
Estratégia de exceção de escolha
Caso você queira tratar a exceção com base no conteúdo da mensagem, a estratégia de exceção de escolha seria a melhor escolha. O funcionamento desta estratégia de exceção será o seguinte -
- Primeiro, ele captura todas as exceções lançadas no fluxo pai.
- Em seguida, ele verifica o conteúdo da mensagem e o tipo de exceção.
- E, por fim, ele encaminha a mensagem para a estratégia de exceção apropriada.
Haveria mais de uma estratégia de exceção como Catch ou Rollback, definida na estratégia de exceção de escolha. Caso não haja estratégia definida sob esta estratégia de exceção, então ele irá rotear a mensagem para a estratégia de exceção padrão. Ele nunca executa nenhuma confirmação, reversão ou atividades de consumo.
Estratégia de exceção de referência
Isso se refere a uma estratégia de exceção comum que é definida em um arquivo de configuração separado. No caso de uma mensagem lançar uma exceção, esta estratégia de exceção se referirá aos parâmetros de tratamento de erros definidos em uma estratégia global de captura, reversão ou exceção de escolha. Como a estratégia de exceção de escolha, ele nunca executa nenhuma atividade de confirmação, reversão ou consumo.