VISA Business Enhancements

/by apr on kudos/ The jPOS team @ CS has certified the new VISA Business Enhancements April 2008 at one of our jPOS sites today and is working on a second site. This is not a big deal and not worth a blog post, but we got word that this is the second site in Latam to be ready to go. Congratulations!! The CS guys have a solution that works even for non jPOS customers (simple jPOS based bridge between the customer’s main system and VISA’s VAP to handle the required message format changes). Feel free to contact them if you want further information.

Trust but verify your version number

/by apr/ Reading the Payment Systems blog I came accross this other excellent PCI answers blog. After reading Trust but verify your POS system I got to re-read the list of validated payment applications. The PABP requirement #1 clearly says: Do not retain full magnetic stripe, card validation code or value (CAV2, CID, CVC2, CVV2), or PIN block data. I’m working on several jPOS systems that connect to some of the systems listed there and it’s nice to see incoming 220s and 420s with lovely data elements 35 and 45 from time to time. Those are SAF-ed messages and I wonder how the hell they manage to not store sensitive data on disk, not even in encrypted form, but they are still able to send it over in store and forward messages that sometimes arrive at our end a couple of days later when our test platform is not active.

<isomsg direction='incoming'>
  <field id='0' value='0420'/>
  <field id='2' value='411111_________1111'/>
  <field id='3' value='012000'/>
  <field id='4' value='000000000100'/>
  <field id='7' value='0107193917'/>
  <field id='11' value='000043'/>
  <field id='12' value='153839'/>
  <field id='13' value='0107'/>
  <field id='14' value='____'/>
  ...
  ...
  <field id='22' value='901'/>
  <field id='25' value='00'/>
  <field id='28' value='C00000150'/>
  <field id='30' value='C00000000'/>
  <field id='35' value='**411111\_\_\_\_\_\_\_\_\_1111=\_\_\_\_\_\_\_\_\_\_\_\_\_\_**'/>
  ...
  ...      
</isomsg>

I think the PABP list is nice, but it will take a lot of time to get customer sites upgraded to PABP compliant versions of the products mentioned there. The customer have a false sense of security because their provider is listed there, but the version they are running is not that good. Bottom line, Trust but verify your POS system but also verify your acquirer’s software version number.

Payment Systems Blog

/by apr on recommendations/ My friend and jPOS developer Dave (CISSP, CISA) has a new blog: Payment Systems Blog We are working with him, Andy and the OLS team in some changes to jPOS-EE and their OLS.Switch required for PABP certification (actually they are doing most of the work, which is great, I will just take care of merging the results back to the jPOS-EE codebase). I guess users reading this blog may have tangential interest in it.

YAGNI

/by apr/ For those of you thinking that your special application needs an extremely high performance engine, and you are not sure if jPOS can handle it, here is a nice post that basically says in a polite way that probably YAGNI!. When you ask if jPOS can handle your load you actually need to ask yourself if the business logic and database access strategy that you are going to put in place on top of jPOS can really handle it.

AGPLv3

/by apr/ The Free Software Foundation has released the GNU Affero General Public License (AGPL v3.0), a license we’ve been waiting for a long time that will allow us to open source more code such as the jCard (our Card Management System) and jPTS (an ISO-8583/2003 based jPOS Transaction Switch) projects. We plan to upgrade all our licenses to AGPL v3.0. What does this mean to you?

  • If you use jPOS as part of an open source project, you can check this Compatibility Matrix.
  • If you are an existing sponsor or contributor, nothing changes, you’ll be entitled to get a waiver
  • If you use jPOS commercially and you are neither a contributor nor a sponsor, you should raise the issue to your managers and have them contact us

Only 10 times bigger

/by apr on propaganda jPOS speed/ While reading about how Open Source is essencial to Paypal’s success I was impressed to see Paypal processes about U$S 1500 every second of every day and that’s only 10 times bigger than some of our jPOS sites running in a couple of Intel boxes and probably only 5 times bigger than The Gladiators’ upcoming system. BTW, I recently got word that a large financial institution (really really large) was using jPOS to test their own legacy systems and (with some changes to the ISOMsg class in order to pre-allocate fields) they managed to get 330k pack/unpack operations per second on a Sun 32-WAY system. Not bad, huh?

jPOS-EE setup HOWTO

/by apr When you first get to see jPOS-EE it looks like a puzzle, which is great for our business :) but you can find here very simple instructions to get you going with a basic jPOS-EE UI setup. The basic idea behind the jPOS-EE build system is that we have modules that get merged at compile time, enabling and fostering code reuse among different jPOS-EE applications. We have some standard modules (you can find those in the modules directory) and optional modules (those are in the opt directory). In order to create your application, you need to either copy or symlink selected modules from the opt directory and you obviously need to add your own modules. This step-by-step instructions use MySQL, you can use other RDBMS but we suggest that you get the system going with MySQL and then change it to use your preferred one.

  • Get jPOS-EE using subversion

    svn checkout http://jposee.googlecode.com/svn/trunk/ jposee

  • Copy or symlink the following optional modules into your modules directory:

    commons -> ../opt/commons
    eecore3 -> ../opt/eecore3
    eeweb3 -> ../opt/eeweb3
    hibernate3 -> ../opt/hibernate3
    hibernate3_mysql -> ../opt/hibernate3_mysql
    jetty6 -> ../opt/jetty6
    jpublish4 -> ../opt/jpublish4
    status -> ../opt/status
    status_ui -> ../opt/status_ui

  • Create the database and grant permissions
    You can review the file devel.properties and change dbname, dbuser and dbpass or you can pick the defaults for this little exercise, i.e:

     CREATE DATABASE jposee;
    GRANT ALL PRIVILEGES ON jposee.* TO 'sa'@'localhost';
  • Build jPOS-EE
    Call ant (you need a recent version of ant, we are using 1.70 but 1.6.5+ would do

  • Use a little Java or BeanShell script to create your DB and initial user
    You can use bin/bsh to invoke a Beanshell. If you are on Windows you may want to use cygwin or create yourself a BSH.BAT based on our unix based bin/bsh script and run:

    import java.util.; import org.jpos.ee.; import org.hibernate.*;

    DB db = new DB();
    db.createSchema (null, true);

    db.open();

    Transaction tx = db.beginTransaction();
    User user = new User();
    // user=’admin’, password=’test’
    user.setNick (“admin”);
    user.setPassword (“66d4aaa5ea177ac32c69946de3731ec0”);
    user.setName (“System Administrator”);
    user.grant (“login”);
    user.grant (“operator”);
    user.grant (“useradmin”);
    user.grant (“sysconfig”);
    user.grant (“admin”);
    db.session().save (user);

    tx.commit();
    db.close();

  • Start jPOS-EE
    You can either call bin/q2, move to the build directory and call java -jar jposee.jar or call ant run

  • Point your browser to http://localhost:8080/jpoeee

Customizing jPOS event logs

/by apr/ The first few things that new jPOS users want to do within the first five minutes after downloading jPOS are:

  • Build it in Eclipse/Netbeans/IDEA/<your -favorite-IDE-here>
  • Run it from a fifth-grade Java program with a lovely 10-page long main program where all components get initialized with hardcoded values for IPs and ports instead of using Q2
  • Get rid of our event log subsystem and use commons logging or log4j

If you don´t recognize yourself in the previous list, then you might be interested to know that we have a nice new optional module in jPOS-EE called stloglistener. I came across StringTemplate just a few days ago after reading Florin´s blog and decided to give it a spin. StringTemplate is just great and learning it is addictive. Besides my plans to use it in our JPublish applications (we are currently using Velocity) and some of our mail-sending stuff I decided to give it a quick run, and it came out to be a very nice addition to jPOS. Now you can fully customize jPOS logs using the new org.jpos.util.STLogListener. In order to use it, you need to install the stloglistener module (available in the opt directory of the jposee subversion repository) and add it to your logger configuration:

path is just the path to your template´s root directory (defaults to the cfg directory). skin can be either an ST group (*.stg) or the base path where you place individual *.st files (i.e cfg/myskin/org/jpos/iso/ISOMsg.st) Here is an example of the configuration of a LogEvent:

org_jpos_util_LogEvent(realm,date,tag,evt) ::= << ### $date;format=”dd/MM/yyyy hh:mm:ss.SSS”$ #############################
# $realm$/$tag$
# $evt:{ $it$$\n$}$

This creates less XML-ish logs with a line of hashes separating each log event:

### 25/08/2007 07:22:42.664 #############################
# org.jpos.simulator.TestRunner/results
# Echo Test [OK] 47ms.
Card not found [OK] 21961ms.
Invalid processing code [OK] 68ms.
Card ok - expiration mismatch [OK] 218ms.
Card ok - invalid account [OK] 460ms.

You can override how to render any component, just by adding a template for it. I tried a simple template for ISOMsg that would print the description of every field. Also tried a nice rfc822-like (mbox format) template that can be read by a mailer (nice to search, sort, etc.). You can easily create ANSI-coloured output, html output, protect some fields, whatever. ST works nice with Maps and Beans so we may have to add some getters to some of our classes in order to be able to customize them more easily. For example, I made org.jpos.transaction.Context.getMap() public so we could customize the output of the TransactionManager´s Context like this:

org_jpos_transaction_Context(o) ::= >>
$o.map.keys:{
k| $k$:$o.map.(k)$$\n$}
$>>

Just for fun, I made a VMS skin (told you this is addictive) up to the point that I´m consider turning on our old MicroVAX just to see if I remember my SYSTEM password (not planning on reloading VMS off 20 TK50 tapes… :) I invite you to play with it and contribute some skins. For those of you not familiar with the jPOS logger subsystem, the main difference with other loggers is that we give the log listeners a reference to the live object, which usually contains multiple log entries associated with a given transaction. The listeners can act as filters by returning a new or modified log event (and that´s how we can tweak the content to make it for example PCI compliant). I have some ideas for new uses for our new friend. I think we could serialize ISOMsgs in IMF format (you have an IMF, right?) using for example YAML, apply ST templates based on the destination endpoint and re-load them off YAML (all the operation can be wrapped in an ISOFilter which could be less dangerous to customize by an end user than for example our BSHFilter).

Space push

/by apr/ As of r2541 we have a new Space operation, Space.push. Space.push is similar to Space.out but places the entry at the head of the list. I tried hard to avoid adding new operations to the Space in order to keep it simple but The Gladiators Team found an extremely interesting use case for it. Under heavy load, when a transaction gets resumed, it competes with new incoming transactions in order to get its CPU slot, but this transaction has already competed once (at the beginning) and it’s unfair to have it on queue again. With the new Space.push operation (implemented in r2541) and changes to the TransactionManager (implemented in r2542) a resumed transaction would get priority over a new one. jPOS-EE has been updated with a binary version of r2542.