6 Back Office and Central Office Extension Guidelines

This chapter describes the various extension mechanisms available in the Commerce Services framework. There are multiple forces driving each extension that determine the correct strategy in each case.

The product has four distinct layers of logic:

UI layer

Struts/Tiles implementation utilizing Actions for processing UI requests and JSP pages with Tiles providing layout.

Application Manager

Session facade for the UI (or external system) that models application business methods. May or may not be reusable between applications. Provides for remote accessibility.

Commerce Service

Session facade for the service that models coarse-grained business logic that should be reusable between applications.

Persistence

Entity beans that are fine-grained, and data access objects (DAO), consumed by the service. The entities are local to the service that controls them.

Note: See the Oracle Retail POS Suite Security Guide for more information about specific security features and implementation guidelines for the POS Suite products.

Audience

This section provides guidelines for extending the Oracle Retail Enterprise applications. The guidelines are designed for three audiences:

• Members of customer architecture and design groups can use this chapter as the basis for their analysis of the overall extension of the systems.

• Members of Oracle Retail's Technology and Architecture Group can use this chapter as the basis for analyzing the viability of the overall extension strategy for enterprise applications.

• Developers on the project teams can use this chapter as a reference for code-level design and extension of the product for the solution that is released.

Application Layers

Figure 6-1 describes the general composition of the enterprise applications. The following sections describe the purpose and responsibility of each layer.

Figure 6-1 Application Layers

User Interface

The user interface (UI) framework consists of Struts Actions, Forms, and Tiles, along with Java server pages (JSPs).

• Struts configuration

• Tiles definition

• Cascading style sheets (CSS)

• JSP pages

• Resource bundles for internationalization (I18N)

Application Manager

The Application Manager components are coarse-grained business objects that define the behavior of related Commerce Services based on the application context.

• Session beans

• View beans for the UI

Commerce Service

A commerce service is a fine grained component of reusable business logic.

• Session beans

• Data transfer objects (DTO)

Algorithm

An SPI-like interface defined to enable more fine-grained pieces of business functionality to be replaced without impacting overall application logic.

Entity

Fine-grained entity beans owned by the commerce service. The current strategy for creating entity beans in the commerce service layer is BMP.

Data Access Objects

Provides an abstract interface to the database, providing specific operations without exposing details of the database.

Database

The Oracle Retail enterprise applications support the ARTS standard database schema. The same tables referenced by Central Office and Back Office are a superset of the tables that support Point-of-Service.

Extension and Customization Scenarios

The following are extension and customization scenarios.

Style and Appearance Changes

This should only present minor changes to the UI layer of the application. These types of changes, while extremely common, should represent minimal impact to the operation of the product. Typical changes could be altering the style of the application (fonts/colors/formatting) or the types of messages that are displayed.

Application impact:

• Struts configuration (flow)

• Tile definition

• Style sheet

• Minor JSP changes, such as moving fields

• Changing static text through resource bundles

Additional Information Presented to User

This is one of the more common extensions to the base product: enabling the full life cycle management of information required by a particular customer that is not represented in the base product.

If the information is simply presented and persisted then we can choose a strategy that simply updates the UI and persistence layers and passes the additional information through the service layer.

However, if the application must use the additional information to alter the business logic of a service, then each layer of the application must be modified accordingly.

This scenario generally causes the most pervasive changes to the system; it should be handled in a manner that can preserve an upgrade path.

Figure 6-2 Managing Additional Information

Application impact for this change:

• JSP pages

• View beans

• Struts configuration

• UI actions

• UI forms

• Application manager

• Commerce service

• Entity or DAO

• Database schema

Changes to Application Flow

Sometimes a multi-step application flow can be rearranged or customized without altering the layers of the application outside of the UI. These changes can be accomplished by changing the flow of screens with the struts configuration.

Figure 6-3 Changing Application Flow

Application impact for this change:

• Struts configuration

Access Data From a Different Database

This customization describes accessing the same business data from a different database schema. No new fields are added or joined unless for deriving existing interface values. This scenario would most likely not be found isolated from the other scenarios.

Figure 6-4 Accessing Data from a Different Database

Application impact for this change:

• Entity beans and DAO

• Database schema

Access Data From External System

This customization involves replacing an entire Commerce Service with a completely new implementation that accesses an external system.

Figure 6-5 Accessing Data from an External System

Application impact for this change:

• Deployment Configuration – replacing Commerce Service implementation with custom implementation.

Change an Algorithm Used By a Service

Assuming the UI is held constant, but values such as net totals or other attributes are derived with different calculations, it is advantageous to replace simply the algorithm in question, as the logic flow through the current service does not change.

Figure 6-6 Application Layers

Application impact for this change:

• Algorithm

• Application configuration

Extension Strategies

Refer to Figure 6-7 as a subset of classes for comparison purposes.

Figure 6-7 Sample Classes for Extension—Entity Bean

Figure 6-8 Sample Classes for Extension—DAO

Extension with Inheritance

This strategy involves changing the interfaces of the service itself, perhaps to include a new finder strategy or data items unique to a particular implementation. For instance, if the customer information contained in base product does not contain data relevant to the implementation, call it CustomField1.

All of the product code would be extended (the service interface, the implementation, the DTO and view beans utilized by the service, the UI layers and the application manager interface and implementation) to handle access to the new field.

Figure 6-9 Extension with Inheritance: Class Diagram—Entity Bean

Figure 6-10 Extension with Inheritance: Class Diagram—DAO

Replacement of Implementation

This strategy involves keeping the existing product interfaces to the service intact, but utilizing a new implementation. This strategy is suggested for when the entire persistence layer for a particular service is changed or delegated to an existing system.

Figure 6-11 demonstrates the replacement of the product Customer Service implementation with an adapter that delegates to an existing CRM solution (the system of record for customer information for the retailer).

This provides access to the data from the existing services that depend on the service interface.

Figure 6-11 Replacement of Implementation

Service Extension with Composition

This method is preferred adding features and data to the base product configuration. This is done with composition instead of inheritance.

For specific instances when you need more information from a service that the base product provides, and you wish to control application behavior in the service layer, it is suggested to use this extension strategy. The composition approach to code reuse provides stronger encapsulation than inheritance. Using this method keeps explicit reference to the extended data/operations in the code that needs this information. Also, the new service contains rather than extends the base product. This allows for less coupling of the custom extension to the implementation of the base product.

Figure 6-12 Extension with Composition: Class Diagram—Entity Bean

Figure 6-13 Extension with Composition: Class Diagram—DAO

Figure 6-14 Extension Composition

Data Extension Through Composition

This strategy describes having the entity layer or DAO layer take responsibility for mapping extra fields to the database by aggregating the custom information and passing it through the service layer. This approach assumes that the extra data is presented to the user of the system and persisted to the database, but is not involved in any service layer business logic.

This scenario alters the UI layer (JSP/Action/ViewBean) and adds a new ApplicationManager method to call assemble the ViewBean from the extensible DTO provided by the replaced Entity bean or DAO.

Slight modifications to the Service session bean might be necessary to support the toDTO() and fromDTO (ExtensibleDTOIfc dto) methods on the Entity bean, depending on base product support of extensions on the particular entity bean.

1. Create the new ApplicationManager session facade.

2. Create the new ViewBeans required of the UI.

3. Create a new Entity bean or DAO that references the original data to construct a base product DTO that additionally contains the custom data using the extensible DTO pattern.

4. Create a new DTO based on the extensible DTO pattern.

5. Create new JSP pages to reference the additional data.

6. Change the deployment descriptors that describe which implementation to use for a particular Entity bean. In the case of DAO, specify the new DAO class in PersistenceContext.xml.

7. Change the new Struts configuration and Action classes that reference the customized Application Manager Session facade.

8. If necessary, change the Commerce Service Session facade to give control of the toDTO and fromDTO methods to the Entity bean and do not assemble or disassemble the DTO in this layer, as it does not give a good plug point for the Extensible DTOs.

Figure 6-15 describes the lifecycle of the data throughout the request.

Figure 6-15 Data Extension through Composition

Figure 6-16 describes the various classes created.

Figure 6-16 Data Extension Through Composition: Class Diagram—Entity Bean

Figure 6-17 Data Extension Through Composition: Class Diagram—DAO