| Oracle® Retail POS Suite Implementation Guide, Volume 1 – Implementation Solutions Release 14.1 E54475-02 |
|
 Previous |
 Next |
| Oracle® Retail POS Suite Implementation Guide, Volume 1 – Implementation Solutions Release 14.1 E54475-02 |
|
Previous |
Next |
This chapter contains information about the Oracle Retail Back Office, Central Office, Point-of-Service, and Returns Management architecture.
The architecture of Back Office and Central Office uses client, middle, and data tiers. The client tier is a web browser; the middle tier is deployed on an application server; and the data tier is a database deployed by the retailer.
The middle tier is organized in an MVC design pattern, also called a Model 2 pattern. This chapter focuses on the middle tier and the model, view, and controller layers that it is divided into.
The client system uses a web browser to display data and a GUI generated by the application. Any browser which supports JavaScript, DHTML, CSS, and cookies can be used. In practice, only a few browsers are tested.
The middle tier of the application resides in a J2EE application server framework on a server machine. The middle tier implements the MVC pattern to separate data structure, data display, and user input.
The model in an MVC pattern is responsible for storing the state of data and responding to requests to change that state which come from the controller. In Back Office and Central Office, this is handled by a set of Commerce Services, which encapsulates all of the business logic of the application. The Commerce Services talk to the database through a persistence layer of entity EJBs, using bean-managed persistence, or data access objects (DAO).
Commerce Services are components that have as their primary interface one or more session beans, possibly exposed as web services, which contain the shared retail business logic. Commerce Services aggregate database tables into objects, combining sets of data into logical groupings. Commerce Services are organized by business logic categories rather than application functionality. These are services like Transaction, Store Directory, or Parameter that would be usable in any retail-centric application.
These services in turn make use of a persistence layer made up of entity beans or DAOs. Each Commerce Service talks to one or more entity beans or DAOs, which map the ARTS standard database schema. A data access object (DAO) is an object that provides an abstract interface to some type of database or persistence mechanism, providing some specific operations without exposing details of the database. Using the bean-managed persistence (BMP) pattern, each entity bean maps to a specific table in the schema, and knows how to read from and write to that table. A DAO maps to one or more tables that belong to the same logical unit. The DAO is responsible for reading or writing data to and from these tables. The Commerce Services thus insulates the rest of the application from changes to the database tables. Database changes can be handled through changes to a few entity beans.
The Commerce Services architecture is designed to facilitate changes without changing the product code. For example, you can:
Replace a specific component's implementation. For example, the current Store Hierarchy service persists store hierarchy information to the ARTS database. If a customer site has that information in an LDAP server, the Store Hierarchy could be replaced with one that connected to the LDAP. The interface to the service need not change.
Create a new service that wraps an existing service (keeping the interface and source code unchanged), but adds new fields. You might create My Customer Service, which uses the existing Customer Service for most of its information, but adds some specific data. All that you change is the links between the Application Manager and Customer Service.
The view portion of the MVC pattern displays information to the user. In Back Office this is performed by a web user interface organized using the Struts/Tiles framework from the open-source Apache Foundation. Using Tiles for page layout enables greater use of the user interface components to enhance the extensibility and customization of the user interface.
To make the view aware of its place in the application, the Struts Actions call into the Application Manager layer for all data updates, business logic, and data requests. Any code in the Struts Actions should be limited to formatting data for the Java server pages (JSPs) and organizing data for calls into the Application Manager layer.
JSPs deliver dynamic HTML content by combining HTML with Java language constructs defined through special tags. Back Office pages are divided into Tiles which provide navigation and page layout consistency.
The controller layer accepts user input and translates that input into calls to change data in the model layer, or change the display in the view layer. Controller functions are handled by Struts configuration files and Application Services.
The application determines which modules to call, on an action request, based on the struts-config.xml file.There are several advantages to this approach:
The entire logical flow of the application is in a hierarchical text (xml) file. This makes it easier to view and understand, especially with large applications.
The page designer does not need to read Java code to understand the flow of the application.
The Java developer does not need to recompile code when making flow changes.
Struts reads the struts-config.xml once, at startup, and creates a mapping database (a listing of the relationships between objects) that is stored in memory to speed up performance.
The application services layer contains logical groupings of related functionality specific to the Back Office application components, such as Store Operations. Each grouping is called an application manager. These managers contain primarily application logic. Retail domain logic should be kept out of these managers and instead shared from the Commerce Services tier.
The application services use the Session Facade pattern; each Manager is a facade for one or more Commerce Services. A typical method in the Application Services layer aggregates several method calls from the Commerce Services layer, enabling the individual Commerce Services to remain decoupled from each other. This also strengthens the web user interface tier and keeps the transaction and network overhead to a minimum.
For example, the logic for assembling and rendering a retail transaction into various output formats are handled by separate Commerce Services functions. However, the task of creating a PDF file is modeled in the EJournal Manager, which aggregates those separate Commerce Service functions into a single user transaction, thus decreasing network traffic and lowering maintenance costs.
The Data Tier is represented by a database organized using the ARTS standard schema. Customer requirements determine the specific database selected for a deployment.
Figure 2-4 shows representative components Application Services and Commerce Services. Arrows show the dependencies among various components.
Figure 2-5 describes a trip through the Back Office architecture, starting from a user's request for specific information and following through until the system's response is returned to the user's browser.
Retailers have an increasing demand for enterprise information and customer service capabilities at a variety of points of service, including the Internet, kiosks and handheld devices. The retail environment requires that new and existing applications can be changed quickly in order to support rapidly changing business requirements. Oracle Retail Platform and Retail Domain enable application developers to quickly build modifiable, scalable, and flexible applications to collect and deliver enterprise information to all points of service.
Figure 2-6 shows a high level view of the Oracle Retail architecture and components.
Table 2-1 describes the components in Figure 2-6.
Table 2-1 Oracle Retail Architecture Components
| Component | Description |
|---|---|
|
Oracle Retail Platform |
Oracle Retail Platform provides services to all Oracle Retail applications. It contains the tour framework, UI framework, and Manager/Technician frameworks. Oracle Retail Platform is not retail-specific. |
|
Retail Domain |
Retail Domain implement business logic. Retail Domain defines data and behavior for retail applications. |
|
Oracle Retail Applications |
All Oracle Retail applications leverage the frameworks and services provided by Oracle Retail Platform and Commerce Services. |
|
External Interfaces |
Using frameworks and services, the applications are able to interface to other applications and resources. |
Advantages of the Oracle Retail architecture include its object-oriented design and scalability. The system is designed to support existing systems and customer extensions. Oracle Retail Platform frameworks support integration by adhering to retail and technology standards. The multi-tier design of the architecture allows the application to support numerous types of infrastructure.
Oracle Retail Platform contains reusable, highly customizable components for building and integrating retail applications with user interfaces, devices, databases, legacy systems, and third-party applications. Oracle Retail Platform also contains integration points for communicating with external resources.
Figure 2-7 shows how the Tour engine controls the Point-of-Service system. This diagram is a more detailed view of the components that form the Retail Domain and Oracle Retail Platform tiers in Figure 2-6.
Beginning with configuration of the UI and Managers/Technicians, events at the user interface are handled by the tour engine, which interacts with tour code (Application Services) and Managers/Technicians (foundation services that part of the Oracle Retail platform layer) as necessary, capturing, and modifying the data stored in Retail Domain objects. Any communication with an integration point is handled by the Oracle Retail Platform container.
Table 2-2 describes the layers of the Point-of-Service architecture.
Table 2-2 Point-of-Service Architecture Layers
| Component | Description |
|---|---|
|
Configuration |
Application and system XML scripts configure the layers of the application. |
|
User Interface |
This layer provides client presentation and device interaction. |
|
Tour Engine |
This mechanism handles the workflow in the application. The tour engine is the controller for Point-of-Service. |
|
Application Services |
This layer provides application-specific business processes. A tour is an application service for Point-of-Service. |
|
Retail Domain Objects |
Pure retail-specific business objects that contain application data. |
|
Oracle Retail Platform Container |
This is an execution platform and application environment. The Tier Loader is the Oracle Retail Platform container for Point-of-Service. It contains the tour framework, UI framework, and Manager/Technician frameworks. |
|
Integration |
This layer provides an integration framework for building standard and custom interfaces using standard integration protocols. |
Design patterns describe solutions to problems that occur repeatedly in object-oriented software development. A pattern is a repeatable, documented method that can be applied to a particular problem. This section describes four patterns used in the architecture of Point-of-Service: MVC, Factory, Command, and Singleton.
The MVC Pattern divides the functionality of an application into three layers: model, view, and controller. Different functionality is separated to manage the design of the application. A model represents business objects and the rules of how they are accessed and updated. The model informs views when data changes and contains methods for the views to determine its current state. A view displays the contents of a model to the user. It is responsible for how the data is presented. Views also forward user actions to the controller. A controller directs the actions within the application. The controller is responsible for interpreting user input and triggering the appropriate model actions. Figure 2-8 illustrates the MVC Pattern.
Another design pattern used in Point-of-Service code is the Factory pattern. The intent of the Factory pattern is to provide an interface for creating families of related or dependent objects without specifying their concrete classes. The application requests an object from the factory, and the factory keeps track of which object is used. Since the application does not know which concrete classes are used, those classes can be changed at the factory level without impacting the rest of the application. Figure 2-9 illustrates this pattern.
Sometimes it is necessary to issue requests to objects without knowing anything about the operation being requested or the receiver of the request. The Command pattern encapsulates a request as an object. The design abstracts the receiver of the Command from the invoker. The command is issued by the invoker and executed on the receiver. Figure 2-10 illustrates the Command pattern. It is used in the design of the Manager/Technician framework.
The Singleton pattern ensures a class only has one instance and provides a single, global point of access. It allows extensibility through subclassing. Singletons allow retailers to access the subclass without changing application code. If a system only needs one instance of a class across the system, and that instance needs to be accessible in many different parts of a system, making that class a Singleton controls both instantiation and access. Figure 2-11 illustrates the Singleton pattern:
This section presents a concise description of the system's architecture. The system is considered a collection of run time behaviors, a set of software modules, and a member of a larger group of external systems and actors.
This section describes technologies and frameworks that are used by Returns Management. These assets are not unique to Returns Management but are key to its implementation.
The following information describes the architectural styles and patterns of Returns Management and its component pieces.
The architectural layers design style is not unique to Returns Management. It is a shared architecture across all of Oracle Retail's web applications.
Figure 2-12 shows the break down of the user interface and business logic across the application. The design uses both a model-view-controller pattern as well as a façade pattern to hide the implementation of business logic. The façade not only applies to the user interface, but to the other pieces of business logic as well.
As with all object construction, the goal is to reduce the dependency between the objects so that code might be more freely modified without adversely affecting other parts of the application.
Apache Struts is used at the graphical user interface layer to provide both a clear separation of the controller, view, and model as well as providing a well known technology for ease of extension. At the façade layer, an application manager is implemented using J2EE session beans to provide a coarse-grained view of business logic to the user interface. Each manager communicates directly with one or more services located in the service layer that provide fine-grained business operations. These service beans are also implemented using J2EE session beans. Each service bean can then communicate with other services or down to persistent storage in the data layer. By abstracting the storage away from the other layers, this not only enables the design to leverage J2EE entity beans but also allows for disparate storage mediums for integrating with third party data stores.
Figure 2-13 is a conceptual view of the modules that make up the Returns Management service. Here, a module corresponds to code that provides a discrete piece of functionality. For example, the Auditing module corresponds to the auditing function.
For illustrative purposes, the code has been split into four broad types:
Functionality to interact with an outside actor, such as the user or the point-of-return. These modules include:
Web Service Adapter
The point-of-return is expected to talk to Returns Management using a web service. An adapter is provided to enable this functionality out-of-the-box.
JSP UI
The user interface is HTML-based, powered by JavaServer Pages (JSP) and Struts.
Functionality that provides the core services offered by Returns Management. These modules include:
Return Evaluation
This is where the initial "Is this item returnable?" question is asked.
Final Result Processing
This is where Returns Management consumes results to maintain historical data.
Analytic Engine
The decision engine that evaluates Returns Management rules.
Functionality to administer, monitor, and examine Returns Management behavior and data. These modules include:
Auditing
Provides the capability to examine the steps that went into a return decision.
Rules and Policy Maintenance
Enables the user to add, modify, or delete policies and the rules which comprise them.
Functionality tied to persistent storage. These modules include:
Audit Log
The steps recorded by the engine as it processes a policy.
Policies
Collections of rules that are bound to certain conditions, for example, some policies apply only to receipted items.
Rules
Each rule evaluates a return-related question, for example, "How many returns has this customer attempted in the past week?" Rules are responsible for indicating to the point-of-return whether an item is returnable or not.
Return Tickets
Returns Management stores information about each return request for later manipulation by Final Result Processing.
Exception File
Records that store information about exceptional behavior, which are created when a customer has exhibited behavior the retailer wants to track.
The following are example of enabling technologies in Returns Management.
Returns Management uses the Apache Struts project to present its Java Server Pages in a J2EE compliant container. For more information, go to http://struts.apache.org/.
Returns Management uses Apache Axis to provide a container-neutral way of presenting web services. For more information, go to http://axis.apache.org/axis/.
The user interface for Returns Management can be divided into two classes of components:
JSPs and Action Classes
The Returns Manager
Figure 2-14 shows the general web user interface diagram as it relates to Returns Management in particular. The interface layer is composed of the JSPs attached to the Returns Management as well as their backing action classes. These actions attempt to provide user interface-level functionality such as flow control and rudimentary data checking. The class at the façade layer, the Returns Manager, exposes numerous coarse-grained methods to enable the Action classes to retrieve key performance indicators (KPIs)—also known as return activities, search the exception file, and other administrative tasks. The Returns Manager then communicates to whatever resources it needs to provide the necessary information to the interface layer. Since all of this work is hidden behind the façade, the Returns Manager has flexibility in deciding how to perform a certain task with minimal impact to the client classes in the interface layer.
The conceptual module view divided the system into modules based off of the functionality provided. The physical module view divides the modules along the notion of module type. For instance, rather than showing policy maintenance as a separate service, policy maintenance is included in the larger Returns Service.
Figure 2-15 broadly divides the modules into four groups:
User Interface Layer: responsible for the web-based user interface.
Consumer Adapter Layer: responsible for communication with Returns Management.
Service Layer: provides the heavy lifting of Returns Management functionality.
Data Layer: provides access to persistent storage.
As mentioned previously, the Returns Management user interface is a web-based system implemented using Struts and Tiles. The presentation layer consists of a large number of JSPs, forms, actions, and other artifacts of the Struts system. Behind this presentation layer resides the Returns Manager façade, which provides the Struts actions with access to the business logic of the application.
In the Model-View-Controller paradigm, Struts provides all three pieces:
Actions provide the model.
JSPs are the view.
Struts classes and configuration files provide the controller.
However, the action classes are not the model used by Returns Management. The action classes exist primarily to marshall data from the presentation layer down to the business logic, and to provide coarse-grained flow control over a business process. It is important to realize that the real model of Returns Management has little to do with the action classes. The real model is implemented behind the Manager façade in the service and data layers.
JavaServer Pages (JSPs) are text files which correspond to the normal JavaServer Page formatting restrictions. Actions and forms are normal Java classes while the Manager is implemented as a stateless session bean.
The consumer adapter layer provides the different interfaces into the Returns Management system. This layer is specifically split from the service layer in the design to decouple the interface of communication from the implementation classes. Therefore, regardless of underlying changes in how Returns Management is implemented, the interface expected by clients can remain static. The separation provides a well-defined contract with which service consumers can interact, and enables future custom adapters to be integrated with minimal effort.
There are three ways to communicate with the Returns Management system:
Return Request and Return Response are exposed using a web Services interface.
Return Results are collected using a JMS queue.
The EJB remote interface, which enables arbitrary methods to be invoked on the service bean.
For more information about communicating with Returns Management, see "Integration Methods and Communication".
The first two interfaces mentioned enable flexible client implementations while providing clear interfaces for interaction. The EJB remote interface is available when some system needs to operate with Returns Management outside of the normal API-type transactions, for example, the Returns Manager makes liberal use of the remote interface for inquiring and maintaining Returns Management data.
The term service is used in two different ways when describing Returns Management.
The first way is the abilities provided by Returns Management in its role as a service in a service-oriented architecture. These abilities are restricted to the two interfaces of evaluation (return request) and exception tracking (return result).
The second way is used to describe the interoperable commerce services that form the core of Returns Management functionality. These are the services that live in the service layer. These services are generally not client accessible. They provide discrete business functions available to other services and Application Managers living in the façade layer.
When describing Returns Management in terms of service-oriented architecture, the services provided by Returns Management are implemented primarily in one class, the Return Service Bean. These services are exposed in the Consumer Adapter Layer for access from client routines.
When describing Returns Management in terms of its commerce service modules, then not only would the return service bean be included but also the modules which exist to provide support to Returns Management, such as the KPI Service and the Returns Post-Processor Service.
For purposes of discussion, this document splits the data used by Returns Management into three types:
Engine data used to determine returnability.
Configuration data used to control behavior.
Historical data used to record information.
These types of data are generally stored in an RDBMS and accessed using an entity bean layer. Each general type is covered briefly in the following sections.
Returns Management uses a decision engine to codify and enforce returns policies. The decision engine operates on sets of rules, which are collected into policies. The rules operate on a set of facts that the engine supplies at run time. These facts are evaluated by the rules, which eventually return an answer back from the engine. See "Determining Return Policies" in the Oracle Retail Returns Management User Guide.
Figure 2-19 shows how policies, rules, and rule actions are conceptually related.
A policy is composed of one or more rules. Each policy has associated metadata that enables the service layer to choose the most appropriate policy for the current item in question.
A rule is configured to ask a certain question about the current item or customer in question. Each rule references several possible rule actions.
A rule action has two distinct functions:
Identify an answer to a question. Each rule action corresponds to a value returned from the rule's question.
Tell the analytic engine (for example, the service layer) what action to take in response to this answer, for example, whether to continue or stop policy evaluation and determine what response to return to the client.
Returns Management has a list of valid response codes that can be returned to a client. This list is maintained in the data store and is accessed using entity beans. Returns Management also maintains a list of receipt messages which are accessed in a similar fashion.
Following an established pattern in Oracle Retail products, Returns Management uses an XML parameter file to maintain a list of configuration options and choices that can be modified for a particular customer deployment. These parameters control a variety of behaviors as well as providing a place for some of the data used during processing (for instance, the list of acceptable tenders).
|
Note: For more information on specific parameters, see the Oracle Retail POS Suite Configuration Guide. |
Returns Management maintains a set of historical data. To record a particular decision during the evaluation phase, Returns Management creates a return ticket that records what item is being returned, who wants to return the item, and the Returns Management decision about the returnability of an item. This return ticket is later updated during the return result process to reflect what was actually returned at the point-of-return.
An exception file that counts up the total number of times an instance of a tracked behavior occurs, for example, a customer with a non-receipted return or a customer with a tender override, is maintained by Returns Management during the return result phase.
The following are grouped in the exception file:
Customer exceptions, such as line items that reflect customer return activities being violated.
Customer exception counts and freeze dates.
Customer Service Overrides, that is, a count of overrides, per day, per customer.
For more information, see the following:
Oracle Retail Returns Management User Guide.
This section describes the interface of the two main services provided by Returns Management:
Evaluation of the return request
Processing of the return result
These services are expected to be invoked from an external source, usually the point-of-return.
In order to provide language neutrality, these two services are accessed in a stateless fashion using XML documents. Return request is a synchronous message, that is, the invoker is expected to wait on a return response message. Return result is an asynchronous message that can be invoked in a fire-and-forget fashion.
Although both services are exposed using a web service interface, a message-driven bean exists to collect return result messages asynchronously as a best practice. More details about messaging are provided in "Integration Methods and Communication".
