When we were selling and demonstrating payment switch applications back in the 1980s and 1990s, one of our laments was that these applications “just don’t demo well.” We were working predominantly on ‘specialty’ (Read: Tandem and Stratus) architectures at that time. While these systems excelled at continuous processing, getting real-time visibility into the current status of your application was another matter. This lack of visibility got more noticeable and acute as graphical computing took off. By contrast, legacy applications like ON/2 and BASE/24 looked like they were moored in the green-screen era. Of course, you could always go out and buy a third-party product to give you visibility. For example, in the Stratus marketplace, my good friends Eran Mertens of Application Resources and Coby Schanz of Softmark offer some great products to augment Stratus-based applications.
By contrast, with jPOS the goal of real-time visibility is embedded right into the project framework. You can read about it in the jPOS Programmers’ Manual in Chapter 14. Alejandro introduces the jPOS UI there, noting that it “is a very simple and lightweight UI layer that enables you to write reusable UI components and easily assemble them by using a QBean configuration file…it can be embedded in standalone applications or used inside Q2.”
In this post, I want to give you a feel for what the UI looks like when implemented into a fully-envisioned jPOS application. Rather than describe the UI in words, I’ll simply show you a couple of screen shots.
Here’s a transaction ‘List’ screen, updated real-time. You can use hyperlinks embedded in the display to isolate traffic from specific stores, or from specific terminals within stores. Note that we display transaction duration (‘Dur’) in milliseconds and the number of transactions outstanding in the incoming queue (‘Out’). This screen gives you immediate knowledge – are transactions flowing? Do transaction durations look ‘normal’? Is there a queue backup? Note also that the screen can be placed into ‘auto-refresh’ mode (we have the default set to 30 seconds).
You can also click on any of the transaction IDs, which are also hyperlinks. That does a ‘show’ of the transaction. This screen is pretty self-explanatory – you get visibility to most of the data columns in the tranlog associated with this particular transaction ID. This transaction was performed in a test environment where we had the ‘Audit’ flag turned on for this terminal location. As a result, we’ve captured the entire raw data request and response. For testing and certification, that’s invaluable stuff.
This system ‘Status’ screen shows you the current status of all components of the application. jPOS uses a very intuitive red/yellow/green light implementation to display the status of each application. For a little background on how the ‘status’ feature operates within jPOS, first take note that we have a ‘status’ table defined as follows (one row for each configured system component):
id varchar(32) not null,
name varchar(255) null,
state varchar(8) null,
detail varchar(255) null,
groupName varchar(32) null,
lastTick datetime null,
timeout numeric(19,0) null,
timeoutState varchar(8) null,
expired tinyint null,
maxEvents int null,
command varchar(255) null,
validCommands varchar (255) null,
primary key (id)
The status subsystem works in a passive way. Each status entry is 'touched' from the system component that controls it. Each component has an associated timeout. If a status entry has not been touched within the given timeout period, then somebody needs to move that entry from its current ‘OK’ status to the destination error condition (e.g., WARN, CRITICAL, OFF, etc.). When a jPOS UI user hits the status page, we run that check on all entries; but if for some reason the users are not looking at that page, we need a way to check all statuses and move timed-out entries to the specified error condition. 01_status_heartbeat (an entry in the ‘deploy’ sub-dir in our jPOS implementations) is in charge of that.
Here’s a fourth screen that shows displays a ‘Store’ configuration.
There’s no limit to what you can do with the jPOS UI. You can provide visibility to any aspect of your implementation.