Using the WebApp Server for Linux Technology PreviewOctober 13th 2000Copyright 2000, Data Access CorporationAll Rights Reserved0) Introduction.1) Creating a new WebApp Workspace.2) How to compile a WebApp.3) How to deploy a WebApp. 3.1) Setting up the links to the apphtml directory. (Like IIS Virtual Directory.) 3.2) Configuring WebApp Server for the new WebApp.4) Putting it all to the test.0) Introduction. This document is all preliminary documentation, and Data Access Corporation reserves the right to make any changes regarding any guidelines or otherwise mentioned in this document before the final release of the product. This document is intended as brief instructions only to guide and help you out with using the WebApp Server for Linux technology preview.Throughout this document we will use the example of creating a simple WebApp called Amazon.1) Creating a new WebApp Workspace. The recommended layout for a new WebApp workspace is the same layout as used in the webappsample WebApp. Note that we use all directories in lowercase letters, in order to keep things simple. By using the same layout you can simply copy the setpath script available in the webappsample application. Normally, the only modification necessary to the setpath script is to change the WORKSPACEDIR variable to point to your workspace root directory.Our Amazon WebApp is located in /usr/local/src/amazon. And the Workspace layout is a standard WebApp workspace with lowercase directory names:amazon/apphtmlamazon/appsrcamazon/dataamazon/programsSo we simply copy the setpath script with the command:cp /usr/local/dfinetserv/examples/webappsample/setpath /usr/local/src/amazonWe then edit the script using our favourite editor (kwrite or vi works fine). We change the line that says:WORKSPACEDIR=/usr/local/dfinetserv/examples/webappsampleInto:WORKSPACEDIR=/usr/local/src/amazon2) How to compile a WebApp. A simple shell script is included to easily compile the WebApp, /usr/local/dfinetserv/bin/buildwebapp. This script should be run from your workspace root directory. It will pick up the setpath script, and compile appsrc/webapp.src, and then move the resulting flx file into your workspace programs directory. The script itself looks like this:
#!/bin/sh. ./setpathdfcomp appsrc/webapp.srcmv appsrc/webapp.flx programs/webapp.flxSince we’re working at Internet speed, our simple WebApp is already done, and now ready to be compiled. So we enter our workspace root directory with the command:cd /usr/local/src/amazonAnd then we compile it using this command:/usr/local/dfinetserv/bin/buildwebappAnd then when it’s done we’re a little sceptic so we check whether the new flx file is actually in the programs directory. We do that with this command:ls –l programsAnd indeed it’s there, and the timestamp looks right, so we go on to the next section.3) How to deploy a WebApp. Deploying the WebApp consists of two steps. First we deploy our apphtml directory so it will be available to our Web server and our JSP engine. Then we deploy the program so that it’s available for WebApp Server.3.1) Setting up the links to the apphtml directory. If you use Apache and Tomcat, then the apphtml directory must be accessible by them both. Tomcat is actually smart enough to pick up new applications directly deployed under its webapps directory, and at the same time make them available through Apache. To make full use of this feature, you can simply copy the apphtml directory in under the Tomcat webapps directory.But sometimes, especially during development when you constantly make changes and updates to the apphtml directory, it’s more convenient to setup a symbolic link, rather than copying the directory contents. However, when setting up a link it’s also necessary to setup a separate link for Apache, thus you need two symbolic links pointing to the apphtml directory. This is exactly what the webappsample application uses, so we’ll use that approach.First we setup the link for Tomcat, our apphtml directory is located in /usr/local/src/amazon/apphtml. So we setup the link with this command:ln –s /usr/local/src/amazon/apphtml /usr/local/jakarta/jakarta-tomcat/webapps/amazon(Note that this should be all on one line.)Next we setup the link for Apache. Our Apache document root is located in /home/httpd/html. So we setup the link with this command:ln –s /usr/local/src/amazon/apphtml /home/httpd/html/amazon3.2) Configuring WebApp Server for the new WebApp. The configuration file for WebApp Server is /etc/dfinetserv.conf. There’s good documentation provided in the file itself. So we recommend to take the time of reading through the file to learn the basics of the different configuration directives.There are three basic settings needed for a WebApp; VirtualRoot, ProgramPath, and the SetEnv directive.VirtualRoot corresponds to where the WebApp is deployed in relation to your Web server’s document root. i.e. if you access your application using HYPERLINK "http://localhost/webappsample" http://localhost/webappsample then your WebApp root URI is /webappsample, and so your WebApp Virtual Root.ProgramPath should contain the full path and filename of the flx for the WebApp. e.g. /usr/local/dfinetserv/examples/webappsample/programs/webapp.flx.The SetEnv directive allows you to set any environment variables specific to the WebApp. Typically this is used to append the WebApp data directory to the DFPATH environment variable. The basic shared contents of DFPATH is normally setup in the global section.For our amazon WebApp, we open the /etc/dfinetserv.conf file in our favourite editor, and insert the following at the end of the file:[amazon]VirtualRoot = /amazonProgramPath = /usr/local/src/amazon/programs/webapp.flxSetEnv DFPATH = /usr/local/src/amazon/data:$DFPATHDebugOutput = trueWe also turned on the DebugOutput option, since this will be the first time we run the WebApp, and naturally we “expect” it to have some bugs, and so the debug option can be useful. The debug option directs all normal screen output from the DataFlex program to the WebApp log file, including “showln”statements. When the debug option is off(as is normal in a production environment), all normal screen output is discarded, except for error messages, or other explicit log output using “Send LogEvent” which are properly logged to the logfile with timestamps and all.4) Putting it all to the test. In order for the Web server, Tomcat and WebApp Server to pick up the new settings, we must first restart the services. This is easily accomplished using the /usr/local/dfinetserv/bin/allwebsvc script. So we first stop the services, if they’re currently running, using the command:/usr/local/dfinetserv/bin/allwebsvc stopand then restarting, using the command:/usr/local/dfinetserv/bin/allwebsvc startIf all went well, they should have started up with no errors, and so we can try it out in our Web browser. For our Amazon WebApp, we quickly start Netscape, which we of course installed on our Linux machine, and type in the url HYPERLINK "http://localhost/amazon" http://localhost/amazon and of course, there it is. It all works fine.