| Author |
Message
|
| wraymore |
 Posted: Tue Nov 25, 2008 3:23 pm Post subject: Question about Extended ASCII |
 |
|
Centurion
Joined: 16 Aug 2005
Posts: 114
Location: Burlington, NC USA
|
WMQ 6.0.2.4
WMB 6.0.0.8
The message is coming from a .net system as Code Page 1200. MQGMO-Convert is set to convert to CCSID 819.
The XML message contains a base 64 encoded string (PDF) and an embedded HL7 within a CDATA tag as elements. I am using the XMLNSC Domain. We got this one message that has a hex 92 (Extended ASCII 146) within the HL7 (had the source system send me the HL7 outside of MQ).
The message flow is failing with the following message:
FAILURE: An error has been reported by the BIPXML4C component.
Currently when I look at the message after the failure, the hex 92 has been converted to hex 1A (substitute).
Is it possible to get the conversion to work correctly for Extended ASCII values?
 |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Nov 25, 2008 4:00 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Why do you convert to CCSID 819? The broker works internally in Unicode...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| wraymore |
| Posted: Wed Nov 26, 2008 7:04 am Post subject: |
|
|
Centurion
Joined: 16 Aug 2005
Posts: 114
Location: Burlington, NC USA
|
Ok, so I do not have to set the CCSID to 819, learned something new this morning.  However I am still seeing all extended ascii characters converted to Unicode 0x1A, which causes the BIPXML4C component to fail.  |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Nov 26, 2008 8:07 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| I am still seeing all extended ascii characters converted to Unicode 0x1A |
I strongly suspect that you are setting the code page incorrectly somewhere. Is the code page in the MQMD header correct ( set to 1200 )? OR did you attempt to set the CCSID on the input node, and you have forgotten to remove that setting?
| Quote: |
| The XML message contains a base 64 encoded string (PDF) and an embedded HL7 within a CDATA tag as elements |
Sounds dangerous. The HL7 message will contain linefeed characters. XML parsers are required to 'normalize' ( i.e. mess about with) linefeed characters. I would feel safer if the HL7 was base64 encoded as well. |
|
| Back to top |
|
|
| wraymore |
| Posted: Wed Nov 26, 2008 10:42 am Post subject: |
|
|
Centurion
Joined: 16 Aug 2005
Posts: 114
Location: Burlington, NC USA
|
Trying to get some more data from the source system. But with the holiday not having much luck. Will post again after getting the data (Code page 1200, the data I had saved off with MQ Visual Edit was code page 819,  ).
Should I have the Convert button checked?  |
|
| Back to top |
|
|
| wraymore |
| Posted: Fri Nov 28, 2008 11:51 am Post subject: |
|
|
Centurion
Joined: 16 Aug 2005
Posts: 114
Location: Burlington, NC USA
|
Finally got another data feed from the lab. I changed the conversion parameters on the MQInput Node advanced tab to be:
Convert box checked
I left the Convert encoding and Convert coded character set ID at the defaults, removed 273 and 819.
With these settings, I do not get a failure from the BIPXML4C component.
However we do still have an issue with the original data. But that is outside the broker.
As for base64 encoding the HL7, I have a question.
Depending upon whether the data is going to Fax Server, EDI or a proprietary tool provided to our clients, transformations of the HL7 occur. In the message flow, the HL7 is pulled out of the XML into the Environment.
CREATE LASTCHILD OF Environment DOMAIN 'XMLNSC' NAME 'HL7Data';
SET Environment.HL7Data.HL7 = InTriadPayld.triadNS:Payload[N];
The transformations are performed, sometimes the base64 encoded pdf is embedded within the HL7, then the HL7 is returned to the XML and the message is put to a queue.
Discounting the politics involved with getting a change to XML, what steps would be required to decode the HL7 section, and then encode before returning to the XML? Also is it possible to have a base64 encoded string within a base64 encoded string? |
|
| Back to top |
|
|
| kimbert |
| Posted: Sat Nov 29, 2008 2:44 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| what steps would be required to decode the HL7 section, and then encode before returning to the XML? |
XMLNSC will do that for you in v6.1. See http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r1m0/topic/com.ibm.etools.mft.doc/ac67201_.htm
| Quote: |
| Also is it possible to have a base64 encoded string within a base64 encoded string? |
Yes. A base64 string is simply a character representation of a byte array. Obviously, the receiver would need to double-decode the double-encoded portion. |
|
| Back to top |
|
|
| wraymore |
| Posted: Mon Dec 01, 2008 1:33 pm Post subject: |
|
|
Centurion
Joined: 16 Aug 2005
Posts: 114
Location: Burlington, NC USA
|
Kimbert; thanks for the information. We are looking at upgrading to 6.1.# 2nd quarter 2009.  |
|
| Back to top |
|
|
| kimbert |
| Posted: Mon Dec 01, 2008 4:45 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| In v6.0 you can still do what you need using by calling a Java method. If you don't know how, just use the search button on this forum. |
|
| Back to top |
|
|
|
|
