Federated Searches allow you to establish search relationships with other sources (including other portals, Web sites, or databases). After you set up the necessary Federated Search access, users of the requesting portal can search for content in the serving repository, whether it is an established search system or your own custom database.
There are incoming and outgoing Federated Searches:
An Incoming Federated Search allows other Plumtree portals to search your portal.
An Outgoing Federated Search allows users of your portal to search other Plumtree portals or other external repositories.
This topic discusses the following information:
To learn how to create or edit administrative objects (including incoming federated searches, outgoing federated searches, and Search Web Services), click here.
To learn how users can run a Federated Search query, click here.
To learn about the Incoming Federated Search Editor, click one of the following editor pages:
To learn about the Outgoing Federated Search Editor, click one of the following editor pages:
Search Web Services allow you to specify general settings for your remote search repository, leaving the security settings to be set in the associated outgoing federated searches. This allows you to segregate access to your search repository through multiple outgoing federated searches.
To learn about the Search Web Service Editor, click one of the following editor pages:
One Plumtree portal can request and/or serve content to another Plumtree portal. When you install the portal, the Public Access Incoming Federated Search is created. This allows other Plumtree portals to search this portal as the Guest user.
To allow other search relationships, you must create new incoming or outgoing federated searches. Whether your portal is requesting or serving content, you and the other administrators involved need to agree upon the following issues prior to establishing Federated Searches:
Which portals will serve content?
Which portals will request content?
What Portal ID and password will be used to identify
the portals?
For every request issued, the requesting portal sends an ID and password
to identify itself to the serving portal. You must enter the same ID and
password in both the requesting portal's outgoing federated search and
the serving portal's incoming federated search.
What content from the serving portal will be available
to the requesting portal?
If both portals share a common external database of users, such as
an LDAP server or NT domain, you must grant the shared users access to
the appropriate content on the serving portal. This provides the greatest
degree of content security without requiring any additional administrative
work.
If the portals involved do not share a database of user information,
you must create one or more portal users in the serving portal that can
be impersonated by users of the requesting portal. You should create serving
portal users specifically for this purpose and share the names of these
users with the administrators of the requesting portals.
The following links lead to usage scenarios:
Impersonating Serving Portal Users describes how requesting portal users are allowed to impersonate serving portal users to gain access to secured content.
Sharing a User Database describes how multiple portals accessing the same user repository can share content.
After you and the other administrators involved have determined how this relationship will work, you are ready to establish your incoming or outgoing federated searches.
If there is a non-portal repository that you want to search, Plumtree or another vendor might have written a Search Web Service to access it. If not, Plumtree provides an EDK that allows you to easily write your own Search Web Services in Java or .NET. For details, contact Customer Support.
To create an outgoing federated search that accesses a non-portal repository: