| Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle WebCenter Interaction 10g Release 4 (10.3.3.0.0) Part Number E26810-01 |
|
|
View PDF |
| Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle WebCenter Interaction 10g Release 4 (10.3.3.0.0) Part Number E26810-01 |
|
|
View PDF |
This chapter describes portal structure and content at a high level. The purpose of this chapter is to assist in planning portal structure and assigning administrative responsibility for managing portal content.
This chapter contains the following sections:
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
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 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 Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter Interaction.
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)
Customer or Partner Management Site (Sales and Service-Oriented Communities)
This section describes a use case for a business unit resource center (a line of business community).
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 WebCenter Content
KD Browser portlet included with Oracle WebCenter Interaction
This section describes a use case for an interactive workspace (a collaborative community).
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 WebCenter Interaction Services
This section describes a use case for a customer or partner management site (a sales and service-oriented community).
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 WebCenter Interaction Services
Oracle WebCenter Content
Oracle WebCenter Portal's Pagelet Producer
This section describes a use case for a dashboard (an analytic community).
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 WebCenter Collaboration
Oracle WebCenter Analytics
Oracle WebCenter Portal's Pagelet Producer
This section describes a use case for a business process application (a process community).
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 WebCenter Collaboration
Oracle Business Process Management
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 implement portlets.
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 (IDK) documentation.
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.
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, task lists, wikis and blogs contributed and managed by distributed teams. All items in Oracle WebCenter Collaboration 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. 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.
Tagging Service: The Tagging Service utilizes users' tags to rank content and provide more usable search results.
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 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, or partitioned, 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 Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter Interaction.
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.
|
 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
