|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
Where is the data in the message tree ? |
« View previous topic :: View next topic » |
Author |
Message
|
Cogito-Ergo-Sum |
Posted: Tue Dec 21, 2010 9:03 am Post subject: Where is the data in the message tree ? |
|
|
 Master
Joined: 07 Feb 2006 Posts: 293 Location: Bengaluru, India
|
To simplify, I started with a FileInput node whose Out is connected to a JavaCompute node. The Out of JavaCompute node is connected to In of a FileOutput node. In the JavaCompute node, for every record communicated by FileInput node, I just want to append a dummy message. My problem is, I do not know JUST WHERE is the message data in the tree. Most examples in the infocenter are so lopsided towards the XML that I am not able to understand how to handle this simple requirement.
As per Message tree, the Body is the last child of the root. Where is the 'real data' ?
This attempt gets me garbage.
Code: |
// Add user code below
MbElement inBody = inMessage.getRootElement().getLastChild().getFirstChild();
String bodyData = "JC01 Test Message " ;
bodyData += (String) inBody.getValue();
MbElement outRoot = outMessage.getRootElement();
// Create the Broker Blob Parser element
MbElement outParser = outRoot.createElementAsLastChild(MbBLOB.PARSER_NAME);
// Create the BLOB element in the Blob parser domain with the required text
MbElement outBody = outParser.createElementAsLastChild(MbElement.TYPE_NAME_VALUE, "BLOB", bodyData);
|
_________________ ALL opinions are welcome.
-----------------------------
Debugging tip:When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.
---Sherlock Holmes |
|
Back to top |
|
 |
Vitor |
Posted: Tue Dec 21, 2010 9:08 am Post subject: Re: Where is the data in the message tree ? |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
Cogito-Ergo-Sum wrote: |
As per Message tree, the Body is the last child of the root. Where is the 'real data' ? |
2 slightly obvious answers:
In the Body where the documentation says it is;
Where it shows up in the Trace.
(Seriously - when you don't know what WMB is doing, or why it's finding / not finding data, put a Trace node in the flow & take a user trace. Much more information than the debugger).
2 equally obvious questions:
What are you parsing the input with?
Why are you using BLOB for the output? _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
Vitor |
Posted: Tue Dec 21, 2010 9:10 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
And of course, what's in the input file? An XML document? Or (my personal guess) a flat file? _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
Cogito-Ergo-Sum |
Posted: Tue Dec 21, 2010 9:31 am Post subject: |
|
|
 Master
Joined: 07 Feb 2006 Posts: 293 Location: Bengaluru, India
|
Quote: |
What are you parsing the input with? |
Err...I am not parsing the input because I do not want to. Just read the record off the input file, append some text to it and write it out.
Quote: |
Why are you using BLOB for the output? |
Because, my output will not be XML. Or, in other words, because MRM et al sound like 'overkill' for my simple(?) requirement.
Quote: |
And of course, what's in the input file? An XML document? Or (my personal guess) a flat file? |
A flat file. _________________ ALL opinions are welcome.
-----------------------------
Debugging tip:When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.
---Sherlock Holmes |
|
Back to top |
|
 |
mqjeff |
Posted: Tue Dec 21, 2010 9:51 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
If the input message is a BLOB, it would be much easier to copy the entire message and then replace the contents of the output BLOB element than to try and build it.
Also please define "garbage". What does your code actually produce? |
|
Back to top |
|
 |
Vitor |
Posted: Tue Dec 21, 2010 10:09 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
Cogito-Ergo-Sum wrote: |
Quote: |
What are you parsing the input with? |
Err...I am not parsing the input because I do not want to. Just read the record off the input file, append some text to it and write it out. |
It's a little short sighted. Also BLOB, by definition, has not format. It's not a character string that can be appended to.
Cogito-Ergo-Sum wrote: |
Quote: |
Why are you using BLOB for the output? |
Because, my output will not be XML. Or, in other words, because MRM et al sound like 'overkill' for my simple(?) requirement. |
a) If it was XML you wouldn't need MRM because XML is self-defining
b) So a message set with 2 elements: "OriginalFile" and "AppendedText" is too much like hard work? IMHO it's an investment.
Cogito-Ergo-Sum wrote: |
Quote: |
And of course, what's in the input file? An XML document? Or (my personal guess) a flat file? |
A flat file. |
So you don't even need to build a message set by hand. Have WMB build the message set from the file definition, add an "AppendedText" element and you're done.
You're also future proofed when someone extends your simple requirement to have the appeneded text vary by message content, or routed by message content, or written out in a different code page, etc, etc. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
Cogito-Ergo-Sum |
Posted: Tue Dec 21, 2010 7:07 pm Post subject: |
|
|
 Master
Joined: 07 Feb 2006 Posts: 293 Location: Bengaluru, India
|
Quote: |
So a message set with 2 elements: "OriginalFile" and "AppendedText" is too much like hard work? IMHO it's an investment. |
Conceptually, there is this thing that I have still not understood. The fundamental thing about WMB are the trees that propagate from node to node. One such tree is the Message tree that has a Root and a few children to it (Properties, MQMD, etc.). One such child of the Message tree is Body which holds the 'real data'. If I am correct until now, then my question is just this. Once I have navigated to the Body (Root.getLastChild), how do I then navigate to the actual text ?
I think, I am still thinking from the perspective of a simple COBOL program that reads a record, appends some text to it and writes it out. That is why, the message sets seem like 'hard work'. _________________ ALL opinions are welcome.
-----------------------------
Debugging tip:When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.
---Sherlock Holmes |
|
Back to top |
|
 |
fjb_saper |
Posted: Tue Dec 21, 2010 8:44 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Cogito-Ergo-Sum wrote: |
I think, I am still thinking from the perspective of a simple COBOL program that reads a record, appends some text to it and writes it out. That is why, the message sets seem like 'hard work'. |
Well your analogy is very much oversimplified.
What you have is a COBOL program that's written out some text. You have then another COBOL program that's reading some bitstream and appending some text to it. However you have no idea whether the bitstream that was read in was in ASCII or in EBCDIC, which specific code page it was in, and whether the text you added to it is in a compatible format or not... (ASCII + EBCDIC)...
So if you want to add something to your BLOB make sure it is translated / cast to a BLOB and use the InputRoot.Properties.CodedCharSet to cast to BLOB...
Best practice says to parse the input BLOB using a message set, append the Data to the tree and let the serialization process happen. This way if you switch CCSID from input to output you should have no problems as long as there is no character that cannot be represented in the output CCSID.
Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
Cogito-Ergo-Sum |
Posted: Wed Dec 22, 2010 12:08 am Post subject: |
|
|
 Master
Joined: 07 Feb 2006 Posts: 293 Location: Bengaluru, India
|
Quote: |
However you have no idea whether the bitstream that was read in was in ASCII or in EBCDIC, which specific code page it was in, and whether the text you added to it is in a compatible format or not... (ASCII + EBCDIC)... |
No, I do. It is guaranteed that the encoding will be EBCDIC. _________________ ALL opinions are welcome.
-----------------------------
Debugging tip:When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.
---Sherlock Holmes |
|
Back to top |
|
 |
Cogito-Ergo-Sum |
Posted: Wed Dec 22, 2010 12:14 am Post subject: |
|
|
 Master
Joined: 07 Feb 2006 Posts: 293 Location: Bengaluru, India
|
Quote: |
So you don't even need to build a message set by hand. Have WMB build the message set from the file definition, add an "AppendedText" element and you're done. |
Once those elements are added, the actual data becomes the child of Body in the message tree ? _________________ ALL opinions are welcome.
-----------------------------
Debugging tip:When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.
---Sherlock Holmes |
|
Back to top |
|
 |
Vitor |
Posted: Wed Dec 22, 2010 5:09 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
Cogito-Ergo-Sum wrote: |
Quote: |
So you don't even need to build a message set by hand. Have WMB build the message set from the file definition, add an "AppendedText" element and you're done. |
Once those elements are added, the actual data becomes the child of Body in the message tree ? |
Again, you're oversimplifying. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
Vitor |
Posted: Wed Dec 22, 2010 5:18 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
Cogito-Ergo-Sum wrote: |
I think, I am still thinking from the perspective of a simple COBOL program that reads a record, appends some text to it and writes it out. That is why, the message sets seem like 'hard work'. |
Well:
1) Message sets are not hard work, and as I described above in your case can be automated. They also offer future advantages as I described.
2) Even the COBOL program you describe above would need to know the record length & define a PIC X(something) to hold it. So there's still the concept of "message set" in that the COBOL would still have a structure defining the data.
3) This isn't COBOL, it's WMB.
4) If the requirement is so simple that you feel WMB is too heavy a solution, write an application to do it (in COBOL, C, C#, Java, etc, etc). I'd agree that as described (file in, append text, WMQ out) it doesn't sound like much.
Of course you'd have to build file polling, error handling and all the other stuff WMB provides. You'd also need to re-engineer the solution when the requirement expands. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
mqjeff |
Posted: Wed Dec 22, 2010 6:40 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
Look, it's all well and good to advocate building a model, and building a model is a good thing to do.
But it's not really going to help much with understanding how to construct and manipulate a logical message tree or the contents of elements therein, either in ESQL or in Java.
The approach to use the BLOB domain to merely append to an existing message is a perfectly reasonable one. When requirements drift later, there's surely enough time at that point to convert to using a model.
The problem as stated was that "garbage" was generated. We've gotten no firm description of what "garbage" means. |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Dec 22, 2010 3:03 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Cogito-Ergo-Sum wrote: |
Quote: |
However you have no idea whether the bitstream that was read in was in ASCII or in EBCDIC, which specific code page it was in, and whether the text you added to it is in a compatible format or not... (ASCII + EBCDIC)... |
No, I do. It is guaranteed that the encoding will be EBCDIC. |
Get off your MF only mentality. Your second program (i.e.) flow is being fed a file of known length but unknown content, the CCSID of which is in the InputRoot.Properties and endianess as well.
The content could be bytes, text or a mix. Using a message set to model the data would allow you to determine exactly what the content is... and to append the text in the right CCSID...
If you're seeing garbage in the output, my best guess is you're mixing CCSIDs... or text and numbers...
Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
Cogito-Ergo-Sum |
Posted: Wed Dec 22, 2010 7:31 pm Post subject: |
|
|
 Master
Joined: 07 Feb 2006 Posts: 293 Location: Bengaluru, India
|
I understand the benefits of message sets and it's use in this case too. Actually implementing the message set in my flow may not take much time/effort either. But. this discussion is not so much about having FileInput nodes, message sets, COBOL, EBCDIC, etc. It is about the message tree that gets propagated throughout the nodes and the location of 'real data' in that message tree. That 'real data' could be XML or simply a string of bytes whose meaning - based on offsets - I know.
Suppose from the original example, the JavaCompute node is taken out and we have only the FileInput and FileOutput nodes. The Out of FileInput node is connected to a FileOutput node. The 'End of data' terminal is connect to 'Finish' terminal. Then, each record of the said input file - regardless of the message set, parser, trees, COBOL, EBCDIC, etc - sits correctly as a record in the output file. Now, given that, in a message flow the trees are propagated from node to node, it means WMB knows what tree to read/create, locate the 'real data' and correctly put it into the output file.
Why can't I do the same navigation of the message tree in a JavaCompute node ? _________________ ALL opinions are welcome.
-----------------------------
Debugging tip:When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.
---Sherlock Holmes |
|
Back to top |
|
 |
|
|
 |
Goto page 1, 2 Next |
Page 1 of 2 |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|