| Author |
Message
|
| matuwe |
 Posted: Thu May 13, 2021 11:42 am Post subject: Iso 8583 DFDL |
 |
|
Master
Joined: 05 Dec 2007
Posts: 296
|
Hi please help. I am using the dfdl from samples. Everytime I try to write message to a tcp server output, the receiving system says I am sending characters and not valid iso message. I tried to cast to blob but problem doesn't seem to go away.
My flow is mq I get xml, do mapping using dfdl then write iso message to target.
Please help |
|
| Back to top |
|
 |
| gbaddeley |
| Posted: Thu May 13, 2021 3:01 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
Can the receiving system provide a hex dump of the TCP message, and indicate which characters are causing issues?
Is it supposed to be ISO8583 financial transaction format?
_________________
Glenn |
|
| Back to top |
|
|
| matuwe |
| Posted: Thu May 13, 2021 10:34 pm Post subject: |
|
|
Master
Joined: 05 Dec 2007
Posts: 296
|
| Hiw can I upload an image here. I need to show the difference between what I sent and what they expect.[/img] |
|
| Back to top |
|
|
| timber |
| Posted: Sat May 15, 2021 1:19 pm Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
| Why do you need to supply an image? Why can't you supply the details of the expected/actual message in BLOB format? |
|
| Back to top |
|
|
| matuwe |
| Posted: Sat May 15, 2021 8:39 pm Post subject: |
|
|
Master
Joined: 05 Dec 2007
Posts: 296
|
I was fighting with this all day yesterday. Tried different ccsid and encodings. But not winning. Let me see if I can explain it properly.
So if I do cast as blob for value 29 which is the data length then I get 1d
Which is good that's what the other system wants,
2, the next field version is 1. If I do a cast as blob on the field I get 01, which is almost good as the other system wants to see 1.
What's confusing is when I take the whole dfdl and do asbitstream 1 becomes 31, 8 becomes 38. I get different values from what I got casting one field at the time.
Okay then, the next problem is the other system says every character must be represented as a nibble not as a byte. Then I got lost here 😀.
This is what they expects to get
001d1840
This is what I get cast each field
001d01080400
This is what I get cast whole dfdl
001d31383430
I just need a way to cast the whole dfdl to match what he wants. As there are a whole lot of fields after these 5 I have displayed. |
|
| Back to top |
|
|
| timber |
| Posted: Mon May 17, 2021 10:56 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
Thanks, we're going in the right direction now. I do need to be honest with you though...ISO8583 is a complex format. I cannot promise an easy fix. This conversation could take a long time, and could require a lot of work from you.
Before we go any further, all of the following will be required:
1. Trace node output from just before the TCPIPOutput node. No screenshots please. Insert a Trace node with pattern set to ${Root} and paste the output here (obviously, remove anything confidential)
2. Required output in BLOB format
or
A specification of the output format
3. Actual output in BLOB format
You may think this is overkill, but it is not. There are many variations of ISO8583, and without a clear requirement it is impossible to know what the DFDL schema needs to do. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon May 17, 2021 3:18 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| matuwe wrote: |
I was fighting with this all day yesterday. Tried different ccsid and encodings. But not winning. Let me see if I can explain it properly.
So if I do cast as blob for value 29 which is the data length then I get 1d
Which is good that's what the other system wants,
2, the next field version is 1. If I do a cast as blob on the field I get 01, which is almost good as the other system wants to see 1.
What's confusing is when I take the whole dfdl and do asbitstream 1 becomes 31, 8 becomes 38. I get different values from what I got casting one field at the time.
Okay then, the next problem is the other system says every character must be represented as a nibble not as a byte. Then I got lost here 😀.
This is what they expects to get
001d1840
This is what I get cast each field
001d01080400
This is what I get cast whole dfdl
001d31383430
I just need a way to cast the whole dfdl to match what he wants. As there are a whole lot of fields after these 5 I have displayed. |
I'm not sure if this is a valid IIB coding technique, but 2 nibble values can be packed into a byte using integer calculation or bit shifts.
eg. val1 = 8 val2 = 4 (these must be in range 0 to 15 decimal)
byte x84 = val1 * 16 + val2
or
byte x84 = (val1 LeftShift 4 ) Or val2
_________________
Glenn |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon May 17, 2021 9:31 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I thought nibble values where being coded correctly with an &
so you have the original value, check the intersection with the 1 byte and see whether that bit is set or not. You can then either add it or subtract it from the byte to set or unset it. And it would have to be a power of 2... 
like byte && 8 = 8 the bit is set
byte && 8 = 0 the bit is not set ...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
