One of the most powerful features of SharePoint is the Search Rest API. It allows us to obtain, filter and personalize the information that is useful to a user and thus allows us to create pages of content of interest to him.
Well, sometimes, despite the incredible effort that Microsoft makes to maintain the infrastructure, something may go wrong.
The guidance below describes how we have been troubleshooting the search issues we faced lately.
Atlas provides a series of content pages that contain search-based webparts and show information classified by type, news, events, knowledge pages, search pages to find users, documents,... Suddenly, from one day to another , we began to notice how, in some Tenants, the user search page first, and later other pages, were showing the wrong content, they were not applying the proper filters.
Our web parts use the SharePoint Rest API for search, running queries that are defined as Result sources at tenant level.
To understand what was happening, we had to look for some clue in the trace of the requests that were made to the servers.
For this, we could use a tool like Fiddler, or simply by opening the Developer tools of the browser (F12) and searching the Network tab, until we found a GET request to a "query" or POST "postquery" endpoint.
What we were really looking for was to see what query SharePoint was actually interpreting.
From our experience, when a web part returns too many results in a search request, it is because the query string is not well defined... But in this case, it was not possible, nobody had touched anything, and suddenly it had stopped working.
Every time that we run a query, the API response has this look...
As you can notice, there is a property in the Json reply, "QueryModification", that tell us the query that SharePoint is actually running.
Without going into much detail about how the Search API works, to understand the problem we were having, simply indicate that we can make a query sending the Result Source (where the query is defined), by ID or by Name, being SharePoint responsible for finding that result source and applying the query along with additional parameters.
Well in our case, we saw that despite querying the Result Source by name (Local People Results), when we inspected the response, QueryModification, had a wrong value. This did not happen if we made the query with the Source ID. That helped us to understand that the issue was with Search, not with our web part itself.
From there, we put aside our code, and directly began to make direct requests to the SharePoint API through the browser (we were also using a very useful tool, Search Query Tool (https://github.com/SharePoint/PnP -Tools/tree/master/Solutions/SharePoint.Search.QueryTool)).
Copying-pasting this into the browser and replacing the [tenantName] and [sourceName] should help you to see if SharePoint finds your Result source from the Tenant and is working fine.
The reply to that query should be something very similar to the previous JSON but in XML, and it will work for OOB or custom result sources.
Comments
0 comments
Please sign in to leave a comment.