On a high level, these components are:
- IndexingModule hooks up events to handle indexing pages (PageData objects).
- A set of conventions applied to the SearchClient.Instance object to exclude some properties of the PageData object and other Episerver classes and including some additional fields. This is handled by the IndexingModule at startup using the CmsClientConventions class.
- The PageIndexer class which handles the indexing, re-indexing and removing pages from the index. What pages are indexed can be customized by modifying the conventions it uses.
- A scheduled job - "Episerver Find CMS Indexing Job" - for complete re-indexing of all pages.
- The GetPagesResult extension method that can be called to execute search requests and get actual PageData objects back.
- A number of additional filter methods that make it more convenient to filter on Episerver CMS types such as PageReference.
Setting up for development
The CMS integration assumes that each environment has its own Find index. It also assumes that pages are added and removed through the CMS API. This means that:
- Each developer should have their own development index unless they use a shared database.
- Each server environment (test, staging etc) should have its own index unless they use a shared database.
- If pages are removed or added in other ways than through the CMS API (for instance using a database restore/rollback), the scheduled job for re-indexing should be run.
If any of the above guidelines are not met, the search and querying functionality may appear to be working but may produce unexpected results. For instance, the GetPagesResult method may return less pages than its TotalMatching property reports. This would for instance happen if two developers use the same index, and one of them publish a page that does not exist in the other developers database.