| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| DFDL parse/encoding problem |
« View previous topic :: View next topic » |
| Author |
Message
|
| fjb_saper |
 Posted: Mon Jul 21, 2014 4:56 am Post subject: |
 |
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
So run your input as UTF-8, change the OutputRoot.Properties.CodedCharSetId to 1200 and have the broker write the output file. Seems easy right?
What did not work in this scenario? 
_________________
MQ & Broker admin |
|
| Back to top |
|
 |
| Senthamizh |
| Posted: Mon Jul 21, 2014 5:11 am Post subject: |
|
|
Apprentice
Joined: 21 Dec 2009
Posts: 47
|
Yes , thats easy and i did the same, but in that case, the DFDL parser throws this error
| Code: |
| Text:CHARACTER:CTDU4023E: The DFDL serializer cannot output the physical representation of element '#xscd(/schemaElement::Message/type::0/model::sequence/schemaElement::Lot_Nr)' at offset '92'. The length '20' in units of 'bytes' exceeds the maximum allowed length of parent element '#xscd(/schemaElement::Message)'. |
But the UTF-16 message that i used to test the model is working fine without any issues. (I have pasted this messgae above)
hence wondering why the broker parse is not accepted by the DFDL model. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jul 21, 2014 5:50 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
The fact that you have the parent element specifying an explicit length does not help. Try with the parent element specifying an implicit length.
You've also been told that the way you set up your DFDL schema you are running into a known bug. Did you open the PMR and get an APAR for it?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| kimbert |
| Posted: Mon Jul 21, 2014 2:22 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
I map some values from this XML to a text file.. The text file need to be UTF-16.
Hence the reason , i made the DFDL encodoing to UTF-16. and gave lengthunits as characters .. |
Good. That makes sense.
| Quote: |
| Hence, here i try to map the UTF-8 to UTF-16 using the CAST functions. |
If you design your DFDL model and your message flow correctly then you do not need to do any CASTing. The message flow handles all of that for you.
| Quote: |
| Initially I tried to just set the OutputRoot.Properties.CCSID as 1200 and make a map, but it fails. Hence, i tried to explicitly make the CAST.. |
Wrong decision - you should have diagnosed the problem instead of looking for a quick fix.
Please tell us what you mean by 'it fails'. We may be able to help.
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too. |
|
| Back to top |
|
|
| Senthamizh |
| Posted: Tue Jul 22, 2014 11:15 pm Post subject: |
|
|
Apprentice
Joined: 21 Dec 2009
Posts: 47
|
Thanks for you replies..
Kimbert, The error i get when i do this
| Quote: |
| Initially I tried to just set the OutputRoot.Properties.CCSID as 1200 and make a map, but it fails. Hence, i tried to explicitly make the CAST.. |
is
| Code: |
| Text:CHARACTER:CTDU4023E: The DFDL serializer cannot output the physical representation of element '#xscd(/schemaElement::Message/type::0/model::sequence/schemaElement::Lot_Nr)' at offset '92'. The length '20' in units of 'bytes' exceeds the maximum allowed length of parent element '#xscd(/schemaElement::Message)'. |
As you said before, i believe this is an bug with the DFDL parser.
But the other advise that you gave is not to define the length explcitly but to use the delimiter for the complex element.
In my case, the output text format is just a single line with 74 characters, thats it ... hence there is no repeating element delimiter... In this case, do you see another way, how i could design my model ?
Having said that.. this message (extract from RFHutil in "Both" format)
| Code: |
.Z.P.G.0 .2.3.2.1 005A0050 00470030 00320033 00320031
.R.F. . . . . . 00520046 00200020 00200020 00200020
.E.T.Q.P .O.L.0.0 00450054 00510050 004F004C 00300030
.1.0.2.3 .2.1.0.0 00310030 00320033 00320031 00300030
.6.9.0.0 .L.O.T.P 00360039 00300030 004C004F 00540050
.O.L.0.0 .0.1.9.5 004F004C 00300030 00300031 00390035
.0. . . .B.B.C.N 00300020 00200020 00420042 0043004E
.T.P.O.L .0.0.0.0 00540050 004F004C 00300030 00300030
. . .0.7 .1.2.2.0 00200020 00300037 00310032 00320030
.0.8 00300038 |
is getting parsed by the model i designed, without any issues. And this message contains 2bytes per char.
So what i inferr from this, is that i miss something in my casting in the broker/esql !! May be i am wrong.. |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Jul 23, 2014 1:38 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Remove the length from the complex element. Set its lengthKind to 'implicit' ( not 'delimited' ).
Then, if necessary, add padding to the final field. Check the 'Pad Kind' and 'Trim Kind' properties. And the 'Text Justification' property.
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too. |
|
| Back to top |
|
|
| Senthamizh |
| Posted: Thu Jul 24, 2014 12:13 am Post subject: |
|
|
Apprentice
Joined: 21 Dec 2009
Posts: 47
|
Thanks for your advice. It worked. I just made the Complex element type to implicit and added the padKind trimKind and it worked. |
|
| 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
|
|
|
|
