Hespanha

JMS é uma API do Java para lidar com troca de mensagens em aplicações. Devido a popularização da integração de sistemas por meio de mensagens, seu uso tem aumentado muito nos últimos tempos, principalmente pelo fato de ser extremamente simples integrar dois sistemas usando JMS. Porém, neste post, pretendo falar de uma outra utilidade muito interessante de JMS, a qual adotamos no último projeto que participei e que deu um resultado muito positivo para o sistema aumentando significativamente a sua robustez.

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!

É preciso tomar cuidado quando você está usando uma enum como retorno de um Session Bean. Tanto o servidor quanto o cliente precisam estar sempre com a mesma versão da enum. Caso você altere a enum do lado do servidor, mas não mudar a versão que está no cliente, se por um acaso a constante que você adicionou no enum for a retornada pelo Session Bean, subirá uma exceção no cliente. Não existe nada parecido com o conceito de serialVersionUid com o uso de enums.

Por um lado, essa característica é boa, pois força o seu cliente a sempre estar com a mesma versão da que está rodando no servidor. Mas, por outro lado, as vezes você quer adicionar uma constante ao seu enum, que em nada interfirá na maioria dos sistemas que estão usando o seu. Por exemplo:

-Um determinado sistema trata retornos com status PAGO e NÂO_PAGO.

Você quer adicionar um novo status de ANALISE na sua enum. Em tese, esse status não interessa para o sistema descrito acima, então, caso ele receba esse status ele poderia simplesmente ignora-lo. Mas com enum isso não é possível. Ou seja, se você tem 50 sistemas usuários do seu, e quer adicionar um novo status que só interessa para um deles, você é obrigado a forçar os 50 sistemas a atualizarem a versão “client” que receberam do seu.