Java is not the only language that can do network operations and produce dynamic Web content. PL/SQL has a number of features that you can use to make your database available on the Web and make back-office data accessible on the intranet.
This chapter discusses the following topics:
This section contains the following topics:
Typically, a Web application written in PL/SQL is a set of stored procedures that interact with Web browsers through HTTP. A set of interlinked, dynamically generated HTML pages forms the user interface of a web application.
The program flow of a PL/SQL Web application is similar to that in a CGI Perl script. Developers often use CGI scripts to produce Web pages dynamically, but such scripts are often not optimal for accessing Oracle Database. Delivering Web content with PL/SQL stored procedures provides the power and flexibility of database processing. For example, you can use DML, dynamic SQL, and cursors. You also eliminate the process overhead of forking a new CGI process to handle each HTTP request.
Figure 11-1 illustrates the generic process for a PL/SQL Web application.
The process includes the following steps:
A user visits a Web page, follows a hypertext link, or submits data in a form, which causes the browser to send a HTTP request for a URL to an HTTP server.
The HTTP server invokes a stored procedure on an Oracle database according to the data encoded in the URL. The data in the URL takes the form of parameters to be passed to the stored procedure.
The stored procedure calls subprograms in the PL/SQL Web Toolkit. Typically, subprograms such as
HTP.Print generate Web pages dynamically. A generated Web page varies depending on the database contents and the input parameters.
The subprograms pass the dynamically generated page to the Web server.
The Web server delivers the page to the client.
You can implement a Web browser-based application entirely in PL/SQL with the Oracle Database components described in this section.
This set of PL/SQL packages is a generic interface that enables you to use stored procedures called by mod_plsql at runtime.
In response to a browser request, a PL/SQL procedure updates or retrieves data from Oracle Database according to the user input. It then generates an HTTP response to the browser, typically in the form of a file download or HTML to be displayed. The Web Toolkit API enables stored procedures to perform actions such as the following:
Obtain information about an HTTP request
Generate HTTP headers such as content-type and mime-type
Set browser cookies
Generate HTML pages
Table 11-1 describes commonly used PL/SQL Web Toolkit packages.
|Package||Description of Contents|
Function versions of the procedures in the
Procedures that generate HTML tags. For instance, the procedure
Functions and procedures that enable the PL/SQL gateway cache feature to improve performance of your PL/SQL Web application.
You can use this package to enable expires-based and validation-based caching with the PL/SQL gateway file system.
Subprograms that send and retrieve HTTP cookies to and from a client Web browser. Cookies are strings a browser uses to maintain state between HTTP calls. State can be maintained throughout a client session or longer if a cookie expiration date is included.
The authorize function used by cookies.
Subprograms that obtain the coordinates where a user clicked an image. Use this package when you have an image map whose destination links invoke a PL/SQL gateway.
Subprograms that impose database optimistic locking strategies to prevent lost updates. Lost updates can otherwise occur if a user selects, and then attempts to update, a row whose values have been changed in the meantime by another user.
Subprograms that perform string matching and string manipulation with regular expressions.
Subprograms used by the PL/SQL gateway for authenticating requests.
Subprograms used by package
The following types of utility subprograms:
Subprograms that download documents from a document repository that you define using the DAD configuration.
See Also:Oracle Database PL/SQL Packages and Types Reference for syntax, descriptions, and examples for the PL/SQL Web Toolkit packages
As explained in detail in the Oracle Application Server mod_plsql User's Guide, mod_plsql maps Web client requests to PL/SQL stored procedures over HTTP. Refer to this documentation for instructions.
Traditionally, PL/SQL Web applications use function calls to generate each HTML tag for output. These functions are part of the PL/SQL Web Toolkit packages that come with Oracle Database. Example 11-1 illustrates how to generate a simple HTML page by calling the
HTP functions that correspond to each HTML tag.
CREATE OR REPLACE PROCEDURE html_page IS BEGIN HTP.HTMLOPEN; -- generates <HTML> HTP.HEADOPEN; -- generates <HEAD> HTP.TITLE('Title'); -- generates <TITLE>Hello</TITLE> HTP.HEADCLOSE; -- generates </HTML> -- generates <BODY TEXT="#000000" BGCOLOR="#FFFFFF"> HTP.BODYOPEN( cattributes => 'TEXT="#000000" BGCOLOR="#FFFFFF"'); -- generates <H1>Heading in the HTML File</H1> HTP.HEADER(1, 'Heading in the HTML File'); HTP.PARA; -- generates <P> HTP.PRINT('Some text in the HTML file.'); HTP.BODYCLOSE; -- generates </BODY> HTP.HTMLCLOSE; -- generates </HTML> END;
An alternative to making function calls that correspond to each tag is to use the
HTP.PRINT function to print the text and tags together. Example 11-2 illustrates this technique.
CREATE OR REPLACE PROCEDURE html_page2 IS BEGIN HTP.PRINT('<html>'); HTP.PRINT('<head>'); HTP.PRINT('<meta http-equiv="Content-Type" content="text/html">'); HTP.PRINT('<title>Title of the HTML File</title>'); HTP.PRINT('</head>'); HTP.PRINT('<body TEXT="#000000" BGCOLOR="#FFFFFF">'); HTP.PRINT('<h1>Heading in the HTML File</h1>'); HTP.PRINT('<p>Some text in the HTML file.'); HTP.PRINT('</body>'); HTP.PRINT('</html>'); END;
Chapter 12, "Developing PL/SQL Server Pages" describes an additional method for delivering using PL/SQL to generate HTML content. PL/SQL server pages enables you to build on your knowledge of HTML tags and avoid learning a new set of function calls. In an application written as a set of PL/SQL server pages, you can still use functions from the PL/SQL Web toolkit to do the following:
Simplify the processing involved in displaying tables
Store persistent data (cookies)
Work with CGI protocol internals
To be useful in a wide variety of situations, a Web application must be interactive enough to allow user choices. To keep the attention of impatient Web surfers, you should streamline the interaction so that users can specify these choices very simply, without excessive decision-making or data entry.
The main methods of passing parameters to PL/SQL Web applications are:
Using HTML form tags. The user fills in a form on one Web page, and all the data and choices are transmitted to a stored procedure when the user clicks the
Submit button on the page.
Hard-coded in the URL. The user clicks on a link, and a set of predefined parameters are transmitted to a stored procedure. Typically, you would include separate links on your Web page for all the choices that the user might want.
This section contains the following topics:
List boxes and drop-down lists are implemented with the HTML tag
Use a list box for a large number of choices or to allow multiple selections. List boxes are good for showing items in alphabetical order so that users can find an item quickly without reading all the choices.
Use a drop-down list in the following situations:
There are a small number of choices
Screen space is limited.
Choices are in an unusual order.
The drop-down captures the attention of first-time users and makes them read the items. If you keep the choices and order consistent, then users can memorize the motion of selecting an item from the drop-down list, allowing them to make selections quickly as they gain experience. Example 11-3 shows a simple drop-down list.
Radio buttons pass either a null value (if none of the radio buttons in a group is checked), or the value specified on the radio button that is checked.
To specify a default value for a set of radio buttons, you can include the
CHECKED attribute in one of the
INPUT tags, or include a
DEFAULT clause on the parameter within the stored procedure. When setting up a group of radio buttons, be sure to include a choice that indicates "no preference", because once the user selects a radio button, they can still select a different one, but they cannot clear the selection completely. For example, include a "Don't Care" or "Don't Know" selection along with "Yes" and "No" choices, in case someone makes a selection and then realizes it was wrong.
Checkboxes need special handling, because your stored procedure might receive a null value, a single value, or multiple values:
All the checkboxes with the same
NAME attribute make up a checkbox group. If none of the checkboxes in a group is checked, the stored procedure receives a null value for the corresponding parameter.
If one checkbox in a group is checked, the stored procedure receives a single
If more than one checkbox in a group is checked, the stored procedure receives a parameter with the PL/SQL type
TABLE OF VARCHAR2. You must declare a type like this, or use a predefined one like
OWA_UTIL.IDENT_ARR. To retrieve the values, use a loop:
CREATE OR REPLACE PROCEDURE handle_checkboxes ( checkboxes owa_util.ident_arr ) AS BEGIN ... FOR i IN 1..checkboxes.count LOOP htp.print('<p>Checkbox value: ' || checkboxes(i)); END LOOP; ... END; / SHOW ERRORS;
Entry fields require the most validation, because a user might enter data in the wrong format, out of range, and so on. If possible, validate the data on the client side using dynamic HTML or Java, and format it correctly for the user or prompt them to enter it again.
You might prevent the user from entering alphabetic characters in a numeric entry field, or from entering characters once a length limit is reached.
You might silently remove spaces and dashes from a credit card number if the stored procedure expects the value in that format.
You might inform the user immediately when they type a number that is too large, so that they can retype it.
Because you cannot always rely on such validation to succeed, code the stored procedures to deal with these cases anyway. Rather than forcing the user to use the
Back button when they enter wrong data, display a single page with an error message and the original form with all the other values filled in.
For sensitive information such as passwords, a special form of the entry field,
<INPUT TYPE=PASSWORD>, hides the text as it is typed in.
For example, the following procedure accepts two strings as input. The first time it is called, the user sees a simple form prompting for the input values. When the user submits the information, the same procedure is called again to check if the input is correct. If the input is OK, the procedure processes it. If not, the procedure prompts for new input, filling in the original values for the user.
-- Store a name and associated zip code in the database. CREATE OR REPLACE PROCEDURE associate_name_with_zipcode ( name VARCHAR2 DEFAULT NULL, zip VARCHAR2 DEFAULT NULL ) AS booktitle VARCHAR2(256); BEGIN -- Both entry fields must contain a value. The zip code must be 6 characters. -- (In a real program you would perform more extensive checking.) IF name IS NOT NULL AND zip IS NOT NULL AND length(zip) = 6 THEN store_name_and_zipcode(name, zip); htp.print('<p>The person ' || name || ' has the zip code ' || zip || '.'); -- If the input was OK, we stop here and the user does not see the form again. RETURN; END IF; -- If some data was entered, but it is not correct, show the error message. IF (name IS NULL AND zip IS NOT NULL) OR (name IS NOT NULL AND zip IS NULL) OR (zip IS NOT NULL AND length(zip) != 6) THEN htp.print('<p><b>Please re-enter the data. Fill in all fields, and use a 6-digit zip code.</b>'); END IF; -- If the user has not entered any data, or entered bad data, prompt for -- input values. -- Make the form call the same procedure to check the input values. htp.formOpen( 'scott.associate_name_with_zipcode', 'GET'); htp.print('<p>Enter your name:</td>'); htp.print('<td valign=center><input type=text name=name value="' || name || '">'); htp.print('<p>Enter your zip code:</td>'); htp.print('<td valign=center><input type=text name=zip value="' || zip || '">'); htp.formSubmit(NULL, 'Submit'); htp.formClose; END; / SHOW ERRORS;
One technique for passing information through a sequence of stored procedures, without requiring the user to specify the same choices each time, is to include hidden parameters in the form that calls a stored procedure. The first stored procedure places information, such as a user name, into the HTML form that it generates. The value of the hidden parameter is passed to the next stored procedure, as if the user had entered it through a radio button or entry field.
Other techniques for passing information from one stored procedure to another include:
Sending a "cookie" containing the persistent information to the browser. The browser then sends this same information back to the server when accessing other Web pages from the same site. Cookies are set and retrieved through the HTTP headers that are transferred between the browser and the Web server before the HTML text of each Web page.
Storing the information in the database itself, where later stored procedures can retrieve it. This technique involves some extra overhead on the database server, and you must still find a way to keep track of each user as multiple users access the server at the same time.
You can use an HTML form to choose a file on a client system, and transfer it to the server. A stored procedure can insert the file into the database as a
BLOB, or other type that can hold large amounts of data.
The PL/SQL Web toolkit and the PL/SQL gateway have the notion of a "document table" that holds uploaded files.
See Also:mod_plsql User's Guide
By default, an HTML form must have a
Submit button, which transmits the data from the form to a stored procedure or CGI program. You can label this button with text of your choice, such as "Search", "Register", and so on.
You can have multiple forms on the same page, each with its own form elements and
Submit button. You can even have forms consisting entirely of hidden parameters, where the user makes no choice other than clicking the button.
Submit button is not essential.
When an HTML form is submitted, your stored procedure receives null parameters for any form elements that are not filled in. For example, null parameters can result from an empty entry field, a set of checkboxes, radio buttons, or list items with none checked, or a
VALUE parameter of "" (empty quotation marks).
Regardless of any validation you do on the client side, always code stored procedures to handle the possibility that some parameters are null:
DEFAULT clause in all parameter declarations, to prevent an exception when the stored procedure is called with a missing form parameter. You can set the default to zero for numeric values (when that makes sense), and use
DEFAULT NULL when you want to check whether or not the user actually specifies a value.
Before using an input parameter value that has a
DEFAULT NULL declaration, check if it is null.
Make the procedure generate sensible results even when not all input parameters are specified. You might leave some sections out of a report, or display a text string or image in a report to indicate where parameters were not specified.
Provide a way to fill in the missing values and run the stored procedure again, directly from the results page. For example, you could include a link that calls the same stored procedure with an additional parameter, or display the original form with its values filled in as part of the output.
Web applications are particularly concerned with the idea of state, the set of data that is current at a particular moment in time. It is easy to lose state information when switching from one Web page to another, which might result in asking the user to make the same choices over and over.
You can pass state information between dynamic Web pages using HTML forms. The information is passed as a set of name-value pairs, which are turned into stored procedure parameters for you.
If the user has to make multiple selections, or one selection from many choices, or it is important to avoid an accidental selection, use an HTML form. After the user makes and reviews all the choices, they confirm the choices with the
Submit button. Subsequent pages can use forms with hidden parameters (
<INPUT TYPE=HIDDEN> tags) to pass these choices from one page to the next.
If the user is only considering one or two choices, or the decision points are scattered throughout the Web page, you can save the user from hunting around for the
Submit button by representing actions as hyperlinks and including any necessary name-value pairs in the query string (the part following the
? within a URL).
An alternative way to main state information is to use Oracle Application Server and its
mod_ose module. This approach lets you store state information in package variables that remain available as a user moves around a Web site.
See Also:The Oracle Application Server documentation set at
While built-in PL/SQL features are focused on traditional database operations and programming logic, Oracle Database provides packages that open up Internet computing to PL/SQL programmers.
This section contains the following topics:
You can send e-mail from a PL/SQL program or stored procedure with the
UTL_SMTP package. You can read about this package in the Oracle Database PL/SQL Packages and Types Reference.
The following code example illustrates how the SMTP package might be used by an application to send e-mail. The application connects to an SMTP server at port 25 and sends a simple text message.
PROCEDURE send_test_message IS mailhost VARCHAR2(64) := 'mailhost.fictional-domain.com'; sender VARCHAR2(64) := 'email@example.com'; recipient VARCHAR2(64) := 'firstname.lastname@example.org'; mail_conn utl_smtp.connection; BEGIN mail_conn := utl_smtp.open_connection(mailhost, 25); utl_smtp.helo(mail_conn, mailhost); utl_smtp.mail(mail_conn, sender); utl_smtp.rcpt(mail_conn, recipient); -- If we had the message in a single string, we could collapse -- open_data(), write_data(), and close_data() into a single call to data(). utl_smtp.open_data(mail_conn); utl_smtp.write_data(mail_conn, 'This is a test message.' || chr(13)); utl_smtp.write_data(mail_conn, 'This is line 2.' || chr(13)); utl_smtp.close_data(mail_conn); utl_smtp.quit(mail_conn); EXCEPTION WHEN OTHERS THEN -- Insert error-handling code here NULL; END;
You can determine the host name of the local machine, or the IP address of a given host name from a PL/SQL program or stored procedure using the
UTL_INADDR package. You can find details about this package in the Oracle Database PL/SQL Packages and Types Reference. You use the results in calls to the
You can open TCP/IP connections to machines on the network, and read or write to the corresponding sockets, using the
UTL_TCP package. You can find details about this package in the Oracle Database PL/SQL Packages and Types Reference.
You can retrieve the contents of an HTTP URL using the
UTL_HTTP package. The contents are typically in the form of HTML-tagged text, but may be plain text, a JPEG image, or any sort of file that is downloadable from a Web server. You can find details about this package in the Oracle Database PL/SQL Packages and Types Reference.
UTL_HTTP package lets you:
Control the details of the HTTP session, including header lines, cookies, redirects, proxy servers, IDs and passwords for protected sites, and CGI parameters through the
Speed up multiple accesses to the same Web site using HTTP 1.1 persistent connections.
Construct and interpret URLs for use with
UTL_HTTP through the
UNESCAPE functions in the
Typically, developers have used Java or Perl to perform these operations; this package lets you do them with PL/SQL.
CREATE OR REPLACE PROCEDURE show_url ( url IN VARCHAR2, username IN VARCHAR2 DEFAULT NULL, password IN VARCHAR2 DEFAULT NULL ) AS req utl_http.req; resp utl_http.resp; name VARCHAR2(256); value VARCHAR2(1024); data VARCHAR2(255); my_scheme VARCHAR2(256); my_realm VARCHAR2(256); my_proxy BOOLEAN; BEGIN -- When going through a firewall, pass requests through this host. -- Specify sites inside the firewall that don't need the proxy host. utl_http.set_proxy('proxy.my-company.com', 'corp.my-company.com'); -- Ask UTL_HTTP not to raise an exception for 4xx and 5xx status codes, -- rather than just returning the text of the error page. utl_http.set_response_error_check(FALSE); -- Begin retrieving this Web page. req := utl_http.begin_request(url); -- Identify ourselves. Some sites serve special pages for particular browsers. utl_http.set_header(req, 'User-Agent', 'Mozilla/4.0'); -- Specify a user ID and password for pages that require them. IF (username IS NOT NULL) THEN utl_http.set_authentication(req, username, password); END IF; BEGIN -- Start receiving the HTML text. resp := utl_http.get_response(req); -- Show the status codes and reason phrase of the response. dbms_output.put_line('HTTP response status code: ' || resp.status_code); dbms_output.put_line('HTTP response reason phrase: ' || resp.reason_phrase); -- Look for client-side error and report it. IF (resp.status_code >= 400) AND (resp.status_code <= 499) THEN -- Detect whether the page is password protected, and we didn't supply -- the right authorization. IF (resp.status_code = utl_http.HTTP_UNAUTHORIZED) THEN utl_http.get_authentication(resp, my_scheme, my_realm, my_proxy); IF (my_proxy) THEN dbms_output.put_line('Web proxy server is protected.'); dbms_output.put('Please supply the required ' || my_scheme || ' authentication username/password for realm ' || my_realm || ' for the proxy server.'); ELSE dbms_output.put_line('Web page ' || url || ' is protected.'); dbms_output.put('Please supplied the required ' || my_scheme || ' authentication username/password for realm ' || my_realm || ' for the Web page.'); END IF; ELSE dbms_output.put_line('Check the URL.'); END IF; utl_http.end_response(resp); RETURN; -- Look for server-side error and report it. ELSIF (resp.status_code >= 500) AND (resp.status_code <= 599) THEN dbms_output.put_line('Check if the Web site is up.'); utl_http.end_response(resp); RETURN; END IF; -- The HTTP header lines contain information about cookies, character sets, -- and other data that client and server can use to customize each session. FOR i IN 1..utl_http.get_header_count(resp) LOOP utl_http.get_header(resp, i, name, value); dbms_output.put_line(name || ': ' || value); END LOOP; -- Keep reading lines until no more are left and an exception is raised. LOOP utl_http.read_line(resp, value); dbms_output.put_line(value); END LOOP; EXCEPTION WHEN utl_http.end_of_body THEN utl_http.end_response(resp); END; END; / SET serveroutput ON -- The following URLs illustrate the use of this procedure, -- but these pages do not actually exist. To test, substitute -- URLs from your own Web server. exec show_url('http://www.oracle.com/no-such-page.html') exec show_url('http://www.oracle.com/protected-page.html') exec show_url('http://www.oracle.com/protected-page.html', 'scott', 'tiger')
Packages for all of these functions are supplied with Oracle8i and higher. You use these packages in combination with the mod_plsql plug-in of Oracle HTTP Server (OHS). You can format the results of a query in an HTML table, produce an image map, set and get HTTP cookies, check the values of CGI variables, and combine other typical Web operations with a PL/SQL program.
Documentation for these packages is not part of the database documentation library. The location of the documentation depends on the particular application server you are running. To get started with these packages, look at their procedure names and parameters using the SQL*Plus
DESCRIBE HTP; DESCRIBE HTF; DESCRIBE OWA_UTIL;