Sample Retail Application Overview

This is a brief overview of the Avitek Sample Retail Application (RTLApp) that is included with a complete BEA AquaLogic Data Services Platform (DSP) installation. This chapter describes the data sources and other application components used to develop the RTLApp.

• Quick Start Instructions for the Avitek Sample Application (RTLApp)
• The Challenge of Disparate Data
• Business Case for the Avitek Self-Service Web Site
• Purpose of the Avitek RTLApp
• Running Retail Sample Application in a Browser
• Viewing RTLApp Source
• Where To Go From Here

About Avitek Ltd.

Avitek is an imaginary retailer that has grown through acquisitions. The company started out selling apparel but recently merged with an electronic retailer to expand business and consolidate cost centers such as accounting and web development. Because of this acquisition the company now has two very different order management systems (OMS), one each for electronics and apparel orders. Avitek also has a customer relationship management (CRM) system to manage customer profile information. Finally, Avitek has a Customer Service system to manage the support cases for Electronic products.

General IT Goals

General immediate and mid-range goals for the newly consolidated IT department include:

• An easy solution to providing integration of different back-end resources.
• An easy solution to providing read/update to these back-end resources.
• An abstraction layer to hide the complexities of interacting with different systems.

Specific Projects

An early "low-hanging fruit" project is to build a customer self-service web site which can also be used by support representatives. This web site needs to provide an easy solution to integrating different back-end resources and to providing two-way communication (read/update). It will also need to provide an abstraction layer to hide the complexities in the different systems.

The front-end architecture of the web site will provide a Java-based Customer Self-Service portal where customers can update their profile information and review or modify their orders. The back-end architecture will access the following five different sources of data (as shown in Figure 6-1):

• Customer related information stored in a CRM database (Oracle)
• Credit card information from a billing system (Sybase)
• Case information from a support database (DB2)
• Apparel order information from the company's Order Management system (SQL Server)
• Electronics Order System accessed through a web service. (The original source of information is mainframe inherited with the merger.)

The project also needs a code name. RTLApp is selected.

Figure 6-1 RTLApp Front and Back End Architecture

Quick Start Instructions for the Avitek Sample Application (RTLApp)

Make sure that both the RTLApp development environment and Web application are available. To start the RTLApp in the IDE, follow the instructions outline in Verifying the Installation, including starting your BEA WebLogic Server.

The steps involved in running RTLApp from inside WebLogic Workshop are similar to starting the IDE. (If you have already build and deployed RTLApp in Workshop you can skip to step 4.)

 Start All Programs BEA WebLogic Platform 8.1 BEA AquaLogic Data Services Platform 2.1 Examples RTL Demo Launch RTL Demo Sample Server

Note: You can go on to Step 2 while starting the sample domain server.

 WL_HOME>/samples/liquiddata/RTLApp/RTLApp.work

Right-click on RTLApp (top node in the Application pane), and choose Build Application from the context-sensitive menu. WebLogic Workshop displays the status of the build. Confirm that the build was successful, as indicated by the build status messages.

 RTLSelfService\Pages

 Debug Start

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

Figure 6-2 RTLApp Login Page

The Challenge of Disparate Data

The sample retail application illustrates in simplified form the kinds of data integration challenges often encountered 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.
• Having such a single point of access to your data, can you develop reusable queries that are easily tested, stored, and retrieved?
• Once you can query data, can you as easily update it in a secure manner?
• Can you cache data to improve performance while protecting users from stale information?
• How difficult is it to consume query results in client applications?

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? When changes to underlying data inevitably occur, how difficult will it be to propagate those changes to the application layer?

So many questions.

Business Case for the Avitek Self-Service Web Site

A survey commissioned by Avitek Marketing found 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. 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 .

Web Site Design Requirements

Site requirements seem simple. Fulfillment identifies that customers will need to be able to:

• Securely 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.

Bottom line: If customers can perform this level of self-service the company will save a lot of money.

Maintenance Requirements

A cross-sectional team of marketing and customer service develop maintenance requirements for the web application:

• 7x24
• Less than 10 pages
• Low-maintenance
• Easily modified

Design Requirements

An application/UI designer begins "specing out" the required JSPs. Pages are the easy part. Data is needed so he shoots off an email to the consolidated IT department.

Information Technology (IT) Weighs In: The Moment of Truth

When an IT data architect analyzes the requirements she 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 with additional maintenance problems down the road. 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.

So much for low-hanging fruit.

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 RTLApp 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.
• Allows read-write testing and deployment.

A Possible Solution

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

• Addressing the problem of data access, DSP provides data integration through a highly-accessible graphical interface.
• In DSP, queries are developed graphically and are self-describing.
• Once data integration is achieved, persistent queries are generated.
• Read-write to live or staged data is available at every step of the development process.

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

Data Access. DSP allows the application 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 DSP server.

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

The declarative form of DSP artifacts (query functions in data services) makes them very readable.

Query Deployment. Once developed, queries are easily integrated into a client application thorough a variety of access methods such as the DSP Mediator API, a data service control, JDBC, or SQL.

Integration. Business logic for the RTLApp is provided by the NetUI and page flow features of Workshop. However, DSP query functions could have as easily been integrated and maintained within the business logic of any J2EE application.

Purpose of the Avitek RTLApp

The RTLApp is designed to illustrate how DSP-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.

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

Finding the Components

The RTLApp is located in the following directory:

  /samples/domains/liquiddata/RTLApp

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

  /samples/domains/liquiddata/RTLSelfService

Some of the schemas used in the RTLApp are in the following directory:

  /samples/domains/liquiddata/schemas

Others are located in their respective data service.

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

  /samples/domains/liquiddata/RTLApp/RTLApp.work

When you install DSP with the WebLogic Platform, the source code for the RTLApp can be accessed from Workshop. For instructions, see Viewing RTLApp Source.

For additional information and references, see:

• Running Retail Sample Application in a Browser.
• Using Workshop Controls to Develop Data Service Platform Applications in the Application Developer's Guide for the specific steps required to create the data service control.

Analyzing the RTLApp Architecture

Several BEA technologies are exercised by the RTLApp.

• Query Development. Data services and queries that draw data from multiple data sources are created in WebLogic Workshop.
• Query Access. Query functions are accessible through the DSP mediator API, JDBC, and the Workshop data service control and can be tested within Workshop.
• Client-side Development. Workshop also provides an environment for building application logic through NetUI, page flow, and other technologies.

Available Data Sources

Although the RTLApp is very simple, the underlying data acquisition is challenging 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 RTLCUSTOMER.
• Order Management System (OMS). Avitek has two order management systems:
  • Apparel products. Information is maintained on site in a second database. This is represented in DSP as RTLAPPLOMS.
  • Electronic products. OMS information is available from a legacy system (RTLELECOMS) via a web service. The web service has several methods such as getCustomerOrderByCustomerID(), that takes a customer ID as input and returns a list of customer open order information through a web service.

  Retail Sample Application Queries

  The following section describes work done by some of the RTLApp data services.

  Physical Data Services

  There physical data services correspond with the physical data sources needed by the application.

  • ApparelDB includes the following data services: CUSTOMER_ORDER, CUSTOMER_ORDER_LINE_ITEM, and PRODUCT.
  • BillingDB includes a CREDIT_CARD data service.
  • CustomerDB includes ADDRESS and CUSTOMER data services.
  • ElectronicsWS includes data services based on the web services. The data services include: getCustomerOrderByCustomerID, getCustomerOrderByOrderID, and getProductList.
  • ServiceDB is the source for the SERVICE_CASE data service.

  In RTLApp physical data services typically have a read function and, often, one or several navigation functions that correlate to the primary key/foreign key relationship between relational sources.

  Logical Data Services

  Logical data services (services based on physical data services or other logical data services) are located in a folder called RTLServices. It is in these logical data services that read and navigation functions drawing on multiple data sources are developed and maintained.

  Avitek Customer Self-Service Sample Application

  Table 6-1 shows the relationship between the data sources, major data elements (for RDBMS systems: tables and columns), sample application JSPs, and the RTLApp web pages.