About the architecture

This is for:

Developer System Administrator

This page covers the architecture of Coveo for Sitecore. You’ll learn about its different parts and how they interact with each other. This can be valuable if you need to troubleshoot issues.

The building blocks

From a conceptual point of view, Coveo for Sitecore is made of the following building blocks.

Block 1: Coveo Search Provider

This module is deployed as a Sitecore package (ZIP file). The Coveo Search Provider acts as a bridge between Sitecore and the Coveo Platform. It’s responsible for handling queries originating from within Sitecore and for synchronizing your Coveo organization indexes with your Sitecore search indexes.

Block 2: Coveo Platform

This module is responsible for creating, managing, and maintaining your index. The Coveo Platform also handles all search queries in the background.

Among other things, it contains:

  • a Push API, which is used to index your Sitecore items.

  • a Sitecore security provider, which handles Sitecore security permissions and lets you find only what you’re allowed to see when you perform a query.

Event workflow

Depending on the type of action that you trigger in Coveo for Sitecore, a different sequence of events occur under the cover. Here are explained the most common scenarios.

Scenario 1: Rebuilding your search indexes

Rebuilding your search indexes causes these events to occur:

Indexing event sequence | Coveo for Sitecore 5

  1. The Sitecore application from where you performed the rebuild (Sitecore Desktop or Content Editor) tells the Coveo Search Provider to rebuild the chosen search index (for example, Coveo_master_index).

  2. The Coveo Search Provider tells the Coveo Platform to create everything necessary on the Coveo Platform side to begin indexing Sitecore items. This includes:

    • One Coveo field for each Sitecore field selected in the Fields section of the Indexing Manager (see About the Indexing Manager - Fields).

    • A field mapping to match each Coveo field with the corresponding Sitecore field.

    • A source of type Sitecore (for example, Coveo_master_index - <farmname>).

    • If the Sitecore security permissions are indexed, an Expanded Sitecore security provider (for example, Expanded Sitecore Security Provider for <farmname>). The Sitecore security provider expands security permissions found on Sitecore items.

  3. If Sitecore permissions are indexed, the Coveo Search Provider begins to retrieve the users and roles (known as identities) from Sitecore.

  4. If Sitecore permissions are indexed, the Coveo Search Provider pushes those identities to the Push API.

  5. The Coveo Search Provider begins to retrieve Sitecore items from the database corresponding to the chosen search index (for example, master).

  6. The Coveo Search Provider pushes those Sitecore items to the Push API.

  7. The Push API indexes those Sitecore items, including their selected fields and their security permissions, if applicable.

Scenario 2: Performing a query from a Coveo Hive search page through the reverse proxy

Warning
Legacy feature

The Coveo Hive Framework is now in maintenance mode and is no longer recommended for new implementations.

To build new search experiences, use one of Coveo’s more modern, lightweight, and responsive libraries. To get started, see the Build search article.

When the Coveo for Sitecore reverse proxy (typically located at http://<INSTANCE_HOSTNAME>/coveo/rest) is enabled, performing a query from a Coveo Hive search page triggers the following events:

Diagram showing query processing when the reverse proxy is enabled | Coveo for Sitecore 5
Note

When a user requests a Coveo-powered search page, a client-side process generates a search token using the API key and the user identities. The token is visible to the user in search page calls, but the API key isn’t.

  1. The Coveo Hive search page sends the query to the reverse proxy endpoint (typically located at http://<INSTANCE_HOSTNAME>/coveo/rest).

  2. The reverse proxy forwards the query to the Coveo Platform Search API endpoint.

  3. The Coveo Platform processes the query and returns only the results that the user is allowed to view.

  4. The Coveo Platform returns search results to the reverse proxy endpoint in a JSON format.

  5. The reverse proxy returns the search results to the Coveo Hive search page.

Scenario 3: Performing a query from a Coveo Hive search page directly to the Coveo Platform

Warning
Legacy feature

The Coveo Hive Framework is now in maintenance mode and is no longer recommended for new implementations.

To build new search experiences, use one of Coveo’s more modern, lightweight, and responsive libraries. To get started, see the Build search article.

Coveo for Sitecore 5.0.822.2

You can now configure Coveo for Sitecore to bypass the reverse proxy and have your Coveo Hive search pages perform calls directly to the Coveo Platform Search API endpoint.

Performing a query from a Coveo Hive search page with the reverse proxy disabled triggers the following events:

Diagram showing query processing when the reverse proxy is disabled | Coveo for Sitecore 5
Note

When a user requests a Coveo-powered search page, a client-side process generates a search token using the API key and the user identities. The token is visible to the user in search page calls, but the API key isn’t.

  1. The Coveo Hive search page sends the query to the Coveo Platform Search API endpoint.

  2. The Coveo Platform processes the query and returns only the results that the user is allowed to view.

  3. The Coveo Platform returns search results to the Coveo Hive search page in a JSON format.