Indexing & Search

Dynamicweb 9 features a lightning fast generalized search framework usually referred to as New Indexing, which can be used to index and search through all kinds of data on your solution – products, content, users, etc.

Broadly speaking, New Indexing consists of the following elements:

  • Indexes – which are data structures optimized for data retrieval
  • Queries – which are used to retrieve data based on criteria you define
  • Facets – which are used to create filters in frontend
  • Tasks – which are used to rebuild indexes at an interval

All of these elements can be heavily configured to suit your particular scenario – and all exist within a so-called repository, which is simply a folder in the file archive containing configuration files.

Read more about working with each element below.

Get started now

If you’re just looking to get started with implementing search in your shop, take a look at these tutorials which should take you most of the way:


Implementing free-text search


Using Facets to filter a product list


Implementing typeahead search


Implementing a PriceRange query

 


A repository is basically a folder containing the configuration files for a particular scenario or website – a way for you to organize indexes and queries in a way that makes sense (Figure 3.1)

To create a repository:

  • Go to Settings
  • Right-click the Repositories node and select New repository
  • Name it
  • Click OK

A repository can contain the following elements:

  • Index definitions – which are instructions for building an index
  • Queries – which are used to retrieve data based on the criteria you define
  • Facets – which are used to create filters in frontend
  • Tasks – which are used to rebuild indexes at an interval

You should add them in the order above – facets are dependent on queries which are dependent on an index.

All of these elements can be found in Files/System/Repositories/YourRepositoryName – and can be moved to other solutions by simply copying the repository folder from one solution to the other. The actual index files are not placed in this folder, but as soon as the index is rebuilt on the new solution they will be created.

Repositories can only be created by Admin and Administrator users, but any user with backend privileges can edit an existing repository.

An index is a data structure optimized for data retrieval operations – which means that querying it is much faster than searching through each row in the database whenever a table is accessed.

To create an index:

  • Click Add index in the repository toolbar (Figure 4.1)
  • Name it
  • Click OK
Figure 4.1 Creating an index

This will open the index configuration page (Figure 4.2) from which you can add and configure the various index components.

Figure 4.2 The index configuration page

An index consists of the following components:

  • Instances – the physical data structures which are queried
  • Build configurations – a set of instructions for retrieving data from Dynamicweb and building an instance
  • Field definitions – a set of instructions detailing what goes in the index and how it should be stored
  • (Optional) Field types – custom field types can be used when you need to analyze data in a non-standard manner.

Read about the components below.

Instances are used to specify a location and an IndexProvider, which will create the index files at the location.

By default, Dynamicweb uses Lucene 3.0.3 and comes with a LuceneIndexProvider which builds index files in a folder in the file archive, e.g. /Files/System/Indexes/YourIndexName/YourInstanceName.

To create an instance:

  • Click Add instance on the index configuration page to open the Instance configuration (Figure 5.1)
  • Provide a name
  • Select a provider – this step is easy, as we supply only one provider out of the box
  • Specify a folder
  • Click OK
Figure 5.1 Creating an instance

Once created, an instance will look like the Lucene B index in Figure 5.2 – this is because it has not been built yet. Once it has been built it will look like the Lucene A index.

Figure 5.2 Instance configuration page

An instance only contains the data which existed at the time it was built. This means that your instances must be periodically rebuilt to include new data - and that you should always have more than one instance defined, since indexes cannot be queried when they are being built.

You can create scheduled tasks for automatically rebuilding your instances at an interval – see details below – and these tasks will build the instances sequentially, and will not rebuilt the last index if the previous instanced failed to be built correctly. This means that you will never be without an instance to query – even if something goes wrong during the built process.

If you have more than three instances defined, you can choose between two different methods for selecting an alternative index when the primary index is being rebuilt:

  • ActivePassive mode selects the next active instance available on the list. So if instances A is unavailable (being built, has failed to build), instance B will be used unless it is unavailable, in which case instance C will be used, and so forth
  • LastUpdated mode selects the most recently built index and uses that

ActivePassive mode is used by default – to change to LastUpdated mode:

  • Click Balancer in the ribbon bar (Figure 6.1)
  • Use the dropdown to select the LastUpdated balancer
  • Click OK
Figure 6.1 Choosing a balancing mode

A build is a set of instructions for retrieving data from Dynamicweb and delivering it to the IndexProvider on an instance, which will then build the physical index files.

To create a build configuration:

  • Click Add build on the index configuration page to open the build configuration dialog
  • Provide a name
  • Select a builder
  • (Optional) Configure the settings exposed by the builder
  • (Optional) Set up notifications on run or failure
  • Click OK

See below for a detailed look at the builders provided by Dynamicweb.

The ProductIndexBuilder is used to index products. It indexes data from multiple Ecommerce data tables, calculating group hierarchies and more – so the index contains all products fields, variant group fields, custom fields, category fields, stock location fields and a number of generated fields.

Figure 8.1 The ProductIndexBuilder

The ProductIndexBuilder supports the following builder actions:

  • Full builds everything from scratch
  • Update rebuilds only the products which have been edited within the timespan which falls between the current time and the HoursToUpdate setting

The following settings can be configured:

Setting

Value

Comments

EmptyStringReplacement

String – default is an empty string

NULL values are not indexed by Lucene, so to be able to locate an empty field you need to index it with a dummy value – this dummy value can be specified here.

BulkSize

Integer – default is 500

The number of products being built at a time

OnlyIndexActiveProducts

Boolean – defaults is False

If set to True, only active products are indexed

MaxProductsToIndex

Integer – default is 2147483647

The maximum number of products to index

SkipGrouping

Boolean – defaults to False

If set to True, the fields "GroupIDs", "ShopIDs", "GroupNames",
"GroupNumbers", "GroupDescriptions", "PrimaryGroupSort", "ParentGroupIDs", and "ParentGroupNames" are skipped

SkipExtenders

Boolean – defaults to False

If set to True, no custom Extenders can extend (update, remove, add) the fields in the index

SkipAllExtendedFields

Boolean – defaults to False

If set to True, the fields "CampaignStartTime", "CampaignEndTime", "CampaignShowProductsAfterExpiration", "IsVariant", "ManufacturerName", "AssortmentIDs", and "StockLocationProductAvailable" are skipped

SkipCategoryFields

Boolean – defaults to False

If set to True, all product category fields are skipped

DoNotStoreDefaultFields

Boolean – defaults to False

If set to True, all default product fields are skipped

HoursToUpdate

An integer – not set by default

If combined with the builder action Update, only the products updated within the hours specified here are rebuilt

HandleInheritedCategoryValues Boolean - defaults to False If True, inherited product category values are indexed. This is very slow, so please don't set this to true unless you really need to.

The ContentIndexBuilder is used for indexing content – pages, their paragraphs, and their item fields.

The index is built by enumerating all available pages, then handling paragraphs & item fields for each page.

The corresponding schema extender – the ContentIndexSchemaExtender – contains the following types of fields:

  • All fields from the Page table – e.g. PageActive, PageID, PageItemType, etc.
  • A number of Page content fields:
    • Paragraph headers contains an array of all paragraph headers on a page
    • Paragraph texts contains an array of all paragraph text content on a page
    • Paragraph content contains an array of the item type properties for each item-based paragraph on a page
    • Page property item type contains the name of the item type used to extend the page properties of this page (if relevant)
  • All item type fields in the format [item.SystemName]_[itemField.SystemName] and Property_[item.SystemName]_[itemField.SystemName].
  • Possibly a number of App fields – see more below.
Figure 9.1 The ContentIndexBuilder

The following settings are available:

  • ExcludeItemsFromIndex allows you to control whether or not item-based content should be indexed. False by default – which means item content IS indexed.
  • AppsToHandle allows you to specify exactly which ContentAppIndexProviders to include. Valid input is a comma-separated list of ContentAppIndexProviders to include. If nothing is set here, all ContentAppIndexProviders are included.

By default, we deliver a ContentAppIndexProvider for the forum – review the API doc on the ContentForumIndexProvider here.

Due to complexity issues, the ItemListEditor and ItemRelationListEditor field types are not indexed.

Creating a custom ContentAppIndexProvider

If you want to extend the content index with app-specific fields or documents, you must create a class inheriting from the ContentAppIndexProvider Class and override the relevant methods.

As example please take a look at ContentForumIndexProvider class.

The Sql index builder is used to index a table from the sql server database – it executes a query without manipulating any data. Currently only understands the builder action Execute.

Figure 10.1 The SqlIndexBuilder

The following settings are available:

  • Connection String can contain an SQL connection string, e.g. “Server=.;Database=test;User Id=sa;Password=sa;”
  • Query can contain an SQL query which retrieves the columns and rows which should be indexed, e.g. “SELECT * FROM AccessUser”
  • Query to get count can contain an SQL query which returns a count of the rows being added to the index, e.g. “SELECT COUNT(*) FROM AccessUser”
  • UseStoredProcedure – a setting which can be set in the index XML config file. When set to True, the stored procedure name must be set in the “Query” setting which will be executed when running the builder to index the data.

The UserIndexBuilder indexes all fields on users, including custom fields (but not user behavior, like orders placed, or order value, etc.).

It executes the following query to retrieve users: 

"SELECT * FROM AccessUser WHERE AccessUserType in (1, 3, 5)"

It uses no settings and only understands the builder action full (Figure 11.2).

Figure 11.2 The UserIndexBuilder

In addition to the standard user fields, the index contains the following generated fields for each user:

Field

Field content

Groups

An array of user group IDs where the user is a member

GroupNames

An array of user group names where the user is a member

Is Admin

True if System Administrator or Administrator

Combined order totals

The sum of Order Price with VAT from orders completed by this user

Largest order price

Largest Order Price with VAT entry associated with this user

Order count for last 30 days

A count of completed orders associated with this user within the last 30 days

Bought products

An array of product IDs from order completed by this user

Loyalty points total

The sum of LoyaltyUserTransactionPoints from EcomLoyaltyUserTransaction associated with this user

Loyalty point last added

A DateTime entry of the last time loyalty points were added to the users

Loyalty point next expirery

Oldest loyalty point transaction date by the user summed with global setting /Globalsettings/Ecom/LoyaltyPoints/ExpirationPeriodInMonths

 

The FileIndexBuilder (Figure 12.1) indexes various data about the files in the file system – NOT the content of the files. This can be used to create e.g. a searchable media library for images, pdf files, etc.

The following standard data is indexed:

  • File name
  • Directory path (/Files/whatever/Folder/OtherFolder/)
  • Directory (OtherFolder)
  • ParentDirectory (Folder)
  • RootDirectory (Files)
  • Extension (i.e. jpg, png, txt etc)
  • Filesize in bytes
  • LastWriteTime

The following fields are generated:

  • FileFullName - file path and name
  • Date created time/Date created time UTC
  • Last access time/Last access time UTC
  • Last write time UTC
  • Is read only

We also index metadata (EXIF, XMP, and IPTC) for certain types of (image) files.

Currently, we can index metadata for following file formats; .pdf, .gif, .jpg, .jpeg, .psd, .bmp, .png, .tiff, .tif, and .ai.

Figure 12.1 The FileIndexBuilder

The following settings can be used to tweak the builder behavior:

  • Recursive can contain a Boolean value, and controls whether subfolder content is indexed. Defaults to True.
  • StartFolder contains the path to a folder, defaults to /Files.
  • SkipMetadata contains a Boolean value, and controls whether metadata (EXIF, XMP, and IPTC) on image files is indexed. 

Fields are mappings between the data retrieved by the builder and the index – a set of instructions detailing which fields should be added to the index and how they should be stored.

To make things easier for you, we’ve created schema extenders for products, content and users – these are predefined sets of field mappings with everything defined for you.

To use a schema extender:

  • Click Add field on the index configuration page to open the build configuration overlay (Figure 13.1)
  • Select the schema extender field type
  • Select the appropriate schema extender; ContentIndexSchemaExtender, ProductIndexSchemaExtender, or UserIndexSchemaExtender
  • Click OK
  • Save
Figure 13.1 Using the Schema Extender

Once you’ve saved the index, you will see a list of fields provided by the schema extender in question, e.g. the fields provided by the ProductIndexSchemaExtender in Figure 13.2.

Figure 13.2 The ProductIndexSchemaExtender

Now, the schema extender naturally makes some choices on your behalf – that’s the tradeoff with a predefined set.

Here are some headlines:

  • All string type fields are analyzed by default which means that spaces are considered a divider (which in turn makes it possible to conduct free-text searches on the data).
  • The fields cannot be assigned a custom boost value

If this behavior is a problem for your setup – which it often will be – you can exclude fields from the schema extender, and then add them manually and with the settings matching your needs.

To exclude a field from the schema extender:

  • Click the schema extender in the Fields area to open the settings (Figure 13.3)
  • Under Excluded fields click Add
  • Select the field(s) you want to exclude
  • Click OK
  • Save

The field will now be excluded the next time the index is built.

Figure 13.3 Excluded fields in the Schema Extender

If you want more control over the way your fields are indexed, you can add them manually – this is especially useful when you need to sort on, create facets or boost data from particular fields.

You can add three different types of fields:

  • A standard Field maps a single field from the builder to a corresponding field in the index
  • A Summary field maps data from more than one source field to a single destination field, converts the data to text and splits on whitespace. This is typically used to implement free-text search
  • A Grouping field allows you to group values together under a common label – this can be used to create facet-friendly index entries from values not inherently suited for faceting

When fields are added manually, you have access to the following settings:

  • Custom boost values – a factor multiplied onto the base relevance of the field (as automatically calculated by Lucene)
  • The storage setting, which details how the data is added to the index:
    • A stored field has its value stored as-is in the index. This does not affect indexing or searching – it simply controls whether you want the index to act as data store for value. Since most of your data will be in the Dynamicweb database, you usually don’t need to store a field in the index.
    • An indexed field is made searchable, and stored as a single value. This is appropriate for keyword or single-word fields, and for multi-word fields you want to retrieve and display as single values (e.g. for facets).
    • An analyzed field is run through an analyzer, and tokens emitted are indexed. This only makes sense as long as the field is also indexed.

To create any of the field types, manually click Add field on the index configuration page, select the field type you want to add, and configure the settings associated with the field type in question, as outlined below.

Stop words

By default, we use the Lucene StandardAnalyzer to analyze and tokenize data – and the StandardAnalyzer has a built-in list of stop words, which are words that will not be indexed (and therefore cannot be searched for).

The default stop words are: “a”, “an”, “and”, “are”, “as”, “at”, “be”, “but”, “by”, “for”, “if”, “in”, “into”, “is”, “it”, “no”, “not”, “of”, “on”, “or”, “such”, “that”, “the”, “their”, “then”, “there”, “these”, “they”, “this”, “to”, “was”, “will”, “with”.

To override the default list of stop words, place a file called stopwords.txt in the /Files/System/Repositories/ folder – the format is one word on each line:

a an and are as etc.

A standard Field maps a single field from the builder or an external source to a field in the index (Figure 15.1).

Figure 15.1 A standard Field

To create a standard Field:

  • Provide a Name and a System name for the field in the index
  • Select a source of data – if mapping to a custom source from a builder extender, use the plus icon and enter a source name matching the name in the code
  • In the settings area:
    • Select the data type you want the data to be indexed as – please ensure that the source and destination data types are compatible
    • (optional) Provide a custom boost value
    • Check Stored, Indexed, and/or Analyzed as appropriate to your needs

A Summary field maps data from more than one source field to a single destination field, converts the data to text and splits on whitespace (Figure 16.1).

Figure 16.1 A Summary field

To create a Summary field:

  • Provide a Name and a System name for the field in the index
  • In the settings area:
    •  (optional) Provide a custom boost value
    • Check Stored, Indexed, and/or Analyzed as appropriate to your needs
  • Select a number of sources

For a summary field, you do not need to select a data type – the data added to a summary field is always aggregated, converted to a string and split on whitespace.

A Grouping field allows you to group values together under a common label – this can be used to create facet-friendly index entries from values not inherently suited for faceting (Figure 17.1).

Figure 17.1 A Grouping field

To create a Grouping field:

  • Provide a Name and a System name for the field in the index
  • Select a source of data – if mapping to a custom source from a builder extender, use the plus icon and enter a source name matching the name in the code
  • In the settings area:
    • Select the data type you want the data to be indexed as – please ensure that the source and destination data types are compatible
    •  (optional) Provide a custom boost value
    • Check Stored, Indexed, and/or Analyzed as appropriate to your needs

Finally, add a number of groups and specify the values contained therein – you will then be able to create facets on the group names from frontend.

Standard Field type fields use the Lucene StandardAnalyzer to analyze and tokenize the source data and add it to the index – and this is perfectly adequate for most applications. However, in some cases you need to do more advanced stuff to the source data before indexing it.

In those cases, you can create custom field types and select one or more analyzers:

  • Click Add field type on the index configuration page to open the build configuration dialog (Figure 18.1)
  • Provide a name for the field type
  • Select a data type for the field type and optionally a custom boost value
  • Select one or more analyzers to run the data through
Figure 18.1 A custom field type

Once a custom field type has been created, you can use it by adding a standard Field type field and selecting the custom field type using the Type-dropdown (Figure 18.2).

Figure 18.2 Using the custom field type

On Analyzers

The Lucene StandardAnalyzer used by us by default has the following behavior:

  • Splits words at punctuation characters, removing punctuation. However, a dot that’s not followed by whitespace is considered part of a token.
  • Splits words at hyphens, unless there’s a number in the token, in which case the whole token is interpreted as a product number and is not split.
  • Recognizes email addresses and internet hostnames as one token.

For information on the other analyzers available, please refer to the Lucene documentation.

A query is simply a request for data from an index – e.g. ‘Return all active products with a price below 100’ or ‘Return all users who live in Denmark’.

Queries are created by stringing together a number of expression which will in turn return the data you want to retrieve (Figure 19.1).

Figure 19.1 Implementing expressions for queries

To create a query:

  • Click Add Query in the repository toolbar (Figure 19.2)
  • Name it
  • Select a data source (an index)
  • Click OK
Figure 19.2 Creating a query

This opens the query configuration page (Figure 19.3).

Figure 19.3 The query configuration page

From here you can configure the query by:

  • Creating parameters
  • Defining expressions
  • Add default sorting criteria

You can view (and change) the source index using the button in the ribbon bar.

A parameter is a variable which can be used as test values in an expression to make the query dynamic – so you could create a parameter called Search, use it as a test value in an expression, and then pass dynamic values to it from frontend through a search filter.

To create a parameter:

  • Click Add Parameter on the query page
  • Name the parameter
  • Select an appropriate data type for the parameter – this should match the data type of the field your will be testing against
  • (Optional) Specify a default value
  • Click OK

Once created, a parameter will be listed in the parameters table (Figure 21.1) – and will be available as a test value when creating expressions.

Figure 21.1 Creating parameters

Expressions are used to limit the data returned by a query – a query without any expressions at all will return all data in an index.

Expressions consist of the following elements:

  • A field in the index to query
  • An operator
  • A test value to test against

For instance, a simple expression returning all Active products in a product index would look like Figure 22.1 – where the field Active is checked against the boolean constant true.

Figure 22.1 Example of a simple expression

To create an expression:

  • Click Add group
  • Select a field in the index using the dropdown
  • Select an operator
  • Use the pencil-icon to set a test value
  • Click OK

Expressions may be combined in AND-groups and OR-groups, and can be negated to return all elements not matching the expressions. This makes it possible to create pretty powerful and complex queries.

When creating expressions, you must select an operator (Figure 23.1).

Which operators are available to you depends on the type of field selected - so for a Boolean field you only have access to true/false, for a sting array you have Contains, MatchAll, MatchAny and In, and so on.

This makes it easy to select the appropriate operator for an expression.

Figure 23.1 Modifying expressions using operators

Please not that due to performance reasons, the Contains operator does not match values in the middle of terms – i.e. it matches [TERM*] but not [*TERM*]. This is not uncommon or odd - it's what Google does, after all.

If you want to match on *[TERM]* instead you can use the ContainsExtended operator – but please be aware that this comes with a significant performance and memory overhead. Don't say we haven't warned you ;)

The right side of an expression contains the test value. Test values can be either static or dynamic depending on the type of test value you use.

The following test value types are available:

  • Constant – a static value of a particular data type – string, double, datetime, etc.
  • Parameter – a dynamic value passed to the query from frontend, e.g. through a search field
  • Macro – a dynamic value retrieved from the context, e.g. PageID, WebsiteID, UserID, CartID, etc.
  • Term – a static value present in the field being queried
  • Code – lets you select a provider which provides a graphical interface to manipulating e.g. a DateTime C# object (CurrentDate – 1 month)

To define a test value:

  • Click the pencil icon on the right side of the expression
  • Select a test value type
  • Configure the type selected:
    • Constant: Select a data type and enter a value
    • Parameter: Select a parameter
    • Macro: Select one of the context-specific values available
    • Term: Use the dropdown to select one or more of the terms that exist in the field (Figure 24.1)
    • Code: Select a provider and configure the associated settings
Figure 24.1 Selecting terms when defining a test value

The following macros are currently available as test values:

Macro

Context

Description

PageID

Dynamicwen.Frontend.PageView.Context

 

WebsiteID

Dynamicwen.Frontend.PageView.Context

 

AssortmentsID

Dynamicweb.UserManagement.Context

 

MostFrequentBoughtProducts

Dynamicweb.UserManagement.Context

Returns an array of of product IDs most frequently bought by the current user within the last 3 months

MostBoughtProducts

Dynamicweb.UserManagement.Context

Returns an array of product IDs which the current user buys in the largest quantities within the last 3 months

FavoritesByUserId

Dynamicweb.UserManagement.Context

Returns an array of product IDs which are on the default favorites list of the current user (accessuserid)

FavoritedByCustomerNumber

Dynamicweb.UserManagement.Context

Returns an array of product IDs which are on the default favorites list of the current user (customer number)

UserID

Dynamicweb.UserManagement.Context

 Returns the UserID of the current user

UserGroups

Dynamicweb.UserManagement.Context

 

CustomerNumber

Dynamicweb.UserManagement.Context

Returns the Customer Number of the current user

LanguageID

Dynamicweb.Ecommerce.Context

 

ShopID

Dynamicweb.Ecommerce.Context

 

CartID

Dynamicweb.Ecommerce.Context

 

StockLocationID

Dynamicweb.Ecommerce.Context

 

 

Matching null values

Apache Lucene, the software library used for the standard IndexProvider in New Indexing, does not index Null values or empty strings at all, which means that you cannot easily isolate index entries without a value in them.

The workaround is to add an expression group matching all records with a value, and then negate it (Figure 24.3).

Figure 24.3 Matching null values

The data returned by a query can be sorted in a number of ways. Most of the time, you will want to control sorting at the app-level, on either the Product Catalog app instance or the Query publisher app instance used to publish the data.

Should you want to not do that, or should those settings fail for some reason, you can create default sorting criteria on the query level:

  • Click Add sorting on the query page
  • Select a field and a direction
  • Click OK
Figure 25.1 Add sorting

Please note that this is a default sorting and that any sorting applied at the app-level will override it.

Sorting on an analyzed field

You can’t sort on a field which is analyzed and expect things to behave in any meaningful manner – so to sort on e.g. the product name, add a separate, unanalyzed product name field to your index. Keep in mind that all string type fields from the Schema Extender are analyzed by default.

At the bottom, you have the following tables available (Figure 26.1):

Figure 26.1 Show settings

Here, you can choose which fields and languages to include and exclude from the query.

Facets are a particular kind of filter which allows customers to refine a product list based on values in the index (Figure 27.1).

Figure 27.1 Frontend example of how facets work

Technically, a facet is a mapping between a query parameter (e.g. Manufacturer) and a list of values from a field in the index (e.g. Manufacturer name) – selecting one of the values then passes the value to the query, and the filtered query result is then returned to frontend.

Facets are created inside facet groups.

To create a facet group:

  • Click Add Facets in the repository toolbar to create a facet group
  • Name it
  • Select a Query to pass the facet values to

This opens the facet group configuration view (Figure 27.2).

Figure 27.2 Creating a facet group

From the facet group configuration view, you can add three types of facet:

  • A field facet retrieves a list of all possible values found in a particular field in the index
  • A list facet lets you group field values under a common label (“Spring colors”)
  • A term facet is identical to a field facet, but will only retrieve the 2048 most frequently used field options from a field

In general, we don’t recommend faceting on data which requires you to use a term facet, as too many facet options can impact performance.

All three facet types can calculate the count of matching elements in the entire query result sat for each facet option.

On each facet you can specify a render type - this is simply a string value available when rendering facets in frontend, which makes it possible to render several types of facet controls within a single facets loop.

 

Field facets retrieve facet options from a particular field in the index – so if the field Colors has twelve different values (blue, green, red, mauve, etc.), twelve different facet options will be available in frontend.

To create a field facet:

  • Click Add field facet on the facet group page
  • Provide a facet name
  • Select a field to retrieve facet options from (fields with more than 2048 different terms cannot be selected - use a term facet instead)
  • Select a query parameter to pass the option values to
  • Specify a render type
Figure 28.1 Creating field facets

A list facet allows you to manually specify list options and give them custom labels (Figure 29.1).

  • Click Add list facet on the facet group page
  • Provide a facet name
  • Select a field to retrieve facet options from
  • Select a query parameter to pass the option values to
  • Specify a render type
  • Create a number of labels and values
Figure 29.1 Creating list facets

If multiple options are given the same label, they will be grouped together – which means that you can use list facets to group facet options under a particular label.

Please note that there is no built-in validation, the values you enter must fit the source data or the facet option will appear empty in frontend.

A term facet behaves almost identical to a field facet, except for the fact that it will only retrieve the 2048 most frequent terms from a field. This makes it possible to facet on fields with a lot of variance in terms, without crippling performance completely.

To create a term facet:

  • Click Add field facet on the facet group page
  • Provide a facet name
  • Select a field to retrieve facet options from
  • Select a query parameter to pass the option values to
  • Specify a render type
Figure 30.1 Creating term facets

The final element of a repository is scheduled Tasks, which rebuild your indexes at predefined intervals.

To create a task:

  • Click Add Task in the repository toolbar
  • Provide a name
  • Click OK

This opens the Task configuration view (Figure 31.1).

Figure 31.1 The Task configuration view

To configure the task:

  • Select a start time and optionally an end time
  • Select the interval with which you want to run the task – please keep in mind that rebuilding indexes can be resource demanding
  • Select a task provider (we supply one out of the box, the IndexBuilderTaskProvider, but you can create your own)
  • Configure the parameters supplied by the task provider – by default:
    • Select an Index to rebuild
    • Select a Build configuration to use

Please note: The tasks created here depend on an autogenerated scheduled task called Repository Task Handler executing them. If your tasks are not executed in a timely manner, it may be because the Repository Task Hander is set to run at an interval longer than the intervals on the repository tasks.