CODEWITHSUNDEEP
node.jsformatibm-mqmqtttelemetry
dng
dng

Reputation: 501

IBM WebSphere / MQTT.js : Convert MQHRF2 to MQSTR format

I have a client in NodeJS using the MQTT module (mqtt.js) to communicate with a topic of WebSphere MQ, redirected to a queue : I need the result to be on a queue so I use a topic between the source and the destination (since MQTT protocol communicate only with topics).

So we have : NodeJS (source) -> Topic of Websphere MQ (intermediate) -> Queue of Websphere MQ (destination)

The problem is that the received messages on the queue of WebsphereMQ are MQHRF2 format but I need MQSTR.

I did not find any property in mqtt.js side to specify the format.

I supposed we can force it with IBM Websphere MQ, but how ? Can I create a channel or anything for this use, that's to say convert the receiving format ?

Thanks in advance for your help !

Configuration :

Constrains :

It works correctly when I publish directly on a topic via the WebSphere MQ explorer. However, it fails when I publish from the NodeJS application.

I tried both methods listing in the comments but I found a weird thing : The result is different according to if I use MQExplorer (what I always used) or the MQ console :

On the MQ Explorer : MQ Explorer

On the MQ Console, with the command : amqsbcg QUEUE_MQTT_VERIF MQTTVerification : MQ Console, with the command : amqsbcg QUEUE_MQTT_VERIF MQTTVerification

As you can see, in the console, the format field is empty, whereas on the MQExplorer it is MQHRF2. The messages are also different.

So the result on the MQConsole is right whereas the MQExplorer still shows a wrong result after the changes. Note that the result is right only if changes has been done on both :

Maybe the source of the problem is just the display on MQExplorer software ?

EDIT:

The difference between MQExplorer and MQConsole was due to the parameter in MQ Explorer : Window -> Preferences -> WebSphereMQ Explorer -> Message properties -> Uncheck "Display message properties".

Upvotes: 2

Views: 1918

Answers (1)

Morag Hughson
Morag Hughson

Reputation: 7525

When redirecting publications made on a topic to a queue you probably have some definitions like this:-

DEFINE QLOCAL(PRICES)
DEFINE TOPIC(APPLES) TOPICSTR('Price/Fruit/Apples')
DEFINE SUB(APPLE.PRICES) TOPICOBJ(APPLES) DESTCLAS(PROVIDED) DEST(PRICES)

which redirects publications made on the topic string 'Price/Fruit/Apples' to the queue PRICES.

What you will find with such a set up however, is that the topic string is added to the message by the queue manager and thus adds an MQRFH2 header onto the front of your published message.

Message Descriptor (MQMD)
Report       :00000000
Message Type :8 (Datagram)
Format       :'MQHRF2  '
Priority     :0
Persistence  :0 (Not Persistent)
Message Id   :414D51204D51473120202020202020202D77835720003702
              'AMQ MQG1        -w.W .7.'
ReplyToQ     :'                                                '
ReplyToQMgr  :'MQG1                                            '
[  102 bytes] Message Content
<mqps>
  <Top>
    Price/Fruit/Apples
  </Top>
</mqps>
Apples are $2/kilo

To remove this without changing the application reading from the queue, make this alteration to the subscription.

ALTER SUB(APPLE.PRICES) PSPROP(NONE)

This stops the queue manager even putting the topic string into the message in the first place.

From your MQ Explorer screenshot, it can be seen that the MQRFH2 is still present after the SUB is changed to PSPROP(NONE) because there is another property present - mqtt.clientid. Since there are other items in the MQRFH2 as well as the topic string, then the SUB change will not remove those - only the topic string added by the queue manager. In that case, you should try the following.

If alternatively you want to have the topic string there sometimes and only remove it for applications that don't want to see it, you can make a similar change to the queue, which can be over-ridden in application code to force the properties to be delivered to the application, but otherwise they won't be. This would also allow you to read any existing messages that had already been published (the change to the SUB isn't retrospectively applied to messages that are already on the queue).

ALTER QLOCAL(PRICES) PROPCTL(NONE)

This will mean that applications that don't specifically request MQGMO_FORCE_RFH2 will see the message without the MQRFH2. The amqsbcg sample is one such application.

If an application codes MQGMO_FORCE_RFH2 it will still be able to see the properties in an MQRFH2 header because it has explicitly asked for that. You cannot stop that by changing the queue.

Your problem is only now with the way MQ Explorer chooses to display the message. There is a parameter in MQ Explorer : Window -> Preferences -> WebSphereMQ Explorer -> Message properties -> Uncheck "Display message properties" which will stop it forcing them to be an MQRFH2, and then you'll be all good.

Upvotes: 2

Related Questions