hypercom t4220 and jPOS

368 views
Skip to first unread message

jPOS Users

unread,
May 4, 2008, 10:34:43 PM5/4/08
to jPOS Users

I am new in jPOS, I have some questions about it.

I wanted to use a hypercom t4220 as the swipe terminal to connect to
the jPOS server. While there is not a lot of information on the web
about using jPOS with that exact model, there is a lot of info about
using it with Hypercoms in general, and I think different hypercoms
tend to be pretty consistent with their ISO8583 implementations. With
jPOS as I know there are two major configurations: the channel and the
packager. based on my research online I think I need the NACChannel
with the ISO87BPackager, is it right? Also, I am not clear the value
for the TPDU passed into the NACChannel. Can you please give me your
suggestion about how to integrate the hypercom t4220 and jPOS?

Thanks,

Gao

Alejandro Revilla

unread,
May 5, 2008, 7:44:04 AM5/5/08
to jpos-...@googlegroups.com
While ISO87BPackager and NACChannel are probably the right choice, you
need to study the protocol specification for your particular terminal
software implementation.

jPOS Users

unread,
May 5, 2008, 10:01:30 AM5/5/08
to jPOS Users
Thanks for your help. But I got an error when I use the ISO87BPackager
and NACChannel.

error unpacking field 119
org.jpos.iso.ISOException: org.jpos.iso.IFB_LLLCHAR: Problem unpacking
field 119
(java.lang.ArrayIndexOutOfBoundsException: 80)
at
org.jpos.iso.ISOStringFieldPackager.unpack(ISOStringFieldPackager.jav
a:216)
at org.jpos.iso.ISOBasePackager.unpack(ISOBasePackager.java:
262)
at org.jpos.iso.ISOMsg.unpack(ISOMsg.java:325)
at org.jpos.iso.BaseChannel.receive(BaseChannel.java:575)
at org.jpos.iso.ISOServer$Session.run(ISOServer.java:128)
at org.jpos.util.ThreadPool$PooledThread.run(ThreadPool.java:
103)
Nested:java.lang.ArrayIndexOutOfBoundsException: 80
at org.jpos.iso.BcdPrefixer.decodeLength(BcdPrefixer.java:115)
at
org.jpos.iso.ISOStringFieldPackager.unpack(ISOStringFieldPackager.jav
a:197)
at org.jpos.iso.ISOBasePackager.unpack(ISOBasePackager.java:
262)
at org.jpos.iso.ISOMsg.unpack(ISOMsg.java:325)
at org.jpos.iso.BaseChannel.receive(BaseChannel.java:575)
at org.jpos.iso.ISOServer$Session.run(ISOServer.java:128)
at org.jpos.util.ThreadPool$PooledThread.run(ThreadPool.java:
103)
<log realm="iso-server.channel/70.21.74.7:61165" at="Mon May 05
20:45:35 CST 200
8.514">
<receive>
--- len ---==85
--- hLen ---==5
--- getMaxPacketLength() ---==100000
if (b.length > 0 && !shouldIgnore (header)) begin
<iso-exception>
org.jpos.iso.IFB_LLLCHAR: Problem unpacking field 119
<nested-exception>
java.lang.ArrayIndexOutOfBoundsException: 80
at org.jpos.iso.BcdPrefixer.decodeLength(BcdPrefixer.java:115)
at
org.jpos.iso.ISOStringFieldPackager.unpack(ISOStringFieldPackager.jav
a:197)
at org.jpos.iso.ISOBasePackager.unpack(ISOBasePackager.java:
262)
at org.jpos.iso.ISOMsg.unpack(ISOMsg.java:325)
at org.jpos.iso.BaseChannel.receive(BaseChannel.java:575)
at org.jpos.iso.ISOServer$Session.run(ISOServer.java:128)
at org.jpos.util.ThreadPool$PooledThread.run(ThreadPool.java:
103)
</nested-exception>
org.jpos.iso.ISOException: org.jpos.iso.IFB_LLLCHAR: Problem
unpacking fie
ld 119 (java.lang.ArrayIndexOutOfBoundsException: 80)
at
org.jpos.iso.ISOStringFieldPackager.unpack(ISOStringFieldPackager.jav
a:216)
at org.jpos.iso.ISOBasePackager.unpack(ISOBasePackager.java:
262)
at org.jpos.iso.ISOMsg.unpack(ISOMsg.java:325)
at org.jpos.iso.BaseChannel.receive(BaseChannel.java:575)
at org.jpos.iso.ISOServer$Session.run(ISOServer.java:128)
at org.jpos.util.ThreadPool$PooledThread.run(ThreadPool.java:
103)
Nested:java.lang.ArrayIndexOutOfBoundsException: 80
at org.jpos.iso.BcdPrefixer.decodeLength(BcdPrefixer.java:115)
at
org.jpos.iso.ISOStringFieldPackager.unpack(ISOStringFieldPackager.jav
a:197)
at org.jpos.iso.ISOBasePackager.unpack(ISOBasePackager.java:
262)
at org.jpos.iso.ISOMsg.unpack(ISOMsg.java:325)
at org.jpos.iso.BaseChannel.receive(BaseChannel.java:575)
at org.jpos.iso.ISOServer$Session.run(ISOServer.java:128)
at org.jpos.util.ThreadPool$PooledThread.run(ThreadPool.java:
103)
</iso-exception>
--- header ---
0000 02 00 30 20 05 ..0 .

--- data ---
0000 80 20 C0 00 06 00 00 00 00 00 00 00 01 50 00
01 . ...........P..
0010 13 00 22 00 00 00 37 40 55 01 11 11 11 11 11 D1 .."...
7@U.......
0020 01 21 01 54 32 11 23 45 67 8F 32 36 34 30 30 30 .!.T2.#Eg.
264000
0030 35 30 30 30 30 34 33 34 30 37 32 36 30 30 30 37
5000043407260007
0040 35 00 06 30 30 30 30 39 30 00 05 00 03 31 35 31
5..000090....151

</receive>
</log>

Can you please give me your suggestion?

aaor...@gmail.com

unread,
May 5, 2008, 10:22:01 AM5/5/08
to jpos-...@googlegroups.com
My man, ain't no way a packager is gonna work out of the box for you. Take a look at my "On-boarding Guide" and do the needful in regards to the part about reading your spec and aligning your packager. You can't skip around the reality of doing that for all fields in play. It's essential for any type of shot at success

I'm not at a computer right now, but go to www.andyorrock.com and search on the terms Onboarding, interface and new. Look for the guide I wrote (downloadable as a PDF).

Andy Orrock

-----Original Message-----
From: jPOS Users <week...@gmail.com>

Date: Mon, 5 May 2008 07:01:30
To:jPOS Users <jpos-...@googlegroups.com>
Subject: Re: hypercom t4220 and jPOS

Andy Orrock

unread,
May 5, 2008, 11:42:22 AM5/5/08
to jpos-...@googlegroups.com
At my desk now...

The jPOS packager alignment exercise is something I discuss here:

http://tinyurl.com/gbtq5

I use American Express (acquirer-side) as my example, but the exercise is
equally relevant to any inbound device or issuer-side auth link.

You can also read Sections 1 and 2.1.2 of my Onboarding Guide (it
specifically addresses onboarding on an outgoing auth link, but its
commentary re. spec alignment are still pertinent to your work. See the
guide referenced here:

http://tinyurl.com/37bjfs

Andy Orrock

-----Original Message-----
From: jpos-...@googlegroups.com [mailto:jpos-...@googlegroups.com] On
Behalf Of jPOS Users
Sent: Monday, May 05, 2008 9:02 AM
To: jPOS Users
Subject: Re: hypercom t4220 and jPOS

jPOS Users

unread,
May 5, 2008, 11:31:08 PM5/5/08
to jPOS Users
Thanks for your help. I have got the pdf file and browsed your
website.

I am using JDK1.4. I am not sure if JDK1.4 support Q2. does it
support?

About the packager alignment, I am using the ISO87BPackager, should I
only change the class type of the fields or define a new packager? How
to do it?

jPOS Users

unread,
May 5, 2008, 11:34:51 PM5/5/08
to jPOS Users
Thanks for your help. I have got the pdf file and browsed your
website.

I am using JDK1.4. I am not sure if JDK1.4 support Q2. does it
support?

About the packager alignment, I am using the ISO87BPackager, should I
only change the class type of the fields or define a new packager? How
to do it?

On May 5, 11:42 pm, "Andy Orrock" <aaorr...@gmail.com> wrote:

Andy Orrock

unread,
May 6, 2008, 9:15:53 AM5/6/08
to jpos-...@googlegroups.com

You'd be better off on 1.5. Sun has EOL-ed 1.4.2 (Oct. 08) as you know.

We run 1.4.2 at one site right now, but we're in the process of upgrading to
1.5. We can run 1.4.2 because our jPOS version is running at r2569. That's
not happenstance: it was a strategic choice.

Alejandro's comments to me at the r2570 juncture point were:

> Version r2569 is good for 1.4.2, on the next release (2570) we've
> removed MX4J in order to use the JMX implementation provided by
> the JVM.

So, it would be incumbent on you to add the MX4J-specific JMX extensions
back in if you go for jPOS off the latest SVN and deploy on 1.4.2.

See r2570 commit here:

http://tinyurl.com/6khmno

Where you ask " should I only change the class type of the fields or define


a new packager? How to do it?"

I take it as a given that you've purchased the jPOS Programmers' Guide and
have read Chapter 7 ("Implementing Custom Packagers") and the related
Appendix ("ISOFieldPackagers"). In Chapter 7, you'll see some examples,
including the complex situations where you have to make use of the
isofieldpackager to handle situations where you have "an ISO-8583 field that
is a full ISO-8583 message itself."

You say:

"Should I only change the class type of the fields or define a new packager?
How to do it?"

Starting from scratch would be re-inventing the wheel. Use an existing
packager as your starting point. Other than 'id' (you'll want all 128
fields defined), ANY of the fields will be in play for change. There really
are no shortcuts here. You need to examine your spec field field-by-field
and then make the corresponding field-by-field changes to your packager
file.

As an example, take a look at this post I did - I had to install an 'FDR
Omaha' (aka, 'FDR Central') credit/offline debit interface. So I read the
spec and jotted down some "Game Plan" notes about how to align a packager:

The post is here: http://tinyurl.com/5pwrh6

The alignment notes ("On-Boarding Game Plan Notes") are here:
http://tinyurl.com/64uod3

The resulting packager is here:

http://andyorrock.typepad.com/paymentsystems/cmc.xml

jPOS Users

unread,
May 6, 2008, 11:12:14 AM5/6/08
to jPOS Users
I really appreciate your help.

I have aligned the packager the same as the AMEX on the page of
http://tinyurl.com/gbtq5. But when I do a transaction with a AMEX
card, I got some stange characters. please have a look.

<isomsg direction="incoming">
<header>0200302005</header>
<field id="0" value="??{&#0;"/>
<field id="6" value="&#1;&amp;&#0;&#1;?&#0;?&#0;&#0;&#0;&#4; "/>
<field id="7" value="?#1;&#17;&#17;&#17;&#17;&#17;J&#1;?"/>
</isomsg>
Also other fields can not be received.

I will continue my test. Can you give me some suggestion?
> > > software implementation.- 隐藏被引用文字 -
>
> - 显示引用的文字 -

Mark Salter

unread,
May 6, 2008, 11:29:15 AM5/6/08
to jpos-...@googlegroups.com
jPOS Users wrote:

> I have aligned the packager the same as the AMEX on the page of
> http://tinyurl.com/gbtq5. But when I do a transaction with a AMEX
> card, I got some stange characters. please have a look.

Andy was not suggesting that the Amex packager was what you needed!

He gave the link as a pointer to what you needed to do to prepare a
packager to meet the needs of the system you are trying to communicate with.

The card number in the message used does not define the message
structure, the system's interface does.

>
> <isomsg direction="incoming">
> <header>0200302005</header>
> <field id="0" value="??{&#0;"/>
> <field id="6" value="&#1;&amp;&#0;&#1;?&#0;?&#0;&#0;&#0;&#4; "/>
> <field id="7" value="?#1;&#17;&#17;&#17;&#17;&#17;J&#1;?"/>
> </isomsg>

Is this an 0200 message? Perhaps this interface does not use headers?

However without a packager *matching* the interface you want to exchange
messages with, you are not testing, you are putting random components
together and very likely confusing yourself.

Start at the top, understand what you are trying to achieve and then the
packager will start making sense.

--
Mark

Andy Orrock

unread,
May 6, 2008, 11:33:01 AM5/6/08
to jpos-...@googlegroups.com
Whoa.

You misinterpreted my original e-mail. That post I referred you to -
http://tinyurl.com/gbtq5 - discusses how to do the jPOS packager alignment
exercise. I simply used AMEX as an example. I only picked AMEX because
their specs are freely available to all and they're excellent specs, so it's
easy to follow along.

What my post did *not* say was "Use the AMEX packager." It is a specific
implementation:

- EBCDIC, not ASCII
- Display field driven throughout, not BCD
- ISO8583:1993, not ISO8583:1987

It's highly unlikely these are your specific needs.

You need to:

1) Pick the closest packager as your starting point (ISO87BPackager is
probably closer than my AMEX packager...also note that I posted another
valid starting point in my last e-mail).

2) Read the jPOS Programmers' Manual Chapter 7 + the associated appendix.

3) Study your spec and note how each field varies from the starting point.

4) Align each of the fields where there's a difference between your starting
point model and your requirement. That's what I did here:
http://tinyurl.com/64uod3

The point of showing you my hand-written notes is to demonstrate that (a) it
doesn't need to be a formal exercise; and, (b) there's no avoiding the
field-by-field analysis like that. [That was the eighth interface we'd
on-boarded for that particular customer, and you can see that I still didn't
have a shortcut available to avoid the analysis.]

Reply all
Reply to author
Forward
0 new messages