Implementing Site Search in CQ5 / AEM
- 1. IMPLEMENTING SITE SEARCH IN CQ5/AEM DEVANG SHAH, I-CUBED
- 2. Session Outline Importance of site search functionality CQ5 internal search workings & limitations Integrating CQ5 with external search engines & challenges Indexing patterns for integrating with external search engines Q&A
- 3. Site Search is one of the core functionality of most websites Browse v/s Search: Alternate methods of allowing visitors to find the information they need quickly and easily “90 percent of companies report that search is the No.1 means of navigation on their site” -- Forrester Research “82 percent of visitors use site search to find the information they need” -- Juniper Research Advances in search features, which allows site visitors to: Auto complete/auto correct search terms Build advanced queries, Filter results by facets, Search results refined by location, preferences, previous history, etc “Visitors who used site search were “more likely to convert from browsers to buyers”.” -- Juniper Research
- 4. • Jackrabbit internally uses Lucene to Index repository content • Whenever any content is modified, along with it getting stored in repository, lucene index is also updated • Index Location: <crx-quickstart>/repository: • repository/index • workspaces/crx.default/index • Index Configuration: • Repository.xml & workspaces.xml <SearchIndex> block • tika-config.xml in workspaces folder • Changes in new version of Jackrabbit (3.x / Oak)
- 5. • Jackrabbit • JCR Spec 1.0: Support for XPATH & JCR SQL1 • JCR Spec 2.0: Support for JCR SQL2. Support for XPATH deprecated in JCR 2.0 but Jackrabbit still supports it • Both SQL & XPATH queries are translated to same search tree • Query Builder is an API to build queries for a query engine • CQ providers several OOTB components & extensions which leverages QueryBuilder API for full text or predicate based searches • OOTB Search Component provides support for full text query and enhanced search features: similar pages, facets support, pagination, etc
- 6. Use Case: Non CQ Content Sources Use Case: Author v/s Visitor Search Patterns CQ generates one index per server Author and visitor search patterns and requirements are typically different Performance & Architecture Considerations Larger sites with more than one source of content and assets. Difficult to index non-CQ content ‘n’ number of queries and search variations – making it difficult to utilize CQ caching architecture Jackrabbit layer on top of Lucene may slow down search and query performance Scaling of search architecture dependent upon CQ architecture Customizations Utilizing different content parsers, index tuning, etc (mitigated in 5.6.1) Can I use newer version of Lucene? How can I extend Jackrabbit search implementation?
- 7. External Search Platforms Search Providers with Crawlers (examples): ▪ Google Search Appliance ▪ Microsoft FAST Non-crawler Search Providers (examples): ▪ Endeca ▪ Lucene/Solr Enables independent scaling of search platform Supports more than one content sources Configuration & customization of search application is decoupled from CQ5 application May provide more advanced search features (faceted search, geospatial search, personalization, etc)
- 8. Challenges building & managing search indexes Building Site Index: Crawl or Query & Inject? How often should index be rebuilt? How to ensure that content & metadata between content sources and search index is always in sync? In case of multiple data sources, how to manage duplicates, index structure and common metadata model? Challenges querying & building search results Should search results page be hosted on the provider’s platform or within CQ? Does search provider offer extended API to query and build search results within the application?
- 10. Integration Notes: GSA, FAST Site Crawler, Endeca’s Plugin for CRX Indexing, Solr via open Source crawlers (Nutch, etc) May require custom service which returns data (for example for Solr, Endeca) Pros: Ease of implementation Indexes rendered version of the pages Cons: Lag between content publishing and index update process may result in out of sync search results experience. Also, what happens to deleted content? Larger index crawl and build times Search index doesn’t have complete set of meta-data
- 12. Example – CQ / FAST connector (available via service pack) Pros: ⁻ Search index always in sync with content repository ⁻ Ability to send metadata with content ⁻ Customizable data formats and allows for partial indexing of page Cons: ⁻ Will require custom development efforts ⁻ Indexing of content instead of rendered version of the pages ⁻ System Performance / Event Handling
- 15. Pros: ⁻ Search index (mostly) in sync with content repository ⁻ Ability to send metadata with content ⁻ Customizable data formats and allows for partial indexing of page ⁻ Minimal replication event processing Cons: ⁻ Will require custom development efforts ⁻ Search index may get out of sync with content repository (but for a shorter duration only) ⁻ Indexing of content instead of rendered version of the pages
- 16. Handling initial content load & index creation In case of content push approach, how will initial index be generated? May need to create initial baseline via site crawl or custom service In case of content pull approach, how will index reflect deleted, moved, site pages? Permission sensitive site pages & assets Option 1: Export ACLs to Search Provider (example: CQ/FAST Connector) Option 2: Check user permission via CQ at run time (similar to how CQ handles delivery of content incase of closed user groups) Referenced assets, content pages and promos Option: Query referenced pages and index. May cause performance (& recursive index) issue though. Option: Selective content indexing (Index parts of page instead of entire page)