MQ WebSphere MessageID Woes

Question

Another newb MQ Server question. I am building an ASP.NET C# application that needs to browse the message, save the message text to a database, and then read the message so it's removed from the queue. That way if the saving fails, the message is still in the queue and I don't have to ask it to be resent.

The problem is I need a way to uniquely identify the message when it is browsed so I can read (remove) it after a successful database save. I read about Correlation IDand MessageId and have trouble getting values.

The CorrelationId is always blank, so I can't use that. The messageId I cannot figure out how to convert it to something readable.

For example: MQ Explorer shows a messageID of: AMQ AZMEUNK62 bS Ý. MQ Explorer says the message ID bytes are: 414D512055534E4A5241523632202020126210532001DD02.

How do I convert the message ID bytes to that human readable string and back?

I've tried the code below which returns unusable result (AMQ AZMEUNK62 ↕b►S ☺?☻)

string msgIdStr = System.Text.Encoding.Default.GetString(mqMessage.MessageId); 
string strMsgId = Encoding.UTF8.GetString(mqMessage.MessageId, 0, mqMessage.MessageId.Length);

I tried these methods because of these posts-

Passing ids in IBM MQ client

How to convert byte[] to string?

Any thoughts most welcome.

Answer 1

The MQ Message and Correl (and Group) ID's aren't humanly readable, and I strongly suggest you keep them as binary, ie byte array (or convert to hex digits in a string or something like that if you really want a displayable version). The string contains AMQ , the beginning of the qmgr name, and some binary information (relating to date/time and a counter) for example. (A common problem seen in C applications are people strcpy'ing it, which truncates at the first null and never matches anything)

A better question here is what is your actual problem. You can browse, get message under cursor or if you know the msgid you can get by message id. You could get under syncpoint which doesnt remove it until you commit after the database update, or you could look at having the get in the same transaction as the database update... there's loads of options, it depends on what you need!