Tratando incoerências de integração com “Invalid Message Channel” pattern
Olá pessoal. Tudo certo?!
Como venho evidenciando há algum tempo, aqui no blog e em palestras, sou um entusiasta de patterns de integração que utilizem channels/filas.
Nesse post, mostro um pattern interessante, descrito no excelente Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions : Invalid Message Channel.
Entendendo a necessidade
De forma geral, defendo integrações com “baixo acoplamento” onde os aplicativos tenham dependência indireta intermediada por um “Messaging Server” (veja esse post para entender melhor o que quero dizer).
Entretanto, fica a questão: O que fazer caso a “Receiver App” receba uma mensagem que não consiga processar?
Como as apps estão “desconectadas” não haveria forma da “receiver” notificar a “sender”. Não é mesmo?
Entendendo o pattern
A solução, de fato, é muito simples. Basicamente, fazemos com que a aplicação “Receiver” encaminhe todas as mensagens inválidas para um novo canal, específico, que as armazena. Observe:
Como pode perceber, entendo que a aplicação receiver deva expor um novo “endpoint” para servir de saída para mensagens inválidas. Esse endpoint deve se conectar a um canal que armazena mensagens incoerentes.
Um“invalid message channel” funciona como uma espécie de log do que “deu errado”. Quando planejamos uma integração, podemos concentrar nossos esforços de contingência no tratamento e eventual recuperação do conteúdo desse “channel” deixando os demais livres de “sujeiras e ruídos”.
Dois passos adiante…
Obviamente, um “invalid message channel” cujo mensagens são esquecidas é como um log de erros com conteúdo ignorado. Não é uma boa estratégia.
Com o surgimento de um canal para mensagens inválidas, surge também um artifício de software que viabilize alguma intervenção (automatizada ou não) para dar tratamento e tratar contingências.
O que seria uma mensagem inválida?
Importante ressaltar que nenhuma mensagem, quando encaminhada pelo sender, é, necessariamente, válida ou inválida. Será o contexto de execução do receiver que irá determinar isso. Por exemplo, considere uma mensagem instruindo o receiver a eliminar um registro, entretanto, esse registro não pode ser eliminado por alguma razão (não existe ou está envolvido em alguma transação) – esse seria um caso de mensagem inválida.
Finalizando…
A discussão é boa, mas já está puxando para outros patterns.
Como você trata incoerências em suas integrações?
Dependendo da necessidade da aplicação eu faria um ASP.Net fornercer um monitor das mensagens onde dependendo da mensagem a ser processada marcaria como a processar ou marcaria com erro. Ex um processamento de TED bancaria.
Pingback: Implementando os EIPs em .NET « Simples Assim
Pingback: Sobre a integração de aplicações através de mensageria « Elemar DEV