It is possible to deploy a single portal or multiple, federated portals. Figure 2-1 illustrates a single portal deployment where different experience definitions provide a portal experience specific to each group of users. Figure 2-2 illustrates federated portals, where instead of experience definitions on a single portal, each federated portal provides a different portal experience.
Figure 2-1 Single Portal with Multiple Experience Definitions
Figure 2-2 Federated Portals
Having a single portal with one or more experience definitions has benefits over deploying multiple federated portals. In a single portal deployment:
Users have different experiences but are managed in a single place.
The Oracle WebCenter deployment is easy to scale. IT needs only to look at total use for a single set of hardware versus fragmented use for multiple sets of hardware.
It is easy to distribute enterprise-wide communications.
It is easy to integrate enterprise-wide business processes.
There is a common content management system
Experience Definitions
Experience definitions allow you to present different audiences with different branding and features in the portal.
For example, you could create an experience definition for a particular customer. The experience definition would include the customer’s logo and company colors and include access to communities and knowledge directory folders specific to the needs of the customer.
Experience definitions are applied according to rules configured with the Experience Rules Manager.
For information on configuring experience definitions and rules, see the Administrator Guide for Oracle WebCenter Interaction.
Communities
Communities are pages shared between members of a group to facilitate collaboration and communication on a particular project or on departmental goals.
Communities provide the following benefits:
A consistent user experience for members of a department or project group.
Discussion forums in which community-pertinent information is discussed and archived.
A version-controlled repository for project or departmental documentation.
For details on implementing communities, see the documentation for Oracle WebCenter Collaboration.
The following are potential use cases for communities:
Business Unit Resource Center (Line of Business Communities)
Audience
Business unit or department
Customers of that business unit or department
Content
Community documents, links, calendar
Metrics
Expert finder
Q&A
Success indicators
Strong departmental or group identity
Existing intranet as content source
Motivated community owner
Pitfalls to avoid
Static page that people visit and forget
Suggested Oracle WebCenter tools
Oracle-BEA AquaLogic Interaction Portlet Framework - Microsoft Excel
Oracle-BEA AquaLogic Interaction Publisher
Interactive Workspace (Collaborative Communities)
Audience
Ad hoc or established project workgroups
Content
Project task list
Document management and archive
Project calendar
Threaded discussions
Project metrics
Success indicators
Members spread out
Project has specific objectives and milestones
Project has outgrown e-mail and file-shares
Pitfalls to avoid
Dustbin of history: old projects, communities that do not go away
Ghost town: two or three people are probably not enough
Suggested Oracle WebCenter tools
Oracle WebCenter Collaboration
Oracle-BEA AquaLogic Interaction Studio
Oracle-BEA AquaLogic Interaction Portlet Framework - Microsoft Excel
Customer or Partner Management Site (Sales and Service-Oriented Communities)
Audience
Customers or partners
Content
Key customer or partner resources: documents, calendar
Self-service access to CRM or PRM system
Feedback mechanism
Customer-to-customer or partner-to-partner: facilitate community
Success indicators
Portal-only access for critical information
Responsiveness to customer/partner feedback
Pitfalls to avoid
No human input
Suggested Oracle WebCenter tools
Oracle WebCenter Collaboration
Oracle-BEA AquaLogic Interaction Studio
Oracle-BEA AquaLogic Interaction Portlet Framework - Microsoft Excel
Dashboards (Analytic Communities)
Audience
Management
Content
Performance metrics
Financial documents
Success indicators
Support to enforce consistent data formatting
Portal-only access for critical information
Culture of accountability based on metrics
Pitfalls to avoid
Make sure the dashboards have fresh data
Make sure security works appropriately
Suggested Oracle WebCenter tools
Oracle-BEA AquaLogic Interaction Portlet Framework - Microsoft Excel
Oracle-BEA AquaLogic Interaction Integration Services for SAP and PeopleSoft
Business Process Applications (Process Communities)
Audience
Users involved in process
Content
Published content
Data from multiple systems
Workflow
Metrics
Success indicators
Simple navigation, consistent branding a priority
Unified search criteria
Looking to utilize reusable components, common foundation
Pitfalls to avoid
If you do not have a process, the software will not do it for you
Suggested Oracle WebCenter
tools
Oracle-BEA AquaLogic Interaction Publisher
Oracle WebCenter Collaboration
Oracle WebCenter Interaction Search
Oracle-BEA AquaLogic Interaction Studio
Oracle-BEA AquaLogic Interaction Portlet Framework - Microsoft Excel
Portlets
Portlets are applications embedded in a portal and can be interactive or solely informational. They are able to communicate preferences with the portal and to communicate with other portlets.
A portlet must be based on a web service. The web service controls the bulk of the portlet settings, such as the URL and cache settings. The portlet definition in the portal contains the name, width, type, and administrative preferences, if any.
Portlet templates allow multiple instances of the same portlet to be created, with each instance potentially different in appearance or information.
Oracle WebCenter Interaction includes pre-made portlets and the ability to easily create portlets using products such as Oracle-BEA AquaLogic Interaction Studio and Oracle-BEA AquaLogic Interaction Publisher.
Portlets can also be developed from scratch using the Oracle WebCenter Interaction Development Kit (IDK). For details on portlet development, see the Oracle WebCenter Interaction Development Kit documentation.
Oracle WebCenter Interaction Search
Oracle WebCenter Interaction Search allows users to quickly and efficiently find a wide variety of information from sources across the enterprise, both inside and outside the Oracle WebCenter products. Search can be distributed across a multiple server cluster.
Searchable Content
There are a number of possible sources of searchable content, and it is important to understand the options for providing that content to end-users:
Knowledge Directory: The core of the Oracle WebCenter knowledge management infrastructure is the Knowledge Directory—a hierarchy of folders that contain links to files of various formats, stored in different types of repositories. Files can be crawled into the Knowledge Directory or manually submitted and can be filtered into the folder hierarchy (also known as a taxonomy) in order to provide an entry point to high-quality, organized content. In addition to the out-of-the-box functionality, virtually any repository can be made searchable through the creation of Content Services. All items in the Knowledge Directory can be searchable.
Oracle WebCenter Collaboration: The project workspaces provided by Oracle WebCenter Collaboration contain documents, threaded discussions, announcements, and task lists contributed and managed by distributed teams. All items in Oracle WebCenter Collaboration can be searchable.
Oracle-BEA AquaLogic Interaction Publisher: The form-based data entry and file management provided by Oracle-BEA AquaLogic Interaction Publisher allows specialized content submitted by users to be published and surfaced in the portal through portlets. All published content items associated with portlets can be searchable.
Portal Administrative Objects: Users, web services, portlets, Content Services—all the objects that make up the administrative infrastructure of a portal are searchable. End-users can search for users (to view profile and expertise information), communities (to visit or join), and portlets (to add to a My Page). Administrators (who need to create and manipulate all types of objects) can search for a wider variety of items and have more advanced options in their search results.
Non-portal Searchable Content: Legacy search engines and repositories with pre-existing search or query functionality can often contain valuable sources of content that for various reasons cannot be crawled into the portal or managed through Oracle WebCenter Collaboration or Oracle-BEA AquaLogic Interaction Publisher. With search web services, any repository that can respond to queries can be extended with a web services adapter so that it can be searched from the portal. Results from a number of disparate search providers (both inside the enterprise and on the internet) can be aggregated in this way.
The Search administrator is responsible for creating and scheduling the initial search index jobs as well as update jobs. The Search administrator is also responsible for customizing search “Best Bets” and the search thesaurus.
Grid Search
Grid Search refers to distributing Oracle WebCenter Interaction Search nodes over multiple servers. Search servers can be configured to be stand-alone or a node in a search cluster. In a search cluster, the search index is divided, orpartitioned, across multiple search nodes.
You can manage the search cluster using the Search Cluster Manager or the command line utility cadmin.
For more information on administering Grid Search, see the Administrator Guide for Oracle WebCenter Interaction.
Grid Search Best Practices
Do not deploy multiple nodes on a single host in a production environment.
Schedule checkpoints when there is little or no planned indexing activity. This will help ensure that the checkpoint reflects the most up to date information and minimize recovery time.
Set the Search Cluster Manager Service to manual or disabled on all but one server. Only one instance of this service can be utilized by the portal.
A single search sever can be installed as a search cluster with one node, rather than a stand-alone search deployment. This helps streamline the process of adding future search nodes.
In a multiple node deployment, configure the cluster home directory on a server other than the search servers themselves. If the cluster home is located on one of the search servers, that server is a single point of failure for the entire cluster.
Cluster home should be located on a high-availability file system with fast connectivity to the search node host machines. Ideally, the cluster home should be on a RAID file system to ensure availability and fault tolerance.
Search nodes should be located within the same subnet on the network, and ideally on the same switch.
