Tive muitas dificuldades em implementar um conector Websphere MQ (WMQ) com o Apache CAMEL que podia lidar com relatórios de confirmação de entrega do MQ (CoD) sem exceções, nem efeitos colaterais na forma de datagramas de resposta indesejados. No final, consegui que funcionasse da maneira que queria, de maneira muito padrão e comum, se você está acostumado a gravar clientes nativos do MQ. Documentei o método em uma postagem para esse mesmo tópico, mas acho que a solução está cheia de complicações e gostaria muito de receber algum conselho ou exemplo para tornar a implementação mais limpa e elegante.

Entendi que o problema tem suas raízes na maneira como o MQ projetou o MEP (Request-Reply Message Exchange Pattern), em comparação com o que as especificações JMS fizeram, em comparação à implementação CAMEL do MEP de Request-Reply em seu componente JMS. Três filosofias diferentes!

O WMQ possui um cabeçalho MessageType (consulteCampos MQMD econstantes) que possui o valor 1 para solicitação, 2 para resposta e 8 para datagrama (MEP unidirecional). Além disso, o valor 4 é usado para marcar as mensagens de relatório na forma de CoD (Conf. De entrega), PAN (Reconhecimento positivo) e NAN (Reconhecimento negativo), que - em termos do fluxo de mensagens - também fornecem uma resposta adicional mensagem. As solicitações CoD, PAN e NAN podem ser solicitadas para Solicitar mensagens, Respostas ou Datagramas usando outro campo de cabeçalho chamado 'Relatório', no qual os sinalizadores para todas as variantes de relatório podem ser combinados. Os campos adicionais do cabeçalho 'ReplyToQ' e 'ReplyToQMgr' especificam o Gerenciador de filas e filas no qual os relatórios e respostas são esperados pelo remetente original e umfixo 24 bytes O campo 'CorrelId' - opcional - pode ajudar a correlacionar Relatórios e Respostas com a mensagem Datagrama ou Solicitação original. Para torná-lo mais complexo, pode-se realmente enviar Respostas e Relatórios com o mesmo ID da Mensagem original e sem o CorrelID, ou fornecer o ID da Mensagem original no CorrelId ou retornar o valor CorrelId quando já especificado no Pedido ou Datagrama original. A IBM fornece umaAPI JMS sobre WMQ, permitindo o tunelamento de trocas JMS simples sobre o WMQ como transporte (com ajuda de um nome de cabeçalho de mensagem extraMQRFH2), ou paramapear mensagens nativas do MQ para mensagens JMS e vice versa.Por outro lado, as especificações JMS fornecem um campo de cabeçalho 'JMSReplyTo' opcional e um 'JMSCorrelationID', mas deixam a semântica exata do MEP para aplicativos clientes; ou seja, declarando nas especificações: "Uma resposta pode ser opcional; cabe ao cliente decidir."O CAMEL apresenta 'rotas' em XML ou Java DSL e um modelo interno de Objetos do Exchange com o objetivo de suportarPadrões EIP entre os quaisRequest-Reply padronizar. CAMEL assume então na suaComponente JMS se o campo JMSReplyTo estiver configurado, isso é necessariamente uma Solicitação esperando uma resposta, fazendo com que a parte Out (ou parte modificada se Out estiver vazia) de um Exchange seja retornada à fila definida em JMSReplyTo.

Eu estava disposto a oferecer suporte a trocas nativas de mensagens do MQ com relatórios de confirmação de entrega (CoD) por meio de um Websphere Queue Manager remoto, para que, além da transação e persistência (ou seja, sem perda, sem duplicatas), também seja possível rastrear quando uma mensagem é consumida e gerar alertas em caso de atrasos.

Emissão de entrada:

Por padrão, o Websphere Queue Manager gera relatórios CoD quando o consumo de mensagens da fila é concluído. Portanto,sem configurações específicas, um cliente MQ remoto que envia um datagrama com o sinalizador CoD (e o obrigatórioToToTo) receberá uma primeira resposta como Relatório do MQ do Gerenciador de filas quando o terminal do CAMEL consumir a mensagem, seguido por uma segunda mensagem de resposta (inesperada) explicitamente retornado por CAMEL e contendo o que resta no objeto Exchange no final da rota CAMEL, porque CAMEL assume um EIP de solicitação-resposta, pois o campo JMSReplyTo está presente (mapeado no MQ ReplyToQ e ReplyToQMgr, ambos sendo necessários para oferecer suporte ao CoD fluxo de retorno).

Problemas de saída:

Sem configurações específicas, o CAMEL também assume por padrão um EIP / MEP de solicitação de resposta na conexão de saída. O terminal CAMEL JMS / MQ aguardará então1 resposta de volta. Quando a mensagem de saída é JMS sobre MQ (portanto, com o cabeçalho MQRFH2), isso funciona bem. Ao forçar o MQ simples, ou seja, removendo o cabeçalho do MQRFH2 como abaixo, não consegui que o ouvinte do nó de extremidade correspondesse ao Relatório do MQ recebido correlacionado, embora os valores rastreados pareçam todos corretos (impondo 24 IDs de correlação de caracteres para que o truncamento de valores CorrelId mais longos ou preenchimento nulo pelo MQ não pode colocar em risco o filtro de correlação). Alguém foi capaz de resolver esse problema?

Detalhes: Embora a API IBM JMS aceite transmitir valores específicos da propriedade JMS WMQ_MESSAGE_BODY = {1 | 0} / WMQ_TARGET_CLIENT = {1 | 0} para controlar a presença do cabeçalho JMS MQRFH2 nas mensagens geradas, essas opções se tornam inoperantes através do CAMEL. É preciso usar oCamelJmsDestinationName cabeçalho (conforme explicado no documento CAMEL JMS) para fornecer um URL da fila IBM para o destino, apresentando a opção "targetClient = 1" para livrar-se do cabeçalho MQRFH2. Mas sem esse cabeçalho, a correlação CAMEL no relatório CoD ou na resposta do MQ falha.

A solução para o problema acima é realmente sobre a construção de uma rota CAMEL específica para lidar com os relatórios CoD retornados pela parte remota (assim como as respostas do MQ correlatas). Portanto, as mensagens de saída do CAMEL devem ser aplicadas como "Em apenas" ExchangePattern e, portanto, não espere por qualquer resposta. Mas isso fará com que o CAMEL suprima também todos os campos ReplyTo. Então, se um MQ CoD for solicitado em um datagrama MQ de saída, uma exceção CAMEL ocorrerá cuja causa éMQException JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2027' ('MQRC_MISSING_REPLY_TO_Q').

O CAMEL documenta uma opção de URI 'disableReplyTo = true' para desativar a escuta de resposta nos padrões de troca e ainda manter os campos ReplyTo - aparentemente nas trocas de entrada e saída. Mas essa opção não funciona (como observado, posso estar errado) nas trocas JMS de saída e é preciso usar a opção 'preserveMessageQos' muito menos intuitiva.

Soluções elegantes para essas questões são bem-vindas.