In recent releases, components of Guided Search have evolved to provide greater simplicity of implementation.
As a result, currently deployed Guided Search applications reflect different stages in the evolution of Guided Search. The parts of the Guided Search documentation that you will find applicable to your needs will depend on the stage on which you have based your application.
The stages take the form of one of the two following data integration models, depending on which components they use and how they use them:
Forge and Developer Studio Model
Prior to the release of Oracle Commerce 3.1, all applications were based on the Developer Studio model. With the release of 11.1, most new applications are based on the CAS Record Store Merger model.
Finding the documentation that is applicable to your deployment model
Sections of the documentation that describe technical concepts are equally valid for all data integration models.
However, sections of the documentation that describe procedures for configuring, starting, or stopping specific components are specific to one or two data integration models. For this reason, it is important to know which components are used in your data integration model before you consult the documentation. It is also important to know if any features of Guided Search are not supported by the model on which your application is based.
The following sections describe the Guided Search components used by each data integration model, and indicate which parts of the documentation are relevant to each.
The following diagram illustrates the main components of a Guided Search application based on the Forge and Developer Studio model:
Significant Features of the Forge and Developer Studio Model
This deployment model uses all components of Guided Search. It is the only deployment model that uses Developer Studio.
Forge is the source of input to dgidx.
Forge receives record data from the Content Acquisition System (CAS) and/or external sources.
Forge receives configuration data in XML files that are generated by
Developer Studio. The XML files are stored in the
config/pipeline directory. The XML files should be
edited through Developer Studio and not through a text editor.
Note
In this model, Forge receives record and configuration data from external sources only when it requests (pulls) the data. In other models, external sources send (push) record and configuration data to Forge or CAS without having received requests for the data.
Software Versions Used by the Forge and Developer Studio Model
Guided Search applications implemented according to the Forge and Developer Studio model use this version of the Discover reference application:
.../ToolsAndFrameworks/version/reference/discover-data
Documentation for the Forge and Developer Studio Model
Because the Forge and Developer Studio Model uses all components of Guided Search, you will find applicable information throughout the Guided Search documentation set.
Note, however, that Platform Services XML Reference is applicable only as a source of background information about configuration parameters. You do not need to edit the XML configuration files directly, and you can ignore sections of the documentation that explain how to edit XML files as an alternative to using Developer Studio.
The following diagram illustrates the main components of a CAS record store merger model Guided Search application:
Software Versions Used by the CAS Record Store Model
Guided Search applications implemented according to the CAS record store merger model use the following software versions:
CAS Record Store Merger Model
This model does not use either Forge or Developer Studio. It uses all other components of Guided Search.
CAS is the source of input to dgidx.
CAS receives record data from external sources, and it receives configuration data from the Endeca Configuration Repository and in XML configuration files.
The CAS record store merger model relies largely on resources other than XML files to configure the data that CAS provides as input to dgidx:
To configure MDEX properties and dimensions, methods of
config_import_apiare invoked byindex_config_cmd.[bat|sh]through CAS-based deployment templates . You can useindex_config_cmd.[bat|sh]to import and export these property and dimension configurations in theindex-config.jsonfile.Dimension configurations, including configuration managed externally to Guided Search, must be written to dimension value record stores. This mechanism makes it possible to specify ranges of values and order information as dimension values.
Documentation for the CAS record store merger model
References in the documentation to Forge and Developer Studio are not applicable to the CAS record store merger model.
Refer to the Oracle Commerce Content Acquisition System Developer's Guide for information about:
The features of a CAS-based application that must be edited through XML files. Refer to the Oracle Commerce XML Reference Guide for detailed information about these XML files.
How to load dimensions, properties, and precedence rules to record stores.
The role of the Endeca Configuration Repository in configuring a CAS-based application.
Refer to the Oracle Commerce Workbench User Guide for information about how to configure Experience Manager rules, keyword redirect rules, thesaurus entries, and phrases. You do not configure these features in XML files.
Refer to the Oracle Commerce Content Acquisition System Developer's Guide for information about the XML files used for configuring application features in a CAS-based application.
