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 Oracle WebCenter Interaction portals to search your portal.
An outgoing federated search allows users of your portal to search other Oracle WebCenter Interaction 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 Oracle WebCenter Interaction portal can request and/or serve content to another Oracle WebCenter Interaction portal. When you install the portal, the Public Access incoming federated search is created. This allows other Oracle WebCenter Interaction 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 identification name 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 Active Directory 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, Oracle or another vendor might have written a search Web service to access it. If not, Oracle provides an IDK that allows you to easily write your own search Web services in Java or .NET. For details, refer to the Oracle WebCenter Interaction Web Service Development Guide, which is located on the Oracle Technology Network at http://www.oracle.com/technology/documentation/bea.html.
To create an outgoing federated search that accesses a non-portal repository: