Working with jPOS

jPOS is an open source library for handling ISO8583 financial messages. A prime issue I've had is that the environment requires a little customization for handling the implementation of the standard and how to get these changes incorporated into its built in server. Finally I've resolved this by having a separate project for building a JAR that can be included into the lib folder for the jPOS source project which I then run by using the included ant file. The only change then required is the inclusion of the specific configuration files that are then needed within the deploy and cfg folders.

Getting to SWIFT

Image by ucumari via Flickr

SWIFT has been a background idea. Ultimately what is needed is a means of generating a message with known input as well as checking a received message against some expectations. After running into WIFE last year I figured that the process was imminently simplified. Time, however, can be a nasty thing.

With two projects boiling away with furious vigor, it has become time to get the basic SWIFT message validation tool written. This is not due to father time having changed his ways but both systems I'm working with showing an impending need for it.

I must say there's been an auspicious start... the OS library hadn't been touched in a while. Not much to fear though since SWIFT doesn't change all that often. False confidence on my part. After popping a sample into Eclipse all that would return was a simple class not found error.

Yay for open source in that I could pop the source into a project and try figure it out. Turns out that there was a dependency on Java 1.4. Ultimately a simple update to the Java version and the classes can no longer hide from the compiler.

So now I just need to figure out how the library works... It would probably help to get a good understanding of how SWIFT messages are put together before doing this, but the clock is ticking. Heck now that I have undone my assumption that the newlines between tags within the message fields are simply there for readability the way forward is looking almost too good to be true.

Spinning a JavaSpin field with QTP

Image by Tonyç via FlickrSometimes its good to be reminded that there are things out there that simply just don't want to work. These always present a challenge. The most recent example is a simple case of a Java application with a spin button for selecting the time with the obvious requirement of being able to set a value. Hmmm...

Spin fields are created as a combination of a couple of buttons inside of an edit field. Rules are then applied to the buttons in terms of their effect on the value. Rules also apply to the value itself. Simply though, there are 4 objects within this one field. The container which is the spin control. An edit field for the value. A button for increasing the value and another button for decreasing the value.

QTP was not happy. There is a Set function that works on the spin object and should set the value of the control. Now while GetROProperty("value") works, the Set function does not. It actually would have been nice for it to have failed with an error rather than doing nothing.

Another simple option also exists... set the edit field to the value. This would have been great except that the Set function for the edit was reported as being invalid - the joys of a composite Java field.

Since every specific object in QTP is simply an extension of the object type, it would seem reasonable to try switching to that level. Another failure. The object can be found but setting the value results in an invalid method failure.

Well ultimately setting a value simply requires that the object be activated and then a Type should work. Now QTP does not provide activate functions for all the Java objects. Not a big deal as an activate is the same as a click on the object.

Ha! Not this time. The click function, which is nothing more than a simulation of a mouse click would not activate the spin field. This was a weird one. Seriously surreal.

OK. Going back to the spin control. QTP provides functions for Next and Prev values. I know already that running these functions does not change the spin field - probably just as well as I would probably have been able to set the hour but would have been unlikely to have accessed the minute field. This exploration did however show a flicker in the field.

Regardless of testing you work in, noting any effect/flicker/change in the application is essential. This flicker lead to the solution... as weird as it turned otu to be.

The solution involved the following:

1. Run the spin object's next function
2. Send a home keypress to the window by typing micHome to the Java window object
3. Type the value to be captured to the Java window

This worked great... on one field. Testing against the second spin field on the same page resulted in more weirdness. The value "2121" was being typed as "121n" (where n was the original value at that position). Running the test code twice though, captured the value correctly. I checked this bizareness three times and in each case, the first field was perfect the second was not.

The implication was to obviously run the type portions twice against the spin field. So the final solution turned out to be:

1. Run the spin object's next function
2. Send a home keypress to the window by typing micHome to the Java window object
3. Type the value to be captured to the Java window
4. Send a home keypress to the window by typing micHome to the Java window object
5. Type the value to be captured to the Java window

Its interesting that most solutions to seemingly intractible problems are actually extremely simple. Pity that they're not obvious.