The issue I am having with the above is my test harness is sending an MQ message to an Wm Q listener. A document is created from the message body which includes the MsgId and CorrelId and is published to a broker. A subscriber receives the document and moves the MsgId to the CorrelId field so that the client can match the reply with the request. The problem is that the CorrelId on the reply message in the client is not always matchable with the MsgId originally sent and I can’t figure out why. There is a variation between the MsgId sent and the CorrelId received. It is apparent that the CorrelId received is based on the original MsgId but is slightly changed.
MsgId 414D512042524C54383537383320202052 -->8986<-- 3F20000501
CorrelId 414D512042524C54383537383320202052 -->3F3F<-- 3F20000501
It may well be the way I am configuring MQ but I can’t be sure as sometimes it is fine.
MsgId as displayed in the testharness GUI on client
MsgId displayed in webmethods IS by custom java Service prior to publish
and. Same is displayed by subscriber.
CorelId as displayed in the MQ console GUI on WebMethods host
CorrelId as displayed in browsing the MQ queue using amqsbcg on client
When it does work it seems that if the CorrelId ends in 3F
(for example: 414D512042524C5438353738332020205289863F2000053F)
It seems to cause 12 of the following messages to have CorrelIds generated by the MQ server on the Wm host which bear no relation to the MsgIds sent and are consequently not matchable.
I am running WebMethods IS 6.0.1 on Windows 2000, Version 3.0 of the MQ Adapter and version 5.3 of MQ on both testharness client and IS hosts and have remote queues and channels between them.
Can anyone help?