|
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.