Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

The Search and Retrieve API provides a means for looking up content from an application based on search criteria including related content and returning the relevant fields for a specific use case. The application can be an iOS or Android mobile app, a web application or a web site requesting the content. The Search and Retrieve API can be used to search for any content, but it is especially useful for headless content because it allows for referenced content to be included and it also offers field filtering. It is very fast thanks to its use of the Apache Solr search engine and because it retrieves content via the XperienCentral cache. The search queries are concise and written either in JSON, which is usually used when querying from code, or in YAML which is easier to read and write when developing or testing queries.

...

max_items_in_result
Limits the total number of content items (pages and media items) returned in the response, regardless of those specified in the from and to parameters. (See Search Parameters for details on those parameters.) When the limit has been reached, no more references defined in the includes section will be "expanded".
default_search_result_amount
The default number of results that are returned when no from and/or to parameters have been provided in the query.

Clustered environments

contentindex_index_readonly_nodes


Panel
borderColor#0081C0
titleColor#0081C0

The following applies to XperienCentral versions R37 and higher.

When using the Search and Retrieve API on a clustered environment, this setting should be

turned on

enabled. When

activating

you enable this

on

setting in an existing environment, you need to manually rebuild the content index

will need to be rebuild

. To do so,

manually remove

delete the <webmanager-root>/work/contentindex directory and

allow it to be regenerated after restarting XperienCentral. Selecting

then restart XperienCentral. The content index will then be regenerated. You need to perform this step even if the application_settings.contentindex_queue_empty_reindex

in

setting on the General tab of the Setup Tool is

not sufficient

enabled.


Back to top


...

Basic Usage

To send an HTTP POST request to https://yoursite.com/web/searchretrieve/v1/yaml, the search query would be:

...

ParameterDescriptionYAML ExampleJSON Example
ids

Search for a content item using the item's content ID. Note that this is not the content item version ID. When searching for a page, the ID must be prefixed with a "P" and when searching for a media item, the ID should be prefixed with an "M". For example, searching for a page would with the content ID 26111, you would use P26111 and searching for a media with the content ID of 1, you would use M1.

This parameter can be used together with the languages parameter in order to retrieve the current or active version for those languages. When no languages are specified, the current version for all languages defined in XperienCentral are returned.

search: 
ids:
  - P26111
  - M1
{
"search": {
"ids": [
"P26111",
"M1"
]}
}
languages
This parameter specifies the language you want the results to be returned in. This parameter supports both the short country code metatag value (ISO-639) as well as the full metatag value (ISO-639 and ISO-3166 separated by an underscore "_"). When the full metatag value is provided, only the country code will be used due to a limitation within the content index. The languages parameter can be used in combination with both ID-based queries and parameterized queries. If this parameter is omitted, the active version for each available language will be returned. If there is no active version available, no version will be returned.
search: 
  languages:
  - en_US
  - nl
{
"search": {
"languages": [
"en_US",
"nl"
]}
}
text
This parameter searches for any text in the title or the body of the documents in the content index.
search:
  text: lorem
{
"search": {
"text": "lorem"
}
}
keywords 
(simple configuration)
The simple configuration for the keywords parameter makes it possible to search for content containing a specific keyword. When searching for multiple keywords or for results excluding certain keywords, use the advanced configuration (below).
search:  
keywords: term 1
{
"search": {
"keywords": "term 1"
}
}
keywords
(advanced configuration)
Allows more complex querying for articles with or without certain keywords. The and, not and or parameters which support lists of keywords should be used in the respective query fields. Values should always be provided in a list (YAML) or array (JSON) format.
search:  
keywords:
and:
  - term 1
  - term 2
not:
- term 3
{
"search": {
"keywords": {
"and": [
"term 1",
"term 2"
],
"not": [
"term 3"
]
}
}
}
types

Allows filtering on specific content types. The following parameters are allowed:

  • page
  • download
  • article
  • image
  • media page
  • multimedia
  • any custom content item identifier, for example helloworldmediaitem
  • any modular content type identifier, prefixed with wmammodularcontent_, for example wmammodularcontent_news
  • mediaitem - This type is a special case. If this parameter is provided, all types of media items will be returned. This parameter can not be used in combination with the other types. If other types are provided together with mediaitem, an exception will be thrown.
search:
  types:
  - page
  - article
- download
- helloworldmediaitem
{
"search": {
"types": [
"page",
"article",
"download",
"helloworldmediaitem"
]
}
}
keywordCategories
Adds a list of term categories to the query. The result has to contain at least one term that is in one of the provided categories.
search:
  keywordCategories:
  - term category 1
  - term category 2
{
"search": {
"keywordCategories": [
"term category 1",
"term category 2"
]}
}
sortBy

Specifies which field should be used to sort the results. The following options are supported:

  • lastModifiedDate
  • publicationDate
  • score (default)
search:
sortBy: publicationDate
{
"search": {
"sortBy": "publicationDate"
}
}
sortOrder
Can be either desc (default) or asc.
search:
sortOrder: asc
{
"search": {
"sortOrder": "asc"
}
}
publicationDate

Supports filtering the results by publication date. A from and/or a to parameter can be provided. If only a from parameter is provided, the results will contain documents that are published between the specified date and now. If only a to parameter is specified, all results with a publication date up to the provided date will be retrieved. Please note that dates should be provided in a ISO-8601 format.

When using Javascript it's really easy to retrieve an ISO string for a Date object. The Date object has a function toISOString() that will return a proper ISO String, using UTC as the timezone. The provided time on the creation of the Date object is converted accordingly.

search:
publicationDate:
from: 2021-03-19T14:58+02:00
to: 2021-05-19T14:58Z
{
"search": {
"publicationDate": {
"from": "2021-03-19T14:58+02:00",
"to": "2021-05-19T14:58Z"
}
}
}
<custom fields>
(simple configuration)

Custom fields can be used to query fields that are not explicitly exposed via the Search and Retrieve API. Examples of these are fields that are added to the content index via annotating methods in custom media items or fields in a Modular Content template that are configured to be indexed. The custom field option supports the same query parameter types as the keyword parameter (both a simple and an advanced query type). To query a custom field, use the identifier of the field as it's stored in the Content Index and provide the value to search for. See the column to the right for examples.

Modular Content fields

Fields in a Modular Content Template can be configured to be indexed in the content index automatically. The identifiers that should be used to query for these fields depend on the exact configuration of that field. In all cases, the identifier should be prefixed with mcf_. If the Search Index value in the configuration of the field is set to one of the "Unique ..." values, the identifier should also include the identifier of the Modular Template as follows:


modular_<identifier-of-the-template>0<identifier-of-the-field>

When the Search Index value is set to "Combined ...", the template identifier can be omitted as follows:modular_<identifier-of-the-field>

Modular date fields

If a Modular Content item has a field of type Date it is possible to search for those content items using a date range, similar to searching for an item's publication date. Please refer to the publicationDate parameter for more information. Searching for a date range can not be combined with other parameters within the same field.

Discovering and Debugging Fields in the Content Index

The Solr Maintenance Reusable allows the user to discover which fields are available within the content index. When this plugin is installed, your role requires the "Developer options" permission for the Solr Maintenance panel in the Authorization panel. Open the Solr Maintenance panel and navigate to Developer Options > Explore the content index to explore the content index. Set the radio button  "Show all facet info" to "yes" to show a list of all available facets per result.

Combining Multiple Custom Fields

It's possible to query for multiple custom fields at the same time by combining both simple and advanced query parameters, as well as "regular" and Modular Content Fields.

search:
  pageversion_navigationtitle: Navigatie titel

search:
modular_string4: value 1
modular_news0string:
and:
- value 1
- value 2
modular_date:
from: 2021-03-19T14:58+02:00
to: 2021-05-19T14:58Z
{
"search": {
"pageversion_navigationtitle": "Navigatie titel"
}
}

{
"search": {
"modular_string4": "value 1",
"modular_news0string": {
"and": [
"value 1",
"value 2"
]
},
"modular_date": {
"from": "2021-03-19T14:58+02:00",
"to" : "2021-05-19T14:58Z"
}
}
}
<custom fields>
(advanced configuration)
Allows more complex querying for articles with fields (not) containing or one more specific values. Supports the and, not and or parameters, which in turn support lists of values which should be used in the respective query fields.  Values should always be provided in a list (YAML) or array (JSON) format.
search:
  pageversion_navigationtitle: Navigatie titel
modular_string4:
    and:
    - value 1
    - value 2
modular_news0string:
    not:
    - value 3
{
"search": {
"pageversion_navigationtitle": "Navigatie titel",
"modular_string4": {
"and": [
"value 1",
"value 2"
]
},
"modular_news0string": {
"not": [
"value 3"
]
}
}
}
from
Allows the selection of a subset of the results starting at the value of this parameter. The first result in a result set has an index of 1, therefore the from parameter should always be 1 or higher. Also note that this parameter is inclusive, meaning that if from is 3, for example, the result set will begin with the third result. When from is omitted, the index value 1 is used.
search:
  from: 3
{
"search": {
"from": 3
}
}
to
Allows the selection of a subset of the results ending at the value of this parameter. Like the from parameter, to is inclusive, meaning that when it is set to 1, only the first result will be returned. For example, if from is set to 3 and to is set to 5, the results 3, 4 and 5 will be returned. The minimum value for this parameter is 1. When to is omitted, a maximum number of 100 results will be returned starting at the from parameter (if specified), otherwise starting from index value 1.
search:
  to: 3
{
"search": {
"to": 5
}
}

...