Frequently Asked Questions
Questions that are frequently asked about the OpenText Federated Query Server product
Click on each question to see the answer.
Federated Query Server is a piece of search middleware that takes a user's query, translates and broadcasts it to multiple HTTP-enabled content repositories, reformats, sorts, merges and clusters the query results, and returns them to the user in a single page.
Federated Query Server is compatible with many OpenText products, including: Content Server (formerly Livelink), Media Management (formerly Artesia DAM), Discovery Server (formerly BRS/Search) and Collections Server (formerly BASIS).
It can also search other Web-enabled Intranet products, such as SAP, Lotus Notes, Microsoft SharePoint Server, Outlook Web Access and Novell GroupWise - please contact us for further details.
Federated Query Server has been tested against many Internet search engines, including Bing, Facebook, Google, Twitter, Wikipedia, Yahoo and YouTube.
Federated Query Server requires a content repository to have the following features and characteristics:
- The repository must have an HTTP interface that uses either the GET or POST method
- A query is submitted, and the results are obtained, by visiting one or more URLs
- The query language of the repository is either Boolean or keyword
- The results are returned as a list of items, each with a URL or ID that identifies the result document
Any content repository that meets the above conditions is likely to be compatible with Federated Query Server.
Yes, Federated Query Server can act as an OpenSearch server, an OpenSearch client, or both. It ships with an OpenSearch description document, and RSS and Atom interfaces. It's configuration tool has built-in support for reading OpenSearch description documents, and built-in parsing rules for every version of RSS and Atom, including OpenSearch extensions.
The Federated Query Server configuration tool has built-in support for reading CMIS AtomPub service documents, and built-in parsing rules for Atom, including CMIS AtomPub extensions.
By executing Federated Query Server (usually by submitting a form in an HTML search page) and specifying the search criteria in form variables.
Searches can be embedded in applications that support HTML forms (e.g. OpenText Content Server) or that can issue HTTP requests (e.g. Java or Mobile applications).
Searches can also be issued from the search bar of most browsers, and from Windows 7 Explorer.
Federated Query Server accepts queries containing keywords and operators.
Keywords may be words or phrases, and may have one or more prefixes, modifiers and wildcards. Operators may be Boolean, proximity, thesaurus or metadata (fielded or numeric).
The text of each operator is configurable, alternate operators may be specified, and operators may be disabled if required.
The text of each operator, and the other characteristics of the query language, make up a language configuration. Federated Query Server has one language configuration for the user interface (i.e. for queries specified on the search form) and one language configuration for each content repository.
Any operators that are found in the query text are translated from the user interface language to the languages of the content repositories. If an operator cannot be translated because it is not defined in the content repository language configuration, then the operator will be degraded until it can be translated.
Metadata values and field names may also be translated.
Yes, Federated Query Server can handle search forms with up to 50 query boxes, each of which may be joined to the next by a conjunctive operator. Each box also has a wide variety of associated form variables that allow the specification of a default operator, field qualification, a metadata number range, etc.
Federated Query Server can either pass the contents of each query box individually to a content repository, or it can combine the contents of some or all the query boxes, along with associated information such as field names, into a single query expression and pass this instead.
Additionally, Federated Query Server can extract the query terms from some or all of the boxes and pass this also (this is useful for specifying terms for ranking).
Federated Query Server starts a new thread for each content repository. The thread translates the query, connects to the repository's host, issues the HTTP request with the query and any other required information, and collects and sorts the query results. All of the threads are started simultaneously and therefore act in parallel. The main thread is responsible for merging the query results and returning them to the browser.
Federated Query Server has three types of content repository - the master repository, one or more sorted repositories, and one or more unsorted repositories. The page returned to the client is effectively the page returned by the master repository, with the query results returned by all other repositories inserted into it.
The results from the master repository and all sorted repositories are sorted and merged into a single list which is output first. The results from all the unsorted repositories are output after the merged list, grouped by repository.
An unlimited number of sort levels may be specified. Each level may sort on any of the elements of a result - for example, relevance score, title, date, size, category, etc.
Usually, the first level sort is by relevance score, as this is the order in which results are normally returned from content repositories.
The sort levels may be static or may be chosen by the user at search time.
Federated Query Server can cluster query results by their content, their location (extracted from each query result's URL), or both.
Clustering by content produces groups of results, each group listed under a phrase that appears frequently in the results of that group. Phrases may be extracted from any or all of the elements of a result.
Duplicate query result removal is optional. If it is enabled, query results that are the same (you can choose which result elements to compare, and how to compare them) are merged into a single result.
Each content repository returns relevance scores that are calculated using a certain algorithm, and that lie within a certain range of numbers. Federated Query Server can be configured to accept relevance scores in any range (for example, 0-1 or 0-100). All relevance scores are converted to a common scale of 0-100 for internal calculations, but may be output again in any scale.
Federated Query Server can also modify relevance scores returned by a content repository - one of four algorithms may be selected to carry out this modification (for example, one of the algorithms reduces high scores but increases low scores).
Federated Query Server can estimate a query result's relevance from its position in the results list. Three algorithms are provided to perform this estimation.
Alternatively, Federated Query Server can retrieve the document pointed to by a result's URL, and assign the result a relevance score based on the content of the document. This feature is very powerful, but will also significantly increase the amount of time before results are returned to the user.
Finally, Federated Query Server can create a pseudo-document from the textual fields in a result (for example, the title and summary) and then assign the result a relevance score based on the content of this pseudo-document.
No, Federated Query Server can accept results in HTML, XML, JSON, CSV, plain text, or virtually any other textual format - as long as the results, and the elements within each result, are identifiable (for example, by strings either side or the presence of an XML tag).
Federated Query Server supports Basic, NTLM, Kerberos and delegated HTTP authentication. It can also access content repositories that require a user to log-in via a Web form.
Credentials can be stored in the Federated Query Server configuration file, specified on the search form, or obtained from the Web server.
Additionally, Federated Query Server can pass cookies between the browser and a content repository, in either or both directions. This can be used to support SSO software (e.g. Siteminder) or to maintain repository session cookies.
Yes, the name or address of the proxy server may be specified in the Federated Query Server configuration file. A list of proxy exceptions (sites that should be connected to directly, rather than through the proxy server) may also be given.
Federated Query Server supports Basic, NTLM, Kerberos and delegated proxy authentication.
Reverse proxy servers are also supported.
Federated Query Server supports SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2 by making use of the OpenSSL library. It also supports HTTPS via a proxy server by using SSL tunneling, and HTTPS reverse proxy servers.
Federated Query Server is currently supported on Windows Server 2012 and 2012 R2, Solaris 10 and 11 (SPARC V9) and Red Hat Enterprise Linux Server 6 and 7 (64-bit).
In addition, the Federated Query Server configuration tool is supported on Windows 7, 8.1 and 10.
Federated Query Server requires approximately 64MB free RAM and 25MB free disk space. Fast network connections between Federated Query Server and the repositories being searched will help obtain the best performance and response times.
In addition, the Federated Query Server configuration tool requires XGA graphics.
Download more information about OpenText Federated Query Server