- v1.0.0-latest-prod
Catalog Browse acts as an intermediary between the commerce-facing frontend and any configured search provider. By default, the Broadleaf Search Services are used. The primary purpose of this mediation is to ensure that any information not present in the search service is hydrated. For example: Due to limitations in the current implementation of Search Services, pricing information needs to be hydrated onto the product results before being displayed in a commerce-facing app.
The search results request mapping of CatalogBrowseEndpoint takes in a search request and passes it through to the CatalogSearchProvider.
The provider communicates with the configured search service, then takes the search results and passes them along to the PricingProvider to hydrate pricing data.
Therefore, this endpoint does little more than pass-through requests to other microservices before returning the results to the caller.
|
Tip
|
See the OpenAPI spec for the search endpoint |
The request made can contain two headers (along with the typical X-Context-Request one) as well as the several parameters.
The headers are used to provide additional context for pricing the product results and are passed along in pricing calls after retrieving search results:
X-Price-Context: Contains general context info including the locale, currency, and user targets associated with the caller’s context
User targets include an identifier and type for a user such as an email and CUSTOMER for a single user.
X-Price-Info-Context: Contains additional context info for gathering price info for specific products.
It includes a list of the products converted into PriceableTargets as well as an optional list of predetermined PriceLists from which prices should be derived.
|
Note
|
A
|
The search request contains the following parameters passed to the search service:
query: The search term or phrase
type: The type of entity being searched for.
Defaults to PRODUCT.
filters: List of filters to pass to the underlying search engine, such as Solr.
Filters have the following properties:
name: Name of the property to filter on
values: Values of the property to filter by
ranges: The min and max values if the property supports ranged querying
ruleFilters: The rule-based RSQL filters to pass to the underlying search engine, such as Solr.
categoryProductMembershipFilters: The rule-based RSQL filters used to check if a related product is a member of the specified category. Only applies when the category’s product membership type is RULE_BASED. Used to pass to the underlying search engine, such as Solr.
enableSpellCheck: Optional. Whether spell checking should be enabled for the search
autoCorrectQuery: Optional. Whether to automatically use available spelling corrections if there are no results for the original query
spellCheckedQuery: Whether the query has already been run once to avoid unnecessarily spellchecking it again
Moreover, standard RSQL filters and pagination parameters may be included.
Search results contain a list of product results and whatever additional attributes are present based on the configured search service. Broadleaf’s Search Services additionally provides all of Spring’s PageImpl fields and the following:
Facets: Defines additional filters that can be applied by users to the search results as well as which filters are currently enabled. Facets also include the count of results that match that filter.
Sort options: Defines how the results may be sorted by a user and which way the results are currently sorted
A search redirect: Indicates that the caller should redirect to a specific URI rather than use the list of search results.
A spell check result: Added if the search engine provides suggestions based on corrective or alternative spelling of the search terms used
The search results request mapping of CatalogBrowseEndpoint takes in a search suggestion request, usually a term or partial term.
It passes this along to the CatalogSearchProvider, which responds with the TypeAheadResponse.
Product suggestions will be passed along to the PricingProvider for pricing info hydration before the final result is returned to the caller.
|
Tip
|
See the OpenAPI spec for the search suggestions endpoint |
The suggestion request includes the query term or phrase and the name of the TypeAheadConfiguration to use.
Moreover, it can include the following two headers used when hydrating pricing on product suggestions.
X-Price-Context: Contains general context info including the locale, currency, and user targets associated with the caller’s context
User targets include an identifier and type for a user such as an email and CUSTOMER for a single user.
X-Price-Info-Context: Contains additional context info for gathering price info for specific products.
It includes a list of the products converted into PriceableTargets as well as an optional list of predetermined PriceLists from which prices should be derived.
|
Note
|
A
|
The response contains a list of related keywords or text predictions and suggestions. Suggestions can be products, categories, brand names, or whatever else may be configured in Search Services. These will be provided in lists, mapped by their type.
|
Note
|
Keywords include a version with highlighting applied if enabled. |