| Author |
Message
|
| MQSIGuy |
 Posted: Thu Sep 30, 2010 4:08 am Post subject: unexplainable PARSE action (reset content decsriptor) |
 |
|
Novice
Joined: 26 Oct 2009
Posts: 20
|
Hello,
I am trying to do the following:
1) Take in a message in the xml domain with an MQRFH2 header (xml value in the mcd folder)
- I have set the MQInput node domain to XMLNSC with 'Use XMLNSC compact parse for XMLNS domain' and 'Retain mixed content' both checked. I have used these options for all other nodes where appropriate (compute)
2) As the MQRFH2 header mcd is xml this overrides the MQInput node and the input domain is xml. This makes my XMLNSC coded ESQL not work...
3) I want to code the ESQL in XMLNSC however to take as much advantage of the performance gains however before coding for the XMLNSC domain I need to change the domin to XMLNSC from XML.
4) I can do this easily enough by putting an RCD node after the input and resetting the domain to XMLNSC (including the mcd in RFH2 header) however this flow will have an extremely high throughput and I am concerned about the performance of the RCD node so...
5) I put a compute node after the MQInput and...
- copied message headers
- parsed inputbody into a BLOB then parsed to the output root as XMLNSC domain
I was hoping this would mean when the output message left the fist compute node it would be in the XMLNSC domain and I could then use the next compute node to code the ESQL string manipulation in XMLNSC
However, this does not work as I always get XML parsing errors.. I have tried various flavours such as deleting the MQRFH2 header, overriding the mcd value to XMLNSC etc but to no alas!
Can anyone offer any indication why this is happening? When the following code is hit
DECLARE msgBlb BLOB CAST((inRef.XML) AS BLOB CCSID inRef.MQMD.CodedCharSetId ENCODING inRef.MQMD.Encoding);
CREATE LASTCHILD OF outRef DOMAIN ('XMLNSC') PARSE (msgBlb);
The variable msgBlob has 2 characters and clearly hasn't parsed the inputbody so on the CREATE statement I get xml errors have occurred.
Any ideas or is it simply better to bite the bullet and use the RCD?
Thanks in advance! |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Sep 30, 2010 4:28 am Post subject: Re: unexplainable PARSE action (reset content decsriptor) |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MQSIGuy wrote: |
| I have tried various flavours such as deleting the MQRFH2 header, overriding the mcd value to XMLNSC etc but to no alas! |
I'm surprised that simply reseting the value didn't work. I'm equally surprised that deleting & recreating the MQRFH2 didn't change the value.
| MQSIGuy wrote: |
| Any ideas or is it simply better to bite the bullet and use the RCD? |
I'll wait to hear what kimbert has to say on the matter. I am interested to hear about problems with the RCD; is this documented somewhere you have a link to? Or based on your experience? I'd certainly agree you shouldn't stud your flows with RCD like raisins in a cake, but I'm unaware of performance issues with the node & am interested to know more.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Sep 30, 2010 4:43 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Your overall plan seems sound enough, but your implementation may be flawed. Your code snippet does not reveal what inRef.XML is pointing to. If it is pointing to InputRoot.XML then this code
| Code: |
DECLARE msgBlb BLOB CAST((inRef.XML) AS BLOB CCSID inRef.MQMD.CodedCharSetId ENCODING inRef.MQMD.Encoding);
CREATE LASTCHILD OF outRef DOMAIN ('XMLNSC') PARSE (msgBlb);
|
...is incorrect. You can't CAST a message tree to a BLOB. You have to use ASBITSTREAM to recover the original BLOB.
Please quote error messages or user trace in future posts - otherwise we're forced to do a lot of guessing and that uses up an annoying amount of imagination.
FWIW, I don't know of any performance issues with the RCD node. It's just as smart as other nodes that use parsers. If no parsing/serialization is needed, it won't do any. In this case, calling ASBITSTREAM on InputRoot.XML should simply return the BLOB without invoking any complex processing ( because the input message tree has not changed).
As always, user trace will reveal a great deal about what your flow is really doing. |
|
| Back to top |
|
|
| MQSIGuy |
| Posted: Thu Sep 30, 2010 4:44 am Post subject: Re: unexplainable PARSE action (reset content decsriptor) |
|
|
Novice
Joined: 26 Oct 2009
Posts: 20
|
| Vitor wrote: |
| MQSIGuy wrote: |
| I have tried various flavours such as deleting the MQRFH2 header, overriding the mcd value to XMLNSC etc but to no alas! |
I'm surprised that simply reseting the value didn't work. I'm equally surprised that deleting & recreating the MQRFH2 didn't change the value.
resetting the value does change it in the mcd folder in the RFH2 header in the broker flow but when it comes out that intial compute node it has changed back to xml and the domain is still XML.
| MQSIGuy wrote: |
| Any ideas or is it simply better to bite the bullet and use the RCD? |
I'll wait to hear what kimbert has to say on the matter. I am interested to hear about problems with the RCD; is this documented somewhere you have a link to? Or based on your experience? I'd certainly agree you shouldn't stud your flows with RCD like raisins in a cake, but I'm unaware of performance issues with the node & am interested to know more. |
but I wonder if I changed the output mcd to xmlnsc AND the output domain to XMLNSC by using the code above if this would work but when I attempt to BLOB the inutbody then parse it on the output root as XMLNSC I am getting an xml errors have occurred error. The input body is well formatted xml with a CDATA but should this stop the BLOB > XMLNSC PARSE statement above? I guess I should set up a quick flow to test that. Normally I owuld only be interested in the content of the CDATA which I know works fine, this is the first time i've tried the entire inputBody.
any ideas? |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Sep 30, 2010 4:46 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
re:
| Quote: |
| - I have set the MQInput node domain to XMLNSC with 'Use XMLNSC compact parse for XMLNS domain' and 'Retain mixed content' both checked. I have used these options for all other nodes where appropriate (compute) |
You probably don't need either of these options. The first one is no longer supported, and in any case it relates to the XMLNS domain, not XML.
The second one is only required if your message flow wants to process the mixed content in the input message. That's a fairly rare requirement. |
|
| Back to top |
|
|
| MQSIGuy |
| Posted: Thu Sep 30, 2010 4:46 am Post subject: |
|
|
Novice
Joined: 26 Oct 2009
Posts: 20
|
| kimbert wrote: |
Your overall plan seems sound enough, but your implementation may be flawed. Your code snippet does not reveal what inRef.XML is pointing to. If it is pointing to InputRoot.XML then this code
| Code: |
DECLARE msgBlb BLOB CAST((inRef.XML) AS BLOB CCSID inRef.MQMD.CodedCharSetId ENCODING inRef.MQMD.Encoding);
CREATE LASTCHILD OF outRef DOMAIN ('XMLNSC') PARSE (msgBlb);
|
...is incorrect. You can't CAST a message tree to a BLOB. You have to use ASBITSTREAM to recover the original BLOB.
Please quote error messages or user trace in future posts - otherwise we're forced to do a lot of guessing and that uses up an annoying amount of imagination.
FWIW, I don't know of any performance issues with the RCD node. It's just as smart as other nodes that use parsers. If no parsing/serialization is needed, it won't do any. In this case, calling ASBITSTREAM on InputRoot.XML should simply return the BLOB without invoking any complex processing ( because the input message tree has not changed).
As always, user trace will reveal a great deal about what your flow is really doing. |
Hi Kimbert,
you are indeed correct and I seem to have left part of my brain at home today... I will try your suggestion then update there might be no need for user trace!
Thanks, |
|
| Back to top |
|
|
| MQSIGuy |
| Posted: Thu Sep 30, 2010 4:51 am Post subject: |
|
|
Novice
Joined: 26 Oct 2009
Posts: 20
|
| kimbert wrote: |
re:
| Quote: |
| - I have set the MQInput node domain to XMLNSC with 'Use XMLNSC compact parse for XMLNS domain' and 'Retain mixed content' both checked. I have used these options for all other nodes where appropriate (compute) |
You probably don't need either of these options. The first one is no longer supported, and in any case it relates to the XMLNS domain, not XML.
The second one is only required if your message flow wants to process the mixed content in the input message. That's a fairly rare requirement. |
ah I thought that as XMLNS was an extension of XML this might still be relevant somehow given that XML is depracated. I guess not!
The second option was selected as the input message has a CDATA section which seemed to be ignored if left unchecked. I confess this is my first foray with XMLNSC (which I am almost ashamed to admit as this stage..) |
|
| Back to top |
|
|
| MQSIGuy |
| Posted: Thu Sep 30, 2010 5:32 am Post subject: |
|
|
Novice
Joined: 26 Oct 2009
Posts: 20
|
it seems the 'retain mixed content' option has to be checked when dealing with CDATA otherwise it is ignored. I noticed something interesting though.
When using the RCD node and 'retain mixed content' checked the CDATA section is passed out the other side.
When using a compute node to reset the message domain and with 'retain mixed content' selected the CDATA section is lost. It may have to do with the option on the PARSE or ASBITSTREAM function but seeing as there are no concerns with the performance of the RCD node I shall investigate no further and use the simple method that I know works.
I'm not sure where I heard that RCD is not permformant but I have certainly heard it more than a few times. Maybe its simply folklore that someone has started ...
Thank you all for the input. |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Thu Sep 30, 2010 5:46 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Sep 30, 2010 5:46 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| The second option was selected as the input message has a CDATA section which seemed to be ignored if left unchecked. |
I'm certain that the 'Retain mixed content' switch should not, in general, suppress CDATA sections. If your input message contains CDATA sections that are mixed content then they will be suppressed - but not because they're CDATA.
If you can demonstrate that an ordinary CDATA section occurring as the value of a tag or attribute gets omitted from the message tree only when you set that switch then I promise that you will have my full attention  |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Sep 30, 2010 6:01 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| WMBDEV1 wrote: |
| Dont worry, its not as bad as the folklore that has Vitor spooked about Java |
Java? Java? Where? 
It's behind me, isn't it? Isn't it? 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
