This section describes how to install and configure a Commerce Reference Store in an environment that:

Each ATG server instance (EAR file) running in your application server includes the appropriate configuration and modules for its designated tasks. The publishing server runs ATG Content Administration, Oracle ATG Web Commerce Merchandising, Site Administration, and, to make it available for editing in the Business Control Center, an instance of Commerce Reference Store. The publishing server also runs the ATG-Endeca integration components. These components trigger the loading of catalog data into the Endeca Content Acquisition System (this step is the precursor to indexing the data in an MDEX on the Oracle Endeca Commerce side).

The production server runs the ATG Content Administration publishing agent as well as the instance of Commerce Reference Store that is served to customers. To allow it to query the MDEX via the Assembler API, the production server also runs the ATG-Endeca integration components.

The Commerce Reference Store 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 ATG install directory. The two ATG 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 Reference Store includes three storefront sites: CRS Store US, CRS Store Germany, and CRS Home. These sites are related in the following ways:

Additionally, the three sites include support for the languages shown in the following table:

Site

Language Support

CRS Store US

English, Spanish

CRS Store Germany

German, English

CRS Home

English, Spanish

Commerce Reference Store uses a switching database configuration that allows you to deploy changes to an offline copy of your data, rather than making changes directly to the data your live site 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 to your live site, 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 the publishing server to the production server, data that is ready to go live is copied from a versioned database, implemented as part of ATG Content Administration, to the production database. Not all data benefits from versioning, so the production database contains several schemas:

The versioned database only has one schema, Publishing, that contains all the data required for your sites, plus additional fields that manage asset versioning.

This illustration is described in the preceding text.

Copyright © 1997, 2014 Oracle and/or its affiliates. All rights reserved. Legal Notices