In order to provide a powerful full-text search, guided search and other advanced search features, Intershop 7 also has search services for product and content searches in consumer storefronts. This interface enables the integration of external search engines, which then build and query search indexes and add search features such as full-text search, guided search (after search navigation), stop word and synonym configuration, etc. to Intershop 7 based e-commerce applications.
Have a look at Cookbook - Search for related common questions.
Through integrating an external search engine, the search services provides powerful search options to Intershop 7. Depending on the actual search engine, these options may include:
This section introduces general search index management concepts, which are common for all search service implementations.
The index creation (and search, consequently) is based on configurable attributes.Hence, indexing is generally based on defining index attributes and filter attributes, as well as on defining synonyms and stop words.
Any additional search functionality (tuning, campaigns, etc.) depends on the actual search engine implemented as search service in Intershop 7.
The standard product attributes to be indexed automatically as well as additional business attributes to be offered on the Indexed Attributes tab in Intershop Commerce Management are defined in the search index type definition file for the corresponding search index.
Intershop 7 provides a convenient way to easily configure filter attributes for guided search in the consumer storefront. These filters appear at the storefront after a simple search helping users to refine their search results.
Filters are managed at the search index configuration and their according definitions are stored in the corresponding configuration file (ISH-Config.xml). Each filter is based on an indexed attribute and is applied to all objects of the index. You can choose between different behaviors for each filter, e.g., sorting, showing up based on count, filter ranges, etc.
Additionally, you can set the scope of the filter - i.e., global or constrained to specific categories. This mechanism is used for filter attributes that are relevant for specific categories only. For example, a filter attribute Display Size has been defined for the catalog category TFT Monitors. In the inTRONICS storefront, this filter attribute will only be displayed if users submit a simple search and then drill down to the category TFT Monitors.
An indexed attribute can only be used for one filter.
These are standard configuration views to manage filter attributes as deployed by default. The actual view depends on the implementation of the used search engine.
Dependent on the used search engine, filter attributes could also be managed in the search engine's own back office so there is no need to implement this at Intershop 7-side.
Synonyms are important to inform a search engine which words have similar meanings, without any similarity in form (for example: "Jeans" > "Pants").
Antonyms are used to tell a search engine that two words have nothing to do with one another, despite the fact that a search engine would report a similarity because the forms are similar (for example: "TFT" > "DVD").
The search services provides a configuration view to define both synonyms and antonyms in the back office on the Synonym tab of the respective index. The difference is in the reduction used for the word relationship. Synonyms have a word relationship reduction of 0%. Antonyms have a reduction of 100%. Intermediate values may be used to define word relationships that are not exactly synonyms, but also not antonyms. For example, Jeans > Pants. This word relationship could be given a slight reduction (such as 5%), so that a search for "Pants" would also find "Blue Jeans", but still give "corduroy pants" earlier in the list. Synonym and antonym relations defined in the back office are mapped to entries within the dedicated synonyms section in the general configuration file. A search engine specific implementation may map these synonym configurations to the search engine-specific configurations or may replace the synonym configuration tab completely if the search engine provides its own configuration pages.
For each synonym and antonym relation, you can define the reduction separately depending on the direction in which the relation is traversed. For example, when a search engine searches semantic relations for "TFT", it may identify "Monitor" as synonym item, but apply a 5% reduction. On the other hand, when looking for items semantically related to "Monitor", a search engine may identify "TFT" as a synonym, without applying a reduction. An antonym relation is defined connecting "TFT" and "DVD", indicating that these words are not related semantically.
Depending on the actually integrated search engine, the synonym evaluation may differ. Possible differences in the search approach may include, among others, recursive evaluation, synonym look up (exact or fuzzy search) or search for single words only or phrases.
Stop words can be defined in the back office to exclude words from the index that have no relevance. A typical example are function words such as "the", "a", etc., which have little meaning and can usually be ignored when searching.
Stop word definitions defined in the back office are mapped to a dedicated stop word section in the general configuration file
A search service integrates search functionality into the storefront. It consists of:
The search services are using the managed service framework. Therefore, they implement the corresponding interfaces and inherit functionality like enabling/disabling per domain via back office services tab, configuring, etc.
A class which implements the SearchIndex interface and/or extends the SearchIndexBaseImpl provides the actual implementation/functionality for a specific search engine.
This includes primarily the communication with the external search server/engine by:
For each specific SearchIndex there exists a SearchIndexType which can hold several instances of this SearchIndex with the same and/or different configurations (ISH-Config.xml). Only one of these SearchIndexes handled by the same SearchIndexType instance can be online at the same time for the same domain.
A base implementation (BaseSearchIndexType) offers functionality for handling the SearchIndexes found at the old deprecated SearchIndexMgrImpl before.
This class is primarily responsible for managing the SearchIndexTypes. A SearchIndexType - and thus the actual SearchIndex - can be enabled/disabled per domain. This is done by the SearchIndexTypeService which instantiates one SearchIndexType per domain (if set to enabled).
As the SearchIndexTypeService holds the configuration file (e.g., SFProductSearch.solr.xml (declaration of DataProviders, Standard Attributes, ImportHandler)), different search services can be implemented which use the same SearchIndex class but different configurations.
This object manages all SearchIndexTypeServices. But more important it provides the functionality to deal with the actual SearchIndexes. You can get the online indices, create new ones or delete them - internally, it delegates the calls to the proper services.
Furthermore, it handles all events in a distributed environment to keep indices in sync.
The data transformation (db -> index) is handled by the SearchIndexImportHandler (a search engine specific implementation) held by the SearchIndex.
Each SearchIndexType has a configuration file from which it is build (e.g., SFProductSearch.solr.xml) and thus for the SearchIndexes it handles.
This configuration includes amongst others:
If you finished the assignment of attributes which have to be indexed (further called AttributesToIndex( ATI)), you can finally build the index.
The workflow as follows:
Advanced Search Module Implementation and Customization: dev_asm.pdf
Search Service Solr Documentation
The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.