You’ve 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 don’t all sales pitches?

I’ve 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.

Replicate This!

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, ColdFusion—a PC Web-deployment product that makes building Web applications around the SQL database a point-and-click frenzy of e-business delight.

What’s 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 you’re 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 won’t cut it.

Then there’s 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, you’re accustomed to almost zero downtime. Throw a PC in the mix, and the rules change—at 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. That’s 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 don’t have 99 percent uptime with this solution. You’ll have your share of problems, most likely self-inflicted, since you don’t 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 doesn’t.

Don’t 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 pages—which, 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 team’s hands for them to massage and try to fit into the AS/400’s database—not to mention they’ve 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 haven’t played with many of the vended products except for a couple of the screen-scraper types. It’s 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. It’s called the Workstation Gateway Server (WSG). To access the application, start the WSG server by using the following command:

STRTCPSVR SERVER(*WSG)

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. You’ll see it’s pretty plain and is literally translated into HTML. Starting out, you’ll 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 you’ve played around with the WSG, come back and read how to find some really neat examples of what you can do with what’s already installed on your AS/400, and what most of you are already familiar with.

It’s 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 didn’t 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 weren’t 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.

From there it was history. After a few months of learning HTML, JavaScript, and quite a few proof-of-concept applications, our team decided it would be worthwhile to use an AS/400 for a Web server for as many projects as we could. After all, we had two great tools to choose from: Net.Data and RPG, both of which are readily available and a breeze to use.

We deployed our first application a couple of months later—a 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 fact that you can’t get around is that if you want to develop Web applications, you will have to learn HTML and quite possibly JavaScript. This fact is true using any tool. Tweaking will always have to be done if you want the job done just right. Knowing that, why burden your staff with learning something else? Net.Data has an SQL-type interface that is easy to learn. Most of your shops already know RPG. I’ve developed some very sophisticated e-commerce sites using RPG, so I know it’s possible. And the great thing is that when someone asks you what you’re using, you can proudly say, “My AS/400.”

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 Webmaster’s 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.