JPOS mismatch (version 1.5 / 1.4.2)
Rag Setty
We are designing a component which creates an ISO Message for any ISO
8583
compliant processor. We have two issues:
The first issue is specific to a processor- The second issue is a
general one
however based on the first issue asked.
1. We have discovered that, there is a problem using JPOS for creating
the ISO
message for an ISO 8583 compliant processor, FDC North ( ISO spec DSHV
-S1-0002-6.0. Specification, dated 8/31/2005 for leased line
merchants). Specifically for
Bit - 32, according to the JPOS spec (1.4.2 or 1.5) is 11 character
data. But, according to FDC
North's Spec, it is 12 character data. when we use JPOS it throws a ISO
Msg
exception when we put 12 digit value for field 32.
---------------------------------------------------------------------------------------------------------------------------------------
It is :
org.jpos.iso.ISOException: org.jpos.iso.IFA_LLNUM: Problem packing
field 32 (org.jpos.iso.ISOException: Field length 12 too long. Max: 11)
at
org.jpos.iso.ISOStringFieldPackager.pack(ISOStringFieldPackager.java:181)
at org.jpos.iso.ISOBasePackager.pack(ISOBasePackager.java:142)
at org.jpos.iso.ISOMsg.pack(ISOMsg.java:311)
at
com.cybs.cte.platform.formatter.GenericMessageFormatter.formatMessage(GenericMessageFormatter.java:306)
at
com.cybs.cte.platform.formatter.GenericMessageFormatterClient.main(GenericMessageFormatterClient.java:67)
---------------------------------------------------------------------------------------------------------------------------------------
2. Is the probability of occurance of above scenario very frequent?
(means can
it happen with other fields also, or with different processors). If so
- how
are they normally addressed in JPOS - Is there some assumption which we
have
missed out - it seems the larger issue is within the JPOS framework.
Are
there different flavours in the ISO 8583 spec ? Is that the case - if
so
again how do we address that - because according to our understanding
and
assumption, since this is a spec there will not be any variation in
field
length and position for the field for a iso compliant processor like
FDC
North.
Since our component should create an ISO Message for any ISO 8583
compliant
processor, this is a big worry for us.
Please do the needful at your earliest.
Thnx in advance,
rAgHaVeNdRa SeTtY
Andy Orrock
You have a fundamental misunderstanding of ISO8583.
Please re-read Section 2.2.1 of Alejandro's jPOS spec, especially this passage:
-------
The problem is not complexity but diversity, ISO-8583 is not specific
about how a given field is represented, so you can have a numeric
field represented as a sequence of ASCII characters, EBCDIC
characters, BCD, etc. Variable length fields have a prefix
specifying its length, but how this is represented is not defined,
different vendors uses different representations (i.e. BCD, EBCDIC,
binary value). In our example, field #3 is a using a BCD
representation, so a value of "000000" is represented with just three
bytes whose values are "00 00 00". Same goes for field #11 whose value
is "000001", it's represented as "00 00 01". In our example, field #41
is an 8 byte alphanumeric field representedas 8 ASCII characters
---------
Field 32 is a classic example of this exact phenomenon. Your FDR
North spec (I have it, too) defines Field 32 as 12 positions *BCD*
(i.e., packed into 6 bytes, with the length prefix). Alejandro's
packager - which should be construed as only a starting point - uses a
variation of Field 32 that is very typical because it's what all
BASE/24 implementations around the world use and that's an 11-position
alphanumeric field. BOTH are "ISO compliant" implementations of the
LLVAR construct.
Alejandro's baseline packager uses this:
id="32"
length="11"
name="ACQUIRING INSTITUTION IDENT CODE"
class="org.jpos.iso.IFA_LLNUM"/>
And you want to modify that to use this (note changes on the second
and fouth lines):
id="32"
length="12"
name="ACQUIRING INSTITUTION IDENT CODE"
class="org.jpos.iso.IFB_LLNUM"/>
This brings into question two things:
1) Have you gone through and looked at the FDR North implementation on
a field by field basis and determined the specific variation of the
data model FDR employs for each field? And have you then compared how
each of these are defined in your packager and adjusted the baseline
"generic" default accordingly? You need to do that. Alejandro's spec
makes clear that this exercise is at the heart of everything that jPOS
is about (this is what he's driving at when he says things like "It's
very important to read your interchange specifications as soon as
possible.").
2) Regarding your comment "Since our component should create an ISO
Message for any ISO 8583 compliant processor, this is a big worry for
us."...surely you now see the issue with this comment. Example: I
have in my possession two specs from FDR: One FDR North, the other
FDR Atlanta. Even within the *same company*, those two interfaces
have signigificant ISO implementation decisions and nuances that
require you to have two separate and specific packagers. Both
interfaces are (to use your term) "ISO Compliant." But both take
advantage of the flexibility of ISO8583 to create distinctly different
interfaces. In one system I work with, there are 5 separate ISO
interfaces. Each one requires a different packager.
Andy Orrock
matias crespillo
will represent each field.
Also, sorry for the offtopicness but --> rAgHaVeNdRa SeTtY <-- Is
this how you sign all your e-mails?
chhil
> Bit - 32, according to the JPOS spec ( 1.4.2 or 1.5) is 11 character
> data. But, according to FDC
> North's Spec, it is 12 character data. when we use JPOS it throws a ISO
> Msg
> exception when we put 12 digit value for field 32.
>
> ---------------------------------------------------------------------------------------------------------------------------------------
> It is :
>
>
> org.jpos.iso.ISOException: org.jpos.iso.IFA_LLNUM: Problem packing
> field 32 (org.jpos.iso.ISOException: Field length 12 too long. Max: 11)
> at
> org.jpos.iso.ISOStringFieldPackager.pack(ISOStringFieldPackager.java:181)
> at org.jpos.iso.ISOBasePackager.pack (ISOBasePackager.java:142)