Configure the search requestors
Requestors manage the execution of an endpoint request and return a result. The Search microservice has two built-in requestors:
- Default Query Requestor: Used by features to retrieve blocks of information.
- Links Query Requestor: Used to retrieve links for redirections and promotions (promoted results and promotion banners).
When you configure the requestors, you specify the requestor type, product catalog collection affected, the features to be used, and any post-processors to be run after executing the feature. The post-processors let you modify every result after the result has been built. For example, to add new fields. Each post-processor has its own configuration.
note
You need to create the features in the feature configuration before configuring the endpoint.
Default Query Requestor
All features except links use the DefaultQueryRequestorFactory requestor. This requestor can be customized to the customer's requirements. It uses the standard requestors
parameters.
requestors
parameters
Field | Description | Type | Default value |
---|---|---|---|
requestorId | Name of the requestor, e.g. product catalog | Yes | String |
type | Type of requestor. To use the DefaultQueryRequestorFactory requestor, enter default . Enter links to use the LinksQueryRequestor requestor (required) | String | default |
mainCollectionId | ID of the indexed product catalog collection. If you do not have this ID, ask Partner enablement (required) | String | --- |
features | List of all features associated with the requestor (required) | Array | --- |
postprocessors | Collection of processors executed after the feature cycle (required) | Array | --- |
redisCached | Determines whether a Redis cache is activated for the requestor. If you set this to true , enter a value in redisTTL (optional) | Boolean | false |
redisTTL | Number of seconds to save data in cache (optional) | Integer | --- |
coding tip
You can use a Redis cache for the requestor and determine the number of seconds of data to save in cache in the redisTTL
parameter. This parameter is useful where your customer has high traffic in the store or during the sales period. The greater the TTL (time-to-live) value, the greater the time between cached responses, and hence the greater the response and the lower impact on the search engine. However, the results may be less up-to-date and it may take longer to see any changes in configuration (for example, changes in product attribute weighting made in Equalize). If you plan to use Redis, you need to add the redis.enabled
environment variable as true
, and redis.nodes
containining the value of the Redis URL available to connect to it. The Redis service must be configured without authorization, as it is not supported by the search service.
You cannot enable a Redis cache for the LinksQueryRequestor
. The current date is added to each Elasticsearch query, so this information changes in every request.
Configuration example
"requestors": [
{
"requestorId": "catalog",
"type": "default",
"features": {
"search": [
"browsingSearch",
"sorting",
"pagination",
"filtering",
"faceting",
"boosting",
"grouping",
"searchHits",
"totalHits",
"debug"
]
},
"redisCached": true,
"redisTTL": 250,
"mainCollectionId": "empathy"
}
]
Links Query Requestor
This requestor is made for requesting blocks of information from links
index. There are three types of links: Redirections, Promotions, and Banners.
The requestor returns a previously configured URL when searching from a query. Promotions and banners also return the previously configured image.
warning
You must have set up a links
collection in the index. A 500 error code is returned if the collection does not exist.
In addition to the requestor
parameters, in the config
block, the query
parameter is used to find the link associated to the parameter. The filters configured are used to delimit the links returned. For example, ?query=home&lang=es&scope=desktop
.
Links are returned ordered by priority (weight), and then by updated date. If no query is sent, all the links marked as match_all
in the Playboard are returned.
Links are applied over certain criteria. When a link has a filter configured, it is only retrieved if the parameter exists in the request and has the same value as the configured link. When a link is configured with a filter with multiple values, that link is returned if the parameter exists in the request and has one of the values configured.
config
parameters
Field | Description | Type | Default value |
---|---|---|---|
linkType | Type of link to retrieve. Available values: DIRECT , PROMOTED , BANNER (required) | String | --- |
queryParamFilters | Filters to apply (required) | String | --- |
queryParamFilters
parameters
Field | Description | Type | Default value |
---|---|---|---|
queryParam | Parameter of the query to retrieve the value from (required) | Array | --- |
field | Field to filter the content of the value of the queryParam (optional) | String | queryParam |
Configuration example
"requestors": [
{
"requestorId": "direct",
"type": "links",
"redisCached": false,
"mainCollectionId": "empathy",
"secondaryCollectionId": "empathy",
"config": {
"linkType": "DIRECT",
"queryParamFilters": [
{
"field": "langs",
"queryParam": "lang"
},
{
"field": "filters.scope",
"queryParam": "scope"
}
]
}
}
]