Himmat Singh Dulawat (3x Sitecore MVP)

If you are using the SOLR search provider, to rebuild the request command we need to build the xDB index using the command manually from the xDB app service in Sitecore XP. You can find more details here: Invoke the rebuild request command Upon execution command, you get the following output: The index rebuild process takes time to complete and the request rebuild command does not provide any information about the progress status. However, there are certain ways you can monitor the state of an ongoing rebuild process. To Monitor the Index Rebuild Process: SOLR Interface: You can do so by running the following query by navigating to the original xDB Solr core and go to the Query tab. On the Query tab, insert the above into "q" part and click "Execute Query". Once executed, we should be able to see the result as such. In this example, the rebuild state is at 5 (Ongoing) and it is at 95%. ...

Recently we have added the Korean language to our multilingual Sitecore website. As we know Sitecore automatically creates dynamic fields in the SOLR schema. But while publishing we found the following issue in our logs: Solution: The error is in sitecore_web_index and it seems we are missing a dynamic field for the Korean language. To solve this issue, we need to add the dynamic field in the SOLR schema file: <dynamicField name="*_t_ko" type=" text_general" indexed="true" stored="true" /> Restart the SOLR But take care that whenever you populate the managed schema from Sitecore, it will overwrite your managed schema, and you will lose all the changes. Another approach is to customize the SOLR schema using backend code. Step 1: Create a custom class and add the following logic: Step 2: Create one more class that inherits from IPopulateHelperFactory implement the ...

If you are on Sitecore Managed Cloud and your SOLR is with Managed Cloud Server Searchstax then it is not easy to manage it. In today’s blog, I am going to discuss how to manage Managed Cloud SOLR Server, especially Restart SOLR. After successfully setting up Sitecore and SOLR instance by Sitecore, Sitecore provides you the URL of SOLR Server and the following details: Solr server connection string Solr server URL Zookeeper Ensemble API key Solr server user Solr server password To access the SOLR admin UI: Open the https://<server_name>-azure.searchstax.com/solr/ URL and enter the Username and Password. Get a List of Nodes: Before doing this exercise, you need to find the number of nodes in your SOLR server (a standard server consists of 3 nodes). For example, if your server_name provided by Sitecore is "ss123456" then ideally your nodes will be ss123456-1, ss123456-2, ss123456-3. By using the below URL, you can ...

While upgrading the project from Sitecore version 8.2 to 10.2 I faced one scenario to convert the Lucene Search configuration to the SOLR. It’s easier to convert the Lucence configuration to the SOLR if all configurations are defined in the configuration files. You just need to change the type to the Solr Provider and configuration to the defaultSolrIndexConfiguration or if it does not default then define the custom Solr Index configuration . The problem occurs when the index file is generated at runtime and custom fields are added dynamically either on the pipeline or Search Crawler. In my case in Sitecore 8.2 lucence configuration fields were added in the document at runtime on SitecoreItemCrawler . Custom Crawler: Code was written on the custom crawler: Solution: To resolve the above issue and find the solution, I have explored Sitecore.ContentSearch DLL and found out it provides the below method in the IProviderUpdateContext interface. ...

After upgrading the project to Sitecore version 10.2 , the SOLR search result is different in order due to the query _val_:__boost function . I have investigated the issue and found out that in Sitecore 9.0.2 our SOLR search query was: ..........AND (-_template:("083a4d2a38694013a9e2d18c05da70ae") *:*)) and in Sitecore 10.2 SOLR search query is: ..........AND (-_template:("083a4d2a38694013a9e2d18c05da70ae") *:*)) AND _val_:__boost There is one more extra condition at last in the query i.e. AND _val_:__boost. I have gone through the Sitecore documents on Search Result Boosting and found that  In Sitecore XP 10.0.0 or later, item-level boosting relies on index-time scoring factors that are indexed in the __boost field and combined with the query score using the query _val_:__boost function. After doing lots of brainstorming I raised a support ticket to the Sitecore and find the below solution: Solution: Sitecore suggested ...

While rebuilding the index on your Sitecore CMS you may face scenarios where indexing data not populating in website search functionality, search stopped working, or slowdown. After completion of indexing again search functionality returns the results. Here Sitecore introduces the very nice concept of SwitchOnRebuild. To understand it assume you have two cores for your Sitecore index active and passive. It means when you rebuild the Active index Sitecore will return the result using the Passive index and after rebuilding Sitecore will switch the Active index to serve the results. It’s a concept of switching of Sitecore index during the rebuild of the particular index to avoid downtime and search unavailability. Recently when I was working on one migration project, when I deployed an application on the Azure Paas environment. I faced a similar type of issue while rebuilding the index it was throwing me the below error: Job started: Index_Update_IndexNa...