Introduction

Catalog views provide a mechanism to configure the visibility of products in a catalog for certain users. With this approach it is possible to offer a different set of products to different customers and/or customer segments.

Each user in an organization typically takes a certain role that is associated with certain access privileges. These privileges also need to be represented in the organization catalogs to enable users-specific (customer-specific) catalog browsing. Using the platform concepts, a catalog administrator can grant the respective permissions per customer segment on the product and category level. This information is used later on during catalog browsing to display exactly those categories and products a certain customer is permitted to view. The catalog view concept allows the catalog administrator to define filters (or visibility rules) that should be applied upon a catalog. The system handles the mapping of the visibility rules to the underlying catalog representation by automatically creating the appropriate permission setting on the product instance level.

This approach is based on time-consuming database operations that create entries for each product and category that is included in a view.
These operations cannot be executed on demand in the live system, because this would slow down the whole storefront application. Therefore the creation of catalog views comprises two steps.

1. Configure the catalog view. This configuration contains:
   • Online-flag / publishing schedule
   • Inclusions of catalogs/categories/products (mandatory)
   • Exclusion of catalogs/categories/products (optional)
   • One or more customer segments (mandatory)
2. Publish the filter contents.
   It is possible to choose if the publishing is done manually only or if there is a special time schedule (e.g., every 6 hours).
   

Here are some important facts about catalog views:

• If there are no products included in a category, the category is hidden.
• It is possible to create multiple catalog views for the same catalog, but:
  • Different catalog views should not contain the same products. Using the same database entries in different contexts may cause performance problems.
  • For multiple catalog views the union of all computed products is displayed (not intersection set).
• If no (valid) catalog views exist all products are displayed.

References

• Cookbook - Catalog Views
• Cookbook - Catalog Views 7.9
• Cookbook - Catalog Views (7.4 - 7.8)
• Video Tutorial - Catalog Views (valid from 7.6)

Catalog View Creation

A catalog view can be created manually in the Commerce Management application, imported with the standard Import/Export framework or via DBinit.

The creation of a catalog view involves the creation of the following additional objects:

• Artificial User Group (Filter Group) - It has the same identifier as the catalog view and is used to identify the visible products and categories in this catalog view.
  This means, products and categories which have role assignments to a filter user group, are visible in the corresponding catalog filter.
• Target User Group (user group of type "CATALOGFILTER") - It has the same identifier as the catalog view, but prefixed with "CatalogFilter_".
  This user group is used to identify the target users assigned to the catalog view, e.g., the users for which this catalog filter is accessible. An user assigned to a catalog filter target group can see only products and categories, visible by this or another catalog view, also assigned to this user.

Catalog View States

The following catalog view states have been introduced:

• Online
  • Filters marked as online are active.
  • Only online filters are used during catalog browsing. Before a filter can enter the online state, it needs to be published (i.e., the role assignment creation process has to be triggered).
• Offline
  • Filters marked as offline are inactive.
  • Offline filters are not used during catalog browsing.
  • Newly created filters always start in the offline state.
  • Once the catalog administrator publishes the filter, the filter can enter the online state.
  • The catalog administrator can manage offline filters (i.e., adding / removing visibility rules). The offline state can be used to disable a filter temporarily without deleting it.
• Publishing
  • Filters in publishing state are considered inactive.
  • They are not ready to be used during catalog browsing until the publishing process has been finished.
  • After the publishing is done, the catalog filter restores its previous state.
• Deleted
  • Filters marked as deleted are considered inactive.
  • They are not used during catalog browsing.
  • Deleted filters cannot be managed any longer - They just wait for the deletion job to remove all their role assignments and this happens asynchronously to prevent data inconsistencies since filters marked as deleted (or offline) will not be evaluated during catalog browsing.

Examples

Catalog Filter Model

The diagram below provides an example for a single catalog filter (view).

Catalog filters - A simple diagram

The example shows an organization with a single catalog and six offers.
The sample catalog filter contains inclusion and exclusion rules defined for the organization catalog structure.
The gray tones in the diagram are used to visualize which products are bound to which categories.
The (simplified) semantics of the sample catalog filter is the following:

• Products 1, 2, 4, and 5 are visible since they are bound to a catalog branch that is included in the catalog filter.
• Product 3 is not visible since there is an explicit exclusion rule for category 'E'.
  This exclusion rule overrides the inclusion rule defined for category 'B'.
• Product 6 is not visible since it is bound to a catalog branch that is not included in the filter.

Catalog Filters and Customer Segments

Once defined, catalog filters need to be assigned to customer segments.
Using this approach, it is fairly easy to define a restricted filter for all users of an organization (i.e., a catalog filter assigned to user group "Everyone") and set up additional, less restricted features for other user groups such as managers.

The diagram provides an example for such a user - filter mapping through user groups.

Catalog filters: Mapping of user groups and filters:

In the example three catalog filters are mapped onto two users.
The two users have different roles in the organization and therefore different access privileges for the organization's catalogs.
User 1 fulfills roles 1 and 3 while user 2 fulfills roles 2, 4 and 5.
Filter 1 provides a user specific catalog view for users in roles 1 and 2.
Filter 2 provides a view for users in roles 3 and 4, whereas filter 3 is a view for users of role 5.
Based on their roles, the two users are mapped onto the following visibility rules of the organization’s catalogs:

• User 1 has access to all catalog sections defined in filter 1 and 2.
• User 2 has access to all catalog sections defined in filter 1, 2, and 3.

Users always get the privileges of all filters that have been assigned to them through all of their roles.
In case of multiple filters per user (as in the example above), all inclusion and exclusion rules are interpreted as a union.
A user will therefore have access to all catalog sections provided by the union of all filters that are assigned to the roles which the user has.
In a similar vein, the user will be excluded from all catalog sections listed in the exclusion list of all catalog filters that are assigned to the roles which the user has.

Catalog View Implementation

 The models below show the business objects relations of the catalog filter concept. They are separated in four parts:

• Catalog Filter -> Customer Segment Assignments

  

• Catalog Filter -> Customer Assignments

  

• Customer -> Catalog Filter Assignments

  

• Customer Segment -> Catalog Filter Assignments

  

Catalog View Stages

The definition of a catalog filter contains configuration of visibility rules (inclusions and exclusions of categories/products). Exclusions can be configured only if inclusions are already configured (defined). At the time the catalog filter is in configuration phase, e.g., target group is assigned and inclusions are configured but exclusions are still not, an user assigned to this filter could see products which are going to be excluded. To avoid this scenario, an additional (preprocessing) step (before the filter is really applied to the storefront) have to be performed to ensure consistency between configured visible products and the actually visible products. This step is called Publishing. The following stages are distinguished: 

• Filter Definition/Configuration Stage
  The definition stage allows the catalog administrator to set up catalog views.
  In this stage, the following information is maintained:
  • General information - catalog view name, description, publishing interval, status (online/offline)
  • Visibility rules configuration - definition of product/category inclusions/exclusions
  • Target group assignments - configuration of customers and/or customer segments for which this catalog view is applied
  The catalog filter has no effect on the actual catalog until it is published.
• Filter Publishing Stage
  The publication stage performs the mapping of the included and excluded categories/products to the underlying product and category role assignments.
  The main task of the publishing stage is to identify all products and categories that are visible in the context of a particular filter.
  For all visible products and categories, the corresponding role assignments are created automatically in a database mass-data operation.
  The created role assignments have highly de-normalized representation of the original catalog filter.
• Filter Refresh/Republish Stage
  The refresh stage is necessary due to the de-normalized representation of visible products and categories in the publication stage. This means, if a product/category inclusion or exclusion is changed, this is not automatically applied to storefront. The catalog filter needs to be published again in order to update the role assignments for the visible products and categories.
  De-normalization is necessary for performance reasons and may lead to inconsistent data if visibility of a product/category is changed and the publishing is skipped.
  Whenever the underlying product or category set changes (e.g., due to imports) the set of visible products and categories needs to be recalculated for each filter in the system.

According to described catalog view stages the filter definition and maintenance are separated from the actual filter execution.
Mapping of the catalog filter visibility rules to role assignments (de-normalization) performs complex mass-data operations that are not executed synchronously during filter definition but instead the publishing process is responsible for this job.

Configuration

General

A catalog view has the following attributes:

Inclusions/Exclusions

To define the visibility of products for certain user/department roles, a catalog view should have inclusions and may have exclusions.

Inclusions might be:

• Catalogs
• Categories
• Products

The inclusion of a higher level object (e.g., catalog) implies the inclusion of all subordinated objects (e.g., categories, products).

Exclusions might be:

• A subset of the inclusions

The inclusion/exclusion mechanism also works for dynamically assigned products. If Update Product Assignments SLDSystem job is still not executed you can only include/exclude catalogs and categories as the products are still not visible/assigned to this category. Otherwise, particular products is possible to be included/excluded.

There are different structures which store the included and excluded categories and products (during filter definition stage). These structures are called FilterProductAssignment (stores included and excluded products) and FilterObjectAssignment (stores included and excluded categories). The important properties are described in the tables below.

FilterProductAssignment properties:

FilterObjectAssignment properties:

Inclusion vs. Visibility of a Product/Category

A product is included in a catalog view if there is an inclusion rule for this product. This means the product is explicitly selected to be included in the catalog view - not by category but the product itself.

A product is visible in a catalog view if:

• It is explicitly included in the catalog view AND there is no exclusion rule for a category of this product
  Example: product P1 is assigned to category Cat3 which has a parent Cat2 which has a parent Cat1. If P1 is explicitly included and Cat1, Cat2 or Cat3 is excluded - the product is not visible.
• A product category Cat2 is included in the catalog view AND (there is no exclusion rule for parent or child category of the Cat2 category OR the product is not excluded itself)
  Example: product P1 is assigned to category Cat3 which has a parent Cat2 which has a parent Cat1. If Cat2 is included and Cat1 or Cat3 is excluded or the product P1 is excluded - the product is not visible.

If the product is assigned to more than one category and only one of them is included - it is visible only through this category.

A category is included in a catalog view if there is an inclusion rule for exactly this category. This means the category is explicitly selected to be included in the catalog view.

A category is visible in a catalog view if:

• It is explicitly included in the catalog view AND there is no exclusion rule for a parent category
  Example: category Cat3 has child Cat4 and Cat3 has parent Cat2 which has a parent Cat1. If Cat3 is explicitly included and Cat1 or Cat2 is excluded - the category Cat3 is not visible.
• A parent category is explicitly included in the catalog view AND (there is no exclusion rule for the current category OR for a category which is a parent of the current one)
  Example: category Cat3 has child Cat4 and Cat3 has parent Cat2 which has a parent Cat1. If Cat3 is the current category (not explicitly included) and Cat1 is explicitly included but Cat2 or Cat3 is excluded - the category Cat3 is not visible.
• A child category is explicitly included in the catalog view AND (there is no exclusion rule for the current category OR for a category, parent of the current one)
  Example: category Cat3 has child Cat4 and Cat3 has parent Cat2 which has a parent Cat1. If Cat3 is the current category (not explicitly included) and Cat4 is explicitly included but Cat1, Cat2 or Cat3 is excluded - the category Cat3 is not visible.

Child/Parent Relations and Inclusion/Exclusion Rules

There are some rules which are applied on products/categories when include/exclude a product/category. These rules are related to forbidding the possibility to include/exclude certain products and categories when something else is already included/excluded. These rules define the following behavior:

• if a product is explicitly included - there is no possibility to include the categories of this product and their parents -> at category level there is a child inclusion rule and the corresponding category is implicitly included.
• if a product is explicitly excluded - there is no possibility to exclude the categories of this product and their parents -> at category level there is a child exclusion rule and the corresponding category is implicitly excluded.
• if a category is explicitly included - there is no possibility to include the parent categories, the child categories and products -> at parent category level there is a child inclusion rule and the parent category is implicitly included. At child category level or product level there is a parent inclusion rule and the child categories/products are implicitly included.
• if a category is explicitly excluded - there is no possibility to exclude the parent categories, the child categories and products -> at parent category level there is a child exclusion rule and the parent category can not be explicitly excluded. At child category level or product level there is a parent exclusion rule and the child categories/products can not be explicitly excluded.

Uninclusion and Unexclusion of a Product/Category

Uninclusion of a product/category means that the inclusion rule is deleted and the corresponding category/product is no longer visible. Also, the parent/child inclusion rules defined by this category/product are removed. Mean that if the same category/product is included in another catalog filter for the same user - it will still be visible.

Unexclusion of a product/category means that the exclusion rule is deleted and the corresponding category/product is visible again. Also, the parent/child exclusion rules defined by this category/product are removed. Mean that if the same category/product is excluded from another catalog filter for the same user - it will still be visible.

Inclusions/Exclusions of Complex Products

There are some special cases for product bundles, retail sets and variations.

Bundles

Products with type Product Bundle and Bundled Product can be treated as normal products for catalog views.
That means:

• If the product bundle is excluded in a catalog view, all (assigned) bundled products are still displayed (separately) in the shop.
• If a bundled product is excluded in a catalog view, all other bundled products and its product bundle are displayed in the shop.
• If a product bundle or bundled product does not have a category assigned, this bundle (or bundled product) is not visible in a catalog view and therefore in the shop.

Retail Sets

For retail sets (Type Retail Set and Part of retail set) it is different.

• If the retail set is excluded, its parts (products with type Part of retail set) are still displayed as normal products.
• If the retail set is included, it needs at least one included part of retail set assigned to be displayed.
• If a part of the retail set is excluded, it is not displayed within the retail set.
• If all parts of a retail set are excluded, the whole retail set is not available.
• If a retail set/part of the retail set does not have a category assigned, this retail set (or part of retail set) is not visible in a catalog view and therefore in the shop.

Variations

In the context of Intershop, the Variation Master does not exist alone - it requires at least one Variation Product assigned. That's why catalog filter inclusion/exclusion mechanism, together with the publishing process, ensures the variation master is visible only if it has at least one variation visible. This means:

• If the variation master is explicitly included, it requires at least one variation explicitly included to be visible. Otherwise, a post-publishing procedure will remove the master which does not have a visible variation.
• If the variation master is not explicitly included, then the explicitly included variation products will be removed from the post-publishing procedure. This is to ensure the consistency of the master-variation pair - both have to be visible (included).
• If the variation master is explicitly included, then all variation products have to be explicitly included to be visible (variation master is visible with at least one variation visible, but if all variations need to be visible - they have to be explicitly included).
• If the variation master is explicitly excluded, then all included/visible variation products are automatically excluded during the Publishing stage.
• If a variation master is included but all variations are excluded, then the variation master is removed from the visible products.
• If a variation product is explicitly excluded, then it is not shown when changing variation selection in the Storefront.
• If the default variation of a master is excluded, then first retrieved visible variation is shown (fallback variation).
• If the variation master or a variation product does not have a category assigned, this master (or variation) is not visible in a catalog view and therefore in the shop.
• If the variation master is categorized and included but no variation is categorized - then no variation is possible to be included in the catalog view and therefore the included master is removed from the visible products by the post-publishing process.
• If a variation product is categorized and included but variation master is not categorized - this master is not possible to be included in the catalog view and therefore the included variations are removed from the visible products by the post-publishing process.
• If the variation master is categorized and included by category Cat1 and variations are assigned to Cat2 which is not included - then this single master is removed from the visible products by the post-publishing process. And the same if the category with variations is included but the category of the master is not included - the variations are removed from the visible products by the post-publishing process.
• If all variations are excluded by excluding their master - the unexclusion (back to visible products) requires to unexclude the master and at least one variation (otherwise the single master will be removed by the post-publishing process).

Customer Segments

For every catalog view, a set of customer segments can be assigned to define who should be able to see the products. These segments come from the customer segmentation service. When a new assignment is made a new hidden consumer and user group will be created for the assigned segment, if one doesn't already exist. The customer segment is assigned to the catalog view through that user group.

Customers

Catalog views can also be assigned directly to customers. They work in addition to the catalog views assigned to the customer segments of the customer.

Publishing

As already mentioned, the publishing process is time-consuming and complex because the set of included products (explicit and implicit) has to be determined and a database entry has to be created/changed for each involved product and category. During this publishing process the visibility of the products and their categories is computed. All of these objects get an entry in their corresponding *_RA table (e.g., PRODUCT_RA, CATALOGCATEGORY_RA) which has to be created/changed/deleted in every publishing process depending on the inclusion status.

The publishing process triggers different actions as shown on the diagram below:

On this diagram four main steps are executed with the corresponding sub-steps:

1. Remove dead catalog filter rules
2. Refresh global product-category assignment view with several sub-steps
3. Publish catalog filter with a post-processing step for removing variations without masters and masters without variation visible from PRODUCT_RA table
4. Invalidate domain (site) specific page caches

Remove Dead Catalog Filter Rules

On this step the no longer valid assignments of the catalog filter are removed. These assignments include filter-product assignments, filter-category assignments and filter-group assignments (user group, customer segment). This step performs a search operation to check if a particular assigned product/category/group still exists in the system. If this product or category or user group no more exists - the corresponding assignments are removed from the catalog filter configuration.

Refresh Global PCA View

Since IS7 supports two types of Product-Category assignments (implicit (dynamic) and explicit (manual)) there is a need to refresh especially the dynamic assignments. The categories which use dynamic product assignments are also called categories with dynamic binding. For each such a category there is a search query definition assigned which contains information how to retrieve the products to be assigned. Usually this information is a specific attribute or another (context) category. As this information is saved in a search query definition, it is ready to be used with a search server. That's why the current configuration of a dynamic bound category requires built and up-to-date product search index for the current locale. Currently all categories with dynamic binding use Solr product search index to retrieve the products (by the given attribute(s)) - the category's search query is transferred to a Solr search query, then call the search index with this query and the result is assigned to the category.

In catalog views it is possible to include/exclude a particular dynamic bound category but if the product assignments are still not initially retrieved - the category is assumed empty. That's why there is a need to extract these product assignments which will be added later (during publishing of the catalog view) to the set of visible products. For this purpose a new process is created acquiring the resource IEProductCategoryAssignmentView which updates the corresponding database view with the retrieved product-category assignments from the search index result.

The following sub-steps describe the process of product selection and category assignments:

• Get the categories with dynamic binding.
• Get the search query definition from the currently iterated category (for each category).
• Get the locale specific search index and check the search server availability - If there is no search index or search server is not available, then skip querying search index and refreshing product assignments for this category.
• Query search index to get products to be assigned to this category - the objects from Solr search result are transformed to ISH objects, usually ProductBO.
• Refresh dynamic product assignments - this step inserts the new product-category assignments in the database view.

At this point the product-category assignments are done and ready for the publishing step.

Publish Catalog Filter

The database table PRODUCT_RA contains an entry for each product that is contained in the visible products set. The database table CATALOGCATEGORY_RA contains an entry for each catalog category that is contained in the visible categories set. The visible products set is a set of products contained in the included set and not contained in the excluded set (included set minus excluded set). The visible categories set is a set of categories contained in the included set and not contained in the excluded set (included set minus excluded set).

Exclusions are used only in the context of a single catalog view. If for example you have two catalog views - C1 and C2 - and a product P is included (implicitly or explicitly) in both, but excluded only in C2, then P is still in the visible product set.

The operation for marking the product and category instances as being visible in the particular view (create/change/delete an entry into/from a *_RA table) is used later on during catalog browsing and catalog search to decide whether a product or category is supposed to be part of the result set. This means that the existing product and category role assignment tables are used to store our "visibility markers". Platform role assignments are always established between an authorization object (such as products and categories), a customer segment and a role. The role assignment connects these three entities to define "who is allowed what where". In order to integrate with this concept, an artificial user group has been created for each catalog filter and a standard role (i.e. access privilege) representing catalog visibility. The existence of a role assignment instance for the artificial user group representing the filter is interpreted as the "visibility marker" and only catalogs and products that have a role assignment to the filters of the user will be shown during catalog browsing.

There is also a post-publishing step which checks for and removes the single variation masters (masters without visible variation) and the single variation products (variations without visible master). This step is performed to ensure that there is always a visible master with at least one visible variation. This is done right after the publishing has been finished because it is no possible to detect this behavior during catalog filter configuration. One example is: someone includes a category with variations but the master is not categorized and therefore not included and not visible in the catalog view; this means the master is not visible in the storefront; if the master is not visible in the storefront - the variations are also not visible because ISH Solr integration stores the master and its variations in one single Solr document and the catalog filter attribute is applied and checked against the master only. On the other hand, the master is not needed alone since the product detail page of the master shows the data of the default variation or first visible variation (if the default is excluded/not visible). That's why catalog view publishing process ensures always a visible master with at least one visible variation by removing the corresponding single masters and variations.

Publishing or republishing is needed when:

• The product category assignment has changed (implicit or explicit)
• Products have been added/removed
• Categories/catalogs have been changed
• Catalog and product relevant data has been changed

Publishing or republishing is NOT needed when:

• The customer segments assigned to a filter are changed, e.g., a user has been added to an existing customer segment
• There is any other change outside the scope of catalog and product

Invalidate Page Caches

The last step of the publishing process is to invalidate domain specific page caches. This includes invalidation of pipeline page cache and static content cache, as well as product related ORM caches.

Accessibility

A catalog view "knows" about its accessibility. Use the Java extension point com.intershop.component.mvc.capi.filter.CatalogFilterBOAccessibilityHandler-isAccessible to implement your own extensions specifying rules by which a catalog view is accessible. For the catalog view to be considered accessible, there should be no extensions available or at least one extension has to return that the catalog view is accessible.

In the standard system an accessibility extension exists that checks whether the catalog view is online, has been published and whether the catalog view is active according to the assigned target group.

Import and Export

This is an example export of catalog view with the latest XML schema definition.

<?xml version="1.0" encoding="UTF-8"?>
<enfinity
        xsi:schemaLocation="http://www.intershop.com/xml/ns/enfinity/7.0/bc_mvc/impex bc_mvc.xsd"
        xmlns="http://www.intershop.com/xml/ns/enfinity/7.0/bc_mvc/impex"
        xmlns:xml="http://www.w3.org/XML/1998/namespace"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<catalog-filter id=".9UKDABnCPMAAAFFyn4DqEH2" state="1" update-interval="0">
    <scope id="" type=""/>
    <name xml:lang="en-US">MyCatalogView</name>
    <description xml:lang="en-US"></description>
    <included-objects>
        <categories>
            <category name="206" domain="PrimeTech-Computers"/>
            <category name="242" domain="PrimeTech-Computers"/>
            <category name="150" domain="PrimeTech-Computers"/>
            <category name="225" domain="PrimeTech-Computers"/>
            <category name="2" domain="PrimeTech-Computers"/>
            <category name="Computers" domain="PrimeTech-Computers"/>
            <category name="106" domain="PrimeTech-Computers"/>
            <category name="191" domain="PrimeTech-Computers"/>
        </categories>
    </included-objects>
    <excluded-objects>
        <categories>
            <category name="3001" domain="PrimeTech-Computers"/>
        </categories>
    </excluded-objects>
    <filter-targets>
        <customers>
            <customer id="Heimroth"/>
            <customer id="Clarkson"/>
        </customers>
        <customer-segments>
            <customer-segment id="CG_PremiumConsumers" repository-id="PrimeTech-PrimeTechSpecials-Anonymous" />
        </customer-segments>
    </filter-targets>
</catalog-filter>
</enfinity>

Using Catalog Views in the Storefront

Every time a product or a category is displayed in the storefront, the catalog views have to be considered. This includes but is not restricted to:

• Product/category links
• Product variations
• Product recommendations from external recommendation engines
• Products from search results
• etc.

A category is visible in the storefront if all of the following conditions are met:

1. One of its ancestors, at least one of its descendants or the category itself is selected for inclusion
   AND
2. It is not excluded from all catalog views that are active for the current user
   AND
3. It or at least one of its descendants have at least one visible product assigned (not all products are excluded from this category or its descendants)

In short, a category is visible if there is self/child/parent category inclusion, no category exclusion in all catalog views for the current user and not all products of this category (and subcategories) are excluded from all catalog views of the current user.

Categories are not implicitly made visible if there are only products selected for inclusion, even if those products are assigned to those categories. This means, if a category is not included and none of its ancestors/descendants is included, but the products of this category are included in the catalog view, the categories from the product category path are not visible.

A product is visible in the storefront if:

• It is not excluded from all catalog views that are active for the current user

Solr Search Index Configuration for Catalog View Handling

In many web shops there is a search server which is used for different customer tasks such as search by term, catalog browsing, paging of search results, filter of search results by different criteria and so on. The purpose of the search server is to replace the usage of database queries to retrieve the desired information. IS7 installations use Apache Solr as such a search server. There is also a Solr integration cartridge (ac_seach_solr) which contains the code to use and maintain the Solr indexes.

During catalog browsing or search, a particular customer can see only the products and categories visible in terms of a catalog view. Currently IS7 Solr integration gets all products in the given repository and adds them to the configured search index for this domain. In the Solr index each product is represented by one Solr document with different attributes corresponding to the product attributes. So, a product could be visible for one customer and invisible for another one depending on which catalog views are assigned to each of them. Since Solr contains product information, there is a need to mark which product in which catalog view is included/visible. During catalog browsing all filters of the customer are retrieved and they are added to the Solr search query to return all products accessible in these filters.

To be able to recognize which product in which filter is included, ISH Solr integration defines the search index attribute CatalogFilterIDs (Catalog View Filter) which contains all catalog filter IDs for a particular product. This attribute is not indexed by default because a sales channel may not have catalog views defined and the usage is useless. If a sales channel defines catalog views, the attribute CatalogFilterIDs have to be included in the indexed attributes. This requires an index rebuild to add the newly included attribute in Solr documents. Without this attribute, Solr search ignores catalog views. Also, for products which have no assignments to catalog views, the CatalogFilterIDs attribute is missing in the corresponding Solr document.

CatalogFilterIDs Search Index Attribute

CatalogFilterIDs attribute has the following properties:

The data provider, which is used during search index rebuild to collect and save the catalog view data in the index, works on the following way:

• Gets the product
• Retrieves all product-role assignments (from PRODUCT_RA table)
• Retrieves all online catalog filters in the channel
• If the user group ID of a product-role assignment is equals to the catalog filter group ID, the corresponding filter ID is added to the list which collects the assigned catalog filters.
• Assigns the CatalogFilterIDs attribute to the list with collected catalog view IDs

This attribute is not set per product (Solr document) if the list with catalog filters is empty. This is, in such case the product does not have assignments to any catalog filters.

Solr Document Containing Catalog View Information

After all the catalog filters are published and the CatalogFilterIDs attribute is added to a product search index with required rebuild - the catalog view information can be observed in the Solr Console, e.g., for a product with SKU=10680607 we have the information that it is included in a catalog view with UUID=2UEKDADA9Y4AAAFT8ZcUoPC_.

<doc>
    <arr name="CatalogFilterIDs">
      <str>2UEKDADA9Y4AAAFT8ZcUoPC_</str>
    </arr>
	<arr name="SKU">
      <str>10680607</str>
    </arr>
 	<double name="ProductListPrice">1337.95</double>
    <arr name="CategoryNames">
      <str>897_Asus</str>
      <str>897</str>
      <str>Computers</str>
    </arr>
    <date name="OnlineFrom">1970-01-01T00:00:00Z</date>
    <int name="OnlineFlag">1</int>
    <double name="ProductSalePriceNet">1337.95</double>
    <str name="UUID">v5AKDADAaK0AAAFT3jIFzOFh</str>
    <str name="CatalogDomainName">inSPIRED-Computers</str>
    <str name="ManufacturerName">Asus</str>
   ...
</doc>

If a product has more than one catalog view assigned, the Solr document will look like this:

<doc>
	<arr name="CatalogFilterIDs">
      <str>px8KDADAX20AAAFTEKcUoPDF</str>
      <str>2UEKDADA9Y4AAAFT8ZcUoPC_</str>
      <str>zZ8KDADAZCwAAAFTPecUoPDH</str>
    </arr>
	<arr name="SKU">
      <str>0889296696803</str>
    </arr>
	...
</doc>

Actions for Configuration of Catalog Filter and Search Index

Since the catalog filter publishing process refreshes the categories with dynamic binding which require a built, up-to-date search index, it is required that all search indexes are initially built. If not built, a subsequent publishing process may hang for some time (usually 10 min) waiting for an acquired resource to be released. Also, if a category with dynamic binding is included in a catalog view and the SLDSystem job Update Product Assignments still did not ran - there is no possibility to exclude particular products from this category as the product assignments are still not calculated. The catalog view publishing process also refreshes the dynamic binding, but this happens after the catalog view is configured. At the time of configuration, dynamic bound products could still not be visible.

Because of the above mentioned problems there are some steps which have to be followed for properly setting up catalog views with Solr index:

• Initially built search indexes - run the SLDSystem job Rebuild Search Indexes.
• Update implicit/explicit product category assignments (dynamic binding) - run the SLDSystem job Update Product Assignments.
• Create/maintain catalog view - add inclusions, exclusions, target groups.
• Publish the catalog view.
• Add CatalogFilterIDs attribute to the Solr product search index - to index catalog filters for each product - and rebuild the index.
• Go to the web shop and check the results depending on the target groups of the catalog view.

Performing Solr Search Query with Catalog Filters

For a particular, storefront-browsing user the Solr search server needs to collect the visible products for this user and must return them as a result. As already mentioned, there is a search index attribute called CatalogFilterIDs which contains all catalog filters in which the product is visible. This attribute has to be included in the indexed attributes of a search index to be able to select only products, visible in a particular catalog view. Once the index is rebuilt and contains catalog view information, it is ready for search queries including catalog filter conditions.

Search queries are performed when browsing leaf categories with products, during paging of product lists in a category, when search by term in the search field is triggered, when filtering search results by different criteria (category, brand, price, ...). In all these cases catalog filters are also considered. A search query generation process takes place to add catalog filter condition to the query. This process has two steps:

1. Get catalog filters by user - the catalog filters are retrieved only if CatalogFilterIDs attribute is included in the index, otherwise no check is performed and no catalog filters are returned. Also, if the attribute is included and the current user don't have any catalog view assigned, no filters are returned.
2. Add catalog filter condition - such condition is added to the search query only if CatalogFilterIDs attribute is included in the index and there is at least one catalog filter retrieved for the current user. Otherwise, no condition is added to the query. If retrieved user filters are more than one - they are combined with OR operator. Thus, if the current user has three catalog views assigned, the search query will contain the condition CatalogFilterIDs=CatalogFilterUUID1_or_CatalogFilterUUID2_or_CatalogFilterUUID3. In this way only products (Solr documents) which have CatalogFilterIDs attribute with one of the values CatalogFilterUUID1, CatalogFilterUUID2 or CatalogFilterUUID3  will be retrieved for this user.

Data Replication of Catalog Views

Catalog views can also be used in a data replication (staging) environment. This allows to configure and publish a catalog view in the EDIT system before it gets replicated to the LIVE environment. There is no separate replication group, provided by IS7, for replication of catalog views. Instead, both replication groups (CONSUMER_GROUPS and PROMOTIONS) can be used to transfer the catalog view structures to the production system. These replication groups assign MVC_CatalogFilter staging group to the current replication task which is responsible for the staging of catalog view related objects. If only catalog views need to be staged, the CONSUMER_GROUPS replication group could be used for the replication task in order to have the replication process faster.