Conector JMS Escuta e Reconhece Atividades em Sessões Transacionadas¶

Propósito¶

Uma Sessão Transacionada para uma Atividade de Atendimento JMS permite que um usuário receba uma mensagem e trabalhe com seus dados, tudo dentro de uma transação.

Enquanto a mensagem é despachada para o sistema Jitterbit, o corretor (como Apache ActiveMQ) bloqueia a mensagem para que outros ouvintes não possam captar a mesma mensagem. Quando o usuário estiver satisfeito com o processamento da mensagem, ele usará uma Acknowledge Activity para notificar o intermediário para remover a mensagem bloqueada da fila (ação: JBXCommit); em outras palavras, a mensagem foi processada com sucesso e não é mais necessária.

Há casos em que, durante o processamento da mensagem no fluxo do processo, torna-se apropriado liberar a mensagem de volta para a fila para que ela possa ser processada novamente ou por um ouvinte diferente. Nesses casos, a Atividade de Reconhecimento pode ser utilizada para informar ao broker que deve liberar o bloqueio da mensagem e deixá-la ser processada novamente (ação: JBXRollback).

Um desses casos são os eventos de falha. Normalmente, as mensagens são despachadas para o Jitterbit System e depois para um Jitterbit Agente Privado. Enquanto a operação é executada pela lógica de negócios, é possível que o agente falhe, o servidor desligue ou ocorra uma exceção. Em qualquer um desses eventos, onde um JBXCommit explícito não foi enviado de volta ao intermediário, o intermediário reverterá a mensagem para evitar a perda de dados. Rollback significa que a mensagem é liberada de volta para a fila para reprocessamento por quaisquer consumidores ativos dessa fila.

Visão Geral¶

Para usar sessões transacionadas com o Jitterbit JMS Connector, certas configurações devem ser usadas. Este documento abrange essas configurações e fornece exemplos de cenários que mostram como as transações podem ser usadas.

Atividade de Escuta JMS¶

A Atividade de escuta JMS é configurada conforme descrito em Atividades de escuta do conector JMS. Para aproveitar a confirmação baseada no cliente, a propriedade Transacted Session deve ser definida como True.

Quando um Transacted JMS Listener recebe uma mensagem, ele espera até:

• Recebe uma confirmação de JBXCommit:
  Nesse caso, a sessão é confirmada e a mensagem é removida do broker.
• Recebe uma confirmação de JBXRollback:
  Nesse caso, a sessão é revertida, o bloqueio é removido pelo corretor e a mensagem é colocada de volta na fila.
• Desconexão de Conexão ou Sessão para o corretor (Agente Privado parado ou travado, desligamento ou travamento do servidor, etc.):
  Nesse caso, o corretor executará uma reversão automática para preservar a mensagem. A reversão só acontecerá enquanto um JBXCommit explícito não for recebido pelo broker.
• Tempo limite de confirmação atingido:
  Nesse caso, uma confirmação de reversão é enviada automaticamente ao intermediário para liberar a mensagem de volta à fila. Esse limite existe para tratar de casos em que uma operação fica travada em um estado de execução muito longa que está fora do intervalo aceitável de processamento de mensagens.

Atividade de Reconhecimento JMS¶

A atividade JMS Acknowledge permite controlar o destino de uma mensagem enviando a ação JBXCommit ou JBXRollback. Isso é feito especificando a atividade na Confirmação de solicitação de transformação.

• AcknowledgmentAction
  • Valores válidos: "JBXCommit" ou "JBXRollback"
  • Não diferencia maiúsculas de minúsculas, mas deve ser escrito conforme listado
  • Ao entrar na transformação, inclua as aspas duplas de abertura e fechamento, pois é do tipo String

• AcknowledgmentMessageID

  • Valor válido: O JMS Message ID da mensagem recebida pelo JMS Listener

  • Este ID pode ser extraído e salvo em uma variável global ao receber a mensagem no Listen Response Transformation (veja a captura de tela)

    

  • A variável global pode então ser usada para a propriedade AcknowledgmentMessageID na Acknowledge Request Transformation

Tempo Limite de Confirmação¶

Essa propriedade permite que o usuário especifique o número de segundos após o qual uma mensagem é revertida automaticamente. Isso evita que uma mensagem fique parada no processamento para sempre ou por mais do que um período de tempo aceitável. Essa propriedade deve ser configurada na Transformação de Solicitação de Envio/Publicação para a Atividade JMS SendOrPublish.

Exemplos¶

Nesses exemplos, recebemos uma mensagem de uma Atividade de escuta JMS, extraímos o ID da mensagem JMS e o salvamos em uma variável. Em seguida, anexamos uma Atividade de Reconhecimento JMS como a operação"On Success". Se tudo correr bem com a Atividade de escuta JMS, a Atividade de reconhecimento simplesmente confirma a transação (removendo a mensagem da fila) conforme terminamos de processar essa mensagem. Da mesma forma, outra Atividade de Reconhecimento JMS pode ser criada e anexada como a operação"Na falha".

É importante observar que, em muitos casos de uso, o JMS Acknowledge não deve ser a próxima operação na cadeia "On Success" se houver trabalho adicional a ser feito com os dados da mensagem. Em vez disso, a Atividade de reconhecimento JMS deve ser incluída quando todas (ou quase todas) as operações forem concluídas com êxito e não precisarmos mais da mensagem.

Variação 1¶

Ouvinte JMS com confirmação de confirmação com OnSuccess e confirmação de reversão com eventos OnFailure.

Variação 2¶

Essa variação mostra o uso de uma operação de lógica de negócios adicional que executa um trabalho adicional com os dados da mensagem. Nessa variação, se o Ouvinte ou a lógica de negócios falhar, ocorrerá uma reversão. Se tudo passar e a lógica de negócios for concluída com sucesso, ela confirmará a transação.

Variação 3¶

Essa variação é muito semelhante ao cenário anterior. Porém, ao invés de fazer commit automaticamente OnSuccess da operação Business Logic, usamos uma chamada para o Jitterbit RunOperation() função no Customer Logic Script para controlar exatamente quando no script queremos confirmar:

RunOperation("<TAG>Operations/4. JMS Acknowledge (Commit)</TAG>", true);

E uma chamada semelhante no script se houver um erro e a transação precisar ser revertida:

RunOperation("<TAG>Operations/3. JMS Acknowledge (Rollback)</TAG>", true);

Isso coloca o ônus no desenvolvedor para determinar as condições de sucesso ou falha. No entanto, em certos casos de uso, isso pode ser essencial para o controle desejado.

Dicas e Sugestões¶

Definindo o Tempo Limite de Confirmação Quando Não Estiver Usando o Sistema Jitterbit¶

A propriedade de tempo limite de confirmação está disponível (na atividade SendOrPublish) se uma mensagem estiver sendo enviada para uma fila de dentro do Jitterbit. Mas e se você quiser controlar o timeout, mas tiver um sistema diferente inserindo as mensagens na fila? A solução: ao criar uma mensagem, basta adicionar uma propriedade Integer na mensagem JMS com a chave JBXAcknowledgmentTimeout e um valor do tempo limite necessário em segundos.

As Mensagens JMS Estão Sendo Confirmadas Automaticamente, Mesmo Sem Chamar a Atividade de Reconhecimento¶

Verifique se o JMS Listener está configurado com Transacted Session definido como True. Confirme se não há atividade de reconhecimento relacionada que está sendo disparada.

As Mensagens Que Falham Continuam Sendo Apanhadas Novamente e Falhando Novamente¶

Se, quando ocorrer uma falha, as mensagens forem revertidas, elas serão colocadas de volta na fila. Como há um ouvinte na fila, ele irá pegar a mensagem e tentar processá-la novamente. Uma solução é ajustar a política de reentrega do corretor (por exemplo, Apache ActiveMQ) para ajustar os atrasos e contar a Dead Letter Queue (DLQ).

As Mensagens Que Continuam Falhando Eventualmente Desaparecem¶

Se o Modo de entrega de uma mensagem for definido como PERSISTENTE, a mensagem não será perdida. Ele simplesmente foi movido para a Dead Letter Queue (DLQ), conforme configurado pelo corretor. Se o Delivery Mode de uma mensagem for NON_PERSISTENT, então a mensagem foi perdida após um certo número de reentregas (se exceder a configuração do corretor para máximo de reentregas).