2.1 Introduction to the Oracle ADF Service Request Demo

The SRDemo application is a realistic customer relationship management sample application that lets customers of a household appliance servicing company attempt to resolve service issues over the web. The application, which consists of sixteen web pages, manages the customer-generated service request through the following flow:

1. A customer enters the service request portal on the web and logs in.

2. A manager logs in and assigns the request to a technician.

3. The technician logs in and reviews their assigned requests, then supplies a solution or solicits more information from the customer.

4. The customer returns to the site and checks their service request and either closes the request or provides further information.

5. While a request is open, managers can review an existing request for a technician and if necessary reassign it to another technician.

Additionally, technicians can identify products in their area of expertise. Managers then use this information to assign service requests.

After the user logs in, they see only the application functionality that fits their role as a customer, manager, or technician.

Technically, the application design adheres to the Model-View-Controller (MVC) architectural design pattern and is implemented using these existing J2EE application frameworks:

• EJB Session Bean to encapsulate the application services of the entity classes

• JavaBean entity classes created from TopLink mappings and database tables

• JavaServer Faces navigation handler and declarative navigation rules

• Oracle ADF Faces user interface components in standard JSF web pages

• Oracle ADF Model layer components to provide data binding

As with all MVC-style web applications, the SRDemo application has the basic architecture illustrated in Chapter One, "Getting Started with Oracle ADF Applications".

This document describes in detail the implementation of each of these layers. Each chapter describes features of Oracle JDeveloper 10g and these technologies to build distributed web applications.

2.1.1 Requirements for Oracle ADF Service Request Application

The SRDemo application has the following basic requirements:

• An Oracle database (any edition) is required for the sample schema.

• You must create a database connection named "SRDemo" to connect to the SRDemo application schema. If you install the SRDemo application using the Update Center, this connection will have been created for you (see Section 2.2.3, "Creating the Oracle JDeveloper Database Connection").

• The JUnit extension for JDeveloper must be installed. If you install the SRDemo application using the Update Center, this extension will also be installed for you (see Section 2.2.5, "Running the Oracle ADF Service Request Demo Unit Tests in JDeveloper").

2.1.2 Overview of the Schema

Figure 2-1 shows the schema for the SRDemo application.

Figure 2-1 Schema Diagram for the SRDemo Application

The schema consists of five tables and three database sequences:

• USERS: This table stores all the users who interact with the system, including customers, technicians, and managers. The e-mail address, first and last name, street address, city, state, postal code, and country of each user is stored. A user is uniquely identified by an ID.

• SERVICE_REQUESTS: This table represents both internal and external requests for activity on a specific product. In all cases, the requests are for a solution to a problem with a product. When a service request is created, the date of the request, the name of the individual who opened it, and the related product are all recorded. A short description of the problem is also stored. After the request is assigned to a technician, the name of the technician and date of assignment are also recorded. All service requests are uniquely identified by an artificial ID.

• SERVICE_HISTORIES: For each service request, there may be many events recorded. The date the request was created, the name of the individual who created it, and specific notes about the event are all recorded. Any internal communications related to a service request are also tracked. The service request and its sequence number uniquely identify each service history.

• PRODUCTS: This table stores all of the products handled by the company. For each product, the name and description are recorded. If an image of the product is available, that too is stored. All products are uniquely identified by an artificial ID.

• EXPERTISE_AREAS: To better assign technicians to requests, the specific areas of expertise of each technician are define.

The sequences include:

• USERS_SEQ: Populates the ID for new users.

• PRODUCTS_SEQ: Populates the ID for each product.

• SERVICE_REQUESTS_SEQ: Populates the ID for each new service request.