Skip navigation.
Downloads | Product Documentation | Support

Liquid Data by Example

# Understanding the Avitek Customer Self-Service Sample Application

This chapter provides a brief overview of the Avitek Customer Self-Service Sample Application (SampleApp), including a description of data sources, queries, and other application components necessary to develop the SampleApp.

- Quick Start
- Introduction
- Case for an Avitek Self-Service Web Site
- Anatomy of the Avitek SampleApp
- Running the Avitek Customer Self-Service Sample Application in a Browser
- Viewing the Avitek Customer Self-Service Sample Application Source
- Where To Go From Here

## About Avitek

Avitek is a retailer that has grown through acquisitions. Because of this growth it has two different order management systems (OMS) to manage electronics and apparel orders. These systems are under separate platforms and are not integrate with each other. Avitek has a customer relationship management (CRM) system to manage customer profile information. Finally, Avitek also has a Customer Service system to manage the support cases for Electronic products.

Avitek now want to build a customer self-service web site and this chapter will walk you through the the challenges in creating this application and how SampleApp was built to satisfy Avitek's needs.

# Quick Start

To run the Avitek Customer Self-Service Sample Application:

1. Make sure you have installed Liquid Data 8.1 with samples (the full installation) into a WebLogic Platform 8.1 directory.
2. Start the Liquid Data Samples server, as described in Set Up and Run the Samples.
3. Run the SampleApp:

>     Start—>Programs—>BEA WebLogic Platform 8.1—>BEA Liquid Data for WebLogic 8.1—>Liquid Data Samples
>     —>Sample Application Home

Alternatively, use the following URL to open the SampleApp login page:

>     http://localhost:7001/LDSampleApp/login.jsp

Log in using one of the names shown in the dialog box. Simply move your mouse over the login name of your choice to fill-in the name and password.

Figure 1-1 Sample App Login Page

# Introduction

The Avitek Customer Self-Service Sample Application shows how you can use Liquid Data to solve the type of data integration problems frequently faced by Information Technology (IT) managers and staff. Issues include:

- What is the best way to normalize data drawn from widely divergent sources?
- Having normalized the data, can you access it, ideally through a single point of access.
- Once you have such a single point of access to your data, can you develop reusable queries that are easily tested, stored, and retrieved?
- Once you have your query set, can you easily incorporate results into a widely available application?

Other questions may occur. Is the data-rich solution scalable? Is it reusable throughout the enterprise? Are the original data sources transparent to the application — or do they become an issue each time you want to make a minor adjustment?

# Case for an Avitek Self-Service Web Site

A survey commissioned by Marketing found Avitek customers to be dissatisfied with the call-in wait time required to track orders or update customer information. In a focus group the idea of a self-service web site resonated with Avitek customers. Customer Service agreed; they have been requesting such a site for years, but the internal costs were always above budget. But now that Marketing is on board ...

## Design Requirements

Site requirements seem simple. Customers need to:

- Log in and out.
- Review order status. A Home page will provide information on open orders, including product names and quantities of items ordered, order amount, shipping instructions, and a summary of any open customer service cases, with details.
- Review order history.
- Review and change personal profile information.
- Search through orders. A sample page provides the ability to retrieve orders based on a range of prices, range of dates, etc.

A business analyst develops the requirements for the application:

- A7/24 web site
- Less than 10 pages
- Low-maintenance
- Easily modified.

An application/UI designer starts "spec out" the required JSPs.

## Information Technology (IT) Comes On Board: The Moment of Truth

Then an IT data architect analyzes the data requirements. This turns up a problem. In surveying the information needed by the application -- customer data for one data source, order data from two very separate divisions of the company (two more data sources), and customer support data (a fourth data source) — the architect realizes that integrating data from these diverse data sources will be complicated and time consuming. Challenges included:

- Cost of development. Writing the code to access and integrate data from multiple diverse data sources would take more time than originally expected and require more expensive and scarcer resources.
- Time to market. Developing and testing an application against multiple data sources would extend beyond the date when the application is needed.
- Cost of testing and maintenance. High.

Perhaps most frustrating: little of the specialized code needed by the application can be reused.

## Search for an Alternative

Developing a unified view into distributed data is one of the most persistent challenges faced by IT departments. Just when you get all the available data sources normalized, new sources appear that must be dealt with, but which also make yesterday's data integration solution obsolete.

This problem is so pervasive that each year thousands of arguably critically-needed applications go unwritten, are delayed, or are delivered in highly compromised form because of the data integration challenges faced by even the most sophisticated enterprises.

Compared to the above, the SampleApp team preferred a solution that:

- Provides a layer of data abstraction so that queries can treat highly-divergent data sources as a single, virtual data source.
- Allows development of human-readable, reusable queries.
- Can be easily accessed by consuming applications through a simple API.
- Protects the integrity and security of the underlying data.

# A Solution

When Avitek looked at Liquid Data, they found a product that addressed the underlying challenges posed by the apparently simple SampleApp:

- In Liquid Data, queries are described in simple, declarative text.
- Addressing the problem of data access, Liquid Data provides data integration through a highly-accessible graphical interface.
- Once data integration is achieved, persistent queries are generated.

Specifically, the features that the team found most appealing included:

Data Access. First, Liquid Data puts a common face on the data. This allows you to access information from anywhere in the company — or beyond — through an easily-created virtual data access layer. Once accessed, data can easily be aggregated through a combination of reusable queries and views that are maintained in the Liquid Data server.

Query Development. Then, once the data is collected under a single point of access, it is not difficult to write queries that pull data together from these disparate sources and present a common, reusable view ready for more specialized queries.

The declarative form of Liquid Data artifacts (queries) makes them very readable. These queries are easily developed in the Data View Builder.

Query Deployment. Once developed, queries are easily integrated into a client application such as WebLogic Workshop.

Queries are as readily available to processes client applications thorough a variety of access methods such as an EJB API or a JSP tag library. Alternatively, these queries can also be accessed as web services.

Integration. Business logic for the SampleApp is provided by the NetUI and page flow features of WebLogic Workshop.

However, Liquid Data queries are easily integrated and maintained within the business logic of any J2EE application.

## Anatomy of the Avitek SampleApp

The SampleApp shows how Liquid Data-generated queries can aggregate data from potentially highly disparate data sources, allowing access to that data through a single point of access that itself is easily integrated with the application.

Figure 1-2 Avitek Queries Supported by the rtlBaseView

Note: To simplify the running of the SampleApp, the multiple data sources described in this document are simulated using the PointBase RDBMS which is shipped with Liquid Data. In the original implementation, these databases were represented by major vendor RDBMS systems.

## Finding the Components

The SampleApp is located in the following directory:

>     <WL_HOME>/samples/liquiddata/SampleApp

SampleApp project files are available from:

>     <WL_HOME>/samples/liquiddata/SampleApp/DVBProject

SampleApp controls, pages, processes, and resources used to create the SampleApp can be found at:

>     <WL_HOME>/samples/liquiddata/SampleApp/LiquidDataSampleApp

Schemas used in the SampleApp are in the following directory:

>     <WL_HOME>/samples/domains/liquiddata/ldrepository/schemas/rtl

The Workshop `.work` file for the SampleApp is located at:

>     <WL_HOME>/samples/liquiddata/SampleApp/SampleApp.work

When you install Liquid Data with the WebLogic Platform, the source code for the SampleApp can be accessed from WebLogic Workshop. For instructions, see Viewing the Avitek Customer Self-Service Sample Application Source.

For additional information and references, see:

- Running the Avitek Customer Self-Service Sample Application in a Browser.
- "Using Workshop Controls to Develop Liquid Data Applications" in the Application Developer's Guide for the specific steps required to create the Liquid Data control.

## Analyzing the SampleApp Architecture

Several BEA technologies are used in the Avitek Customer Self-Service Sample Application.

- Query Development. Queries and a data view that draw data from multiple data sources are created in the Data View Builder.
- Query Access. The WebLogic Workshop Liquid Data Control provides programmable access to Liquid Data queries.
- Client-side Development. WebLogic Workshop also provides an environment for building application logic through NetUI, page flow, and other technologies.

### Steps Used in Developing the SampleApp

The basic steps used to develop the Avitek Customer Self-Service Sample Application were:

1. In Liquid Data:

- Identify and analyze data sources
- Configure Liquid Data to access these sources

2. In the Data View Builder:

- Design and test queries and a data view
- Deploy queries to the Liquid Data repository

3. In WebLogic Workshop:

- Create a Liquid Data control
- Add deployed queries to the Liquid Data control
- Develop necessary client-side logic for the application

4. Test and deploy your application.

### Available Data Sources

Although the SampleApp is very simple, the underlying data acquisition is potentially complex because date comes from four heterogeneous data sources. These are:

- Customer Relationship Management (CRM) system. CRM data (customer and credit card information) is stored in a database called `RTL-CUSTOMER`.
- Order Management System (OMS). Avitek has two order management systems:

- Electronic products. OMS information is available from a legacy system via a web service. The web service has a method called `getOpenOrders()`, which takes a customer ID as input and returns a list of customer open order information through a web service, `ElectOrderService`.
- Apparel products. Information is maintained on site in a second database. This is represented in Liquid Data as `RTL-APPL-OMS`.

- Customer Service. Service data is stored in a third database. The schema for this data is `RTL-SERVICE`.

### Avitek Customer Self-Service Sample Application Queries

The following section describes work done by the main SampleApp queries.

#### Data View Source (RTLBaseView.xq)

The RTLBaseView query forms the basis of the parameterized data view of the same name (`RTLBaseView.xv`) that supplies data for the Avetek SampleApp queries. Every element in the four underlying data sources is mapped to the `customerBaseView.xsd` target schema. A `custid` query parameter identifies the particular customer.

Figure 1-3 Project Showing RTLBaseView Query, the Basis for the Data View Underlying RTLSample Queries

A Data View Builder project is available that can help in understanding how this query was developed. You can review and run this project from:

>     <WL_HOME>/samples/liquiddata/SampleApp/DVBProject/RTLBaseView.qpr

Once perfected, the RTLBaseView.xq query is turned into a data view. Figure 1-4 shows the data view consolidates disparate data sources into a single complex object which can then be easily mapped to the target schema.

The CustomerView project (`CustomerView.qpr`) illustrates how the RTLBaseView data view is used to free the query developer from a need to directly access and map multiple data sources to the target schema. Instead, the RTLBaseView data source becomes a source schema that contains a superset of the data elements needed by any particular query.

Of course other data sources could also be used in creating a query but in this particular case a more effective design consolidating all the data elements into a since data view data source.

#### Default View (CustomerView.xq)

This query populates the home page of the SampleApp.

Figure 1-4 CustomerView Project Illustrating How the RTLBaseView Data View Supports Query Development

Using the RTLBaseView data view, the query returns:

- For a specific customer ID: FIRST_NAME and LAST_NAME.
- For Apparel open orders: ORDER_ID, ORDER_DATE, TOTAL_ORDER_AMOUNT, shipping information, and PRODUCT_DESC and QUANTITY for each items in the order.
- For Electronics open orders: the same information as is returned for open orders for apparel.
- For any customer support cases associated with the customer ID: CASE_ID, CASE_TYPE, PRODUCT_ID, STATUS, and STATUS_DATE.

A Data View Builder project is available that can help in understanding how this query was developed. You can review and run this project from:

>     <WL_HOME>/samples/liquiddata/SampleApp/DVBProject/CustomerView.qpr

#### Customer Profile (ProfileView.xq)

Retrieves information about customers from a RDBMS system maintained by the CRM software.

The query `ProfileView.xq` returns:

- For a given customer ID: name, email address, SSN, BIRTH_DATE, DEFAULT_SHIP_METHOD, and two Booleans identifying if the customer wants email notification of shipment and an online statement.
- For a given customer ID: address information such as ADDR_ID, CUSTOMER_ID, name, address, phone, ALIAS, STATUS, and whether the address is the default.
- For a given customer ID: credit card information such as CC_ID, CUSTOMER_NAME, CC_TYPE, CC_BRAND, LAST_DIGITS, EXPIRATION_DATE, ALIAS, STATUS, and ADDR_ID.

A Data View Builder project is available that can help in understanding how this query was developed. You can review and run this project from:

>     <WL_HOME>/samples/liquiddata/SampleApp/DVBProject/ProfileView.qpr

#### Electronic Division Order Detail (RTLElecOrderDetail.xq)

Provides customers with detailed information on any particular order selected from the History or Home page. Data originates in a proprietary order management system (OMS) which is made available to Liquid Data through a web service.

The query `ElecOrderDetail.xq` returns:

- For a given order ID: order information (ORDER_DATE, STATUS, and so forth).
- For a given customer ID and order ID: ship to information (CUSTOMER_ID, address information, STATUS, and so forth).
- For a given customer ID and order ID:

- Bill to information (name of purchaser, DAY_PHONE, ALIAS, STATUS, IS_DEFAULT, and so forth).
- Tracking information (TRACKING_NUMBER and information about each item in the order such as LINE_ITEM_ID, ORDER_ID, PRODUCT_ID, PRODUCT_DESC, QUANTITY, PRICE, and STATUS).

A Data View Builder project is available that you can use to understand how this query was developed. You can review and run this project from:

>     <WL_HOME>/samples/liquiddata/SampleApp/DVBProject/ElecOrderDetailView.qpr

#### Apparel Division Order Detail (AppOrderDetailView.xq)

Provides a customer with detailed information on any particular order found in the order history or on the Home page. The data originates in a RDBMS system.

The query `AppOrderDetailView.xq` returns the same data elements as `ElecOrderDetailView.xq`

A Data View Builder project is available for this query. You can review and run this project from:

>     <WL_HOME>/samples/liquiddata/SampleApp/DVBProject/ApplOrderDetailView.qpr

#### Order Summary (OrderSummaryView.xq)

Provides customers with summary information about all their orders with the company.

The query `RTLOrderSummaryView.xq` returns:

- For a range of dates: Apparel sale summary order information (ORDER_ID, ORDER_DATE, TOTAL_ORDER_AMOUNT, SHIP_TO_NAME, ESTIMATED_SHIP_DATE, TRACKING_NUMBER plus PRODUCT_DESC and QUANTITY for each items in the order).
- For a range of dates: Electronics sale summary information in the same form as for an Apparel sale (ORDER_ID, ORDER_DATE, and so forth).

A Data View Builder project is available for this query.You can review and run this project from:

>     <WL_HOME>/samples/liquiddata/SampleApp/DVBProject/OrderSummaryView.qpr

Table 1-5 shows the relationship between the data sources, major data elements (for RDBMS systems this means tables and columns), sample application JSPs, and the SampleApp web pages.

Table 1-5

Customer Page | Data Source(s) | Primary Data Elements | JSP
--- | --- | --- | ---
Home page | Customer Relationship Management (CRM) RDBMS Order Management System (OMS) RDBMS OMS via a web service Customer Service RDBMS | from RTL_Customer CustID, name from RTL_APPL_OMS Order summary information from ElectOrdeService Order summary information from RTL_SERVICE Open case information | `DefaultView.jsp`
Profile page | Customer Relationship Management (CRM) RDBMS | from RTL_Customer Customer profile Bill-to, ship-to address Credit card information | `ProfileView.jsp`
Details (accessible from Home page or History page) | For apparel order detail: Order Management System (OMS) RDBMS Customer Relationship Management (CRM) RDBMS For electronics order detail: OMS via a web service Customer Relationship Management (CRM) RDBMS | For apparel order detail: from RTL_APPL_OMS Order detail information tracking information from RTL_Customer CustID, name, ship to address, billing information including last 5 digits of credit card For electronics order detail: (same as apparel order detail) | `OrderDetail.jsp`
History page | Same as Home page but no use of CS system | Same as Home page but shows no case information | `OrderHistory.jsp`

SampleApp Primary Pages and Their Data Sources, Primary Data Elements, and Associated JSP

# Running the Avitek Customer Self-Service Sample Application in a Browser

If you have not already done so, use Quick Start to start the Avitek Customer Self-Service Sample Application. The following table shows the combination of login names and passwords:

Table 1-6

Name | Password
--- | ---
`Steve` | `steve123`
`Jack` | `jack1234`
`Tim` | `tim12345`
`Homer` | `homer123`
`Jerry` | `jerry123`

Sample App Login Names and Passwords

Once a customer logs in, she or he sees the Customer Order Status screen (Figure 1-7). This page also serves as the Home page of the application.

### SampleApp Home Page

Figure 1-7 SampleApp Home Page

The Home page summarizes the customers order status. This customer service home page is controlled by a JSP called default.jsp. Call-outs show the underlying data sources. The page derives its font and other look-and-feel characteristics from a cascading stylesheet. For additional information on how this page is created, see Page from the SampleApp.

## Order Search

In addition to being able to get Order History and Profile information from the SampleApp Home Page, the customer can search for specific orders based on order dates, items, or amounts.

Figure 1-8 Avitek Customer Self-Service Sample Application Search Form

The JSP for this page initiates a small Java program that incorporates the customers input and generates an XQuery based on the selected parameters. See Ad Hoc Query.

# Viewing the Avitek Customer Self-Service Sample Application Source

The JSP pages and connection logic for the SampleApp were created in WebLogic Workshop. You can view the source for the SampleApp in WebLogic Workshop.

To open the SampleApp project, open the `SampleApp.work` file in WebLogic Workshop. The full path is:

>     <WL_HOME>/samples/liquiddata/SampleApp/SampleApp.work

Note: If you are already running WebLogic Workshop or have previously run it with a different server setting, you may need to fix your application properties settings. If necessary, select the following from the WebLogic Workshop menu:

Tools —> Application Properties —> WebLogic Server

When opening the Avitek Customer Self-Service Sample Application in WebLogic Workshop, you initially see the application components and the work area.

Figure 1-9 Initial Avitek Customer Self-Service Sample Application Initial Project View

WebLogic Workshop allows you to work with the application you have under development as components or files. Web pages can be displayed and run, page flows and application logic can be developed and tested.

Note: Getting Started with WebLogic Workshop fully describes the development environment and how it can be used to build enterprise applications on the WebLogic Platform 8.1. The on-line document includes numerous examples and tutorials.

The WebLogic Workshop Samples application contains a number of samples relevant to data access and XML. See:

<WL_HOME>/samples/workshop/SamplesApp/`SamplesApp.work`

## WebLogic Workshop Components of the SampleApp

All the components of the Avitek Customer Self-Service Sample Application are available from the Liquid Data Samples directory. See Finding the Components.

Figure 1-10 Avitek Customer Self-Service Sample Application Application Palette

When you click on the LiquidDataSampleApp folder in WebLogic Workshop, a number of components become visible. The following components are of special interest.

- Controls folder. For the SampleApp there are three controls:

- RTL_Control.jcx This control contains methods for each stored query used in the Liquid Data application.
- UpdateAddress.jcx`` This control contains methods that allow for updates to customer profile information.
- UpdateCreditCard.jcx This is a control that contains methods to update customer credit card information.

- Pages folder. Contains the JSPs and the page flow controller, `demoPageFlowController.jpf`, that make up the SampleApp.
- Resources folder. Contains common resources such as the HTML style sheet, graphics files and common JSPs such as headers and footers.
- WEB-INF folder. Contains application source components, in particular struts and NetUI components that come with WebLogic Workshop.

### Liquid Data Control

The RTLControl contains automatically-generated methods based on a set of Liquid Data stored queries selected by the developer of the control. For information on accessing Liquid Data queries in WebLogic Workshop see "Select Queries to Add to a Control" in Using Workshop Controls to Develop Liquid Data Applications in the Application Developer's Guide.

Figure 1-11 Design View of Liquid Data Control and Control Methods

For information on deploying a Liquid Data stored query see Deploying a Query in the Testing Queries chapter of Building Queries and Data Views.

A portion of the Source View of the `RTLOrderSummary` method of the `RTLControl.jcx` file is shown in Figure 1-12. Note that the name of the target schema for the query appears in comments.

Figure 1-12 Source view of a Liquid Data Control

.

Each method in the Liquid Data Control corresponds to a stored query. Each method returns an `XMLBean` type. The XMLBeans are generated when the control is created, and are stored in the Libraries directory of the WebLogic Workshop application.

### Application Pages

In the Pages folder you can find the Java Server Pages (JSPs) that make up the Avitek Customer Self-Service Sample Application. These were constructed entirely in WebLogic Workshop using queries from the Liquid Data control and NetUI graphical elements.

Figure 1-13 JSP Pages in the SampleApp

### Application Logic: Page Flow

The Avitek Customer Self-Service Sample Application is composed of java server pages (JSPs) that are managed by a WebLogic Workshop PageFlowController. In the Avitek Customer Self-Service Sample Application the PageFlowController is named`demoPageFlowController.jpf`.

From an application logic perspective, whenever a user releases control of a page by selecting an option such as Next, Previous, Ok, Cancel, and so forth, application logic returns to the PageFlowController. Once that logic is processed, the user see with the appropriate web page.

Using WebLogic Workshop you can inspect, change and extend page flow programmatically or graphically. There are three views of page flow: page flow, action, and source.

#### Page Flow: Flow View

The WebLogic Workshop page flow schematic (Figure 1-14) illustrates graphically the relationship between JSPs, including has modeless page flow is determined by user actions.

When you click on a particular page name, the page opens in the WebLogic Workshop development browser.

Figure 1-14 Avitek Customer Self-Service Sample Application Page Flow

The three primary elements found in Page Flow View are:

- Pages. Clicking on a particular page will open the page for editing.
- Actions. The transition between pages is controlled by actions. Specific actions are user-driven such as in the case of a user accepting an option ("OK") or deciding against it ("Cancel") via a particular form or dialog box.
- Source. When source is selected, the code for the page appears in the work area.

#### Page Flow: Action View

The Action View tab is help in finding the location of page flow actions associated with the Avitek Customer Self-Service Sample Application.

Figure 1-15 Avitek Customer Self-Service Sample Application Action View

#### Page Flow: Source View

The PageFlowController file contains several parts:

- Declarations of graphical elements in the application.
- Public transient simple and array variables that facilitate and persist application logic between pages.
- `@jpf:forward` calls within comments that associate user actions with appropriate target JSPs.
- Queries and associated logic.

### Inter-page Navigation

The code in Listing 1-1 shows the application's entry point and page flow options, as determined by whether the customer's login efforts qualify as `success` or `invalidLogin`.

Listing 1-1 also shows how customer details are obtained from Liquid Data through a query. Some things to note in examining this section of code are:

- A single `if/else if` statement allows you to pull data from two independent data sources.
- XQuery makes it possible to access data through Java rather than having to enter or preformat SQL statements.

Listing 1-1 Page Flow Logic Supporting the OrderDetails.jsp

>     /**
>          * @jpf:action
>          * @jpf:forward name="success" path="OrderDetails.jsp"
>          */
>         protected Forward ViewOrderDetails()
>         {
>             String oId = getRequest().getParameter("orderId");
>             String orderType = getRequest().getParameter("orderType");

>             ORDERDETAILTYPE[] orders1 = null;

>             if (orderType.equals("ELEC")){
>                 orders1 = rtlControl.getElecOrderDetailView(oId, customer.getCUSTOMERID()).
>                     getOrderDetailView().getORDERDETAILVIEWArray(0).getORDERDETAILArray();
>             } else if (orderType.equals("APPL")){
>                 orders1 = rtlControl.getApplOrderDetailView(oId, customer.getCUSTOMERID()).
>                     getOrderDetailView().getORDERDETAILVIEWArray(0).getORDERDETAILArray();
>             }
>             order = (orders1 != null && orders1.length > 0) ? orders1[0] : null;
>         ...
>             return new Forward("success");
>         }

### Pagination

The OrderHistory page provides pagination; that is it retrieves data in batches and provides an interface to the user to get the next or previous batch of data.

Figure 1-16 Pagination, illustrated in OrderHistory.jsp.

When you click the Next or the Previous button a new parameterized query is executed that retrieves the next five or previous five records from both data sources, even though they do not have a common key between them. A local variable is incremented or decremented as part of the parameterization process.

### Data Binding

In the Avitek Customer Self-Service Sample Application two types of data binding occur: read and update.

#### Read Cycle

When creating a page which reads data, you need to follow these steps:

1. Create the control to access the query you plan to use.
2. Create a page flow.
3. When the page is accessed, application logic invokes the query.
4. Data is bound to the JSP through NetUI.

#### Update Cycle

In the Avitek Customer Self-Service Sample Application update is accomplished in two ways.

#### Updating Credit Card Information Using a WebLogic Workshop Database Control

When a customer changes his or her credit card information, a WebLogic Workshop database control.is used to update the data source using SQL. You can view source for this control in the file `process.jpd` in WebLogic Workshop processes folder.

#### Updating Customer Profile Information Using WebLogic Workshop Process Control

When the customer update profile information, the Liquid Data control invokes a WebLogic Integration (WLI) process that updates the source database and refreshes information in the application.

Figure 1-17 Design View of processControl.jcx

When activated, `processControl.jcx` completes its work by refreshing profile information through the Liquid Data server with this Liquid Data control call:

`rtlControl.getProfileView(custId)`

### Ad Hoc Query

The `AdHocQueryProvider.java` has code to construct an XQuery based on inputs (such as an amount, date, or word) a user enters from a web page. Once created, the ad hoc query is called from `demoPageFlowController` as part of the `SearchOrders` routine.

### Page from the SampleApp

The SampleApp Home page is called `default.jsp`

Figure 1-18 Design View of DefaultView.jsp, the SampleApp Home Page

Elements of `defaultView.jsp` were built through dragging-and-dropping variables of XMLBean type onto the JSP page. Other points of interest include:

- The NetUI repeater wizard was used to create the Current Open Order listing.
- The entire page is populated by a single Liquid Data data query, `getCustomerView.xq,` which takes a single `custID` parameter.

# Summary

In summary, the Avitek Customer Self-Service Sample Application provides:

- A virtual data access layer that allows you to treat heterogeneous data as from a single source.
- Ability to access the data through declarative queries that can be created in the Data View Builder or developed externally.
- Availability of Liquid Data queries and server for easy integration into applications or processes.

# Where To Go From Here

Here are some additional resources for learning more about Liquid Data and WebLogic Workshop:

- "Using Liquid Data Controls to Develop Workshop Applications" in the Application Developer's Guide describes steps required to create the Liquid Data control.
- Finding the Components lists where you can findSampleApp components and the Liquid Data project files that help in understanding how the underlying queries were developed.
- To learn more about WebLogic Workshop see Getting Started with WebLogic Workshop.
- To learn more about XML Beans see Getting Started with XML Beans.
- The WebLogic Workshop Samples application contains a number of samples relevant to data binding and XML. See:

<WL_HOME>/samples/workshop/SamplesApp/`Samples.work`