During the course of configuring software, you occasionally run across an option that invokes the response "Cool!" immediately followed by the question "How would I use that?"

This scenario happened to me when I configured my first Client Access Express emulation session back when Moses was a child. What I found was definitely a nice feature, but to me it was a solution waiting to find a problem.

If you are responsible for software development at your company, if you have lots of perfectly good green-screen applications running, and if you have been charged with the task of "updating" (read Web-enabling) these programs, then read on. In this article, I'll describe the option that gave me the "deja-huh?" experience. No, it won't automatically Web-enable your applications, but it will help integrate the two technologies.

The Solution Gets a Problem

One project with which I've recently been involved is document storage. This is an old problem that has been solved many times over by commercial software. The trouble with many of the commercially available products is that they are either too expensive (Where do they come up with those prices?), too complex, or too bloated for the task at hand. For example, IBM's ImagePlus is a great product, but it is better suited to applications in which it is going to replace paper in a workflow, such as in an insurance company. It's simply too complex, and perhaps too expensive, for many installations. The requirements at my company are much simpler. We need to scan the documents, store and index the resulting image files, and then view the image on any PC workstation. Naturally, all of this has to be done on the cheap.

Scanning the documents is simple. We use the eiStream WMS, Inc. (formerly Eastman Software) Imaging for Windows Professional program and an IBM document scanner to scan the images. eiStream supplies ActiveX controls so that the program can be automated. Preferring not to use a language such as VB to do the automation, we turned to J-Integra, a wonderful product by Linar Ltd. J-Integra builds Java classes as a wrapper around the ActiveX controls, allowing manipulation of Imaging Professional from a Java program. We wrote a fairly simple Java program to connect to our AS/400 database; it builds and presents a list of document types to the users, and ,once they select a type, it controls Imaging Professional and the scanning process. The scanned image files are stored on an AS/400 NetServer share called 'IMAGES', which points to the IFS directory '/images'.

For each of the scanned image files, the Java program adds to the AS/400 file a record that contains the file name, its document type, and a data link entry. We took advantage of the DataLinks feature of DB2 UDB for AS/400 to manage the image files on the IFS of the AS/400. DataLinks extends DB2 so that files that appear in the IFS can become integrated with the normal database simply by using an SQL function. Part of the integration includes transferring ownership of the files to the system. This prevents accidental deletion and facilitates intentional deletion of the image files. Further information about DataLinks can be found in the IBM Redbook DB2 UDB for AS/400 Object Relational Support (SG24-5409), available at http://www.redbooks.ibm.com/.

The images themselves are stored in tagged image file format (TIFF). Experimentation showed that, in our application, this format gives the best compromise between image quality and file size. The fact that this format allows for multiple images in one image file is a plus.

Once the images are stored on the AS/400 NetServer and are catalogued in the database, they need to be indexed. In our case, we index images by an account serial number and possibly a membership number. This is accomplished with an AS/400-based Java servlet and a browser on the client. Although the actual document scanning is limited to the PC on which the scanner is physically attached, the use of a servlet permits anyone with a PC and a browser to index the scanned images. Thus, no costly client software is required! In fact, the only thing needed in addition to the browser is a plug-in capable of displaying TIFF images. For this, we turned to AlternaTiff, a freeware package from Medical Informatics Engineering, Inc. Each image is displayed in turn in a browser window, along with text fields into which the user enters appropriate key data. When the user clicks on the "okay" button, the information is written back to the AS/400 database, the key data is verified and, if it passes muster, the image is flagged as "indexed." Then the next image is presented. Errata are sent back to the user for correction and resubmission.

The point of all of this effort is to have the images available for viewing from any appropriately configured PC. To do this, we use IBM's HTTP Server for OS/400 (which soon will be replaced by the Apache Server for OS/400) to serve up the files when requested. For our network, a request to http://images/images/filename.tif will get filename.tif served to the browser. The first "images" in that URL is an alias for our AS/400. I designed it so that, should I ever wish to move the Web server to another machine, I can simply change the DNS entry in our DNS server to point to the new machine. No change to the image database will be necessary.

The naming scheme for the image files is rather simplistic. Its form is YYYYMMDDssss.tif where YYYYMMDD is the year, month, and day the image was scanned and ssss is a four-digit sequence number that gets reset with each new day. Although this naming scheme makes it fairly easy to organize images by age, it leaves much to be desired for retrieving an individual image. Creating a WWWBRWS file in '/images' will allow the user to browse that directory containing the images. But the resultant user confusion would be highly undesirable at least, and just plain rude at worst. A much better alternative, naturally the one that we took, was to create a Java servlet, entitled QueryImages, that returns a list of images and their descriptions for a given account serial number or membership number. Thanks to the excellent design of the HttpServlet class, it was quite easy to do.

If you've ever been on the Internet and used a site's search function, you've undoubtedly noticed URLs that look like this:"http://somenode.com/somethingHere?someVar=someVal&someOtherVar=someOtherVal". The text that follows the question mark in the URL is comprised of parameter names and values that are available to a CGI program or Java servlet. In this example, the two parameter names are "someVar" and "someOtherVar," and the associated value for each is "someVal" and "someOtherVal," respectively. In our application, I use the parameter names "S" to represent the account serial number and "M" to represent the membership number. Figure 1 shows a snippet of Java code that extracts the parameter names and values. These values are used to determine which subsequent routines must be called to build lists of images that match the given criteria. Notice how easily this is accomplished with Java. The parsing routines are already done in the HttpServlet class. An equivalent CGI program written in RPG would be much more complicated. I'm using Tomcat to run the servlet and have mapped the name "QI" to "QueryServlet". To get a list of images available for a given serial number, say 726, and a given membership number, perhaps 255, the user need only enter into the browser the URL "http://images:1414/QueryImages/QI?s=726&m=255"; he'll be presented with a list of images from which he can select.

Figure 1: This Java code shows how to extract parameter names and values from a URL. It is extremely simple using the HttpServlet class.

Right now, you're probably thinking that this solution is quite inelegant. And you're right. Besides the obvious awkwardness involved in having the user type in a URL like this, there are other problems, too. What if the user doesn't know the required account serial or member number? In our shop, an account can be accessed by account serial number, account number (which is different from account serial number), name, phone number, membership number, or any of a host of other more esoteric identifiers used in our business. I could take the time to write a servlet that would allow the browser to do lookups, but that's totally unnecessary. I've got green-screen applications that have been running since 1985 that do lookups very well. In fact, most of the time, an image would be useful only after the green-screen information was read and digested.

So that leaves two options: Either I can have the user transcribe the account serial number to his browser, forcing him to type that intimidating URL for each inquiry and earning me his eternal enmity, or I can rewrite the green-screen applications so that they are Web-enabled--maybe even completely dumping all of the old code and replacing it with Java servlets or applets. That option certainly wouldn't be expedient. And it would undoubtedly earn me the eternal enmity of the CEO, since it would be an expenditure that would end up in a lateral move without obvious benefits.

Fortunately, there is another option: Client Access allows me to bolt the new Web-based image inquiry application onto the existing RPG-based green-screen application. If you refer to Figure 2, you'll note a button that appears in the middle of the screen.

 

Figure 2: The button appearing in this green-screen was created by Client Access. The text within it was supplied by the RPG application.

Closer inspection of that button will show that its text contains a URL that is formatted properly for submission to the Web server. If you examine the screen closely, you'll note that the parameter value for "S" is the same as the serial number of the account. Also, the value for "M" is the same as the membership number on the account. That text was placed in a 78-byte, output-only text field by the green-screen application.

The appearance of the button is a contrivance of Client Access. With the proper options set in the emulator window, Client Access will create a hotspot wherever it finds text that can be identified as a URL, which for this purpose IBM identifies as anything that begins with the string "http://". Clicking on this hotspot will cause Client Access to launch the default browser, passing to it the URL contained within the button. The appearance of the hot spot as a 3-D button is optional. You can have it appear as normal text and it will still work the same way, but I believe that the appearance of the button makes its function more intuitive.

To enable this feature, you need to be in an emulator window. Once there, simply click on assist->hotspot setup and check the boxes as shown in Figure 3. Be sure to save your changes if you're working with a previously saved configuration. If you're making these changes while creating a new configuration, you'll be prompted to save it when you attempt to close the window.

 

Figure 3: Enabling URL hotspots is as simple as checking "Execute URL." The 3-D button version is enabled by checking "3-D Buttons."

Hotspots Are Hot

As you can see, the "URL Hotspot" feature of Client Access is a simple solution to a problem that confronted me. The modifications to my green-screen application took less than an hour to complete and were accomplished with minimum fuss. I intend to do all future development as Web-based applications and, with this feature, I can graft the new functionality to the existing software. So I get the best of both worlds.

I hope that this article will inspire you to try your hand at Web development now that you have the URL Hotspot in your bag of tricks. At the very least, I hope I've solved one of those mysteries of computing, leaving you to say, "So that's how I'd use it!"

Barry L. Kline is a consultant living in central Pennsylvania. He can be reached via email at This email address is being protected from spambots. You need JavaScript enabled to view it..