I have a doubt about implementing Custom Packagers

[Jaime Vizán González]

Hi, Im implementing a custom packager and I wonder if it is mandatory
to define a field like this
<isofield
id="1"
length="16"
name="Bitmap"
class="org.jpos.iso.IFE_BITMAP"/>
with id="1". I need other isofield with id="1". Im afraid I have to
extend ISOMsg class.

[Mark Salter]

Jaime Vizán González wrote:
> Hi, Im implementing a custom packager and I wonder if it is mandatory
> to define a field like this

If you need a bitmap, you must get the length/format correct, but that
is almost all your worries covered...

... I hope.

> <isofield
> id="1"
> length="16"
> name="Bitmap"
> class="org.jpos.iso.IFE_BITMAP"/>
> with id="1". I need other isofield with id="1". Im afraid I have to
> extend ISOMsg class.

May I ask what is in your field 1?

You may have some issues, but the detail of what is different with your
need will help us know...

--
Mark

[AAO]

That's your Secondary Bit Map indicator.

It's sort of confusing, which is why I took the time to explain it here:

http://www.andyorrock.com/2007/08/iso8583-seconda.html

Andy Orrock

2009/10/6 Jaime Vizán González <jaime...@gmail.com>

[Jaime Vizán González]

Hi, Mark. The field #1 is PAN, Primary Account Number. For example, I would like getting something like this

0200E76068000101580016552763006974700100... 

where:

0200 is the MTI

E760680001015800 is the bitmap (The fields #1,2,3,6,7,8,10,11,18,19,21,40,48,50,52,53 are presents)

16552763006974700100 is the field #1, PAN, etc

[Mark Salter]

Jaime Vizán González wrote:
> Hi, Mark. The field #1 is PAN, Primary Account Number. For example, I
> would like getting something like this

As Andy indicates, the first bit ('field 1' is likely a bit to indicate
that the secondary bitmap is present.

The second bit (bit 2) will indicate the pan is present ...

>
> 0200E76068000101580016552763006974700100...

My I guess this illustration is wrong...

I would think it should be:-

0200E760680001015800112233445566778816552763006974700100...

where 1122334455667788 is the secondary bitmap?

I hope you will see that ultimately the field numbers don't matter too
much. the raw data that travels across the network does not carry the
field numbers.

--
Mark

[Jaime Vizán González]

El 07/10/2009, a las 09:05, Mark Salter escribió:

>
> Jaime Vizán González wrote:
>> Hi, Mark. The field #1 is PAN, Primary Account Number. For example, I
>> would like getting something like this
>
> As Andy indicates, the first bit ('field 1' is likely a bit to
> indicate
> that the secondary bitmap is present.

is it possible the field 64 is the secondary bitmap? In this way, the
first bit could be the PAN

>
> The second bit (bit 2) will indicate the pan is present ...
>
>>
>> 0200E76068000101580016552763006974700100...
>
> My I guess this illustration is wrong...
>
> I would think it should be:-
>
> 0200E760680001015800112233445566778816552763006974700100...
>
> where 1122334455667788 is the secondary bitmap?

That's the problem I would like 1122334455667788 was the pan.

>
>
> I hope you will see that ultimately the field numbers don't matter too
> much. the raw data that travels across the network does not carry the
> field numbers.
>

Ok, but the bitmap travels across the network. For my application the
bitmap is wrong. My client send me messages with secondary bitmap bit
in field 64. I mean, the first bit is the PAN and not secondary bitmap.

Thanks in advance

>
> --
> Mark
>
> >

[chhil]

Please take a look at postpack.xml in the distribution.

See how it embed a secondary bitmap in field 127. Using this as an
example you can follow suit.

Have added a snippet below..

<isopackager>
<isofield
id="0"
length="4"
name="MESSAGE TYPE INDICATOR"
class="org.jpos.iso.IFA_NUMERIC"/>

<isofield
id="1"
length="16"

name="BIT MAP"
class="org.jpos.iso.IFB_BITMAP"/>
<isofield
:
:
:
:

<isofieldpackager
id="127"
length="999999"
name="RESERVED PRIVATE USE"
class="org.jpos.iso.IFA_LLLLLLBINARY"
packager="org.jpos.iso.packager.GenericSubFieldPackager">
<isofield
id="0"
length="0"
name="PLACEHOLDER"
class="org.jpos.iso.IF_CHAR"/>
<isofield
id="1"
length="8"
name="BITMAP"
class="org.jpos.iso.IFB_BITMAP"/>

Hope this helps...
-chhil

2009/10/7 Jaime Vizán González <jaime...@gmail.com>:

[Jaime Vizán González]

I get it.

I use the next file, siopack.xml:

<isopackager bitmapField="64">

<isofield
id="0"
length="4"
name="MESSAGE TYPE INDICATOR"
class="org.jpos.iso.IFA_NUMERIC"/>
<isofield
id="1"

length="20"
name="PAN - PRIMARY ACCOUNT NUMBER"
class="org.jpos.iso.IFA_NUMERIC"/>
....
<isofield
id="64"

length="16"
name="BIT MAP"

class="org.jpos.iso.IFA_BITMAP"/>

So, the ISOMsg 0200E76068000101580016552763006974700100... has a
correct bitmap for my application. Now the field 1 is PAN and it isn't
secondary bitmap.

Thanks

[Mark Salter]

Jaime Vizán González wrote:
> I get it.
Good, I'm not sure I see how this will work, I'm worried about how
ISOMsg knows to split the BITMap across fields - I will need to take a
closer look sometime.

>>> Ok, but the bitmap travels across the network. For my application the
>>> bitmap is wrong. My client send me messages with secondary bitmap bit
>>> in field 64. I mean, the first bit is the PAN and not secondary
>>> bitmap.

If the secondary bitmap has it's own field, then I can see your need is
different and - I think - a bit unusual.

If you have found a solution that works for you, then great, I'm happy too.

8)

Have you built a message and sent it successfully?

--
Mark

[Miscelanea]

Finally, I have achieved pack and unpack a message but I have had to
change JPos classes.

[Alejandro Revilla]

Finally, I have achieved pack and unpack a message but I have had to
change JPos classes.

and the changes are ... [drum roll....]