|
Test Data Queue Applications Using Java
by Kevin Vandever
[The code for this article is available for
download.]
If your Java applications need to access iSeries resources, the IBM iSeries Toolbox for Java
is an excellent way to accomplish
that. The toolbox is so robust that it has become an extension of OS/400 itself. You name the iSeries
resource, and the toolbox probably has a Java class to access that resource. In fact, it was while using such
a tool, which I extracted from the toolbox simply to help me test data queues, that I thought, "Hey, if this is
helpful to me, maybe others can benefit, too."
You Have Choices
In "Calling a
Program Using the iSeries Toolbox for Java," I explained how to call RPG programs using the toolbox.
This is one of the many ways to access iSeries resources. My shop uses that particular technique in
production and it works very well. Another iSeries resource used extensively in my shop is data queues.
We use them to communicate between iSeries machines, to trigger jobs, and to transport data to and from
our Web site.
Regardless of the project, it is often necessary for the programmer to put and get dummy entries to and
from a data queue for testing purposes. Countless times, I've witnessed programmers writing programs to
handle this task. If you own Jim Sloan's TAA Tools, there are commands (SNDDTAQ and RCVDTAQ)
that can be used to test your data queues. However, while searching the vast vault of toolbox classes one
day, I stumbled on some sample Java source code that displays a GUI form to allow you to read from or
write to an iSeries data queue. I immediately downloaded and tested it and, sure enough, it worked. This
isn't a specific tool marketed by IBM; rather, it is an example of how to use a couple of toolbox classes--
AS/400 access and data queue access--and a couple of Java GUI classes--Swing and AWT--to display a
simple form and either read from or write to an iSeries data queue.
Is there an advantage to using the Java GUI technique over its iSeries counterparts? Maybe not. However,
if you don't own TAA Tools, you are more comfortable with a GUI environment, you deal with multiple
iSeries boxes, or you just think it would be cool to test any data queue in your iSeries network from a GUI
on your desktop, check out the example provided by IBM and give it a whirl.
It Pays to Read the Doc
I have included the sample source code DataQueueDocumentExample,
which I found in the free Java
Toolbox download documentation. The first two import statements import classes from the iSeries Toolbox
for Java. The latter three are to include core Java classes that allow for GUI creation. If you follow along in
the code, you will see that three private, static objects are created. The first is the actual document object
that will be displayed on the screen. The second is the text field object that will contain the data read from
or written to the data queue. The third object is a Boolean object and will be used to determine whether a
data queue read or write was requested from the command line. The next block of code is used to determine
if the correct number of parameters was entered on the command line:
if (args.length != 2)
{
System.out.println("Usage: DataQueueDocumentExample
system read|write");
return;
}
This is the standard method for handling command line input errors. If two parameters, separated by white
space, are not entered on the command line, the Java source will display to the screen the constant "usage,"
followed by the name of the class and the list of parameters. In this case, the Java application is looking for
a system name or IP address, and either read or write. Next, the Boolean object, rw, is set to true if "read"
was entered as the second parameter on the command line. Otherwise, it is set to false. The parameter index
starts with zero (0), which is why the number one (1) indicates the second parameter. The next line creates
a String object called mode and instantiates it with the Boolean value of rw. Then, instead of using
true/false as the Boolean values, the syntax ? "Read" : "Write"; replaces "true/false" with
"read/write." Therefore, if rw is true, mode will be read, and if rw is false, mode will equal write. Pretty
cool, huh? Java's an extremely hip language.
Try
Take a look at the logic within the try braces ({}). First, the Java application is going to create a frame
object for our document. The frame will contain a heading and tell what mode the document is in. Next, an
error dialog adaptor object is created and will be used if an error is encountered. Then a cursor adapter
object is created. This object will be used to keep track of where you are in the data queue after an entry is
read or written. For you SQL buffs, think of the cursor adapter as you would a cursor in an SQL result set.
You can also think of the cursor adapter as you would a file pointer in DB2 UDB. Now it's time to create an
AS/400 object.
The AS/400 object can handle zero to three parameters. The three parameters are system, user ID, and
password. In this example, it accepts the system from the command line, and since the other two
parameters are empty (null), you will be prompted for them when you call this Java application.
The following code is used to create a path name object that will contain the AS/400 IFS path name for the
object provided in the parameters. The object accepts the library, object name, and object type and will
return an AS/400 IFS path name. You will replace the first parameter, where I have “LIBRARY,” with the
library that contains your data queue. The second parameter, where I have “OBJECT,” will be the name of
your data queue, and the last parameter where I have “OBJECT_TYPE,” will contain *DTAQ.
// Create the data queue path name.
QSYSObjectPathName dqName = new QSYSObjectPathName
("LIBRARY", "OBJECT", "OBJECT_TYPE”);
If you already know the AS/400 IFS path name, you can skip this step and enter the path name in the next
step, which is to create the data queue object.
To create the data queue object, you need the AS/400 system object created earlier and the AS/400 IFS path
of the data queue. The Java application then checks if the data queue exists by attempting to create it using
the create method. If it exists, the catch logic will trap the error and, in this case, ignore it because it most
likely states that the data queue already exists. Below is the code that accomplishes this:
// Make sure the the data queue exists.
DataQueue dq = new DataQueue (system, dqName.getPath ());
try
{
dq.create (200);
}
catch (Exception e)
Data Queue Document
Now it's time to instantiate our data queue document object, dqDocument, with our specific system and
data queue. Once that is done, the addErrorListener and addWorkingListener methods are called, passing
our error handler and cursor adapter objects created earlier. Then we instantiate a text field for our
document and initialize it with 40 spaces. This entry will depend on the maximum length you defined in
your data queue and whether you want to initialize with some actual text or blanks.
The next line of code determines whether to make the text field an editable field. In this case, it will do so if
the rw value is not true. Remember that rw was set to true if "read" was entered on the command line. So
this text field will be editable if rw is not "read," which means it is set to "write."
Next, a new button object is created and labeled with whatever is contained in mode, which will be either
"read" or "write." Then the button object's addActionListener method is called to create another method to
process the button when it is clicked by the user. In this case, if rw is true (read), the read method is called
from our document object. If rw is false (write), the write method is called. You can call other document
methods here, depending on what you want to do. For example, there is a peek method, which allows you
to read the data queue entry without removing the entry from the queue. The read method used here
removes the entry from the queue once it is read. The peek method is helpful when you want to reuse the
queue entries. Note that you can enter a wait parameter that will tell the application to wait for a given
number of seconds or indefinitely for a queue entry before processing the next line of code.
The next bit of code is a method definition that tells the application to exit if the document is closed. Now
that the objects have been instantiated and the methods defined, it is time to lay out the document frame
and display it to the user. To run the Java application, type the following from a DOS prompt or your
Command Shell inside CODE/400. (Note that you will only type "read" or "write" on the command line,
not both. The read|write below signifies that you will enter one or the other.)
java DataQueueDocumentExample your_IP_address read|write
A GUI prompt screen will first appear to allow you to enter your user ID and password. If you entered
"read" at the command line, you will see the following:
If you entered "write" at the command line, you will see the following:
Test Away!
Will this little tool change the world? Probably not. However, it is a nifty little testing instrument you can
use to write to and read from data queues on any iSeries in your network from the comfort of your desktop.
It also allows you the opportunity to play with the iSeries Toolbox for Java and Java itself and to learn how
they work. For information on installing and configuring Java and the Java toolbox, refer to "Calling a Program Using the
iSeries Toolbox for Java." Future articles will cover more toolbox topics, but for now enjoy this one.
|
