Hi Drew
I’d advise raising this as a developer support ticket. The Find UI is delivered as a SaaS service it needs to be handled by support.
https://world.episerver.com/support
David
Thanks, David,
I'll open a ticket and report back here with the findings.
Drew
Episerver support reported back that my research did in fact point to the right solution.
https://blogs.msdn.microsoft.com/webdev/2012/11/19/all-about-httpruntime-targetframework/
Having the targetFramwork attribute set to the correct version fixed the problem.
Episerver support reported back that my research did in fact point to the right solution.
https://blogs.msdn.microsoft.com/webdev/2012/11/19/all-about-httpruntime-targetframework/
Having the targetFramwork attribute set to the correct version fixed the problem.
Summary
When browsing to the Find admin UI in our production admin instance, no data is displayed in any of the individual admin parts. For instance, browsing to Episerver > Find > Overview > Explore shows a spinner and a "Retrieving data" message, but no results are displayed.
However, searching for products on the site succeeds, as does searching for products in the catalog UI (we've configured catalog UI to use find for searching).
Details
Looking at the request made by the find admin UI, we see a request to /episerver/Find/_proxy/_search that returns a 500 error. the POST data is:
The EventViewer on the server shows the following error:
Other searches in the admin that do not use the Find/proxy api appear to succeed. For example, navigating to EpiAdmin > Find > Configure > Boosting and using the "Preview the boosting effect" feature returns results. This request is a post to https://admin.server.domain/epiesrver/Find/api/editorialboosting/searchwithweights/ with the folowing payload:
Research
We found this support post, but I don't believe it is the cause of our problem. It mentions that the fix is to add an attribute to httpRuntime in web.config of targetFramework='4.6.1', but I don't believe that targetFramework is a part of the schema for httpRuntime, but rather system.web/compilation. (we already have a targetFramework='4.7.1' on the compilation element)
Versions
We're using
Environments
This is happening in our CI environment and our Production environment, one with a developer and another with a production index. Therefore, I know it's our code or library code that's the problem, and not network or environment problems.