ISO8583 Secondary Bit Map

There was some good dialogue over the past 24 hours on the jPOS Users mailing list about how to implement the ISO8583 secondary bit map.  I find that most ISO specs gloss over this concept or don't do a good enough job explaining the implementation.  It's a fairly tricky concept.  I bet I've had to explain it in-depth about half a dozen times over the past year.

The best and most comprehensive description of the secondary bit map is something I ran across in Total Systems' ('TSYS') ISO8583 specs.  It says:

BIT MAP, SECONDARY

The first bit of the Bit Map, Primary indicates the presence or absence of a second map called the Bit Map, Secondary. Like the Primary map, the secondary map is a control field consisting of 64 bits (8 bytes). It can be considered an extension of the primary map, since it is associated with fields 66 through 128. Data field 65 does not exist. This position is used to indicate the present of another bit map. However, as no third bit map is currently defined, the first bit of the secondary bit map must always 0 (zero). The Bit Map, Secondary is included only when the message contains information in any field from 66 through 128. When present, the secondary map immediately follows the primary one and precedes the data fields.

Perfect.  Hey, they even describe the possibility of a tertiary bit map.  You can't get any more comprehensive than that.

So, you implement the secondary (and placeholder for the tertiary!) bit map(s) as follows:

<isopackager>
  <isofield
      id="0"
      length="4"
      name="MESSAGE TYPE INDICATOR"
      pad="true"
      class="org.jpos.iso.IFA_NUMERIC"/>
  <isofield
      id="1"
      length="16"
      name="BIT MAP"
      class="org.jpos.iso.IFB_BITMAP"/>
  <isofield
      id="2"
      length="19"
      name="PAN - PRIMARY ACCOUNT NUMBER"
      pad="false"
      class="org.jpos.iso.IFA_LLNUM"/> 

[snip]
 
  <isofield
      id="65"
      length="1"
      name="BITMAP, EXTENDED"
      class="org.jpos.iso.IFB_BINARY"/>

NOTE:  That's a packager that implements an ASCII, character-based implementation with a BCD bit map.  While your choice of classes will vary based upon your specific implementation needs, the roles of Fields 0, 1, 2 (showing 2 here simply as a boundary for the Bit Map) and 65 should look exactly like this.  I've got half a dozen different ISO8583 implementations running in jPOS, and each one looks like this in terms of the names and roles.

As Alejandro noted in his reply to the e-mail that started this discussion, jPOS takes care of the secondary bit map behind the scenes.  It doesn't need to be explicitly defined.  In other words, you see the bit map here is 16 in length.  If Field 1 is present, then the bit map you receive or build is 32 in length...but the underlying jPOS packager takes care of constructing (or deconstructing) that for you.  That's the beauty of what Alejandro has done:  everyone around the world was dealing over and over again with these quirky ISO8583 complexities, but he solved them for everyone once and for all.  As I've noted before:  if you're about to tackle an ISO8583-based project, why reinvent the wheel?

Comments

[Guy Richard]

Hi,
One more doubt regarding this.If we specify the above format in the packager the message can be easily packaged into a secondary bit map. But how can we read that? to illustrate using the given example the value in the iso field 65 can be read using ISOMsg.getString(65).But how can we read the value in the secondery field? ()

Guy

[Andy Orrock]

See answer provided to you by Alejandro Revilla in the jpos-users group:

With recent versions of jPOS (svn) you can do:

String s = message.getString("63.2");

[Atif]

hi,

I need help regarding bitmap's representation. How can I represent it as a series of ASCII characters? the ASCII equivalent of Zero (null character) makes the string terminate.

[Andy]

jPOS does this for you - in your packager, you can specify that the bit map use the ASCII version, not the packed version.