The Oracle Web/ Application Server or iAS (Internet Application Server) enables
users using Web Browsers to access HTML pages (static content) and data from
Oracle databases (dynamic content). Cartridges or plug-in's are provided to
execute PL/SQL code, Java, Perl and other programming language code. It can
also execute standard CGI-BIN programs. Look at this simplified example:
+-CLIENT-+ +----------------S E R V E R-----------------+
| | | |
| Web | <--Internet--> | Oracle Web <-> Oracle PL/SQL <-> Oracle |
| Browser| HTTP | Listener Cartridge (OWA) Database |
| | | |
+--------+ +--------------------------------------------+
NOTE: The "PL/SQL Cartridge" was formerly called OWA (Oracle Web Agent).
The Oracle Web Agent extends the Common Gateway Interface (CGI) to Oracle PL/SQL stored procedures.
Programming is done in PL/SQL using the following set of packaged procedures:
HTP - Hypertext Procedures
HTF - Hypertext Functions
OWA_UTIL - Oracle Web Agent Utilities
Example PL/SQL procedure:
CREATE OR REPLACE PROCEDURE HelloWorld AS
BEGIN
htp.htitle('My first dynamic Web page');
htp.print('Hello world');
htp.line;
END HelloWorld;
/
To run this example, one would typically provide an URL like this to a
Web Browser:
Using PL/SQL Server Pages, a technology similar to Active Server Pages and
JavaServer Pages: The basic design is created in a visual tool, for instance
an HTML designer and the PL/SQL code (also called scriptlets) is written in
special tags. Only the absolute minimum of PL/SQL will have to be written
and the HTML designer and PL/SQL programmer can share the same file. A PSP
file is compiled into a PL/SQL stored procedure, which means that the PSP
compile is used during the development phase only.
Two PSP products exist on the market: Oracle PL/SQL Server Pages (OPSP) and
ChangeGroup PL/SQL Server Pages (CGPSP). OPSP comes with Oracle8i Release 2
and newer and has a command line interface only.
CGPSP is compatible with OPSP and integrates 100% with editors and tools, has
visual error correction in a browser-based environment, automatic security
and synonym setup, project facilities such as make, install script
generation, and much more. CGPSP works with Oracle7, 8, and 8i, O(W)AS 3.0
and newer, iAS 1.0 and newer, plus all Apache-based Web servers. See more
information about CGPSP at .
www.changegroup.dk/en/cgpsp.htm.
Externalize ROWNUM by implementing queries like this:
SELECT ...
FROM (SELECT ROWNUM rnum, ... FROM ...)
WHERE rnum BETWEEN :low AND :high
AND rownum < (:high - :low + 1);
where :low and :high are dynamically generated values depending on
which result page the user is viewing. Typically, they are used to
show "Next 15 matches", "Previous 15 matches" links at the bottom
of each page.
Because the Web is stateless, there is no way to lock data between a SELECT and an UPDATE initiated from a Web Browser.
One workaround is to let the procedure that display the data for updating also store the data values in hidden fields. Eg:
for c1 in (select rowid, a.* from emp a) loop
htp.FormHidden('the_rowid', c1.rowid);
htp.Print('Enter new Employee Name:');
htp.FormHidden('old_ename', c1.ename);
htp.FormText('new_ename', c1.ename);
end loop;
The update procedure can now compare the hidden values in the form with the current table values before allowing the update to
continue. Eg:
UPDATE emp SET ename = new_ename
WHERE rowid = the_rowid
AND ename = old_ename;
if (SQL%ROWCOUNT = 0) then
htp.print('Someone else changed this row, please re-query before updating.');
else
htp.print('1 row updated.');
end if;
Yes, Designer/2000 (CASE) V1.2A and above includes a Web Server Generator
that can generate QUERY-ONLY applications.
From Designer/2000 1.3W one can generate applications that can do
Insert, Update and Delete operations.
1.3W also generates JavaScript (NOT JAVA!) code to do client side validation!!!
With the Oracle Web Server version 1.0 you have a CGI-BIN program called OWA that works with any HTTP webserver.
With version 2.0 you have a CGI-BIN program called OWA that works with any
webserver, in addition to a Web Request Broker (WRB) OWA cartridge.
The WRB cartridge with 2.0 works with the Oracle Web Server
(with 2.0 you can still use the web agent with any server, but you can't use
the WRB component with any other server).
With version 2.1 you have the CGI-BIN program... in addition to a
Web Request Broker OWA cartridge. The WRB cartridge with 2.1 works with
the Oracle Web Server and/or
the Netscape Fasttrack Server.
With version 3.0 you will have the CGI-BIN program... the cartridge...
which works with
Oracle Web Server,
Netscape fasttrack/enterprise/commerce server,
MSIIS, and perhaps
others.
The Oracle Web Request Broker (WRB) is faster and more scalable than the CGI-BIN program OWA,
but can only be used with certain Web servers.
CGI programs are spawned off each time a HTTP request is made to it while the WRB will only start new brokers if the workload increase.
Note that the OWS-BIN OWA program's configuration parameters are stored in the SV*.CFG file while the WRB OWA is configured from SV*.APP.
using Netscape-style cookies in conjunction with some sort of login
form. The PL/SQL procedure that processes the form returns a cookie to
the browser which the browser will hold on to and include with future
requests, until you send it a new cookie, or the browser session ends.
This avoids having to have user identifiers in the URL.
Look at OWA2, a replacement for Oracle's PL/SQL Cartridge.
With OWA2 you can control authentication from a PL/SQL function in your database.
One can keep authentication information in a file separate from the sv<server>.cfg file. In this case
the following information in the sv<server>.cfg file...
************
[Security]
Basic {
(Users)
users: passwords
(Groups)
groups: users <----- Single group should not exceed 200 users
(Realms)
realms: groups <----- Be sure to include all groups
}
;
[Protection]
/secret-dir/ Basic(Realm)
************
could be replaced with....
************
[Security]
Basic @/path/to/user/authentication/file
;
[Protection]
/secret-dir/ Basic(Realm)
************
The file referred to above should contain the following information...
************
(Users)
users: passwords
(Groups)
groups: users <----- Single group should not exceed 200 users
(Realms)
realms: groups <----- Be sure to include all groups
************
Download and look at the following working source code example:
OWA2 is a replacement for the Oracle PL/SQL Web Request Broker Cartridge.
Other than Oracle's PL/SQL Cartridge, OWA2 :
Can call a user definable PL/SQL function to do authentication
Can stream multiple IMAGES concurrently from a database table to Web Browsers
Send simple mail messages
Add parameters to enable/disable timing, logging, database tracing, etc.
Keep database sessions open for performance reasons
It was written, compiled and tested on a SUN6000E running Solaris 2.5, Oracle 7.3 and the Oracle WebServer V2.0.3.
If you make any changes to OWA2 or port it to a different environment,
please mail the source code back to us.
Cookies allow any site to store information on a WEB Browser's hard disk (cookie.txt file).
This information is sent back to the originating site whenever you access it again.
The Oracle WebServer Administrator's userid and password can be found in your $ORACLE_HOME/ows21/admin/svadmin.cfg file.
The password is not encrypted!!!
the server responds with "Requested URL was not found on this server".
Causes:
This is due to there not being a mapping in the service listener's
Virtual Directory Mappings configuration, of the form:
/home/oracle/ows2/bin/ CN /ows-bin/service/
so the "owa" program isn't found.
You're accessing a directory, /xxxx/, and the directory isn't
readable by the Web Server process.
The Web Server is configured to not generate directory listings
automatically, and there isn't an index.html file (or whatever
you've picked as your index file name).
Fix:
Create the virtual directory mapping, halt the listener, and
restart it.
Make sure that either the Web Server will create indices itself,
or that there is a readable index file under the name you've
specified. If altering the server configuration, halt and restart
the server. If changing file ownership or permissions, note the
directory rescanning issue below.
the server responds with "Request failed. We were unable to
process your request at this time. Please try again later."
Cause:
The listener can't read the configuration file owa.cfg.
The listener is attempting to invoke the PL/SQL procedure named, but can't, for some reason.
Fix:
Make sure that the file /home/oracle/owa2/admin/owa.cfg (or
whatever is the moral equivalent on your system) is readable by
the user running the Web Server.
Check that the user for the listener has the permissions to
invoke such functions: do "exec tw.ping" in sqlplus. There won't
be any output, but it should say that it ran ok. If necessary, try
reloading the stored procedures into the database.
Make sure that the names of the input fields in the form
match up exactly with the names of the parameters in the
script. There must be an one-to-one mapping.
If you've got multiple-value fields, such as SELECTs,
make sure they're of the right type (defined in the
OWA_UTIL package), and that there's an extra value
supplied by a hidden field to force at least one value
to be selected.
If all else fails, the procedure is probably raising an
exception. Put OTHERS exception handlers around everything
and call barf(errstr('procedure name')), or the moral equivalent
on your system.
Symptom: webserver doesn't notice file permissions have changed.
The webserver caches the modification time of the directory,
and of all the files within it. If a URL is not available because
of permissions problems, and you fix that, the webserver will
continue to say that the URL is not available, because the
directory modification date hasn't changed, so it doesn't bother
to check the file itself. Renaming the file to something and back
again will make the webserver see the change.
This is configurable, however. On the Web Listener configuration
page, there is a parameter which determines how long the Web
Server will go without re-scanning a directory that appears to
have not changed yet, including the ability to never rescan
unless the modification date changes.
