When you onboard the Coveo search platform by default, you will get two organizations — Prod and Nod Prod, prod can manage the Live search experiences, and non-Prod by default can manage one of the test search experiences, e.g., search on stage platform.

But in most cases, you may need to support multiple test platforms to support various testing, e.g., UAT, Stage, etc.; in this post, let us see one of the approaches to support multiple environments, e.g., UAT, Stage on Coveo Non-Prod organization.

Here the assumption is UAT websites enabled with domains containing uat, e.g., test-site1.uat.com, and stage websites enabled with the domains containing stage test-site1.stage.com.

Login to the Coveo Admin console and select non-Prod organization.

Create two conditions to identify the UAT and Stage environments.

Add two Filter conditions to the query pipelines to filter the content based on the environment conditions defined in the earlier step (filter based on the environment).

Enable UAT/Stage sources — Enable the source (I am using a sitemap source) with both the stage and uat sitemap URLs.

The source index both stage and uat content, but the query pipeline filters the content based on the source_environment and renders it to the end user.

Enable the source_environment context variable to the search page; if you are using the Coveo search page, enable the below event handler — the event handler sets the DNS that accessed the search page to the source_environment context variable. If you are using API to access the search result, pass the source_environment as part of the API context.

Coveo.$$(document.getElementById('coveo-search')).on('buildingQuery', function(e, args) {
    args.queryBuilder.addContextValue('source_environment', window.location.hostname);
  });

Now when the user accesses the search result page from the stage environment, the stage content is displayed, and uat data is while accessing the UAT search result page.

Specifying the source_environment context variable while accessing the search result through API.

https://platform.cloud.coveo.com/rest/search/v2?organizationId=xxxx&searchHub=xxxxx&access_token=xxxxx&context={"country":"us","locale":"es","source_environment":"stage"}&q=xxxx

Refer to Coveo Search Implementation with AEM (Adobe Experience Manager) | by Albin Issac | Tech Learnings | Sep, 2022 | Medium | Tech Learnings for more details on enabling Coveo search for AEM websites.

Sling Models are annotation-driven Java "POJO's" (Plain Old Java Objects) that facilitate the mapping of data from the JCR to Java variables and provide several other niceties when developing in the context of AEM. When you adapt to a sling model, the model factory returns the specific model implementation; the returned model implementation is selected through the model pickers.

In this post, let us dive deep into how this model picking works internally.

The Sling Model Framework has the Implementation Picker to select the specific model implementation.

The Implementation Picker interface can be referred to here — ImplementationPicker (Apache Sling 8 API); the picker interface is enabled with a picker method responsible for selecting a specific model implementation.

The Sling Framework, by default, has the below picker implementations.

First Implementation Picker:

This is the default picker implementation; it picks the first implementation from the list alphabetically ordered by class name. If there are multiple implementations of the specific models, this one selects the first one and returns it to the requestor. First Implementation Picker will be used if no other implementations support picking the model implementation.

The service ranking is set to the highest (Integer.MAX_VALUE) to support more custom picker implementations.

Resource Type-Based Resource Picker:

This picks the specific model implementation based on the resource type. This picker's ranking is 0 to ensure this comes before First Implementation Picker.

The AEM core components have their picker implementation to pick the latest version of a model implementation for a specific model.

Latest Version Implementation Picker:

This picks the specific model implementation based on the resource type and the model version —Picks the latest model version of a core component model based on the version information in the package name. The ranking for this picker is specified as 1 to ensure this comes after the Resource Type Based Resource Picker.

All the core components reference the model interface directly — com.adobe.cq.wcm.core.components.models.Carousel; the model implementations are always enabled with a specific version, so the Resource Type Based Resource Picker will not pick any model implementation, and the picking is delegated to the Latest Version Implementation Picker, and this always returns the latest model implementation based on the version number — e.g., com.adobe.cq.wcm.core.components.internal.models.v1.CarouselImpl).

The External models that implement Core Component interfaces have precedence over internal models, allowing us to enable model delegation for the core components.

The custom picker implementation can be enabled by implementing the org.apache.sling.models.spi.ImplementationPicker interface and picker method with your custom model picker logic; the ranking should be enabled accordingly to ensure the default implementations are not impacted.