| Oracle® Retail Advanced Science Engine Implementation Guide Release 14.1 E59126-02 |
|
 Previous |
 Next |
| Oracle® Retail Advanced Science Engine Implementation Guide Release 14.1 E59126-02 |
|
Previous |
Next |
This chapter describes, at a high level, the overall ORASE architecture and some sample deployment options and summarizes the ORASE implementations and installations. It contains the following sections:
The main ORASE components are illustrated in Figure 2-1, "ORASE Component Architecture".
ORASE is a three-tiered architecture consisting of a Presentation Layer, Business Layer, and Database Layer.
The Presentation Layer is implemented using Java Server Faces (JSF) and Oracle Application Development Framework (ADF) Faces.
The Business Layer contains:
Java code and XML
ADF Business Components (BC)
Java Persistence Application Programming Interface (JPA)
ORASE services that contain common utilities, common logging, capture, and playback (as appropriate)
Pluggable science that contains calculation algorithms and the Gurobi solver (for ASO only)
Batch and Extract-Transform-Load (ETL) scripts orchestration
Job Processor for stage and run execution (Oracle Coherence is optional for scaling)
Metadata is used throughout the Business and Presentation Layers.
The Database layer contains all persisted data and corresponding data mining, common, and module-specific procedures. The major components of the Database layer are:
RPAS, on which CM and the Fusion Client are installed. ORASE communicates with RPAS only via ETL scripts.
The ORASE database.
The RA Data Model.
Configuration is used throughout the business and database layers. See Chapter 5, "Configuration" for details.
Figure 2-2, "ORASE Deployment Components" outlines the deployment components that are included with ORASE. (Note that MBA is used only by RA.)
The Oracle WebLogic Application Server hosts the user interface and middle-tier components.
ORASE is the umbrella for all the related applications.
The Oracle Database hosts the ORASE back-end components and the RA Data Model (RADM), also known as the RA Schema.
Computation components run either on WebLogic or, as shown, optionally on computation nodes using Oracle Coherence.
Data interaction between the Oracle Database and RPAS is done through a file-based interface/ODI.
For security, as needed, the UI and installer supports HTTPS and SSL communication. Oracle wallet is used to store database connection credentials and provide secure connection to the database.
On ASO only, the Gurobi solver is deployed with the computation components to perform space optimization tasks.
See the Oracle Retail Advanced Science Engine Installation Guide for information about hardware and software requirements.
Figure 2-3, "ORASE Data Architecture" details the overall architecture of RADM, ORASE, and CM/RDF within a single solution.
Note that, as mentioned above, ORASE requires and depends on the RADM and ETL components being properly installed, configured, and populated with appropriate data required by ORASE. ORASE does not require that the installation of RA, only RADM.
RADM stores core foundation hierarchies and their attributes, (for example, Item, Location, and Calendar), alternate hierarchies for those foundation hierarchies and their attributes (for example, Category Management Groups (CMG) and Trade Areas), Customer/Consumer Segments and their attributes, and performance history. ORASE applications can use this data for their processes.
RADM packages ETL code for the Oracle Retail Merchandising System (RMS) foundation hierarchies. In addition to this, RA also has staging tables that can be leveraged for loading alternate hierarchies and their attributes that are not supported in RMS. (See the Oracle Retail Analytics Operations Guide for details about the API.) RMS is not considered the system of record for CMG, Trade Area, and Customer/Consumer Segments; therefore, extracting this information is the system integrator's responsibility. Once this data is loaded in RA staging tables, it is consumed by RA's ODI processes. (See Appendix B, "Database Detail Definitions" for table, column, and mapping definitions.)
Figure 2-4, "ORASE Data Model" shows the data flow diagram for the ORASE applications.
As mentioned above, ORASE depends on RADM for the foundation data. Internally, ORASE common includes data objects, configuration, and stored procedures that are common across the ORASE modules.
In turn, each ORASE module includes the UI-supporting objects and stored procedures, and the necessary objects and stored procedures, for the data mining and processing activities.
The MBA module uses code in ORASE common and uses RADM for input and output data.
Figure 2-5, "ASO Data Model"shows the data flow diagram for the ASO application.
ASO includes the UI-supporting objects and stored procedures and the necessary objects and stored procedures for the optimization and processing activities.
Detailed table definitions can be found in Appendix B, "Database Detail Definitions".
This section describes some sample deployments, including a minimal deployment that can be used for demonstrations and deployments that consider various types of scale, representing real-world customer scenarios. Deployment is illustrated in Figure 2-2, "ORASE Deployment Components".
It is recommended that you begin the implementation process with a minimal deployment before you begin a complex configuration that involves clustering, computational servers, or RAC. ORASE can be minimally deployed as:
A single Oracle WebLogic Server instance
A single Oracle database server
Such deployments are useful for small trials and pilots but do not consider scale and load balancing for users, computation, or database.
For scaling up to production-level loads, the deployment options shown in Figure 2-6, "Deployment for Scale" can be considered.
Scaling may be done at the UI (Presentation Layer), Computation (Business Layer), or Database layer, as needed.
To facilitate scaling with multiple simultaneous users, UI/middle-tier scaling can be done using Oracle WebLogic nodes in a cluster. Refer to Oracle WebLogic User documentation for details. Optionally, an external HTTP load balancer can be used.
ORASE, AC, and ASO can make high computational demands on the Business Layer, depending on the amount of data being used, the number of simultaneous users, and the size and quantity of clustering or space optimization runs that are initiated by the user. If computational scale is needed, additional compute nodes can be added using Oracle Coherence to distribute the computational load between these nodes. Note that Coherence can run on the same server where a WebLogic node is running in a separate Java Virtual Machine. See the Oracle Retail Advanced Science Engine Installation Guide and the Oracle Retail Assortment and Space Optimization Installation Guide for information about Coherence installation.
Some ORASE processes, like CDT and DT mining, can make high demands on the database layer, depending on the amount of data being used, the number of users, and the size and number of categories being mined. If database scaling is required, use the Oracle Real Application Cluster (RAC) solution and add database nodes as needed. Refer to Oracle RAC user documentation for details.
