| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Broker V5 -> V6 migration issue |
« View previous topic :: View next topic » |
| Author |
Message
|
| smeunier |
 Posted: Wed Jul 08, 2009 1:32 pm Post subject: Broker V5 -> V6 migration issue |
 |
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
While migrating from V5 to V6, a few anomalies have occurred, which have required minor message flow or message set changes. The last one we are struggling with is a dropped <LF> from the output message in V6, which is ok in V5. The legacy application on the back end has dependencies on the <LF>. Te out put data between V5 and V6 is identical, the only difference is the absence of the <LF> on the the last node in the XML output record.
I'm wondering how I can force this (<LF>) either through the message set or the ESQL. I have tried numerous tests but all have failed. Ay tips would be helpful.
The inbound message arrives via the mySAP.com adapter in XML format. The message is then parsed and a new message structure is created from elements of the original message. The final output message as shown below is missing the <LF> x'0A' at the end of the data withing the CDATA tag. I inserted the text "missing" for illustaration purpose, whereas the "." in bold represents the previous good tag.
| Code: |
[CDATA[ 5B434441 54415B20 20202020 20202020
00001472 20202020 20202020 20202020 20202020
00001488 20 080521 20202020 20203230 30383035 32312020
00001504 43 20202020 20202020 20202020 20203433
00001520 78924737 62743243 37383932 34373337 36323734 33323433
00001536 20202020 20202020 20202020 20202020
00001552 20202020 20202020 20202020 20202020
00001568 00306678 06[b].[/b] 30303330 36363738 30360A20 20202020
00001584 20202020 20202020 20202020 20202020
00001600 200805 20202020 20202020 20203230 30383035
00001616 21 32312020 20202020 20202020 20202020
00001632 743864 27648732 20203734 33383634 32373634 38373332
00001648 20202020 20202020 20202020 20202020
00001664 20202020 20202020 20202020 20202020
00001680 0030 667807[b]missing[/b]] 20202020 30303330 36363738 30375D5D |
What I'm failing to understand, due to experience, is what is forcing the first <LF> and how can I affect the insertion of a <LF> into the last(other) data groups.
Any help would be appreciated. |
|
| Back to top |
|
 |
| kimbert |
| Posted: Thu Jul 09, 2009 12:41 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Check the TDS properties for the outermost complex type. If it does not already have its Group Terminator set to '<LF>' then make it so. |
|
| Back to top |
|
|
| smeunier |
| Posted: Mon Jul 13, 2009 12:14 pm Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
The suggestion of adding a Group Terminator <LF> worked in terms of forcing a <LF> for each group of data. However it added extra <LF> to records which already had one on the end. You can see this in the CDATA section snippet below. (depicted by "." characters). In the message
set I have the Data Element Separation=Fixed Length and the Group Indicator=(nothing specified) and Group Separator = <LF>
| Code: |
00001456 [CDATA[ 5B434441 54415B20 20202020 20202020
00001472 20202020 20202020 20202020 20202020
00001488 20 080521 20202020 20203230 30383035 32312020
00001504 43 20202020 20202020 20202020 20203433
00001520 78924737 62743243 37383932 34373337 36323734 33323433
00001536 20202020 20202020 20202020 20202020
00001552 20202020 20202020 20202020 20202020
00001568 00306678 06.. 30303330 36363738 30360A0A 20202020
00001584 20202020 20202020 20202020 20202020
00001600 20080 20202020 20202020 20202032 30303830
00001616 521 35323120 20202020 20202020 20202020
00001632 74386 42764873 20202037 34333836 34323736 34383733
00001648 2 32202020 20202020 20202020 20202020
00001664 20202020 20202020 20202020 20202020
00001680 003 0667807. 20202020 20303033 30363637 3830370A
|
|
|
| Back to top |
|
|
| kimbert |
| Posted: Mon Jul 13, 2009 12:50 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Bad news, I'm afraid. If the simple fix didn't work the only solution is to read the model and understand how it works. I can't make any more suggestions without very detailed knowledge of the message set. Before posting loads of detail, please take a close look and see if you can see how it all works. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
