The jPOS packager alignment exercise is something I discuss here:
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:
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
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:
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
> 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="??{�"/>
> <field id="6" value="&�?�?��� "/>
> <field id="7" value="?#1;J?"/>
> </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
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.]