Primeiro vamos a um cenário onde este agendamento é útil.

Vamos supor que a seguinte regra é solicitada: Ao tentarmos cobrar o cartão do cliente, se a operadora retornar transação negada, o sistema deve re-tentar cobrar este cartão por mais 2 dias, sendo que cada tentativa deve ser feita após 24hs.

É possível resolver este requisito usando banco de dados e as famosas flags, mas essa definitivamente não é uma solução elegante. Imagina que você precisaria ficar fazendo pooling no banco para ver quais cobranças já passaram de 24 horas para processa-las novamente. Ou seja, horrível.

Com JMS dá pra fazer algo muito melhor. Se quando a compra é feita, retornar negado, basta enviar uma mensagem JMS pra fila, agendando essa mensagem para ser processada apenas após 24 horas. Quando der essas 24hhs, o MDB lê a mensagem e chama novamente o módulo de cobrança.

Muito simples e elegante. Sem pooling, sem ficar controlando status manualmente, nem nada desse tipo.

O código para fazer isso é extremamente simples:

[sourcecode language='java']
ObjectMessage message = session.createObjectMessage();

message.setLongProperty("JMS_JBOSS_SCHEDULED_DELIVERY", (new Date().getTime() + (1000 * 60 * 60 * 24)));[/sourcecode]

Pronto, você acabou de agendar a entrega da sua mensagem para daqui a 24 horas. Essa conta maluca aí é porque a data precisa ser passada em milisegundos.

Eu sou um grande fã de JMS, e essa é mais uma das caracteristicas que me fazem gostar dessa tecnologia.

[]'s

Tinhamos o seguinte cenário:

“É tentado cobrar um determinado valor do cartão de crédito do cliente, caso a operadora retorne OK, ou seja, a compra foi executada com sucesso, deve ser chamada uma API aqui da empresa que autoriza o cliente a usar o nosso sistema”

Agora pense na seguinte situação: O cliente é cobrado, debita o valor do seu cartão de crédito, mas quando
a API de autorização é chamada, acontece um erro e o cliente não é liberado para usar o sistema. O que fazer neste caso? Rollback da transação??? ahmmmm…não existe rollback na operadora de cartão de crédito! Mas mesmo se tivesse, ao meu ver essa não seria a solução ideal, afinal de contas, você perderia uma “venda”.

É aí que entra JMS e o título do post: “Contendo falhas de forma elegante”.

Nós adotamos a seguinte solução para este caso: Quando a operadora cobra o cliente, não há mais como voltar atrás, então, até esse ponto é fluxo é sincrono e, a autorização se tornou um fluxo assincrono. Com isso, foi criada uma  fila JMS e o cliente é colocado nesta fila para ser autorizado. A grande vantagem disso é que, em caso de um problema, a API do JMS possui uma propriedade configurável que faz com que ele retente processar de tempos em tempos. Com isso, caso o sistema não consiga autorizar o cliente na primeira vez, ele vai tentar novamente após 30 minutos, até 10 tentativas. Tempo suficiente para, se for um problema de banco por exemplo, o problema ser corrigido.

Mas não acaba aí, no JMS existe um conceito chamado “fila morta”. Caso após as 10 tentativas, o sistema não consiga processar aquela tarefa, ela será enviada para está fila. No nosso sistema, foi criada uma monitoração nesta fila. Caso algum registro caia na famigerada “fila morta”, o sistema irá alarmar e uma equipe responsável entrará em ação para solucionar o problema e após isso, reprocessar o registro.

Com isso, é possível uma ação totalmente pró-ativa, evitando assim chamadas na “Central de Atendimento” de clientes que pagaram e não receberam autorização para acessar o sistema.

Na nossa experiência aqui na empresa, JMS tem se mostrado uma excelente solução, tanto pela sua facilidade de uso com o auxílio de um servidor de aplicação, como o Jboss por exemplo, como também pela elegância e robustez que ele prove no seu uso.

Recomendo a todos os programadores Java a se aprofundarem neste assunto!

Um abraço!