OpenText Content Server Search

Recently, while working on content server, I came across several search related issues. With time and lot of hard work I was able to resolve all of them, but this resulted in me having pretty good picture of how OpenText’s search engine works. Hence I thought of writing this blog for anyone facing similar issue or for anyone who just wants to learn more about its search engine.

Search Engine 10.0 (SE10) is the search engine provided as part of OpenText Content Server.

The entire Search Engine comprises two main flows – Indexing and Searching.

Indexing starts with extraction of data from content server and storing it in Search Index. Searching flow forms a cycle, starting with a user entering search query, the query being searched in search index and the result being displayed to user.

Livelink Search Overview

Search Engine 10 consists of following main components:

1. Extractor – extracts new data and adds them to IPool
2. IPool – contains content and metadata in object form for addition to search index
3. Update Distributor – selects index engine for addition of IPool to search index
4. Index Engine – carries out indexing operation
5. Search Index – contains index on which search is carried out
6. Search Federator – receives new search request and passes them to search engine
7. Search Engine – searches the string provided by search federator in search index
8. Grid Registry – Grid registry is used by SE components to coordinate their use of RMI

We'll be looking into all of these in detail in next pages. For now lets see some advantages of this search engine.

Advantages of SE10 are:

• Scalability: Search Grid part of SE can be easily scaled with addition of more Admin server to distribute task and improve overall search performance. SE10 can be restructured to add capacity, rebalance the distribution of objects across servers, switch partition modes and perform addition or removal of metadata fields.
• Upgrade Migration: SE10 includes conversion of older indexes to newer versions. Hence, addition of new features and capabilities does not require re-indexing of data.
• Transactional Capability: If a catastrophic outage happens in the midst of a transaction, the system can recover without data corruption. Additionally, logical groups of objects for indexing can be treated as a single transaction, and the entire transaction can be rolled back in the event that one object cannot be handled properly.
• Metadata Updates: The OT search technology has the ability to make in-place updates of some or all of the metadata for an object.
• Search-Driven Update: SE10 can perform bulk operations of modification and deletion on sets of data that match search criteria. This allows for very efficient index updates for specific types of transactions.
• Maintenance Commitment: OT supports search solution throughout the life of their ECM application including regular updates.
• Data Integrity: Search Engine 10 has several features to allow quality, consistency and integrity of search index and the data to be assessed.