Web development on the iSeries using CGI and the CGIDEV2 library

This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
Giovanni Perotti, keeper of the Easy400 website asked me to write a little note 
sharing my success story using CGIDEV2 for web development on the iSeries.  
Below is the text of my note which I thought some of you may appreciate as you 
begin to develop web applications for your iSeries.  While I am by no means an 
HTML expert and havn't experimented and/or used every technology available 
today for the iSeries, I have been programming using the RPG language for 18+ 
years now and at times have been on the bleeding edge of the language.  I offer 
this article for any RPG programmers looking for an excellent way on moving 
your applications to the web.

Hope you enjoy the article.

Mike Skvarenina
IBM Certified Specialist-AS/400 RPG Programmer
mskvarenina@usa.net



Hello all.  In this article I will share with you how I turned my trustly old 
iSeries from a green screen only machine into one lean, mean, web-servin' 
machine!

It used to be that the iSeries (or AS/400, or System/38) was a green screen 
only machine.  But along came the GUI and then came the web and for all this 
time the iSeries seemed to lag behind the times typing to keep up with this new 
technology.  Sure 3rd party tools came along but many of them were expensive 
and/or you were forced to work within the constraints of the tool.

My company like most, wanted a GUI interface and for a while I began writing 
client/server programs using Microsoft's Visual Basic for my front-ends and ILE 
RPG for my back-end communicating over windows sockets.  (Jon Paris should 
remember me from COMMON where he introduced me once as a guy doing sockets in 
RPG when IBM's own manuals said it wasn't possible in RPG).

Next came the web and my company began to REALLY push for a new interface.  
Struggling to deliver, I looked at many options then stumbled upon Net.data.  
Thanks to some simple examples from Craig Pelkie (www.web400.com), I got my 
feet wet developing a browser based application talking directly to my iSeries 
database.

This was great but I wanted more.  I discovered a book by Brad Stone titled 
"e-RPG: Building Web Applications with RPG".  From Brad's book I learned the 
basics of how to write RPG programs for the web.  Once again I wanted more so I 
continued to do research until I found this site, featuring a "product"? called 
CGIDEV2.

6 months later, my programmers and I learned how to exploit CGIDEV2 and turn 
our iSeries into one lean, mean, web-servin' machine!  We've abandoned all new 
5250 development and have concentrated all new interactive development toward 
the web.

Once I realized how feasible RPG CGI programming was and what doors it opened, 
the first thing I did was design an architecture for iSeries development for 
the web.  I wanted a modular approach so programs and functionality could be 
reused and I wanted as much security as possible since some of these apps could 
potentially be exposed to the web outside of our Intranet.

Since our users were very confortable with a green screen menu, the very first 
production program I wrote was a menu processor.  I wanted each user to login 
to the menu, then be presented with icons for various functions.  I built a 
file to hold the menu options then built the RPG CGI program to display it.  
When a user enters our initial URL, the first thing they see is a login page.  
When they login, I build them a custom menu based on their authority.  Within 
the database file is an icon filename, option description (which turns into a 
hyperlink when the menu is displayed) and the target program.  As the menu is 
built, I construct a hidden form containing the target program to 'submit' and 
a cooresponding JavaScript function for each target program so when either the 
icon or underlying hyperlink is pressed, the function is called which in turn 
'submits' the target program.

To acheive a modular approach I build a common data structure which I call the 
CGICDS and added all the fields each program may use.  For example, within the 
CGICDS is the user ID, name, selected employee ID, function code, target 
program, and many more.  The menu processor for example populates the User ID 
and name once validated.  The CGICDS is then passed back to the browser as a 
hidden variable on each subsequent form that could be submitted.

This brings me to a small mention of security.  Another objective I had was to 
not allow the users to bookmark one of our apps then return to it at a later 
date bypassing the login procedure.  I also didn't want them being able to 
simply alter a variable in the URL to gain access to information I didn't 
specifically want them to see.  To accomplish this objective I used the POST 
rather than the GET method of passing data from the browser to the server.  
Using this method, all the user sees and can bookmark is the URL to a given 
program.  Now if a user does bookmark a 'menu option' rather than going through 
the web menu, all they get is a login prompt since the User ID wasn't passed to 
the called program.  (This is part of the modular approach I will further 
describe shortly)

OK so back to the modular discussion.  One objective was to be able to write 
programs that did certain functions (employee search for example) then be able 
to 'call' then from other web programs.  I certainly didn't want to rewrite an 
employee search function each time into a new RPG CGI program nor did I want to 
deal with /COPYs.  So using the CGICDS approach, I was able to devise a way to 
pass this along from program to program, thus implementing a modular approach.

The following will describe in theory how this approach works in hopes that you 
too may be able to implement this method.  I will describe 2 RPG CGI programs, 
an employee search and employee viewer program.  Keep in mind that the employee 
search program can be used not only by the employee viewer but also any other 
program that may need to search and 'return' an employee.  Notice that I said 
'return'...well in reality most web pages are forward moving only meaning you 
click on spot and you move 'forward' to the next page, then you click again and 
you move forward again.  Well in my case, this is exactly what happens.

One final note before I begin...there's this case of persistence.  I do not use 
persistence...it's difficult to implement and would slow down the development 
process as well as utilize additional resources on the iSeries.  All my apps 
run as though each incoming request is coming from a new visitor.

Let's begin by talking about the employee viewer program.  This program when 
passed a 'selected employee' in the CGICDS will display a web page showing the 
employee picture (stored on the IFS) and some demographics.  Now here's the 
key:  If no employee was selected this must mean that the employee search 
hasn't been performed yet so what I do is return a small web page with an 
onLoad event that submits a hidden form containing the employee search program 
as the target program of the form.  Now also key is a field in the CGICDS 
called the 'next' target program.  Well in this case I put the calling program, 
the employee viewer, as the 'next' program to be called.

The employee search is submitted and returns an HTML page containing some 
artwork and a 'search data:' input box.  The user enters a name and presses the 
'search' button which is tied to a JavaScript function which submits a form.  
The form's target is the employee search program again, and the form contains 
the CGICDS as a hidden variable built from the previous 'call', the search data 
variable, and a function code which tells the search program to use the search 
data, read the database, and return a list of employees.  Remember the 'next' 
program to be called field in the CGICDS?  I take this 'next' program to be 
called and put it on a hidden form.  The list of employees is returned and I 
make then each a hyperlink calling a JavaScript function with the employee ID 
as a variable to the function.  When the user clicks an employee, the function 
is called which puts the employee ID variable into the hidden form, then 
submits the target which just so happens to be the employee viewer.

The employee viewer starts running again and reads in a selected employee to 
view, and does it's business.  It's that simple!

Using this approach my programmers and I have deployed 10 web based 
applications and have many more in development.  End users have no idea they 
are talking to their trusty ol'green screen machine and the web pages we 
produce have all the look and feel of a commercial site and utilize many of the 
advanced features of HTML.

Finally, the best part of this experience is I can now clearly state that the 
iSeries is no longer just a green screen serving machine but truly has 
graduated to one lean, mean, web-serving machine