Search Query Tool: Issues with the new approach to retrieve all managed properties for a search result introduced in v2.8.7
felixbohnacker opened this issue · comments
Between release 2.8.6 and 2.8.7, the feature that allows you to view the managed properties of a search result seems to have changed.
Previously, they were retrieved from the search farm whereas they are now retrieved from the farm where the content is stored.
However, this doesn't meet my expectations in any of the following scenarios:
- Non-SharePoint content sources
- Dedicated search farm with a content enrichment web service
- Cloud SSA
I guess that there will be some more examples where this approach is less-than-ideal.
Is there any way to revert this back to the old behaviour without having to stay at v2.8.6 forever?
@felixbohnacker If you are working with on-prem you can just stick with v2.8.6. There are no new search features being added to the app anyways. Any change over the past couple of years has been to accommodate SPO scenarios.
@wobba Thank you for your reply. I‘m both using on-premises and SPO.
Then have both versions or use the older if that works 🙂 And it should be ok to fetch the props via any webapp. Don't see how that should matter. That's how I always used it in in the past onprem as well.
Sure, using both versions side by side would be an option, but it's more annoying than just using the newest version and benefit from any improvements made.
At this point, I'm just wondering what the reason for this change was and why reverting to the "old" behaviour isn't possible.
Trying to figure out what the change was. I'm pretty sure it uses the SharePoint Site URL for the request, and has always done so. Can you share what you are seeing between them in terms of URL used for the managed properties call?
In v2.8.6, there is an HTTP GET request to /_api/search/query?querytext='WorkId%3a%22%22'&refiners='ManagedProperties(filter%3d5000%2f0%2f*)'&clienttype='ContentSearchRegular' when clicking on the "Managed Properties" button.
In v 2.8.7, this only works if the SharePoint Site URL is the same as the URL of the system where the respective item is hosted.
Although my C# knowledge is limited, I just tried to dig through the code to check when this change has been made. It seems that the error message that is now shown when the two hosts differ has been introduced with the following commit: d2f1041
If I'm not mistaken, this seems to be the only relevant change to this feature that has been made between 2.8.6 and 2.8.7.
Ahh... I get it. I'll add a check for the connection method used in that check so that it works for scenarios not using domain auth tokens. Which connection method are you using yourself for on-prem?
Will be fixed in the next release :)
Thank you very much. I just built the tool myself based on the new code and I can confirm that retrieving the managed properties and their values works in our on-premises setup now.
However, this doesn't fix the issue I have when using the search query tool in our cloud hybrid search setup. There, I'm performing the search query against SharePoint Online with the logon method "SharePoint Online". For content that is not stored within the SPO tenant, but indexed using the cloud SSA, the host URL differs from the SharePoint site URL as well obviously.
Do you know what the correct host URL would be for content marked with IsExternalContent. Would it be the main geo host? And what's a good way to find this? And there are tenants with vanity domains as well in the mix.
If you find a foolproof way, we can add it.
As we don't have a multi-geo tenant in our company, I don't know how this looks like in practice unfortunately :(
However, it seems that "[i]n a hybrid SharePoint environment with cloud hybrid search, on-premises content is added to the Microsoft 365 index of the central location" according to https://docs.microsoft.com/en-us/microsoft-365/enterprise/configure-search-for-multi-geo?view=o365-worldwide#whats-different-about-search-in-a-multi-geo-environment.
Therefore, it is my understanding that on-premises content is only returned as a search result in three cases:
- The API request is sent to the default geo location
- The API request is sent to a non-default location, the query parameter EnableMultiGeoSearch is set to true and the MultiGeoSearchConfiguration parameter isn't included or left blank
- The API request is sent to a non-default location, the query parameter EnableMultiGeoSearch is set to true and the MultiGeoSearchConfiguration parameter includes the default geo location.
Thus, sending the managed properties request to the same URL as the original search request (and adding the EnableMultiGeoSearch and MultiGeoSearchConfiguration parameters with the same values as in the original search request if they have been included) should be sufficient if I'm not mistaken.
Do you have a test environment where you can confirm these assumptions by chance?
The quick-fix is to use the host you connect to when item has IsExternalContent and assume this is the main geo. This requires IsExternalContent to be included in the selected properties for it to work though.