Author |
Message
|
matuwe |
Posted: Fri Jul 23, 2010 2:43 am Post subject: PARSE does not validate BLOB |
|
|
 Master
Joined: 05 Dec 2007 Posts: 296
|
I have a strange problem. I am trying to use the the ESQL CREATE
Code: |
Create LASTCHILD OF Environment.TEST DOMAIN ('MRM') PARSE(Environment.Data
OPTIONS BITOR (ValidateContentAndValue,ValidateException,ValidateImmediate)
SET TRIM(Environment.currentTransformation.transformation)
TYPE TRIM(Environment.currentTransformation.messageFormat)
FORMAT TRIM(Environment.currentTransformation.messageType)
ENCODING InputRoot.Properties.Encoding
CCSID InputRoot.Properties.CodedCharSetId
);
|
This work only if Environment.Data is CHARACTER, but doesn't work if I leave it as BLOB value. I know it is supposed to work as I have used it before with InputRoot.BLOB.BLOB. What am I doing wrong, is it my Encoding or something. I get validation errors and it is complaining about HEX value not matching.  |
|
Back to top |
|
 |
smdavies99 |
Posted: Fri Jul 23, 2010 3:49 am Post subject: |
|
|
 Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
Did you copy the data (in Blob format ) into the Environment Tree correctly?
IMHO, if you did the following
Code: |
SET Environment.Data = InputRoot.BLOB.BLOB
|
then it will not work properly. You will lose the association with a parser.
Take a look at CREATE FIELD... DOMAIN('BLOB').... _________________ WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
Back to top |
|
 |
kimbert |
Posted: Fri Jul 23, 2010 4:48 am Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
Quote: |
This work only if Environment.Data is CHARACTER |
How do you get the CHARACTER data? Are you using CAST with an ENCODING parameter? If so, please post the line of ESQL that performs the CAST.
Quote: |
but doesn't work if I leave it as BLOB value |
I think your guess is correct - this is probably an encoding issue. Are you sure that InputRoot.Properties.Encoding contains the correct encoding?
Quote: |
I get validation errors and it is complaining about HEX value not matching |
Two points here:
- you are getting *parsing* errors, not validation errors. Parsing is about decoding the input and creating a logical message tree. Validation checks that the logical message tree matches the XML schema ( mxsd ) structure. Validation can be switched on and off.
- if you quote the full text of the error then it may confirm/reject our theory about the encoding. |
|
Back to top |
|
 |
mqjeff |
Posted: Fri Jul 23, 2010 4:48 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
smdavies99 wrote: |
You will lose the association with a parser. |
I don't think that applies in this case. It's a salient point, but it's got naught to do with trying to use PARSE, afaik.
ASBITSTREAM, sure. But not CREATE... PARSE.
It is certainly worth reviewing how the BLOB was populated, however. There could be any number of reasons why the specified field doesn't contain the actual data.
And there could be a bug with passing in BLOB vs. CHARACTER - it's worth seeing if adding a CAST() to the CREATE FIELD statement changes things. |
|
Back to top |
|
 |
matuwe |
Posted: Fri Jul 23, 2010 5:38 am Post subject: |
|
|
 Master
Joined: 05 Dec 2007 Posts: 296
|
These are the steps I follow,
1. Get data from a file as xml tag
Then convert it to BLOB like so
Code: |
SET OutputRoot.XMLNSC.ESB_INTERNAL.INPUTS.INPUTPAYLOAD = ASBITSTREAM(InputBody.ESB_INTERNAL.fileData OPTIONS FolderBitStream); |
For some reason Rootfolder only works if the data in fileData is XML, else it fails, that is why I am using Folderbitstream and cleaning the extra tag
2. Then I tried two option to pass the data to validate, option two fails.
2.1
Code: |
SET Environment.Data = CAST(CAST(InputBody.ESB_INTERNAL.ESB_DATA.payload AS BLOB)AS CHARACTER CCSID InputRoot.Properties.Encoding ENCODING InputRoot.Properties.Encoding);
|
2.2
Code: |
SET Environment.Data = InputBody.ESB_INTERNAL.ESB_DATA.payload;
|
3. PARSE compute node
I am not suren that I am using Broker 7 on AIX. |
|
Back to top |
|
 |
mqjeff |
Posted: Fri Jul 23, 2010 5:40 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
I'm confused.
You're saving the BLOB into OutputRoot.XMLNSC.ESB_INTERNAL.INPUTS.INPUTPAYLOAD and then trying to read it from InputBody.ESB_INTERNAL.ESB_DATA.payload
? |
|
Back to top |
|
 |
kimbert |
Posted: Fri Jul 23, 2010 5:57 am Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
I'm confused too - probably because I don't understand what your message flow is trying to do. Can you take a step back and describe the purpose of the message flow, please? |
|
Back to top |
|
 |
matuwe |
Posted: Fri Jul 23, 2010 6:14 am Post subject: |
|
|
 Master
Joined: 05 Dec 2007 Posts: 296
|
Hi I receive data as acii CHARACTER and the I try to store it in payload. So to preserve the data I want to wrap it into BLOB and later in the flows do a parse and validate. For some reason if my data is left as ASCII, when the message moves from one flow to another I lost the CR (currage return).
So the reason I went with the option of casting was because the PARSE was failing with the blob I created. |
|
Back to top |
|
 |
mqjeff |
Posted: Fri Jul 23, 2010 6:31 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
You didn't say anything about crossing flow boundaries.
You're solving the wrong problem in the wrong way.
Most XML parsers will *always* convert <CR><LF> into <LF>, as that's the correct thing to do, even inside element values.
If you wish to preserve your field contents, you should base64 encode it to protect it, and then base64 decode it to restore it. |
|
Back to top |
|
 |
matuwe |
Posted: Fri Jul 23, 2010 6:45 am Post subject: |
|
|
 Master
Joined: 05 Dec 2007 Posts: 296
|
Oww Ok I see, but it still will not fix my other problem with the PARSE. I still want to convert the data to Binary before I parse.
Owww another reason I need to cast to blob is because I need to store the data in the database as a blob field.
 |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri Jul 23, 2010 7:07 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
You set the BLOB with an ASBITSTREAM but you do not associate a CCSID with it. Do you know what default CCSID gets assigned in this case?
It you did not explicitely set the OutputRoot.Properties.CodedCharSetId to that same value, how can you be sure when getting the message at the next node that InputRoot.Properties.CodedCharSetId will contain the correct value for the CCSID??
Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
matuwe |
Posted: Fri Jul 23, 2010 10:44 am Post subject: |
|
|
 Master
Joined: 05 Dec 2007 Posts: 296
|
Oww seem like you are correct. The ccsid is different when I rad the data to when I actually do the cast in another flow. Thanks I will try to use a specific ccsid.  |
|
Back to top |
|
 |
kimbert |
Posted: Fri Jul 23, 2010 1:13 pm Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
Quote: |
Hi I receive data as acii CHARACTER and the I try to store it in payload. So to preserve the data I want to wrap it into BLOB and later in the flows do a parse and validate |
You seem to be parsing the input data in the first flow, and then jumping through all sorts of hoops to retrieve its original BLOB value.
Is there any reason why you cannot do this the usual way? The normal solution is to parse the input in the BLOB domain and save InputRoot.BLOB.BLOB somewhere ( and save the CCSID and ENCODING, of course). If the flow needs to parse the BLOB later, retrieve the BLOB + CCSID/ENCODING and call CREATE...PARSE. |
|
Back to top |
|
 |
|