Jeremy Davis
Sitecore, C# and web development
Anyone who's been doing Sitecore DXP for a while will be fairly comfortable with Solr and how search works under the Content Search APIs. But if you're moving to the newer SaaS products then you're not working with that any more. And getting started with Sitecore's SaaS Search product does involve learning a few changed concepts.
Here are four quick things they tell you that you might not have thought too much about, but you need to remember to help avoid project surprises...
The documentation and training for Search talks about how you can design and create Entities to represent content types in search - things like Books, Pages, Products etc. But an important thing to remember is that you can't run a search query that returns multiple types of Entities in a single result set.
That means if your site needs to show multiple content types at once, you have to make sure you use a single Entity type for all of these things. And hence you likely need a field in your Entity which records the content type in your index so you can do stuff like vary the display between products and pages.
That's likely what you would have done anyway with ContentSearch and Solr - so don't be too distracted by all the talk of entities in the new documentation.
Relatedly, the specific Entity definition you choose to start your work from can be important too.
The commerce side of Sitecore Search has a bunch of pre-build recipies which you can use to create things like "make recommendations of products to show this user" as UI components. These sound like a good time-saver, but take care.
Since these are generally related to commerce scenarios, they rely internally on the pre-built "Product" entity that's provided out of the box. So if your content is indexed to a different entity then these recipies won't work correctly.
If you're going to make use of the commerce-related recipies, then your base entity needs to be Sitecore's Product one to avoid problems. Extend that instead of creating your own.
While you can do things to configure recipies in the search console, sometimes you'll come across requirements where the data that affects a widget's behaviour should come from the current user's website session.
Take care here, as if you have requirments for making search components based on recipies which rely this. For example "certain results should not be shown to users who are in security group X" is tricky as you can't pass the current user's group into the recipe when it's called.
You may need to build a custom component for this type of requirement, vary which widget/recipe is displayed or risk some JavaScript which hides certain results after they've been returned.
Usually when you're talking about Search, any reference to "crawler" means that the system will go out and find data by doing things like following links and loading each URL in turn. But the "feed crawler" for Sitecore Search doesn't work like that.
While it will go though a "feed" (a json document describing your content) and index it, it can't go out and fetch this data from your site.
You have to send the file containing all the relevant data for the index to Sitecore Search for it to process, despite what the name implies. Remember that when you're planning your indexing approach.
Hopefully if you keep those things in mind, you can make your implementation simpler.
↑ Back to top
