When our team performs code refactoring on custom web parts, the following two objectives are identified with the team:
- Remove as many configurations as possible.
There are lots of web parts retrieving data via the search query (CSOM) and each of them contains a result source id configuration item.
Unlike the built-in “Local SharePoint Results” result source, the custom result sources have different result source id values for each site collection. It requires a configuration file for each site collection that keeps track of the result source id value for each result source.
The following two screenshots show the different result source id values for the same custom result source “Featured Content”.
Figure B. Result source id value for “Featured Content” in site collection A.
Figure C. Result source id value for “Featured Content” in site collection B.
The solution to this problem is to use the Result Source Name instead of the Result Source Id in the query.
Two query properties are required: “SourceName” and “SourceLevel”
- SourceName is the result source display name. For example, “Featured Content” shown in Figure B and C.
- SourceLevel indicates which level the result source been defined. There are 4 levels :
To query with O365 Search REST API, the following is the URL format of your search query URL. Instead of using a hard-coded sourceid value, you can replace it with the result source name and level information.
- REST API Search Query with Source Name:
- REST API Search Query with SourceId:
This solution helped our team transform all the search queries in our legacy code with result source names. The configurations of result source GUID per site collection is no longer needed in our new code base.