This guide describes how to install and configure a Commerce Store Accelerator application in an environment that:
Runs on a single machine.
Has three Oracle Commerce Platform instances, one each for publishing, staging, and production. Each Platform instance runs under a separate server within a single application server distribution.
Each Oracle Commerce Platform server instance (EAR file) running in your application server includes the appropriate configuration and modules for its designated tasks. The publishing server runs Content Administration, Site Administration, Oracle Commerce Merchandising, and, to make it available for editing in the Business Control Center, an instance of Commerce Store Accelerator. The publishing server also runs the components that allow the Oracle Commerce Platform to integrate with Oracle Commerce Guided Search. These integration components trigger the loading of catalog data into the Oracle Commerce Content Acquisition System. This loading step must happen before the data can be indexed in an Oracle Commerce MDEX Engine and searched by Oracle Commerce Guided Search.
Each Oracle Commerce Platform server instance (EAR file) running in your application server includes the appropriate configuration and modules for its designated tasks. The publishing server runs Content Administration, Site Administration, Oracle Commerce Merchandising, and, to make it available for editing in the Business Control Center, an instance of Commerce Store Accelerator. The publishing server is also responsible for invoking the Guided Search integration components on the production and staging servers after a deployment completes. These components trigger the loading of catalog data into the Oracle Commerce Content Acquisition System. This loading step must happen before the data can be indexed in an Oracle Commerce MDEX Engine and searched by Oracle Commerce Guided Search.
The staging server runs the Content Administration publishing agent as well as the instance of Commerce Store Accelerator that is served to merchandisers through Experience Manager Preview (or by loading the staging instance of the storefront directly). To allow it to query the authoring MDEX via the Assembler API, the staging server runs the Guided Search integration components.
Similarly, the production server runs the Content Administration publishing agent and the instance of Commerce Store Accelerator that is served to customers. To allow it to query the live MDEX via the Assembler API, the production server runs the Guided Search integration components.
The Commerce Store Accelerator EAR files are assembled in development mode, where only classes, libraries, and J2EE modules are imported to the EAR file, and Nucleus configuration and other resources are used directly from the Oracle Commerce Platform install directory. The Oracle Commerce Platform servers communicate with each other through the Java Remote Method Invocation (RMI) API, for example, when the publishing server deploys content to the production server.
Commerce Store Accelerator includes two storefront sites, CSA and CSA Germany. These sites are related in the following ways:
CSA and CSA Germany share the same product catalog.
CSA and CSA Germany have separate shopping carts.
CSA and CSA Germany use different price lists. CSA’s price list is in US dollars. CSA Germany’s price list is in Euros.
Additionally, the sites include support for the languages shown in the following table:
Site | Language Support |
|---|---|
CSA | English, Spanish |
CSA Germany | German, English |
Commerce Store Accelerator uses a switching database configuration for the production server that allows you to deploy changes to an offline copy of your data, rather than making changes directly to the data your production server depends on. After the data is deployed to the offline copy, a switch is made so that the offline copy becomes the online copy and vice versa. In this way, you avoid deploying directly to the production server, which can cause errors, inconsistencies, or poor site performance. After the switch is made, the offline copy is also updated, so that both copies are current after each deployment.
When you deploy from a publishing server to a production server, data that is ready to go live is copied from a versioned database, implemented as part of Content Administration, to the production database. Not all data benefits from versioning, so the production database contains several schemas:
The
Productioncore schema holds data that does not benefit from switching, such as user account data.The
SwitchingAandSwitchingBschemas hold data that does benefit from switching, such as catalog and pricing data. Only one switching schema is active on the live site at any given time. Data is copied to the offline schema, and then the switch is made.
The staging database does not use switching and only has one schema, Staging, that contains all the data required for your sites on the staging server.
The versioned database also only has one schema, Publishing, that contains all the data required for your sites on the publishing server, plus additional fields that manage asset versioning.
