In addition to the category, product, and sku items, the catalog repository includes catalog items that represent different hierarchies of categories and products. Each user is assigned one catalog, and sees the navigational structure, products and SKUs, and property values associated with that catalog. A given product may appear in multiple catalogs. The product repository item type includes a catalogs property whose value is a Set of the catalogs the product is included in.
Note that if a user has not been assigned a catalog, search queries and facets may not work properly for that user. This is generally not an issue for actual customers, who should all have catalogs assigned to them, but it may affect internal users testing the application. Make sure any internal users accessing the application have catalogs assigned to them.
Handling Catalog-Specific Properties
Depending on how your catalog repository is configured, the property values of individual categories, products, or SKUs may vary depending on the catalog. If so, when you index the catalog, you may need to generate multiple XHTML documents for each product or SKU (one for each catalog the item is included in).
To support creation of multiple XHTML documents per product or SKU, Oracle ATG Web Commerce includes the /atg/commerce/search/CustomCatalogVariantProducer component. This component is of class atg.commerce.search.producer.CustomCatalogVariantProducer, which implements the atg.repository.search.indexing.VariantProducer interface. (See Using Variant Producers.) The variant producer iterates through each catalog individually, so that each XHTML document contains only the property values associated with a single catalog.
The CustomCatalogVariantProducer component is added to the ProductCatalogOutputConfig component’s variantProducers property by default:
variantProducers+=\
CustomCatalogVariantProducer
The mechanism used for retrieving catalog-specific property values differs depending on the property:
For
category,product, orskuitem properties that use theatg.commerce.dp.CatalogMapDerivationclass to derive catalog-specific values, the correct values are automatically obtained by that class.The
catalogsproperty of theproductitem is configured by default to use the/atg/commerce/search/CustomCatalogPropertyAccessorcomponent. This component is of classatg.commerce.search.producer.CustomCatalogPropertyAccessor, which implements theatg.repository.search.indexing.PropertyAccessorinterface. (See Using Property Accessors.) This accessor returns, for each XHTML document, only the specific catalog the document applies to. The accessor is specified in theproduct-catalog-output-config.xmldefinition file:<item is-multi="true" property-name="catalogs"
property-accessor="customCatalog">The
CustomCatalogPropertyAccessorcomponent is mapped to the namecustomCatalogby theProductCatalogOutputConfigcomponent’spropertyAccessorMapproperty:propertyAccessorMap+=\
customCatalog=CustomCatalogPropertyAccessorThe
product-catalog-output-config.xmlfile defines a non-repository property,ancestorCategories.catalogSpecificId, which holds an array of the catalog-specific category IDs of a product’s ancestor categories. The value of this property is determined by the/atg/commerce/search/CustomCatalogCategoriesPropertyAccessorcomponent:<property display-name-resource="catalogSpecificId" store-as-docset="true"
name="catalogSpecificId" type="string" property-
accessor="/atg/commerce/search/CustomCatalogCategoriesPropertyAccessor"
output-name="ancestorCategories.catalogSpecificId"
is-non-repository-property="true" filter="unique"/>
Indexing a Large Number of Catalog Items
If your catalog repository has a large number of catalog items (for example, for a business-to-business commerce site), it is a good idea to use the store-as-collection option for the product item’s catalogs.$repositoryID property. When you do this, Oracle ATG Web Commerce Search creates a separate collection for each value of this property. Each collection encodes, for each product, whether or not the product is in the catalog that the collection represents.
For example, suppose your catalog repository has 10 catalog item and 1000 products. If catalogs.$repositoryID is stored as a collection, each catalog will have an associated collection that encodes 1000 Boolean values, one for each product, with each value indicating whether or not the product represented by that value is part of the catalog. This structure makes it very simple and fast to apply a constraint that restricts results to products in specific catalogs. It also allows catalog-membership information to be stored as efficiently as possible, since only a single bit is needed to record whether a product is in a specific catalog.
To enable this option, set the store-as-collection attribute to true for the product item’s catalogs.$repositoryID property. For example:
<item is-multi="true" property-name="catalogs" property-accessor="customCatalog">
<meta-properties>
<property name="$repositoryId" type="string" store-as-collection="true"/>
</meta-properties>
</item>The resulting XHTML document for a given product includes a separate meta tag for each catalog the product is included in. For example:
<meta name="atg:string,collection:catalogs" content="catalogA" />
<meta name="atg:string,collection:catalogs" content="catalogC" />
<meta name="atg:string,collection:catalogs" content="catalogF" />
These tags result in the creation of three collections, /Meta/catalogs/catalogA, /Meta/catalogs/catalogC, and /Meta/catalogs/catalogF.
Note that the naming convention used for collections is similar to the one for document sets. For collections, however, the slash notation does not signify a hierarchical structure; the name is just an identifier for the collection.
For information about using query constraints based on collections, see the ATG Search Query Guide.
