When we started to log messages using a very simple XML format a long time ago, and then created the XMLPackager to support that message format, we never thought that this was going to be so heavily used, we frequently find ISO-8583 interchanges based on this format, implemented in different languages by different vendors in different countries.

I’ve recently been involved in the deployment of an ISO/Bridge system at a financial institution in one African country connected to another institution at another African country. When I asked for the ISO-8583 specs in order to configure ISO/Bridge, I was surprised to see that the specs where XML based, and basically our spec.

I hope we start seeing this with the jPOS CMF soon.

The existing format looks like this:

 <isomsg>
   <field id="0" value="0800" />
   <field id="11" value="000001" />
   <field id="70" value="301" />
 </isomsg>

Starting in jPOS 1.6.5 r2817, you can optionally use:

 <isomsg>
   <field id="0">0800</field>
   <field id="11">000001</field>
   <field id="70">301</field>
 </isomsg>

Or any combination, i.e:

 <isomsg>
   <field id="0" value="0800" />
   <field id="11" value="000001" />
   <field id="70">301</field>
 </isomsg>

This is particularly useful in some implementations that use XML content as part of the ISO-8583 payload, in the past, we had to expand it using XML entities such as <, > that where not nice looking in the logs.

With the new addition, we can:

 <isomsg>
   <field id="0" value="0800" />
   <field id="11" value="000001" />
   <field id="70">301</field>
   <field id="127">< ?xml version='1.0' encoding='UTF-8' ?>
      <custom>
         <tid>29110001</tid>
         <message>I love XML tags</message>
      </custom>
   </field>
 </isomsg>

(you have to add a CDATA block around your inner XML)

At response time, we wanted to make it as backward compatible as possible, so we only use this mode if we detect that the field content is XML.

/by apr/

If you use the jPOS’ TransactionManager, and you use a Map to pass around your Context among participants, you may find yourself creating some kind of Contants kind of class in order to define your Context’s keys.

If you use jPOS-EE-SDK component model, you may find yourself creating a lot of those. distributed among different files, etc. and your code has to extend or implement many different interfaces in order to access them.

I found a very simple solution. as part of jPOS-EE eecore module build, we search for *.k files and create a single org.jpos.ee.Constants file that you can rely to be there.

So you write things like:

Context.k

  public static final String REQUEST = "REQUEST"
  public static final String RESPONSE = "RESPONSE";
  public static final String TERMINAL = "TERMINAL";
  ...
  ...

ErrorCode.k

  public static final String OK = "ok";
  public static final String INVALID _ISSUER = "invalid.issuer";
  public static final String INVALID_TERMINAL = "invalid.terminal";
  ...
  ...

that would create an interface org.jpos.ee.Constants like this:

package org.jpos.ee;
public interface Constants {
  public static final String REQUEST = "REQUEST"
  public static final String RESPONSE = "RESPONSE";
  public static final String TERMINAL = "TERMINAL";
  public static final String OK = "ok";
  public static final String INVALID _ISSUER = "invalid.issuer";
  public static final String INVALID_TERMINAL = "invalid.terminal";
}

We do the same with *.p files, we create a single org/jpos/ee/Constants.properties, so you can write something like this:

#
# defined in modules/mymodules/src/org/jpos/myapp/MyErrors.p
#
ok = 00 APPROVED
invalid.terminal = 14 INVALID TERMINAL
...
...

There’s also a handy class called org.jpos.ee.K that implements Constants and give you access to the Constants.properties ResourceBundle by using code like this:

  String message = K.get (K.OK);  // would give you a "00 APPROVED"

PS.- Sorry to disappoint you… no fancy doclet processing here… this is just a very simple build patch that happens to do what I need. I hope you find it useful.