About sites

Oracle Commerce Experience Manager enables you to build an application that can run multiple web sites using a single index. Business users can use this application to create site-specific pages that use a single index. Even if you are not building an application that supports multiple sites, your application must contain at least one site.

You can create applications to support multiple web sites that share the same code base, templates, cartridges, and search configuration. Each web site can have its own unique set of pages that display the site's unique look or branding.

Note

If you are using Oracle Commerce Guided Search, applications have one site by default, and Oracle does not support adding additional sites.

Individual sites are stored directly under the pages node. This default site root path is configured in the assembler.properties file. For example, in the Discover reference application, the path looks like the one in the following example: 

preview.enabled=true
user.state.ref=previewUserState
media.sources.ref=authoringMediaSources
repository.configuration.path=./repository/${workbench.app.name}
defaultSiteRootPath=/pages

In the following configuration, the Discover application contains three sites: DiscoverAll, DiscoverPrinters and DiscoverCameras. 

/pages
        /DiscoverAll
								/DiscoverCameras          
        /DiscoverPrinters

Sites are the top-level content in this application. Each page within a site belongs to exactly one and only one site. Each site node is a site definition and every application must have at least one site definition. The Assembler uses properties in these site definitions to facilitate site-specific behavior. Site definitions are stored in the pages node of the IFCR. Our sample configuration would have three site definitions: one each for DiscoverAll, DiscoverCameras, and DiscoverPrinters. 

/pages
        /DiscoverAll
            _.json
								/DiscoverCameras
            _.json         
        /DiscoverPrinters
            _.json

The following site definition for DiscoverAll shows a unique display name, DiscoverAll and description, as well as a unique URL pattern, /DiscoverAll for this site: 

{
  "ecr:type":"site-home",
  "urlPattern" : "/DiscoverAll",
  "displayName" : "DiscoverAll"
  "description" : "This site shows all things that are Discover."
}

If only a subset of records within the index are relevant for a specific site, then you must specify site-based filters. The site-based filter is applied to all queries performed on the site. The filter that is applied is determined by site context. The following configuration has three site definitions and two sites with site-based filters. One for DiscoverCameras and one for DiscoverPrinters. The filter for DiscoverCameras would filter out all records except those that were relevant to cameras, while the DiscoverPrinters filter would filter out all records except those that were relevant to printers. DiscoverAll includes every record in the index, so that site does not have a filter. 

ifcr/
    /pages
        /DiscoverAll
              _.json
								/DiscoverCameras
              _.json
              filterState.xml        
        /DiscoverPrinters
              _.json
              filterState.xml

The following is an example of the filterState.xml file for DiscoverCameras: 

<Item class="com.endeca.infront.navigation.model.FilterState" xmlns="http://endeca.com/schema/xavia/2010">
          <Property name="recordFilters">
            <List>
              <String>product.category: "Cameras"</String>
            </List>
          </Property>
</Item>

Note that Oracle does not support site-based filters in Oracle Commerce Guided Search.

In a multiple site application, the Assembler must identify the site or the site state for incoming requests. This identity is included in the request as part of a domain name, a URL, or a request parameter. Resolving this site state gives the Assembler the ability to retrieve the relevant site definition, the site-based filter and other site specific information.

The ActionPathProvider is an interface that you are free to implement as you see fit. Cartridge handlers in applications built with Spring can use the ActionPathProvider to determine navigation or record detail action paths. The content paths that prefix navigation and record states are configured as sets of key-value pair mappings. In a multiple site application, the ActionPathProvider can define different mappings for pages on different sites. The following example shows an ActionPathProvider in the assembler-context.xml file with new mappings for the DiscoverCameras site that has been added to navigationActionUriMap and the recordActionUriMap: 

<bean id="actionPathProvider" scope="request" class="com.endeca.infront.re¬
fapp.navigation.BasicActionPathProvider">
 <constructor-arg index="0" ref="contentSource"/>
 <constructor-arg index="1" ref="httpServletRequest"/>
<!-- navigationActionUriMap -->
 <constructor-arg index="2">
 <map>
    <entry key="^/pages/DiscoverCameras/.*$" value="/pages/DiscoverCameras/camerasbrowse" />
    <entry key="^/pages/[^/]*/mobile/detail$" value="/mobile/browse" />
    <entry key="^/pages/[^/]*/services/recorddetails/.*$" value="/services/guidedsearch" />
    <entry key="^/pages/[^/]*/detail$" value="/browse" />
    <entry key="^/services/.*$" value="/services/guidedsearch" />
 </map>
 </constructor-arg>
<!-- recordActionUriMap -->
 <constructor-arg index="3">
 <map>
    <entry key="^/pages/DiscoverCameras/.*$" value="/pages/DiscoverCameras/camerasdetail" />
    <entry key="^/pages/[^/]*/mobile/.*$" value="/mobile/detail" />
    <entry key="^/pages/[^/]*/services/.*$" value="/services/recorddetails" />
    <entry key="^/pages/[^/]*/.*$" value="/detail" />
    <entry key="^/services/.*$" value="/recorddetails" />
 </map>
 </constructor-arg>
 <constructor-arg index="4" ref="siteState"/>
 </bean>

Copyright © Legal Notices