ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexWebSphere Message Broker SupportCAST as BLOB loses x'0d0a

Post new topicReply to topic
CAST as BLOB loses x'0d0a View previous topic :: View next topic
Author Message
jb3
PostPosted: Wed Apr 18, 2018 1:47 am Post subject: CAST as BLOB loses x'0d0a Reply with quote

Apprentice

Joined: 18 Aug 2017
Posts: 26

I have two systems integrated through IIB 9.

System A to System B

System A sends a SWIFT message in an XML wrapper [CCSID 850 Encoding 546] --> IIB strips the XML wrapper and CASTs the SWIFT message as BLOB --> System B

Since IIB has to strip the XML wrapper and pass just the SWIFT message to System B, IIB does not have any SWIFT libraries/messagesets. That is why BLOB.

When System A sends the SWIFT message, there is <CR><LF>/x'0d0a after the tags, however when I cast as BLOB there is only <LF>/x'0a.
This is causing issue at System B. I want to retain the <CR><LF>/x'0d0a in BLOB.

I have tried cast as BLOB [CCSID 850 Encoding 546], and also as [CCSID 819 Encoding 546], both of them result in <LF>/x'0a.
As a backup, i am now replacing <LF>/x'0a with <CR><LF>/x'0d0a in BLOB.


System B to System A

System B sends plain SWIFT message [CCSID 819 Encoding 546] --> IIB reads it as BLOB, and then casts it as CHAR (819,546), puts a XML wrapper and sends --> System A.

In this interface <CR><LF>/x'0d0a is retained all through from System B to System A, which is exactly how the above interface should be too.


Please guide if i am doing something wrong, or is this a limitation of CAST as BLOB.

Thanks
Back to top
View user's profile Send private message
timber
PostPosted: Wed Apr 18, 2018 6:53 am Post subject: Reply with quote

Guardian

Joined: 25 Aug 2015
Posts: 942

This one is easy to explain, but only if you happen to know the answer...

System A to System B
The XML specification requires that every XML parser follows this rule
Quote:
To simplify the tasks of applications, the XML processor MUST behave as if it normalized all line breaks in external parsed entities (including the document entity) on input, before parsing, by translating both the two-character sequence #xD #xA and any #xD that is not followed by #xA to a single #xA character.

So this is nothing to do with the CAST function in IIB. The parsing of the input XML has (correctly) changed the end-of-line character to a single #xA.

System B to System A
In this scenario, IIB is not parsing the XML (just writing it out) so the conversion of line endings does not happen.
Back to top
View user's profile Send private message
jb3
PostPosted: Wed Apr 18, 2018 7:10 am Post subject: Reply with quote

Apprentice

Joined: 18 Aug 2017
Posts: 26

Hi Shaman,

Thanks for your response.

While investigating on this before, i did a test as below:

System A sends a SWIFT message in an XML wrapper [CCSID 850 Encoding 546] --> IIB parses as XMLNSC and then puts the same message on local queue without any transformation.

Then i checked the hex representation of data on the local queue.

It had retained the <CR><LF>/x'0d0a.

That is when i started focusing on CAST as BLOB.

Regards
Back to top
View user's profile Send private message
timber
PostPosted: Wed Apr 18, 2018 9:32 am Post subject: Reply with quote

Guardian

Joined: 25 Aug 2015
Posts: 942

Quote:
System A sends a SWIFT message in an XML wrapper [CCSID 850 Encoding 546] --> IIB parses as XMLNSC and then puts the same message on local queue without any transformation.

Then i checked the hex representation of data on the local queue.

It had retained the <CR><LF>/x'0d0a.
That's because no XML parsing had happened. IIB is (by design) lazy about parsing. It only parses when it needs to. If you didn't access any part of the message, then IIB did not bother to parse any of it.
You can override this 'lazy parsing' feature by setting Parse Timing to 'Immediate' on the Parser Options properties of the input node.
Back to top
View user's profile Send private message
nukalas2010
PostPosted: Mon Dec 24, 2018 5:34 am Post subject: Reply with quote

Master

Joined: 04 Oct 2010
Posts: 217
Location: Somewhere in the World....

Hi JB,
I am also facing similar issue, so just want to check whether you got any luck by trying any other method or how you achieved it.

Thanks,
Back to top
View user's profile Send private message
timber
PostPosted: Mon Dec 24, 2018 12:14 pm Post subject: Reply with quote

Guardian

Joined: 25 Aug 2015
Posts: 942

Quote:
I am also facing similar issue
Please describe your issue in detail. Your problem could be 'similar' in many different ways.
Back to top
View user's profile Send private message
nukalas2010
PostPosted: Wed Dec 26, 2018 2:54 am Post subject: Reply with quote

Master

Joined: 04 Oct 2010
Posts: 217
Location: Somewhere in the World....

timber wrote:
Please describe your issue in detail. Your problem could be 'similar' in many different ways.


As "Similar" as Original post

Quote:
System A to System B

System A sends a SWIFT message in an XML wrapper [CCSID 850 Encoding 546] --> IIB strips the XML wrapper and CASTs the SWIFT message as BLOB --> System B

Since IIB has to strip the XML wrapper and pass just the SWIFT message to System B, IIB does not have any SWIFT libraries/messagesets. That is why BLOB.

When System A sends the SWIFT message, there is <CR><LF>/x'0d0a after the tags, however when I cast as BLOB there is only <LF>/x'0a.
This is causing issue at System B. I want to retain the <CR><LF>/x'0d0a in BLOB.

I have tried cast as BLOB [CCSID 850 Encoding 546], and also as [CCSID 819 Encoding 546], both of them result in <LF>/x'0a.
As a backup, i am now replacing <LF>/x'0a with <CR><LF>/x'0d0a in BLOB.
Back to top
View user's profile Send private message
timber
PostPosted: Sat Dec 29, 2018 8:40 am Post subject: Reply with quote

Guardian

Joined: 25 Aug 2015
Posts: 942

I have already explained why this happens. Do you think I'm wrong?
Back to top
View user's profile Send private message
nukalas2010
PostPosted: Tue Jan 01, 2019 4:40 am Post subject: Reply with quote

Master

Joined: 04 Oct 2010
Posts: 217
Location: Somewhere in the World....

timber wrote:
I have already explained why this happens. Do you think I'm wrong?


I cant say its wrong.. but setting the parser to 'Immediate' didn't help.

timber wrote:
So this is nothing to do with the CAST function in IIB. The parsing of the input XML has (correctly) changed the end-of-line character to a single #xA.


This causes the problem.. so want to know any other alternative parser or encoding mechanism for don't to lose <CRLF>

Currently I am achieving this by replacing LF with CRLF which is not recommended.

Thanks,
Back to top
View user's profile Send private message
timber
PostPosted: Tue Jan 01, 2019 11:15 am Post subject: Reply with quote

Guardian

Joined: 25 Aug 2015
Posts: 942

Quote:
setting the parser to 'Immediate' didn't help.
I never claimed that it would solve the original problem. If you carefully read this thread, you will see that jb3 was doing an experiment to see if my diagnosis was correct. But jb3's experiment was not correctly designed!

Quote:
This causes the problem.. so want to know any other alternative parser or encoding mechanism for don't to lose <CRLF>
There is only one recommended XML parser in IIB (XMLNSC). It always follows the XML specification, so it will always normalise linefeed characters.

The easiest solution is to change the source application, and send the XML as a base64-encoded string. But you're probably going to tell me that the source application cannot be changed.
Back to top
View user's profile Send private message
nukalas2010
PostPosted: Tue Jan 01, 2019 10:04 pm Post subject: Reply with quote

Master

Joined: 04 Oct 2010
Posts: 217
Location: Somewhere in the World....

Thanks for the clarification dear...

We will try to check with source application for the possibility to change the xml encoding to base64.
Back to top
View user's profile Send private message
timber
PostPosted: Wed Jan 02, 2019 1:44 am Post subject: Reply with quote

Guardian

Joined: 25 Aug 2015
Posts: 942

Clarification: The source application should base64-encode the SWIFT message before wrapping it in the XML tags.
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexWebSphere Message Broker SupportCAST as BLOB loses x'0d0a
Jump to:



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
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.