  |
|
|
|
|||||||
 |
 |
|
|
Data Entry Robots by Michael Sansoterra [The code for this article is available for download.] 
Sometimes undeserved credit can cause inflated expectations for future projects! I had just such an experience a few years back at a client's, after having a few simple successes that gave the impression I could do anything quickly. I was asked to load some data from a PC-based Microsoft Access database into an iSeries application. The amount of data (i.e., fields) was small, but the number of records was considerable and the expectation was that it could be done rapidly. I set out to learn the structure of the destination iSeries tables and populate them from the PC using ODBC. Unfortunately, I had major difficulties in populating the tables due to a large number of flags and counters that I just couldn't figure out how to set in a short time. The hourglass to complete the project was draining fast, and I didn't want to have to tell the customer to hire data-entry personnel. Another option would have been modifying the application's data-entry program to use my input files rather than the screen. It became increasingly apparent that I would have to heavily modify some RPG/400 code to use my input files rather than loading the tables directly. I pondered entering the data myself. Blast! If I only had someone to quickly enter the data. Just then the light bulb went on. I did have someone--or something. That something that could enter my data is the Personal Communications (PCOMM) terminal emulator package, which comes with Client Access (known as iSeries Access since V5R2). PCOMM is more than just a terminal emulator. It has a Component Object Model (COM) interface that allows Windows programmers to control its entire operation. Armed with this information, I was able to construct a computerized data-entry robot to read data from an Access database and enter it on the 5250 screen. Actually, my original program did nothing more than send keystrokes to the application's data-entry screen. For the most part this was fine, except that every once in a while a data-entry error occurred, which would send my data-entry robot into orbit because it kept feeding data to the emulator even though the emulator wasn't accepting it! Later investigation revealed that an intelligent robot could be built to respond to specific events on the 5250 screen, such as monitoring for a keyboard-error condition or looking for a specific message on the screen. Building the Robot Say you're faced with the formidable task of entering history data for a set of items. You've come to the conclusion that populating the underlying tables is proving difficult and that modifying an application program is lengthy. Figure 1 shows a simple sample screen that needs to be filled in.
It's not the most intricate screen in the world (and it only populates one table!), but this is for an example, so simplicity is important! How do you go about letting the computer enter data? There are a few simple steps to preparing a robot to key the data. Step 1: Identify all of the data-entry screens that will be required to receive the necessary information. For each screen, construct a grid containing information about the fields that need to be populated or analyzed by the data-entry robot. Running the Display File Field Description (DSPFFD) command against the display file will help you collect screen coordinates and edit code information. Table 1 shows a grid for the Maintain Item History screen.
Table 1: A sample grid with important field information to be analyzed or filled in The grid consists of a field description (the actual field name usually isn't important), the field's screen coordinates and length, the number of decimals, whether the sign is on the left or the right (which is important to a 5250 screen), and whether the field is used for output or both input and output. Step 2: Get to know your data-entry screen. You must know how the application screen works if you're going to program the computer to work with it. In particular you need to identify the order in which the fields need to be entered, if a function key needs to be pressed after a field is entered (such as Enter or Page Down), and whether an error can occur after a function key is pressed. Collect this information and put it in a grid, or pseudocode. Table 2 shows a sample grid illustrating the steps needed to enter data in the Maintain Item History screen.
Table 2: Sample grid containing important field information to be analyzed or filled in Step 3: Start the coding in your favorite Windows environment. Your newly devised tables from steps 1 and 2 will be instrumental in helping your code move along quickly. On the PC side, Figure 2 shows a Microsoft Access table called tblItemHistory, which stores the data that needs to be entered in the iSeries.
In your PC application, set references to the following PCOMM COM objects. (In Visual Basic this can be done by choosing Project, then References. In Access it can be done in the VBA [modules] editor by choosing Tools, then References.)
Table 3 has a brief description of each of these PCOMM objects.
Table 3: Four important PCOMM COM objects are necessary to control the emulator The sample Access database, developed in Microsoft Access 2000, along with the iSeries source that I used for this article, is available for download. To use this example, you have to compile the physical file, display file, and program objects on the iSeries. You also have to populate the iSeries item master file with sample data for item numbers 125,127,128, and 150. Finally, you need to have an emulator session open running the sample item master maintenance program, by issuing the command CALL ITEMHISTR. The first thing the code does is to retrieve the number of open 5250 sessions from the connection manager: intSessCount = pcommConnMgr.autECLConnList.Count Assuming that one or more sessions are found, the code loops through each session and retrieves a handle (or reference) for each PCOMM session. For each session handle, the "presentation space," "windows metrics," and "operator information area" objects are attached to the given session: pcommPS.SetConnectionByHandle lngSessionHandle pcommWin.SetConnectionByHandle lngSessionHandle pcommOIA.SetConnectionByHandle lngSessionHandle Once attached, you can use these COM objects to retrieve and modify the session's attributes. As noted in Table 3, setting a reference to the presentation space object for the current session will allow us to peek at what's on the screen for the current session. In particular, the GetText method is used to read 21 characters starting from coordinate (1,30) to test if the session has our data-entry screen open (as identified by title): If pcommPS.GetText(1, 30, 21) = "Maintain Item History" Then In this code, the program is assuming that at least one session will be waiting at the desired screen. (Our robot can be programmed to start all the way back at the sign-on screen, if needed.) If the current session is not running the desired program, the robot looks at the next session. Instead of looking for a program title, it's common to search for a program name as well, or both--as long as the robot program can uniquely identify a screen. When the proper screen is found, the data-entry robot invokes the pcomm_EnterData subroutine and passes the current session's presentation space and operator information area. This is the routine where all the real data-entry work is done. The local data-entry table is opened, and a loop is begun to process all rows. The first data-entry step is to enter the item number at coordinates (4,8) using the presentation space's SetText method, then press Enter, using the SendKeys method. The code waits for the emulator to become available by invoking the WaitForInputReady method of the OIA object. According to the rules laid down in Table 2, you check the message line window of the screen to make sure that this is a valid item number. If the item number is invalid, you log an error and continue with the next item; otherwise, fill in the remaining fields on the screen using the SetText method again. Of particular importance is making sure that the sign of a numeric field appears on the proper side (left or right), depending on the field's edit code. Once that is completed, Enter is pressed twice and then our intelligent robot checks for the "History Already Exists" warning message on the message line and takes appropriate action. That was simple! Here are a few more pointers.
Enter [enter] Field Exit [fldext] F1-F24 [pf1-pf24]
Save Your Fingers and Brain for Other Things While a data-entry robot definitely has its benefits, it does have some drawbacks. The data-entry screen coordinates may not be moved without having to reengineer the robot. A bullet-proof application takes a while to code, since each entry field would have to be followed by a large number of checks to verify, among other things, that the system is available, that an error message didn't occur, and that error reset is not waiting to be pressed. Nonetheless, by doing a reasonable coding job, most data-entry applications coded with basic error checking will do fine. Most of the time, they can be tweaked for special cases as they're encountered. If you're looking to avoid the headaches and dangers of populating data in an application's tables, and you want to be sure your data-entry person won't botch the keying process, then this technique is for you. Michael Sansoterra is a programmer/analyst for SilverLake Resources, an IT services firm based in Grand Rapids, Michigan. E-mail: msansoterra@silver-lake.com
|
Editors
Contact the Editors |
| Copyright © 1996-2008 Guild Companies, Inc. All Rights Reserved. |
DAMON TECHNOLOGIES