Getting Unicode value instead of Original Value in Field 95 (Generic Packager) (Length 42)

[Bheshaj Majhi]

Hello JPOS Users,

I tried with this various types of Class but getting UNICODE results instead of original value.
Kindly suggest how to get proper original field 95 value. 
(Original Value - 000000005000000000000000000000000000000000 )

<isofield
            id="95"
            length="42"
            name="REPLACEMENT AMOUNTS"
            class="org.jpos.iso.IFE_CHAR  "/>


IFE_CHAR
   <field id="95" value="\u0008ïµ\u0000\u0000\u0000\u0002��\u0001\u0000\u0000\u000a\u0010\u0009\u001b\u0009��\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u00000000000050"/>

IFE_AMOUNT  -- \u0001é\u000µ\u0000\u0000\u0000\u0002��\u0001\u0000\u0000\u000a\u0012\u0009\u001b�\u0009\u0003\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u00000000000050

IFE_NUMERIC - "ñï\u000µ\u0000\u0000\u0000\u0002��\u0001\u0000\u0000\u000a\u0013\u0009\u001b�\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u00000000000050

IFA_NUMERIC -    
<field id="95" value="`�(\u0007 \u0000\u0000\u0000\u0002%\u0004\u0001\u0000\u0000\u0015\u0016\u0005&apos;\u0006D&quot;\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000ððððððððõð"/>

IFA_AMOUNT -        
 <field id="95" value="�&apos;�\u0007 \u0000\u0000\u0000\u0002%\u0004\u0001\u0000\u0000\u0015\u0017\u0005&apos;\u0006Q8\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000ððððððððõð"/>


IFE_LLNUM--
"µ\u0000\u0000\u0000\u0002��\u0001\u0000\u0000\u000a\u0019\u0009\u001b�ßï\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u00000000000050000000000000000000000"/>

I have tried with this many, your guidance will be highly appreciated. (referred Programmer's guide too :) 

Thanks & Regards, 
Bheshaj 

[Andrés Alcarraz]

It seems your data is BCD encoded (that should be in the interface specification), so you need IFB_NUMERIC.

I hope this helps.

Andrés Alcarraz

--
--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage. Please support jPOS, contact: sa...@jpos.org
---
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/4eb23f93-73c9-4b71-ad6f-1ee3efef92bcn%40googlegroups.com.

​

[Bheshaj Majhi]

Hello,

IFB_NUMERIC produced, 
 <field id="95" value="984678071000000002250401000015210528043500"/>
which is different.
whereas, 

(Original Value - 000000005000000000000000000000000000000000 )

Kindly suggest.

[Andrés Alcarraz]

Sorry, without access to the specs and the raw bytes, I'm out of guesses, which we shouldn't be doing in the dirst place.

----
Enviado desde mi móvil, disculpas por la brevedad.

Sent from my cellphone, I apologize for the brevity.

Andrés Alcarraz.

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/9fb6532a-bf4e-4a0d-9e97-77f4dc9bf3dan%40googlegroups.com.

[Bheshaj Majhi]

Attached screenshot of field 95 attribute. please check and suggest.

[Andrés Alcarraz]

According to the spec, it should be IFE_NUMERIC, if it doesn't work, either the spec is wrong or the data you have (which you still didn't share) is, also p, show how you are doing to test. Code and all.

----
Enviado desde mi móvil, disculpas por la brevedad.

Sent from my cellphone, I apologize for the brevity.

Andrés Alcarraz.

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/894d909a-9547-44e6-a19f-5f53b1f5ac30n%40googlegroups.com.

[Bheshaj Majhi]

I have tried with IFE_NUMERIC as mentioned at first msg. But getting Unicode. 
Regarding the test, (  how you are doing to test  )  I am using VTS sim and receiving the isomsg as issuer (using Generic Packager)
as below, 

<isofield
            id="95"
            length="42"
            name="REPLACEMENT AMOUNTS"

            class="org.jpos.iso.IFE_NUMERIC "/>
where, 

IFE_NUMERIC - "ñï\u000µ\u0000\u0000\u0000\u0002��\u0001\u0000\u0000\u000a\u0013\u0009\u001b�\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u00000000000050

where original value sent from VTS is 000000005000000000000000000000000000000000.
I hope I am clear about this. If not, do suggest.

Having issue with only field 95 other field data is receiving in correct format.

[Andrés Alcarraz]

Please share the whole raw data (in hex) you are testing, so we can help you.

Are you sure that when packager reaches that field it has correctly consumed previous fields?

It's hard to help you with so little data. There are dozens of things that could be wrong.

----
Enviado desde mi móvil, disculpas por la brevedad.

Sent from my cellphone, I apologize for the brevity.

Andrés Alcarraz.

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/2d0c0527-e730-42a9-8e78-276a9dadb837n%40googlegroups.com.

[Bheshaj Majhi]

Hello Andrés,
Sorry, I am not able to share whole Hexdump data due to security purpose. Also do suggest if there is any other way around this.
I would greatly appreciate your help with that.

[Andrés Alcarraz]

Just mask the sensible parts, or take a non production message. Otherwise, it will extremely hard for anyone to help you.

----
Enviado desde mi móvil, disculpas por la brevedad.

Sent from my cellphone, I apologize for the brevity.

Andrés Alcarraz.

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/d79713ef-c314-4bad-a464-9ec36232646fn%40googlegroups.com.

[Bheshaj Majhi]

0000  04 10 F6 7E 64 81 0A E0  A4 1E 00 00 00 42 00 00  ...~d........B..
0010  00 00 10 XX XX XX XX XX  XX 98 76 00 00 00 00 00  ...@e.....f.....
0020  00 00 67 00 00 00 00 00  67 00 05 30 14 14 49 61  ..g.....g..(..Ia
0030  00 00 00 00 15 45 19 44  47 05 28 28 20 05 29 59  .....E.DG.(1..)Y
0040  99 07 56 05 10 00 06 27  52 81 F4 F1 F4 F9 F1 F4  ..V....Ga7......
0050  F0 F0 F1 F5 F4 F5 F0 F0  E3 C5 D9 D4 C9 C4 F0 F1  ................
0060  C3 C1 D9 C4 40 C1 C3 C3  C5 D7 E3 D6 D9 40 40 C1  ....@........@@.
0070  C3 D8 E4 C9 D9 C5 D9 40  D5 C1 D4 C5 40 40 40 40  .......@....@@@@
0080  40 40 40 40 40 40 40 40  C2 C8 E4 C2 C1 D5 C5 E2  @@@@@@@@........
0090  E6 C1 D9 40 40 C9 D5 07  56 07 56 14 F0 F0 F0 F1  ...@@...V.V.....
00a0  F3 F5 F6 C3 F0 F0 F0 F0  F0 F0 F0 F0 F2 F0 F0 F0  ................
00b0  01 05 12 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
00c0  00 00 00 50 00 10 40 00  00 00 00 00 00 00 03 04  ...P..@.........
00d0  14 95 12 84 92 44 07 A0  00 00 00 02 25 04 01 00  .....D......%...
00e0  00 15 45 05 28 14 14 47  00 00 00 00 00 00 00 00  ..E.(..G........
00f0  00 00 00 F0 F0 F0 F0 F0  F0 F0 F0 F5 F0           .............

Here is the hexdump. Kindly check and suggest. Andrés   

[Andrés Alcarraz]

I don’t see any EBCDIC in the message that could be what you are looking for, except at the end, but it is just the beginning, in that case the field packager is indeed IFE_NUMERICas it should, but the problem is somewhere else, if the data is incomplete, then the problem is in the channel.

But also, your content is not aligend, or you should see an ArrayOutOfBoundsException so you surely have other fields before which do not hold the correct values.

As I said previously, either the spec was wrong or the data was, and it was the data. You have a long way ahead if your packager does not match the spec and you should be doing this in test environment with test data you can share. But also, you need to check field by field against the specs and the data.

Regards.

El 28/05/24 a las 10:30, Bheshaj Majhi escribió:

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/0184a894-b7c8-4826-acd8-85659d500e1en%40googlegroups.com.

​

--

Andrés Alcarraz

[Bheshaj Majhi]

Thank you so much  Andrés, Found the issue and it was due FIELD 61 (org.jpos.iso.IFB_LLHNUM) due to which the value is getting trimmed to 18 length value (instead of 36 digit length value). So after changing the FIELD 61 (org.jpos.iso.IFB_LLHBINARY) , getting Correct Value in Field 95.

Regards, 
Bheshaj