Click here to see "Taking an Oracle ADF Application from Design to Reality" description and Table of Contents

In this section, our
COULD-Have main requirement is to log all search criteria entered by the user, as well as the number of records returned. This will enable us in the future to see how useful our search page is, or if the users are having difficulty in using it.

Again, we need to break down these requirements into discrete solvable units:

Create an additional logging table to store query results.

For each session there may be one or more queries/searches, each returning zero or one or more records. Accordingly, we want to create an additional logging table in the database that records these facts. Once again we'll beg our DBA to create a new table in the database:

Given that we have our log_query table to store information about the query event, we now need to identify a chokepoint method in the Oracle ADF framework to capture the event, so we can write to the log_query table.

In Oracle ADF Business Components, in the ViewObjectImpl the method executeQuery() is responsible for executing the View Object's query against the database. We can override this method in the ParcelViewImpl as follows:

As you can see we want to log the query to the log_query table before doing the query, and after the query in the same record we'll update the number of records fetched. Within the AppModuleImpl we'll define the insertLogQuery() and updateLogQuery() methods as follows:

You'll note that we have the setLogQueryId() and getLogQueryId() methods to write and read the next log_query_seq value from the database to an instance variable in the AppModuleImpl, similar to what we did for the LogSessionId. We'll add the following code to the AppModuleImpl:

For each query, we want to save a copy of the search parameters and their values. Later on, we can see what sorts of searches our users are doing and find out if, in combination with the log_query table record, they are successfully returning any records. So for the last time, we'll beg our DBAs to create another logging table in the database:

Note how the table has a foreign key to our log_query table's primary key enabling us to track the parameters against the queries for the user session.

Identify a framework chokepoint method to capture the enquiry search parameters and write them to our logging tables.

Thanks to our earlier work we know that the ViewObjectImpl has a chokepoint method executeQueryForCollection() that is called before the View Object's query is executed. That in turn allows us to inspect the bind variables entered by the user. Currently our executeQueryForCollection() method looks like this:

If we run our SearchPage, and either accept or reject the terms and conditions, the user information is written to the log table.

Summary

In this section we have added code to satisfy the
COULD-Have requirements of our application, including logging all search criteria entered by the user, as well as the number of records returned. The
next and final chapter shows how we can add some functionality to prevent malicious access.
Click here to see "Taking an Oracle ADF Application from Design to Reality" description and Table of Contents