Let me talk a little about the flow in this configuration. When a user opens the APEX URL, a HTTP/HTTPS request is sent to the XML DB HTTP server which is a part of XMLDB. This request then flows through EPG to mod_plsql. mod_plsql authorizes the request using the wwv_flow_epg_include_modules.authorize procedure. The APEX engine, in combination with the OWA web toolkit and user-defined stored procedures and functions, generates the response HTML. Calls to the user-defined functions and procedures are coded by the developer in the APEX application. Once the response HTML has been generated, mod_plsql gives the response back to the user using XMLDB HTTP server. I have drawn this process flow in the following diagram:

Now let us see the process to configure the XML DB HTTP server (also called XMLDB protocol server), bundled with database, to work on port 8080.

The port on which the inbuilt XML HTTP server operates, can be configured using the DBMS_XDB.sethttpport procedure as shown in the following screenshot:

The account status of the XDB schema should be OPEN. Check this using the following SQL script:

SELECT account_status
FROM dba_users
WHERE username = 'XDB';

Enter your XDB schema password (the XDB schema is created with database installation) after opening the URL: http://<hostname>:8080. You should be able to see the following page:

Oracle XML DB protocol server maintains a shared pool of sessions, but these connections are to handle the client web requests. Each protocol connection or client request is associated with one session from the pool of the protocol server. After a connection is closed, the session is put back into the shared pool and can be used to serve later connections.

To enable the Oracle XML DB repository to use secure HTTP connections (HTTPS), a DBA must configure the database accordingly. This configuration includes the setting of the http2-port and http2-protocol parameters, enabling the HTTP Listener to use SSL, and enabling the launching of the TCPS dispatcher. After doing this, the DBA must restart the database and the Listener.

Now let us check the DADs configured in the EPG. To do this, we will first have to compile the Chapter1 package in PACKT_SCHEMA. If you have not already created PACKT_SCHEMA, the user may check the Steps to create PACKT_SCHEMA section of the Appendix for the steps to do this. Execute the following command from SQLPLUS as SYSDBA to create CHAPTER1 package.. Make sure that you are running SQLPLUS from the directory that holds 4-98-9_01_chapter1.sql. Put PACKT_SCHEMA in the Enter the schema in which you want to compile this code: prompt:

SQL> @4-98-9_01_chapter1

Now execute the following two statements:

SQL> set serveroutput on
SQL> exec packt_schema.chapter1.get_dad_list();

The output will list apex along with the other DADs configured in the EPG. Run the following statement to find the configured database username for the apex DAD:

SQL> exec packt_schema.chapter1.chk_apex_dad_usr_nam();

You should get the output as shown in the following screenshot:

The Database and web interaction in DAD and Listener configurations section of the Appendix demonstrates the process of creating a DAD and assigning privileges to it. The demonstration also includes the use of this DAD for database and web interaction. Principally, APEX does the exact same thing. The difference is that APEX does it on a bigger scale.

Using the configurations done in the DAD, the EPG determines the database account to be used to fulfill the request, and authenticates the request based on the request-validation-function attribute configured for the DAD.

The EPG configuration of any database can be found out by running the following script:

<OracleHome>\RDBMS\ADMIN\epgstat.sql

You should get the output after running this script, as shown in the following screenshot:

Depending on the requirements, we can choose, from a number of possible server combinations for external mod_plsql configuration. The possibilities are: Native Apache, Oracle HTTP Server (OHS), Oracle Application Server (OAS), or OHS + WebLogic Server.

Let me now talk about the flow in this configuration and how it is different from internal mod_plsql configuration. The only difference between external and internal mod_plsql configuration is that the mod_plsql plugin is external in the external configuration. So, if the EPG configuration (internal mod_plsql configuration) is a perfect human, then external configuration is a human with its heart beating outside the body. That may seem like a weird analogy, but that's what it is. Since mod_plsql is a module of Apache HTTP server, and since OHS is based on Apache, and since OHS is a component of OAS, both OHS and OAS can also be used for external mod_plsql configuration. OHS also offers HTTP services in OFM (Oracle Fusion Middleware) and can be configured in front of the WebLogic Server. So it is possible to configure OHS + WebLogic and then use the mod_plsql in OHS for the DAD configuration.

The following diagram shows the external mod_plsql configuration:

External Apache has configuration files called httpd.config and dads.conf.

dads.conf holds the name of the DAD of APEX. The dads.conf file has a virtual path mentioned in the Location directive. The URL of external mod_plsql configuration looks like the following:

http://<hostname>:<port>/<virtual_path_in_location_directive>/f?p=app_id:page_no:session_id:Request:Debug:ClearCache:Params:ParamValues:PrinterFriendly

The following is a screenshot of a typical dads.conf file. Check out the similarities between the dads.conf file and the attributes configured for EPG:

Directives such as PlsqlRequestValidationFunction (refer the previous screenshot), which are allowed in the context of the Location directive, help us configure the attributes which get configured in EPG using the dbms_epg package. Note that the wwv_flow_epg_include_modules.authorize procedure is declared as the validation function in the dads.conf file. The same function is also configured as the value of the request-validation-function attribute of the apex DAD, which is created along with the installation of Oracle 11g. We can check this out using the following script:

SQL> exec packt_schema.chapter1.chk_apex_req_val_funct();

The wwv_flow_epg_include_modules.authorize procedure is called before creating an APEX session. This function in turn calls the wwv_flow_epg_include_mod_local function. The Gods of APEX have given you the freedom to invoke our own procedures using the apex DAD. All functions on which the ANONYMOUS schema have execute privileges, and have been declared in the wwv_flow_epg_include_mod_local function, can be invoked using the DAD of apex. Let us now have a look at the wwv_flow_epg_include_mod_local function:

create or replace function wwv_flow_epg_include_mod_local(
    procedure_name in varchar2)
return boolean
is
begin
    --return false;
    if upper(procedure_name) in (
          '') then
        return TRUE;
    else
        return FALSE;
    end if;
end wwv_flow_epg_include_mod_local; 

To invoke the procedures from apex DAD, comment the return false; statement and mention the procedure name which you want to invoke using the apex DAD in the in list of the if statement.

If you wish to call your own procedures in Listener configuration, then you can configure the same in the defaults.xml file of the Listener. A demonstration of calling a custom procedure in Listener configuration is shown in the The Listener configuration section of Appendix.

Similarly, we can see that other attributes configured in the EPG DAD are also configured in the external DAD configuration using the Location directive of the dads.conf file. In the previous screenshot of dads.conf file, the directive <Location> has /pls/apex as the virtual path. So you would have the following URL for your apex DAD with this configuration file:

http://<hostname>:<port>/pls/apex/f?p=4550

Httpd.conf is another important character in the story. If dads.conf is a super hero, then httpd.conf is super hero's brother and has got his own set of powers. It can hide the trademark APEX URL by helping you set virtual hosts. The RewriteRule directive in httpd.conf takes the concept of concealing the URL to a whole new level. It lets you define patterns of characters and if the URL entered by the user matches the pattern in this directive, then it will redirect to a page which is also defined in the directive. So you can have any URL for APEX, define its pattern in the RedirectRule directive, and then have your APEX application's URL as the URL to which the server will redirect.