| Author |
Message
|
| jb3 |
 Posted: Wed Apr 18, 2018 1:47 am Post subject: CAST as BLOB loses x'0d0a |
 |
|
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 |
|
 |
| timber |
| Posted: Wed Apr 18, 2018 6:53 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
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 |
|
|
| jb3 |
| Posted: Wed Apr 18, 2018 7:10 am Post subject: |
|
|
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 |
|
|
| timber |
| Posted: Wed Apr 18, 2018 9:32 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
| 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 |
|
|
| nukalas2010 |
| Posted: Mon Dec 24, 2018 5:34 am Post subject: |
|
|
Master
Joined: 04 Oct 2010
Posts: 220
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 |
|
|
| timber |
| Posted: Mon Dec 24, 2018 12:14 pm Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
| 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 |
|
|
| nukalas2010 |
| Posted: Wed Dec 26, 2018 2:54 am Post subject: |
|
|
Master
Joined: 04 Oct 2010
Posts: 220
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 |
|
|
| timber |
| Posted: Sat Dec 29, 2018 8:40 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
| I have already explained why this happens. Do you think I'm wrong? |
|
| Back to top |
|
|
| nukalas2010 |
| Posted: Tue Jan 01, 2019 4:40 am Post subject: |
|
|
Master
Joined: 04 Oct 2010
Posts: 220
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 |
|
|
| timber |
| Posted: Tue Jan 01, 2019 11:15 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
| 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 |
|
|
| nukalas2010 |
| Posted: Tue Jan 01, 2019 10:04 pm Post subject: |
|
|
Master
Joined: 04 Oct 2010
Posts: 220
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 |
|
|
| timber |
| Posted: Wed Jan 02, 2019 1:44 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
| Clarification: The source application should base64-encode the SWIFT message before wrapping it in the XML tags. |
|
| Back to top |
|
|
|
|
