Weblications

by Mike Tickle

Early on, when the Internet first started leaking into business, it was used as a means to deliver information to employees or associates that were operating in the field. Employee handbooks, Human Resources material and other types of reference material were published to the web so that any employee, no matter where their job site was, would be able to access the same type of information that the in-house employees could.

Now, the current rage in web-based applications, or "weblications," on the Internet are those that are used not only to distribute information, but also to collect it. And, not only collect it, but compile statistics and reports in real time and feed them to people in the field for their use. This is something that has really taken off in the past year, and Active Server Pages have proven to be a real workhorse for this type of weblication.

As an example, a large contract pharmaceutical organization in Research Triangle Park, N.C. has developed a weblication that allows the collection of medical research data from around the world. This information is submitted on Case Report Forms (CRFs).

Previously, this information was faxed or phoned in, and there were two main places for errors to occur: The person filling out the CRF and the person on the other end who was entering the data by hand. This company's application stops those errors, as it checks errors on submission from the pages of the weblication. Also, a middle layer was developed to double-check information, so that someone couldn't enter 200 degrees for a person's body temperature.

At the same time, the information coming in from the web was available to anyone who needed it, internally or externally through the same product. Someone in New Zealand could be conducting research on a new medication, and someone else in Germany could be reviewing the information seconds after it had been submitted. This truly shows the power of data collection over the Internet. The entire application is neatly packaged and can be installed anywhere on an Microsoft Windows NT Server with either a Microsoft SQL database server or an Oracle 7.3 database, along with ActiveState's Perl interpreter.

Let's look at a theoretical situation. Say a large company's telecommunications department is struggling with managing their 4,000 phone lines they have distributed around the country and the 4,000 phones those lines are attached to. This company has a centralized telecommunications department in Boston, but they rely on field offices and local telephone companies for support whenever a new phone needs to be added, or an existing phone has to be removed or if features on an existing phone need to be changed.

Now, let's really mess it up by saying it is all managed on paper. Yeah, paper.

In order to complete a work order, a technician writes the order on paper and faxes it to the local phone company. But, before she can do that, she has to go to one book and get a work order number and record the work order information in a second book. Then, when she receives confirmation from the phone company that the order has been received, she goes to a third book and enters that information. When the work is completed, she opens the fourth book, which contains information about all 4,000 lines and updates the information about the line or phone that has just been modified.

Another item to ad into the mix are contract telephone repair technicians that the company uses to perform some of the work. These repairmen receive work orders via fax and voice.

All told, we are looking at three organizations: The company's telecommunications department, the local telephone company, and the contract repairmen. Each one of these communicates with the other via voice or fax, and each one records information in a different manner by hand. I think we can do better than this.

Let's start with a basic active internet weblication. We'll call it the TelCommBlaster 3000. The TelCommBlaster 3000 is an active server pages weblication running on Microsoft Windows NT and backs to a Microsoft SQL database. It will be accessible to all of our organizations above.

We'll look closer at the workflow and how things work in the next edition of this column. For now, let's just take a broad look. For this look, we have to assume a few things: that all parties have a computer, internet access, a current web browser, a printer, and an e-mail program. We will also assume that everyone checks their email at least twice a day.

The telecommunication specialist at the home office in Boston enters a work order in the TelCommBlaster 3000. If it requires the phone company's attention, an e-mail is sent to the customer service representative at the local phone company, which tells the rep to go to the TelCommBlaster 3000 and check out a new order. The rep opens the order online, fills in the information he needs to and submits the form (the customer service rep also has the option to print the work order, or export it to a text file for internal use). Another e-mail flies out back to the home office notifying them that the telephone company has done their work processing the order. Once the work is completed, the customer service representative logs back into the system and closes the work order and the home office is notified by e-mail.

If the work order requires the attention of the contract repairmen, a similar process happens. They get an e-mail that a new order has been opened, view it online and print it out. The contract repairman will send a confirmation e-mail back to the home office stating that the order has been received. Once the work is completed, the repairman logs back into the system and closes the work order and the home office is notified by e-mail.

All of this information getting passed around is stored in the database through the Active Data Object. Everything from phone numbers to the location of phones to the features to customer service representative names and e-mail address is stored.

From the outside, the TelCommBlaster 3000 looks pretty simple. All you have to do is take form input and plunk it down into a database table. Unfortunately, its not that simple. This weblication will require air-tight error checking that will guarantee clean data every time and will also require an audit trail as long as your arm in order to track down misuse or errors. There are several smaller, yet critical issues we will cover at a later date.

Right now, our options for discussion are:

1. What type of database should be used here? Is Microsoft Access good enough or should Microsoft SQL Server or Oracle be brought into play?
2. What type of security should be implemented? Will SSL or SET be vital to security?
3. Who is ultimately responsible for the system? Is it best to have one administrator or many?
4. What type of training requirements exist?
5. What will be the total development time and cost?
6. Where does it get hosted?
7. Where the hell do you start?