| Author |
Message
|
| smdavies99 |
 Posted: Mon Jun 23, 2008 6:02 am Post subject: Problems with Message Generated from DB2 Database |
 |
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
I have two systems. One Linux, One Windows. Both are running Broker. Windows - V6.1.0.1, Linux 6.0.0.7
Both systems have flows deployed that read a record from a DB2 Database and put it into a self describing XML format and send it to an output Queue.
The message is passed to another flow running on the Windows Broker where they receive further processing.
In my test scenario, the content of the messages that are received for final processing are identical yet the windows one ir processed ok but the Linux one fails with an XML error.
The problems seem to be with one of the fields that has data that includes some German Text with umlauts etc.
The underlying databases were created with a codeset of ISO-8859-1and a codepage =819.the messages were output from the intermediate flows using CCSID 819.
Here is the db2 insert command, message, and the trace output showing the failure
| Code: |
insert into WBIAPP.MANF_PARTS_DESCRIPTION values ('1000HT', 'DE', 'Some German Text','In den nächsten Jahren werden große')
|
| Code: |
<Manufacturing>
<Product>
<Part_Number>DU88234</Part_Number>
<Origin>DE</Origin>
<Short_Descr>Some German Text</Short_Descr>
<Detailed_Description>In den nchsten Jahren werden groe</Detailed_Description>
</Product>
</Manufacturing>
|
| Code: |
'' from trace node 'MTEST.Trace'.
The trace node 'MTEST.Trace' has output the specified trace data.
This is an information message provided by the message flow designer. The user response will be determined by the local environment.
2008-06-23 14:26:43.673782 4880 Error BIP2628E: Exception condition detected on input node 'MTEST.MQInput'.
The input node 'MTEST.MQInput' detected an error whilst processing a message. The message flow has been rolled-back and, if the message was being processed in a unit of work, it will remain on the input queue to be processed again. Following messages will indicate the cause of this exception.
Check the error messages which follow to determine why the exception was generated, and take action as described by those messages.
2008-06-23 14:26:43.673835 4880 RecoverableException BIP2230E: Error detected whilst processing a message in node 'MTEST.Trace'.
The message broker detected an error whilst processing a message in node 'MTEST.Trace'. An exception has been thrown to cut short the processing of the message.
See the following messages for details of the error.
2008-06-23 14:26:43.673858 4880 ParserException BIP5009E: XML Parsing Errors have occurred.
Errors have occurred during parsing of XML.
Review further error messages for an indication to the cause of the errors.
2008-06-23 14:26:43.673877 4880 ParserException BIP5004E: An XML parsing error ''Invalid character (Unicode: 0x1A) '' occurred on line 1 column 195 when parsing element ''Detailed_Description''.
Internal error codes : '196', ''''.
This error was reported by the generic XML parser. It is usually the result of a badly-formed XML message.
Check that the input XML message is a well-formed XML message that adheres to the XML specification. Note that the line number and column number quoted give the position where the parser discovered the problem. The actual error might be earlier in the message.
Other possible causes could be:
1. A character not supported by XML in the instance message data.
XML only supports a subset of control characters so ensure that no unsupported characters, such as X'00', appear in the document.
2. The Coded Character Set ID defined in the message header does not reflect the contents of the instance message.
If the XML document has an XML prologue, the WebSphere MQ CodedCharSetId should be consistent with the XML Encoding field.
3. A reserved XML character appears in the instance message data.
Characters that could otherwise be recognised as XML mark-up such as < or & should be replaced with the comparable XML entities such as < or &.
|
_________________
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 |
|
 |
| smdavies99 |
| Posted: Mon Jun 23, 2008 6:06 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Sorry, Pressed Submit instead of preview.
Anyway, I think there is something simple I'm missing here in eiher the way the DB2 DB has been setup or the way I'm sending the output message from Linux to Windows.
All Queue Managers were created with a CCSID of 1208 (UTF- .
Stephen D
_________________
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 |
|
|
| fjb_saper |
| Posted: Mon Jun 23, 2008 7:19 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| smdavies99 wrote: |
Anyway, I think there is something simple I'm missing here in eiher the way the DB2 DB has been setup or the way I'm sending the output message from Linux to Windows.
All Queue Managers were created with a CCSID of 1208 ( UTF-8 ).
Stephen D |
Nice, so all your interqmgr traffic is geared towards UTF-8. But did you take care of the apps sending the message? Do they populate the message in UTF-8? Do the sending applications set the CCSID?
Do the receiving application request the message in CCSDID 1208, or with the platform's debault CCSID? Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Mon Jun 23, 2008 7:43 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
If I set the CCSID in RFHUTIL to 819 or 1208 or 1252 it makes no difference.
From the Broker Trace, the MQMD seems to be identical for both the messages received at the final flow. They should be as the same MQMD was used to send the message in the first place.
The order of things is like this
1- RFHUTILC puts a message to a queue on the LINUX QM
2- A triggered app reads the message from the queue and sends two identical copies of the message to different output queues. One of these is a remote queue for the Windows broker QM. The other is a remote queue for the LINUX broker QM.
3- The same Flow is deployed to both brokers. This does a DB lookup based upon a value in the message. The output message is created and sent to the same final flow on the Windows Broker.
4- The messages that was processed by the flow deployed on Windows passed through the 'final' flow ok.
5- The message that was processed by the flow deployed on Linux fails with the error shown in the original post if the XML contains a character like an umlaut.
At the input queue to the flow where things go wrong both messages have the same CCSID & Encoding.
at the moment, I'm stumped.
_________________
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 |
|
|
| fjb_saper |
| Posted: Mon Jun 23, 2008 7:49 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
RFHUtil does not display UTF-8 even if you ask for the message putting the ccsid to 1208. You have to look at the hex values to see the difference.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Mon Jun 23, 2008 9:32 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
The hex values were indeed incorrect. Just as reported by Broker. I have gotten to the bottom of the problem after much digging.
It turns out that the Linux DB2 Table was loaded from a script that had been FTP'd and then edited with 'vim'. The unlauts etc were 'mangled' by this process. Luckily, this is the data for the initial load only.
I fixed up the table load script and it all now works as desired.
_________________
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 |
|
|
| fjb_saper |
| Posted: Mon Jun 23, 2008 2:43 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Gr8! Thanks for letting us know
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
