| Author |
Message
|
| Yoel |
 Posted: Mon Aug 24, 2015 5:15 am Post subject: How to read/write MQ headers using Monitoring events |
 |
|
Novice
Joined: 03 Apr 2012
Posts: 17
|
Hello friends,
I'm trying to write from an IIB v9 monitoring event - an entire MQ message (MQ headers and body) , and read the message later in a different flow / java app to store the payload and headers in a database in a readable way.
Should I select 'All' in 'include bitstream data in payload' in the event?
If so, I must select a binary format (base64Binary or hexBinary) since the MQ headers are binary. How would I parse the bitstream in the reading flow / java app, so I can write the info into a database?
Any Ideas?
Thanks |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Aug 24, 2015 5:35 am Post subject: Re: How to read/write MQ headers using Monitoring events |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Yoel wrote: |
| Should I select 'All' in 'include bitstream data in payload' in the event? |
Yes.
| Yoel wrote: |
| If so, I must select a binary format (base64Binary or hexBinary) since the MQ headers are binary. How would I parse the bitstream in the reading flow / java app, so I can write the info into a database? |
The same way you'd parse any bitstream that was encoded as base64 or hexBinary. Seriously. There's nothing "magic" about that content.
So whatever "different flow / java app" you're using, use the standard features for that language.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Yoel |
| Posted: Mon Aug 24, 2015 5:55 am Post subject: |
|
|
Novice
Joined: 03 Apr 2012
Posts: 17
|
Thank you Vitor.
So without any magic, how would you parse a bitstream of an mq message?
Lets talk about ESQL so we can be specific with the answers. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Aug 24, 2015 6:03 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Yoel wrote: |
So without any magic, how would you parse a bitstream of an mq message?
Lets talk about ESQL so we can be specific with the answers. |
With a PARSE. Or to be specific, the PARSE option. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Yoel |
| Posted: Mon Aug 24, 2015 11:29 am Post subject: |
|
|
Novice
Joined: 03 Apr 2012
Posts: 17
|
| Vitor wrote: |
| With a PARSE. Or to be specific, the PARSE option. |
In the docs in the above link there is a distinction between 'Body parsers' and 'Header parsers'.
The reason I thought the requirement to parse any MQ message will be challenging is that there might be an unknown amount of headers in addition to the body in a single bitstream message.
Would the BLOB or XMLNSC parsers deal with these headers easily? (Well, I thought this was magic)  |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Aug 24, 2015 11:33 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Yoel wrote: |
| The reason I thought the requirement to parse any MQ message will be challenging is that there might be an unknown amount of headers in addition to the body in a single bitstream message. |
There might well be.
| Yoel wrote: |
| Would the BLOB or XMLNSC parsers deal with these headers easily? |
They won't deal with them at all, any more than they deal with them in the flow producing the event message.
I said you'd deal with them as you'd deal with them in any other encoded stream. I never said you could do it with a single ESQL statement (or any other single line of code in any other language.
I would also point out that there are never an "unknown" number of headers in an MQ message. There are always an exact and easily determined number & type.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Yoel |
| Posted: Mon Aug 24, 2015 11:56 am Post subject: |
|
|
Novice
Joined: 03 Apr 2012
Posts: 17
|
Thank you very much for your help.
| Vitor wrote: |
| I would also point out that there are never an "unknown" number of headers in an MQ message. There are always an exact and easily determined number & type. |
Obviously there must be an easy way to determine the number and type of the headers. Can you please share this knowledge or a reference to it.
An example of code in any programming language can also do the job.
Thanks again! |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Aug 24, 2015 12:04 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Yoel wrote: |
| Obviously there must be an easy way to determine the number and type of the headers. |
| Yoel wrote: |
Can you please share this knowledge or a reference to it.
An example of code in any programming language can also do the job. |
Start here and here, then follow the links.
Be aware that, if the java app you mention previously is using JMS rather than the native MQ jars, the actual message headers are rolled up according to the JMS documentation as described here. So if you're examining the actual message with JMS it appears to have JMS headers, but the actual encoded bitstream will have the actual headers from the payload.
It can cause confusion.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Yoel |
| Posted: Mon Aug 24, 2015 11:04 pm Post subject: |
|
|
Novice
Joined: 03 Apr 2012
Posts: 17
|
| Vitor wrote: |
Start here and here, then follow the links.
|
After reading the quoted reference following the links..
Are you suggesting I have to calculate the length of the MQMD, cut and parse that part of the BLOB.
Then read the format field of the MQMD:
if its a string - cast the rest to character
or if its RFH2 - cut and parse the RFH part and then cast the message to character? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Aug 25, 2015 4:24 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Well... it all depends. Which version of MQ are you using??
And what language are you using to read MQ?
And if that is ESQL why are you not letting the broker deal with the headers?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Aug 25, 2015 4:29 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Yoel wrote: |
| Are you suggesting I have to calculate the length of the MQMD |
No. Unless you've noticed some variable length fields in the MQMD I've missed.
| Yoel wrote: |
Then read the format field of the MQMD:
if its a string - cast the rest to character
or if its RFH2 - cut and parse the RFH part and then cast the message to character? |
Or otherwise process appropriately. There are a lot more possibilities than "string" and "RFH2". Including other headers before you get to the payload.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Yoel |
| Posted: Tue Aug 25, 2015 6:10 am Post subject: l |
|
|
Novice
Joined: 03 Apr 2012
Posts: 17
|
| fjb_saper wrote: |
Well... it all depends. Which version of MQ are you using??
|
I'm using MQ v8.
| fjb_saper wrote: |
And what language are you using to read MQ?
|
Currently I'm using ESQL.
I do have thoughts, though, to move this at a later point to an external java app to save some pvu..
| fjb_saper wrote: |
And if that is ESQL why are you not letting the broker deal with the headers?
|
I'll love to let the broker do the work if I just knew how.
This is where I am up to:
I am getting a base64Binary from the event which is equivalent to a BLOB.
Now, how do I take a BLOB and just tell the broker this is an MQ message.
I am looking for a wide solution to read monitoring events from all flows, so headers and format of the body might change at a later point, and I would like my solution to store at least the header in a readable way. The majority of the message body's will be textual and therefor readable.
If that is a problem Ill stick with only rfh headers and only string bodys as this covers the majority.
So, what is that easy way to "letting the broker deal with the headers"?
Thanks a lot! |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Aug 25, 2015 6:19 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You might need to split the BLOB at the start of your message data, and then parse the first chunk using the MQ domain and the second chunk using your proper message domain.
Obviously, all of this after you decode the message data.
You might also be able to just use an RCD node.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| Yoel |
| Posted: Tue Aug 25, 2015 6:22 am Post subject: |
|
|
Novice
Joined: 03 Apr 2012
Posts: 17
|
| Vitor wrote: |
| No. Unless you've noticed some variable length fields in the MQMD I've missed. |
Agreed. No length field.
But asuming I have to feed the 'Header parsers' with only headers, and noticing the fields of MQMD are fixed length - it can be calculated (after extracting ther version from the correct position in the BLOB)
What is the answer, if not this? do I give the 'Header parsers' the entire message?
| Vitor wrote: |
Or otherwise process appropriately. There are a lot more possibilities than "string" and "RFH2". Including other headers before you get to the payload. |
I was not clear. I meant to keep it simple, in these are the basic, and the most frequent I can see in my senario.
Thanks for all of your help! |
|
| Back to top |
|
|
| timber |
| Posted: Tue Aug 25, 2015 7:44 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
I don't think you can use CREATE...PARSE to parse a BLOB into its various header/body trees. But an MQInput node does that job really nicely. Any reason not to use an intermediate queue, and let IIB do the heavy lifting for you?
Once you have a message tree containing the MQ, RFH2 and body you can copy each header into OutputRoot.XMLNSC and get its XML representation. |
|
| Back to top |
|
|
|
|
