| Author |
Message
|
| ashrain |
 Posted: Wed Mar 16, 2011 9:13 am Post subject: Reading hex data in CDATA section |
 |
|
Novice
Joined: 16 Mar 2011
Posts: 12
|
Hello,
I'm trying to read hex data from a CDATA section,but its failing in the input queue.The CCSID is 819 and Encoding 273.
><![CDATA[SSANDHYA ]]>.Any help will be much appreciated |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed Mar 16, 2011 9:38 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
What do you mean "trying"?
What does "failing on input queue" mean?
post the specific error message.
Also note that CDATA is explicitly guaranteed to NOT provide protection against illegal XML characters. Best bet to keep arbitrary content within a CDATA section is to base64 encode it first. |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Mar 16, 2011 10:31 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| Best bet to keep arbitrary content within a CDATA section is to base64 encode it first. |
I agree. And if you have base64-encoded it, you don't need the CDATA section any more. |
|
| Back to top |
|
|
| MQSIGuy |
| Posted: Thu Mar 17, 2011 3:49 am Post subject: |
|
|
Novice
Joined: 26 Oct 2009
Posts: 20
|
| kimbert wrote: |
| Quote: |
| Best bet to keep arbitrary content within a CDATA section is to base64 encode it first. |
I agree. And if you have base64-encoded it, you don't need the CDATA section any more. |
Yes but if you base64encode the CDATA section will that then alter the output to the client who requires it exactly as the broker receives it perhaps? |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Mar 17, 2011 4:33 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| if you base64encode the CDATA section will that then alter the output to the client who requires it exactly as the broker receives it perhaps? |
Yes - if you base64-encode the field then the client will probably need to base64-decode it.
However, if mqjeff's guess is correct, (i.e. the problem is caused by an invalid character in the incoming XML) then the CData solution cannot work. In that case it would be silly to argue from the client's point of view - the first goal must be to fix the the message flow so that it always outputs well-formed XML regardless of its inputs. |
|
| Back to top |
|
|
| ashrain |
| Posted: Thu Mar 17, 2011 5:19 am Post subject: |
|
|
Novice
Joined: 16 Mar 2011
Posts: 12
|
| hello..thanks for the reply..my senior will be looking at it to come up with a solution and I will let you guys know if this has been solved.....tnx again |
|
| Back to top |
|
|
| MQSIGuy |
| Posted: Thu Mar 17, 2011 5:20 am Post subject: |
|
|
Novice
Joined: 26 Oct 2009
Posts: 20
|
| kimbert wrote: |
| Quote: |
| if you base64encode the CDATA section will that then alter the output to the client who requires it exactly as the broker receives it perhaps? |
Yes - if you base64-encode the field then the client will probably need to base64-decode it.
However, if mqjeff's guess is correct, (i.e. the problem is caused by an invalid character in the incoming XML) then the CData solution cannot work. In that case it would be silly to argue from the client's point of view - the first goal must be to fix the the message flow so that it always outputs well-formed XML regardless of its inputs. |
Consider the following example.. An application sends you well formed XML with a CDATA section that contains a mix of hex and simple text. They are indeed using the CDATA section incorrectly but you have no control over this. The requirements state you must simply take what is in the CDATA and pass it to a client in the exact format it was received.
So input is:
<XMLHdr>
<XMLHdrData/>
<![CDATA[HEX..simplified test]
<XMLHdr>
The output is the CDATA section only
HEX..simplified test
You can't however modify the contents of the CDATA section at all. The broker can't deal with it because on MQInput you will get 'XML Parsing Errors have ocurred' because CDATA is not being used properly. So could you base64encode the CDATA section using an MRM XML message set to parse the incoming XML message at the MQInput node and the CDATA section as base64encoding, remove the CDATA and decode before putting to another MQ Object the client is consuming from. Would the decoding at any point in the broker have the same effect even if it wasn't in the XML domain but parsed as CHAR or BLOB for example? The client is unable to decode because they are external etc and its not an option.
Also imagine this is not an ideal world and you have to work within the stated boundaries... 
Interesting topic perhaps... |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Mar 17, 2011 6:41 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
These two statements contradict one another:
| Quote: |
| An application sends you well formed XML with a CDATA section that contains a mix of hex and simple text. |
and
| Quote: |
| You can't however modify the contents of the CDATA section at all. The broker can't deal with it because on MQInput you will get 'XML Parsing Errors have ocurred' because CDATA is not being used properly. |
Either the data is well-formed ( and therefore can be parsed by an input node ) or it is not well-formed. |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Mar 17, 2011 6:41 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| So could you base64encode the CDATA section using an MRM XML message set to parse the incoming XML message at the MQInput node and the CDATA section as base64encoding, remove the CDATA and decode before putting to another MQ Object |
or better. use XMLNSC to do the same job. |
|
| Back to top |
|
|
| MQSIGuy |
| Posted: Thu Mar 17, 2011 7:10 am Post subject: |
|
|
Novice
Joined: 26 Oct 2009
Posts: 20
|
| kimbert wrote: |
These two statements contradict one another:
| Quote: |
| An application sends you well formed XML with a CDATA section that contains a mix of hex and simple text. |
and
| Quote: |
| You can't however modify the contents of the CDATA section at all. The broker can't deal with it because on MQInput you will get 'XML Parsing Errors have ocurred' because CDATA is not being used properly. |
Either the data is well-formed ( and therefore can be parsed by an input node ) or it is not well-formed. |
I see your point... It is of course not well formed then.. My thinking pattern was simply the XML structure is well formed, the content of the CDATA is not and in this case we do not want or consider its contents to be XML and we would never try to parse is as such..
How about parsing as BLOB on the MQInput and using the built-in 'encode & decode' java methods but calling from ESQL as EXTERNAL JAVA CALL?
Such as...
MQInput > ComputeNode > MQutput
In the compute node call
ESQL EXTERNAL JAVA "com.ibm.broker.javacompute.Base64.encode";
remove CDATA THEN
decode again into BLOB and put to MQOutput node.
CREATE PROCEDURE base64Decode(IN msgBlob CHARACTER)
RETURNS BLOB
LANGUAGE JAVA
EXTERNAL NAME "com.ibm.broker.javacompute.Base64.decode";
If XMLNSC was an option then yes it could do similar job as MRM XML... |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Mar 17, 2011 7:20 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
We may have strayed off-topic a bit here - so just to summarize:
- we do not know whether the above discussion is relevant to ashrain's problem.
- next step is for ashrain to post the full text of the error message - then we will know. |
|
| Back to top |
|
|
|
|
