Which data sources are suitable for use in concierge auto-completion. Also consider if tab facets are appropriate to segment the search results listing. This is more important to consider for enterprise repositories which often have a much higher reliance on metadata.įaceted navigation (filters) that will be applied across the search, and what the filters will be based on. How each type of result will be formatted and what information should be displayed. a people search screen would only include results from the people data source.) What repositories should be included in the overall set of results. For example, a fully templated and formatted HTML page, or a JSON packet containing a specified set of fields. What sort of response Funnelback should provide when it returns the results. Funnelback will need to be integrated with the authentication mechanism (Active Directory, SAML, etc.) Users will need to be authenticated to access the search.
#Egnyte desktop sync 8.1.3 download windows
TRIM collections require single sign-on using Windows integrated authentication with Kerberos, and delegation to be configured. Some repository types have other specific requirements. These restrictions can also impose restrictions on who can access the search (for example impersonation may only work for users on the same network zone as the Funnelback server). TRIM repositories are restricted to direct searching only, and only on Windows - Funnelback search cannot be nested within another system (such as a CMS) as TRIM search requires user impersonation to be configured. Some repository types apply extra restrictions on how the search can be configured. if you’re searching as user=jsmith, then this will be applied to each of the repositories. This requires the same usernames to be used across the different authenticated repositories.
Awareness of the dependencies is crucial when designing the solution.ĭocument level security is only supported for certain repository types.ĭocument level security restricts the results to those that the current user can see. Some of the repository types require the Windows version of Funnelback. And it can often be difficult to obtain user accounts that have non-expiring passwords or the level of access required to produce the index. Funnelback typically requires an on-premises installation. This can also impose restrictions on where the Funnelback server is located and how it is configured. It is common for internal security configuration to present barriers to accessing data. Internal network policies often hinder access to data. Personalised content presents a unique problem - Funnelback is only able to index the view of content that is returned to it and cannot account for what different users will see when accessing the resource. This vastly increases complexity of the search, the amount of work to process a query and also places some limitations on the search. It also makes debugging a lot more difficult due to the size of log files.Īuthentication and filtering of results based on security permissions is a common requirement. It also affects the crawl time, with some repositories taking weeks or months to get fully crawled.
This affects the resourcing required for any setup and usually demands a multi-server environment. Integration can go in both directions - with Funnelback integrating to index content from different systems and some systems may integrate with Funnelback to nest Funnelback search results within the application, or to submit content directly to the Funnelback push API.ĭata repositories are often very large. Search covers numerous repositories of different types, requiring a lot of integration points with other systems.
Additional file formats using an external converter Additional file formats using Apache Tika Configuring Funnelback to index additional file types Delimited text, XML and JSON data sources Authenticated access to the search results Consider search-time authentication requirements
0 kommentar(er)
