| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| MQInput Node xml validation |
« View previous topic :: View next topic » |
| Author |
Message
|
| rekarm01 |
 Posted: Sun Feb 01, 2009 5:02 pm Post subject: |
 |
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
First, it looks like the sending application is sending XML messages to a message flow with unwanted characters. Is this something the sender should fix? If not, is this something that the message flow needs to handle? If so, how? Should it pass the unwanted characters to WAS via HTTPRequest, and if so, how should WAS handle them?
Second, it looks like the CCSIDs (coded character set ids) are wrong in at least one or more places, along the way. If an incorrect CCSID shares a common ASCII subset with the correct one, this can often go unnoticed for a while, until a non-ASCII character comes along. One common symptom is this:
| dbennett9283 wrote: |
| It does indeed appear that the character has changed from ñ to ±. Very interesting...why did this occur? |
Worse symptoms include conversion exceptions for non-existent or illegal characters, like this:
| dbennett9283 wrote: |
| Any idea as to why Message Broker has no issue with these characters but WAS 6.1 does? |
... (which might also be mitigated by applying WAS 6.1 Fix Pack 15 or later, to fix defects like APAR PK56607).
One basic rule is that any application that reads a string ought to use the same CCSID that the application that wrote the string used. Every application that touches a string needs to have some idea which CCSID is currently associated with it, (which also includes the applications that read/write usertrace and logs, and even the keyboard and terminal emulator itself). This could be an explicit part of the message, within a header or XML declaration, for example; or it could be implied by some external requirement or arrangement, using environment variables, menu options, or some other means to coordinate related applications.
Displaying a usertrace with non-ASCII characters, using a misconfigured application, can be misleading; it's sometimes helpful to add a statement that CASTs a string to BLOB, and learn how to read hex:
| Code: |
2009-02-01 14:01:58.608119 5926 UserTrace BIP2539I:
Evaluating expression ''CAST(InputBody.XML.addressLine2 AS BLOB CCSID InputRoot.Properties.CodedCharSetId)''.
This resolved to ''CAST('*CASH ONLYññññññññññ' AS BLOB CCSID 437 )''.
The result was ''X'2a43415348204f4e4c59a4a4a4a4a4a4a4a4a4a4'''. |
From dbennett9283's trace output:
- LocalEnvironment.MQMD.CodedCharSetID=437: I'm assuming this was copied from the MQMD provided by the sender, prior to MQInput. I'm guessing that the correct value should have been ccsid=819 (ISO/IEC 8859-1), but I can't say for certain without more information. If that's the case, then the suspect string originally looked like '*CASH ONLY¤¤¤¤¤¤¤¤¤¤', but the '¤' (<U00A4> CURRENCY SIGN) was read as 'ñ' (<U00F1> LATIN SMALL LETTER N WITH TILDE), upon reaching the MQInput node.
- Root.Properties.CodedCharSetID=NULL: The correct value should be ccsid=1208 (UTF-8), to match the XML declaration encoding="UTF-8". The HTTPRequest node can then generate a default header using this property.
|
|
| Back to top |
|
 |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
