Telão Interativo SPTV com Apache Camel

Demorou, mas está pronto e com vídeo no YouTube! Tinha feito uma postagem explicando a simplicidade de trabalhar com o Apache Camel e prometi postar no futuro como fazer o painel interativo do SPTV com WebSocket incluindo testes e eis a conclusão!

Olhando por cima em um primeiro momento parece que não, mas o Apache Camel mudou muito! Inclusive o componente de integração com Twitter que usamos no projeto anterior depreciou e tivemos que usar outro, até a segunda edição do livro Camel In Action foi lançada exatamente na semana passada (23/02 para ser mais específico) com várias novidades e a evolução constante não para.

Bom, vamos para o projeto. Diferente do outro, estamos com Spring Boot agora e utilizei vários recursos para possibilitar testes inteligentes incluindo a instância de um container para avaliar a integração com o ActiveMQ. Particularidades gerais:

• Assim como o projeto anterior, temos 4 rotas porém um pouco diferentes, por exemplo a de ID ConsumerTweetQueueRoute além de salvar em arquivo a mensagem da fila do ActiveMQ também direciona para o consumer do WebSocket, assim, todos os clients conectados receberão uma mensagem no formato JSON.
• Cara rota possui sua classe de teste dedicada, sendo que a classe PrepareTweetsAndEvaluateThemRoutesIT vai um pouco mais além instanciando um container para auxiliar na avaliação da integração com o ActiveMQ (para entendimento favor ver postagem sobre o tema do Michael J. Simons).
• Veja que nos testes de cada rota inclui mocks antes e depois de algum endpoint e até alterei o endpoint padrão para um outro utilizando os métodos replaceFromWith, weaveByToUri e interceptSendToEndpoint. O motivo principal é obter os dados que trafegam na rota e verificar se são os esperados e também alterar o controle de um producer, por exemplo os que fazem polling por um direct para justamente controlarmos quando deve iniciar um determinado fluxo ou não.
• É estranho em um primeiro momento ver que estou sempre buscando o último exchange do mock nos testes, mas o motivo é simples. O mesmo contexto do Camel é usado em todos os métodos de teste da classe, então pode acontecer de pegar um valor indesejado. Até poderia ter forçado a limpeza e o uso de um novo contexto com DirtiesContext, só que o drawback pesado é a velocidade do teste que acaba demorando demais.
• Abusei bastante do UseAdviceWith para permitir um controle maior das rotas. Teve um exemplo que fiz para rodar uma única rota excluindo as outras.
• Para realizar a DML de exclusão do registro relevante no banco de dados, usei a query parameters no endpoint do JPA. Na documentação diz que precisa ser um Map oriundo do Registry do Camel. Implementei um esquema diferente para permitir que o valor passado seja convertido para Map por meio de um converter. Para o Camel saber que ele existe, basta criar um Bean que automaticamente é registrado e injetado no contexto padrão.
• Criei um ScenarioBuilder com uma lógica para ler de um arquivo CSV exemplos de tweets para servir de insumo no teste de integração, assim pude simular o fluxo entre as rotas salvando no banco 15 ou mais tweets para garantir que a regra de negócio está OK.

Se você não estiver afim de habilitar sua conta do Twitter para esse tipo de integração é possível testar por meio da classe WebSocketProducerOnlyTest. Saiba como no vídeo abaixo:

Inclui um GIF demonstrando a execução do projeto no GitHub. Confere lá!

Ao som de Kō Ōtani - Sign of the Colossus.