Chapter 3 - The "Should-Have" Requirements: Creating an App for the General Public

Add code in the bean to capture the user's IP address.

At this stage, we've added the Accept and Reject buttons on the screen, as well as the sender/receiver poplist. In addition, we have the session bean behind the scenes that has method's in it to handle which button the user presses, as well as the last function getEnquirySourceCode() to retrieve the sender/receiver poplist's value.

Within the acceptTermsAndConditions and rejectTermsAndConditions methods, we want to gather details about the user, namely the user's IP address. This can be easily done via the following code in our EnquiryBean session bean:

public String getRemoteAddr() {
  String remoteAddr =
      ((HttpServletRequest)FacesContext.getCurrentInstance().    (cont next line)
           getExternalContext().getRequest()).getRemoteAddr();
  return remoteAddr;
}

Write the user's IP address and choice to the database.

This last task actually links us back to our first "should have" requirement, namely: Log the user's IP address plus whether they accept or reject the terms and conditions(as well as if the user is a sender or a receiver). At this stage we want to implement the current requirement; its solution will be coupled with the next requirement.

Like all other problems above, the easiest way to solve this one is to break into solvable parts. This particular problem breaks into the following parts:

• Find a suitable event when to record this information. In recording details about the user, we need to think about why we're recording the information. In our case, it is to log whether the user accepted or rejected the terms and conditions. The best time to record the user information is when the user actually presses the Accept or Reject button.
  
  
• Find a suitable code chokepoint to gather the data we need. Given that we now know we want to record the user information when the user presses the Accept or Reject button, the obvious code chokepoint in which to place our further logic in is the acceptTermsAndConditions and rejectTermsAndConditions methods we added to our EnquiryBean session bean. At this point, our bean looks as follows:

  public class EnquiryBean {
  
    String enquirySourceIndex;
    String termsAndConditions = "unset";
  
    public void setEnquirySourceIndex(String enquirySourceIndex) {
      this.enquirySourceIndex = enquirySourceIndex;
    }
  
    public String getEnquirySourceIndex() {
      return enquirySourceIndex;
    }
  
    public void setTermsAndConditions(String termsAndConditions) {
      this.termsAndConditions = termsAndConditions;
    }
  
    public String getTermsAndConditions() {
      return termsAndConditions;
    }
  
    // Intended for the "Accept" button for the terms and conditions
    public void acceptTermsAndConditions(ActionEvent event) {
      setTermsAndConditions("accepted");
    }
  
    // Intended for the "Reject" button for the terms and conditions
    public void rejectTermsAndConditions(ActionEvent event) {
      setTermsAndConditions("rejected");
    }
  
    public String getRemoteAddr() {
      String remoteAddr =
        ((HttpServletRequest)FacesContext.getCurrentInstance(). (cont next line)
                       getExternalContext().getRequest()).getRemoteAddr();
      return remoteAddr;
    }
  
    private String getEnquirySourceCode() {
      DCBindingContainer dcBinding = (DCBindingContainer)BindingContext.getCurrent().getCurrentBindingsEntry();
      
      DCControlBinding listControlBinding = dcBinding.findCtrlBinding("EnquirySourceList");
      FacesCtrlListBinding listBinding = (FacesCtrlListBinding)listControlBinding;
      Row row = listBinding.getRowAtRangeIndex(Integer.valueOf(enquirySourceIndex));
      Object[] enquiryListValues = row.getAttributeValues();
      String enquiryListCode = row.getAttribute("Code").toString();
  
      return enquiryListCode;
    }
  }
  

• Gather the data we wish to record, including the user's IP address, if they accept or reject the terms and conditions, and if the user is a sender or a receiver. Given that we now know the methods to gather the data, we can augment the acceptTermsAndConditions() and rejectTermsAndConditions() methods to easily retrieve the user IP address, the button selection, and the poplist selection, thanks to the getRemoteAddr(), getTermsAndConditions() and getEnquirySourceCode() methods we created earlier.
  
  We could create a new method storeUserInformation() that is called from both acceptTermsAndConditions() and rejectTermsAndConditions() as follows:

  // Intended for the "Accept" button for the terms and conditions
  public void acceptTermsAndConditions(ActionEvent event) {
    setTermsAndConditions("accepted");
    storeUserInformation();
  }
  
  // Intended for the "Reject" button for the terms and conditions
  public void rejectTermsAndConditions(ActionEvent event) {
    setTermsAndConditions("rejected");
    storeUserInformation();
  }
  
  public void storeUserInformation() {
    String userIPAddr = getRemoteAddr();
    String userTermsAndConditions = getTermsAndConditions();
    String userEnquirySource = getEnquirySourceCode();
  }
  

  As you can see, the storeUserInformation() method retrieves all the values that we're interested in persisting to the database. At this point it would be a really good idea to throw a breakpoint into this method and run the application under a debug session, to see what values are retrieved by the storeUserInformation() method. Before we write the data to the database, we should make sure that we actually have data to write and that we haven't made a mistake!

  If all goes well this leads us onto our final task:

• Write the user information to the database. At this point, we have three pieces of information that we want to record about the user: Their IP address, if they accepted or rejected the terms and conditions, and if they are a sender or receiver of a parcel.

  We again need to consider how we're going to accomplish this task. In order to write this data to the database we first need a table, so we'll beg our DBA to create the following:

  CREATE TABLE log_session 
  (log_session_id   NUMBER(10)   NOT NULL
  ,user_ip          VARCHAR2(15) NOT NULL 
  ,terms_conditions VARCHAR2(8)  NOT NULL
  ,enquiry_source   VARCHAR2(4)  NOT NULL
  ,datetime         DATE         NOT NULL 
  ,CONSTRAINT log_session_pkg PRIMARY KEY (log_session_id));
  

  We'll also ask our DBA to create the following sequence to populate the log_session_id:

  CREATE SEQUENCE log_session_seq;
  

  We then need to choose how we'll write the data to the table. From our session bean, we could just write raw JDBC to write the log entries. However this isn't ideal because we have the entire Oracle ADF Business Components model layer that is ideally suited to writing to the database and doesn't require us to write a single line of JDBC code which can be error-prone.

  We could create an Oracle ADF Business Components Entity Object and View Object based on the log_session table to write values to the database, utilizing our existing Oracle ADF Business Component Application Module. However, logging on to the database has one very special characteristic that makes reusing our existing Application Module that we created in our application inherently a problem.

  As you are aware, the Application Module within Oracle ADF Business Components, or more precisely the root Application Module, is responsible for transactional control with the database; the Application Module issues the commit and rollbacks that ultimately save the underlying View Object and Entity Object data to the database. So for a standard Oracle ADF Business Components CReated-Update-Delete (CRUD) like application our root Application Module will take care of allowing the user to make multiple changes to the underlying data and then saving the results.

  Yet in the case of logging, regardless of what the user is doing, we must save the results to the database as soon as a log entry is made. The log event requires its own transaction separate to that of the CRUD application's Application Module transaction, which our SearchPage is based on. The PL/SQL analogy of such a feature is known as an "autonomous transaction".

  One approach to solve this is to create a separate logging root Application Module that controls its own transactions, with its own View Object and Entity Objects that we can log through. However, there is an easier way. Utilizing the ability of the Oracle ADF Business Components framework, you can make JDBC calls to the database utilizing the current root Application Module's connection but wrapping the JDBC anonymous PL/SQL block in an autonomous_transaction pragma.

  To do this, we'll implement a method called logSession() in our AppModuleImpl:

  public void logSession(String userIp,
                         String termsConditions,
                         String enquirySource) {
  
    DBTransaction trans = getDBTransaction();
  
     
                                    
  SequenceImpl seq = new SequenceImpl("LOG_SESSION_SEQ", trans);
    setLogSessionId(seq.getSequenceNumber());
  
    CallableStatement statement = null;
  
    String plsql =
      "DECLARE "
     +  "PRAGMA AUTONOMOUS_TRANSACTION;"
     + "BEGIN "
     +  "INSERT INTO log_session "
     +  "(log_session_id, user_ip, terms_conditions, enquiry_source, datetime) "
     +  "VALUES "
     +  "(?,?,?,?,sysdate);"
     +  "COMMIT;"
     + "END;";
  
    statement = trans.createCallableStatement(plsql, 4);
    try {
      statement.setInt(1, getLogSessionId().intValue());
      statement.setString(2, userIp);
      statement.setString(3, termsConditions);
      statement.setString(4, enquirySource);
  
      int rows = statement.executeUpdate();
  
    } catch (SQLException s) {
      throw new JboException(s);
    } finally {
      try {
        if (statement != null)
          statement.close();
      } catch (SQLException s) { /* ignore */ }
    }
  }
                                  

  Note how we retrieve the log_session_seq and store it in a variable of the AppModuleImpl via a call to setLogSessionId. The retrieved LogSessionId sequence number will become useful later. In order to store the LogSessionId in the AppModuleImpl, we've also defined the following instance variable and accessor methods:

  private Number logSessionId;
  
  public void setLogSessionId(Number logSessionId) {
    this.logSessionId = logSessionId;
  }
  
  public Number getLogSessionId() {
    return logSessionId;
  }
  

  In order to store instance variables within the Application Module, that will be persisted over many user requests, we need to override the activateState and passivateState() methods in the AppModuleImpl as follows:

  private static final String LOG_SESSION_ID = "jbo.logSessionId";
  
  @Override
  protected void passivateState(Document document, Element element) {
    Number logSessionIdNum = getLogSessionId();
    if (logSessionIdNum != null) {
      int logSessionIdInt = logSessionIdNum.intValue();
      Node node = document.createElement(LOG_SESSION_ID);
      Node cNode = document.createTextNode(Integer.toString(logSessionIdInt));
      node.appendChild(cNode);
      element.appendChild(node);
    }
  }
  
  @Override
  protected void activateState(Element element) {
    super.activateState(element);
    if (element != null) {
      NodeList nodeList = element.getElementsByTagName(LOG_SESSION_ID);
      if (nodeList != null) {
        for (int i = 0, length = nodeList.getLength(); i < length; i++) {
          Node child = nodeList.item(i).getFirstChild();
          if (child != null) {
            try {
              setLogSessionId(new Number(child.getNodeValue()));
              break;
            } catch (SQLException ex) {
              new JboException(ex.getMessage());
            }
          }
        }
      }
    }
  }
  

  We then modify our EnquiryBean's storeUserInformation() method to call the Application Module's logSession() method

  public void storeUserInformation() {
    String userIPAddr = getRemoteAddr();
    String userTermsAndConditions = getTermsAndConditions();
    String userEnquirySource = getEnquirySourceCode();
    
    DCDataControl dc = BindingContext.getCurrent().getDefaultDataControl();
    ApplicationModule am = (ApplicationModule)dc.getDataProvider();
    AppModuleImpl service = (AppModuleImpl)am;
    
    service.logSession(userIPAddr, userTermsAndConditions, userEnquirySource);
  }
  

  Note that in the Oracle JDeveloper source editor it may be necessary to recompile (rebuild) the Model project and then the ViewController project, to get Oracle JDeveloper to recognize the AppModuleImpl's new logSession() method from the Model project. Otherwise, you may see a syntax error with no chance of importing the class to use. Once you have rebuilt both projects, then import model.AppModuleImpl and the syntax error will disappear.

  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 chapter we have added code to satisfy the "Should-Have" requirements of our application, including logging of the user's IP address if they accept our terms and conditions, and enhancing the search capabilities. In the next chapter we will add functionality to log all search criteria entered by the user, as well as the number of records returned. Click here to see "Taking an Oracle ADF Application from Design to Reality" description and Table of Contents