Youve finally gotten around to putting together a plan to get your business on the Web. Then a flyer (or 10) hits your desk with different ways to deploy this project. The solutions range from fancy-named PC-based solutions to using your existing knowledge with RPG. They all sound great, but dont all sales pitches?
Ive been lucky enough to have the chance to not only work with the PC side of Web development projects but also deploy full-featured Web sites from an AS/400. After all is said and done, if your data and applications already reside on the AS/400, there is no doubt in my mind that the solution you choose should be AS/400-based. Let me explain why.
The first Web project I was involved with was a simple order-taking Web page. It was a fill-in-the-blanks type of Web page powered by a Microsoft Windows NT server, an SQL database, and, running it all, ColdFusiona PC Web-deployment product that makes building Web applications around the SQL database a point-and-click frenzy of e-business delight.
Whats the catch? If your data already resides on the PC, there is no catch. But if your data resides on the AS/400 (which is a main reason youre reading this magazine), how do you get the data to the SQL database? Well, you can use ODBC. But if you need a fast connection, keep in mind that ODBC has a history of being rather time-consuming. If your page is going to be the next eBay (which most pages seem to be these days), ODBC just wont cut it.
Then theres replication. You can use one of the many products out there to replicate the data from your AS/400 to your SQL database and back again. Sounds easy, right? Well, it is if it works. Being used to the AS/400, youre accustomed to almost zero downtime. Throw a PC in the mix, and the rules changeat least from my experience. Not only do you have to worry about the machine itself, but you also have to worry about the replication software you are running and the physical connection itself. Thats a few more links than I feel comfortable putting into a chain. But, because you needed to get this project done yesterday, this is your only option, since the front-end Web application has already been written.
Needless to say, you dont have 99 percent uptime with this solution. Youll have your share of problems, most likely self-inflicted, since you dont have time to learn the replication software package. But aside from that, it seems the Web-development group has different ideas than you do of what data needs to be collected. So you have to make changes, add a lot of error checking, and pray for the best.
Another problem you have is that orders have to be processed in batch. To do so, you have to replicate the data every couple of hours, making sure you send records from a certain table last so you can trigger the billing of the orders. Sometimes this works; other times it doesnt.
Dont Forget Where Your Experience Lies
My main point here is that the biggest problem you will run into is that the AS/400 group is introduced into this project too late in the design phase. The same group that has been writing and maintaining order-entry applications is not consulted until it is too late to make some really meaningful changes in the project.
This is, however, totally understandable. I can see how a manager wanting a sales report done automatically asks the group that has been producing them. When a manager wants a Web page up, he goes to the group that makes Web pageswhich, in the early days of e-commerce, usually was not the AS/400 group.
If you do plan to deploy Web applications on a PC platform, by all means get an experienced team from the AS/400 side on the project right away. After all, the data is going to end up in that teams hands for them to massage and try to fit into the AS/400s databasenot to mention theyve been doing order taking and all sorts of business programming for years.
Can My AS/400 Be a Web Server?
Now for the big questions: Can my AS/400 act as a Web server? Can I run full-function Web applications on my AS/400, interacting with my native existing database? The answer to both is an all-inclusive yes!
Your options for application development on the AS/400 are endless. You can start out with the ever-popular Java applications and go straight to the least expected RPG and COBOL. In the middle of your option list is a mix of products that claim to take your existing applications and make them Web-ready. Some do this by scanning through your code and making new Web screens for the existing programs. Others are simply screen- scrapers that translate your 5250 data stream into HTML, porting any application with a screen interface to a Web browser.
I havent played with many of the vended products except for a couple of the screen-scraper types. Its true that these products take your screens and put them to the Web, but unless you put a little work into it, these interfaces will be difficult for your users to work with. If you want to see the most basic examples of taking your screens and putting them to the Web, then take a look at an application built into the AS/400 that will allow you to do just that. Its called the Workstation Gateway Server (WSG). To access the application, start the WSG server by using the following command:
Then, open your Web browser and point it to http://your.as400.ipaddress:5061/WSG. Port 5061 is the default port for the WGS.
Figure 1 (page 69) shows an example of the screen you get. Youll see its pretty plain and is literally translated into HTML. Starting out, youll find it pretty neat, so try and see how easy it is to edit some source. This screen shot simply shows an example of what a data-intensive screen may be like.
After youve played around with the WSG, come back and read how to find some really neat examples of what you can do with whats already installed on your AS/400, and what most of you are already familiar with.
Its Been There All Along
After I exhausted most alternatives to try to find an easy way to develop well-working e- commerce applications on the AS/400, I stumbled across a set of APIs in the IBM Web Programming Guide. These APIs opened my eyes and blew my mind. The set of APIs I am referring to is the same type of procedures used in other Common Gateway Interface (CGI) programming languages that I dabbled with on the PC. The languages allow you to write and read data from a browser. Because I dabbled with APIs before using the tried and true RPG programming language, and because these APIs didnt look nearly as complicated as the APIs I had used before, I decided to try them out.
In less than 30 minutes, I had written an RPG program that wrote dynamic HTML to a browser. All it said was Hello World, but that was enough to know that I had stumbled onto something big. So, I kept digging (mostly on my spare time) just to see what else I could do.
The first real application I wrote was one that simply read through an item master file and displayed items, descriptions, quantity on hand, and anything else I could think of. I showed it to a couple of coworkers. They werent impressed until I told them it was an RPG program. It took a few minutes of convincing (i.e., changing code, recompiling, and running it again), but soon they were as excited as I was.
We deployed our first application a couple of months latera customer service online system that replaced an existing NT server running ColdFusion. The NT machine could simply not keep up, especially after the number of records reached the tens of thousands. Querying the database took minutes, but on our AS/400 it took seconds. Also, because we had a team with years of experience developing green-screen applications for our users, we knew what questions to ask when developing the system. Our customers were more than happy and knew that because the application was running on an AS/400, those who would use the page to view their open orders would have no problems with downtime.
Stick with What You Know
At a time when a new Web-deployment package or technique comes out every day, sometimes it is best to remember what you know. You know your AS/400 is stable. You know your staff has been producing and maintaining software that has kept your business up and running. You also know what it takes to learn something new.
One last note is this: When people call the AS/400 and RPG legacy, I take that as the best compliment possible. Why? Because for something to reach legacy status, it has to
have been around for a long time and, most important, it has to have worked. To me, legacy equals proven.
REFERENCES AND RELATED MATERIALS
e-RPG: Building AS/400 Web Applications with RPG. Bradley V. Stone. Carlsbad, California: MC Publishing Co., 2000
HTTP Server for AS/400 Webmasters Guide V4R4 (GC41-5434-04, CD-ROM QB3AEO04)
Web Programming Guide V4R4 (GC41-5435-03, CD-ROM QB3AEQ03)
Figure 1: You can access a data-intensive screen through the WSG interface.