Assegurando-se de que as Mensagens Não Serão Perdidas

É importante proteger as mensagens que fluem pelo domínio do seu intermediário. Isso é válido para as mensagens geradas pelo aplicativo e as utilizadas internamente para comunicação entre componentes. As mensagens utilizadas internamente entre componentes sempre utilizam o protocolo . As mensagens de aplicativos podem utilizar todos os protocolos de transporte suportados.

Para mensagens de aplicativos e internas que viajam pelo , duas técnicas protegem contra a perda de mensagens:

Para obter informações adicionais sobre como utilizar essas opções, consulte Guia de Administração do Sistema.

Mensagens Internas

Os componentes do utilizam mensagens do para comunicar eventos e dados entre processos e subsistemas do intermediário e o e o . Os componentes asseguram que os recursos do sejam explorados para proteção contra a perda de mensagens. Não é necessário executar nenhuma etapa adicional para configurar ou para proteger-se contra a perda de mensagens internas.

Mensagens de Aplicativos

Se a entrega de mensagens de aplicativos for crítica, será necessário projetar programas aplicativos e os fluxos de mensagens que eles utilizam para assegurar que as mensagens não sejam perdidas. As técnicas utilizadas dependem do protocolo utilizado pelos aplicativos.

e
Se estiver utilizando os nós de entrada internos que aceitam mensagens através dos protocolos ou , você poderá utilizar as seguintes pautas e recomendações:
  • Utilizando Mensagens Persistentes

    Os produtos do sistema de mensagens do fornecem persistência de mensagem, que define a duração da mensagem no sistema e garante a integridade da mensagem. As mensagens não-persistentes serão perdidas caso ocorra uma falha no sistema ou gerenciador de fila. Mensagens persistentes são sempre recuperadas no caso de uma falha.

    Você pode controlar a persistência de mensagem das seguintes maneiras:
    • Programe seus aplicativos que colocam mensagens em uma fila utilizando o MQI ou AMI para indicar que as mensagens são persistentes.
    • Defina a fila de entrada com persistência de mensagem como a definição padrão.
    • Configure o nó de saída para tratar mensagens persistentes.
    • Programe seus aplicativos de assinante para solicitar persistência de mensagem.

    Quando um nó de entrada lê uma mensagem que é lida a partir de uma fila de entrada, a ação padrão é utilizar a persistência definida no cabeçalho de mensagens (MDMQ) do que foi definido pelo aplicativo que criou a mensagem ou pela persistência padrão da fila de entrada. A mensagem retém essa persistência durante o fluxo de mensagens, a menos que seja alterada em um nó de processamento de mensagens subseqüente.

    Você pode substituir o valor de persistência de cada mensagem quando o fluxo de mensagens terminar em um nó de saída. Este nó possui uma propriedade que permite a você especificar a persistência de cada mensagem quando ela é colocada na fila de saída, como o valor solicitado, ou como um valor padrão. Se você especificar o padrão, a mensagem utiliza o valor de persistência definido para as filas nas quais as mensagens são gravadas.

    Se uma mensagem passar por um nó Publication, a persistência de mensagens enviadas para assinantes será determinada pelas opções de registro dos assinantes. Se um assinante tiver solicitado entrega persistente de mensagem, e for autorizado para fazer isto por ACL explicita ou implícita (herdada), a mensagem é entregue de maneira persistente independente de sua propriedade de persistência existente. Além disso, se o usuário tiver requisitado entrega de mensagem não-persistente, a mensagem será entregue de modo não-persistente independente da existência de sua propriedade de persistência.

    Se um fluxo de mensagens criar uma nova mensagem (por exemplo, em um nó Compute), a persistência no MQMD da nova mensagem será copiada a partir da persistência no MQMD da mensagem recebida.

  • Processando Mensagens sob Controle do Ponto de Sincronização

    A ação padrão de um fluxo de mensagens é processar mensagens de entrada sob o ponto de sincronização em uma transação controlada pelo intermediário. Isso significa que uma mensagem que falha ao ser processada por qualquer motivo é recuperada pelo intermediário. Como ela foi recebida sob o ponto de sincronização, a mensagem com falha será reindicada na fila de entrada e poderá ser processada novamente. Se o processamento falhar, os procedimentos de tratamento de erros que estão configurados para esse fluxo de mensagens (definidos pela forma que o fluxo de mensagens foi configurado ou pelo intermediário) serão executados.

    Para obter detalhes completos do processamento de nós de entrada, consulte Gerenciando Erros no Nó Input.

Se você estiver utilizando o nó de entrada interno SCADAInput que aceita as mensagens dos dispositivos de telemetria através do protocolo MQIsdp, esse protocolo não possui um conceito de filas. Os clientes conectam-se a um nó SCADAInput especificando o número da porta na qual o nó está atendendo. As mensagens são enviadas para clientes utilizando um clientId.Entretanto, você pode especificar um QoS (Quality of Service) máximo dentro de uma mensagem de assinatura SCADA, que é semelhante à persistência:
  • QoS0 Não-persistente.
  • QoS1 Persistente, mas pode ser entregue mais de uma vez
  • QoS2 Entrega uma única vez

Se uma mensagem SCADA persistente for publicada, ela poderá ser reduzida para o mais alto nível que o cliente pode aceitar. Em algumas circunstâncias, isso pode significar que a mensagem se torna não-persistente.

, e
Se você estiver utilizando os nós de entrada internos Real-timeInput e Real-timeOptimizedFlow que aceitem mensagems dos aplicativos JMS e multicast, ou nós HTTP Input e HTTPRequest que aceitem mensagens dos aplicativos de serviços da Web,não haverá recursos disponíveis para proteção contra perda de mensagens. No entanto, você pode fornecer procedimentos de recuperação, configurando o fluxo de mensagens para tratar seus próprios erros.
Outros Transportes e Protocolos
Se você criou seus próprios nós de entrada definidos pelo usuário que recebem mensagens de outro protocolo de transporte, deverá contar com o suporte fornecido por esse protocolo de transporte ou fornecer seus próprios procedimentos de recuperação.

Conceitos relacionados
Fluxos de Mensagem
Suporte ao Aplicativo para o Usuário Final

Tarefas relacionadas
Projetando um Fluxo de Mensagens
Criação de um Fluxo de Mensagens
Definindo o Conteúdo do Fluxo de Mensagens
Tratando Erros em Fluxos de Mensagens
Gerenciando Erros no Nó Input
Suportando Aplicativos de Usuário Final

Referências relacionadas
Nós Internos