Unable to unpack field 2 - Required 633 but just got 330 bytes

352 views
Skip to first unread message

hsampson

unread,
Dec 3, 2010, 9:03:22 AM12/3/10
to jPOS Users
Hi all,

I started using jpos a couple of weeks back and it's been a great help
in connecting to a postilion server I'm required to communicate with.
With the help of this list, I have be able to put together code that
uses PostChannel to connects to postilion and sends my request. Here
comes the problem: initially when I used dummy data, jpos was able to
unpack the responses from postilion (using cfg/packager/postpack.xml).
However, now that I'm using correct data I cannot unpack as before. I
get the following error.

<log realm="test" at="Fri Dec 03 13:50:45 UTC 2010.790"
lifespan="2ms">
<unpack>

3C3F786D6C2076657273696F6E3D22312E302220656E636F64696E673D225554462D38223F3E3C466272543234586D6C3E3C4D7367547970653E3C2F4D7367547970653E3C4669656C64733E3C5472616E547970653E3C2F5472616E547970653E3C527370436F64653E203C2F527370436F64653E3C4C656467657242616C616E6365203E203C2F4C656467657242616C616E63653E3C417661696C61626C6542616C616E63653E203C2F417661696C61626C6542616C616E63653E3C46544E756D6265723E203C2F46544E756D6265723E3C4163636F756E7443757272656E63793E203C2F4163636F756E7443757272656E63793E3C53746174656D656E74446174613E203C2F53746174656D656E74446174613E3C4572726F72546578743E43616E6E6F7420646573657269616C697A6520584D4C3C2F4572726F72546578743E3C2F4669656C64733E3C2F466272543234586D6C3E
<bitmap>{2, 3, 5, 6, 11, 18, 19, 20, 22, 23, 26, 27, 30, 32, 34,
35, 36, 39, 42, 43, 44, 47, 48, 50, 51, 53, 56, 58, 59, 61, 62, 63, 64}
</bitmap>
error unpacking field 2 consumed=12
<iso-exception>
org.jpos.iso.IFA_LLNUM: Problem unpacking field 2
<nested-exception>
java.lang.RuntimeException: Required 633 but just got 330 bytes
at
org.jpos.iso.AsciiInterpreter.uninterpret(AsciiInterpreter.java:63)
at
org.jpos.iso.ISOStringFieldPackager.unpack(ISOStringFieldPackager.java:
173)
at org.jpos.iso.ISOBasePackager.unpack(ISOBasePackager.java:
234)
at org.jpos.iso.ISOMsg.unpack(ISOMsg.java:416)
at org.jpos.iso.BaseChannel.unpack(BaseChannel.java:903)
at org.jpos.iso.BaseChannel.receive(BaseChannel.java:671)

Your kind assistance is greatly appreciated

Cheers

Mark Salter

unread,
Dec 3, 2010, 9:25:28 AM12/3/10
to jpos-...@googlegroups.com
On 03/12/2010 14:03, hsampson wrote:

> I started using jpos a couple of weeks back and it's been a great help
> in connecting to a postilion server I'm required to communicate with.

So you have the message spec, you know how the message length is
represented (and have chosen the channel appropriately), you know what
headers need to be present (if any) and you have checked the format of
the message required matches the Packager you have selected?


> With the help of this list, I have be able to put together code that
> uses PostChannel to connects to postilion and sends my request. Here
> comes the problem: initially when I used dummy data,

Define 'dummy data' please?

It seems possible that the target system might previously have been
returning your data back as 'rubbish' or unknown card? So being able to
unpack what you sent in might not be as successful as you hoped.

> jpos was able to
> unpack the responses from postilion (using cfg/packager/postpack.xml).
> However, now that I'm using correct data I cannot unpack as before. I
> get the following error.

Correct data? A card in the expected BIN range for example?

>
> <log realm="test" at="Fri Dec 03 13:50:45 UTC 2010.790"
> lifespan="2ms">
> <unpack>
>
> 3C3F786D6C2076657273696F6E3D22312E302220656E636F64696E673D225554462D38223F3E3C466272543234586D6C3E3C4D7367547970653E3C2F4D7367547970653E3C4669656C64733E3C5472616E547970653E3C2F5472616E547970653E3C527370436F64653E203C2F527370436F64653E3C4C656467657242616C616E6365203E203C2F4C656467657242616C616E63653E3C417661696C61626C6542616C616E63653E203C2F417661696C61626C6542616C616E63653E3C46544E756D6265723E203C2F46544E756D6265723E3C4163636F756E7443757272656E63793E203C2F4163636F756E7443757272656E63793E3C53746174656D656E74446174613E203C2F53746174656D656E74446174613E3C4572726F72546578743E43616E6E6F7420646573657269616C697A6520584D4C3C2F4572726F72546578743E3C2F4669656C64733E3C2F466272543234586D6C3E
> <bitmap>{2, 3, 5, 6, 11, 18, 19, 20, 22, 23, 26, 27, 30, 32, 34,
> 35, 36, 39, 42, 43, 44, 47, 48, 50, 51, 53, 56, 58, 59, 61, 62, 63, 64}
> </bitmap>
> error unpacking field 2 consumed=12
> <iso-exception>
> org.jpos.iso.IFA_LLNUM: Problem unpacking field 2
> <nested-exception>
> java.lang.RuntimeException: Required 633 but just got 330 bytes
> at
> org.jpos.iso.AsciiInterpreter.uninterpret(AsciiInterpreter.java:63)
> at
> org.jpos.iso.ISOStringFieldPackager.unpack(ISOStringFieldPackager.java:
> 173)
> at org.jpos.iso.ISOBasePackager.unpack(ISOBasePackager.java:
> 234)
> at org.jpos.iso.ISOMsg.unpack(ISOMsg.java:416)
> at org.jpos.iso.BaseChannel.unpack(BaseChannel.java:903)
> at org.jpos.iso.BaseChannel.receive(BaseChannel.java:671)
>
> Your kind assistance is greatly appreciated

What is your MTI inbound, what does the target system 'think' of your
request and what MTI is in the response?

I don't see much 'ascii' or anything particulary iso8583 like so suspect
your Packager selection is incorrect.

I thought you may have a header to deal with.

The packager is currently falling into some bytes that it is treating as
the bitmap (possibly the wrong bytes), then trying to pick up field 2
length, which is also wrong (633 bytes is a bit much for a card number).

Currently you are *way* off the mark.

The message given above is xml!

<?xml version="1.0"
encoding="UTF-8"?><FbrT24Xml><MsgType></MsgType><Fields><TranType></TranType><RspCode>
</RspCode><LedgerBalance > </LedgerBalance><AvailableBalance>
</AvailableBalance><FTNumber> </FTNumber><AccountCurrency>
</AccountCurrency><StatementData> </StatementData><ErrorText>Cannot
deserialize XML</ErrorText></Fields></FbrT24Xml>


Please start again from the top this time:-

Use the message length structure to select the right Channel,
Check for Headers (if they are needed) and what they contain,
Check the Packager matches the interface specification exactly.


--
Mark

Mark Salter

unread,
Dec 3, 2010, 9:30:18 AM12/3/10
to jpos-...@googlegroups.com
On 03/12/2010 14:03, hsampson wrote:
> Your kind assistance is greatly appreciated
>
PS, which company are you working for in Ghana?

Please check the license conditions if you intend to build a commercial
solution using 'our' jPos code.

--
Mark

Henry Sampson

unread,
Dec 3, 2010, 1:57:54 PM12/3/10
to jpos-users
Hi Mark,

Thanks for the reply. I think I did all due diligence but your reply has confirmed a suspicion that I had that the interface was not returning an ISO message.

And I believe you know I'm from Ghana from Alejandro so for licensing that is currently firmly in our scope. As your implementation plan suggests, I am testing currently

Cheers,

Henry



--
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  "jPOS Users" group.
Please see http://jpos.org/wiki/JPOS_Mailing_List_Readme_first
To post to this group, send email to jpos-...@googlegroups.com
To unsubscribe, send email to jpos-users+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/jpos-users

Mark Salter

unread,
Dec 3, 2010, 3:12:37 PM12/3/10
to jpos-...@googlegroups.com
On 03/12/2010 18:57, Henry Sampson wrote:
> Hi Mark,

Hi Henry.

>
> Thanks for the reply. I think I did all due diligence but your reply has
> confirmed a suspicion that I had that the interface was not returning an
> ISO message.

I wondered if this was an error condition. I was wondering how best to
handle an xml error versus an ISO8583 response. I figured the normal
course of events the xml would not be returned, still seems a little odd
to me.

I couldn't see any pattern in the response, so feared the worse and
translated from hex to ascii just in case there was anything useful -
the xml was a surprise.

>
> And I believe you know I'm from Ghana from Alejandro so for licensing
> that is currently firmly in our scope. As your implementation plan
> suggests, I am testing currently

I checked your email headers which spawned my question. I always take
an interest in where in the world questions (and users) come from, I
guess I am nosey 8). Are you working for a banking or card
organisation; are you at liberty to say?

Very glad to hear you have spoken with Alejandro already,

Hopefully my pointers helped rather than hindered, so good luck and I
hope you are running real soon.


--
Mark

Alejandro Revilla

unread,
Dec 3, 2010, 3:46:23 PM12/3/10
to jpos-...@googlegroups.com
I wonder if the XML information you have is taken from one of the ISO-8583 fields.

I would double-check your definition of field 127.

As for Mark's geolocation, most of us do that, I start reading e-mails on the first 'From' of the rfc-822 header, it was not a #jposleak :)

chi...@gmail.com

unread,
Dec 4, 2010, 11:48:11 PM12/4/10
to jpos-...@googlegroups.com
I recall seeing postilion mentioned in earlier emails and 127.22 holds data in name value pairs and is the only place in a bitmapped message that holds xml.
Postilion also supports a xml 8583 non bitmapped message but this one does not seem to fall in that category. -chhil
_

Sent from BlackBerry® on Airtel


From: Alejandro Revilla <a...@jpos.org>
Date: Fri, 3 Dec 2010 18:46:23 -0200
Subject: Re: [jpos-users] Unable to unpack field 2 - Required 633 but just got 330 bytes

Tauya Mhangami

unread,
Dec 2, 2017, 4:23:42 PM12/2/17
to jPOS Users
did anyone know how to define a packager that uppacks Postilion field 127.22? I am using the one below but i am geting the followin err
org.jpos.iso.ISOException: org.jpos.iso.IFA_LLLLLLCHAR: Problem unpacking field 22 (java.lang.ArrayIndexOutOfBoundsException: 1026)

                 new IFA_LLCHAR(12, "RECORD IDENTIFICATION"),
                  new IFA_LLLLLLCHAR(999999, "STRUCTURED DATA"),
                         
                  new IF_CHAR(253, "PAYEE NAME AND ADDRESS"),
                  new IFA_LLCHAR(28, "PAYER ACCOUNT INFORMATION"),
                  new IFA_LLLLCHAR(8000, "ICC DATA")
              

              };
              public Field127Packager() {
                // TODO Auto-generated constructor stub
                  super();
                  setFieldPackager(fld127);
            }

I try to dump and this is what I am getting.  Please assist
127<isomsg id="127">
127  <field id="0" value=""/>
127  <field id="2" value="0000115335"/>
127  <field id="3" value="RBZPosSrc   RBZPBSnk    000124000124RBZDebitGrp "/>
127  <field id="4" value="RBZ00001224259        "/>
127  <field id="6" value="34"/>
127  <field id="11" value="0000115335"/>
127  <field id="13" value="hazwe         zwe"/>
127  <field id="14" value="RBZ     "/>
127  <field id="20" value="20171026"/>
127  <field id="22" value="214TellerLastName13RBZ215TellerFirstName19TellerOne218Postilion:MetaData3135214TellerLastName111215TellerFirstName111210TellerCard111222TermInfo.ParticipantId111226Postilion:ActiveActiveData111212TerminalType111210TellerCard2165912221660012312222TermInfo.ParticipantId119226Postilion:ActiveActiveData232223PostCard:PinBasedSecure14true212TerminalType217eftcHypercomBase5"/>
127</isomsg>

please assist

chhil

unread,
Dec 2, 2017, 8:24:07 PM12/2/17
to jpos-...@googlegroups.com
Ideally to remove any guess work you should look at the Postilion ISO specification to define your field.
You can try the packagers from 


-chhil

--
--
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+unsubscribe@googlegroups.com.
To post to this group, send email to jpos-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/3d09f0fe-8a3b-4903-8c2a-32d5fd708b95%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages