Author |
Message
|
kwelch |
Posted: Thu Oct 10, 2002 9:42 am Post subject: invalid XML coming out of WMQI |
|
|
 Master
Joined: 16 May 2001 Posts: 255
|
Hi
I have a messageflow that creates an XML file that is read by a JAVA app which then updates a database. The java app is bombing on my message with an error saying that I have an invalid character in my XML message. I have traced this back to the MQMD_MsgId field. My message coming in is in EBCDIC and has the following values in hex 'FF' and '36' when this gets converted to ASCII it becomes 'C9' and 'E0' which apparently is not valid XML. Since this is the MsgId field and not something we generate I am not sure how to handle this. Also, I don't know that these are the only two characters. There are probably more. Does anyone have any ideas of how I can create a valid XML file and not change the value of the MsgId field? Thanks for any suggestions you might have.
Karen |
|
Back to top |
|
 |
jdouch |
Posted: Thu Oct 10, 2002 11:58 pm Post subject: |
|
|
Apprentice
Joined: 31 May 2002 Posts: 32 Location: London, UK
|
have you specified the convert option on the advanced tab in the input node ??
last project we went from EBCDIC to ASCII by specifying this with no problems.... if testing you need to specify the format MQSTR _________________ Julian Douch
E-business Solutions Consultant
WMQ/WMQI Specialist |
|
Back to top |
|
 |
kwelch |
Posted: Fri Oct 11, 2002 4:49 am Post subject: |
|
|
 Master
Joined: 16 May 2001 Posts: 255
|
Hi Julian,
Yes all of our messages have fomrat of MQSTR. Originally I was not specifying the convert option in my messageflow because most of are apps do GET with Convert option. I tried that and both ways it does not work. It's giving me characters that are considered invalid in XML. Since it is in the MsgId field I don't know what to do as it is generated and we want to keep it intact.
Any ideas? Anyone? Is there away to mask special characters so XML will like them?
Karen |
|
Back to top |
|
 |
kirani |
Posted: Fri Oct 11, 2002 7:08 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001 Posts: 3779 Location: Torrance, CA, USA
|
Karen,
MsgId is a binary field and it will not get converted by MQGMO_CONVERT option.
How do you generate XML file from message flows? Why would your XML message (Body only) will have Msg-Id in it? Are you assigning MQMD.MsgId to some field in output XML message? _________________ Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
Back to top |
|
 |
kwelch |
Posted: Mon Oct 14, 2002 6:07 am Post subject: |
|
|
 Master
Joined: 16 May 2001 Posts: 255
|
Hi Kiran,
Yes this message comes from a mainframe application where it is writing a logging message to a queue so it has the original MQMD as part of the body of the message. I also discovered that other parts of our message have binary data as well. It is coming from a mainframe system that has IMS so each of the copybooks has LL ZZ in front of it which is binary. We want to store the message as is for replay capabilities. So that is why my message body has binary data in it.
Someone has told me that if I could Base64 the data that Java could probably handle it. I am not exactly sure what this means or how to do this. I was wrapping the xml with CDATA tag but that is not handling this binary data. So..............if you or anyone has any other ideas let me know. Thanks!
Karen |
|
Back to top |
|
 |
mverh |
Posted: Wed Oct 16, 2002 9:57 am Post subject: |
|
|
Voyager
Joined: 06 Mar 2002 Posts: 97
|
Why don't you store the fields in the MQMD as columns in your warehouse table along with the message payload. Treat the payload as a BLOB. This way you can run queries against the database based on things like msgid, correlid, userid etc and tehn you won't have to concern yourself about binary fields like msgid etc.
We store all inbound messages to the broker in a d/b using this strategy based on a flag in a common message header. We don't store outbound messages because we can derive these via replay services.
BTW, we also offload the insert/extract services by routing a copy of the input message to a remote queue that points to a broker that acts as our warehouse service provider. This way our flows that do our real work aren't burdened by any d/b i/o associated with warehousing. |
|
Back to top |
|
 |
kwelch |
Posted: Wed Oct 16, 2002 10:21 am Post subject: |
|
|
 Master
Joined: 16 May 2001 Posts: 255
|
Thanks for the suggestion.
We aren't using a warehouse table. We have an existing Java application that already reads MQ messages and updates an oracle database. These messages just don't happen to have the problems that our mainframe messages do.
Any other suggestions?
Karen |
|
Back to top |
|
 |
|