Federator:
Address Situations Where One Index Isn’t Possible
Key Features:
Multiple search engine support
With our library of pre-built backends, a variety of different search engines can be accessed individually or in combination. You can combine different editions or versions of the same kind of search engine or across different search engines.
MultiSearch
Sends queries to multiple search engines, then combines the results into a single set. Relevance normalization algorithms mix results into the right order and combine refiner values so that users get the seamless experience they expect. Administrators can also add a bias. For example, slightly preferring results from a local system over a remote system.
Dynamic Query and Result Transformation
ur extensible query and result pipelines let developers modify queries and results on the fly so they can tackle difficult search challenges easily. A library of pre-built pipeline stages provides powerful add-ons without coding. All of this is done transparently to the UI, which simplifies development and administration.
SharePoint’s OOTB pipelines are sealed; and open up a wide range of innovative solutions.
Low Latency
Minimizes response time so that users see responsive search, even with a heavy query load.
Completely integrated with SharePoint
The Federator is built as a SharePoint Search Service Application (SSA) so that all SharePoint UI and administrative functions work with it seamlessly independent of which search engine(s) are accessed. This architecture also provides easy deployment, dynamic scaling, and integrated monitoring with tools and techniques familiar to SharePoint administrators.
Key Benefits:
- Comply with export restriction laws
- Integrate subscription sources that don’t allow crawling
- Seamlessly incorporate Google, Bing or Wikipedia
- Maintain Governance + Compliance
- Include real-time news and stock values in results
- Maintain high security using separate indexes
- Scale beyond what one search farm can handle
Solve Difficult Search Problems
Our customers use our Federator to solve a range of problems, without custom code. Here are a few examples:
Problem: divisions of a company each need control of their own search environment. They index divisional content in local language, with specific security and content enrichment. But employees need easy access to information across divisions.
- Solution: use the Federator at each search environment to merge results; employees in each division see a unified view across the company.
Problem: security policies dictate separate intranet and extranet farms with no possibility that extranet users might see internal confidential content that happens to have the wrong entitlements. Employees need to see both intranet and extranet content.
- Solution: use the Federator on intranet portals to combine search from intranet and extranet indexes. Don’t use it on extranet portals.
Problem: each region has some content which is subject to information export restrictions; indexing it centrally violates laws. A global index works well for the rest of the content. How can employees see a single view with both global and local content?
- Solution: create small local farms with export controlled content (and other sensitive content). Use the Federator to merge results from the local search farm with results from the global search farm. This keeps you in legal compliance and provides a great user experience.
Problem: large-scale deployments magnify the impact of outages, upgrades, disaster recovery, and maintenance; restoration from a large index backup can take 20 hours or more, with search offline the whole time.
- Solution: divide the search farm into multiple sections and use the Federator across them; each section can be upgraded independently and the whole system can be online during restoration.
Problem: a company has multiple search technologies including some specialized search engines for specific applications. How can they provide a single destination for search?
- Solution: connect the multiple search engines to the Federator and then present unified results as well as tabs or independent search centers for the specialized applications.
Problem: a project to switch from a sophisticated FAST ESP implementation to SharePoint 2013 has to re-implement all the functionality of the old search engine, then cut over to the new one. This is a long project with a risky transition before new capabilities can be added.
- Solution: use the Federator to integrate ESP with the SharePoint 2013 UI; users see an improved UI and have people search immediately. Start implementing new functions in SharePoint 2013 right away, and re-implement FAST ESP functions and content collections one at a time. Use the Federator to switch over each function and collection as it is ready, and to fall back if needed. After everything is working well in SharePoint 2013, simply turn off ESP and remove the Federator.
Problem: hybrid SharePoint OOTB has a weak federated search experience that users are unhappy with: blocks of results with refiners from the local search only.
- Solution: use the Federator to provide the experience users want: a single interleaved result set and combined set of refiners.
Enhance Enterprise Search Results in Real-Time
Our customers also use our Federator for direct access to queries and results on a single search engine. Here are some examples:
- Include real-time product inventory and price information in search results
- Enhance expertise finding by adding dynamic relevance profiles
- Improve search relevance by pre-stemming queries
- Highlight different results based on current weather conditions
- Provide contextual results in their customer portal based on an employee’s profile, location, and current task
- Tailor how synonyms are processed to provide more precise search results
- Automatically search for spelling variants if no results are returned
- Include real-time news and stock values seamlessly in search results
