/by apr/ I have been introduced to Strohalm NGO and the Cyclos project a long time ago by Todd Boyle but today I have been honored by a courtesy visit of Cyclo's project lead, Mr. Hugo van der Zee. I've seen an impressive demo of the upcoming Cyclos3 and Hugo was introduced to jPOS and miniGL. We found many areas of collaboration:

• Cyclos is going to support [m]POS transactions. jPOS is a natural fit there.
• Cyclos has its own internal ad-hoc accounting system. They will seriously evaluate the posibility of moving to the more generic miniGL.
• Both projects are highly aligned regarding the tools we use, the license we use and complement each other pretty well.

Hugo and I will be working in the integration but we are also looking for an skilled jPOS developer in our area to work full time in it (interested parties please contact us). Besides the technical aspects of Cyclos and jPOS, their implementations of community currencies are amazing and something really good for weak economies. Hugo has a background in economics and I was lucky to get a first-hand explanation of the rationale behind them. I was proud to know that our government through our major bank BROU sponsored by EMPRETEC are actively supporting an implementation here. I´m sure the collaboration and integration will be good for both projects, so Welcome Cyclos!.

/by apr/ As a follow-up to the recent post about miniGL layers we have removed support for foreign amounts at the transaction.entry level, foreign currencies are now handled in their own layer. That means that if you have a checking account and a savings account (we usually figure out the account type based on the content of the processing code field) in multiple currencies, you don´t need a separate set of accounts (one per type), the same account can hold transactions in multiple currencies. As mentioned in the previous post, we use layers to deal with pending versus real transactions (think pre-auth/completion) and we found an easy way to add multi-currency support by defining a PENDING_OFFSET constant. We are still working in the layers plan for our jCard system, but as an initial take, we have defined the PENDING_OFFSET=1000 and we store transactions in their corresponding layer using the iso4217 currency code, so e.g.: we store real dollars in 840 and pending dollars in 1840 (same goes for other currencies). So far the new setup looks extremely simple and straightforward. A close friend and CPA has contributed a very nice idea to the mix, conversion layers. I´m still not sure if we want to handle them with the existing database schema or we want some supporting tables for that, it has been good food for thought for now.

here is a very nice article by Andy about implementing an ISOPackager. Highly recommended if you are new to jPOS and you are trying to figure out how to connect to a remote host.

/by apr/ I´ve added a new feature to miniGL: Layers.

This new feature is designed to support multiple balances for a single account, such as available versus accounting balance.

We could use some flags for unsettled transactions, or pre-auths waiting for completion, but with this new layers support everything gets more simple, reusable and IMO elegant. Imagine a simple ATM withdrawal transaction:

(both liabilities as seen from an issuer perspective, fees not included here for simplicity)

Sounds very nice, but we have a problem, this transaction is still unsettled until we get a batch close or completion transaction, so if we don´t have this new layers feature, we would end up having either some kind of flag or duplicating accounts, i.e:

• Cardholder´s checking account
• Cardholder´s checking account (pending)
• ATM Network account
• ATM Network account (pending)

With our new layered approach, we post real transactions to layer zero (ground) and pending transactions to say layer one. When the transaction gets settled at the end of the day, we just reverse the effect of the transaction in layer one (blue) and post it to layer zero (black), e.g, when we get a pre-auth, we could post:

Pre Authorization

(In this example, '1' would be the 'pending' layer).

Completion

(Now it´s confirmed, we "ground" it)

I´ve modified the existing rule implementations in order to support this new layers feature, e.g. the DoubleEntry rule (that verifies that debits equals credits in the reporting currency for a given GLTransaction) now accepts a list of layers to check, so we can be very strict in some layers (such as the ground layer aka the real deal) while more relaxed in other ones. minigl.dtd has been modified in order to support a new <layers> element in rule definitions.

Some other uses for this include data-entry application where a junior clerk could post transactions to a given layer for later verification, then someone else with enough karma to authorize the transaction would "ground" it. We can use this feature to track "budgets", "cost centers" or just to ease some rule implementations (e.g.: we can have minimum balances layer, a max balances layer, and so on).

The layer number is arbitrary to a given miniGL application. On multi-currency systems, we use the currency ISO number as the accounting layer for a given currency.

When you ask for a balance for a given account at a given journal, miniGL gives you the ability to get the balance for a set of layers. This comes very handy when computing accounting versus available balances in ATM and POS transactions. You ask getBalance(journal, account, 0) and you get the accounting balance. You ask for getBalance(journal, account, 1) and you get the pending transactions (still unsettled). But if you ask getBalance(journal, account, 0,1) miniGL combines both layers to give you the available balance. We also use a third layer for overdrafts (used in credit card applications), say layer '2', so on certain transactions that would allow an overdraft (i.e. POS purchases), we could check getBalance(journal, account, 0,1,2).

I just hope the guy in the mail stamp up there is not twisting in his crave ... :)

/by apr/ For some time I have been playing with the idea of supporting a PAUSE action at prepare time in the jPOS transaction manager (think continuations), but it has some side effects related to transaction recovery, so it is still in the works. But I´ve added an easy to use and handy RETRY action that you can use while implementing your participants. If you return RETRY at prepare time, the TransactionManager will store your context in the persistent space and will re-queue it at regular intervals (default to 5 seconds, configured by a retry-interval property) back into the main queue. Imagine you have a system that connects to different remote processors and one processor goes slow or down for a while. Even if you are handling a big number of concurrent sessions, eventually all sessions might get locked waiting for responses coming from that particular endpoint. You could solve a situation like this by using multiple transaction manager instances (one per endpoint) but with this new RETRY thing, you can just RETRY the transaction at a later time (usually a few seconds later). You can place a retry counter in the context, or check the timestamp in order to avoid retrying the transaction forever. There´s an example in jpos6/modules/txnmgr/test/org/jpos/transaction/TestRetryParticipant.java.

/by apr/ Yesterday´s late afternoon, I had an unexpected and welcome IM call from my friend Rodolfo Pilas, he said he was there with Mr. Federico Heinz and they were keen to step by jPOS.org. Would you believe that? Interesting enough, I was aware Mr. Heinz was coming to speak at the JIAP 2006. That´s an event organized by government employed IT people. I would have loved to assist to Mr. Heinz presentation, but something very funny and weird happened to me last year with the JIAP 2005 event, so I said nah... I hate to speak at events (just because I get very anxious due to lack of practice) but last year, JIAP organizers asked the local Linux User Group about providing a presentation about local free software project initiatives, and they contacted me to speak about ours. Instead of talking about jPOS, I thought that it would be a good idea to speak about how we develop software in a distributed and collaborative environment, trying to map this to distributed government agencies with their replicated IT departments, reinventing the wheel on a regular basis instead of collaborating with each other. I said yes, but then the organizers though that talking at their event would somehow promote jPOS, so they thought it was a good idea to charge me! Hilarious. I asked for a printed and signed quote just to frame it and nail it at my office, but never managed to get one. I was told that the audience was mostly mainframe guys, I think that they really need to listen about how we develop software these days or they´d be lost, but yet the people that´s leading them are greedy and blind and driven just by money. Anyway, I did not assist to Mr. Heinz´s presentation yesterday, but was honored by his visit to our little jPOS project, it was amazing to be able to speak with a person of his caliber, and to get to know that he likes our logo! Thank you for your visit!

/by apr/ jPOS Spaces have proven to be very useful for us and I believe that they could be useful for others too, but adding a full jPOS dependency may prevent its use by other projects, so I did some minor surgery in order to remove a few dependencies and I've created a minimalist version of it here. If you think I'm doing this just to test the new exciting Google Code hosting you are wrong, but I have to admit that it was the trigger... I couldn't resist to give it a shot :) A note to jPOS users: You don't need miniSpace, you have it inside jPOS. I believe that we can benefit from external feedback from people using miniSpace - we will port improvements made in miniSpace-land back to jPOS-land as we see fit.

/by apr/ We recently went live on yet another instance of a jPOS based application called OLS.Switch, and after several months working with the OLS team we reached over 1000 iterations. At the same time, we see a lot of people in our mailing lists, new to jPOS, sometimes new to payment systems, and still facing a deadline in say ... one week (two weeks for the pragmatists). I consider myself an average programmer, but I've been exposed to payment systems for over 15 years, and I wrote jPOS from scratch, and the OLS team has tremendous experience in this area, and we still need to work month after month, iteration after iteration in order to get ready to go live. Am I missing something? Is this just because I don't use an IDE? Hmm... I doubt it. Andy (OLS' CTO) put it in a very nice way in his blog.

by apr on certifications

A recent post in the users' mailing list has triggered this post.

The post goes something like this: "The problem was they where modifing this server (it's a test server) and that's why I didn't get anything." Sounds familiar?

This happened to me dozens of times.

These people think they are smarter than us developers, so they use our time to test their systems, and they hide behind their big names. I can imagine they say something like "hey, let's test this new patch that handle our latest features with the next stupid programmer that needs to certify".

They do test driven development, but the problem is YOU (developer) are the tester, and by the way, you don't know that.

They hide behind their big brand names and you get to listen things like "Your system has to be failing, our's process a massive amount of transactions every single day, we just can't afford to go wrong".

And that's very true, their production system, installed turn-key by their solutions provider actually works (until they start messing with it), but the little crap that they have put together for your tests, running some bogotified version of the original software with some spaghetti-patch to support the latest feature recently requested by the marketing division never worked before.

It would be okay if they are honest and tell you "Listen, test with this proven certification environment, and then, if you don't mind, we would like to run a couple of tests in our new system".

That's fair, you usually need a little bit of help during certification and it's very nice to provide some useful feedback, but the problem is they usually don't get to acknowledge their system has never run before until you spend a week, testing day after day, frustrasted against a wall.

UPDATE: the previous title was rude so I changed it to BCFH (based on BOFH, C for certifier)

/by apr/ This time we got it right! I've tagged a v1_5_2 version and moved the version number to 1.5.3, but while working on these major build system changes I thought it was time go up to 1.6.0. We'll refer to jPOS 1.6.x versions as jPOS 6 and its svn repository is https://svn.sourceforge.net/svnroot/jpos/trunk/jpos6/ I was thinking about doing these changes on the current 'jpos' directory, but looking further into the work we have ahead, it seems like it will require several days or weeks to have everything migrated to the new environment, so a 'jpos6' temporary directory seems like the way to go. Once we are ready to release 'jpos6', we can get rid of the older versions in 'trunk' (it will remain available in tag/v1_5_2/*) I'm committing a basic installation there with just a the main 'jpos' and 'q2'. The nice thing about the new layout is that we don't need conditional compilation anymore, if something requires some extra library, it will be distributed in its own module. I will update the README and INSTALL files as time permits (help is welcome), but to get an idea of where we're going, you may want to read the first chapters of the jPOS-EE SDK guide. If you want to stay up to date with the latest commits, you can subscribe to the SVN notifications list (send e-mail to jpos-commits-subscribe at jpos dot org). This time we got it right! (you've got to read that piece, it's so funny and sad at the same time that everything there is sooooo true...)