Oracle® Fusion Middleware

Administrator's Guide for Oracle Portal

11g Release 1 (11.1.1)

E10239-07

June 2012

Oracle Fusion Middleware Administrator's Guide for Oracle Portal, 11g Release 1 (11.1.1)

E10239-07

Copyright © 2001, 2012, Oracle and/or its affiliates. All rights reserved.

Primary Author: Swati Thacker

Contributing Author: Kumar Dhanagopal

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.

This software and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.

Contents

List of Examples

List of Figures

List of Tables

Preface

- Audience

- Documentation Accessibility

- Related Documents

- Conventions

What's New in Oracle Portal?

- New Features in Oracle Portal 11g Release 1 (11.1.1)

- New Features in OracleAS Portal 10g Release 2 (10.1.4)

Part I Concepts

1 Understanding the Oracle Portal Architecture

- 1.1 Understand the Oracle Portal Components

- 1.1.1 What Are the Middle-Tier Components?

- 1.1.2 What Are the Infrastructure Components?

- 1.2 Understanding the Oracle Portal Architecture

- 1.2.1 How Does Oracle Portal Integrate with Other Components?

- 1.2.2 How Do the Pieces Fit Together?

- 1.2.2.1 How Are Pages Assembled in Oracle Portal?

- 1.2.2.2 How Does Communication Flow in Oracle Portal?

- 1.3 Understanding Caching in Oracle Portal

- 1.3.1 Understanding Oracle Web Cache

- 1.3.2 Understanding Portal Cache

- 1.3.3 Understanding Cache Invalidation in Oracle Portal

- 1.4 Understanding WSRP and JPS

- 1.5 What's Next?

2 Planning Your Oracle Portal

- 2.1 What Do I Need to Consider?

- 2.1.1 Which Topology Is Right for Me?

- 2.1.2 How Much Hardware Do I Need?

- 2.1.3 How Can I Maximize Performance?

- 2.1.4 How Can I Make My Portal Scale?

- 2.1.5 How Can I Make My Portal Highly Available?

- 2.1.6 How Can I Secure My Portal?

- 2.1.7 How Should I Configure My Hardware and Software?

- 2.1.7.1 Using a Single Computer

- 2.1.7.2 Using Multiple Computers

- 2.1.8 Getting the Most Out of Your Configuration

- 2.1.8.1 Load Balancing

- 2.1.8.2 Failover and Redundancy

- 2.1.8.3 Scalability

- 2.2 What Do I Need to Do?

- 2.2.1 Planning Your Portal

- 2.2.2 Upgrading Oracle Portal

- 2.2.3 Verifying Pre-Installation Requirements

- 2.2.4 Installing Oracle Fusion Middleware

- 2.2.5 Performing Post-Installation Configuration

- 2.2.6 Performing Advanced Configuration

- 2.2.7 Securing Oracle Portal

- 2.2.8 Monitoring Oracle Portal

- 2.2.9 Troubleshooting Oracle Portal

Part II Installation and Basic Configuration

3 Pre-Installation and Post-Installation Tasks

- 3.1 Installation Overview

- 3.1.1 WebLogic Server Installation

- 3.1.2 Infrastructure Component Installation

- 3.1.3 Oracle Fusion Middleware Middle-tier Release Installation

- 3.1.4 Installation Components and Versions

- 3.2 Accessing Oracle Portal After Installation

- 3.3 Configuring Oracle Portal During and After Installation

4 Interoperability Scenarios

5 Basic Configuration and Administration

- 5.1 Getting Started with Oracle Portal Administration

- 5.1.1 Using the Oracle Portal Administer Tab

- 5.1.2 Using Additional Administrative Tools

- 5.1.2.1 Oracle Enterprise Manager 11g Fusion Middleware Control

- 5.1.2.2 WebLogic ScriptingTool (WLST) Command-line Utility

- 5.1.2.3 Portal Installation and Configuration Scripts

- 5.2 Finding Out Information About Oracle Portal

- 5.2.1 Accessing Oracle Portal in Your Browser

- 5.2.2 Finding Your Oracle Portal Version Number

- 5.3 Performing Basic Page Administration

- 5.3.1 Setting a Default Home Page

- 5.3.1.1 Setting the System Default Home Page

- 5.3.1.2 Setting a Group's Default Home Page

- 5.3.1.3 Setting a User's Default Home Page

- 5.3.2 Setting the System Default Style

- 5.3.3 Creating Personal Pages

- 5.3.3.1 Automatically Creating a Personal Page for New Users

- 5.3.3.2 Creating a Personal Page for an Existing User

- 5.3.4 Setting the Total Space Allocated for Uploaded Files

- 5.3.5 Setting the Maximum File Size for Uploaded Files

- 5.3.6 Changing the Page Group Quota

- 5.3.7 Specifying E-mail (SMTP) Host

- 5.3.8 Specifying an Error Message Page

- 5.3.9 Specifying an Error Reporting Style

- 5.3.10 Setting the Default Page for Non-Authenticated Users

- 5.3.11 Specifying the Default DOCTYPE for Pages

- 5.3.12 Removing the Context-Sensitive Help Link

- 5.4 Configuring Self-Registration

- 5.5 Setting Up Oracle BPEL Process Definitions for Approvals

- 5.5.1 Synchronizing BPEL Workflow with Portal Workflow

- 5.5.1.1 Deploying the Call Back WebService

- 5.5.1.2 Configuring Portal for BPEL

- 5.5.2 Securing your Portal for BPEL Business Process

- 5.5.2.1 Configuring Outbond SSL to BPEL Server

- 5.5.2.2 BPEL Server Callback to Portal

- 5.5.3 Creating a New BPEL Process Definition

- 5.5.4 Editing an Existing BPEL Process Definition

- 5.5.5 Deleting an Existing BPEL Process Definition

- 5.5.6 Oracle Portal Message Schema

- 5.5.7 BPEL Callback Webservice Proxy

- 5.6 Performing Basic Portal Administration

- 5.6.1 Simplifying the Full URL of an Oracle Portal Instance

- 5.6.2 Configuring Oracle HTTP Server to Use the Oracle Portal Home Page

- 5.6.3 Stopping and Starting Portal Components Using Fusion Middleware Control

- 5.6.4 Configuring a Portal DAD Using Fusion Middleware Control

- 5.6.5 Configuring a Portal DAD Using WLST

- 5.6.5.1 Creating a Portal DAD

- 5.6.5.2 Updating Portal Dad

- 5.6.5.3 Deleting Portal DAD

- 5.6.5.4 listing a DAD

- 5.6.6 Configuring the Portal Cache Using Fusion Middleware Control

- 5.6.7 Configuring the Portal Cache Using WLST

- 5.6.8 Clearing the Portal Cache

- 5.6.9 Configuring the Portal Parallel Page Engine

- 5.6.9.1 Setting PPE Configuration Parameters

- 5.6.9.2 Configuring the Parallel Page Engine Using WLST

- 5.6.10 Retrieving the Portal Schema Password

- 5.6.11 Using a Custom Image Directory

- 5.7 Configuring Mobile Support in Oracle Portal

- 5.7.1 Installing Oracle Application Server Wireless

- 5.7.2 Patching OracleAS Single Sign-On for Oracle Portal Mobile Access

- 5.7.3 Configuring Mobile Settings in Oracle Portal

- 5.7.3.1 Enabling Mobile Access

- 5.7.3.2 Configuring Mobile Home Pages

- 5.7.3.3 Displaying Page Titles in Mobile Banner Links

- 5.7.3.4 Displaying Enhanced Page Layouts on PDAs

- 5.7.3.5 Logging Mobile Responses

- 5.7.4 Configuring Mobile Access

- 5.7.4.1 Configuring the Oracle Portal Home Page URL References

- 5.7.4.2 Configuring the OracleAS Wireless Portal Service URL Reference

- 5.7.5 Changing the Mobile Device Component of the Cache Key

- 5.8 Managing Users, Groups, and Passwords

- 5.9 Configuring Browser Settings

- 5.10 Configuring Language Support

- 5.10.1 Installing Languages After Installing Oracle Portal

- 5.10.2 Enabling the Use of Territories

- 5.11 Configuring Oracle Portal for WebDAV

- 5.11.1 Performing Basic WebDAV Configuration

- 5.11.2 Setting Up a WebDAV Client

- 5.11.3 WebDAV Clients and SSL

- 5.11.4 Checking the Version of OraDAV Drivers

- 5.11.5 Checking version of oraDAV

- 5.11.6 Viewing Errors

- 5.12 Configuring Resource Proxying

Part III Advanced Configuration Topics

6 Advanced Configuration

- 6.1 Changing Oracle Fusion Middleware Listen Ports

- 6.2 Configuring SSL

- 6.3 Configuring Multiple Middle Tiers with a Load–Balancing Router

- 6.3.1 Step 1: Install a Single Portal Middle Tier (M1)

- 6.3.2 Step 2: Configure Oracle Portal on M1 to Be Accessed Through the LBR

- 6.3.3 Step 3: Confirm That Oracle Portal is Up and Running

- 6.3.4 Step 4: Install a New Portal (M2)

- 6.3.5 Step 5: Configure the New Middle Tier (M2) to Run Your Existing Portal

- 6.3.6 Step 6: Configure Portal Tools and Web Providers (Optional)

- 6.3.7 Step 7: Enable Session Binding on Oracle Web Cache

- 6.3.8 Step 8: Confirm the Completed Configuration

- 6.4 Configuring Virtual Hosts

- 6.4.1 Create Virtual Hosts

- 6.4.1.1 Create the Virtual Host for www.xyz.com

- 6.4.1.2 Create the Virtual Host for www.abc.com

- 6.4.1.3 Verify the httpd.conf File

- 6.4.1.4 Verify That the Virtual Hosts Are Configured Correctly

- 6.4.2 Configure Oracle Web Cache

- 6.4.3 Register Oracle Portal with OracleAS Single Sign-On

- 6.4.4 Verify the Configuration

- 6.4.5 Reconfiguring Portal for a Change in the OracleAS Single Sign-On 10g Host Name

- 6.5 Configuring Oracle Portal to Use a Proxy Server

- 6.6 Configuring Oracle Portal to Work with a Reverse Proxy Server

- 6.7 Managing Oracle Portal Content Cached in Oracle Web Cache

- 6.7.1 Managing Oracle Web Cache

- 6.7.2 Configuring Portal Web Cache Settings Using Oracle Enterprise Manager

- 6.7.3 Configuring Portal Web Cache Settings Using WLST

- 6.7.3.1 Listing the Attributes

- 6.7.3.2 Updating the Attributes

- 6.7.4 Managing Portal Content Cached in Oracle Web Cache

- 6.7.4.1 Clearing the Entire Web Cache

- 6.7.4.2 Clearing the Cache for a Particular User

- 6.7.4.3 Setting the Expiry Time for Invalidation-based Caching

- 6.7.4.4 Clearing the Cache for a Particular Portal Object

- 6.7.5 Clearing the Cache Invalidation Queue Through SQL*Plus

- 6.7.6 Managing the Invalidation Message Processing Job

- 6.8 Configuring Oracle Portal to Use a Dedicated Oracle Web Cache Instance

- 6.8.1 Understanding Installation Prerequisites and Requirements

- 6.8.2 Configuring a Dedicated Oracle Web Cache

- 6.8.2.1 Task 1: Verify That the Oracle Web Cache on the Dedicated Server Is Running

- 6.8.2.2 Task 2: Configure Oracle Web Cache on the Dedicated Server

- 6.8.2.3 Task 3: Stop the Unused Oracle Web Cache on the Middle-Tier Server

- 6.8.2.4 Task 4: Configure Oracle Portal Middle Tier with Oracle Web Cache Settings

- 6.8.2.5 Task 5: Configure Virtual Host Settings for Oracle HTTP Server

- 6.8.2.6 Task 6: Re-Registering the Oracle HTTP Server Partner Application

- 6.9 Changing the Infrastructure Services Used By a Middle Tier

- 6.10 Configuring the Cluster Environment After Installation

- 6.10.1 Middle Tier Configuration

- 6.10.2 Repository Configuration

- 6.11 Configuring OracleAS Wireless

- 6.12 Changing the Oracle Portal Schema Password

- 6.12.1 Changing the Schema Password for a Default Oracle Portal Instance

- 6.12.2 Changing the Portal Credentials

- 6.12.2.1 Managing Portal Credentials Using Oracle Enterprise Manager

- 6.12.2.2 Managing Portal Credentials Using WLST Commands

- 6.12.3 Changing the Schema Password for a Nondefault Oracle Portal Instance

- 6.13 Configuring Oracle Portal Using WLST

- 6.13.1 Configuring Portal Middle Tier

- 6.13.2 Configuring Portal Site Attributes

- 6.13.3 Configuring Portal Oracle Internet Directory Attributes

- 6.13.3.1 Listing the Attributes

- 6.13.3.2 Updating the Attributes

7 Securing Oracle Portal

- 7.1 About Oracle Portal Security

- 7.1.1 Oracle Portal Security Model

- 7.1.2 Classes of Users and Their Privileges

- 7.1.2.1 Oracle Portal Default, Seeded User Accounts

- 7.1.2.2 Oracle Portal Default, Seeded Groups

- 7.1.2.3 Oracle Portal Default Schemas

- 7.1.3 Resources Protected

- 7.1.3.1 Global Privileges

- 7.1.3.2 Object Privileges

- 7.1.3.3 Granting Privileges to New Providers

- 7.1.3.4 Privileges to Edit Web Providers and Provider Groups

- 7.1.3.5 Privileges to Create and Edit WSRP Producers

- 7.1.3.6 Privileges to Edit URL and XML Portlets in the Portlet Repository

- 7.1.4 Authorization and Access Enforcement

- 7.1.5 Authorization Modification

- 7.1.5.1 Secure Network Aware Authorization Modifiers

- 7.1.5.2 Default Authorization Modifier

- 7.1.5.3 Page View and Edit Authorization Modifier

- 7.1.5.4 Defining Required Page Attributes for use with Authorization Modifiers

- 7.1.6 Leveraging Oracle Fusion Middleware Security Services

- 7.1.7 Leveraging Oracle Identity Management Infrastructure

- 7.1.7.1 Relationship Between Oracle Portal and OracleAS Single Sign-On

- 7.1.7.2 Relationship Between Oracle Portal and Oracle Access Manager

- 7.1.7.3 Relationship Between Oracle Portal and Oracle Internet Directory

- 7.1.7.4 Relationship Between Oracle Portal and Oracle Directory Integration Platform

- 7.1.7.5 Relationship Between Oracle Portal and Oracle Delegated Administration Services

- 7.1.7.6 User Portlet

- 7.1.7.7 Portal User Profile Portlet

- 7.1.7.8 Group Portlet

- 7.1.7.9 Portal Group Profile Portlet

- 7.1.7.10 Oracle Delegated Administration Services Public Roles

- 7.1.8 Configuring Dynamic Groups

- 7.1.8.1 Defining the Dynamic Group

- 7.1.8.2 Using a Dynamic Group to Secure a Page

- 7.1.9 Security for Portlets

- 7.1.9.1 Authentication

- 7.1.9.2 Authorization

- 7.1.9.3 Communication Security

- 7.1.9.4 Access Control Lists

- 7.1.9.5 Oracle Portal Server Authentication

- 7.1.9.6 Securing the Portal Tools Provider Configuration Pages

- 7.1.9.7 Single Sign-On

- 7.1.9.8 Programmatic Portlet Security

- 7.1.9.9 Message Authentication

- 7.1.9.10 HTTPS Communication

- 7.1.9.11 Configuration of SSL

- 7.1.10 Securing Access to Web Services Remote Portlets

- 7.1.10.1 Setting Up the Keystores

- 7.1.10.2 Configuring the Producer

- 7.1.11 Securing the OmniPortlet and Simple Parameter Form

- 7.1.12 Securing the Web Clipping Provider

- 7.1.12.1 Adding Certificates for Trusted Sites

- 7.1.12.2 Configuring Oracle Advanced Security for the Web Clipping Provider

- 7.1.13 Securing the Federated Portal Adapter

- 7.1.14 Securing OraDAV

- 7.1.14.1 Session Cookie Expiration

- 7.1.14.2 SSL and OraDAV

- 7.1.14.3 Encrypting a Password in MOD_ORADAV.CONF

- 7.2 Configuring Oracle Fusion Middleware Security Framework for Oracle Portal

- 7.2.1 Configuring Fusion Middleware Security Framework Options for Oracle Portal

- 7.2.2 Configuring Oracle Identity Management Options for Oracle Portal

- 7.2.2.1 Setting the Appropriate Naming and Nickname Attributes

- 7.2.2.2 Defining a Role for Oracle Portal Installers

- 7.3 Configuring Oracle Portal Security

- 7.3.1 Configuring Oracle Portal Security Options

- 7.3.1.1 Changing Settings on the Global Settings Page

- 7.3.1.2 Enforcing Role-Based Access Control

- 7.3.1.3 Configuring Provider Message Authentication

- 7.3.2 Configuring Options for Oracle Fusion Middleware Security Framework

- 7.3.2.1 Configuring SSL for Oracle Portal

- 7.3.2.2 Securing the Connection to Oracle Internet Directory (Optional)

- 7.3.2.3 Post-Installation Security Checklist

- 7.3.3 Configuring Oracle Portal Options for Database Security

8 Monitoring and Administering Oracle Portal

- 8.1 Using Oracle Enterprise Manager 11g Fusion Middleware Control

- 8.2 Using Fusion Middleware Control to Monitor and Administer Oracle Portal

- 8.2.1 Portal Home Page Overview

- 8.2.1.1 Page Response Time Portlet

- 8.2.1.2 Page Response Codes Statistics Portlet

- 8.2.1.3 Popular Producers Portlet

- 8.2.1.4 Related Components Portlet

- 8.2.1.5 Producers Portlet

- 8.2.1.6 Resource Center Portlet

- 8.2.1.7 Page Engine Statistics Portlet

- 8.2.2 Administrating and Monitoring from the Oracle Home Page

- 8.2.2.1 Performance Metrics Page

- 8.2.2.2 Performance Summary Page

- 8.2.2.3 Configure Database Access Descriptor Page

- 8.2.2.4 Portal Cache Configuration Page

- 8.2.2.5 Page Engine Configuration Page

- 8.2.2.6 Portal Wire Configuration Page

- 8.2.2.7 Logs

- 8.2.3 Topology Tab

- 8.3 Viewing Oracle Portal Activity Reports

- 8.3.1 Logged Events

- 8.3.2 Choosing Which Events Are Logged

- 8.3.3 Activity Log Views

- 8.3.4 Accessing Activity Log Views Externally

- 8.4 Viewing Oracle Fusion Middleware Port Usage

- 8.5 Defining Oracle Enterprise Manager Administration Roles

- 8.6 About the Oracle Fusion Middleware System MBean Browser

- 8.6.1 When should I use the Oracle Fusion Middleware System MBean Browser?

- 8.6.2 About Portal Configuration MBeans

9 Configuring Intranet and Internet for Oracle Portal

- 9.1 Configuring a Dedicated Intranet and Internet for Oracle Portal

- 9.1.1 Installing and Configuring the External Middle tier

- 9.1.2 Installing the First Internal Middle Tier on APPHOST3

- 9.1.3 Configuring an Oracle Web Cache Invalidation-only Cluster

- 9.1.3.1 Preparing the Network Environment for the Oracle Web Cache Invalidation-only Cluster

- 9.1.3.2 Configuring the Caches

- 9.1.3.3 Disabling External to Internal Communication Through the Firewall

- 9.1.4 Configuring the First internal Middle Tier on APPHOST3 for Load Balancing Router

- 9.1.5 Registering the Internal Middle Tier as a Partner Application

- 9.1.6 Changing Host Assertion in WebLogic

- 9.1.6.1 Validate the Configuration

- 9.1.7 Installing the Second Internal Middle Tier on APPHOST4

- 9.1.8 Configuring an Oracle Web Cache Invalidation-only Cluster

- 9.1.9 Configuring the Second Internal Middle Tier on APPHOST4 for Load Balancing Router

- 9.1.10 Configure Web Cache

- 9.1.11 Configuring the Oracle Portal Schema in the Oracle Metadata Repository

- 9.1.12 Validating the Completed Configuration

- 9.2 Upgrading Oracle Portal 10g Intranet-Internet setup to 11g

- 9.2.1 Installing and Upgrading the External Middle Tier

- 9.2.2 Post Upgrade Configuration of the External Middle tier

- 9.2.3 Installing and Upgrading the First Internal Middle Tier on APPHOST3

- 9.2.4 Post Upgrade Configuration of the First Internal Middle Tier on APPHOST3

- 9.2.5 Installing and Upgrading the Second Middle Tier on APPHOST4

- 9.2.6 Post Upgrade Configuration of the Second Internal Middle Tier on APPHOST4

- 9.2.7 Validating the Configuration

10 Configuring the Search Features in Oracle Portal

- 10.1 Search Options in Oracle Portal

- 10.1.1 Oracle Portal Search

- 10.1.2 Oracle Secure Enterprise Search

- 10.1.3 Default Search Functionality

- 10.1.4 Deciding Which Search Options to Use

- 10.1.5 Differences Between Oracle Secure Enterprise Search and Oracle Portal Search

- 10.2 Configuring Oracle Portal Search Options

- 10.2.1 Configuring Oracle Portal Search Portlets

- 10.2.1.1 Choosing Search Result Pages

- 10.2.1.2 Limiting the Number of Search Results on a Page

- 10.2.1.3 Choosing an Advanced Search Link (Basic/Custom Search Portlets)

- 10.2.1.4 Choosing an Internet Search Engine (Advanced/Custom Search Portlets)

- 10.2.2 Configuring Oracle Text Options in Oracle Portal

- 10.2.2.1 Enabling and Disabling Oracle Text in Oracle Portal

- 10.2.2.2 Setting Oracle Text Search Result Options

- 10.2.2.3 Setting a Base URL for Oracle Text

- 10.2.2.4 Configuring Proxy Settings for Oracle Text

- 10.2.3 Configuring Oracle Secure Enterprise Search Options in Oracle Portal

- 10.3 Oracle Text

- 10.3.1 Understanding Oracle Portal Searches with Oracle Text Enabled/Disabled

- 10.3.1.1 Searching With Oracle Text Disabled

- 10.3.1.2 Searching With Oracle Text Enabled

- 10.3.2 Oracle Text Prerequisites

- 10.3.3 Oracle Text Indexes

- 10.3.3.1 Oracle Text Index Overview

- 10.3.3.2 Oracle Text Index Preferences

- 10.3.3.3 Datastore Procedures

- 10.3.3.4 Granting CTXAPP Role to the Oracle Portal Schema

- 10.3.3.5 Multilingual Functionality (Multilexer)

- 10.3.3.6 STEM Searching

- 10.3.3.7 Maximizing AUTO_FILTER Performance

- 10.3.4 Creating and Dropping Oracle Text Indexes

- 10.3.4.1 Creating All Oracle Text Indexes Using ctxcrind.sql

- 10.3.4.2 Creating a Single Oracle Text Index

- 10.3.4.3 Dropping All Oracle Text Indexes Using ctxdrind.sql

- 10.3.4.4 Dropping a Single Oracle Text Index

- 10.3.5 Maintaining Oracle Text Indexes

- 10.3.5.1 Synchronizing Oracle Text Indexes

- 10.3.5.2 Synchronizing an Oracle Text Index On Commit

- 10.3.5.3 Synchronizing All Oracle Text Indexes Manually

- 10.3.5.4 Scheduling Index Synchronization

- 10.3.5.5 Deciding How Often to Synchronize Oracle Text Indexes

- 10.3.5.6 Synchronizing All the Index Content

- 10.3.5.7 Optimizing Oracle Text Indexes

- 10.3.5.8 Scheduling Index Optimization

- 10.3.5.9 Choosing the Optimization Interval

- 10.3.6 Indexing and Searching URL Content

- 10.3.6.1 Relative URLs

- 10.3.6.2 Unsupported URLs

- 10.3.6.3 Supported URLs

- 10.3.6.4 URL Index Proxy Settings

- 10.3.7 Disabling Document and URL Indexing

- 10.3.8 Viewing the Status of Oracle Text Indexes

- 10.3.9 Monitoring Oracle Text Indexing Operations

- 10.3.9.1 Using start_log to Monitor Index Operations

- 10.3.9.2 Using logcrind.sql to Monitor Index Creation

- 10.3.10 Viewing Indexing Errors

- 10.3.11 Translating Indexing Errors to Objects in Oracle Portal

- 10.3.11.1 Item Indexing Errors

- 10.3.11.2 Page Indexing Errors

- 10.3.11.3 Category Index Errors

- 10.3.11.4 Perspective Indexing Errors

- 10.3.11.5 Document Index Errors

- 10.3.11.6 URL Index Errors

- 10.3.12 Common Indexing Errors

- 10.3.12.1 Common Document Indexing Errors

- 10.3.12.2 Common URL Indexing Errors

- 10.3.13 Handling Indexing Hangs or Crashes

- 10.3.13.1 Identifying Whether an Index Operation is Hanging

- 10.3.13.2 Preventing Indexes From Hanging and Crashing

- 10.4 Oracle Secure Enterprise Search

- 10.4.1 Oracle Secure Enterprise Search Overview

- 10.4.1.1 About the Oracle Secure Enterprise Search Sample Query Applications

- 10.4.1.2 About Oracle Secure Enterprise Search Configuration

- 10.4.2 Oracle Secure Enterprise Search Secure Portlet

11 Tuning Performance in Oracle Portal

- 11.1 Setting the Number of Server Processes

- 11.2 Setting the Number of Idle Processes

- 11.3 Setting the Number of PPE Fetchers

- 11.4 Tuning the Oracle HTTP Server

- 11.5 Tuning File System Cache to Improve Caching Performance

- 11.6 Tuning Oracle Net Services

12 Exporting and Importing Content

- 12.1 Introduction Oracle Portal Export or Import

- 12.2 Before You Begin

- 12.2.1 System Requirements

- 12.2.2 Additional Considerations

- 12.2.3 Privileges for Exporting and Importing Content

- 12.3 Examples of Using Export and Import

- 12.3.1 Case1: Exporting/Importing Between Development and Production Instances

- 12.3.2 Case 2: Deploying Identical Content Across Multiple Portal Instances

- 12.3.3 Case 3: Consolidating Content from Multiple Sources

- 12.4 Export in Oracle Portal

- 12.4.1 Oracle Portal Export - Recommended Method

- 12.4.1.1 How Does Oracle Portal Export Work?

- 12.4.1.2 How Do I Manage My Transport Sets?

- 12.4.2 Oracle Portal Export - Alternate Method

- 12.5 Acquire Transport Set Services

- 12.5.1 Register a Source Portal

- 12.5.2 Moving Data to the Target System

- 12.6 Import in Oracle Portal

- 12.6.1 Oracle Portal Import - Recommended Method

- 12.6.1.1 Creating a Database Link

- 12.6.1.2 Importing Data

- 12.6.1.3 How Do I Manage My Transport Sets (Import)?

- 12.7 Using the Oracle Portal Export and Import Command-line Scripts

- 12.7.1 Downloading the Command-line Scripts

- 12.7.2 Running Your Script to Create an Export Dum File

- 12.7.3 Importing the Transport Set Tables to the Target System

- 12.8 Behavior of Objects After Migration

- 12.8.1 Behavior of Oracle Portal Objects

- 12.8.1.1 Page Groups

- 12.8.1.2 Attributes

- 12.8.1.3 Approvals

- 12.8.1.4 Items

- 12.8.1.5 Pages

- 12.8.1.6 Regions

- 12.8.1.7 Portal Templates

- 12.8.1.8 HTML Templates

- 12.8.1.9 Categories

- 12.8.1.10 Perspectives

- 12.8.1.11 Navigation Pages

- 12.8.1.12 Styles

- 12.8.1.13 Item Types

- 12.8.1.14 Page Types

- 12.8.2 Import Behavior of Child Objects

- 12.8.3 Behavior of DB Provider Objects

- 12.8.3.1 Seeded DB Providers

- 12.8.3.2 Portal DB Providers

- 12.8.3.3 Portal DB Provider Components

- 12.8.3.4 Shared Components

- 12.8.3.5 Registered Database Providers

- 12.8.4 Behavior of Portal DB Provider Reports Object Types

- 12.8.5 Behavior of Web Providers

- 12.8.5.1 OmniPortlet

- 12.8.5.2 Web Clipping Providers, WSRP Producers, and Other Web Providers

- 12.8.6 Behavior of Shared Portlet Instances

- 12.9 Recommended Best Practices When Exporting and Importing

- 12.9.1 Naming Convention for Replicated Tabs

- 12.9.2 Migrating Page Groups and Components

- 12.9.3 Migrating Portal DB Providers and Components

- 12.9.4 Migrating Search Components

- 12.9.4.1 Basic and Advanced Search Portlets

- 12.9.4.2 Custom Search Portlets

- 12.9.5 Migrating Content Between Upgraded Oracle Portal Instances

- 12.9.6 Exporting and Importing in a Hosted Environment

- 12.9.7 Importing Data with Oracle Text Index Synchronization Turned Off

- 12.9.8 Migrating Users and Groups

13 Using the Federated Portal Adapter

- 13.1 About the Federated Portal Adapter

- 13.1.1 Overview

- 13.1.2 Differences Between Database Providers and Web Providers

- 13.1.3 Use of the Federated Portal Adapter

- 13.1.4 Security Issues

- 13.1.5 Federated Portal Adapter Related Portlet Modifications

- 13.2 Setting Up the Environment to Use the Federated Portal Adapter

- 13.2.1 Checking the PlsqlSessionCookieName Value

- 13.2.2 Federated Portal Adapter User Authentication Using HMAC

- 13.2.3 Setting the Cookie Domain

- 13.2.4 Sharing an OracleAS Single Sign-On and an Oracle Internet Directory Server

- 13.3 Registering a Provider Using the Federated Portal Adapter

- 13.4 Writing Custom Portlets Using the Federated Portal Adapter

- 13.4.1 Relative Links

- 13.4.2 Personalization

- 13.5 Troubleshooting Federated Portal Adapter

Part IV Appendixes

A Using Oracle Fusion Middleware Configuration Files

- A.1 Oracle HTTP Server Configuration File (httpd.conf)

- A.2 DAD Configuration File (portal_dads.conf)

- A.3 Oracle Database Connection Configuration

- A.4 Web Cache Configuration Files

- A.5 OracleAS Single Sign-On's Partner Application Table

- A.6 Local HOSTS File

B Using Oracle Portal Installation and Configuration Scripts

- B.1 Managing the Invalidation Message Processing Job Using cachjsub.sql

- B.2 Configuring for IP Check During Session Cookie Validation

- B.3 Using the secupoid.sql Script

- B.4 Configuring the Portal Session Cookie

- B.4.1 Configuring the Cookie Name

- B.4.2 Configuring the Scope of the Cookie

- B.4.3 Securing the Cookie

- B.5 Managing the Session Cleanup Job

- B.6 Timing and Caching Statistics

- B.6.1 Portlet Statistics

- B.6.1.1 Portlet Timing Information

- B.6.1.2 Portlet Caching Information

- B.6.2 Page Statistics

- B.6.3 Additional Summary Statistics

- B.7 Using the cfgiasw Script to Configure Mobile Settings

- B.8 Using the cfgxodnc.pl Script to Change the Mobile Device Component of the Cache Key

- B.8.1 Adding the PlsqlCGIEnvironmentList Parameter to the portal_dads.conf File

- B.8.2 Running the cfgxodnc.pl script

- B.8.3 Adding the useDeviceNameCacheKeys parameter to the PPE Configuration file

- B.8.4 Clearing Cached Data

- B.9 Using the Category and Perspective Scripts

- B.10 Using the PDK-Java Preference Store Migration and Upgrade Utility

- B.11 Using the Schema Validation Utility

- B.11.1 Using the Schema Validation Utility with Oracle Portal Export and Import

- B.11.2 Using the Standalone Schema Validation Utility

C Integrating JavaServer Pages with Oracle Portal

- C.1 Using the JavaServer Page Configuration File

- C.1.1 Contents of Your JavaServer Page Configuration File

- C.1.1.1 The <jps> Tag

- C.1.1.2 The <portal> Tag

- C.1.1.3 The <database> Tag

- C.1.1.4 The <url> Tag

- C.1.1.5 The <cookie> Tag

- C.1.1.6 The <pageGroups> Tag

- C.1.1.7 The <pageGroup> Tag

- C.1.2 Example JavaServer Page Configuration File

- C.1.3 Location of Your JavaServer Page Configuration File

- C.1.4 External JavaServer Page Login

- C.2 Setting Up a JAZN File for External Communication

- C.2.1 Setting Up mod_osso

- C.2.2 Setting Up JAZN with LDAP

D Using the wwv_context APIs

- D.1 Procedures

- D.1.1 add_attribute_section

- D.1.2 commit_sync

- D.1.3 create_index

- D.1.4 create_missing_indexes

- D.1.5 create_prefs

- D.1.6 createindex

- D.1.7 drop_all_indexes

- D.1.8 drop_index

- D.1.9 drop_invalid_indexes

- D.1.10 drop_prefs

- D.1.11 dropindex

- D.1.12 optimize

- D.1.13 set_parallel_degree

- D.1.14 set_sync_memory

- D.1.15 set_use_doc_index

- D.1.16 set_use_url_index

- D.1.17 sync

- D.1.18 touch_index(p_indexes wwsbr_array)

- D.1.19 touch_index

- D.1.20 update_index_prefs

- D.2 Functions

- D.2.1 checkindex

- D.2.2 doc_index

- D.2.3 get_commit_sync

- D.2.4 get_parallel_degree

- D.2.5 get_sync_memory

- D.2.6 get_use_doc_index

- D.2.7 get_use_url_index

- D.2.8 valid_doc_index

- D.2.9 valid_url_index

- D.2.10 url_index

- D.3 Constants

- D.3.1 Index Name Constants

- D.3.2 Oracle Text AUTO_FILTER Format Constants

- D.3.3 Oracle Text Job Constants

- D.3.4 URL Unsuitable for Indexing Constant

- D.4 Exceptions

E Configuring the Portal Tools Providers

- E.1 Configuring Web Clipping

- E.1.1 Configuring the Web Clipping Repository

- E.1.2 Registering the Web Clipping Provider (PDK Only)

- E.1.3 Configuring HTTP or HTTPS Proxy Settings

- E.1.3.1 Restricting Users from Clipping Content from Unauthorized External Web Sites

- E.1.4 Configuring Caching

- E.1.4.1 Configuring Caching

- E.2 Configuring OmniPortlet

- E.2.1 Configuring the OmniPortlet Provider

- E.2.1.1 Configuring HTTP or HTTPS Proxy Settings

- E.2.1.2 Configuring the Secured Data Repository (PDK only)

- E.2.1.3 Configuring Caching (PDK Only)

- E.2.1.4 Configuring OmniPortlet to Access HTTPS URLs

- E.2.2 Performing Optional OmniPortlet Configurations

- E.2.3 Registering the OmniPortlet Provider (PDK Only)

- E.2.4 Configuring the OmniPortlet Provider to Access Other Relational Databases Using DataDirect JDBC Drivers

- E.2.4.1 Installing DataDirect JDBC Drivers

- E.2.4.2 Registering DataDirect Drivers in OmniPortlet

F Setting Up and Maintaining a Virtual Private Portal

- F.1 Overview of Hosting

- F.1.1 Why Use Hosting?

- F.1.2 Known Limitations

- F.2 Overview of Steps to Perform for Virtual Private Portals

- F.2.1 Enabling Hosting

- F.2.2 Setting Up Users and Groups

- F.2.3 Adding Subscribers

- F.2.4 Removing Subscribers

- F.2.5 Advanced Features

- F.2.6 Pre-Installation Checklist

- F.2.7 Using Oracle Directory Manager

- F.3 Enabling Hosting on an Out-of-the-Box Portal

- F.4 ASP Users And Groups

- F.4.1 Setting Up ASP Users and Groups

- F.4.2 Restrictions

- F.5 Adding Subscribers

- F.6 Advanced Operations on a Virtual Private Portal

- F.6.1 Managing ASP Users and Groups

- F.6.1.1 Password Sync

- F.6.1.2 Delta (Structure Changes) Sync

- F.6.1.3 Complete Sync

- F.6.2 Removing Subscribers

- F.6.3 Using WebDAV in the Virtual Private Portal

- F.6.4 Setting Up Directory Integration Platform for the Virtual Private Portal

- F.6.5 Partially Prepare (Pre-Cook) Subscribers

- F.7 Restrictions

- F.7.1 Scripts

- F.7.2 ASP Users/Groups Support

- F.7.3 Add Subscriber

- F.7.4 Remove Subscriber

- F.7.5 Upgrade

- F.8 Parameters for the Scripts

G Troubleshooting Oracle Portal

- G.1 Problems and Solutions

- G.1.1 Unable to Access Oracle Portal

- G.1.2 Unable to Log In to Oracle Portal

- G.1.3 Problems Creating Category or Perspective Pages

- G.1.4 Problems with Network Address Translation (NAT) Setup

- G.1.5 User and Group Information in Oracle Portal and Oracle Internet Directory Does Not Match

- G.1.6 Problems with Oracle Portal Performance

- G.1.7 Error When Creating Web Folders

- G.1.8 Create New Users and Create New Groups Portlets Do Not Appear

- G.1.9 ORA-2000x Errors in the error_log File

- G.1.10 Remote Web Providers Time Out in a Dynamic DNS Environment

- G.1.11 Problems Related to Memory-Intense Operations

- G.1.12 Unable to Create Oracle Text Indexes

- G.1.13 Problems with MultiLanguage Support for Help

- G.1.14 Stale Style-Sheet Data Is Displayed on Portal Pages

- G.1.15 Stale Content Is Displayed on Portal Pages

- G.1.16 Images Are Not Displayed on Portal Pages

- G.1.17 Unhandled Exception Errors

- G.1.18 Problems in Configuring the OmniPortlet Provider

- G.1.19 Problems in Configuring Oracle Web Cache for the OmniPortlet Provider

- G.1.20 Problems in Accessing Oracle Portal from a Mobile Device

- G.1.21 Error During Export and Import After Upgrading from Oracle Portal 3.0.9 or 9.0.4

- G.1.22 Errors Displayed When the Oracle Portal Language is Traditional Chinese

- G.1.23 Uploaded Content Is Not Returned in Search

- G.2 Diagnosing Oracle Portal Problems

- G.2.1 Enabling ECID Logging

- G.2.2 Generating Trace Files

- G.2.2.1 Using PlsqlBeforeProcedure and PlsqlAfterProcedure

- G.2.2.2 Setting the sql_trace Parameter

- G.2.2.3 Setting Database Event 10046

- G.2.3 Viewing the Diagnostic Output of Components

- G.2.3.1 JPDK

- G.2.3.2 Portal Services

- G.2.3.3 Parallel Page Engine

- G.2.3.4 Oracle Fusion Middleware Portal Developer Kit

- G.2.3.5 Oracle Metadata Repository

- G.2.3.6 Oracle Web Cache

- G.2.4 Using Fusion Middleware Control Log Viewer

- G.2.5 Using Oracle Portal Diagnostics Assistant

- G.2.6 Analyzing Mobile-Related Problems in Oracle Portal

- G.2.7 Enabling Performance Logging

- G.3 Need More Help?

Index

List of Examples

- 5-1 Registering the Wallet

- 5-2 Sample Oracle Portal Message Schema

- 5-3 Reject Callback Webservice

- 5-4 Approve Callback Webservice

- 5-5 Creating a Portal DAD

- 5-6 Updating the Portal DAD Attributes

- 5-7 Deleting the Portal DAD Entry from the Portal_dads.conf File

- 5-8 Listing the Various DADs in the domain

- 5-9 Configuring the Portal Cache

- 5-10 Updating the Parallel Page Engine

- 5-11 Configuration Parameters for Portal Access

- 7-1 Defining a Dynamic Group

- 7-2 Adding a JNDI Environment Variable Definition to web.xml

- 7-3 Defining JNDI Environment Variables for Multiple Provider Instances in web.xml

- 7-4 Updated Wallet Path

- 7-5 Registering the Wallet

- 7-6 Registering the Wallet

- 7-7 Certificate Registration in the Database

- 7-8 Certificate Registration in the Portal Midtier WLS

- 7-9 Sample File Containing a List of Certificates

- 9-1 ssoreg Usage on UNIX

- 12-1 Importing Content into Multiple Subscriptions

- 13-1 Setting the HMAC Keys:

- A-1 httpd.conf

- A-2 portal_dads.conf

- B-1 Caching Information Debug Output 1

- B-2 Caching Information Debug Output 2

- B-3 Caching Information Debug Output 3

- B-4 Caching Information Debug Output 4

- C-1 Example JavaServer Page Configuration File

- F-1 Scenario 1 - Administering Many Subscribers

- F-2 Scenario 2 - Upgrading

List of Figures

- 1-1 Components of the Portal Architecture

- 1-2 The Middle-Tier Components

- 1-3 The Infrastructure Tier Components

- 1-4 Portal Page Request Flow

- 1-5 Communication Flow and Protocols

- 1-6 Adding Oracle Web Cache to a Medium to Large Portal Configuration

- 2-1 Oracle Portal Single Computer Configuration

- 2-2 Separating the Fusion Middleware Middle Tier from the Infrastructure

- 2-3 Oracle Identity Management Installed on a Separate Computer

- 2-4 Multiple Middle Tiers

- 2-5 Multiple Server Configuration Using a Load Balancing Router

- 2-6 My Oracle.com Middle-Tier Configuration

- 3-1 Login Link

- 5-1 The Administer Tab on the Portal Builder Page

- 5-2 Sample PDA Page Layout

- 5-3 The Set Language Portlet

- 6-1 Multiple Middle-Tier Configuration with a Load Balancing Router

- 6-2 Installation of Oracle Portal Middle Tier

- 6-3 Oracle Portal Being Accessed Through the LBR

- 6-4 Virtual Host Overview

- 6-5 Reverse Proxy Server Configuration

- 6-6 Oracle Portal Using a Dedicated Oracle Web Cache Instance

- 7-1 Oracle Portal Security Architecture

- 7-2 N-Tier Authentication By User Proxy

- 7-3 Shared Objects

- 7-4 Create Attribute

- 7-5 Edit Page Type

- 7-6 Page Type

- 7-7 Oracle Portal DIT Structure

- 7-8 DIT Structure for Oracle Portal Groups

- 7-9 Oracle Directory Integration Platform Synchronization

- 7-10 Relationship between Oracle Delegated Administration Services, mod_osso, and OracleAS Single Sign-On

- 7-11 User Portlet

- 7-12 Portal User Profile Portlet

- 7-13 Group Portlet

- 7-14 Portal Group Profile Portlet

- 7-15 Create Group Page

- 7-16 Privilege Assignment Section of the Create Group Page

- 7-17 Administration Privileges Section of the Edit Group Profile Page

- 7-18 Configure Roles Page

- 7-19 Secured Connection to OracleAS Single Sign-On

- 7-20 Secured Connection to Oracle Web Cache

- 7-21 Secured Connections Throughout the System

- 7-22 External SSL Only

- 8-1 Oracle Fusion Middleware Control - Oracle Portal Home Page

- 8-2 Page Response Time Portlet

- 8-3 Page Response Codes Statistics Portlet

- 8-4 Popular Producers Portlet

- 8-5 Producers Portlet

- 8-6 Resource Center Portlet

- 8-7 Page Engine Statistics Portlet

- 8-8 Oracle Fusion Middleware - Metrics Page

- 8-9 Oracle Fusion Middleware - Cache Metrics Tab

- 8-10 Oracle Fusion Middleware - Repository Metrics Tab

- 8-11 Oracle Fusion Middleware - Producer Metrics Tab

- 8-12 Oracle Fusion Middleware - Producer Metrics Tab

- 8-13 Oracle Fusion Middleware - Performance Summary Page

- 8-14 Time Range Selection Bar

- 8-15 Metric Palette

- 8-16 Oracle Fusion Middleware Control - Configure Database Access Descriptor Page

- 8-17 Oracle Fusion Middleware Control - Edit Database Access Descriptor Page

- 8-18 Fusion Middleware Control - Portal Web Cache Settings

- 8-19 Oracle Fusion Middleware Control - Portal Parallel Page Engine Settings

- 8-20 Oracle Fusion Middleware Control - Log Messages Page

- 8-21 Log Configuration Page

- 8-22 Administer Log Registry Page

- 8-23 Edit Log Registry Record page

- 8-24 Oracle Fusion Middleware Ports Page

- 10-1 Oracle Portal Basic Search Portlet

- 10-2 Oracle Portal Basic Search Results Page

- 10-3 Oracle Portal Advanced Search Portlet

- 10-4 Oracle Portal Custom Search Portlet

- 10-5 Oracle Portal Search Results Page

- 10-6 Oracle Portal Saved Searches Portlet

- 10-7 Hits per Page Setting on Search Portlets

- 10-8 Advanced Search Link on Basic/Custom Search Portlets

- 10-9 Internet Search Engine Link on Advanced/Custom Search Portlets

- 12-1 Export Process

- 12-2 Transport Set Manifest

- 12-3 Detailed Manifest Screen

- 12-4 Portal Navigator

- 12-5 Transport Set Manager

- 12-6 Transport Set Manager Objects

- 12-7 Export Log and Download Scripts Page

- 12-8 Transport Set Export Log

- 12-9 Export Transport Set Portlet

- 12-10 Browse Transport Sets for Export

- 12-11 Register a Source Portal Page

- 12-12 Acquire a Transport Set

- 12-13 Transport Set Manager Import Objects

- 12-14 Transport Set Manager Import Log

- 12-15 Import Transport Set Page

- 12-16 Import Transport Set Portlet

- 12-17 Browse Transport Sets for Import

- 12-18 Import Process

- 12-19 Import Process

- B-1 Portal Page Running in Debug Mode

- E-1 Invalidation-Based Caching Provided by Oracle Web Cache

- F-1 Oracle Internet Directory Tree Before Running the Script

- F-2 Oracle Internet Directory Tree After Running the Script

- F-3 Oracle Internet Directory Tree with Users and Groups

- F-4 Membership Structure of Acme Users and Groups

- F-5 CompanyA in Both Portal and Oracle Internet Directory

- G-1 HTTP Server Status

- G-2 Request Flow with ECID Generation and Propagation

- G-3 PDK Logging Page

- G-4 Log Entries in the PDK Logging Page

List of Tables

- 3-1 Installation Components and Version

- 3-2 Portal URL Descriptions

- 5-1 Portlets in the Portal Subtab

- 5-2 Portlets in the Portlets Subtab

- 5-3 Portlets in the Database Subtab

- 5-4 Message Payload Details

- 5-5 Database Access Descriptor Commands for Portal WLST Configuration

- 5-6 Parallel Page Engine (PPE) Parameters

- 5-7 ProviderHeaders Parameter

- 5-8 PDA Display Options

- 5-9 Oracle Portal Languages and Language Abbreviations

- 5-10 ptllang Parameters

- 6-1 Additional Information

- 6-2 Virtual Host Information

- 6-3 Virtual Host Information

- 7-1 Default Oracle Portal User

- 7-2 Default Oracle Portal Groups

- 7-3 Default Oracle Portal Schemas

- 7-4 Page Group Privileges

- 7-5 Portal DB Provider Privileges

- 7-6 Administration Privileges

- 7-7 Oracle Portal Objects with Privilege Control

- 7-8 Global Privilege Codes for provideruiacls.xml

- 7-9 Object Privilege Codes for provideruiacl.xml

- 7-10 Attribute Values for Providers and Portlets

- 7-11 Authorization Modifiers Packages

- 7-12 Oracle Internet Directory Features Not Supported in Oracle Portal

- 7-13 inetOrgPerson Attributes

- 7-14 orclUserV2 Attributes

- 7-15 groupOfUniqueNames/groupOfNames Attributes

- 7-16 orclGroup Attributes

- 7-17 Directory Synchronized Events Handled By Oracle Portal

- 7-18 WSRP Producer Key Store Connection Parameters

- 7-19 Shared Library Path Environment Variable

- 7-20 Synchronization Setting Comparison

- 7-21 Relative Order of the Elements In web.xml

- 7-22 Sample Values for Fields in the Certificate Request Dialog

- 7-23 Site-to-Server Mapping

- 8-1 DAD Settings

- 8-2 Portal Cache Settings

- 8-3 Portal Parallel Page Engine Settings

- 8-4 Logged Events for Oracle Portal Objects

- 8-5 Activity Log Views

- 8-6 Portal Configuration MBeans

- 9-1 Communication Path and Ports Used by Network Packets

- 10-1 Default Search Settings

- 10-2 Oracle Portal Search Options

- 10-3 Oracle Text Indexes In the Oracle Portal Schema

- 10-4 Recommended Synchronization Schedule for Oracle Text Indexes on Oracle Database 11g

- 12-1 Export User Privileges

- 12-2 Import User Privileges

- 12-3 Default Modes

- 12-4 OPEASST.CSH Parameter Descriptions

- 12-5 Database Connection Information

- 12-6 Database Link Syntax

- 12-7 Status Descriptions

- 12-8 Warning and Failure Types

- 12-9 Cascade Warning Behavior

- 12-10 Parameter Descriptions

- 12-11 Import Behavior of Regions in Overwrite Mode

- 12-12 Import Behavior of Child Objects

- 12-13 Behavior of Shared Portlet Instances During Migration

- 13-1 Use of the Federated Portal Adapter

- 13-2 SQL Scripts for Maintaining the Key Store

- B-1 Enabling and Disabling the IP Check

- B-2 ctxjsub Parameters

- B-3 _debug Values for Timing and Caching Statistics

- B-4 Oracle Application Server Wireless Configuration Parameters

- B-5 The cfgxodnc Script Parameters

- B-6 Upgrade Modes in Which to Run the Utility

- B-7 Migration Modes in Which to Run the Utility

- C-1 The <portal> Tag's Attributes

- C-2 The <url> Tag's Attributes

- C-3 The <cookie> Tag's Attributes

- C-4 The <pageGroup> Tag's Attributes

- E-1 The Web Clipping Repository Settings

- E-2 The Web Clipping Provider Registration Settings

- E-3 The Web Clipping Provider Proxy Settings

- E-4 The OmniPortlet Provider Proxy Settings

- E-5 The OmniPortlet Provider Registration Settings

- E-6 Parameters in the driverInfo Property

- E-7 Parameters and Values for driverClassName and dataSourceClassName

- F-1 Parameters

- F-2 enblhstg.csh

- F-3 addsub.csh

- F-4 rmsub.csh

- F-5 syncasp.csh

- F-6 embldip.csh

- G-1 Trace Levels

- G-2 Logging Levels

- G-3 JPDK Standard Message Attributes

- G-4 Logging Levels and Description

- G-5 PPE Request Log Levels

- G-6 PPE urlDebugMode Levels

- G-7 PPE Standard Message Attributes

- G-8 PDK Log Levels

- G-9 CREATE DIRECTORY Parameters

- G-10 Repository Logging Package Parameters

- G-11 Repository Context Attributes

- G-12 Oracle Portal Diagnostics Assistant Script Parameters

- G-13 Error Log Files and Locations

Preface

This guide describes how to configure Oracle Portal. This includes how to plan, upgrade, check pre-installation requirements, and perform post-installation tasks. This guide further explains some more advanced Portal deployments, and explains how to perform the advanced configuration required for these deployments. This guide also provides information about monitoring and troubleshooting.

Note:

For the portable document format (PDF) version of this manual, when a URL breaks onto two lines, the full URL data is not sent to the browser when you click it. To get to the correct target of any URL included in the PDF, copy and paste the URL into your browser's address field. In the HTML version of this manual, you can click a link to directly display its target in your browser.

Audience

This guide is intended for two kinds of users:

- Oracle Portal administrators, who are responsible for configuring and maintaining Oracle Portal.

- Oracle Fusion Middleware administrators, who must configure Oracle Portal to work with other Oracle Fusion Middleware components.

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/us/corporate/accessibility/index.html.

Access to Oracle Support

Oracle customers have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/support/contact.html or visit http://www.oracle.com/accessibility/support.html if you are hearing impaired.

Related Documents

For more information, see the following related documentation available in the Oracle Fusion Middleware documentation library:

- Oracle Fusion Middleware Developer's Guide for Oracle Portal

- Oracle Fusion Middleware User's Guide for Oracle Portal

Note:

A complete glossary of Oracle Portal-related terminology can be found in the Oracle Fusion Middleware User's Guide for Oracle Portal.

- Oracle Fusion Middleware Concepts

- Oracle Fusion Middleware Administrator's Guide

- Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server

- Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache

- Oracle Application Server Single Sign-On Administrator's Guide

- Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory

- Oracle Fusion Middleware Upgrade Guide for Oracle Portal, Forms, Reports, and Discoverer

- Oracle Fusion Middleware Upgrade Planning Guide

- Oracle Fusion Middleware Release Notes for Microsoft Windows (32-Bit)

- Oracle Fusion Middleware Release Notes for Linux x86

Conventions

The following text conventions are used in this document:

Convention

Meaning

boldface

Boldface type indicates graphical user interface elements associated with an action, or terms defined in text or the glossary.

italic

Italic type indicates book titles, emphasis, or placeholder variables for which you supply particular values.

monospace

Monospace type indicates commands within a paragraph, URLs, code in examples, text that appears on the screen, or text that you enter.

CAPITALIZED

Capitalized text indicates procedure names.

< >

Angle brackets enclose user-supplied information.

[ ]

Brackets enclose optional clauses from which you can choose one or none.

.

.

.

Vertical ellipsis points in an example mean that information not directly related to the example has been omitted.

What's New in Oracle Portal?

This chapter provides a brief description of features introduced with the latest and previous releases of Oracle Portal and provides pointers to additional information, this chapter includes the following section:

- New Features in Oracle Portal 11g Release 1 (11.1.1)

- New Features in OracleAS Portal 10g Release 2 (10.1.4)

New Features in Oracle Portal 11g Release 1 (11.1.1)

The new features of Oracle Portal 11g Release 1 (11.1.1) include:

- Oracle Portal Runs on Oracle WebLogic Server

- Support for WS-Security

- Support for New HTML Document Type Declarations (Doctypes)

- Optimization of Oracle Internet Directory Integration

- Identity Management Integration

- Integration with Oracle Secure Enterprise Search

- Oracle Enterprise Manager Fusion Middleware Control

- Improved Export/Import Utilities

- Integration with Oracle Fusion Middleware

- Support for Content Approvals Using BPEL

- Improved Integration with Oracle Applications

- Capability to integrate Oracle WebCenter Portal: Services into Oracle Portal

- Use of Oracle JSF Portlet Bridge to portletize JSF applications and integrate them into Oracle Portal

- Content Integration

- Improved Access to Oracle Portal Management Content

- OmniPortlet Enhancements

- Support for New Industry Standards

Oracle Portal Runs on Oracle WebLogic Server

Oracle Portal, originally shipped as part of Oracle Application Server in previous releases, now runs on Oracle WebLogic Server 11gR1 (10.3.3).

Support for WS-Security

With this enhancement, an administrator can secure a WSRP producer with WS-Security (For example: SAML, UserTaken, and so on.), and select an appropriate token type to use for identity propagation.

Support for New HTML Document Type Declarations (Doctypes)

A new portal configuration setting allows you to specify the HTML output type generated by Oracle Portal. In addition to HTML 4.01 Transitional, three new doctypes are supported: HTML 4.01 Strict, XHTML 1.0 Transitional, and XHTML 1.0 Strict.

Optimization of Oracle Internet Directory Integration

These security enhancements let you adjust for login performance, and specify how soon the effects of provisioning changes in groups affect user authorizations.

Identity Management Integration

This enhancement lets you define a dynamic group in Oracle Internet Directory, add a user as a member, and secure a page by assigning appropriate access rights to the dynamic group. Whatever changes to the group's rights or the user's membership in the group are then reflected in the user's ability to access the page.

Integration with Oracle Secure Enterprise Search

Secure Enterprise Search (SES) provides the ability to search public and private portal content as well as external repositories (and replaces UltraSearch).

Oracle Enterprise Manager Fusion Middleware Control

Oracle Portal 11g Release 1 (11.1.1) includes integration with Oracle Enterprise Manger Fusion Middleware Control 11g, which introduces many important new features for monitoring and configuring Portal components, viewing performance metrics for portal pages, portlets, and providers in real time using the Oracle Enterprise Manager interface.

Improved Export/Import Utilities

The Export/Import utilities include several key improvements for Oracle Portal 11g Release 1 (11.1.1), including:

- Pre-check improvements

- SVU improvements

- Improved error logging

- Enhanced user guidance

- Export improvements

- UI enhancements

- New cloning functionality

Integration with Oracle Fusion Middleware

Oracle Portal 11g Release 1 (11.1.1) has new portlets that integrate Oracle Secure Enterprise Search (search submission and search results), Oracle BPEL (notifications, task analysis, reporting), Oracle Business Intelligence Enterprise Edition (Siebel BI Tools), and Hyperion System BPM (Business Performance Management), this provides improved, out-of-the-box integration with Oracle Portal.

Support for Content Approvals Using BPEL

Oracle Portal 11g Release 1 (11.1.1) enables you to use Oracle BPEL to define approval processes for page groups and pages in your Portal. Oracle BPEL brings added functionality beyond that provided by the Oracle Portal built-in workflow, and it is now a simple job to leverage that functionality in your Portal.

Improved Integration with Oracle Applications

Oracle Portal 11g Release 1 (11.1.1) provides improved integration with the following:

- Oracle Applications based on Oracle Applications Framework, such as Oracle Self-Service Applications, can now expose application pages based on Oracle Applications Framework as portlets within Oracle Portal.

- Oracle Portal 11g Release 1 (11.1.1) will also support incorporation of portlets from PeopleSoft applications, including PeopleSoft Version 9, which is based upon the PeopleTools release 8.48 technology layer. The following adapters are available:

- Oracle Universal Content Management

- Content DB* Third-party content management JCR adapters

- File system

Capability to integrate Oracle WebCenter Portal: Services into Oracle Portal

In this release, you can integrate Oracle WebCenter Portal: Services, which is a separate license, into Oracle Portal. For information about setting up the services producer application, see Chapter 27, Creating Portlets with the Oracle JSF Portlet Bridge in the Oracle Fusion Middleware Developer's Guide for Oracle WebCenter.

Use of Oracle JSF Portlet Bridge to portletize JSF applications and integrate them into Oracle Portal

You can portletize JSF applications by using Oracle JSF Portlet Bridge, which is packaged with Oracle WebCenter Portal: Services. You can integrate these portlets into Oracle Portal. For more information about Oracle JSF Portlet Bridge, see Creating Portlets with the Oracle JSF Portlet Bridge in the Oracle Fusion Middleware Developer's Guide for Oracle WebCenter.

Content Integration

The Oracle Portal portlets help to expose content from third-party document management systems. The portlets are built in Oracle JDeveloper, and JCR 1.0 adapters are used to connect to content management systems.

Improved Access to Oracle Portal Management Content

Oracle Portal 11g Release 1 (11.1.1) has a new JCR-based (JSR-170) adapter, that will allow you to integrate content stored and managed within the Portal Repository in a custom J2EE application.

OmniPortlet Enhancements

This enhancement will provide an advanced parameter form that allows you to populate a list of values dynamically based on a data source, such as a SQL query or database column. In addition, the Web service data source of OmniPortlet has been improved greatly, allowing you to consume complex Web services, including BPEL and PL/SQL-based Web services.

Support for New Industry Standards

Oracle Portal 11g Release 1 (11.1.1) supports the following new standards:

- WSRP 2.0: Oracle Portal supports WSRP 2.0, including rich Ajax-enabled portlets built with ADF rich client technology.

- JSR301: The Portlet Bridge Specification for JavaServer Faces (JSR 301) outlines the standard for building new portlets with JSF, turning JSF pages and task flows into standards-based portlets, and bringing existing JSF applications into Oracle Portal.

- JSR170: This allows you to integrate content stored and managed within the Portal Repository in a custom J2EE application.

New Features in OracleAS Portal 10g Release 2 (10.1.4)

The new features of OracleAS Portal 10g Release 2 (10.1.4) include:

- New Caching Architecture

- Query Path URL Supports SSL

- New URL Format

- WSRP Support

- Search and Oracle Text Indexing Enhancements

- Support for Enhanced Provider Message Authentication

New Caching Architecture

In 10g Release 2 (10.1.4), OracleAS Portal introduces a major improvement in scaleability. In this release, OracleAS Web Cache which uses Edge Side Includes (ESI) processing, is the entry point for page request processing rather than the Parallel Page Engine (PPE). This simplifies the page metadata (PMD) and it allows different types of metadata to be cached in OracleAS Web Cache at a more granular level, increasing the cache hit ratio and enabling a more granular invalidation of portal content. This new approach also provides support for secure full page caching in OracleAS Web Cache.

Query Path URL Supports SSL

OracleAS Portal maintains the URL prefix of OracleAS Single Sign-On, which accesses certain information through calls from the database using the UTL_HTTP package. These calls can now also be made using HTTPS. In previous releases, these calls were made using HTTP. As a result, even if OracleAS Portal and OracleAS Single Sign-On were configured to use HTTPS, you had to still use an HTTP port on OracleAS Single Sign-On to support these interfaces. If you are using HTTPS, then after configuring OracleAS Single Sign-On to use SSL, you must update the OracleAS Single Sign-On query path URL.

New URL Format

The URL format in OracleAS Portal 10g Release 2 (10.1.4) has changed from http://<host>:<port>/pls/<dad> to http://<host>:<port>/portal/pls/<dad>. This change is to accommodate the availability of all necessary Portal Services running within OC4J_PORTAL. If URLs of the older format are accessed, then OracleAS Portal either automatically rewrites the URL to use the new format, or alerts you to change the bookmarked URL to the new format.

WSRP Support

Organizations engaged in enterprise portal projects have found application integration to be a major issue. Until now, users developed portlets using proprietary APIs for a single portal platform and often faced a shortage of available portlets from a particular portal vendor. All this changes with the introduction of Web Services for Remote Portlets (WSRP). WSRP is a Web services standard that allows the plug-and-play of visual, user-facing Web services with portals or other intermediary Web applications. Being a standard, WSRP enables interoperability between a standards-enabled container and any WSRP portal.

Search and Oracle Text Indexing Enhancements

Notable improvements to the search facilities in OracleAS Portal include:

- Search Indexes Synchronize Automatically On Commit
If you are using Oracle Database 10g, you can now specify that Oracle Text indexes synchronize automatically whenever portal objects are added, modified, or deleted. This feature is useful for portal applications where newly added or altered content must be searchable immediately.

To find out more, Section 10.3.5.1, "Synchronizing Oracle Text Indexes". This feature is not available on databases earlier than Oracle Database 10g

- Improvements to Document and URL Filtering
Oracle Text uses the AUTO_FILTER to convert documents and URL content into a plain text format that is suitable for indexing. Filtering content unnecessarily can impact the speed and efficiency of portal searches, so in this release OracleAS Portal introduces two special attributes for file- and URL- based item types: MIME Type and Character Set. These attributes enable portal users to classify portal content correctly when it is uploaded to the portal and this streamlines the filter process.

For more information, see Section 10.3.3.7, "Maximizing AUTO_FILTER Performance".

Support for Enhanced Provider Message Authentication

In 10g Release 2 (10.1.4), OracleAS Portal introduces the support for Enhanced Provider Message Authentication. Enhanced message authentication secures the integrity of the headers that are used to propagate the user's authenticated identity to the Web provider. This enables you to leverage J2EE security in your provider code.

See Also:

- Section 7.3.1.3, "Configuring Provider Message Authentication" for information on how to configure Provider Message Authentication.

- Oracle Fusion Middleware Developer's Guide for Oracle Portal

Part I

Concepts

Part one contains the following chapters:

- Chapter 1, "Understanding the Oracle Portal Architecture"

- Chapter 2, "Planning Your Oracle Portal"

1 Understanding the Oracle Portal Architecture

This chapter introduces Oracle Portal and it's architecture, and contains the following sections:

- Understand the Oracle Portal Components, which provides you with a basic understanding of the solutions and components of Oracle Portal, so you can have a better understanding on how they work in concert with Oracle Portal.

Note:

Oracle Portal cannot be installed as standalone, but must be installed as part of Oracle Fusion Middleware.

- Understanding the Oracle Portal Architecture, which provides you with a basic understanding of the Portal architecture.

- Understanding Caching in Oracle Portal, which describes the caching configurations you can implement to increase the availability and scalability of medium to large deployments.

- Understanding WSRP and JPS, which provides an introduction to the Web Services for Remote Portlets (WSRP) specifications and Java Portlet Specification (JPS). These two standards enable the development of portlets that interoperate with different portal products, and therefore widen the availability of portlets within an organization.

1.1 Understand the Oracle Portal Components

It is important to understand a bit about the overall Oracle Portal architecture so you can more fully understand how your Oracle Portal configuration fits within that structure. The next few sections provide some key concepts and terms you will need as you plan your configuration strategy.

The Oracle Portal architecture consists of three basic tiers:

- Client Tier

- Middle Tier

- Infrastructure Tier

Client Tier

From the client computer, a user can connect to the middle tier and the infrastructure tier to access the self-service tools for publishing information, build applications, deploy content management, and administer enterprise portal environment.

Middle Tier

The middle tier, which includes application tier and web tier, is a set of Oracle Portal components typically installed into a single Oracle home. A single enterprise can have one or more Fusion Middleware installations, either residing on one host, or for more complex installations, distributed across multiple hosts.

Infrastructure Tier

The infrastructure installation consists of several components that help authenticate users, store access control information, and pass on the required content to the user based on the privileges the user has on Oracle Portal. Like the middle-tier components, infrastructure components can be distributed across multiple hosts to enable scalability and high availability.

Figure 1-1 shows the three parts of the Oracle Portal architecture.

Figure 1-1 Components of the Portal Architecture

Note:

Oracle Portal 11g Release 1 (11.1.1) is not directly supported on Internet Protocol Version 6 (IPv6).

The supported configurations are:

- An IPv4/IPv6 reverse proxy setup on an IPv4/IPv6 dual stack machine.

- The Portal mid-tier and the backend database on IPv4 machines, and clients accessing the Portal server through the proxy.

1.1.1 What Are the Middle-Tier Components?

The middle tier is the part of a Portal architecture that contains several components responsible for accepting requests from clients, validating the requests, and providing content, while using intelligent data caching for faster and reliable performance.

For Oracle Portal, the middle tier handles all Web requests by forwarding them to the appropriate provider. This is also where portal pages are assembled, and where the caching of portal content is managed. The middle tier also provides other functions for other Oracle Fusion Middleware components.

Some of the key components for Oracle Portal middle-tier are divided into:

Application Tier

Application Tier includes:

- Oracle WebLogic Server: Oracle WebLogic Server is a standards-based application server that provides a comprehensive and fully integrated platform for running Web sites, J2EE applications, and Web services. It addresses all the challenges that you face as you refine your business processes to become an e-business.
Oracle WebLogic Server provides full support for the J2EE platform, XML, and emerging Web services standards. With Oracle WebLogic Server, you can simplify information access for your customers and trading partners by delivering enterprise portals that can be customized and accessed from a network browser or from wireless devices. It enables you to redefine your business processes and integrate your applications and data sources with those from your customers or partners. You can deliver tailored customer experiences through real-time personalization, and assess and correlate customer navigation, purchasing, ratings, and demographic data.

You can also implement a centralized management, security, and directory framework to manage and monitor all of your distributed systems and diverse user communities. Oracle WebLogic Server maximizes your Web site infrastructure by deploying your fast, scalable Internet applications through built-in Web caching, load balancing, and clustering capabilities.

Oracle WebLogic Server is actually a set of solutions with each solution containing one or more components. A component can be a service, an API, or an application. For detailed information, see the Oracle Fusion Middleware Concepts guide.

- Portal Services: For Oracle Portal, Oracle HTTP Server handles all incoming requests to Oracle Portal, by forwarding them to the WLS_PORTAL instance, which provides all the Portal Services. The Parallel Page Engine (PPE) is one of the Portal Services that assembles portal pages. Other services, like those previously provided by mod_plsql, are now incorporated in the Portal Services as well.

- Fusion Middlware Control: This administration tool for Portal enables you to administer clusters, start and stop services, enable and disable components, view logs and ports, and monitor servers in real-time.

Web Tier

- Oracle HTTP Server. Oracle HTTP Server is the underlying deployment platform for all programming languages and technologies Oracle Fusion Middleware supports. Providing a "scalable" Web listener front ending the J2EE container and the framework for hosting static and dynamic pages and applications over the Web, Oracle HTTP Server includes significant features that facilitate load balancing, administration, and configuration.

- Oracle Web Cache. Works together with Oracle Portal's own file-based caching to cache page definitions and content in memory, to boost performance. Oracle Portal is closely integrated with Oracle Web Cache to improve Oracle Portal's overall availability, scalability, and performance. Oracle Web Cache combines caching and compression technologies to accelerate the delivery of both static and dynamically generated portal content.

Figure 1-2 The Middle-Tier Components

The middle-tier installation comprises the following components:

1. Oracle WebLogic Server, Oracle HTTP Server, and Oracle Web Cache, which is the simplest configuration and does not contain any of the Oracle Portal Solution components.

2. Oracle Portal which adds the Portal solution to those provided by Oracle WebLogic Server and Oracle Web Cache.

3. Oracle Reports, Oracle Business Intelligence Discoverer, and Oracle Forms, which contains all of the middle-tier components, including Oracle Portal.

Refer to the following sections for more information:

- Section 2.1.7, "How Should I Configure My Hardware and Software?"

- Section 6.3, "Configuring Multiple Middle Tiers with a Load–Balancing Router"

1.1.2 What Are the Infrastructure Components?

By default, the infrastructure tier handles all authentication requests and hosts the Oracle Fusion Middleware Metadata Repository, which contains schemas and business logic used by Fusion Middleware components (including Oracle Portal) and other pieces of the infrastructure.

For the Oracle Portal middle-tier installation, the infrastructure tier is a prerequisite.

The Oracle Fusion Middleware Infrastructure contains:

- Oracle Internet Directory. An LDAP version 3 compliant repository for storing user credentials and group memberships for Oracle Portal and other Oracle products.

- Oracle Application Server Single Sign-On (SSO). Authenticates user credentials against Oracle Internet Directory for Oracle Portal and other applications, thus enabling users to log on once to the Web portal to access multiple accounts and applications with a single user name and password.

- Oracle Metadata Repository. The repository is installed in an Oracle Database and consists of a collection of schemas that contain product metadata for Oracle Fusion Middleware components. Some middle-tier components, such as Oracle Portal, store their metadata in this repository and need access to that metadata during run time.

Figure 1-3 The Infrastructure Tier Components

You can install multiple instances of any of these components on multiple servers, and then connect the servers to suit your needs. Deployment configuration options for Oracle Portal range from installing everything on a single server to multitier configurations in which the pieces comprising Oracle Portal are located across multiple servers.

There are three types of OracleAS Infrastructure installations:

1. Oracle Identity Management, which installs and configures Oracle Identity Management services (Oracle Internet Directory, OracleAS Single Sign-On, Oracle Delegated Administration Services, Oracle Directory Integration and Provisioning, OracleAS Certificate Authority).

2. Oracle Metadata Repository, which installs a new Oracle Database containing the Oracle Metadata Repository, and also stores the database objects that comprise Oracle Portal.

3. Oracle Identity Management components and Oracle Metadata Repository, which consists of all the components listed in the preceding two installation types.

Note:

Throughout this guide, you will see references to ORACLE_HOME. ORACLE_HOME, represents the full path of the Oracle home, and it is used in cases where it is easy to determine which Oracle home is referenced. Oracle home contains all Oracle components selected for an installation type. You are prompted to enter an Oracle home in the Path field of the Oracle Universal Installer File Locations window.

The following conventions are used in procedures where it is necessary to distinguish between the Oracle instance, middle tier, WLS instance, or Oracle Metadata Repository Oracle home:

- Middleware home, consists of the Oracle WebLogic Server home, and, optionally, one or more Oracle homes. A Middleware home can reside on a local file system or on a remote shared disk that is accessible through NFS. MW_HOME will be used in this documentation to refer to the directory where the product is installed.
MW_HOME must be replaced with the full path name of the installed Oracle Fusion Middleware instance.

- Oracle home, contains installed files necessary to host a specific product. For example, the Portal Oracle home contains a directory that contains binary and library files for Oracle Portal and its components. An Oracle Home resides within the directory structure of the Middleware home. Each Oracle Home can be associated with multiple Oracle instance or Oracle WebLogic Server Domain. The default ORACLE_HOME is named as as_1.

- Oracle instance home, contains one or more system components, such as Oracle Web Cache, Oracle HTTP Server, or Oracle Internet Directory. The system components in an Oracle instance must reside on the same machine. An Oracle instance directory contains updatable files, such as configuration files, log files, and temporary files. An Oracle instance is a peer of an Oracle WebLogic Server domain. Both contain specific configurations outside of their Oracle homes. The directory structure of an Oracle instance is separate from the directory structure of the Oracle home. The default instance home is named as asinst_1.

- WebLogic Server home, which contains installed files necessary to host a WebLogic Server. The WebLogic Server home directory is a peer of Oracle home directories and resides within the directory structure of the Middleware home.

- Oracle Metadata Repository home, represents the full path of the OracleAS Infrastructure home containing the Oracle Metadata Repository.

1.2 Understanding the Oracle Portal Architecture

After your development team builds your Web portal, the next step is to deploy a production version of it. Successful deployment means that end users are able to access content in a timely manner, without delays, errors, or server downtime. Because Oracle Portal can be installed in a variety of configurations on different machines, a successful deployment ultimately depends how you configure portal to address the requirements of your site. This section provides some background information that should be useful to you as you plan your configuration.

1.2.1 How Does Oracle Portal Integrate with Other Components?

Some Oracle Fusion Middleware components serve as portlet providersFoot 1  for Oracle Portal, which means you can easily integrate information from various components into a single portal page. Other components provide essential services to Oracle Portal, as described in the following list.

- Oracle Reports. Oracle Portal includes a simple report building facility. However, as your reports become more complex, you may want to import the report into Oracle Reports Services to take full advantage of the functionality it offers. You can deploy any Oracle Reports Services report as a portlet.

See Also:

Oracle Fusion Middleware Publishing Reports to the Web with Oracle Reports Services

- Oracle Business Intelligence Discoverer. As a portlet provider, OracleBI Discoverer offers Worksheet portlets and List of Workbooks portlets to Oracle Portal users. A Worksheet portlet contains information from a single Discoverer worksheet. The portlet displays this information in a table, a graph, or both. The List of Workbooks portlet presents a list of available workbooks.

See Also:

- Oracle Fusion Middleware Guide to Publishing Oracle Business Intelligence Discoverer Portlets

- Oracle Fusion Middleware Configuration Guide for Oracle Business Intelligence Discoverer

- Oracle Secure Enterprise Search. Secure Enterprise Search (SES) enables portal users to add a powerful search capability to their portal pages, and can be used to perform a search over a variety of content repositories and data sources. It also has the capability to crawl the Oracle Portal Repository and search public content. Refer to Chapter 10, "Configuring the Search Features in Oracle Portal" for more information about Secure Enterprise Search.

- Oracle Application Server Wireless. Working with OracleAS Wireless, Oracle Portal automatically transforms the portal page structure to a format appropriate for the smaller screens of most wireless devices. Only portlets generating OracleAS Wireless XML content can display on a wireless device.
Oracle Portal developers also have access to a set of page design tools that help in creating portal pages that optimize the wireless experience. With these tools, developers can build a distinct portal structure for their wireless users. The wireless pages and portal pages can share portlet instances, which enables clients to reuse portlets on browser and wireless clients without reconfiguring each portlet.

Refer to Section 5.7, "Configuring Mobile Support in Oracle Portal"for more information.

- Oracle Enterprise Manager 11g. Oracle Enterprise Manager 11g provides Fusion Middleware Control. Oracle Enterprise Manager 11g Fusion Middleware Control can be used for monitoring, diagnostics, and for configuring Oracle Portal-specific integration and performance settings. Refer to Chapter 8, "Monitoring and Administering Oracle Portal" for more information about monitoring Oracle Portal.

- Oracle Fusion Middleware Forms Services. Oracle Forms applications combine interactive, graphical interfaces with strong support for data validation. Forms developers can quickly create applications with powerful data manipulation features. Fusion Middleware Forms Services deploys Forms applications to Java clients in a Web environment. Fusion Middleware Forms Services automatically optimizes class downloads, network traffic, and interactions with the Oracle Database. Fusion Middleware Forms Services applications are secured by the OracleAS Single Sign-On, and accessed from an Oracle Portal environment provided by Oracle WebLogic Server.

- Oracle Application Server Single Sign-On. OracleAS Single Sign-On authenticates users who are attempting to gain access your portal. Refer to Section 7.1.7.1, "Relationship Between Oracle Portal and OracleAS Single Sign-On" for more information.

- Oracle Internet Directory. Oracle Internet Directory is Oracle's highly scalable, LDAP version 3 service, which hosts the Portal's group membership information. Oracle Portal queries the directory and retrieves the group memberships of the user from the directory to determine what they may access and change. Refer to Section 7.1.7.3, "Relationship Between Oracle Portal and Oracle Internet Directory" for more information.

- Oracle Delegated Administration. In addition to querying Oracle Internet Directory for user and group information, Oracle Portal must provide users with a user interface to add and modify user and group information. To change information in the directory, you use the Oracle Delegated Administration Services user interface. Oracle Portal provides links to the Oracle Delegated Administration Services for users with sufficient privileges to add and change users and groups. Refer to Section 7.1.7.5, "Relationship Between Oracle Portal and Oracle Delegated Administration Services" for more information.

- Oracle Directory Integration and Provisioning. Oracle Directory Integration Platform notifies Oracle Portal upon the occurrence of any directory events (for example, user deletions) to which Oracle Portal subscribes. In essence, the directory integration server informs Oracle Portal when a change occurs in the directory that requires a change in Oracle Portal. Refer to Section 7.1.7.4, "Relationship Between Oracle Portal and Oracle Directory Integration Platform" for more information.

- Metadata Repository. The metadata repository is created using the Repository Creation Utility (RCU) and consists of a collection of schemas that contain product metadata for Oracle Fusion Middleware components. Oracle Portal, store their metadata in this repository and need access to that metadata during run time.

1.2.2 How Do the Pieces Fit Together?

A portal comprises groups of pages, each page divided into regions. The regions specify how space on a given page is allotted to that page's items and portlets.

1.2.2.1 How Are Pages Assembled in Oracle Portal?

Each time a user requests an Oracle Portal page, the page is dynamically assembled and formatted according to the portlets and layout chosen for that page. Keep in mind that the parts that comprise the page are typically drawn from a variety of sources. For example, the page's layout, look and feel, and user personalizations are stored in the database as part of the overall page definition, completely separate from any portlet content. This information may, in turn, be cached by the middle tier.

The fully assembled page may be cached in Oracle Web Cache based on the page's caching properties. However, if full-page caching is used, pages are not re-assembled with each request, because they are served directly out of Oracle Web Cache.

The portlets that appear on the page can be written in PL/SQL or Java. For PL/SQL portlets, the source is an Oracle Metadata Repository database. This could be the database where the current instance of Oracle Portal is installed, or some other Oracle Metadata Repository database located on a remote server, which is accessed through the Federated Portal Adapter. If written in Java, a Web provider provides the portlet from any location accessible from the network, either Internet or intranet. For example, you could create a portal page that displays content from many different providers. These providers can be database providers, Web providers, or WSRP producers.

Figure 1-4 shows how a typical page is assembled. In this release, Oracle Web Cache, using Edge Side Includes (ESI) processing, is the entry point for page request processing rather than the PPE. The various pieces of metadata involved in a page request are cached at a more granular level, increasing the cache hit ratio and enabling a more granular invalidation of portal content. This new approach also provides support for secure full page caching in Oracle Web Cache.

Figure 1-4 Portal Page Request Flow

Figure 1-4 shows the steps performed when a client requests an Oracle Portal page.

1. The client browser requests a portal page. Oracle Web Cache receives this request.

2. Oracle Web Cache retrieves the page stub. You can think of the page stub as a blueprint for the page that is to be assembled. If the page stub is not already cached in Oracle Web Cache, then it is generated by the Portal Services running in the Oracle Portal instance

Note:

The Portal Services are used to assemble portal pages, access portal and page metadata, and so on. The Parallel Page Engine (PPE) continues to be one of the Portal Services that assembles portal pages. Other services, like those previously provided by mod_plsql, are now incorporated in the Portal Services as well.

3. Oracle Web Cache parses the page stub and retrieves additional user and page security metadata. Examples of the User Metadata (UMD) are user name, device type, and language. This user information is gathered once per session per user. If the UMD is not already cached in Oracle Web Cache, then it is generated by the Portal Services running in the Oracle Portal instance. The page security metadata (SMD) contains information that is used to determine whether the user is authorized to see the content at a given URL. If the SMD is not already cached in Web Cache, a request is sent through Portal Services to the portal schema in the Oracle Metadata Repository (not shown in Figure 1-4). If the user has not logged in and is requesting private data, then the user will be challenged to log in. An error page displays if it turns out that the user is not authorized to view the page.

4. Oracle Web Cache returns the already fully assembled copy of the page if it is found in the cache. Otherwise, it requests the content from Portal Services. The content of the page is assembled as follows:

1. Portal Services tries to get the cached copy of the page metadata (PMD) from Oracle Web Cache. The PMD, or the page definition, contains information about the portlets on a page and their layout. If there is a cache miss in Oracle Web Cache, then it checks if the portal cache has a valid cached copy. Finally, if no cached copy of the PMD exists, then the portal schema in the Oracle Metadata Repository generates the PMD.

2. Portal Services retrieves common page components, such as navigation portlets, banners, tabs, and subpage regions, from Oracle Web Cache if they exist. These requests are performed in parallel. A request is sent to the portal schema in the Oracle Metadata Repository if no valid cached copies exist.

3. For each portlet on the page, Portal Services checks if a cached copy of the portlet's content exists in the Portal Cache. If there is a cache hit, the cached content is used. If there is a cache miss, Portal Services fetches the content from the appropriate provider. These requests are performed in parallel along with the requests described in the preceding step. Each provider returns content for the portlet. Content can be requested from Web providers, WSRP producers, or Database (DB) providers.

5. Oracle Web Cache returns the fully assembled page to the client browser.

1.2.2.2 How Does Communication Flow in Oracle Portal?

The Oracle Portal implements a distributed architecture consisting of multiple communication points and protocols. For complex configurations including the introduction of firewalls and proxies, you need to understand the communication points, and how the various components of Oracle Portal integrate together. Likewise, to allow for the distribution of the various functions across multiple servers, it is necessary to be aware of the network protocols that are used in the internode communication.

The Oracle Portal architecture consists of three basic tiers: the client browser (pictured at the far left in Figure 1-5) the middle-tier server (pictured on the bottom left), and the infrastructure server and repositories (pictured on the top left). Although the default installation places all servers and repositories on the same host, it is recommended that you install these functions on separate servers, for increased performance and high availability.

Figure 1-5 shows in detail the communication flow between the various components of Oracle Portal.

Figure 1-5 Communication Flow and Protocols

The three tiers and the communication protocols used between them is described next:

- Client

- Infrastructure Tier

- Middle Tier

Client

- The client sends a request to Oracle Portal, which is part of the middle tier, using the HTTP or HTTPS protocols. The use of firewalls and proxies is supported between the client and the middle tier.

- If the user needs to be authenticated, the client browser is redirected to the Oracle HTTP Server in the infrastructure tier. This connection is through HTTP or HTTPS and supports the implementation of both firewalls and reverse proxies in the network environment.

Infrastructure Tier

The infrastructure tier consists of the Oracle HTTP Server, OracleAS Single Sign-On, Oracle Internet Directory, and Oracle Metadata Repository.

- If the requested page requires authentication, the user is prompted for a user name and password. This function is carried out by the Portal Services, through a redirection to OracleAS Single Sign-On for authentication. All authentication requests are communicated using the SQL*Net protocol.

- OracleAS Single Sign-On verifies user credentials against the Oracle Internet Directory through LDAP/S. The credentials are compared to those found within the Directory (LDAP compare) and the result returned to OracleAS Single Sign-On. Upon successful authentication, OracleAS Single Sign-On creates a single sign-on cookie. Once the user is authenticated and an appropriate Oracle Portal session created, the user may access pages and other objects.

- As the access control lists (ACL) for all portal objects are held in the Oracle Metadata Repository, the Oracle Portal uses an LDAP/S request to communicate with the Oracle Internet Directory to query the appropriate user and group membership information defined in the Directory. When a user first logs in to Oracle Portal, the group memberships of the user are copied to the portal node and cached on that tier. This process allows for fast lookup of object privileges. Once the object and page privileges of the user are known, the Parallel Page Engine goes on to generate the page from the appropriate pieces.

- All user provisioning is performed against the Oracle Internet Directory. The interface between the Infrastructure tier's Oracle HTTP Server and the LDAP server is through the Oracle Delegated Administration Services servlet. The Oracle Delegated Administration Services interface uses the LDAP/S protocol to communicate with the Oracle Internet Directory.

- The OracleAS Single Sign-On model includes the addition of mod_osso, which allows any URL to be protected within the OracleAS Single Sign-On environment. Calls to the Delegated Administration Services servlet are protected by the mod_osso plug-in. This verifies that the user has been properly authenticated before providing access to the Oracle Internet Directory. In effect, mod_osso filters the URL and forwards the HTTPS-based request, only if the user has previously been authenticated.

- The Oracle Directory Integration Platform automatically keeps the locally cached information up to date with changes in the Oracle Internet Directory. Just as the Oracle Directory Integration Platform keeps the local cache synchronized with the Oracle Internet Directory, it also keeps the Oracle Internet Directory synchronized with any external repository. The Oracle Directory Integration Platform communicates with the Oracle Internet Directory through LDAP/S.

Middle Tier

The middle tier is divided into tiers:

The middle tier consists of the Application Tier and Web Tier, includes Oracle Web Cache, Oracle HTTP Server, Oracle WebLogic Server, and other Oracle Portal components.

Note:

Oracle Web Cache, Oracle HTTP Server, and Oracle WebLogic Server can be installed on different hosts to allow scalability and high availability.

- Oracle Web Cache front ends the middle-tier components and thus optimizes the throughput of Oracle Portal. When a page request comes from the browser, Oracle Web Cache evaluates the URL and services the request from the cache if possible. If a requested page is not previously cached, the request is forwarded to its origin server (Oracle HTTP Server in this case) for generation. As a Web accelerator, Oracle Web Cache allows the use of HTTP or HTTPS communication between itself and:

- The client browser

- The appropriate origin server

- Both the origin server and the client browser

- The Parallel Page Engine (PPE) runs as a servlet within the Oracle Containers for J2EE. A URL request to the servlet is forwarded through the Oracle HTTP Server's plug-in, mod_weblogic. As a standards-based plug-in, mod_weblogic communicates with Oracle Containers for J2EE using the Apache Java Protocol (AJP).

- The WSRP container is a Java portlet container that implements the WSRP specification and the Java Specifications Request (JSR) 168 APIs.

- The PPE itself makes requests to database providers, Web providers, and Web Services for Remote Portlets (WSRP) producers through HTTPS-based communication. The render request to a database provider is through a URL loopback to the Portal Services, while the call to a Web provider is by use of a SOAP-based message protocol over HTTP or HTTPS, and the call to a WSRP producer is by use of the WSRP communication protocol using the Web Services Definition Language (WSDL) URL.

- If any Web providers require information from the Oracle Metadata Repository, they issue the appropriate call through the PDK using a SOAP-based message protocol over HTTP or HTTPS.

- The Oracle Web Cache component uses an invalidation-based cache methodology. If a requested URL can be serviced from the cache, it is assumed to be correct until the specified URL is invalidated. If a user customizes their Oracle Portal experience, or if the privileges configured to use the user changes, the Oracle Portal invalidates the appropriate cached objects within Oracle Web Cache. To do this, the Oracle Portal issues a HTTPS-based request directly from the Oracle Metadata Repository to the invalidation port of the Oracle Web Cache.

1.3 Understanding Caching in Oracle Portal

Oracle Portal caches data in the following locations:

- Browser – Data that does not change between requests can be cached in the browser, for example, expiry-based pages.

- Oracle Web Cache – Many types of portal data are stored in this in-memory caching system. See Section 1.3.1, "Understanding Oracle Web Cache".

- Portal Cache – Many types of portal data are also stored in this persistent file system-based cache. See Section 1.3.2, "Understanding Portal Cache".

Oracle Portal uses three methods to cache Web pages and content:

- Invalidation-based caching is used by Oracle Web Cache. An item remains in the cache until it is explicitly invalidated. For example, a user may update some item, requiring the cache to be invalidated. As part of the update, the Oracle Metadata Repository or a Provider sends an invalidation message to Oracle Web Cache. The next time there is a request for the invalidated item, it is refreshed in the cache. You can set the expiry time for invalidation-based caching. See Section 6.7.4.3, "Setting the Expiry Time for Invalidation-based Caching" for more information.

- Validation-based caching is used by the portal cache. Before an item in the portal cache is used, Portal Services contacts the Oracle Metadata Repository or a Provider to determine if the cached item is still valid.

- Expiry-based caching is used by the portal cache, Oracle Web Cache, and browsers. Expiry-based portlets are cached in the portal cache, whereas, expiry-based assembled pages are cached in Oracle Web Cache. A retention period for the item specifies how long it is valid in the cache, before a refresh is required. Pages that use expiry-based caching may also be cached in the user's browser.

Caching can be done at the following levels:

- User – A separate copy of the data is cached for each user.

- System – A single copy of the data is cached for all users.

1.3.1 Understanding Oracle Web Cache

Oracle Web Cache is a powerful server acceleration and load balancing solution. Oracle Web Cache is required for running Oracle Portal. Oracle Web Cache offers intelligent caching, page assembly, and compression features. Oracle Web Cache accelerates the delivery of both static and dynamic Web content, and provides load balancing and failover features for Oracle Fusion Middleware.

To increase the availability and scalability of medium to large deployments, consider configuring multiple instances of Oracle Web Cache to run as members of a cache cluster. A cluster is a collection of cooperating Oracle Web Cache instances that work together to provide a single logical cache. Cache clusters provide failure detection and failover, increasing the availability of your Web site. If an Oracle Web Cache instance fails, other members of the cache cluster detect the failure and take ownership of the cached content of the failed cluster member. This is achieved because the nodes that receive requests hold the content, after forwarding the request to the owner cache node.

By distributing the Web site's content across multiple Oracle Web Cache servers, more content can be cached and more client connections can be supported, expanding the capacity of your Web site. You make use of the processing power of more CPUs and, because multiple requests are executed in parallel, you increase the number of requests that are served concurrently.

Oracle Portal functions as a Web Cache origin server to take advantage of the following Web Cache features:

- Caching dynamically generated, user-specific page structure and portlet content

- Fine-grained cache control

- Invalidation-based caching

- Layer 7 load balancing and failover detection

- Performance assurance and surge protection

Portal sites can choose from the following deployment options:

- Collocated: Web Cache runs on the same physical server as the Oracle Portal middle tier. This configuration is appropriate for smaller, low-volume sites where the scalability of the middle tier is not a concern.

- Dedicated: Web Cache is deployed on a dedicated server that sits in front of one or more Oracle Portal middle-tier servers. Dedicated deployments are usually preferable to collocated deployments, as there is no risk of resource contention with other server processes. Oracle Web Cache performs well on commodity hardware, so a dedicated deployment does not have to be costly in terms of hardware expenditure.
For medium to large business Web sites with high volume, the dedicated topology is advantageous for the following reasons:

- No resource contention. Installing Oracle Web Cache and Oracle Portal middle tier on different servers will guarantee no competition among different services for hardware resources.

- Performance assurance and surge protection. By separating the middle-tier server and cache server, this topology minimizes compound failure rates. Oracle Web Cache offers patent-pending techniques to guarantee site performance and scalability, even when Web server loads surpass capacity levels. A surge protection mechanism detects system overload conditions, providing a crucial buffer against traffic spikes and denial-of-service attacks.

- Server affinity. Oracle Web Cache can be used to balance the load between multiple Oracle Portal middle-tier servers and providers in a cluster. Cookies can be used to maintain persistent, or "sticky", connections to a specific server when necessary to preserve state.

See Also:

Section 6.8, "Configuring Oracle Portal to Use a Dedicated Oracle Web Cache Instance"

To avoid a single point of failure in very high-volume sites, two or more nodes running Oracle Web Cache may be deployed behind a Load Balancing Router (LBR). If you have multiple deployments of Oracle Portal, each portal site can have its own Web Cache server. One or more sites can also share a single Web Cache server. Similarly, a provider can share a Web Cache with a portal site, or a dedicated Web Cache can be deployed in front of the Web server that hosts the provider. Refer to Section 6.7, "Managing Oracle Portal Content Cached in Oracle Web Cache" for more information about configuring Oracle Web Cache.

In addition to providing failover, an Oracle Web Cache cluster also balances the load it forwards to the middle tier.

Figure 1-6 Adding Oracle Web Cache to a Medium to Large Portal Configuration

After the initial request to the owner node, the content is cached across any requesting instances. In Figure 1-6, the LBR distributes incoming requests to the three Oracle Web Cache instances. When the on-demand content is not available on the node receiving the request, the other instances are checked for the cached content, and the page matching the request is returned to the Browser.

To take advantage of Oracle Web Cache's clustering capability, you must configure each instance as a member of a cache cluster. In this setup, there is no one-to-one relationship between an Oracle Web Cache instance and a matching middle-tier instance. As shown in Figure 1-6, Oracle Web Cache 1 provides load balancing between middle tiers 1, 2, and 3. Oracle Web Cache 2 and 3 do the same.

See Also:

Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache

You will find additional information about caching and performance on the Oracle Technology Network (OTN).

1.3.2 Understanding Portal Cache

Portal cache is a file system-based cache for Oracle Portal pages and portlets. Portal cache supports validation-based caching and expiry-based caching.

Portal cache consists of two kinds of caches:

- Portal Content Cache
The content cache contains user level and system level content generated by Oracle Portal, which includes page metadata, database portlets, Web portlets, documents, style sheets, images, and full-page caches.

- Portal Session Cache
Oracle Portal uses session cookies to maintain session details for each portal user. This session cookie is encrypted and contains important information like the database user name, lightweight user name, and Globalization Support characteristics of the session. In order for Portal Services to execute a portal request, it must get the database user name from the session cookie. To avoid an expensive decrypt operation with each user request, Portal Services decrypts the session cookie once and maintains the relevant cookie details in an in-memory session cache. The in-memory session cache may be used for garbage-collection by the JVM, and therefore, the session details are also cached in the file system.

Portal content and session cache content resides on the file system, typically and is configured in the file DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration\portal_cache.conf. You can specify content cache for Oracle Portal from the Fusion Middleware Control. See Section 5.6.6, "Configuring the Portal Cache Using Fusion Middleware Control" for more information.

In multiple middle-tier configurations, you can set up the portal cache for each middle tier on a shared file system. This ensures that each middle tier can share cached content, rather than each drawing from its own independent cache.

For example, one middle tier might handle a request for an item by caching it in the portal cache. Because you must use a load balancing router for configurations having multiple middle tiers, the next request for the item could be handled by a different middle tier. This middle tier could access the cached version if the portal caches for each middle tier are shared on a common file system.

Various parameters for configuring portal cache include:

- Cache location

- Total cache size

- Maximum cacheable file size

- Maximum time a cached file can be in the cache system

- Cleanup of the cache storage

See Also:

- Oracle Fusion Middleware Performance and Tuning Guide

- cache.conf section in the Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server.

1.3.3 Understanding Cache Invalidation in Oracle Portal

Oracle Portal makes use of two caching systems: Oracle Web Cache, and portal cache. Oracle Web Cache supports invalidation-based caching and expiry-based caching. The portal cache supports validation-based caching and expiry-based caching.

Cache invalidations can be classified into two groups:

- Hard Invalidations
Hard invalidations are queued up over the duration of a single browser request and are then processed when the Oracle Portal user interface action completes. The results will be seen immediately. Most page edits and all portlet customizations are treated as hard invalidations.

- Soft Invalidations
Soft invalidations are queued up over many browser requests and are then processed later by the soft invalidation database job. Security related changes, for example, granting privileges on a page to a user or group, are treated as soft invalidations.

Cache Invalidation Resource Requirements

Invalidations are queued up based on edits and personalizations. With more such actions being performed, a greater number of invalidations are submitted. Individual actions that involve more portal objects or users will require more resources to process the corresponding invalidations. For example, changing the access privileges for a group of users will require that data for each user in the group be invalidated. Therefore, the larger the group the more invalidation resources will be needed. Consider another example, deleting a large number of pages as a bulk operation requires invalidation resources proportional to the number of pages being deleted. Processing of invalidations requires storage, CPU, and communication resources. Therefore, large numbers of cache invalidations may slow down the system. The reason for this could be any of the following:

- Communication with Oracle Web Cache
When either hard or soft invalidations are processed, a TCP/IP connection is established with the Oracle Web Cache invalidation port from the Oracle Metadata Repository, to send invalidation messages.

For both hard and soft invalidations, all the messages queued are sent using a TCP/IP connection to Oracle Web Cache. Oracle Web Cache receives these invalidation messages and attempts to invalidate cached data. This load may affect Oracle Web Cache's ability to respond to requests for data.

- Cache invalidation queue storage
Both hard and soft invalidation messages are queued into a database table in the Oracle Metadata Repository. As the queue grows in size, more database resources are required to maintain the queue.

- Cache invalidation queue optimization
During the processing of hard or soft invalidation messages, queue optimization removes duplicate or unnecessary invalidation messages. For example, if a page group is being invalidated, individual invalidation messages for pages in the page group are unnecessary. If a large number of invalidation messages have been queued up, the optimization process may take a long time.

1.4 Understanding WSRP and JPS

The WSRP specification is a Web services standard that allows the plug-and-play of visual, user-facing Web services with portals or other intermediary Web applications. Being a standard, WSRP enables interoperability between a standards-enabled container based on a particular language (such as Java, .NET, Perl) and any WSRP portal. Therefore, a portlet (regardless of language) deployed to a WSRP-enabled container can be rendered on any portal that supports this standard. For more information about WSRP, see http://docs.oasis-open.org/wsrp/v2/wsrp-2.0-spec.pdf.

JPS is based on JSR 168 and JSR 286. It defines a set of APIs for building standards-based portlets using Java. Portlets built to this specification can be rendered to a portal locally or deployed to a WSRP container for rendering portlets remotely. For more information about JSR 168, see http://jcp.org/aboutJava/communityprocess/final/jsr168/index.html.

See Also:

Oracle Fusion Middleware Developer's Guide for Oracle Portal

1.5 What's Next?

You are ready to move on to Chapter 2, "Planning Your Oracle Portal", now that you have a basic understanding of the Oracle Fusion Middleware architecture, how Oracle Portal fits in, the working of caching in Oracle Portal, and WSRP producers. By the end of that chapter, you should have a good idea of how you want to configure your installation.

Footnote Legend

Footnote 1: Applications and information sources, represented as portlets, communicate with the portal through a provider. Each portlet only has one provider, and a provider can have one or more portlets that expose an underlying application or information source.

2 Planning Your Oracle Portal

This chapter details the task flow involved in planning, installing, configuring, and administering Oracle Portal. After reading this chapter, you should understand how to plan the hardware and software you need to effectively build a portal.

This chapter contains the following sections:

- What Do I Need to Consider?

- What Do I Need to Do?

Note:

You may want to review Chapter 1, "Understanding the Oracle Portal Architecture" if you are unfamiliar with the terms used in this chapter.

2.1 What Do I Need to Consider?

To develop a plan for configuring your portal, it is critical that you have a firm grasp of the goals you want your system to achieve. Take a look at the following sections to see what's involved in each of these crucial decision points:

- Which Topology Is Right for Me?

- How Much Hardware Do I Need?

- How Can I Maximize Performance?

- How Can I Make My Portal Scale?

- How Can I Make My Portal Highly Available?

- How Can I Secure My Portal?

- How Should I Configure My Hardware and Software?

- Getting the Most Out of Your Configuration

2.1.1 Which Topology Is Right for Me?

Oracle Fusion Middleware offers a variety of topology options. The Oracle Fusion Middleware recommended topologies range from small general development implementations to very large enterprise-wide implementations.

See Also:

- Overview of the recommended topologies in the Oracle Fusion Middleware Concepts guide.

- High Availability for WebLogic Server.

2.1.2 How Much Hardware Do I Need?

Servers, databases, and resources supporting your Web portal must handle wide variations in user traffic, especially during peak intervals.

As with any Web portal, the server and database capacity with which you will need to deploy a portal largely depends on the number of user requests that you anticipate. Displaying a single page to a user may require many separate transactions, from verifying whether the user has permission to view the page, to loading the images that appear on the page, to calling a style sheet that contains formatting information for the page.

The upper and lower limits of what you will need are determined by how you expect your users to use the portal. If the primary function of the Portal is integration, then the majority of load will generally be on the Middle tier. If, on the other hand, the Portal is content driven with significant amounts of customization, then the balance shifts to the repository/infrastructure.At a minimum, you will need enough server capacity to satisfy the average load during a work day, with response times that are acceptable to your user base. If possible, you should strive to satisfy the volume of page requests you anticipate during peak intervals of high user activity. Hardware resources such as CPU, memory, I/O capacity, and network bandwidth are key to reducing response times. You must install Oracle Portal on a server or group of servers that can handle a large number of transactions, or your users will experience slow response times.

Adding more servers and database capacity will certainly improve your Web portal's performance, but unless you have unlimited funds at your disposal, you will need to balance good performance against the costs configured to use each new piece of hardware and software.

See Also:

Oracle Fusion Middleware Administrator's Guide

2.1.3 How Can I Maximize Performance?

Response time is the elapsed time between when a user request is issued and when the response to that request has been completed. Your Web portal should respond as quickly as possible with the least amount of software and hardware overhead. Some performance considerations are:

- Distributing the load
If you anticipate a heavy volume of traffic on your Web portal, you can distribute the load across multiple servers, each with its own middle-tier instance. If one server is overloaded with too much traffic, a second server can handle the overflow. See Section 2.1.8.1, "Load Balancing" for more information.

- Protecting against failures
A distributed Oracle Portal configuration offers improved availability over a single server configuration because you are making more software and hardware resources available to the Web portal. You can use additional servers and software to provide failover, thus ensuring system stability. See Section 2.1.8.2, "Failover and Redundancy" for more information.

- Implementing cache clusters
To increase the availability and scalability of medium to large deployments, you can configure cache clusters. Cache clusters provide failure detection and failover, increasing the availability of your Web site. See Section 1.3, "Understanding Caching in Oracle Portal" for more information.

See Also:

Oracle Fusion Middleware Performance and Tuning Guide

- Choosing optimal cache options for pages, portlet instances, and templates
Caching is the primary way to maximize performance in Oracle Portal. Using a distributed architecture will increase system availability and speed, but cache methodology is by far the most important. To improve performance and scalability, Oracle Portal provides several caching options as described in the chapter on improving page performance in the Oracle Fusion Middleware User's Guide for Oracle Portal.

2.1.4 How Can I Make My Portal Scale?

Redundancy enables you to scale your system by providing identically configured duplicate computers to provide enough capacity to service requests, and provide backups in case of failures and errors.

In addition, you can improve scalability by choosing optimal cache options for pages, portlet instances, and templates. Oracle Portal provides several caching options. For more information, refer to the chapter about improving page performance in the Oracle Fusion Middleware User's Guide for Oracle Portal.

Refer to Section 2.1.8.3, "Scalability" and Section 1.3, "Understanding Caching in Oracle Portal" for more information.

2.1.5 How Can I Make My Portal Highly Available?

Clustering also enables you to achieve a higher level of system availability than is possible with only a single Oracle Fusion Middleware instance. An application running on a single instance of an Oracle Fusion Middleware is dependent on the operating system and host on which the server is running. In this case, the host poses as a single point of failure because if the host goes down, the application becomes unavailable.

See Also:

Oracle Fusion Middleware High Availability Guide

2.1.6 How Can I Secure My Portal?

Sensitive data should be secured without affecting content that you want to make available to all users.

To support a flexible approach to controlling access to Web content, Oracle Portal leverages other components of Oracle Fusion Middleware and Oracle Database 11g to provide strong protection for your portal. Oracle Portal interacts with all of the following components to implement its security model:

- Oracle Application Server Single Sign-On

- mod_osso, an Oracle HTTP Server listener module, which facilitates Single Sign-On for J2EE web applications.

- Oracle Web Cache

- Oracle Internet Directory

- Oracle Delegated Administration Services

- Oracle Directory Integration Platform

See Chapter 7, "Securing Oracle Portal" for more information.

2.1.7 How Should I Configure My Hardware and Software?

This section discusses how you should configure your hardware and software installations for optimal use of Oracle Portal and all related Oracle Fusion Middleware components. This section explains how you can configure your hardware to set up a small development environment, and deploy larger sites serving many users.

2.1.7.1 Using a Single Computer

In the simplest configuration, all of the Oracle Fusion Middleware component pieces are installed on a single computer as shown in Figure 2-1. In fact, a single database could also reside on the computer, containing separate schemas for Oracle Portal, Oracle Internet Directory, and OracleAS Single Sign-On.

Figure 2-1 Oracle Portal Single Computer Configuration

This configuration works nicely in a small development environment in which your developers are using Oracle Portal's declarative interface to build pages, portlets and applications. It also easily supports a small deployment of the finished Web portal. If you expect to deploy a larger site that delivers more content to more users, you will need more than a single server or the simple configuration shown in Figure 2-1.

2.1.7.2 Using Multiple Computers

If a single computer configuration does not suit your needs, consider moving the various pieces of the Oracle Portal architecture to other computers. When configuring your Web portal, you will require more servers depending on the size of your site, where each server performs specialized work. Adding extra hardware increases performance, and adding more software instances supports redundancy.

Deployment options for configuring larger Web portal sites include:

- Separating the Middle Tier from the Oracle Metadata Repository

- Installing Oracle Identity Management Separately

- Adding Middle-Tier Instances

- Installing Oracle Web Cache Separately from the Middle Tier

- Configuring High Availability for the Infrastructure

Perform the tasks in this list until you are satisfied that your configuration can handle the demands of your deployed Web portal. If your site must handle only a moderate workload, you could first separate the middle tier from the database, then consider moving Oracle Identity Management to another server. You probably will not need to perform all of these configuration tasks. But as the site grows, you should expand its underlying configuration by following the sequence shown in this list.

Note:

Before you go online with your Web portal, it's a good idea to set up and test a small pilot system. This enables you to gather valuable configuration and tuning information based on real usage patterns, without affecting the users you plan to serve.

2.1.7.2.1 Separating the Middle Tier from the Oracle Metadata Repository

The first thing you should consider when configuring a larger system is installing the middle tier separately, as shown in Figure 2-2.

See Also:

Oracle Fusion Middleware Performance and Tuning Guide

Figure 2-2 Separating the Fusion Middleware Middle Tier from the Infrastructure

This frees the Oracle Metadata Repository and the middle tier from having to compete for hardware resources, such as I/O, memory, and disk space. Installing them on separate computers also gives you more flexibility in performance tuning. This is important for sites that plan on storing a lot of content in the Oracle Metadata Repository. Tuning parameters, such as those for an operating system, are different from those for middle-tier components such as the HTTP server. Setting a performance parameter for one may not provide optimal performance for another.

2.1.7.2.2 Installing Oracle Identity Management Separately

OracleAS Single Sign-On authenticates user credentials against Oracle Internet Directory for Oracle Portal and other applications, thus requiring users to log on to the Web portal only once with a single user name and password, to enable access to multiple accounts and applications.

Once users have logged in to a deployed Oracle Portal site, they can access any other OracleAS Single Sign-On secured application.

As shown in Figure 2-3, Oracle Identity Management is located on a different computer from the Oracle Metadata Repository. A single instance of Oracle Identity Management can be configured to work with multiple Oracle products, including multiple instances of the Oracle Portal middle tier.

Figure 2-3 Oracle Identity Management Installed on a Separate Computer

The system shown in Figure 2-3 is an example of a distributed configuration. The configuration includes a centralized Oracle Identity Management server that could support multiple middle-tier instances. Moving Oracle Identity Management to its own server gives you the flexibility to tune its performance independently of the database and middle tier.

In addition, isolating Oracle Identity Management from middle-tier installations ensures greater stability for the entire distributed system. If the computer where a middle tier is installed fails, OracleAS Single Sign-On and other middle-tier instances that rely on it to validate logins are not affected. Additionally, different security policies can be used to manage the various computers in the configuration.

See Also:

Oracle Fusion Middleware Installation Planning Guide

2.1.7.2.3 Adding Middle-Tier Instances

You can add redundant middle-tier instances, each with identical configuration settings, to support the largest Web portals. The added middle-tier instances are shown in Figure 2-4. It is a good idea to install each middle-tier instance on its own computer to isolate any hardware failures.

Figure 2-4 Multiple Middle Tiers

The middle tier forwards user requests for portal pages to a provider, then assembles the pages with the returned content. As you add more middle-tier instances to your Oracle Portal configuration, you increase the capacity for user requests and improve the overall performance of your portal. Database and network resources are used more efficiently.

Note:

For this configuration, you must use a Load Balancing Router (LBR). See Section 2.1.8.1, "Load Balancing" for more information.

2.1.7.2.4 Installing Oracle Web Cache Separately from the Middle Tier

You can also separate the Oracle Web Cache server from the middle tier to enable better caching of data, faster request times, and reduction in the load on the middle tier.

Separating the Web Cache can improve performance by making it easier to tune the system, since it is memory intensive rather than CPU intensive. Separating the components can also bring cached data closer to the end user, effectively increasing security by limiting what content is cached "at the network edge" for a given user community. For example, in a typical inside/outside scenario, separate Web Caches can target the community with specific cached content.

2.1.7.2.5 Configuring High Availability for the Infrastructure

In Oracle Fusion Middleware 11g, all Oracle High Availability (HA) solutions, including Cold Failover Cluster, Data Guard, and Real Application Clusters (Oracle RAC), are supported for the OracleAS Infrastructure.

See Also:

Oracle Fusion Middleware High Availability Guide

2.1.8 Getting the Most Out of Your Configuration

A distributed Oracle Portal configuration offers improved performance over a single computer configuration because you are making more software and hardware resources available to the Web portal. But there are other benefits. You can use additional servers and software to provide failover, thus ensuring system stability. And you can deal with wide fluctuations in the amount of work your Web portal is expected to perform over the course of a day using load balancing between multiple servers. Finally, you can add more servers to a distributed configuration to support more users, thus providing scalability.

2.1.8.1 Load Balancing

If you anticipate a heavy volume of traffic on your Web portal, you can distribute the load across multiple servers, each with its own middle-tier instance. If one server is overloaded with too much traffic, a second server can handle the overflow.

Oracle Fusion Middleware provides its own load balancing capability by pooling server instances to service incoming requests. If one instance does not respond, then the request is forwarded to another instance. This ensures that content and applications are always available to users of your deployed site.

For very large sites, you can add load balancing hardware or software to distribute incoming requests to the middle-tier servers. Figure 2-5 shows a Load Balancing Router (LBR), a very fast network device that distributes network requests across a large number of servers, being used for this purpose. This is the most common approach to load balancing, and provides users of your portal with a single published address instead of them having to send each request to a particular middle-tier server.

Figure 2-5 Multiple Server Configuration Using a Load Balancing Router

See Section 6.3, "Configuring Multiple Middle Tiers with a Load–Balancing Router" for more information on adding an LBR to distribute incoming requests to middle-tier servers.

As an example, the high traffic personal site, My.Oracle.com (MOC), uses an LBR to sort requests. Because the software logic for distributing loads is contained in the LBR itself rather than installed separately on each individual middle-tier server, an LBR lowers the overall administrative costs of your configuration. MOC is both an intranet and extranet Web site. It provides Oracle employees with a single customizable entry point to all of Oracle's online services as well business information from external providers.

Adding an LBR can also help your configuration deal with load variations. Users may access your site, use its applications, and request content at a much higher frequency during certain peak intervals, for example, between 9 a.m. and 10 a.m. when most users log on to begin their work day. During these periods of heavy traffic, the LBR can distribute page requests among the various middle-tier instances to ensure quick response times.

If your peak load occurs on a regular basis, consider a configuration that specifically addresses the need to handle peak load requirements. If your peak load is infrequent, you may be willing to tolerate slower response times at peak intervals rather than spend additional money on hardware.

Note that the LBR itself can be configured to support failover. The My.Oracle.com configuration in Figure 2-6 could add a second LBR, which would be available in case the primary router fails.

2.1.8.2 Failover and Redundancy

Failover is the ability to switch to a backup when part of your system fails, such as a server or database. When an Oracle Database 11g fails, for example, it restarts using any preserved state information from the backup.

Redundancy is the technique of providing duplicate computers configured identically. The redundant computers provide enough capacity to service requests, and provide backups in case of failures and errors. You implement redundancy by increasing the number of computers in your configuration. One server is typically active while the other monitors the first server's activity, ready to take over if it fails.

As shown in Figure 2-6, My Oracle.com provides for failover using an additional middle-tier server that can take over if any of the other servers encounter problems that cause them to fail.

Note:

The components depicted in Figure 2-6 represent only one of many possible configurations. Oracle does not expressly recommend or endorse these specific vendors, or components, or both.

Figure 2-6 My Oracle.com Middle-Tier Configuration

To set up redundant middle-tier instances, you configure the original and each redundant instance with identical site name and server port entries, for example, my.oracle.com and port 5000. That is, although the pysical site names and ports can be different, the virtual host references for the redundant tiers must be the same.

One alternative to redundancy is to set up failover by using any excess capacity that you have in your overall configuration. For example, you might have four middle-tier servers, each running at 75% capacity. If one server fails, the other three can take over the workload of the fourth (25% X 3 = 75%, which is the capacity of the failing server).

2.1.8.3 Scalability

Scalability is the ability of a Web portal to handle more requests as the number of users and the volume of content increases over time. As the portal handles more traffic, users should not notice any change in performance, as measured by response intervals and frequency of errors. If scalability is your goal, you need a flexible configuration that will enable you to add database capacity and servers incrementally as needed without adversely affecting the rest of your configuration.

2.2 What Do I Need to Do?

This section describes the task flow involved in planning, installing, configuring, and administering Oracle Portal.

Successfully deploying Oracle Portal consists of the following steps:

1. Planning Your Portal

2. Upgrading Oracle Portal (if necessary)

3. Verifying Pre-Installation Requirements

4. Installing Oracle Fusion Middleware

5. Performing Post-Installation Configuration (basic configuration and administration)

6. Performing Advanced Configuration

7. Securing Oracle Portal

8. Monitoring Oracle Portal

9. Troubleshooting Oracle Portal

The following sections provide high-level descriptions of each step and point to more detailed information in various locations, including this configuration guide, other Oracle Fusion Middleware 11g Documentation Library books, technical white papers, and OTN, http://www.oracle.com/technology/.

2.2.1 Planning Your Portal

If you are new to Oracle Portal, you may benefit from reading Chapter 1, "Understanding the Oracle Portal Architecture" to understand how Oracle Portal fits into the Oracle Fusion Middleware architecture.

You can find more information about planning your Oracle Portal configuration on Portal Center at http://www.oracle.com/technology/products/ias/portal/index.html.

2.2.2 Upgrading Oracle Portal

You will find the latest information on upgrading from an earlier release of Oracle Portal on OTN, http://www.oracle.com/technetwork/middleware/ias/upgrade-087279.html. On the Upgrade page, you will find:

- Instructions for downloading the upgrade scripts.

- Online upgrade documentation.

2.2.3 Verifying Pre-Installation Requirements

To ensure a smooth installation, you must verify that you have fulfilled all prerequisites and have performed all pre-installation steps. The Oracle Fusion Middleware Installation Planning Guide contains the general Oracle Fusion Middleware requirements, while Chapter 3, "Pre-Installation and Post-Installation Tasks" discusses the portal-specific steps.

2.2.4 Installing Oracle Fusion Middleware

The Oracle Fusion Middleware Installation Planning Guide contains the steps for installing the Oracle Fusion Middleware middle tier and infrastructure required to run Oracle Portal. Refer to Chapter 3, "Pre-Installation and Post-Installation Tasks" for additional information.

2.2.5 Performing Post-Installation Configuration

Chapter 5, "Basic Configuration and Administration" contains information about all the post-configuration tasks that can be performed by the Oracle Portal administrator.

You can find additional information on Portal Center at, http://www.oracle.com/technology/products/ias/portal/index.html.

2.2.6 Performing Advanced Configuration

Part III, "Advanced Configuration Topics" is targeted at the Oracle Fusion Middleware administrator. Chapter 6, "Advanced Configuration" provides instructions on how to perform more advanced Oracle Portal configuration and integration configuration, including virtual hosts, load balancing routers, proxy server, Oracle Web Cache, and OracleAS Single Sign-On configuration. Other chapters in Part III deal with setting up features such as search, import and export, and more.

2.2.7 Securing Oracle Portal

Chapter 7, "Securing Oracle Portal" contains in-depth information on how to configure the security features in Oracle Portal.

2.2.8 Monitoring Oracle Portal

You can monitor Oracle Portal through the Oracle Enterprise Manager 11g Fusion Middleware Control. For details, see Chapter 8, "Monitoring and Administering Oracle Portal".

In addition, you can generate performance reports to monitor portal performance. See Appendix G, "Enabling Performance Logging". This performance information will be useful later on, for tuning Oracle Portal performance. See Chapter 11, "Tuning Performance in Oracle Portal".

2.2.9 Troubleshooting Oracle Portal

Appendix G, "Troubleshooting Oracle Portal" discusses various issues and ways for resolving and diagnosing problems.

Part II

Installation and Basic Configuration

Part two contains the following chapters:

- Chapter 3, "Pre-Installation and Post-Installation Tasks"

- Chapter 4, "Interoperability Scenarios"

- Chapter 5, "Basic Configuration and Administration"

3 Pre-Installation and Post-Installation Tasks

This chapter introduces the installation tasks that you must complete before and after installing Oracle Portal. For complete instructions on how to install and configure the infrastructure and the middle tier in different topologies, refer to the Oracle Fusion Middleware Installation Planning Guide.

This chapter contains the following sections:

- Installation Overview

- Accessing Oracle Portal After Installation

- Configuring Oracle Portal During and After Installation

If you are planning to upgrade Oracle Portal from a previous release, you will need to refer to the Upgrade documentation on the Oracle Technology Network (OTN), http://www.oracle.com/technology/products/ias/portal/upgrade.html.

3.1 Installation Overview

Installing Oracle Portal 11g Release 1 (11.1.1) comprises the following stages:

- WebLogic Server Installation

- Infrastructure Component Installation

- Oracle Fusion Middleware Middle-tier Release Installation

3.1.1 WebLogic Server Installation

The WebLogic Server installation consists of the Core Application Server, Administration Console, Configuration Wizard and Upgrade Framework, Web 2.0 HTTP Pub-Sub Server, JDBC Drivers, WebLogic Server Clients, WebLogic Web Server Plug-Ins, UDDI and Xquery Support, and Server Examples. The WebLogic Server installation includes a Oracle WebLogic Server administration domain, which is a logically related group of Oracle WebLogic Server resources. Domains include a special Oracle WebLogic Server instance called the Administration Server, which is the central point from which you configure and manage all resources in the domain. Usually, you configure a domain to include additional Oracle WebLogic Server instances called Managed Servers. Managed Servers host the portal application components, Web services, and their associated resources. You deploy Web applications, EJBs, Web services, and other resources onto the Managed Servers and use the Administration Server for configuration and management purposes only. The Managed Servers can be grouped together into a cluster.

The default Portal managed server is WLS_PORTAL which resides at:

DOMAIN_HOME\config\fmwconfig\servers

Note:

Before you proceed with installing a Oracle Portal, ensure that you have installed WebLogic Server. See Oracle WebLogic Server Installation Guide. The WebLogic Server installation creates the Middleware Home, which is used to install all the Oracle Fusion Middleware components.

3.1.2 Infrastructure Component Installation

The Infrastructure Installation includes:

- Installing Oracle Database

- Installing Oracle Metadata Repository

- Installing Oracle Single Sign-On 10g and Oracle Delegated Administration Services 10g

Note:

See Table 3-1, "Installation Components and Version"

Installing Oracle Database

Oracle Database enables you to store Portal data, update it, and efficiently retrieve it, with a high degree of performance, reliability, and scalability. You must install a supported Oracle Database Release. For more information, see System Requirements and Supported Platforms for Oracle Fusion Middleware 11gR1 http://www.oracle.com/technetwork/middleware/downloads/fmw-11gr1certmatrix.xls on OTN.

See:

Oracle Fusion Middleware Repository Creation Utility User's Guide and Loading Portal Schema Using RCU.

Installing Oracle Metadata Repository

A metadata repository contains metadata for Oracle Portal. It can also contain metadata about the configuration of Oracle Fusion Middleware and metadata for your Portal.

The Oracle Metadata Repository creates a new database and populates it with a collection of schemas used by Oracle Portal components, such as the Oracle Portal metadata schema during an infrastructure installation.

You can use the Repository Creation Utility (RCU) CD-ROM to create multiple repositories in a single database. RCU creates the necessary Portal schemas, refer to Section 3.1.2, "Loading Portal Schema Using RCU" for more information.

When you install Oracle Portal, some default database schemas and user accounts are also installed. Refer to Section 7.3.1, "Configuring Oracle Portal Security Options" in Chapter 7, "Securing Oracle Portal" for a description of the default database schemas.

See:

Oracle Fusion Middleware Installation Planning Guide

Note:

Before proceeding create schemas for the Portal you want to install.

Installing Oracle Single Sign-On 10g and Oracle Delegated Administration Services 10g

Oracle Identity Management enables you to configure and manage the identities of users, devices, and services across diverse servers, to delegate administration of these identities, and to provide end users with self-service privileges. Additionally, you can configure and enable single sign-on access across enterprise applications and restrict access to online resources to users with valid credentials.

Oracle Portal requires Oracle Single Sign-On (SSO) and Oracle Delegated Administration Services (DAS) from the 10g release. If you do not already have access to these 10g components, you must install them in order for your products to function properly. For more information, refer to Oracle Identity Management 10g (10.1.4.0.1) documentation library at http://download.oracle.com/docs/cd/B28196_01/index.htm.

Loading Portal Schema Using RCU

Repository Creation Utility (RCU) is a graphical and CLI-based tool used to create and manage Oracle Fusion Middleware database schemas in your database. Oracle Portal requires schemas in database prior to installation, these schemas are created and loaded in your database using RCU. To create the Portal schemas, perform the following steps:

1. Run rcu.bat, (Windows) from ORACLE_HOME\bin\rcu.bat.

2. The Welcome screen is displayed, click Next.

3. In the Create Repository screen, select Create to load component schemas into a database and click Next to continue.

4. In the Database Connect Detail screen enter the following information:

- Database Type: Select the database type from the drop-down list.

- Host Name: Enter the name of the server where your database is running. Use the following format:
myhost.mydomain.com

For Oracle RAC databases, specify the VIP name or one of the node names in this field.

- Port: Enter the port number for your database. The default port number for Oracle databases is 1521.

- Service Name: Specify the service name for the database. Typically, the service name is the same as the global database name.

- User Name: Enter the user name for your database..

- Password: Enter the password for your database user.

- Role: Select the database user's role from the drop-down list.

Click Next.

The Repository Creation Utility-Checking Prerequisites screen is displayed, click OK when all the prerequisites are meet.

5. In the Select Components screen, enter a prefix to be added to the database schema (for example: MPS), and check only the following check-boxes:

- Check AS Common Schemas and Metadata Services Portal under it.

- Check WebCenter Suite and WebCenter portlets under it.

Click Next.

Click OK, when the prerequisites are validated.

6. In the Schema Passwords screen, enter the schema passwords for each main and additional (auxiliary) schema user.

7. Click next to accept the default settings, in the Map Tablespaces Screen, and then do the following:

- Select Yes to allow the RCU to create any missing tablespaces

- If there are any missing tablespaces. select OK to acknowledge Table space creation.

8. In the Summary Screen (for Create Operation), review the information and click Create to begin schema creation.

9. In the Completion Summary screen, note the location of the log files, then click Close to dismiss the screen. The main RCU log and component log files are written to the following directory:
ORACLE_HOME\rcu\log\logdir.date_timestamp

See:

Oracle Fusion Middleware Repository Creation Utility User's Guide

3.1.3 Oracle Fusion Middleware Middle-tier Release Installation

During the Oracle Fusion Middleware middle-tier installation, Oracle Portal is configured to use the infrastructure services. The deployment of the portal applications in the middle tier also occurs at this time. The following steps are performed at this time:

1. Oracle Web Cache configuration information is stored in the Oracle Portal schema in the Oracle Metadata Repository.

2. User and Group information is created in Oracle Internet Directory.

3. The Oracle Fusion Middleware Provider Group is added to Oracle Portal.

4. Oracle Portal Service Monitoring is configured.

5. The Provider user interface is configured to work with Oracle Portal. The middle-tier URL, used to access the provider user interface framework from Oracle Portal is added to the global settings page.

6. The default Web providers, OmniPortlet and Web Clipping, are registered.

7. The Web Services for Remote Portlets (WSRP) container is installed.
The portal repository database contains the default preference store of this WSRP container. Refer to the Oracle Fusion Middleware Developer's Guide for Oracle Portal for more information.

Note:

Oracle Portal supports communication with any WSRP producer.

8. A sample JSR 168 application is installed to run the WSRP container.

9. Oracle Text and Secure Enterprise Search are configured.

10. The Oracle Portal DAD is created in the configuration file, DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration\portal_dads.conf, using the parameters provided at installation time.

11. The file webcache.xml is created in ORACLE_INSTANCE\config\WebCache\webcache1.
webcache.xml stores Oracle Web Cache invalidation settings and it is used by Web providers such as OmniPortlet and Web Clipping. See the Oracle Fusion Middleware Developer's Guide for Oracle Portal for more information.

The details for these steps are available, after the installation, in the file \Program Files\Oracle\Inventory\logs in Windows and /etc/oraInst.loc in Unix.

Refer to Section 7.1.2.1, "Oracle Portal Default, Seeded User Accounts" and Section 7.1.2.2, "Oracle Portal Default, Seeded Groups" for a description of the Oracle Portal default user accounts and groups.

Out of the box, the initialization parameters for this new database are suitable for a very small Oracle Portal configuration with few users. If you plan to use Oracle Portal, it is recommended that you modify the initialization parameters for the database based on the requirements for installing the Oracle Metadata Repository in an existing database, using the settings specified in the Oracle Fusion Middleware Installation Planning Guide. As you make changes in your configuration, you may need to further tune the initialization parameters based on the size of your configuration, and the number of simultaneous users of Oracle Portal.

3.1.4 Installation Components and Versions

Table 3-1, describes the various installation components and their versions.

Table 3-1 Installation Components and Version

Number of Databases

Oracle WebLogic Server

Infrastructure Components

Oracle Fusion Middleware Mid-Tier

Single Database

10.3.4.0

- Oracle Database: Identity Management and Metadata Repository: 10.2.0.4 or later and 11.1.0.7

- Oracle Metadata Repository: 10.1.4.0.1

- Oracle Single Sign-On 10g and Oracle Delegated Administration Services 10g: 10.1.4.0.1 + PS3+ (Patch:7215628 - 10.1.4.3.0)

- Repository Creation Utility: 11.1.1.4.0

11.1.1.4.0

Two Databases

10.3.4.0

- Oracle Database: Identity Management 10.1.0.5 (seeded) and Metadata Repository 10.2.0.4 or later and 11.1.0.7

- Oracle Metadata Repository: 10.1.4.0.1 (IM)

- Oracle Single Sign-On 10g and Oracle Delegated Administration Services 10g: 10.1.4.0.1 + PS3+ (Patch:7215628 - 10.1.4.3.0)(IM)

- Repository Creation Utility: 11.1.1.4.0 (MR)

11.1.1.4.0

Two Databases

10.3.4.0

- Oracle Database: Identity Management IM: 9.2.0.7, 10.1.0.5 or 10.2.0.2 (colocated) - see Oracle Application Server Metadata Repository Creation Assistant User's Guide and Metadata Repository 10.2.0.4 or later and 11.1.0.7

- Oracle Metadata Repository: 10.1.4.0.1 (IM)

- Oracle Single Sign-On 10g and Oracle Delegated Administration Services 10g: 10.1.4.0.1 + PS3+ (Patch:7215628 - 10.1.4.3.0) (IM)

- Repository Creation Utility: 11.1.1.4.0 (MR)

11.1.1.4.0

3.2 Accessing Oracle Portal After Installation

This section details the steps you should take to access Oracle Portal after installation:

1. Access Oracle Portal by entering the following URL in your browser:

http://<host>:<port>/portal/pls/<dad>

For example:

http://portal.example.com:8090/portal/pls/portal

The Portal Builder page is displayed.

Table 3-2 explains the components that make up the URL used to access Oracle Portal.

Table 3-2 Portal URL Descriptions

Parameter

Description

host

Defines the computer on which you installed Oracle Portal.

Enter both the hostname and the fully qualified domain name. For example, enter host.domain.com.

This name must also match the ServerName parameter in the configuration file, httpd.conf, located in ORACLE_INSTANCE\config\OHS\ohs1.

port

Defines the port number to access Oracle Portal.

This is the Oracle Web Cache Listen Port.

portal

Specifies that the request should be routed to the Portal Services running inside Oracle Portal WLS.

Note: In earlier versions, the Oracle Portal URL was of the format http://<host>:<port>/pls/<dad>. Backward compatibility is provided for such URLs using rewrite rules in the Oracle HTTP Server configuration, so that URLs of the /pls/<dad> format are rewritten to /portal/pls/<dad>. When URLs of the older format are accessed, Oracle Portal either services the URL directly or alerts you to change the bookmarked URL to the new format.

pls

Specifies that the request is for a PL/SQL procedure.

dad

Defines the Database Access Descriptor (DAD) you specified earlier for your Oracle Portal installation. The DAD contains information on how to connect to the database. In a typical default installation, the DAD is 'portal'.

2. Click the Login link, located in the top right corner as shown in Figure 3-1:

Figure 3-1 Login Link

3. Log in as the orcladmin user, using the orcladmin password.
When you login, you go to by default to the Welcome tab Here you can view the documentation library, go to the Quick Tips, and Getting Started with Oracle Portal.

3.3 Configuring Oracle Portal During and After Installation

During a middle-tier installation that includes Oracle Portal, you can specify if you want to configure, and automatically start Oracle Portal at the end of the installation. If you select that option, Oracle Universal Installer (OUI) will configure Oracle Portal.

If you choose Install Only, the Portal will not be configured. To configure the Oracle Portal after the installation, refer to the Install Only section, in the Oracle Fusion Middleware Installation Guide for Oracle Portal, Forms, Reports and Discoverer.

4 Interoperability Scenarios

This chapter lists interoperability scenarios and considerations for Oracle Portal 11g Release 1 (11.1.1).

For related information, see the following documents:

- Oracle Fusion Middleware Installation Guide for Oracle Portal, Forms, Reports, and Discoverer

- Oracle Fusion Middleware Upgrade Guide for Oracle Portal, Forms, Reports, and Discoverer

Interoperability Scenarios

- Oracle Portal 11g Release 1 (11.1.1) with Oracle Reports 11g Release 1 (11.1.1)

- Oracle Portal 11g Release 1 (11.1.1) with Oracle Business Intelligence (BI) Discoverer 11g Release 1 (11.1.1)

- Oracle Portal 11g Release 1 (11.1.1) with Oracle Identity Management 11g Release 1 (11.1.1)

- Oracle Portal 11g Release 1 (11.1.1) with Oracle BPEL Process Manager 11g Release 1 (11.1.1)

- Oracle Portal 11g Release 1 (11.1.1) with Oracle WebCenter Portal 11g Release 1 (11.1.1)

- Oracle Portal 11g Release 1 (11.1.1) with Oracle Identity Management 10.1.4.x

- Oracle Portal 11g Release 1 (11.1.1) mid tier with Oracle Portal 10.1.4.x repository

- Oracle Portal 11g Release 1 (11.1.1) mid tier with Oracle Portal 10.1.2.x repository

- Oracle Portal 11g Release 1 (11.1.1) mid tier with Oracle Identity Management 10.1.4.x and Oracle Portal 10.1.x repository

- Oracle Portal 11g Release 1 (11.1.1) mid tier with Oracle Identity Management/Single Sign-On 10.1.4.x and Oracle Portal 10.1.x repository

- Oracle Portal 11g Release 1 (11.1.1) with Oracle Identity Management 10.1.2.3 and Oracle Single Sign-On/Oracle Delegated Administration Service (DAS) 10.1.2.3

- Oracle Portal 11g Release 1 (11.1.1) with Oracle Access Manager 11g Release 1 (11.1.1)

- Oracle Portal 11g Release 1 (11.1.1) with Secured Enterprise Search (SES) 10.1.8.3. For this interoperability scenario to work, you must download and install Automated Release Update (ARU) 11142341 from https://support.oracle.com.

- Oracle Portal 11g Release 1 (11.1.1) with Secured Enterprise Search (SES) 10.1.8.4. For this interoperability scenario to work, you must download and install Automated Release Update (ARU) 10984348 and 11142341 from https://support.oracle.com.

5 Basic Configuration and Administration

This chapter assumes that Oracle Portal has been installed along with the Oracle Fusion Middleware components and addresses the basic tasks that the portal administrator can perform after installation is complete.

This chapter contains the following sections:

- Getting Started with Oracle Portal Administration

- Finding Out Information About Oracle Portal

- Performing Basic Page Administration

- Configuring Self-Registration

- Setting Up Oracle BPEL Process Definitions for Approvals

- Performing Basic Portal Administration

- Configuring Mobile Support in Oracle Portal

- Managing Users, Groups, and Passwords

- Configuring Browser Settings

- Configuring Language Support

- Configuring Oracle Portal for WebDAV

- Configuring Resource Proxying

5.1 Getting Started with Oracle Portal Administration

Basic Oracle Portal configuration can be performed on the Administer tab available from Oracle Portal. Additionally, there are other administrative tools available to configure Oracle Portal and its related components.

This section will introduce you to the various different administrative tools:

- Using the Oracle Portal Administer Tab

- Using Additional Administrative Tools

5.1.1 Using the Oracle Portal Administer Tab

The Oracle Portal framework provides administrative services, such as access to monitoring and configuration tools, single sign-on, directory integration, caching, and security. A lot of the features needed to manage users and groups, to set up security and search features, and to administer the portal and database are incorporated into a series of dialog boxes accessed through portlets on a portal page.

After you have installed Oracle Portal, you need to log in as an administrator (The default username is orcladmin), to perform various administrative functions. After you have logged in to Oracle Portal, the Portal Builder page is displayed.

Click the Administer tab to view all the subtabs and portlets that help you administer the portal. The Administer tab is shown in Figure 5-1.

Figure 5-1 The Administer Tab on the Portal Builder Page

You will see the following subtabs in the Administer tab screen:

- Portal - This subtab enables you to create users and groups, administer the OracleAS Single Sign-On (SSO) server, and administer other services including Oracle Internet Directory, Secure Enterprise Search, Web Cache, proxy settings, and so on.

- Portlets - This subtab enables you to view the Portlet Repository and its refresh log, and register remote providers and provider groups.

- Database - This subtab enables you to create and edit database schemas, create and edit database roles, and monitor database information like database parameters, memory consumption, and database storage details.

Portal

This subtab under the Administer tab in the Portal Builder page contains the portlets shown in Table 5-1. This subtab is displayed by default when you click the Administer tab.

Table 5-1 Portlets in the Portal Subtab

Portlet Name

Enables You to

Services

- Specify default home page, default style, and so on.

- Administer users and groups in the Oracle Internet Directory or configure the directory settings.

- Administer log registry.

- Set up basic and advanced search features.

- Specify Proxy Server settings.

- Administer and monitor the performance of Oracle Portal and its dependent components such as the Oracle HTTP Server, Portal Services, Oracle Metadata Repository, Secure Enterprise Search, and providers using the Oracle Enterprise Manager 11g Fusion Middleware Control.

- Manage Oracle BPEL process definition, and configuring BPEL callback.

See Chapter 8, "Monitoring and Administering Oracle Portal" for more information on administering the log registry and monitoring Oracle Portal performance.

Transport Set -Export Services

- Export a transport set.

- Browse the status of, download scripts for, reuse, export, or delete transport sets.
See Chapter 12, "Export in Oracle Portal" for more information.

Transport Set -Acquire Services

- Register a database link as source portal.

- Browse or delete source portal registration.

- Acquire a transport set from the source portal to your portal.

- See Chapter 12, "Acquire Transport Set Services" for more information.

Transport Set -Import Services

- Validate a transport set .

- Import a transport set.

- Browse the status of, precheck, import or delete transport sets.

- See Chapter 12, "Import in Oracle Portal" for more information.

Oracle Reports Security

- Define access to Oracle Reports objects.

- Report definition file.

SSO Server Administration

- Edit OracleAS Single Sign-On (SSO) Server configuration.

- Create or edit configuration information for partner applications.

- Create or edit configuration information for external applications.

See Chapter 7, "Securing Oracle Portal" for more information.

Note: You will need to log in as an Oracle Fusion Middleware administrator to change SSO settings.

Oracle Reports Security

- Define access to Oracle Reports objects.

- Report definition file.

User

- Create new users and specify account information.

- Edit or delete users.

Portal User Profile

- Establish the user's preferences and global privilege information in the portal.

Group

- Create groups, assign users to them, and designate group administrators.

- Edit or delete groups.

Portal Group Profile

- Establish the group's preferences and privilege information in the portal.

Portlets

This subtab under the Administer tab in the Portal Builder page contains the portlets shown in Table 5-2.

Table 5-2 Portlets in the Portlets Subtab

Portlet Name

Enables You To

Portlet Repository

- View all local and remote portlets.

- Refresh information about all the portlets in the repository.

- View Portlet Repository refresh log.

Remote Providers

- Add a provider to the portlet repository.

- Change configuration and access information about a provider.

Remote Provider Group

- Register multiple providers with a single URL.

- Edit a Provider Group registration.

Database

This subtab under the Administer tab in the Portal Builder page contains the portlets shown in Table 5-3.

Table 5-3 Portlets in the Database Subtab

Portlet Name

Enables You To

Schemas

- Create new database schemas, or edit existing schemas.

Roles

- Create new database roles, or edit existing roles.

Database Information

- Monitor and view various database related information and parameters.

Database Memory Consumption, Transactions and Locks

- Monitor database jobs.

- View reports and charts of memory consumption and transactions.

- Monitor session and locks.

- Terminate undesirable user sessions.

Database Storage

- Monitor and view various database storage related information.

5.1.2 Using Additional Administrative Tools

For some administrative tasks that cannot be performed through the Oracle Portal Administer tab, you may need to use one of the following tools:

- Oracle Enterprise Manager 11g Fusion Middleware Control

- WebLogic ScriptingTool (WLST) Command-line Utility

- Portal Installation and Configuration Scripts

5.1.2.1 Oracle Enterprise Manager 11g Fusion Middleware Control

Oracle Enterprise Manager 11g Fusion Middleware Control is included when you install Oracle Fusion Middleware. From Oracle Portal's perspective, consider this to be the administration tool for the Oracle Fusion Middleware. Oracle Fusion Middleware Control enables you to perform the following administration and configuration operations:

- Administer clusters

- Start and stop services

- View logs and ports

- Perform real-time monitoring

- Modify the OracleAS Infrastructure services used by an Oracle Fusion Middleware middle tier.

Refer to Chapter 8, "Monitoring and Administering Oracle Portal" for a detailed description of these Oracle Fusion Middleware Control functions.

Most configuration changes for an Oracle Portal instance are made from the Portal home page or one of the component pages accessed from the Portal home page. To open Portal home page from the Oracle Fusion Middleware Control home page, use the navigation sidebar to open the instance, expand Portal folder, and then select the Oracle Portal instance to configure. Refer to "Accessing Oracle Enterprise Manager 11g Fusion Middleware Control" for instructions on how to access Fusion Middleware Control.

5.1.2.2 WebLogic ScriptingTool (WLST) Command-line Utility

The WebLogic Scripting Tool (WLST) is a command-line scripting interface, that helps you to perform administrative tasks and initiate WebLogic Server configuration changes to WebLogic Server instances and domains. For more information, see the WebLogic Scripting Tool Command Reference guide. You can use Portal-specific WLST commands to complete the following administrative and configuration tasks:

- Configuring a Portal DAD Using WLST

- Configuring the Portal Cache Using WLST

- Configuring the Parallel Page Engine Using WLST

- Configuring Portal Web Cache Settings Using WLST

- Configuring Portal Middle Tier

- Configuring Portal Site Attributes

- Configuring Portal Oracle Internet Directory Attributes

See Also:

- Getting Started Using the Oracle WebLogic Scripting Tool (WLST) in the Oracle Fusion Middleware Administrator's Guide

- WebLogic Scripting Tool Command Reference

5.1.2.3 Portal Installation and Configuration Scripts

There are also various scripts, copied to your ORACLE_INSTANCE during the installation of Oracle Portal. These scripts may be needed to perform administrative actions. Refer to Appendix B, "Using Oracle Portal Installation and Configuration Scripts" for a description of these scripts.

5.2 Finding Out Information About Oracle Portal

This section covers the following topics:

- Accessing Oracle Portal in Your Browser

- Finding Your Oracle Portal Version Number

5.2.1 Accessing Oracle Portal in Your Browser

After Oracle Portal is installed, access it by entering the following URL in your browser:

http://<host>:<port>/portal/pls/<dad>

See Table 3-2, "Portal URL Descriptions" for an explanation of the URL components.

For backward compatibility, the old URL syntax is supported in this release. For example, http://<host>:<port>/pls/<dad>.

See Also:

Section 3.1, "Installation Overview"

5.2.2 Finding Your Oracle Portal Version Number

To find your portal version number:

1. Log in as a portal administrator.

2. In the Portal Builder, click the Administer tab.
By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

3. Click the Portal tab.

4. In the Services portlet, click the Global Settings link.
The version number for your Oracle Portal is shown at the bottom of the page.

5.3 Performing Basic Page Administration

This section covers the following topics:

- Setting a Default Home Page

- Setting the System Default Style

- Creating Personal Pages

- Setting the Total Space Allocated for Uploaded Files

- Setting the Maximum File Size for Uploaded Files

- Changing the Page Group Quota

- Specifying an Error Message Page

- Setting the Default Page for Non-Authenticated Users

- Specifying the Default DOCTYPE for Pages

- Removing the Context-Sensitive Help Link

5.3.1 Setting a Default Home Page

The home page is the first page that is displayed to a user after logging in to Oracle Portal. Here's how the logic works:

- If the user has specified a personal home page, that page is displayed when the user logs on.

- If the user has not selected a personal home page, but the portal administrator has set one for him or her, the default home page specified for that user is displayed.

- If the user has not selected a personal home page, but belongs to a default group, the default home page specified for that group is displayed.

- If there is no default home page for the user's default group, or if the user has no default group, then the system default home page is displayed.

Note:

You must be a portal administrator to define a default home page for the system, a group, or a user.

5.3.1.1 Setting the System Default Home Page

If there is no default home page for the user's default group, the system default home page is displayed.

To set the system default home page:

1. In the Services portlet, click Global Settings.
By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

2. Next to the Default Home Page field, click the Browse Pages icon to see a list of pages from which to choose.

Note:

You cannot enter a value in this field; you must select one from the list.

3. Click Return Object next to the page you want to make the system default home page.

4. Click OK to return to the Portal Builder.

Note:

To check that you set the system default home page correctly, log out of the portal and log back in again. When you log back in, you should be taken the page that you specified as the system default home page.

5.3.1.2 Setting a Group's Default Home Page

If the user has not selected a personal home page, but belongs to a default group, the default home page specified for that group is displayed.

To set a group's default home page:

1. In the Portal Group Profile portlet, in the Name field, enter the name of the group for which you want to assign a default home page.
By default, the Portal Group Profile portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

Note:

If you are not sure of the group name, click the Browse Groups icon and select from the list provided.

2. Click Edit.

3. Next to the Default Home Page field, click the Browse Pages icon to see a list of pages from which to choose.

Note:

You cannot enter a value in this field; you must select one from the list.

4. Click Return Object next to the page you want to make the default home page for this group.

5. Click OK.

Note:

Click Reset to remove the group's default home page.

5.3.1.3 Setting a User's Default Home Page

If the user has not selected a personal home page, but you have set one for him or her, the default home page specified for that user is displayed.

To set a user's default home page:

1. In the Portal User Profile portlet, in the Name field, enter the user name of the user for whom you want to assign a default home page.
By default, the Portal User Profile portlet is on the Administer tab of the Portal Builder page.

Note:

If you are not sure of the user name, click the Browse Users icon and select from the list provided.

2. Click Edit.

3. Next to the Default Home Page field, click the Browse Pages icon to see a list of pages from which to choose.

Note:

You cannot enter a value in this field; you must select one from the list.

4. Click Return Object next to the page you want to make the default home page for this user.

5. Click OK.

Note:

Click Reset to reset the user's default home page to the system default home page.

5.3.2 Setting the System Default Style

If you are the portal administrator, you are responsible for selecting a style to serve as the system default.

When a style is deleted, all pages and item regions that used the style revert to the page group default style. If the page group default style is <None>, all pages and regions revert to the system default style.

Note:

To set the system default style, you must be the portal administrator.

To set the system default style:

1. In the Portal Builder, click the Administer tab.

2. Click the Portal subtab.

3. In the Services portlet, click the Global Settings link.
By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

4. In the Default Style section, choose a style from the Display Name list.

Note:

The list includes all public styles in the Shared Objects page group.

5. Click OK to return to the Portal Builder.

5.3.3 Creating Personal Pages

A personal page provides an area within Oracle Portal where authorized users can store and share their own content. Personal pages are located under the Shared Objects page group, and are organized alphabetically by user name.

Note:

To create personal pages for users, you must be the portal administrator.

This section covers the following topics:

- Automatically Creating a Personal Page for New Users

- Creating a Personal Page for an Existing User

5.3.3.1 Automatically Creating a Personal Page for New Users

To configure Oracle Portal to automatically create a personal page for new users:

1. In the Services portlet, click Global Settings.
By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

2. Ensure that you are on the Main tab.

3. Select Create Personal Pages for New Users.

4. Click OK.

Whenever a new user logs on for the first time, a personal page is automatically created for that user.

Note:

Personal pages are automatically created when new users log on for the first time (that is, when the user record is created for the user), not for users that already exist.

5.3.3.2 Creating a Personal Page for an Existing User

To configure Oracle Portal to create a personal page for an existing user:

1. In the Portal User Profile portlet:

1. In the Name field, enter the name of the user for whom you want to create a personal page.

Note:

If you are not sure of the name of the user, click the Browse Users icon and select from the list provided.

2. Click Edit.

By default, the Portal User Profile portlet is on the Administer tab of the Portal Builder page.

2. Ensure that you are on the Preferences tab.

3. Select Create Personal Page.

Note:

If you do not see this check box, the user already has a personal page.

4. Click OK.

Notes:

- Personal pages are accessible from the Navigator in the Shared Objects page group. Any authorized user can drill down into the Personal Pages area of the Shared Objects page group, but they can only view their own personal page, or those personal pages to which they have been granted access.

- Personal pages for users with user names that do not begin with an alphabetic character are located under the Others area of Personal Pages.

- Personal pages cannot be deleted.

5.3.4 Setting the Total Space Allocated for Uploaded Files

You can limit the amount of space provided in your database to store documents uploaded to page groups. See Section 5.3.6, "Changing the Page Group Quota" if you want to limit the amount of space provided for a single page group.

You can also limit the size of individual files that content contributors can upload to page groups. See Section 5.3.5, "Setting the Maximum File Size for Uploaded Files" for more information.

When a user uploads a file to the portal, the upload is monitored in the middle tier to detect whether the total space or maximum file size is exceeded. If either of these limits is exceeded, the upload is terminated and an error message is displayed.

Note:

To set the total space allocated for uploaded files, you must be the portal administrator.

To set the total space allocated for uploaded files:

1. In the Services portlet, click Global Settings.
By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

2. Make sure you are on the Main tab.

3. In the Total Space Allocated radio group, select Limit To to limit the amount of space provided to store files uploaded to the page groups in this portal.

4. In the field, enter the maximum amount of megabytes provided for uploaded files across the whole portal. When this limit is reached, users will no longer be able to upload files to page groups in the portal.

Notes:

- Select No Limit if you do not want to impose a limit for uploaded files.

- The Used Space field displays the amount of space currently used by documents uploaded to page groups in this portal provided that a limit has been set. If no limit has been set you can still find out how much space is being used by clicking Calculate. Note that the calculation may take some time.

5. Click OK.

5.3.5 Setting the Maximum File Size for Uploaded Files

You can limit the size of individual files that users can upload to the page groups in your portal.

You can also limit the total amount of space provided in your database to store documents uploaded to page groups. See Section 5.3.4, "Setting the Total Space Allocated for Uploaded Files" for more information.

When a user uploads a file to the portal, the upload is monitored in the middle tier to detect if the maximum file size or portal file quota is exceeded. If either of these limits is exceeded, the upload is terminated and an error message is displayed.

Note:

To set the maximum file size for uploaded files, you must be the portal administrator.

To set the maximum file size for uploaded files:

1. In the Services portlet, click Global Settings.
By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

2. Make sure you are on the Main tab.

3. In the Maximum File Size radio group, select Limit To to specify the maximum size allowed for individual files uploaded to the portal.

4. In the field, enter the maximum size (in MB) for each individual file uploaded to the portal. If a content contributor attempts to upload a file larger than this size, an error is displayed.

Note:

Select No Limit if you do not want to impose a maximum file size.

5. Click OK.

5.3.6 Changing the Page Group Quota

You can limit the amount of space provided in your page group to store uploaded documents.

Note:

To change the page group quota, you must have at least one of the following privileges:

- Portal administrator

- Manage all privileges on the page group

- Manage all global privileges on all page groups

To change the page group quota:

1. In the Portal Navigator page, click the Page Groups tab.

2. Click Properties next to the page group with which you want to work.

3. In the Page Group Quota section, select Limit to to limit the amount of space provided to store uploaded documents.

4. In the field provided, enter the size limit (in MB) for uploaded documents in the page group. When this limit is reached, users will no longer be able to upload documents to the page group.

Note:

Select No limit if you do not want to impose a limit for uploaded documents.

5. Click OK.

5.3.7 Specifying E-mail (SMTP) Host

Enter the Host Name and Port of your e-mail server so that self-registered users can be informed by e-mail when their accounts are accepted or rejected. The default port for SMTP is usually 25. If you enable self-registered users to log on immediately, this information is not needed.

5.3.8 Specifying an Error Message Page

Oracle Portal enables you to choose the error message page that you want to display to users. You can choose the default system error page, or you can specify your own customized error page.

Oracle Portal includes an error message page (called Sample Error Page) that you can edit to match the look and feel of the other pages in your portal. The Sample Error Page is available under the Portal Design-Time page group and includes a portlet that displays all the diagnostic information. Alternatively, you can create your own error message page in any of your page groups. To do this, you must include the Error Message Portlet on the page and turn caching off.

Note:

By default, the Error Message Portlet is located under the Administration Portlets page of the Portlet Repository.

To specify an error message page:

1. In the Services portlet, click Global Settings.
By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

2. In the Error Page section, select one of the following:

- System Error Page to use the system error page to display full-page error messages to users. The system error page automatically includes all the diagnostic information.

- Error Page to use your own page to display full-page error messages to users. Click the Browse Pages icon to select the error message page that you want to use.

3. Click OK.

5.3.9 Specifying an Error Reporting Style

Oracle Portal enables you to choose the error reporting style that you want to display to users. If you enable Secure Error Reporting, it prints only the toplevel error message. This option could be selected to avoid exposing error codes, cause and actions to the end users.

5.3.10 Setting the Default Page for Non-Authenticated Users

You can specify the default page that is displayed to users after they have logged out, or when they initially access the portal site, by setting the default home page for the PUBLIC (that is, non-authenticated) user.

Note:

You must be a portal administrator to define a default home page.

To set the default page users see when they log out, or when they initially access the site, perform the following steps:

1. In the Portal User Profile portlet, in the Name field, enter PUBLIC.
By default, the Portal User Profile portlet is on the Administer tab of the Portal Builder page.

2. Click Edit.

3. Next to the Default Home Page field, click the Browse Pages icon to see a list of pages from which to choose.

Note:

You cannot enter a value in this field; you must select one from the list.

4. Click Return Object next to the page you want to be displayed when users log out.

5. Click OK.

Note:

Click Reset to remove this setting.

5.3.11 Specifying the Default DOCTYPE for Pages

You can specify a global default doctype that identifies which version of HTML or XHTML it is using for all pages within your portal. Specifying the global doctype setting lets your browser display pages faster.

You identify the version of HTML or XHTML by including a doctype declaration in the code at the begining of the page, such as:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

Some examples of doctypes include:

- HTML 4.01 Compatibility mode

- HTML 4.01 Transitional

- HTML 4.01 Strict

- XHTML 1.0 Transitional

- XHTML 1.0 Strict

Note:

Specifying the doctype does not affect the generated HTML, only the DOCTYPE declaration at the beginning of the HTML.

If you select a strict doctype (for example HTML Strict) some portlet refresh features will be affected due to HTML that is prohibited when using a Strict doctype. Specifically:

- The page assembly timeout option is not shown when editing pages.

- Portlet refresh does not use partial page refresh, instead the whole page is refreshed.

In addition, if you choose the middle image alignment option, your HTML will not validate as Strict. This is because an align attribute has to be used in this case, rather than a CSS attribute and the align attribute does not conform to Strict guidelines.

To specify the doctype for pages in a page group:

1. In the Services portlet, click Global Settings.
By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

2. In the Page DOCTYPE section, select the DOCTYPE to be used as a default for all page groups.

3. Check Allow Page Groups to use a different DOCTYPE to let users override this setting at the page group level, specifying a different doctype for the pages within a specific page group.

4. Click OK.

5.3.12 Removing the Context-Sensitive Help Link

If you have access to SQL*Plus, you can suppress the Context-sensitive Help link that appears in the banner in Oracle Portal wizards, dialog boxes, alerts, and so on. Note that you cannot suppress the "?" icon that appears in the blue bar of wizards, dialog boxes, and alerts.

You cannot perform this task through the user interface; it must be done programmatically through SQL*Plus.

Note:

You must make the following API calls in both the portal schema and in the portal SSO schema.

To remove the context-sensitive help link:

1. Access SQL*Plus.

2. Enter:

exec wwui_api_body.set_display_help (wwui_api_body.DISPLAY_HELP_OFF);
commit;

To reinstate the context-sensitive help link:

1. Access SQL*Plus.

2. Enter:

exec wwui_api_body.set_display_help (wwui_api_body.DISPLAY_HELP_ON);
commit;

5.4 Configuring Self-Registration

To enable users to create their own portal user accounts, you must configure the self-registration feature. After completing this process, the self-registration link is exposed in the Login portlet.

You can set up an approval process for self-registered users so that they cannot log in until their accounts have been approved. When the account has been approved or rejected, the user is notified by e-mail.

If you do not require approval for self-registered users, the user will be able to log in to the portal immediately after registering.

Note:

To set up self-registration, you must be the portal administrator.

To set up self-registration:

1. In the Services portlet, click Global Settings.
By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

2. In the Self-Registration Options section, select Enable Self-Registration.

3. Select No Approval Required if self-registered users can log on to the portal immediately after registering.

4. Select Approval Required if self-registered users need to be approved before they can log on to the portal.

1. Click Configure to set up the approval process.

2. In the Approvers field, enter the names of the users or groups that must approve self-registered users.

Note:

Use a semicolon (;) as the separator between multiple users or groups. Each step of the approval routing can include both users and groups.

3. For Routing Method for Approvers, choose:

- One at a time, all must approve if you want each user or group to be notified in turn and every user or group must approve self-registered users before they can log on.

- All at the same time, all must approve if you want all the users and groups to be notified at the same time and every user or group must approve self-register users before they can log on.

- All at the same time, only one must approve if you want all the users and groups to be notified at the same time, but only one user or group member must approve self-registered users before they can log on.

4. Click Add Step.

5. Repeat steps a to d to add more steps to the approval process.

Notes:

- You do not need to change any other settings on this tab, or any of the settings on the other tabs in this screen.

- The final approver in the approval chain must be privileged to approve the registration requests of users. To do this, grant the Allow account management privilege to the final approver. These privileges can be assigned on the default DAS Edit User page.

- Each approver in the approval chain must have the My Notifications portlet on their page to see and act upon new user accounts that are waiting for approval. The My Notifications portlet can be found under Portal Content Tools in the portlet repository.

6. Click OK to return to the Global Settings screen.

5. Click OK.

6. Go to the home page of your portal.

7. Switch to Edit mode.

8. If the home page of your portal does not already contain a Login portlet, add the Login portlet to the page.
By default, the Login portlet can be found in the SSO/OID page under the Administration page in the Portlet Repository.

9. Next to the Login portlet, click the Edit Defaults icon.

10. Select Enable Self-Registration.

11. In the Self-Registration Link Text field, enter the text that you want users to click to register with the portal.

12. Leave the Self-Registration URL field blank to use Oracle Portal's own self-registration screen.
If you have created your own self-registration screen, enter the URL in this field.

13. Click OK.

5.5 Setting Up Oracle BPEL Process Definitions for Approvals

Oracle Portal includes functionality to manage and control the publishing of content on your portal through the use of approvals. However, if your organization finds that the built-in approvals functionality is somewhat restrictive, you can use Oracle BPEL workflow processes for approvals instead.

5.5.1 Synchronizing BPEL Workflow with Portal Workflow

Oracle BPEL workflow can work alongside Portal's default workflow. However, the workflow status as it changes at the BPEL end must be reflected back to the Portal workflow tables. To achieve this, a WebService is called back from BPEL which updates the Portal tables. The credentials needed to establish the connection to the Portal approval schema must be defined in datasource.xml.

5.5.1.1 Deploying the Call Back WebService

To deploy the callback webservices from BPEL:

1. Add a new JNDI entry in the datasources.xml file located in the WLS_PORTAL. Specify the JNDI name as PortalApprovalDS.
To add a datasource entry:

1. Log on to the Oracle WebLogic Administration console.

2. If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.

3. In the Domain Structure tree, expand Services > JDBC, then select Data Sources.

4. On the Summary of Data Source Page, click New.

5. On the JDBC Data Source Properties page, enter jdbc/PortalApprovalDS as the name for the JDBC data source,

6. Select Oracle as the Database Type and Oracle's Driver (Thin) Version XXXXXX as the Database Driver.

7. Click Next to continue.

8. On the Transactions Option page, select global transaction options and accept the default setting, then click Next.

9. On the Connection Properties page, enter the Database Name, Host Name, Port, Database user Name (approval schema name and password, for example: <<PORTAL_SCHEMA_NAME>>_APPROVAL) and click Next.

10. On the Test Database Connection page, review the connection parameters and click Test Configuration.

11. On the Select Target Page, select WLS_PORTAL as the sever to deploy the data source.
If you are using a cluster portal, you need to specify the Portal machine name to the cluster address by login to your WebLogic Administration console and selecting your Domain Name > Environment > Clusters > Cluster Address. After entering the required information you have to restart the managed server (WLS_PORTAL).

12. Click Finish to save the JDBC data source configuration and deploy the data source to the selected targets.

2. Deploy the WSPortalApproval.ear file, located at ORACLE_HOME\archives\applications to the managed server WLS_PORTAL using Oracle WebLogic Server Administration console.
To deploy the application:

1. Log on to the Oracle WebLogic Administration console.

2. If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.

3. In the left pane of the Console, select Deployments.

4. In the right pane, click Install.

5. Using the Install Application Assistant, locate the WSPortalApproval.ear file and click Next.

6. Select the server (from the list of available servers) under which this needs to be installed ( The default server is WLS_PORTAL).

7. Accept the default values in the next screen and click Finish. The deployment will be in Prepared state, select Start to make it Active.

3. Navigate to DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user and verify that the WSPortalApproval folder is created.

4. After the deployment ensure that the deployed web service is accessible in the following way:
http_protocol://wls_hostname:wls_port/bpel/WSPortalApproval.

5.5.1.2 Configuring Portal for BPEL

Once the Callback Webservices is sucessfully deployed, perform the following step to enable BPEL for portal:

1. Login to your Oracle Portal.

2. Click the Administer tab, and then select the Portal subtab.

3. Under Services, select Configure BPEL Callback.
The Configure BPEL callback page is displayed.

4. In the Callback Endpoint field, enter the callback service URL which is obtained in Step 1. For example, http_protocol://wls_hostname:wls_port/bpel/WSPortalApproval.

5. Click OK.

5.5.2 Securing your Portal for BPEL Business Process

Oracle Portal uses secure socket layer (SSL) to secure communication with the BPEL business process which is the human workflow composite deployed on the SOA Server. Perform the following task to secure the end to end Portal BPEL communication:

- Configuring Outbond SSL to BPEL Server

- BPEL Server Callback to Portal

For more information on Portal security, see Chapter 7, "Securing Oracle Portal".

5.5.2.1 Configuring Outbond SSL to BPEL Server

To secure communication from Portal Repository to BPEL server, perform the following steps:

- Configuring the BPEL Business Process to use SSL

- Import BPEL Server Certificates into Portal Database Wallet

5.5.2.1.1 Configuring the BPEL Business Process to use SSL

Before you start, ensure that your BPEL business process is deployed on a SOA managed server. To configure SSL perform the following task:

Enabling SOA Managed Server for SSL

To enable the SOA managed server, perform the following tasks:

1. Login to the Oracle WebLogic Administration Console.

2. If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.

3. In the left pane of the Console, expand Environment and select Servers.

4. In the Servers table, click the SOA Managed Server instance.

5. Select SSL Listen Port Enabled, and enter the SSL Listen Port number.

Obtaining Keys and Certificates,

After you have enabled the SSL for the SOA managed server, do the following:

1. Obtain digital certificates, private keys, and trusted CA certificates for a SOA WebLogic Managed Server using the CertGen utility, Sun Microsystem's keytool utility. Digital certificates, private keys, and trusted CA certificates can be obtained from a reputable vendor such as Entrust or Verisign by sending the certificate request created using the utilities mentioned. For testing purpose you can also use the digital certificates, private keys, and trusted CA certificates provided by the WebLogic Server kit.

2. Store the private keys, digital certificates, and trusted CA certificates. Private keys and trusted CA certificates in a keystore assigned for SSL.

Note:

The preferred keystore format is JKS (Java KeyStore). Oracle WebLogic Server supports private keys and trusted CA certificates stored in files or in the WebLogic Keystore provider for the purpose of backward compatibility only.

Configuring the Identity and Trust Keystore

For configuring the identity and trust key store for the WebLogic Managed Server, you need to use the WebLogic Administration Console and perform the following steps:

1. Login to the Oracle WebLogic Server Administration Console.

2. If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.

3. In the left pane of the Console, expand Environment and select Servers.

4. Select your SOA WebLogic Managed server.

5. Select Configuration > Keystores.

6. In the Keystores field, select Custom Identity and Custom Trust.

7. In the Identity section, define attributes for the identity keystore:

1. Custom Identity Keystore: The fully qualified path to the identity keystore.

2. Custom Identity Keystore Type: The type of the keystore.

3. Custom Identity Keystore Passphrase: The password you will enter when reading or writing to the keystore. This attribute is optional or required depending on the type of keystore. All keystores require the passphrase in order to write to the keystore. However, some keystores do not require the passphrase to read from the keystore. WebLogic Server only reads from the keystore so whether or not you define this property depends on the requirements of the keystore.

8. Click Save.

9. To activate these changes, in the Change Center of the Administration Console, click Activate Changes.

After you have configured the Keystore, you need to configure it for SSL, see Servers: Configuration: SSL and Configure two-way SSL in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help.

5.5.2.1.2 Import BPEL Server Certificates into Portal Database Wallet

After the BPEL business process is configured to use SSL, you need to make the Portal Repository communicate to the SOA server with https. To enable this communication, Portal Database wallet must store BPEL business process managed server CA trusted certificate into its truststore. Secure communication is required when the BPEL process URL is used inside Portal Repository during you registration of WSDL and Endpoint URLs for the process deployed in the BPEL server and SOAP Request to BPEL server when the item ( participating in the bpel workflow ) gets uploaded on the page.

Creating an Empty Wallet (HTTPS)

Create an empty wallet to establish the trust points for SSL access to the OracleAS Single Sign-On. To do this, perform the following steps:

1. Open the Oracle Wallet Manager on the ORACLE_HOME. Note that you can run Oracle Wallet Manager from any location, as long as the generated wallet is accessible from the portal schema in the Oracle Metadata Repository. You can also save the wallet (the directory containing the wallet files) anywhere and move it to another location that is accessible from the portal schema in the Oracle Metadata Repository.

2. Choose Wallet > New.
On UNIX, the wallet is stored in the following location by default:

/etc/ORACLE/WALLETS/<Account Name creating the Wallet>

On Windows, the wallet is stored in the following location by default:

\Documents And Settings\<Account Name creating the Wallet>\ORACLE\WALLETS

3. Create a password for the wallet.

4. Enter the same password in the Confirm Password field.

5. Select Standard for Wallet Type.

6. Click OK.

7. Click Yes to accept the option to create a Certificate Request.

8. Fill out the Certificate Request dialog with details that uniquely identify your server, and click OK. A dialog will inform you that the certificate request was created successfully. The Certificate node in the Wallet Navigator will change to Requested.

9. Send the CR to the chosen Certificate Authority (CA).

10. You must add the Trusted Root Certificate to the Wallet, as shown in "Adding the Trusted Root Certificate to the Wallet (HTTPS)".

11. Save the wallet in a convenient directory, for example:

INFRA_ORACLE_HOME\wallets

12. Choose Wallet > Save.

Adding the Trusted Root Certificate to the Wallet (HTTPS)

Perform the steps in this section only if you do not have the trusted root certificate of the OracleAS Single Sign-On server's issuing certificate authority listed in the Trusted Certificates list. In this case, you must add the Trusted Root Certificate to the Wallet as shown in the following steps, which are based on the Internet Explorer browser:

1. Using the browser, go to the OracleAS Single Sign-On home page, https://infra.domain.com/pls/orasso. Ensure that this is on an HTTPS URL.

1. If the certificate on the server is not automatically trusted by your browser, the Security Alert dialog box is shown.

2. Click View Certificate.

3. Click the Certification Path tab.

4. Select the Certificate Authority Root, which is the first certificate in the list.

5. Click View Certificate.

6. Click Install Certificate.
This brings up the Certificate Import Wizard. This will import the certificate into the browser's list of trusted certificate authorities.

7. Click Next.

8. Select Automatically select a certificate store based on the type of certificate.

9. Click Next.

10. Click Finish.
The trusted root certificate is installed in your browser.

2. Click the lock icon in the status bar to bring up the Certificate dialog box.

3. Click the Certification Path tab.

4. Select the Certificate Authority Root, which is the first certificate in the list.

5. Click View Certificate.

6. Click the Details tab.

7. Click Copy to File....
This brings up the Certificate Export Wizard.

8. Click Next.

9. Under Select the format you want to use, select Base-64 encoded X.509 (.CER).

10. Click Next and specify a file name for the certificate. You can provide any filename for the certificate with a .cer extension.

11. Click Next and then Finish.

At this point, a .cer certificate file is created, which contains the trusted certificate authority's root certificate. This certificate must be added to the Wallet's list of Trusted Certificates. To accomplish this, assuming that the wallet manager is already running and the empty wallet has been opened, perform the following steps:

1. Right-click the Trusted Certificates node.

2. Select Import Trusted Certificate....

3. Select Paste the certificate, and click OK.

4. Copy the contents of the certificate file you created earlier into the text area for the BASE64 format certificate, and then click OK.

5. Verify that the Certificate Authority Root has been added to the list of trusted certificates.

6. Save the wallet.

7. You can also set the auto login feature, check Wallet > AutoLogin, if it is not already checked. This feature enables PKI-based access to services without a password, is required for most wallets. It is required for database server and client wallets. It is only optional for products that take the wallet password at the time of startup.

Note:

If the BPEL workflow app is configured to use two-way SSL, then you have to import the DB wallet CA's (certificate authority) trusted certificate, into the truststore of soa-server).

5.5.2.2 BPEL Server Callback to Portal

The Portal Callback URL used by clients, has to be secured in the following scenarios:

- BPEL enabling Portal (Registration of Portal Callback URL with Portal Repository)

- Status query of Callback URL on the Global Settings Page (Portal Repository)

- Once the approval done by the user on the BPEL server, it tries to intimate Portal Repository through the call back URL.

To secure the Portal Callback Webservice communication perform the following:

- Configuring Portal Callback Webservices for 2-Way SSL

- Configuring the Oracle BPEL Process for Identity and Trust Keystore

- Configuring Portal Database for Identity and Trust Keystore

- Enabling BPEL Business Process for Authentication with Portal Callback Webservice

- Enabling Portal Repository Client for Authentication with Portal Callback Webservice

- Registering the Database Wallet to the Portal Preference Store

5.5.2.2.1 Configuring Portal Callback Webservices for 2-Way SSL

To configure Portal Webservices

1. If you have not deployed WSPortalApproval.ear, you need to deploy it to your WLS_PORTAL managed server as explained in Section 5.5.1.1, "Deploying the Call Back WebService".

2. Enable SSL for WSPortalApproval.ear in your managed server (WLS_PORTAL), do the following:

- Login to the Oracle WebLogic Administration Console.

- If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.

- In the left pane of the Console, expand Environment and select Servers.

- In the Servers table, click the WLS_Portal Managed Server instance.

- Select SSL Listen Port Enabled, and enter the SSL Listen Port number.

3. Obtain the identity and trust Keystore for the Portal manged server (WLS_Portal) (See, Configuring the Identity and Trust Keystore).

4. Configure the Keystore for SSL, see Servers: Configuration: SSL and Configure two-way SSL in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help.

5.5.2.2.2 Configuring the Oracle BPEL Process for Identity and Trust Keystore

For configuring the identity and trust keystore, do the following:

1. Deploy the Oracle BPEL processes on your SOA managed server (soa_server).

2. Obtain the identity and trust Keystore for the SOA manged server (See, Configuring the Identity and Trust Keystore).

5.5.2.2.3 Configuring Portal Database for Identity and Trust Keystore

You need to create a Wallet, to store your identity and trust keystore, see Creating an Empty Wallet (HTTPS) and Adding the Trusted Root Certificate to the Wallet (HTTPS)

5.5.2.2.4 Enabling BPEL Business Process for Authentication with Portal Callback Webservice

The BPEL Business Process requires to present its identity for authentication with the Portal managed server ( configured for two-way SSL). For this use your Keytool's export and import commands to perform the following:

- Export the SOA managed server's CA trusted certificate to a text file in BASE 64 encoded format (soa_server_trusted.cer).

- Export the Portal managed server CA's trusted certificate to a text file in BASE 64 encoded format (portal_server_trusted.cer>.

- Import the SOA managed CA's (certificate authority) trusted certificate (soa_server_trusted.cer), into the truststore of Portal Managed Server.

- Import the Portal wallet CA's (certificate authority) trusted certificate (portal_server_trusted.cer), into the truststore of Portal Managed Server.

5.5.2.2.5 Enabling Portal Repository Client for Authentication with Portal Callback Webservice

The Portal managed server which is configured as two-way SSL, it needs the wallet to present its identity for authentication, for this do the following:

- Export the wallet CA's trusted certificate to a text file in BASE 64 encoded format. (for exporting from the wallet, you can use Oracle Wallet Manager or orapki utility)

- Import the Portal wallet CA's (certificate authority) trusted certificate (exported into a file in the previous step), into the truststore of Portal Managed Server.

- Import the Portal wallet CA's (certificate authority) trusted certificate (portal_server_trusted.cer), into the truststore of Portal DB Wallet.

5.5.2.2.6 Registering the Database Wallet to the Portal Preference Store

If your Portal Repository is not registered to use a database wallet, then you need to register it by running secwc.sqlscript, located at ORACLE_HOME\portal\admin\plsql\wwc)

Example 5-1 Registering the Wallet

cd $ORACLE_HOME/portal/admin/plsql/wwc sqlplus <portal_schema/<portal_pwd>@connectstring sql> @secwc.sql <wallet_location>, <wallet_pwd>sql> @secwc.sql 'file:/u01/app/oracle/product/1021_prodee/dbwallet', 'welcome1'

5.5.3 Creating a New BPEL Process Definition

Before page group administrators and page owners can use Oracle BPEL workflow processes for approvals, you first need to create a process definition that points to those workflow processes.

Note:

This assumes that the Oracle BPEL processes have already been created and deployed.

1. In the Services portlet, click BPEL Process Definition Settings.
By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

2. Click Create New BPEL Process Definition.

3. In the Process Name field, enter the name of the Oracle BPEL process.
Page group administrators and page designers use this name to identify the process when selecting which process to use for their page group or page. The name should be the same as the name used to identify the process in Oracle BPEL and should not contain any spaces or special characters.

4. In the Description field, enter a description of the behavior of the Oracle BPEL process.
While this field is optional, providing a description will greatly aid page group administrators and page designers when they are selecting a process to use for their page group or page. The description can contain up to 4000 characters and can include spaces but not special characters.

5. In the Process Deployment Location field, enter the URL where the Oracle BPEL process is deployed. This is also known as the endpoint. You can obtain this endpoint from the process deployed in the SOA server.
If this URL is not accessible directly from Oracle Portal, make sure you have set up the global proxy definition. See Section 6.5, "Configuring Oracle Portal to Use a Proxy Server."

6. In the Process WSDL Location field, enter the URL to the Oracle BPEL process's description document, or .wsdl file. Oracle Portal must have read permissions on this .wsdl file.
If this URL is not accessible directly from Oracle Portal, make sure you have set up the global proxy definition. See Section 6.5, "Configuring Oracle Portal to Use a Proxy Server."

7. In the Process Operation field, enter the name of the operation that Oracle Portal should trigger when this Oracle BPEL process definition is called. The WSDL document should describe this operation.

8. Click OK to create the Oracle BPEL Process Definition.

9. A confirmation screen lets you know whether the definition was created successfully. If the definition was not created successfully, check the settings and try again.
If your BPEL process definition was created successfully, click Close.

5.5.4 Editing an Existing BPEL Process Definition

You can edit an existing BPEL process definition if there are no items involved in the workflow. The business process will be locked if there any items in it.

1. In the Services portlet, click BPEL Process Definition Settings.
By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

2. Click the name of the BPEL process definition that you want to edit.

3. Edit the fields as required. For information about these fields, see Section 5.5.3, "Creating a New BPEL Process Definition."

Note:

You cannot edit the Process Name field.

4. Click OK to save your changes.

5. A confirmation screen lets you know whether the changes you made were successful. If the changes were not successful, check the settings and try again.
If your changes were successful, click Close.

5.5.5 Deleting an Existing BPEL Process Definition

You can delete an existing BPEL process definition if required.

1. In the Services portlet, click BPEL Process Definition Settings.
By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

2. In the table, click the delete icon next to the BPEL process definition that you want to delete.

3. Check the details to make sure that this is the BPEL process definition that you want to delete.

4. Click Delete to continue with the operation, or Cancel if you have changed your mind.

5. Click Close.

5.5.6 Oracle Portal Message Schema

Oracle Portal initiates any Oracle BPEL workflow process through a SOAP message over HTTP. It also sends payload information including the URL of the item so that approvers can view it.

Example 5-2 shows a sample Oracle Portal message schema to illustrate the kind of information included in the message payload. The designer of the Oracle BPEL workflow process should use this information when creating the process (.XSD) file.

Example 5-2 Sample Oracle Portal Message Schema

<complexType>
<sequence>
<element name="title" type="string"/>
<element name="payload">
<complexType>
<sequence>
<element name="itemType" type="string"/>
<element name="url" type="string"/>
<element name="status" type="string"/>
<element name="date" type="string"/>
<element name="Originator" type="string"/>
<element name="description" type="string"/>
<element name="pageName" type="string"/>
<element name="pageDisplayName" type="string"/>
<element name="pageGroupName" type="string"/>
<element name="subject" type="string"/>
<element name="itemVersion" type="string"/>
<element name="itemExpiry" type="string"/>
<element name="itemDisplayOption" type="string"/>
<element name="author" type="string"/>
<element name="defaultLanguage" type="string"/>
</sequence>
</complexType>
</element>
<element name="itemId" type="integer"/>
<element name="pageId" type="integer"/>
<element name="siteId" type="integer"/>
<element name="submitter" type="string"/>
<element name="approvalId" type="integer"/>
<element name="instanceId" type="integer"/>
<element name="portalWSUrl" type="string"/>
<element name="content_manager">
<complexType>
<sequence>
<element name="userCount" type="integer"/>
<element name="users" type="string" minOccurs="0" maxOccurs="10"/>
</sequence>
</complexType>
</element>
<element name="page_manager">
<complexType>
<sequence>
<element name="userCount" type="integer"/>
<element name="users" type="string" minOccurs="0" maxOccurs="10"/>
</sequence>
</complexType>
</element>
<element name="page_group_manager">
<complexType>
<sequence>
<element name="userCount" type="integer"/>
<element name="users" type="string"/>
<element name="groupCount" type="integer"/>
<element name="groups" type="string"/>
</sequence>
</complexType>
</element>
</sequence>
</complexType>

Table 5-4 describes the different elements in the message payload.

Table 5-4 Message Payload Details

Element

Description

title

The display name of the item

itemType

The item type of the item, for example, text, file, url

url

The URL that points to the item

status

The status of the item

date

The date when the item was submitted

Originator

The creator of the item.

description

The description of the item.

pageName

The internal name of the page containing the item

pageDisplayName

The title of the page containing the item

pageGroupName

The name of the page group that owns the page containing the item.

subject

Information sent by Oracle Portal to Oracle BPEL to explain why the message is being sent

itemVersion

The version number of the item

itemExpiry

The expiry date of the item

itemDisplayOption

The display option for the item

author

The name of the author as specified by the user who submitted the item

defaultLanguage

The default language of the portal

itemId

Internally generated ID for the item

pageId

Internally generated ID for the page

siteId

Internally generated ID for the page group

submitter

The user who submitted the item

approvalId

instanceId

The instance ID through which the item was added

content_manager

List of users with Manage Content privileges on the page containing the item. Use this to extract the specific user names of users with these privileges to use them as approvers in the Oracle BPEL workflow process.

page_manager

List of users with Manage privileges on the page containing the item. Use this to extract the specific user names of users with these privileges to use them as approvers in the Oracle BPEL workflow process.

page_group_manager

List of users with Manage All privileges on the page group that owns the page containing the item. Use this to extract the specific user names of users with these privileges to use them as approvers in the Oracle BPEL workflow process.

5.5.7 BPEL Callback Webservice Proxy

Oracle Portal requires any Oracle BPEL workflow process to add a callback service before you deploy the business process.

Example 5-3 and Example 5-4, shows a sample callback proxy service to illustrate a Reject or Approval step. The designer of the Oracle BPEL workflow process can use this information when creating the process.

Example 5-3 Reject Callback Webservice

try
{
portalwsproxy.proxy.WSPortalApprovalSoapHttpPortClient client =
new portalwsproxy.proxy.WSPortalApprovalSoapHttpPortClient();

oracle.xml.parser.v2.XMLElement elm ;
elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:portalWSUrl");
org.w3c.dom.Node node = (org.w3c.dom.Node) elm.getFirstChild();
String portalWSUrl = node.getNodeValue();
System.out.println("portalWSUrl = " + portalWSUrl);
client.setEndpoint(portalWSUrl);

elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:itemId");
node = (org.w3c.dom.Node) elm.getFirstChild();

System.out.println("Itemid = " + node.getNodeValue());
java.math.BigDecimal itemId = new java.math.BigDecimal(node.getNodeValue());

elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:pageId");
node = (org.w3c.dom.Node) elm.getFirstChild();

System.out.println("Pageid = " + node.getNodeValue());
java.math.BigDecimal pageId = new java.math.BigDecimal(node.getNodeValue());

elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:siteId");
node = (org.w3c.dom.Node) elm.getFirstChild();

System.out.println("Siteid = " + node.getNodeValue());
java.math.BigDecimal siteId = new java.math.BigDecimal(node.getNodeValue());

elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:approvalId");
node = (org.w3c.dom.Node) elm.getFirstChild();

System.out.println("approvalId = " + node.getNodeValue());
java.math.BigDecimal approvalId = new java.math.BigDecimal(node.getNodeValue());

elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:instanceId");
node = (org.w3c.dom.Node) elm.getFirstChild();

System.out.println("instanceId = " + node.getNodeValue());
java.math.BigDecimal instanceId = new java.math.BigDecimal(node.getNodeValue());

client.reject(itemId,pageId,siteId,instanceId,approvalId);
}
catch(java.rmi.RemoteException remoteException)
{
System.out.println("REJECT  "+remoteException);
System.out.println("An exception occured while trying " +
" connect to portal");
remoteException.printStackTrace();
}
catch(Exception exception)
{
System.out.println("REJECT_OTHERS "+ exception);
exception.printStackTrace();
}

Example 5-4 Approve Callback Webservice

try
{
portalwsproxy.proxy.WSPortalApprovalSoapHttpPortClient client =
new portalwsproxy.proxy.WSPortalApprovalSoapHttpPortClient();

System.out.println("INSIDE THE APPROVE section");
oracle.xml.parser.v2.XMLElement elm ;

elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:portalWSUrl");
org.w3c.dom.Node node = (org.w3c.dom.Node) elm.getFirstChild();
String portalWSUrl = node.getNodeValue();
System.out.println("portalWSUrl = " + portalWSUrl);
client.setEndpoint(portalWSUrl);

elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:submitter");
node = (org.w3c.dom.Node) elm.getFirstChild();
System.out.println("submitter = " + node.getNodeValue());
String submitter = new String(node.getNodeValue());

elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:itemId");
node = (org.w3c.dom.Node) elm.getFirstChild();

System.out.println("Itemid = " + node.getNodeValue());
java.math.BigDecimal itemId = new java.math.BigDecimal(node.getNodeValue());

elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:pageId");
node = (org.w3c.dom.Node) elm.getFirstChild();
System.out.println("pageid = " + node.getNodeValue());
java.math.BigDecimal pageId = new java.math.BigDecimal(node.getNodeValue());

elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:siteId");
node = (org.w3c.dom.Node) elm.getFirstChild();
System.out.println("Siteid = " + node.getNodeValue());
java.math.BigDecimal siteId = new java.math.BigDecimal(node.getNodeValue());

elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:approvalId");
node = (org.w3c.dom.Node) elm.getFirstChild();
System.out.println("approvalid = " + node.getNodeValue());
java.math.BigDecimal approvalId = new java.math.BigDecimal(node.getNodeValue());

elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:instanceId");
node = (org.w3c.dom.Node) elm.getFirstChild();
System.out.println("instanceid = " + node.getNodeValue());
java.math.BigDecimal instanceId = new java.math.BigDecimal(node.getNodeValue());

client.approve(itemId,pageId,siteId,submitter,instanceId,approvalId);
}
catch(java.rmi.RemoteException remoteException)
{
System.out.println("INSIDE APPROVE  " + remoteException);
System.out.println("An exception occured while trying " +
" connect to portal");
remoteException.printStackTrace();
}
catch(Exception exception)
{
System.out.println("INSIDE APPROVE WHEN_OTHERS " + exception);
exception.printStackTrace();
}

5.6 Performing Basic Portal Administration

This section covers the following topics:

- Simplifying the Full URL of an Oracle Portal Instance

- Configuring Oracle HTTP Server to Use the Oracle Portal Home Page

- Stopping and Starting Portal Components Using Fusion Middleware Control

- Configuring a Portal DAD Using Fusion Middleware Control

- Configuring a Portal DAD Using WLST

- Configuring the Portal Cache Using Fusion Middleware Control

- Configuring the Portal Cache Using WLST

- Clearing the Portal Cache

- Configuring the Portal Parallel Page Engine

- Retrieving the Portal Schema Password

- Using a Custom Image Directory

5.6.1 Simplifying the Full URL of an Oracle Portal Instance

You can simplify the full URL created by the Oracle Portal installation to a more memorable or meaningful URL using the Redirect directive. In this way, end users can access Oracle Portal by entering a simple URL.

By default, the URL for a new Oracle Portal installation requires you to enter:

http://<host>:<port>/portal/pls/<dad>

You can simplify this URL to:

http://<host>/<redirectpath>

Note:

Do not simplify the Oracle Portal URL to http://<host>:<port>/portal. This is because Oracle Portal is already mounted on /portal.

1. Open the Oracle HTTP Server configuration file, httpd.conf, which is located in the following directory:

ORACLE_INSTANCE\config\OHS\ohs1

2. Enter the redirect path as follows:

Redirect /<redirectpath> http://<host>:<port>/portal/pls/<dad>

For example:

Redirect /portalhome http://mysite.oracle.com/portal/pls/portal

In this example, end users can enter:

http://mysite.oracle.com/portalhome

to access the full URL, which is:

http://mysite.oracle.com/portal/pls/portal

Notes:

- The example http://mysite.oracle.com/portalhome assumes that the default port is being used. If the default port is not being used, then the user would have to enter the URL with the port number, http://mysite.oracle.com:<port>/portalhome.

- You can also edit the httpd.conf file using the Oracle Enterprise Manager 11g Fusion Middleware Control. After you edit the httpd.conf file you can restart the Oracle HTTP Server using the Oracle Enterprise Manager 11g Fusion Middleware Control.

3. Restart the HTTP server by executing the following command from ORACLE_INSTANCE\bin\opmnctl:

opmnctl restartproc type=ohs

You can also restart HTTP server by using the Oracle Enterprise Manager 11g Fusion Middleware Control.

5.6.2 Configuring Oracle HTTP Server to Use the Oracle Portal Home Page

To set the Oracle Portal home page as the Oracle HTTP Server's default home page:

1. In the directory ORACLE_INSTANCE\config\OHS\ohs1\htdocs, make a backup copy of the files welcome-index.html and welcome-index.html.<lang>, where <lang> is the language code. For example, welcome-index.html.en is the index HTML file for English.

2. Edit welcome-index.html.<lang> by replacing the entire contents of the file with the following HTML redirection code:

<HTML>
<SCRIPT LANGUAGE=JavaScript>
document.location="http://<host>.<domain>:<port>/portal/pls/<dad>"
</SCRIPT>
</HTML>

Notes:

- Do not specify a port number if you are running Oracle Portal on port 80 or 443.You will need to specify a port number if you are running Oracle Portal on port 8090.

- If you plan to support other languages, you need to have the language-specific index HTML files with the redirection code, for these languages.

5.6.3 Stopping and Starting Portal Components Using Fusion Middleware Control

Portal components typically need to be restarted following a configuration change.

Follow the steps below to stop, start, or restart a component using Fusion Middleware Control:

1. Navigate to the Fusion Middleware Control instance for the appropriate farm.
See "Accessing Oracle Enterprise Manager 11g Fusion Middleware Control" for more information.

2. Navigate to the home page for your Oracle Portal instance.
See Section 8.2, "Using Fusion Middleware Control to Monitor and Administer Oracle Portal" for more information.

3. Locate the Related Components portlet.

4. In the Name column of the Related Components portlet, click on the component to start or stop.

5. From the component menu, select Control.

6. Do one of the following:

- Click Stop to stop the component.

- Click Start to start the component.

5.6.4 Configuring a Portal DAD Using Fusion Middleware Control

A Database Access Descriptor (DAD) is a set of values that specify how an application connects to an Oracle Database to fulfill an HTTP request. The information in the DAD includes the user name (which also specifies the schema and the privileges), password, connect-string, and Globalization Support language of the database.

There are two types of DADs: general DADs and portal DADs. An Oracle Portal middle tier uses a portal DAD to access the Oracle Metadata Repository, and this section describes how you can create, edit, or delete a Portal DAD. For information on general DADs, refer to the Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server.

Creating a Portal DAD

A Portal DAD is automatically created when Oracle Portal is installed. However, should it be necessary, you can create a DAD manually using Fusion Middleware Control.

Note:

Oracle Portal provides support for only one Portal DAD per Portal instance; you cannot create a new DAD if there is a pre-existing DAD for the instance.

Follow the steps below to create a new Portal DAD :

1. Navigate to the Fusion Middleware Control instance for the appropriate farm.
See Section 8.1, "Using Oracle Enterprise Manager 11g Fusion Middleware Control" for more information.

2. Navigate to the home page for your Oracle Portal instance.
See Section 8.2, "Using Fusion Middleware Control to Monitor and Administer Oracle Portal" for more information.

3. From the Portal menu, select Settings > Database Access Descriptor.

4. Click Add and complete the parameters for the new Portal DAD. Refer to Table 8-1, "DAD Settings" for a description of all the options on this page.

5. Click OK.

6. Restart the Oracle HTTP Server and the managed server (WLS_PORTAL).
Refer to Section 5.6.3, "Stopping and Starting Portal Components Using Fusion Middleware Control" for information on restarting the Oracle HTTP Server and WLS_Portal components.

Editing a Portal DAD

Follow the steps below to edit a Portal DAD using Fusion Middleware Control:

1. Navigate to the Fusion Middleware Control instance for the appropriate farm.
See Section 8.1, "Using Oracle Enterprise Manager 11g Fusion Middleware Control" for more information.

2. Navigate to the home page for your Oracle Portal instance.
See Section 8.2, "Using Fusion Middleware Control to Monitor and Administer Oracle Portal" for more information.

3. From the Portal menu, select Settings > Database Access Descriptor.

4. Select the DAD and click Edit. Edit the DAD parameters for this Oracle Portal instance as required. Refer to Table 8-1, "DAD Settings" for a description of all the options on this page.

5. Click OK.

6. Restart the Oracle HTTP Server and the managed server (WLS_PORTAL).
Refer to Section 5.6.3, "Stopping and Starting Portal Components Using Fusion Middleware Control" for information on restarting the Oracle HTTP Server and WLS_Portal components.

Deleting a Portal DAD

Follow the steps below to delete a Portal DAD using Fusion Middleware Control:

Note:

Do not delete the default Portal DAD. If the default Portal DAD is deleted, then Oracle Portal stops working.

1. Navigate to the Fusion Middleware Control instance for the appropriate farm.
See Section 8.1, "Using Oracle Enterprise Manager 11g Fusion Middleware Control" for more information.

2. Navigate to the home page for your Oracle Portal instance.
See Section 8.2, "Using Fusion Middleware Control to Monitor and Administer Oracle Portal" for more information.

3. From the Portal menu, select Settings > Database Access Descriptor.

4. Select the DAD and click Delete.

5. Click OK.

6. Restart the Oracle HTTP Server and the managed server (WLS_PORTAL).
Refer to Section 5.6.3, "Stopping and Starting Portal Components Using Fusion Middleware Control" for information on restarting the Oracle HTTP Server and WLS_Portal components.

5.6.5 Configuring a Portal DAD Using WLST

Follow the instructions below to create, list, update, or delete a Portal DAD from the WLST command-line scripting interface. Refer to Section 5.1.2.2, "WebLogic ScriptingTool (WLST) Command-line Utility" for more information about using the WLST.

Use the Database Access Descriptor commands listed in Table 5-5 to create, list, update, or delete a Portal DAD from the WLST command-line scripting interface. Based on your actions, the portal_dads.conf file located at DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration is updated.

Table 5-5 Database Access Descriptor Commands for Portal WLST Configuration

Use this command...

To...

Use with WLST...

Creating a Portal DAD

Create a Portal Database Access Descriptor.

Online

Updating Portal Dad

Update the attributes of a Portal Database Access Descriptor.

Online

Deleting Portal DAD

Delete a Portal Database Access Descriptor.

Online

listing a DAD

List the parameters used by the Database Access Descriptors for configuration.

Online

5.6.5.1 Creating a Portal DAD

A Portal DAD is automatically created when Oracle Portal is installed. To create a Portal DAD manually, use the following WLST(online) command:

createPortalDad (name, schema, password, [connect_string], nls_language)

Argument

Definition

name

Name of the Database Access Descriptor.

schema

The Portal database account user name.

password

The Portal database account password.

connect_string

Optional. The connection string used to connect to a remote database.

Connect string may be host name: port number: connect string. The connect string format may be ServiceNameFormat (host:port:database_service_name), SIDFormat (host:port:database_sid), or TNSFormat (TNS alias or the whole TNS entry).

nls_language

The globalization support language of the Portal database that is represented by this DAD. This setting overrides the NLS_LANG environment variable for a database session and defines some important globalization support properties of the response, including the response character set.

Make sure that this language setting matches the NLS_LANG of the back-end database.

Example 5-5 Creating a Portal DAD

createPortalDad(name='portal1',schema='schema',password='welcome1',connect_string='foo.oracle.com:1521:orcl',nls_language='AMERICAN_AMERICA.AL32UTF8')

Note:

Oracle Portal provides support for only one Portal DAD per Portal instance; you cannot create a new DAD if there is a pre-existing DAD for the instance.

5.6.5.2 Updating Portal Dad

To update the attributes of the Portal DAD use the following WLST(online) command:

updatePortalDad (name, [schema], [password], [connect_string], [nls_language])

Argument

Definition

name

Name of the Database Access Descriptor. This name cannot be changed during update.

schema

Optional. The Portal database account user name.

password

Optional. The Portal database account password.

connect_string

Optional. The connection string used to connect to a remote database.

Connect string may be host name: port number: connect string. The connect string format may be ServiceNameFormat (host:port:database_service_name), SIDFormat (host:port:database_sid), or TNSFormat (TNS alias or the whole TNS entry).

nls_language

Optional. The globalization support language of the Portal database that is represented by this DAD. This setting overrides the NLS_LANG environment variable for a database session and defines some important Globalization Support properties of the response, including the response character set. Make sure that this language setting matches the NLS_LANG of the back-end database.

Example 5-6 Updating the Portal DAD Attributes

updatePortalDad(name='portal1',schema='user1',password='welcome2',connect_string='foo.oracle.com:1521:orcl',nls_language='AMERICAN_AMERICA.AL32UTF8')

5.6.5.3 Deleting Portal DAD

To delete the Portal DAD use the following WLST(online) command:

deletePortalDad(name)

Argument

Definition

name

Name of the Portal Database Access Descriptor.

Example 5-7 Deleting the Portal DAD Entry from the Portal_dads.conf File

deletePortalDad(name='portal1')

5.6.5.4 listing a DAD

To list the parameters specified in all the DAD (both general DADs and Portal DADs), use the following WLST(online):

listDads ()

Example 5-8 Listing the Various DADs in the domain

listDads()
------------
/pls/portal1
Schema: h1user
Connect String: foo.oracle.com:1521:orcl
NLS Language: "AMERICAN_AMERICA.AL32UTF8"

5.6.6 Configuring the Portal Cache Using Fusion Middleware Control

Portal cache is a file system-based cache for Oracle Portal pages and portlets. See Section 1.3.2, "Understanding Portal Cache" for more information.

Follow the steps below to configure the Portal cache using Fusion Middleware Control:

1. Navigate to the Fusion Middleware Control instance for the appropriate farm.
See Section 8.1, "Using Oracle Enterprise Manager 11g Fusion Middleware Control" for more information.

2. Navigate to the home page for your Oracle Portal instance.
See Section 8.2, "Using Fusion Middleware Control to Monitor and Administer Oracle Portal" for more information.

3. From the Portal menu, select Settings > Portal Cache.

4. Ensure that the Caching option is set to On.

5. Edit the cache settings for the Oracle Portal instance as required. Table 8-2, "Portal Cache Settings" has a description of all the options on this page.

6. Click Apply.

7. Restart the managed server (WLS_PORTAL).
Refer to Section 5.6.3, "Stopping and Starting Portal Components Using Fusion Middleware Control" for information on restarting the WLS_Portal components.

5.6.7 Configuring the Portal Cache Using WLST

The WLST(online) command update the attributes of the Portal cache.

TheSE configuration details are maintained in the DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration\portal_cache.conf file.

To update the attributes of the Portal Cache, use:

configurePortalCache(enable, directory, total_size, max_size, cleanup_time, max_age)

Argument

Definition

enable

Enables (On) or disables (Off) portal content and session caching.

directory

The directory where cached content is stored.

Make sure that this directory exists and has read-write access.

total_size

The total amount of disk space (in megabytes) that the Portal cache may use. The maximum value allowed is 4 GB.

max_size

The maximum size (in bytes) for all cached files. The maximum value allowed is 4 GB.Any dynamically generated content that exceeds this limit is not cached.

cleanup_time

The time at which to start the cleanup of the cache storage. Use the [Sunday-Saturday, Everyday, Everymonth][hh:mm] format to define the exact day and time in which cleanup should occur.

max_age

Maximum age of a single cached document. This setting ensures the cache system does not contain any old content. Old cache files are removed to make space for new cache files. The default is 30 days.

Example 5-9 Configuring the Portal Cache

configurePortalCache(enable=true,directory='/scratch/user/installs/Inst_1/cache/PortalComponent/portal',total_size=10101010,max_size=12300033,cleanup_time='Everyday 11:00',max_age=20)

5.6.8 Clearing the Portal Cache

Sometimes you must clear the entire portal cache (the Oracle Portal file system-based cache). For example, when you change the character set of the Oracle Metadata Repository, you will need to clear the entire portal cache as the existing content will use the older character set.

To clear the portal cache:

1. Navigate to the portal cache directory. The default path is ORACLE_INSTANCE\portal\cache.

2. Perform a recursive delete of all the files under this directory. For example, on UNIX platforms, issue the following command:

rm -rf *

Notes:

- Whenever you clear the portal cache, you may need to clear the Oracle Web Cache content as well. Refer to Section 6.7.3, "Configuring Portal Web Cache Settings Using WLST" for information about clearing the Oracle Web Cache content.

- You must clear the portal cache on all middle tiers.

WARNING:

Ensure that you are in the correct directory before issuing this command. Do not delete the cache directory.

5.6.9 Configuring the Portal Parallel Page Engine

The Oracle Portal architecture is designed around a three-tier architecture that allows any browser to connect to it. This flexible architecture allows each component (browser, Oracle HTTP Server listener, Oracle Database 11g, and Oracle Portal) to be upgraded individually as required.

A part of the Oracle Portal middle tier, the Parallel Page Engine (PPE) is a servlet that runs under Oracle WebLogic Server and services page requests. The PPE reads page metadata, calls providers for portlet content, accepts provider responses, and assembles the requested page in the specified page layout.

5.6.9.1 Setting PPE Configuration Parameters

All servlets are installed under WLS_PORTAL, based upon the application deployment. The configuration parameters for PPE are entered in the appConfig.xml file, that is, in the </portal-midtier> and the configuration parameter under it. In the default installation, this file can be found at the following location:

DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration

The providerHeaders parameter (see Table 5-7) for PPE is entered in the web.xml file, this file can be found at the following location:

DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portal\uh04o6\war\WEB-INF

PPE Parameters

Table 5-6 describes each of the different configuration parameters available for use with the PPE. Each parameter affects the operation of the PPE in a different manner. Some are simply for logging, while others can affect the performance of the engine or Oracle Portal itself. In most cases, the default values should be sufficient; however, there may be configurations where this is not the case. Each parameter is described with its syntax, description, and default.

Table 5-6 Parallel Page Engine (PPE) Parameters

PPE Setting

Syntax

Description

Default Value

x509certfile

<x509certfile>c:\certificates\trustedcerts.txt</x509certfile>

Specifies a file containing a list of certificates to be implicitly trusted by HTTPClient. These certificates are added as trust points to all connections made by HTTPClient using SSL. Once this setting is in use, all SSL connections must be trusted. Otherwise, HTTPClient will throw an exception in the PPE.

Note that SSL connections are made from the PPE for two reasons, and this configuration affects both:

- loopback requests to the portal, for example, for PMD.

- show calls to Providers.

Note that the file specified here can be obtained from a wallet by exporting all trusted certificates, but the comments in the resultant file must be removed. Alternatively, it can be created manually.

trust points not used

versionOnSplashScreen

<versionOnSplashScreen>false</versionOnSplashScreen>

Indicates whether the PPE must display version information on the splash screen.

false

useScheme

<useScheme>http</useScheme>

Overrides the scheme (http or https) used when the PPE makes requests to the portal. The default, if not specified, is to always use the page request scheme. Note that if you set the useScheme parameter then you must set the usePort parameters.

You need to specify these in scenarios where public access is through https on port A, and you want to set PPE requests to use a faster http connection on port B.

Use page request scheme

usePort

<usePort>8888</usePort>

Overrides the port used when the PPE makes requests to the portal. The default, if not specified, is to always use the page request port.

You need to specify these in scenarios where public access is through https on port A, and you want to set PPE requests to use a faster http connection on port B.

Use page request port

useDeviceNameCacheKeys

<useDeviceNameCacheKeys>false</useDeviceNameCacheKeys>

This key is used to specify whether the mobile device name or device class must be used while building cache keys. The default is for the device class to be used.

If set to true, then the device name is used to build cache keys.

false

urlDebugUsers

<urlDebugUsers>fred,bill,ben</urlDebugUsers>

This is specified to indicate the list of users allowed to use the _debug URL parameter, subject to the value restriction in the urlDebugMode parameter. If this is not specified, all users can use it subject to the value restriction.

The format is a comma-delimited list of portal user names, with leading and trailing spaces being ignored.

none required

urlDebugMode

<urlDebugMode>1</urlDebugMode>

Specifies the highest value of the _debug URL parameter that the PPE should honor. Possible values for _debug are:

none, 0, 1, 2, 3, 4, and 5

If a value higher than that allowed is received by the PPE, it is reduced to the highest value permitted, or ignored if no value is allowed.

The values build incrementally. For example, at debug value 2, values for debug level 1 and 0 are also recorded.

1

stall

<stall>65</stall>

If the response headers are returned, but the data itself lags behind, then a stall comes into affect. This value keeps the PPE from holding on to connections forever. Once the response headers are received, the PPE makes every effort to wait as long as is feasible to retrieve all of the data. Set this value appropriately if the portlets being requested are large, or running over a slow network.

Note that the upper limit of this parameter should be set to a response time acceptable by a Web user (typically a few seconds).

65 sec

showPageDebug

<showPageDebug>false</showPageDebug>

If you set showPageDebug to true, the Page timing information is shown on every request.

Refer to Section B.6, "Timing and Caching Statistics" for a description of the timing and caching statistics.

false

showError

<showError>true</showError>

When a portlet times out, or something within the PPE goes wrong with a particular portlet request, an error is displayed to the user. The messages tend to be generic, but do give the user some information and an indication that the page did not display as expected. If you set this to false, no messages are displayed to the user.

true

resourceUrlKey

<resourceUrlKey>KEY</resourceUrlKey>

This key is used by the PPE to calculate checksums for URLs that are requested by WSRP and JPDK resource proxying.

If you are using JPDK proxying, a JNDI environment variable, also called resourceUrlKey, must be set for the provider.

none

requestTime

<requestTime>30</requestTime>

This is the default time out assigned to portlet requests that do not have their own time out value specified. It is applied as the amount of time (in seconds) allowed before response headers are returned by the server. Time outs are weighted by where they originate. If the portlet sets its own time out value, then that is the time out that is used. If no portlet time out is available, then the provider registration time out is used. If neither of these is present, then the requestTime is used.

Note that the upper limit of this parameter should be set to a response time acceptable by a Web user (typically a few seconds).

30 sec

queueTimeout

<queueTimeout>10</queueTimeout>

The amount of time a request should stay in the queue before being timed out. This parameter can be used if requests for portlets are timing out, but the requests are never being sent. Although this points to other performance problems that could be solved by alternative configurations, this option is available to allow requests to stay in the queue for longer or shorter periods of time.

10 sec

proxyHost

proxyPort

<proxyHost>ph.comp.com</proxyHost>
<proxyPort>8888</proxyPort>

This is the host name and port number of a proxy server that may be required to request data from the Oracle Fusion Middleware. These parameters are only required if a proxy server is in use between PPE and the Oracle Fusion Middleware listener.

n/a

poolSize

<poolSize>25</poolSize>

This represents the number of connections that the PPE is capable of making at any one time. This value can be raised or lowered based upon performance needs. Setting the number higher makes more threads and connections available for use; however, this uses more resources.

25

offlinePath

offlinePathMxml

<offlinePath>/path/offline.html</offlinePath>
<offlinePathMxml>/path/offline.xml</offlinePathMxml>

By setting either of these, the PPE is set to display the desired off-line message. There are two available messages: one for an HTML browser and one for a mobile enabled device.

null

minTimeout

<minTimeout>5</minTimeout>

This is the minimum request timeout allowed to be used by a Portlet. Thus, if the minTimeout is set to 5, and a portlet sends a timeout of 2, the minTimeout value of 5 would be applied to that portlet.

5 sec

maxParallelPortlets

<maxParallelPortlets>20</maxParallelPortlets>

Used to specify the maximum number of portlet requests for a given page, that should be allowed, to execute at the same time. Allowed values are:

0 - Indicates no restriction (beyond the number of fetchers available).

Any positive integer - Indicates a restriction on simultaneous requests.

20

maxParallelPagePortlets

<maxParallelPagePortlets>10</maxParallelPagePortlets>

Used to limit the number of page portlet requests that are allowed to execute at the same time in the PPE. Allowed values are as follows:

0 - Indicates no restriction (beyond the number of fetchers available).

Any positive integer - Indicates a restriction on simultaneous requests.

10

jspSrcAlias

<jspSrcAlias>/internal_jsp/</jspSrcAlias>

The alias for the JSP engine, like /portal/jsp or some other path.

/jsp/

jspRoot

<jspRoot>internal_jsp</jspRoot>

The relative path where JSP files for JSP Pages can be found.

jsp

httpsPorts

<httpsPorts>433:444</httpsPorts>

This is a colon (':') separated list of ports on which Oracle Portal is configured to use SSL.

null

enableWebCacheStaticRules

<enableWebCacheStaticRules>false</enableWebCacheStaticRules>

This key is not used if you are running 11g Release 1 (11.1.1) of the portal repository, and is provided only for backward compatibility when you use a 11g Release 1 (11.1.1) middle tier with an earlier release of the portal repository.

If you are using an earlier release of the portal repository, then consider the following:

If set to false, PPE includes the no-store directive in the surrogate control response header of an assembled page. This overrides any static cacheability rule defined in Oracle Web Cache, and ensures that the assembled page is not cached in the Web Cache.

If set to true, PPE does not include the no-store directive in the surrogate control response header of an assembled page. This allows the use of static cacheability rules for caching the assembled page in Oracle Web Cache.

Note: It is recommended to use the default value, false, as setting it to true makes cached content accessible using the URL only and this affects security. Portal data that is cached in Oracle Web Cache is secured by the presence of secure Oracle Portal HTTP headers in the request. A setting of true means that fully assembled pages may be requested by URL alone and will be returned from the cache.

false

dmsLogging

<dmsLogging>false</dmsLogging>

If you set dmsLogging to true, the PPE outputs data for DMS Logging.

true

cacheEncryptionKey

<cacheEncryptionKey>KEY</cacheEncryptionKey>

This key is used to obscure the headers used for caching using Oracle Web Cache. This allows for a more secure cache key, and makes retrieving a cached object more difficult for unwanted requests.

This key is not used if you are running 11g Release 1 (11.1.1) of the portal repository, and is provided only for backward compatibility when you use an 11.1.1 middle tier with an earlier release of the portal repository.

Server Context information

fileUploadLimit

<fileUploadLimit>65536</fileUploadLimit>

This is used to define the maximum size of the file (in bytes) that can be uploaded.

65536

disableUploadRequestChunking

<disableUploadRequestChunking>false</disableUploadRequestChunking>

If set to true, then chunked encoding of data transfer for file upload will be disabled.

false

wsrpFullPageDecoration

<wsrpFullPageDecoration>false</wsrpFullPageDecoration>

If set to false, turns off decoration when a portlet is rendered for the full page modes of WSRP portlets.

true

wsrpCouldNotGetMarkupMsg

<wsrpCouldNotGetMarkupMsg>This is my personalized error message</wsrpCouldNotGetMarkupMsg>

Replaces the default 'Could not get markup' message (issued when a WSRP portlet request fails) with a custom string.

none - default message displays

5.6.9.1.1 Passing Page Headers to Providers

Arbitrary HTTP headers received by the PPE on page requests can be forwarded to providers. To do this the Portal Administrator specifies headers to be forwarded on a per provider basis. Providers are identified by the URL at which they are running and an optional service ID.

Passing page headers to providers uses the providerHeaders and headersFor: initialization parameters which must be specifed in web.xml. For example, including the following in the web.xml file:

...
<init-param>
<param-name>providerHeaders</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>headersFor: http://my.provider.com/jpdk/providers</param-name>
<param-value>Date:Pragma:X-Oracle-Header</param-value>
</init-param>
<init-param>
<param-name>headersFor: http://some.provider.com/jpdk/providers urn:charts</param-name>
<param-value>Via:X-Custom-Header</param-value>
</init-param>
<init-param>
<param-name>headersFor: http://other.provider.com/jpdk/clipping</param-name>
<param-value>Cookie/ORA_UCM_INFO;sandiaCookie:Via:X-Custom-Header</param-value>
</init-param>
...

would result in requests made to the provider running at http://my.provider.com/jpdk/providers receiving the Date, Pragma and X-Oracle-Header from the page request, and the provider running at http://some.provider.com/jpdk/providers with a service ID of urn:charts receiving the Via and X-Custom-Header page request headers.

The provider running at http://other.provider.com/jpdk/clipping would receive Via and X-Custom-Header page request headers in addition to the ORA_UCM_INFO and sandiaCookie page request cookies. Any other cookies in the page request would not be forwarded.

Table 5-7 describes the providerHeaders and headersFor parameters:

Table 5-7 ProviderHeaders Parameter

PPE Setting

Syntax

Description

Default Value

providerHeaders

<init-param>

<param-name>providerHeaders</param-name>

<param-value>true</param-value>

</init-param>

Enables page header forwarding to providers. Allowed values are:

true - the headers specified in the headersFor: <URL>[<sid>] will be forwarded to the providers.

false - standard provider header handling.

Defaulting the providerHeaders parameter to false prevents processing overhead associated with this feature during PPE startup and page processing where no provider headers are being passed.

false

headersFor: <url> [<sid>]

<init-param>

<param-name>headersFor: <url> [<sid>]</param-name>

<param-value> header name</param-value>

</init-param>

Specifies a colon separated list of HTTP header names that will be forwarded to the provider with service ID <sid> (if specified), running at URL <url>.

This parameter can also be used to specify named cookies to be forwarded. These are defined using a semi-colon delimited list of cookie names preceded by the literal text 'Cookie/'.

n/a

5.6.9.2 Configuring the Parallel Page Engine Using WLST

The WLST (online) command is used to update some of the PPE configuration parameters in the appConfig.xml file, the configuration file that is used by the Portal midtier repository servlet. The WLST command is used to update the following parameters in the appConfig.xml file:

configurePortalPageEngine(encrypt_key, resource_url_key, use_port, use_scheme, x509certfile)

Argument

Definition

encrypt_key

Specifies the HMAC key to obscure the headers used for caching using Web Cache. This allows for a more secure cache key, and makes retrieving a cached object by unwanted requests more difficult.

resource_url_key

This key is used calculates checksums for URLs that are requested by WSRP and JPDK resource proxying. For WSRP resource proxying to work, the key must be set to an alpha-numeric value of 10 characters or more. In addition, for JPDK proxying, a JNDI environment variable, also called resourceUrlKey, must be set for the provider.

use_port

Overrides the port used when the PPE makes requests to the portal. The default, if not specified, is to always use the page request port. Note that if you set use_scheme, you must also set the use_port argument.

This may be used for other reasons, but mostly it is used when SSL is running between the browser and the PPE but not between the PPE and Portal. In this case, the non-SSL port for loop back requests will be different from the SSL port used by the browser.

use_scheme

Overrides the scheme (HTTP or HTTPS) used when the PPE makes requests to the Portal. The default, if not specified, is to always use the page request scheme. Note that if you set use_scheme, you must also set the use_port argument.

x509certfile

Specifies a file containing a list of certificates to be implicitly trusted by HTTP Client. These certificates are added as trust points to all connections made by HTTP Client using SSL.

Note:

For more information, refer Table 5-6, "Parallel Page Engine (PPE) Parameters".

Example 5-10 Updating the Parallel Page Engine

configurePortalPageEngine(encrypt_key='encryption key',resource_url_key='foo.oracle.com',use_port=9999,use_scheme='http',x509certfile='file')

5.6.10 Retrieving the Portal Schema Password

The Oracle Portal schema password is required for some operations where you need to log in to the Portal schema. This section describes how to retrieve the Oracle Portal schema password. For information about changing schema passwords for both default and nondefault Oracle Portals, refer to Section 6.12, "Changing the Oracle Portal Schema Password". To retrieve the Portal schema password, you can use one the following:

- Using the Oracle Enterprise Manager 11g Fusion Middleware Control

- Using the WLST Command

Using the Oracle Enterprise Manager 11g Fusion Middleware Control

To retrieve the Oracle Portal schema password, using the Oracle Enterprise Manager 11g Fusion Middleware Control, do the following:

1. Login to the Enterprise Manager.

2. Expand WebLogic Domain, and then select ClasssicDomain.

3. Right click ClasssicDomain, select Security, and then Credentials.
The Credentials page is displayed.

4. Under Credential, expand oracle.portal.dads, to see the mapname and keyname. The default mapname is oracle.portal.dads and the keyname is /pls/portal.

Using the WLST Command

The Oracle Portal schema password is stored in the configured credential store, and can be retrieved by an administrator using the WLST listCred command. This command returns the list of attribute values of a credential in the domain credential store with given map name and key name and lists the data encapsulated in credentials of type password only. To retrieve the Portal schema password, perform the following:

1. Run wlst, located at ORACLE_HOME\common\bin in windows (For Unix it is wlst.sh).

2. Enter connect()" -> wls:\offline>connect().

3. Enter your username, password, and server URL.

4. Run listCred(map="mapName", key="keyName"). For example, wls:/ClassicDomain/serverConfig> listCred(map="oracle.portal.dads", key="/pls/portal")

5. The output will be as shown in the following example:

{map=oracle.portal.dads, key=/pls/portal}
Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root.
For more help, use help(domainRuntime)

[Name : DEV_PORTAL, Description : null, expiry Date : null]
PASSWORD:manager1

5.6.11 Using a Custom Image Directory

To avoid losing custom images stored in the Oracle Portal images directory (which is ORACLE_HOME\portal\images by default) during a future upgrade, it is recommended that you create your own images directory and set up an appropriate Oracle HTTP Server alias for this directory.

For example, add an entry, similar to the one shown next, to the file ORACLE_HOME\portal\conf\portal.conf. It is recommended that you use the local Oracle Enterprise Manager 11g Fusion Middleware Control instance to make this change. For more information, refer to the Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server or the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

Alias /myimages/ "/opt/app/myportal/images/"
<Directory "/opt/app/myportal/images/">
AllowOverride None
Order allow,deny
Allow from all
ExpiresActive on
ExpiresDefault A2592000
<Files *>
Header set Surrogate-Control 'max-age=2592000'
</Files>
</Directory>

You do not need to perform any specific Oracle Web Cache configuration as Oracle Web Cache is already configured to globally cache .bmp, .gif, .png, .jpg, and .jpeg files.

5.7 Configuring Mobile Support in Oracle Portal

This section discusses how Oracle Portal and Oracle Application Server Wireless are configured to operate together. Oracle Portal pages can be viewed from a wide variety of devices including desktop browsers, mobile phones, and PDAs. Oracle Portal uses OracleAS Wireless to provide wireless functionality to receive requests from wireless devices, and transform content provided by the portal into an appropriate format.

This section describes the following:

- Installing Oracle Application Server Wireless

- Patching OracleAS Single Sign-On for Oracle Portal Mobile Access

- Configuring Mobile Settings in Oracle Portal

- Configuring Mobile Access

- Changing the Mobile Device Component of the Cache Key

5.7.1 Installing Oracle Application Server Wireless

OracleAS Wireless is no longer installed by default, and OracleAS Wireless 10g must now be installed separately.

To install wireless:

1. Download the Oracle Application Server 10g Release 2 distribution available from OTN:
http://www.oracle.com/technetwork/middleware/ias/downloads/101202-095224.html

2. Follow the onscreen instructions to install the OracleAS Wireless 10g distribution.
After completing the OracleAS Wireless 10g installation on a separate server, continue by configuring Oracle Portal and OracleAS Wireless as shown in Section 5.7.4, "Configuring Mobile Access".

Note:

Oracle Portal 11g Release 1(11.1.1.4) uses OracleAS Wireless 10g for mobile support.

3. You need to install the following OracleAS Wireless 10g patch to the Wireless instance:

- If you are using OracleAS Wireless 10g (10.1.2.0.2), you can download the patch ID 8567297 from https://support.oracle.com/.

- If you are using OracleAS Wireless 10g (10.1.2.3), you can download the patch ID 8567297 from https://support.oracle.com/.

This patch is required to fix an issue on cookie handling for mobile devices.

Note:

Integrating Oracle Application Server Wireless 10g with Oracle Portal 11g Release 1 (11.1.1) requires you to complete a set of manual steps, as described in the My Oracle Support note 837837.1 (Oracle Portal 11g Release 1 (11.1.1) with Oracle Application Server Wireless). In addition, see the following:

- My Oracle Support note 343563.1 about Deprecated Features in Oracle Application Server 10g Release 2 (10.1.2)

- My Oracle Support note 402434.1 about Deprecated Features in Oracle Application Server 10g Release 3 (10.1.3)

5.7.2 Patching OracleAS Single Sign-On for Oracle Portal Mobile Access

To fix issues on the mobile login form, you must download and install the patch ID 8564509 from https://support.oracle.com/.

5.7.3 Configuring Mobile Settings in Oracle Portal

To configure mobile settings in Oracle Portal:

1. In the Services portlet, click Global Settings.
By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

2. Click the Mobile tab.

Most mobile-related settings for Oracle Portal are found here. For more detail, see:

- Enabling Mobile Access

- Configuring Mobile Home Pages

- Displaying Page Titles in Mobile Banner Links

- Displaying Enhanced Page Layouts on PDAs

- Logging Mobile Responses

- Configuring the OracleAS Wireless Portal Service URL Reference

Note:

In a hosted environment, you can control each subscriber individually. The exception to this is the OracleAS Wireless Service URL setting. When Oracle Portal is operating in hosted mode (with multiple subscribers), any change to the OracleAS Wireless Service URL must be made by the hosting administrator, using a command line script, as it affects all subscribers.

5.7.3.1 Enabling Mobile Access

The Enable Mobile Access option enables you to control how Oracle Portal responds when a mobile client requests portal pages through OracleAS Wireless. If you want Oracle Portal to return pages and portlets in response to mobile requests, you must select the Enable Mobile Access option.

If you do not select this option, Oracle Portal responds to mobile requests with a message stating that it is not mobile enabled.

To enable mobile access:

1. In the Services portlet, click Global Settings.

2. Click the Mobile tab.

3. Select the Enable Mobile Access option.

4. Click OK.

5.7.3.2 Configuring Mobile Home Pages

Your mobile home page is the first page you see when you access Oracle Portal from a mobile device. If mobile access is enabled, you may choose whether users may select a home page specifically for mobile devices and you can also determine whether all mobile home pages display a Login Link by default:

- Enabling Users to Select Mobile Home Pages

- Excluding Login Links from Mobile Home Pages

5.7.3.2.1 Enabling Users to Select Mobile Home Pages

The Enable Mobile Home Page Selection option enables you to control whether portal users may select separate home pages for mobile access. If you do not select this option, the home pages displayed on mobile devices is the same home page that is used for standard desktop access.

To allow mobile home pages:

1. In the Services portlet, click Global Settings.

2. Click the Mobile tab.

3. Select the Enable Mobile Home Page Selection option.

4. Click OK.

When you select this option, the Default Mobile Home Page field become available to users on the Account Info page. For more information, see the Oracle Fusion Middleware User's Guide for Oracle Portal.

5.7.3.2.2 Excluding Login Links from Mobile Home Pages

The Exclude Login Link from Mobile Home Page option enables you to control whether a Login Link is displayed on mobile home pages. If mobile home pages are allowed, a Login Link is displayed on the mobile home page by default. Select this option if you do not want the default Login Link to be displayed.

To exclude Login Links from mobile home pages:

1. In the Services portlet, click Global Settings.

2. Click the Mobile tab.

3. Select the Exclude Login Link from Mobile Home Page option.

4. Click OK.

5.7.3.3 Displaying Page Titles in Mobile Banner Links

The Use Page Titles in Mobile Banner Links option enables you to choose what text is displayed in the navigation links that appear in the mobile banner. Select this option to use the titles of pages in navigation link text. To see an example, refer to Figure 5-2. If you do not select this option, the default text (Home and Back) is displayed instead.

To use page titles in navigation link text:

1. In the Services portlet, click Global Settings.

2. Click the Mobile tab.

3. Select the Use Page Titles in Mobile Banner Links option.

4. Click OK.

5.7.3.4 Displaying Enhanced Page Layouts on PDAs

The Enhance Display for PDAs option allows enhanced page layouts to be displayed on PDAs (Personal Digital Assistants). PDAs have better display capabilities than other, more simple mobile devices; therefore it is possible to enhance portal page display for PDAs.

If you select this option, default font and color settings on the PDA are used for the text, link text, the page list background, the banner background, and so on. By setting additional PDA Display Options you can override the default PDA display settings and include an image in the PDA page banner if you wish. See Figure 5-2, "Sample PDA Page Layout".

Figure 5-2 Sample PDA Page Layout

If you do not select this option, the same page layout is used for all mobile devices.

To display enhanced page layouts on PDAs and (optionally) customize PDA display options:

1. In the Services portlet, click Global Settings.

2. Click the Mobile tab.

3. Select the Enhance Display for PDAs option.

4. Click Apply.
When you click Apply, a new section called PDA Display Options is displayed at the bottom of the page.

5. (Optional) Set PDA Display Options to control how portal pages are displayed on PDAs. Ensure that you use valid markup when specifying your font and color preferences.
For more detail, see Table 5-8, "PDA Display Options".

6. Click OK.

Table 5-8 PDA Display Options

Option

Description

General Options

Override the default font and color for:

- Background Color - Specify a background color for portal pages; for example, enter #FF0000 or red.

- Font Name - Specify the font used to display text on portal pages; for example, enter arial.

- Font Size - Specify the font size used to display text on portal pages; for example, enter -1.

- Font Color - Specify the font color used to display text on portal pages; for example, enter #0000FF or blue.

To use the default font or color selected by the PDA, leave the appropriate field blank.

Basic Link Options

Override the default colors:

- Unvisited Link Color - Specify a color for unvisited links on portal pages; for example, enter #00FFFF or lightblue.

- Selected Link Color - Specify a color for selected links on portal pages; for example, enter #FFFFFF or white.

- Visited Link Color - Specify a color for visited links on portal pages; for example, enter #FF00FF or magenta.

To use the default link color selected by the PDA, leave the appropriate field blank.

Banner Image Options

Use these options to specify an image (.GIF) for the PDA banner:

- Banner Image (File name or URL) - If the image is located in the portal's default image directory, enter the name of the .GIF file only; for example, enter mylogo. Alternatively, enter the full URL to the image; for example, enter http://www.mycompany/images/mylogo.

- In Default Image Directory? - Select this check box if the banner image you want to use is located in the portal's default image directory. Clear this check box if the image is accBanner Background Color - Specify a background banner color for portal pages; for example, enter #00FFFF or lightblue. Leave the field blank to use the default color selected by the PDA.essible from a URL.

- Banner Background Color - Specify a background banner color for portal pages; for example, enter #00FFFF or lightblue. Leave the field blank to use the default color selected by the PDA.

Page List (Breadcrumbs) Options

Override the default colors:

- Foreground Color - Specify a foreground color for portal page breadcrumbs; for example, enter #00FFFF or lightblue.

- Background Color - Specify a background color for portal page breadcrumbs; for example, enter #0000FF or blue.

- Link Color - Specify a color for link text in portal page breadcrumbs; for example, enter #000000 or black.

To use the default color selected by the PDA, leave the appropriate field blank.

Login / Logout Link

Specify a color for the Login/Logout link displayed on portal pages; for example, enter #000000 or black.

5.7.3.5 Logging Mobile Responses

The Log Mobile Responses option enables you to control whether portlet responses to mobile requests are logged. This feature is useful during development for portlet debugging purposes. When you select this option, the portal logs the content that mobile portlets generate when displayed on a page in response to a mobile device request.

For mobile devices, portal content is rendered in an Oracle specific markup language called MobileXML. This markup is transformed by OracleAS Wireless to the appropriate device markup that generated the request.

Portlet responses are logged when all the following conditions are met:

- The Log Mobile Responses option is selected.

- The user making the request is logged on.

- The request is either from a mobile device, or it is for a mobile page.

Notes:

- This option is intended for development purposes only. We do not recommend that you set this option in a production portal as mobile response logging will impact your portal performance.

- Whenever you enable or disable the Log Mobile Responses option, all currently cached page data is invalidated. Therefore, we recommended that you do not change this option frequently after your Oracle Portal has been deployed for general access.

To log portlet responses to mobile requests:

1. In the Services portlet, click Global Settings.

2. Click the Mobile tab.

3. Select the Log Mobile Responses option.

4. Click OK.

Oracle Portal comes with two built-in portlets for viewing the content that is logged:

- Most recent mobile log entry - Shows only the most recent record for a particular user, irrespective of the portlet from which the data was recorded.

- Mobile log portlet - Shows a list of all the portlets for which a user has content recorded, the user can select which portlet's content they wish to review.

You will find additional information in the article Provider Debugging Techniques: Using the Mobile Log Viewers, on the Oracle Technology Network (OTN), http://www.oracle.com/technology/products/ias/portal/html/mobile_11g_debugging.with.logs.html.

5.7.4 Configuring Mobile Access

After the initial mobile access configuration, or any subsequent Oracle Application Server reconfiguration that results in a change to the Oracle Application Server Wireless service URL or Oracle Portal home page URL, you must manually configure OracleAS Wireless and Oracle Portal to reflect their respective URLs. For more information, see:

- Configuring the Oracle Portal Home Page URL References

- Configuring the OracleAS Wireless Portal Service URL Reference

5.7.4.1 Configuring the Oracle Portal Home Page URL References

The Oracle Portal home page URL is the address that the OracleAS Wireless service definition refers to. When initially configuring wireless access, or if the home page URL changes, you need to configure or update the following references to it:

- Oracle Application Server Wireless Service Definition

- Oracle Portal's Internal Reference to Itself

5.7.4.1.1 Oracle Application Server Wireless Service Definition

To configure the Oracle Portal home page URL in the OracleAS Wireless server service definition:

1. Log in to OracleAS Wireless Tools by using the following URL:

http://<host>:<port>/webtool/login.uix

2. Enter the user name and password for the wireless administrator.

3. Click the Contents tab.

4. In the Content Manager, select the portal service, and click Edit.
If no Portal service is listed in the Content Manager, create a new service using the Wireless Administration tool as shown in Creating a New Portal Service.

5. Click Input Parameters on the left side of the screen.

6. In the Input Parameters screen, change the URL as required.

7. Click Apply to save the changes.

8. Log out of the OracleAS Wireless Content Manager.

See Also:

Oracle Application Server Wireless Administrator's Guide

Creating a New Portal Service

If a Portal service does not already exist in the Content Manager, create one using the Wireless Administration tool as shown below:

1. Open the Wireless Administration tool and select the Services tab.

2. Select HttpMasterService and click Create Application.

3. Select Multi-Channel Application and click Create.

4. Enter portalservice as the application name, and the full URL to the Portal home page as the URL.
The Portal home page URL appears on the Mobile tab on the Global Settings of the AS11 Portal, and is of the form:

http://<AS11portal-host>/portal/pls/portal/portal.home

5. Click Next, and then click Finish.

6. Select portalservice, and then click Quick Publish and name it portalservice.

7. Click Finish.

8. Select the Contents tab and click Add Application Link.

9. Open the master link, select portalservice, and click Next.

10. Name the application link portalservice, click Next, and then click Finish.

11. Click Access Control Content, select Guest, and click Assign Application.

12. Select portalservice, click Add to Group, and then click Finish.

13. Select the Users tab, and then the Users subtab.

14. Select Guest, and click View Application Links, and check that portalservice appears in the list.

15. Note the object ID in the table for the portalservice service (for example, 7066) to specify the URL in the Portal Global Settings Mobile tab.

5.7.4.1.2 Oracle Portal's Internal Reference to Itself

To configure Oracle Portal's own reference to its home page URL, use the script cfgiasw.pl to set the value. The script files are located here:

ORACLE_HOME/assistants/opca/

To run the script, use the following command:

perl cfgiasw.pl -s portal -c portal_db -h "http://my_portal_server.com/portal/pls/portal/portal.home"

The preceding example is specific to a UNIX machine. See Section B.7, "Using the cfgiasw Script to Configure Mobile Settings" for more information on the cfgiasw script.

5.7.4.2 Configuring the OracleAS Wireless Portal Service URL Reference

Oracle Application Server Wireless is used by Oracle Portal as an intermediary in providing access to mobile devices. To provide this access, Oracle Portal must know the URL to the OracleAS Wireless service on which the portal is registered. If the OracleAS Wireless service URL changes, its reference within Oracle Portal must be updated. This reference can be configured in either of the following ways:

- Using the Global Settings Page to Configure the OracleAS Wireless Portal Service URL

- Using the cfgiasw Script to Configure the OracleAS Wireless Service URL Reference

5.7.4.2.1 Using the Global Settings Page to Configure the OracleAS Wireless Portal Service URL

To update the OracleAS Wireless Portal Service URL using the Global Settings page:

1. In the Services portlet, click Global Settings.
By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

2. Click the Mobile tab.

3. Enter the URL in the OracleAS Wireless Portal Service URL field.

4. Enter portalservice as the application name, and the full URL to the Portal home page as the URL in the form:

http://<wireless-host>/ptg/rm?PAoid=<objectid>

where <objectid> is the portal service Object ID from the Content tab of the Wireless Administration screen.

5. Click OK.

You can set the OracleAS Wireless Portal Service URL definition only when Oracle Portal is not operating with multiple subscribers. If Oracle Portal is operating with multiple subscribers, only the hosting administrator should change the value of OracleAS Wireless Portal Service URL (using the cfgiasw script).

5.7.4.2.2 Using the cfgiasw Script to Configure the OracleAS Wireless Service URL Reference

To change or configure Oracle Portal's reference to the URL of Oracle Application Server Wireless Portal service, use the script cfgiasw.pl to set the value. The script files are located here:

ORACLE_HOME\assistants\opca\

To run the script, use the following command:

perl cfgiasw.pl -s portal -c portal_db -w "http://my_iasw_server.com/ptg/rm?PAoid=12345"

The preceding example is specific to a UNIX machine. See Section B.7, "Using the cfgiasw Script to Configure Mobile Settings" for more information on the cfgiasw script.

5.7.5 Changing the Mobile Device Component of the Cache Key

OracleAS Wireless is integrated with Oracle Web Cache to improve page rendering performance and scalability. The cache is used as a repository for post-transformed content; the wireless runtime determines what content needs to be inserted into the cache and when to expire content in the cache. The cache key used by Oracle Portal is composed of numerous components. One of these components is based on the OracleAS Wireless header, X-Oracle-Device.Class. This component allows portlet content to be cached based on the class of the mobile device used.

You can enable portlet content to be cached based on the name of a specific device rather than the device class. Refer to Section B.8, "Using the cfgxodnc.pl Script to Change the Mobile Device Component of the Cache Key" for more information.

5.8 Managing Users, Groups, and Passwords

Refer to Chapter 7, "Securing Oracle Portal" for more information on managing users, groups, and passwords.

5.9 Configuring Browser Settings

Refer to Browser Recommendations in the Preface of the Oracle Fusion Middleware User's Guide for Oracle Portal.

5.10 Configuring Language Support

Oracle Portal allows application development and deployment in different languages. This allows developers to work in their own language when they build portals. In addition, the self-service content management supports multiple languages so that end users can provide documents and other content in different languages.

During the middle-tier installation, Oracle Portal is configured, by default, to support en_US. To configure additional languages (listed in Table 5-9) after installation, use the ptllang tool. For more information, see Section 5.10.1, "Installing Languages After Installing Oracle Portal.".

Table 5-9 Oracle Portal Languages and Language Abbreviations

Language

Language Abbreviation

Arabic

ar

Brazilian-Portuguese

ptb

Canadian French

frc

Czech

cs

Danish

dk

Dutch

nl

English

us

Finnish

sf

French

f

German

d

Greek

el

Hebrew

iw

Hungarian

hu

Italian

i

Japanese

ja

Korean

ko

Latin American Spanish

esa

Norwegian

n

Polish

pl

Portuguese

pt

Romanian

ro

Russian

ru

Simplified Chinese

zhs

Slovak

sk

Spanish

e

Swedish

s

Thai

th

Traditional Chinese

zht

Turkish

tr

Note:

Oracle Portal is not supported on the ZHT32EUC database character set. If your environment supports Traditional Chinese, then use the AL32UTF8, ZHT16MSWIN950, or ZHT16BIG5 character set.

The languages that are configured are shown in the Set Language portlet. You can use Oracle Portal in the language that corresponds to the language setting in the browser, or to the language you have selected in the Set Language portlet. However, the language setting in the browser must correspond to an installed language in Oracle Portal. The Set Language portlet is not displayed by default, but you can add the portlet to the Portal Builder page or any other page that you create in Oracle Portal.

See Also:

The section Working with the Set Language Portlet in the Oracle Fusion Middleware User's Guide for Oracle Portal.

This section contains the following topics:

- Installing Languages After Installing Oracle Portal

- Enabling the Use of Territories

5.10.1 Installing Languages After Installing Oracle Portal

To install languages after you have installed Oracle Portal, run ptllang. You must run ptllang for each language that you want Oracle Portal to support.

Caution:

During login operations, information is sent to Oracle Application Server Single Sign-On. The language used in the authentication request is sent back to Oracle Portal. OracleAS Single Sign-On must have all languages installed that exist on the Oracle Portal, so that the selected language is recognized. If OracleAS Single Sign-On does not have the selected language installed, it will default to US English. This is the language that would be asserted to any Oracle Portal that requested authentication in a language that is not available on OracleAS Single Sign-On.

The Set Language portlet in Oracle Portal sets a language and a Persistent Language cookie on OracleAS Single Sign-On and Oracle Portal.

If there are multiple portals configured to use the same OracleAS Single Sign-On, and the portals have different languages installed, all the combined languages must exist on the OracleAS Single Sign-On to accommodate a Set Language request from any of the portals.

Environment

The ptllang tool is available in the ORACLE_HOME/assistants/opca directory. Set the ORACLE_HOME environment variable to the Oracle home that contains the binaries for Oracle Portal, Forms, Reports and Discoverer.

Assumptions

The Oracle Metadata Repository is already installed, and the respective databases are up.

Usage

On Windows:

ptllang.bat  -lang lang_code [ -s portal_schema] [-sp portal_schema_password] [-c portal_db_connect_string] [-log log_file_directory]

On UNIX:

ptllang.sh  -lang lang_code [ -s portal_schema] [-sp portal_schema_password] [-c portal_db_connect_string] [-log log_file_directory]

Table 5-10 lists and describes the parameters supported by ptllang.

Table 5-10 ptllang Parameters

Parameter

Definition

-s

Oracle Portal schema name.

Default: portal

-sp

Oracle Portal schema password.

-c

Connect string to the target database where Oracle Metadata Repository is installed. The format must be DbHostName:DbPortNumber:DbServiceName.

-lang

Abbreviation for the language to install. For a list of abbreviations of all the supported languages, see Table 5-9.

-log

The directory to which the log file is written.

Usage example

The following examples pass in the input provided on the command line. The examples load the Dutch language strings into the portal schema in the Oracle Metadata Repository.

On Windows:

ptllang.bat -s portal -sp portal -c myDBhost.domain.com:1521:dbServiceName -lang nl -log c:\temp

On UNIX:

ptllang.sh -s portal -sp portal -c myDBhost.domain.com:1521:dbServiceName -lang nl  -log /oracle/log

5.10.2 Enabling the Use of Territories

Once a language is installed into Oracle Portal, the end user can select the language to be used from the languages displayed in the Set Language portlet. For a given language, portal users may also select their geographic location (territory) so that localization settings such as date, currency, and decimal formats are displayed correctly. For example, if the portal language is set to English, portal users may select from territories such as, America, Australia, Canada, Ireland, United Kingdom, and so on.

Territory selection is not available on the Set Language portlet by default. If you want portal users to be able to specify their geographical location (territory), you must edit the Set Language portlet.

The Set Language portlet is not displayed by default. However, you can add it to the Portal Builder page or any other Oracle Portal page.

Adding the Set Language Portlet to a Portal Page

To add the Set Language portlet to a portal page:

1. Log in to Oracle Portal as the portal schema owner.

2. Display the page where you want to display the Set Language portlet. For example, you might want to add the Set Language portlet to the Administrator tab on the Portal Builder Page.

3. Click Edit on top of the page.

4. Click the Add Portlet icon in the region where you want to add the portlet.

5. In the Portlet Repository, click Portal Content Tools.

6. Click Set Language in the Available Portlets area, and click OK.
The Set Language portlet is now available on the portal page.

Note:

If you add the Set Language portlet to a page and subsequently install another language, the new language is not displayed when you view the page. As a workaround, remove the portlet and add it to the page again.

Enabling the Use of Territories and Locales

To enable the use of territories and locales:

1. Log in to Oracle Portal as the portal schema owner.

2. Click the Edit Defaults icon for the Set Language portlet.

3. In the Edit Set Language Portlet Settings screen shown, select the Enable Territory Selection option.

4. Click OK.

By selecting the Enable Territory Selection option, the appropriate locales for each registered language are displayed. The locales are listed after the languages in the Set Language portlet, as shown in Figure 5-3.

Figure 5-3 The Set Language Portlet

Note:

The Oracle Portal online Help system, which uses Oracle Help for the Web, relies on certain fonts to render the online Help user interface in different languages. To get the correct fonts installed, you must select all the languages in which you want to render the online Help, at the time of installation of the middle-tier server. To do this, click the Product Languages button, and select your languages on the Select a Product to Install screen, during the installation.

Additionally, you must make sure that the languages that are installed on the middle tier correspond with the languages that are installed on the infrastructure tier, to avoid problems with the Set Language request issued to OracleAS Single Sign-On.

Installing all languages increases the time required for the middle-tier installation.

5.11 Configuring Oracle Portal for WebDAV

WebDAV is a protocol extension to HTTP 1.1 that supports distributed authoring and versioning. With WebDAV, the Internet becomes a transparent read and write medium, where content can be checked out, edited, and checked in to a URL address. mod_dav is an implementation of the WebDAV specification. The standard mod_dav implementation supports read and write access to files.

The term OraDAV refers to the capabilities available through the mod_oradav module. mod_oradav is the Oracle module that is an extended implementation of mod_dav, and is integrated with the Oracle HTTP Server. mod_oradav can read and write to local files, but also to an Oracle Database. The Oracle Database must have an OraDAV driver installed. The OraDAV driver is installed by default on installation of Oracle Portal. mod_oradav calls this driver to map WebDAV activity to database activity. mod_oradav enables WebDAV clients to connect to an Oracle Database, read and write content, and query and lock documents in various schemas.

See Also:

Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server

When Oracle Fusion Middleware is installed, all required OraDAV parameters are set with values that enable access to Oracle Database content through a Web browser or a WebDAV client. If necessary, you can modify parameter values if the default values do not meet your needs.

Similar to the portal DAD configuration file, WebDAV has it own configuration file (INSTANCE_HOME/config/OHS/ohs1/moduleconf/mod_oradav.conf) that contains the OraDAV parameters and start with DAV and DAVParam. These parameters are specified within a <Location> directive. The oradav.conf file is included in the httpd.conf file.

See Also:

Oracle Fusion Middleware User's Guide for Oracle Portal

5.11.1 Performing Basic WebDAV Configuration

After Oracle Portal has been installed as part of the Oracle Fusion Middleware installation, the mod_oradav.conf file should be populated with a <Location> directive that points to the portal schema. In Example 5-11, the location /dav_portal/portal will be OraDAV-enabled and will (once populated with the correct values) connect to the portal schema so that users can use WebDAV clients to access portal data.

Example 5-11 Configuration Parameters for Portal Access

<Location /dav_portal/portal>
DAV Oracle
DAVDepthInfinity On
DAVParam ORACONNECTSN
<dbhost:dbport:dbservicename>
DAVParam ORAUSER <portal schema name>
DAVParam ORACRYPTPASSWORD <portal schema crypted password>
DAVParam ORACONTAINERNAME wwdav
DAVParam ORAPACKAGENAME
<portal_schema>.wwdav_api_driver   DAVParam ORAException RAISE
DAVParam ORATraceLevel 0   DAVParam ORACookieMaxAge 28800   Options Indexes
</Location>

By default, the Oracle Portal DAV URL is:

http://<host>:<port>/dav_portal/portal/

For example:

http://mysite.oracle.com:8090/dav_portal/portal

The dav_portal part of the URL is the default name of a virtual directory used to differentiate between portal access through a WebDAV client and portal access that uses the pls virtual directory. portal is the DAD of the portal installation. You can also configure virtual hosts to provide a different, simpler, or easier to remember URL for WebDAV access, if need be.

Users connect to a portal in WebDAV clients using the same user name and password that they use to log in to the portal itself. If the portal is in a hosted environment, users also need to add their company information to their user name, as follows:

<username>@<company>

Authentication

Due to the way some WebDAV clients behave, users might experience authentication requests multiple times. To avoid this, the portal administrator can enable the cookie option by adding the following line to the oradav.conf file:

DAVParam ORACookieMaxAge <seconds>

where seconds is the amount of time in seconds before the cookie expires.

For example a value of 28800 is 8 hours and means that once a user has logged on through a WebDAV client, the client tool will not send the user name and password again until 8 hours has passed. Many WebDAV clients (For example: Oracle Drive, WebFolders and Cadaver) do not prompt the user for a user name and password after that time as they retain the values entered when the user first connected and use them to create a new cookie.

Note:

Some WebDAV clients, for example, Dreamweaver, do not support cookies, so even if the cookie option is enabled, users may still be prompted for their passwords multiple times.

If you are using the SQL*Net Advanced Security Option (ASO), the ORACONNECT parameter in the mod_oradav.conf file must be replaced with ORASERVICE dbhost as shown next:

<Location /dav_portal/portal>
DAV Oracle
DAVParam ORASERVICE dbhost
DAVParam ORAUSER portal_schema
DAVParam ORAPASSWORD portal_schema_password
DAVParam ORAPACKAGENAME portal_schema.wwdav_api_driver
Options Indexes
</Location>

This allows the database alias to be resolved by the tnsnames.ora file.

Notes:

- When you add a new DAD without specifying the user name and password, or if you change the portal database schema user name or password using SQL*Plus, you will need to update the portal_dads.conf and mod_oradav.conf files manually.

- Whenever you make changes to portal_dads.conf or mod_oradav.conf, Oracle HTTP Server and managed server (WLS_Portal) must be restarted before the new settings will take effect.

Default Time Limit for File Locks

The new DEFAULTLOCKTIMEOUT parameter provides information about the amount of time for which any single lock created by a DAV client will endure if the client does not actively maintain the lock. This is an optional parameter. By modifying this value, you can define the default amount of time beyond which the locks will expire.

The DEFAULTLOCKTIMEOUT parameter is available in the following format in the mod_oradav.conf file:

DAVParam DEFAULTLOCKTIMEOUT 86400

The unit of measurement for this parameter is seconds. If the parameter is not specified in the configuration file, then Oracle Portal will create locks that will expire in one day, that is, 86400 seconds.

If the time specified for a lock expires, then any temporary document related to that lock is removed. This is expected behavior, for example:

- If Microsoft Word crashes while you are updating a document, you will lose changes to the document if the lock time has expired.

- If you perform operations such as LOCK, PUT, PUT and then close a client without specifying UNLOCK, all data that was PUT will be lost if the lock time has expired.

5.11.2 Setting Up a WebDAV Client

The steps required to set up a WebDAV client to connect to Oracle Portal varies depending on the client. All clients will eventually request a URL. The Portal DAV URL is very similar to the URL you use to access the portal itself in your Web browser, and uses the following format:

http://<host>:<port>/<dav_location>

5.11.3 WebDAV Clients and SSL

Although OraDAV does support Secure Socket Layer (SSL), some WebDAV clients do not. Refer to the WebDAV client's documentation for details.

5.11.4 Checking the Version of OraDAV Drivers

You can check the version of the OraDAV drivers from any Web browser, as shown in the following example:

http://<computer>:<port>/<dav location>/~OraDAV-Version

The output will be like the following example:

Version 1.0.3.2.3-0030
Using Container Version 1.5

5.11.5 Checking version of oraDAV

You can check the version of oraDAV by going to dav_portal at http://host:portal/dav_portal/portal. In the Dav portal url, the version will be displayed as oraDav Portal Driver (Version Number).

5.11.6 Viewing Errors

Any errors that occur when a user performs actions on a portal using a WebDAV client are recorded in an error log that is created in that user's personal page (as an item titled My Error Log) the first time an Oracle Portal-related WebDAV error occurs. This can be very helpful for interpreting the error messages reported in WebDAV clients, such as the message 'An error has occurred while trying to complete this operation' that is often displayed in Web Folders, or HTTP error numbers reported in Cadaver.

All errors are also recorded in the Apache error log file (ORACLE_INSTANCE\diagnostics\logs\OHS\ohs1), so if the user does not have a personal page, or is a public user, the errors can still be examined.

The OraTraceEvents parameter in the mod_oradav.conf file ensures that certain information about an error, such as Agent, User, ECID, URL, and Method, is logged in the Apache error log file. This information is helpful to portal administrators and Oracle Support Services in resolving the error. The OraTraceEvents parameter is available in the following format in the mod_oradav.conf file:

DAVParam OraTraceEvents agent

The information logged in the Apache error log file will be in a format similar to the following example:

[Wed Sep 22 10:38:46 2004] [notice] OraDAV: Agent [Secret-Agent-Man] User
[Hanckel] ECID [Viscous] URI [/orddav_var2/images/var2] Method [MKCOL].

For more verbose error reporting in the Apache error log file, add the following parameter to the oradav.conf file:

DAVParam ORATraceLevel 1

Notes:

- Remember that Oracle HTTP Server needs restarting whenever a change is made to the mod_oradav.conf file. For information about how to do this, refer to the Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server.
You can also refer to the section "OraDAV Configuration Parameters" in the Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server for details of other OraDAV parameters.

- The error log is not truncated and may become quite a large file. We recommend that you periodically delete this file. The next time an error is encountered a new file will be created.

- "Not Found" messages are sometimes seen in the error log because the client computer checks for the existence of a file name. If the file does not exist, the error log correctly displays a 404 error message.

5.12 Configuring Resource Proxying

If you plan to use JPDK resource proxying to choose a key that can be shared between the Portal and providers, then you will need to configure the resourceURLKey parameter. This key is used by the Parallel Page Engine to calculate checksums for URLs that are requested by WSRP and JPDK resource proxying. For WSRP resource proxying to work, the key must be set to an alpha-numeric value of 10 characters or more. The WSRP samples that are shipped with the product use resource proxying. Therefore, if this is not configured correctly, then you will not be able to view images in WSRP portlets. In addition, for JPDK proxying, a JNDI environment variable, also called resourceUrlKey, must be set for the provider. Refer to Section 5.6.9, "Configuring the Portal Parallel Page Engine" for more information.

To configure WSRP resource proxying, perform the following steps:

1. Set the value for the resource_url_key parameter to an alphanumeric value of 10 characters or more, by using the WLST command configurePortalPageEngine.

Note:

You can set the Resource URL Key through Fusion Midlleware Control from the Portal menu, by selecting Settings, and then selecting Page Engine.

2. Restart the WLS_PORTAL.

Part III

Advanced Configuration Topics

Part 3 contains the following chapters:

- Chapter 6, "Advanced Configuration"

- Chapter 7, "Securing Oracle Portal"

- Chapter 8, "Monitoring and Administering Oracle Portal"

- Chapter 10, "Configuring the Search Features in Oracle Portal"

- Chapter 11, "Tuning Performance in Oracle Portal"

- Chapter 12, "Exporting and Importing Content"

- Chapter 13, "Using the Federated Portal Adapter"

6 Advanced Configuration

This chapter describes the configuration that must be performed to achieve some of the more advanced configurations. You must be familiar with the available administrative tools described in Section 5.1, "Getting Started with Oracle Portal Administration" in order to perform these configurations.

This chapter contains the following sections:

- Changing Oracle Fusion Middleware Listen Ports

- Configuring SSL

- Configuring Multiple Middle Tiers with a Load–Balancing Router

- Configuring Virtual Hosts

- Configuring Oracle Portal to Use a Proxy Server

- Configuring Oracle Portal to Work with a Reverse Proxy Server

- Managing Oracle Portal Content Cached in Oracle Web Cache

- Configuring Oracle Portal to Use a Dedicated Oracle Web Cache Instance

- Changing the Infrastructure Services Used By a Middle Tier

- Configuring the Cluster Environment After Installation

- Configuring OracleAS Wireless

- Changing the Oracle Portal Schema Password

- Configuring Oracle Portal Using WLST

6.1 Changing Oracle Fusion Middleware Listen Ports

For information about changing ports in Oracle Fusion Middleware Listen Ports, refer to the Oracle Fusion Middleware Administrator's Guide.

See Also:

Section 8.4, "Viewing Oracle Fusion Middleware Port Usage"

6.2 Configuring SSL

Oracle Portal uses a number of different components (such as the Parallel Page Engine, Oracle HTTP Server, and Oracle Web Cache) each of which may act as a client or server in an HTTP communication. As a result, each component in Oracle Portal's middle tier must be configured individually to use HTTPS protocol and Secure Sockets Layer (SSL), rather than HTTP.

The following sections in Chapter 7, "Securing Oracle Portal" describe the SSL configuration options that are available with Oracle Portal.

- Section 7.3.2.1.2, "SSL to OracleAS Single Sign-On"

- Section 7.3.2.1.4, "SSL to Oracle Web Cache"

- Section 7.3.2.1.5, "End to End SSL for Oracle Portal"

- Section 7.3.2.1.6, "External SSL with Non-SSL Within Oracle Fusion Middleware"

- Section 7.3.2.1.7, "Configuring SSL to Oracle WebLogic Managed Server"

- Section 7.3.2.1.8, "Configuring and Registering Web Providers, Provider Groups, and WSRP Producers Exposed Over SSL"

6.3 Configuring Multiple Middle Tiers with a Load–Balancing Router

This section describes how you can set up Oracle Portal in a multiple middle-tier environment, front-ended by a Load Balancing Router (LBR) to access the same Oracle Metadata Repository.

Note:

As with all out-of-the-box portal installations, this solution is best for internal deployments because it is not configured to use SSL. For the Oracle recommended way of configuring secure enterprise deployments, refer to the Oracle Fusion Middleware High Availability Guide.

The purpose of an LBR is to provide a single published address to the client tier, and front-end a farm of servers that actually service the requests, based on the distribution of the requests done by the LBR. The LBR itself is a very fast network device that can distribute Web requests to a large number of physical servers.

Let us assume that we want to configure the multiple middle-tier configuration, shown in Figure 6-1. In the example, we show Oracle Web Cache on the same computer as the Oracle Portal middle tier, although they can theoretically be on different computers.

Figure 6-1 Multiple Middle-Tier Configuration with a Load Balancing Router

Table 6-1 Additional Information

Computer

Details

Load Balancing Router (LBR)

Computer Name: lbr.abc.com

IP Address: L1.L1.L1.L1

Listening Port: 80

Invalidation Port: 4001 (accessible only from inside)

Portal middle tier 1 (M1)

Computer Name: m1.abc.com

IP Address: M1.M1.M1.M1

Oracle HTTP Server Listening Port: 8888

Oracle Web Cache Listening Port: 8090

Oracle Web Cache Invalidation Port: 4001

Oracle Web Cache Administration Port: 4002

Oracle Portal Managed Server (WLS_PORTAL): 9001

Portal middle tier 2 (M2)

Computer Name: m2.abc.com

IP Address: M2.M2.M2.M2

Oracle HTTP Server Listening Port: 8888

Oracle Web Cache Listening Port: 8090

Oracle Web Cache Invalidation Port: 4001

Oracle Portal Managed Server (WLS_PORTAL): 9001

Notes:

- The name and port values used in this section are for illustration purposes only, and you will need to substitute these with your own.

- Refer to the steps outlined in Section 8.4, "Viewing Oracle Fusion Middleware Port Usage" to view a list of all the ports currently in use by the components of a particular Oracle Portal instance.

Additional LBR configuration is required to successfully handle:

- Loopback Communication

- Oracle Web Cache Invalidation

Loopback Communication

Oracle Portal's Parallel Page Engine (PPE) retrieves page metadata information. This communication is referred to as Loopback Connections. In a default configuration, the loopback connections are local, because Oracle Web Cache and Oracle Portal reside on the same computer.

If an LBR is front-ending Oracle Fusion Middleware, it will need additional configuration if Oracle Web Cache is located on the same subnet. To understand this better, let's take a look at the different parts of the loopback connections without this additional configuration.

1. The PPE sends a loopback request for page metadata when Oracle Portal generates a page. This loopback request goes directly to the LBR.

2. The request is forwarded by the LBR to Oracle Web Cache.

3. Oracle Web Cache forwards the request to Portal Services, running under Oracle HTTP Server.

4. Portal Services processes the request and sends back the response to the loopback request to Oracle Web Cache.

5. Oracle Web Cache forwards the response to the LBR.

6. The LBR receives the response that is supposed to be routed back to the PPE.

7. The LBR detects that the source address, to which the response needs to be sent, is on the same subnet and it sends it back to Oracle Web Cache, using the LBR's known socket connection, instead of using the PPE's socket connection.

8. Oracle Web Cache is not listening for the request at all, and the incoming reply is dropped as there is no valid session.

9. Oracle Portal pages time out with the error 'Timeout occurred while retrieving page metadata.'

As you can see, under normal circumstances, the behavior of the LBR is correct, as the LBR is programmed to forward all requests to Oracle Web Cache. However, when loopback requests come from an internal network, the outcome is not desirable.

To avoid this, you must set up a Network Address Translation (NAT) bounce back rule on the LBR. This configures the LBR as a proxy for requests coming to it from inside the firewall. This setup ensures that the internal requests are forwarded correctly, and when the response reaches the LBR, it is translated correctly and sent to the correct source address on the network (the PPE in this case).

The required steps for setting this up are discussed later. NAT bounce back is set up differently on individual LBRs. Consult your LBR's configuration guide for more information.

See Also:

Oracle Fusion Middleware Enterprise Deployment Guide for Java EE

Oracle Web Cache Invalidation

Oracle Portal leverages Oracle Web Cache to cache a lot of its content. When cached content in Oracle Web Cache changes, Oracle Portal sends invalidation messages from the database to Oracle Web Cache. Oracle Portal can only send invalidation messages to one Web Cache node in an Oracle Web Cache cluster. Oracle Portal relies on that Oracle Web Cache member to invalidate content in the other members of the cluster. When Oracle Fusion Middleware is front-ended by an LBR, the LBR must be configured to accept invalidation requests from the database and balance the load among the cluster members. Depending on how your routing is set up you may also need to set up NAT and open the appropriate outbound ports on your data tier. The required steps for setting this up are discussed later.

Notes:

- After you have completed the Oracle Web Cache Invalidation, ensure that its password is also updated in the Oracle Portal Repository.

- You will notice in Figure 6-1 that the infrastructure is behind the LBR. The infrastructure can be one host, or distributed over multiple hosts. To configure the infrastructure properly, refer to the advanced configuration information in the Oracle Application Server Single Sign-On Administrator's Guide.

To configure Oracle Portal in a multiple middle-tier environment, front-ended by an LBR, you must perform the following steps:

- Step 1: Install a Single Portal Middle Tier (M1)

- Step 2: Configure Oracle Portal on M1 to Be Accessed Through the LBR

- Step 3: Confirm That Oracle Portal is Up and Running

- Step 4: Install a New Portal (M2)

- Step 5: Configure the New Middle Tier (M2) to Run Your Existing Portal

- Step 6: Configure Portal Tools and Web Providers (Optional)

- Step 7: Enable Session Binding on Oracle Web Cache

- Step 8: Confirm the Completed Configuration

6.3.1 Step 1: Install a Single Portal Middle Tier (M1)

Install a single Portal middle tier, and verify the installation. To do this perform the following steps:

1. Follow the steps described in Oracle Fusion Middleware Installation Guide for Oracle Portal, Forms, Reports and Discoverer, to install a Portal middle tier on the first computer (M1). It is assumed that you use the services of an existing Oracle Fusion Middleware Infrastructure.

See Also:

Oracle Fusion Middleware Installation Planning Guide

2. Verify that you have installed the middle tier successfully by ensuring that you can access the Oracle Portal home page at:

http://m1.abc.com:8090/portal/pls/portal

Your configuration now looks like Figure 6-2, with the details described in Table 6-1.

Figure 6-2 Installation of Oracle Portal Middle Tier

You now proceed with the next step where you configure Oracle Portal to be accessed through an LBR.

6.3.2 Step 2: Configure Oracle Portal on M1 to Be Accessed Through the LBR

To configure Oracle Portal so it can be accessed through the Load Balancing Router (LBR), perform the following steps:

1. Configure the LBR (lbr.abc.com) to accept requests on port 80 and forward those to the Oracle Web Cache port (8090) running on computer m1.abc.com. To do this, you need to:

1. Set up a group, or pool on the LBR, to which individual servers can be added.

2. Add the desired servers' IP addresses, and port numbers to the group.

3. Create a virtual server that listens on port 80, and balances load between the members of the group.

4. Make sure the LBR translates the port that it is listening on to forward requests to the port that Oracle Web Cache is listening on.

Note:

Consult the LBR documentation to set up the groups, and a virtual server.

2. Configure the Oracle Portal middle tier on M1 to allow underlying components to construct URLs based on the LBR host name (lbr.abc.com) and LBR port number (80), so that self-referential URLs rendered on Oracle Portal pages are valid for the browser. To do this, perform the following steps:

1. Define a virtual host, using the Create Virtual Host wizard, as explained in Section 6.4.1.1, "Create the Virtual Host for www.xyz.com", and specify the host name of the LBR (lbr.abc.com:80) in the Server Name field for your virtual host.

2. Define a second virtual host, using the Create Virtual Host wizard, as explained in Section 6.4.1.1, "Create the Virtual Host for www.xyz.com", with the following exceptions:

- Specify the host name of M1 (m1.abc.com:8090) in the Server Name field for your virtual host.

- Restart the Oracle HTTP Server.

3. After you have configured the virtual hosts, open the httpd.conf file in the Oracle Enterprise Manager 11g Fusion Middleware Control, and do the following:

- Expand Web Tier and click the Oracle HTTP Server (ohs1) link for your Oracle Portal instance.

- In the Oracle HTTP Server home page, select Administration, and then Advanced Configuration.

- In the Advanced Server Configuration page, select httpd.conf from Select File option, and click Go.

- Add the virtual host definitions in the httpd.conf file:

NameVirtualHost *:8888
<VirtualHost *:8888>
ServerName http://lbr.abc.com:80
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>

<VirtualHost *:8888>
ServerName http://m1.abc.com:8090
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>

- Click Apply.

- Restart the Oracle HTTP Server.

3. Define a site that matches the virtual host entry, created in the previous step (lbr.abc.com), using Oracle Fusion Middleware Control on M1, as follows:

1. Navigate to the Web Cache Home Page in the Oracle Enterprise Manager 11g Fusion Middleware Control on M1, as described in the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

2. From the Web Cache menu, select Administration, and then Sites.
The Sites page is displayed.

3. Click Create under Sites.

4. On the Create Site page, specify lbr.abc.com for the Host and 80 for Port.

5. Select Default Site and Compression.

6. Leave the URL Prefix field blank.

7. Click OK. You will now see lbr.abc.com in the Sites table.

8. Select lbr.abc.com from the Sites table and click Edit.

9. In the Aliases section, click Create to create a new alias and enter the following information:
Host Name: m1.abc.com

Port: 8090

10. Click OK.

11. Click Apply.

4. Use Oracle Enterprise Manager 11g Fusion Middleware Control on M1, to map the site lbr.abc.com to middle tier m1.abc.com.

1. From the Sites page, in the Site-to-Server Mapping section, click Create.
The Create Site-to-Server Mapping Definition page is displayed.

2. Enter the following information in the Create Site-to-Server Mapping section:
Host Pattern: lbr.abc.com

Port Pattern: 80

Leave the Prefix field blank.

3. In the Origin Servers section, select m1.abc.com:8888 from All Origin Servers, and move it to Selected Origin Servers.

4. Click OK.

5. Click Apply.

6. Select m1.abc.com from the Sites table and click Delete to remove the unused site.

7. From the Site-to-Server Mapping table, click Delete to remove the unused sites.

8. Restart your Oracle Web Cache by selecting Control, and then Restart from the Web Cache Home page in the Oracle Enterprise Manager 11g.

To verify that the site has been mapped correctly, navigate to the Site-to-Server Mapping page, and ensure that M1 is mapped to the site lbr.abc.com.

5. Configure computer m1.abc.com so that it can resolve the LBR host name to have the correct IP address. You can either rely on DNS resolution, or make entries in the /etc/hosts file as follows:

L1.L1.L1.L1  lbr.abc.com

Where L1.L1.L1.L1 is the IP address for the LBR. There is no need to restart the system after making these changes.

WARNING:

Ensure that the /etc/hosts file does not have an entry that points the local host name to 127.0.0.1. For example:

127.0.0.1 m1.abc.com

6. Configure the LBR to perform Network Address Translation (NAT) bounce back for loopback requests coming from the PPE running on m1.abc.com. This ensures that when the PPE makes a loopback request to Oracle Web Cache, there are no errors.

Notes:

- NAT bounce back is set up differently on individual LBRs. Consult your LBR's configuration guide on how to set this up.

- The log files contain the NAT bounce back addresses for all loopback requests from the Parallel Page Engine (PPE), that get forwarded to Oracle Web Cache or Oracle HTTP Server through the LBR.

7. Configure the LBR (lbr.abc.com) to accept invalidation requests from the Oracle Metadata Repository on a separate port (4001 in this example), so that it is forwarded to the Oracle Web Cache running on computer m1.abc.com on port 4001.

Note:

The LBR does not have to listen on the Oracle Web Cache invalidation port. On LBRs that do not have Port Mapping ability the port number must match the Oracle Web Cache invalidation port.

1. Set up a group, or pool on the LBR, to which individual servers can be added.

2. Add the desired servers' IP addresses, and port numbers to the group.

3. Create a virtual server that listens on port 4001, and balances load between the members of the group.

4. In the case where the LBR's port, that is listening for the invalidation requests, and the Oracle Web Cache's invalidation port are different, you must ensure that the LBR translates the port that it is listening on to forward requests to the port that Oracle Web Cache is listening on.

Notes:

- Consult the LBR documentation to set up the groups, and virtual server.

- If the Oracle Fusion Middleware Infrastructure is behind another firewall, you need to make sure that it can send invalidation messages to the LBR.

- If the Oracle Portal Metadata Repository Database is behind another firewall, make sure that the database machine can access Web Provider using the provider registration URL.

WARNING:

For security reasons, the invalidation port on the LBR (port 4001) should only be accessible from within the network.

8. Configure the portal middle tier as follows:

1. Navigate to the Portal Home page in the Enterprise Manager.

2. From the Portal menu, select Settings, and then Wire Configuration.
The Portal Wire Configuration page is displayed.

3. Enter the following information under Portal Middle Tier section in the Portal Wire Configuration page:

- Published Host: lbr.abc.com

- Listening Port: 80

4. Under Oracle Web Cache section in the Portal Wire Configuration page, enter lbr.abc.com as the Host, and 8093 as the Invalidation Port.

5. Click Apply.

6. Restart your managed server.

9. You need to configure the HTTP settings for lbr.abc.com in the Oracle WebLogic Server Administration Console as follows:

1. Log in to Oracle WebLogic Server Administration Console.

2. If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.

3. In the left pane of the Console, expand Environment and select Clusters.

4. Select the cluster server and, then the HTTP tab.

5. In the HTTP page enter the following information:

- Frontend Host: lbr.abc.com

- Frontend HTTPPort: 80

6. Click Save.

7. Click Activate Changes.

8. Restart your managed server.

10. Run ssoreg to register the virtual host for which mod_osso facilitates single sign-on. The specific application URLs to be defined as partner applications within this site are defined in the osso.conf file. ssoreg is located on the Identity Management instance in ORACLE_HOME/sso/bin.
The following example shows the usage of ssoreg on UNIX:

$ ssoreg.sh
-site_name lbr.abc.com
-mod_osso_url http://lbr.abc.com:port
-config_mod_osso TRUE
-oracle_home_path ORACLE_HOME
-config_file /tmp/osso.conf
-admin_info cn=orcladmin
-virtualhost
-remote_midtier

On Windows, you must run ssoreg.bat instead. Refer to the information about registering mod_osso in the Oracle Application Server Single Sign-On Administrator's Guide.

11. Back up osso.conf which is located in ORACLE_INSTANCE/config/OHS/ohs1.

12. Copy the osso.conf file to the ORACLE_INSTANCE/config/OHS/ohs1 directory.

13. Restart your Oracle HTTP Server.

After these steps, your configuration looks like Figure 6-3 with the details described in Table 6-1.

Figure 6-3 Oracle Portal Being Accessed Through the LBR

6.3.3 Step 3: Confirm That Oracle Portal is Up and Running

Confirm that Oracle Portal is up and running by performing the following tests in the specified order. If a test fails, address the issues, before proceeding with the next test. To diagnose the Oracle Web Cache, Oracle HTTP Server, and LBR configuration and logs, refer to the Oracle Fusion Middleware Administrator's Guide.

1. Test access to Oracle Web Cache and Oracle HTTP Server through the LBR, by accessing a static file that is cached in Oracle Web Cache, and make sure it works. For example, you can access the following URL:

http://lbr.abc.com:port/index.html

2. Test the connection to Oracle Metadata Repository through the LBR, by accessing the following URL:

http://lbr.abc.com:port/portal/pls/portal/htp.p?cbuf=test

The response should be "test". If this succeeds, it means that the Oracle Fusion Middleware middle tier can connect to the Oracle Metadata Repository. If this fails, then scan the WLS_PORTAL-diagnostic.log file for the WLS_Portal instance for details about the request failure, and take appropriate actions.

3. Test access to Oracle Portal, by completing the following steps:

1. Access the Oracle Portal home page at http://lbr.abc.com:port/portal/pls/portal. If this does not work, then scan the WLS_PORTAL-diagnostic.log file for the WLS_Portal instance, and look for errors. The most common reason for this error is because the PPE cannot make loopback connections. For this to work:

- Ensure that Network Address Translation (NAT) is enabled in the LBR.

- Ensure that the middle tier on m1.abc.com can resolve the address of lbr.abc.com. To do this, run the following command from m1.abc.com:

ping lbr.abc.com

2. While accessing the Oracle Portal home page, it may give an XML Parsing Error, in such case review the diagnostic logs. One of the causes for this error may be a mismatch of the WebCache invalidation password between Oracle Web Cache and Oracle Portal. Review the settings at both ends and make sure that the password matches.

3. Click the portal login link. If this does not work, review the steps performed to run ssoreg to register the virtual host for which mod_osso facilitates single sign-on. Check the WLS_PORTAL-diagnostic.log file for the WLS_PORTAL instance in the DOMAIN_HOME\servers\WLS_PORTAL\logs for more details.

4. Click some links in the portal.

5. Confirm that content is getting cached in Oracle Web Cache.
From the Web Cache menu in the Oracle Enterprise Manager, select Monitoring, and then Popular Requests. Select Cache Popular Requests from the Show Popular Request drop-down list. In the Cache Popular Requests, click Go to refresh the page content. If you accessed Oracle Portal, you will see portal content (For example, URLs that contains strings like _esiReqType=2, wwpob_smd.has_previlege, and wwv_setting.render_css. If you do not see any portal content, open another browser and log in to Oracle Portal. Return to the Cache Popular Requests page, and click Go, to refresh the page content. This should provide enough content for verification.

6. Perform some basic page edits in Oracle Portal, like adding a portlet to a page and make sure that the new content shows up. If the new content does not display properly, or if you see errors, Oracle Web Cache invalidation is misconfigured.

6.3.4 Step 4: Install a New Portal (M2)

Follow these steps to install a new Portal middle tier on M2 (m2.abc.com):

Note:

Before you proceed with installing a Oracle Portal, ensure that you have installed WebLogic Server. See Oracle WebLogic Server Installation Guide. The WebLogic Server installation creates the Middleware Home, which is used to install all the Oracle Fusion Middleware components.

1. Run Oracle Universal Installer to install a Portal middle tier on the second computer (M2).

2. Select the Install Software and Configure option in the Select Installation Type screen during the installation of Oracle Fusion Middleware middle tier and click Next.

3. From the Prerequisite Checks screen, click Next to continue.

4. In the Select Domain screen, select Expand Cluster and enter the following information:

- Host: Enter m1.abc.com

- Port: Enter the WebLogic Administration port number (default: 7001).

- User Name: Enter the user name of the WebLogic Administration server.

- User Password: Enter the password of the WebLogic Administration server.

5. Enter the information in the Specify Email for Security Updates screen and click Next to continue.

6. Specify the Middleware Home, Oracle Home, and Oracle Instance locations, along with the Oracle Instance name in the Specify Installation Location screen and click Next to continue.

Note:

It is recommended that you use the same physical path for installing the second middle tier. This helps when you make configuration changes on one computer and want to transfer the changes to another computer. If the physical path is different on other computers, you must ensure that the path elements are corrected after copying the files.

7. In the Configure Components screen, select the components you have selected for M1 and click Next.

8. In the Configure Ports screen, select Specify Ports Using Configuration file, and click Browse to select the staticports.ini file used by M1.
If you did not save the file during M1 installation, the file does not exist. In this scenario, click View\Edit File and edit the file as follows:

Domain Port No = 7001
[OHS]
Oracle HTTP Server Port No = 8888
[WEBCACHE]
Oracle WebCache Port No = 8090
Oracle WebCache Invalidation Port No = 4001
[MANAGEDSERVER]
Oracle WLS Portal Managed Server Port No = 9001

Note:

The port values should be the same as in MI.

9. In the Specify Application OID screen, enter your Oracle Internet Directory server details and click Next.

10. In the Installation Summary screen, verify the information and click Install.

See Also:

Oracle Fusion Middleware Installation Planning Guide

This new installation should not have affected your previous configuration. Confirm that Oracle Portal is up and running on M1, and can be accessed through the LBR. See Section 6.3.3, "Step 3: Confirm That Oracle Portal is Up and Running" for more information about how to check this.

6.3.5 Step 5: Configure the New Middle Tier (M2) to Run Your Existing Portal

Perform the following steps, in the order specified, to configure M2 to run your existing portal:

1. Copy the configuration settings for Oracle Portal from the middle tier M1, to the middle tier M2. It is a good idea to make backup copies of the files first. To do this, copy the following files:

- appConfig.xml

- portal_cache.conf

- portal_dads.conf

- portal_plsql.conf

From DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration of M1 to M2.

If M1 and M2 are installed using different physical paths, you need to make sure that the path elements are corrected after copying the files.

2. Configure the new Oracle Portal middle tier to allow underlying components to construct URLs based on the Load Balancing Router (LBR) host name (lbr.abc.com) and LBR port number (80). To do this, perform the following steps, using the Fusion Middleware Control on M2:

1. Define a virtual host, using the Create Virtual Host wizard, as explained in Section 6.4.1.1, "Create the Virtual Host for www.xyz.com", with the following exceptions:

- Select New listen address option, and enter lbr.abc.com:80.

- Specify the host name of the LBR (lbr.abc.com) in the Server Name field for your virtual host.

2. Define a second virtual host, using the Create Virtual Host wizard, as explained in Section 6.4.1.1, "Create the Virtual Host for www.xyz.com", with the following exceptions:

- Select New listen address option, and enter m2.abc.com:8090.

- Specify the host name of M2 (m2.abc.com) in the Server Name field for your virtual host.

- Restart the Oracle HTTP Server.

3. After you have configured the virtual hosts, open the httpd.conf file in the Oracle Enterprise Manager 11g Fusion Middleware Control, and do the following:

- Expand Web Tier and click the Oracle HTTP Server (ohs1) link for your Oracle Portal instance.

- In the Oracle HTTP Server home page, select Administration, and then Advanced Configuration.

- In the Advanced Server Configuration page, select httpd.conf from Select File option, and click Go.

- Add the virtual host definitions in the httpd.conf file:

NameVirtualHost *:8888
<VirtualHost *:8888>
ServerName http://lbr.abc.com
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>

<VirtualHost *:8888>
ServerName http://m2.abc.com:8090
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>

- Click Apply.

- Restart the Oracle HTTP Server.

3. Copy mod_oradav.conf, mod_osso.conf, plsql.conf, and portal.conf from ORACLE_INSTANCE\config\OHS\ohs1\moduleconf of M1 to M2.

4. Copy ORACLE_INSTANCE\config\OHS\ohs1\osso.conf from M1 to M2.

5. Open portal.conf file located in ORACLE_INSTANCE\config\OHS\ohs1\moduleconf and remove all lines beginning with WebLogicHost and WebLogicPort and replace them with a WebLogicCluster directive and update it as follows for the Oracle HTTP Server to be made aware of all of the Oracle WebLogic Managed Servers:
For M1:

<Location /portal>
SetHandler weblogic-handler
WebLogicCluster m1.abc.com:9001,m2.abc.com:9001
</Location>

For M2:

<Location /portal>
SetHandler weblogic-handler
WebLogicCluster m2.abc.com:9001,m1.abc.com:9001
</Location>

6. Restart the Oracle HTTP Server using the following commands:

ORACLE_INSTANCE\bin\opmnctl stopall
ORACLE_INSTANCE\bin\opmnctl startall

7. Configure the computer m2.abc.com to resolve the LBR host name to have the correct IP address. You can either rely on DNS resolution for this, or make entries in the /etc/hosts file as follows:

L1.L1.L1.L1  lbr.abc.com

WARNING:

Ensure that the /etc/hosts file does not have an entry that points the local host name to 127.0.0.1. For example:

127.0.0.1 m2.abc.com

8. Access the Oracle Web Cache Manager on M1, as described in the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

9. Use Oracle Enterprise Manager 11g on M1, to add M2 as an additional origin server to the Oracle Web Cache. To do this, perform the following steps:

1. Navigate to the M1 Web Cache Home page in the Oracle Enterprise Manager 11g.

2. From the Web Cache menu, select Administration, and then Origin Server.
The Origin Servers page displays.

3. Click Create.
The Create Origin Server page displays.

4. In the Create Origin Server page displays page, provide the following information:

Property

Value

Host

m2.abc.com

Port

8888

Capacity

100

Protocol

HTTP

Routing Enabled

ENABLED

Failover Threshold

5

Ping URL

/

Ping Frequency (seconds)

10

Note:

For the Port value, use the M2's Oracle HTTP Server listening port.

5. Click OK.

6. Click Apply.

7. To verify that the origin server has been added properly, locate m2.abc.com in the Origin Server table.

Refer to the section on mapping sites to origin servers in the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache for more information.

10. Use Fusion Middleware Control on M1, to map the site lbr.abc.com to the two origin servers m1.abc.com, and m2.abc.com, by performing the following steps:

1. Navigate to the M1 Web Cache Home page in the Oracle Enterprise Manager 11g.

2. From the Web Cache Menu, select Administration, and then Sites.
The Sites page displays.

3. On the Site-to-Server Mapping page, select the mapping for the LBR site in the table and click Edit.

4. Select m2.abc.com:8888 in the All Origins Servers and move it to Selected Origin Server.

5. Click OK.

6. Click Apply.

7. To verify that the site has been mapped correctly, ensure that both M1 and M2 are mapped to the site lbr.abc.com in the Site to Server Mappings table by accessing Web Cache menu in the Enterprise Manager, Administration > Sites.

Refer to the section on mapping sites to origin servers in the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache for more information.

11. Use Oracle Fusion Middleware Control on M1, to add the Oracle Web Cache on M2 to the Oracle Web Cache cluster on M1 and ensure that the password for both the Oracle Web Cache are same. To do this, perform the following steps:

1. Navigate to the Web Cache Home page in the Fusion Middleware Control.

2. From the Web Cache menu, select Administration, and then Cluster.

3. In the Cluster page, click Add.
The Web Cache for M2 will be added.

4. Click Apply.

5. Click Synchronize and, click Yes to confirm.

6. Restart the Oracle Web Cache on M1 and M2.
For information about configuring a cache cluster, refer to the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

12. Configure the LBR to perform Network Address Translation (NAT) bounce back for loopback requests coming from Oracle HTTP Server on m2.abc.com. Refer to Step 6 in Section 6.3.2, "Step 2: Configure Oracle Portal on M1 to Be Accessed Through the LBR " section for more information.
After these steps, your configuration looks like Figure 6-1.

Note:

For adding more middle tiers, follow the procedures outlined in Section 6.3.4, "Step 4: Install a New Portal (M2)" and Section 6.3.5, "Step 5: Configure the New Middle Tier (M2) to Run Your Existing Portal", for each middle tier.

6.3.6 Step 6: Configure Portal Tools and Web Providers (Optional)

Some additional configuration is required to ensure that Portal Tools providers (OmniPortlet and Web Clipping) and locally and custom built Web providers work properly in the middle-tier environment. If OmniPortlet or any other Web providers already have personalizations in the file system, you can use the PDK-Java Preference Store Migration and Upgrade Utility to migrate the personalizations to the database and upgrade personalizations from earlier releases. Refer to Section B.10, "Using the PDK-Java Preference Store Migration and Upgrade Utility" for more information about this utility.

For the WSRP producer, the Oracle Metadata Repository is used as the default portlet preference store. If you want to use a different preference store, then refer to the Oracle Fusion Middleware Developer's Guide for Oracle Portal for more information.

Configuring Portal Tools Providers in the Multiple Middle-Tier Environment

Perform the following steps for Portal Tools (OmniPortlet and Web Clipping) providers to function properly in the multiple middle-tier environment:

1. The Portal Tools configuration information is stored in the OmniPortlet and Web Clipping provider.xml file on the middle-tier server. You need to update the configuration directly on one middle tier (for example, M1) and then propagate it across all middle tiers front-ended by the LBR. For more information, see Section E.1.3, "Configuring HTTP or HTTPS Proxy Settings".
Propagate the changes made to the provider.xml file to middle tier M2:

- Copy DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_version\dir_name\war\WEB-INF\providers\omniPortlet\provider.xml from M1 to M2.
Note that dir_name is a randomly generated directory name for each deployment instance.

- Copy DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_version\dir_name\war\WEB-INF\providers\webClipping\provider.xml from M1 to M2.

2. Restart middle tier M2.

3. Verify that OmniPortlet and the Web Clipping providers work properly through the LBR, by going to the test pages at the following URLs.

- OmniPortlet Provider: http://lbr.abc.com/portalTools/omniPortlet/providers/omniPortlet
If you see the "No Portlets Available" message under the Portlet Information section in the OmniPortlet Provider test page, then you may not have configured OmniPortlet correctly in Step 1. If OmniPortlet is configured correctly, the OmniPortlet and Simple Parameter Form portlets are available on the test page.

- Web Clipping Provider: http://lbr.abc.com/portalTools/webClipping/providers/webClipping

Note:

If you want to use the Web Clipping provider, or the Web Page Data Source for OmniPortlet, you must also enable session binding in Oracle Web Cache. Refer to "Step 7: Enable Session Binding on Oracle Web Cache" for more information.

4. In Oracle Portal, click Edit Registration for the OmniPortlet producer on the Producers tab of the Navigator, under Locally Built Producers. Then click the Connection tab, and change the first part of the producer registration URL from http://m1.abc.com:7777/ to http://lbr.abc.com/.

5. In Oracle Portal, click Edit Registration for the Web Clipping producer on the Providers tab of the Navigator, under Locally Built Producers. Then click the Connection tab and change the first part of the producer registration URL from http://m1.abc.com:7777/ to http://lbr.abc.com/.

6. Refresh the Portlet Repository so that the Portal Tools portlets appear in the Portlet Builders folder in the Portlet Repository:

1. Log in as the portal administrator, and click the Builder link.

2. Click the Administrator tab.

3. Click the Portlets sub-tab.

4. Click the Refresh Portlet Repository link in the Portlet Repository portlet.

5. The refresh operation continues in the background.

Creating and Editing Locally Built Web Providers in the Multiple Middle-Tier Environment

Locally built providers are providers that are defined within an instance of Oracle Portal. These locally built providers are available if you have migrated them from the previous release. You typically create or edit these providers before configuring for LBR. If you are doing it after the LBR is configured, perform the following steps:

1. The Web provider information is kept in the provider.xml file on the middle-tier server. You need to migrate provider.xml to one middle tier (for example, M1) using upgrade assistance and then propagate it across all middle tiers front-ended by the LBR. Before you do this, you must shut down all middle tiers except M1.

2. Propagate the changes made to the files in M1 to middle tier M2:

1. Go to DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_version\dir_name\war\WEB-INF and copy the deployment, deployment_providerui, and providers folders from M1 to M2.
Note that dir_name is a randomly generated directory name for each deployment instance.

2. Change the <warDir> element in the DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_version\dir_name\war\WEB-INF\\deployment_providerui\provideruiacls.xml file with the appropriate value for M2 (shown in bold):

<providerMap name="MyProducer" baseLanguage="en">
<displayName language="en" translation="myprovider"></displayName>
<timeout>20</timeout>
<timeoutMessage language="en" translation="Timed Out"></timeoutMessage>
<loginFrequency>Never</loginFrequency>
<httpURL>http://lbr.abc.com:80/portalTools/builder/providers/MYPROVIDER</httpURL>
<cookieDomain>abc.com</cookieDomain>
<serviceId>MYPROVIDER</serviceId>
<requireSessionData>false</requireSessionData>
<httpAppType>Portal</httpAppType>
<warDir>{providerBuilder war directory of this mid-tier}</warDir>
<warFile>providerBuilder</warFile>
</providerMap>

3. Restart the middle tier M2.

4. Verify that the Web provider works properly through the LBR, by going to the test page at the URL http://lbr.abc.com:80/portalTools/builder/providers/<providerName>.

Configuring Custom Built WSRP Producers in a Multiple Middle-Tier Environment

By default, WSRP producers store their portlet preference data in the Oracle Metadata Repository, and will work correctly in a multiple middle-tier environment. If you want to use a custom database to store this information, then refer to theOracle Fusion Middleware Developer's Guide for Oracle Portal for the steps to be performed.

Note:

When using a custom database for portlet preference data in a multiple middle-tier environment, all WSRP producers must reference the same database schema in data-sources.xml.

Configuring Load Balanced Session-Based Web Providers

To configure session-based Web providers, front-ended by a Load Balancing Router (LBR), the login frequency should be set to "Once Per User Session", on the provider information page, and the LBR must be configured to do cookie-based routing. To set the login frequency, take the following steps:

1. Log in to Oracle Portal. On the Portal Builder page.

2. In Portal Builder, click the Administer tab and then the Portlets tab.

3. Under Remote Providers, enter the name of the Web provider you want to configure, and then click Edit.

4. Click the Connection tab.

5. Under User/Session Information, set the Login Frequency to Once Per User Session.

6. Click OK.

Refer to the specific documentation of your LBR for information about how to configure an LBR to do cookie-based routing.

Editing an External Application Login URL

If your external application is hosted on the middle tier, then you need to update the external application login URL in the OracleAS Single Sign-On Server. You can do this by following the procedure in the "Editing an External Application" section in the Oracle Application Server Single Sign-On Administrator's Guide. Change the first part of the login URL from http://m1.abc.com:7777/ to http://lbr.abc.com/.

6.3.7 Step 7: Enable Session Binding on Oracle Web Cache

The Session Binding feature in Oracle Web Cache is used to bind user sessions to a given origin server to maintain state for a period of time. Although almost all components running in a default Oracle Portal middle tier are stateless, session binding is required for two reasons:

- The Web Clipping Studio, used by both the Web Clipping portlet and the Web Page Data Source of OmniPortlet, uses HTTP session to maintain state, for which session binding must be enabled. Refer to Appendix E, "Configuring the Portal Tools Providers" for more information about Web Clipping.

- Enabling session binding forces all the user requests to go to a given Oracle Portal middle tier, resulting in a better cache hit ratio for the portal cache. Refer to Section 1.3.2, "Understanding Portal Cache" for details on the portal cache.

Note:

Regardless of whether you have configured an LBR in your topology, you must enable session binding in Oracle Web Cache if you have more than one middle tier. In this configuration Oracle Portal does not require session binding to be set up on the LBR.

To make Oracle Web Cache bind the portal user session to the Oracle Portal middle tier, perform the following steps in the Oracle Fusion Middleware Control:

1. Navigate to the Web Cache Home page, in the Oracle Enterprise Manager 11g.

2. From the Web Cache menu, select Administration, and then Session Configuration.
The Session Configuration page displays.

3. Create a session definition in the Session Definition table. Refer to the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache for information on how to create session definitions.

4. Specify session-binding settings:

1. In the Session Policy Configuration section, click Create.
A new row in the table appears.

2. From the Session Name list, select the session you created in Step 3, and then With Session from the Cache option.

3. From the Session Binding Configuration section, check the Bind using a session radio button. Select session you created in Step 3 and select Cookie-based.

4. Click Apply to submit changes.

For more information refer to the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

6.3.8 Step 8: Confirm the Completed Configuration

To verify that your complete configuration is working as expected, perform the following steps:

1. To clear the contents stored in Oracle Web Cache, restart M1 and M2, as follows:

1. Access Oracle Enterprise Manager 11g and open the M1 instance.
For details, see "Accessing Oracle Enterprise Manager 11g Fusion Middleware Control".

2. From the M1 menu, select Control, then Start Down and Control, then Start Up.

3. Repeat the steps for M2.

2. Test access to Oracle Portal through the LBR by completing the following steps:

1. Access the Oracle Portal home page at http://lbr.abc.com/portal/pls/portal.

2. Click the portal login link.

3. Click some links in the portal.

4. Confirm that content is getting cached in Oracle Web Cache, by completing the following steps:
Access Fusion Middleware Control, expand Web Tier, and select Web Cache. Right click Web Cache menu and select Monitoring, and then Popular Requests. The Popular Requests page displays. Perform some basic page edits in Oracle Portal, like adding a portlet to a page and make sure that the new content shows up on the Popular Requests page by refreshing the page If the new content does not display properly, or if you see errors, Oracle Web Cache invalidation is misconfigured.

6.4 Configuring Virtual Hosts

The Oracle HTTP Server supports the configuration of virtual hosts. Virtual hosts allow a single computer to appear as any number of different sites. You can, for example, configure a computer to represent both www.abc.com and www.xyz.com. Another example would be configuring a computer to represent both my.oracle.com and oraclepartnernetwork.oracle.com. To configure virtual hosts with Oracle Portal, you must set this up on the Oracle HTTP Server. Additional Oracle Web Cache and Oracle Application Server Single Sign-On configuration is also required.

Portal pages are cached in Oracle Web Cache with the host name of the host that you access first. Subsequent requests to the same page will always contain links with that host name irrespective of which host you are accessing.

For example, if you access Page A using virtual host www.abc.com, then all links in Page A will show up relative to www.abc.com. If another user accesses the same page, Page A, using the virtual host www.xyz.com, then due to the aliasing in Oracle Web Cache, all links created for this page will still reference www.abc.com and clicking on these links will result in portal pages being served from www.abc.com.

Unless the pages served from both virtual hosts are mutually exclusive, that is, portal pages served from site www.abc.com are not being served from www.xyz.com, users will be bouncing back and forth between the two virtual hosts. If this is not desired, then refer to 824225.1 from http://metalink.oracle.com for information on creating two sites with host independent invalidation in the Web Cache site definitions.

Note:

If your intent is only to change the host name of your middle tier, refer to the Oracle Fusion Middleware Administrator's Guide.

Let's assume that your server name is www.abc.com, and you connect to Oracle Portal at http://www.abc.com:8090/portal/pls/portal. The IP address of the computer that the middle tier is installed on is 196.12.67.8.

You want to access Oracle Portal at http://www.abc.com:8090/portal/pls/portal, using the real server name, and http://www.xyz.com:8090/portal/pls/portal, using a virtual host name, where both URLs resolve to the same IP address.

In this example, port 8090 is the Oracle Web Cache listening port, and port 8888 is the Oracle HTTP Server listening port.

Let's also assume that the OracleAS Single Sign-On is installed on a different computer with the IP address 123.45.67.8, and accessed at the URL http://www.login.com:8091/pls/orasso.

Notes:

- The IP addresses used in this example are for illustration purposes only and may not be valid IP addresses.

- The name and port values used in this section are for illustration purposes only and you will need to substitute these with your own.

- In this section we only describe how to configure virtual hosts for the Oracle Portal middle tier, and this does not modify the host name for OracleAS Single Sign-On. For more information about how to customize the OracleAS Single Sign-On host name, refer to the information about deploying OracleAS Single Sign-On with a proxy server, in the Oracle Application Server Single Sign-On Administrator's Guide, and the Oracle Fusion Middleware Administrator's Guide.

Figure 6-4 shows the previously described configuration. Oracle Web Cache and the Oracle Fusion Middleware are shown as residing on the same middle-tier computer, although they can exist on different computers.

Figure 6-4 Virtual Host Overview

Note:

The domain names www.abc.com, www.xyz.com, and www.login.com must be valid domain names, and you must be able to ping them.

To configure the virtual host, perform the following steps in the specified order:

1. Create Virtual Hosts

2. Configure Oracle Web Cache

3. Register Oracle Portal with OracleAS Single Sign-On

4. Verify the Configuration

6.4.1 Create Virtual Hosts

You must create virtual hosts entries in the httpd.conf file for the virtual host name www.xyz.com, and for the real server name www.abc.com. To define the virtual hosts, use Oracle Enterprise Manager 11g Fusion Middleware Control to perform the following steps:

- Create the Virtual Host for www.xyz.com

- Create the Virtual Host for www.abc.com

Once you have finished this step, do the following:

1. Verify the httpd.conf File

2. Verify That the Virtual Hosts Are Configured Correctly

6.4.1.1 Create the Virtual Host for www.xyz.com

To create the virtual host for www.xyz.com:

1. Access the Oracle Enterprise Manager 11g Fusion Middleware Control.

For details, see "Accessing Oracle Enterprise Manager 11g Fusion Middleware Control".

2. Expand Web Tier and then click the HTTP Server link for your Oracle Portal instance.

3. In the Oracle HTTP Server home page, select Administration, and then Virtual Hosts.
The Virtual Hosts page is displayed.

4. Click the Create button.
The Create Virtual Host page is displayed.

5. On the Create Virtual Host page, provide the information listed in Table 6-2.

Table 6-2 Virtual Host Information

Virtual Host Information

Value

Virtual Host Name

Select Use existing listen address and select a port number from the drop-down option.

Server Name

Your Domain name, http://www.xyz.com.

Document Root Directory

ORACLE_INSTANCE\config\OHS\ohs1\htdocs

Directory Index

Can be left blank

Administration E-Mail Address

Valid e-mail address

Type

name-based

6. Click OK.

7. Ensure that your server name, http://www.xyz.com, is listed in the table.

8. After you have configured the virtual hosts, open the httpd.conf file in the Oracle Enterprise Manager 11g Fusion Middleware Control, and do the following:

- Expand Web Tier and click the Oracle HTTP Server (ohs1) link for your Oracle Portal instance.

- In the Oracle HTTP Server home page, select Administration, and then Advanced Configuration.

- In the Advanced Server Configuration page, select httpd.conf from Select File option, and click Go.

- Add the Port to the ServerName, and the Rewrite and RewriteOptions directives in the VirtualHost container, as follows (shown in bold text):

NameVirtualHost *:8888

<VirtualHost *:8888>
ServerName http://www.xyz.com:8090
DocumentRoot <ORACLE_INSTANCE>/config/OHS/ohs1/htdocs
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

- Click Apply.

- Restart the Oracle HTTP Server by selecting Control, and then Restart from the Oracle HTTP Server Home page.

6.4.1.2 Create the Virtual Host for www.abc.com

To create the virtual host for www.abc.com:

1. In Section 6.4.1.1, "Create the Virtual Host for www.xyz.com" follow steps 1 through 6.

2. Provide the following information in the Server Name field for your virtual host:

www.abc.com

3. In Section 6.4.1.1, "Create the Virtual Host for www.xyz.com" follow step 8.

4. Restart the Oracle HTTP Server.

6.4.1.3 Verify the httpd.conf File

After configuring virtual hosts for www.abc.com and www.xyz.com, take a look at your httpd.conf file, using Fusion Middleware Control, as follows:

1. Access the Oracle Enterprise Manager 11g Fusion Middleware Control.

2. Right click the HTTP Server link for your Oracle Portal instance.

3. In the Oracle HTTP Server home page, select Administration, and then Advanced Configuration.

4. In the Advanced Server Configuration page, select httpd.conf from Select File option and click Go.
Your httpd.conf file should have the following new section:

NameVirtualHost *:8888

<VirtualHost *:8888>
ServerName http://www.xyz.com:8090
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

<VirtualHost *:8888>
ServerName http://www.abc.com:8090
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

Entries for the virtual hosts can vary depending on the existing content of the httpd.conf file, but you must have virtual host entries for both www.abc.com and www.xyz.com.

5. Click Apply to update the file.

Note:

- The httpd.conf file can also be updated manually. The file can be edited manually, to contain the right VirtualHost directives, as shown previously.
Finally, restart Oracle HTTP Server, by running the following command from:

ORACLE_INSTANCE\bin\opmnctl stopall
ORACLE_INSTANCE\bin\opmnctl startall

- If your site name is not registered with the DNS, you need to update the hosts file on your client computer as follows:
On Windows, this file is typically located in the directory C:\WINNT\system32\drivers\etc. Here is an example of the hosts file on Windows:

# Copyright (c) 1993-1995 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP
# for Windows.
#
127.0.0.1 localhost
196.12.67.8 www.abc.com
196.12.67.8 www.xyz.com

On UNIX, the file is typically located in the directory /etc/hosts. You do not have to restart the system after making these changes.

6.4.1.4 Verify That the Virtual Hosts Are Configured Correctly

Verify that both the server name, and the virtual host are working, by accessing these URLs:

- http://www.xyz.com:8090/portal/pls/portal

- http://www.abc.com:8090/portal/pls/portal

6.4.2 Configure Oracle Web Cache

The site www.abc.com is already defined in Oracle Web Cache. Additionally, you must create a site alias in Oracle Web Cache, to make the multiple virtual hosts transparent to the Oracle Metadata Repository. Note that www.abc.com must be set up as a site, while www.xyz.com must be defined as a site alias. This way, invalidation messages sent to Oracle Web Cache invalidate content that is cached for both sites.

See Also:

Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache for information about setting up a site alias.

6.4.3 Register Oracle Portal with OracleAS Single Sign-On

To register Oracle Portal with OracleAS Single Sign-On, do the following:

1. Run ssoreg to register the virtual host, www.xyz.com, for which mod_osso facilitates single sign-on. The specific application URLs to be defined as partner applications within this site are defined in the osso.conf file. The ssoreg script is located on the infrastructure tier in ORACLE_HOME/sso/bin (UNIX).
The following example shows the usage of ssoreg in UNIX:

ORACLE_HOME/sso/bin/ssoreg.sh
-site_name www.xyz.com:8090
-config_mod_osso TRUE
-mod_osso_url http://www.xyz.com:8090
-remote_midtier
-config_file ORACLE_HOME/Apache/Apache/conf/osso/osso_xyz.conf

2. Copy the osso_xyz.conf file from your infrastructure home to the ORACLE_INSTANCE/config/OHS/ohs1 directory.

3. Open the httpd.conf file using Oracle Enterprise Manager 11g Fusion Middleware Control, and add the following osso parameters shown in bold:

<VirtualHost *:8888>
ServerName www.xyz.com:8090
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
OssoIpCheck off
OssoSecureCookies off
OssoIdleTimeout off
OssoConfigFile osso_xyz.conf
</VirtualHost>

4. Restart the Oracle HTTP Server.

6.4.4 Verify the Configuration

To verify that the virtual hosts are set up correctly, connect to Oracle Portal using either of the following URLs:

- http://www.abc.com:8090/portal/pls/portal

- http://www.xyz.com:8090/portal/pls/portal

You should get a login screen at http://www.login.com on the first login and must be able to log in successfully. A subsequent login from the other virtual host should result in a successful single sign-on without a prompt for login credentials.

6.4.5 Reconfiguring Portal for a Change in the OracleAS Single Sign-On 10g Host Name

To reconfigure Oracle Portal for a change in the OracleAS Single Sign-On 10g host name, perform the following steps:

1. In the ORACLE_HOME/Apache/Apache/conf/httpd.conf file that is located in the 10g infrastructure home, change the server name to the new host name as shown below.

ServerName new_sso_host

Example:

ServerName sso.mycompany.com

2. Set the ORACLE_HOME environment variable to the 10g infrastructure home.

1. Change the directory to ORACLE_HOME/sso/bin in the 10g infrastructure home.

2. Run the following script (on UNIX):

ssocfg.sh http new_sso_host new_sso_port

Example:

ssocfg.sh http sso.mycompany.com 7777

Note:

On Windows, use the ssocfg.bat script.

3. Register the new OracleAS Single Sign-On 10g partner application.

1. Change the directory to ORACLE_HOME/sso/bin in the 10g infrastructure home.

2. Run the following script:

ssoreg.sh \
-oracle_home_path $ORACLE_HOME \
-site_name infrastructure_middle_tier:port \
-config_mod_osso TRUE \
-mod_osso_url http://new_sso_host:new_sso_port \
-config_file file_name.conf

Example:

ssoreg.sh \
-oracle_home_path $ORACLE_HOME \
-site_name sso.mycompany.com:7777 \
-config_mod_osso TRUE \
-mod_osso_url http://sso.mycompany.com:7777 \
-config_file $ORACLE_HOME/Apache/Apache/conf/osso/osso-sso.conf

Note:

The command-line syntax and example shown here are for UNIX.

For Windows, use the ssoreg.bat script, use a backslash (\) as the directory path separator, and enter the full command on a single line.

3. Back up ORACLE_HOME/Apache/Apache/conf/osso/osso.conf, and replace it with the content from the ORACLE_HOME/Apache/Apache/conf/osso/osso-sso.conf file that you created in the previous step.

4. Update the DCM repository.

$ORACLE_HOME/dcm/bin/dcmctl updateconfig

5. Change the DAS operation URL.

1. Start the OID administration tool (oidadmin).

2. Log in as orcladmin.

3. Navigate to the DAS operation URL as shown below:

4. Update orcldasurlbase with the following value:

http://new_sso_host:new_sso_port/

Example:

http://sso.mycompany.com:7777/

5. Click Apply.

6. Restart the 10g infrastructure tier.

$ORACLE_HOME/opmn/bin/opmnctl stopall
$ORACLE_HOME/opmn/bin/opmnctl startall

7. Register the new mod_osso partner application for Oracle Portal 11g.

1. Change the directory to ORACLE_HOME/sso/bin in the 10g infrastructure home.

2. Run the following script:

ssoreg.sh \
-site_name portal_middle_tier:port \
-config_mod_osso TRUE \
-oracle_home_path $ORACLE_HOME \
-mod_osso_url http://portal_host:port \
-config_file file_name.conf \
-admin_info cn=orcladmin \
-remote_midtier

Example:

ssoreg.sh \
-site_name portal.mycompany.com:8090 \
-config_mod_osso TRUE \
-oracle_home_path $ORACLE_HOME \
-mod_osso_url http://portal.mycompany.com:8090 \
-config_file $ORACLE_HOME/Apache/Apache/conf/osso/osso-portal.conf \
-admin_info cn=orcladmin \
-remote_midtier

Note:

The command-line syntax and example shown here are for UNIX.

For Windows, use the ssoreg.bat script, use a backslash (\) as the directory path separator, and enter the full command on a single line.

3. In the Oracle Portal 11g ORACLE_HOME, back up /config/OHS/ohs1/osso.conf, and replace it with the content from the ORACLE_HOME/Apache/Apache/conf/osso/osso-portal.conf file that you created in the previous step.

8. Restart the WLS_PORTAL managed servers.
Restart Oracle Web Cache by selecting Control, and then Restart from the Web Cache Home page in the Oracle Enterprise Manager 11g.

Finally, restart Oracle HTTP Server, by running the following command from:

ORACLE_INSTANCE\bin\opmnctl stopall
ORACLE_INSTANCE\bin\opmnctl startall

6.5 Configuring Oracle Portal to Use a Proxy Server

You can configure Oracle Portal to use proxy servers to connect to providers and Web sites outside of your firewall.

Notes:

- Oracle Text uses these proxy server settings when indexing URL content. See Section 10.3.6.4, "URL Index Proxy Settings" for more information.

- To configure Oracle Portal to use a proxy server, you must be a portal administrator.

- For the Oracle recommended way of configuring secure enterprise deployments, refer to the Oracle Fusion Middleware Enterprise Deployment Guide for Java EE.

To specify a proxy server:

1. In the Services portlet, click Global Settings.
The Services portlet is on the Administer tab of the Builder page.

2. Click the Proxy tab.

3. In the HTTP Proxy Host field, enter the address for the HTTP proxy server that you want to use to access applications outside your firewall, for example, myproxy.mycompany.com. Do not prefix http:// to the proxy server name.

4. In the Port field, enter the port number for the proxy server. The port number defaults to 80 if no value is specified.

Note:

Contact your server administrator for the names of servers running proxy software and their port numbers.

5. Click Add.
You can now use this proxy server for connections between the portal and Web providers or WSRP producers. You can also use this proxy for other connections, for example, to connect to the URLs specified for URL items.

6. In the Select Proxy section, choose the proxy server you want to use for such connections. Choose None if you do not want to use a proxy server for non-provider connections.

7. In the No Proxy Servers for Domains beginning with field, enter the domains for which the proxy server should not be used.

Note:

The domains must begin with a period (.), for example, .mycompany.com. Separate multiple domains with a comma (,).

8. Click OK.

You will find additional information about how to set up proxy servers in the paper "A Primer on Proxy Servers" on the Oracle Technology Network (OTN), http://www.oracle.com/technology/.

6.6 Configuring Oracle Portal to Work with a Reverse Proxy Server

A reverse proxy server is a host process that is used as part of a firewall architecture to isolate the internal hosts from the externally accessible host(s). It does this by providing a proxy through which external requests must pass to access internal services. Typically, a proxy server takes the form of a dual-homed host. This means that it is a host with two network interface cards. One interface connects to the external network, and the other interface connects to the internal network, or demilitarized zone (DMZ) of the firewall.

Table 6-2 shows an architecture in which the browser accesses the server through the hostname that is published by the proxy server. The proxy server then forwards the request to the actual host within the firewall.

Caution:

For this configuration to work properly, you must first configure OracleAS Single Sign-On to work with the reverse proxy server. Information on deploying OracleAS Single Sign-On with a proxy server can be found in the Oracle Application Server Single Sign-On Administrator's Guide.

Figure 6-5 Reverse Proxy Server Configuration

For this example, consider the following:

Property

Value

External server name

www.abc.com

External server port

80

Internal server name

internal.company.com

Web Cache listening port

8090

Web Cache Administration port

8091

Web Cache invalidation port

8093

OHS listening port

8888

Note:

The name and port values used in this section are for illustration purposes only, and you will need to substitute these with your own. Refer to Managing Ports, in the Oracle Fusion Middleware Administrator's Guide.

Configuring Oracle Portal for the architecture depicted in Figure 6-5 involves the following steps:

1. Configuring Your Reverse Proxy Server

2. Configuring the Virtual Host for Oracle HTTP Server

3. Configuring your Web Cache to Work with the Reverse Proxy Server

4. Configuring the Portal Middle Tier to Work with Reverse Proxy Server

5. Configuring the Oracle WebLogic Server to Work with Reverse Proxy Server

6. Configuring Loopback to the Internal Server

7. Configuring the osso.conf File

8. Verifying Your Configuration

Configuring Your Reverse Proxy Server

You can choose any proxy server to function as a reverse proxy. For example, you can use Oracle Web Cache, Oracle HTTP Server, or Internet Information Services (IIS) listener.

Note:

This section describes how to configure Oracle HTTP Server as a reverse proxy. It is assumed that you have set up and configured Oracle HTTP Server to listen on port 80 and accessed as www.abc.com. On some platforms, if you are using ports less than 1024, it requires additional configuration steps. For more information, refer to the Oracle Fusion Middleware Administrator's Guide.

To use the Oracle HTTP Server as a reverse proxy first install the standalone version of the Oracle HTTP Server on the reverse proxy server. This section explains how to configure the Oracle HTTP Server to pass incoming requests to Oracle Application Server Single Sign-On, Oracle Delegated Administration Services and Oracle Portal, and modify all HTTP headers so that only the identity of the reverse proxy server computer is visible to clients. To configure the Oracle HTTP Server as a reverse proxy, use the RewriteRule directive with the [P] (force proxy) flag to define URL rewriting rules and to pass requests through mod_proxy. Add the Port and the Rewrite directives in the httpd.conf file (ORACLE_INSTANCE\config\OHS\ohs1) at a location by following the LoadModule directives.

ProxyPassReverse / http://internal.company.com:8090
RewriteEngine On
RewriteRule ^/(.*) http://internal.company.com:8090/$1 [P]

Restart your Oracle HTTP Server:

ORACLE_INSTANCE\bin\opmnctl restartproc process-type=OHS

Configuring the Virtual Host for Oracle HTTP Server

On the middle-tier where the Portal is running, set the ServerName directive to point to the server name of the reverse proxy, so that self-referential URLs rendered on Oracle Portal pages are valid for the browser. To do this, complete the following steps:

1. Define a virtual host for the Oracle HTTP Server instance that will be used for the reverse proxy, by using the Create Virtual Host wizard, as explained in Section 6.4.1.1, "Create the Virtual Host for www.xyz.com", with the following exceptions:

- Specify www.abc.com in the Server Name field.

- Specify 80 for the Port directive in the Virtual Host container.

2. Define a virtual host for the Oracle HTTP Server instance that is the Apache Server installed with Oracle Portal, by using the Create Virtual Host wizard, as explained in Section Section 6.4.1.1, "Create the Virtual Host for www.xyz.com", with the following exceptions:

- Specify internal.company.com in the Server Name field.

- Specify 8090 for the Port directive in the VirtualHost container.

3. After you have configured the virtual host, open the httpd.conf file using the Oracle Enterprise Manager 11g Fusion Middleware Control as follows:

1. Expand Web Tier and click the Oracle HTTP Server (ohs1) link for your Oracle Portal instance.

2. In the Oracle HTTP Server home page, select Administration, and then Advanced Configuration.

3. In the Advanced Server Configuration page, select httpd.conf from Select File option, and click Go.

4. Edit the following syntax in the httpd.conf file:

NameVirtualHost *:8888
<VirtualHost *:8888>
ServerName http://www.abc.com:80
RewriteEngine On
RewriteOptions inherit
UseCanonicalName Off
</VirtualHost>

<VirtualHost *:8888>
ServerName internal.company.com:8090
RewriteEngine On
RewriteOptions inherit
UseCanonicalName Off
</VirtualHost>

5. Restart your Oracle HTTP Server:

ORACLE_INSTANCE\bin\opmnctl restartproc process-type=OHS

Configuring your Web Cache to Work with the Reverse Proxy Server

To configure the reverse proxy for Web Cache, you must define a site that matches the virtual host entry, created in the previous section and then create ordered mappings of site to the origin server using the Oracle Fusion Middleware Control. To do this complete the following steps:

1. Navigate to the Web Cache Home page in Enterprise Manager.

2. From the Web Cache menu, select Administration, and then Sites.
The Sites page is displayed.

3. From the Site Definitions section, click Create.
The Create Site Definition page is displayed.

4. Enter the following information:

- Host: www.abc.com

- Port: 80

5. In the Aliases section, click Create to create a new alias.

6. Enter the following information:

- Host: internal.company.com

- Port: 8090
Accept the default settings for the remaining fields.

7. Click OK.

Note:

It is recommended that you delete your unused sites, so that webcache allows only certain types of URLs.

8. From the Sites page, in the Site-to-Server Mapping section, click Create.
The Create Site-to-Server Mapping Definition page is displayed.

9. Enter the following information in the Create Site-to-Server Mapping section:

- Host Pattern: www.abc.com

- Port Pattern: 80

10. In the Origin Servers section, select internal.company.com:8888 from All Origin Servers, and move it to Selected Origin Servers.

11. Click OK.

12. Restart your Oracle Web Cache by selecting Control, and then Restart from the Web Cache Home page in the Oracle Enterprise Manager 11g.

Configuring the Portal Middle Tier to Work with Reverse Proxy Server

Oracle Portal maintains some information related to the URL used to access Portal, you must update the portal middle tier configuration as follows:

1. Navigate to the Portal Home page in the Enterprise Manager.

2. From the Portal menu, select Settings, and then Wire Configuration.
The Portal Wire Configuration page is displayed.

3. Enter the following information under Portal Middle Tier section in the Portal Wire Configuration page:

- Published Host Name: www.abc.com

- Listening Port: 80

4. Click Apply.

5. Restart your managed server (WLS_PORTAL).

Configuring the Oracle WebLogic Server to Work with Reverse Proxy Server

You need to configure the HTTP settings for www.abc.com as follows:

1. Log in to Oracle WebLogic Server Administration Console.

2. If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.

3. In the left pane of the Console, expand Environment and select Clusters.

4. Select the cluster server and, then the HTTP tab.

5. In the HTTP page enter the following information:

- Frontend Host: www.abc.com

- Frontend HTTPPort: 80

6. Click Save.

7. Restart your managed server (WLS_PORTAL).

Configuring Loopback to the Internal Server

To improve performance and to ensure that seeded providers work correctly, the local HOSTS file must be used to resolve domain names that are not normally visible to the internal network. For more information about this loopback connection, refer to Section 1.2.2.2, "How Does Communication Flow in Oracle Portal?".

For example, the Oracle Fusion Middleware host for internal.company.com makes requests to itself, but the URLs that it is requesting are referring to www.abc.com. You must create host entries in the local HOSTS file on that machine, allowing it to resolve this name within the firewall, and ensure that you add an entry for the proxy machine in the /etc/hosts file on the database machine. This step is required for the database machine to resolve the address of the proxy machine on the network. The hosts entry for this example in Windows should include the following lines:

# This is a sample HOSTS file used by Microsoft TCP/IP
# for Windows NT/2000.
127.0.0.1    localhost
123.45.67.8  www.abc.com

If you do not provide these entries in the local HOSTS file, then you must set the Oracle Fusion Middleware host to recognize a proxy server that would take the request out to the Internet and back in through the reverse proxy (www.abc.com), or configure the reverse proxy server's internal interface to respond to www.abc.com.

Note:

On some platforms, such as HP-UX, there is a file that indicates the search order that should be applied to the sources for IP name mapping. For the preceding example to work, if such a file exists on your platform, make sure that it specifies the local hosts file to be checked for IP mapping, before any DNS servers.

Configuring the osso.conf File

You must configure the osso.conf file as follows:

1. Run ssoreg.sh located in ORACLE_HOME/sso/bin (Unix) from your Identity Management instance to register the virtual host for which mod_osso facilitates single sign-on.
The following example shows the usage of ssoreg.sh in UNIX:

$ORACLE_HOME/sso/bin/ssoreg.sh
-site_name www.abc.com:80
-config_mod_osso TRUE
-mod_osso_url http://www.abc.com:80
-update_mode MODIFY
-remote_midtier
-config_file/tmp/osso.conf

On Windows, you must run ssoreg.bat instead.

2. Back up the osso.conf file.

3. Copy the osso.conf file to the ORACLE_INSTANCE/config/OHS/ohs1 directory.

Verifying Your Configuration

After completing the configuration procedures, you can verify your configuration now by accessing the Oracle Portal using the proxy host name and port at http://www.abc.com/portal/pls/portal. Hover over the URLs to ensure that they all show up as www.abc.com and not internal.company.com and the port number in the browser should not be 8090 or 8888.

6.7 Managing Oracle Portal Content Cached in Oracle Web Cache

Oracle Web Cache offers caching, page assembly, and compression features. Oracle Web Cache accelerates the delivery of both static and dynamic Web content, and provides load balancing and failover features for Oracle Fusion Middleware. Refer to Section 1.3, "Understanding Caching in Oracle Portal" for an overview of how caching works in Oracle Portal.

This section discusses how to configure Oracle Portal to work with Oracle Web Cache.

This section contains the following topics:

- Managing Oracle Web Cache

- Configuring Portal Web Cache Settings Using Oracle Enterprise Manager

- Configuring Portal Web Cache Settings Using WLST

- Managing Portal Content Cached in Oracle Web Cache

- Clearing the Cache Invalidation Queue Through SQL*Plus

- Managing the Invalidation Message Processing Job

6.7.1 Managing Oracle Web Cache

In previous releases, you had to use Oracle Web Cache Manager to configure Oracle Web Cache. In this release you can use Oracle Enterprise Manager 11g Fusion Middleware Control to configure Oracle Web Cache and update the Oracle Web Cache configuration file, webcache.xml. Refer to Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache for more information.

6.7.2 Configuring Portal Web Cache Settings Using Oracle Enterprise Manager

Use the Oracle Enterprise Manager 11g Fusion Middleware Control to change Oracle Web Cache settings that Oracle Portal uses, such as the host name, and the invalidation port number. You configure these settings on the Portal Wire Configuration page.

See Also:

Section 8.2.2.6, "Portal Wire Configuration Page" for a detailed description of how to use the Portal Wire Configuration page.

6.7.3 Configuring Portal Web Cache Settings Using WLST

You can use the WLST (Online) command for Portal Web Cache to:

- Listing the Attributes

- Updating the Attributes

6.7.3.1 Listing the Attributes

To List the attributes of Web Cache configuration used by the Portal repository:

Syntax

listPortalWebcacheConfigAttributes ([dad_name])

Argument

Definition

dad_name

Optional. Name of the Database Access Descriptor. Default DAD name is 'portal'.

Example

The following example lists the Web Cache configuration used by the Portal repository. The Web Cache host name to which the invalidation messages are sent, the invalidation user name, password and the invalidation port to which the invalidation messages are sent are listed.

listPortalWebcacheConfigAttributes(dad_name='portal')

---------------
WebCacheConfig
---------------
WebCache Host: foo.oracle.com
WebCache Invalidation Password: invalidator
WebCache Invalidation Port: 6523
WebCache Invalidation User: invalidator

6.7.3.2 Updating the Attributes

To List the attributes of Web Cache configuration used by the Portal repository:

Syntax

setPortalWebcacheConfig([dad_name], [host], [inv_port], [inv_user], [inv_passwd])

Argument

Definition

dad_name

Optional. Name of the Database Access Descriptor. Default DAD name is 'portal'.

host

Optional. The name of the Web Cache host to which invalidation messages are sent.

inv_port

Optional. The Web Cache port number to which invalidation messages are sent.

inv_user

Optional. The user name used for sending the invalidation messages.

inv_password

Optional. Web Cache invalidation password.

Example

The following example updates the Web Cache configuration based on the specified values.

setPortalWebcacheConfig(dad_name='portal',host='example.mycompany.com',inv_port='6523',inv_user='invalidator',inv_passwd='invalidator')

6.7.4 Managing Portal Content Cached in Oracle Web Cache

From the Oracle Portal user interface, you can perform various other tasks to manage portal content cached in Oracle Web Cache. You can either clear the entire portal content cached in Oracle Web Cache, or clear content for each portal user.

Caution:

Clearing the cache results in cache misses on subsequent requests and may degrade the Portal's performance until the cache is repopulated.

You may want to clear the cache if a user's group membership has changed, to remove the cache entries for that user, so that he or she has new privileges. Similarly, if you change a user or group's privileges on an object, you can clear the cache entries for that object.

To clear the entire cache, or to clear the cache for a particular user, you must be the portal administrator. To clear the cache for a particular portal object, you must have at least Manage privileges on the object.

The following sections describe the actions that can be performed using Oracle Portal in more detail:

- Clearing the Entire Web Cache

- Clearing the Cache for a Particular User

- Setting the Expiry Time for Invalidation-based Caching

- Clearing the Cache for a Particular Portal Object

6.7.4.1 Clearing the Entire Web Cache

You can clear the entire Web Cache by performing the following steps:

1. In the Services portlet, click Global Settings.
By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

2. Click the Cache tab.

3. Select Clear The Entire Web Cache.

4. Click Apply or OK to clear the cache.

Note:

This clears all the page URLs and style sheets but not the portal images.

6.7.4.2 Clearing the Cache for a Particular User

You can clear the cache for a particular user by performing the following steps:

1. In the Services portlet, click Global Settings.
By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

2. Click the Cache tab.

3. In the Clear Cache For User field, enter the name of the user for whom you want to clear the cache.

Note:

If you are not sure of the user name, click the Browse Users icon and select from the list provided.

4. Click Apply or OK to clear the cache for the specified user.

Note:

Alternatively, you can clear the cache for a particular user by editing the user's portal profile.

6.7.4.3 Setting the Expiry Time for Invalidation-based Caching

With invalidation-based caching, a cache entry is purged when the portal or a provider sends a message informing Oracle Web Cache that the object has changed (for example, when an item is edited). However you can also set an expiry time for cache entries. A cache entry that reaches this time limit is purged, even if Oracle Web Cache has not received an invalidation message for it.

Note:

To set the expiry time for invalidation-based cache entries, you must be the portal administrator.

To set the expiry time for invalidation-based cache entries:

1. In the Services portlet, click Global Settings.
By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

2. Click the Cache tab.

3. In the Maximum Expiry Time field, enter the maximum amount of time (in minutes) a cache entry should remain in the cache before being purged.

Note:

Choosing a small value for this leads to cache misses more frequently because the cache expires more often. However, choosing a large value might lead to stale content. Avoid a value of 0 because it makes all the portal content non-cacheable.

4. Click OK.

6.7.4.4 Clearing the Cache for a Particular Portal Object

You can clear cache entries for page groups, pages, Portal Templates for pages, portlets in the Portlet Repository, Portal DB Providers, and Portal DB Provider components, by performing the following steps:

1. In the Navigator, drill down to the object with which you want to work.

- For page groups, pages, and Portal Templates for pages, click Properties, then click the Access tab.

- For Portal DB Providers, and Portal DB Provider components, click Grant Access.

- For portlets, click Edit Root Page next to the Portlet Repository page group, drill down to the page that contains the portlet, click the Actions icon next to the portlet, and then click Access.

2. Click Clear Cache.

3. Click OK.

6.7.5 Clearing the Cache Invalidation Queue Through SQL*Plus

Sometimes, the cache invalidation queue can grow excessively large as a result of user actions. For example, repeated granting of security privileges on a page to a group with a large number of members will place one soft invalidation in the queue for every user for every grant.

Some soft invalidations may not be necessary, but Oracle Portal may not be able to determine this. For example, if a group's privileges on a page are upgraded from View to Fully Personalize, and no member of the group has viewed the page yet, then no invalidation is necessary. However, Portal does not have a record of who has viewed the page. Therefore, it proceeds with the soft invalidation configured to use the security change.

The portal administrator can check the number of soft invalidations in the queue by executing the following query in SQL*Plus as the portal schema owner:

select count(1) from wwutl_cache_inval_msg$ where process_type=2;

The portal administrator can check the total number of invalidations, hard or soft, in the queue by executing the following query in SQL*Plus as the portal schema owner:

select count(1) from wwutl_cache_inval_msg$;

The number of rows in the table wwutl_cache_inval_msg$ that can be considered excessive depends, to some extent, on the speed of the infrastructure running the database. Typically, 50000 messages will slow down the soft invalidation job, and sending 50000 invalidation messages to Oracle Web Cache will introduce a network load, as Oracle Portal communicates with the Oracle Web Cache invalidation port.

If the soft invalidations are found to be unnecessary, the portal administrator can perform the following query in SQL*Plus as the portal schema owner:

delete from wwutl_cache_inval_msg$ where process_type=2;

This removes soft invalidations from the queue.

If the soft invalidations are necessary but there is an excessively large number, the portal administrator can clear the cache invalidation queue using the following command:

truncate table  wwutl_cache_inval_msg$;

The portal administrator should then clear the entire cache through the Oracle Portal user interface. Refer to Section 6.7.4.1, "Clearing the Entire Web Cache" for information about performing this task.

6.7.6 Managing the Invalidation Message Processing Job

Oracle Portal uses invalidation messages to expire objects in the cache. You can use the cachjsub.sql script to configure the frequency at which the invalidation job executes. Refer to Section B.1, "Managing the Invalidation Message Processing Job Using cachjsub.sql" for more information and instructions on how to run cachjsub.sql.

6.8 Configuring Oracle Portal to Use a Dedicated Oracle Web Cache Instance

You can deploy Oracle Web Cache on a dedicated server that front-ends one or more Oracle Portal middle-tier servers. Oracle Web Cache performs well even on commodity hardware, so a dedicated deployment does not have to be costly in terms of hardware expenditure. In general, it is recommended to use a computer with 1 GB of memory. Both the cache server and middle-tier server need to use a high speed network card to ensure site performance. Refer to Section 1.3, "Understanding Caching in Oracle Portal" for an overview of how caching works in Oracle Portal.

To set up this topology, the administrator of the Web site needs to disable the Oracle Web Cache that was installed on the same computer as Oracle Portal middle tier, and set up a new Oracle Web Cache instance on a dedicated server. Figure 6-6 shows the topology where Oracle Portal uses a dedicated Oracle Web Cache instance.

Figure 6-6 Oracle Portal Using a Dedicated Oracle Web Cache Instance

6.8.1 Understanding Installation Prerequisites and Requirements

- For the Oracle Portal middle tier, you must install OracleAS Infrastructure first, and then the Portal middle tier.

- After installing the OracleAS Infrastructure and middle tier on their respective servers, install Oracle Web Cache on a dedicated server.

6.8.2 Configuring a Dedicated Oracle Web Cache

Oracle Universal Installer automatically configures and starts Oracle Portal middle tier and Oracle Web Cache on the same computer during the Oracle Portal middle-tier installation. You need to disable the Oracle Web Cache installed on the Oracle Portal middle-tier computer that is not used, and configure the dedicated Oracle Web Cache installed on a different computer to communicate with Oracle Portal middle tier.

Configuring a dedicated Oracle Web Cache for Web site: www.company.com, port number: 7777 involves the following six tasks:

- Task 1: Verify That the Oracle Web Cache on the Dedicated Server Is Running

- Task 2: Configure Oracle Web Cache on the Dedicated Server

- Task 3: Stop the Unused Oracle Web Cache on the Middle-Tier Server

- Task 4: Configure Oracle Portal Middle Tier with Oracle Web Cache Settings

- Task 5: Configure Virtual Host Settings for Oracle HTTP Server

- Task 6: Re-Registering the Oracle HTTP Server Partner Application

6.8.2.1 Task 1: Verify That the Oracle Web Cache on the Dedicated Server Is Running

To properly configure Oracle Web Cache on the dedicated server, Oracle Web Cache needs to be up and running. Refer to the Oracle Fusion Middleware Administrator's Guide for information about how to start, stop, restart, and view the status of Oracle Web Cache on the Fusion Middleware Control home page.

6.8.2.2 Task 2: Configure Oracle Web Cache on the Dedicated Server

To properly configure Oracle Web Cache on the dedicated server, you will need the origin server information from the Oracle Web Cache installed on the same computer as Oracle Portal middle tier. To modify the origin server properties setting from the dedicated Oracle Web Cache instance, follow the instructions in section 2.11.2 Task 2: Specify Origin Server Settings, from the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

6.8.2.3 Task 3: Stop the Unused Oracle Web Cache on the Middle-Tier Server

This task is optional. To save resources on the Oracle Portal middle-tier server, follow the instructions in the Oracle Fusion Middleware Administrator's Guide to stop the unused cache on the middle-tier server. This cache instance will not be used for this deployment option.

6.8.2.4 Task 4: Configure Oracle Portal Middle Tier with Oracle Web Cache Settings

Oracle Portal middle tier needs to know the Oracle Web Cache Listen ports, the invalidator user name, invalidator password settings, and so on. You need to apply the new host name and port number of the dedicated Oracle Web Cache to Oracle Portal middle tier by modifying these settings in the Portal Wire Configuration page:

1. In the Oracle Enterprise Manager 11g, select Portal in the System Components section. The Oracle Portal Home page appears.

2. Right click Portal, and select Settings > Wire Configuration.

3. Click the Portal Web Cache Settings link from the Administration section. The Portal Web Cache Settings page appears.

4. On the Portal Wire Configuration page, under Portal Midtier modify the Host field with proper host name: www.company.com, modify the Listening Port field with proper port number 7777.

5. Review the other Web Cache Settings, like Invalidation Host, to match the cache information on the dedicated server and click Apply. See the online Help for guidance on changing the default ports and password settings.

6.8.2.5 Task 5: Configure Virtual Host Settings for Oracle HTTP Server

You must create virtual host entries in the httpd.conf file of the Oracle HTTP Server that is part of the Oracle Portal middle tier, with the dedicated Oracle Web Cache settings. In this example, you will set up virtual host name www.company.com and port number 7777 (same as the dedicated Oracle Web Cache Listen port). The virtual host name and port number must be consistent with the site definition value defined in Oracle Web Cache. To do this, perform the following tasks:

1. Configure Virtual Hosts Settings, as follows:

1. Log in to the Oracle Enterprise Manager.

2. From the Oracle Enterprise Manager home page, expand Web Tier and select the HTTP Server for your instance.

3. Go to HTTP Server >Administration, and select Virtual Hosts.

4. Click Create.

5. On the Create Virtual Host page, provide the information listed in Table 6-3.

Table 6-3 Virtual Host Information

Virtual Host Information

Value

Virtual Host Name

Select Use existing listen address.

Server Name

Your Domain name, www.company.com

Document Root Directory

ORACLE_INSTANCE\config\OHS\ohs1\htdocs

Directory Index

Can be left blank

Administration E-Mail Address

Valid e-mail address

Type

name-based

6. Click OK.

Note:

Do not restart your Oracle HTTP Server.

2. After you have configured the virtual host, open the httpd.conf file (located at ORACLE_INSTANCE\config\OHS\ohs1) using a text editor and add the Port and the Rewrite directives in the VirtualHost container, as follows (shown in bold text): syntax:

NameVirtualHost *:8888
<VirtualHost *:8888>
ServerName http://www.company.com:7777
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

6.8.2.6 Task 6: Re-Registering the Oracle HTTP Server Partner Application

For information about Re-registering the Oracle HTTP Server Partner application, see Re-register the Oracle HTTP Server Partner Application.

6.9 Changing the Infrastructure Services Used By a Middle Tier

Oracle Portal enables you to change the OracleAS Infrastructure services (either Oracle Identity Management or Oracle Metadata Repository) that a middle tier uses. You can use this feature, for example, to move middle tiers (and their applications) from stage to production. If you are changing the Oracle Metadata Repository that your Oracle Portal uses, then you will also need to move application-specific data stored in the stage Oracle Metadata Repository to an Oracle Metadata Repository in the production environment. Changing the Infrastructure services is convenient, if you need additional computers for the production environment. In a single step, you add a computer that already has a middle tier and deployed applications. For instructions on how to change the Infrastructure Services used by a middle-tier instance, refer to the Oracle Fusion Middleware Administrator's Guide.

Note:

By default, an Oracle Portal middle tier is made up of one portal instance. Both the DAD name and the Oracle Metadata Repository schema name for this instance are portal. You can only change the Infrastructure services of this default Oracle Portal instance in the previously described way.

6.10 Configuring the Cluster Environment After Installation

Portal Configuration includes configuring the middle tier in the filesystem and the repository in the database. For post install configuration changes in the cluster environment, you must update and replicate both these types of configurations in each of the nodes.

6.10.1 Middle Tier Configuration

You must update the middle tier (file system) configuration, for each nodes of the cluster configuration. You can update the midtier configuration, by performing one of the following:

Login to the Oracle Enterprise Manager 11g, and perform the following:

- To change the Portal Cache configuration, from the Portal home page, select Portal, Settings, and then Portal Cache to display the Portal Cache Configuration page. Make the required changes and click Apply. If you want to use the WLST commands, see Configuring the Portal Cache Using WLST.

- To change the Page Engine configuration, from the Portal home page, select Portal, Settings, and then Page Engine to display the Page Engine Configuration page. Make the required changes and click Apply. If you want to use the WLST commands, see Configuring the Parallel Page Engine Using WLST.

6.10.2 Repository Configuration

You must update the repository configuration (database) only once in a cluster configuration, as the updates are made to the backend Portal schema in the database that is shared by all the nodes of the cluster. However the repository configuration can be run repeatedly for each of the nodes like the midtier configuration. To update the repository configuration. login to the Oracle Enterprise Manager 11g Fusion Middleware Control, and from the Portal menu, select Settings, and then Wire Configuration, to display the Portal Wire Configuration page. Make the required changes and click Apply.

If you want to use WLST commands, see Configuring Oracle Portal Using WLST.

6.11 Configuring OracleAS Wireless

In case of multiple middle-tier installations, the first configured OracleAS Wireless service URL is stored in the Oracle Portal instance. You can change this to your choice of OracleAS Wireless service by running the cfgiasw.pl script. Refer to Section B.7, "Using the cfgiasw Script to Configure Mobile Settings" for more information.

Note:

You can also change the URL to your choice of OracleAS Wireless service by running the portalRegistrar script in the Oracle Application Server middle tier selected for the OracleAS Wireless service. Refer to the Oracle Application Server Wireless Administrator's Guide for more information about configuring OracleAS Wireless.

6.12 Changing the Oracle Portal Schema Password

This section provides information about changing schema passwords for both default and nondefault Oracle Portals. For information on how to retrieve the Portal schema password, refer to Section 5.6.10, "Retrieving the Portal Schema Password". The Oracle Portal schema password is created when you load the Portal schema through RCU, and is required for some operations where you need to log in to the Portal schema. The Portal schema password is stored in a an LDAP-Based Credential Store. An LDAP-based policy store is specified in the configuration file jps-config.xml with the element serviceInstance, as illustrated in the following example, which shows the specification of an LDAP-base credential store using an Oracle Internet Directory LDAP server:

<serviceInstance name="someInstance" provider="some_ldap_provider">
...
<property name="credstore.type" value="OID"/>
<property name="ldap.url" value="ldap://someURL"/>
...
</serviceInstance>

The default location of the file jps-config.xml is DOMAIN_HOME\config\fmwconfig.

To Change the Oracle Portal Schema Password, perform the following:

- Depending on your Portal Instance, choose one of the following option:

- Changing the Schema Password for a Default Oracle Portal Instance

- Changing the Schema Password for a Nondefault Oracle Portal Instance

- Changing the Portal Credentials

6.12.1 Changing the Schema Password for a Default Oracle Portal Instance

For information about changing the Oracle Portal schema password for the default Oracle Portal instance, refer to the section on changing Oracle Metadata Repository schema passwords, in the Oracle Fusion Middleware Administrator's Guide.

Note:

By default, an Oracle Portal middle tier is made up of one portal instance. Both the DAD name and the Oracle Metadata Repository schema name for this instance are portal. The section on changing Oracle Metadata Repository schema passwords in the Oracle Fusion Middleware Administrator's Guide describes how to change the schema password for this default Oracle Portal instance.

6.12.2 Changing the Portal Credentials

You can change the Portal credentials using the following option:

- Managing Portal Credentials Using Oracle Enterprise Manager

- Managing Portal Credentials Using WLST Commands

6.12.2.1 Managing Portal Credentials Using Oracle Enterprise Manager

This section explains the steps you follow to manage credentials in a domain credential store with Oracle Enterprise Manager.

1. Log in to Oracle Enterprise Manager and navigate to WebLogic Domain > Domain Name. Right click Domain Name, and select Security > Credentials, to display the Credentials page.
The area Credential Store Provider is read-only and, when expanded, displays the credential store provider currently in use in the domain.

The table below this read-only area allows creating, editing, and searching credentials.

2. At any point, use the button Delete to remove a selected item (key or map) in the table. Note that deleting a credential map, deletes all keys in it. Similarly, use the button Edit to view or modify the data in a selected item.

3. To display credentials matching a given key name, enter the string to match in the box Credential Key Name, and then click the blue button to the right of it. The result of the query is displayed in the table.

4. To redisplay the list of credentials after examining the results of a query, right click Classic Domain and select Security > Credentials.

Create a New Credential Map

To create a new credential map:

1. Click Create Map to display the Create Map dialog.

2. In this dialog, enter the name of the map for the credential being created.

3. Click OK to return to the Credentials page. The new credential map name is displayed with a folder icon in the table.

Add a New Key

To add a new key to a credential map:

1. Click Create Key to display the Create Key dialog.

2. In this dialog, select a map from the pull-down list Select Map where the new key will be inserted, enter a key in the text box Key, select a type from the pull-down list Type (the appearance of the dialog changes according to the type selected), enter the required data.

3. Click OK when finished to return to the Credentials page. The new key is shown under the map icon corresponding to the map you selected.

6.12.2.2 Managing Portal Credentials Using WLST Commands

WLST supports the following online commands to administer credentials:

- listCred

- updateCred

- createCred

- deleteCred

listCred

The command listCred returns the list of attribute values of a credential in the domain credential store with given map name and key name. This command lists the data encapsulated in credentials of type password only.

Script Mode Syntax

listCred -map mapName -key keyName

Interactive Mode Syntax

listCred(map="mapName", key="keyName")

The meanings of the arguments (all required) are as follows:

- map specifies a map name (folder).

- key specifies a key name.

Example

The following invocation returns all the information (such as user name, password, and description) in the credential with map name myMap and key name myKey:

listCred -map myMap -key myKey

updateCred

The command updateCred modifies the type, user name, and password of a credential in the domain credential store with given map name and key name. This command updates the data encapsulated in credentials of type password only.

Script Mode Syntax

updateCred -map mapName
-key keyName
-user userName
-password passW
[-desc description]

Interactive Mode Syntax

updateCred(map="mapName", key="keyName", user="userName", password="passW", [desc="description"])

The meanings of the arguments (optional arguments are enclosed by square brackets) are as follows:

- map specifies a map name (folder) in the credential store.

- key specifies a key name.

- user specifies the credential user name.

- password specifies the credential password.

- desc specifies a string describing the credential.

Example

The following invocation updates the user name, password, and description of the password credential with map name myMap and key name myKey:

updateCred -map myMap
-key myKey
-user myUsr
-password myPassw
-desc "updated usr name and passw to connect to app xyz"

createCred

The command createCred creates a new credential in the domain credential store with a given map name, key name, user name and password. This command can create a credential of type password only.

Script Mode Syntax

createCred -map mapName
-key keyName
-user userName
-password passW
[-desc description]

Interactive Mode Syntax

createCred(map="mapName", key="keyName", user="userName", password="passW", [desc="description"])

The meanings of the arguments (optional arguments are enclosed by square brackets) are as follows:

- map specifies the map name (folder) of the new credential.

- key specifies the key name of the new credential.

- user specifies the new credential user name.

- password specifies the new credential password.

- desc specifies a string describing the new credential.

Example

The following invocation creates a new password credential with the specified data:

createCred -map myMap
-key myKey
-user myUsr
-password myPassw
-desc "new passw cred to connect to app xyz"

deleteCred

The command deleteCred removes a credential with given map name and key name from the domain credential store.

Script Mode Syntax

deleteCred -map mapName -key keyName

Interactive Mode Syntax

deleteCred(map="mapName",key="keyName")

Example

- map specifies a map name (folder).

- key specifies a key name.

Example

The following invocation removes the credential with map name myMap and key name myKey:

deleteCred -map myMap -key myKey

6.12.3 Changing the Schema Password for a Nondefault Oracle Portal Instance

Typically, you use Fusion Middleware Control to change the Oracle Portal schema password, but in the case of a portal instance whose schema resides outside the Oracle Metadata Repository, you have to change the portal schema password using SQL*Plus.

Follow these steps to change schema passwords directly in the database:

1. Connect to the database as a user with SYSDBA privileges.

2. Enter the following command:

SQL> ALTER USER <schema> IDENTIFIED BY <new_password>;

For example, to change the PORTAL30 schema password to "abc123":

SQL> ALTER USER PORTAL30 IDENTIFIED BY abc123;

After this, you have to update the Database Access Descriptor (DAD) with the new password. Perform the following steps to update the DAD update the attributes of the Portal DAD using the following WLST(online) command:

updatePortalDad (name, [schema], [password], [connect_string], [nls_language])

This will update the portal_dads.conf, and then restart your managed server (WLS_PORTAL).

6.13 Configuring Oracle Portal Using WLST

This section provides information on using WLST as an option for the following Portal configuration:

- Configuring Portal Middle Tier

- Configuring Portal Site Attributes

- Configuring Portal Oracle Internet Directory Attributes

Note:

You need to restart your managed server after making the configuration changes.

See:

Chapter 8, "Monitoring and Administering Oracle Portal" for performing the task using the Enterprise Manager.

6.13.1 Configuring Portal Middle Tier

You can use the following WLST Online command to updates the Portal repository with the Portal midtier configuration:

Syntax

setPortalMidtierConfig([dad_name], [ohs_host], [ohs_port], [ohs_protocol], [webcache_host], [webcache_inv_user], [webcache_inv_port], [webcache_inv_passwd])

Argument

Definition

dad_name

Optional. Name of the Database Access Descriptor. Default DAD name is 'portal'.

ohs_host

Optional. Oracle HTTP Server host name.

ohs_port

Optional. Oracle HTTP Server port number.

ohs_protocol

Optional. Oracle HTTP Server protocol.

webcache_host

Optional. The name of the Web Cache host to which invalidation messages are sent.

webcache_inv_user

Optional. The Web Cache user name used for sending the invalidation messages.

webcache_inv_port

Optional. The Web Cache port number to which invalidation messages are sent.

webcache_inv_passwd

Optional. Web Cache invalidation password.

Example

The following example updates the Portal midtier configuration based on the specified values.

setPortalMidtierConfig(dad_name='portal1',ohs_host='foo.oracle.com',ohs_port='8090',ohs_protocol=false,webcache_host='foo.oracle.com',webcache_inv_user= 'invalidator',webcache_inv_port='6523',webcache_inv_passwd='invalidator')

6.13.2 Configuring Portal Site Attributes

You can use the WLST (Online) command to list the attributes of the portal site configuration:

Syntax

listPortalSiteConfigAttributes ([dad_name])

Argument

Definition

dad_name

Optional. Name of the Database Access Descriptor. Default DAD name is 'portal'.

Example

The following example lists the Portal site configuration. Site protocol can be true or false. HTTP is the protocol when site protocol is false and HTTPS is the protocol when the site protocol is true. The site host name and port number are also listed.

listPortalSiteConfigAttributes ([dad_name])

---------------
SiteConfig
---------------
Site Protocol: false
Site Host: foo.oracle.com
Site Port: 8090

6.13.3 Configuring Portal Oracle Internet Directory Attributes

You can use the WLST(Online) command to list and update the attributes of the Oracle Internet Directory configuration:

6.13.3.1 Listing the Attributes

To list the attributes of the Oracle Internet Directory configuration, do the following:

Syntax

listPortalOIDConfigAttributes ([dad_name])

Argument

Definition

dad_name

Optional. Name of the Database Access Descriptor. Default DAD name is 'portal'.

Example

The following example lists the Oracle Internet Directory data, which includes the Oracle Internet Directory host name and port number.

listPortalOIDConfigAttributes(dad_name='portal1')
listPortalOIDConfigAttributes('portal1')

---------------
OidConfig
---------------
OID Port: 13060
OID Host: foo.oracle.com

6.13.3.2 Updating the Attributes

To update the attributes of the Oracle Internet Directory configuration, do the following:

Syntax

setPortalOIDConfig ([dad_name], [host], [port], [protocol], [admin_user], [admin_passwd])

Argument

Definition

dad_name

Optional. Name of the Database Access Descriptor. Default DAD name is 'portal'.

host

Optional. Oracle Internet Directory host name.

port

Optional. Oracle Internet Directory port number.

protocol

Optional. Oracle Internet Directory protocol.

admin_user

Optional. Oracle Internet Directory administrator's name.

admin_passwd

Optional. Oracle Internet Directory administrator's password.

Example

The following example updates the OID configuration based on the specified values.

setPortalOIDConfig(dad_name='portal1',host='foo.oracle.com',port='13060',protocol=false,admin_user='cn=orcladmin',admin_passwd='oracle1')

7 Securing Oracle Portal

One of the most important aspects of any portal solution is security. The ability to control user access to Web content and to protect your site against people breaking into your system is critical. This chapter describes the Oracle Portal security architecture in the following topics:

- About Oracle Portal Security

- Configuring Oracle Fusion Middleware Security Framework for Oracle Portal

- Configuring Oracle Portal Security

See Also:

- Oracle Fusion Middleware Security Guide

- Oracle Fusion Middleware Getting Started with Oracle Identity Management

7.1 About Oracle Portal Security

The following sections provides an overview of the Oracle Portal security and how it works with the Oracle Fusion Middleware Security Framework.

- Oracle Portal Security Model

- Classes of Users and Their Privileges

- Resources Protected

- Authorization and Access Enforcement

- Authorization Modification

- Leveraging Oracle Fusion Middleware Security Services

- Leveraging Oracle Identity Management Infrastructure

- Configuring Dynamic Groups

- Security for Portlets

- Securing Access to Web Services Remote Portlets

- Securing the OmniPortlet and Simple Parameter Form

- Securing the Web Clipping Provider

- Securing the Federated Portal Adapter

- Securing OraDAV

7.1.1 Oracle Portal Security Model

When you make content available on the Web, it is very likely that you need to restrict access to at least some parts of it. For example, it is unlikely that you want every user to be able to see every document on your site. It is even less likely that you want every user to be able to change every document on your site. Oracle Portal provides a comprehensive security model that enables you to completely control what users can see and change on your Web site.

Before a user logs on to Oracle Portal, they can only view the content that the content contributors designate as public. Public content can be viewed by any user who knows the URL of a portal object (for example, a page) and can connect to the computer where it is stored. The user sees only those aspects of the object that are designated as public, such as the public portlets. If the object has no public contents, then the user is denied access to it.

Once the user logs in to the portal, they may or may not be able to see and change content depending upon their access privileges. Typically, an authenticated user can see and do more in the portal than a public user. For example, an authenticated user might see items or portlets on the page that the public user cannot view. An authenticated user might also be able to add and edit content, and change properties, privileges that would typically be denied to a public user. In the portal, you can control access to objects (pages, items, or portlets) by user and group. That is, you might grant access privileges for a page to specific named users, user groups, or a combination of both.

To support this flexible approach to controlling access to Web content, Oracle Portal leverages the other components of Oracle Fusion Middleware and Oracle Database 11g to provide strong protection for your portal. Oracle Portal interacts with all of the following components to implement its security model:

- Oracle Application Server Single Sign-On authenticates users, who are attempting to gain access to non-public areas of your portal.

- mod_osso is an Oracle HTTP Server module that redirects authentication requests to OracleAS Single Sign-On. It also keeps track of user activity in partner applications.

- Oracle Web Cache is the cache used to serve up pages generated by Oracle Portal (or proxied to the Oracle HTTP Server if not able to service the request). Based on invalidation caching, Oracle Portal invalidates the cache when the underlying page or metadata changes.

- Oracle Internet Directory, Oracle's native LDAP version 3 service, acts as the repository for user credentials and group memberships.

- The Oracle Internet Directory's Oracle Delegated Administration Services adds or updates the information stored inside the directory (users and groups).

- Oracle Directory Integration Platform notifies Oracle Portal upon the occurrence of any directory events (for example, user deletions) to which Oracle Portal subscribes. In essence, the directory integration server informs Oracle Portal when a change occurs in the directory that requires a change in Oracle Portal.

Oracle Portal Architecture

Figure 7-1 shows the components and relationships of the Oracle Portal security architecture.

Figure 7-1 Oracle Portal Security Architecture

The Oracle Portal architecture consists of three basic tiers, including the client browser, the middle-tier server, and the infrastructure servers and repositories. By default, Oracle Internet Directory and OracleAS Single Sign-On are installed on the same host as part of the infrastructure installation. This tier is subsequently used for the Oracle Portal installation.

While the default installation has all three servers and repositories installed on the same host, we recommend that you install these functions on separate servers.

In Oracle Portal, the middle and infrastructure tier components have a number of components in common. These include a repository access component made up of a Database Access Descriptor (DAD) and Oracle Fusion Middleware. The latter is used on the infrastructure tier to run Oracle Delegated Administration Services and to execute portal runtime engine on the middle tier.

To optimize the throughput and performance of Oracle Portal, generated pages are cached in Oracle Web Cache. If a request for a portal page can be served from Oracle Web Cache, it will be returned without accessing the Oracle Portal middle tier. If not, the request will be forwarded to the origin HTTP server and the Parallel Page Engine.

If the current user is not authenticated with the Single Sign-On environment, and if the requested page is not a public page, the user is prompted for a user name and password. This function is carried out through a redirection to OracleAS Single Sign-On for authentication, which in turn verifies the credentials against Oracle Internet Directory through an LDAP request. The credentials are compared to those found in the directory.

Upon successful authentication, OracleAS Single Sign-On creates a single sign-on session cookie. Once the user is authenticated and an appropriate Oracle Portal session created, it is necessary to determine which pages and objects the user has the necessary access privileges to. For performance reasons the access control lists (ACLs) for all portal objects are stored in the Oracle Portal schema in the Oracle Metadata Repository along with the definition of the objects being secured.

User and Group provisioning is a function of Oracle Internet Directory. That is, all user and group membership information is stored in the Oracle Internet Directory. When a user first logs in to Oracle Portal, their current group membership is read from the directory and cached in the same repository as the ACLs. This process allows for fast lookup of object privileges. Once the object and page privileges of the user are known, the appropriate page metadata can be generated to allow the Parallel Page Engine to assemble the secured page.

To simplify the provisioning of users and groups in Oracle Internet Directory for use in the portal, Oracle Portal uses Oracle Delegated Administration Services to generate a user interface to allow direct access to Oracle Internet Directory. Calls to Oracle Delegated Administration Services are protected by the mod_osso plug-in, which verifies that the user has been properly authenticated before providing access to the Oracle Internet Directory.

One important feature of the security architecture is the ability to keep the local cached group membership list synchronized with Oracle Internet Directory. The Oracle Directory Integration Platform automatically keeps the locally cached information up-to-date with changes in Oracle Internet Directory.

If you need to authenticate against an external repository, Oracle Internet Directory supports both delegated and external authentication. Likewise, just as the Oracle Directory Integration Platform keeps the local cache synchronized with the Oracle Internet Directory, it also keeps the Oracle Internet Directory synchronized with any external repository.

7.1.2 Classes of Users and Their Privileges

Oracle Portal provides a number of user accounts and groups by default.

- Oracle Portal Default, Seeded User Accounts

- Oracle Portal Default, Seeded Groups

- Oracle Portal Default Schemas

7.1.2.1 Oracle Portal Default, Seeded User Accounts

Table 7-1 describes the user account created by default when Oracle Portal is installed.

Table 7-1 Default Oracle Portal User

User

Description

orcladmin

This account is granted the highest privileges in Oracle Portal. This account is created for the Oracle Fusion Middleware administrators, and uses the password that is supplied during the Oracle Fusion Middleware installation.

This user is also an Oracle Instant Portal administrator for every Oracle Instant Portal, regardless of who created them.

7.1.2.2 Oracle Portal Default, Seeded Groups

Table 7-2 describes the groups created by default when Oracle Portal is installed.

Table 7-2 Default Oracle Portal Groups

GroupFoot 1

Description

AUTHENTICATED_USERS

Is the group that includes any authenticated, or logged in, user. The purpose of this group is to provide a means to assign the default privileges you want every logged in user to have in the portal.

By default, this group is given the Create Group and Create All Styles privileges.

This group is a member of OracleDASCreateGroup.

DBA

Is a highly privileged group established for Oracle Fusion Middleware administrators. Components that are part of Oracle Fusion Middleware grant full component-specific privileges to members of this group.

The DBA group is a member of the PORTAL_ADMINISTRATORS group.

This group is also a member of the following Oracle Fusion Middleware privilege groups:

- OracleDASCreateUser

- OracleDASEditUser

- OracleDASDeleteUser

- OracleDASUserPriv

- OracleDASCreateGroup

- OracleDASEditGroup

- OracleDASDeleteGroup

- OracleDASGroupPriv

- OracleDASConfiguration

Members of DBA do not have the necessary privileges to administer OracleAS Single Sign-On. If you want members of this group to administer OracleAS Single Sign-On, then you must grant them those privileges as described in the Oracle Application Server Single Sign-On Administrator's Guide.

PORTAL_ADMINISTRATORS

Is a highly privileged group established for Oracle Portal.

By default, this group is given the following Oracle Portal global privileges:

- Manage All Page Groups

- Manage All Pages

- Manage All Styles

- Manage All Providers

- Manage All Portlets

- Manage All Portal DB Providers

- Manage All Portal User Profiles

- Edit All Group Profiles

- Manage All Logs

- Execute All Transport Sets

This group is a member of the following Oracle Fusion Middleware privilege groups:

- OracleDASCreateUser

- OracleDASEditUser

- OracleDASDeleteUser

- OracleDASCreateGroup

- OracleDASConfiguration

Members of PORTAL_ADMINISTRATORS do not have the necessary privileges to administer OracleAS Single Sign-On. If you want members of this group to administer OracleAS Single Sign-On, then you must grant them those privileges as described in the Oracle Application Server Single Sign-On Administrator's Guide.

PORTLET_PUBLISHERS

Is a privileged group established for users who need to publish portlets to other users of the portal.

By default, this group is given the Publish All Portlets global privilege of Oracle Portal.

PORTAL_DEVELOPERS

Is a privileged group established for users who are building portlets.

By default, this group is given the following Oracle Portal global privileges:

- Create All Portal DB Providers

- Manage All Shared Components

Portal developers require special privileges to create database providers and portlets. You can assign such privileges to the developers to perform tasks, such as modifying data on all schemas. For more information, refer to Table 7-6. In addition, the administration privilege All Schema object type should also have the Manage privilege. For more information, refer to Table 7-6.

RW_ADMINISTRATOR

Is the group of users who administer Oracle Reports Services reports, printers, calendars, and servers.

You must assign this group any desired object privileges (for example, Manage).

RW_DEVELOPER

Is the group of users who develop Oracle Reports Services reports.

You must assign this group any desired object privileges (for example, Execute or Manage).

RW_POWER_USER

Is the group of users who can modify Oracle Reports Services reports.

You must assign this group any desired object privileges (for example, Execute or Manage).

RW_BASIC_USER

Is the group of users who use Oracle Reports Services reports.

You must assign this group any desired object privileges (for example, Execute).

OIP_USER_ADMINS

Is the group of users who can both create Oracle Instant Portals and perform user administration on them. FMWADMIN users are members of this group.

OIP_AVAILABLE_USERS

Is the group of users who can access Oracle Instant Portals. This list appears in the Manage User Rights dialog box in the Oracle Instant Portal user interface.

Note: To designate Oracle Portal users as Oracle Instant Portal users, use the Groups portlet to add them to the OIP_AVAILABLE_USERS group, which was created by default during the installation process. Then use the Manage User Rights dialog in Oracle Instant Portal to grant the appropriate privileges.

Footnote 1 All groups shown in this table are located in cn=<portal_group_container>,cn=Groups,dc=MyCompany,dc=com. Note that identity management realm name is determined by the domain name of the server on which the system is installed. For example, if the domain name of the server was oracle.com, the default identity management realm name would be dc=oracle,dc=com. If the domain name of the server could not be determined, Oracle Internet Directory defaults to the domain specified during installation by the administrator. The OracleDASxxxxx groups are Oracle Internet Directory privilege groups that reside under cn=groups,cn=OracleContext,dc=MyCompany,dc=com. These groups provide the privileges to perform operations in Oracle Internet Directory, such as creating or editing of users and groups, and their privileges.

Notes:

- When viewing portal-related roles in Oracle Internet Directory Self-Service Console, the descriptions for these roles are prefixed with numbers, for example, portal.040823.142021.462000000. The numbers are actually the name of the Oracle Portal application, and are displayed to enable selection of roles in a multiple-portal environment where multiple portals associated with the same Identity Management system exist.

- When a user is granted Manage privileges on any Oracle Instant Portal's home page, he or she is granted full privileges over that particular portal. The user cannot edit, delete, or even view any other Oracle Instant Portal, unless he or she has been granted explicit permission to do so. However, the user can delete any user in the Manage User Rights dialog box, even those he or she did not create. (For this reason, it's wise to curtail the number of users who have Manage privileges on a home page.)

7.1.2.3 Oracle Portal Default Schemas

When you install Oracle Portal, the installation process installs some default schemas of which you need to be aware.

Table 7-3 describes the schemas created by default when Oracle Portal is installed.

Table 7-3 Default Oracle Portal Schemas

Schema

Description

PREFIX_PORTAL

Contains the Oracle Portal database objects and code.

To execute Web requested procedures, Portal Services uses N-Tier authentication to connect to the schema to which the lightweight user accounts are assigned (by default, PREFIX_PORTAL_PUBLIC). As shown in Figure 7-2, access to the database of the portal user is proxied through the single schema user.

PREFIX_PORTAL_PUBLIC

Is the schema that all lightweight users are mapped to by default. Procedures are granted to the PREFIX_PORTAL_PUBLIC schema specifically. They are no longer granted execute to PUBLIC.

PREFIX_PORTAL_DEMO

Is created to hold some demonstration code. The installation of this schema is optional.

PREFIX_PORTAL_APP

Is used for external JSP application authentication.

Figure 7-2 shows the N-Tier authentication by user proxy.

Figure 7-2 N-Tier Authentication By User Proxy

7.1.3 Resources Protected

Within Oracle Portal, you decide at what level of granularity you want to control access. You can assign privileges to any object for each user or for each group. For example, you can assign access privileges for each user for each and every item in your portal, but this approach creates considerable overhead for your content contributors.

If you want to lessen the burden on contributors, then you can assign privileges for each group at the page level and simply ensure that all of the items that you place on any given page have similar security requirements. With this approach, the security that items receive through the page that contains them is usually sufficient and content contributors only need to assign privileges for items that require higher security than the page.

See Also:

Section 7.1.7.10, "Oracle Delegated Administration Services Public Roles" for information about how you might model privileges.

7.1.3.1 Global Privileges

Use global privileges to give a user or group a certain level of privileges on all objects of a particular type.

Note:

Global privileges confer a great deal of power on the user to whom they are granted. As a result, they should be granted very cautiously and only to users or groups who truly require them. You should only have a small number of users with global privileges.

There are three types of privilege groups:

- Table 7-4, "Page Group Privileges"

- Table 7-5, "Portal DB Provider Privileges"

- Table 7-6, "Administration Privileges"

Table 7-4 Page Group Privileges

Object Type

Privileges

All Page Groups

None: No global page group privileges are granted.

Manage All: Perform any task on any page group. This privilege supersedes any other privilege in the other global page group privileges. For example, this also allows managing of any page.

Manage Classifications: Create, edit, and delete any category, perspective, custom attribute, custom page type, or custom item type in any page group.

Manage Templates: Create, edit, and delete any Portal Template or HTML template in any page group. Grant access to any template.

Manage Styles: Create, edit, and delete any style in any page group.

View: View any page in any page group.

Create: Create page groups, and create any page group object in those page groups. Users or groups with these privileges can also edit and delete the page groups and page group objects they create. Note: These users cannot create any objects in the existing page groups.

All Pages

None: No global page privileges are granted.

Manage: Create, edit, personalize, or delete any page in any page group. Grant access to any page in any page group.

Manage Content: Add, edit, hide, show, share, or delete any item, portlet, or tab on any page in any page group.

Manage Items With Approval: Create new items on any page in any page group. These items are not published until approved via a specified approval process. Users and groups with this privilege can also edit the items they create. Users and groups with this privilege can personalize pages. When approvals are not enabled for the page group, this privilege becomes equivalent to the global privilege Manage Content on the object type All Pages with regard to items.

Manage Styles: Apply an available or new style to any page in any page group. Create, edit, and delete new styles. Note: Only allows editing of styles created by user (cannot modify or delete other user's styles).

Personalize Portlets (Full): Personalize any page in any page group to add, show, hide, delete, move, or rearrange portlets. Personalize any page to show, hide, delete, or rearrange tabs, or add tabs to existing tabbed regions. Personalize any page in any page group to use a different style.

Personalize Portlets (Add-only): Personalize any page in any page group to add portlets or add tabs to existing tabbed regions. Users or groups with these privileges can also delete the portlets they add. Personalize any page in any page group to use a different style.

Personalize Portlets (Hide-Show): Personalize any page in any page group to show or hide portlets or tabs. Personalize any page in any page group to use a different style. Arrange portlets in any page in any page group.

Personalize (Style): Personalize any page in any page group to use a different style.

View: View any page in any page group.

Create: Create subpages in any page group. Users or groups with these privileges can also edit and delete the subpages they create. Note: You must have Manage privileges on the root page in a page group in which you want to create the pages.

All Styles

None: No global style privileges are granted.

Manage: Create, edit, and delete any style in any page group.

View: View any style in any page group.

Publish: Make any style in any page group public for other users to use.

Create: Create styles in any page group. Users or groups with these privileges can also edit and delete the styles they create.

All Providers

None: No global provider privileges are granted.

Manage: Register, edit, deregister any provider, and display and refresh the Portlet Repository. Also allowed to grant edit abilities on any provider.

Edit: Edit any registered provider.

Publish: Register and deregister any provider.

Execute: View the contents of any provider.

Create: Register portlet providers. On the provider the user (or group) creates, the user gets a Manage privilege; therefore, the user can perform all operations (including edit and deregister) on the particular provider that the user has created.

All Portlets

None: No global portlet privileges are granted.

Manage: Create, edit, or delete any portlet in any provider.

Edit: Edit any portlet in any provider.

Execute: Execute any portlet in any provider. Users or groups with these privileges can see all portlets even if the portlet security is enforced. The Show link appears in the Navigator for all portlets.

Access: View any portlet in any provider.

Publish: Publish any page, navigation page, or Portal DB Provider portlet to the portal, making it available for adding to pages.

Table 7-5 Portal DB Provider Privileges

Object Type

Privileges

All Portal DB Providers

None: No global application privileges are granted.

Manage: Edit or delete any Portal DB Provider. Create, edit, or delete any portlet in any Portal DB Provider. Grant access to any Portal DB Provider and any portlet in any Portal DB Provider.

Edit Contents: Edit any portlet in any Portal DB Provider.

View Source: View the package specification and body and run any portlet in any Portal DB Provider. Intended primarily for users or groups who may want to look at a portlet's source so they know how to call it.

Personalize: Run and personalize any portlet in any Portal DB Provider.

Run: Run any portlet in any Portal DB Provider.

Create: Create Portal DB Providers. Users or groups with these privileges can edit, and delete the providers they create and create, edit, and delete any portlet in them.

All Shared Components

None: No global shared component privileges are granted.

Manage: Create, view, copy, edit, delete, and export any shared component in any Portal DB Provider. View and copy any system shared component. Grant access to any non-system shared component.

Create: Create shared components in any Portal DB Provider. View and copy any system shared component. View any shared component. Users and groups with these privileges can view, copy, edit, delete, and export the shared components they create.

Table 7-6 Administration Privileges

Object Type

Privileges

All User Profiles

None: No global user profile privileges are granted.

Manage: Edit any user profile. Grant this privilege to other users and groups.

Edit: Edit any user profile.

All Group Privileges (profiles)

None: No global group profile privileges are granted.

Manage: Edit any group profile. Grant this privilege to other groups. The Privileges tab of the group profile allows the user to assign those privileges to the group. The Manage privilege provides the edit privilege and the ability to grant it to others.

Edit: Edit any portal group profile (setting the default home page and default mobile home page). Note: The ability to change any group's description, memberships, and owners is controlled by the Oracle Internet Directory access control policies, which are administered through membership in the OracleDASEditGroup group.

All Schemas

None: No global schema privileges are granted.

Manage: Create, edit, and drop any schema. Grant access to any schema. Create, edit, drop, and rename any database object in any schema. Query, update, delete, and insert data in any table or view in any schema. Compile any function, procedure, package, or view in any schema. Execute any function, procedure, or package in any schema. Grant access to any database object in any schema.

Modify Data: Create schemas. Query, update, delete, and insert data in any table or view in any schema. Compile any function, procedure, package, or view in any schema. Execute any function, procedure, or package in any schema. Users or groups with these privileges can edit, drop, and grant access to the schemas they create.

Insert Data: Create schemas. Query and insert data in any table or view in any schema. Users or groups with these privileges can edit, drop, and grant access to the schemas they create.

View Data: Create schemas. Query data in any table or view in any schema. Users or groups with these privileges can edit, drop, and grant access to the schemas they create.

Create: Create schemas. Users with these privileges can also edit, drop, and grant access to the schemas they create. Note: If you want a user or group to access the Schemas portlet on the Administer Database tab of the Builder page, either make the user or group a member of the DBA group, or explicitly grant the user or group View privileges on the Administer Database tab. If you do not grant these privileges, the user or group will still be able to use the Navigator to access schemas.

All Logs

None: No global log privileges are granted.

Manage: Edit or purge any log. Grant this privilege to others.

Edit: Edit or purge any log.

View: View any log.

All Transport Sets

None: No global transport set privileges are granted.

Execute: Export and Import objects that are not shared. In addition, users with these privileges can edit or purge Export and Import objects that are not shared.

Manage: Edit or purge any import or export sets. Grant this privilege to others.

7.1.3.2 Object Privileges

You can assign access privileges to users or groups for all of the following objects within Oracle Portal through the Access tab of the object's Edit Page:

Table 7-7 Oracle Portal Objects with Privilege Control

Type of Object

Available Privileges

Inherited Privileges

Calendar

- Manage

- View

- Personalize

- Execute

From Database Provider

Chart

(based on SQL query)

- Manage

- Edit

- View

- Personalize

- Execute

From Database Provider

Chart

(based on wizard)

- Manage

- Edit

- View

- Personalize

- Execute

From Database Provider

Data Component

- Manage

- Edit

- View

- Personalize

- Execute

From Database Provider

Data Component Cell

- Edit

- View

From Data Component

Database Provider

- Manage

- Edit

- View Source

- Personalize

- Execute

Not applicable

Document

- Own

- Manage

- View Only

From page or item

Dynamic Page Component

- Manage

- Edit

- View

- Personalize

- Execute

From Database Provider

FormFoot 1

- Manage

- Edit

- View

- Personalize

- Execute

From Database Provider

Frame Driver

- Manage

- Edit

- View

- Personalize

- Execute

From Database Provider

Hierarchy

- Manage

- Edit

- View

- Personalize

- Execute

From Database Provider

Image Chart

- Manage

- Edit

- View

- Personalize

- Execute

From Database Provider

Link

- Manage

- Edit

- View

- Personalize

- Execute

From Database Provider

List of Values

- Manage

- Edit

- View

- Personalize

- Execute

From Database Provider

Menu

- Manage

- Edit

- View

- Personalize

- Execute

From Database Provider

Oracle Reports Services printer

- Manage

- Edit

- View

- Execute

From Database Provider

Oracle Reports Services report

- Manage

- Edit

- View

- Personalize

- Execute

From Database Provider

Oracle Reports Services Server

- Manage

- Edit

- View

- Execute

From Database Provider

Page

- Manage

- Manage Content

- Manage Items With ApprovalFoot 2

- Manage Style

- Personalize Portlets (Full)

- Personalize Portlets (Add-Only)

- Personalize Portlets (Hide-Show)

- Personalize (Style)

- View

From the root page of the page group

Page group

- Manage All

- Manage Classifications

- Manage Templates

- Manage Styles

- View

Not applicable

Page Item

- Own

- Manage

- View Only

From page

Portlet

- Manage

- Edit

- Execute

- Access

- Publish

Not applicable

Provider

- Manage

- Edit

- Publish

- Execute

Not applicable

Query by example form

- Manage

- Edit

- View

- Personalize

- Execute

From Database Provider

ReportFoot 3

- Manage

- Edit

- View

- Personalize

- Execute

From Database Provider

Schema

- Manage

- Modify

- Insert

- View

Not applicable

URL

- Manage

- Edit

- View

- Personalize

- Execute

From Database Provider

XML

- Manage

- Edit

- View

- Personalize

- Execute

From Database Provider

Footnote 1 You can have many different types of forms (stored procedure or table based, version 2 or version 3 based, and master-detail), but all of these types have the same available privileges and privilege inheritance.

Footnote 2 This privilege is only available on the Access tab if approvals are enabled at the page group level. When approvals are not enabled for the page group, or when approvals are enabled, but there is no approval process defined at the page or page group level, this privilege becomes equivalent to the global privilege Manage Content on the page.

Footnote 3 You can have two different types of reports (SQL and table based), but all of these types have the same available privileges and privilege inheritance.

7.1.3.3 Granting Privileges to New Providers

When you create or register a new provider, a page is created in the Portlet Repository under Portlet Staging Area to display portlets for that provider. This page is not visible to all logged in users. It is only visible to the user who published the provider and portal administrators. The publisher or portal administrator can change the provider page properties to grant privileges to appropriate users or groups, as required.

7.1.3.4 Privileges to Edit Web Providers and Provider Groups

To manage Web providers and provider groups through the user interface, as opposed to working with files directly, you need to grant appropriate privileges to the administrative users. The access control list is implemented differently than for the Oracle Portal schema resident objects. Refer to Section 7.1.3.1, "Global Privileges" and Section 7.1.3.2, "Object Privileges" for information about the Oracle Portal schema resident objects. Rather, the grants for provider privileges are maintained in an XML file.

To grant privileges to edit and delete Web providers or provider groups, you need to manually make changes to the following file:

DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_version\kjdcke\war\WEB-INF\deployment_providerui\provideruiacls.xml

An example of this file follows:

Note:

In this example, the user names any_provider_manage_user, any_provider_edit_user, and so on, are just sample user names used here to illustrate the privilege codes that correspond to the privileges implied by the corresponding user names. An actual user grant would have the OracleAS Single Sign-On user name as the value of the name attribute in the <user> element, and the privilege would be populated with the appropriate privilege code.

<providerui xmlns="http://www.example.com/portal/providerui/1.0">
<objectType name="ALL_OBJECTS">
<object name="ANY_PROVIDER" owner="providerui">
<user name="any_provider_manager_user" privilege="500"/>
<user name="any_provider_edit_user" privilege="400"/>
<user name="any_provider_execute_user" privilege="300"/>
</object>
<object name="ANY_PORTLET" owner="providerui">
<user name="any_portlet_manage_user" privilege="500"/>
<user name="any_portlet_edit_user" privilege="400"/>
<user name="any_portlet_execute_user" privilege="300"/>
</object>
</objectType>
<objectType name="PROVIDER">
<object name="TEST_PROVIDER" owner="providerui">
<user name="provider_manage_user" privilege="500"/>
<user name="provider_edit_user" privilege="400"/>
<user name="provider_execute_user" privilege="300"/>
</object>
</objectType>
<objectType name="PORTLET">
<object name="PORTLET_UNDER_TEST_PROVIDER" owner="TESTPROVIDER">
<user name="portlet_manage_user" privilege="500"/>
<user name="portlet_edit_user" privilege="400"/>
<user name="portlet_execute_user" privilege="300"/>
</object>
</objectType>
</providerui>

This file allows for granting of the following types of privileges, described in the following sections:

- Global Privileges

- Object Level Privileges

7.1.3.4.1 Global Privileges

Table 7-8 describes the global object types and corresponding privilege codes that can be granted to users in the provideruiacls.xml file. When granting a privilege to the user, you should specify the numeric privilege code.

Table 7-8 Global Privilege Codes for provideruiacls.xml

Type of Object

Available Privileges

ANY_PROVIDER

500 (Manage): Can edit, delete, and open any provider or provider group and portlets under them.

400 (Edit): Can edit any provider or provider group and execute the portlets under them.

300 (Execute): Can open any provider or provider group and execute the portlets under them.

ANY_PORTLET

500 (Manage): Can edit, delete, and execute any portlet under any provider.

400 (Edit): Can edit and execute any portlet under any provider.

300 (Execute): Can execute any portlet under any provider.

To add a privilege to a particular user, add an entry in the proper object type container, for example:

<objectType name="ALL_OBJECTS">
<object name="ANY_PROVIDER" owner="providerui">
<user name="jdoe" privilege="400"/>
…
</object>
</objectType>

For these global privileges, the objectType name is set to ALL_OBJECTS, the object owner is set to providerui, and the object name should be ANY_PROVIDER or ANY_PORTLET depending on the type of grant you are setting.

You then set the user name and privilege to the values corresponding to the OracleAS Single Sign-On user name of the grantee and the privilege code you wish to assign. This model does not support any grants to groups. It only supports grants directly to users.

7.1.3.4.2 Object Level Privileges

Table 7-9 describes the object level privileges that can be granted to users to give them privileges on specific object instances as referenced within the provideruiacl.xml XML file.

Table 7-9 Object Privilege Codes for provideruiacl.xml

Type of Object

Available Privileges

PROVIDER

500 (Manage): Can edit, delete, and open the specified provider or provider group and the portlets under it.

400 (Edit): Can edit the specified provider or provider group and execute the portlets under it.

300 (Execute): Can open the specified provider or provider group and execute the portlets under it.

PORTLET

500 (Manage): can edit, delete, and execute the specified portlet under the specified provider.

400 (Edit): Can edit and execute the specified portlet under the specified provider.

300 (Execute): Can execute the specified portlet under the specified provider.

To add a privilege to a particular user, add an entry into the proper object type container, for example:

<objectType name="PORTLET">
<object name="PORTLET_UNDER_TEST_PROVIDER" owner="TESTPROVIDER">
<user name="jdoe" privilege="400"/>
…
</object>
</objectType>

For the object level privileges, the objectType name is set to PROVIDER or PORTLET, depending upon to which object instances you are providing access. The object name is set to the provider name or the portlet name, respectively. The object owner is set to providerui or the name of the associated provider, again respectively for providers and portlets.

Table 7-10 summarizes these rules:

Table 7-10 Attribute Values for Providers and Portlets

Attribute

Provider Instance Grant

Portlet Instance Grant

ObjectType name

PROVIDER

PORTLET

Object name

Provider or provider group name

Portlet name

Object owner

providerui

Provider name

User name

OracleAS Single Sign-On user name

OracleAS Single Sign-On user name

User privilege

Privilege code

Privilege code

7.1.3.5 Privileges to Create and Edit WSRP Producers

For information on granting privileges to create and edit WSRP producers, refer to the Security section of the JSR 168 specification, at:

http://jcp.org/aboutJava/communityprocess/first/jsr168/index.html.

7.1.3.6 Privileges to Edit URL and XML Portlets in the Portlet Repository

To edit URL and XML portlets in the Portlet Repository, privileges need to be granted to the users. The URL and XML portlets are available from the Portlet Builders page in the Portlet Repository. To grant access, or to edit sample providers in the JPDK Web application, you need to manually make changes to provideruiacls.xml in the following folder:

DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_version\kjdcke\war\WEB-INF\deployment_providerui\

Refer to Section 7.1.3.4, "Privileges to Edit Web Providers and Provider Groups" for information about the privileges you can grant.

7.1.4 Authorization and Access Enforcement

When users attempt to log in to Oracle Portal, OracleAS Single Sign-On must first verify their credentials against the directory. Once their identity has been verified, Oracle Portal checks their access privileges in the directory to determine which objects they may see and use within the portal.

1. From Oracle Portal, the user requests to log in by clicking the Login link.

2. The login request is forwarded to mod_osso, which uses dynamic directives to integrate with the OracleAS Single Sign-On server for authentication.

3. OracleAS Single Sign-On verifies the user credentials against the information stored in the directory.

4. If authentication is successful, then OracleAS Single Sign-On creates an SSO cookie for the user. If authentication is not successful, the user is denied access and returned to the login page to re-enter their user name and password.

5. Once the user's identity has been verified, control is returned to Oracle Portal, which creates a portal session cookie. Oracle Portal then connects to the directory and determines the user's group memberships and privileges.

6. Oracle Portal caches the user's membership and privilege information locally for the duration of their session.

7. When the user attempts to access a page, Oracle Portal performs the following checks:

- Checks whether the page is public. If so, the user can view it.

- If the page is not public, Oracle Portal checks the local privilege table to determine whether the current user has privileges to view the page. If the user has viewing privileges, the user can view it.

- If the current user does not have direct viewing privileges on the page, Oracle Portal checks the cached membership information and privilege table to determine whether any of the groups to which the user belongs has privileges to view the page. If one of the groups to which the user belongs has viewing privileges on the page, the user can view it.

Note:

If changes are made to Oracle Internet Directory that affect the user's privileges, a notification is raised and the cached information about the user is invalidated. Thus, Oracle Portal starts enforcing the user's updated privileges as soon as it receives the notification. If you are using groups that are based on the groupOfNames objectclass, then you need to update the provisioning profile. See "Update Subscription Profiles for Groups Based on groupOfNames" for more details.

7.1.5 Authorization Modification

In Oracle Portal 11g, a user's ability to view or edit a page, is based on the definition of an ACL policy, which references the page and the user (and/or any roles to which they belong). The user's privileges are defined by a “named” individual identity, rather than based on a specific business rule (such as from where the request originated). To allow for extensions to this security model, the Oracle Portal 11g includes the Authorization Modifier Package for extending the authorization routines. This package is executed prior to the standard ACL check, and enables additional rules to be evaluated before interrogating the ACL itself. This feature applies only to new pages or page groups, and not to the already existing pages or page groups. If the Authorization Modifier succeeds (returns true) then the authorization check falls through to the default ACL based mechanism in order to determine if the user has the appropriate access rights. Conversely, if the Authorization Modifier denies access (returns false) the ACL is not even interrogated, and the behavior is to act as if the user did not have appropriate privileges for the operation, even if the ACL would have allowed it. By default, the installed Authorization Modification Package always returns true, and hence the functionality is effectively disabled. Thus the determination of access privileges is based solely on the evaluation of the security ACLs. To switch on the Authorization modifier it is necessary to replace the default package body with one that implements the desired business rule.

Portal includes the following authorization modifiers:

- Secure Network Aware Authorization Modifiers

- Default Authorization Modifier

- Page View and Edit Authorization Modifier

7.1.5.1 Secure Network Aware Authorization Modifiers

Oracle Portal is shipped with three predefined Modifier packages (see Table 7-11) which allow for the implementation of a Secure Network Aware Portal environment, this helps to implement security policies based not only on an ACL, but also on the origin of the Portal page request.

Table 7-11 Authorization Modifiers Packages

Script Files

Description

cfgamyes.pkb

The default ConFiGuration Authorization Modifier disables ALL page Editing or Customization functionality for requests which originate outside of the secured network

cfgampev.pkb

The ConFiGuration Authorization Modifier for Page Edit and View, allows for the securing of individual pages outside of the secured network. That is, the ability to prevent the viewing or editing of specific pages when the request originated from outside the secure network environment.

cfgamno.pkb

Returns the Authorization modifier to the default disabled state.

The Modifier packages are available in the ORACLE_HOME\upgrade\portal\admin\plsql\wwc directory.

To run the packages perform the following steps:

1. Using SQL*Plus, connect to the Oracle Portal schema as the owner.

2. Run the required package body script file to over-write the current Authorization Modifier installed.

7.1.5.2 Default Authorization Modifier

This implementation of the Authorization Modifier package uses the existence of the ORA_EXT_REQ CGI environment variable described above to recognize that the request has been received on a server that has been designated as publicly accessible, and hence should be considered outside of the Secure Network environment. Once compiled into the Authorization packages, any request from outside of the network which involves an Edit request is automatically disabled. That is, all customize and Edit links are removed from the page and direct edit URL references are disallowed.

7.1.5.3 Page View and Edit Authorization Modifier

This implementation includes:

7.1.5.3.1 Securing Specific Pages

The more specific Authorization Modifier (cfgampev) also uses the CGI variable to determine an external request. It however uses it in conjunction with defined page meta-data, in the form of a custom page attribute, to localize the desired inside/outside security to a subset of pages within the portal. Hence the ability to have externally available view and/or edit privileges on a specific page is determined on whether one or both named attributes are defined in the page in question.

7.1.5.3.2 Preventing External Viewing of a Specific Page

The ability to view a page externally is determined by the isViewRestricted named custom attribute. Once defined as part of the page description (through the use of a custom page template, the setting of this attribute will determine dynamically if the page is to be viewable, or not. That is, when set to On external viewing of the page is prevented, while a value of 'Off' (the default) indicates it is to be available externally. From the perspective of the end user, the activation of this rule has the effect of removing any links which reference the page as well as preventing any direct URLs to it (such as via a browser bookmark).

7.1.5.3.3 Preventing External Edits and Customization for a Specific Page

In a similar manner, the use of another named attribute isEditRestricted will dictate whether a specific page may be edited from outside of the secured network. This is different to the Default Modifier which globally turns off the ability to perform any editWhen the value of this attribute is set to 'On' the ability to edit/customize the page is revoked, while setting it to 'Off' indicates edits from “outside” are to be allowed. The effect of setting this this attribute is to not only remove the page level edit links, but also revoke the edit/customize capability of the Portlets embedded within the page. function on any page within the Portal.

7.1.5.4 Defining Required Page Attributes for use with Authorization Modifiers

While the attributes described above are not currently part of the standard page meta-data, the extensible page model allows us to add them in the form of “Custom Attributes” to our page definition. By the creation of a custom page type to be used as the basis of the inside/outside secureable pages it is a simple process to allow a page designer to define declaratively whether the page is to be internally secured or accessible both from with-in and with-out the secured network. The following section documents the steps required to create the appropriate page type used to secure a page via the Authorization Modifier functions described above.

1. Log in to the Oracle Portal.

2. From the Portal Builder page, select Navigator.

3. In the Portal Navigator page, under Page Groups Tab, select Shared Objects to define the Custom Attribute and Page Types. It is recommended that these properties are defined as Shared Objects rather than scoped to a specific Page Group, as it allows for their reuse across multiple Page Groups.

Figure 7-3 Shared Objects

4. From the Shared Objects page, select Attributes.

5. In the Attribute page, select Create New... Attribute and enter the following:

- Display Name: Enter isViewRestricted or isEditRestricted depending on the functionality desired. Ensure you have entered the right case as the Authorization modifier rule is case sensitive

- Set the Datatype to Boolean.

Figure 7-4 Create Attribute

6. Click Create.

7. Click isViewRestricted link to edit the attribute.

8. In the Edit Attribute page, select Enable Translations.

9. Click Apply.

10. Click OK.

Once the required custom attribute is defined, you needs to make it part of the meta-data of the page, to do so perform the following:

1. From the Shared Objects, select Page Types.

2. In the Page Type page, select Create New... Page Type and enter the following:

- Display Name: Enter NetworkSecurablePage as the name.

- Base Page Type: Standard.

- Click Create.

- Edit the new Page Type and define the attributes associated with it by selecting the Attributes tab.

- Click NetworkSecurablePage link to edit the page type.

- Click the Attributes tab.

- In the Attributes page, select an attribute from the Available Attributes list to the Selected Attributes list.

- Click Apply.

- Set the default value of the attribute depending on your security requirements.

- Select Required for the Attribute to be shown in the Page Type and Page Designer.
Click Apply.

Figure 7-5 Edit Page Type

You have to configure the Page Group to expose the new Page Type you have created. To complete the task:

1. Select a Page Group, and click Properties.

2. Click Configure tab, from the Edit Page Group Page.

3. Click Edit, under Types and Classification.

4. Select the page you have created in this scenario, NetworkSecurablePage from Hidden Page Types to Visible Page Types, for the Page Group to expose the new Page Type.

Figure 7-6 Page Type

7.1.6 Leveraging Oracle Fusion Middleware Security Services

Oracle Portal leverages Oracle Fusion Middleware Security Services in the following ways:

- SSL Encryption

- J2EE Security

See Also:

For more information:

- Section 7.3.2.1, "Configuring SSL for Oracle Portal"

- Section C.2, "Setting Up a JAZN File for External Communication"

- Oracle Fusion Middleware Services Guide for Oracle Containers for Java EE

SSL Encryption

The use of HTTPS and the Secure Sockets Layer (SSL) allows for the creation of a secured connection between a client and a server. Digital certificates on each end of the communication verify the validity of the server and encryption of the communication to ensure that it is not compromised. You can implement SSL encryption for Oracle Portal through the Oracle Fusion Middleware Security Services.

J2EE Security

JPDK Web providers can leverage WLS J2EE security roles for implementing authorization logic when the container is configured for JAZN LDAP and the portal is configured to use enhanced authentication to ensure message integrity.

See Also:

Section 7.3.1.3.2, "Enhanced Authentication"

7.1.7 Leveraging Oracle Identity Management Infrastructure

To provide a more comprehensive security solution, Oracle Portal takes advantage of a variety of components in the Oracle Identity Management infrastructure:

- Relationship Between Oracle Portal and OracleAS Single Sign-On

- Relationship Between Oracle Portal and Oracle Access Manager

- Relationship Between Oracle Portal and Oracle Internet Directory

- Relationship Between Oracle Portal and Oracle Directory Integration Platform

- Relationship Between Oracle Portal and Oracle Delegated Administration Services

Oracle Portal also takes advantage of Oracle Identity Management when it creates users and groups. The most common way to create users and groups, and set global privileges and preferences for your portal is through the following portlets:

- User Portlet

- Portal User Profile Portlet

- Group Portlet

- Portal Group Profile Portlet

See Also:

Oracle Fusion Middleware Getting Started with Oracle Identity Management

7.1.7.1 Relationship Between Oracle Portal and OracleAS Single Sign-On

Oracle Portal uses OracleAS Single Sign-On for user authentication.

7.1.7.1.1 Support for External Applications

OracleAS Single Sign-On supports the concept of External Applications, which retain their own authentication mechanisms, but for which OracleAS Single Sign-On can automate login for Oracle Portal users. This is achieved by providing an External Applications portlet that exposes the list of external applications registered with the single sign-on server.

Note:

Single sign-on using the Basic authentication method (user name and password) is supported for external applications that users access using Firefox. However, single sign-on is not currently supported when using Internet Explorer 6.x or 7.x for external applications that use the Basic authentication method.

7.1.7.1.2 Support for Global Inactivity Timeout in Oracle Portal

A Global Inactivity Timeout can be configured for the OracleAS Single Sign-On Server. To use this feature, you must configure the OracleAS Single Sign-On Server on the infrastructure tier and mod_osso on the Oracle Fusion Middleware middle tier.

- To configure Global Inactivity Timeout for Oracle Portal 11g with OracleAS Single Sign-On server 10.1.2.x, see the Oracle Application Server Single Sign-On Administrator's Guide.

- To configure Global Inactivity Timeout for Oracle Portal 11g with OracleAS Single Sign-On server 10.1.4.3, perform the following steps:

Note:

All examples mentioned here use codes and directory paths for UNIX. On Windows, use backslash(\) and replace ssoreg.sh with ssoreg.bat.

1. Run the ssogito.sql script, which is located at ORACLE_HOME/sso/admin/plsql/sso.
A list of fields appears.

- In the Enter value for timeout_cookie_domain field, enter the domain name in which Oracle Portal and Single Sign-On are installed (for example: Enter value for timeout_cookie_domain: .acme.org).

- In the Enter value for inactivity period field, enter the length of the desired inactivity period in minutes (for example: Enter value for inactivity_period: 15).

- In the Enter value for new_git_version field, set the value to v3.0.

2. Register MOD_OSSO on the OracleAS Single Sign-On server by running the following command.

/app/oracle/product/sso10143/sso/bin/ssoreg.sh -oracle_home_path /app/oracle/product/sso10143 -site_name ssoacme.org:7777 -config_mod_osso TRUE -mod_osso_url http://sso.acme.org -config_file /app/oracle/product/sso10143/Apache/Apache/conf/osso/osso.conf

3. Set the OssoIdleTimeout parameter to on by editing the mod_osso.conf file, which is located at ORACLE_HOME/Apache/Apache/conf, as shown in the following example:

<IfModule mod_osso.c>
OssoIpCheck off
OssoIdleTimeout on
OssoConfigFile  /app/oracle/product/sso10143/Apache/Apache/conf/osso/osso.conf

4. Restart both OC4J_SECURITY and the Oracle HTTP_Server.

/app/oracle/product/sso10143/opmn/bin/opmnctl restartproc process-type=OC4J_SECURITY
/app/oracle/product/sso10143/opmn/bin/opmnctl restartproc process-type=HTTP_Server

5. Test Global Inactivity Timeout on the OracleAS SIngle Sign-On server.

1. Go to http://sso.acme.org:7777/oiddas.

2. Log in as orcladmin, and wait for 20 minutes.

3. Check whether the server asks for authentication again.

6. Register MOD_OSSO for the Portal server.

ORACLE_HOME/sso/bin/ssoreg.sh
-oracle_home_path $ORACLE_HOME
-site_name www.acme.org:8090
-config_mod_osso TRUE
-mod_osso_url http://www.acme.org:8090
-remote_midtier
-config_file /app/oracle/product/Middleware_Portal/asinst_1/config/OHS/ohs1/osso.conf

7. Set the OssoIdleTimeout parameter to on by editing the mod_osso.conf file, which is located at ORACLE_INSTANCE/config/OHS/ohs1/moduleconf,as shown in the following example:

<IfModule mod_osso.c>
OssoIpCheck off
OssoSecureCookies off
OssoIdleTimeout on
OssoConfigFile osso.conf

8. Restart the HTTP Server from the Portal middle tier.

/app/oracle/product/Middleware_Portal/asinst_1/bin/opmnctl restartproc process-type=OHS

9. Test Gobal Inactivity Timeout on Portal middle tier.

1. Go to http://www.acme.org:8090/portal/pls/portal.

2. Log in as orcladmin, and wait for 20 minutes.

3. Check whether the server asks for authentication again.

7.1.7.2 Relationship Between Oracle Portal and Oracle Access Manager

Oracle Access Manager is a component of Oracle Fusion Middleware that you can use in place of OracleAS Single Sign-On 10g to implement centralized authentication, policy-based authorizations, delegated administration, and so on.

Upgrading from OracleAS Single Sign-On 10g to Oracle Access Manager 11g

You can use the Oracle Fusion Middleware Upgrade Assistant to upgrade from OracleAS Single Sign-On 10g to Oracle Access Manager 11g.

Note:

After upgrading to Oracle Access Manager 11g, you cannot create, administer, and access external applications through the SSO Server Administration portlet. Clicking on any link in the portlet results in an error.

During the upgrade process, if external applications are detected, the Upgrade Assistant provides you the option to discontinue the upgrade process. If you choose to proceed, after upgrading to OAM, external applications will not work; neither can you create and administer external applications.

For more information about upgrading to Oracle Access Manager 11g, see the "Upgrading Your Oracle Single Sign-On Environment" chapter in the Oracle Fusion Middleware Upgrade Guide for Oracle Identity Management. That document describes the upgrade process you should follow depending on whether or not you want to continue using Oracle Delegated Administration Services after upgrading to Oracle Access Manager 11g.

7.1.7.3 Relationship Between Oracle Portal and Oracle Internet Directory

Oracle Internet Directory (OID) is Oracle's highly scalable, native LDAP version 3 service that hosts the Oracle common user identity. Oracle Portal queries OID to determine a user's privileges and what they are entitled to see and do in Oracle Portal. In particular, Oracle Portal retrieves the group memberships of the user from OID to determine what they may access and change.

Given this model, Oracle Portal requires the following interactions with Oracle Internet Directory:

- Oracle Portal specific entries stored in the directory

- Group attributes stored in the directory

- User attributes stored in the directory

- Caching of user and group information from the directory

- Populating user and group lists of values from the directory through Oracle Delegated Administration Services

Oracle Portal makes use of the features in Oracle Internet Directory to provide efficient user and group management. For a complete list of features provided by Oracle Internet Directory, refer to the chapter, "What's New in Oracle Internet Directory" in the Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory. However, a few of Oracle Internet Directory features are not supported by Oracle Portal.

Table 7-12 lists and describes the Oracle Internet Directory features not supported in Oracle Portal.

Table 7-12 Oracle Internet Directory Features Not Supported in Oracle Portal

Features

Description

Dynamic Groups

In dynamic groups, membership is computed dynamically based on specific attribute values and assertions that you specify. Because of the inability to determine when to issue web cache invalidations for dynamic groups, pages that are secured with dynamic groups need to use expiry based caching or no caching.

Single Authentication Security Layer (SASL)

SASL is a method for adding authentication support to connection-based protocols. Oracle Internet Directory server supports SASL-based authentication mechanisms, but currently these mechanisms are not supported in the DBMS_LDAP package, which is used by Oracle Portal.

Client-side referral caching

For performance reasons, an API can be used to cache the cached referral entries on the client side. Currently, there is no support for client-side referral caching in the DBMS_LDAP package, which is used by Oracle Portal.

7.1.7.3.1 Directory Entries in Oracle Internet Directory for Oracle Portal

In order for security to function properly, Oracle Portal requires the following entries in the directory's Directory Information Tree (DIT) structure:

- Default user accounts (cn=PUBLIC, cn=orcladmin) are created in the identity management realm's user base (cn=Users,dc=MyCompany,dc=comFoot 1 ). By default, the orcladmin user is added to the DBA group during portal install and configuration. The PUBLIC user is created for unauthenticated users. Typically, the PUBLIC user entry is for granting viewing privileges on portal content that is accessible to any user, unrestricted.

- Group container is created within the identity management realm's group base (cn=Groups,dc=MyCompany,dc=com^1). Oracle Portal can leverage any group in the directory, but groups are more easily accessed for display in a list of values if they are located within the Oracle Portal group container.
The name of the group container is derived from the following in Oracle Portal:

- Oracle Portal schema name

- Date and time when Oracle Portal began to use Infrastructure Services

The format of the name is:

schema_name.yymmdd.hh24miss.ff

Note:

The name of the group container may have a different format for releases of Oracle Portal older than 10g Release 1.

- Groups are created within the Oracle Portal group container in the directory:

- cn=AUTHENTICATED_USERS

- cn=DBA

- cn=PORTAL_ADMINISTRATORS

- cn=PORTAL_DEVELOPERS

- cn=PORTLET_PUBLISHERS

- cn=RW_ADMINISTRATOR

- cn=RW_DEVELOPER

- cn=RW_POWER_USER

- cn=RW_BASIC_USER

- Application entity (orclApplicationCommonName=application_name) is created in the root Oracle Context (cn=Portal,cn=Products,cn=OracleContext). The application password is randomly generated. Oracle Portal uses this entity to bind to the directory when it needs to query it or perform actions against it (for example, adding a user) on behalf of the user. When Oracle Portal binds to the directory for a user, it uses a proxy connection to connect as the user. This method ensures that the directory properly enforces the user's authorization restrictions. The Oracle Portal application entity obtains the privileges to initiate proxy connections by its membership in the user proxy privileges group (cn=UserProxyPrivilege,cn=Groups,cn=OracleContext). The name of the application entity is derived from the schema and the time that Oracle Portal began to use the Infrastructure Services. For example, the name of the application entity can be portal.040820.123756.096286000, where portal is the schema name and 040820.123756.096286000 is the timestamp in the yymmdd.hh24miss.ff format.

- Directory synchronization subscription A provisioning profile entry is created in the provisioning profiles node of the directory (cn=Provisioning Profiles,cn=changelog subscriber,cn=oracle internet directory). This entry indicates that the directory must notify Oracle Portal when user or group privilege information has changed. It enables Oracle Portal to keep its authorizations synchronized with the information stored in the directory.

Note:

When the provisioning profile is deleted from Oracle Internet Directory, the Enable directory synchronization and Send event notifications every n seconds, disappear from the Directory Synchronization section on the Global Settings page's SSO/OID tab. To navigate to the Global Settings page, in the Portal Builder, go to the Portal subtab on the Administer tab, and click the Global Settings link in the Services Portlet.

Figure 7-7 shows where the Oracle Portal information is located in the directory's DIT structure.

Figure 7-7 Oracle Portal DIT Structure

Under cn=Groups,cn=OracleContext,<subscriber_dn>, there is a cn=Groups container, that contains the following groups:

authenticationServices
userProxyPrivilege
iasadmins
OracleDASCreateUser
OracleDASEditGroup
OracleDASCreateGroup
OracleDASEditUser
OracleDASDeleteUser
OracleDASUserPriv
OracleUserSecurityAdmins
OracleDASDeleteGroup
OracleDASGroupPriv
OracleDASConfiguration

These privilege group entries are modified during a portal installation to add portal groups and the portal application entry to their memberships, to achieve desired portal functionality. As such, portal information is contained in these groups as well.

7.1.7.3.2 User Attributes Stored in Oracle Internet Directory

Oracle Portal, like all other components of Oracle Fusion Middleware, relies upon the directory to store user information. All users in the directory are defined using the following object classes:

- The inetOrgPerson object class contains the entire user attributes defined by the Internet Engineering Task Force (IETF) Request for Comments (RFC) number 2798.

- The orclUser and orclUserV2 object classes contain a set of standard, additional attributes for Oracle products.

The subsequent tables show the various user attributes stored in Oracle Internet Directory.

Table 7-13 inetOrgPerson Attributes

inetOrgPerson (IETF) attributes

Comment

cn

Common name of the user

This attribute is mandatory.

employeeNumber

Number used to identify employees

sn

Last name. This attribute is mandatory. If nothing is explicitly specified for this attribute, the user's nickname is used.

givenName

First name

middleName

displayName

Preferred name

mail

e-mail address

telephoneNumber

homePhone

mobile

pager

facsimileTelephoneNumber

street

l

City of office

st

State of office

postalCode

Postal code of office

c

Country of office

homePostalAddress

Home address

jpegPhoto

Person's picture

o

Organization

title

manager

Employee's supervisor

uid

User ID

userPassword

preferredLanguage

Table 7-14 orclUserV2 Attributes

orclUserv2 attributes

Comments

orclIsVisible

A flag to indicate whether the user should be hidden from all but administrators.

orclDisplayPersonalInfo

A flag to indicate whether a user's personal information should be hidden from all but administrators.

orclMaidenName

orclDateOfBirth

orclHireDate

orclDefaultProfileGroup

Default user group for the person

orclActiveStartDate

When account was activated

orclActiveEndDate

when account was (or will be) terminated

orclTimeZone

orclIsEnabled

A flag to indicate whether the user account is active. If not active, the user will not be allowed to log in.

7.1.7.3.3 Group Attributes Stored in Oracle Internet Directory

Oracle Portal, like all other components of Oracle Fusion Middleware, relies upon the directory to store group information. All groups in the directory are defined using the following object classes:

- The groupOfUniqueNames object class contains all of the group attributes defined by IETF (RFC 2256).

- The orclGroup object class contains a set of standard, additional attributes for Oracle Portal.

Note:

In Oracle Portal 9.0.2 and subsequent releases, you cannot scope groups to a specific page group. This option was available only in Oracle Portal 3.0.9.x and preceding releases.

Figure 7-8 shows where the Oracle Portal information for groups is located in the directory's DIT structure.

Figure 7-8 DIT Structure for Oracle Portal Groups

The subsequent tables show the various group attributes stored in Oracle Internet Directory.

Table 7-15 groupOfUniqueNames/groupOfNames Attributes

groupOfUniqueNames/groupOfNames (IETF) attributes

Comment

cn

The common name of the group, which can be typed into places like the Edit Group field in the Group portlet to locate the group.

description

The text description of the group, which is displayed in lists of values where the group appears.

uniqueMember/member

A list of the distinguished names (DNs) of all of the members of the group. The member DNs can represent a user or another group.

owner

A list of the DNs of all of the users and groups that have the privilege of administering this group.

Table 7-16 orclGroup Attributes

orclGroup attributes

Comment

orclGUID

The globally unique identifier (GUID) for this group.

orclIsVisible

A flag to indicate whether the group is public or private. Private groups only appear in lists of values for their owners. Other users cannot see them.

7.1.7.3.4 Oracle Internet Directory Cache in Oracle Portal

To improve performance, Oracle Portal caches some directory information locally. In particular, Oracle Portal caches the following:

- Directory connection information for Oracle Portal

- URLs for Oracle Delegated Administration Services

- orclGUIDs of certain privilege groups for authorization checks on directory portlets (for example, the User and Group portlets)

- some Oracle Context information

- the locally selected group search and creation bases

- group memberships and default group for each user

The majority of the information cached by Oracle Portal is fairly static (for example, directory connection information). For those items that are more dynamic, such as group memberships and default group, Oracle Portal relies upon the Oracle Directory Integration and Provisioning agent for updates. Oracle Portal maintains a directory synchronization subscription in the directory that flags the agent to notify it of any change events that affect Oracle Portal security (for example, adding or deleting a user from a group).

7.1.7.3.5 User and Group Lists of Values in Oracle Portal

The User, Group, Portal User Profile, and Portal Group Profile portlets include lists of values for users or groups. These lists of values must be populated with information stored in the directory. By default, the list of values displays the groups contained under the Oracle Portal group container in the Oracle Portal DIT structure. You can browse to any group in the tree, if you have the right access privileges.

The groups that are displayed in the list of values for groups depend on the privileges of the user viewing them. For example, if a user views the list of values from the Group portlet, the list only displays those groups that can be edited or deleted by that user. From Oracle Portal 10g Release 2 (10.1.2) onwards, the implementation of the LOVs supports a callback method. This callback mechanism requires corresponding support in the Oracle Delegated Administration Services environment.

If you have upgraded from a release of Oracle Portal earlier than 10g Release 2 (10.1.2), and if your Infrastructure and Fusion Middleware middle tier were separated onto different hosts or protocols, you may have performed additional user and group Lists of Values (LOVs) configuration to accommodate the JavaScript Origin Server Security policy.

There were two configuration options:

- Setting up of a common-domain by running the script secjsdom.sql.

- Deploying Oracle Delegated Administration Services on the middle tier.

If you have installed the appropriate Oracle Delegated Administration Services version in your environment, and have not previously implemented the configuration options mentioned in the preceding text, then no subsequent configuration steps are required in Oracle Portal to support the LOVs on a separate host. However, if you used the configuration options mentioned previously, it is required to remove these steps. This can be done as follows:

1. If Oracle Portal has been configured to use a locally deployed Oracle Delegated Administration Services servlet, reconfigure it to point to the Infrastructure tier by running the secdaslc.sql script as follows:

1. From the operating system prompt, go to the following directory:

ORACLE_HOME\portal\admin\plsql\wwc

2. Using SQL*Plus, connect to the Oracle Portal schema as the owner and run the following commands:

@secdaslc N
commit;

If Oracle Portal is used with an older release of Oracle Delegated Administration Services that does not support the callback method and the directory and Oracle Portal servers reside on different domains, you have to install the required patch to the Oracle Delegated Administration Services environment to support the use of LOVs across domains.

7.1.7.4 Relationship Between Oracle Portal and Oracle Directory Integration Platform

As shown in Figure 7-9, the Oracle Directory Integration Platform provides important services to notify components of user and group change events and synchronize directories.

Figure 7-9 Oracle Directory Integration Platform Synchronization

In the figure, the flow to and from the Oracle Internet Directory has two paths. The first path, labeled Oracle Directory Synchronization Service, shows the concept of synchronization. In this case, the Oracle Internet Directory acts as a gateway to some external directory or repository. The synchronization service ensures that changes are coordinated between the Oracle Internet Directory and its connected directories. Whenever a change occurs in one of the directories, a notification must be raised with the Oracle Internet Directory to appropriately reflect the change across all of the affected directories.

The second path, labeled Oracle Directory Provisioning Integration Service, shows the concept of provisioning. In provisioning, an application, such as Oracle Portal, subscribes to changes to certain user or group information. For example, suppose that an administrator removes a user from a group through the Oracle Delegated Administration Services. As a result of this change, the user should no longer be allowed to access certain pages in Oracle Portal. The Oracle Directory Integration Platform must notify Oracle Portal to update its local cache and immediately prevent the user from accessing the pages to which she no longer should have access.

For provisioning services, components like Oracle Portal subscribe to provisioning events (for example, deletion of a group) to keep their local caches of user and group information synchronized with the central user and group repository in the Oracle Internet Directory. When a change event occurs, all of the components that are subscribed to that change event are notified by the Directory Synchronized Provisioning agent of the Oracle Directory Integration Platform. Oracle Portal sets the portal directory synchronization subscription flag in the directory to indicate that it should be notified whenever a subscribed change event takes place. Table 7-17 shows the events to which Oracle Portal subscribes and the actions it takes when those events occur.

Table 7-17 Directory Synchronized Events Handled By Oracle Portal

Subscribed event

Oracle Portal action

USER DELETE

The local user profile entry is deleted, resulting in the deletion of the user's privileges. Pages associated with this user are invalidated in Oracle Web Cache.

USER MODIFY

(orclDefaultProfileGroup)

The default group of the user is changed in the local user profile.

GROUP DELETE

The local group profile is deleted, resulting in the deletion of the privileges assigned to this group. The WWSEC_FLAT$ table is updated accordingly if immediate synchronization is enabled on the Global Settings SSO/OID tab.

GROUP MODIFY

(uniqueMember, member)

The WWSEC_FLAT$ table is updated to reflect membership changes that affect Oracle Portal if immediate synchronization is enabled on the Global Settings SSO/OID tab.

If the membership changes involve a group being added or deleted from the modified group, the pages associated with the users of the added or deleted group are invalidated in Oracle Web Cache. The reason for this action is that the security changes might affect what is visible on the page or the access privileges of the page itself.

Note:

Oracle Portal does not need to subscribe to user and group creation events. The local user profile is created automatically when a new user first logs on or is assigned some privilege that causes the user to be referenced in an access control list (ACL) of Oracle Portal. Similarly, a local group profile is created automatically when a new group is first referenced in an ACL.

To function properly, Oracle Portal requires the following for its integration with Oracle Directory Integration Platform:

- The Oracle Directory Integration Platform must be running. With Oracle Portal Release 11.0.0 and later, the Oracle Directory Integration and Provisioning agent is started by default if the user had started the infrastructure tier using opmctl start all. To start the Oracle Directory Integration Platform, use the oidctl command. For example:

oidctl instance=1 server=odisrv flags="host=iasqa-ultra1.abc.com port=4032" start

- The subscription profile must be created in the Oracle Internet Directory. A default subscription profile is automatically created during the installation of Oracle Portal.

See Also:

Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory

7.1.7.4.1 Update Subscription Profiles for Groups Based on groupOfNames

By default, groups created in the Oracle Internet Directory by Oracle Delegated Administration Services are based on the IETF object class groupOfUniqueNames. However, there is now support for handling groups created with the object class groupOfNames as well. If your portal has an existing Oracle Directory Integration Platform subscription profile in the Oracle Internet Directory (from 9.0.2), then it would be subscribing to group modifications and deletions based on groups using groupOfUniqueNames. If any existing groups in Oracle Internet Directory are based on the groupOfNames object class you must update the Oracle Directory Integration Platform subscription profile to subscribe to the events for groups based on groupOfNames in addition to groupOfUniqueNames.

To create or update the subscription profile, run oidprovtool as shown in the following example:

oidprovtool operation=create ldap_host=myhost.mycompany.com \
ldap_port=389 \
ldap_user_dn="cn=orcladmin" \
application_dn="orclApplicationCommonName=PORTAL,cn=Portal,cn=Products,cn=OracleContext"\
organization_dn="dc=us,dc=mycompany,dc=com" \
interface_name=PORTAL.WWSEC_OID_SYNC \
interface_type=PLSQL \
interface_connect_info=myhost:1521:iasdb:PORTAL:password\schedule=360 \
event_subscription="USER:dc=us,dc=mycompany,dc=com:DELETE" \
event_subscription="GROUP:dc=us,dc=mycompany,dc=com:DELETE"\
event_subscription="USER:dc=us,dc=mycompany,dc=com:MODIFY (orclDefaultProfileGroup,userpassword)"\
eventsubscription="GROUP:dc=us,dc=mycompany,dc=com:MODIFY(uniqueMember)" \
profile_mode=OUTBOUND

This will create or update the provisioning profile and subscribe to changes for the uniqueMember and member attributes.By default, this provisioning profile is enabled.

7.1.7.5 Relationship Between Oracle Portal and Oracle Delegated Administration Services

In addition to querying the directory for user and group information, Oracle Portal must provide users with the means to add and modify user and group information. To change information in the directory, use the Oracle Delegated Administration Services. Oracle Portal provides links to the delegated administration server for users with the privileges to add and change users and groups.

7.1.7.5.1 Creating and updating information Stored in Oracle Internet Directory

The Oracle Delegated Administration Services provides a comprehensive interface for making updates to the directory. Authenticated users who have the appropriate privileges can access the delegated administration server through the User and Group portlets on the Administration tab in Oracle Portal. To access these portlets, a user must be a member of the OracleDASCreateUser and OracleDASCreateGroup groups, respectively. AUTHENTICATED_USERS may create groups by default.

7.1.7.5.2 Relationship Between Oracle Delegated Administration Services, mod_osso, and the OracleAS Single Sign-On

mod_osso protects URLs behind the OracleAS Single Sign-On environment by making the HTTP server effectively into a partner application. Oracle Delegated Administration Services functionality is single sign-on enabled by using mod_osso to get the user's identify from the OracleAS Single Sign-On session.

Figure 7-10 Relationship between Oracle Delegated Administration Services, mod_osso, and OracleAS Single Sign-On

mod_osso is a module of the Oracle HTTP Server that is written as a partner application. You can use mod_osso to enable applications on WLS applications, for single sign-on. You achieve this by configuring mod_osso with Oracle HTTP Server directives to restrict access to the Oracle Fusion Middleware application URLs.

Oracle Delegated Administration Services relies on mod_osso to authenticate users attempting access. When a user attempts to access an Oracle Delegated Administration Services dialog (for example, a list of users or groups, or the Create User form), mod_osso checks whether the user has been authenticated. mod_osso performs no authorization checks other than checking for authentication. If the user has not been authenticated, mod_osso, which is an OracleAS Single Sign-On partner application, redirects the user's request to OracleAS Single Sign-On. OracleAS Single Sign-On either:

- Finds a cookie that indicates the user has been properly authenticated and sends back an authenticated token to mod_osso.

- Or, if no cookie has been created yet, it brings up the login page to authenticate the user.

Once the user has been properly authenticated, they are redirected by mod_osso to the requested Oracle Delegated Administration Services URL. Oracle Delegated Administration Services then becomes accessible to the user and enforces the user's privileges, typically relying on access control items in the Oracle Internet Directory.

Oracle Delegated Administration Services URLs

The first request to Oracle Delegated Administration Services from a user session in Oracle Portal is redirected to the OracleAS Single Sign-On so that mod_osso, which acts as a partner application on behalf of Oracle Delegated Administration Services, can establish the identity of the user. OracleAS Single Sign-On constructs a URLC token that includes the requested Oracle Delegated Administration Services URL. There is about a 2K limit on the length of the URLC token imposed by Internet Explorer. As such, the length of the Oracle Delegated Administration Services URL is also limited. To provide a seamless integration with Oracle Delegated Administration Services, Oracle Portal includes the URLs of the current portal page and the portal home page within this Oracle Delegated Administration Services URL. A typical Oracle Delegated Administration Services URL appears as follows:

http://myportal.us.abc.com:8090/oiddas/ui/oracle/ldap/das/group/AppCreateGroupInfo
Admin?doneURL=https%3A%2F%2Fwebsvr.us.abc.com%3A5001%2Fportal%2Fpage%3F_
pageid%3D6%2C1%2C6_12%3A6_18%26_dad%3Dportal_9_0_2_6_7%26_schema%3DPORTAL_9_0_2_
6_7&homeURL=https%3A%2F%2Fwebserver.us.abc.com%3A5001%2Fportal%2Fpage%3F_
pageid%3D6%2C1%2C6_12%3A6_18%26_dad%3Dportal_9_0_2_6_7%26_schema%3DPORTAL_9_0_2
_6_7&parentDN=cn%3Dportal_9_0_2_6_
7.s901dev0.portalserver.us.abc.com%2Ccn%3Dgroups%2Cdc%3Dus%2Cdc%3Doracle%2Cdc%3Dco
m&enablePA=true

When this URL is included in the URLC token, which is then encrypted for security reasons, the length of the resulting token easily approaches the 2K threshold. If it exceeds this limit, the browser may show an error.

There is no fixed size for the URL. However, if you see browser errors when performing Oracle Delegated Administration Services operations, you should consider reducing the size of various parts that comprise the portal URL as this will help ensure that the URL does not exceed the 2k limit. For example, limit hostnames to 8 characters or less and DAD names to 6 characters or less.

In the event that you encounter this problem, the work around is to log in to Oracle Delegated Administration Services first through a shorter URL, such as the Directory Administration link in the Services portlet. Any subsequent access to Oracle Delegated Administration Services will then not require SSO redirection, and will succeed.

7.1.7.6 User Portlet

The User portlet on the Portal tab under Administration enables you to create and update users through Oracle Delegated Administration Services. To create a new user, click the Create New Users link in the User portlet. To update information for an existing user, enter their user name in the Name field or choose it from the list of values and click Edit. To delete a user, enter their user name in the Name field or choose it from the list of values and click Delete.

Note:

Only a user who is a member of the OracleDASCreateUser, OracleDASEditUser, or OracleDASDeleteUser privilege groups can see the User portlet. The link to create new users is displayed only to users who are members of the OracleDASCreateUser group.

See Also:

Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory

Figure 7-11 User Portlet

7.1.7.7 Portal User Profile Portlet

Note:

The Portal User Profile portlet is only visible to users with Manage or Edit privileges for All User Profiles.

To set global user privileges and preferences that pertain specifically to the portal, use the Portal User Profile portlet. To update a user's portal preferences and privileges, enter their user name in the Name field or choose it from the list of values. You can set all of the following for the user's profile:

- Preferences

- whether the user can access the portal

- database schema name for the user

- whether the user has a personal page

- default user group for the user

- default home page for the user

- default style for the user

- whether to clear the Oracle Web Cache for the user

- Global Privileges

- page group privileges

- Portal DB Provider privileges

- administration privileges

Figure 7-12 Portal User Profile Portlet

7.1.7.8 Group Portlet

Note:

Every user can see the Group portlet, but the link to create new groups is displayed only to users who are members of the OracleDASCreateGroup privilege group. Users can only edit or delete a group if they are the group's owner or a member of a group with appropriate access control information (ACI) to edit or delete the group. The following privilege groups are seeded in the Oracle Internet Directory:

- OracleDASCreateGroup

- OracleDASEditGroup

- OracleDASDeleteGroup

The preceding privilege groups imply global privileges, and should be allocated carefully.

The Group portlet on the Portal tab under Administration enables you to create and update user groups through Oracle Delegated Administration Services. To create a new group, click the Create New Groups link in the Group portlet. To update information for an existing group, enter its name in the Name field or choose it from the list of values and click Edit. To delete a group, enter the group name in the Name field or choose it from the list of values and click Delete.

See Also:

Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory

Figure 7-13 Group Portlet

7.1.7.9 Portal Group Profile Portlet

Note:

The Portal Group Profile portlet is displayed to all users, but only users with the Manage or Edit privilege for All Group Profiles, or the owner of a group can edit its profile.

To set global group preferences and privileges that pertain specifically to the portal, you need to use the Portal Group Profile portlet. To update a group's portal preferences and privileges, enter the group name in the Name field or choose it from the list of values. You can set all of the following for the group's profile:

- Preferences

- default home page for the group

- default style for the group

- Global Privileges

- page group privileges

- Portal DB privileges

- administration privileges

Figure 7-14 Portal Group Profile Portlet

7.1.7.10 Oracle Delegated Administration Services Public Roles

In many cases, it is more efficient to use roles exposed by Oracle Delegated Administration Services to assign privileges for each individual user. When creating users, you might notice a section called Roles Assignment on the Create User page.

Note:

In releases before 9.0.4, roles were called public groups.

Roles provide a very convenient mechanism by which users can be created and granted a set of privileges simultaneously. When a check box for a role is checked for a given user, they are granted the designated role upon creation. As an administrator, you can create your own roles and pre-assign any combination of Oracle Internet Directory and Oracle Portal privileges to them.

7.1.7.10.1 Example: Defining a User Administrator Role

Suppose that you want to create a role with the appropriate privileges for a user administrator. You could create such a role by following these steps:

Step 1: Create a group.

You begin by creating a group as follows:

1. From Portal Builder (the Design-Time pages), click Administer, if you are not already on the Administer tab.

2. Click Create New Group in the Group portlet and the Create Group page appears, as shown in Figure 7-15.

Figure 7-15 Create Group Page

3. Enter the required fields (indicated by asterisks).

4. On the Create Group page, click Privilege Assignment to go to that section and choose the following privileges, as shown in Figure 7-16:

- Allow user creation

- Allow user editing

- Allow user deletion

Figure 7-16 Privilege Assignment Section of the Create Group Page

5. Click Submit.

Step 2: Assign the Manage privilege for all user profiles.

After you create the user administrator group, you need to assign it the Manage privilege for all user profiles. This privilege is the only global privilege that you need to assign to this group for user administration.

1. From Portal Builder (the Design-Time pages), click Administer, if you are not already on the Administer tab.

2. From the Portal Group Profile portlet, enter the name of your newly created group and click Edit.

3. Click Privileges tab.

4. Scroll down to the Administration Privileges section, shown in Figure 7-17. From the list next to All User Profiles, choose Manage.

Figure 7-17 Administration Privileges Section of the Edit Group Profile Page

5. Click OK.

Step 3: Make the group a role.

Now that you have created a group representing the user administrator role, you need to enable it as a role so it appears in the list of roles on the Create User page.

1. From Portal Builder (the Design-Time pages), click Administer, if you are not already on the Administer tab.

2. In the Services portlet, click Directory Administration.

3. Click Configuration tab.

4. Click User Entry.

5. Click Next until you reach Step 5 of 5, Configure Roles, of the wizard, as shown in Figure 7-18.

6. Click Add Role to choose the new group and add it to the list of roles.

Figure 7-18 Configure Roles Page

7. Click Finish. Your group will now appear in the list of public groups on the Create User page.

Step 4: Hide detailed privilege assignment section.

To encourage the usage of roles rather than direct privilege assignment, you can turn off the detailed privilege assignment section of the Create Users page. To implement this change, you need to update a configuration entry in the Oracle Portal schema. This setting stops Oracle Delegated Administration Services from displaying the Privilege Assignment section in the Create/Edit User page when it is called from an Oracle Portal administration page.

1. Log in to the PORTAL schema through SQL*Plus.

Note:

The PORTAL schema password is stored in the Oracle Internet Directory and the entry may be viewed by an administrator using the oidadmin utility with the following path under Entry Management:

OrclResourceName=PORTAL,orclReferenceName=iasdb.myho

st.au.oracle.com,cn=IAS Infrastructure

Databases,cn=IAS,cn=Products,cn=OracleContext

2. Invoke the following commands to set the das_enable_pa variable in Oracle Portal's Oracle Internet Directory configuration preference store:

$ sqlplus
...
Enter user-name: portal
Enter password:
...
SQL> set serverout on
SQL> exec wwsec_oid.set_preference_value('das_enable_pa', 'N');

PL/SQL procedure successfully completed.

SQL> commit;

Commit complete.

SQL> exit
...

3. Because the User Portlet is cached in Oracle Web Cache and the Oracle Portal middle-tier file system cache, you must invalidate the cached version of the portlet before you are done. Updating the configuration parameter changes the behavior of the portlet, but updating the parameter does not invalidate the cache. Follow these steps to invalidate the cached version of the User Portlet:

1. Log in to Oracle Portal as a user with administrator privileges.

2. Go to the Builder.

3. Click the Administration tab.

4. From the Portal tab, open Global Settings and navigate to the SSO/OID tab.

5. Scroll to the bottom of the page.

6. Select Refresh Cache for OID Parameters.

7. Click Apply.

See Also:

Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache

Step 5: Validate your changes.

Once you have performed steps 1 through 4, go to the Create User page to verify that your user administrator group appears there. Note how the other Oracle Portal administrative roles, or groups, are already pre-seeded into the Roles Assignment list on this page.

7.1.8 Configuring Dynamic Groups

Dynamic group support relies on the dynamically populated static group functionality. Dynamic groups in 11.1.1 are exposed in the same manner as static groups (in fact a dynamic group can be a composite of a static member list and a dynamically determined membership).

The dynamic membership of the group is defined through the setting of the group's labeledURI attribute with an appropriate LDAP query filter. The query filter defines the set of users that will define the membership of the group.

Note:

The labeledURI attribute is not exposed in the DAS console, so a dynamic group cannot be defined in DAS. The labeledURI attribute must be defined within Oracle Directory Manager, or by using an appropriate LDAP command, such as ldapmodify, from the command line.

7.1.8.1 Defining the Dynamic Group

You can create the dynamic group in two ways:

- Create the dynamic group with an LDIF file and using the ldapadd command

- Create the dynamic group using the Oracle Directory Services Manager (ODSM)

Option 1: Create Dynamic Group Using an LDIF file

To create the dynamic group using an LDIF file:

1. Create an LDIF file with a text editor. The following example shows how a dynamic group can be defined that represents all users under the default user search base, with the title of "Manager":

Example 7-1 Defining a Dynamic Group

dn: cn=managers,cn=portal.070720.104824.056918000,cn=groups,dc=us,dc=orac
le,dc=com
labeleduri: ldap://myserver.mycompany.com.com:12061/cn=users,dc=us,dc=mybiz,dc=com
??sub?(title=Manager)
description: Dynamic Group of Managers
cn: Managers
orclisvisible: true
objectclass: orclDynamicGroup
objectclass: orclGroup
objectclass: top
objectclass: groupOfUniqueNames
displayname: Managers
owner: cn=fmwadmin,cn=users,dc=us,dc=mybiz,dc=com

Note:

The labledURI syntax for an LDAP URL is defined in RFC 2255 (http://www.faqs.org/rfcs/rfc2255.html). In the example above, it is representing a search for any entry under the DN cn=users,dc=us,dc=mybiz,dc=com with the attribute title=Manager. This is to be done on the server myserver.mycompany.com at LDAP port 12061 and using a subtree ("sub") search.

A dynamic group can be defined on any attribute or condition that can be represented as an LDAP URL and defined in the labeledURI attribute. Dynamic groups can also be defined using the ConnectBy assertion, which is included in the orclDynamicGroup objectClass. Refer to the Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory for more information for this alternate approach.

2. Save the file, and then update the OID server by issuing the ldapadd command. For example:
ldapadd -h myserver -p 12061 -D cn=fmwadmin -w mybiz1 –f managers.ldif –v

add labeleduri: ldap://myserver.mycompany.com:12061/cn=users,dc=us,dc=mybiz,dc=com??sub?(title=Manager)

add description:

Dynamic Group of Managers

add cn:

Managers

add orclisvisible:

true

add objectclass:

orclDynamicGroup

orclGroup

top

groupOfUniqueNames

add displayname:

Managers

add owner:

cn=fmwadmin,cn=users,dc=us,dc=mybiz,dc=com

adding new entry cn=managers,cn=portal.070720.104824.056918000,cn=groups,dc=us,dc=mybiz,dc=com

modify complete

Option 2: Create a Dynamic Group Using ODSM

1. Invoke Oracle Directory Services Manager (ODSM) and connect to the Oracle Internet Directory server.
Refer to section "7.1.2 Using Oracle Directory Services Manager" in the Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory for information on invoking and using the Oracle Directory Services Manager.

2. From the Go to list, select Data Browser.

3. Click on the New Entry icon in the data browser.

4. Provide the DN and add the objectclasses orclDynamicGroup and groupOfUniqueNames.

5. On the Mandatory Properties tab, provide the CN attribute.

6. On the Optional Properties tab, provide the attributes for labeleduri.

7. Click OK to complete the definition of the dynamic group.

When you refresh the tree view you'll see the new group that you created. Note that group members will not be shown in ODSM.

7.1.8.2 Using a Dynamic Group to Secure a Page

Once the dynamic group is defined, it can be used as a guarantee to secure pages in the Portal. Since updates to dynamic groups do not issue DIP change events, the Portal doesn't have any trigger to invalidate pages that may be affected by these dynamic groups. Therefore, pages using dynamic groups to secure them should either not be cached, or cached with expiry-based caching at the user level with a cache duration appropriate for the attribute being used to define the dynamic group.

7.1.9 Security for Portlets

Portlets act as windows on your application, displaying summary information and providing a way to access the full functionality of the application. Portlets expose application functionality directly in your portal or provide deep links that take you to the application itself to perform a task. Because portlets format information for display on a Web page, the underlying application need not be Web enabled to be integrated with Oracle Portal.

In Oracle Portal, portlets are managed by providers. A provider is an application that you register with Oracle Portal. Oracle Portal supports three types of providers:

- Web providers

- Database providers

- Web Services for Remote Portlets (WSRP) producers

Portlet security consists of three major areas of functionality:

- Authentication: When a user first accesses a secure URL, they must be challenged for information that verifies their identity, such as a user name and password, or a digital certificate.

- Authorization: Authorization is the process that allows certain users to access parts of an application. Some parts of an application may have public access while others may be accessible only to a limited number of authenticated users.

- Communication security: Communication security is the means by which Oracle Portal establishes the authenticity of communications (for example, messages) to and from providers. In a heavily networked environment, it is critical to verify that communications are authenticate.

To make your Web providers truly secure, you need to make sure that they are secured in each of these areas. If you only implement security features for one or two out of three areas, then your providers cannot be considered secure. The effort you expend to secure a Web provider should be proportional to the confidentiality of the data the provider exposes.

To make your WSRP portlets secure, ensure that Oracle Portal and the WSRP producers communicate through an inherently secure network, such as a VPN network or a network that is behind a firewall.

7.1.9.1 Authentication

When a user first logs in to Oracle Portal, they must enter their password to verify their identity before being permitted access. OracleAS Single Sign-On manages the login process. Refer to Section 7.1.9.7, "Single Sign-On" for more information.

7.1.9.2 Authorization

Authorization determines whether a particular user should view or interact with a portlet. There are two types of authorization checks:

- Portal Access Control Lists: When you log in to Oracle Portal, OracleAS Single Sign-On authenticates you. Once authenticated, Oracle Portal uses access control lists (ACLs) to grant you privileges on portal objects such as pages and portlets. The actions may range from simply viewing an object to performing administrative functions. If you do not belong to a group that has been granted a specific privilege, Oracle Portal prevents you from performing the actions associated with that privilege.

- Programmatic Portlet Security: The Portal Developer's Kit-Java includes APIs that are called to determine if a particular user is authorized to view a portlet. You can use these APIs to implement authorization logic that augments the Portal ACL security.

- J2EE Security Roles: You can use J2EE programmatic security in your provider code. To leverage this capability, you must configure your provider for enhanced authentication to protect the integrity of the asserted identity. From within your portlet code, you can use request.isUserInRole("securityrole"), where request is the HttpServletRequest request and securityrole is a declared J2EE security role. Refer to Section 7.3.1.3.2, "Enhanced Authentication" for more information on how to configure enhanced authentication.

7.1.9.3 Communication Security

Authentication and authorization are important components of securing your Web providers. They do not, however, check the authenticity of messages being received by a provider and are therefore not suitable on their own for securing access to a provider. If the communication is unsecured, someone could imitate Oracle Portal and fool the Web provider into returning sensitive information.

Communication security focuses on securing communications between Oracle Portal and a JPDK Web provider. These methods do not apply to database providers, which execute within the portal database. There are three types of communication security:

- Portal Server Authentication ensures that incoming messages came from a trusted host.

- Message Authentication ensures that the incoming messages were not tampered with.

- Message Encryption protects the contents of a message by encrypting them.

7.1.9.3.1 Portal Server Authentication

Portal Server Authentication restricts access to a provider to a small number of recognized computers. This method compares the IP address or the hostname of an incoming HTTP message with a list of trusted hosts. If the IP address or hostname is in the list, the message is passed to the provider. If not, it is rejected before reaching the provider.

7.1.9.3.2 Message Authentication

Message authentication works by appending a checksum based on a shared key to provider messages. When a message is received by the provider, the authenticity of the message is confirmed by calculating the expected value of the checksum and comparing it with the actual value received. If the values are the same, the message is accepted. If they are different the message is rejected without further processing. The checksum includes a time stamp to reduce the chance of a message being illegally recorded in transit and resent later.

See Also:

Section 7.1.9.9, "Message Authentication"

7.1.9.3.3 Message encryption

Message encryption relies on the use of the HTTPS protocol for communication between the provider and Oracle Portal. Messages are strongly encrypted to protect the data therein and provide confidentiality. While encryption provides a high level of security, it also of necessity impacts performance.

Note:

Use of the HTTPS protocol for communication between Oracle Portal and WSRP producers is not supported in this release.

7.1.9.4 Access Control Lists

When you log in to Oracle Portal, OracleAS Single Sign-On authenticates you. Oracle Portal then uses access control lists (ACLs) to determine if you are authorized to view each piece of content, including providers and portlets. If you do not belong to a group that has been granted a specific privilege, Oracle Portal prevents you from performing the actions associated with that privilege.

ACLs are managed by the following:

- Privileges define the actions that can be performed on the object to which they are granted. Several privileges can be granted, such as Manage, Execute, Access, and Publish. If you set any of these privileges, then the user can access the portlet.

- Users and their privileges are managed from the Portal tab under the Administer tab of the builder.

- Group membership in a group and the privileges granted to the group are managed from the Portal tab under the Administer tab of the builder. A privilege granted to a user group is inherited by all members of that group.

- Privileges can be granted to a provider. By default, those privileges apply to the provider and all the portlets in the provider. Provider ACLs are managed on the Provider tab of the navigator.

- Privileges for portlets can override the privilege set for the portlet's provider. Portlet ACLs are managed on the Provider tab of the navigator. Using Open for the Provider takes you to a page to manage the portlets of the provider.

7.1.9.4.1 Advantages

- ACLs offer a simple, yet very powerful, mechanism to secure portal objects.

- Because the management of users and groups is centralized, you do not have to change the ACLs as the membership of groups changes.

7.1.9.4.2 Disadvantages

ACLs are applied at the provider or portlet level. You cannot vary the security rules for a portlet depending on the portal page on which the portlet is placed.

7.1.9.5 Oracle Portal Server Authentication

One way you can prevent unauthorized access to providers is to restrict access to the provider to known client computers at the server level. This method goes some way toward defending against denial of service attacks.

In the Oracle HTTP Server, you can permit or deny directives in the httpd.conf file based on hostnames or IP addresses. If hostnames are used as discriminators, the server needs to look them up on its Domain Name Server, which incurs overhead to the processing of each request. Using the IP address prevents this added overhead, but the IP address may change without warning.

7.1.9.5.1 Advantages

- This approach only allows trusted hosts to access the provider.

- You can set the restrictions up easily.

7.1.9.5.2 Disadvantages

- Oracle Web Cache does not have IP address checking capability. If you have Oracle Web Cache in front of a provider, a client on any host can send show requests to Oracle Web Cache.

- You can circumvent this approach by sending messages to a provider containing fake IP addresses and hostnames. This method is tricky to carry out effectively because return messages will go to the computer with the copied IP address, but it can still cause problems.

The following sections are applicable for Web providers only and not WSRP producers.

7.1.9.6 Securing the Portal Tools Provider Configuration Pages

Out of the box, the Portal Tools (OmniPortlet and Web Clipping) provider configuration pages are protected with certain privileges. Refer to Section 7.1.3.4, "Privileges to Edit Web Providers and Provider Groups" for more information about these privileges. In the event that the pages are no longer protected, check in the web.xml file under the DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_version\kjdcke\war\WEB-INF directory, that the following param-value is set to true and not false:

<init-param>
<param-name>oracle.webdb.providerui.securedAccessParam</param-name>
<param-value>true</param-value>
</init-param>

7.1.9.7 Single Sign-On

Portlets act as windows into an application by displaying a summary of content and a method for accessing the full functionality of the application. Portlets can expose application functionality directly in the portal or provide deep links into the application itself to perform a task.

If the application does not perform authorization, then users need not be authenticated to see and use it or its associated portlets. For more restricted applications, you need to authenticate the user who is accessing the application:

- Partner applications share the same authenticated user as the Oracle Portal user. The application user and the Oracle Portal user are the same in this case.

- External applications use a different authentication mechanism than Oracle Portal and usually a different repository for user credentials. The application user name can be the same as in Oracle Portal, but the external application verifies the user through its own mechanism.

7.1.9.7.1 Partner Application

A partner application shares the same OracleAS Single Sign-On as Oracle Portal for authentication. Sharing OracleAS Single Sign-On instances means that when a user is already logged into Oracle Portal, their identity can be asserted to the partner application without logging in again.

Partner applications tightly integrate with OracleAS Single Sign-On. When a user attempts to access a partner application, the partner application delegates the authentication of the user to OracleAS Single Sign-On. Once authenticated with a valid user name and password, a user need not provide a user name or password when accessing other partner applications that share the same OracleAS Single Sign-On instance. OracleAS Single Sign-On determines that the user was successfully authenticated and indicates successful authentication to the other partner applications.

The partner application provider trusts Oracle Portal to authenticate the user on the provider's behalf. This relationship is possible because Oracle Portal is, itself, a partner application. Partner application providers must trust Oracle Portal to authenticate the user in this way because the provider cannot perform the authentication itself. Authenticating the user directly requires the provider to redirect the browser to OracleAS Single Sign-On and provide success and failure URLs. This method is not possible due to the provider architecture. The primary reason for it is that the authentication occurs in response to an API call from Oracle Portal to the provider. OracleAS Single Sign-On cannot imitate that call upon successful authentication to the initSession()/dologin() method to complete its normal processing.

Authentication of users in partner applications differ from conventional applications. Partner applications delegate user authentication to OracleAS Single Sign-On. If the user has not been authenticated, OracleAS Single Sign-On displays a login page prompting the user to enter a user name and password. The login page submits the user name and password back to OracleAS Single Sign-On.

If successfully authenticated, OracleAS Single Sign-On creates a special cookie containing information about the user. For security, OracleAS Single Sign-On encrypts the contents of the cookie. The cookie is sent back to the user's browser but is scoped such that only OracleAS Single Sign-On can access it. It is not passed to any other listeners. After creating the cookie, OracleAS Single Sign-On redirects the Web browser to the success URL specified by the partner application. At this point, the partner application creates an application session cookie which contains information the application needs to reestablish the session later. Upon making subsequent requests to the partner application, it detects the presence of the partner application session cookie and from it knows that the user is already authenticated.

If the user later accesses another partner application, that application looks for its application specific session cookie. If the cookie is not found, the application redirects the request to OracleAS Single Sign-On as described previously. This time OracleAS Single Sign-On detects the presence of the user's OracleAS Single Sign-On cookie. This cookie indicates that the user is already authenticated and OracleAS Single Sign-On redirects the browser to the success URL of the second partner application without prompting the user for credentials again. At this point, the partner application creates its own application specific session cookie.

In order to protect the integrity of the identity assertion made by Oracle Portal to the provider, message authentication with HMAC should be configured. See Section 7.3.1.3, "Configuring Provider Message Authentication" for information on how to set this up.

Advantages

- Provides the tightest integration with Oracle Portal and OracleAS Single Sign-On.

- Provides the best OracleAS Single Sign-On experience to users.

- Provides the most secure form of integration because user names and passwords are not transmitted between the portal and the provider.

- The application and the portal share the same user repository, which reduces user maintenance.

Disadvantages

- The application must share the same user repository as Oracle Portal even though the application's user community may be a subset of the portal's user community. This minor issue can be addressed because you can restrict access to the portal pages that expose the application to the application's user community.

- The application can only be tightly integrated with one or more OracleAS Single Sign-On if they share the same user repository.

Implementation Techniques

You make an application a partner application by protecting its URLs using mod_osso. Once configured, mod_osso restricts access to URLs and handles such things as the redirection to OracleAS Single Sign-On and the creation of cookies.

mod_osso

mod_osso is a general purpose Oracle HTTP Server module and a partner application of OracleAS Single Sign-On. It uses OracleAS Single Sign-On to do the authentication. The module does all the communication and handling of cookies between the Oracle HTTP Server and OracleAS Single Sign-On. If mod_osso is configured to protect the URLs of a Web application, then the application effectively becomes a partner application.

Oracle Portal is also a partner application and uses OracleAS Single Sign-On to authenticate users. Provided Oracle Portal and mod_osso use the same OracleAS Single Sign-On instance, the user can access either the Web application or Oracle Portal by logging in to either one, that is, they need only login once to be able to access both the Web application and Oracle Portal.

Advantages

- mod_osso is simple to set up.

- You need no additional code in the application.

- New features to the OracleAS Single Sign-On environment are exposed through simple dynamic directives.

- mod_osso generates a partner application cookie and does all the cookie handling.

- mod_osso secures the partner application and deep links from the partner application provider.

Disadvantages

- Although not neccessarily a drawback, mod_osso can only be used with Web applications.

7.1.9.7.2 External Application

An External Application is an application that uses a different authentication mechanism than Oracle Portal. The application may use a different instance of OracleAS Single Sign-On than that used by Oracle Portal or some other authentication method. In either case, OracleAS Single Sign-On stores user name mappings, passwords, and any other required credentials to authenticate the user in each external application. When a user is already logged in to Oracle Portal, they will be logged into the external application without having to enter their user name or password.

Applications that manage their own authentication of users can be loosely integrated with OracleAS Single Sign-On by registering as external applications. An external application can be exposed as a provider using the Oracle Fusion Middleware Portal Developer Kit so that it may be accessed from a portlet on a page. External application providers are only available to JPDK Web providers.

See Also:

For more information about the External Applications portlet, see the Oracle Fusion Middleware User's Guide for Oracle Portal.

When a previously authenticated user accesses an external application for the first time, OracleAS Single Sign-On attempts to authenticate the user with the external application. The authentication is performed by submitting an HTTP request that combines the registration information and the user's user name and password for the application. If the user has not yet registered their user name and password for the external application, OracleAS Single Sign-On prompts the user for the required information before making the authentication request. When a user supplies a user name and password for an external application, OracleAS Single Sign-On maps the new user name and password to the user's Oracle Portal user name and stores them. The next time the user needs to access the external application the stored credentials are used.

Note:

If there is a change in the URL of an external application, then the external application must be updated in the OracleAS Single Sign-On Server. For information about updating the external application, refer to the "Editing an External Application" section in the Oracle Application Server Single Sign-On Administrator's Guide.

Advantages

- Allows integration with many portals. If there is a preferred portal, the application could be integrated as a partner application of that portal and an external application of other portals.

- Provides a single sign-on experience for users. However, users still need to maintain different user names and passwords. In addition, the external application user name mapping must be maintained.

- Allows integration with multiple portals independent of their user repositories and single sign-on mechanisms.

Disadvantages

- External applications do not share the same user repository as the portal, which requires additional maintenance of user information.

- The user name and password is transmitted to the provider in plain text. This approach is not as secure as a partner application. Configuring the provider URL to use SSL addresses this issue.

- The application must be written using a technology that can be easily integrated with Java or PL/SQL.

7.1.9.7.3 No Application Authentication

In this case, the provider trusts the portal sending the requests. The provider can determine if the user is logged in and the portal user name, but the application has not authenticated the user.

Advantages

You can implement this form of integration most easily and very fast.

Disadvantages

Provides the weakest integration with Oracle Portal. However, this may not be an issue if your portlet content is not sensitive, or if the provider location is secured by the network topology and only accessible by the portal.

7.1.9.8 Programmatic Portlet Security

You can implement portlet security methods within a provider to verify that given users may access portlet instances. These security methods work at the portlet level, that is, each portlet may have its own user access control. By implementing access control methods in the provider, content may only be retrieved from a portlet if the user's credentials pass the authorization logic. If you do not implement portlet security methods in the provider, any user name may be passed in, even a fictitious, unauthenticated one.

A provider can implement two portlet security methods:

- Get a list of portlets

- Determine portlet accessibility

These methods have access to the following information about authorization level:

- Strong indicates that OracleAS Single Sign-On has authenticated a user in the current Oracle Portal session, that is, the user logged in to Oracle Portal with a valid user name and password, and called the portlet in that session.

- Public indicates a user has not logged in within the context of the current Oracle Portal session and does not have a persistent cookie to indicate that such a state previously existed.

Portlets can also access the Oracle Portal user privileges and group memberships:

- User's default group

- User or group privileges

- User's highest available privilege across all groups

- Objects a user can access

7.1.9.8.1 Advantages

With portlet security methods, you can have a portlet produce different output depending on the user's level of authorization.

7.1.9.8.2 Disadvantages

Most security manager implementations use the authorization level or some other user specific element in an incoming message. A check of this type could be bypassed by an entity imitating Oracle Portal.

7.1.9.9 Message Authentication

The Oracle Fusion Middleware Portal Developer Kit supports message authentication to limit access to a specified provider instance or group of provider instances. A provider is registered with a secret shared key known only to the portal and provider administrators.

An Oracle Portal instance sends a digital signature, calculated using a Hashed Message Authentication Code (HMAC) algorithm, with each message to a provider. A provider may authenticate the message by checking the signature with its own copy of the shared key. This technique may be used in SSL communication with a provider instead of client certificates.

An Oracle Portal instance calculates a signature based on user information, a shared key, and a time stamp. The signature and time stamp are sent as part of the SOAP message. The time stamp is based on UTC (coordinated universal time, the scientific name for Greenwich Mean Time) so that time stamps can be used in messages between computers in different time zones.

When the provider receives this message it will generate its own copy of the signature. If the signatures agree, it will then compare the message time stamp with the current time. If the difference between the two is within an acceptable value the message is considered authentic and processed accordingly.

A single provider instance cannot support more than one shared key. Multiple keys could cause security and administration problems if several clients sharing a provider use the same key. For instance, if one copy of the shared key is compromised in some way, the provider administrator has to create a new key, distribute it to all of the clients, and the clients must then update their provider definition. The way around this issue is to deploy different provider services, specifying a unique shared key for each service. Each provider service has its own deployment properties file so that each service is configured independently of the others. The overhead of deploying multiple provider services within the same provider adapter is relatively small.

If a provider does not have an Oracle Web Cache in front of it, the use of the same signature cookie over the lifetime of a provider session means you must trade off between performance and the security provided by authenticating the requests. The signature cookie value is calculated only once after the initial SOAP request establishes the session with the provider. The shorter the provider session timeout, the more often a signature will be calculated to provide greater security against an illegal show request. However, the SOAP request required to establish a session takes more time.

In a provider that uses Oracle Web Cache to cache show request responses, you make a similar trade-off. Cached content is secured in the sense that incoming requests must include the signature cookie to retrieve the cached content, but caching content for an extended period of time leaves the provider open to illegal show requests.

The signature element provides protection against interception and the resending of messages, but it does nothing to prevent the interception and reading of message contents. Messages are still transmitted in plain text. If you are concerned about the content of messages being read by unauthorized people, you should use message authentication in conjunction with SSL.

See Also:

Section 7.3.1.3, "Configuring Provider Message Authentication"

7.1.9.9.1 Advantages

Message authentication ensures that the message received by a provider comes from a legitimate Oracle Portal instance.

7.1.9.9.2 Disadvantages

- Message authentication can cause administration problems if a provider serves more than one Oracle Portal instance.

- Message authentication has a performance implication if made very secure by having a short session timeout.

7.1.9.10 HTTPS Communication

Normal communication between Oracle Portal and a provider uses HTTP, a network protocol that transmits data as plain text using TCP as the transport layer. An unauthorized agent can read an intercepted message. HTTPS uses an extra security layer (SSL) on top of TCP to secure communication between a client and a server.

Each entity (for example, an Oracle Web Cache instance) that receives a communication using SSL has a freely available public key and a private key known only to the entity itself. Any messages sent to an entity are encrypted with its public key. A message encrypted by the public key may only be decrypted by the private key so that even if a message is intercepted it cannot be decrypted.

Certificates are used to sign communications, thereby ensuring that the public key does in fact belong to the correct entity. These certificates are issued by trusted third parties known as Certification Authorities (CA), for example, OracleAS Certificate Authority or Verisign. They contain an entity's name, public key, and other security credentials. They are installed on the server end of an SSL communication to verify the identity of the server. Client certificates may also be installed on the client to verify the identity of a client, but this feature is not yet supported Oracle Portal. Message authentication may be used instead.

Oracle Wallet Manager is the application used to manage public key security credentials. It is used to generate public/private key pairs, create a certificate request to a CA, and then install the certificate on a server.

7.1.9.11 Configuration of SSL

When a provider is registered from an Oracle Portal instance, only one URL is entered. HTTP or HTTPS may be used, but not a combination of both.

A server side certificate that is installed on a computer identifies that computer, or the domain, and may be used by any number of port definitions on that computer. A certificate trust list ensures that communication is limited to specifically identified servers. Message authentication should be used as well to fully secure communication between a trusted Oracle Portal instance and a provider.

See Also:

- Section 7.3.2.1, "Configuring SSL for Oracle Portal"

- Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory

- Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache

7.1.9.11.1 Advantages

- SSL encrypts the contents of a portlet during the transmission of the data from the provider to the Parallel Page Engine. To further secure the portlet contents, the surrounding page should be invoked by a SSL based request.

7.1.9.11.2 Disadvantages

- Encryption has a performance impact on Oracle Portal.

- If used, encryption requires all portlets from a provider to use HTTPS even if some of the content is public.

You will find additional information on security for your Web providers in the papers:

- Overview of Provider Security

- Overview of Password Authenticated Applications

on the Oracle Technology Network (OTN), http://www.oracle.com/technology/.

7.1.10 Securing Access to Web Services Remote Portlets

This section describes how to secure access to WSRP portlets from Oracle Portal.

- Setting Up the Keystores

- Configuring the Producer

For a conceptual overview of WSRP producers, see the Oracle Fusion Middleware Developer's Guide for Oracle Portal.

7.1.10.1 Setting Up the Keystores

The security credentials of the WSRP producer and Portal application can be retrieved and managed using a Java Keystore (JKS) or an Oracle Wallet. A keystore is a file that provides information about available public and private keys. Keys are used for a variety of purposes, including authentication and data integrity. User certificates and the trust points needed to validate the certificates of peers are also stored securely in the wallet or keystore. See the Oracle Fusion Middleware Security and Administrator's Guide for Web Services for information about keystores.

The consumer in the step-by-step procedures below is the Oracle Portal, which consumes portlets generated by the remote portlet producer over WSRP. The producer uses the public key of the consumer to verify the authenticity of the security tokens received from the consumer in the WS-Security headers of the requests it receives over its getMarkup interface. To do this, the producer needs a Java keystore that contains the certificate of the consumer and the root certificate used to sign it. These certificates are added to the Java keystore as trusted certificates.

This section describes how to create keystores and keys using a Java Keystore (JKS). JKS is the proprietary keystore format defined by Sun Microsystems. To create and manage the keys and certificates in the JKS, use the keytool utility that is distributed with the Java JDK 6.

Create Java keystores for the consumer and producer

To create Java keystores for the consumer, perform the following steps:

1. Go to MW_HOME\jdk160_xx_\bin and open a command prompt.

2. Using keytool, generate a key pair:

keytool -genkeypair -keyalg RSA -dname "<consumer_dname>" -alias <consumer_alias> -keypass <key_password> -keystore <keystore> -storepass <keystore_password> -validity <days_valid>

where:

- <consumer_dname> is the name of the consumer (for example, cn=consumer,dc=example,dc=com)

- <consumer_alias> is the alias of the consumer (for example, consumer)

- <key_password> is the password for the new public key, (for example, welcome1)

- <keystore> is the keystore name, (for example, consumer.jks)

- <keystore_password> is the keystore password, (for example, welcome1)

- <days_valid> is the number of days for which the key password is valid (for example, 360).

Note:

You must use the -keyalg parameter and specify RSA as its value as shown above as the default algorithm (DSA) used by keytool for generating the key will not work.

3. Export the public key for the consumer:

keytool -exportcert -v -alias <consumer_alias> -keystore <keystore> -storepass <keystore_password> -rfc -file <certificate_file>

where:

- <consumer_alias> is the alias of the consumer (for example, consumer)

- <keystore> is the keystore name, (for example, consumer.jks)

- <key_password> is the password for the public key, (for example, welcome1)

- <keystore_password> is the keystore password, (for example, welcome1)

- <certificate_file> is the file name for the certificate to export the key to (for example, consumer.cer)

4. Importing the trusted certificate in the producer keystore:

keytool -importcert -alias <consumer_alias> -file <certificate_file> -keystore <keystore> -storepass <keystore_password>

where:

- <consumer_alias> is the alias of the consumer

- <certificate_file> is the consumer certificate file name

- <keystore> is the producer keystore name

- <keystore_password> is the producer keystore password

7.1.10.2 Configuring the Producer

To configure the producer, do the following:

- Configuring the Global Keystore

- Registering the WSRP Producer

Configuring the Global Keystore

To configure the keystore, do the following:

1. Login to your Oracle Portal.

2. Click the Administer tab.

3. In the Services portlet, click Global Settings.
By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

4. Click Keystore tab.
The Default Keystore page is displayed.

5. In the Default Keystore page, enter the required information.

6. Click Apply.

7. Click OK.

Registering the WSRP Producer

To register the producer, do the following:

1. Click the Portlets subtab.

2. In the Remote Providers portlet, click Register a Provider to display the Register Provider page and enter the following information:

- In the Name field, enter the name of the provider. This name must not be more than 200 characters or contain spaces or other special characters.

- In the Display Name field, enter a name to display for the provider when it is referenced, for example in the Portlet Repository. The display name must not be more than 200 characters.

- In the Timeout field, enter the number of seconds Oracle Portal should try to connect to the provider before displaying the timeout message.

- In the Timeout Message field, enter the message to display when Oracle Portal cannot establish contact with the provider within the number of seconds specified in the Timeout field. The message displays within the body of the portlet.

- From the Implementation Style list, select WSRP for your WSRP provider.

Click Next to display the Define Connection page.

3. In the WSDL URL field, enter the WSDL URL for your provider and click Next.
The Portal Registration Property Values page is displayed.

4. Provide any registration properties required by the provider. If there are none, you can proceed to the next step.
The WS-Security Configuration page is displayed.

5. In the Keystore Configuration section, enter the parameters discussed in Table 7-18.

Table 7-18 WSRP Producer Key Store Connection Parameters

Field

Description

Store Path

Enter the full path to the keystore that contains the certificate and the private key that is used for signing some parts (security token and SOAP message body) of the SOAP message.

The selected file could be a keystore created with the JDK keytool, or an Oracle Wallet.

Store Password

Provide the password to the key store that was set when the key store was created. Ensure that you enter the correct store password. If you enter a wrong password, the producer portlet displays an error during runtime.

Store Type

Select a keystore type (JKS or ORACLEWALLET) for this producer.

Signature Key Alias

Select a signature key alias from the list.

Signature Key Password

Specify the password for accessing the key identified by the alias specified in Signature Key Alias.

6. Click Finish. You should see a Registration Confirmation page.

Note:

PeopleSoft 8.48 and 8.49 WSRP producers support the Username Token profile only. An Oracle WSRP producer supports SAML Token profile. For other WSRP containers, check with the specific vendor to determine the token formats they support.

7.1.11 Securing the OmniPortlet and Simple Parameter Form

The OmniPortlet and simple parameter form are located under Portlet Builders in the Portlet Repository. By default, any user who has the privilege to create pages can add these portlets to a page and define them. Furthermore, a user who has at the minimum Manage Content privileges on the page can define these portlets by clicking the Define OmniPortlet or Define Simple Parameter Form.

To control this kind of access, you can activate a privilege check. Once you perform the procedure that follows, the display of these portlets depends upon the privileges granted to the user or user group from the Access tab. To perform any operations on the portlet, the user or user group needs at least the Execute privilege.

1. Log in to Oracle Portal.

2. Click the Navigator link.

3. Click the Portlet Repository page group.

4. Click Pages.

5. Next to the Portlet Builders page, click Edit.

6. Click Page: Access in the upper left of the page.

7. Select Enable Item Level Security.

8. Click OK.

9. Click the Edit Item icon next to OmniPortlet.

10. Click the Access tab.

11. Check Define Portlet Access Privileges.

12. Click Apply and note the appearance of the Grant Access and Change Access sections of the page.

13. Use the Grant Access section to assign privileges to users and groups as desired.

14. Click OK.

15. Repeat steps 9 through 14 for the Simple Parameter Form.

7.1.12 Securing the Web Clipping Provider

Appendix E, "Configuring the Portal Tools Providers" describes the administrative tasks that must be performed before you are able to use the Web Clipping provider. The following sections describe some security configuration options that you should implement to enable the Web Clipping provider to access trusted sites and encrypt the channel between itself and the database:

- Adding Certificates for Trusted Sites

- Configuring Oracle Advanced Security for the Web Clipping Provider

7.1.12.1 Adding Certificates for Trusted Sites

When a user navigates to a secure site, the Web site typically returns a certificate, identifying itself to the user when asking for secure information. If the user accepts the certificate, the certificate is placed into the list of trusted certificates of the browser so that a secure channel can be opened between the browser and that server. Like a Web browser, the Web Clipping provider behaves as an HTTP client to external Web sites. In order for the Web Clipping provider to keep track of trusted sites, it makes use of a file that stores the certificates of those sites, namely the ca-bundle.crt file, located in the ORACLE_HOME\portal\conf directory.

The shipped ca-bundle.crt is an exported version of the trusted server certificate file from Oracle Wallet Manager. The default trusted server certificate in Oracle Wallet Manager does not cover all possible server certificates that exist on the Web. For this reason, when a user navigates to a secure server using HTTPS, the user may get an SSL Hand-shake failed exception in the Web Clipping Studio. To solve this problem, the ca-bundle.crt file needs to be augmented with new trusted sites that are visited. As a portal administrator, you must do the following to extend the shipped ca-bundle.crt file:

1. Use a browser (preferably Internet Explorer) to download the root server certificate from each external HTTPS Web site in BASE64 format that is visited, and is missing from the trusted certificate file.

2. Use Oracle Wallet Manager to import each certificate.

3. Export the trusted server certificates into a file and replace the ca-bundle.crt file with that file.

For more information about Oracle Wallet Manager, see the Oracle Database Advanced Security Administrator's Guide in the Oracle Database documentation on OTN, http://www.oracle.com/technology/.

7.1.12.2 Configuring Oracle Advanced Security for the Web Clipping Provider

The Web Clipping provider can use Oracle Advanced Security Option (ASO) to secure and encrypt the channel between itself (on the middle tier) and the database that hosts the Web Clipping Repository. As ASO is a feature available only on Oracle Fusion Middleware Enterprise Edition, or as an add-on option to the Standard Edition, this feature is disabled by default. To enable it, perform the following steps:

1. Go to the Web Clipping provider test page at:

http://<host>:<port>/portalTools/webClipping/providers/webClipping

2. Under the Provider Configuration section, in the Setting column, there is a Web Clipping Repository field. Click its corresponding Edit link in the Actions column.

3. In the Repository Settings section of the Edit Provider: webClipping page, select the enable (secure database connections) option in the Advanced Security Option field.

4. Select OK to save the settings and return to Web Clipping provider test page.

In addition, you must set the following ASO configuration parameters in the sqlnet.ora file to ensure that the database connections created between the Web Clipping provider and the database hosting the Web Clipping Repository are using ASO. See the Oracle Database Advanced Security Administrator's Guide for the list of values to use as all possible combinations of parameters are described in detail.

- SQLNET.AUTHENTICATION_SERVICES -- This parameter is used to select a supported authentication method in making database connections with ASO. See the Oracle Database Advanced Security Administrator's Guide for more information about setting this parameter.

- SQLNET.CRYPTO_SEED -- This parameter denotes the cryptographic seed value (FIPS 140-1 setting), used in making database connections with ASO.
See the Oracle Database Advanced Security Administrator's Guide for more information about setting this parameter.

Note:

When setting these parameters after the initial configuration (where the database parameters are already set up), the database connections are assumed to be open already. Because enabling ASO affects all connections made to the database, it is advisable to restart the WLS instance containing the Web Clipping provider to reset all the current connections to now use ASO. You would also need to do this when disabling ASO.

7.1.13 Securing the Federated Portal Adapter

The Federated Portal Adapter is a component of Oracle Portal that allows portal instances to share their portlets through the Web portlet interface. For example, suppose that a user displays a page in one portal instance that contains a portlet whose source resides on another portal instance. When the Federated Portal Adapter on the remote portal receives the request for the portlet, it starts a session for the user on the remote portal. The portlet can then be run from the remote portal instance by the user. This scenario has a couple of security implications:

- Because the Federated Portal Adapter must create a session for the user on the remote portal, it would be best for the two portal instances to share the same single sign-on server. Otherwise, name collisions could occur when the Federated Portal Adapter attempts to log the user onto the remote portal instance.

- Because the Federated Portal Adapter creates private portal sessions based on SOAP messages it receives, it is a potential security risk. A message authentication code must be used to ensure that any messages received by the Federated Portal Adapter emanate from a trusted source.

See Also:

Chapter 13, "Using the Federated Portal Adapter"

You will find additional information in the article "How to Add Remote Portlets Using the Federated Portal Adapter," on OTN, http://www.oracle.com/technology/.

7.1.14 Securing OraDAV

WebDAV (World Wide Web Distributed Authoring and Versioning) is the IETF's standard for collaborative authoring on the Web. It defines a set of extensions to HTTP that facilitates collaborative editing and file management between users located remotely from each other on the Internet.

OraDAV, Oracle's implementation of WebDAV, is the mechanism used by the Oracle HTTP Server to communicate with WebDAV clients. OraDAV enables your users to connect to Oracle Portal using their WebDAV clients. In terms of security, accessing Oracle Portal through WebDAV presents two security issues for you to consider:

- Expiration of Oracle Portal session cookies for OraDAV

- SSL and OraDAV

7.1.14.1 Session Cookie Expiration

The OraDAV configuration parameter, ORACookieMaxAge, specifies, in seconds, the length of time for which the DAV client should retain the cookie. The default value is 28800 (that is, 8 hours). Many WebDAV clients (For example Oracle Drive, WebFolders and Cadaver) do not prompt the user for a user name and password after that time as they retain the values entered when the user first connected and use them to create a new cookie.

ORACookieMaxAge can be changed in Oracle Enterprise Manager or by directly editing it in the mod_oradav.conf file located in ORACLE_INSTANCE\config\OHS\ohs1\moduleconf. If you choose to manually change the file, you must synchronize the changes with Dynamic Configuration Management. Once the change has been made in the configuration file, you need to restart the Oracle HTTP Server to have the changes take effect in the runtime system:

Execute the following command from ORACLE_INSTANCE\bin\opmnctl to restart the Oracle HTTP Server:

opmnctl restartproc type=ohs

Note:

Not all WebDAV clients use cookies. Some perform their authentication on each request using HTTP basic authentication. A client may choose to record the user name and password for the duration of that WebDAV client session and thus only need to prompt the user once for their credentials. In either case, though, this behavior results in a slower response time from Oracle Portal because every request from such clients must be authenticated, requiring added communication with the Oracle Internet Directory.

See Also:

Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server

7.1.14.2 SSL and OraDAV

The use of SSL for WebDAV communication is supported with OraDAV.

7.1.14.3 Encrypting a Password in MOD_ORADAV.CONF

This section describes how to encrypt a password in the mod_oradav.conf file.

Perform the following tasks:

- Edit the DAV Password

- Obfuscate the Password

Edit the DAV Password

To edit the password in the mod_oradav.conf file, do the following:

1. Open your mod_oradav.conf file, located at ORACLE_INSTANCE/config/OHS/ohs1/moduleconf (UNIX).

2. Locate the DAV entry for which you wish to change the password. In a default portal instance, you can find the DAV configuration entry in the following directive:

<Location /dav_portal/portal>

3. In the DAV entry, remove the directive ORACRYPTPASSWORD (For example, DAVParam ORACRYPTPASSWORD BS50NfrosVZOjfgc9hUQ9wcbFFxLSYT/BA==), and replace with the clear text password using the following syntax:

DAVParam ORAPASSWORD <your_password_here>

For example:

If you want to have a password of passwd123, add a line as follows: DAVParam ORAPASSWORD passwd123.

4. Save the file.

Obfuscate the Password

After editing the DAV password, it is recommended that the DAV password be obfuscated by running the oradavTool.pl script located at ORACLE_HOME/bin in UNIX and ORACLE_HOME\bin in Windows. To do so, perform the following steps:

1. If necessary, change the user to the Oracle software owner user, typically oracle, using the following command:

su - oracle

2. Set the ORACLE_HOME environment variable to specify the path to the Oracle home directory for the current release, and set the PATH environment variable to include the directory containing the Perl executable and the location of the oradavTool.pl script (located at ORACLE_HOME/ohs/bin in UNIX and ORACLE_HOME\ohs\bin in Windows).
Bourne, Bash, or Korn shell:

$ ORACLE_HOME=new_ORACLE_HOME_path;export ORACLE_HOME
PATH=$ORACLE_HOME/bin:$ORACLE_HOME/perl/bin:$PATH;export PATH

C or tcsh shell:

% setenv ORACLE_HOME new_ORACLE_HOME_PATH
% setenv PATH ORACLE_HOME/bin:$ORACLE_HOME/perl/bin:PATH

On Microsoft Windows, set the PATH and PERL5LIB environment variable:

set PATH=ORACLE_HOME\bin;%ORACLE_HOME%\perl\bin;%PATH%
set PERL5LIB=ORACLE_HOME\perl\lib

3. On UNIX platforms, set the shared library path environment variable
Include the ORACLE_HOME/lib or lib32 directory in your shared library path. Table 7-19 shows the appropriate directory and environment variable for each platform.

Table 7-19 Shared Library Path Environment Variable

Platform

Environment Variable

Include Directory

AIX Based Systems

LIBPATH

ORACLE_HOME/lib

HP-UX PA-RISC

SHLIB_PATH

ORACLE_HOME/lib

Solaris Operating System

LD_LIBRARY_PATH

ORACLE_HOME/lib32

Other UNIX platforms, including Linux and HP Tru64 UNIX

LD_LIBRARY_PATH

ORACLE_HOME/lib

For example, on HP-UX PA-RISC systems, set the SHLIB_PATH environment to include the ORACLE_HOME/lib directory:

$SHLIB_PATH=$ORACLE_HOME/lib:$SHLIB_PATH;export SHLIB_PATH

4. Change directory to the ORACLE_HOME/bin (UNIX) directory, as this is the location of the oradavTool.pl script.

5. Invoke the following Perl script to encrypt the mod_oradav.conf password:

perl oradavTool.pl -f mod_oradav.conffilename

Where mod_oradav.conffilename is the filename for mod_oradav.conf, which includes the full path to the mod_oradav.conf file.

For example, in UNIX:

perl oradavTool.pl -f /u01/app/oracle/as11gr1/ORACLE_INSTANCE/config/OHS/<ohs_name>/moduleconf/mod_oradav.conf

6. The directive ORAPASSWORD is updated with the new directive ORACRYPTPASSWORD, and your password is obfuscated.

7. Restart your Oracle HTTP Server.

7.2 Configuring Oracle Fusion Middleware Security Framework for Oracle Portal

This section describes considerations for:

- Configuring Fusion Middleware Security Framework Options for Oracle Portal

- Configuring Oracle Identity Management Options for Oracle Portal

7.2.1 Configuring Fusion Middleware Security Framework Options for Oracle Portal

For Oracle Portal, the main consideration when configuring the Oracle Fusion Middleware Security Framework is how to properly configure SSL. Refer to Section 7.3.2.1, "Configuring SSL for Oracle Portal" for a full description of SSL configuration for Oracle Portal.

7.2.2 Configuring Oracle Identity Management Options for Oracle Portal

As you configure Oracle Portal for security, you should consider the following topic related to Oracle Identity Management:

- Setting the Appropriate Naming and Nickname Attributes

7.2.2.1 Setting the Appropriate Naming and Nickname Attributes

When deciding on the Directory Information Tree structure and the setting of the Oracle Context parameters for your Oracle Identity Management Infrastructure, you should consider making the naming attribute different from the nickname attribute. The naming attribute is used for the first attribute in the entry's Distinguished Name. By contrast, the nickname attribute holds the OracleAS Single Sign-On user name.

For Oracle Portal to properly support renaming users by changing the value of the nickname attribute in the Oracle Internet Directory, the nickname attribute must be different than the naming attribute. By keeping the two separate, the Distinguished Name of the user's entry in the Oracle Internet Directory remains unchanged even when the value of the nickname attribute changes.

See Also:

Oracle Fusion Middleware Getting Started with Oracle Identity Management

7.2.2.2 Defining a Role for Oracle Portal Installers

To run the Oracle Portal Configuration Assistant (OPCA), the user needs certain permissions for the various operations performed by this tool. When the user runs ptlasst, if they provide the credentials -ldap_d 'cn=orcladmin' -w orcladmin_pwd, then they assume the identity of the Oracle Internet Directory super user, which enables all operations to succeed. However, if a user needs to run ptlasst as someone other than cn=orcladmin, then explicit privileges must be provided to this user for the operations to succeed.

In enterprise deployments of the Oracle Fusion Middleware, a central data center may have charge of maintaining and managing the central Oracle Identity Management Infrastructure, including Oracle Internet Directory and Oracle Application Server Single Sign-On. If a department or division within the enterprise were to install Oracle Portal and needed to associate it with the central infrastructure, the Oracle Identity Management Infrastructure administrators would probably not want to just hand out the cn=orcladmin password to the departmental administrator to install her Oracle Portal. In such cases, the Oracle Identity Management administrator would grant certain privileges to the Oracle Portal administrator in order to allow her to run the Oracle Portal configuration. After performing the configuration, those privileges could then be revoked.

To define the role for Oracle Portal Installers and assign it to someone, perform the following steps:

1. An LDIF substitution file (.sbs) is provided to create the group and add it to the appropriate privilege groups in order for it to inherit the necessary privileges to successfully perform Oracle Portal configuration.
The file is:

ORACLE_HOME/portal/admin/plsql/wwc/secadmin.sbs

This file needs to be run through the ldifmigrator to replace the keywords and transform it into a proper LDIF file:

ldifmigrator 'input_file=secadmin.sbs' 'output_file=secadmin.ldif' -lookup 'host=oidhost' 'port=oidport' 'DN=cn=orcladmin' 'password=orcladmin_pwd'

2. This command creates a file call secadmin.ldif file, which can be loaded onto the Oracle Internet Directory server to install the necessary role for Oracle Portal Installers:

ldapmodify -h <oidhost> -p <oidport> -D cn=orcladmin -w orcladmin_pwd -v -c -f secadmin.ldif

Once the secadmin.ldif file is loaded in the Oracle Internet Directory, the newly created role will be available on the Create/Edit user page of Oracle Delegated Administration Services. In order to grant a user this role, you must be logged in as orcladmin, which is the only user that is able to grant this role to others.

3. Log on to Oracle Delegated Administration Services and locate the entry for the user to whom you want to grant the ability to install Oracle Portal. Edit the user entry and check the role for Oracle Portal Installer. The user should now have the ability to successfully do the Oracle Portal Configuration.

Note:

In addition to defining this role for Oracle Portal Installers, you should also make sure that, if the directory contains a lot of groups, the Query Entry Return Limit on the directory server is high enough to return all of the groups when queried during Oracle Portal configuration. This limit is stored in the orclsizelimit attribute in the root entry of the directory. The Oracle Portal configuration queries the list of groups in order to populate its local cache. When invoking the configuration using the cn=orcladmin account, query limits are not imposed. However, when doing the configuration as any user other than cn=orcladmin, the server query limits will be imposed. Hence, you must make sure that the limits are set high enough, even if it is just for the duration of the execution of Oracle Portal configuration.

A sample LDIF file that you can use with the ldapmodify command line utility follows:

dn:
changetype: modify
replace: orclsizelimit
orclsizelimit: 2000

Alternatively, you can set the Query Entry Return Limit from the Oracle Directory Manager. The attribute is listed against the server entry.

4. Once the Oracle Portal configuration is complete, you can edit the user's entry again and remove the privilege, which is no longer needed after performing the initial configuration.

7.3 Configuring Oracle Portal Security

This section describes configuration considerations for Oracle Portal.

- Configuring Oracle Portal Security Options

- Configuring Options for Oracle Fusion Middleware Security Framework

- Configuring Oracle Portal Options for Database Security

7.3.1 Configuring Oracle Portal Security Options

This section contains the following subsections:

- Changing Settings on the Global Settings Page

- Enforcing Role-Based Access Control

- Configuring Provider Message Authentication

7.3.1.1 Changing Settings on the Global Settings Page

Once you have installed Oracle Portal and performed the appropriate tasks from Section 7.3.2.3, "Post-Installation Security Checklist", you can change all of the following settings that pertain to security from the Global Settings page of Oracle Portal:

- Cache for Oracle Internet Directory Parameters

- Oracle Directory Integration Platform Synchronization

- Group Search Base Distinguished Name (DN)

- Group Creation Base Distinguished Name (DN)

7.3.1.1.1 Cache for Oracle Internet Directory Parameters

As pointed out in Section 7.1.7, "Leveraging Oracle Identity Management Infrastructure", Oracle Portal maintains a cache of information from the directory. From the Global Settings page, you can refresh this cache with the updated information from the directory. Refresh Cache for OID Parameters immediately updates the cache with the latest parameters values from the directory. The cached information is relatively static information, hence you do not need to refresh the cache frequently.

7.3.1.1.2 Oracle Directory Integration Platform Synchronization

Because Oracle Portal caches group membership information, it requires a mechanism for updating the cache when the information is changed in the directory. The directory integration server notifies Oracle Portal whenever a change is made in the directory that must be reflected in Oracle Portal. In Global Settings, you can set:

- Enable directory synchronization defines whether the directory integration server notifies Oracle Portal when a relevant change is made in the directory. If this setting is not checked, then Oracle Portal will not be notified of any directory integration server subscribed events. For a proper and supported configuration of Oracle Portal this option must be enabled.

- Send event notifications every n seconds defines the interval of time between event notifications sent by the directory integration server to notify Oracle Portal of relevant changes. This setting is available only when Enable directory synchronization is checked.

The following settings let you adjust for login performance and how soon the effects of provisioning changes in groups affect user authorizations:

Enable lazy synchronization of role memberships

A user's group memberships are updated in the portal only at the next login after group memberships are changed in Oracle Internet Directory, and only at the next login. Changes in authorization take effect at the next login. If no updates to the user's groups have occurred between login events, the user's groups are no longer required on subsequent logins, until a change occurs to one of the user's groups.

Enable immediate synchronization of role memberships

A user's group memberships are updated at each login, and are updated when the Portal receives a group update notification from Oracle Internet Directory. This mode is recommended only when authorization updates need to be enforced soon after the updates in Oracle Internet Directory occur, possibly changing a user's authorizations within a current session.

Enable synchronization of role memberships on every login

A user's group memberships are updated in the portal at each login and take effect at the next login after groups are updated in Oracle Internet Directory.

A user's group memberships are updated in the portal at each login, with the updated set of group memberships being in effect for the duration of that session. Oracle Internet Directory is queried for the current set of group memberships at each login, whether needed or not. If, for any reason, the user's group memberships are not correctly reflected in the Portal, it will be re-established with the correct set at each login.

Figure 7-18 compares the tradeoffs between login performance, and how quickly user authorizations are updated for each setting:

Table 7-20 Synchronization Setting Comparison

Setting

Description

Lazy synchronization

Best performance - login slows only after a group membership change affecting this user has been done.

Immediate Synchronization

This has the most performance impact as group synchronization updates may occur within a user's session, and will also occur at each login, and to get the most "immediate" effect, the DIP synchronization interval and the webcache soft invalidation interval needs to be set fairly low, thereby increasing the frequency of these events.

Synchronize at each login

Baseline performance - consistent with previous releases.

When the Oracle Directory Integration and Provisioning server is running and configured to work with Oracle Portal, group membership changes in Oracle Internet Directory will result in soft cache invalidations in Oracle Portal.

See Also:

- Section 1.3.3, "Understanding Cache Invalidation in Oracle Portal"

- Section 6.7, "Managing Oracle Portal Content Cached in Oracle Web Cache"

- Section 7.1.7.4, "Relationship Between Oracle Portal and Oracle Directory Integration Platform"

Some examples of group membership cache invalidations are:

- If you add a user to a group, the Oracle Directory Integration and Provisioning server notifies Oracle Portal of the change. Oracle Portal will then issue a single soft invalidation message that will be processed by the soft invalidation job. This is because of the possibility that the user may have new privileges that can affect what data can be viewed.

- If you add group _A to group _B, the Oracle Directory Integration and Provisioning server notifies Oracle Portal of the change. Oracle Portal will then issue a soft invalidation message for each user in group _A. This is because of the possibility that the users in group _A may have new privileges that affect what data they can view.

7.3.1.1.3 Group Creation Base Distinguished Name (DN)

Oracle Portal maintains its user group information in the directory. When groups are created through the Group portlet, they are created under a node of the LDAP Directory Information Tree (DIT). A node is identified by its distinguished name (DN). Therefore, in Oracle Portal, you need to specify in which node you wish to create groups:

Group Creation Base DN is the DN of the node in which you want Oracle Portal to maintain its user groups. For example:

cn=portal.040820.123756.096286000,cn=Groups,dc=MyCompany,dc=com

This setting is particularly useful if you adapt Oracle Portal to interact with an existing DIT.

7.3.1.1.4 Group Search Base Distinguished Name (DN)

Just as you need to define the node in which you want to create groups, you must also define the node in which you want Oracle Portal to search for existing groups. For example, you need to specify where Oracle Portal searches when it displays the group's list of values in the Group portlet.

Local Group Search Base DN is the DN of the node in which you want Oracle Portal to maintain its user groups. For example:

cn=portal.040820.123756.096286000,cn=Groups,dc=MyCompany,dc=com

This setting is particularly useful if you adapt Oracle Portal to interact with an existing DIT.

7.3.1.2 Enforcing Role-Based Access Control

From Oracle Portal 10g Release 2 (10.1.2) onwards, it is possible to enable or disable enforcement of Role-Based Access Control. This option is disabled in the default configuration. Role-Based Access Control can prevent the assignment of both object level privileges and global privileges directly to users from the Oracle Portal User Interface and forces them to be granted only to groups. However, this option does not have any impact on the privileges granted directly to users:

- Before Role-based Access Control was enabled

- Automatically when an object is created

- Through the use of the Oracle Portal APIs

To enable or disable Role-based Access Control, you must run the script secrlacl.sql located in the directory ORACLE_HOME/portal/admin/plsql/wwc. The syntax for secrlacl.sql is:

@secrlacl.sql Y|N

For example, if you want to enable Role-based Access Control, run the script as follows:

@secrlacl.sql Y

Once Role-based Access Control is enabled, you will see the following changes in Oracle Portal:

- Access Tab for Objects. Here you will see only the Group LOV; the User LOV does not appear.

- The Privilege tab is not rendered on the Edit User Profile page.

7.3.1.3 Configuring Provider Message Authentication

Additional configuration is required to set up a provider service that expects HMAC-enabled communication. You can set up basic or enhanced authentication.

7.3.1.3.1 Basic Authentication

If your JPDK provider code is accepting the portal user's identity through the oracle.portal.provider.v2.ProviderUser from the oracle.portal.provider.v2.render.PortletRenderRequest object, and using this identity for any sensitive operations, you should configure the portal and this provider for basic message authentication. Basic message authentication utilizes a Hashed Message Authentication Code (HMAC), which is a mechanism for message authentication using cryptographic hash functions, to ensure the integrity of the message.

To configure basic authentication using HMAC, you need to configure both the JPDK Web provider and Oracle Portal as follows:

JPDK Web Provider

For the JPDK Web provider, add a shared key as a Web provider JNDI environment variable to the web.xml file. The exact position of environment entries in web.xml is toward the end, as shown in bold in Table 7-21, which shows the relative order of the elements in web.xml.

Table 7-21 Relative Order of the Elements In web.xml

Element Name

icon?

display-name?

description?

distributable?

context-param*

filter*

filter-mapping*

listener*

servlet*

servlet-mapping*

session-config?

mime-mapping*

welcome-file-list?

error-page*

taglib*

resource-env-ref*

resource-ref*

security-constraint*

login-config?

security-role*

env-entry*

ejb-ref*

ejb-local-ref*

Add a JNDI environment variable definition to the web.xml file, by adding the following env-entry element in the appropriate location:

<env-entry>
<env-entry-name>oracle/portal/provider/service_name/sharedKey</env-entry-name>
<env-entry-value>shared_key_value</env-entry-value>
<env-entry-type>java.lang.String</env-entry-type>
</env-entry>

Enter the service name and the shared key value, as shown in Example 7-2.

Example 7-2 Adding a JNDI Environment Variable Definition to web.xml

<env-entry>
<env-entry-name>oracle/portal/provider/sample/sharedKey</env-entry-name>
<env-entry-value>1234567890abcdeFGHIJ</env-entry-value>
<env-entry-type>java.lang.String</env-entry-type>
</env-entry>

In this example, sample is the service name for the provider and 1234567890abcdeFGHIJ is the shared key value. The value of the shared secret key used for the HMAC computation must contain between 10 and 20 alphanumeric characters.

You must define this environment variable for each provider instance that you want to secure, as shown in Example 7-3.

Example 7-3 Defining JNDI Environment Variables for Multiple Provider Instances in web.xml

<env-entry>
<env-entry-name>oracle/portal/provider/provider0/sharedKey</env-entry-name>
<env-entry-value>1234567890abcdeFGHIJ</env-entry-value>
<env-entry-type>java.lang.String</env-entry-type>
</env-entry>

<env-entry>
<env-entry-name>oracle/portal/provider/provider1/sharedKey</env-entry-name>
<env-entry-value>0987654321abcdeFGHIJ</env-entry-value>
<env-entry-type>java.lang.String</env-entry-type>
</env-entry>

<env-entry>
<env-entry-name>oracle/portal/provider/provider2/sharedKey</env-entry-name>
<env-entry-value>123123123123</env-entry-value>
<env-entry-type>java.lang.String</env-entry-type>
</env-entry>

Alternatively, you can add the provider property sharedKey in the .properties file. To do this, perform the following steps:

1. Open the file <app_root>/WEB-INF/deployment/service_name.properties. (Substitute service_name with the name of your provider service instance.)

2. Add the provider property sharedKey and the value for your shared key, as shown in the following example:

sharedKey=1234567890abcdeFGHIJ

You must set this property in each of the service_name.properties files for each provider instance that you want to secure.

Note:

The disadvantage of this alternate approach is that you cannot manage the environment variables for the provider using Oracle Fusion Middleware Control, as you would with JNDI environment entries.

Oracle Portal

In Oracle Portal, register the provider with the shared key and login frequency settings, as follows:

1. In the Portal Builder, click the Administer tab, then click the Portlets subtab.

2. In the Remote Providers portlet, click Register a Provider.

3. In the Register a Provider page, enter the provider details, and click Next.

4. In the General Properties section, for Shared Key, enter the value of the secret key.

5. In the User/Session Information section, for Login Frequency, select Once Per User Session.

6. Follow the instructions in the wizard and click Finish.

7.3.1.3.2 Enhanced Authentication

If your JPDK Web provider code is running in an WLS container configured for JAZN-LDAP, and the provider code uses J2EE security or obtains the user's identity through the getRemoteUser() or getUserPrincipal() methods of the HttpServletRequest object, you should configure the portal and this provider for enhanced message authentication. You should also configure enhanced message authentication if you are using the LDAP (Oracle Internet Directory) Security features in your provider, as documented in the Oracle Fusion Middleware Developer's Guide for Oracle Portal. Enhanced message authentication secures the integrity of the additional headers that are used to propagate the user's authenticated identity to the provider.

To configure enhanced authentication using HMAC, you need to configure both the JPDK Web provider and Oracle Portal.

JPDK Web Provider

To configure the JPDK Web provider, perform the following steps:

1. For the JPDK Web provider, add a shared key as a Web provider JNDI environment variable to the web.xml file. The exact position of environment entries in web.xml is toward the end, as shown in Table 7-21, which shows the relative order of the elements in web.xml.
Add a JNDI environment variable definition to the web.xml file, by adding the following env-entry element in the appropriate location:

<env-entry>
<env-entry-name>oracle/portal/provider/service_name/sharedKey</env-entry-name>
<env-entry-value>shared_key_value</env-entry-value>
<env-entry-type>java.lang.String</env-entry-type>
</env-entry>

Enter the service name and the shared key value, as shown in Example 7-2.

In Example 7-2, sample is the service name for the provider and 1234567890abcdeFGHIJ is the shared key value. The value of the shared secret key used for the HMAC computation must contain between 10 and 20 alphanumeric characters.

You must define this environment variable for each provider instance that you want to secure, as shown in Example 7-3.

Alternatively, you can add the provider property sharedKey in the .properties file. To do this, perform the following steps:

1. Open the file <app_root>/WEB-INF/deployment/service_name.properties. (Substitute service_name with the name of your provider service instance.)

2. Add the provider property sharedKey and the value for your shared key, as shown in the following example:

sharedKey=1234567890abcdeFGHIJ

You must set this property in each of the service_name.properties files for each provider instance that you want to secure.

Note:

The disadvantage of this alternate approach is that you cannot manage the environment variables for the provider using Oracle Fusion Middleware Control, as you would with JNDI environment entries.

2. Add the provider property enhancedAuthentication in the .properties file. To do this, perform the following steps:

1. Open the file <app_root>/WEB-INF/deployment/service_name.properties. (Substitute service_name with the name of your provider service instance.)

2. Add the provider property enhancedAuthentication and set it to true, as shown in the following example:

enhancedAuthentication=true

You must set this property in each of the service_name.properties files for each provider instance that you want to secure.

Oracle Portal

In Oracle Portal, register the provider with the shared key and login frequency settings, as follows:

1. In the Portal Builder, click the Administer tab, then click the Portlets subtab.

2. In the Remote Providers portlet, click Register a Provider.

3. In the Register a Provider page, enter the provider details, and click Next.

4. In the General Properties section, for Shared Key, enter the value of the secret key.

5. In the User/Session Information section, for Login Frequency, select Once Per User Session.

6. Follow the instructions in the wizard and click Finish.

7.3.2 Configuring Options for Oracle Fusion Middleware Security Framework

When configuring Oracle Portal, you should consider the following options that leverage the Oracle Fusion Middleware Security Framework:

- Configuring SSL for Oracle Portal

- Securing the Connection to Oracle Internet Directory (Optional)

- Post-Installation Security Checklist

7.3.2.1 Configuring SSL for Oracle Portal

The sections that follow provide an overview of the most common SSL configurations for Oracle Portal and describe the procedures necessary to implement them.

- Section 7.3.2.1.1, "Overview of SSL Configurations"

- Section 7.3.2.1.2, "SSL to OracleAS Single Sign-On"

- Section 7.3.2.1.3, "SSL to Oracle Access Manager"

- Section 7.3.2.1.4, "SSL to Oracle Web Cache"

- Section 7.3.2.1.5, "End to End SSL for Oracle Portal"

- Section 7.3.2.1.6, "External SSL with Non-SSL Within Oracle Fusion Middleware"

- Section 7.3.2.1.7, "Configuring SSL to Oracle WebLogic Managed Server"

- Section 7.3.2.1.8, "Configuring and Registering Web Providers, Provider Groups, and WSRP Producers Exposed Over SSL"

7.3.2.1.1 Overview of SSL Configurations

Oracle Portal uses a number of different components (such as the Parallel Page Engine, Oracle HTTP Server, and Oracle Web Cache) each of which may act as a client or server in the HTTP communication. As a result, each component in the Oracle Fusion Middleware middle tier may be configured individually for the protocols of HTTPS rather than HTTP.

Interacting with Oracle Portal involves a number of distinct network hops. These hops are as follows:

- Between the client browser and the entry point of the portal environment. That is either:

- Oracle Web Cache

- Network edge hardware device such as a Reverse Proxy or SSL accelerator

- Between Oracle Web Cache and Oracle HTTP Server of the Oracle Fusion Middleware middle tier

- Between the client browser and the Oracle HTTP Server of the OracleAS Single Sign-On or Oracle Internet Directory (or infrastructure) tier

- A loopback between the Parallel Page Engine (PPE) on the middle tier and Oracle Web Cache or front-end Reverse proxy

- Between the Parallel Page Engine (PPE) and the Remote Web Provider producing Portlet content

- Between Oracle Portal infrastructure and the Oracle Internet Directory

SSL Usage Restriction

- External JavaServer Pages do not work with the Parallel Page Engine in a partial SSL configuration mode. They work when SSL is used throughout Oracle Portal. If SSL is implemented externally with a load balancing router, only internal JavaServer Pages work.
As a result, with the SSL configurations described in Section 7.3.2.1.2, "SSL to OracleAS Single Sign-On", Section 7.3.2.1.5, "End to End SSL for Oracle Portal", and Section 7.3.2.1.6, "External SSL with Non-SSL Within Oracle Fusion Middleware", you should only use external JSPs.

- With the default settings in the ssl.conf file, an Oracle Portal server running on HP-IA cannot be accessed through Microsoft Internet Explorer. To work around this issue, remove the line downgrade-1.0 force-response-1.0 from the ssl.conf file as follows:
Current

BrowserMatch ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

After correction

BrowserMatch ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown

Checks to Perform Before Configuring SSL

Before using the methods recommended to configure SSL, you must confirm that Oracle Portal is working correctly in the default non-SSL configuration. To test this, you must ensure that the following portal tasks work without errors:

- The Oracle Portal home page is accessible

- Users can log in to Oracle Portal

- Edits to content are shown immediately

7.3.2.1.2 SSL to OracleAS Single Sign-On

If any connection should be secured with SSL, it is the connection between the browser and OracleAS Single Sign-On. The password should be protected by SSL in transit between the browser and OracleAS Single Sign-On. For at least a minimal level of security, you should configure your installation with this option. All of the subsequent SSL configurations assume that you have configured SSL for OracleAS Single Sign-On.

Figure 7-19 shows a configuration where OracleAS Single Sign-On is configured to use SSL.

Figure 7-19 Secured Connection to OracleAS Single Sign-On

After you have successfully performed the checks described in "Checks to Perform Before Configuring SSL", you can use either of the following two methods to configure SSL to OracleAS Single Sign-On:

- Configuring SSL to OracleAS Single Sign-On Using SSLConfigTool

- Configuring SSL to OracleAS Single Sign-On Manually

Configuring SSL to OracleAS Single Sign-On Using SSLConfigTool

Note:

As the OracleAS Single Sign-On middle-tier partner application is still non-SSL, you must re-register it as non-SSL. Therefore, the re-registration of mod_osso needs to specify the non-SSL URL of the OracleAS Single Sign-On middle tier for the mod_osso_url parameter to ssoreg.

Refer to the information on registering mod_osso in the Oracle Application Server Single Sign-On Administrator's Guide.

To configure SSL to OracleAS Single Sign-On using SSLConfigTool, perform the following steps:

1. Run the SSLConfigTool script on the Oracle Fusion Middleware Infrastructure.

1. Enable SSL on the OracleAS Infrastructure that has Identity Management installed. Run SSLConfigTool in the infrastructure Oracle home, as shown in the following example for Windows:

SSLConfigTool.bat -config_w_default -opwd <fmwadmin_pwd>

Where:

- config_w_default is used to run the tool in silent mode using the values specified in the portlist.ini file.

- opwd is the Oracle administrator password. If no password is specified, you will be prompted to enter the password.

See Also:

Oracle Fusion Middleware Administrator's Guide

The information on enabling SSL in the Oracle Application Server Single Sign-On Administrator's Guide. If you are going to configure OracleAS Single Sign-On behind a reverse proxy server, you should refer to the information on deploying OracleAS Single Sign-On with a proxy server, in the Oracle Application Server Single Sign-On Administrator's Guide.

2. After enabling SSL on the OracleAS Infrastructure that has Identity Management installed, you must protect OracleAS Single Sign-On URLs. To do this, refer to the section "Protect Single Sign-On URLs" in the Oracle Application Server Single Sign-On Administrator's Guide.

2. Create a wallet. See "Create an Empty Wallet (HTTPS)" for more information.

3. Check if the issuer of the OracleAS Single Sign-On certificate is listed in the Trusted Certificates list. If not, add the Trusted Root Certificate to the Wallet, as shown in "Add the Trusted Root Certificate to the Wallet (HTTPS)".

4. Update the wallet path and password as described in "Update Wallet Path and Password in Portal Repository Preference Store".

5. Re-register the Oracle HTTP Server as described in "Re-register the Oracle HTTP Server Partner Application"

6. The orcldasurlbase attribute in the cn=OperationURLs, cn=DAS, cn=Products, cn=OracleContext entry may need to be updated in Oracle Internet Directory. If it is not set to use the HTTPS port, you must refresh the cache for the Oracle Internet Directory parameters: To do this, perform the following steps:

1. Using Oracle Directory Manager (Integrated Management Tools : Oracle Directory Manager on Windows, or INFRA_ORACLE_HOME/bin/oidadmin on UNIX), run the Oracle Directory Manager and log in as cn=fmwadmin.

2. Navigate to Entry Management, cn=OracleContext > cn=Products > cn=DAS > cn=OperationURLs.

3. Check if the orcldasurlbase entry reflects the HTTPS port being used on the infrastructure tier, that is, https://<infrahost>:<port>/.

If the orcldasurlbase entry does not reflect the HTTPS port, change it in Oracle Internet Directory and force a refresh of the portal cache, which holds the relevant Oracle Internet Directory information. To refresh the portal cache, perform the following steps:

1. Logon to Oracle Portal as a user with administrator privileges.

2. Click the Administration tab, in the Portal Builder page.

3. From the Portal tab, open Global Settings and navigate to the SSO/OID tab.

4. Scroll to the bottom of the page.

5. Select Refresh Cache for OID Parameters under Cache for OID Parameters.

6. Click Apply.

7. The page should refresh with the appropriate value in the DAS Host Name field.

At this point, configuration is complete for SSL communication to OracleAS Single Sign-On.

Note:

You must clear the Portal modplsql cache so that the page displays the correct SSO URLs.

The following example shows how to clear the Portal modsql cache on UNIX.

cd $INSTANCE_HOME/portal/cache
rm –rf ./session/*
rm -rf ./plsql/*
rm -rf ./pmd/*

Enable the WebLogic Plug-In, WebLogic ProxySSL, and WLProxySSLPassThrough parameter

1. Enable WebLogic Plug-In by performing the following steps:

1. Log in to the WebLogic Administration Console.

2. If you have not already done so, in the Change Center pane, click Lock & Edit.

3. In the Domain Structure pane, expand the Environment node, and select Clusters.
list of clusters configured in the domain is displayed.

4. Click cluster_portal.

5. Expand the Advanced link near the bottom of the page.

6. Select the WebLogic Plug-In Enabled option.

7. Click Save.

2. Set the WLProxySSLPassThrough and WebLogic ProxySSL parameters to ON in the WLS routing configuration section in ORACLE_INSTANCE/config/OHS/OHS Name/moduleconf/portal.conf as shown in the following example:

# WLS routing configuration
<Location /portal>
SetHandler weblogic-handler
WebLogicCluster <HostName>:<Weblogic portal ClusterPort>
WLProxySSL On
WLProxySSLPassThrough ON
</Location>

3. Restart WLS_PORTAL by using Oracle WebLogic Administration console.
Restart Oracle HTTP using the following commands:

ORACLE_INSTANCE/bin/opmnctl stopall
ORACLE_INSTANCE/bin/opmnctl startall

Configuring SSL to OracleAS Single Sign-On Manually

To manually configure this option, refer to the information on enabling SSL in the Oracle Application Server Single Sign-On Administrator's Guide. If you are going to configure OracleAS Single Sign-On behind a reverse proxy server, you should refer to the information on deploying OracleAS Single Sign-On with a proxy server, in the Oracle Application Server Single Sign-On Administrator's Guide.

Note:

As the OracleAS Single Sign-On middle-tier partner application is still non-SSL, you must re-register it as non-SSL. Therefore, the re-registration of mod_osso needs to specify the non-SSL URL of the OracleAS Single Sign-On middle tier for the mod_osso_url parameter to ssoreg.

Refer to the information on registering mod_osso in the Oracle Application Server Single Sign-On Administrator's Guide.

In this release of Oracle Portal, you have the option of configuring Portal to access the OracleAS Single Sign-On URLs over HTTP or HTTPS. The steps that follow indicate which steps are needed for each configuration:

- Create an Empty Wallet (HTTPS)

- Add the Trusted Root Certificate to the Wallet (HTTPS)

- Update Wallet Path and Password in Portal Repository Preference Store

- Re-register the Oracle HTTP Server Partner Application (HTTP and HTTPS)

- Enable the WebLogic Plug-In (HTTPS)

- Verify the Wallet Path and the OracleAS Single Sign-On Query Path URL (HTTP and HTTPS)

- Conditionally Update the Oracle Delegated Administration Services URL Base Entry in Oracle Internet Directory (HTTP and HTTPS)

Create an Empty Wallet (HTTPS)

Perform the steps in this section only if you plan to use an HTTPS port on OracleAS Single Sign-On, after configuring OracleAS Single Sign-On to use SSL.

Create an empty wallet to establish the trust points for SSL access to the OracleAS Single Sign-On. To do this, perform the following steps:

1. Open the Oracle Wallet Manager (ORACLE_HOME\bin\owm). Note that you can run Oracle Wallet Manager from any location, as long as the generated wallet is accessible from the portal schema in the Oracle Metadata Repository. You can also save the wallet (the directory containing the wallet files) anywhere and move it to another location that is accessible from the portal schema in the Oracle Metadata Repository.

2. Choose Wallet > New.
On UNIX, the wallet is stored in the following location by default:

/etc/ORACLE/WALLETS/<Account Name creating the Wallet>

On Windows, the wallet is stored in the following location by default:

\Documents And Settings\<Account Name creating the Wallet>\ORACLE\WALLETS

3. Create a password for the wallet.

4. Enter the same password in the Confirm Password field.

5. Select Standard for Wallet Type.

6. Click OK.

7. Click No when asked to create a certificate request.

8. Check if the issuer of the OracleAS Single Sign-On certificate is listed in the Trusted Certificates list. If not, you must add the Trusted Root Certificate to the Wallet, as shown in "Add the Trusted Root Certificate to the Wallet (HTTPS)".

9. Save the wallet in a convenient directory, for example:

INFRA_ORACLE_HOME\wallets

10. Choose Wallet, and then Save.

11. Check Wallet, and then AutoLogin, if it is not already checked.

Add the Trusted Root Certificate to the Wallet (HTTPS)

Perform the steps in this section only if you do not have the trusted root certificate of the OracleAS Single Sign-On server's issuing certificate authority listed in the Trusted Certificates list. In this case, you must add the Trusted Root Certificate to the Wallet as shown in the following steps, which are based on the Internet Explorer browser:

1. Using the browser, go to the OracleAS Single Sign-On home page, https://infra.domain.com/pls/orasso. Ensure that this is on an HTTPS URL.

1. If the certificate on the server is not automatically trusted by your browser, the Security Alert dialog box is shown.

2. Click View Certificate.

3. Click the Certification Path tab.

4. Select the Certificate Authority Root, which is the first certificate in the list.

5. Click View Certificate.

6. Click Install Certificate.
This brings up the Certificate Import Wizard. This will import the certificate into the browser's list of trusted certificate authorities.

7. Click Next.

8. Select Automatically select a certificate store based on the type of certificate.

9. Click Next.

10. Click Finish.
The trusted root certificate is installed in your browser.

2. Click the lock icon in the status bar to bring up the Certificate dialog box.

3. Click the Certification Path tab.

4. Select the Certificate Authority Root, which is the first certificate in the list.

5. Click View Certificate.

6. Click the Details tab.

7. Click Copy to File....
This brings up the Certificate Export Wizard.

8. Click Next.

9. Under Select the format you want to use, select Base-64 encoded X.509 (.CER).

10. Click Next and specify a file name for the certificate. You can provide any filename for the certificate with a .cer extension.

11. Click Next and then Finish.

At this point, a .cer certificate file is created, which contains the trusted certificate authority's root certificate. This certificate must be added to the Wallet's list of Trusted Certificates. To accomplish this, assuming that the wallet manager is already running and the empty wallet has been opened, perform the following steps:

1. Right-click the Trusted Certificates node.

2. Select Import Trusted Certificate....

3. Select Paste the certificate, and click OK.

4. Copy the contents of the certificate file you created earlier into the text area for the BASE64 format certificate, and then click OK.

5. Verify that the Certificate Authority Root has been added to the list of trusted certificates.

6. Save the wallet.

Update Wallet Path and Password in Portal Repository Preference Store

Perform the steps in this section only if you plan to use an HTTPS port on OracleAS Single Sign-On, after configuring OracleAS Single Sign-On to use SSL.

Update the wallet path and password in the Portal repository preference store, using the following script from the Oracle Portal midtier home:

cd $ORACLE_HOME/portal/admin/plsql/wwc
sqlplus <portal_schema/<portal_pwd>@connectstring
sql> @secwc.sql <wallet_location> <wallet_pwd>

Example 7-4 Updated Wallet Path

@secwc.sql 'file:/u01/app/oracle/product/1021_prodee/dbwallet''welcome1'

Re-register the Oracle HTTP Server Partner Application (HTTP and HTTPS)

Run ssoreg to register the virtual host for which mod_osso facilitates single sign-on. The specific application URLs to be defined as partner applications within this site are defined in the file osso.conf. ssoreg located in ORACLE_HOME/sso/bin.

The following example shows the usage of ssoreg on UNIX:

ORACLE_HOME/sso/bin/ssoreg.sh
-site_name www.abc.com
-config_mod_osso TRUE
-mod_osso_url http://www.abc.com:8090
-remote_midtier
-config_file ORACLE_INSTANCE/conf/OHS/ohs1/osso.conf
-admin_info cn=orcladmin

On Windows, you must run the ssoreg.bat batch file instead. For more information, see the Oracle Application Server Single Sign-On Administrator's Guide.

Enable the WebLogic Plug-In (HTTPS)

See Enable the WebLogic Plug-In, WebLogic ProxySSL, and WLProxySSLPassThrough parameter

Verify the Wallet Path and the OracleAS Single Sign-On Query Path URL (HTTP and HTTPS)

Oracle Portal maintains the URL prefix of OracleAS Single Sign-On, which accesses certain information through calls from the database using the UTL_HTTP package. The calls made across this interface are required for the following reasons:

- Obtain the list of external applications to allow customization of the External Applications portlet.

- Perform the mapping of OracleAS Single Sign-On user names to external application user names.

To verify the wallet path and OracleAS Single Sign-On Query Path URL, perform the following steps:

1. Log in to Oracle Portal as the portal administrator.

2. Click the Administer tab.

3. Click the Portal tab.

4. Click Global Settings in the Services portlet.

5. Click the SSO/OID tab.

6. The SSO Server Settings section should have the appropriate values.

Conditionally Update the Oracle Delegated Administration Services URL Base Entry in Oracle Internet Directory (HTTP and HTTPS)

After OracleAS Single Sign-On is SSL-enabled, all OracleAS Single Sign-On partner applications need to be re-registered so that the updated SSL login URL is obtained by each partner application for subsequent authentication requests.

After enabling the infrastructure tier's Oracle HTTP Server for SSL, you were asked to re-register all partner applications, which includes mod_osso on the infrastructure tier. You have the option of accessing Oracle Delegated Administration Services over non-SSL or SSL. The base URL for Oracle Delegated Administration Services is stored in Oracle Internet Directory, and this determines the URL that other applications render when providing links to Oracle Delegated Administration Services functionality.

If you want Oracle Delegated Administration Services accessed over SSL, then the re-registration of mod_osso needs to specify an SSL URL for the mod_osso_url parameter to ssoreg. Refer to the information on registering mod_osso in the Oracle Application Server Single Sign-On Administrator's Guide.

If you decide that you want to access Oracle Delegated Administration Services over SSL, then the orcldasurlbase attribute in the cn=OperationURLs, cn=DAS, cn=Products, cn=OracleContext entry needs to be updated in Oracle Internet Directory to reflect this fact. This attribute value is then used by Oracle Portal for generating subsequent Oracle Delegated Administration Services URLs. This procedure assumes that the Oracle HTTP Server on the infrastructure tier is also listening on an HTTPS port.

1. For this step, you need Oracle Directory Manager (Integrated Management Tools : Oracle Directory Manager on Windows, or INFRA_ORACLE_HOME/bin/oidadmin on UNIX). Run the Oracle Directory Manager and log in as cn=orcladmin.

2. Navigate to Entry Management, cn=OracleContext > cn=Products > cn=DAS > cn=OperationURLs.

3. Update the orcldasurlbase entry to reflect the HTTPS port being used on the infrastructure tier, that is, https://<infrahost>:<port>/.

Once the entry is updated in Oracle Internet Directory, you must force a refresh of the portal cache, which holds the relevant Oracle Internet Directory information.

1. Log on to Oracle Portal as a user with administrator privileges.

2. Go to the Builder.

3. Click the Administration tab.

4. From the Portal tab, open Global Settings and navigate to the SSO/OID tab.

5. Scroll to the bottom of the page.

6. Select Refresh Cache for OID Parameters.

7. Click Apply.

8. The page should refresh with the appropriate value in the DAS Host Name field.

Note:

When SSO is enabled for SSL and registered to access via Portal URL, ensure that the Portal Global settings page points to the https url for the orcldasurlbase entry in OID, to facilitate OID operations from Oracle Portal.

At this point, configuration is complete for SSL communication to OracleAS Single Sign-On.

Note:

You must clear the Portal modplsql cache so that the page displays the correct SSO URLs.

The following example shows how to clear the Portal modsql cache on UNIX.

cd $INSTANCE_HOME/portal/cache
rm –rf ./session/*
rm -rf ./plsql/*
rm -rf ./pmd/*

7.3.2.1.3 SSL to Oracle Access Manager

If you are using Oracle Access Manager (OAM) as the authentication server, then you must enable SSL communication to Oracle Access Manager (OAM). For more information about securing communication with Oracle Access Manager (OAM), see "Secure Communication and Certificate Management" in Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.

7.3.2.1.4 SSL to Oracle Web Cache

Once you secure the Oracle Single Sign-On communication, the next option is to secure the communication to the front door of Oracle Portal, which is Oracle Web Cache. In this configuration, Oracle Web Cache can forward the request to the Oracle HTTP Server, which is acting as the Oracle Portal middle tier, using HTTP for better performance. Similarly, the Parallel Page Engine requests for portlet content that loopback to Oracle Web Cache can request the content using HTTP.

Figure 7-20 shows a configuration where Oracle Web Cache is configured to use SSL.

Figure 7-20 Secured Connection to Oracle Web Cache

After you have successfully performed the checks described in "Checks to Perform Before Configuring SSL", to configure SSL to Oracle Web Cache do the following:

Note:

In the previously described configuration of SSL, you must re-register the Oracle Portal middle-tier partner application. Because the OracleAS Single Sign-On middle-tier partner application is still non-SSL, you must re-register it as non-SSL. Therefore, the re-registration of mod_osso needs to specify the non-SSL URL of the OracleAS Single Sign-On middle tier for the mod_osso_url parameter to ssoreg.

For information about registering mod_osso, see the Oracle Application Server Single Sign-On Administrator's Guide.

- Enable OracleAS Single Sign-On for SSL

- Create a Wallet

- Secure Oracle Web Cache

- Configure the Parallel Page Engine

- Configure the HTTP Server

- Re-register the Oracle HTTP Server Partner Application

- Configure and Register Web Providers or Provider Groups Exposed over SSL

- Configure and Register WSRP Producers Exposed Over SSL

- Augment the Portal Tools Trusted Certificate File

- Enable Access for Secure Enterprise Search

- Wire the Portal Repository

- Configure the Portal Repository for Web Cache SSL

- Enable the WebLogic Plug-In

Enable OracleAS Single Sign-On for SSL

Perform the steps described in "Configuring SSL to OracleAS Single Sign-On Manually" to enable OracleAS Single Sign-On for SSL.

Create a Wallet

The various components of Oracle Portal use the Oracle Wallet Manager to store the certificates for the secure communication. The first step in this process is to obtain a certificate from a Certificate Authority (for example, OracleAS Certificate Authority, Verisign, GTE CyberTrust, and so on).

Note:

When you enabled OracleAS Single Sign-On for SSL, you had to create an empty wallet. For this procedure, Oracle recommends that you create a new wallet.

Obtaining a Certificate To obtain a digital certificate from the relevant signing authority, you submit a Certificate Request (CR) uniquely identifying your server to the signing authority.

1. Open the Oracle Wallet Manager in the middle-tier ORACLE_HOME/bin. On UNIX, enter owm from the command prompt. On Windows, invoke Oracle Wallet Manager from the Start menu.

2. Choose Wallet > New.
On UNIX, the wallet is stored in the following location by default:

/etc/ORACLE/WALLETS/<Account Name creating the Wallet>

On Windows, the wallet is stored in the following location by default:

\Documents And Settings\<Account Name creating the Wallet>\ORACLE\WALLETS

3. Create a password for the wallet, and select one of the option standard (default value) or PKCS1, as the Wallet Type.

4. Click Yes to accept the option to create a CR.

5. Fill out the Certificate Request dialog with details that uniquely identify your server. Table 7-22 shows some sample values for the various fields in the Certificate Request dialog.

Table 7-22 Sample Values for Fields in the Certificate Request Dialog

Field Name

Sample Values

Common Name

www.abc.com

Organizational Unit

DOCUMENTATION

Organization

Oracle Corporation

Locality/City

Redwood Shores

State/Province (Note: Do not use abbreviations; the value specified for state or province must be completely spelled out)

California

6. Click OK. A dialog will inform you that the certificate request was created successfully. The Certificate node in the Wallet Navigator will change to Requested.

7. Save the wallet in a convenient directory, for example:

ORACLE_HOME\webcache\wallets\portalssl

8. Send the CR to the chosen Certificate Authority (CA).

Note:

Certificates are issued by trusted third parties known as Certification Authorities (CA), for example, OracleAS Certificate Authority or Verisign. For details on how to obtain a certificate, check the appropriate vendor's Web site.

Cutting and Pasting

Depending on the CA, you may need to cut and paste the certificate request in their Web page or export the CR to a file for subsequent uploading to the site.

1. Select the Certificate node in the Wallet Navigator.

2. Highlight the Certificate text in the Certificate Request field. Make sure to include the BEGIN/END NEW CERTIFICATE REQUEST lines.

3. Copy and paste into the Certificate Request field on the CA's Web site.

Exporting Certificate Request

To export the certificate request:

1. Choose Operations > Export Certificate Request.

2. Choose the Name and Location of the CR file. A Status Line Message will confirm the successful export of the CR.

3. Once exported, the CR can be uploaded to the CA's Web site.

Managing Trusted Certificates Once the CA has processed the request, the User Certificate is forwarded to you either as text within an e-mail or as a simple file that is downloaded from a given Web page.

Note:

If you are using a trial Root Certificate or have chosen a CA which is not currently installed in the Oracle Wallet Manager, you must first import the CA's Trusted Certificate before importing your server-specific User Certificate.

Importing Trusted Certificate (if necessary)

To import the trusted certificate:

1. Choose Operations > Import Trusted Certificate.

2. Based on the CA, choose Paste the Certificate or Select a file that contains the certificate.

3. Select the appropriate certificate file or paste in the text from the e-mail. Oracle Wallet Manager expects base-64 encoded root certificates. If you do not have a base-64 encoded root certificate, then you must perform the steps described in the "Changing Trusted Certificate Format (if necessary)" section.

4. Click OK.

A status line message should appear indicating that the certificate was successfully imported. When you import the server specific User Certificate, the certificate node in the tree structure should also display as Ready.

Changing Trusted Certificate Format (if necessary)

If the certificate import fails, then it is possible that the Certificate is in a format that the Oracle Wallet Manager does not support. In this case, you need to convert it to a supported format before importing. The easiest way to do this is through the certificate Import and Export Wizards within a browser. The following steps are for the Internet Explorer browser:

1. In Internet Explorer, select Tools > Internet Options....

2. Click the Content tab.

3. Click Certificates....

4. Click the Trusted Root Certification Authorities tab.

5. Select Import... and follow the wizard to import the certificate.

6. Highlight the newly imported certificate from the list.

7. Click Export... and follow the wizard to the Export File Format page.

8. Choose Base-64 encoded X.509.

9. Click Next and give the certificate a file name.

10. Click Next.

11. Click Finish.

12. In Oracle Wallet Manager, choose Operations > Import Trusted Certificate.

Once the Trusted Root Certificate has been successfully imported into the Oracle Wallet Manager you may then import the server specific User Certificate.

Importing Server's User Certificate

To import the server's user certificate:

1. Choose Operations > Import User Certificate.

2. Based on the CA, choose Paste the Certificate or Select a file that contains the certificate.

3. Select the appropriate certificate file or paste in the text from the e-mail.

4. Click OK.

A status line message should appear indicating that the User Certificate has been successfully imported.

Having imported the certificate, it is important to save the wallet with the Autologin functionality enabled. This step is required because Oracle Web Cache accesses the wallet as the process starts and the wallet password is not held by Oracle Web Cache. If this property is not set, Oracle Web Cache immediately shuts down if running in SSL mode. To set this property, perform the following steps:

1. Choose the Trusted Certificate you just imported from the list in the Oracle Wallet Manager.

2. Choose Wallet > Save.

3. Check Wallet > AutoLogin, if it is not already checked.

Secure Oracle Web Cache

The sections that follow describe how to configure Oracle Web Cache to accept SSL connections.

Configuring Oracle Web Cache SSL Port

To Configure the Oracle Web Cache SSL port, perform the following steps:

1. Login to the Oracle Enterprise Manager 11g Fusion Middleware Control, as described in the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

2. From the Web Cache menu, select Administration > Ports Configuration.
The Ports Configuration page is displayed.

3. Click Create.

4. From the Create Port page, enter the following information:

- Port Type: NORM

- IP Address: ANY

- Port Number: SSL port that Web Cache will listen on

5. Click OK.

6. To add the SSL port, select the port you have configured in the previous steps, and click Edit... and enter the following information in the SSL Configuration section:

- Enable SSL: Enable the check-box

- Server Wallet Name: Select the Wallet containing the SSL server certificate

7. Click OK.

8. From the Web Cache menu, select Control > Restart...., to restart the Oracle Web Cache.

For more information on the procedure in the preceding text, refer to the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

Defining a Site for the Published SSL Hostname and Port

As there is no out-of-box default SSL configuration, you need to add a Site definition for the SSL-based Site that Oracle Web Cache will be caching. To add a site definition, perform the following steps:

1. Navigate to the Web Cache Home Page in the Oracle Enterprise Manager 11g Fusion Middleware Control, as described in the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

2. From the Web Cache menu, select Administration > Sites.
The Sites page is displayed.

3. Click Create under Sites.

4. On the Create Site page, enter the following details:

- Enter the Host, which is the hostname seen by the browser.
This is the load balancing router or reverse proxy server name for configurations that use a load balancing router or other reverse proxy, or it is the Oracle Web Cache hostname in a configuration where Oracle Web Cache receives browser requests.

- Set Port to the HTTPS port addressed by the browser requests.

- Leave the URL Prefix blank.

- Select the Default site checkbox.

- Deselect the Compression checkbox.

- Click OK.

- Click Apply.

5. Remove any sites that are no longer applicable to your modified configuration, including the default, out-of-the-box non-SSL site.

For more information on the procedure in the preceding text, refer to:

- The section on creating a site for HTTPS requests for the cache, in the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

- The section on creating site definitions in the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

Adding Site Aliases

Site aliases are necessary if content is cached across a number of different hostnames, or ports, or both, but which actually refer to the same logical content. For example, when the PPE makes a request for a portlet, and this portlet is requested on a non-SSL port, but the main Site is accessed over SSL, then an alias entry is needed. This equates the content accessed through the Site with SSL, to the content accessed over non-SSL. This way, invalidation requests that are sent to invalidate the content, will invalidate the content that is cached over either form of URL.

You need to create an alias for the non-SSL Oracle Web Cache listening port for the Oracle Web Cache SSL site. To create a site alias:

1. From the Sites page, select the newly added site, and click Edit.

2. In the Aliases section, click Create to create a new alias and enter the same hostname as used by the site entry, and provide the non-SSL port that the PPE will use to request portlets from Oracle Web Cache.

3. Click OK.

4. Click Apply.

5. Restart the server after making the necessary additions.

For example, if the logical site name is accessed using the URL https://portal.mycompany.com:4443, and the non-SSL Listen Port for Oracle Web Cache is 8090, then you should select the Site with SSL Port 4443, and add an alias for it using the non-SSL port of Oracle Web Cache (8090).

For more information on the procedure in the preceding text, refer to the section on creating site definitions in the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

Adding Site to Server Mappings of the New Site to the Origin Server

After adding a new site definition, you must add the site to server mapping for the newly defined site to the origin server. To do this:

1. From the Sites page, in the Site-to-Server Mapping section, click Create.
The Create Site-to-Server Mapping Definition page is displayed.

2. In the Create Site-to-Server Mapping section, enter the information of the Site you are mapping, which should be the Oracle Web Cache site with the SSL port. For example, if your logical site name is https://portal.mycompany.com:4443, then select the site with Host Pattern portal.mycompany.com and Port Pattern 4443.

3. In the Origin Servers section, select the non-SSL Origin Server to which requests should be routed for content, and move it from All Origin Servers to the Selected Origin Servers listing. For example, if the origin server is running on port 8888 on host portal.mycompany.com, then select portal.mycompany.com:8888.

4. Click OK to close the dialog box and see the new mapping appear in Table 7-23, "Site-to-Server Mapping" of the original page.

5. Click Apply Changes.

6. Click Apply.

7. Restart the Oracle Web Cache.

For more information on the procedure in the preceding text, refer to the section on mapping sites to origin servers in the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

Enabling Session Binding

The Session Binding feature in Oracle Web Cache is used to bind user sessions to a given origin server to maintain state for a period of time. Although almost all components running in a default Oracle Portal middle tier are stateless, session binding is required:

To make Oracle Web Cache bind the portal user session to the Oracle Portal middle tier, perform the following steps:

1. Navigate to the Web Cache Home page, in the Oracle Enterprise Manager 11g Fusion Middleware Control.

2. From the Web Cache menu, select Administration > Session Configuration.
The Session Configuration page displays.

3. Select the Site, you have created in previous steps.

4. From the Session Binding Configuration section, select Cookie based session binding with any Set-Cookie.

5. Click Apply.

For more information refer to the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

Adding Wallet Path for the Origin Server Wallet

You must enter the wallet path in the Origin Server Wallet page, by performing the following steps:

1. From the Oracle Web Cache Administration page (http://www.abc.com:<webcache_admin_port>/webcacheadmin), click Origin Server Wallet under Origin Servers, Sites, and Load Balancing.

Note:

You should log in as administrator. If you do not know the password, you can reset it by using Oracle Fusion MiddleWare Control. For more information, see "Configuring Password Security" in the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

2. Select the option for the Cache Name, to change its wallet path.

3. Click Edit Selected to display the Edit Origin Server Wallet dialog box.

4. Enter a valid Wallet Directory. For example, use the wallet directory path specified on the Listen Ports page.

5. Click Submit to close the dialog window. The new wallet directory path is displayed in the table on the Origin Server Wallet page.

Note:

After you have performed all the steps to secure Oracle Web Cache, you must restart the Oracle Web Cache server using the Oracle Fusion Middleware Control for the changes to take effect.

Configure the Parallel Page Engine

In this configuration, you need to configure the PPE to make portlet requests using HTTP requests. The sections that follow describe how to implement a partial SSL PPE configuration for this purpose. To configure the PPE, perform the following steps:

1. Login to the Oracle Enterprise Manager 11g Fusion Middleware Control.

2. From the Oracle Portal home page's Portal menu, select Settings, and then Page Engine.
The Page Engine Configuration page is displayed.

3. In the Advanced Properties section, add the following parameters:

- Use Port: 8090

- Use Scheme: http

- HTTPS Ports: 4443

4. (Optional) If you want the PPE to trust only specific certificates, in the Advanced Properties section, add x509certfile in the 509 Certification file field.The value of x509certfile is the absolute path to the text file containing the list of certificates which defines the group of "trusted" servers.

Note:

If you choose not to implement x509certfile, the PPE trusts any SSL certificate.

5. Click Apply.

6. Restart your managed server (WLS_PORTAL).

Configure the HTTP Server

Add a Virtual Host definition, for Portal to work with the SSL port of web cache, this configuration will specify the self-referential urls for the hostname and the port. Add the following details for the virtual host in the httpd.conf file:

1. Login to the Oracle Enterprise Manager 11g Fusion Middleware Control.

2. Expand Web Tier, and click the Oracle HTTP Server (ohs1) link for your Oracle Portal instance.

3. In the Oracle HTTP Server home page, select Administration, and then Advanced Configuration.

4. In the Advanced Server Configuration page, select httpd.conf from Select File option, and click Go.

5. Add the following details for the virtual host in the httpd.conf file:

LoadModule certheaders_module ORACLE_HOME/ohs/modules/mod_certheaders.so
NameVirtualHost *:OHS http port
<VirtualHost *:OHS http port>
ServerName https://webcachehost:webcache=sslport
RewriteEngine On
RewriteOptions inherit
SimulateHttps On
UseCanonicalName On
</VirtualHost>

ORACLE_HOME is the full path to the Oracle home for the Oracle Portal installation.

6. Click Apply.

7. Restart the Oracle HTTP Server by selecting Control, and then Restart from the Oracle HTTP Server Home page.

Re-register the Oracle HTTP Server Partner Application

Run ssoreg to register the virtual host for which mod_osso facilitates single sign-on. The specific application URLs to be defined as partner applications within this site are defined in the file osso.conf. ssoreg is located on the infrastructure tier (OID) in ORACLE_HOME/sso/bin.

The following example shows the usage of ssoreg on UNIX:

ORACLE_HOME/sso/bin/ssoreg.sh
-site_name www.abc.com:4443
-config_mod_osso TRUE
-mod_osso_url https://www.abc.com:4443
-update_mode MODIFY
-remote_midtier
-config_file /tmp/osso.conf
-admin_info cn=orcladmin

Copy osso.conf to the ohs instance in which you configured the virtual host for the Web Cache SSL port (ORACLE_INSTANCE/config/OHS/ohs1/osso.conf).

Restart the Oracle HTTP Server using the following commands:

ORACLE_INSTANCE/bin/opmnctl stopall
ORACLE_INSTANCE/bin/opmnctl startall

On Windows you must run the ssoreg.bat batch file instead. For more information about registering partner applications, see the Oracle Application Server Single Sign-On Administrator's Guide.

At this point, configuration is complete for SSL communication to Oracle Web Cache.

Configure and Register Web Providers or Provider Groups Exposed over SSL

See "Configuring and Registering Web Providers or Provider Groups Exposed Over SSL" for details.

Configure and Register WSRP Producers Exposed Over SSL

See "Configuring and Registering WSRP Producers Exposed Over SSL" for details.

Augment the Portal Tools Trusted Certificate File

If you use the Web Page data source of OmniPortlet provider, you are doing a loopback to the Web Clipping provider, and so need to add the web provider server certificate to the trusted certificate file pointed to by the <trustedCertificateLocation> tag in OmniPortlet provider.xml file. The default certificate file is the ca-bundle.crt file, located in the ORACLE_HOME\portal\conf directory.

To do this, perform the steps shown subsequently, which are based on the Internet Explorer browser. The steps may differ slightly if you are using another browser for capturing and exporting the necessary certificate.

1. Capture the necessary certificate: Point your browser to the Web Clipping provider test page: http://<host>:<port>/portalTools/webClipping/providers/webClipping.
You should see a Security Alert dialog box that shows "The security certificate was issued by a company you have not chosen to trust. View the certificate to determine whether you want to trust the certifying authority." or something similar. Click View Certificate, and then go through the following steps to export the certificate into a temporary file:

1. Select the Details tab.

2. Select Show: <All> in the drop-down list, and click Copy to File....Run the Export wizard to export the certificate in Base-64 encoded X.509 format into a temporary file ORACLE_HOME/portal/conf/providertemp.cer.

2. Append the certificate in the temporary file to the certificate file used by OmniPortlet provider (default is ORACLE_HOME/portal/conf/ca-bundle.crt).

Enable Access for Secure Enterprise Search

For Secure Enterprise Search to access secure Web sites, you need to import certificates into the crawler's trust store and the Oracle Containers for J2EE (WLS) JVM's trust store on the middle-tier and infrastructure instances.

By default, the WLS JVM recognizes certificates of well-known certificate authorities. However, if the secure portal instance uses a self-signed certificate or a certificate signed by an unknown certificate authority, then you must import the portal's certificate into the WLS JVM's truststore. The WLS JVM default truststore is located at ORACLE_HOME\jdk\jre\lib\security\cacerts.

To add the required certificate to the trust store, perform the following steps on the middle-tier and infrastructure instances:

1. Change directory to ORACLE_HOME\jdk\jre\lib\security\ on the middle tier.

2. Create a backup of the truststore file cacerts, for example, cacerts.bak.

3. Execute the following command to add the required certificate to the trust store:

$ORACLE_HOME/jdk/bin/keytool -import -alias <aliasName> -file <root_certificate_file_name> -trustcacerts -v -keystore $ORACLE_HOME/jdk/jre/lib/security/cacerts

Note:

Use any arbitrary value for -alias, but ensure that it is unique for each certificate.

4. Provide the trust store password, and type "Yes", when prompted for confirmation.

Note:

The preceding steps also need to be performed on the OracleAS Infrastructure containing the Secure Enterprise Search crawler.

Wire the Portal Repository

Configure the portal middle tier as follows :

1. Navigate to the Portal Home page in the Oracle Enterprise Manager 11g.

2. From the Portal menu, select Settings, and then Wire Configuration.
The Portal Wire Configuration page is displayed.

3. Enter the following information under Portal Middle Tier section in the Portal Wire Configuration page:

- Published Host: Enter the host name.

- Listening Port: Enter the port number.

- Check the SSL Protocol check box.

4. Click Apply.

5. Restart your managed server.

Configure the Portal Repository for Web Cache SSL

Portal requires mod_osso to retrieve the SSO information. Now that mod_osso is configured for SSL (registered as partner application with WC ssl port), portal requires the wallet path and password used to store the WC ssl certificate.

To update the Wallet Path and Password in Portal Repository Preference Store, do the following:

1. Import the Web Cache SSL certificate into the Portal Database Wallet's trust store.

2. If you don't have a database wallet, you could create one using OWM (Oracle wallet manager) or orapki utility in the installation where the database resides. Once you have the wallet, import the SSL certificate of web cache into the database wallet.

3. This wallet location has to be registered into the Portal preference store using the secwc.sql script, located at ORACLE_HOME\portal\admin\plsql\wwc.

Example 7-5 Registering the Wallet

cd $ORACLE_HOME/portal/admin/plsql/wwc
sqlplus <portal_schema/<portal_pwd>@connectstring sql> @secwc.sql <wallet_location> <wallet_pwd>
sql> @secwc.sql 'file:/u01/app/oracle/product/1021_prodee/dbwallet''welcome1'

Enable the WebLogic Plug-In

See Enable the WebLogic Plug-In, WebLogic ProxySSL, and WLProxySSLPassThrough parameter.

7.3.2.1.5 End to End SSL for Oracle Portal

For installations that require the utmost security, it is possible to configure SSL throughout the system. In this configuration, the loopback from the PPE to Oracle Web Cache uses a wallet and the hop between the PPE and the Web providers uses a certificate directly rather than through a wallet.

Figure 7-21 shows a configuration where SSL is configured throughout Oracle Portal.

Figure 7-21 Secured Connections Throughout the System

Note:

If you have already followed the steps described in Section 7.3.2.1.4, "SSL to Oracle Web Cache", you must revert all the changes you have made before configuring SSL throughout Oracle Portal.

After you have successfully performed the checks described in "Checks to Perform Before Configuring SSL", perform the following steps to configure SSL to OracleAS Single Sign-On:

- Enable OracleAS Single Sign-On for SSL

- Create a Wallet

- Configure Oracle HTTP Server and Oracle WebLogic Server

- Secure Oracle Web Cache

- Secure the Parallel Page Engine

- Specify Oracle Portal Published Address and Protocol

- Configure the HTTP Server

- Re-register the Oracle HTTP Server Partner Application

- Configure the Portal Repository for Web Cache SSL

- Enable the WebLogic Plug-In

- Configure and Register Web Providers or Provider Groups Exposed over SSL

- Configure and Register WSRP Producers Exposed Over SSL

- Augment the Portal Tools Trusted Certificate File

- Enable Access for Secure Enterprise Search

Enable OracleAS Single Sign-On for SSL

Perform the steps described in "Configuring SSL to OracleAS Single Sign-On Manually" to enable OracleAS Single Sign-On for SSL.

Create a Wallet

It is possible to share a single wallet across both the listener and origin server (and all other available ports in Oracle Web Cache) if Oracle Web Cache and the Oracle HTTP Server are on the same computer. Conversely, specific wallets may be created for each port. In this case the two servers and ports will be sharing the same wallet specified earlier.

In some cases, such as when the Oracle HTTP Server is on a different computer than Oracle Web Cache, you need to create a separate wallet for the Oracle HTTP Server. For this situation, refer to the steps in "Create a Wallet" to create the wallet for the Oracle HTTP Server.

In the default case, where the Oracle HTTP Server is on the same computer as Oracle Web Cache, you can share the wallet between the two.

Note:

After creating the wallet, import it by using either the Fusion MiddleWare Control or the importWallet WLST command. For more information, see the "Wallet Management" section in the Oracle Fusion Middleware Administrator's Guide.

Configure Oracle HTTP Server and Oracle WebLogic Server

You need to configure the Oracle HTTP Server to establish SSL communication to WebLogic Server (WLS) and the routing information to Weblogic Managed Server (WLS_PORTAL), should proxy the SSL mode. To configure HTTP and WLS perform the following steps:

1. From the Oracle Enterprise Manager 11g Fusion Middleware Control, go to Oracle HTTP Server home page, and select Administration, and then Advanced Configuration.
The Advanced Server Configuration page is displayed.

2. Select the portal.conf file from the menu option, and click GO.

3. Set the WLProxySSL parameter to ON, as shown below.

# WLS routing configuration
<Location /portal>
SetHandler weblogic-handler
WebLogicHost stbcr13-3.us.abc.com
WebLogicPort 9001
WLProxySSL On
</Location>

4. Click Apply.

5. You need to create a separate wallet for the Oracle HTTP Server. For this situation, refer to the steps in "Create a Wallet" to create the wallet for the Oracle HTTP Server and ensure that in the webcache.xml file, the wallet location is added in the <OSWALLET> tag.
You can add the wallet location to the <OSWALLET> tag using the Oracle Enterprise Manager 11g as follows:

1. Expand Web Tier and click the Oracle Web Cache (webcache1) link for your Oracle Portal instance.

2. From the Web Cache menu, select Security, and then SSL Configuration.

3. Select the wallet you have created, and click Change Wallet.

4. Click Ok.

6. Restart the Oracle HTTP Server.

7. Copy the certificate from the newly created wallet to a text file. Then, import the file into the keystore used by the managed server on which Oracle Portal is deployed.
To find out the location of the WebLogic Server keystore, go to the WebLogic Server Administration Console, navigate to Environment and then Servers, click the WLS_PORTAL link, select the Keystores subtab under the Configuration tab, and look for the path specified in the Java Standard Trust Keystore field.

For exporting the certificate from the Oracle HTTP Server wallet, you can use Oracle Wallet Manager or the orapki utilities available in the middle tier. For importing the certificate into the keystore, you can use keytool.

The following is a sample usage of keytool:

keytool -import -trustcacerts -alias aliasName -file
certificate_file_name -keystore cacerts -storetype JKS

certificate_file_name should contain the file server certificate and the certificate authority's root certificate exported from the wallet.

For more information, see "SSL Configuration in Oracle Fusion Middleware" in the Oracle Fusion Middleware Administrator's Guide.

Secure Oracle Web Cache

The sections that follow describe how to configure Oracle Web Cache to accept SSL connections and forward SSL requests to the SSL-enabled origin server.

Configuring the Oracle Web Cache SSL Port

To configure the Oracle Web Cache SSL port, perform the following steps:

1. Login to theOracle Enterprise Manager 11g Fusion Middleware Control, as described in the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

2. From the Web Cache menu, select the Administration, and then Ports Configuration.
The Ports Configuration page is displayed.

3. Click Create.

4. From the Create Port page, enter the following information:

- Port Type: NORM

- IP Address: ANY

- Port Number: SSL port that Web Cache is listening on.

5. Click OK.

6. To add the SSL port, select the port you have configured in the previous steps, and click Edit... and enter the following information in the SSL Configuration section:

- Enable SSL: Enable the check-box

- Server Wallet Name: Select the Wallet containing the SSL server certificate

7. Click OK.

8. From the Web Cache menu, select Control > Restart...., to restart the Oracle Web Cache.

For more information on the procedure in the preceding text, refer to the section on configuring HTTPS operations ports for the cache in the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

Adding the SSL Origin Server

To add the SSL origin server:

1. From the Web Cache menu, select Administration, and then Origin Servers.
The Origin Servers page is displayed.

2. Click Create... to add the SSL Origin Server.

3. Enter the information as follows:

- Host Name: Physical hostname of the computer in which Oracle HTTP Server is running

- Port: Oracle HTTP Server's SSL listen port. This property maps to the Listen parameter in the HTTP server's ssl.conf file located at ORACLE_INSTANCE\config\OHS\ohs1.

- Capacity: 100

- Protocol: HTTPS

- Routing: Enable

- Failover Threshold: 5

- Ping URL: /

- Ping Interval: 10

4. Click OK.

5. Click Apply.

6. From the Web Cache menu, select Control, and then Restart, to restart the Oracle Web Cache.

For more information on the procedure in the preceding text, refer to the section on configuring Origin Server, Load Balancing, and Failover Settings in the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

Defining a Site for the Published SSL Host Name and Port

As there is no out-of-box default SSL configuration, you need to add a site definition for the SSL-based Site that Oracle Web Cache will be caching. To define a site, perform the following steps:

1. Navigate to the Web Cache Home Page in the Oracle Enterprise Manager 11g Fusion Middleware Control, as described in the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

2. From the Web Cache menu, select Administration, and then Sites.
The Sites page is displayed.

3. Click Create under Sites.

4. On the Create Site page, enter the following details:

- Enter the Host Name, which is the hostname seen by the browser.

- Set Port to the HTTPS port addressed by the browser requests, which would be the Oracle Web Cache SSL listen port.

- Select Yes, for Default site.

- Select No, for Site-Wide Compression.
For other parameters accept the default settings and leave entry blank where applicable.

- Click OK.

- Click Apply.

5. Remove any sites that are no longer applicable to your modified configuration.

For more information on the procedure in the preceding text, refer to:

- The section on creating a site for HTTPS requests for the cache, in the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

- The section on creating site definitions, in the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

Adding Site to Server Mappings of the New Site to the Origin Server

After adding a new site definition, you must add the site to server mapping for the newly defined site to the origin server. To do this:

1. From the Sites page, in the Site-to-Server Mapping section, click Create.
The Create Site-to-Server Mapping Definition page is displayed.

2. Select the Site you are mapping and move it from All Origin Servers to the Selected Origin Servers listing, which should be the Oracle Web Cache site with the SSL port.

3. Check the Origin Server that you added in the previous step, entitled "Adding the SSL Origin Server", to which requests should be routed for content.

4. Click Apply Changes, and then Apply, to see the new mapping, as shown in Table 7-23 of the original page.

Table 7-23 Site-to-Server Mapping

Host Name(Oracle Web Cache Host Name)

Site Port(Oracle Web Cache Listen Port)

ESI Content Policy

Host Name(Oracle Web Cache Host Name)

Origin Server Port(Oracle Http Server Port)

Proxy

www.mycompany.com

8094

Unrestricted

www.mycompany.com

8889

No

5. Restart the Oracle Web Cache.

For more information on the procedure in the preceding text, refer to the section on mapping sites to origin servers, in the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache

Enabling Session Binding

The Session Binding feature in Oracle Web Cache is used to bind user sessions to a given origin server to maintain state for a period of time. Although almost all components running in a default Oracle Portal middle tier are stateless, session binding is required for two reasons:

To make Oracle Web Cache bind the portal user session to the Oracle Portal middle tier, perform the following steps:

1. Navigate to the Web Cache Home page, in the Oracle Enterprise Manager 11g Fusion Middleware Control.

2. From the Web Cache menu, select Administration, and then Session Configuration.
The Session Configuration page displays.

3. Select the site that you created in previous steps.

4. From the Session Binding Configuration section, select Cookie based session binding with any Set-Cookie.

5. Click Apply.

For more information, see the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

Adding Wallet Path for the Origin Server Wallet

See Adding Wallet Path for the Origin Server Wallet.

Secure the Parallel Page Engine

In this configuration, SSL is used throughout as the request comes to Oracle Web Cache through HTTPS and the PPE loops back over HTTPS as well. The server specifies the chain that goes with its certificate. As long as the chain is valid and leads to a self-signed root certificate, it is validated without determining whether it is trusted, assuming that you have not loaded any trust points into it.

To implement this configuration, perform the following steps on the Oracle Portal middle tier:

1. Login to the Oracle Enterprise Manager 11g Fusion Middleware Control.

2. From the Oracle Portal home page's Portal menu, select Settings, and then Page Engine to display the Page Engine Configuration page.

3. In the Advanced Properties section, enter the Oracle Web Cache SSL port into the HTTPS Ports value.

4. (Optional) If you want the PPE to trust only specific certificates, add x509certfile. The value of x509certfile is the absolute path to the text file containing the list of certificates which defines the group of "trusted" servers.

Note:

If you choose not to implement x509certfile, the PPE trusts any SSL certificate.

5. Click Apply.

6. Restart your managed server (WLS_PORTAL).

Specify Oracle Portal Published Address and Protocol

To specify the published address for Oracle Portal with the modified port for SSL, you need to use Oracle Enterprise Manager as follows:

1. Navigate to the Oracle Enterprise Manager 11g Fusion Middleware Control.

2. Click the Standalone Instance with the Oracle Fusion Middleware that is running the Oracle Portal middle tier.

3. Click the Oracle Portal system component (WLS_PORTAL).

4. From the Portal menu, click Settings, and then Wire Configuration.
The Portal Wire Configuration page is displayed.

5. Enter the following information under Portal Middle Tier section in the Portal Wire Configuration page:

- Listening Port: Enter the Oracle Web Cache SSL port number.

- Check the SSL Protocol check box.

6. Click Apply.

The Oracle Portal schema is updated with the setting and the Oracle Enterprise Manager 11g target instance is updated to use HTTPS for its URL tests.

If at a later time you choose to switch to HTTP, you would perform this same procedure and return Listening Port SSL Enabled to No.

Configure the HTTP Server

Edit the Virtual Host definition, for Portal to work with the SSL, this configuration will specify the self-referential urls for the hostname and the port. Go to Oracle HTTP Server home page in the Oracle Enterprise Manager 11g Fusion Middleware Control, select Administration, and then Advanced Configuration. Select the ssl.conf file, and add the following details for the virtual host shown in bold:

<VirtualHost *:8890>
UseCanonicalName On
ServerName https://dadvmn0041.us.abc.com:8094
<IfModule ossl_module>
SSLEngine on
SSLVerifyClient None
SSLCipherSuite
SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SH
A,SSL_RSA_WITH_DES_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_C BC_SHA
SSLCRLCheck Off
SSLWallet "wallet_location"

Replace wallet_location with the full path of the custom wallet as shown in the following example:

SSLWallet "$ORACLE_INSTANCE/config/OHS/ohs1/keystores/default"

Re-register the Oracle HTTP Server Partner Application

Run ssoreg to register the virtual host for which mod_osso facilitates single sign-on. The specific application URLs to be defined as partner applications within this site are defined in the file osso.conf. ssoreg is located on the infrastructure tier (OID) in ORACLE_HOME/sso/bin.

The following example shows the usage of ssoreg on UNIX:

ORACLE_HOME/sso/bin/ssoreg.sh
-site_name www.abc.com
-config_mod_osso TRUE
-mod_osso_url https://www.abc.com:8094
-update_mode MODIFY
-remote_midtier
-config_file ORACLE_INSTANCE/config/OHS/ohs1/osso.conf
-admin_info cn=orcladmin

Copy the osso.conf to the ohs instance where we configured virtual host for the webcache ssl port (ORACLE_INSTANCE/config/OHS/ohs1/osso.conf).

Restart the Oracle HTTP Server using the following commands:

ORACLE_HOME/bin/opmnctl stopall
ORACLE_HOME/bin/opmnctl startall

On Windows you must run the ssoreg.bat batch file instead. Refer to the information on creating partner applications in the Oracle Application Server Single Sign-On Administrator's Guide.

Configure the Portal Repository for Web Cache SSL

Portal queries mod_osso to retrieve the SSO information. Now that mod_osso is configured for SSL (registered as partner application with WC ssl port), portal need to know the wallet path and password used to store the WC ssl certificate.

To update the Wallet Path and Password in Portal Repository Preference Store, do the following:

1. Import the Web Cache SSL certificate into the Portal Database Wallet's trust store.

2. If you don't have a database wallet, you could create one using OWM (Oracle wallet manager) or orapki utility in the installation where the database resides. Once u have the wallet, import the SSL certificate of web cache into the database wallet.

3. This wallet location has to be registered into the Portal preference store using the secwc.sql script, located at ORACLE_HOME\portal\admin\plsql\wwc.

Example 7-6 Registering the Wallet

cd $ORACLE_HOME/portal/admin/plsql/wwc
sqlplus <portal_schema/<portal_pwd>@connectstring sql> @secwc.sql <wallet_location> <wallet_pwd>
sql> @secwc.sql 'file:/u01/app/oracle/product/1021_prodee/dbwallet''welcome1'

Enable the WebLogic Plug-In

See Enable the WebLogic Plug-In, WebLogic ProxySSL, and WLProxySSLPassThrough parameter.

Configure and Register Web Providers or Provider Groups Exposed over SSL

See "Configuring and Registering Web Providers or Provider Groups Exposed Over SSL".

Configure and Register WSRP Producers Exposed Over SSL

See "Configuring and Registering WSRP Producers Exposed Over SSL".

Augment the Portal Tools Trusted Certificate File

See "Augment the Portal Tools Trusted Certificate File".

Enable Access for Secure Enterprise Search

See "Enable Access for Secure Enterprise Search".

7.3.2.1.6 External SSL with Non-SSL Within Oracle Fusion Middleware

The previous configurations discuss how to configure Oracle Portal in such a way that communications within Oracle Fusion Middleware are secured through SSL. In some cases, you may want to have Oracle Portal set up such that the site is externally accessible through SSL URLs but the Oracle Fusion Middleware is internally running in non-SSL mode. Note that in this latter scenario, you need to have the SSL to non-SSL translation done either by a load balancing router (LBR) or an SSL accelerator. The section that follows outlines the steps you would use with an accelerator on an LBR or a reverse proxy server performing the SSL translation.

With this option, the SSL features of the Oracle Fusion Middleware Security Framework are not used, but, instead, an external component is used for providing the SSL connection point. These external accelerators may be coupled with LBRs or reverse proxy servers. Oracle Fusion Middleware enables you to configure these external devices to provide SSL, thus allowing Oracle Fusion Middleware to use HTTP internally for the best performance.

Figure 7-22 shows a configuration where Oracle Portal is externally accessible through SSL.

Figure 7-22 External SSL Only

Note:

In a typical configuration, w1.abc.com and m1.abc.com would reside on the same computer, but for illustration purposes, they are separated here.

For the purposes of this procedure, assume the following:

- In this example, SSL acceleration is performed by an SSL accelerator, such as LBR, which also proxies page requests between the HTTP and HTTPS protocols and their ports. The location of the SSL end point will determine the target for the loopback requests. For example, if an SSL-enabled reverse proxy server front-ends a single protocol LBR, loopback requests will be sent to the LBR, while the published site is exposed by the reverse proxy server.

- Your load balancing router is running on lbr.abc.com and the LBR port used for accessing the site is 443.

- Oracle Web Cache is on computer w1.abc.com and the listening port is 8090, the administration port is 4002, and the invalidation port is 4001.

- The Oracle HTTP Server is running on computer m1.abc.com and the port is 8888.

- The port numbers used are example values only.

See Also:

- Section 6.3, "Configuring Multiple Middle Tiers with a Load–Balancing Router"

- Oracle Portal Enterprise Deployment Guide: http://www.oracle.com/technetwork/database/features/availability/maa-portal-edg-129356.pdf

- Oracle Fusion Middleware High Availability Guide

After you have successfully performed the checks described in "Checks to Perform Before Configuring SSL", perform the following steps to configure Oracle Portal with external SSL:

- Configure the Oracle Fusion Middleware Middle Tier

- Re-register the Oracle HTTP Server Partner Application

- Enable Access for Secure Enterprise Search

- Enable the WebLogic Plug-In

Configure the Oracle Fusion Middleware Middle Tier

You need to configure the Oracle Fusion Middleware middle tier to allow the underlying components to construct URLs based on the load balancing router's hostname, lbr.abc.com, and port (443). To do this:

1. Edit httpd.conf as follows:

1. Access the Oracle Enterprise Manager 11g Fusion Middleware Control.

2. Click the link for the middle tier where Oracle Portal is installed.

3. Expand Web Tier and click the HTTP Server link for your Oracle Portal instance.

4. In the Oracle HTTP Server home page, select Administration, and then Advanced Configuration.

5. In the Advanced Server Configuration page, select httpd.conf from Select File option and click Go.

6. Add the following Virtual Host definitions:

NameVirtualHost *:8888
<VirtualHost *:8888>
ServerName https://lbr.abc.com:443
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>

<VirtualHost *:8888>
ServerName http://m1.abc.com:8090
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

7. Click Apply.

8. Restart the Oracle HTTP Server by selecting Control, and then Restart from the Oracle HTTP Server Home page.

2. Configure the Parallel Page Engine. To do this, perform the following steps:

1. Login to the Oracle Enterprise Manager 11g Fusion Middleware Control.

2. From the Oracle Portal home page's Portal menu, select Settings, and then Page Engine to display the Page Engine Configuration page.

3. In the Advanced Properties section, add the following parameters, to attempt loopbacks using a different protocol and port than what is used by the site:

- Use Scheme: http

- Use Port: 8090

- HTTPS Port: 443

4. Click Apply.

5. From the Portal menu, select Control, then Shut Down and Start Up, to restart your WLS_PORTAL instance.

3. Ensure that DNS resolves lbr.abc.com to the LBR's IP address.

4. Login to the Oracle Enterprise Manager 11g Fusion Middleware Control and do the following:

1. From the Portal home page's Portal menu, click Settings, and then Wire Configuration to display the Portal Wire Configuration page.

2. In the Portal Wire Configuration page, enter the following parameters for Web Cache in the Oracle Web Cache section:

- Host: lbr.abc.com

- Invalidation Port: 4001

- Invalidation User: invalidator

- Invalidation Password: The password you have specified

3. In the Portal Middle Tier section, select SSL Protocol checkbox.

4. Click Apply.

5. From the Oracle Web Cache home page in the Oracle Enterprise Manager 11g Fusion Middleware Control, select Administration, and then Sites.
The Sites page is displayed.

6. Click Create under Sites.

7. On the Create Site page, enter the following details:

- Host: The published hostname and fully qualified domain of the external SSL accelerator device or reverse proxy server.

- Port: The SSL port number, for example, 443 for the default SSL port.

- URL Prefix: Leave blank.

- Client-Side Certificate: Not required.

- Default Site: Yes.

- Compression: No.

Refer to the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache for detailed instructions on the configuration mentioned earlier.

8. Click OK.

9. Click Apply.

10. Set up an alias for Oracle Web Cache. In the configuration where the Parallel Page Engine loops back to Oracle Web Cache and Oracle Web Cache is listening on a different port than the load balancing router, loopback content gets cached with a URL key of lbr.abc.com:8090, whereas Oracle Portal sends invalidation requests to invalidate URLs with the format lbr.abc.com:443. To get around this inconsistency, you need to set up an alias in Oracle Web Cache to let it know that lbr.abc.com:8090 and lbr.abc.com:443 are the same, invalidation requests for one should invalidate requests for the other as well, and the cached content should also be leveraged based on this alias.

1. From the Oracle Web Cache home page in the Oracle Enterprise Manager 11g Fusion Middleware Control, select Administration, and then Sites.

2. From the Sites page, select the newly added site, in this case lbr.abc.com and click Edit.
The Edit Site page is displayed.

3. In the Aliases section, click Create to create a new alias, enter lbr.abc.com as the Host and 8090 as the Port, where 8090 is the value for usePort in the appConfig.xml configuration file for the Parallel Page Engine.

4. Click OK.

5. Click Apply.

6. From the Web Cache menu, select Control, and then Restart, to restart Oracle Web Cache.

If the default HTTPS port 443 is chosen for a site configured with external SSL configuration, as in the preceding example, an additional alias needs to be defined in Oracle Web Cache for the site lbr.abc.com:443, which should be lbr.abc.com:80. Follow the instructions for creating the alias as mentioned in Step 10 and replace port 8090 with 80.

An alias for port 80 is needed because the "Host" header sent by the browser will be lbr.abc.com (without a port number appended to it). Because Oracle Web Cache is listening on the HTTP port, it will assume that the port number is 80 and use this to determine the site-to-server mapping. It also uses this for cache key creation.

11. After adding a new site definition, you must add the site to server mapping for the newly defined site to the origin server. To do this:

1. From the Sites page, in the Site-to-Server Mapping section, click Create.
The Create Site-to-Server Mapping Definition page is displayed.

2. In the Create Site-to-Server Mapping section, enter the information of the Site you are mapping (lbr.abc.com) and then select a site definition created in the previous step.

3. In the Origin Servers section, select m1.abc.com, and move it from All Origin Servers to the Selected Origin Servers listing.

4. Click OK.

5. Click Apply.

6. From the Web Cache menu, select Control, and then Restart, to restart Oracle Web Cache.
To verify that the site has been mapped correctly, navigate to the Site-to-Server Mapping page, and ensure that m1.abc.com is mapped to the site lbr.abc.com.

For more information on the procedure in the preceding text, refer to the section on mapping sites to origin servers, in the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

12. Configure your load balancing router, lbr.abc.com, to:

1. Accept requests on HTTPS port 443 and forward them to the Oracle Web Cache port 8090 running on computer w1.abc.com, while converting HTTPS requests to HTTP.

2. Accept requests on HTTP port 8090 and forward them to the Oracle Web Cache port 8090 running on computer w1.abc.com. This enables the loopback requests. The LBR's port 8090 should only be accessible from the middle tier. Your firewall may need to be configured separately to make this work. To test this, run the following command on the middle-tier server:

telnet lbr.abc.com 8090

You should not see any connection failure message when you run the telnet command.

3. Accept requests on HTTP port 4001 for the invalidation requests and forward them to the Oracle Web Cache invalidation port 4001. You must be able to connect to the LBR's port for invalidation requests from the Oracle Metadata Repository. Your firewall may need to be configured separately to make this work. To test this, run the following command on the Oracle Metadata Repository server:

telnet lbr.abc.com 4001

You should not see any connection failure message when you run the telnet command.

4. Facilitate communication from the middle tier to Oracle Web Cache through the LBR. NAT-related configuration may be required for this. Refer to Section 6.3, "Configuring Multiple Middle Tiers with a Load–Balancing Router" for more information on configuring NAT.

Note:

Refer to Section 6.3.6, "Step 6: Configure Portal Tools and Web Providers (Optional)" for information on how this configuration might affect your Web providers.

5. Facilitate communication from the Oracle Metadata Repository to Oracle Web Cache for the invalidation requests through the LBR. NAT-related configuration may be required for this.

Re-register the Oracle HTTP Server Partner Application

Run ssoreg to register the virtual host for which mod_osso facilitates single sign-on. The specific application URLs to be defined as partner applications within this site are defined in the file osso.conf. ssoreg is located on the infrastructure tier in ORACLE_HOME/sso/bin.

The following example shows the usage of ssoreg on UNIX:

$ ssoreg.sh
-site_name lbr.abc.com
-config_mod_osso TRUE
-mod_osso_url https://lbr.abc.com:8094
-Oracle_home_path ORACLE_HOME
-config_file /tmp/osso.conf
-admin_info cn=orcladmin
-virtualhost
-remote_midtier

On Windows you must run the ssoreg.bat batch file instead. Refer to the information on creating partner applications in the Oracle Application Server Single Sign-On Administrator's Guide.

Enable Access for Secure Enterprise Search

For Secure Enterprise Search to access secure Web sites, you need to import certificates into the crawler's trust store and the Oracle Containers for J2EE (WLS) JVM's trust store on the infrastructure instance.

By default, the WLS JVM recognizes certificates of well-known certificate authorities. However, if the secure portal instance uses a self-signed certificate or a certificate signed by an unknown certificate authority, then you must import the portal's certificate into the WLS JVM's truststore. The WLS JVM default truststore is located at ORACLE_HOME\jdk\jre\lib\security\cacerts.

To add the required certificate to the trust store, perform the following steps on the infrastructure instance:

1. Change directory to ORACLE_INSTANCE\jdk\jre\lib\security on the infrastructure.

2. Create a backup of the truststore file cacerts, for example, cacerts.bak.

3. Execute the following command in UNIX to add the required certificate to the trust store:

$ORACLE_HOME/jdk/bin/keytool -import -alias <aliasName> -file <root_certificate_file_name> -trustcacerts -v -keystore $ORACLE_HOME/jdk/jre/lib/security/cacerts

Note:

Use any arbitrary value for -alias, but ensure that it is unique for each certificate.

4. Provide the trust store password, and type "Yes", when prompted for confirmation.

Note:

The preceding steps also need to be performed on the OracleAS Infrastructure containing the Secure Enterprise Search crawler.

Enable the WebLogic Plug-In

See Enable the WebLogic Plug-In, WebLogic ProxySSL, and WLProxySSLPassThrough parameter.

7.3.2.1.7 Configuring SSL to Oracle WebLogic Managed Server

This section describes how to enable SSL for WLS using the WebLogic Administration Console. Perform the following steps:

1. Login to the WebLogic Administration Console, and ensure that the console is configured to the domain you have created during portal installation.

2. If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.

3. In the left pane of the Console, expand Environment and select Servers.

4. In the Servers table, click the WLS_Portal Managed Server instance.

5. Select SSL Listen Port Enabled, and enter the SSL Listen Port number.

6. Select the Configuration tab group, and then the Keystores tab page.

7. In the Keystores field, select the Demo Identity and Demo Trust option.

8. Select the General tab page.

9. Expand the Advanced group of options near end of the page, and select the WebLogic Plug-In Enabled option.

10. Click Save.

Your WLS managed server (WLS_Portal) is configured for SSL.

7.3.2.1.8 Configuring and Registering Web Providers, Provider Groups, and WSRP Producers Exposed Over SSL

This section describes how you can configure Oracle Portal to provide access to Web providers, Provider groups, and WSRP producers exposed over SSL. This section contains the following topics:

- Configuring and Registering Web Providers or Provider Groups Exposed Over SSL

- Configuring and Registering WSRP Producers Exposed Over SSL

Configuring and Registering Web Providers or Provider Groups Exposed Over SSL

To register a Web provider, which is exposed over SSL, you must have a copy of the root certificate of the certificate authority used by the Web provider. If the Web provider is using an unknown or uncommon certificate authority, you need to add the appropriate root certificate (using Base-64 encoded X.509 format) to the set of trusted certificates recognized by the Oracle Database hosting the Oracle Metadata Repository containing the Oracle Portal schema. To configure Web providers or provider groups exposed over SSL, perform the following steps:

1. To import the producer SSL certificate into the database keystore, perform the following:

- Change directory to $ORACLE_HOME/javavm/lib/security on the Oracle home containing the Oracle Database hosting the Oracle Metadata Repository containing the Oracle Portal schema.

- Create a backup of the truststore file cacerts, for example, cacerts.bak.

- Execute the following command (in Unix) to add the required certificate to the trust store:

$ORACLE_HOME/jdk/bin/keytool -import -alias <aliasName> -file <root_certificate_file_name> -trustcacerts -v -keystore $ORACLE_HOME/javavm/lib/security/cacerts

Note:

Use any arbitrary value for -alias, but ensure that it is unique for each certificate.

- Provide the trust store password, and type Yes, when prompted for confirmation.

Note:

If your portal schema is located in an Repository Creation Utility (RCU) database and if the release of that Oracle Database is earlier than 10g (10.1.0.x), then these steps do not need to be performed.

Example 7-7 Certificate Registration in the Database

[ABC@stake03 security]$ $ORACLE_HOME/jdk/bin/keytool -import -alias cacert2 -file /home/name1/testcer.crt.cer -trustcacerts -v -keystore /u01/app/oracle/product/1021prod_ee/javavm/lib/security/cacerts
Enter keystore password:  changeit
Owner: CN=stacu35.us.oracle.com, O=wc_1
Issuer: CN=stacu35.us.oracle.com, O=wc_1
Serial number: 0
Valid from: Thu Mar 06 19:48:48 PST 2008 until: Tue Mar 05 19:48:48 PST 2013
Certificate fingerprints:
MD5:  4D:43:B4:A7:E9:02:33:20:A9:82:C4:CE:8D:4A:46:59
SHA1: FB:3D:1D:6D:01:6F:7B:35:27:85:20:0F:C4:28:F2:6A  2:75:1D:29
Trust this certificate? [no]:  yes
Certificate was added to keystore
[Saving /u01/app/oracle/product/1021prod_ee/javavm/lib/security/cacerts]

2. To import the producer SSL certificate into the Portal Midtier WLS keystore, perform the following:

- Change directory to JAVA_HOME/jre/lib/security/ where Java Home is the JDK that the WLS_PORTAL managed server is running on.

- Create a backup of the truststore file cacerts, for example, cacerts.bak.

- Execute the following command to add the required certificate to the trust store:

$JAVA_HOME/bin/keytool -import -alias <aliasName> -file <root_certificate_file_name> -trustcacerts -v -keystore $JAVA_HOME/jre/lib/security/cacerts

Note:

Use any arbitrary value for -alias, but ensure that it is unique for each certificate.

- Provide the trust store password, and type Yes, when prompted for confirmation.

Example 7-8 Certificate Registration in the Portal Midtier WLS

[ABC@stake03 security]$ $JAVA_HOME/jdk/bin/keytool -import -alias cacert2 -file /home/name1/testcer.crt.cer -trustcacerts -v -keystore /u01/app/oracle/product/portal/jdk/jre/lib/security/cacerts
Enter keystore password:  changeit
Owner: CN=stacu35.us.oracle.com, O=wc_1
Issuer: CN=stacu35.us.oracle.com, O=wc_1
Serial number: 0
Valid from: Thu Mar 06 19:48:48 PST 2008 until: Tue Mar 05 19:48:48 PST 2013
Certificate fingerprints:
MD5:  4D:43:B4:A7:E9:02:33:20:A9:82:C4:CE:8D:4A:46:59
SHA1: FB:3D:1D:6D:01:6F:7B:35:27:85:20:0F:C4:28:F2:6A  2:75:1D:29
Trust this certificate? [no]:  yes
Certificate was added to keystore
[Saving /u01/app/oracle/product/portal/jdk/jre/lib/security/cacerts]

See Also:

The subsection "Secure the Parallel Page Engine" in Section 7.3.2.1.5, "End to End SSL for Oracle Portal".

Configuring and Registering WSRP Producers Exposed Over SSL

To configure WSRP producers exposed over SSL, perform the following steps:

1. In a Web browser, enter the WSDL URL of your WSRP producer to ensure that it is working. If the WSDL definition does not appear in the browser, then the deployment of your WAR file must have failed. Refer to the section on diagnosing Java portlet problems in the Oracle Fusion Middleware Developer's Guide for Oracle Portal.

2. Modify your WSDL file and make it available over HTTP.

Note:

The following steps are for a setup where the WSRP ports are generated with the HTTP protocol because HTTP was used for requesting the WSDL URL. However, if you are accessing WSDL using HTTP and the internal URLs are referenced using HTTPS, then you can skip Step 2.

1. In a Web browser, enter the HTTPS WSDL URL. For example:
https://host:port/context-root/portlets?WSDL

Each port in the WSDL definition should be displayed with an HTTPS location. For example:

<wsdl:port binding="bind:WSRP_v1_Markup_Binding_SOAP" name="WSRPBaseService">
<soap:address location="https://host:port/context-root/portlets/WSRPBaseService"/>
</wsdl:port>

2. Save a copy of the WSDL definition to a file on your application server in a location where it can be accessed externally over HTTP. For example, the ORACLE_HOME/Apache/Apache/htdocs/ directory of your Oracle Portal installation. When you register the producer in Oracle Portal, use the location of this WSDL for your WSDL URL on the Define Connection page of the registration. The format of a WSDL URL is as follows:
http://<host>:<port>/<Savedxml.xml>WSDL

Note:

In the WSDL URL format, change the file type from <Savedxml.xml> to <Savedxml.html> or <Savedxml.txt>. This change in file type is required only for Oracle Portal versions starting from 11.1.1.4.0.

3. If the ports are not listed with HTTPS locations, then you must change them manually before proceeding. You can do this by saving the XML to a file from the browser and opening it in a text editor.

3. To register a WSRP producer, which is exposed over SSL, you must have a copy of the root certificate of the certificate authority used by the WSRP producer. Check if the root certificate exists in the set of trusted certificates recognized by the Oracle Database hosting the Oracle Metadata Repository containing the Oracle Portal schema. To check if a root certificate already exists, repeat Step 1 and Step 2 of Section 7.3.2.1.5, "Configure and Register Web Providers or Provider Groups Exposed over SSL". Access the home page of the SSL-enabled portal. If a certificate security alert dialog box appears, then skip Step 4.

4. If the WSRP producer is using an unknown or uncommon certificate authority, then you need to add the appropriate root certificate (using Base-64 encoded X.509 format) to the set of trusted certificates. To add a root certificate of the certificate authority used by the WSRP producer to the truststore, repeat Step 1 and Step 2 of Section 7.3.2.1.5, "Configure and Register Web Providers or Provider Groups Exposed over SSL".

5. (Optional) If you want the PPE to trust only specific certificates, then add x509certfile in the appConfig.xml file (located at, DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration). The value of x509certfile is the absolute path to the text file containing the list of certificates which defines the group of trusted servers. For example:
<x509certfile>c:\mySSLconfig\trustedCerts.txt</x509certfile>

The contents of a typical trustedCerts.txt file would look as shown in Example 7-9.

Example 7-9 Sample File Containing a List of Certificates

-----BEGIN CERTIFICATE-----
MIICPDCCAaUCEDJQM89Q0VbzXIGtZVxPyCUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk2MDEyOTAwMDAwMFoXDTIwMDEwNzIzNTk1OVow
XzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAx
IFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQDlGb9to1ZhLZlIcfZn3rmN67eehoAKkQ76OCWvRoiC5XOooJskXQ0fzGVuDLDQ
VoQYh5oGmxChc9+0WDlrbsH2FdWoqD+qEgaNMax/sDTXjzRniAnNFBHiTkVWaR94AoDa3EeRKbs2
yWNcxeDXLYd7obcysHswuiovMaruo2fa2wIDAQABMA0GCSqGSIb3DQEBAgUAA4GBAEtEZmBoZOSY
G/OwcuaViXzde7OVwB0u2NgZ0C00PcZQmhCGjKo/O6gE/DdSlcPZydvN8oYGxLEb8IKIMEKOF1Ac
ZHq4PplJdJf8rAJD+5YMVgQlDHx8h50kp9jwMim1pN9dokzFFjKoQvZFprY2ueC/ZTaTwtLXa9ze
WdaiNfhF
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
MIICPTCCAaYCEQC6WslMBTuS1qe2307QU5INMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMgUHJpbWFy
eSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0wNDAxMDcyMzU5NTla
MF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3Mg
MiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEAtlqLow1qI4OAa885h/QhEzMGTCWi7VUSl8WngLn6g8EgoPovFQ18oWBrfnks
+gYPOq72G2+x0v8vKFJfg31LxHq3+GYfgFT8t8KOWUoUV0bRmpO+QZEDuxWAk1zr58wIbD8+s0r8
/0tsI9VQgiZEGY4jw3HqGSRHBJ51v8imAB8CAwEAATANBgkqhkiG9w0BAQIFAAOBgQC2AB+TV6QH
p0DOZUA/VV7t7/pUSaUw1iF8YYfug5MLv7Qz8pisnwa/TqjOFIFMywROWMPPX+5815pvy0GKt3+B
uP+EYcYnQ2UdDOyxAArdG6S7x3ggKLKi3TaVLuFUT79guXdoEZkj6OpS6KoATmdOu5C1RZtG644W
78QzWzM91Q==
-----END CERTIFICATE-----

Note:

If you choose not to implement x509certfile, then the PPE trusts any SSL certificate.

6. Restart your Oracle Fusion Middleware instance:

ORACLE_HOME/opmn/bin/opmnctl stopallORACLE_HOME/opmn/bin/opmnctl startall

7. Register the WSRP producer, by specifying the WSDL. The URL used here must be HTTPS based. For example:

http://><host>:<port>/wsrp-tools/portlets/wsrp2/WSDL

7.3.2.2 Securing the Connection to Oracle Internet Directory (Optional)

In Section 7.3.2.1, "Configuring SSL for Oracle Portal", we were mainly concerned with the HTTP-based network hops. However, you can also secure the network connection to the Oracle Internet Directory itself, which is LDAP-based communication. In this case the Oracle Internet Directory should be configured to use LDAP over SSL (LDAPS). You can find further information about configuring the Oracle Internet Directory for LDAPS in the Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

Once Oracle Internet Directory is configured to use SSL, you must update the Oracle Portal schema to use the new port on the LDAP server. To perform this step, you run the SQL script, secupoid.sql, located in ORACLE_HOME/portal/admin/plsql/wwc. This script allows for the setting of the following Oracle Internet Directory related parameters:

- Directory Host Name

- Directory Port

- Application Directory Password

- SSL Settings

When you run the script, it displays the current settings and gives you the ability to change them accordingly. In this case, you want to set the following:

use_ssl_to_connect_to_ldap=Y

The script will then give you the option of automatically refreshing Oracle Portal's Oracle Internet Directory cache. Refer to Section B.3, "Using the secupoid.sql Script" for more information.

Note:

From 10g Release 2 (10.1.2) onwards, you can optionally install Oracle Portal using LDAPS rather than having to implement it after installation.

7.3.2.3 Post-Installation Security Checklist

After Oracle Portal is installed, you should consider performing the following steps to complete the security configuration:

- Updating the Oracle Text Base URL

- Safeguard Passwords for Lightweight Oracle Portal Users

- Remove Unnecessary Objects

- Review Default Seeded Privileges

- Revoke Public Access to Provider Components

- Control Access to Administration Pages

- Protect PL/SQL Packages

- Consider SSL

- Consider LDAP over SSL for Oracle Internet Directory Connections

- Change the Application Entity Password

7.3.2.3.1 Updating the Oracle Text Base URL

After configuring SSL for portal, perform the following steps to update the Oracle Text Base URL:

1. Login to your Oracle Portal.

2. Click the Administer tab.

3. Under Services, select Global Settings.

4. Select the Search tab, from the Global Setting page.

5. In Oracle Text Base URL, change the URL property from http to https in the Base URL. For example, change http://abc0088.us.abc.com:8090/portal/pls/portal/ to https://abc0088.us.abc.com:8090/portal/pls/portal/.

7.3.2.3.2 Safeguard Passwords for Lightweight Oracle Portal Users

Unscrupulous users might try to learn the passwords of your default users, which could result in an account lock. This lock can be released from the server, but it is far better that you not depend on the default user accounts for administrative purposes. To safeguard the passwords for these accounts do the following:

1. Create new lightweight administrator accounts with the same access rights as the default users, and set the account termination date in OracleAS Single Sign-On for the default users. Alternatively, you can also deselect the Allow User To Log In setting in the Edit User page for the default users.

2. Once you have disabled login or changed the passwords for the default users, try logging in to the portal as the default users with the default passwords to ensure that your changes have been successful.

7.3.2.3.3 Remove Unnecessary Objects

To prevent users from entering your portal through obsolete or unnecessary pages, you should remove any unused objects from your Oracle Portal and database environment. For example:

- Delete page groups that are no longer in use.

- Delete Oracle Portal providers that are no longer in use.

7.3.2.3.4 Review Default Seeded Privileges

When Oracle Portal is installed, the seeded groups listed in Table 7-2 are provisioned with a set of privileges that are typically required by users in those roles. You should review these initial set of privileges to ensure that they are consistent with your security policy.

Users or groups can obtain privileges from one of the following sources:

- Oracle Portal access control entries

- Oracle Internet Directory privilege groups

To edit the privileges granted through Oracle Portal access control entries, you edit the user or group profile from the Administer tab with the User Profile Portlet or Group Profile Portlet. Click the User or Group Profile dialog's Privilege tab. You can revoke or assign privileges from this list.

To edit the privileges granted through Oracle Internet Directory privilege groups, use the User Portlet or Group Portlet to edit the User or Group in Oracle Internet Directory. Select or deselect the check marks by the Privilege Assignment list to grant or revoke the appropriate privileges in Oracle Internet Directory.

Privileges granted to the AUTHENTICATED_USERS group are given to any user that logs on to Oracle Portal through OracleAS Single Sign-On upon successful authentication. This is the group that you will want to establish with the default privileges for all your logged in users.

For example, if you do not want authenticated users to be able to create groups, then edit the AUTHENTICATED_USERS group through the Group Portlet and remove the check mark beside Allow group creation under Privilege Assignment.

7.3.2.3.5 Revoke Public Access to Provider Components

In some cases, Oracle Portal provider components may give users the option to view or modify records in application tables. To tighten security, you should revoke public access from such components if it is unnecessary. You can also use a menu component with specific access rights on the menu options to more tightly control application access.

7.3.2.3.6 Control Access to Administration Pages

To prevent users who should not have access to administration interfaces from entering administration pages, you should ensure that you control access rights for the following page groups and the pages they contain:

- Portal Design-Time Pages is the page group that contains the Oracle Portal Home Page, and the Builder and Navigator pages.

- Portlet Repository

To control access to the page groups mentioned earlier, perform the following steps:

1. In the Navigator, click Page Groups.

2. Click Edit Properties next to the page group for which you want to change the access settings.

3. Click the Access tab.

4. Grant MANAGE ALL to specific users or to certain groups. For example, DBA, PORTAL_ADMINISTRATORS, PORTAL_DEVELOPERS, and your own groups.

5. When you are done, click OK.

To control access to individual administration pages in these page groups, perform the following steps:

1. In the Navigator, click Page Groups.

2. Click Contents next to the page group that contains the pages on which you want to change the access settings.

3. Click Pages.

4. Click Properties next to the page for which you to change the access settings.

5. Click the Access tab.

6. Grant MANAGE ALL to specific users or to certain groups. For example, DBA, PORTAL_ADMINISTRATORS, PORTAL_DEVELOPERS, and your own groups.

7. When you are done, click OK.

Note:

The Builder page is the root page of the Portal Design-Time Pages page group. To alter its access settings, you must click Edit Root Page next to the Portal Design-Time page group.

7.3.2.3.7 Protect PL/SQL Packages

The default installation protects standard database procedures that are granted to PUBLIC (for example, dbms_*, utl_*). If you write your own PL/SQL packages, which are granted to PUBLIC, and do not want to provide access to these packages through a Web browser, then refer to the chapter "Securing Application Database Access Through mod_plsql" in the Oracle Fusion Middleware User's Guide for mod_plsql.

7.3.2.3.8 Consider SSL

If your portal contains confidential information, you should consider configuring it with SSL. See Section 7.3.2.1, "Configuring SSL for Oracle Portal" for the available SSL configuration options.

7.3.2.3.9 Consider LDAP over SSL for Oracle Internet Directory Connections

By default, Oracle Portal connects to the directory using LDAP without SSL. If the directory server is configured for an SSL port, though, Oracle Portal can be configured to use LDAP over SSL, also known as LDAPS.

See Also:

Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory

To configure Oracle Portal to use SSL to connect to the directory, you must run the secupoid.sql script, located in ORACLE_HOME/portal/admin/plsql/wwc. This script enables you to change the following Oracle Portal configuration parameters related to the directory:

- Directory hostname

- Directory port

- Application directory password

- SSL setting

When you install Oracle Portal, it is automatically configured with a directory server. However, you may want to change some settings, such as whether to use SSL, after installation. To change to an SSL connection for the directory, simply run the secupoid.sql script in the PORTAL schema to specify the LDAPS port instead of the LDAP port, and indicate that you want to use SSL.

Running the secupoid.sql script

The section that follows shows a sample execution of secupoid.sql from SQL*Plus.

In the example, the directory was initially configured to run LDAP on port 389. Later, an LDAPS port was activated on 636. Because the server name does not change, we retain the old value, update the port, and indicate that we want to use SSL by setting the Use SSL? value to Y. When you run the script, it displays the current configuration and lets you replace any of the configurable settings. The script also enables you to update Oracle Portal's directory cache after running it. Because activating SSL does not change any of the directory information cached by Oracle Portal, it is not usually necessary to refresh the cache in this case.

SQL> @secupoid
Current Configuration
--------------------
OID Host: oid.domain.com
OID Port: 389
Application DN:
orclApplicationCommonName=PORTAL.040820.123756.096286000,cn=Portal,cn=Products,cn=OracleContext
Application Password: 3E8C2D1B87CB61011757239C5AA9B390
Use SSL? N

PL/SQL procedure successfully completed.

Updating OID Configuration Entries
Press [Enter] to retain the current value for each parameter
For SSL Connection to LDAP, specify "Y"es or "N"o
------------------------------------------------
Enter value for oid_host:
Enter value for oid_port: 636
Enter value for app_password:
Enter value for use_ssl_to_connect_to_ldap: Y
Enter value for refresh_with_new_settings: N

PL/SQL procedure successfully completed.

No errors.

After executing the script, Oracle Portal is configured for LDAPS access of the directory. Refer to Section B.3, "Using the secupoid.sql Script" for more information.

7.3.2.3.10 Change the Application Entity Password

Oracle Portal never passes a user's password to the directory. Only OracleAS Single Sign-On performs that task. However, Oracle Portal authenticates itself to the directory through its application entity and password.

If you want to change the application entity's password, you need to first change its entry in the directory, using command line utilities or the Oracle Directory Manager. To locate the application entry in the directory, you need its DN, which is reported by the secupoid.sql script. By default, Oracle Portal's application entry is:

orclApplicationCommonName=PORTAL.040820.123756.096286000,cn=Portal,cn=Products,cn=OracleContext

To change the password, you set the userPassword attribute for the application entry to the new password.

After you have changed the password in the directory, you run secupoid.sql script in the PORTAL schema and specify the new password there, too. Running the script enables Oracle Portal to encrypt the password and store it for retrieval when it needs to connect to the directory.

Refer to Section B.3, "Using the secupoid.sql Script" for more information about the secupoid.sql script.

See Also:

Section 7.1.7.3.1, "Directory Entries in Oracle Internet Directory for Oracle Portal", for more information about the application entity.

7.3.3 Configuring Oracle Portal Options for Database Security

Fine-grained access controls and secure application contexts add a new dimension to your ability to secure your data in the database.

Fine-grained access control is sometimes referred to as virtual private database or row level security. Fine-grained access control in the Oracle Database 11g is the ability to dynamically attach, at run time, a predicate (WHERE clause) to any and all queries issued against a database table or view. This feature gives you the ability to procedurally modify the query at run time. You may evaluate who is running the query, where they are running the query from, when they are running the query and develop a predicate given those circumstances. With the use of application contexts, you may securely add additional information to the environment (such as an application role the user may have) and access it in your procedure or predicate as well.

As an example of fine-grained access control, you might have a security policy that determines what rows different groups of people may see. Your security policy will develop a predicate based on who is logged in and what group they are in.

You will find additional information about fine-grained access and application contexts on Portal Center, http://portalcenter.oracle.com/.

Footnote Legend

Footnote 1: The default identity management realm name is determined by the domain name of the server on which the system is installed. For example, if the domain name server was oracle, the default identity management realm name would be dc=oracle,dc=com. If the domain name server cannot be determined, the default name assigned by the directory is dc=Default Company,dc=com

8 Monitoring and Administering Oracle Portal

This chapter provides information about the monitoring and administration tools that are available, and how to use them to successfully monitor and administer Oracle Portal.

You can monitor and administer Oracle Portal through Oracle Enterprise Manager 11g Fusion Middleware Control. Additionally, you can view Oracle Portal Analytics to monitor Oracle Portal performance and analyze Oracle Portal access characteristics.

You can also configure the Oracle Portal using WLST, see Section 5.1.2.2, "WebLogic ScriptingTool (WLST) Command-line Utility".

See Also:

For additional Oracle Portal monitoring and administration information, see the Oracle Portal Administration page on the Oracle Technology Network (OTN), at http://www.oracle.com/technology/products/ias/portal/index.html.

This chapter contains the following sections:

- Using Oracle Enterprise Manager 11g Fusion Middleware Control

- Using Fusion Middleware Control to Monitor and Administer Oracle Portal

- Viewing Oracle Portal Activity Reports

- Viewing Oracle Fusion Middleware Port Usage

- Defining Oracle Enterprise Manager Administration Roles

- About the Oracle Fusion Middleware System MBean Browser

8.1 Using Oracle Enterprise Manager 11g Fusion Middleware Control

Oracle Enterprise Manager 11g Fusion Middleware Control is included when you install Oracle Portal. From Oracle Portal's perspective, consider this to be the administration console for Oracle Portal. In the Oracle Enterprise Console you can:

- Administer clusters

- Start and stop services

- View logs and ports

- Perform real-time monitoring

Accessing Oracle Enterprise Manager 11g Fusion Middleware Control

You can access by navigating to the following URL: http://<hostname.domain>:<port>/em. For example, http://myhost.mycompany.com:7001/em.

Your start page for Fusion Middleware Control is the Farm home page. This page contains an Application Deployments page and a Fusion Middleware page indicating the status of the farm's system components. From these portlets, you can display the home page for each component of the Oracle Fusion Middleware for monitoring and administrative purposes.

If Oracle Portal is configured, it will appear in the Fusion Middleware portlet under Portal: portal (WLS_PORTAL).

See:

Oracle Fusion Middleware Administrator's Guide

8.2 Using Fusion Middleware Control to Monitor and Administer Oracle Portal

To monitor and administer Oracle Portal, in the Oracle Fusion Middleware home page under Portal, click on the portal J2EE application name. This also displays the WebLogic Container name besides the Portal application, which allows you to locate a specific portal application, running in a specific WebLogic container. The WLS_PORTAL is the container for portal servlets, and not the actual portal servlet to monitor.

Fusion Middleware Control displays a lot of useful metrics for Portal, when this metrics are displayed in tabular format, they allow sorting of metric rows in ascending or descending order and allowing you to find highest and lowest values easily.

8.2.1 Portal Home Page Overview

Figure 8-1 shows the Oracle Portal Home page, the main page for monitoring Oracle Portal, and from which you access Portal's configuration, logging, and metrics pages, and Portal components.

Figure 8-1 Oracle Fusion Middleware Control - Oracle Portal Home Page

The Oracle Portal home page, shown in Figure 8-1, displays various portlets which are described in the following sections:

- Page Response Time Portlet

- Page Response Codes Statistics Portlet

- Popular Producers Portlet

- Related Components Portlet

- Producers Portlet

- Resource Center Portlet

- Page Engine Statistics Portlet

8.2.1.1 Page Response Time Portlet

The Page Response Time portlet, as shown in Figure 8-2, shows a graphical representation of the average time in milliseconds that the Parallel Page Engine (PPE) takes to generate a page.

Figure 8-2 Page Response Time Portlet

8.2.1.2 Page Response Codes Statistics Portlet

The Page Response Codes Statistics Portlet, shown in Figure 8-3, provides statistics about HTTP response codes generated by Portal's PPE. Typically, HTTP-2xx and HTTP-3xx status codes mean successful responses.

Figure 8-3 Page Response Codes Statistics Portlet

8.2.1.3 Popular Producers Portlet

The Popular Producers portlet, as shown in Figure 8-4, provides a graphical view of the relative popularity of producers based on access counts.

Figure 8-4 Popular Producers Portlet

8.2.1.4 Related Components Portlet

The Related Component portlet lists the Oracle Fusion Middleware components used by Oracle Portal. You can drill down and find more information about individual Oracle Fusion Middleware components, by clicking on a link. The listed components are:

- Portal URL

- WebLogic Server

8.2.1.4.1 Portal URL

Clicking the Portal URL takes you to the Welcome page for the currently configured Oracle Portal.

8.2.1.4.2 WebLogic Server

Clicking the WebLogic Server (domain name) link, in the Related Components portlet, takes you to the Oracle WebLogic Server Domain home page for the WLS instance associated with the currently configured Oracle Portal. This is the starting point for managing and monitoring the WLS instance associated with the Oracle Portal. For example, you can restart the WLS instance from here. All configuration changes require a restart of the WebLogic Server running on Portal, and the WebLogic Server (domain name) link provides quick access to perform such an operation.

8.2.1.5 Producers Portlet

The Producers portlet, as shown in Figure 8-5, lists Portal producers, their status, and metrics. The status of Producers is shown to be Up when none of the portlets' last response codes indicated a failure. The status appears Down if the last response code for at least one portlet indicates a failure.

Metrics you can monitor include:

- Status - Indicates whether a specific producer's portlet is Up or Down.

- Availability - The percentage of requests that got an HTTP-2xx response from a producer.

- Invocations - The number of times a producer's portlet was invoked.

- Average - The average time (in milliseconds) to request a producer's portlet.

Figure 8-5 Producers Portlet

8.2.1.6 Resource Center Portlet

The resource Center portlet, as shown in Figure 8-6, provides links to general information about using Oracle Fusion Middleware Control to configure Oracle Portal, links to procedures for common administrative tasks, and links to other useful sites.

Figure 8-6 Resource Center Portlet

8.2.1.7 Page Engine Statistics Portlet

The Page Engine Statistics Portlet, shown in Figure 8-7, shows average response times, page access counts, page metadata metrics and Queue statistics for the PPE.

Figure 8-7 Page Engine Statistics Portlet

8.2.2 Administrating and Monitoring from the Oracle Home Page

From the Oracle Portal home page you can also start and stop Oracle Portal and the Portal's J2EE applications, and access Portal's configuration, log, and metrics pages:

8.2.2.1 Performance Metrics Page

Use the Performance Metrics page to display Oracle Portal metrics or other metrics for the Oracle Fusion Middleware Farm and Farm components. From the Portal home page's Portal menu, click Monitoring, and then Performance Metrics to display the Metrics page shown in Figure 8-8.

Figure 8-8 Oracle Fusion Middleware - Metrics Page

Overview of Metric Collection: Recent History and Since Startup

Performance metrics are automatically enabled for Oracle Portal. In other words, you do not need to set options or perform any extra configuration to collect performance metrics. If you encounter a problem, such as an application that is running slowly or is hanging, you can view particular metrics to find out more information about the problem. Fusion Middleware Control provides real-time data.

The following types of metrics are available for Oracle Portal:

- Since Startup: At any given time, real-time metrics are available for the duration for which the WebLogic Server hosting Portal applications was up and running. The real-time metrics that are collected or aggregated since the startup of the container are displayed for Portal as Since Startup. These metrics provide data aggregated over the life time of the WebLogic Server, and therefore, these are very useful.

Note:

Metric collection starts afresh after the Oracle Fusion Middleware components are restarted. Data collected prior to the restart is no longer available.

- Recent History: In addition to the Since Startup metrics, Oracle Portal metrics are also configured to capture the performance data every five minutes. This metric data is used in conjunction with the Since Startup metrics and is made available as Recent History metrics. All metrics seen under Recent History are calculated using just the recent metrics. For example, if a service was used for a short time, but it was not accessed at all for the last 15 minutes, then the Since Startup metrics for the service shows numbers greater than 0, whilst the Recent History metrics for that service are all zero. The Recent History metrics enable you to assess real-time performance of a live site based on data collected just from recent runtime access.
Typically, Recent History metrics shows data for the immediate last 10-15 minutes of data. However, there are scenarios when the data is not for the last 10-15 minutes:

- If the WebLogic Server has just been started up, and has been running for less than 10-15 minutes, then Recent History shows data for the duration for which the server has been up and running.

- Metric collection stops temporarily if no metric requests are detected over a long period of time. The collection restarts when the client next requests metrics. If metric collection has stopped, then Recent History initially shows data for the period since metric collection has stopped. As soon as the metric collection starts again, the data starts displaying.

While diagnosing a live site, navigate to the Portal metric pages and see the Services Summary section to identify services that are actively used and/or are taking longer than expected. Click the Refresh icon next to the time stamp to refresh metrics with live data. Then, click the particular service and repeat these steps to determine which specific operation in the service is taking long. If needed, navigate to application pages that use the service and set the application to trigger the runtime metrics to get more data.

The Metrics page is divided into the following five tabs:

- Page Metrics Tab

- Cache Metrics Tab

- Repository Metrics Tab

- Producer Metrics Tab

- Portlet Metrics Tab

For more information, refer to the Oracle Enterprise Manager 11g Online Help.

Page Metrics Tab

The Page Metrics tab (shown in Figure 8-8) gives the following information:

- Provides statistics on the percentage of HTTP Response Codes generated by the PPE.

- Page Engine Statistics like number of pages accessed, average page response time per milliseconds, process requests, since startup and recent history.

Cache Metrics Tab

The Cache Metrics tab (shown in Figure 8-9) contains portlets that display connection pool and Portal cache statistics.

Figure 8-9 Oracle Fusion Middleware - Cache Metrics Tab

Repository Metrics Tab

Repository Metrics tab (shown in Figure 8-10) shows metrics for the Portal database repository requests, such as repository response code statistics and database connection pool.

Figure 8-10 Oracle Fusion Middleware - Repository Metrics Tab

- Database Connection Pool: Shows the status of the database connection pool.

- The Repository Response Code Statistics portlet gives the following information:

- The type of type HTTP response code.

- The number of invocations in percentage and count, by the HTTP response code, since startup and last 15 minutes.

- A HTTP-2xx and HTTP-3xx status codes typically mean successful responses.

- A HTTP-499 is a special code which means that the requested resource is protected and you need a login access.

- A HTTP-470 means that a logout operation has been performed.

- The average time each HTTP response code takes to process requests, since startup and recent history.

- The maximum time taken to process HTTP requests.

Producer Metrics Tab

The Producer Metrics tab (shown in Figure 8-11) contains three portlets that display the most popular producers based on access counts, their response times and a table containing data for all the producers.

Figure 8-11 Oracle Fusion Middleware - Producer Metrics Tab

- The Most Popular Producers portlet gives the following information:

- The number of invocations per producer (displayed on a chart).

- The highest value on the chart indicates which portlet producer is used the most and the lowest value indicates which portlet producer is used the least.

- The Popular Producer Response Time gives the following information:

- The average time each portlet producer takes to process producer requests since the Portal application started up (displayed on a chart).

- The highest value on the chart indicates the worst performing portlet producer and the lowest value indicates which portlet producer is performing the best.

- The Producer Statistics portlet gives the following information:

- The name of the portlet producer being monitored:
Click the name of a portlet producer to view more information about each portlet that the application uses.

- The current status of each portlet producer:
Up (Green Up Arrow) indicates that the portlet producer is up and running and Down (Red Down Arrow) indicates that the portlet producer is currently unavailable. The producer instance might be down, or there could be some network connectivity issues.

- The percentage of producer invocations that succeeded, since startup and recent history.

- The number of invocations, for each producer, since startup and recent history.

- The percentage of cache hits, since startup and recent history.

- By sorting the Average Time (ms) table, you can find the most frequently accessed portlet producer in your Portal application and the average time each portlet producer takes to process producer requests, regardless of the result, since startup and recent history. Use this metric to detect non-performant portlet producers. If you use this metric in conjunction with the Invocations metric, then you can prioritize which producer to focus on.

- The maximum and minimum time taken to process producer requests.

Portlet Metrics Tab

The Portlet Metrics tab (shown in Figure 8-15) contains three portlets that display the most popular portlets based on access counts, portlet response times and other portlet metrics.

Figure 8-12 Oracle Fusion Middleware - Producer Metrics Tab

- The Most Popular Portlets portlet gives the following information:

- The number of invocations per portlet (displayed on a chart).
The highest value on the chart indicates which portlet is used the most and the lowest value indicates which portlet is used the least.

- The Popular Portlet Response Time gives the following information:

- The average time each portlet takes to process requests since the the Portal application started up (displayed on a chart).

- The lowest value on the chart indicates which portlet is performing the best.

- The highest value indicates the worst performing portlet.

- The Portlet Statistics portlet gives the following information:

- The current status of each portlet.
Up (Green Up Arrow) indicates that portlet is up and running and Down (Red Down Arrow) indicates that the portlet is currently unavailable. The producer instance might be down, or there could be some network connectivity issues.

- The name of the portlet being monitored.

- The name of the portlet producer through which the portlet is accessed.

- The portlet producer type: Web, or WSRP.
Web portlet producer - deployed to a J2EE application server, which is often remote and communicates through Simple Object Access Protocol (SOAP) over HTTP.

WSRP portlet producer - Web Services for Remote Portlets (WSRP) is a Web services standard that allows interoperability between a standards enabled container and any WSRP application.

- The percentage of producer invocations that succeeded, since startup and recent history. If Successful Invocations (%) is below 100%, check the diagnostic logs to establish why service requests are failing.

- The number of invocations, per producer, since startup and recent history.

- The percentage of cache hits, since startup and recent history.

- By sorting the Average Time (ms) table, you can find the most frequently accessed portlet in your Portal application and the average time each portlet takes to process requests, regardless of the result, since startup and last 15 minutes. Use this metric to detect non-preforming portlet. If you use this metric in conjunction with the Invocations metric, then you can prioritize which portlet to focus on.

- The maximum and minimum time taken to process portlet requests.

8.2.2.2 Performance Summary Page

Use the Performance Summary page to display metrics for Oracle Portal and Oracle Portal components. Oracle Fusion Middleware automatically and continuously measures run-time performance. The performance metrics are automatically enabled; you do not need to set options or perform any extra configuration to collect them.If you encounter a problem, such as an application that is running slowly or is hanging, you can view particular metrics to find out more information about the problem.

From the Portal home page's Portal menu, click Monitoring, and then Performance Summary to display the Performance Summary page shown in Figure 8-13.

Figure 8-13 Oracle Fusion Middleware - Performance Summary Page

From the Performance Summary page you can:

- Select the time range for which to view metrics using the options on the Time Range Selection bar.

- Set display options, such as metric thresholds, using the View options.

- View metrics in table format using the Table View option.

- Select the metrics to view using the Metric Palette.

Time Range Selection Options

The Time Range Selection Bar (shown in Figure 8-14) contains options for selecting the time range for which metrics are displayed.

Figure 8-14 Time Range Selection Bar

View Options

Use the View options to select metric thresholds for the selected metrics.

Overlay Option

Use the Overlay option to view metrics of another portal application.

Show Metric Palette Option

Use the Show Metric Palette option to display the Metric Palette (shown in Figure 8-15) from where you can select the metrics to view.

Figure 8-15 Metric Palette

8.2.2.3 Configure Database Access Descriptor Page

In Fusion Middleware Control, you can add, edit or delete the DAD (Database Access Descriptor) for an Oracle Portal instance. From the Portal home page's Portal menu, click Settings, and then Database Access Descriptor to display the Configure Database Access Descriptor page shown in Figure 8-16.

See Section 5.6.4, "Configuring a Portal DAD Using Fusion Middleware Control" for more information.

Figure 8-16 Oracle Fusion Middleware Control - Configure Database Access Descriptor Page

You can edit or view DAD settings from the Edit Database Access Descriptor page. From the Configure Database Access Descriptor page, select the DAD and click Edit to display the Edit Database Access Descriptor page shown in Figure 8-17. For information on adding and deleting a DAD, and for more information on editing a DAD, refer to Section 5.6.4, "Configuring a Portal DAD Using Fusion Middleware Control"

Note:

If you make any changes on the Edit DAD pages, you must restart Oracle HTTP Server and WLS_PORTAL.

Figure 8-17 Oracle Fusion Middleware Control - Edit Database Access Descriptor Page

In the Edit Database Access Descriptor page, you can modify the DAD settings detailed in Table 8-1, "DAD Settings":

Table 8-1 DAD Settings

Setting

Description

Database Access Descriptor Name or Location

Specify a path that points to the Portal DAD (for example, /pls/portal). The path must start with /pls, must not contain any special characters or spaces, and may not exceed 64 characters.

Note: When editing a Portal DAD, this field is read-only.

Portal Schema Name

Enter the schema name for the Portal instance.

Portal Schema Password

Enter the schema password for the Portal instance.

Tip: To obtain the schema password, refer to Section 5.6.10, "Retrieving the Portal Schema Password".

Use this field to set the password for a nondefault Oracle Portal instance.

For the default Oracle Portal instance, we recommend that you set the password, refer to Section 6.12, "Changing the Oracle Portal Schema Password" for more information.

Database Connect String

Enter the connection string (if the database is remote). If you are editing a Portal DAD, use the Connection String Format property below to specify the format of the connect string you have entered here.

Connection String Format

Specify the format used for the Database Connect String property. The options are:

- TnsNameFormat (TNS alias or the whole TNS entry)
Use this format when the connect string is resolved through tnsnames.ora or when the complete tnsnames.ora entry is specified in the mod_plsql configuration file. For example:

myhostdb.oracle.com

or

DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(Host=myhost.oracle.com)(Port=1521))(CONNECT_DATA=(SID=mydb)))"

- LdapServiceNameFormat
Use this format when the database connection details are defined in the LDAP directory. The LDAP connection details are contained in the file ldap.ora, located in the $ORACLE_HOME/ldap/admin directory

- NetServiceNameFormat (SQL*Net entry)
Use this format when the connect string is resolved by SQL*Net, For example, cn=oracle,cn=mydb for name resolution through LDAP, or mydb.oracle.com for name resolution through tnsnames.ora. Please refer to the SQL*Net documentation for a more detailed description of Net Service Names.

For database installations like Real Application Clusters, it is recommended that you configure the connect string using the NetServiceNameFormat such that the lookup is through LDAP. This allows database nodes to be for added and removed without having to re-configure each Oracle Fusion Middleware middle tier separately to recognize added or removed nodes.

Database NLS Language

Enter the NLS language of the Oracle Portal database represented by this DAD. This setting overrides the NLS_LANG environment variable for a database session and defines some important NLS properties of the response, including the response character set.

For Oracle Portal, this setting should match the NLS_LANG of the back-end database. For example, if you set this parameter is to JAPANESE_JAPAN.JA16SJIS, content is transferred from the database in the JA16SJIS character set.

Tip: To obtain the settings of this parameter, query the nls_database_parameters table as follows:

select value, parameter

from nls_database_parameters

where parameter in ('NLS_LANGUAGE', 'NLS_TERRITORY','NLS_CHARACTERSET');

Refer to the Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server, for more details on the mod_plsql parameter PlsqlNLSLanguage.

Request Validation Function

Specifies an application-defined PL/SQL function that can provide further processing of a requested procedure. This enables you to implement tight security for your PL/SQL application. For example, you can block package/procedure calls which must not be executed from this DAD.

Use the following format for the PL/SQL function:

boolean function_name (procedure_name IN varchar2)

On invocation, the procedure_name argument contains the name of the procedure that the request is trying to execute. For example, if all PL/SQL application procedures callable from a browser are inside the package mypkg, you could implement the following function:

boolean my_validation_check

(procedure_name varchar2)

is

begin

if (upper(procedure_name) like upper

('myschema.mypkg%')) then

return TRUE;

else

return FALSE;

end if;

end;

Use the following syntax to specify this property:

plsqlRequestValidationFunction <string>

For example:

PlsqlRequestValidationFunction myschema.mypkg.my_validation_check

Tips:

By default, mod_plsql restricts direct URL access to certain schemas/packages. For more information, see the Exclusion List property described below.

It is highly recommended that you provide an implementation for this function that only allows requests that belong to your application and are callable from a browser.

Since this function is called for every request, ensure that this function is as performant as possible. Here are some recommendations:

- Name your PL/SQL packages such that the implementation of this function is similar to that shown in the example above.

- If your implementation performs a table lookup to determine which packages/procedures are allowed, you can improve performance if you pin the cursor in the shared pool.

Exclusion List

Specify the procedures/packages/schema names which are forbidden to be directly executed from a browser. This is a comma separated list in which each string in the list is case insensitive and can accept wildcards. If this parameter is not specified, the default procedures are used. The default list is: sys.*, dbms_*, utl_*, owa_*, owa.*, htp.*, htf.*.

If this parameter is overridden, the defaults still apply. Therefore, you do not have to explicitly add the default list to the list of excluded patterns.

If you wish to have spaces in the pattern specified for PlsqlCGIExclusionList, enclose the exclusion list in double quotes.

Setting this directive to #NONE# disables all protection and poses a security risk. This setting is not recommended for a live site and is reserved for debugging purposes only.

Session Cookie Name

This parameter applies only to Oracle Portal installations that participate in a distributed environment. In most cases leave this field blank as this parameter automatically defaults to the DAD name.

Select Session State Management

Portal Default (StatelessWithResetPackageState)No value is set for the Session State Management property. The default setting assigned by mod_plsql is used.

CGI Environment List

Specify overriding and/or new CGI environment variables. This is a comma separated list of names and value pairs which can override existing environment variables listed below or add new ones. If no value is specified for the parameters below, the value is obtained from the Oracle HTTP Server:

- AUTHORIZATION

- DAD_NAME

- DOC_ACCESS_PATH

- DOCUMENT_TABLE

- HTTP_ACCEPT

- HTTP_ACCEPT_ENCODING

- HTTP_ACCEPT_CHARSET

- HTTP_ACCEPT_LANGUAGE

- HTTP_COOKIE

- HTTP_HOST

- HTTP_PRAGMA

- HTTP_REFERER

- HTTP_USER_AGENT

- PATH_ALIAS

- PATH_INFO

- REMOTE_ADDR

- REMOTE_HOST

- REMOTE_USER

- REQUEST_CHARSET

- REQUEST_IANA_CHARSET

- REQUEST_METHOD

- REQUEST_PROTOCOL

- SCRIPT_NAME

- SCRIPT_PREFIX

- SERVER_NAME

- SERVER_PORT

- SERVER_PROTOCOL

Error Style

Specify whether error messages are displayed on pages generated by mod_plsql or the Oracle HTTP Server. Specify this parameter at the DAD level or at the global level by manually editing the file dads.conf.

ApacheStyle (default) - mod_plsql indicates to the Oracle HTTP Server which HTTP errors are encountered and the Oracle HTTP Server generates the error page. This can be used in conjunction with the Oracle HTTP Server Error Document directive to produce customized error messages.

modplsqlStyle - error pages are generated by mod_plsql. Typically, the error page contains a short message indicating the PL/SQL error encountered, for example, scott.foo PROCEDURE NOT FOUND.

DebugStyle - error pages are generated by mod_plsql and they contain additional information such as the URL, parameters, and server configuration information.

This mode is for debugging purposes only. Do not use this option in a production system since displaying internal server variables is a security risk.

Note: If the PL/SQL application generates its own error page, this option is ignored.

Document Table

Enter the name of the database table where files uploaded through a Web browser are stored.

Use the format: <Schema>.wwdoc_document

Document Path

Enter a path in the URL installation to indicate a document is being referenced. In the following URL, docs (which is the default value) is the Document Path.

http://myapp.myserver.com:2000/pls/my_site/docs/folder1/presentation

Path Aliasing

Used by PL/SQL applications for Direct Access URLs. The default is url. Everything after the keyword url is sent to the invoked procedure.

Path Alias Procedure

Used by PL/SQL applications for Direct Access URLs.

Always Describe Procedures

Specify On or Off. mod_plsql must know the data type of the parameters being passed in. Based on the data type, mod_plsql binds each parameter as an array or as a scalar. This can be done two ways:

Off - Default for mod_plsql. If this option is chosen, mod_plsql uses the following heuristics:

- If there is a single value being passed, then the parameter is a scalar. Otherwise, it is an array

Note: If someone tries to pass a single value for an array parameter, it fails. A Describe call is then made, requiring two database trips (one for the failed execute and the other for the Describe call).

On - One way to know the data type is to describe the procedures before executing it. This approach can be inefficient since every procedure has to be described before execution

Before Procedure

A user-defined procedure is called before invoking the target procedure. Use this option to generate headers or start enabling SQL traces.

After Procedure

A user-defined procedure is called after invoking the target procedure. Use this option to generate footers or stop SQL traces.

Fetch Buffer Size (rows)

Specify how many rows of PL/SQL response data mod_plsql fetches in each round trip to the database. The default is 200 rows.

8.2.2.4 Portal Cache Configuration Page

In Oracle Fusion Middleware Control, you can specify the Oracle Web Cache settings that Oracle Portal should use. From the Oracle Portal home page's Portal menu, select Settings, and then Portal Cache to display the Portal Cache Configuration page shown in Figure 8-18.

Figure 8-18 Fusion Middleware Control - Portal Web Cache Settings

In the Portal Web Cache Settings page, you can modify the settings detailed in Table 8-2:

Table 8-2 Portal Cache Settings

Setting

Description

Caching

Enables (On) or disables (Off) portal content and session caching.

Cache Directory

The directory path to where cached content is stored.

Note: Ensure that this directory exists and that it is accessible (read/write access required).

Total Cache Size

The total amount of disk space (in megabytes) that the portal cache can use. The maximum value allowed is 4 GB.

Note: This setting is not a hard limit. The cache may exceed this limit temporarily.

Maximum Cache File Size

The maximum size (in bytes) for all cached files. The maximum value allowed is 4 GB.

Any dynamically generated content that exceeds this limit is not cached.

Caching Schedule

The time at which to start the cleanup of the cache storage. Use the format: [Every Sunday - Every Saturday, Every Day, Every Month][hh:mm] to define the exact day and time at which cleanup should occur.

The frequency can be set as daily, weekly, and monthly. The default is Every Day 23:00. An infrequent cleanup improves performance but total cache size may be exceeded. A frequent cleanup decreases performance, but total cache size is not exceeded.

- To define daily frequency, select Every Day. A cleanup will start every day at the time defined. For example:
Every Day 2:00

Cleans up the cache every day at 2 am (local time).

- To define a weekly frequency, enter the day of the week [Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday]. For example:
Every Wednesday 15:30

Cleans up the cache every Wednesday at 3:30 pm (local time).

- To define monthly frequency, select Every Month. The cleanup starts on the first Saturday of the month at the time defined. For example:
Every Month 23:00

Cleans up the cache on the first Saturday of every month at 11:00 pm (local time).

Maximum Age for Cache Files(days)

The maximum age for cached files. This setting ensures the cache system does not contain any old content. Old cache files are removed to make space for new cache files. The default is 30 days.

Note: This setting only affects items in the Portal content cache. Session cookie cache items are cleaned if they are in the cache for more than 1 day.

Refer to Section 5.6.6, "Configuring the Portal Cache Using Fusion Middleware Control" for more information on how to configure the Portal Cache.

8.2.2.5 Page Engine Configuration Page

Use the Configure Page Engine page to analyze the performance of the Parallel Page Engine (PPE) that Oracle Portal is using. From the Oracle Portal home page's Portal menu, select Settings, and then Page Engine to display the Page Engine Configuration page shown in Figure 8-18.

Figure 8-19 Oracle Fusion Middleware Control - Portal Parallel Page Engine Settings

In the Portal Parallel Page Engine Settings page, you can modify the settings detailed in Table 8-3:

Table 8-3 Portal Parallel Page Engine Settings

Setting

Description

Proxy Host

This is the host name of a proxy server that may be required to request data from the Oracle Fusion Middleware. These parameters are only required if a proxy server is in use between PPE and the Oracle Fusion Middleware listener.

Proxy Port

This is the port number of the proxy server specified by Proxy Host.

Proxy User

This is the user of the proxy server specified by Proxy Host.

Proxy Password

This is the password of the proxy server specified by Proxy Host.

Cache Encryption Key

This key is used to obscure the headers used for caching using Oracle Web Cache. This allows for a more secure cache key, and makes retrieving a cached object more difficult for unwanted requests.

This key is not used if you are running 11g Release 1 (11.1.1) of the Portal repository or later, and is provided only for backward compatibility when you use an 11.1.1 middle tier with an earlier release of the Portal repository.

Resource URL Key

This key is used by the PPE to calculate checksums for URLs that are requested by WSRP and JPDK resource proxying.

For WSRP resource proxying to work, the key must be set to an alpha-numeric value of 10 characters or more.

In addition, for JPDK proxying, a JNDI environment variable called resourceUrlKey must be set for the provider.

Use Port

Overrides the port used when the PPE makes requests to the Portal. The default, if not specified, is to always use the page request port.

Note: You must set the Use Scheme and Use Port parameters.

You need to specify these in scenarios where public access is through https on port A, and you want to set PPE requests to use a faster http connection on port B.

Use Scheme

Overrides the scheme (HTTP or https) used when the PPE makes requests to the Portal. The default, if not specified, is to always use the page request scheme.

Note: You must set the Use Scheme and Use Port parameters.

You need to specify these in scenarios where public access is through https on port A, and you want to set PPE requests to use a faster http connection on port B.

509 Certification file

Specifies a file containing a list of certificates to be implicitly trusted by HTTPClient. These certificates are added as trust points to all connections made by HTTPClient using SSL. Once this setting is in use, all SSL connections must be trusted. Otherwise, HTTPClient will throw an exception in the PPE.

SSL connections are made from the PPE for two reasons and this configuration affects both:

- loopback requests to the portal, for example, for PMD.

- show calls to Providers.

Note: The file specified here can be obtained from a wallet by exporting all trusted certificates, but the comments in the resultant file must be removed. Alternatively, it can be created manually.

Refer to Section 5.6.9, "Configuring the Portal Parallel Page Engine" for more information on how to configure the Parallel Page Engine.

8.2.2.6 Portal Wire Configuration Page

Use the Portal Wire Configuration page to configure Portal Midtier and to configure Web Cache and Oracle Internet Directory (OID) for a database access descriptor. From the Oracle Portal home page's Portal menu, select Settings, and then Wire Configuration to display the Portal Wire Configuration page shown in Figure 8-18.

The page is arranged in the following sections:

- Select Database Descriptor

- Portal Midtier

- WebCache

- OID

Select Database Descriptor

This field specifies the database access descriptor to be configured.

Portal Midtier

Element

Description

Host

Specifies the <hostname> of the Portal URL. In the High Availability context, this host name is the host name of the load balancer. In standalone setups, this host name is the host name of Web Cache. If you access a Portal from a browser using the url https://www.myportal.com:4443 then the Host value will be www.myportal.com.

Port

Specifies the <port> of the Portal URL. It is the listen port of the load balancer host name in HA setups. In standalone setups, this port is the listen port of Web Cache. If you access a Portal from a browser using the url https://www.myportal.com:4443 then the Port value will be 4443.

SSL Protocol

Specifies the protocol of the Portal URL. It can be either HTTP (non-SSL) or HTTPS (SSL). If you access a Portal from a browser using the url https://www.myportal.com:4443 then the SSL Protocol will be enabled.

WebCache

Element

Description

Host

Specifies the host name to be used by Portal for contacting Web Cache. By default, it matches the Portal middle tier host property, and this default value is used in most configurations.

Invalidation Port

Specifies the port number to be used by Portal for contacting Web Cache to perform invalidations. In non-High Availability environments, this property is configured to match the Oracle Web Cache invalidation port. In High Availability environments, this property is mapped to a port on an LBR which acts as a load balancing traffic across the individual invalidation ports.

Invalidation User

Specifies the invalidation user name. See Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache for more information.

Invalidation password

Specifies the invalidation password, this is the invalidation password to be used by Portal for invalidating content in Web Cache. This password must match the password in Web Cache. If it does not match the Portal becomes unusable.

When you set Oracle Web Cache properties on this page, the Oracle Portal schema is updated.

Notes:

- When you change Oracle Web Cache properties in the Portal Web Cache Settings page, it impacts the property cached with Portal. Navigate to the Web Cache Administration page, in Fusion Middleware Control, to make the appropriate changes to Web Cache. Refer to the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache for more information about Oracle Web Cache.

- Changing Oracle Web Cache settings can impact Web Providers (such as OmniPortlet and Web Clipping) if the Oracle Web Cache and the Web Provider are running on the same middle tier. In this case, you must make corresponding cache configuration changes for the Web Providers. See "Defining the Oracle Web Cache Invalidation Port" in the Oracle Fusion Middleware Developer's Guide for Oracle Portal.

OID

Element

Description

Host

Specifies the host name of the OID server.

Port

Specifies the OID port number.

User

Specifies the OID user name.

Password

Specifies the OID password.

Protocol

Specifies the protocol to be used. Select this check box to use the HTTPS protocol.

Note:

After completing the Oracle Portal wire configuration, you must refresh the cache content.

8.2.2.7 Logs

Log Message Page

Use the Log Messages page to view detailed diagnostic information for that Oracle Portal instance. From the Portal home page's Portal menu, click Log, and then View Log Messages to display the Log Messages page shown in Figure 8-20. For more information, refer to the Enterprise Manager Online Help.

Figure 8-20 Oracle Fusion Middleware Control - Log Messages Page

See Appendix G, "Troubleshooting Oracle Portal" for more information.

Logs Configuration Page

In Fusion Middleware Control, you can specify the log settings that Oracle Portal should use. From the Oracle Portal home page's Portal menu, select Logs, and then Log Configuration to display the Log Configuration page shown in Figure 8-21.

Figure 8-21 Log Configuration Page

See Also:

Oracle Fusion Middleware Administrator's Guide

8.2.3 Topology Tab

A Topology tab is displayed at the top of every Fusion Middleware component home page. Click the Topology link to display a graphical representation of your Oracle Fusion Middleware environment, including the Oracle Fusion Middleware processes that are running Oracle Portal instances, such as, Web Cache, WLS_Portal and HTTP Server.

See Also:

Oracle Fusion Middleware Administrator's Guide

8.3 Viewing Oracle Portal Activity Reports

You can choose how objects and actions are logged in Oracle Portal and generate reports for analyzing the data. For example, you can add an entry into the Activity Log tables every time Oracle Portal users create, edit or delete a particular page.

Any authorized user can view the Oracle Portal Log Registry records. However, only the portal administrator can set up what information is to be logged. See Section 8.3.2, "Choosing Which Events Are Logged" for more information.

Note:

With the introduction of Oracle Web Cache into the Oracle Portal architecture, some actions logged in Oracle Portal Activity Log tables have become inaccurate. These actions include View, Execute (for Reports, Charts, and Hierarchies), and Show. The Activity Log tables and views still remain in the Oracle Metadata Repository, as all other logged actions remain accurate.

8.3.1 Logged Events

Table 8-4 lists the events that can be logged for portal objects.

Table 8-4 Logged Events for Oracle Portal Objects

Portal Object

Event

Pages

Create, Edit, Delete, Personalize

Items

Create, Edit, Delete, Move, Check Out, Check In

Application Components

Create, Edit, Delete, Execute (except for Reports, Charts, and Hierarchies), Copy, Export, Rename, Generate, Access Control, Manage, Insert, Update, Save

Portlets

Add to Page, Delete from Page

Portlet Instances

Hide, Personalize

Searches

Search

Note:

User and Group actions such as Create, Edit, and Delete are logged by Oracle Internet Directory and may be viewed from Oracle Directory Manager, if logging is enabled. For more information, refer to theOracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

8.3.2 Choosing Which Events Are Logged

You can choose which events are logged in Oracle Portal Log Registry records.

1. In the Services portlet, click Log Registry Administration.

Note:

By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

The Administer Log Registry page is displayed as shown in Figure 8-22.

Figure 8-22 Administer Log Registry Page

Figure 8-22 shows two logging requests. The first creates an entry in the Activity Log every time a portlet is personalized. The second creates an entry every time a page is created. If you want to log all possible requests, choose % for each field.

2. Do one of the following:
Click Add New Log Registry Record to create a new Log Registry record and specify logging criteria.

Or,

Edit logging criteria for an existing Log Registry record. To do this, perform the following steps:

1. Click the Edit icon to edit logging criteria for an existing Log Registry record (under Edit/Delete Log Registry Record).
The Edit Log Registry Record page is displayed as shown in Figure 8-23.

Figure 8-23 Edit Log Registry Record page

2. Choose the objects that you wish to log, from the Sub Domain list. Valid objects are listed in Table 8-4.

3. Choose which actions (or events) you want to log, from the Action list. Valid actions are listed in Table 8-4.

4. Specify other logging criteria as required.

5. Click OK.

8.3.3 Activity Log Views

Several Activity Log views are available (named wwlog_*). These views exist in the schema in which Oracle Portal is installed. These views are granted to public; however, the logs are secure according to the object's security. For example, information about pages is available only on pages for which the user has access privileges.

Table 8-5 lists all the Activity Log views and their descriptions. You can create simple Oracle Portal DB Provider reports and charts based on these views if required.

Table 8-5 Activity Log Views

Log View

Description

wwlog_portal_admin_logs

All logs (only has records if the user is the portal administrator).

wwlog_user_logs

All logs created by current user.

wwlog_all_portlet_logs

Portlet instances on pages that the current user can view.

wwlog_all_document_logs

Documents that the current user can view.

wwlog_all_search_logs

Searches that the current user can view.

wwlog_all_item_logs

Items that the current user can view.

wwlog_all_component_logs

Components that the current user can view.

wwlog_all_object_logs

Summary view, which encompasses all the preceding views.

8.3.4 Accessing Activity Log Views Externally

You can also access information in the Activity Log views from outside of the Oracle Portal browser-based interface, that is, using SQL*Plus, Oracle Reports Services, and so on. To do this, you must first set the portal security context for your database session using the wwctx_api.set_context API:

wwctx_api.set_context (
p_user_name => 'portal_username',
p_password  => 'portal_pw'
);

8.4 Viewing Oracle Fusion Middleware Port Usage

In Oracle Fusion Middleware Control, the Ports Usage page shows a list of all the ports currently in use by the components of a particular Oracle Fusion Middleware instance. This page is important when you are troubleshooting port conflicts among the various Oracle Fusion Middleware components.

Whenever possible, Oracle Fusion Middleware Control provides a link to the appropriate Oracle Enterprise Manager 11g configuration page where you can modify the port settings for the component.

To access port usage information for your Oracle Fusion Middleware:

1. From the navigation pane, expand the farm and then WebLogic Domain.

2. Select the domain.

3. From the WebLogic Domain menu, choose Port Usage.
The Port Usage page is displayed, as shown in Figure 8-24.

Figure 8-24 Oracle Fusion Middleware Ports Page

For information on managing ports, refer to the Oracle Fusion Middleware Administrator's Guide.

8.5 Defining Oracle Enterprise Manager Administration Roles

In 11g Release 1 (11.1.1), Oracle Enterprise Manager supports three kinds of administration roles: Administrator, Operator and Monitor. An Administrator role has full privilege for performing any operations, including security-related operations. Whereas, an Operator has a few privileges and the monitor has a limited set of privileges. If a user doesn't have permission, the functionality is either invisible or greyed out. The following table describes the privileges:

Action

Administrator

Operator

Monitor

Start Up and Shut Down

Yes

Yes

No

View Metrics

Yes

Yes

Yes

View Log Messages

Yes

Yes

Yes

Log Configuration

Yes

No

No

Cache Settings Configuration

Yes

Permission to view only

Permission to view only

PPE Configuration

Yes

Permission to view only

Permission to view only

Portal Wiring Configuration

Yes

Permission to view only

Permission to view only

DAD Configuration Table

Yes

Permission to view only

Permission to view only

DAD Configuration : Add Action

Yes

No

No

DAD Configuration : Edit Action

Yes

No

No

DAD Configuration : Delete Action

Yes

No

No

8.6 About the Oracle Fusion Middleware System MBean Browser

The Oracle Fusion Middleware System MBean Browser is a part of Oracle Fusion Middleware Control, and it is used to update configuration settings for middle tier components. A managed bean (MBean) is a Java object that represents a JMX manageable resource in a distributed environment, such as an application, a service, a component or a device. MBeans are defined in the Java EE Management Specification (JSR-77), which is part of Java Management Extensions, or JMX, a set of specifications that allow standard interfaces to be created for managing applications in a Java EE environment.

This section contains the following topics:

- When should I use the Oracle Fusion Middleware System MBean Browser?

- About Portal Configuration MBeans

8.6.1 When should I use the Oracle Fusion Middleware System MBean Browser?

You use the System MBean Browser to enter or modify Oracle Portal configuration settings that are not available in Fusion Middleware Control Oracle Portal pages.

Note:

You should not use the System MBean Browser unless you are an advanced middle tier administrator.

8.6.2 About Portal Configuration MBeans

Configuration MBeans are defined for each of the Oracle Portal configuration files. Table 8-6 lists the configuration MBeans for Oracle Portal.

Table 8-6 Portal Configuration MBeans

Configuration Mbean

Associated Configuration File

Portal DAD MBean (Config)

portal_dads.conf

Portal Cache MBean (Config)

portal_cache.conf

Portal plsql MBean (Config)

portal_plsql.conf

Portal Midtier MBean (Config)

appConfig.xml

Portal Wiring MBean (Runtime)

No associated configuration file.

Note:

All Portal environment variables that are set in the registry are not exposed using MBeans. However, if they are specified in the server configuration file ENVID, the environment variables are exposed by PortalServerConfigMXBean.

9 Configuring Intranet and Internet for Oracle Portal

This document explains how to configure a dedicated intranet and internet for Oracle Portal and upgrading Intranet-Internet setup from Oracle Portal 10g to Oracle Portal 11g. This document contains the following topics:

Configuring a Dedicated Intranet and Internet for Oracle Portal

Upgrading Oracle Portal 10g Intranet-Internet setup to 11g

9.1 Configuring a Dedicated Intranet and Internet for Oracle Portal

You can configure Oracle Portal to be accessible from within a company network as well as from external clients. This section describes some important characteristics of this configuration, and provides instructions on how to configure Oracle Portal for this purpose.

The intranet-internet configuration for Oracle Portal requires two logical middle tiers: portal.mycompany.com and internal.mycompany.com, each residing on a different host. This separation of physical middle-tiers helps isolate the content cached for internet and intranet users. This enhances security, and also ensures that users who navigate to one logical middle tier do not access content served by the other logical middle tier. Each logical middle tier then provides access to the same Oracle Portal schema in the Oracle Application Server Metadata Repository and the same Oracle Portal data. In this configuration, the external logical middle tier is the primary middle tier used to install, configure, and expose web providers. The internal logical middle tier is designated as a partner application.

The intranet-internet configuration requires that all Oracle Web Cache instances be configured as an invalidation-only cluster. Invalidation-only clustering ensures that Oracle Web Cache maintains distinct caches for the two logical sites, while enabling the cluster members to share invalidation messages (thereby ensuring that content edits are visible across the two logical sites).

In this configuration, invalidation messages are sent from the Oracle Portal schema in the OracleAS Metadata Repository to the internal Oracle Web Cache instance, and the invalidation message is then sent out to all the cluster members. The invalidation message used in this configuration ensures that it invalidates content regardless of the host and port specified in the cached URL. This type of invalidation ensures that content cached with either logical middle-tier URL is invalidated. For more information on the Oracle Web Cache invalidation-only cluster, refer to the Oracle Application Server Portal Configuration Guide.

To ensure that the internal and external user communities are distinct, two URLs are used to access the Oracle Portal applications: from the intranet, http://internal.mycompany.com; from the Internet, https://portal.mycompany.com.

The process of configuring the dedicated intranet and extranet for Oracle Portal consists of the following tasks:

1. Installing and Configuring the External Middle tier

2. Installing the First Internal Middle Tier on APPHOST3

3. Configuring an Oracle Web Cache Invalidation-only Cluster

4. Configuring the First internal Middle Tier on APPHOST3 for Load Balancing Router

5. Registering the Internal Middle Tier as a Partner Application

6. Changing Host Assertion in WebLogic

7. Installing the Second Internal Middle Tier on APPHOST4

8. Configuring an Oracle Web Cache Invalidation-only Cluster

9. Configuring the Second Internal Middle Tier on APPHOST4 for Load Balancing Router

10. Configure Web Cache

11. Configuring the Oracle Portal Schema in the Oracle Metadata Repository

12. Validating the Completed Configuration

9.1.1 Installing and Configuring the External Middle tier

To install and configure the external middle tier, perform the steps in the following sections in Oracle Portal Enterprise Deployment Guide:11.1.1.2:

- Install application tier on APPHOST1

- Configure APPHOST1

9.1.2 Installing the First Internal Middle Tier on APPHOST3

Follow these steps to install the first internal middle tier:

1. Copy the staticport.ini file from the Disk1/stage/Response directory to a local directory, such as TMP.

2. Edit the staticport.ini file to assign the following custom ports:

Oracle HTTP Server port = 7777
Oracle HTTP Server Listen port = 7778
Web Cache HTTP Listen port = 7777
Web Cache Administration port = 9400
Web Cache Invalidation port = 9401
Web Cache Statistics port = 9402
Application Server Control port = 1810

3. Before installing the first middle tier on APPHOST3, you must change the repository version in the portal schema from 11.1.1.4 to 11.1.1.1.0. This can be achieved by performing the following steps:

1. Query the Portal version by connecting to the database as portal schema as shown in the following example:

>sqlplus portal/portaldb_portal@portaldb
sql> select version from wwc_version$;
sql> 11.1.1.4.0

Note and remember this Portal repository version.

2. Change the Portal repository version to 11.1.1.1.0 as shown in the following example:

sql> update wwc_version$ set version = '11.1.1.1.0';
sql> commit;
sql> select * from wwc_version$;
sql> 11.1.1.1.0

This step is mandatory. If this step is not performed, the newly installed middle tier on APPHOST3 overwrites the configuration maintained in the portal schema with the details of the newly installed middle tier. This affects the external portal middle tier. Temporarily downgrading the Portal schema version ensures that the configuration maintained in the Portal schema is left untouched. Later, the portal version must be restored to its original version. Downgrading the portal repository is required only when you are creating a new domain.

Install Weblogic Server

1. Start the Oracle Universal Installer.
To start the installer on Unix, issue the server103_linux32.bin command.

To start the installer on Windows, issue the server103_win32.exe command.

The Welcome screen appears Click Next.

2. Choose a Middleware Home Directory.
Enter a value for the Middleware Home as shown in the following example:

/u01/app/oracle/product/FMW

Henceforth, this will be known as MW_HOME. Click Next.

3. On the next screen, you will be prompted to register for security updates.
Choose whether or not to receive security updates from Oracle Support. Click Next.

4. Select Typical install type in the Choose Install Type screen.
Click Next.

5. Provide the path where you want to install the product in the Choose Product Installation Directories screen. Click Next.

6. Weblogic server will now be installed at the specified location. The Installation Summary screen appears. Click Done to complete the Installation.

Install Oracle Portal

1. Run following command to install Oracle Portal binaries into the MW_HOME created in the above steps:
On UNIX: runInstaller

On WIndows: setup.exe

2. The Welcome screen appears. Click Next.

3. The Installation Type screen appears. Select Install Software and Configure, and click Next.
The Prerequisite Checks screen appears.

4. Ensure that all checks have passed and click Next.
The Specify Installation Location screen appears.

5. Enter the following values:

- Middleware Home (MW_HOME)
For example, /u01/1pp/oracle/product/FMW

- Oracle Home
Enter the installation directory for Portal. This will be placed under the MW_HOME directory.

For example, Portal

- Weblogic Server Directory
Enter the installation directory for Oracle Weblogic server. This should be MW_HOME/wlserver_10.3.

For example, /u01/app/oracle/product/FMW/wlserver_10.3

- Oracle Instance Location
Enter the directory where the Oracle Configuration files will be placed. This should be outside of Oracle Home. Henceforth, this will be known as ORACLE_INSTANCE.

For example, /u01/app/oracle/admin/PortalDomain/Portal1

- Oracle Instance Name.
In this case, Portal1

Click Next. The Select Domain screen appears.

6. Select Create New Domain. Enter the values for User Name, User Password, and Domain Name.
Click Next. The Configure Components screen appears.

7. Ensure that the following values are checked:

- Server Components - Oracle Portal

- Management Components - Enterprise Manager

- Clustered box
Click Next. The Configure Ports screen appears.

8. Select Specify Ports using Configuration File.
Select a file name and click View or Edit. You can find a sample statisticports.ini file on installation Disk1 in the stage/repsonse directory.

Save the file and click Next.

9. In the Specify Schema screen, specify the following values:

- Databse Connect String
For example,

db_hostname:port:servicename

- Portal Schema Name: MYP_PORTAL

- Portal Schema Password
Enter password entered in RCU

Click Next. The Specify Portlet Schema screen appears.

10. Specify the following portlet schema credentials:

- Portlet Schema Name: MYP_PORTLET

- Portlet Schema Password: Enter the password that was entered in RCU

Click Next. The Specify Application Identity Store screen appears.

11. Specify the following values:

- Hostname
Enter the name of OID server.

- Port
Enter OID port: 389

- User Name
Enter cn=orcladmin

- Password
Enter the orcladmin OID password.

Click Next. The Summary screen appears.

12. Click Install to begin the installation process.

Note:

For UNIX installations, run the oracleRoot.sh script when prompted.

9.1.3 Configuring an Oracle Web Cache Invalidation-only Cluster

You must configure an Oracle Web Cache invalidation-only cluster that includes the Oracle Web Cache instances from both the internal and external computers. In this cluster configuration, invalidation requests are propagated across all cache cluster members. However, the Oracle Web Cache invalidation-only cluster does not forward other requests between the cluster members. While processing user requests, each cluster member acts as an individual cache and does not request objects from peer cluster members.

This configuration can be used to simplify the administration of many caches, especially in a cluster whose members are separated by a firewall. For example, a cluster can have two caches located on either side of a firewall that separates the intranet from the internet.

9.1.3.1 Preparing the Network Environment for the Oracle Web Cache Invalidation-only Cluster

Before configuring the Oracle Web Cache invalidation-only cluster between the external and internal Oracle Web Cache instances, perform the following checks:

1. Ensure that all external Oracle Web Cache instances can resolve and contact all internal Oracle Web Cache instances and vice versa. This can be done using the ping network command.

2. Ensure that the invalidation port (9401) is open in the firewall only in one direction. It must be open from the internal Oracle Web Cache instance to the external Oracle Web Cache instance.

3. Ensure that the administration port (9400) is open in the firewall in both directions.

Note:

After the configuration is complete, the administration port (9400) should be closed to traffic from the external middle tiers to the internal middle tiers.

4. Ensure that you can use telnet to send network packets from the internal to the external Oracle Web Cache ports.

9.1.3.2 Configuring the Caches

This section explains how to manage the caches as a cluster and segregate cache content, using the Oracle Web Cache Manager on APPHOST1 to configure settings for a cache cluster.

1. In the navigator frame, select Properties > Clustering.
The Clustering page appears. The General Cluster Information section displays the default clusterwide values for failover and invalidation propagation. The Cluster Members table displays the external middle tier cache.

2. In the General Cluster Information section of the Clustering page, click Edit.
The Edit General Cluster Information dialog box appears.

3. In the Propagate Invalidation field, select Yes to indicate that you want invalidation requests from cache cluster members to be propagated to other cache cluster members.

4. Click Submit.

5. In the Cluster Members table of the Clustering page, default values are displayed for the current cache. Select the APPHOST1 cluster member and click Edit Selected.
The Edit Cluster Member dialog box appears.

6. In the Capacity field, enter 0.

Note:

If you assign a capacity of 0 to all cluster members, no requests will be forwarded between cluster members. With this setup, you can propagate the configuration and invalidation across all cache cluster members, simplifying the administration of many caches.

7. Click Submit.

Before you can add APPHOST3 to the cluster, the following conditions must be in effect:

- The cache must be started.

- The administrator password of the cache to be added must be the same as the administrator password of the cache on APPHOST1. If it is different, you must connect to the cache's admin server and modify the administration password. For more information, refer to "Task 2: Modify Security Settings" in Chapter 8, "Setup and Configuration" in Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

9.1.3.2.1 Adding Caches to the Invalidation-Only Cluster

You must now add the APPHOST3 cache to the cluster using Oracle Web Cache Manager on APPHOST1.

To add a cache to the cluster in OracleAS Web Cache Manager:

1. In the navigator frame, select Properties > Clustering.
The Clustering page appears.

2. In the Cluster Members section of the Clustering page, click Add.
The Add Cache to Cluster dialog box appears.

3. In the Host Name field, enter apphost3.us.oracle.com as the host name of the cache to be added to the cluster.

4. In the Admin Port field, enter the web cache administration port (9400) for the cache to be added to the cluster.

5. In the Protocol for Admin Port field, select either HTTP to accept HTTP browser requests.

6. In the Cache Name field, enter apphost3.us.oracle.com-webcache.

7. Click Submit.
The cache is now part of the cluster and is listed in the Cluster Members table.

8. Repeat Steps 2 through 7, substituting apphost4 in the Host Name and Cache Name fields.

9. Click Apply Changes.
OracleAS Web Cache adds the cache-specific information from the new cache cluster members to the cluster configuration.

10. For each cluster member, set the Capacity to 0. To do this, select Properties, then Clustering. Select a cluster member and click Edit. In the Edit Cluster Member dialog box, set the Capacity to 0.

11. Propagate the configuration to all cluster members.
When you modify the cluster and apply changes, OracleAS Web Cache adds the cache-specific information from the new cache cluster members to the configuration. For those changes to take affect in all cluster members, you must propagate the configuration and restart the cache server process of the cluster members.

To propagate the configuration to new cluster members in Oracle Web Cache Manager:

1. In the navigator frame, select Operations > Cache Operations.
The Cache Operations page appears. The Operation Needed column indicates the caches to which the configuration should be propagated.

2. Propagate the configuration to all cache cluster members:

- Select All caches in the Operate On field.

- Select an Interval of Immediate. (No other interval is allowed for propagation.)

- Click Propagate.

When the operation completes, the Operation Needed column in the Cache Operations page indicates the cluster members that need to be restarted.

3. Stop and restart all cluster members:

- Select All caches in the Operate On field.

- Select an Interval to stagger the time that operation begins on the caches, and then click Restart.
When the operation completes, the Operation Needed column in the Cache Operations page indicates that no operations are needed. The cache cluster is ready to use.

12. Ensure that the administration and invalidation ports are closed to traffic coming from outside the network.

9.1.3.3 Disabling External to Internal Communication Through the Firewall

To disable external to internal communication through the firewall, perform the following steps:

1. Disable the administration port from external middle tier to internal middle tier.

2. Ensure that the network packets cannot be sent from the external to the internal Oracle Web Cache administration and invalidation ports, using telnet.

3. Ensure that network packets can be sent from the internal to the external Oracle Web Cache for both the administration and invalidation ports.
The communication paths and ports should now be as listed in Table 9-1:

Table 9-1 Communication Path and Ports Used by Network Packets

Communication Path

Ports to be enabled

Internal WebCache 1 to External WebCache 1

Port 9400 and Port 9401

Internal WebCache 1 to External WebCache 2

Port 9400 and Port 9401

Note:

For network security reasons, you should perform any additional cluster configuration from a Web Cache instance on one of the internal middle tiers. Any Web Cache instance in the cluster can be used to administer the cluster, but if you want to use an external Oracle Web Cache instance, you must temporarily open the administration port in the firewall to allow external to internal traffic.

9.1.4 Configuring the First internal Middle Tier on APPHOST3 for Load Balancing Router

You must configure the Load Balancing Router to accept requests on port 7777 and forward them to the OracleAS Web Cache port 7777 APPHOST3.

You must also configure Oracle Portal middle tier on APPHOST3 to allow underlying components to construct URLs based on the Load Balancing Router host name (haqaedg05.us.oracle.com) and Load Balancing Router port number 7777, so that self-referential URLs rendered on Oracle Portal pages are valid for the browser. In order to do this, you must configure virtual hosts. To configure virtual hosts, perform the following steps:

1. Configure the Load Balancing Router to accept requests on port 80 and forward them to the Oracle Web Cache port (7777) running on APPHOST3. To do this:

1. Set up a group, or pool, on the Load Balancing Router, to which individual servers can be added. See the Load Balancing Router documentation for instructions on how to do this.

2. Add the desired servers' IP addresses and port numbers to the group.

3. Create a virtual server that listens on port 80, and balances requests among the members of the group. See the Load Balancing Router documentation for instructions on how to do this.

4. Ensure that the Load Balancing Router translates the port on which it is listening to forward requests to the port on which Oracle Web Cache is listening.

2. Configure the Oracle Portal middle tier on APPHOST3 to allow underlying components to construct URLs based on the Load Balancing Router host name (internal.mycompany.com) and Load Balancing Router port number (80), so that self-referential URLs rendered on Oracle Portal pages are valid for the browser. To do this, define a virtual host as follows:

1. Access the Oracle Enterprise Manager 11g console located at http://apphost3.us.oracle.com:7001/em.

2. In the navigation panel on the left, expand Web Tier.

3. Select ohs1. The Oracle HTTP Server home page is displayed.

4. From the menu, select Administration and navigate to Advanced Configuration.

5. From the Select file menu, select httpd.conf. Click Go to edit the file.

6. Edit the httpd.conf file. Add a VirtualHost container, as shown in the following example:

NameVirtualHost *:7778

<VirtualHost *:7778>
ServerName internal.mycompany.com
Port 80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>

7. Click Apply.

8. When prompted to restart Oracle HTTP Server, click No.

3. Define a second virtual host, using the same steps as for the first, with the following exceptions:

- Specify apphost3.mycompany.com as the Server Name.

- Specify 7777 for the Port directive in the VirtualHost container.

- When prompted to restart the Oracle HTTP Server, click Yes.

4. Define a site that matches the virtual host entry created in the previous step, using Oracle Web Cache Manager on APPHOST3, as follows:

1. Access the Oracle Web Cache Manager on APPHOST3, as described in the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

2. From Properties, click Sites.

3. Click Create under Named Sites Definitions.

4. On the Create Named Site page, specify internal.mycompany.com for the Host and 80 for Port. Keep the default values for all other fields.

5. Click OK. internal.mycompany.com now appears in the Named Sites Definitions table.

5. Use Oracle Web Cache Manager on the external middle tier to add APPHOST3 as an origin server to the Oracle Web Cache cluster. To add APPHOST3, perform the following steps:

1. Click Origin Server under Origin Servers, Sites, and Load Balancing.

2. In the Origin Server page, click Add under the Application Web Servers table.

3. In the Add Application Web Server page, provide the following information:

Property

Value

Hostname

apphost3.us.oracle.com

Port

7778 (APPHOST3 Oracle HTTP Server listening port)

Routing

ENABLED

Capacity

100

Failover Threshold

5

Ping URL

/

Ping Interval

10

Protocol

HTTP

4. Click Submit.

5. To verify that the origin server has been added properly, locate apphost3.mycompany.com in the Origin Server table.

Note:

Refer to the section "Map Sites to Origin Servers" in Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache, for more information.

6. Use Oracle Web Cache Manager on the external middle tier to map the site internal.mycompany.com to the middle tier apphost3.mycompany.com.

1. In the navigation frame, select Site-to-Server Mapping under Origin Servers, Sites, and Load Balancing.

2. In the Site-to-Server Mapping page, select the first mapping in the table and click Insert Above.

3. In the Edit/Add Site-to-Server Mapping page, select the Select from Site definitions option and then select internal.mycompany.com.

4. In the Select Application Web Servers section, select the application server on APPHOST3 (apphost3.mycompany.com) specified in the Origin Servers page.

5. Click Submit.

6. Click Apply Changes on the top of the page.

7. In the Cache Operations page, click Restart to restart Oracle Web Cache on APPHOST3.

To verify that the site has been mapped correctly, navigate to the Site-to-Server Mapping page, and ensure that APPHOST3 is mapped to the site internal.mycompany.com.

7. Configure the apphost3.mycompany.com computer so that it can resolve the Load Balancing Router hostname to have the correct IP address. You can use DNS resolution, or create an entry in the /etc/hosts file as follows:
xxx.xxx.240 internal.mycompany.com

Note:

Ensure that the /etc/hosts file does not have an entry that points the local hostname to 127.0.0.1. For example:

127.0.0.1 apphost3.mycompany.com

9.1.5 Registering the Internal Middle Tier as a Partner Application

For the single sign-on component to work properly, it must always be referenced by a partner application with the same host name in the URL. This is because cookies are sent back only to the host that generated them.

You must register the internal middle tier as a partner application. To achieve this, perform the following steps from an internal middle tier, APPHOST3:

1. Set the ORACLE_HOME variable to the SSO ORACLE_HOME location.

2. Run the SSO registration script ORACLE_HOME/sso/bin/ssoreg.sh with the parameters as shown in Example 9-1.

Example 9-1 ssoreg Usage on UNIX

-site_name_internal.mycompany.com
-mod_osso_URL https://internal.mycompany.com
-config_mod_osso TRUE
-oracle_home_path ORACLE_HOME
-config_file /tmp/osso.conf
-admin_info cn=orcladmin
-virtualhost
-remote_midtier

On Windows, run the ssoreg.bat script.

3. Copy /tmp/osso.conf to the Portal mid-tier home located at MW_HOME/asinst_1/config/OHS/ohs1.

4. Restart Oracle HTTP Server by issuing the following command:
ORACLE_HOME/opm/bin/opmnctl restartproc process-type=OHS

5. Log in to the Single Sign-On Server using the following URL:
http://login.mycompany.com/pls/orasso

6. Go to the administration page and then navigate to Administer Partner applications. Delete the entry for apphost3.mycompany.com.

7. Restart Web Tier for the changes to take effect. Oracle Web Tier components can be restarted using the following commands:
opmnctl stopall

opmnctl startall

Note:

Before issuing these commands, ensure that the environment variable ORACLE_INSTANCE is set to the value that was entered during the install.

9.1.6 Changing Host Assertion in WebLogic

By default, certain CGI environment variables are not passed through to WebLogic because the Oracle HTTP Server acts as a proxy for WebLogic. These include the host and port. WebLogic needs to be aware it is using a virtual site name and port so that it can generate internal URLs appropriately. To achieve this, perform the following tasks:

1. Log into the WebLogic administration console using the following URL:
http://apphost1.us.oracle.com:7001/console

2. Select Environment and navigate to Clusters.

3. Click Lock and Edit in the Change Center window to enable editing.

4. Select cluster_portal. Navigate to HTTP and enter the following values:

Parameter

Value

Frontend Host

internal.mycompany.com

Frontend HTTP Port

80

Frontend HTTPS Port

Not required

5. Click Activate Changes in the Change Center window.

6. Restart WLS_PORTAL managed server. To restart WLS_PORTAL, perform the following steps:

1. Log in to http://apphost1.us.oracle.com:7001/console.

2. Navigate to Servers and select the Control tab.

3. Select the WLS_PORTAL check box and click Shut down.

4. To restart WLS_PORTAL, select the WLS_PORTAL check box and click Start.
The WLS_PORTAL starts.

9.1.6.1 Validate the Configuration

After the first internal middle tier on APPHOST3 is configured, you must restore the portal version number to its original version number. To do this, perform the following steps:

1. Query the Portal version by connecting to the database as portal schema as shown in the following example:

>sqlplus portal/portaldb_portal@portaldb
sql> select version from wwc_version$;
sql> 11.1.1.1.0

2. Change the Portal repository version to 11.1.1.4.0 as shown in the following example:

sql> update wwc_version$ set version = '11.1.1.4.0';
sql> commit;
sql> select * from wwc_version$;
sql> 11.1.1.4.0

In order to validate the configuration, perform the following tests:

Test

URL

Result

Test Load Balancer

http://myPortal.mycompany.com/

Home page displayed

Test Load Balancer via SSL

https://myPortal.mycompany.com/

Home page displayed

Test Load Balancer termination

http://myPortal.mycompany.com/portal/pls/portal/owa_util.print_cgi_env

REQUEST_PROTOCOL value of HTTPS

9.1.7 Installing the Second Internal Middle Tier on APPHOST4

Before installing the second internal middle tier on APPHOST4, ensure that the internal middle tier on APPHOST3 is running.To install the second internal middle tier on APPHOST4, perform the following tasks:

- Follow the steps in Section 9.1.2, "Installing the First Internal Middle Tier on APPHOST3" to install the second internal middle tier, with the following exceptions:

- Substitute APPHOST3 with APPHOST4 wherever applicable.

- The portal version number must be changed only during the installation of the first internal middle tier on APPHOST3. Subsequently, when APPHOST4 or more middle tiers are set up, the portal version number must not be changed.

- In the Install Oracle Portal section, replace Step 6 with the following step:

- Select Expand Cluster. Enter the following values:

Parameter

Value

Host Name

Name of the host running WebLogic Admin Server: APPHOST3.mycompany.com

Port

Port that the Admin Server is using. For example, 7001

User Name

Admin Server administrator account name

Password

Admin Server password

Click Next. The Configure Components screen appears.

Note:

It is recommended that you use the same physical path for installing the second middle tier. This helps when you make configuration changes on one machine and want to transfer the changes to another machine.

9.1.8 Configuring an Oracle Web Cache Invalidation-only Cluster

After installing the second middle tier on APPHOST4, you must add the APPHOST4 cache to the cluster using Oracle Web Cache Manager on APPHOST1. To achieve this, perform the steps in Section 9.1.3, "Configuring an Oracle Web Cache Invalidation-only Cluster", replacing APPHOST3 with APPHOST4 wherever applicable.

9.1.9 Configuring the Second Internal Middle Tier on APPHOST4 for Load Balancing Router

Perform the following steps to configure the second internal middle tier on APPHOST4:

1. Introduce WLS_PORTAL1(APPHOST4) to ORACLE HTTP Server on APPHOST3.
After the managed server WLS_PORTAL has started, the Oracle HTTP Server (OHS) on the external middle tier needs to be made aware, so that it can route requests to it.

2. Update Oracle HTTP Server configuration to be cluster aware.
After the WebLogic cluster has been created, the WebLogic requests need to be directed to the cluster. To achieve this, you must edit the following in the portal.conf file located at ORACLE_INSTANCE/config/OHS/ohs1/moduleconf on APPHOST3:

- Change the following entries for the blocks beginning with the following:

- /portal

- /portalTools

- /wsrp-tools

- /portalHelp

- /portalHelp2

- Edit the following:

<Location /portal>
SetHandler WebLogic-handler
WebLogicHost apphost3.mycompany.com
WebLogicPort 9001
</Location>

to

<Location /portal>
SetHandler WebLogic-handler
WebLogicCluster apphost3.mycompany.com:9001,apphost4.mycompany.com:9001
</Location>

3. Restart the Oracle HTTP Server using the following command:
opmnctl restartproc process-type=OHS

4. Copy the configuration information from APPHOST3 to APPHOST4.

File

Location APPHOST3

Location APPHOST4

appConfig.xml

portal_cache.conf

portal_dads.conf

portal_plsql.conf

MW_HOME/user_projects/domains/PortalDomain/config/fmwconfig/servers/WLS_PORTAL/applications/portal/configuration/

MW_HOME/user_projects/domains/PortalDomain/config/fmwconfig/servers/WLS_PORTAL1/applications/portal/configuration

mod_oradav.conf

mod_osso.conf

plsql.conf

portal.conf

virtual_hosts.conf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

osso.conf

ORACLE_INSTANCE/config/OHS/ohs1

ORACLE_INSTANCE/config/OHS/ohs1

sqlnet.ora

ORACLE_INSTANCE/config/

ORACLE_INSTANCE/config/

5. Restart Oracle HTTP Server using the following commands:

ORACLE_HOME/opmn/bin/opmnctl stopall
ORACLE_HOME/opmn/bin/opmnctl startall

6. Configure virtual hosts.
You must configure Oracle Portal middle tier to allow underlying components to construct URLs based on the Load Balancing Router hostname (internal.mycompany.com) and Load Balancing Router port number 7777. In order to do this, you must configure virtual hosts. To configure virtual hosts, perform the following steps:

1. Edit the httpd.conf file located in $INSTANCE_HOME/config/OHS/ohs1.

2. Add the following entries to the file:

NameVirtualHost *:8888
<VirtualHost *8888>
ServerName http://internal.mycompany.com:7777
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>

<VirtualHost *:8888>
ServerName apphost4.us.oracle.com:7777
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>

7. Create the following Portal directories on APPHOST4 to allow the storage of the Oracle Portal cache:
ORACLE_INSTANCE/portal/cache

ORACLE_INSTANCE/diagnostics/logs/portal

8. Update instance paths in the files located in the directory at $DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL1/applications/portal/configuration.
Edit the following files as stated below:

portal_cache.conf – Change PlsqlCacheDirectory

portal_plsql.conf – Change PlsqlLogDirectory

9. Start WLS_PORTAL1 by logging into the Administration Server on APPHOST4 using the following URL:
http://apphost4.us.oracle.com:7001/console

for more information about starting WLS_PORTAL1, see section Start WLS_PORTAL1 in Oracle Portal Enterprise Deployment Guide:11.1.1.2.

10. Validate the configuration
After the configuration is completed, you must validate the configuration. In order to validate the configuration, perform the following tests:

Test

URL

Result

Test Load Balancer

http://myPortal.mycompany.com/

Home page displayed

Test Load Balancer via SSL

https://myPortal.mycompany.com/

Home page displayed

Test Load Balancer Termination

https://myPortal.mycompany.com/portal/pls/portal/owa_util.print_cgi_env

REQUEST_PROTOCOL value of HTTPS

9.1.10 Configure Web Cache

Change Web Cache Passwords

The Web Cache invalidation and admin passwords are randomly generated. It is recommended that these passwords be changed from the default value to a new known value. To change the password, perform the following steps:

1. In the navigator window, expand the Web Tier tree.

2. Select wc1 in APPHOST4.

3. From the menu list at the top of the page, select Administration and navigate to Passwords.

4. Enter a new invalidation password and administration password. Confirm and click Apply.

Note:

Use the same passwords as used in the external middle tier.

5. Restart Web Cache, for the changes to take effect, by using the following command:
opmnctl restartproc ias-component=wc1

Use Oracle Web Cache Manager on APPHOST3 to add APPHOST4

To add APPHOST4 using Oracle Web Cache Manager, perform the following steps:

1. Click Origin Server under Origin Servers, Sites, and Load Balancing.

2. In the Origin Server page, click Add under the Application Web Servers table.

3. In the Add Application Web Server page, provide the following information:

Property

Value

Hostname

apphost4.us.oracle.com

Port

7778 (APPHOST4 Oracle HTTP Server listening port)

Routing

ENABLED

Capacity

100

Failover Threshold

5

Ping URL

/

Ping Interval

10

Protocol

HTTP

4. Click Submit.

5. To verify that the origin server has been added properly, locate apphost4.us.oracle.com in the Origin Server table.

Use Oracle Web Cache Manager on APPHOST3 to map the Load Balancing Router site to the origin servers

To map the load balancing router site internal.mycompany.com to the two origin servers apphost3.mycompany.com and apphost4.mycompany.com using Web Cache Manager, perform the following steps:

1. In the navigation frame, select Site-to-Server Mapping under Origin Servers, Sites, and Load Balancing.

2. In the Site-to-Server Mapping page, select the mapping for the Load Balancing Router site in the table and click Edit Selected.

3. In the Select Application Web Servers section, select an application Web server specified in the Origin Servers page for APPHOST4 (apphost4.mycompany.com).

4. Click Submit.

5. To verify that the site has been mapped correctly, ensure that both APPHOST3 and APPHOST4 are mapped to internal.mycompany.com in the Site to Server Mappings table.

6. Click Apply Changes at the top of the page. Perform the following steps in the Cache Operations page:

1. Click Propagate to propagate changes to APPHOST4.

2. Click Restart to restart Web Caches on APPHOST3 and APPHOST4.

9.1.11 Configuring the Oracle Portal Schema in the Oracle Metadata Repository

Configure the Oracle Portal schema in the Oracle Metadata Repository to send host-independent invalidations. To do this, perform the following steps:

1. Log in to APPHost1 and run the script OH/portal/admin/plsql/wwc/cachhii.sql using SQL*Plus.

2. Specify on at the prompt to enable host-independent invalidations.

9.1.12 Validating the Completed Configuration

To verify that your configuration is complete and is working as expected, perform the following steps:

1. Test access to Oracle AS Portal through the Load Balancing Router by completing the following steps:

1. Access the OracleAS Portal home page at http://internal.mycompany.com:7777/pls/portal.

2. Click the Portal login link.

3. Click some links in the portal.

4. Confirm that content is getting cached in Oracle Web Cache. To do this, access the Oracle Web Cache Manager on APPHOST3 as described in Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.
Under Monitoring, click Popular Requests. select Cached from the Filter Objects drop-down list, and click Update. If you accessed Oracle Portal, you will see portal content (For example, URLs that contain /pls/portal).

Perform some basic page edits in Oracle Portal, such as adding a portlet to a page, and verify that the new content shows up. If the new content does not display properly, or errors occur, Oracle Web Cache invalidation is misconfigured.

9.2 Upgrading Oracle Portal 10g Intranet-Internet setup to 11g

This section includes the following topics:

- Installing and Upgrading the External Middle Tier

- Post Upgrade Configuration of the External Middle tier

- Installing and Upgrading the First Internal Middle Tier on APPHOST3

- Post Upgrade Configuration of the First Internal Middle Tier on APPHOST3

- Installing and Upgrading the Second Middle Tier on APPHOST4

- Post Upgrade Configuration of the Second Internal Middle Tier on APPHOST4

- Validating the Configuration

9.2.1 Installing and Upgrading the External Middle Tier

Installing the External Middle Tier

To install the external middle tier, perform the following tasks:

1. Install WebLogic Server version 1034.

2. Install PS1 S/W bits.

3. Install PS3 Sparse patch.

4. Open the vi portal-deployment-sequence.xml file located at MW_HOME/oracle_home/install/config/deploy.
Comment the following lines in the file as shown below:

<!-- <Deploy name="portalHelp" file="portal/jlib/portalHelp.ear" description="Portal Help" stagingMode="nostage"/> -->
<!-- <Deploy name="portalHelp2" file="portal/jlib/portalHelp2.ear" description="Portal Help 2" stagingMode="nostage"/>-->

5. Run ./config.sh which is located at MW_HOME/$ORACLE_HOME/bin.

Upgrading the Repository and External Middle Tier

You must use the Upgrade Assistant to upgrade the repository and external middle tier. To upgrade the external middle tier and the required schemas and repository, see Section 3.6, "Task 6: Use the Upgrade Assistant to Upgrade the Required Schemas and Middle Tiers" in Oracle Fusion Middleware Upgrade Guide for Oracle Portal, Forms, Reports, and Discoverer

9.2.2 Post Upgrade Configuration of the External Middle tier

After upgrading the repository and the middle tier, you must configure the middle tier. The following configuration tasks must be performed:

1. Open the httpd.conf file located at MW_HOME/instance_name/config/OHS/ohs1. Edit the file as shown below:

NameVirtualHost*:7778
<VirtualHost*:7778>
ServerName portal.mycompany.com
#SecureHttps On
Port 443
UseCanonicalName On
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

<VirtualHost*:7778>
ServerName apphost1.us.oracle.com:7777
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>

2. Specify the Frontend host and port details.

1. Log into the upgraded WebLogic console using the following URL:
http://apphost1.us.oracle.com:7001/console

2. From the navigation panel on the left, navigate to Clusters and click Summary of Clusters.

3. Select cluster_portal. The Settings for cluster_portal page is displayed.

4. Select the HTTP tab from the Configuration section.

5. Enter the following frontend host and port details:
Frontend Host: portal.mycompany.com

Frontend HTTP Port: 80

Frontend HTTPS Port: 443

6. Click Save. Click Activate Changes for the changes to take effect.

3. Restart WLS_PORTAL for the configuration changes to take effect. To restart WLS_PORTAL, perform the following steps:

1. Log in to http://apphost1.us.oracle.com:7001/console.

2. Navigate to Servers and select the Control tab.

3. Select the WLS_PORTAL check box and click Shut down.

4. To restart WLS_PORTAL, select the WLS_PORTAL check box and click Start.
The WLS_PORTAL starts.

4. Open the portal_dads.conf file located at. Edit the file as shown below:

<Location /pls/portal>
SetHandler pls_handler
Order allow,deny
Allow from All
AllowOverride None
PlsqlDatabaseUsername portal
PlsqlDatabasePassword CSFPassword
PlsqlDatabaseConnectString portalinfra.us.oracle.com:1521:portaldb.us.oracle.com  ServiceNameFormat
PlsqlNLSLanguage AMERICAN_AMERICA.WE8ISO8859P1
PlsqlAuthenticationMode SingleSignOn
PlsqlDocumentTablename portal.wwdoc_document
PlsqlDocumentPath docs
PlsqlDocumentProcedure portal.wwdoc_process.process_download
PlsqlDefaultPage portal.home
PlsqlPathAlias url
PlsqlPathAliasProcedure portal.wwpth_api_alias.process_download
PlsqlExclusionList "#None#"
PlsqlCGIEnvironmentList "REQUEST_PROTOCOL=HTTPS"
PlsqlCGIEnvironmentList "SERVER_PORT=443"
</Location>

5. Create a database wallet and store the certificate of the load balancer in this wallet. After storing the certificate inside the database wallet, it is also necessary to store the location of the wallet within the Portal repository.
To achieve these tasks, perform all the steps in the following sections of Oracle Portal Enterprise Deployment Guide:11.1.1.2:

- Create a Database Wallet

- Import Certificate into Database Wallet

- Identify the Wallet to Portal

6. You must register the external middle tier with SSO. For information about registering with SSO, see Oracle Portal Enterprise Deployment Guide:11.1.1.2.

7. Restart Web Tier (OHS and Web Cache).
Having made the above changes, the Web tier components must be restarted. This can be achieved by issuing the following commands:

opmnctl stopall

opmnctl startall

8. Validate the configuration.
In order to validate the configuration, perform the following tests:

Test

URL

Result

Test Load Balancer SSL Termination

https://myPortal.mycompany.com/portal/pls/portal/owa_util.print_cgi_env

REQUEST_PROTOCOL value of HTTPS

Test Portal via Load Balancer

https://myPortal.mycompany.com/portal/pls/portal

Portal home page displayed

Test Portal Login via Load Balancer

https://myPortal.mycompany.com/portal/pls/portal

Should be able to log in using account orcladmin

9.2.3 Installing and Upgrading the First Internal Middle Tier on APPHOST3

Install the First Internal Middle Tier on APPHOST3

To install the internal middle tier on APPHOST3, perform the following tasks:

1. Install WebLogic Server version 1034.

2. Install PS1 S/W bits.

3. Install PS3 Sparse patch.

4. Open the vi portal-deployment-sequence.xml file located at MW_HOME/oracle_home/install/config/deploy.
Comment the following lines in the file as shown below:

<!-- <Deploy name="portalHelp" file="portal/jlib/portalHelp.ear" description="Portal Help" stagingMode="nostage"/> -->
<!-- <Deploy name="portalHelp2" file="portal/jlib/portalHelp2.ear" description="Portal Help 2" stagingMode="nostage"/>-->

5. Connect to the database and change the version in the Portal schema as shown below:

>sqlplus portal/portaldb_portal@portaldb
sql> select version from wwc_version$;
sql> 11.1.1.4.0

Now change the version to 11.1.1.1.0 as shown below:

sql> update wwc_version$ set version = '11.1.1.1.0';
sql> commit;
sql> select * from wwc_version$;
sql> 11.1.1.1.0

6. Create Portlet schema using 11g RCU.

7. Run ./config.sh which is located at MW_HOME/$ORACLE_HOME/bin.

Upgrade the First Internal Middle Tier on APPHOST3

You must use the Upgrade Assistant to upgrade the internal middle tier on APPHOST3. To upgrade the internal middle tier on APPHOST3, see Section 3.6,"Task 6: Use the Upgrade Assistant to Upgrade the Required Schemas and Middle Tiers" in Oracle Fusion Middleware Upgrade Guide for Oracle Portal, Forms, Reports, and Discoverer.

Note:

The Repository is upgraded only for the external middle tier. You need not upgrade the repository for the Internal middle tiers on APPHOST3 and APPHOST4.

9.2.4 Post Upgrade Configuration of the First Internal Middle Tier on APPHOST3

After upgrading the internal middle tier, you must configure the middle tier. The following configuration tasks must be performed:

1. Specify the Frontend host and port details.

1. Log into the upgraded WebLogic console using the following URL:
http://apphost3.us.oracle.com:7001/console

2. From the navigation panel on the left, navigate to Clusters and click Summary of Clusters.

3. Select cluster_portal. The Settings for cluster_portal page is displayed.

4. Select the HTTP tab from the Configuration section.

5. Enter the following frontend host and port details:
Frontend Host: internal.mycompany.com

Frontend HTTP Port: 7777

Click Save.

Note:

Leave the Frontend HTTPS port field blank.

6. Restart WLS_PORTAL, for the changes to take effect, by performing the following steps:

1. Log in to WebLogic console.

2. Navigate to Servers and select the Control tab.

3. Select the WLS_PORTAL check box and click Shut down.

4. To restart WLS_PORTAL, select the WLS_PORTAL check box and click Start.
The WLS_PORTAL starts.

2. You must register the internal middle tier on APPHOST3 with SSO. For information about registering with SSO, see Oracle Portal Enterprise Deployment Guide:11.1.1.2. Copy the generated osso.conf file to the following directory:
$ORACLE_HOME/asinst_1/config/OHS/ohs1/osso.

3. Restart Web Tier (OHS and Web Cache).
Having made the above changes, the Web tier components must be restarted. This can be achieved by issuing the following commands:

opmnctl stopall

opmnctl startall

9.2.5 Installing and Upgrading the Second Middle Tier on APPHOST4

After the first internal middle tier on APPHOST3 is installed and upgraded, you must restore the portal version number to its original version number. To do this, perform the following steps:

1. Query the Portal version by connecting to the database as portal schema as shown in the following example:

>sqlplus portal/portaldb_portal@portaldb
sql> select version from wwc_version$;
sql> 11.1.1.1.0

2. Change the Portal repository version to 11.1.1.4.0 as shown in the following example:

sql> update wwc_version$ set version = '11.1.1.4.0';
sql> commit;
sql> select * from wwc_version$;
sql> 11.1.1.4.0

Note:

The portal version number must be changed only when the installing and upgrading the first internal middle tier on APPHOST3. Subsequently, when APPHOST4 or more middle tiers are set up, the portal version number must not be changed.

Install the Second Internal Middle Tier on APPHOST4

To install the second internal middle tier on APPHOST4, perform the following tasks:

1. Follow all the steps in Installing the External Middle Tier.

2. Install Oracle Portal 11g as mentioned in Section 9.1.7, "Installing the Second Internal Middle Tier on APPHOST4".

Upgrade the Second Internal Middle Tier on APPHOST4

You must use the Upgrade Assistant to upgrade the internal middle tier on APPHOST3. To upgrade the internal middle tier on APPHOST3, see Section 3.6, "Task 6: Use the Upgrade Assistant to Upgrade the Required Schemas and Middle Tiers" in Oracle Fusion Middleware Upgrade Guide for Oracle Portal, Forms, Reports, and Discoverer.

Note:

The Repository is upgraded only for the external middle tier. You need not upgrade the repository for the Internal middle tiers on APPHOST3 and APPHOST4.

9.2.6 Post Upgrade Configuration of the Second Internal Middle Tier on APPHOST4

To configure the WebLogic domain for APPHOST4, perform the following tasks:

1. Introduce WLS_PORTAL1(APPHOST4) to ORACLE HTTP Server on APPHOST3.
After the managed server WLS_PORTAL has started, the Oracle HTTP Server (OHS) on the external middle tier needs to be made aware, so that it can route requests to it.

2. Update Oracle HTTP Server configuration to be cluster aware.
After the WebLogic cluster has been created, the WebLogic requests need to be directed to the cluster. To achieve this, you must edit the following in the portal.conf file located at ORACLE_INSTANCE/config/OHS/ohs1/moduleconf on APPHOST3:

- Change the following entries for the blocks beginning with the following:

- /portal

- /portalTools

- /wsrp-tools

- /portalHelp

- /portalHelp2

- Edit the following:

<Location /portal>
SetHandler WebLogic-handler
WebLogicHost apphost3.mycompany.com
WebLogicPort 9001
</Location>

to

<Location /portal>
SetHandler WebLogic-handler
WebLogicCluster apphost3.mycompany.com:9001,apphost4.mycompany.com:9001
</Location>

3. Restart the Oracle HTTP Server using the following command:
opmnctl restartproc process-type=OHS

4. Copy the configuration information from APPHOST3 to APPHOST4.

File

Location APPHOST3

Location APPHOST4

appConfig.xml

portal_cache.conf

portal_dads.conf

portal_plsql.conf

MW_HOME/user_projects/domains/PortalDomain/config/fmwconfig/servers/WLS_PORTAL/applications/portal/configuration/

MW_HOME/user_projects/domains/PortalDomain/config/fmwconfig/servers/WLS_PORTAL1/applications/portal/configuration

mod_oradav.conf

mod_osso.conf

plsql.conf

portal.conf

virtual_hosts.conf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

osso.conf

ORACLE_INSTANCE/config/OHS/ohs1

ORACLE_INSTANCE/config/OHS/ohs1

sqlnet.ora

ORACLE_INSTANCE/config/

ORACLE_INSTANCE/config/

5. Configure virtual hosts. To achieve this, perform the following steps:

1. Edit the virtual_hosts.conf file located at ORACLE_INSTANCE/config/OHS/ohs1/moduleconf on APPHOST4.

2. Ensure that the file contains the UseCanonicalName On entry as shown below:

NameVirtualHost *:7778
<VirtualHost *7778>
ServerName http://internal.mycompany.com:7777
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>

<VirtualHost *:7778>
ServerName apphost4.us.oracle.com:7777
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>

6. Restart Oracle HTTP Server using the following commands:

ORACLE_HOME/opmn/bin/opmnctl stopall
ORACLE_HOME/opmn/bin/opmnctl startall

7. Create the following Portal directories on APPHOST4 to allow the storage of the Oracle Portal cache:
ORACLE_INSTANCE/portal/cache

ORACLE_INSTANCE/diagnostics/logs/portal

8. Update instance paths in the files located in the directory at $DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL1/applications/portal/configuration.
Edit the following files as stated below:

portal_cache.conf – Change PlsqlCacheDirectory

portal_plsql.conf – Change PlsqlLogDirectory

9. Before starting WLS_PORTAL1, perform the following steps:

1. Unzip the portal.ear file located at $ORACLE_HOME/archives/applications dir.

2. Open portal_dads.conf which is a zero byte file. Add content to the file to make it a non-zero byte file, and save it.

3. Rebuild the portal.ear file.

4. Restart WLS_PORTAL1.

5. Copy portal_dads.conf file from APPHOST3 instance to $DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL1/applications/portal/configuration (APPHOST4).

6. Restart WLS_PORTAL1 server.

10. Start WLS_PORTAL1 by logging into the Administration Server on APPHOST4 using the following URL:
http://apphost4.us.oracle.com:7001/console

for more information about starting WLS_PORTAL1, see section Start WLS_PORTAL1 in Oracle Portal Enterprise Deployment Guide:11.1.1.2.

9.2.7 Validating the Configuration

To validate the configuration, access the external Portal URL (http://portal.mycompany.com/portal/pls/portal) and internal Portal URL (http://internal.mycompany.com:7777/portal/pls/portal) in the following two scenarios and verify that they are working:

- APPHOST3 is completely down (opmn services and WLS_PORTAL) and APPHOST4 is completely up (opmn services and WLS_PORTAL).
APPHOST3 is completely up (opmn services and WLS_PORTAL) and APPHOST4 is completely down (opmn services and WLS_PORTAL)

10 Configuring the Search Features in Oracle Portal

This chapter provides information on setting up the search capabilities in Oracle Portal. This includes how to set up Oracle Text and maintain Oracle Text indexes.

This chapter contains the following sections:

- Search Options in Oracle Portal

- Configuring Oracle Portal Search Options

- Oracle Text

- Oracle Secure Enterprise Search

10.1 Search Options in Oracle Portal

Oracle Portal offers powerful search capabilities that you can customize according to your needs. A robust set of built-in search portlets enables you to perform searches on the portlet repository, portal pages and external sites.

Furthermore, you can perform searches against more than 100 document types including HTML, XML, PDF, word processing formats, spreadsheets formats, presentation formats, and other common business formats.

This section introduces the search options that are available in Oracle Portal and gives some guidance on how you can select which option is best for you:

- Oracle Portal Search

- Oracle Secure Enterprise Search

- Default Search Functionality

- Deciding Which Search Options to Use

- Differences Between Oracle Secure Enterprise Search and Oracle Portal Search

10.1.1 Oracle Portal Search

Oracle Portal includes a set of built-in features tuned for searching content stored and managed within the Oracle Portal Repository. These features are incorporated within four search portlets and they can be configured in a variety of ways:

- Basic Search — this portlet allows simple keyword searches.

- Advanced Search — this portlet enables you to enter more detailed search criteria, including operators on multiple attributes values.

- Custom Search — this portlet is fully customizable and enables you to design a search portlet to suit your needs, including pre-defined searches that display results in place. As this portlet is a superset of the Basic and Advanced search portlets, it can be configured to look and behave like these portlets if required.

- Saved Searches — this portlet enables you to repeat saved searches.

These portlets search all text-type metadata associated with content in the Oracle Portal Repository. For example, display name, keyword, description, and similar attributes.

In addition to metadata, the portlets can search the portal content and this is possible as Oracle Text is enabled in Oracle Portal by default.

Note:

This does not apply to the content of portlets. Portlet content cannot be indexed and consequently cannot be searched.

This means that Oracle Portal search portlets also search in:

- Documents/files and URL items — file and URL items in binary format can be indexed providing the file format is filterable by Oracle Text.

- Web pages that URLs (in URL attributes) point to — the content must be plain text or HTML.

Note:

If more than one search term is specified along with an AND search operator (like Contain All of the Terms, Partially Match All of the Terms, Sound Like All of the Terms, and so on), then the terms must all appear within the same search index to result in a match. For example, if you enter 'weights aerobics' and choose the Contains All operator, then search results are returned only when both these terms are found in item metadata, URL content, or document content. If the term weights is found in URL content and the term aerobics is found in document content, then this does not result in a match.

To find out how to configure Oracle Text for use in Oracle Portal, see Section 10.2.2, "Configuring Oracle Text Options in Oracle Portal". To learn more about Oracle Text, how to maintain Oracle Text indexes, and for troubleshooting information, see Section 10.3, "Oracle Text".

To find out how you can configure Oracle Portal search portlets, see Section 10.2.1, "Configuring Oracle Portal Search Portlets". To learn more about Oracle Portal search portlets and how to add search functionality to Oracle Portal pages, refer to the Oracle Fusion Middleware User's Guide for Oracle Portal.

Disabling Oracle Text

Out-of-the-box, Oracle Text is enabled. Although Oracle does not recommend that you disable Oracle Text, it is possible to do so, if your portal does not require or would not benefit from full text searches for Oracle Portal Repository content. For more information, see Section 10.3.1.1, "Searching With Oracle Text Disabled".

Search Results and Content Security

Oracle Portal search result pages can display items, pages, categories, or perspectives that meet your search criteria. Refer to Section 10.1.3, "Default Search Functionality" for more information. Search results do not include:

- Content you are not authorized to view

- Content that has expired, or is not yet published

- Page content that is derived from a template

- Portlet instances or Portal Smart Links

- Multiple versions of an item (when versioning in enabled, only the current version of items are returned in search results)

Page designers can choose whether to display links to associated objects with each search result. For example, users may see links to the page group, page, category and perspective associated with an item. However, users who click such links are denied access to the object, if they do not have the required access privileges.

10.1.2 Oracle Secure Enterprise Search

Oracle Secure Enterprise Search (SES) provides an enterprise search capability over a variety of content repositories and data sources, including the Oracle Portal Repository. Oracle Secure Enterprise Search includes a secure search portlet that can be embedded in Oracle Portal pages.

From this portlet, a user can enter a search term and launch a search that returns a single result set that includes content from all configured data sources. When Oracle Portal is configured as one of the data sources, the search returns public content and any private content that the user has the appropriate privileges to see.

The Oracle Secure Enterprise Search Administrator's Guide provides detailed configuration instructions for Oracle Secure Enterprise Search and is available on the Oracle Technology Network (OTN) at http://www.oracle.com/technology/products/oses/index.html.

See Section 10.4, "Oracle Secure Enterprise Search" for more of an overview of Oracle Secure Enterprise Search.

10.1.3 Default Search Functionality

After a standard Oracle Portal installation you can start using the search features in Oracle Portal right away. Without any additional configuration, you can place one of the built-in Oracle Portal search portlets on a page and use it to search portal content.

During installation, Oracle Text indexes are created and synchronized and Oracle Text searching is enabled in your portal. However, it is important to note that new or modified content (items, pages, categories, perspectives) is not returned in search results until the Oracle Text indexes are next synchronized. See Section 10.3.5.1, "Synchronizing Oracle Text Indexes".

By default, Oracle Text indexes are scheduled to synchronize hourly by a job that calls wwv_context.sync. If you find that the default synchronization interval is not suitable for your portal you can modify it at any time. For details, see.Section 10.3.5.5, "Deciding How Often to Synchronize Oracle Text Indexes".

If you are using Oracle Database 11g, you can specify that Oracle Text indexes synchronize automatically whenever portal objects are added, modified, or deleted. This feature is useful for portal applications where newly added or altered content must be searchable immediately. To find out more, see Section 10.3.5.2, "Synchronizing an Oracle Text Index On Commit".

Note:

If you do not want to make use of the additional features provided by Oracle Text, then you can disable this feature. See Section 10.2.2.1, "Enabling and Disabling Oracle Text in Oracle Portal".

Table 10-1 shows some other default search settings. See Section 10.2, "Configuring Oracle Portal Search Options" for information about how to change the values listed here.

Table 10-1 Default Search Settings

Search Setting Option

Default

Results Page - Basic Search Portlets and Basic Search Box Items

Basic Search Results Page

Results Page - Advanced, Custom and Saved Search Portlets

Search Results Page

Advanced Search Link

Advanced Search Page

Internet Search Engine Link

None

Hits per Page

20

Oracle Text

Enabled

Oracle Text - Themes And Gists

Disabled

Oracle Text - Highlight Text Color

Default

Oracle Text - Highlight Text Style

Plain

Oracle Text - Base URL

http://<host>:<port>/portal/pls/<dad>

The following images show default search portlets and pages:

Figure 10-1 Oracle Portal Basic Search Portlet

Figure 10-2 Oracle Portal Basic Search Results Page

Figure 10-3 Oracle Portal Advanced Search Portlet

Figure 10-4 Oracle Portal Custom Search Portlet

Figure 10-5 Oracle Portal Search Results Page

Figure 10-6 Oracle Portal Saved Searches Portlet

10.1.4 Deciding Which Search Options to Use

Choosing how to configure searching within Oracle Portal begins with a careful examination of your goals for the search experience and understanding of your portal content. Some key questions include:

- Searching 'breadth' - do you wish to limit the results returned from your portal search to content managed within the Oracle Portal Repository, or do you want to return results from other repositories?

- Searching 'depth' - is full text indexing of document content a key requirement, or is a metadata only index sufficient?

- Content security policies and portal user profiles - is your search experience targeted at primarily public, unauthenticated users searching public content or is it more targeted at individual users who have various levels of access privileges to the content?

- Advanced searching features - is the ability to order results by relevancy, view document themes and gists, and other features of Oracle Text an important capability to offer your users?

- Administration - how much time are you willing to invest in administering and maintaining indexes, data sources, and so on?

Use Table 10-2 to help match your search requirements to the most appropriate search configuration:

Table 10-2 Oracle Portal Search Options

Oracle Portal (Oracle Text disabled)

Oracle Portal (Oracle Text enabled)

Oracle Secure Enterprise Search

Searching 'Breadth'

Oracle Portal Repository only

Oracle Portal Repository only

Oracle Portal Repository and other repositories

Searching 'Depth'

Oracle Portal metadata only

Full text index

Full text index

Content security and user profiles

Returns secure and public content in search results

Returns secure and public content in search results

Returns secure and public content in search results

Advanced searching features

No

Yes

Yes

Administration

Minimal

Maintain full text indexes

Maintain full text indexes and configure data sources

10.1.5 Differences Between Oracle Secure Enterprise Search and Oracle Portal Search

This section highlights the main differences between Oracle Secure Enterprise Search and Oracle Portal Search.

- Oracle Ultra Search only crawls public content
Oracle Portal is exposed to Oracle Ultra Search as a file system, and to see content in a folder, the folder must be public. If it is not public, none of the content from the folder or the sub-folder hierarchy is crawled. If you create a piece of content and make it public, then it is only indexed if all the containing folders are also public.

- Oracle Secure Enterprise Search returns a single list of pages and items:
To Oracle Secure Enterprise Search, both Oracle Portal pages and items are resources with metadata and content, or a visual representation that can be crawled, indexed, and returned in search results. This means that, Oracle Secure Enterprise Search can return a search result list that contains both pages and items. Oracle Portal Search searches for distinct types of data (pages, items, categories and perspectives) and only one type of data can be searched at a time. Whilst Oracle Secure Enterprise Search does not treat categories and perspectives as separate searchable entities, it can (like Oracle Portal Search), search for items and pages that have a particular perspective or category.

- Oracle Secure Enterprise Search searches content of displayed pages in addition to metadata:
Oracle Portal Search searches page and item metadata. The Oracle Secure Enterprise Search crawler sees the rendered content plus the metadata. This means that Oracle Secure Enterprise Search can return results when Oracle Portal search does not return any.

- Oracle Portal Search excludes some item types:
Oracle Portal Search can only return items of the following base item types:

- <None> that is, no base item type

- Base File

- Base URL

- Base Text

- Base PL/SQL

- Base Page Link

- Base Image

- Base Image Map

Oracle Secure Enterprise Search indexes the visualization of any item type that appears on a page, along with the item's metadata, irrespective of the base item type, as it is the page rendition that is indexed. This means that all the content on the page, static and dynamic, is indexed by Oracle Secure Enterprise Search including banners and template items, login/logout links, and so on.

- Oracle Text and scoring systems:

Both Oracle Secure Enterprise Search and Oracle Portal Search use Oracle Text to index their content, however their implementations are different. Furthermore, Oracle Secure Enterprise Search uses a slightly different scoring system to Oracle Portal Search, and it may be customized. See the Oracle Secure Enterprise Search Administrator's Guide available from OTN at http://www.oracle.com/technology/products/oses/index.html.

Both scoring systems give weighting when a search term is found in the title, so title hits will score more highly than hits in the document content. In Oracle Portal searches, the score ranks even higher when there are multiple terms in the title, and weighting is also given when multiple terms are found close together or to search results that contain the most hits.

- Oracle Secure Enterprise Search crawls external content:
Oracle Secure Enterprise Search can crawl content outside of Oracle Portal, that is, external Web sources. Oracle Portal searches are restricted to internal content.

10.2 Configuring Oracle Portal Search Options

The Oracle Portal search feature is installed with defaults so you can start using the search features right away. Refer to Section 10.1.3, "Default Search Functionality" for a description of these initial defaults.

This section describes how you, the portal administrator, can configure aspects of the search feature that affect all search portlets:

- Configuring Oracle Portal Search Portlets

- Configuring Oracle Text Options in Oracle Portal

- Configuring Oracle Secure Enterprise Search Options in Oracle Portal

10.2.1 Configuring Oracle Portal Search Portlets

This section describes how to configure aspects of the search feature that affect all Oracle Portal search portlets:

- Choosing Search Result Pages

- Limiting the Number of Search Results on a Page

- Choosing an Advanced Search Link (Basic/Custom Search Portlets)

- Choosing an Internet Search Engine (Advanced/Custom Search Portlets)

10.2.1.1 Choosing Search Result Pages

You can determine which page is used to display search results from:

- Basic Search portlets and Basic Search Box items

- Advanced, Custom, and Saved Searches portlets

If you choose a different search result page, then it is applied to both new and existing search portlets.

You can override this setting for a particular Custom Search portlet, if required. A Custom Search portlet only uses the result page specified here, if the Where should the search results be displayed? option (on Edit Defaults: Results Display tab) is set to the Default Search Results Page. For more information on how to set options for the Custom Search portlet, refer to the Oracle Fusion Middleware User's Guide for Oracle Portal, available from OTN at http://www.oracle.com/technology/products/ias/portal/documentation.html.

To specify a search result page for Oracle Portal search portlets:

1. In the Services portlet, click Global Settings.
By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

2. Click the Search tab.

3. In the Search Results Pages section, for Basic Search Portlets and Basic Search Box Items, choose a suitable search results page.
You can choose any portal page that contains a search portlet. If you select a page without a search portlet, then no results are displayed. The default is the Basic Search Results Page.

4. For Advanced, Custom and Saved Search Portlets, choose a suitable search results page.
You can choose any portal page that contains a search portlet. If you select a page without a search portlet, then no results are displayed. The default is the Search Results Page.

5. Select OK.

Note:

If page caching is enabled, then the change may not be seen in existing search portlets immediately. The cache is cleared automatically every 24 hours for all search portlets. Alternatively, clear the cache manually from the Web Cache Administration page in Oracle Fusion Middleware Control. See Section 8.1, "Using Oracle Enterprise Manager 11g Fusion Middleware Control".

If a page you select is subsequently deleted, then the associated Page field is empty. Choose another page and then click OK. If you click Cancel, then you will see Page Not Found errors after search operations.

10.2.1.2 Limiting the Number of Search Results on a Page

You can limit the number of results that search portlets can display. The limit is applied to Basic, Advanced, and Custom Search portlets.

You cannot change the limit for individual Basic or Advanced Search portlets. However, you can override this setting for a Custom Search portlet, if required.

If the number of results returned by a search exceeds this limit, the search results pages include Next and Previous icons so that users can view all of the results as shown in Figure 10-7. On a Custom Search portlet, these icons may be hidden, if required.

For more information on how to set options for the Custom Search portlet, refer to the Oracle Fusion Middleware User's Guide for Oracle Portal, available on OTN at http://www.oracle.com/technology/products/ias/portal/documentation.html.

Figure 10-7 Hits per Page Setting on Search Portlets

For example, if you limit Hits Per Page to 10, the first 10 results are displayed on the first search results page, the next 10 on the second page, and so on.

Note:

If you change the limit, the new value does not effect existing search portlets, only new ones.

To specify the number of search results per page:

1. In the Services portlet, click Global Settings.
By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

2. Click the Search tab.

3. In the Search Properties section, for Hits Per Page, enter the number of search results to display on a page.

4. Click OK.

10.2.1.3 Choosing an Advanced Search Link (Basic/Custom Search Portlets)

Typically, advanced searches allow a user to specify additional search criteria. For example, see Figure 10-8.

Figure 10-8 Advanced Search Link on Basic/Custom Search Portlets

The advanced search link can be to an external site, another portal page, or a package call within Oracle Portal.

An advanced search link is displayed on Basic Search portlets. Optionally, this link can be displayed on Custom Search portlets. For more information on how to set options for the Custom Search portlet, refer to the Oracle Fusion Middleware User's Guide for Oracle Portal, available on OTN at http://www.oracle.com/technology/products/ias/portal/documentation.html.

You can determine the destination of the Advanced Search Link, for all Basic/Custom Search portlet instances. When you specify a new Advanced Search Link, it is applied to both new and existing search portlets that display an Advanced Search link.

To enter advanced search link details:

1. In the Services portlet, click Global Settings.
By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

2. Click the Search tab.

3. In the Advanced Search Link section, do one of the following:

- Specify a destination Page Name for the Advanced Search link.
The default is the Advanced Search Page, which contains the built-in Oracle Portal Advanced Search portlet. However, you can select any portal page displaying advanced search options, the page does not have to contain one of the Oracle Portal search portlets. For example, you can use a JSP page containing advanced search options if one existed in your portal.

If the page you select is subsequently deleted, this field is empty. Choose another page and then OK. If you click Cancel, the advanced search links will all still point to the deleted page.

- Specify a URL for the Advanced Search link.
Enter the URL you want to use. If you have created a customized search engine that you want to use for advanced searches throughout the portal, you can specify its link here.

You can specify an absolute URL, or a relative URL. For example, http://www.myfavoritesearchengine.com creates a link directly to this Internet search site.

If you enter a relative URL (that is, a portal package), the value specified here is appended to the Oracle Portal schema URL and this results in a call to the portal package. Note how the value is appended, depending on whether the value specified begins with '/':

/value results in this URL: http://<webserver>:<port>//<PORTALSCHEMA>.my_search_package.my_search_method>

value results in this URL: http://<webserver>:<port>/portal/pls/<dad>//<PORTALSCHEMA>.my_search_package.my_search_method

4. Select OK.

Note:

If page caching is enabled, the change may not be seen in existing search portlets immediately. The cache is cleared automatically every 24 hours for all search portlets. Alternatively, clear the cache manually from the Web Cache Administration page in Oracle Fusion Middleware Control. See Section 8.1, "Using Oracle Enterprise Manager 11g Fusion Middleware Control".

10.2.1.4 Choosing an Internet Search Engine (Advanced/Custom Search Portlets)

An Internet search engine link is displayed on Advanced Search portlets. So, if users do not find the information they need when they search Oracle Portal, they can extend their search using an Internet Search Engine. See Figure 10-9.

Figure 10-9 Internet Search Engine Link on Advanced/Custom Search Portlets

Optionally, this link can be displayed on Custom Search portlets. For more information on how to set options for the Custom Search portlet, refer to the Oracle Fusion Middleware User's Guide for Oracle Portal, available on OTN at http://www.oracle.com/technology/products/ias/portal/documentation.html.

When you specify the URL of an Internet search engine and the link text that users click to access the specified Internet search engine, it applies to all new and existing Advanced/Custom Search portlet instances that display an Internet search link.

1. In the Services portlet, click Global Settings.
By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

2. Click the Search tab.

3. In the Internet Search Engine section, for URL, enter the URL of an Internet search engine. For example, http://www.myinternetsearch.com.
The URL must be fully formed. It must include http:// and any associated parameters.

4. For Link Text, enter the text that users click to access the specified Internet search engine. For example: MySearch
If you enter MySearch, this text is displayed as a link in Advanced Search portlets and optionally in Custom Search portlets. See Figure 10-9.

5. Select OK.

If the Internet Search Engine properties (URL and Link Text) are not specified, none of the Advanced or Custom Search portlets display an Internet search engine link.

Note:

If page caching is enabled, the change may not be seen in existing search portlets immediately. The cache is cleared automatically every 24 hours for all search portlets. Alternatively, clear the cache manually from the Web Cache Administration page in Fusion Middleware Control. See Section 8.1, "Using Oracle Enterprise Manager 11g Fusion Middleware Control".

10.2.2 Configuring Oracle Text Options in Oracle Portal

This section describes how to configure Oracle Text features in Oracle Portal:

- Enabling and Disabling Oracle Text in Oracle Portal

- Setting Oracle Text Search Result Options

- Setting a Base URL for Oracle Text

- Configuring Proxy Settings for Oracle Text

Note:

If page caching is enabled, changes to Oracle Text search settings may not be seen in existing search portlets immediately. The cache is cleared automatically every 24 hours for all search portlets. Alternatively, clear the cache manually from the Web Cache Administration page in Fusion Middleware Control. See Section 8.1, "Using Oracle Enterprise Manager 11g Fusion Middleware Control".

See Section 10.3, "Oracle Text" for more information about Oracle Text, how to maintain Oracle Text indexes, and troubleshooting information.

10.2.2.1 Enabling and Disabling Oracle Text in Oracle Portal

Oracle Text extends the searching capabilities of Oracle Portal. See Section 10.1.1, "Oracle Portal Search". Out-of-the-box, Oracle Text is always enabled. Although Oracle does not recommend that you disable Oracle Text, it is possible to do so, if your portal does not require or would not benefit from full text indexing content within the Oracle Portal Repository. See also Section 10.2.2.1, "Enabling and Disabling Oracle Text in Oracle Portal".

1. In the Services portlet, click Global Settings.
By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

2. Click the Search tab.

3. Select Enable Oracle Text Searching to make use of Oracle Text when searching Oracle Portal.
Deselect this option at any time to disable the use of Oracle Text.

Note:

If you see the message Oracle Text is not installed, Oracle Text is not installed in the database and is not available in Oracle Portal. Arrange with your database administrator to have Oracle Text installed. Once installed, you must run the following command in SQL* Plus to create the Oracle Text role:

inctxgrn.sql

This file is located in the directory ORACLE_HOME/portal/admin/plsql/wws.

Log on using the user name and password for the PORTAL schema. You must also create Oracle Text indexes. See Section 10.3.4, "Creating and Dropping Oracle Text Indexes" for more information.

4. Click OK.

10.2.2.2 Setting Oracle Text Search Result Options

When Oracle Text is enabled, you can display additional information alongside items (documents/files) when they are returned as search results. For each item returned you can view:

- Major themes in a chart. A theme shows the nouns and verbs that occur most frequently.

- A short summary about the content (gist). Gists are derived from how frequently those nouns and verbs appear.

- An HTML version.

- An HTML version of the file with search terms highlighted in a specific color and font.

Themes and gists are optional and HTML highlighting can be customized as follows:

1. In the Services portlet, click Global Settings.
By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

2. Click the Search tab.

3. Select Enable Themes And Gists to create a theme and gist for each item returned by the search.

Note:

Themes and gists are not available for all languages.

4. For Highlight Text Color, select the color to highlight search terms found in the HTML version of items returned by the search.

5. For Highlight Text Style, select the style to apply to search terms found in the HTML version of the items returned by the search.

6. Click OK.

10.2.2.3 Setting a Base URL for Oracle Text

Oracle Text needs a base URL to resolve relative URLs into fully qualified absolute URLs. See Section 10.3.6.1, "Relative URLs" for more information.

To specify the Base URL for Oracle Text:

1. In the Services portlet, click Global Settings.
By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

2. Click the Search tab.

3. Enter the Oracle Text Base URL in the format: http://<host>:<port>/portal/pls/<dad>
For example: http://myportal.com:4000/portal/pls/design

If no value is specified, no relative URLs are indexed and therefore, any URL content that relative URLs points to, cannot be searched.

4. Click OK.

10.2.2.4 Configuring Proxy Settings for Oracle Text

Oracle Text uses Oracle Portal proxy server settings to access URL content. This is necessary when Oracle Portal lies behind a firewall and URL items point to content beyond this firewall. See Section 10.3.6.4, "URL Index Proxy Settings" for more information.

Refer to Section 6.5, "Configuring Oracle Portal to Use a Proxy Server" for information about configuring the global proxy settings for Oracle Portal.

10.2.3 Configuring Oracle Secure Enterprise Search Options in Oracle Portal

See Section 10.4, "Oracle Secure Enterprise Search".

10.3 Oracle Text

Oracle Text adds powerful text search and intelligent text management to the Oracle Database. Oracle Portal uses the Oracle Text functionality to extend its search capabilities.

Out-of-the-box, Oracle Text is always enabled. However, use of Oracle Text with Oracle Portal is an optional feature that can be disabled by a portal administrator. For more information, see Section 10.3.1, "Understanding Oracle Portal Searches with Oracle Text Enabled/Disabled".

The use of Oracle Text with Oracle Portal is described in the following sections:

- Understanding Oracle Portal Searches with Oracle Text Enabled/Disabled

- Oracle Text Prerequisites

- Oracle Text Indexes

- Creating and Dropping Oracle Text Indexes

- Maintaining Oracle Text Indexes

- Indexing and Searching URL Content

- Disabling Document and URL Indexing

- Viewing the Status of Oracle Text Indexes

- Monitoring Oracle Text Indexing Operations

- Viewing Indexing Errors

- Translating Indexing Errors to Objects in Oracle Portal

- "Common Indexing Errors"

- Handling Indexing Hangs or Crashes

You will find additional information in the Oracle Text documentation, available on OTN at http://www.oracle.com/technology/.

10.3.1 Understanding Oracle Portal Searches with Oracle Text Enabled/Disabled

Out-of-the-box, Oracle Text is always enabled. Although Oracle does not recommend that you disable Oracle Text, it is possible to do so, if your portal does not require or would not benefit from full text indexing Oracle Portal Repository content.

See Section 10.2.2.1, "Enabling and Disabling Oracle Text in Oracle Portal" for information about disabling Oracle Text.

10.3.1.1 Searching With Oracle Text Disabled

If Oracle Text is disabled and you perform a basic search (enter a search term only), the following metadata is searched:

- Item attributes (Display Name, Description, Keywords, Author)

- Page attributes (Display Name, Description, Keywords)

- Category and perspective attributes (Display Name, Description)

A basic search does not search custom attributes.

If more than one search term is specified along with the search operator Contains All of the Terms, then the terms must all appear within the same attribute to result in a match. For example, if you enter weights aerobics, search results are returned only when both these terms are found in a single attribute, such as Description. If the term weights is found in Description and the term aerobics is found in Display Name, then this does not result in a match.

It is also worth noting that fewer search operators are available when Oracle Text is disabled. Only three search operators are available for the main search term: Contain All of the Terms, Contain Any of the Terms, and Contain these Terms Exactly. There are fewer operators for attribute searches too.

Searches that specify criteria against selected attributes (advanced searches), matches against the selected attributes. No file- or URL- based attributes (including the seeded attributes URL and File Name) appear on advanced search forms as these are not searchable when Oracle Text is disabled. Similarly, page designers editing Custom Search portlets are prevented from selecting file- and URL- based attributes as search criteria. If any search portlet specified a file- or URL- based attribute before Oracle Text was disabled, the attribute appears greyed out and italicized if Oracle Text is subsequently disabled.

10.3.1.2 Searching With Oracle Text Enabled

If Oracle Text is enabled when you perform a basic search, all text-type attributes, including custom text attributes are searched. Furthermore, the content of file and URL items are searched.

Documents/file and URL items in binary format can be searched providing that the file format is filterable by Oracle Text. In addition, Web pages that URLs (in URL attributes) point to can also be searched, providing that the content is plain text or HTML. For more information, see Section 10.3.3.1, "Oracle Text Index Overview".

10.3.2 Oracle Text Prerequisites

Oracle Text is a standard component of the Oracle Database 11g. If you want to use the Oracle Text functionality in Oracle Portal, it is essential that the Oracle Text component is correctly installed and functioning properly.

Ensure that:

- Oracle Text is installed in the Oracle Portal Repository database. The Oracle Text component is required to be in the Oracle Portal Repository database before the Oracle Portal Repository can be installed. This is because some Oracle Portal packages make reference to the ctx_ddl packages in the CTXSYS schema in which the Oracle Text component resides.

- Oracle Text upgrade steps are complete. In particular, during database upgrades, it is essential that any manual steps that pertain to Oracle Text are completed correctly.

- Library path for the Oracle Text AUTO_FILTER is set correctly. For AUTO_FILTER to function correctly, the ctxhx executable (called during indexing) needs to be able to load the appropriate shared libraries. See also Section 10.3.3.1, "Oracle Text Index Overview".

- For UNIX platforms, ensure that the library path used by ld includes ORACLE_HOME/ctx/lib for both the TNS listener and the environment where the database is started. The library path environment variable for the different UNIX platforms are as follows:
Solaris, Tru64 UNIX, Linux -> $LD_LIBRARY_PATH

HP/UX -> $SHLIB_PATH and $LD_LIBRARY_PATH

IBM AIX -> $LIBPATH

For detailed information, see the Oracle Text Reference, available on OTN at http://www.oracle.com/technology/documentation/.

Whenever you change the library path you must restart both the database and the listener for Oracle Text indexing operations to work. If one or both environment variables are not set, documents are not indexed as expected and the table ctx_user_index_errors may be full of DRG-11207, status 137 errors. See also Section 10.3.12.1, "Common Document Indexing Errors".

- On Windows platforms, the Oracle Text DLLs are located in ORACLE_HOME\bin. Ensure that this path is included in the PATH environment variable, that is, in the environment from where the Oracle server is started.

10.3.3 Oracle Text Indexes

If you want to use the Oracle Text functionality in Oracle Portal, several Oracle Text indexes are required in the Oracle Portal schema. Details of these indexes are described in the following sections:

- Oracle Text Index Overview

- Oracle Text Index Preferences

- Datastore Procedures

- Granting CTXAPP Role to the Oracle Portal Schema

- Multilingual Functionality (Multilexer)

- STEM Searching

- Maximizing AUTO_FILTER Performance

10.3.3.1 Oracle Text Index Overview

All required Oracle Text indexes are built automatically during Oracle Portal installation by procedures in the package wwv_context.

See Also:

Appendix D, "Using the wwv_context APIs"

After portal installation, you can use the procedures in this package to manage the indexes, and this includes removing and re-creating the indexes. For more information, see Section 10.3.4.3, "Dropping All Oracle Text Indexes Using ctxdrind.sql" and Section 10.3.4.1, "Creating All Oracle Text Indexes Using ctxcrind.sql".

Note:

Oracle Text can be disabled, even when Oracle Text indexes are present. See Section 10.2.2.1, "Enabling and Disabling Oracle Text in Oracle Portal".

Table 10-3 describes the Oracle Text indexes that are required.

Table 10-3 Oracle Text Indexes In the Oracle Portal Schema

Index

Table.column

Purpose

Datastore type

Filter
Type

Optional?

WWSBR_CORNER_CTX_INDX

wwpob_page$.ctxtxt

Index page metadata

user datastore

-

No

WWSBR_DOC_CTX_INDX

wwdoc_document$.
blob_content

Index document content

direct datastore

AUTO_FILTER

Yes

WWSBR_PERSP_CTX_INDX

wwv_perspectives.
ctxtxt

Index perspective metadata

user datastore

-

No

WWSBR_THING_CTX_INDX

wwv_things.ctxtxt

Index item metadata

user datastore

-

No

WWSBR_TOPIC_CTX_INDX

wwv_topics.ctxtxt

Index category metadata

user datastore

-

No

WWSBR_URL_CTX_INDX

wwsbr_url$.absolute_url

Index URL content

URL datastore

AUTO_FILTER

Yes

Most of the Oracle Text indexes use a user datastore. The exceptions are the indexes WWSBR_DOC_CTX_INDX (Document index) and WWSBR_URL_CTX_INDX (URL index):

- Document index: Uses a direct datastore. It indexes the document content held directly in the BLOB type blob_content column of the wwdoc_document$ table.

- URL index: Fetches the content to be indexed for each row in the wwsbr_url$ table from the location pointed to by the absolute_url column.

It is possible to disable Document and URL indexing. This can improve the speed and efficiency of portal searches as searches are limited to item, page, category, and perspective metadata only. See Section 10.3.7, "Disabling Document and URL Indexing".

The Document and URL indexes both use a filter (AUTO_FILTER), to convert documents into a plain text format that is suitable for indexing:

- Binary documents are converted into plain text (providing the binary format is supported by the AUTO_FILTER).

- Plain text, HTML, XHTML, SGML, and XML documents bypass the filter and are indexed directly.

- Documents that do not need to be indexed, such as graphics, are ignored by the filter.

See also Section 10.3.3.7, "Maximizing AUTO_FILTER Performance".

Note:

If Oracle Portal is installed into a database that does not have a functional AUTO_FILTER, document and URL searching is automatically disabled as this functionality does not work without the AUTO_FILTER. See also Section 10.3.7, "Disabling Document and URL Indexing".

10.3.3.2 Oracle Text Index Preferences

Oracle Text uses preferences to configure the Oracle Text indexes used by Oracle Portal and these preferences are created and owned by the Oracle Portal schema. The preferences are created using the ctx_ddl package, which resides in the CTXSYS schema, and the data representing the preferences is actually stored in relational tables in the CTXSYS schema.

Oracle Text index preferences must exist before the indexes are created. Subsequent changes to these preferences do not take effect until the Oracle Text indexes are dropped and re-created.

The Oracle Text index preferences that are used during Oracle Portal installation to create Oracle Text indexes can be re-created using the package wwv_context. Some Oracle Text index preferences can also be configured by you, the portal administrator, after installation. For example, global Oracle Portal proxy settings are used by Oracle Text to populate the proxy preferences used in Oracle Text indexes.

See Also:

Appendix D, "Using the wwv_context APIs"

Oracle Text indexes also use a number of Lexer preferences to control the linguistic aspects of the indexing. Lexer preferences are created by the script sbrimtlx.sql and you can run this script at any time to re-create the Lexer preferences. The script is located in the directory ORACLE_HOME/portal/admin/plsql/wws.

You will find additional information in the Oracle Text documentation on OTN, http://www.oracle.com/technology/.

10.3.3.3 Datastore Procedures

In an Oracle9i Database Server, for each of the Oracle Text indexes that use user datastores, a datastore procedure is created in the CTXSYS schema where Oracle Text is installed. The procedures are called for each row that is to be indexed for the given index. These procedures in turn call procedures in the Oracle Portal schema.

The datastore procedures are named as follows:

- WWSBR_THING_CTX_<user_id>

- WWSBR_CORNER_CTX_<user_id>

- WWSBR_PERSP_CTX_<user_id>

- WWSBR_TOPIC_CTX_<user_id>

Where <user_id> is the user_id (as found in the ALL_USERS view) of the Oracle Portal Repository schema. This suffix is required so that the procedure names do not clash, in the case where multiple Oracle Portal repositories exist in the same database.

If for any reason these procedures do not exist, Oracle Text does not work. This might happen, for example, if the CTXSYS schema is dropped and reinstalled. In this situation, the procedures can be reinstalled by running the script inctxgrn.sql as the Oracle Portal schema owner:

SQL> @inctxgrn.sql

This script also grants the CTXAPP role to the Oracle Portal schema. See Section 10.3.3.4, "Granting CTXAPP Role to the Oracle Portal Schema" for details. The script is located in the directory ORACLE_HOME/portal/admin/plsql/wws.

In Oracle Database 11g, the datastore procedures are not created in the CTXSYS schema. Instead, the procedures are owned by the index owning schema, that is, the Oracle Portal schema. In this case, all the procedures are in the package wwsbr_ctx_procs:

- wwsbr_ctx_procs.thing_ctx

- wwsbr_ctx_procs.corner_ctx

- wwsbr_ctx_procs.perspective_ctx

- wwsbr_ctx_procs.topic_ctx

As the procedures are in the Oracle Portal schema, <user_id> suffixes are not required.

10.3.3.4 Granting CTXAPP Role to the Oracle Portal Schema

To use Oracle Text functionality, the role CTXAPP must be granted to the Oracle Portal schema. This happens automatically during Oracle Portal installation and normally no further action is required.

If for any reason this grant is revoked, Oracle Text does not work. For example, this may occur if the CTXAPP role is dropped when the CTXSYS schema is reinstalled.

To restore the necessary grants, run the script inctxgrn.sql as the Oracle Portal schema owner:

SQL> @inctxgrn.sql

The script is located in the directory ORACLE_HOME/portal/admin/plsql/wws. This script also creates the Oracle Portal user datastore procedures, which are required in the CTXSYS schema. See Section 10.3.3.3, "Datastore Procedures".

10.3.3.5 Multilingual Functionality (Multilexer)

Oracle Portal uses the Oracle Text Multilexer to enable language-specific searching in Oracle Portal. The Multilexer:

- Controls the way that the linguistic aspects of searching are carried out.

- Allows content, items, pages, categories, perspectives, and their translations, to be treated in a way that is appropriate to their language.

Lexer preferences are used to configure the Multilexer used for all the Oracle Text indexes. The lexer preferences are created by the script file sbrimtlx.sql,the script is located in the directory ORACLE_HOME\portal\admin\plsql\wws.You can modify these preferences if required, but if you do, you must drop and re-create the Oracle Text indexes for the changes to take a effect.

For more information on the Multilexer, refer to Oracle Text documentation on OTN, http://www.oracle.com/technology/.

10.3.3.6 STEM Searching

By default, STEM searching is used when Oracle Text is enabled in Oracle Portal. STEM searching enables you to search for words that have the same root as the specified term. For example, a stem of $sing expands into a query on the words sang, sung, sing.

However, STEM searching is used only when logged in to Oracle Portal in one of the following languages, where STEM searching is supported in Oracle Text:

AMERICAN ENGLISH
CANADIAN FRENCH
DUTCH
UK ENGLISH
FRENCH
GERMAN DIN
GERMAN
ITALIAN
LATIN AMERICAN SPANISH
MEXICAN SPANISH
SPANISH

In all other languages, the STEM operator is not used.

10.3.3.7 Maximizing AUTO_FILTER Performance

AUTO_FILTER is a universal filter that converts most document formats, such as PDF documents, into a plain text format that is suitable for indexing. In Oracle Portal, only the Document and URL index make use of the AUTO_FILTER.

During the indexing process, AUTO_FILTER converts documents and URL content according to the following AUTO_FILTER_FORMAT settings:

- BINARY - these documents are converted into plain text (providing the binary format is supported by the AUTO_FILTER).

- TEXT - these documents bypass AUTO_FILTER and get indexed directly; for example, plain text, HTML, XHTML, SGML, and XML documents.

- IGNORE - these documents, such as images, are not filtered or indexed.

Filtering content unnecessarily can impact the speed and efficiency of portal searches, so it is important that you optimize the filtering process. The best way to optimize the use of AUTO_FILTER, is to ensure that all document and URL content uploaded to your portal is classified with the correct MIME type and character set:

- MIME type - In Oracle Portal, it is the MIME type of a document that determines the AUTO_FILTER_FORMAT (the setting that AUTO_FILTER uses to determine whether a document gets filtered). For example, a document uploaded with the MIME type application/PDF gets mapped to BINARY and is filtered, whereas a document with the MIME type text/HTML gets mapped to TEXT and is indexed directly. Other documents, like images with the MIME type image/GIF, are mapped to IGNORE.

- Character set - AUTO_FILTER can convert documents from a non-database character set to the character set used by the database. This enables you to index and search for documents in other character sets. If AUTO_FILTER cannot determine the character set or it is not one of the supported character sets, the document gets indexed without any character set conversion.

To determine the AUTO_FILTER_FORMAT mapping, the browser uses the following mapping sequence when the content is uploaded to your portal:

Files

- If a MIME type is specified (either by the browser allocating it, or by the user specifying it with the Mimetype attribute), this MIME type is used to map to an AUTO_FILTER_FORMAT (using the wwdav$mime table).

- If the MIME type does not exist in the table, then the file extension is used to try and find the AUTO_FILTER_FORMAT.

- If the file extension does not match any defined extensions, then the default AUTO_FILTER_FORMAT for the Document index is used.

URLs

- If a MIME type is specified by the user with the Mimetype attribute, this MIME type is used to map to an AUTO_FILTER_FORMAT (using the wwdav$mime table).

- If the MIME type doesn't exist in the table then, if the URL has a file extension, the file extension is used to try and find the AUTO_FILTER_FORMAT. For example, if a URL is pointing to a PDF file, then the AUTO_FILTER_FORMAT would be set to BINARY.

- If the extension doesn't match either then the default AUTO_FILTER_FORMAT for the URL index is used.

To ensure that all portal content gets classified and filtered properly, Oracle Portal provides two special attributes for file- and URL- based item types: MIME Type and Character Set. By extending a built-in Base File and Base URL item type to include these attributes, users can enter the correct information when they upload portal content.

Note:

Although the MIME Type and Character Set attributes enable you to specify the correct MIME type and character set for file- and URL- based items, it is not possible to specify these for File and URL attributes:

- File attributes - browser always determines the MIME type.

- URL attributes - MIME type is always text/html, so AUTO_FILTER always processes URL attributes as plain text.

If speed and efficiency of portal searches are important in your portal or your portal stores or references non-database character set documents, ask page group administrators to add MIME Type and Character Set attributes to all file- and URL- based item types available in their page groups. See also, Adding Attributes to an Item Type in the Oracle Fusion Middleware User's Guide for Oracle Portal.

Note:

When you search for portal content by MIME type or character set, you will only find content based on an item type that includes the corresponding attribute (MIME Type or Character Set).

You will find additional information in the Oracle Text documentation on OTN, http://www.oracle.com/technology/.

10.3.4 Creating and Dropping Oracle Text Indexes

All the required Oracle Text indexes are created automatically during Oracle Portal Repository installation. However, if the indexes are subsequently dropped, it may be necessary to re-create them.

Creating and dropping indexes is a very time-consuming and resource-intensive operation, so plan this task during non-business hours. Also, dropping and re-creating Oracle Text indexes may affect the search functionality in your portal as all the indexes must be present and valid for the search feature to operate normally. When an index is dropped, Oracle Text functionality, such as extra search operators, special search result attributes, and so on, are temporarily unavailable even though Oracle Text searching is enabled. This is another good reason for planning this task during non-business hours.

Note:

Dropping or creating Oracle Text indexes does not invalidate Oracle Web Cache. Therefore, search results published automatically and existing search forms, are still displayed until they expire from the cache, or someone edits the search portlet (using the Edit Defaults page).

The following sections describe how to create and drop Oracle Text indexes:

- Creating All Oracle Text Indexes Using ctxcrind.sql

- Creating a Single Oracle Text Index

- Dropping All Oracle Text Indexes Using ctxdrind.sql

- Dropping a Single Oracle Text Index

10.3.4.1 Creating All Oracle Text Indexes Using ctxcrind.sql

You can re-create all the Oracle Text indexes using scripts and packages provided with Oracle Portal. The primary script for creating the Oracle Text indexes is ctxcrind.sql and it is located in the directory ORACLE_HOME/portal/admin/plsql/wws.

When you run the script ctxcrind.sql as the Oracle Portal Repository schema owner:

- All the required Oracle Text indexes and preferences are created. See also, Section 10.3.3, "Oracle Text Indexes".

- If there are existing Oracle Text indexes, all existing preferences and valid indexes are dropped and re-created. Indexes are judged to be valid if:

- The row in view user_indexes for the relevant index has index_status, domidx_status, and domidx_opstatus all set as 'VALID'.

- The index has an entry in ctx_user_indexes with the idx_status set to 'INDEXED'.

- Any indexes that are not present are also created.

This process can take several hours.

To create Oracle Text indexes using the script ctxcrind.sql:

1. Navigate to the directory ORACLE_HOME/portal/admin/plsql/wws.

2. In SQL*Plus, log on using the user name and password for the PORTAL schema.

3. In SQL*Plus, enter this command:

ctxcrind.sql

If the operation is successful, all the Oracle Text indexes and preferences are created in the Oracle Portal Repository schema. If it fails, check that your system has met all the requirements. See Section 10.3.2, "Oracle Text Prerequisites".

Note:

The time it takes to create the Oracle Text indexes, depends on how many items and page groups exist in your portal.

The script ctxcrind.sql makes a call to the procedure:

wwv_context.createindex( p_message => l_message );

Where p_message is an out parameter that passes a completion message. The call wwv_context.createindex() is in turn equivalent to:

wwv_context.drop_prefs;  /* Drop all Oracle Text preferences for the indexes, except Lexer preferences */
wwv_context.drop_invalid_indexes; /* Drop all invalid indexes */
wwv_context.create_prefs; /* Create all Oracle Text preferences,except Lexer preferences */
wwv_context.create_missing_indexes(l_indexes);  /* Create missing indexes and record them in l_indexes */
wwv_context.touch_index(l_indexes); /* Mark all rows for created indexes as requiring synchronization */
wwv_context.sync;     /* Synchronize indexes */
wwv_context.optimize; /* Optimize indexes */

See Also:

Appendix D, "Using the wwv_context APIs"

10.3.4.2 Creating a Single Oracle Text Index

If you want to create a specific index, use the procedure wwv_context.create_index(p_index). See also Appendix D, "create_index".

Use p_index to specify which index you want to create. One of:

wwv_context.PAGE_TEXT_INDEX
wwv_context.DOC_TEXT_INDEX
wwv_context.PERSPECTIVE_TEXT_INDEX
wwv_context.ITEM_TEXT_INDEX
wwv_context.CATEGORY_TEXT_INDEX
wwv_context.URL_TEXT_INDEX

This procedure creates an empty index. Search results cannot be returned from an empty index, so you'll need to populate the index too. See Section 10.3.5.6, "Synchronizing All the Index Content" for information about marking an index for update and synchronizing an index.

10.3.4.3 Dropping All Oracle Text Indexes Using ctxdrind.sql

You can drop all of the Oracle Text indexes and preferences (except for the Lexer preferences), using the script ctxdrind.sql. This script is located in the directory ORACLE_HOME/portal/admin/plsql/wws.

To drop all the Oracle Text indexes using the script ctxdrind.sql:

1. Navigate to the directory ORACLE_HOME/portal/admin/plsql/wws.

2. In SQL*Plus, log on using the user name and password for the PORTAL schema.

3. In SQL*Plus, enter this command:

ctxdrind.sql

This script makes a call to:

wwv_context.dropindex(p_message  =>l_message);

Where p_message is an out parameter that passes a completion message.

Note:

When the Oracle Text indexes are dropped, any views and packages that reference tables on which the indexes were created will become invalid.

These views and packages are automatically validated when they are next accessed. Alternatively, it is possible to validate the views and packages manually.

10.3.4.4 Dropping a Single Oracle Text Index

You may want to drop a specific Oracle Text index. For example, you may want to drop the URL index so that it can be re-created with a different proxy setting, without having to drop and re-create all the other indexes.

To do this, drop the index directly using the command:

SQL> drop index <index_name> force;

For example, to drop the URL index, enter:

SQL> drop index WWSBR_URL_CTX_INDX force;

Alternatively, you can drop an index using wwv_context.drop_index:

SQL>exec wwv_context.drop_index('<index_name>');

See also, Appendix D, "drop_index".

10.3.5 Maintaining Oracle Text Indexes

It is important that you maintain Oracle Text indexes properly as this ensures that portal search results are returned accurately and efficiently. If you are maintaining Oracle Text indexes you'll need to consider index synchronization and optimization:

- Synchronization — Updates an Oracle Text index based on a queue.

- Optimization — Compacts fragmented rows and removes old data in an Oracle Text index. As an index is synchronized, it grows in such a way as to consume more disk space than necessary and this reduces the efficiency of queries.

Oracle Text gives you full control over how often each index is synchronized and optimized. For more information about synchronization, see:

- Synchronizing Oracle Text Indexes

- Synchronizing an Oracle Text Index On Commit

- Synchronizing All Oracle Text Indexes Manually

- Scheduling Index Synchronization

- Deciding How Often to Synchronize Oracle Text Indexes

- Synchronizing All the Index Content

For more information about optimization, see:

- Optimizing Oracle Text Indexes

- Scheduling Index Optimization

- Choosing the Optimization Interval

10.3.5.1 Synchronizing Oracle Text Indexes

When new content is added to your portal (items, pages, categories, perspectives) it must be indexed before it can be searched. Furthermore, when any row in a table on which the indexes are created are modified, that row is marked as needing synchronization. These are referred to as pending rows and they are not returned in search results until the index is synchronized.

You can see which rows are marked pending, using the view ctx_user_pending. You can also use the script textstat.sql to see the number of rows that need to be synchronized for each index. See also, Section 10.3.8, "Viewing the Status of Oracle Text Indexes".

During installation, Oracle Text indexes are created and synchronized and by default, all indexes are scheduled to synchronize hourly by a job that calls wwv_context.sync. If hourly synchronization is not acceptable for your portal you may modify the default synchronization schedule. For example, you can choose to synchronize every five seconds, if it is important to reflect text changes quickly in the index. Alternatively, you can choose to synchronize once a day, for more efficient use of computing resources and a more optimal index. See Section 10.3.5.4, "Scheduling Index Synchronization".

You can specify that Oracle Text indexes synchronize immediately after portal content is added, updated, or deleted, and this can be configured on an index-by-index basis. This feature is not available on databases earlier than Oracle Database 10g as earlier versions do not support the sync property. Oracle recommend that the page, item, category, and perspective indexes are configured to synchronize on commit as this configuration does not impact search performance. You can also configure the document and URL indexes to synchronize on commit but as this configuration can impact the speed and efficiency of portal searches, you will need to evaluate its use on a portal-by-portal basis. Table 10-4 summarizes the recommended synchronization schedule for Oracle Text indexes on Oracle Database 11g:

Table 10-4 Recommended Synchronization Schedule for Oracle Text Indexes on Oracle Database 11g

Oracle Text Index

Index Synchronization on Oracle Database 11g

Page, Item, Category, Perspective

Synchronize immediately after a commit—whenever an associated portal object is added, modified or deleted. See Section 10.3.5.2, "Synchronizing an Oracle Text Index On Commit".

Document, URL

Synchronization scheduled hourly (or some other regular interval) by a job that calls wwv_context.sync. See Section 10.3.5.4, "Scheduling Index Synchronization".

The following sections describe your synchronization options:

- Synchronizing an Oracle Text Index On Commit

- Synchronizing All Oracle Text Indexes Manually

- Scheduling Index Synchronization

10.3.5.2 Synchronizing an Oracle Text Index On Commit

Use the procedure wwv_context.commit_sync() to specify whether an Oracle Text index synchronizes immediately after data is committed to your portal. For more information, see also, Appendix D, "commit_sync".

The commit does not return until the synchronization is complete. Since the synchronization is performed as a separate transaction, there may be a period, usually small, when the data is committed but index changes are not. The operation uses the memory specified with the memory parameter. See also, Appendix D, "set_sync_memory".

Note:

Use textstat.sql to determine the current status of this setting. For more information, Section 10.3.8, "Viewing the Status of Oracle Text Indexes"

To specify that an Oracle Text index synchronizes on commit:

Execute wwv_context.commit_sync as the Oracle Portal schema owner from SQL*Plus, using the command:

exec wwv_context.commit_sync('<Index_name>', true);

To specify that an Oracle Text index synchronizes manually:

Execute wwv_context.commit_sync as the Oracle Portal schema owner from SQL*Plus, using the command:

exec wwv_context.commit_sync('<Index_name>', false);

To verify the status of on commit synchronization for an Oracle Text index:

Execute wwv_context.get_commit_sync as the Oracle Portal schema owner from SQL*Plus, using the command:

set serveroutput on
begin
dbms_output.put_line(
case wwv_context.get_commit_sync('<index_name>')
when true then
'Index synchronizes automatically when data commits'
when false then
'Index needs to be synchronized manually'
end
);
end;

10.3.5.3 Synchronizing All Oracle Text Indexes Manually

Use the procedure wwv_context.sync() to synchronize the Oracle Text indexes manually. This procedure indexes all pending rows. See also, Appendix D, "sync".

With manual synchronization you can also specify memory size and parallel synchronization. See also, Appendix D, "set_parallel_degree" and Appendix D, "set_sync_memory".

Note:

wwv_context.sync ignores any index that synchronizes immediately after data is committed (wwv_context.commit_sync is set to true).

To synchronize Oracle Text indexes manually:

Execute this procedure as the Oracle Portal schema owner from SQL*Plus, using the command:

exec wwv_context.sync();

Use the following syntax to specify the degree of parallelism used during synchronization:

exec wwv_context.set_parallel_degree('<index_name>', <parallel_degree>);

For example:

exec wwv_context.set_parallel_degree('WWSBR_CORNER_CTX_INDX', 2);

Use the following syntax to specify the amount of memory used during synchronization:

exec wwv_context.set_sync_memory('<index_name>', <sync_memory);

For example:

exec wwv_context.set_sync_memory('WWSBR_CORNER_CTX_INDX', 12582912);

This procedure operates across all virtual private portal subscribers.

10.3.5.4 Scheduling Index Synchronization

In most installations, it is desirable to schedule index synchronization to run automatically at regular intervals so that newly added or updated content gets indexed periodically. You can schedule a job using the script textjsub.sql. This uses dbms_job to call wwv_context.sync at regular intervals.

The script takes three parameters and it can also be used to alter or remove a synchronization job:

start_time        - a valid date or 'START' or 'STOP'
start_time_fmt    - start time format mask.
Ignored if start_time is 'START' or 'STOP'
interval_minutes  - minutes between each run. Ignored if 'STOP'

If you set start_time to START, the second argument is ignored and the next job is scheduled to run immediately. Subsequent jobs are run after the interval specified.

If you set start_time to STOP, the job is removed and other arguments are ignored.

To schedule Oracle Text index synchronization:

Run the script textjsub.sql. For example, to schedule index synchronization every 60 minutes, enter:

SQL> @textjsub.sql START NOW 60

10.3.5.5 Deciding How Often to Synchronize Oracle Text Indexes

The appropriate interval between index synchronization jobs depends on:

- How often new content is added to your portal site.

- Whether it matters that newly added or altered content is not searchable immediately.

- How long is it reasonable to have to wait before added or updated content is searchable.

Depending on your requirements, the synchronization interval could be anything from a few minutes to several days.

It is more efficient to synchronize a larger number of rows on a single occasion than to repeatedly synchronize a smaller number of rows, as the index becomes less fragmented. If an index is less fragmented, then it needs to be optimized less frequently. See Section 10.3.5.7, "Optimizing Oracle Text Indexes" for more information.

However, indexing a larger number of rows at once places a heavier load on the server. Synchronizing more frequently increases the total amount of work but spreads the load on the server. The job only synchronizes the rows that are pending, however, there is always some overhead, however small, in starting up the synchronization job.

10.3.5.6 Synchronizing All the Index Content

You can synchronize all the content for a particular Oracle Text index by marking every row in that index as requiring synchronization.

For example, when an index is initially created it is empty, so you would need to update the entire index content. This involves performing an update for the column that the index is created on. For every row in the indexed table use the procedure wvv_context.touch_index(p_index) to update the column.

After running this procedure, there is an entry in the table ctx_user_index_pending for every row in the table upon which the index was created.

Note also that this procedure works across all virtual private portal subscribers.

To synchronize all the content of an index:

Use the procedure wvv_context.touch_index(p_index). Where p_index enables you to specify one of these index names:

wwv_context.PAGE_TEXT_INDEX
wwv_context.DOC_TEXT_INDEX
wwv_context.PERSPECTIVE_TEXT_INDEX
wwv_context.ITEM_TEXT_INDEX
wwv_context.CATEGPRY_TEXT_INDEX
wwv_context.URL_TEXT_INDEX

To synchronize all the content of multiple indexes:

Use the procedure wvv_context.touch_index(p_indexes). Where p_indexes enables you to specify a varray of index names to be synchronized (wwsbr_array).

10.3.5.7 Optimizing Oracle Text Indexes

Synchronizing Oracle Text indexes causes them to become fragmented. Each Oracle Text index is an inverted index where search terms are listed in a form that is efficient to look up. Each search term references the location of the term.

When new terms are added during synchronization, duplicate terms are not removed, so the index may contain the same term several times. This inflates the size of the index and causes the performance of search queries to deteriorate.

The solution is to optimize the Oracle Text indexes. This process compacts the indexes and (optionally) removes old data.

To optimize all of the Oracle Text indexes:

To optimize all of the Oracle Text indexes, use the procedure wwv_context.optimize(). See also, Appendix D, "optimize".

This procedure takes the following parameters:

wwv_context.optimize
(
p_optlevel in varchar2 default CTX_DDL.OPTLEVEL_FULL, -- FULL, FAST, TOKEN
p_maxtime in number default null,  -- Maximum time for full optimization, in minutes
p_token in varchar2 default null -- Token to optimize (when TOKEN)
);

Internally, this procedure calls the Oracle Text procedure ctx_ddl.optimize_index for each Oracle Text index and passes these parameters. It performs full index optimization as opposed to fast or token optimization.

You will find additional information in the Oracle Text documentation on OTN, http://www.oracle.com/technology/.

Note:

If no Oracle Text indexes exist, the procedure wwv_context.optimize has no effect.

wwv_context.optimize only optimizes an Oracle Text index if it is sufficiently fragmented to require optimization. The measure of the fragmentation used is the average number of times a token that appears more than once, is found in the index. If this average is greater than 10, the index is judged to require optimization. The fragmentation query used is as follows:

SELECT AVG(COUNT(*)) FROM DR$<index_name>$I
GROUP BY TOKEN_TEXT HAVING COUNT(*) > 1

Where <index_name> is the name of the index to be measured.

10.3.5.8 Scheduling Index Optimization

In most installations it is desirable to schedule the index optimization process to run automatically at regular intervals. You can schedule a job using the script optjsub.sql. This uses dbms_job to call wwv_context.optimize at regular intervals.

This script optjsub.sql takes three parameters and it can also be used to alter or remove an optimization job:

start_time       - A valid date or 'START' or 'STOP'
start_time_fmt   - Start time format mask.
Ignored if start_time is 'START' or 'STOP'
interval_minutes - Minutes between each run. Ignored if 'STOP'

If you set start_time to 'START', the second argument is ignored and the next job is scheduled to run immediately. Subsequent jobs are run after the interval specified.

If you set start_time to 'STOP', the job is removed and other arguments are ignored.

During Oracle Portal installation, a job is set up to optimize all of the Oracle Text indexes, every 24 hours.

To schedule Oracle Text index optimization:

Run the script optjsub.sql. For example, to schedule index optimization every 60 minutes, enter:

SQL> @optjsub.sql START NOW 60

This script is located in the directory ORACLE_HOME/portal/admin/plsql/wws. If no Oracle Text indexes are present when you run this optimization job, the procedure has no effect.

10.3.5.9 Choosing the Optimization Interval

It is difficult to predict how often Oracle Text indexes need to be optimized as the frequency depends on the amount of content that is being loaded, the type of content being loaded, the synchronization schedule, and many other factors.

However, if you measure the index fragmentation at regular intervals, you can determine how rapidly it is becoming fragmented. Using this information, you can set an appropriate optimization interval.

The procedure wwv_context.optimize only optimizes the index if it is judged to be fragmented. So, other than the minimal overhead of calling the job, it is quite safe to run this job more often than perhaps is required.

During Oracle Portal installation, a job is set up to optimize all of the Oracle Text indexes, every 24 hours.

10.3.6 Indexing and Searching URL Content

When Oracle Text is enabled in Oracle Portal, the content of URL attributes attached to items or pages are indexed by default. Note that indexing does not include portlet content on pages. Once the URL content is indexed, it is searchable. When you enter search criteria for URL attributes, it is this URL content that is searched.

Note:

If you do not want portal users to search URL content you can disable the URL index. See Section 10.3.7, "Disabling Document and URL Indexing" for more information.

10.3.6.1 Relative URLs

In Oracle Portal you can enter a relative URL for a URL attribute. When these URLs display as links on a portal page they are relative to the base HREF that is set in the HTML <head> section for a portal page. The format of the base HREF is:

<protocol>://<server>:<port>/portal/pls/<dad>/

For example, in the HTML <head> section you might see:

<base href="http://myserver.abc.com/portal/pls/portal/">

In this example:

- The relative URL /help/index.html is resolved by the browser to:
http://myserver.abc.com/help/index.html

- The relative URL!PORTAL.mypackage.proc (with no leading /) is resolved by the browser to:
http://myserver.abc.com/portal/pls/portal/!PORTAL.mypackage.proc

The base HREF on a page is dependent on the URL used to request the page. As it is possible to use more than one URL to access the page, the base HREF reflects the URL used to access the page.

Oracle Text Base URL Setting

When indexing URL content, Oracle Text needs to know how to resolve relative URLs into fully qualified absolute URLs. As Oracle Text does not have the context of an initial request from which to determine the correct base HREF, you must specify the base HREF that is used. You set this option, by specifying the Oracle Text Base URL property on the Global Settings: Search page. See Section 10.2.2.3, "Setting a Base URL for Oracle Text" for details.

During Oracle Portal installation, this option is set automatically.

The format of the Oracle Text Base URL is:

<protocol>://<server>:<port>/portal/pls/<dad>/

For example: http://myserver.abc.com/portal/pls/portal/

Note:

Do not specify an Oracle Text Base URL beginning with https, as HTTPS URLs are not indexed by Oracle Text. If you do this, no relative URLs are indexed.

If you change the Oracle Text Base URL, it does not take effect immediately. When a URL is edited, it is marked as requiring synchronization and Oracle Text will use the new preference the next time the index is synchronized. If you want to force all URLs to immediately use a new Oracle Text Base URL value, you can mark the entire content of the URL Index as requiring synchronization, using the procedure:

SQL> wwv_context.touch_index(wwv_context.URL_TEXT_INDEX);

This procedure acts across all subscribers. In a single virtual private portal subscriber, this is equivalent to:

SQL> update wwsbr_url$ set absolute_url = null;
...
SQL> commit;

10.3.6.2 Unsupported URLs

Oracle Text cannot index URLs that use these protocols:

- https

- javascript

If a URL item specifies one of these protocols it is not indexed. You will not see a corresponding error in the Oracle Text error logs.

10.3.6.3 Supported URLs

Oracle Text can index URLs that use these protocols:

- http

- file - File URLs must be accessible from the database server.

- ftp - FTP URLs must point to locations that do not require authentication as Oracle Text is not able to authenticate — even as an anonymous user.

10.3.6.4 URL Index Proxy Settings

When indexing URL content, Oracle Text can use proxy servers to access URLs. This may be necessary when Oracle Portal lies behind a firewall and URLs point to content beyond this firewall. As indexing takes place from the Oracle Portal Repository server, it is the proxy settings required on this computer that are important.

The URL index uses the same proxy settings that are used globally for Oracle Portal. These are set on the Proxy Settings page, available from the Services portlet. See Section 10.2.2.4, "Configuring Proxy Settings for Oracle Text" for details.

The proxy settings are used when Oracle Text indexes are created. So, if you change the proxy settings the indexes must be re-created. If you need to drop all your indexes and re-create them, use the scripts ctxdrind.sql (drop indexes) and ctxcrind.sql (create indexes). See Section 10.3.4, "Creating and Dropping Oracle Text Indexes" for more information:

SQL> @ctxdrind.sql
...
SQL> @ctxcrind.sql
...

These scripts drop and re-create all of the indexes and this can take a long time if your indexes are large. Alternatively, you can drop and re-create the Oracle Text preferences and URL index only:

begin
-- Drop and re-create the Oracle Text preferences
-- to pick up the new proxy settings.
wwv_context.drop_prefs();
wwv_context.create_prefs();
end;
/
-- Check that the proxy settings used by the index are correct
select prv_attribute attribute, prv_value value
from ctx_user_preference_values
where prv_attribute in ('TIMEOUT','HTTP_PROXY','NO_PROXY')
/

begin
-- Drop and re-create the URL index
wwv_context.drop_index(wwv_context.URL_TEXT_INDEX);
wwv_context.create_index(wwv_context.URL_TEXT_INDEX);

-- Mark all of the rows for the index as pending
wwv_context.touch_index(wwv_context.URL_TEXT_INDEX);

-- Syncronize and optimize
wwv_context.sync();
wwv_context.optimize();
end;
/

10.3.7 Disabling Document and URL Indexing

By default, the content of files uploaded to the Oracle Portal Repository and the content referenced in URL items or custom URL attributes is indexed. This allows users to search and find terms in document and URL content and for most cases, this is desirable.

When portal users do not need to search within file and URL content you may wish to disable the Document and URL indexes. In this case, searching is limited to item, page, category, and perspective metadata, including Title, Author, Keywords, Description, Update Date and all custom Text, Boolean and Date attributes. Metadata-only searching is more efficient and therefore faster than searches that include file and URL content.

Note:

If the Oracle Portal Repository is installed into a database that does not have a functional AUTO_FILTER, document and URL searching is automatically disabled as this functionality does not work without the AUTO_FILTER.

Use the following procedures to specify whether the document and URL indexes are required:

- set_use_doc_index

- set_use_url_index

Both procedures belong to the package wwv_context. For more detail, see Appendix D, "Using the wwv_context APIs".

If you disable Document and URL indexes, the script ctxcrind.sql (which normally creates missing Oracle Text indexes) removes existing Document/URL indexes as they are no longer required. If you do not remove Document/URL indexes, the indexes are still updated when the synchronization and optimization jobs are run. Therefore, it is more efficient to remove the unused indexes by running ctxcrind.sql. See Section 10.3.4, "Creating and Dropping Oracle Text Indexes".

Whenever you make changes to these Document and URL index settings, the appearance and behavior of search portlets in Oracle Portal are affected. If portlets are being cached, such changes might not appear immediately. Therefore, you should clear the portal cache manually, after making any index changes. See Section 6.7.4.4, "Clearing the Cache for a Particular Portal Object".

For example, when you disable the Document index, search portlets display fewer search operators for file- based attributes, that is, only Match All Within File Name and Match Any Within File Name. Similarly, if the URL index is disabled, the only operators available for URL-based attributes are Match All Within URL and Match Any Within URL. Other search operators (such as Content Contains All) are not displayed as file and URL content is not searchable when these indexes are disabled.

When you disable the Document index, Themes, Gists and View as HTML features are no longer available, so you must disable Themes and Gists on the Global Settings: Search page. See Section 10.2.2.2, "Setting Oracle Text Search Result Options" for details.

To enable or disable Document and URL indexes:

Use the following procedures:

-- To enable the document index
execute wwv_context.set_use_doc_index(true);
-- To disable the document index
execute wwv_context.set_use_doc_index(false);
-- To enable the URL index
execute wwv_context.set_use_url_index(true);
-- To disable the URL index
execute wwv_context.set_use_url_index(false);

10.3.8 Viewing the Status of Oracle Text Indexes

You can determine the status of Oracle Text indexes from several tables and views accessible from the portal schema.

To view a status report for Oracle Text indexes, run the script textstat.sql as the portal schema owner:

SQL> @textstat.sql

This script is located in the directory ORACLE_HOME/portal/admin/plsql/wws. Here is an example of the information that is generated by this script:

SQL> @textstat
Portal Text Indexes:

INDEX_NAME            STATUS   DOMIDX_STATUS DOMIDX_OPSTATUS IDX_STATUS
--------------------- -------- ------------- --------------- ------------
WWSBR_CORNER_CTX_INDX VALID    VALID         VALID           INDEXED
WWSBR_DOC_CTX_INDX    VALID    VALID         VALID           INDEXED
WWSBR_PERSP_CTX_INDX  VALID    VALID         VALID           INDEXED
WWSBR_THING_CTX_INDX  VALID    VALID         VALID           INDEXED
WWSBR_TOPIC_CTX_INDX  VALID    VALID         VALID           INDEXED
WWSBR_URL_CTX_INDX    VALID    VALID         VALID           INDEXED

Document and URL index preferences:
Document Index: true  - index will be used if valid
URL Index:      true  - index will be used if valid

Indexes with rows waiting to be indexed:

Index                     Rows to Index
-----------------------   -------------
WWSBR_CORNER_CTX_INDX        2677

PL/SQL procedure successfully completed.

Scheduled Text Jobs:

LAST_DATE LAST_SEC  NEXT_DATE NEXT_SEC  B  FAILURES INTERVAL            WHAT
--------- --------- --------- ---------- - ------ -------------------------
25-AUG-05 04:57:32  26-AUG-05 04:57:32  N   0     SYSDATE + 24/24 wwsbr_stats.gather_stale;
25-AUG-05 04:57:32  26-AUG-05 04:57:32  N   0     SYSDATE + 1440/(24*60) wwv_context.optimize(CTX_DDL.OPTLEVEL_FULL,1440,null);
25-AUG-05 06:59:30  25-AUG-05 07:59:30  N   0     SYSDATE + 60/(24*60)  wwv_context.sync;

Running Text Jobs:
no rows selected

Indexes sync on commit setting:
Item Index:        true    - Index will sync automatically when data commits
Page Index:        true    - Index will sync automatically when data commits
Document Index:    false   - Index needs to be syncronized manually
Category Index:    true    - Index will sync automatically when data commits
Perspective Index: true    - Index will sync automatically when data commits
URL Index:         false   - Index needs to be syncronized manually

SQL>

From this script you can view the following information:

- Portal Text Index Status - Shows whether all of the Oracle Text indexes exist and their current status. All working, valid indexes display VALID for the first three status columns and INDEXED for the final column as shown in this example. See also, Section 10.3.3.1, "Oracle Text Index Overview".

- Document and URL Index Status - Indicates whether the Document and URL indexes are enabled (true) or disabled (false). See also, Section 10.3.7, "Disabling Document and URL Indexing".

- Number of Pending Rows Per Index - Lists any indexes that are waiting to be indexed. An entry is listed for every index that has rows waiting to be indexed, or are pending. The number of pending rows is also shown. See also, Section 10.3.5.1, "Synchronizing Oracle Text Indexes".

- Scheduled Oracle Text Job Details - Lists any jobs that are scheduled for Oracle Text index maintenance. The report shows the last date and time that the job was run and the next date when the job is due to be run. The column labeled B shows whether the job is broken or not; if the job is marked Y it is broken and does not run. The Interval column indicates the next time that a job will run and finally, the What column indicates the procedure that will be run for each job. See also, Section 10.3.5.4, "Scheduling Index Synchronization".

- Active Oracle Text Job Details - Details any jobs that were running when the textstat.sql report ran.

- Indexes Sync On Commit Setting - This section shows which indexes are configured to synchronize immediately after data commits to your portal and which ones need to be synchronized manually using wwv_context.sync (manually or using a job). See also, Section 10.3.5.2, "Synchronizing an Oracle Text Index On Commit".
On earlier database versions, the following information is displayed:

Indexes sync on commit setting:
...Not available for this database version, available from 10g onwards.

10.3.9 Monitoring Oracle Text Indexing Operations

Oracle Text logs information to a file when indexes are created and populated. This enables you to monitor the progress of indexing operations, keep track of indexes, and troubleshoot any problems that may arise.

10.3.9.1 Using start_log to Monitor Index Operations

You can use the ctx_output.start_log (filename) command to log output from the indexing process. In the subsequent example, the log file is named textindex.log:

ctx_output.start_log('textindex.log');
ctx_output.add_event(ctx_output.event_index_print_rowid);
...
-- Create or syncronize the indexes
...
ctx_output.end_log;

You can determine the location of the log file using the LOG_DIRECTORY parameter in ctx_adm.set_parameter, for example, /tmp. Once the directory is set, all subsequent Oracle Text logs output to this directory:

ctxsys.ctx_adm.set_parameter('LOG_DIRECTORY', '/tmp');

10.3.9.2 Using logcrind.sql to Monitor Index Creation

You can use the script logcrind.sql (instead of ctxcrind.sql) to create the Oracle Text indexes with logging enabled. The script takes one parameter which is the name of the log file, for example:

SQL> @logcrind.sql textindex.log

This script sets the LOG_DIRECTORY to be the same as the database udump directory, as specified by the user_dump_dest initialization parameter.

The add_event call (used in the preceding example) is also used in the script logcrind.sql and this outputs the rowid of every row indexed to the log. This logging allows indexing operations to be tracked and also indicates whether the indexing of each row is successful or not.

Here is a sample from an Oracle Text indexing log:

13:53:27 05/06/03 begin logging
13:53:27 05/06/03 event
13:53:42 05/06/03 log
13:53:42 05/06/03 event
13:53:48 05/06/03 Creating Oracle index "MYPORTAL"."DR$WWSBR_CORNER_CTX_INDX$X"
13:53:48 05/06/03 Oracle index "MYPORTAL"."DR$WWSBR_CORNER_CTX_INDX$X" created
13:53:49 05/06/03 Creating Oracle index "MYPORTAL"."DR$WWSBR_DOC_CTX_INDX$X"
13:53:49 05/06/03 Oracle index "MYPORTAL"."DR$WWSBR_DOC_CTX_INDX$X" created
13:53:49 05/06/03 Creating Oracle index "MYPORTAL"."DR$WWSBR_PERSP_CTX_INDX$X"
13:53:49 05/06/03 Oracle index "MYPORTAL"."DR$WWSBR_PERSP_CTX_INDX$X" created
13:53:50 05/06/03 Creating Oracle index "MYPORTAL"."DR$WWSBR_THING_CTX_INDX$X"
13:53:50 05/06/03 Oracle index "MYPORTAL"."DR$WWSBR_THING_CTX_INDX$X" created
13:53:51 05/06/03 Creating Oracle index "MYPORTAL"."DR$WWSBR_TOPIC_CTX_INDX$X"
13:53:51 05/06/03 Oracle index "MYPORTAL"."DR$WWSBR_TOPIC_CTX_INDX$X" created
13:53:51 05/06/03 Creating Oracle index "MYPORTAL"."DR$WWSBR_URL_CTX_INDX$X"
13:53:51 05/06/03 Oracle index "MYPORTAL"."DR$WWSBR_URL_CTX_INDX$X" created
13:54:16 05/06/03 sync index: MYPORTAL.WWSBR_CORNER_CTX_INDX
13:54:17 05/06/03 Begin document indexing
13:54:17 05/06/03 INDEXING ROWID AAAUUcAAJAAAlhMAAA
13:54:17 05/06/03 INDEXING ROWID AAAUUcAAJAAAlhMAAI
..
13:54:18 05/06/03 INDEXING ROWID AAAUUcAAJAAAlhQAAk
13:54:18 05/06/03 Errors reading documents: 0
13:54:18 05/06/03 Index data for 159 documents to be written to database
13:54:18 05/06/03    memory use: 225971
13:54:18 05/06/03 Begin sorting the inverted list.
13:54:18 05/06/03 End sorting the inverted list.
13:54:18 05/06/03 Writing index data to database.
13:54:18 05/06/03    index data written to database.
13:54:18 05/06/03 End of document indexing. 159 documents indexed.

10.3.10 Viewing Indexing Errors

Any errors that occur when an index is created or synchronized are logged in the view CTX_USER_INDEX_ERRORS. You can see details for these errors, using the command:

SQL> desc ctx_user_index_errors;
Name                   Null?    Type
---------------------- -------- ---------------
ERR_INDEX_NAME         NOT NULL VARCHAR2(30)
ERR_TIMESTAMP                   DATE
ERR_TEXTKEY                     VARCHAR2(18)
ERR_TEXT                        VARCHAR2(4000)

SQL>

This view gives the index name, the rowid (ERR_TEXTKEY column) corresponding to the row in the indexed table, and an error message that indicates the cause of the failure. Furthermore, the error log file indicates the rowid for the row in the table that is being indexed and a success or failure message.

Typically, you do not see errors for the item (WWSBR_THING_CTX_INDX), page (WWSBR_CORNER_CTX_INDX), category (WWSBR_TOPIC_CTX_INDX) or the perspective (WWSBR_PERSP_CTX_INDX) indexes as these index content that is produced by Oracle Portal and this content is easy to index. It is more common to see indexing errors for document and URL content.

For the Document index, the content may have to be filtered to turn a binary document into plain text for indexing. There are a number of reasons this may fail. For example, the document format may not be supported by AUTO_FILTER, the Oracle Text filter. See also, Section 10.3.3.7, "Maximizing AUTO_FILTER Performance".

For the URL index, the URL content has to be fetched and this could fail for a number of reasons. For example, the URL may indicate a location that is not accessible as the Oracle Portal server is behind a firewall and the proxy settings are not set correctly. Or, maybe the URL is incorrect, or perhaps the site that is being access is down.

In addition, URL content is filtered and this may produce errors. For example, all URL attributes are presumed to be plain text, so you'll see an error for any URL attribute that is not plain text.

10.3.11 Translating Indexing Errors to Objects in Oracle Portal

The indexing errors shown in the view CTX_USER_INDEX_ERRORS or the Oracle Text indexing logs, show the rowid of the row in the table being indexed when the error occurred. You can use this information to determine which row is causing an indexing problem and you can also determine exactly which portal item or page this row corresponds to.

The following sections describe some queries that you may find useful if you need to determine the cause of an indexing issues:

- Item Indexing Errors

- Page Indexing Errors

- Category Index Errors

- Perspective Indexing Errors

- Document Index Errors

- URL Index Errors

10.3.11.1 Item Indexing Errors

The rowid gives the row in the items table that is causing problems. You can use a direct query to find out more information about that row. For example:

select i.name, i.title,          -- item title
p.name page_name,         -- page name
p.title page_title,       -- page display name
pg.name page_group,       -- page group name
sl.title page_group_title -- page group display name (default language)
from wwv_things i,
wwpob_page$ p,
wwpob_item$ pi,
wwsbr_sites$ pg,
wwsbr_site_languages$ sl
where i.masterthingid = pi.master_thing_id
and i.siteid = pi.site_id
and pi.page_id = p.id
and sl.siteid = pg.id
and sl.language = pg.defaultlanguage
and pi.page_site_id = p.siteid
and pg.id = i.siteid
and i.rowid = 'AAAOwMAAJAAAWISAAF

10.3.11.2 Page Indexing Errors

The rowid gives the row in the pages table. You can use a direct query to find out more information about the page being indexed. For example:

select p.name page_name,
p.title page_title,
pg.name page_group,
sl.title page_group_title
from wwpob_page$ p,
wwsbr_sites$ pg,
wwsbr_site_languages$ sl
where sl.siteid = pg.id
and sl.language = pg.defaultlanguage
and pg.id = p.siteid
and p.rowid = 'AAAOv/AAJAAAaSSAAB'

10.3.11.3 Category Index Errors

You can use a direct query against the category table to determine faulty categories. You can also use a join to show the page group. This query shows the category name and display name, and the page group name and display name.

select c.title, c.name, pg.name, sl.title
from wwv_topics c,
wwsbr_sites$ pg,
wwsbr_site_languages$ sl
where sl.siteid = pg.id
and sl.language = pg.defaultlanguage
and pg.id = c.siteid
and rowid='AAAOv/AAJAAAaSSAAB'

10.3.11.4 Perspective Indexing Errors

These are similar to categories. If you use a direct query against the perspective table it shows the faulty perspectives. You can also use a join to show the page group.

select p.title, p.name, pg.name, sl.title
from wwv_perspectives p,
wwsbr_sites$ pg,
wwsbr_site_languages$ sl
where sl.siteid = pg.id
and sl.language = pg.defaultlanguage
and pg.id = p.siteid
and p.rowid = 'AAAOv/AAJAAAaSSAAB'

10.3.11.5 Document Index Errors

You are more likely to see errors with the Document index. In this case the index is on the table where the documents are actually stored. Therefore, you have to join back to the item table to determine the associated item.

The following query gives the document file name and item's Name and Display Name that a document query is associated with:

select d.filename, i.name, i.title  from wwv_things i,
wwdoc_document$ d,
wwv_docinfo di
where
d.name = di.name(+)
and di.thingid = i.id(+)
and di.masterthingid = i.masterthingid(+)
and di.siteid = i.siteid(+)
and d.rowid = 'AAAOYyAAJAAAWAaAAF'

Note that not all documents are necessarily associated with items, in which case you need to modify the query to join in a similar way to the page table.

10.3.11.6 URL Index Errors

Like the Document index, you have to join back to the item table to determine the associated item.

The following query shows the URL, and item Name and Display Name.

select u.url, u.absolute_url, i.name, i.title
from wwv_things i,
wwsbr_url$ u
where u.object_id = i.id
and u.object_siteid = i.siteid
and u.object_type = 'ITEM'
and u.rowid = 'AAAOYyAAKAAAWAaAAB'

Note that a URL may not be attached to an item, it may be attached to a page, in which case you need to modify the query to join in a similar way to the page table.

10.3.12 Common Indexing Errors

Some common indexing errors are described in the following sections:

- Common Document Indexing Errors

- Common URL Indexing Errors

10.3.12.1 Common Document Indexing Errors

Typically, document indexing errors are in the format:

DRG-11207: user filter command exited with status n

The actual exit status indicates the cause of the problem. For a description of common exit status values and their meanings, log on to Oracle Metalink, at http://metalink.oracle.com and read the article Troubleshooting DRG-11207 errors. This article has DocId 210319.1.

10.3.12.2 Common URL Indexing Errors

Here are some common URL indexing errors. The list is not exhaustive but it highlights some of the more common errors you may see:

DRG-11604 URL store: access to %(1)s is denied

Access to the document is denied to the indexing user agent. The crawler is not capable of authenticating or managing cookies returned by the site. Check that the URL can be accessed. If it is protected, it may not be possible to index the content.

DRG-11609 URL store: unable to open local file specified by %(1)s
DRG-11610 URL store: unable to read local file specified by %(1)s

These occur for file:// URLs where the file indicated cannot be opened or read. Remember that the file needs to be accessible from the computer on which the Oracle Portal Repository database is running. Check that the file exists and that it is accessible from the database computer as the database user.

DRG-11611 URL store: unknown protocol specified in %1)s

The protocol specified in the URL is not one that the Oracle Text user agent recognizes. This can happen if no protocol is specified. A common cause of this problem is that a relative URL is specified but the Oracle Text Base URL option is not set to fully qualify the URL. Also, Oracle Text can only index http, file and ftp URLs. Look at the URL that has failed and make sure that it is in a supported fully qualified format, including a valid protocol. See also, Section 10.3.6, "Indexing and Searching URL Content"

DRG-11612 URL store: unknown host specified in %(1)s

The URL specified a host in the URL that cannot be resolved from the Oracle Portal repository database server. It may be that a firewall lies between the Oracle Portal repository server and the location specified by the URL. In this case it might be necessary to use a proxy server to access the URL. Check that the URL is correct and that the host is accessible from the Oracle Portal database server. Also check that the Oracle Portal proxy settings are correct and that the index is using the proxy settings. See also, Section 10.2.2.4, "Configuring Proxy Settings for Oracle Text".

DRG-11613 URL store: connection refused to host specified by %(1)s

This means that the host specified in the URL was resolved but the HTTP request was refused. Check that the URL is correct and that it is accessible.

DRG-11614 URL store: communication with host specified in %(1)s timed out

The request timed out. Check that the URL is correct and accessible.

DRG-11616 URL store: too many redirections trying to access %(1)s

When accessed, a URL can cause a redirect to another URL. This in turn can cause a redirect, and so on. If a large number of redirects occur, this error is displayed. This can occur if a redirection loop is found.

DRG-11622 URL store: unknown HTTP error getting %(1)s

An HTTP error that is not explicitly handled by Oracle Text has occurred. The HTTP error is reported in the error message.

10.3.13 Handling Indexing Hangs or Crashes

If for any reason a document or URL cannot be indexed, an error is logged. This situation should not prevent the indexing operation completing normally. However, any content that fails to be indexed is not searchable.

Sometimes an indexing operation can fail catastrophically in which case, the index operation is terminated before the indexes are properly populated. In most cases, such problems should be reported to Oracle Support Services. However, in some instances you may be able to work around the problem temporarily by excluding the content that is causing a failure. See Section 10.3.13.2, "Preventing Indexes From Hanging and Crashing" for more information.

Rarely, an indexing operation causes a disastrous failure, that is, the server process performing the indexing is terminated. When this happens, this message is displayed in the client running the indexing operation:

ORA-03113 End of file on communication channel

Note:

If you are unsure whether an indexing operation completed successfully, repeat the operation from SQL Plus where end of file errors are clearly reported.

If the server process is terminated, the event should be recorded in the database logs. Use the database alert log to determine the location of any trace files that are written. The trace files may indicate errors such as ORA-0600 or ORA-7445. For example, this trace file shows errors that occurred whilst creating Oracle Text indexes using the script logcrind.sql:

ksedmp: internal or fatal error
ORA-7445: exception encountered: core dump [drsfdatam()+308] [SIGSEGV]
[Address not mapped to object] [0x0] [
] []
Current SQL statement for this session:
declare
l_dump_dest varchar2(512);
p_logfile varchar2(100) := 'sync_2012.log';
begin
dbms_output.enable(10000);
select value into l_dump_dest from v$parameter
where name = 'user_dump_dest';
ctxsys.ctx_adm.set_parameter('LOG_DIRECTORY',l_dump_dest);
ctx_output.start_log(p_logfile);
ctx_output.add_event(ctx_output.event_index_print_rowid);
dbms_output.put_line('Log file is: '||ctx_output.logfilename);
wwv_context.sync();
ctx_output.end_log;
end;
----- PL/SQL Call Stack -----
object line object
handle number name
8198f83c 244 package body CTXSYS.DRIDISP
8198f83c 377 package body CTXSYS.DRIDISP
8198f83c 334 package body CTXSYS.DRIDISP
8178acc8 403 package body CTXSYS.DRIDML
827124b0 2033 package body CTXSYS.DRIDDL
827124b0 2090 package body CTXSYS.DRIDDL
817ea0f0 1324 package body CTXSYS.CTX_DDL
8185a488 828 package body TOOLS.WWV_CONTEXT
82d83ed8 18 anonymous block
----- Call Stack Trace -----

10.3.13.1 Identifying Whether an Index Operation is Hanging

The easiest way to determine if an indexing operation is hanging is to run the indexing operation with Oracle Text logging enabled. See Section 10.3.9, "Monitoring Oracle Text Indexing Operations".

With logging enabled, the rowid of each row is recorded when it is indexed and you can see when an indexing operation hangs on the same row for a prolonged period. It may be normal for some rows to take a few minutes to process but if an operation takes much longer than expected, this may indicate a problem.

In general, the view CTX_USER_INDEX_ERRORS is not very useful if you are trying to find out why an indexing process is hanging or crashing. This is because information is only visible in this view after it is committed and a commit does not occur whilst an indexing operation is hanging. In fact, a commit may not occur at all if the operation crashes.

Operations such as URL indexing and document filtering can take quite a long time to process. Both of these operations are subject to timeout mechanisms to avoid lengthening this process even further:

- URL indexing timeout -The default timeout for fetching URL content is 30 seconds. If URL content is not retrieved within 30 seconds, the attempt is abandoned, a failure error is reported in the view CTX_USER_INDEX_ERRORS and the indexing process continues to the next row. In most cases, 30 seconds is sufficient time to fetch URL content. However, once the content is retrieved it must be indexed, so the total time can be slightly more than the URL timeout value.

- Document filtering timeout - The timeout for document filtering operations is not a hard timeout limit. The timeout setting, which by default is 120 seconds, is the time that is waited while no output is produced by the AUTO_FILTER. If the timeout is exceeded the current filtering operation is terminated, the content for the current document is not indexed, and the indexing process proceeds to the next document. If the AUTO_FILTER output file is still growing after 120 seconds, the filtering operation is allowed to continue.

These timeout mechanisms help to avoid problems with URL and document indexing, two areas where issues are likely to arise. However, you may still encounter situations where an indexing operation hangs indefinitely.

10.3.13.2 Preventing Indexes From Hanging and Crashing

If certain content is causing indexing operations to fail, you can exclude the content from the indexing process. First, you must identify the row that is causing the problem. This section describes how to do this and the additional steps required to exclude such content.

Step 1 Identify the rowid Causing Indexing Problems

You can do this using the Oracle Text logging facility, with print rowid event enabled. If you look at the generated log file you can determine the rowid (of the row being processed) when failure occurred. In most cases it is this rowid that is causing indexing problems.

However, in some cases the actual rowid being processed may not be written to the log file when the failure occurs. In this case you must determine the next rowid:

- If the entire table is being synchronized, for example, when an index is first created, the rowid is the next rowid from the table. To determine the rowid, select from the table without an order by clause.

- When only a few pending rows are being updated, look at the view ctx_user_pending to determine the next rowid.

When you have identified which row is causing your indexing problems, you should verify that it is the correct row. You do this by reproducing the failure while synchronizing that row only.

If the Oracle Text indexes do not exist, create the indexes (but do not populate them) using these command:

SQL> exec wwv_context.drop_prefs;
PL/SQL procedure successfully completed.
SQL> exec wwv_context.create_prefs;
PL/SQL procedure successfully completed.
SQL> declare
2      l_indexes wwsbr_array;
3  begin
4      wwv_context.create_missing_indexes(l_indexes);
5  end;
6  /
PL/SQL procedure successfully completed.
SQL>

This creates all of the indexes, with no rows pending.

Step 2 Mark the Problem rowid As Pending

The next step is to mark the row suspected of causing indexing problems as pending. The column you need to update depends on which index you are updating. The names of these columns are indicated in the subsequent examples. You must replace the rowid given in these examples, with the rowid you wish to verify:

URL index (WWSBR_URL_CTX_INDX) The absolute_url column is populated by a trigger, so set it here to null:

update wwsbr_url$ set absolute_url=null where rowid = 'AAAOwQAAJAAAU0+AAL';

Document index (WWSBR_DOC_CTX_INDX) Update the blob_content column, but preserve the original blob_content value:

update wwdoc_document$ set blob_content = blob_content where rowid = 'AAAOYyAAJAAAWAaAAF'

Item index (WWSBR_THING_CTX_INDX) This index uses a user datastore created on the ctxtxt column. The value of this column is irrelevant and in Oracle Portal is always 1.

update wwv_things set ctxtxt = '1' where rowid = 'AAAOwMAAJAAAU0eAAB'

Page index (WWSBR_FOLDER_CTX_INDX) Similar to the item index.

update wwpob_page$ set ctxtxt = 1 where rowid = 'AAAOwMAAJAAAWITAAA'

Category index (WWSBR_TOPIC_CTX_INDX) Similar to the item index.

update wwv_topics set ctxtxt = 1 where rowid = 'AAAOwMAAJAAAWITAAA'

Perspective index (WWSBR_PERSP_CTX_INDX) Similar to the item index.

update wwv_perspectives set ctxtxt = 1 where rowid = 'AAAOwMAAJAAAWITAAA'

If you have a site with several subscribers installed then you may need to switch subscriber before you can see the row that you are interested in. To change subscribers, use the following procedure to set the session context for a lightweight user:

wwctx_api.set_context
(
p_user_name     IN varchar2,
p_password      IN varchar2 default null,
p_company       IN varchar2 default null
);

wwctx_api is a public PL/SQL API package. For more information, refer to the Oracle Portal PL/SQL API Reference available on OTN at http://www.oracle.com/technology/products/ias/portal.

After the column update, the suspect row is placed in the pending queue.

Step 3 Synchronize the Index

Now you can synchronize the index and see if the same problem occurs, using the command:

SQL> exec wwv_context.sync();

This command synchronizes the suspect row only as it is the only row in the pending queue. The row can be updated again to repeat the test. See also, Appendix D, "sync".

Step 4 Exclude the Content Causing Problems

You can prevent the indexing operation from hanging or crashing in the future, by modifying, or even removing the row causing indexing problems. For example, if it is a document, you can edit the associated item in Oracle Portal and remove the document.

Note:

Contact Oracle Support Services if your system hangs or crashes during indexing operations. If you can provide specific detail relating to the content causing the problem, it will help them to reproduce the problem more readily.

10.4 Oracle Secure Enterprise Search

This section introduces Oracle Secure Enterprise Search and the sample Oracle Secure Enterprise Search Secure portlet. Specific topics in this section include:

- Oracle Secure Enterprise Search Overview

- Oracle Secure Enterprise Search Secure Portlet

10.4.1 Oracle Secure Enterprise Search Overview

Oracle Secure Enterprise Search is built on Oracle Database and Oracle Text technology and provides uniform search-and-locate capabilities over multiple repositories: Oracle Databases, other ODBC compliant databases, IMAP mail servers, HTML documents served up by a Web server, files on disk, and more.

Oracle Secure Enterprise Search uses a crawler to collect documents. You can schedule the crawler to suit the Web sites that you want to search. The documents stay in their own repositories, and the crawled information is used to build an index that stays within your firewall in a designated Oracle Database. Oracle Secure Enterprise Search also provides APIs for building content management solutions.

In addition, Oracle Secure Enterprise Search offers the following:

- A complete text query language for text search inside the database

- Full integration with the Oracle Database server and the SQL query language

- Advanced features like concept searching and theme analysis

- Attribute mapping to facilitate attribute search across disparate repositories

- Indexing of all popular file formats (150+)

- Full globalization, including support for Chinese, Japanese and Korean (CJK), and Unicode

You will find additional information on OTN at:

http://www.oracle.com/technology/products/oses/index.html

Oracle Secure Enterprise Search is integrated with Oracle Portal so that you can add powerful multi repository search facilities to portal pages. It also has the capability to crawl Oracle Portal's own repository and search public and private content.

10.4.1.1 About the Oracle Secure Enterprise Search Sample Query Applications

Oracle Secure Enterprise Search includes fully functional sample query applications to query and display search results. The query applications are written as J2EE-compliant Web applications. The sample query applications also include the Oracle Secure Enterprise Search Secure portlet.

The Oracle Secure Enterprise Search Secure portlet demonstrates how to write a search portlet for use in Oracle Portal. When the user issues a search query a list of results matching the user's search criteria are returned.

For information about how to use the Oracle Secure Enterprise Search Secure portlet in Oracle Portal, see Appendix A of Oracle Secure Enterprise Search Administrator's Guide.

10.4.1.2 About Oracle Secure Enterprise Search Configuration

If you are using Secure Enterprise Search (SES), then by default, the search result of your Portal displays durable URL format for an item or a page. To display your URL as a readable format, perform the following steps:

1. Run sbrsrxml.sql, located at ORACLE_HOME\upgrade\portal\admin\plsql\wws in Windows and ORACLE_HOME/upgrade/portal/admin/plsql/wws, in UNIX, using your Portal schema password.

2. Enter the value 0, for example @wws\sbrsrxml.sql 0 in Windows.

After you run a full SES crawl, your URL is displayed in a readable format. And if you want your URL to display the durable URL format, then run sbrsrxml.sql and enter the value 1.

For more information, see the Oracle Secure Enterprise Search Administrator's Guide at http://download.oracle.com/docs/cd/E14507_01/admin.1112/e14130/toc.htm.

10.4.2 Oracle Secure Enterprise Search Secure Portlet

Oracle Secure Enterprise Search provides a search portlet that can be embedded in Oracle Portal pages.

For more information, see Appendix A of Oracle Secure Enterprise Search Administrator's Guide.

11 Tuning Performance in Oracle Portal

This chapter discusses how you can tune the performance of your Oracle Portal on the configuration, after you have set up the basic configuration of your portal system.

This chapter contains the following list of options for tuning the performance of Oracle Portal:

- Setting the Number of Server Processes

- Setting the Number of Idle Processes

- Setting the Number of PPE Fetchers

- Tuning the Oracle HTTP Server

- Tuning File System Cache to Improve Caching Performance

- Tuning Oracle Net Services

See Also:

- Oracle Fusion Middleware Performance and Tuning Guide

- The Performance page on Portal Center:
http://www.oracle.com/technology/products/ias/portal

11.1 Setting the Number of Server Processes

Oracle HTTP Server processes Web requests by distributing them to HTTP processes. Oracle HTTP Server can serve all types of requests originating in users' browsers, such as those for static files, Java servlets, or PL/SQL procedures.

MaxClients is an Oracle HTTP Server configuration directive that controls the maximum number of Web requests that Oracle HTTP Server can handle at any given time. When the MaxClients value is exceeded, Oracle HTTP Server refuses to handle any new requests until it handles the current load and the HTTP processes are freed. In fact, client browsers may be locked out if the number of allowable sessions has been exceeded by other browsers.

One way to think of the MaxClients directive is that it's a regulator that permits the right flow of concurrent Web requests to your server. Set it too low, and your Web portal performance may suffer. Even though you may have the server and database resources to handle more traffic with quicker response intervals, Web requests cannot get through because you have not set enough processes in MaxClients.

Setting MaxClients too high unnecessarily consumes resources, because each HTTP process server consumes resources, such as CPU time, memory, and I/O. It may also result in poorer rather than better performance. Oracle HTTP Server can handle all sorts of requests, including those for PL/SQL procedures. When Oracle HTTP Server receives such a request, it hands it off to Portal Services to communicate with the portal database. For each server process that executes a portal database request, there will be a need to cache a database connection. The value you set for MaxClients, therefore, sets the upper limit of database connections that Portal Services can open.

Say you set MaxClients to the maximum number, 1024. At any given time, Oracle HTTP Server is ready to handle 1024 simultaneous Web requests, including some that require database connections. Even if your server is large enough to deal with this, the database it is connected to may not be. If the ratio of requests for PL/SQL procedures versus other types of requests suddenly becomes very high, you risk overloading your database.

Note:

On Windows, consider tuning the Oracle HTTP Server parameter ThreadsPerChild.

The key to good performance is determining the number of Web requests the servers in your configuration can process, and how much traffic your database can handle. So if your portal configuration includes multiple middle-tier servers connected to a single database, the number of possible Web requests you can handle is probably going to be limited more by database capacity than the middle tiers.

See Also:

- Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server

- "Configuring the MaxClients Setting" in Section 11.4, "Tuning the Oracle HTTP Server"

11.2 Setting the Number of Idle Processes

MinSpareServers is a UNIX-specific Oracle HTTP Server directive that sets the minimum number of idle sessions. An idle session is one that is not currently handling a Web request. If the number of idle sessions is fewer than the number specified in MinSpareServers, new processes are created at a maximum rate of 1 in every second.

You should consider tuning this parameter only on very busy sites. The default setting is 5. Setting this parameter to a large number is almost always a bad idea. A rule of thumb is to set MinSpareServers at a little over the average number of Web requests your portal typically handles. Ideally, you can set it so user requests are filled all the time by open ports without having to open a new one, but this is possible if you have the database resources to support a lot of ports.

Unlike UNIX, Windows is a thread-based operating system where one process is started and then additional child processes are threaded as required. For Windows computers, the directive is called MaxThreadsPerChild. This is the number of concurrent requests the server will allow. Set this value according to the responsiveness of the server and the amount of system resources you want to allow the server to consume. MaxThreadsPerChild on Windows is equivalent to MaxClients on UNIX.

See Also:

Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server

11.3 Setting the Number of PPE Fetchers

A request for a portal page originates in the form of a URL sent from a user's browser to the HTTP server. If the request is for a portal page, it is forwarded to the Parallel Page Engine (PPE). The PPE then asks each provider that owns a portlet on the page to execute the portlet and return content to the portal page.

To increase the concurrency of the PPE, perform the following step:

Increase the Value of Default Number of Threads

The PPE uses a pool of fetchers to forward requests to providers and wait for data to be returned. Once it is finished with the request, the fetcher is available to handle another new request.

The parameter to tune the number of PPE threads is called poolSize and is configured in the file DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration\appConfig.xml.

The default setting is 25. For most Web portals, you should never have to change pool size. But keep in mind that if pool size is too low, the user notices that pages take too long to draw at peak periods. If pool size is set too high, a possible resource drain may occur because too many concurrent URL requests can overwhelm the PPE.

The parameter for the PPE is:

<poolSize>50</poolSize>

For the configuration changes to take effect restart the Oracle Fusion Middleware middle tier.

11.4 Tuning the Oracle HTTP Server

However you choose to configure the Oracle HTTP Server listener, you can optimize performance by setting an approximate number of simultaneous requests that can be handled by the Oracle HTTP Server listener.

The total number of database sessions needed to run Oracle Portal is a factor of the total number of concurrent requests that simultaneously need to access the portal repository. The total number of concurrent requests of any type that can be serviced by a given instance is itself a factor of the Oracle HTTP Server configuration parameter called MaxClients.

Each connection to the portal repository results in one network connection and two sessions (the two sessions use the same physical connection). The first session is for portal and the second is for portal_public.

Therefore, if MaxClients is set to 150, but the maximum number of concurrent requests that ever need to simultaneously access the portal repository is 50, then you need to ensure that the database is configured to allow for (50*2) = 100 sessions.

It is theoretically possible, though extremely remote, that all 150 requests have to simultaneously access the portal repository, in which case the number of database sessions required would be (150*2) = 300.

If the number of concurrent requests that need to simultaneously access the portal repository is high, and the allowed number of sessions has been exceeded, then clients may be "locked out". However, setting a very high value for the number of sessions will unnecessarily consume resources.

Notes:

1. Typical requests that are concurrently being serviced at any point in time consist of a wide variety of request types (for example, static images, portal page requests, and other Oracle HTTP Server requests), and the real number of concurrent requests that simultaneously need to access the portal repository is quite small.

2. As Oracle Portal leverages Oracle Web Cache and the Portal File Cache to cache content, many times Oracle Portal does not need to contact the portal repository at all, thereby reducing the database session requirements.

3. For portal page requests, the poolSize parameter in the PPE acts like a throttle, which reduces the possibility of flooding the system with concurrent requests for portal pages.

4. This section only talks about sessions needed by the Portal Services running inside Oracle Portal. Other entities which connect to the same repository must also be accounted for.

Configuring the MaxClients Setting

Because login frequency is generally lower than Oracle Portal access frequency, it makes sense to configure the OracleAS Single Sign-On on a separate Oracle HTTP Server listener. The objective is to tune down the MaxClients setting to a value that is reasonable, without affecting the needs of the portal system.

See Also:

Oracle Fusion Middleware Performance and Tuning Guide

Perform the following steps to configure the MaxClients setting:

1. For the OracleAS Single Sign-On's listener, once you've determined the approximate value to set for the MaxClients parameter, edit this accordingly in the configuration file, httpd.conf, which is located in:

ORACLE_INSTANCE\config\OHS\ohs1

Tune down the MaxClients setting to control the number of requests that Oracle HTTP Server services on the Oracle HTTP Server listener. This controls the maximum number of sessions that can be established.

2. For the Oracle Portal listener, you can separately tune the MaxClients parameter according to the needs of the OracleAS Single Sign-On and the needs of Oracle Portal, without creating a conflict. This parameter directly corresponds to the number of sessions established and to the maximum workload that the Oracle HTTP Server listener can handle on the portal listener.
The following example shows the MaxClients section in the httpd.conf file:

# MaxClients: maximum number of server processes allowed to start
# MaxRequestsPerChild: maximum number of requests a server process serves
<IfModule prefork.c>
StartServers         5
MinSpareServers      5
MaxSpareServers     10
MaxClients         150
MaxRequestsPerChild  0
AcceptMutex fcntl

Notes:

- If you tune the OracleAS Single Sign-On and the Oracle Portal separately, each will have a separate listener. The Oracle Portal will control the resources (sessions) on the portal database and the OracleAS Single Sign-On will control the resources on the OracleAS Single Sign-On database.

- The number of sessions and connections that the database permits is limited by the value set in the Oracle Database's init.ora file. Refer to the Oracle Database documentation library for more information.

11.5 Tuning File System Cache to Improve Caching Performance

Tuning the File system cache can increase caching performance. Two ways of tuning the file system cache are:

- Configuring File System Cache to Reside on a Faster File System.

- Moving Session Cache Directory to More Performant File System.

Note:

Starting with this release, Oracle Portal implements in-memory caching of the session cache. This functionality reduces the possibility of contention for reading frequently used session cache objects, thereby reducing the need to move the session cache content to a more performant file system.

More information on how to do this can be found in the section describing how to optimize PL/SQL performance, in the Oracle Fusion Middleware User's Guide for mod_plsql.

11.6 Tuning Oracle Net Services

Portal Services leverage Oracle Net Services to connect to the Oracle Portal schema in the Oracle Metadata Repository. By tuning Oracle Net Services, you can improve database access performance

Refer to the paper, "Tuning Oracle Net Services to optimize mod_plsql Database access times" on the Oracle Technology Network (OTN) at http://www.oracle.com/technology/. The tuning steps mentioned in this document are still applicable to Oracle Portal.

12 Exporting and Importing Content

Oracle Portal provides a set of export and import utilities that enable you to transfer content between portals. This chapter provides a summary of recommendations and best practices for using the export and import utilities. This chapter contains the following main sections:

- Introduction Oracle Portal Export or Import

- Before You Begin

- Examples of Using Export and Import

- Export in Oracle Portal

- Acquire Transport Set Services

- Import in Oracle Portal

- Using the Oracle Portal Export and Import Command-line Scripts

- Behavior of Objects After Migration

- Recommended Best Practices When Exporting and Importing

12.1 Introduction Oracle Portal Export or Import

This section describes the tasks you need to perform and information about how Oracle Portal Export and Import works with other components of Oracle Fusion Middleware. This section contains the following topics:

- How Does Oracle Portal Export and Import Work?

- Additional Information

How Does Oracle Portal Export and Import Work?

The Oracle Portal Export and Import process consists of the following steps:

1. Create transport sets and extract the content of the transport sets to transport tables. Transport sets contain the portal objects that you want to export to your target portal environment. This information is displayed in a manifest. The manifest is a list of objects in a transport set, used to provide a granular level of control over the export. For more information on the export process and using the Transport Sets - Export Services portlet refer to Section 12.4.1.2, "How Do I Manage My Transport Sets?"

2. Move the transport sets from one system (source) to another (target) using the Transport Sets - Acquire Service portlet, or using the Oracle Portal Export and Import command-line scripts if there is an intervening firewall. Moving the transport set from the source to the target system using the Transport Sets - Acquire Service portlet is described in Section 12.5.2, "Moving Data to the Target System". Using the command-line scripts is described in Section 12.7, "Using the Oracle Portal Export and Import Command-line Scripts".

3. Import the objects from the transport tables to the target portal repository using the Import Transport Set portlet. For more information on the import process and using the Import Transport Set portlet refer to Section 12.6.1, "Oracle Portal Import - Recommended Method".

Additional Information

- Refer to the section on moving product-specific metadata for Oracle Portal from a test metadata repository to a production metadata repository in the Oracle Fusion Middleware Administrator's Guide.

- Refer to the section about controlling the exporting and importing of portlet personalizations in the Oracle Fusion Middleware Developer's Guide for Oracle Portal.

12.2 Before You Begin

Before beginning the export and import process, ensure you have the following information:

- System Requirements

- Additional Considerations

- Privileges for Exporting and Importing Content

- Oracle Portal instance information:

- Portal schema name.

- Portal schema password.

- Portal connect string information.

- Portal user name.

- Portal user password.

- Company name (used only for hosted portal installations). In most cases, this should be left blank.

Note:

The Oracle Portal schema password is a random password created when the application is installed.

12.2.1 System Requirements

Before exporting and importing content, ensure that your system meets the minimum system requirements, as described in this section.

Notes:

- Export and import functions only within the same release of Oracle Portal and the same patch release, for example, release 10.1.4 to release 10.1.4 or release 11.1.1 to release 11.1.1. You cannot export and import between two different releases, such as release 10.1.2 to release 10.1.4 or release 10.1.4 to release 11.1.1.

- For successful migration of objects, the version of the portal repository should be the same in the target and the source. Any difference in the versions of the middle tiers does not impact migration.

- Using Different Releases of the Export Client Utility. Whenever you move data between different releases of Oracle Database, the following rules apply:

- The Oracle Database imp utility and the database to which data is being imported (the target database) must be either the same release or a later release.

- The release of the Oracle Database exp utility must be same as the earliest release of the source or target database.

Notes:

- Oracle Database exp and imp are the migration utilities for export and import used to dump and restore data in an Oracle-specific format for backup and transfer of user data.

- If you have problems with database release mismatches, then contact Oracle Support Services.

The choice to use the database Oracle home or the middle-tier Oracle home depends on the release of the database used for the source and target portal installations. By default, the 11.1.1 release of the middle tier uses an 11.1.1 release Oracle home.

Based on the recommendations given earlier, the following conditions apply when an 11.1.1 release of a portal and 11.1.1 release of a middle tier is involved:

- Always use the middle-tier Oracle home to export content. Version 10.2.0.3 is the earliest version of the database supported for an 11.1.1 release of a portal installation.

- Always use the target database Oracle home to import content. The release of the import utility and the target database must be the same.

For example, to create an export file that will be imported into a later release of a database, use a release of the Oracle Database exp utility that is the same as the source database. To create an export file that will be imported into an earlier release of a database, use a release of the Oracle Database exp utility that is the same as the release of the target database.

Note:

Oracle recommends you use the same release of the database for the source and target portal installations.

- Oracle export and import and character sets. The Oracle Database exp utility always exports user data, including Unicode data, in the character sets of the export server. The character sets are specified when the database is created.
The Oracle Database imp utility automatically converts the data to the character sets of the import server.

Some 8-bit characters can be lost (that is, converted to 7-bit equivalents) when you import an 8-bit character set export file. This occurs if the client system has a native 7-bit character set or if the NLS_LANG operating system environment variable is set to a 7-bit character set. Most often, you notice that accented characters lose their accent marks.

Both the Oracle Database exp and imp utilities alert you of any required character set conversion before exporting or importing the data.

Note:

When the character set width differs between the export client and the export server, the data may be truncated if the conversion causes the data to expand. If truncation occurs, then the export displays a warning message.

- Understand your source and target portal instances.

- Do you have command-line access to appropriate directories on the source and target computers? If you are using the Oracle Portal Export and Import command-line scripts to move the transport sets from one system to another, you must have command-line access to run the shell or command utilities generated by the export import process. The command-line utilities, in turn, access the Oracle Database exp and imp utilities, and the Oracle Portal instance.

- Is your database configured to allow background jobs to run? Each export or import process sets up a background process. Therefore, verify that the job_queue_processes database parameter is set appropriately.
To check the value of the job_queue_processes parameter, perform the following query from SQL*Plus:

%select name, value from v$parameter where name='job_queue_processes'

The value for job_queue_processes should be at least 2 to allow the background jobs to run.

An alternative way of checking the job_queue_processes parameter is to examine the init.ora file in your database's ORACLE_INSTANCE.

- When do you export and import data? Perform the export and import process after regular business hours, and disable access to Oracle Portal during the process. One way to disable access to the portal temporarily is to configure your listener for a different port number for the duration of the export and then revert to the original port when the export process is complete.

Note:

If the Oracle Database exp and imp utilities finish with errors or warnings, then you should not import that transport set. The errors or warnings that are recorded in the Oracle Database exp and imp log files (typically named <script_file_name>_<long identifier>_exp.log and <script_file_name>_<long identifier>_imp.log) should be corrected first.

- How much time does the export or import process take? The exact amount of time to export or import content in Oracle Portal cannot be determined. Many dependencies affect the time it takes to export and import content. The following are dependencies that can affect the processing time.
Dependencies that affect the Export process are as follows:

- Objects being exported have a number of dependencies spanning across page groups.

- There are references or dependencies between objects.

- Extraction process takes a long time to start because of the assigned database job in the queue.

- There are a large number of documents being extracted, especially BLOB columns.

- There is insufficient memory in the TEMP tablespace for sort operations.

- Schema validation takes a long time due to a large number of objects that need to be validated.

Dependencies that affect the Import process are as follows:

- Preliminary check for large page groups, which also depends on the number of internal and external dependencies that need to be checked.

- Import process takes a long time to start because of the assigned database job in the queue.

- There is insufficient memory in the TEMP tablespace for sort operations.

- Post-import schema validation takes a long time due to a large number of objects being validated.

- Difference between the source and target languages is reasonably high.

Tip:

Before importing large transport sets, you may want to increase the values of relevant database cache parameters based on your requirement. This will reduce the time taken to import large transport sets.

12.2.2 Additional Considerations

This section provides a list of some additional considerations you must make before you export and import data in Oracle Portal.

- When exporting or importing large data sets, check that there is sufficient space in the TEMP tablespace. This ensures that the export or import process does not fail due to insufficient memory.

- For exporting large page groups from the command line, use the opeasst.csh script. See Section 12.4.1.1.3, "Exporting Large Page Groups from the Command Line" for more information.

- For importing large page groups from the command line, use the import script with the -automatic_merge option. See Section 12.7.3, "Importing the Transport Set Tables to the Target System" for more information.

- If you have installed any Business Intelligence and Forms components and use related portlets in Oracle Portal on the source portal instance, then you must ensure that the same components are installed on the target portal instance before you can export and import data between the portal instances. If the same Business Intelligence and Forms components are not found on the target portal instance, then, during import, the portlets related to those components will be removed from the pages in which they appear.

Caution:

Do not manually update system tables to resolve any issues you might have in the source or target portal instances. Doing so will cause the export and import process to fail. If you have any problems with source or target instances, then contact Oracle Support Services.

12.2.3 Privileges for Exporting and Importing Content

This section describes the privileges required to successfully export and import content. The privileges described subsequently apply to the export and import of Oracle Instant Portal content also.

Privileges for Exporting Content

To allow for secured control over the export of shared objects (objects in the Shared page group), there are two privileges defined at the infrastructure level.

- Any Transport Set - Manage enables you to export and import portal objects, including shared objects. This privilege is granted to the DBA group by default during the portal installation process.

- Any Transport Set - Execute enables you to export and import portal objects, excluding shared objects. This privilege is granted to the PORTAL_ADMINISTRATORS group by default during portal installation process.

Table 12-1 provides a description of export user privileges.

Table 12-1 Export User Privileges

User Privileges

Export Objects That Are Not Shared?

Export Objects That Are Shared?

Any Transport Set - Manage

Yes

Yes

Any Transport Set - Execute

Yes

No

Any Transport Set - None

No

No

Privileges for Importing Content

In addition to the Any Transport Set - Manage privilege, you must also have the Manage privilege on objects of a given type to successfully import content.

For example, a page group containing Web providers requires you to have Manage All privileges on All Providers and All Page Groups to import that page group. Table 12-2 provides a description of each object type and the required privilege level.

Note:

The FMWADMIN and Oracle Portal users are granted the Manage All privilege on all page groups at the time of installation or upgrade. Members of the DBA group are also granted the Manage All privilege on all page groups by default.

Table 12-2 Import User Privileges

Object Type

Privileges

All Page Groups

Manage All and All Providers Manage are required to import page groups and shared objects.

All Providers

Manage is required to import page groups, Portal DB Providers, Web providers, WSRP producers, and other database providers.

All Portal DB Providers

Manage is required to import Portal DB Provider objects.

All Shared Components

Manage is required to import shared components if the Portal DB Provider objects reference the shared components.

Note:

If you import a page based on a style that belongs to the shared objects group and do not have the necessary privileges to import shared objects, then the style of the page is reset to Main Style by default.

12.3 Examples of Using Export and Import

Oracle Portal supports the ability to copy or update page groups and portal content between your source and target destination portal instances. This section gives examples of the most common uses of the Oracle Portal Export and Import processes.

12.3.1 Case1: Exporting/Importing Between Development and Production Instances

This case shows the steps to copy or update portal page groups and portlets between a development instance and a production instance of Oracle Portal.

Note:

User personalizations are not exported; therefore, any personalizations of a page or portlet on the source are not exported or imported.

Scenario 1: Exporting pages and content to a target portal system. The first export to your target system must migrate the entire page group. The following steps provide an overview of the process:

1. Develop page groups, applications, and content on the source system.

2. Identify pages, applications, and content to export, then create transport sets accordingly and export to the target system.

3. Import the transport sets on the target system, into your portal repository.

Scenario 2: Updating content on your target instance. Oracle Portal supports updating items and region-level content on your target system only under the following circumstance:

Export and import of all changes from the source to the target instance. All page structure, content, and user preferences on your target system are replaced with the content from your source system. The first export to your target system migrates the entire page group from the source portal to the target portal instance.

See Section 12.9, "Recommended Best Practices When Exporting and Importing" for more information about the recommended practices for exporting and importing content.

12.3.2 Case 2: Deploying Identical Content Across Multiple Portal Instances

As well as using the Acquire Transport Set portal to transport data, you can also use the exp and imp migration utilities to deploy identical content across multiple Oracle Portal instances. In this case, the Oracle Portal objects (portlets, page groups, and so on) can be created in one instance, and propagated to multiple instances using the exp and imp migration utilities. For more information, refer to the information on staging a test environment from a production environment, in the Oracle Fusion Middleware Administrator's Guide.

12.3.3 Case 3: Consolidating Content from Multiple Sources

When you use Oracle Portal Export and Import to migrate content from multiple portal instances to a single target portal instance, you must consider the following points:

- Do not create objects with the same names on different source portal instances from where you plan to import. This helps avoid namespace collisions between shared objects. For example, assume that you create a shared template (shared_tempate1) in source instances (source1 and source2) used by page groups (pgrp1 and pgrp2) in source1 and source2 respectively. Now, if you try to consolidate the two page groups from source1 and source2 into one target instance, then this will result in precheck errors as both page groups use different shared templates with the same name (shared_template1).

- Do not create page groups with the same name. For example, do not create a page group (pgrp1) in source instances source1 and source2 if you need to consolidate these two page groups in into a single target instance. This warning is also valid for names of database provider objects, shared components, Web providers, and database providers.

12.4 Export in Oracle Portal

This section describes the methods for the Oracle Portal Export. This section contains the following topics:

- Oracle Portal Export - Recommended Method

- Oracle Portal Export - Alternate Method

12.4.1 Oracle Portal Export - Recommended Method

This section describes the recommended method to export content in Oracle Portal. It contains the following topics:

- How Does Oracle Portal Export Work?

- How Do I Manage My Transport Sets?

12.4.1.1 How Does Oracle Portal Export Work?

This section describes the export process and the steps required to successfully transfer content from the source portal system, including:

- Creating Transport Sets

- Exporting Data

- Exporting Large Page Groups from the Command Line

12.4.1.1.1 Creating Transport Sets

Once the system requirements are verified, your goal is to create a transport set. Figure 12-1 shows the process.

Note:

Limit any possible conflict issues by making one person responsible for maintaining a transport set.

Figure 12-1 Export Process

1. From the Navigator or Bulk Actions (enables you to add multiple pages at once to the export transport set), select the page group or root page to be exported. The Transport Set Manager is displayed.

2. Select a name and whether to include access controls and preferences, or external and child objects as part of the transport set. Click Next to generate the transport manifest.

3. When the dependency calculation has finished, click Display Manifest to display the Export Transport Set page to view the results. The manifest is a list of objects in a transport set, used to provide a granular level of control over the export. Check that the Replace on Import options are set appropriately for the explicit and referenced objects as described in Working with Import Modes in this section. Add any external objects that are required on the destination portal to the transport set. The transport set is now ready for export.

4. Click Export Now to initiate the export. The procedure extracts the data and populates the transport tables. Refer to Section 12.4.1.1.2, "Exporting Data" for more information about the export process.

The Export Transport Set Manager ensures that all the object dependencies in the transport set are correctly extracted. Specifically, the Dependency Manager classifies each object as explicitly selected, referenced, external or child, based on how the object is related to the objects being explicitly exported. The information is displayed in the manifest, as shown in Figure 12-2. The following list shows the classification of objects:

- Explicitly Selected Objects. Objects, that were explicitly selected, from the Navigator or Bulk Actions for export.

- Referenced Objects. Objects that are directly or indirectly referenced by the explicitly selected objects, but are always within the same page group as an explicit object. For example, a style used by a page is a referenced object when it belongs to the same page group.

- External Objects. External objects ensure that the explicitly selected objects perform on the target portal. For example, external providers and database schemas could be considered external objects. Generally, shared objects and components are external objects unless explicitly selected.

- Child Objects. Objects that are part of a hierarchy. For example, subpages, subcategories and subperspectives are child objects of a page, category and perspective.

Notes:

- When a referenced object contains child objects, the child objects are imported in Reuse mode. You should therefore explicitly select the referenced object and include it in the transport set. This will enable you to set the import mode to Replace on Import. Before importing the page group in Reuse mode, note the page group properties. After importing the page group manually, update any changes to reflect the old properties.

- A child object is picked up for migration only for an explicit object. If a parent page, category, or perspective appears in the referenced section, then the child objects are not picked. See Table 12-12, "Import Behavior of Child Objects" for more information.

- Containers of explicit objects and referenced objects are migrated as external dependencies.

Working with Import Modes

The manifest provides a granular level of control over the import mode. The manifest is the list of objects in a transport set. There are two modes available during import:

- Replace on Import. If the object exists on the target, then it is replaced. If it does not exist, then it is created. If this mode is not selected and the object exists, then the object on the target portal is retained as is. However, if the object does not exist on the target, then it is created.

- Reuse on Import. If the object does not exist on the target, then it is created. If it already exists, then it remains as is.

Table 12-3 describes the object classification and the default modes.

Table 12-3 Default Modes

Object Classification

Default Import Mode

Explicitly selected objects

Replace on Import

Referenced objects

Reuse

Child objects

Replace on Import

External objects

Reuse

Figure 12-2 is an example of a transport set manifest.

Figure 12-2 Transport Set Manifest

Clicking the name of an object, for example an explicitly selected object, displays a detailed view of child, referenced, and external objects. The objects can be displayed in either a tree view or tabular view. Figure 12-3 is an example of the tree view of a detailed manifest screen.

Figure 12-3 Detailed Manifest Screen

Note:

Editable seeded item types are extracted. It is recommended that you do not edit seeded types. If you want to extract them, then create custom types in the Shared Objects page group based on the existing seeded types. The Dependency Manager includes these in the manifest.

12.4.1.1.2 Exporting Data

Review Section 12.8, "Behavior of Objects After Migration" before exporting and importing your portal content from a source to a target instance.

Note:

Portlet repository information (security, organization, and so on) related to the portlet is not migrated during the export and import process.

To export objects:

1. Select the objects for export. You can do this from the Navigator, or search results > Bulk Actions for page groups. See Figure 12-4.

Note:

Be sure to export portlets (Portal Forms, Portal Reports, Charts, Dynamic Pages) before exporting portal pages and page groups that reference them.

Figure 12-4 is an example of the Portal Navigator.

Figure 12-4 Portal Navigator

2. Click the Export, Export Page Group, or Export Root Page link to display the Transport Set Manager. Make the transport set name as descriptive as possible, and avoid using any special characters at the start of the name. For example, My Company Transport Set 12-NOV-2008.
Figure 12-5 is an example of the Transport Set Manager.

Figure 12-5 Transport Set Manager

3. Select Access Controls and Preferences if you want to include access control lists (ACLs) associated with the objects in the transport set. If you select this option, the following happens:

- Users and groups associated with the objects are migrated.

- Privileges attached to the objects are migrated.

- Parameters and events associated with the users are migrated.

4. Select Export all external objects to include external object dependencies in the export with explicitly selected objects.

5. Select whether to include hierarchical objects in the export.

- Choose Include Entire Hierarchy to include all child objects of explicitly selected objects in the export.

- Choose Include Object Structure Only to include only the structure of the explicitly selected object (i.e., without any of its child objects) in the export. This option applies only for hierarchical objects (i.e., Pages, Perspectives, and Categories)

6. Set the Pagination options for the transport set.
Manifest View:

- Select Full transport view (Default) to render all the objects in the dependency manifest at once.

- Select Paginated View to enable the user option to set the number of viewable objects per section. For example, if the number of viewable objects is set to 100, you can view only 100 objects per section with the pagination controls. This option is useful particularly for large transport sets which could time out the manifest user interface before rendering.

Tree View:

- Select Full Dependency View (Default) to render the detailed dependency tree with all the dependencies at once.

- Select Paginated View to restrict the dependencies to only the immediate references, and use the Drill Down Pagination controls to traverse through the child references. This setting is useful for large dependency trees that may time out the tree view rendering.

7. Click Next to generate the transport manifest. When the dependency calculation has finished (click ReQuery to check the status), click Display Manifest to display the Export/Import Dependency Manager to view the results (see Figure 12-6). Check that the Replace on Import options are set appropriately for the explicit and referenced objects as described in Working with Import Modes in this section. Add any external objects that are required on the destination portal to the transport set.

8. After making changes, click Recalculate to see the updated manifest.
Figure 12-6 shows the transport set objects.

Figure 12-6 Transport Set Manager Objects

9. To finalize the transport set immediately after a dependency calculation, click Export Now. If you've made changes, or it's possible that other users on the Portal may have made changes since the dependency calculation, click Recalc & Export to recalculate dependencies prior to exporting the transport set. The objects marked for export are copied to the transport tables for migration. When the export process is complete, the Export Log and Download Scripts page is displayed.

Note:

When you select Export Now the objects are exported

Figure 12-7 Export Log and Download Scripts Page

10. Check the log in your transport set manager for any errors by clicking the View Log Of Actions link.
Figure 12-8 is an example of the View Log page.

Figure 12-8 Transport Set Export Log

Note:

To view a detailed log of the export process, including debug messages, click on the link at the top of the log indicated by "Detailed log information can be viewed here".

11. If you are moving data across a firewall to the target system, you'll need to use an Oracle Portal Export and Import command-line script rather than the Acquire Transport Set portlet. From the Export Log and Download Scripts page, select an appropriate export script based on your operating system and download it to the source system. Refer to Section 12.7, "Using the Oracle Portal Export and Import Command-line Scripts" for more information on using the command-line scripts.

12.4.1.1.3 Exporting Large Page Groups from the Command Line

You can use the opeasst.csh (Oracle Portal Export Assistant) script to export large page groups with all the dependencies without going through the portal's user interface. The script replicates the behavior of exporting transport sets through the user interface with the Export all External Objects option turned on.

The script does the following in the following order:

- Creates a transport set with a specified name

- Calculates dependencies for the specified page groups and promotes all external objects iteratively until there are no more promotable external objects

- Extracts metadata into the transport tables

- Generates the checklist for the external dependencies (if any) for the transport set

The script can be found in the /portal/admin/plsql/wwu directory. The following is an example of the script:

%opeasst.csh
Usage: opeasst.csh -s portal_schema
-p portal_password -c connect_string
-ts transportset_name -pgrps pgrp_names
-log log_name [-export_acls]

Note:

This script can be used to export all page groups.

Table 12-4 provides a description of the parameters used in this process.

Table 12-4 OPEASST.CSH Parameter Descriptions

Parameters

Description

-s portal_schema

Oracle Database account for the portal.

-p portal_password

Oracle Database password for the portal.

-c connect_string

TNS connection information for the source database.

-ts transportset_name

Name of the transport set to be created.

-pgrps pgrp_names

Comma-delimited list of Page groups for export.

Note: Exporting seeded page groups using the script is not allowed.

Name of the logfile to which to output the export checklist process log.

-export_acls

Export object-level privileges.

Do the export from the command line, and then perform the following tasks:

1. Check the log in your transport set manager for any errors by clicking the Status link. See Section 12.4.1.2, "How Do I Manage My Transport Sets?" for more information about how to edit and browse the transport sets on the system.

2. When the export is complete browse your transport sets and select the appropriate script for your operating system. See Section 12.7, "Using the Oracle Portal Export and Import Command-line Scripts" for details.

3. Run the script using -mode export as the option.

%MyScript.csh -mode export

This prompts you for information such as the schema name (source), password, dump file names, and so on. It also creates a dump file upon completion.

4. Using FTP, transfer your dump file and the export and import script to the computer where your target Oracle Portal schema resides.

5. To import your objects, the contents of the transport set dump file must first be imported to the transport set tables on the target system. See Section 12.6.1.2, "Importing Data" for details.

The following features and limitations currently apply:

- The script supports only exporting page groups

- Multiple page groups can be exported at once using comma-delimited values

- Export checklist logs are available after export. These logs help identify prerequisites prior to import

- Export Access Control Lists feature is supported

- The import mode options (i.e., Replace on Import and Reuse on Import) are not available

- Exporting database providers is not supported

- If the Dependency Manager results in some external objects for the page group being exported, then all the external objects are automatically made explicit by the script without any user intervention. Those objects that can be made explicit are recursively added to become part of the transport set until there are no remaining external objects in the transport set.

- The script name cannot be changed.

Notes:

- Remember to set the infrastructure Oracle home (ORACLE_INSTANCE) when connecting to the database to run the opeasst.csh script.

- To run shell script tools on the Windows operating system, you need one of the following UNIX emulation utilities:
— Cygwin 1.3.2.2-1 or later. Visit http://sources.redhat.com.

— MKS Toolkit 6.1. Visit http://www.datafocus.com/.

- Whenever you use the command line, it will create a new dump based on the timestamp, and will not overwrite an existing dump, it is recommended that you cleanup the unused and the old dump files periodically to save the disk space.

12.4.1.2 How Do I Manage My Transport Sets?

The Transport Sets -Export Services portlets on the Administer page enables you to export, browse, and edit the transport sets on the system. This section discusses the following:

- Browsing Transport Sets for Export

Note:

The status is set to "ACQUIRE_IN_PROGRESS" on both the source and target for the Transport Set being acquired, and is a valid status in the export browse transport set list.

12.4.1.2.1 Browsing Transport Sets for Export

You can view and edit the list of objects selected for an exported transport set. You can view all of the transport sets that are on the system and their current status. You can also view the log of actions, view the referenced objects, and download the export and import scripts.

To display the Transport Sets

1. Navigate to the Export Transport Set portlet. Figure 12-9 shows the Export Transport Set Portal.

Figure 12-9 Export Transport Set Portlet

2. Click Browse Transport Sets for Export. Figure 12-10 shows a sample Browse Transport Sets for Export screen.

Figure 12-10 Browse Transport Sets for Export

The Browse Transport Sets for Export screen shows the status of all transport sets on the source system.

- To view the export manifest for a transport set, click Name

- To download scripts for a transport set, click the corresponding Script link.

- To view the log for a transport set, click Status

- To generate a checklist to validate the transport set's readiness for import click Generate Checklist.

- To delete a transport set, select it and click Delete.

When you select transport sets and click Delete, you are prompted for confirmation. Clicking OK does not affect transport sets that are in the Export, Export In Progress, Precheck In Progress, Migration In Progress, Import, or Import In Progress statuses.

To make a previously exported or finalized (Dependency calculation complete) transport set available for reuse, select the transport set and click Reuse.

When you select transport sets and click Reuse, you are prompted for confirmation. Clicking OK does not affect transport sets that are in the Export, Export In Progress, Migration In Progress, Ready For Import, Import, Import In Progress statuses.

Notes:

- The Reuse option is valid only for transport sets in the source portal with a status of

- You can import objects with multiple hierarchies in the same transport set.

12.4.2 Oracle Portal Export - Alternate Method

You can export content when both the source and target Oracle Portal instances exist in a customer database installation, and not in a product metadata repository. This means that you can use Acquire Transport Set services when the source and target Oracle Portal instances are in the same database and when there is no firewall between the instances. For more details, see "Using the Oracle Portal Export and Import Command-line Scripts".

For details, refer to the information on staging a test environment from a production environment, in the Oracle Fusion Middleware Administrator's Guide.

12.5 Acquire Transport Set Services

You use the Transport Sets - Acquire Services portlet to perform the following task:

- Register a Source Portal

- Moving Data to the Target System

12.5.1 Register a Source Portal

Before moving data from a source portal you must first register the portal. Once registered, the source portal can be selected and used to specify the data source in the Transport Sets - Acquire Services portal as described in Section 12.5.2, "Moving Data to the Target System"

To register a source portal:

1. Create a private database link with embedded credentials (known as a fixed user database link) to the source portal. Refer to Section 12.6.1.1, "Creating a Database Link" for instructions on how to create a database link.

2. In the Transport Sets - Acquire Services portlet, click Register a Source Portal to display the Register a Source Portal screen. Figure 12-11 shows the Register a Source Portal screen.

Figure 12-11 Register a Source Portal Page

3. Provide a unique name and database link for the source portal and click Register. You can now select the source portal when you acquire a transport set.

4. Provide a unique name and database link for the source portal and click Register. You can now select the source portal when you acquire a transport set.

12.5.2 Moving Data to the Target System

Before importing your objects, the contents of the transport set must first be moved to the transport set tables on the target system. If there is no intervening firewall, use the Transport Set - Acquire Services portlet to move the data as shown below. If you are moving data across a firewall or there are other local configuration considerations that do not allow you to use the Acquire Transport Set portlet, use the command-line scripts as shown in Section 12.7, "Using the Oracle Portal Export and Import Command-line Scripts".

To move your content using the Acquire Transport Sets portlet:

1. In the Transport Set - Acquire Services portlet, click the Browse Source Portals on the Administer page and check that the source portal you're moving data from is registered on the target instance.
If the source portal has not previously been registered, from the Acquire Transport Sets portlet, click Register A Source Portal and register it as described in Section 12.5.1, "Register a Source Portal".

2. From the Transport Set - Acquire Services portlet, click Acquire Transport Sets to display the Acquire a Transport Set page.

Figure 12-12 Acquire a Transport Set

3. Specify the source portal and the transport set and click Acquire to start transferring the data.

4. When the transfer is complete, click Display Manifest to display the transport set manifest. Click on the explicitly selected object to display the detailed manifest. Click Tree View to see the nested dependencies.

5. Click Close to return to the manifest, and then click Precheck Now to perform a precheck of the transferred data. The system checks that all object dependencies have been resolved.

6. Click Display Manifest when the precheck is complete and check the status column for errors. Refer to Table 12-7 to see the status icons. Resolve any errors before continuing with importing the transport set.

12.6 Import in Oracle Portal

This section describes the methods for importing in Oracle Portal. This section contains the following topics:

- Oracle Portal Import - Recommended Method

12.6.1 Oracle Portal Import - Recommended Method

This section describes the import process and the steps required to successfully transfer content using the Transport Sets - Acquire Services portal to the target portal system, including:

- Creating a Database Link

- Register a Source Portal

- Moving Data to the Target System

- Importing Data

- How Do I Manage My Transport Sets (Import)?

12.6.1.1 Creating a Database Link

The Acquire Transport Sets functionality uses a fixed user database link to pull data from the source database. When an application uses a fixed user database link, the local server always establishes a connection to a fixed remote schema in the remote database. The local server also sends the fixed user's credentials across the network when an application uses the link to access the remote database.

To create the database link:

1. On the Portal Builder page, click the Navigator link.

2. Click the Database Objects tab.

3. In the Name column, scroll down to the schema to which you want to link and click the schema's name.

4. Click Create New...Database Link.

5. Enter the Database Link Name you want to use to identify the database link.
Example: mydb.mydomain@remotedb

6. Choose the schema that will own the finished database link, and then click Next. Only schemas in which you have Manage schema access privileges display in the list.

Note:

7. Complete the database connection fields as shown in Table 12-5, and then click Next.

Table 12-5 Database Connection Information

Field

Description

Current User

Select to log into the remote database using the same user name and password that you use to log into Oracle Portal.

Specific User

Select to log into the remote database using a user name and password other than the one you use to log into Oracle Portal.

User Name

Enter a User Name and Password if you want to log into the database automatically as the Current or Specific user. If you don't enter a User Name and Password, a login dialog box will display when you try to log into a database using the link.

The User Name and Password must be for a valid user account in the remote database.

Password

Enter the password for the database User Name.

8. Enter either the TNSNAME for the database, or supply the Host Address, Host Service Name, the Host Protocol, and the Host Port, and then click Finish.

After creating the database link, continue by registering it as described in Section 12.5.1, "Register a Source Portal". Once the link is established through the registered source portal, you can select one of the transport sets that are "Export Complete" on the source portal and move it to the target using the Transport Sets - Acquire Services portal as described in Section 12.5.2, "Moving Data to the Target System". The Acquire process pulls the transport set data one by one in batches through the database link and informs you once the process is done.

Creating a Database Link from the Command Line

You can also create the database link from the command line using SQL *Plus using the following syntax:

create database link <link_name> connect to <source-portal> identified by "<source-portal-password>" using '<net-service-name>';

where:

Table 12-6 Database Link Syntax

Parameters

Description

link_name

A user-defined name for the link.

source-portal

Name of the portal schema that you want to register as the source for this portal.

source-portal-password

Database password for the above schema.

Note: Passwords for Oracle 11g databases, unlike earlier versions, are case sensitive by default. To preserve the password case you must enclose it within double quotes.

net-service-name

Alias or the full connection descriptor (obtained from $TNS_ADMIN/tnsnames.ora).

Example:

create database link mylink1 connect to portal12 identified by "******"

using

'(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = stacu35.us.oracle.com)(PORT = 1521)))

(CONNECT_DATA =

(SERVER=DEDICATED)

(SERVICE_NAME = asinfra.us.oracle.com)))'

Refer to the section on "Creating Database Links" in the Oracle Database Administrator's Guide for more information on creating database links using SQL *Plus.

After creating the database link, continue by registering it as described in Section 12.5.1, "Register a Source Portal", and moving it to the target using the Transport Sets - Acquire Services portal as described in Section 12.5.2, "Moving Data to the Target System".

12.6.1.2 Importing Data

To import an object, the contents of the transport set must first be imported to the target system. When you select a transport set for import, a preliminary check (or precheck) process determines if the objects already exist on the target.

To import your content:

1. Locate the Import Transport Set portlet, installed by default on the Administer tab.

Note:

When you import a transport set and click the Browse Transport Sets link, you will see the newly imported transport set with the Export Complete status and links to the export scripts.

Selecting a transport set on the target for Reuse resets the transport set. This makes the transport unusable because it was not exported from the target instance and therefore no objects exist that match the objects in the transport set.

2. Select the imported transport set and click Import. The Objects page of the Import Manager is displayed.
Figure 12-13 shows the Objects page that displays the list of objects included for import.

Figure 12-13 Transport Set Manager Import Objects

3. If you select Replace on Import, then the object is replaced if it is found in the target portal.

Note:

Replace on Import mode is the default mode for explicitly selected objects; Reuse is the default mode for referenced objects. The import modes are not applicable to the external objects until they are made explicitly selected objects.

4. To view the log output, click the Status icon. Table 12-7 provides a description of each status type.

Table 12-7 Status Descriptions

Status

Description

Pass

Fail

Pass with warnings

Figure 12-14 shows a sample View Log page.

Figure 12-14 Transport Set Manager Import Log

Note:

To view a detailed log of the import process, including debug messages, click on the link indicated by "Detailed log information can be viewed here" at the top of the transport set log.

5. Click Close to return to the Objects page.

6. Click the Main tab.

Figure 12-15 Import Transport Set Page

7. Select the Access Controls and Preferences option under Access Controls and Preferences if you want to include the access control lists (ACLs) associated with the objects in the transport set.

Note:

The Import Access Control Lists option cannot be selected if you did not select it during the export process.

If you select this option, the following happens:

- Group profiles get created only if they do not exist on the target.

- User and group profiles do not get updated upon subsequent imports. Default groups of users are not imported.

- If a user exists on the target, then the user's default group is populated from Oracle Internet Directory.

8. Select or Precheck Again if you've made changes to resolve warnings or errors before importing, select Precheck & Import to precheck the transport set prior to importing it, select Import Now to import the transport set without prechecking, or select Save & Close to save any changes and return to the transport set later.

Note:

9. Check the log for errors.
To ensure that all the content has been imported correctly:

- In the Navigator, verify that the content in each portal page group that you imported was imported correctly. Specifically, for each portal page, verify that the appropriate portlets appear in each region of your portal page. When these portlets (navigation pages, pages exposed as portlets, database provider components, or Web portlets) occur as external dependencies and they do not exist on the target, then the portlet entry is deleted from the page.

Note:

During the import, a two-step preliminary check process is performed. Clicking View Log shows both the first stage of the process and the preliminary check as complete. This is done before the import and before populating the portal tables with data.

Clicking Refresh Log will show both the second stage of the process and the preliminary check with different timestamps.

Warnings and Failures During Import

Objects that are being imported can be classified into two types:

- Warning types - Objects that, on failure, cascade warnings to explicitly selected objects.

- Failure types - Objects that, on failure, cascade failures to explicitly selected objects.

A warning type will raise warnings and allow the explicitly selected objects to be imported. A failure type object is not imported.

If an explicitly selected object has two dependencies, a warning type and a failure type, and if both the dependencies fail the preliminary check process, then the failure type will be dominating, and the explicitly selected object will fail.

A warning type affects explicitly selected objects more than any other kind of object. Referenced and external objects raise failures and warnings for the explicitly selected objects based on their type. Table 12-8 describes the warning or failure behavior for each object.

Table 12-8 Warning and Failure Types

Object

Type

Expected Behavior

Attribute

Failure

The explicitly selected object will fail if the dependent attribute fails.

Item type

Failure

The explicitly selected object will fail if the dependent item type fails.

Page type

Failure

The explicitly selected object will fail if the dependent page type fails.

Style

Warning

The style will revert to the main style of the page group to which it belongs.

Category

Warning

The category is set to none.

Perspective

Warning

The perspective associated with an item or page is removed.

Portal Templates for pages

Failure

The explicitly selected object will fail if the dependent template fails.

Portal Templates for items

Warning

The Portal Template for item associated with an item or page is removed.

HTML Template

Warning

The HTML Template associated with an item or page is removed.

Page

Warning

There are three possible outcomes when a page is a dependent of another object:

- Page exposed as a portlet. The portlet entry is removed from the region that contained the page portlet.

- Page link pointing to a page. The page link is removed from the region, because the page to which the link is pointing to has failed.

- Page Parameters and Events dependency. The link that was pointing to the page that failed is reset to point to the same page in which the Page Parameters and Events link is located.

Navigation page

Warning

The navigation page portlet is removed from the page. You can associate the page with another navigation page after the import.

Color, font, JavaScript, application template, image

Warning

Set to the default at run time.

Any other providers (DB provider, Web provider, WSRP provider)

Warning

The portlet instance on the referenced page is removed. Refer to the section on Portlet Cleanup for more information.

When the container objects in the following list appear as external dependencies, because their child objects were selected for export and they do not exist on the target, the explicitly selected objects (child objects of the container objects) will fail.

- Page group

- Portal DB Provider

- Category

- Perspective

- Page

Cascade Warning Behavior

Warnings or failures detected in objects during the preliminary check behave as shown in Table 12-9.

Table 12-9 Cascade Warning Behavior

Object

Warning Status

Failure Status

Contained object

Status is cascaded to the container object.

Status is cascaded to the container object.

Hierarchical object

- Status is cascaded to all parent objects.

- Status is not cascaded to child objects.

- Status is cascaded to all child objects.

- Status is cascaded to all parent objects.

Referred object

Status is not cascaded to all referenced objects.

Status is cascaded to all referenced objects.

Portlet Cleanup

Imported portlets are synchronized with the target portlet repository during the import process. If a portlet instance fails during the resolution phase of the import process, then it is deleted from the source page.

For example, a page can have a portlet, which could be one of the following:

- Navigation page

- Page exposed as a portlet

- Database Portlet (registered or built-in)

- Web/WSRP portlets (registered or built-in)

When these portlets appear as external dependencies in Reuse mode and do not exist on the target page, the portlet instance is deleted from the page. If these dependencies were made explicit and their import failed, then the portlet instances would still be deleted.

To summarize, if the imported portlet does not exist in the portlet repository on the target, then it gets deleted from the source page.

Note:

The portlet cleanup operation deletes portlet dependencies such as Page Parameters and Events, URL, text, and so on. The page structure remains unchanged after removing the portlet instance from a source page.

If the navigation page (external dependency) does not exist on the target page, then a page using that navigation page passes with warnings, and the navigation page portlet gets deleted from the source page.

12.6.1.3 How Do I Manage My Transport Sets (Import)?

The Transport Sets -Import Services portlets on the Administer tab and enable you to import, browse, and edit the transport sets on the system. This section discusses the following:

- Browsing Transport Sets for Import

Note:

The status is set to "ACQUIRE_IN_PROGRESS" on both the source and target for the Transport Set being acquired, and is a valid status in the export browse transport set list.

Browsing Transport Sets for Import

You can view and edit the list of objects selected for an imported transport set. You can view all of the transport sets that are on the system and their current status. You can also view the log of actions, view the referenced objects, and generate a checklist.

To display the Transport Sets:

1. Navigate to the Import Transport Set portlet. Figure 12-16 shows the Import Transport Set Portal.

Figure 12-16 Import Transport Set Portlet

2. Click Browse Transport Sets for Import. Figure 12-17 shows a sample Browse Transport Sets for Import screen.

Figure 12-17 Browse Transport Sets for Import

The Browse Transport Sets for Import page shows the status of all transport sets on the source system.

To view the export manifest for a transport set, click Name

To view the log for a transport set, click Status

To delete a transport set, select it and click Delete.

When you select transport sets and click Delete, you are prompted for confirmation. Clicking OK does not affect transport sets that are in the Export, Export In Progress, Precheck In Progress, Migration In Progress, Import, or Import In Progress statuses.

To generate a checklist to validate the transport set's readiness for import, click Generate Checklist.

12.7 Using the Oracle Portal Export and Import Command-line Scripts

If there is an intervening firewall between the source and target instances, you must use the Oracle Portal Export and Import command-line scripts to move the transport sets. The process consists of:

- Downloading the Command-line Scripts

- Running Your Script to Create an Export Dum File

- Importing the Transport Set Tables to the Target System

12.7.1 Downloading the Command-line Scripts

Use Download Scripts and View Log page to download the scripts as described below for Internet Explorer:

1. Right-click the selected script, then click Save Target As.

2. Change the name and remember to include the correct file extension, .csh for UNIX or .cmd for NT. For example, MyScript.csh.

3. Save the file to the directory on your file system where you want to run the export script. Usually, this directory is where your export portal resides.

Note:

This location must have access to the database. On some systems, the downloaded UNIX script requires you to set the Execute permissions correctly before running it. Ensure that you do not edit the export script.

12.7.2 Running Your Script to Create an Export Dum File

The next step in the export process are to create a transport set dump file using the script you created in the previous section, and then transfer your export data to your target system.

1. Run a script with the parameters shown in the following example. The example assumes that the name of the script is MyScript.csh. The parameters in bold are applicable only for export, and they are mandatory.

%MyScript.csh
Usage: MyScript.csh <-mode export_or_import_or_exportdp_or_importdp>
<-s portal_schema><-p portal_password> <-pu portal_username>
<-pp portal_userpassword> <-company company_name> <-c connect_string>
<-d dump_file_names> <-dir directory_object> <-sp source_portal>
<-automatic_merge>

Notes:

- Remember to set the infrastructure Oracle home (ORACLE_INSTANCE) when running the export script.

- The value for the company_name parameter is the company name you see in the login page when working in a hosted portal. When working in a portal that is not hosted, the value for the parameter should be none. If you are running the script in interactive mode, then do not pass a value. Ensure that you do not edit the export script.

Table 12-10 provides a description of the parameters you can use in this process.

Table 12-10 Parameter Descriptions

Parameters

Description

-mode

Mode for invoking the Export Import Command Line Utility

EXPORT mode: Exports content to dump files using the Oracle Database exp utility.

IMPORT mode: Imports content from dump files using the Oracle Database imp utility.

EXPORTDP mode: Exports content to dump files using the Oracle Database expdp (ORACLE DATAPUMP EXPORT) utility.

IMPORTDP mode: Imports content from dump files using the Oracle Database impdp (ORACLE DATAPUMP EXPORT) utility.

-s portal_schema

Oracle Database account for the portal

-p portal_password

Oracle Database password for the portal

-pu portal_username

Lightweight user name for logging in to the portal

-pp portal_userpassword

Lightweight user password for logging in to the portal

-company company_name

Company name (for example, ORACLE)

-c connect_string

TNS connection information to the remote database

-d dump_file_names

Names of files for Oracle Export or Import utilities to write to or read from. If multiple file names are specified, then they must be separated by commas.

For example: FILE1.DMP,FILE2.DMP

Note: If multiple file names are not specified, then the Export or Import utilities will automatically prompt for another file name during the export and import process, if required.

-dir directory_object

Directory Object for Oracle expdp/impdp utilities.
The directory_object is the name of a database directory object (not the name of an actual directory) created by the database administrator (DBA) using the SQL CREATE DIRECTORY command (applicable modes => EXPORTDP / IMPORTDP)

-sp source_portal

Oracle Database account for the source portal (applicable mode => IMPORTDP). Datapump import needs this information to map the schema objects from the dump to target).

-automatic_merge

Automatically imports contents of the dump file (applicable modes => IMPORT / IMPDP)

-automatic_precheck

Automatically prechecks the contents of the dump file (applicable modes => IMPORT / IMPDP)

Note:

The IMPORT utility can read only the dump created using the EXPORT utility. The IMPDP utility can read only the dump created using the EXPDP utility.

2. Transfer your export data. To do this:

1. Run the script using -mode export or -mode exportdp as the option. For example, to run the script in EXPORT mode:

myscript1.csh -mode export -s myportal -p myportal123 -c mydb -d myexport.dmp

Or to run the script in EXPORTDP mode:

myscript1.csh -mode exportdp -s myportal -p myportal123 -c mydb -d myexport.dmp -dir expimp_dir

where expimp_dir is the logical directory created using "create directory command from SQL*Plus session", and mapped to any physical directory on the server.

2. Finally, using FTP, transfer your dump file and the Export and Import script to the computer where your target Oracle Portal schema resides.

12.7.3 Importing the Transport Set Tables to the Target System

The final step is to use the command-line script to import the transport set tables to the target system. This is done by calling the same script (used in the export) with the -mode parameter set to import or importdb. The parameters in bold are applicable only for import and are mandatory. Refer to Table 12-10 for a description of the parameters.

%MyScript.csh
Usage: MyScript.csh <-mode export_or_import_or_exportdp_or_importdp>
<-s portal_schema><-p portal_password> <-pu portal_username>
<-pp portal_userpassword> <-company company_name> <-c connect_string>
<-d dump_file_names> <-dir directory_object> <-sp source_portal>
<-automatic_merge>

Example to run the script in IMPORT mode:
myscript1.csh -mode import -s myportal -p myportal123 -pu expimp_usr
-pp expimp_usr123 -company ORACLE -c mydb -d myexport.dmp

Example to run the script in IMPORTDP mode:
myscript1.csh -mode importdp -s myportal -p myportal123 -pu expimp_usr
-pp expimp_usr123 -sp myportal -company ORACLE -c mydb -d myexport.dmp
-dir expimp_dir

To perform the entire import from the command line, which initiates a background process, you must include the portal user name and password parameters. This is required to validate your role on the target portal instance.

Notes:

- Remember to set the infrastructure Oracle home (ORACLE_INSTANCE) when running the import script.

- Before running the script using the -automatic_merge option, you must ensure that all external objects listed in the manifest exist in the target instance. You can ensure this by running the script using the -automatic_precheck option. External objects include database schema, tables, external applications, and so on. This information can be obtained by checking the external objects in the source instance.

- The value for the company_name parameter is the company name you see in the login page when working in a hosted portal. When working in a portal that is not hosted, the value for the parameter should be none. If you are running the script in interactive mode, then do not pass a value.

The contents of the dump files are imported, and the transport set is made available from the user interface for merging on the target portal system. Figure 12-18 shows how the import process works.

Figure 12-18 Import Process

The following steps summarize the import process:

1. You import the contents of the transport set dump file to the transport set tables utilizing the same script used in the export.

2. A background job is submitted to initiate the import, and log information is generated.

3. Once the import is complete, you can access the transport set from the user interface.
The final step is to use the command-line script to import the transport set tables to the target system. This is done by calling the same script (used in the export) with the -mode parameter set to import or importdb. The parameters in bold are applicable only for import and are mandatory. Refer to Table 12-10 for a description of the parameters.

%MyScript.csh
Usage: MyScript.csh <-mode export_or_import_or_exportdp_or_importdp>
<-s portal_schema><-p portal_password> <-pu portal_username>
<-pp portal_userpassword> <-company company_name> <-c connect_string>
<-d dump_file_names> <-dir directory_object> <-sp source_portal>
<-automatic_merge>

Example to run the script in IMPORT mode:
myscript1.csh -mode import -s myportal -p myportal123 -pu expimp_usr
-pp expimp_usr123 -company ORACLE -c mydb -d myexport.dmp

Example to run the script in IMPORTDP mode:
myscript1.csh -mode importdp -s myportal -p myportal123 -pu expimp_usr
-pp expimp_usr123 -sp myportal -company ORACLE -c mydb -d myexport.dmp
-dir expimp_dir

To perform the entire import from the command line, which initiates a background process, you must include the portal user name and password parameters. This is required to validate your role on the target portal instance.

Notes:

- Remember to set the infrastructure Oracle home (ORACLE_HOME) when running the import script.

- Before running the script using the -automatic_merge option, you must ensure that all external objects listed in the manifest exist in the target instance. You can ensure this by running the script using the -automatic_precheck option. External objects include database schema, tables, external applications, and so on. This information can be obtained by checking the external objects in the source instance.

- The value for the company_name parameter is the company name you see in the login page when working in a hosted portal. When working in a portal that is not hosted, the value for the parameter should be none. If you are running the script in interactive mode, then do not pass a value.

The contents of the dump files are imported, and the transport set is made available from the user interface for merging on the target portal system. Figure 12-18 shows how the import process works.

Figure 12-19 Import Process

The following steps summarize the import process:

1. You import the contents of the transport set dump file to the transport set tables utilizing the same script used in the export.

2. A background job is submitted to initiate the import, and log information is generated.

3. Once the import is complete, you can access the transport set from the user interface.

Notes:

To preserve data integrity, avoid:

- Importing an object, changing its name, and then reimporting it.

- Importing an object, moving it to shared objects, and then reimporting it.

- Importing an object, and then moving it from one hierarchy to another.

12.8 Behavior of Objects After Migration

The following considerations should be made before migrating portal content from a source instance to a target instance using Oracle Portal Export and Import. This section discusses the behavior of Oracle Portal objects after migration.

Import of Translations

Import of translations in Overwrite mode will not be a strict overwrite, and will act as if the translations are being merged. Any unwanted translations on the target, which do not exist on the source, are not removed when the page group is imported in Overwrite mode. You can remove the unwanted translations after the import. However, new translations brought from the source will be imported. This behavior is true for translations of all relevant objects in the subsequent tables.

This section contains the following subsections:

- Section 12.8.1, "Behavior of Oracle Portal Objects"

- Section 12.8.2, "Import Behavior of Child Objects"

- Section 12.8.3, "Behavior of DB Provider Objects"

- Section 12.8.4, "Behavior of Portal DB Provider Reports Object Types"

- Section 12.8.5, "Behavior of Web Providers"

- Section 12.8.6, "Behavior of Shared Portlet Instances"

12.8.1 Behavior of Oracle Portal Objects

This section discusses the behavior of the following portal objects after migration:

- Page Groups

- Attributes

- Approvals

- Items

- Pages

- Regions

- Portal Templates

- HTML Templates

- Categories

- Perspectives

- Navigation Pages

- Styles

- Item Types

- Page Types

12.8.1.1 Page Groups

On the first export and import, if a page group does not exist, then it is created on your target system. Any settings at the page group level are replicated on the target system. On the second import, depending on the mode selected:

Replace on Import mode. The page group properties from the source replace those on the target. All objects within the page group are created or updated depending on whether or not they existed.

Reuse mode. When page groups already exist on the target, the properties are reused and not updated. New objects within the page group are created; existing objects are reused.

Notes:

- New pages are currently not created when page groups are imported using Reuse mode.

- The order of visible objects (in the Configure tab) may differ between the source and target portal. The result is that the drop-down lists (when selecting an item, category, and so on) will look different in the target portal. You can manually reorder the visible objects in the target.

- All configurable settings of a page group are reused and overwritten appropriately in the Configure tab (found when you click Properties for a page group).

- If a page group is imported with a different name, then a new page group is created on the target.

- Migration of the Shared Objects page group excludes pages that cannot be edited or exported, for example, the A to Z root pages.

12.8.1.2 Attributes

On the first export and import, the attributes are created on the target system. The second import, depending on the mode selected for your target:

Replace on Import mode. The properties of the attribute are updated.

Reuse mode. When the attribute already exists on the target, it is reused and not updated.

Notes:

- Attributes that are marked as external cannot be created on the target, even with Any Transport Set - Manage privilege.

- Attributes on the source and the target can only be considered the same when they have the same name, are the same type and have the same unique internal identifier. If the two attributes have the same unique internal identifier but different names, then they can be only imported in Replace on Import mode. If the name and the type are the same, but the unique internal identifier is different, then the attribute import will fail and cascade to any other related objects.

12.8.1.3 Approvals

To view the approvers, access control lists must be exported and imported along with the page group or page that has an approval defined on it.

Replace on Import mode. The approval process can be established for a page or page group. If a page group or a page is marked for either insert or update, then the approval object will be processed in Replace on Import mode. All the approved information in the target will be deleted and re-created. Note that pending items on the source will not be imported, and any pending items on the target will be deleted altogether.

Reuse mode. No action is performed.

12.8.1.4 Items

Item information comes as a part of page export. They follow the import mode of the page.

Replace on Import mode. When a page is imported in Replace on Import mode, items in page regions from the source are copied to the target. Any items found only on the target are removed, items that exist on both the source and target are updated, and items that exist only on the source are created.

Reuse Mode. No items are imported from the source. The page from the source is only used as a reference, and will determine the import mode of items.

Notes:

- The schema associated with a PL/SQL item, page, or attribute, is extracted only if it is not a Public schema or a Creator schema. Such a schema is marked as an external object. The schema needs to be present on the target database to avoid a preliminary check failure. However, you can proceed with the import. The logs will show appropriate messages indicating that it will result in run time errors that can be corrected by bringing in the schema later and reassociating it.

- The list of object items will show differently between source and target unless you migrate those referenced objects (pages, categories, and perspectives) within the same transport set as the list of objects. Note that the Dependency Manager will not mark the objects referenced in the list of objects for export. For this reason, you need to explicitly mark those referenced objects for export, or ensure that they are already in the transport set.

- If portlet instance items are moved from one region to another between subsequent imports of the same page, then any personalizations made by users on those portlet instances are removed.

- Items for pages based on a template are synchronized, in Overwrite mode.

- All explicitly checked-out items in an active state are made checked-in after import.

12.8.1.5 Pages

Exports the page and the page type, template, and style it references along with content (item and portlets).

Replace on Import mode. The properties of the page are replaced. See Section 12.8.1.6, "Regions" for region import behavior. See Section 12.8.1.4, "Items" for item behavior.

Reuse mode. The original page on the target is reused. Child objects are not created on the target (if they do not already exist).

Refer to Table 12-11, "Import Behavior of Regions in Overwrite Mode", for information on import behavior when a page is imported in Overwrite mode.

Notes:

- The current release does not support locking and unlocking content using WebDAV. Content contributors can lock a file, which in turn will check out the item. On import, no owned locks will be displayed.

- When a page exposed as a portlet appears in the external objects list, make sure to include the page in the transport set.

12.8.1.6 Regions

Region information comes as part of page export. They follow the import mode of the page.

Replace on Import mode. When a page is imported in Replace on Import mode, page regions from the source are copied to the target. Any regions found only on the target are removed, including all content in those regions.

Reuse Mode. No regions or items are imported from the source. The page from the source is only used as a reference, it will determine the import mode of regions.

Note: This release of Oracle Portal implements synchronization of target regions with the source. See Table 12-11, "Import Behavior of Regions in Overwrite Mode" for more information.

Synchronization of Regions

This release of Oracle Portal implements synchronization of target regions with the source. The import behavior when a page is imported in Overwrite mode is described in Table 12-11.

Table 12-11 Import Behavior of Regions in Overwrite Mode

Case

Source

Target

import Behavior

Synchronization of target regions with the source

Region_A

Region_B

Region_D

Region_A

Region_C

Region_D

Region_E

- The attributes of Region_A and Region_D are updated with the properties from the source.

- Region_B is not found on the target and will be created.

- Region_C and Region_E, which exist only on the target, are deleted.

Region delete from target

-

-

When a region is deleted from the target, all the items and portlets, including user personalizations, are deleted from the target.

Root region mismatch for a page

Note: A page can only have one root region.

Root region – Region_X

Root region – Region_Y

The entire root Region_Y hierarchy is deleted from the target and re-created with the Region_X hierarchy from the source.

Region type mismatch

Note: Available region types are item, portlet, tab, and subpage.

Region_X – Type A

Region_X – Type B

When there is a region type mismatch, all the items and portlets under that region (including user personalizations) are removed from the target and re-created with the items from the source region.

Region type match

Region_X – Type A

Region_X – Type A

The target items are synchronized with the source items for that region.

Synchronization of target items with source

Note: This happens whenever the source and target region type matches.

Item_A

Item_B

Item_D

Item_A (base user)

Item_A (personalized for User A)

Item_C (base user)

Item_D (base user)

Item_E (personalized for User B)

- Item_A (base user) is overwritten.

- Item_A (User A personalization) is preserved on the target.

- Item_B is created on the target.

- Item_C (base user) is deleted from the source.

- Item_D (base user) is overwritten.

- Item_E (User B personalization) is preserved on the target.

Note: Although Item_E does not exist in the source, it is not deleted from the target because it is a user personalization on the target.

Only base user item records are part of the structure of a page, and are shown when a page is edited.

12.8.1.7 Portal Templates

Exports the template, the style it references, and any content on the template. The layout and content of pages that depend upon the template are synchronized with the revised template on the target.

Replace on Import mode. The template properties are replaced on import.

Reuse mode. Template information is reused on the target and is not updated from the settings on the source system.

Notes:

- Do not export or import the Category Pages Template or Perspective Pages Template found in the shared objects or page group. They are present only if a category or perspective is created in that page group.

- A template can force all pages based on the template to use the template's style, or it can allow pages based on it to have their own styles. When importing a template whose style has changed, the changes are only propagated to the pages based on the template, if the template forces the pages to use the template's style.

- Templates that were modified after the last import cannot be reused. If you try to reuse a modified template, then the template will fail the preliminary check stage along with the pages in the transport set that are based on the template. Appropriate messages are logged in the preliminary check logs indicating that you have to mark the template in Overwrite mode to proceed with the import.

- When a page or an item that uses Portal Templates for Items is migrated, the Portal Templates for Items are brought in as dependencies in the target.

- If pages based on a portal template are imported where the template is in Overwrite mode, any page customizations (such as move, hide, add, or delete) on page regions, items, or portlets based on the template are brought from source to target including regions and item/portlet movements. The target page should simply look same as the source page.

- If a portal template is imported in Overwrite mode, any page personalizations on the target are preserved as long as the base item, portlet, region, or tab exist in the migrated page.

Caution:

Deletions on a tab as part of personalizations on the target will be lost. The user will not be able to see any items or portlets under the personalized deleted tab after it is imported. This is because the template takes precedence and recreates the tabs on the target based on itself. However, since the personalization data is preserved, the actual items or portlets under the tab will not be recreated.

12.8.1.8 HTML Templates

On the first export and import, the HTML Templates are created on the target system. On the second import, depending on the mode selected for your target:

Replace on Import mode. The properties of the HTML Template are updated.

Reuse mode. If the HTML Template already exists on the target, then it is reused and not updated.

12.8.1.9 Categories

Exports the category and its subcategories.

Reuse mode. The original category on the target is reused. Child objects are not created on the target (if they do not already exist).

Notes:

- The category page (the page that appears when a category is clicked) and the category template are not exported. They are created each time on import. The category is always reused; therefore, you make changes once on the target, and the changes will not be lost during subsequent imports. This applies to the category, the category page, and the category template.

- There is no Replace on Import mode. The Replace on Import option will not apply; the category will always be reused.

12.8.1.10 Perspectives

Exports the perspective and its subperspectives.

Reuse mode. The original perspective on the target is reused. Child objects are not created on the target (if they do not already exist).

Notes:

- There is no Replace on Import mode. The Replace on Import option will not apply; the perspective will always be reused.

- The perspective page (the page that appears when a perspective is clicked) and the perspective template are not exported. They are created each time on import. The perspective is always reused; therefore, you make changes once on the target, and the changes will not be lost during subsequent imports. This applies to the perspective, the perspective page, and the perspective template.

12.8.1.11 Navigation Pages

Exports the navigation page, the style it references, and any links on the navigation page.

Replace on Import mode. The properties of the navigation page are replaced.

Reuse mode. The original navigation page on the target is reused.

12.8.1.12 Styles

Exports the style.

Replace on Import mode. The properties of the style are replaced.

Reuse mode. The style on the target is reused.

Notes:

- Styles on the source and the target are considered the same when they have the same name and the same unique internal identifier. If the two styles have the same unique internal identifier, but different names, then they can be only imported in Replace on Import mode.

- Attributes associated with styles are not imported. A local style is associated with all the local attributes of the page group to which the style belongs, and all the shared attributes. A shared style is associated with all the shared attributes.

12.8.1.13 Item Types

Exports the item type and the attributes it references.

Editable seeded item types present in all portal instances are extracted.

Notes:

- If you have to modify a seeded item type, then Oracle recommends you make a copy of the seeded item type, and then modify the properties of the copy.

- Item types on the source and the target are considered the same when they have the same name, are the same type, and have the same unique internal identifier. If the item types on the source and the target have same unique internal identifier, but different names, then they can only be imported in Replace on Import mode.

- Currently, when the attributes associated with the custom types (item type, page type) are modified or the functions associated with the custom type are modified between imports, the changes are not always correctly migrated. You should delete and re-create the custom type on the target. This results in all the items and pages (based on the custom type) being deleted.

- If an item link in a page points to an item on another page, then during export of the page containing the item link, the page containing the linked object is brought in as a dependent page.

12.8.1.14 Page Types

Exports the page type and the attributes it references.

Notes:

- Page Types on the source and the target can only be considered the same when they have the same name, are the same type and have the same unique internal identifier. If the page types on the source and the target have same unique internal identifier but different names then they can only be imported in Replace on Import mode.

- Currently, when the attributes associated with the custom types (item type, page type) are modified or the functions associated with the custom type are modified between imports, the changes are not always correctly migrated. You should delete and re-create the custom type on the target. This will result in all the items/pages (based on the custom type) being deleted.

12.8.2 Import Behavior of Child Objects

This section describes the functioning of child objects after migration. Table 12-12 describes the behavior in detail.

Table 12-12 Import Behavior of Child Objects

Name of Object

Objects

Import Behavior

Contained objects, which contribute to the structure of the object

- Regions

- Items

- Tabs and subtabs on a page

- Contained objects are created or overwritten when the contained object is created or overwritten.

- When container objects are reused for the target, none of the contained objects will be created from the transport set, even if they do not exist on the target.

Contained objects that do not contribute to the structure of the object, but act as placeholders within a container.

- Attribute, Style, Category, Perspective, Item Type, Page Type, Page, and so on, in a page group.

- Form, Report, Chart, Dynamic Page, and so on, in a Portal DB Provider.

- Contained objects are created when the container object exists on the target, or are created from the transport set.

- When container objects are reused for the target, only new contained objects will be created from the transport set. All the existing objects will be left untouched on the target.

Child objects

- Subpage

- Subcategory and subperspective

- Child objects are created when the parent object exists on the target, or are created from the transport set.

12.8.3 Behavior of DB Provider Objects

This section describes the behavior of the following DB Provider objects after migration:

- Seeded DB Providers

- Portal DB Providers

- Portal DB Provider Components

- Shared Components

- Registered Database Providers

12.8.3.1 Seeded DB Providers

- When a page with Develop-in-Place portlets is imported, the components related to those portlets are automatically created in the database schema of the target portal's Develop-in-Place provider.
The name of the Develop-in-Place database provider is PTL_TOOLS_APP. The underlying database schema for PTL_TOOLS_APP is <PortalSchema>_APP.

- For other seeded database providers, the relevant components brought in from the source portal are automatically created in the database schema of the target portal's database provider, if the provider already exists on the target portal.
You have to make the seeded database provider a part of the transport set, if it does not already exist on the target portal. Otherwise, you do not need to move it.

Notes:

- The Develop-in-Place provider cannot be exported or imported on a standalone basis, that is, the Develop-in-Place portlets have to exist on a page.

- The Develop-in-Place provider, unlike other database providers, does not show up as an external object in the UI manifest.

- When migrating any database provider, if the Develop-in-Place components or components from other database providers are getting their data from database objects in a schema other than the underlying schema for the database provider, then that database schema should also be exported and imported into the target portal in advance using the exp and imp utilities.

12.8.3.2 Portal DB Providers

On the first export and import, if a Portal DB Provider does not exist, then it is created on the target system.

- Portal DB Provider properties will be created on the target.

- Provider registration will be done for the newly created Portal DB Provider.

On the second import, depending on the mode selected for the target:

Replace on Import mode. The Portal DB Provider properties from the source replace those on the target. All components within the Portal DB Provider are created or updated depending on whether or not they exist.

Reuse mode. When a Portal DB Provider already exists on the target, the properties are reused and not updated. New components within the Portal DB Provider are created, and existing components are reused.

Note:

If you are migrating a Portal DB Provider, then you need to perform the following tasks before importing the Portal DB Provider:

1. Ensure that the schema that is used by the Portal DB Provider being exported, exists in the target database instance and that the CONNECT and RESOURCE roles have been granted to it.

2. Run the provsyns.sql script (located in the MID_TIER_ORACLE_HOME/portal/admin/plsql/wwc directory) on the target. Using SQL*Plus, log in as the Portal schema owner and run the script from the SQL prompt, as follows:

SQL> @provsyns.sql <db_provider_schema_name>

The provsyns.sql script can be executed multiple times for a Portal DB Provider schema.

12.8.3.3 Portal DB Provider Components

The following are the Portal DB Provider components:

- Menu

- Forms

- Reports

- Charts

- Calendars

- List of Values

- Link

- Hierarchies

- Dynamic Pages

- XML/URL Components

- Data Components

On the first export and import, the components are created on the target system.

- The first version of the component will be created under the nominated Portal DB Provider, and this will be the production version.

- A package will be created with the same name as the component under the schema associated with the Portal DB Provider.

On the second import, depending on the mode selected for the target:

Replace on Import mode. A new version of the component is created on top of any existing versions, and this will be the production version. Existing versions on the target, if any, will be archived. The package will be regenerated with the information obtained from the production version.

Reuse mode. If the component does not exist on the target, then it will be created.

Notes:

- List of Values and Link components do not have versions or a package associated with them. Therefore, these components are deleted and re-created on the target, in Overwrite mode.

- Because the List of Values and Link components cannot render on their own, or they are not in portlet form, there will not be any personalizations attached to these components.

- The List of Values (LOV) appears as an external object, which you can choose to make explicit. If an LOV does not exist on the target, then the import will proceed, and the logs will indicate that the LOV associated with the attribute was reset, and you could bring in the LOV and reassociate it later.

12.8.3.4 Shared Components

The following are the shared components:

- Color

- Font

- Image

- JavaScript

- UI Templates (Structured, Unstructured)

On the first export and import, if a shared component does not exist, then it is created on the target system.

On the second import, depending on the mode selected for the target:

Replace on Import mode. The shared components are deleted and re-created with the source information.

Reuse mode. When a shared component already exists on the target, the properties are reused and not updated. New shared components are created, and existing components are reused.

Note: System colors, fonts, and templates are reused on the target, and they are never exported and imported.

12.8.3.5 Registered Database Providers

The schema associated with a registered database provider is marked as an external object in the manifest. Note that on import:

- If the provider and the schema do not exist on the target, then the schema fails the preliminary check, which causes the provider to fail, in turn causing the explicit object to fail.

- If the provider exists and the schema differs on the source and the target, then the provider is assigned a warning status, and the logs will display that a difference in schemas exists.

Note: You must ensure that all the objects are valid after you migrate the schema from the source to the target, to avoid database registration errors.

12.8.4 Behavior of Portal DB Provider Reports Object Types

The Report Security Access Objects are always exported or imported as part of the Portal DB Provider export and import.

Notes:

- The granular export and import of Report Security Access Components are not supported.

- The Report Security Access Components behave in the same manner as DB Provider components in versioning.

- A package is created or regenerated for the Report Definition File (RDF) access component, similar to DB Provider Components.

12.8.5 Behavior of Web Providers

This section describes the following Web providers:

- OmniPortlet

- Web Clipping Providers, WSRP Producers, and Other Web Providers

Enabling and Disabling Export and Import of Web Providers

To enable or disable the migration of OmniPortlet and Web Clipping providers, edit the following variable in the DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\kjdcke\war\WEB-INF\web.xml file:

<env-entry>
<env-entry-name>oracle/portal/provider/global/transportEnabled</env-entry-name>
<env-entry-value>true</env-entry-value>
<env-entry-type>java.lang.String</env-entry-type>
</env-entry>

Set the value to false to disable export and import of OmniPortlet and Web Clipping providers.

12.8.5.1 OmniPortlet

OmniPortlet providers, including their default personalizations and related information, referenced by your transport set will be exported and imported with the pages automatically.

Connection information (for example database, user name, password, URL, HTTP authentication user name and password, and so on) associated with an OmniPortlet instance is migrated automatically by default.

If you want to disable the exporting and importing of connection information because of security reasons, then edit the DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\1pwj8k\war\WEB-INF\providers\omniPortlet\provider.xml file and set the exportConnectionInfo parameter to false. For example:

<provider class="oracle.webdb.reformlet.ReformletProvider">
<exportConnectionInfo>false</exportConnectionInfo>
...
</provider>

If the connection information is not migrated, then the imported OmniPortlet uses the connection information of the same name on the target, if it exists. You can also enter the connection information of the imported OmniPortlet instance from the Edit Defaults page or the Personalize page.

If the connection information to be imported has the same name as an existing connection information of a provider in the target, then the source provider's connection information will not be imported unless the Overwrite mode is specified. Messages will be written to the transport log if the import of connection information failed.

Reuse mode. OmniPortlet providers are always reused.

Notes:

- If the provider registration generates an error due to insufficient privileges, then the provider object fails the preliminary check stage. This is then cascaded to the explicitly selected objects. A provider failing always fails the explicitly selected objects.

- Edit Default customizations are migrated. User personalizations are preserved on target, if present.

Important:

- If localePersonalizationLevel is different between the source OmniPortlet provider and target OmniPortlet provider, then some imported personalizations may become inaccessible in the imported pages. For example, if the current locale is Japanese, and if localePersonalizationLevel is set to locale on the source OmniPortlet provider and to none on the target OmniPortlet provider, then the Japanese personalizations will become inaccessible after importing.
You can set localePersonalizationLevel in the provider.xml file located in the directory, DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\1pwj8k\war\WEB-INF\providers\omniPortlet.

For detailed information about localePersonalizationLevel, see the release note at MID_TIER_ORACLE_HOME/portal/pdkjava/v2/pdkjava.v2.release.notes.html.

- If OmniPortlet portlets are configured to use an SSL URL for fetching data, then you must copy these files manually, as SSL URL certificates are not exported and imported by default. Perform the following steps to manually copy the certificate files to the target instance:

1. Append the SSL URL certificates to the certificate file used by the OmniPortlet provider (default is ORACLE_HOME\portal\conf/ca-bundle.crt).

2. Update the <trustedCertificateLocation> tag in OmniPortlet provider.xml file located in DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\1pwj8k\war\WEB-INF\providers\omniPortlet.

3. Restart WLS_PORTAL.

12.8.5.2 Web Clipping Providers, WSRP Producers, and Other Web Providers

Web Clipping providers, WSRP producers, and other Web providers referenced by your transport set must either exist already on your target system or be able to be registered successfully during the import on your target system.

Reuse mode. Web Clipping providers, WSRP producers, and other Web providers are always reused.

Important: If Web Clipping portlets are configured to use SSL URLs for fetching data, then you must copy these files manually, as SSL URL certificates are not exported and imported by default. Perform the following steps to manually copy the certificate files to the target instance:

1. Append the SSL URL certificates to the certificate file used by the Web Clipping provider (default is MID_TIER_ORACLE_HOME/portal/conf/ca-bundle.crt).

2. Update the <trustedCertificateLocation> tag in the OmniPortlet provider.xml file located in DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\1pwj8k\war\WEB-INF\providers\omniPortlet.

3. Restart WLS_PORTAL.

Notes:

- If the provider registration generates an error due to insufficient privileges, then the provider object fails the preliminary check stage. This is then cascaded to the explicitly selected objects. A provider failing always fails the explicitly selected objects.

- When WSRP portlets are imported, the portlet personalizations are not imported.

12.8.6 Behavior of Shared Portlet Instances

The scenarios in Table 12-13 summarize the behavior of shared portlet instances during migration.

Table 12-13 Behavior of Shared Portlet Instances During Migration

Source

Target

1. Export the shared portlet user page (without the portlet repository information).

1. Import the shared portlet for the first time.

2. Register it under the portlet repository with the display name of the shared portlet instance.

1. Rename the shared portlet instance.
Note that these changes are not reflected on the portlet repository item which will still contain the original name/display-name)

2. Export the user page.

1. Import the renamed shared portlet instance after it is already exists on the target.
Since the portlet instance is reused on the target, the display-name changes from the source are not migrated.

12.9 Recommended Best Practices When Exporting and Importing

The following is a summary of important recommendations and best practices developed for migrating portal content from a development or test environment to a production instance using Oracle Portal Export and Import.

- Naming Convention for Replicated Tabs

- Migrating Page Groups and Components

- Migrating Portal DB Providers and Components

- Migrating Search Components

- Migrating Content Between Upgraded Oracle Portal Instances

- Exporting and Importing in a Hosted Environment

- Importing Data with Oracle Text Index Synchronization Turned Off

- Migrating Users and Groups

12.9.1 Naming Convention for Replicated Tabs

In earlier releases, the replicated tabs on the target had a different name from that on the source when the tabs were replicated on the pages based on the template. As a result, when you brought in the page at a later time, the tabs on the source did not match the ones on the target, and extra tabs were created on the target.

In this release of Oracle Portal, having a predictable naming convention for replicated template tabs helps to avoid duplication of tabs. Because a page name has to be unique only in a hierarchy, the replicated tabs assume the same name as the template tab. However, you must ensure that you do not rename the replicated tab.

12.9.2 Migrating Page Groups and Components

Page groups and their associated components may be moved from development to production using the Export and Import utilities described in this document. In addition to page groups as a whole, individual components within page groups such as subpages, categories, perspectives, and page styles can be moved individually to the target system, only if the entire page group has been imported to the target system earlier.

- Considerations and best practices to keep in mind:

- The first export to your target system migrates the entire page group from the source portal to the target portal instance. Subsequent transport sets can then export an individual page or other page group component on the target portal installation.

Note:

The preliminary check process will fail for an object if the page group does not exist on the target. Whenever a page group object is exported, the page group that owns the object is included as an external dependency. You can choose to make the page group explicit if you do not know if the page group exists on the target, and therefore avoid any potential preliminary check failures.

The same applies to other objects included in a hierarchy. Categories, perspectives, and pages when exported display the parent category, perspective, or page as an external dependency in addition to the page group to which they belong. All database provider components display the provider as an external dependent when they are exported by themselves.

The default settings of a page group, for example, the default template, style, navigation page, and so on are also extracted by the Dependency Manager and classified as either reference or external (that is, local or shared).

- All new or existing content on a page is replaced when a page with the same name is reimported to the target.

- You can only move objects within a page group to the same page group of the same name on the target portal.

- A page is migrated along with any subpages.

- After an initial import operation to your target system, if you change the name of the page group on the target system, then subsequent import attempts to that page group will fail.

- Categories, item types, perspectives, and page types that are configured in the source are not automatically configured in the target. You must explicitly configure these objects unless you are doing a page group export.

- Page URL behavior: Always use page link item types or path-based URLs when creating links to portal pages. Do not use raw portal page URLs.
By default, portal page URLs generated by Oracle Portal contain installation-specific ID numbers that change when the object is exported. This causes broken links when pages are imported into a different site.

The following is an example of a URL generated for a page. If the page is imported on another site, then this page ID will change.

http://my.portal.com/servlet/page?_pageid=47,49&_dad=portalr2&_schema=portal

If you are using such URLs as manually entered links, then Oracle recommends you use path-based URLs or Page Link item types.

The same page has the following path-based URL:

http://my.portal.com/portal/pls/portal/url/PAGE/HRPAGEGROUP/HRHOME/HRBENEFITS

To find the path-based URL for a page, look at the page property sheet. A link to the property sheet can be displayed by adding a Property Sheet Smart Link item to the page.

You can also use a Page Link item type to create a link to a page. The Page Link item type dynamically generates the correct link at run time.

- Page portlets: When you replace a page, the content and the structure are replaced on the target.

Note:

- This release does not support importing and exporting the Oracle Portal Survey components or the Favorites portlet. Any new Favorites or Groups added in the source will not show up in the transport set, nor will they be migrated to the target.

- This release supports exporting and importing generic page portlets. A generic page portlet can now be configured to point to any page. The page that the page portlet points to is marked by the Dependency Manager as referenced/external depending on whether or not it belongs to the same page group. On import, this information is resolved and stored in the preference store. On import, if the page does not exist on the target, then the portlet is reset.

- This release supports exporting and importing Web providers and their default personalizations. See the section on controlling the export and import of portlet personalizations in the Oracle Fusion Middleware Developer's Guide for Oracle Portal.

To preserve the content in a page (items, portlets) on the target, but import a style layout, or for rendering changes from the source, you must expose your content through the Federated Portal Adapter portlet. The key is to separate your content from your page structure into two separate page groups. One for content only, exposed through the Federated Portal Adapter, and the other is your display page group. Users can use this to access, view, and customize their portal. Follow these steps:

1. On the source system, create a page group that only contains pages that have one region that you will later expose to other pages. This region is to be populated with either portlets or items. Name this page group Content Page Group.

2. Export this content page group to the target system.

3. On the target system, register the content page group through the Federated Portal Adapter. Expose these pages as portlets through the Federated Portal Adapter provider on the target system.

4. On the source system, register the same provider (using the same name as the Federated Portal Adapter provider).

5. On the source system, create another page group called Display Page. In this page group, create pages with regions that expose the portlets from the Federated Portal Adapter provider. You can also include tabs and other portlet regions in this page group if required.

6. Export the Display Page group to the target system.

7. From the target system, update, delete, modify, and add new items to the regions and pages in the content page group exposed through the Federated Portal Adapter provider.

8. On the source system, make changes to the page structure (tabs, new regions, and so on) to the Display Page page group.

9. Export the latest Display Page page group to the target system.

10. Verify that the Content Page Group contains the new changes that you made in Step 7, on the target environment.

11. Verify that the target system contains the latest changes to the pages in the Display Page page group that you recently changed.

Note:

When a page containing a portlet from an adapter rendered provider (the loop-back case) is imported and the provider is automatically registered on the new portal, it will have the old URL, referencing the old portal.

When a loop-back provider is required in the new portal, you will have to create one or update the default provider.

- Page and Portlet Personalizations and Edit Defaults Migration. You can preserve the user customizations on a page or portlet on the target system while replacing or reusing the edit properties of that page or portlet.

Note:

Personalizations for Web portlets are not currently preserved. Migration of Edit Defaults is supported for OmniPortlet and Web Clipping providers. If other providers implement this feature, their Edit Defaults will also be migrated. See the Oracle Fusion Middleware Developer's Guide for Oracle Portal for information about how to implement this support.

Base objects that no longer exist on the page in the source portal will be removed from the target page after subsequent imports. This ensures that all personalizations for base portlet regions are also removed. Base objects are regions, portlets, items, and tabs that are imported as part of the core definition of the page, defining its structure and content.

Portlets that already exist on a page behave in the following way when the page is imported in Replace on Import mode:

- Edit Defaults will be migrated.

- User Personalizations will be preserved.

Properties of the page behave in the following way when the page is imported in Replace on Import mode:

- Edit Properties will be replaced.

- User Personalizations will be preserved, subject to the user customizations being valid.

Note:

You can personalize, add, hide or show, delete, and move portlets and tabs. The page must have at least one portlet region and one tab (tab related customizations) in that region. The customized objects inherit the properties of the page. When a region is deleted, for example, a second import removes the region or tab from the page, then customized objects will also be deleted.

When you import the page with an increase in the number of portlets on a page, the source takes precedence even if you have customized the page in the target and deleted a portlet. The next time you import the same page, the deleted portlet is considered to be a new portlet to be added to the structure on the target. This also applies to tabs.

The order of appearance of these portlets (personalizations) and the portlets that form the content of the page are determined by the source and mode of import.

- Replace on Import mode. The portlets from the source are arranged in the order found in the source followed by the portlets in the target (personalizations).

- Reuse Mode. The personalizations are preserved, and there will be no changes to the target page.

12.9.3 Migrating Portal DB Providers and Components

Portal DB Providers and their associated components can be moved from a development environment to a production environment using the Export and Import utilities described in this chapter. In addition to Portal DB Providers as a whole, individual components within Portal DB Provider such as forms, reports, charts, and calendars can be moved individually to a target system. This is possible only if the entire Portal DB Provider was imported to the target system earlier.

Some considerations and best practices for migrating Portal DB Provider components are:

- Do not rearrange Portal DB Provider portlet IDs directly in the provider.xml file as this is likely to cause problems after migration.

- Avoid using the portal schema for storing Portal DB Provider components, or the database objects that the components reference.

- In the source environment, create a separate schema (referred to as the portlets schema) for the Portal DB Provider components. This is the schema that is referenced in the registration information when the Portal DB Provider is created.

For more information, see the section "Creating a Schema in Oracle Portal" in the Oracle Fusion Middleware Developer's Guide for Oracle Portal.

- In the source environment, create a separate schema (referred to as the database objects schema) for the database objects that the components reference. If the database objects already exist in a particular schema, then ensure that this schema is not referenced when creating the Portal DB Provider. This is the schema that holds database objects such as Tables, Views, or Procedures that are used in the creation of Portlet DB Provider components. For example, when you build a form based on a table, view, or a procedure, the table, view, or procedure is stored in the database objects schema.

- Before importing the Portal DB Provider and its components, ensure that the database objects schema referenced by the components is available in the target environment. The database objects schema must have the same name as in the source environment. Ensure that the database objects and database objects schema have the same grants and privileges as in the source environment. Also ensure that the status of all database objects is valid. The database objects schema can be exported or imported using the database's export or import utilities.

- Before importing the Portal DB Provider and its components, create an empty portlets schema in the target environment with the same name as in the source environment.

- Ensure that the Portal DB Provider does not have any components that are in Edit or Archive mode. All components being exported should have only one valid production version to ensure that the target environment contains valid components after an import.

- If a page group contains portlets from a Portal DB Provider, then the provider has to be explicitly included in the transport set you are exporting. As an alternative, you can also export or import the provider earlier.

- The schema associated with registered Portal DB Providers is extracted as external object on the manifest.

Note:

While importing a database objects schema, you must ensure that the ACLs (roles and privileges) associated with the schema already exist on the target system. This ensures that the generation of components, or the registration of database providers, does not fail during the import.

12.9.4 Migrating Search Components

There a number of options for adding search components to your pages. You can add a Basic Search to match search criteria entered into the Search field, an Advanced Search, and a Custom Search to create an automatically executed search.

12.9.4.1 Basic and Advanced Search Portlets

Basic Search portlets and Advanced Search portlets can be exported and imported. After import, the portlets should appear as they did in the source portal including the user preferences (if the user preferences were being imported).

12.9.4.2 Custom Search Portlets

Custom Search portlets can have many customizations which refer to other objects in the portal, such as page groups to search, attributes to search on, image on submission form, style for results, page for the results, attributes for the results, default values for category, perspective and item type attributes. These can be referred to as dependencies. When a custom search portlet is exported and imported, its dependencies are calculated and shown as external dependencies in the manifest. It is up to the user to include it in the transport set, so that it is exported and imported as well.

If not included, it is possible that a custom search portlet can be customized in the source but the dependencies do not exist in the target. Also, a custom search portlet in the source may have been customized and then the dependency is removed from the portal and the custom search portlet's customizations are not updated. In this case, when the custom search portlet is used for a search, the missing reference is ignored. When the custom search portlet is customized again and the customizations saved the missing reference is removed.

On export, all the custom search portlets that were selected for export are checked and any missing references are removed. The customizations are then included in the transport set.

On import, a preliminary check determines if any dependencies are missing in the target after import. Messages are written to the log. For each custom search portlet that has missing dependencies, the log will show the reference path of the custom search portlet and the missing dependencies and what will happen on import.

The page on which the custom search portlet resides will be flagged with a warning. On the actual import, the custom search portlet customizations are modified to have the correct IDs of all the same dependencies in the target, and the customizations are copied into the target.

Note:

Search results saved using the Saved Searches portlet are not imported or exported. You should submit the same search in the new target and save the latest set of search results.

12.9.5 Migrating Content Between Upgraded Oracle Portal Instances

Export and import is not supported between two portals that are upgraded from releases earlier than 9.0.2. For example, assume that you have a source development portal instance and a target production portal instance, both of release 3.0.9. You then upgrade both the instances independently to release 9.0.4, and then to release 11.1.1. Exporting and importing content between these two upgraded 11.1.1 development and production instances is not supported.

During an upgrade from a pre-9.0.2 release of Oracle Portal, objects (styles, attributes, item types, and page types) are given a new Global Unique Identifier (GUID). If the GUIDs do not match between objects in two Oracle Portal instances, then the preliminary check for these objects will fail. If, for example, you have a source development instance and a target production instance, then you must resynchronize the Oracle Portal instances to avoid preliminary check failures. To do this, perform the following steps:

1. Create an empty portal instance that will become the new source development instance.

2. Export the contents of the target production portal instance.

3. Import the contents into the new source development portal instance.

You have now exported and imported the contents from your target production portal instance to the new source development portal instance.

References to seeded page group objects, such as Top Level Pages and Design-Time Pages, will not resolve to the correct GUIDs across two instances. Remove these references from the objects you are exporting. Alternatively, you can create new objects that copy the functionality of the seeded page group objects.

Caution:

Any new components in the development instance are lost during the re-creation of the development portal instance. Migrate all the new components from the development instance to the production instance before you upgrade the production instance. If you have partially developed components, then you must re-create these after the new development portal instance is created.

See Also:

Section 12.4.2, "Oracle Portal Export - Alternate Method"

12.9.6 Exporting and Importing in a Hosted Environment

Oracle Portal Export and Import supports the creation of classified content that can be used for replicating content and structure for new subscriptions. It does this by letting the portal instance set the subscription information during the import of the transport set contents into system tables. This means that in a hosted environment, you can export from any subscription, and you can import into any other subscription. This import is not limited to just one subscription; you can import the contents of the same transport set into multiple subscriptions, as follows:

1. Run the command-line utility in import mode.

2. Log in to a subscription.

3. Import the contents of the transport set into the subscription.

Example 12-1 shows a scenario where Oracle Portal Export and Import can be used to import the contents of a transport set into multiple subscriptions.

Example 12-1 Importing Content into Multiple Subscriptions

1. Create a default seed subscription where the objects will be created and managed.

In this subscription, you create a classified content and structure, which could consist of page groups, pages, other page group objects, Portal DB Providers and their components (exposed as portlets in the pages), portlets from Web providers, and so on.

2. Export the content and structure to a transport set, which becomes the seed transport set.

3. Export the contents of the transport set to a dump file.

4. Create a new subscription with the same structure and content defined earlier, by performing the following steps:

1. Create the new subscription.

2. Import the contents of the dump file into the portal instance.

3. Log in to the new subscription.

4. From the Transport Set portlet, select the transport set and import it.

5. Verify that the new subscription now contains the required structure and content.

5. Repeat the previous step for each new subscription that you want to be based on the structure and content created in step 1.

This procedure can be used to create multiple taxonomic categories by creating transport sets for each category, and following the preceding procedure to populate new subscriptions.

Note:

In a hosted environment with multiple subscribers, you cannot secure transport sets to a specific subscription in Oracle Portal. If you created a transport set for export and import, then any other user who logs in to Oracle Portal will be able to view the contents of the transport set that you created, in all subscriptions in that portal.

12.9.7 Importing Data with Oracle Text Index Synchronization Turned Off

While importing large data sets into a target Oracle Portal instance, it is sometimes observed that the import process takes a longer time than normal, if synchronization of Oracle Text indexes is enabled. The import process is faster if you disable the synchronization of text indexes for the period of the import. To disable the synchronization of Oracle Text indexes, perform the following steps:

1. Before you start the import process, run the following command in the target Oracle Portal instance as the portal schema owner (PORTAL):

@textjsub.sql STOP

Refer to Section 10.3.5.4, "Scheduling Index Synchronization" for details on scheduling, starting, and stopping text index synchronization.

2. Ensure that the wwv_context.sync job does not exist on the dba_jobs table.

3. Import your data set. See Section 12.6.1.2, "Importing Data" for more details.

4. Run the textjsub.sql script as the portal schema owner (PORTAL):

@textjsub.sql START

5. Optionally, run the command to synchronize Oracle Text indexes. Refer to Section 10.3.5.1, "Synchronizing Oracle Text Indexes" for the procedure to do this.

12.9.8 Migrating Users and Groups

Oracle recommends the following procedure for exporting and importing:

- Develop your portal objects (page groups, content, portlets, and so on) on your source development system.

- To simplify the task of exporting and importing, assign users, groups, and privileges only on your production system.

- Use Export and Import to migrate your portal objects to your target production system.

- Apply users and privileges to imported portal objects as needed.

Users and groups are defined in Oracle Internet Directory. When you choose to include access control lists and User and Group preferences during Oracle Portal Export, the user and group profiles held in the portal schema are included in the transport set. However, this does not migrate the user and group definitions that are held in Oracle Internet Directory.

For the user and group profiles to be properly imported on the target portal, the user and groups that they refer to must exist in the target portal's associated Oracle Internet Directory.

If you are building your portal content on a test or development server, with the intention to then move that content to a production server, you have the option of assigning your security privileges on the test server and then migrating them, along with the content, to your production server.

In this scenario, assign the privileges to groups, so there is no need to ensure the consistency of the user population between the test and production infrastructures.

If you want to precisely model your user population on both the production and test servers, the best approach is to use Oracle Directory Integration and Provisioning capabilities to synchronize the data from the production directory server to the test server. Synchronizing the data from production to test also provides you the option of adding test users and groups to the test Oracle Internet Directory server without affecting the production server.

Note:

See the Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory for more information on setting up directory synchronization. Note that it is advisable to automatically synchronize the data from production to test, but not the other way around.

The Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory can also be referred for additional information on migrating users and groups.

With the production groups also present on the test server, you can model and test all your access privileges on the test server and then safely migrate the portal access control lists with your exported objects onto the production system.

If you are introducing new groups and access privileges for those groups on the test system, then before you move the portal content and access control lists to production, make sure you migrate the group definitions to production first. You can actually create the groups on production first, and let the synchronization process reflect the new group on the test system before applying the test access control entries, if you need to actually create the group on the test instance first, you can create the group on production with the same means you used to generate the group on test. If this was done manually, and you want to avoid repeating the manual step on production, you can issue an LDAP query on the test instance to generate an LDIF file, which you can then load onto the production instance. For example:

%ldapsearch –h testoid.domain.com –p 389 –D cn=fmwadmin –w password123 -b 'cn=portal.iasdb.domain.com,cn=groups,dc=domain,dc=com' –s sub –L 'cn=groupname' > newgroup.ldif

Note:

Before loading the LDIF file containing the group information into the production Oracle Internet Directory instance, you may need to edit the file to correct the portal instance name to match the name for that portal instance on the production Oracle Internet Directory instance. This name will typically be different between the test and the production instances and the name is part of the group DN, so it will have to be modified before loading the file.

In this example, cn=portal.iasdb.dbserver.domain.dcom, cn=groups, dc=us, dc=oracle, dc=com is the location under which the portal groups are located. Refer to Chapter 7, "Securing Oracle Portal" for more information on the organization of the entries in the Directory Information Tree in Oracle Internet Directory. This creates a file called newgroup.ldif containing the group definition. You can then load the file on the production Oracle Internet Directory instance by using ldapadd:

%ldapadd –h prodoid.domain.com –p 389 –D cn=fmwadmin –w password123 –v -f newgroup.ldif

You may only want to deploy default privileges granted to some of the seeded portal groups, or no privileges at all. If no privileges are deployed, then the user performing the import will own the objects. The user can then further grant privileges on the target system as necessary for the specific deployment.

There is no need to synchronize seeded groups or users, assuming that, if privileges are granted to seeded groups in Portal, and those seeded groups are still present on the target system, then the privileges will be correctly associated with those seeded groups.

When migrating group profiles from the source to the target, the import will remap the DNs of the groups to the local group base on the target system if the exported profile was one for a local group on the source. A local group is one that is under the portal group container (the group install base). For groups that were not under the group install base, the DN will remain unchanged.

Note:

The ssoexp and ssoimp scripts found in the wwu directory are obsolete for Oracle Fusion Middleware 9.0.x and not compatible with the 9.0.x login server. These should not be used.

13 Using the Federated Portal Adapter

This chapter provides information about the Federated Portal Adapter, previously known as the "PL/SQL HTTP Adapter". It describes how it can be used to share portlets with other Oracle Portal instances.

This chapter contains the following sections:

- About the Federated Portal Adapter

- Setting Up the Environment to Use the Federated Portal Adapter

- Registering a Provider Using the Federated Portal Adapter

- Writing Custom Portlets Using the Federated Portal Adapter

- Troubleshooting Federated Portal Adapter

13.1 About the Federated Portal Adapter

In this section, we will describe the following:

- Overview

- Differences Between Database Providers and Web Providers

- Use of the Federated Portal Adapter

- Security Issues

- Federated Portal Adapter Related Portlet Modifications

13.1.1 Overview

The Federated Portal Adapter is a component of Oracle Portal that allows Oracle Portal instances to share their database portlets through the Web portlet interface. It is a tool that uses SOAP and HTTP to distribute database providers across database servers. The Federated Portal Adapter allows database providers to be accessed as though they were Web providers.

In earlier releases of Oracle Portal, all database providers accessed from a portal instance had to be on the same physical database server that contained the portal instance.

In Oracle Portal release 3.0.9, it was possible to distribute database portlets across database servers. To do this the user had to register each portal 'node' with each other which created a database link between the 'nodes'. These portal nodes would not function beyond a firewall. Furthermore the registration of the portal nodes was symmetric, which made the registration of multiple nodes hard to manage

Oracle Portal already had the concept of Web providers where the communication between the portal and the provider is done with the open protocols HTTP and SOAP. The PDK-Java services allow users to easily develop providers in Java that receive SOAP messages and respond accordingly.

The Federated Portal Adapter is a module written in the portal instance (in both Java & PL/SQL) that receives the SOAP messages for a Web provider, parses the SOAP and then dispatches the messages to a database provider as PL/SQL procedure calls. In effect, the Federated Portal Adapter makes a database provider behave exactly the same way as a Web provider. This allows users to distribute their database providers across database servers. All remote providers can now be treated as Web providers, hiding their implementation from the user and effectively replacing the distributed portal installations.

13.1.2 Differences Between Database Providers and Web Providers

A significant difference between database providers and Web providers is that typically database providers use a portal session within the code, so that as part of the Federated Portal Adapter a portal session is created on the remote portal instance. The SOAP messages were extended to contain enough information to create a session on the remote portal instance, which means that the user in the remote portal must be the same user as in the local portal. For example, if 'UserA' is running in 'PortalA' and is using a provider on 'PortalB' through the Federated Portal Adapter then a session will be created in 'PortalB' for 'UserA'. Typically this means that 'PortalA' and 'PortalB' would share the same Oracle Application Server Single Sign-On, as partner applications. However an alternative arrangement could be that they have separate OracleAS Single Sign-Ons but the OracleAS Single Sign-Ons share the same name server. An example could be two OracleAS Single Sign-Ons sharing the same Oracle Internet Directory instance.

13.1.3 Use of the Federated Portal Adapter

The use of the Federated Portal Adapter can be divided into three categories:

Table 13-1 Use of the Federated Portal Adapter

Category

Description

Oracle Portal Database Providers

Portal DB Providers created within Oracle Portal will have the necessary code to be run through the Federated Portal Adapter. This means that applications created containing forms, charts, reports, and so on, can be shown on any other portal instance.

Pages

Pages exposed as portlets can also be run through the Federated Portal Adapter. Regions within pages can contain portlets or items. Using the Federated Portal Adapter these can now be accessed from any portal instance.

User Created Providers

Users may wish to create their own PL/SQL providers. You will be able to expose these providers through the Federated Portal Adapter as long as they are coded in accordance with the guidelines given in this chapter.

13.1.4 Security Issues

The Federated Portal Adapter creates a portal session in the remote portal based on the information passed in an initSession SOAP message. This introduces a security issue because it may be possible to replicate these SOAP messages and create sessions for any user on a portal and then access the portal as that user. To avoid this, an encryption key is shared between the two portals and part of the SOAP message is encrypted using that key. The requested private portal session can only be created if the previously shared key can decrypt it. Otherwise a PUBLIC session is created. The request to display a portlet is made with a Show message that is protected by the encrypted cookie which is created by the initSession SOAP message. The use of an encryption key means that the Federated Portal Adapter can safely trust the incoming SOAP message and create portal sessions in the portal instance without opening the portal to hackers.

See Also:

Section 13.2.2, "Federated Portal Adapter User Authentication Using HMAC"

If it is known that the portal instance will only be accessed through the Federated Portal Adapter from other portal instances, then security can be enhanced by configuring the listener to restrict access from computers other than the known portal instances. This is done by using the 'Allow' directive in the httpd.conf file.

13.1.5 Federated Portal Adapter Related Portlet Modifications

It should be noted that database providers written before Oracle Fusion Middleware 10g (10.1.4) will not work when accessed through the Federated Portal Adapter if one of the following conditions is true:

- The portlet contains relative links

- The portlet is personalizable

All links within a portlet should be absolute links, that is, http://<host>:<port>/images/foo.gif rather than relative, /images/foo.gif when using the Federated Portal Adapter. This is because the request is processed by the Parallel Page Engine on the local portal instance. Relative links will therefore be interpreted as relative to the local portal and not to the portal containing the portlet.

Personalization is an issue because the processing of personalization is different between database and Web providers. For Web providers the personalization form is submitted to the Parallel Page Engine of the local portal, which in turn calls the portlet again and the personalizations are saved and the page is redirected appropriately. Because database providers accessed through the Federated Portal Adapter are effectively Web providers, this method of personalization should be undertaken for these providers. A public API is provided (WWPRO_API_ADAPTER) to do this.

Portal Database Portlet Providers developed in previous releases of Oracle Portal will be upgraded automatically to work with the Federated Portal Adapter. Pages exposed as providers can also be accessed through the Federated Portal Adapter.

13.2 Setting Up the Environment to Use the Federated Portal Adapter

To use the Federated Portal Adapter there are a few administrative steps that must be undertaken. These steps are:

- Checking the PlsqlSessionCookieName Value

- Federated Portal Adapter User Authentication Using HMAC

- Setting the Cookie Domain

- Sharing an OracleAS Single Sign-On and an Oracle Internet Directory Server

13.2.1 Checking the PlsqlSessionCookieName Value

DADs must have a unique PlsqlSessionCookieName value for all the portals accessed by the Federated Portal Adapter.

For example,

- portal1 can have the schema name portal, the DAD name portal and the PlsqlSessionCookieName value portal1.

- portal2 can have the schema name portal, the DAD name portal, but must have a different PlsqlSessionCookieName value, like portal2.

Note:

In previous releases of Oracle Portal, the DAD name had to be the same as the schema name, and the DAD name was always the same as the name of the session cookie created. This is no longer the case. You can now specify the name of the cookie created when portal is accessed by the DAD, and the schema name does not have to be the same as the DAD name.

Oracle Enterprise Manager 11g Fusion Middleware Control can be used to update the Session Cookie Name. To do this:

1. Navigate to the Portal Home page in the Oracle Enterprise Manager 11g Fusion Middleware Control.
For details, see Section 8.1, "Using Oracle Enterprise Manager 11g Fusion Middleware Control".

2. From the Portal menu, select Settings, and then Database Access Descriptor.
The Configure Database Access Descriptor page is displayed.

3. To edit an existing DAD, select the DAD name and click Edit.
The Edit Database Access Descriptor page is displayed.

4. In the Edit Database Access Descriptor page, under Security, Document, Alias and Session section enter a new value for Session Cookie Name.

5. Click OK.

6. Restart the managed server (WLS_PORTAL).

13.2.2 Federated Portal Adapter User Authentication Using HMAC

Federated Portal Adapter functionality will support the registering of remote Database providers between geographically dispersed portals. Database providers are registered as if they were Web providers residing at a special URL on the remote portal.

Note:

If you are only rendering public content in the remote portlets, you can ignore this section.

In order that more than just public content can be rendered in the remote portlets we require that in some way we can guarantee that user A on one portal is the same as user A on another portal. This will typically be achieved by using a shared Oracle Application Server Single Sign-On using the partner application feature, but may also be achieved with a shared name server (for example, Oracle Internet Directory), synchronized name servers or a manual process.

If this environment can be achieved, then using the Hash Message Authentication Code (HMAC) authentication mechanism, private sessions can be initiated on a remote portal to render private content of remote portlets.

Setting the HMAC Keys

If the administrator of portal A wishes to permit users of portal B to create private sessions on portal A, a private 'key' will have to be stored on each portal. This key is used to encode and decode portions of each SOAP request sent between them. If a key is missing or they are different on each portal, only PUBLIC sessions will be created.

A key must be at least 10 characters long, and one administrator should inform the other administrator of its value in a suitably secure way.

SQL scripts are provided to perform the task of maintaining the key store - all are found in the ORACLE_HOME\portal\admin\plsql\wwc directory.

Table 13-2 SQL Scripts for Maintaining the Key Store

Script

Description

proadsss.sql

Sets the key at the sending end (portal instance on which the page with the remote portlets is created).

proadssr.sql

Sets the key at the receiving end (portal instance on which the portlets are created).

proadsds.sql

Removes the key at the sending end (portal instance on which the page with the remote portlets is created).

proadsdr.sql

Removes the key at the receiving end (portal instance on which the portlets are created).

In each case, sending and receiving refer to the SOAP message.

Example 13-1 Setting the HMAC Keys:

In the example mentioned earlier, portal B is the sender (sending SOAP and show requests) and portal A is the receiver of those requests. The portal administrator of portal B must connect to SQL*Plus as the portal owner and run:

SQL> @proadsss
Enter provider portal PL/SQL Adapter URL:
http://<portalA_hostname>:<port>/adapter/<portalA_DAD>
Enter shared key:<shared key>
exit;

The portal administrator of portal A must connect to SQL*Plus as the portal owner and run:

SQL> @proadssr
Enter provider portal PL/SQL Adapter URL:
http://<portalB_hostname>:<port>/adapter/<portalB_DAD>
Enter shared key:<shared key>
exit;

If sharing of providers is required both ways, then this will need to be repeated the other way round, possibly with different shared keys. It should also be noted that a portal can expose its providers to several other portal instances (for example, 'Portal A' exposes providers to 'Portal B' and 'Portal C') and separate keys can be set up between each of the portal instances.

13.2.3 Setting the Cookie Domain

Normally cookie domains are restricted to a single computer. This can be widened by running a script on each portal, and then selecting the Web provider in same cookie domain as the portal option on provider registration. Once this is done, 'deep link' functionality can be achieved. This means that when you click a link in a portlet rendered by the Federated Portal Adapter, the browser renders the referred page (typically from the remote portal). The session context that has already been established is also maintained.

Cookies received by a browser, or other HTTP client, are sent to servers if the domain of the cookie matches the server's host name. So cookies with the domain '.co.uk' and 'mycompany.co.uk' will be sent with a request to 'http://mycompany.co.uk/portal/pls/etc/etc'. By default the scope of cookies created by portal is restricted to the host name of the middle-tier computer.

Because communication to the portlets is done in the middle tier by the Parallel Page Engine (PPE) and not the browser, the session cookie for the remote portal will, by default, not be sent to the remote portal when links are followed within the portlet.

This can be solved by widening the scope of the cookies created by portal and making sure that the cookies received by the PPE are sent back to the browser. Widening the scope of the cookies created by portal is achieved by running the SQL script ctxckupd.sql in the ORACLE_HOME\portal\admin\plsql\wwc directory.

For example, there are two portals:

- http://myhost1.mycompany.co.uk:3000/portal/pls/portalA

- http://myhost2.mycompany.co.uk:4000/portal/pls/portalB

and a provider is registered from 'Portal B' on 'Portal A'.

When showing a page on 'Portal A' that contained a portlet from 'Portal B' by default a portal session cookie for 'Portal B' whose domain is 'myhost2.mycompany.co.uk:4000' would be created, and sent to the PPE. If the 'Web provider in same cookie domain as the portal' property is checked on the provider registration page then this cookie will be sent back to the browser, but the domain of the cookie will then be 'myhost1.mycompany.co.uk:3000' because that is where it is being sent from, because the PPE is at 'myhost1.mycompany.co.uk:3000').

If a link is followed from within the portlet the cookie is not sent with the request, because the domain of the cookie does not match with that of the host of the request.

To solve this, connect to SQL*Plus as the portal owner of each portal and run ORACLE_HOME\portal\admin\plsql\wwc and broaden the scope of the domain's cookies created by Oracle Portal so each portal is in the same domain. Once this is done, the scope of the cookie domains created by any of the portals will be broad enough to be sent back to the browser. Links within the portlet will then work correctly.

See Also:

Section B.4, "Configuring the Portal Session Cookie"

Note:

Having only one dot in the host.domain name of the middle-tier server is not an Oracle tested configuration. To avoid unexpected results, configure the middle tier servers with a multiple part domain name. This will provide more than one dot in the host.domain name of the middle tier.

13.2.4 Sharing an OracleAS Single Sign-On and an Oracle Internet Directory Server

The benefits of single sign-on can be maximized, by utilizing a common Identity Management server. portal session information is passed to the remote portal, which uses the Federated Portal Adapter to create a session. It is recommended that all portals on which you want to create private sessions, share the same Oracle Internet Directory server and the same OracleAS Single Sign-On.

For example, if a user 'JSMITH' displays a page on one portal and a portlet on that page is being sourced from the Federated Portal Adapter on a remote portal, then a session is created on the remote portal for user 'JSMITH'. If the two portals do not share OracleAS Single Sign-On then 'JSMITH' may be the user name for 'John Smith' on one portal and 'Jane Smith' on the other. To avoid this sort of problem, ensure that all the portals participating in the Federated Portal are configured to use a single Oracle Identity Management. They should all use the same OracleAS Single Sign-On for authentication. However, if the portlets being shown are 'public' then there is no need to share the OracleAS Single Sign-On and a public portal session will be created at the remote portal instance.

If you currently have two portals using distinct OracleAS Single Sign-On servers, you may first need to consolidate the OracleAS Single Sign-On servers. To do this, refer to the information on consolidating multiple servers in the Oracle Application Server Single Sign-On Administrator's Guide.

Consolidating the servers means that you will be decommissioning one of the servers and identifying the other as the common server for both portals to use. Then you'll need to configure the portal that was configured to use the decommissioned OracleAS Single Sign-On to the consolidated one. To do this, do the following:

Sharing an OracleAS Single Sign-On and an Oracle Internet Directory Server

You have two portals, portal1 and portal2. You decide to decommission the SSO server for portal2 and configure portal2 to use the SSO server for portal1. To do this, perform the following steps:

1. Change the OIDDependency element for portal2 to point to the same OIDComponent that portal1 by performing the following steps:

1. Navigate to the Portal Home page in the Oracle Enterprise Manager 11g.

2. From the Portal menu, select Settings, and then Wire Configuration.
The Portal Wire Configuration page is displayed.

3. Enter the OID details for portal1 under Oracle Internet Directory (OID) section.

2. Re-register the Oracle HTTP Server for portal2, by invoking ssoreg.sh located in ORACLE_HOME/sso/bin (Unix) from your Identity Management instance as shown in the following example:

$ORACLE_HOME/sso/bin/ssoreg.sh
-site_name portal2.example.com:8090
-config_mod_osso TRUE
-mod_osso_url http://portal2.example.com:8090
-update_mode MODIFY
-remote_midtier
-config_file config_file_path

On Windows, you must run ssoreg.bat instead.

3. Update the Portal Metadata Repository for portal2 by logging into the Portal schema and update the GUID column of the WWSEC_PERSON$ table to set a placeholder GUID so that it will pick up the new GUIDs from the newly associated OID server:

SQL> update wwsec_person$ set guid = ':'||id;
SQL> commit;

13.3 Registering a Provider Using the Federated Portal Adapter

Registering a provider through the Federated Portal Adapter is like registering any Web provider. You must perform the following steps:

1. Log in to your Oracle Portal.
The Portal Builder page is displayed.

2. Click the Administer tab and then the Portlets subtab.

3. Click Register a Provider in the Remote Providers portlet.

4. In the Provider Information page, enter the Name, Display Name, Timeout, and Timeout Message as you would normally. Ensure that the Implementation Style is set to Web. Although the provider is actually written in PL/SQL, all communication to it is as a Web provider and not a database provider so it is important to set the Implementation Style to Web.

5. In the General Properties page enter the URL of the adapter service. The syntax for the URL should be:

http://host:port/adapter/dad/schema

If the DAD and the schema are the same you can just use:

http://host:port/adapter/dad

where the host, port, DAD and schema locate the remote portal instance. You can verify that this is the correct URL by pasting it into a browser.

If the URL is correct you should get to a page with the message "Congratulations - you got to the adapter test page"

6. Select the Web provider in same cookie domain as the portal option. This will ensure that cookies generated from the provider will be sent back to the browser. Note that it may be necessary to broaden the scope of the cookies created by portal as described earlier.

7. Enter the 'Service Id'. This should be in the form 'urn:<provider name>'. Where provider name is the name of the provider on the remote portal instance, this is case sensitive and will be upper case. This is the information that the Federated Portal Adapter uses to locate the specific provider at the remote portal.
Note that for page groups exposed as providers, the name of the provider will be something like 'MYPAGE970D272EBE9D2D0FE034080020F7DA4B' it is important that you specify this 'Name' rather than the 'Display Name'. The name and display name can be accessed from the Remote Providers portlet, available in the Portlets subtab under the Administer tab in Oracle Portal. Clicking the Browse Providers icon displays the names of all the providers.

8. In the User/Session Information section, select the User radio button and set the Login Frequency to be Once Per User Session. These settings make sure that information is sent with the request to allow a portal session to be created on the remote portal instance.

Note:

When you create or register a new provider, a page is created in the Portlet Repository under Portlet Staging Area to display portlets for that provider. This page is not visible to all logged in users. It is only visible to the user who published the provider, and the portal administrator. The publisher or portal administrator can change the provider page properties to grant privileges to appropriate users and groups, as required.

13.4 Writing Custom Portlets Using the Federated Portal Adapter

There are two main areas of code that need special attention when writing database providers that are accessed through the Federated Portal Adapter. They are:

- Relative Links

- Personalization

13.4.1 Relative Links

Any links within portlets that are accessed through the Federated Portal Adapter should absolute rather than relative. If links are relative then they will not work because they will be relative to the local middle tier rather than the remote middle tier. For example, links should be of the form 'http://myhost.mycompany/etc/etc' rather than '/etc/etc'.

13.4.2 Personalization

The way personalizations work when accessing portlets through the Federated Portal Adapter is now very similar to the method used by PDK-Java portlets. There are two main areas of the portlet code that need to be changed to make personalization work through the Federated Portal Adapter:

- The show call of the portlet needs additional logic to show the portlet in edit_defaults mode, or, if the parameter 'p_mode' is null, in personalize mode. If the 'p_mode' is 'OK', 'APPLY' or 'RESET', then the personalizations should be saved as appropriate.

- The <FORM> HTML tags generated for the personalize page should be created using the procedure wwpro_api_adapter.open_form. This will ensure that the action for the form is correct, and that the correct parameters are passed upon page submission. The sequence of events when submitting the personalization form is:

1. The page submits to the 'local' PPE. There are several standard parameters that need to be sent with this submission (for example, _providerid, _dad, p_action, and so on) and the parameters that are being personalized. The procedure wwpro_api_adapter.open_form is supplied to make the generation of this submission as simple as possible.

2. The PPE then shows the personalization page again. However the 'p_action' parameter will now be set so that during the show_portlet call of the portlet it will be one of the following settings:

'OK' - In this case the personalizations should be saved and then there should be a redirect to the page containing the portlets.

'APPLY' - In this case the personalizations should be saved and the personalization page is shown.

'RESET' - In this case the default values for parameters are queried and the personalization page is shown.

The database services provider is a sample provider in the Oracle Fusion Middleware Portal Developer Kit (PDK) that works with the Federated Portal Adapter. For more information, see the Portal Developer Kit on the Oracle Technology Network (OTN), http://www.oracle.com/technology/products/ias/portal/pdk.html.

13.5 Troubleshooting Federated Portal Adapter

There are some known restrictions showing page portlets with the Federated Portal Adapter.

- The Show Details mode does not work, that is, the portlet name cannot be displayed as a link that shows additional information about the portlet.

- If the page portlet contains tabs, then clicking a tab is a 'deep link' and the rendered page takes over the whole page, that is, it is not shown within the original page as a portlet.

- The rendering of navigation pages, which includes the page banner, does not work properly when pages are displayed through the Federated Portal Adapter. For example, the Personalize link in a regular page portlet displays personalization options for the container page, but this is not the case in a remote page portlet. Also, page portlets shown through the Federated Portal Adapter do not display the banner of the container page, whereas the banner is displayed in the case of regular page portlets.

- If the page portlet has a navigation page portlet that has a sub page region in it, the sub page region will not be displayed on the page portlet when it gets rendered through the Federated Portal Adapter. For a non-remote page portlet, the region shows the sub pages of the container page holding the portlet.

- When you export and import Federated Portal Adapter portlets, the portlets are not shown on the target instance if you have not performed the following tasks on the target portal instance:

1. Configure the target portal instance to use the PL/SQL adapter running on the source portal instance.

2. Grant the View permission to the target portal instance for the Federated Portal Adapter Web Provider page in the source portal instance.

Part IV

Appendixes

Part four contains the following appendices:

- Appendix A, "Using Oracle Fusion Middleware Configuration Files"

- Appendix B, "Using Oracle Portal Installation and Configuration Scripts"

- Appendix C, "Integrating JavaServer Pages with Oracle Portal"

- Appendix D, "Using the wwv_context APIs"

- Appendix E, "Configuring the Portal Tools Providers"

- Appendix F, "Setting Up and Maintaining a Virtual Private Portal"

- Appendix G, "Troubleshooting Oracle Portal"

A Using Oracle Fusion Middleware Configuration Files

Although we recommend that you use Oracle Enterprise Manager 11g Fusion Middleware Control for administering Oracle Portal, you can also make changes directly through Oracle Fusion Middleware's configuration files and tables. This appendix provides information about the files and tables that can affect the connection to, and the behavior of, Oracle Fusion Middleware and its components in the middle tier and on other computers to which it is connecting.

See Also:

Oracle Fusion Middleware Administrator's Guide

Specific topics covered include:

- Oracle HTTP Server Configuration File (httpd.conf)

- DAD Configuration File (portal_dads.conf)

- Oracle Database Connection Configuration

- Web Cache Configuration Files

- OracleAS Single Sign-On's Partner Application Table

- Local HOSTS File

See Also:

Section 5.6.9, "Configuring the Portal Parallel Page Engine" for information on appConfig.xml file.

A.1 Oracle HTTP Server Configuration File (httpd.conf)

The Oracle HTTP Server configuration file, httpd.conf, contains configuration information for running the Oracle HTTP Server. The content of this file includes information about listening ports, server names, virtual hosts, proxy configurations, and the like. This file also configures Secure Sockets Layer (SSL) support by defining information such as certificates and other HTTPS configuration directives. This file is available at the following location:

ORACLE_INSTANCE\config\OHS\ohs1\httpd.conf

If you create additional virtual hosts in Oracle HTTP Server, then you must add the RewriteEngine and RewriteOptions mod_rewrite directives for the virtual host that is used by Oracle Portal, in the httpd.conf file as shown in the following example (shown in bold text):

NameVirtualHost *:7778
<VirtualHost *:7778>
ServerName http://www.xyz.com:7779
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

Example A-1 httpd.conf

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
- <portal-midtier xmlns="http://xmlns.oracle.com/portal/config/midtier" description="Oracle Portal Midtier Configuration Parameters">
<useWebCache>true</useWebCache>
<jspRoot>internal_jsp</jspRoot>
<jspSrcAlias>/internal_jsp/</jspSrcAlias>
<useSessionMemorycache>true</useSessionMemorycache>
<autoRedirect>true</autoRedirect>
<maxParallelPortlets>20</maxParallelPortlets>
<maxParallelPagePortlets>10</maxParallelPagePortlets>
</portal-midtier>

A.2 DAD Configuration File (portal_dads.conf)

This file contains the configuration parameters for the PL/SQL Database Access Descriptor (DAD). A DAD is a set of values that specifies how a database server should fulfill an HTTP request.

You can modify a Portal DAD by editing the portal_dads.conf file using Oracle Enterprise Manager 11g Fusion Middleware Control, WLST, or by manually editing the file.

- Using Fusion Middleware Contol

- Configuring a Portal DAD Using WLST

- Manually Editing the portal_dads.conf File

If you manually update the portal_dads.conf file, then you must also add the necessary mod_rewrite and mod_wls directives in the httpd.conf and mod_weblogic.conf files respectively.

Using Fusion Middleware Contol

Perform the following tasks using Fusion Middleware Control:

1. Open Oracle Enterprise Manager 11g Fusion Middleware Control.

2. Open the Portal instance.

3. From the Portal menu, select Settings, and then select Database Access Descriptor to display the DAD configuration information.

To edit the DAD file:

1. Select the portal DAD entry to edit and click Edit.

2. Enter the new values and click OK.

3. Restart the Oracle HTTP Server and WLS_PORTAL components.

This ensures that the required mod_rewrite and mod_weblogic directives are added.

For more information about configuring DADs or using Oracle Fusion Middleware Control, refer to the Oracle Fusion Middleware Administrator's Guide.

Manually Editing the portal_dads.conf File

Based on the type of updates you make in the portal_dads.conf file, perform all or some of the following tasks:

1. If you added a new portal DAD in the portal_dads.conf file, then you must add the following Rewrite directives to the httpd.conf file:

RewriteRule (^/pls/<dad>/.*) /portal$1 [PT]
RewriteRule (^/pls/<dad>$) /portal$1 [PT]

where <dad> is the name of the new DAD. For example:

RewriteRule (^/pls/mydad/.*) /portal$1 [PT]
RewriteRule (^/pls/mydad$) /portal$1 [PT]

2. If you modified a DAD name in the portal_dads.conf file, then you must update the Rewrite directives described in the previous step with the new DAD name.

3. To update the manual configuration changes done on the middle tier, run the following commands:

ORACLE_INSTANCE/bin/opmnctl restartproc process-type=OHS

Updating the plsqlSessionCookieName Value

Although you can change the plsqlSessionCookieName in Fusion Middleware Control, you can also manually change the value in the portal_dads.conf file. This file is located under:

DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration

A typical entry in this file looks like this:

<Location /pls/portal>
SetHandler pls_handler
Order allow,deny
Allow from All
AllowOverride None
PlsqlDatabaseUsername portal
PlsqlDatabasePassword SomePassword
PlsqlDatabaseConnectString myhost.domain.com:1521:mySID
PlsqlDefaultPage portal.home
PlsqlAuthenticationMode SingleSignOn
PlsqlSessionCookieName portal
PlsqlMaxRequestsPerSession 500
PlsqlDocumentTablename portal.wwdoc_document
PlsqlDocumentPath docs
PlsqlDocumentProcedure portal.wwdoc_process.process_download
PlsqlPathAlias url
PlsqlPathAliasProcedure portal.wwpth_api_alias.process_download
PlsqlFetchBufferSize 128
</Location>

To edit a DAD entry, change the value of PlsqlSessionCookieName, for example, portal2. After saving the file, update the Oracle HTTP Server configuration and restart the WLS_PORTAL.

See Also:

Section 5.6.4, "Configuring a Portal DAD Using Fusion Middleware Control" for instructions on how to configure a DAD using Fusion Middleware Control.

Note:

We recommend that you edit the portal_dads.conf file using Fusion Middleware Control.

If you manually edit the portal_dads.conf file, then you must add the necessary mod_rewrite and mod_weblogic directives to the httpd.conf and mod_weblogic.conf files respectively. To do this, perform the steps mentioned in Section A.2, "DAD Configuration File (portal_dads.conf)" using the Fusion Middleware Control.

Example A-2 portal_dads.conf

<Location  /pls/portal>
SetHandler  pls_handler
Order  deny,allow
Allow  "from All"
AllowOverride  None
PlsqlAuthenticationMode  SingleSignOn
PlsqlDatabaseUsername  HW081010A_PORTAL
PlsqlDatabasePassword  welcome1
PlsqlDatabaseConnectString  stake03.us.oracle.com:1521:e10gdev5.us.oracle.com  ServiceNameFormat
PlsqlNLSLanguage  AMERICAN_AMERICA.AL32UTF8
PlsqlPathAlias  url
PlsqlSessionCookieName  HW081010A_PORTAL
PlsqlPathAliasProcedure  HW081010A_PORTAL.wwpth_api_alias.process_download
PlsqlSessionStateManagement  StatelessWithFastResetPackageState
PlsqlDocumentPath  docs
PlsqlDocumentProcedure  HW081010A_PORTAL.wwdoc_process.process_download
PlsqlDocumentTablename  HW081010A_PORTAL.wwdoc_document
PlsqlDefaultPage  HW081010A_PORTAL.home
</Location>

A.3 Oracle Database Connection Configuration

SQL*Net configuration files define the entries that can be used as connect strings in the DADs. Typically, the portal_dads.conf located in DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration and sqlnet.ora file located in DATABASE_HOME\network\admin contain information on how Oracle WebLogic Server can connect to the database where the Oracle Portal installation is located.

For more details on SQL*Net configuration, refer to the Oracle Database Net Services Administrator's Guide in the Oracle Database 11g documentation library.

A.4 Web Cache Configuration Files

Information about the Oracle Web Cache configuration files can be found in the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

A.5 OracleAS Single Sign-On's Partner Application Table

The configuration table on the OracleAS Single Sign-On's side is the partner application Table, WWSSO_PAPP_CONFIGURATION_INFO$. Maintenance of this table is typically done using the OracleAS Single Sign-On application's user interface for adding or editing partner applications.

For an initial installation, you need to register the Portal's mod_osso_url using ssoreg tool, this populates both the OracleAS Single Sign-On's partner configuration table and Oracle Portal's enabler configuration table. For example:

$ORACLE_HOME/sso/bin/ssoreg.sh
-site_name portal.example.com:8090
-config_mod_osso TRUE
-mod_osso_url http://portal.example.com:8090
-remote_midtier
-config_file config_file_path

On Windows, you must run the ssoreg.bat batch file.

A.6 Local HOSTS File

The HOSTS file on a network host defines mappings of IP names to IP addresses. Normally, a Domain Name Server (DNS) provides the mapping of IP name to IP address. In some of the configurations described in Chapter 5, "Basic Configuration and Administration", a host may need to be addressed in an internal network with a domain name that is not defined within the internal network. In these cases, the server's HOSTS file can provide the necessary name resolution.

B Using Oracle Portal Installation and Configuration Scripts

After installing Oracle Portal as part of the Oracle Fusion Middleware installation, several scripts are available for post-installation configuration.

The specific topics covered in this appendix include:

- Managing the Invalidation Message Processing Job Using cachjsub.sql

- Configuring for IP Check During Session Cookie Validation

- Using the secupoid.sql Script

- Configuring the Portal Session Cookie

- Managing the Session Cleanup Job

- Timing and Caching Statistics

- Using the cfgiasw Script to Configure Mobile Settings

- Using the cfgxodnc.pl Script to Change the Mobile Device Component of the Cache Key

- Using the Category and Perspective Scripts

- Using the PDK-Java Preference Store Migration and Upgrade Utility

- Using the Schema Validation Utility

B.1 Managing the Invalidation Message Processing Job Using cachjsub.sql

Oracle Portal uses caching to improve its performance. One type of caching it uses is the invalidation-based caching. In invalidation-based caching, Oracle Portal caches various objects (pages, portlets, and so on) for a set amount of time. When these objects are requested, they are retrieved from the cache, if available; otherwise they are regenerated from the Metadata Repository. The cache for these objects will expire when the maxcache time has been reached, or when the objects are explicitly invalidated (expired) by invalidation messages.

Oracle Portal uses invalidation messages when it needs to expire objects in the cache. Invalidation messages are categorized as hard and soft invalidations. Hard invalidations take effect immediately, that is, the objects that they intend to invalidate expire from cache immediately. Soft invalidations take effect when they are processed by the invalidation processing job. The frequency by which the invalidation job executes is configurable. This is done using the cachjsub.sql script.

To change the execution frequency of the invalidation processing job:

1. Locate the following directory:
ORACLE_HOME\portal\admin\plsql\wwc

2. On the database where the portal schema is installed, log on to SQL*Plus with the appropriate user name and password for that schema.
For example:

sqlplus portal/portal

3. Enter the following command to update the execution frequency of the invalidation job:

SQL> @cachjsub.sql <start_time> <start_time_fmt> <interval_mins>

cachjsub.sql takes three parameters:

- start_time is either when the first job should be run or START.

- start_time_fmt is the Oracle date format model to be applied to the value of start_time. Refer to the database documentation library for more information about the Oracle date format model.

- interval_mins is how many minutes each run is scheduled apart.

Note:

If START is provided for the first parameter, the second parameter is ignored, and it will default the start time to the current time.

Example 1:

SQL> @cachjsub.sql START null 120

Example 2:

SQL> @cachjsub.sql '02-22-2005 7:30' 'MM-DD-YYYY HH:MI' 1440

Example 3:

SQL> @cachjsub.sql '06-14-2005 15:30' 'MM-DD-YYYY HH24:MI' 60

Note: Example 3 shows time in the 24-hour format.

B.2 Configuring for IP Check During Session Cookie Validation

As part of the process of validating the session cookie of a user's request (even if that user is orcladmin), Oracle Portal can be configured to perform a comparison between the IP address stored in the cookie with the IP address of the current client. Only if the two values are the same will Oracle Portal consider the request legitimate.

By default, Oracle Portal does not perform this check. When a proxy exists between the user's client and the portal, the IP address stored in the session cookie is that of the proxy, and not that of the client.

Depending on the network configuration into which the Oracle Fusion Middleware is installed, it may be possible to enable IP checking in cookie validation, for added security.

To change the state of IP checking in cookie validation, use SQL*Plus to update data in the portal schema as detailed in Table B-1.

Table B-1 Enabling and Disabling the IP Check

Portal Schema

SSO Schema

Enable

IP Checking

update wwsec_enabler_config_info$

set url_cookie_ip_check = 'Y';

commit;

update wwsec_enabler_config_info$

set url_cookie_ip_check ='Y';

update wwsso_ls_configuration_info$

set cookie_ip_check = 'Y';

commit;

Disable

IP Checking

update wwsec_enabler_config_info$

set url_cookie_ip_check = 'N';

commit;

update wwsec_enabler_config_info$

set url_cookie_ip_check ='N';

update wwsso_ls_configuration_info$

set cookie_ip_check = 'N';

commit;

B.3 Using the secupoid.sql Script

By default, Oracle Portal connects to Oracle Internet Directory using LDAP without SSL. If the Oracle Internet Directory server is configured for an SSL port, though, Oracle Portal can be configured to use LDAP over SSL, also known as LDAPS.

See Also:

Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory

To configure Oracle Portal to use SSL to connect to Oracle Internet Directory, you must run the secupoid.sql script. This script enables you to change the following Oracle Portal configuration parameters related to Oracle Internet Directory:

- Oracle Internet Directory host name

- Oracle Internet Directory port

- Application Oracle Internet Directory password

- SSL setting

When you install Oracle Portal, it is automatically configured to use an Oracle Internet Directory server. However, you may want to change some settings, such as whether to use SSL, after installation. To change to an SSL connection for Oracle Internet Directory, simply run the ORACLE_HOME/portal/admin/plsql/wwc/secupoid.sql script in the PORTAL schema to specify the LDAPS port instead of the LDAP port, and indicate that you want to use SSL.

Running the secupoid.sql Script

This section shows a sample execution of secupoid.sql from SQL*Plus.

In the example, Oracle Internet Directory was initially configured to run LDAP on port 3060. Later, an LDAPS port was activated on 3130. Because the server name does not change, we retain the old value, update the port, and indicate that we want to use SSL by setting the Use SSL? value to Y. When you run the script, it displays the current configuration and lets you replace any of the configurable settings. The script also enables you to update Oracle Portal's Oracle Internet Directory cache after running it. Because activating SSL does not change any of the Oracle Internet Directory information cached by Oracle Portal, it is not usually necessary to refresh the cache in this case.

SQL> @secupoid
Current Configuration
--------------------
OID Host: oid.domain.com
OID Port: 3060
Application DN:
orclapplicationcommonname=ssl_portal.080130.052806.514018000,cn=portal,cn=products,cn=oraclecontext
Application Password: 2E1325D176112857A6E76E803E6284B0
Use SSL? N

PL/SQL procedure successfully completed.

Updating OID Configuration Entries
Press [Enter] to retain the current value for each parameter
For SSL Connection to LDAP, specify "Y"es or "N"o
------------------------------------------------
Enter value for oid_host:
Enter value for oid_port: 3130
Enter value for app_password:
Enter value for use_ssl_to_connect_to_ldap: Y
Enter value for refresh_with_new_settings: N

PL/SQL procedure successfully completed.

No errors.

After executing the script, Oracle Portal is configured for LDAPS access of Oracle Internet Directory.

When secupoid.sql is run, it can change the port number of Oracle Internet Directory stored in the portal schema of the Oracle Metadata Repository.

B.4 Configuring the Portal Session Cookie

Oracle Portal uses a session cookie to maintain session state for portal applications. For portal to work correctly, the client browser must be configured to accept cookies from the server. Upon installation, the portal session cookie has a default name, scope, and security that are set appropriately for most installations. This section describes these defaults, and how they can be changed if needed.

B.4.1 Configuring the Cookie Name

By default the portal's session cookie is named portal after the default Database Access Descriptor (DAD) used to access the portal schema. You can use Oracle Enterprise Manager 11g to change the cookie name, if it needs to explicitly be set to something else. To do this, you must access the DAD Edit page in the Oracle Enterprise Manager 11g Fusion Middleware Control. This page is located under mod_plsql services of the Oracle Portal middle-tier component. The cookie name can be set on the Document Alias and Session Parameter page. To change the name of the cookie, provide the desired name in the Session Cookie Name field of the Session Cookie section.

B.4.2 Configuring the Scope of the Cookie

In cases where you want access to the same portal from two middle tiers at the same time, or if you want to open the portal cookie domain as required by the PL/SQL Adapter functionality, you must define the scope of the Oracle Portal session cookie to be sent to all the middle-tier servers involved in the architecture. By default, the session cookie's domain is scoped to the host from which it was generated. The path for the cookie is set to "/".

Note:

You should make these changes when there is no traffic on the portal, otherwise existing sessions will experience session errors (ORA-20000) after you change the session cookie name.

For example, if the cookie was generated from www.company.com, then the cookie domain is www.company.com. However, let's say that another server, portal.company.com is also a middle-tier server that needs access to that session cookie. Then the cookie domain would need to be widened so that the portal.company.com server can also see the cookie.

Follow these steps to modify the scope of the portal session cookie:

1. Locate the following directory:

ORACLE_HOME\portal\admin\plsql\wwc

2. On the database where your Oracle Portal schema is installed, log on to SQL*Plus as the portal schema. For example:

sqlplus portal\portal_pwd

3. Enter the following command:

SQL> @ctxckupd
OracleAS Portal
Current Settings for Portal Session Cookie:
Cookie Domain : Only send cookie back to originating host:port
Set Cookie as Secure: Y
Enter the domain for the session cookie: .company.com
Should cookie be flagged as secure for HTTPS sessions? (Y/N): N
Settings changed to
Cookie Domain : .company.com
Do not set cookie as secure. (N)
SQL>

This enables you to set the cookie domain for the session cookie. In this example, the cookie domain is set to .company.com.

Notes:

- If you want to use different listeners or keep the session cookie throughout different domains, specify a Cookie Domain to be the host name only. For example, if you access Oracle Portal from two computers:
— machine1.us.company.com:3000

— machine2.us.company.com:4000

When running ctxckupd.sql, set the cookie domain to .us.company.com.

- The cookie domain also determines the scope of the NLS_LANGUAGE cookie, which is a persistent cookie that determines the user's preferred language. This NLS_LANGUAGE cookie is set when selecting languages in the set language portlet.

B.4.3 Securing the Cookie

In this release of Oracle Portal, the script ctxckupd.sql contains an additional option, Set Cookie as Secure.

The default location for this script is ORACLE_HOME\portal\admin\plsql\wwc. When you run this script, you see the following output:

SQL> @ctxckupd
OracleAS Portal
Current Settings for Portal Session Cookie:
Cookie Domain : Only send cookie back to originating host:port
Set Cookie as Secure: Y
Enter the domain for the session cookie...
Leave blank to scope to originating host:
Should cookie be flagged as secure for HTTPS sessions? (Y/N): N
Settings changed to
Cookie Domain : Only send cookie back to originating host:port
Do not set cookie as secure. (N)
SQL>

Set Cookie as Secure indicates that the cookie should be sent back to the server if the request is over an HTTPS connection only. This setting ensures that the session cookie is not transmitted over an insecure connection when it needs to be protected. By default, this option is set to Yes and is sufficient for most deployments.

In some cases, you may need to set the Set Cookie as Secure option to No. For example, if your portal is accessed over both HTTP and HTTPS and you want the session cookie to be shared across both protocols (possible if they are running on the default ports 80 (HTTP) and 443 (HTTPS)). In this instance, when Set Cookie as Secure is set to No, the same cookie produced over an HTTPSrequest, is sent over any subsequent HTTP requests.

B.5 Managing the Session Cleanup Job

Oracle Portal and OracleAS Single Sign-On perform session management similar to other Web-based applications. Sessions are tracked with cookies. Session information is stored in a table in the Oracle Portal and OracleAS Single Sign-On schema. When a user logs out, the session information is marked inactive. A DBMS job subsequently cleans up the inactive rows.

The session table accumulates a number of rows that are flagged as active. When a user shuts down the browser instead of logging out, the row is "active", even though it is not actually in use. The cleanup job cleans up the active rows that are older than a specified duration.

When Oracle Portal is installed, a DBMS job is installed to perform session cleanup of the session table, WWCTX_SSO_SESSION$. The cleanup job is set to run every 24 hours. The first scheduled cleanup occurs 24 hours after the installation of the job.

When the job runs, it deletes all inactive sessions and all sessions marked active (WWCTX_SSO_SESSION$.ACTIVE = 1), that are older than 7 days (WWCTX_SSO_SESSION$.SESSION_START_TIME < sysdate - 7).

These default settings can be modified by running some job management scripts in the Oracle Portal schema to manage portal sessions, or in the OracleAS Single Sign-On schema to manage OracleAS Single Sign-On sessions. They utilize the same session management infrastructure.

Follow these steps to obtain the current cleanup job information:

1. Locate the following directory:

ORACLE_HOME\portal\admin\plsql\wwc

2. On the database where the Oracle Portal or OracleAS Single Sign-On schema is installed, log in to SQL*Plus with the appropriate user name and password for that schema.
For example:

sqlplus portal\portal

3. Enter the following command to get the current job information:

SQL> @ctxjget

The command results in the display of the currently installed job information, as returned by the DBMS_JOB package:

The session cleanup job is job ID 7381
dbms_job.isubmit(job=>7381,what=>'begin execute immediate''begin
wwctx_sso.cleanup_sessions(p_hours_old => 168); end;''; exception when
others then null; end;',next_date=>to_date('2001-04-17:14:07:20',
'YYYY-MM-DD:HH24:MI:SS'),interval=>'SYSDATE + 24/24',no_parse=>TRUE);

PL/SQL procedure successfully completed.

The results indicate which procedure is executed, what parameters are passed to it, and when the next invocation is to occur. This particular example indicates that the job is to clean up active sessions that are a week old (168 hours). It also indicates that the next scheduled job execution is on 4/17/2001 at 5:14 pm, and the job should run every 24 hours thereafter.

If the job execution must be modified, either to adjust the age of sessions that should be deleted, or to increase or decrease the frequency of cleanup, you can run the ctxjsub.sql script to submit modified execution parameters.

Follow these steps to submit modified job execution parameters:

1. Locate the following directory:

ORACLE_HOME\portal\admin\plsql\wwc

2. On the database where the Oracle Portal or OracleAS Single Sign-On schema is installed, log on to SQL*Plus with the appropriate user name and password for that schema. For example:

sqlplus portal\portal

3. Enter the following command to submit new cleanup job information:

@ctxjsub <hours_old> <start_time> <time_format> <interval_hours>

Table B-2 lists the ctxjsub parameters.

Table B-2 ctxjsub Parameters

Parameter

Description

hours_old

The age of an active session that should be deleted.

start_time

The time that the next job should run.

time_format

The time format string that specifies how start_time is formatted.

interval_hours

The amount of time, in hours, between runs of the cleanup job.

For example:

SQL> @ctxjsub 200 '04/17/2001 10:00' 'MM/DD/YYYY HH24:MI' 12

The job information is displayed, similar to:

Created path for job id.
DBMS_JOB id = 7381
Cleanup job updated. Job ID = 7381

PL/SQL procedure successfully completed.

The cleanup job submission script can be run any number of times to modify the execution parameters. Each invocation updates the job information associated with the job ID for the cleanup job. This job ID is maintained in the preference store so that the job information is updated instead of submitting multiple jobs.

You can also specify a start_time of START, in which case, the time_format parameter is ignored, but you still need to pass it a value (such as NOW). The result is to run the job <interval_hours> hours from now:

SQL> @ctxjsub 168 START NOW 24

This submits the job as it does in the installation.

If you want the cleanup job to execute immediately, then obtain the job ID by calling ctxjget.sql. Once you know the job ID, you can execute the job by issuing the following command in the product schema:

SQL> exec dbms_job.run(7381);

In the preceding example, 7381 is the job ID returned by the call to ctxjget.sql. When you execute a job in this manner, the next automated invocation of the job occurs at interval_hours after this manual invocation. To run the job on the original schedule, resubmit the start_time desired using ctxjsub.sql.

B.6 Timing and Caching Statistics

All Oracle Portal pages can be run in a special mode in which timing and caching information is displayed. If you want to see this debug information on every page you can set the Parallel Page Engine Parameter showPageDebug to true in the appConfig.xml file.

See Also:

Section 5.6.9, "Configuring the Portal Parallel Page Engine"

If you want to see the debug information for just a few select pages and portlets, you can control the logging level by the _debug URL parameter. For example, to see the timing statistics for the following Oracle Portal page:

http://abc.com/servlet/page?_pageid=21

You can manually insert ?_debug=3

To make:

http://abc.com/servlet/page?_pageid=21?_debug=3

Possible values for _debug are 0, 1, 2, 3, 4, and 5.

Values greater than 1 will potentially raise the logmode value for the duration of the request, and trigger all request log messages to be echoed into the page response.

Note:

All values greater than 0 cause _debug=1 to be propagated in back end requests.

Table B-3 shows the results of _debug values:

Table B-3 _debug Values for Timing and Caching Statistics

Value

Timing and Caching Statistics?

Flag Forwarded to Providers? (as value 1)

logmode Raised to a Minimum of

Log Messages Written to Page Response?

0

Yes

-

-

-

1

Yes

Yes

-

-

2

Yes

Yes

debug

Yes

3

Yes

Yes

request

Yes

4

Yes

Yes

content

Yes

5

Yes

Yes

parsing

Yes

urlDebugMode and urlDebugUsers are additional parameters that can be used to restrict the use of _debug on a URL. See Section 5.6.9, "Configuring the Portal Parallel Page Engine" for more information.

The following statistics are available when the portal page is run in debug mode:

- Portlet Statistics

- Page Statistics

- Additional Summary Statistics

Figure B-1 shows a page that is running in the _debug=0 mode:

Figure B-1 Portal Page Running in Debug Mode

B.6.1 Portlet Statistics

In Figure B-1, you can see a number of Portlet related statistics listed under each portlet. Each Portlet has a unique internal reference identification number. This number is used in the "Information for Portlet" summary. For the portlet in the top left corner of Figure B-1, you can see that this number is 6256.

For each portlet the following statistics are listed:

B.6.1.1 Portlet Timing Information

- Portlet Timing (msecs) (wait msecs)
Indicates how many milliseconds it took to retrieve the portlet, and how long the request was queued, also in milliseconds.

- Timing Status
This is deprecated and no longer in use.

- XSLT Timing (msecs)
Displays the number of milliseconds that were needed to retrieve the XSL style sheet, in case the portlet is an XML portlet.

B.6.1.2 Portlet Caching Information

- Portlet Cache status Web Cache (values) File System Cache (values)
This is the Cache status from both Oracle Web Cache and the portal cache.

Valid values for Oracle Web Cache are:

- MISS, or NEW [M] indicating a cache miss in Oracle Web Cache and that the content that is generated by the portlet is new.

- MISS, or STALE [G] indicating a cache miss, due to stale content in Oracle Web Cache.

- HIT [H] indicating an Oracle Web Cache hit.

Valid values for File System Cache are:

- HIT_PING indicating a cache hit for a validation-based portlet.

- HIT_EXPIRES indicating a cache hit for an expiry-based portlet.

- MISS_STALE indicating a cache miss due to stale content in the Cache. This applies to both expiry, and validation-based portlets.

- MISS_NEW indicating a cache miss and that the content that is generated by the portlet is new. This applies to both expiry, and validation-based portlets.

If a portlet uses the File System Cache, then the information mentioned in the preceding text will be listed. Otherwise it will be null.

If there is a hit on Oracle Web Cache, no details about File System Cache will be displayed because the content is served directly out of Oracle Web Cache. Additionally, if a portlet does not use Oracle Web Cache, then no Web Cache information will be printed.

- From Cache: Web Cache Cache Expires (seconds), Age in Cache (secs), File System Cache (values).
Information from both Oracle Web Cache and File System Cache will be printed here based on the type of caching that the portlet uses.

See Also:

Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache

"Cache Expires" lists the number of seconds after which the portlet content in Oracle Web Cache will expire.

"Age in Cache" lists the number of seconds that the portlet content has been Cached in Oracle Web Cache.

"File System Cache" displays the information obtained from the File System Cache about Cache Key, Cache Expiry and about the Cache Level in case of a cache hit, with the Cache Status of either HIT_PING, or HIT_EXPIRES.

In case of a cache hit, the Cache Key and Cache Level (for Validation-based portlets) and Cache Expires and Cache Level (for expiry-based portlets) are displayed, with the Cache Status value of either HIT_PING or HIT_EXPIRES.

For Validation-based and Expires-based portlets, "None" is printed when there is a cache miss due to the portlet content being new. (Cache Status: MISS_NEW) The portlet is contacted to get the new Cache Key, Cache Expiry and Cache Level.

For Validation-based portlets, if the content in the Cache has become stale resulting in a cache miss, the current values in the cache for Cache Key and Cache Level are displayed. In this case, the portlet is contacted to get the updated Cache Key and the level (Cache Status: MISS_STALE).

For Expires-based portlets, when the content in the cache has become stale resulting in a cache miss, a value of INVALID in the Expires field and Cache Level are displayed. In this case, the portlet is contacted to get the updated Cache Expiry and Cache Level (Cache Status: MISS_STALE).

- From Portlet: (Cache Key) (Cache Level)
From Portlet: (Cache Key) (Cache Level)

This is the information obtained from the portlet about File System Cache Key, Cache Expiry, and Cache Level when there is a cache miss and when portlet is contacted for the updated, or new values (Cache Status: MISS_NEW, or MISS_STALE). Note that there is no Oracle Web Cache related information displayed in this section.

For Validation-based portlets, when there is a cache hit and if the ping is successful, meaning the content in the Cache is still valid, then the portlet does not return a new Cache Key and Cache Level; instead it will indicate that the cache is still valid. In this case, "Ping Success" is displayed (Cache Status: HIT_PING).

For Expires-based portlets, when there is a cache hit and if the content has not expired, then the portlet is not contacted for the content. In this case, "Not contacted" is displayed (Cache Status: HIT_EXPIRES).

Following are a few examples that show different caching scenarios and the resulting output. Note that the other page and portlet related output is not shown here.

Note:

In this release, page portlets are requested as portlets, separate from the container page definition. Therefore, portlet and page caching information is displayed for each page portlet in the debug output.

Example B-1 Caching Information Debug Output 1

Portlet Cache: File System Cache, Caching Type: Validation-based, Status: MISS, STALE.

Caching information for portlet:
Portlet Cache status: File System Cache:- MISS,STALE
From Cache: File System Cache:- Cache Key: 42, Cache Level: USER
From Portlet: Cache Key: 44, Cache Level: USER

Example B-2 Caching Information Debug Output 2

Portlet Cache: File System Cache, Caching Type: Expires-based, Status: MISS, NEW.

Caching information for portlet:
Portlet Cache status:File System Cache:-  MISS,NEW
From Cache: File System Cache:-None
From Portlet: Cache Expires: 1, Cache Level: USER

Example B-3 Caching Information Debug Output 3

Portlet Cache: File System Cache, Web Cache, Caching Type: Validation and Invalidation-based, Status: MISS, NEW in File System Cache and Web Cache.

Caching information for portlet:
Portlet Cache status: Web Cache:- MISS,NEW [M], File System Cache:- MISS,NEW
From Cache: Web Cache:- Cache Expires: 86400 secs, Age in Cache: 0 secs , File System Cache:- None
From Portlet: Cache Key: 9.0.2.2.1502:04:18:09:19:56, Cache Level: SYSTEM

Example B-4 Caching Information Debug Output 4

Portlet Cache: Web Cache, Caching Type: Invalidation-based, Status: HIT in Web Cache.

Caching information for portlet:
Portlet Cache status: Web Cache:- HIT [H]
From Cache: Web Cache:- Cache Expires: 86400 secs, Age in Cache: 58 secs
From Portlet: -

B.6.2 Page Statistics

Every page has a unique internal reference identification number, similar to the portlets on the page, shown in Figure B-1.

For the page, the following statistics are listed:

- Elapsed Time (msecs)
This is the total amount of time required to generate the page calculated in the Parallel Page Engine (PPE). The actual generation time in the browser can be higher, due to network overhead.

Elapsed time is made up of page meta WAIT time and Stream time. Page meta WAIT time is the time taken to wait on content through an HTTP connection. Stream time is the time taken streaming and assembling the content pieces. Stream time is in turn composed of the following elements:

- Page meta time

- Time waiting for portlets to complete

- Time taken streaming content to the browser

Effectively, elapsed time is the total amount of time (in milliseconds) that it takes to put the page together, from the time the request was received to the last byte being written to the browser.

- Page meta-time (msecs) (wait = msecs)
Displays the time that it takes to retrieve the page meta data. The wait time (msecs) represents how long the request was queued.

- Page meta Cache Status (Web Cache values), (Cache Expires msecs), (Age in Cache msecs), (File System Cache values)
Represents the cache status from both Oracle Web Cache and portal cache. Valid values for Oracle Web Cache are MISS, or NEW and HIT. Valid values for portal cache are HIT, or PING, and MISS, or STALE. The Web Cache Expires value and the Age in Cache are both measured in milliseconds.

- Login meta-time (msecs) (wait msecs)

Displays the time (in milliseconds) that it takes to retrieve the login meta data. The wait time represents the total amount of time (in milliseconds) that the request spends in the request queue.

- Login meta Cache Status

Similar to Page meta Cache Status mentioned earlier, represents the cache status for the login meta data from both Web Cache and portal cache.

B.6.3 Additional Summary Statistics

- Stream info (msecs)
Represents (in milliseconds) how long it takes for the page to stream to the browser.

- processing (msecs)
Processing time (in milliseconds) for streaming.

- write (msecs)
The write lines can repeat several times. The lines represent each physical buffer write to the stream itself. This are one set for each buffer write.

- flush (msecs)
The flush logs indicate that the writing stream was flushed. This is logged to keep track of the number of network round trips.

B.7 Using the cfgiasw Script to Configure Mobile Settings

If you want to change portal's references to Oracle Portal or OracleAS Wireless' portal service URLs, you must use the cfgiasw.pl script to manually update the references. The script file is located here:

ORACLE_HOME\assistants\opca

Running the script without parameters will print its usage to the screen, which is shown next:

Usage:

perl cfgiasw.pl -s portal_schema
-w ias wireless url
-h portal home page url
-c connect_string

Table B-4 Oracle Application Server Wireless Configuration Parameters

Parameter

Description

-s

Oracle Database schema for Oracle Portal database objects.

Default = PORTAL

-w

The URL of the Oracle Application Server Wireless gateway for mobile requests to Oracle Portal. This parameter is mandatory (no default). The value for this parameter must be enclosed in double quotation marks.

-h

The URL of the Oracle Portal home page. This is used within portal to determine the character set of the Oracle Portal middle tier. This information is required when creating an Oracle Application Server Wireless service This parameter is not mandatory (no default). The value for this parameter must be enclosed in double quotation marks.

-c

Connect string for database (no default).

Note:

- Ensure that you are using the Perl version that is available as part of the Oracle Portal installation, by setting the path variable as follows:
For Windows:

PATH ORACLE_HOME\perl\bin\

For Solaris or Linux:

PATH ORACLE_HOME/perl/bin

- While running the cfgiasw script you are prompted for the password. Specify the portal schema password for the script to proceed.

For non-hosted Portals, the OracleAS Wireless' Portal service URL reference can be set in the Mobile tab of the Global Settings page, except the URL of the Oracle Portal home page, which can only be set using the cfgiasw script.

This script is used to set references to both the OracleAS Wireless Portal Service URL and the Oracle Portal home page URL, in Oracle Portal. It can be used in a hosted environment to set the URL references, and will affect all subscribers, because this information is not configured separately for each subscriber. For example:

perl cfgiasw.pl -s portal -c portal_db -w "http://<iaswhost>:<port>/ptg/rm?PAoid=$wireless_service_id"

In the preceding example, if a mobile device makes a request to the Oracle Portal directly without being mediated by an Oracle Application Server Wireless server, Oracle Portal redirects the client to the URL specified here. This URL should be the Oracle Portal's service URL on the Oracle Application Server Wireless server, in the form:

http://<host>:<port>/ptg/rm?PAoid=<service_id>

If this setting is blank, then mobile client requests made directly to Oracle Portal receive an HTTP status indicating that their request is not supported.

See Section 5.7, "Configuring Mobile Support in Oracle Portal" for configuring other mobile settings in Oracle Portal.

B.8 Using the cfgxodnc.pl Script to Change the Mobile Device Component of the Cache Key

The cache key used by Oracle Portal is composed of numerous components. One of these components is based on the URL, and another is based on the OracleAS Wireless header, X-Oracle-Device.Class. These components allow portlet content to be cached based on the class of the mobile device used. Examples of device classes include pcbrowser, pdabrowser, microbrowser, and so on.

You can enable portlet content to be cached based on the name of a specific device rather than the device class. To do this, the X-Oracle-Device.Class header in the device component of the cache key must be replaced with the X-Oracle-Device.Name header.

To ensure that Oracle Portal works properly with portlet content that is cached based on the value of the X-Oracle-Device.Name header, you must do the following:

- Enable Oracle Portal to use this header. Refer to Section B.8.1, "Adding the PlsqlCGIEnvironmentList Parameter to the portal_dads.conf File" for the steps to be performed.

- Disable caching or configure Oracle Portal to cache content based on the X-Oracle-Device.Name header. To configure Oracle Portal to cache portlet content based on the X-Oracle-Device.Name header, you must perform the following tasks:

- Section B.8.2, "Running the cfgxodnc.pl script"

- Section B.8.3, "Adding the useDeviceNameCacheKeys parameter to the PPE Configuration file"

- Section B.8.4, "Clearing Cached Data"

See Also:

Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache for the procedure to disable caching of portal content.

B.8.1 Adding the PlsqlCGIEnvironmentList Parameter to the portal_dads.conf File

To enable Oracle Portal to use the X-Oracle-Device.Name header, you must add a new parameter, PlsqlCGIEnvironmentList, to the portal_dads.conf file for the Oracle Fusion Middleware instance. To edit the portal_dads.conf file, perform the following steps:

1. Open the portal_dads.conf file located in the following directory:

DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration

2. Add the following entry to the file:

PlsqlCGIEnvironmentList HTTP_X_ORACLE_DEVICE_NAME

3. Save the portal_dads.conf file.

Note:

Although you can manually edit the portal_dads.conf file, we recommend using Application Server Control. To do this, follow the steps outlined in Section A.2, "DAD Configuration File (portal_dads.conf)" using Fusion Middleware Control.

If you manually edit the portal_dads.conf file, then you must add the necessary mod_rewrite and mod_weblogic directives to the httpd.conf and mod_weblogic.conf files respectively.

4. Run the following command to restart Oracle HTTP Server:

INSTANNCE_HOME\bin\opmnctl restartproc type=OHS

If you now try to access Oracle Portal using a mobile device, then content will be rendered based on the mobile device used. The cache will also have an increased capacity.

B.8.2 Running the cfgxodnc.pl script

To enable Oracle Portal to use the X-Oracle-Device.Name header, run the cfgxodnc.pl script in the on mode. This script is available at the following location:

Oracle_HOME\assistants\opca

Usage:

perl cfgxodnc.pl -s portal_schema
-c portal_connect_string
-on|-off

To run this script, you must specify all the parameters.

Table B-5 The cfgxodnc Script Parameters

Parameter

Description

-s

Oracle Database schema for Oracle Portal database objects.

Default = PORTAL

-c

Connect string for database (no default).

-on/-off

Option to enable or disable use of X-Oracle-Device.Name in the cache key.

Note:

Ensure that you are using the Perl version that is available as part of the Oracle Fusion Middleware installation, by setting the path variable as follows:

For Windows:

PATH ORACLE_INSTANCE\perl\bin\

For Solaris or Linux:

PATH ORACLE_INSTANCE/perl/bin

Note:

While running the cfgxodnc.pl script you are prompted for the password. Specify the portal schema password for the script to proceed.

The following is an example showing the usage of the cfgxodnc.pl script to enable the X-Oracle-Device.Name header:

perl cfgxodnc.pl -s PORTAL -c portal_database -on

The cache size increases when the X-Oracle-Device.Name header is used in the device component of the cache key. If you revert to using the X-Oracle-Device.Class header, then the cache size decreases again.

You can revert to using the X-Oracle-Device.Class header in the device component of the cache key by running the cfgxodnc.pl script in the off mode.

B.8.3 Adding the useDeviceNameCacheKeys parameter to the PPE Configuration file

To use device names instead of device classes when building cache keys, set the useDeviceNameCacheKeys by editing the appConfig.xml file as mentioned below:

1. Open the appConfig.xml file located in the following directory:

DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration

2. Add the following entry to the file:

useDeviceNameCacheKeys

3. Save the appConf.xml file.

4. Restart the Oracle HTTP Server and WLS_PORTAL.
Refer to Section 5.6.3, "Stopping and Starting Portal Components Using Fusion Middleware Control" for information on restarting the Oracle HTTP Server and WLS_PORTAL components.

B.8.4 Clearing Cached Data

To ensure that new cache keys are built based on the device name, you must clear all cached data, both in Oracle Web Cache and Oracle Portal File System Cache. Refer to Section 6.7.3, "Configuring Portal Web Cache Settings Using WLST" for information about clearing data cached in Oracle Web Cache. Refer to Section 5.6.8, "Clearing the Portal Cache" for information about clearing data cached in the File System Cache.

B.9 Using the Category and Perspective Scripts

To ensure that all new category and perspective pages are created without errors and that all existing category and perspective pages display their associated items and pages as expected, you must run the category and perspective scripts.

The scripts required are:

ORACLE_HOME\portal\admin\plsql\wws\pstdefin.sql
ORACLE_HOME\portal\admin\plsql\wws\pstpgshw.sql
ORACLE_HOME\portal\admin\plsql\wws\pstundef.sql
ORACLE_HOME\portal\admin\plsql\wws\pstpgcre.sql
ORACLE_HOME\portal\admin\plsql\wws\pstprcpg.sql

To run these scripts:

1. Delete the current category or perspective templates.

2. Connect to Oracle Portal using SQL*Plus as the portal schema user.

3. Configure the pstdefin.sql file with:

- Page group information. You can re-create the pages in a single page group, several page groups or all page groups.

- Page information. You can re-create category pages only, perspective pages only, or both.

Descriptions for these settings are in the pstdefin.sql file. If necessary, use the script pstpgshw.sql to retrieve information from Oracle Portal to configure the pstdefin.sql file.

4. Run the script pstpgcre.sql to apply the changes. For example:

SQL> @pstpgcre.sql

If a template exists in the page group when the new pages are created, new category and perspective pages are created based on that template. If you delete the template before running the scripts or the template is missing, then a new template is created in the page group and the new pages are based on this template.

B.10 Using the PDK-Java Preference Store Migration and Upgrade Utility

A preference store is a mechanism for storing information like user preference data, portlet and provider settings, or even portlet data, while using Oracle Portal. Currently, PDK-Java has two PreferenceStore implementations, DBPreferenceStore and FilePreferenceStore. DBPreferenceStore persists data using a JDBC compatible relational database and FilePreferenceStore persists data using the file system.

This utility allows users to migrate existing data between different preference stores (for example, from FilePreferenceStore to DBPreferenceStore) and to upgrade from previous releases of PDK-Java and Oracle Portal to manage portlet preference data generated by existing portlets. The tool allows upgrading users to ensure that their existing locale-specific portlet preference data uses a naming format compatible with the latest PDK and Oracle Portal releases.

If you have already installed OracleAS PDK, you can manage the information stored in the preference store by using the Preference Store Migration and Upgrade Utility, which is included in the pdkjava.jar file.

For a complete description of the syntax of the Preference Store Migration and Upgrade Utility, run the following command:

java -classpath $ORACLE_HOME/portal/jlib/pdkjava.jar;
$ORACLE_HOME/portal/jlib/ptlshare.jar
oracle.portal.provider.v2.preference.MigrationTool

Note:

For filetodb mode of migration, in addition to the pdkjava.jar and ptlshare.jar files that are included in the classpath in the above command, you should include $ORACLE_HOME/jdbc/lib/ojdbc6.jar.

You can run the Preference Store Migration and Upgrade Utility in either of the following modes based on the -mode you select while running the command:

- Upgrade mode

- Migration mode

Note:

After running the utility, restart WLS_PORTAL and Oracle HTTP Server to ensure that the latest preference store information is used.

Upgrade Mode

Use an upgrade mode (file or db) to upgrade data in place, and to modify existing locale-specific preferences in the preference store so that the naming format used is compatible with the current version of Oracle Portal and a given localePersonalizationLevel setting.

Table B-6 describes the upgrade modes in which you can run the utility.

Table B-6 Upgrade Modes in Which to Run the Utility

Mode

Description

file

Use when data in a FilePreferenceStore must be upgraded.

db

Use when data in a DBPreferenceStore must be upgraded.

An upgrade mode (file or db) can be used in the following scenarios:

- You have upgraded from OracleAS PDK 9.0.4.0.0 or earlier and want to use existing portlets with the default localePersonalizationLevel setting of language (In earlier releases, the default setting was locale).

- You have upgraded from Oracle Portal 9.0.2.0.0 or earlier and want to use existing portlets with a localePersonalizationLevel setting of locale (Oracle Portal now uses different names for some locales and therefore some existing data must be remapped).

- You want to change the localePersonalizationLevel for an existing portlet from locale to language or vice-versa.

When using an upgrade mode (file or db), you must use the -remap option to specify the localePersonalizationLevel (language or locale) that you are upgrading to. You can also use the -countries option to specify a prioritized list of ISO country codes, indicating your order of preference in case of a collision between remapped preferences for different countries. For example, if you specify -remap language -countries GB,US in the command, it means that if the utility comes across both US English and British English preferences (en_US and en_GB) in a given preference store, it will remap the British English preference to become the English-wide preference (en).

Note:

While running the utility in db mode, for the pref1User and pref1password properties, use the values specified in the JDBC connection definition in the data-sources.xml file.

Migration Mode

Use a migration mode (filetodb, filetofile, dbtofile, or dbtodb) to copy data from a source preference store to a target preference store. When the utility is run in this mode, the preference stores for all the portlet definitions are updated.

Table B-7 describes the migration modes in which you can run the utility.

Table B-7 Migration Modes in Which to Run the Utility

Mode

Description

filetodb

Use when data must be copied from a FilePreferenceStore to a DBPreferenceStore.

filetofile

Use when data must be copied from one FilePreferenceStore to another FilePreferenceStore that is in a different location.

dbtofile

Use when data must be copied from a DBPreferenceStore to a FilePreferenceStore.

dbtodb

Use when data must be copied from one DBPreferenceStore to another DBPreferenceStore that is based on a different database table.

When using a migration mode (filetodb, filetofile, dbtofile, or dbtodb), you can use the -remap and -countries options to specify that the data should be upgraded in the course of being migrated, that is, locale-specific preferences should be remapped appropriately.

The other options accepted by the utility are used to specify the properties of the preference stores involved in the upgrade or migration process. These options must correspond to the tags you specify in provider.xml to describe the preference stores. For more information about the properties you can set on a preference store, see the PDK-Java XML Provider Definition Tag Reference at:

http://www.oracle.com/technology/products/webcenter/files/pdk_downloads/xml_tag_reference_v2.html

Properties beginning with the prefix -pref1 correspond to properties of the source preference store. In an upgrade mode (file or db), this is the only preference store. For example, specifying -pref1UseHashing true -pref1RootDirectory j2ee/home/applications/jpdk/jpdk/WEB-INF/providers/sample would set the useHashing and rootDirectory properties of a source FilePreferenceStore.

Note:

If you installed the Portal Development Kit, then the source preference store will be available in the following location:

DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\jpdk\dir_name\war\WEB-INF\providers

When one of the migration basic modes is selected, properties beginning with the prefix -pref2 correspond to properties of the target preference store. For example, specifying -pref2User portlet_prefs -pref2Password portlet_prefs -pref2URL jdbc:oracle:thin:@myserver.mydomain.com:1521:mysid would set the database connection details on a target DBPreferenceStore.

The following are examples of the usage of the utility in UNIX:

java -classpath $ORACLE_HOME/portal/jlib/pdkjava.jar;
$ORACLE_HOME/portal/jlib/ptlshare.jar
oracle.portal.provider.v2.preference.MigrationTool -mode file -remap language
-countries GB,US -pref1UseHashing true
-pref1RootDirectory $DOMAIN_HOME/servers/WLS_PORTAL/tmp/_WL_user/jpdk/dir/war/WEB-INF/providers

java -classpath $ORACLE_HOME/portal/jlib/pdkjava.jar;
$ORACLE_HOME/portal/jlib/ptlshare.jar; $ORACLE_HOME/jdbc/lib/ojdbc6.jar
oracle.portal.provider.v2.preference.MigrationTool -mode filetodb -remap locale
-countries AR,MX -pref1UseHashing true
-pref1RootDirectory $DOMAIN_HOME/servers/WLS_PORTAL/tmp/_WL_user/jpdk/dir/war/WEB-INF/providers
-pref2User portlet_prefs -pref2Password portlet_prefs
-pref2URL jdbc:oracle:thin:@myserver.mydomain.com:1521:mysid

B.11 Using the Schema Validation Utility

The Schema Validation Utility (SVU) is used to clean up and report any data inconsistencies in the Portal schema. The SVU performs validations on Page Group objects and DB Provider objects.

Some of the benefits of using the SVU are:

- It prevents Oracle Portal import from failing due to data inconsistencies between the source and target Portal instances.

- It prevents Oracle Portal patching from failing when applying a patch to update a version of Portal.

Schema Validation Utility can be run in the following scenarios:

- During the Oracle Portal Export and Import process.

- When errors such as ORA-1403, ORA-1422, and ORA-4088 are seen when using the Oracle Portal user interface.

For a more detailed explanation of how the validation is performed, and to download the SVU script, svu_rept.sql, log in to Oracle Metalink at http://metalink.oracle.com and read the article Schema Validation Utility. The Doc ID for this article is 286619.1.

There are two ways of running the Schema Validation Utility, which are:

- Using the Schema Validation Utility with Oracle Portal Export and Import

- Using the Standalone Schema Validation Utility

B.11.1 Using the Schema Validation Utility with Oracle Portal Export and Import

In Oracle Portal Export and Import, the SVU is run automatically in REPORT mode by default in the background during export and import, in the following stages:

1. Before exporting - To clean up any data inconsistencies that exist on the source instance.

2. Before importing - To clean up any data inconsistencies that exist on the target instance that could affect the import process.

3. After importing - To clean up any data inconsistencies that may have been introduced by the import process.
If the SVU reports any inconsistencies, the export or import process will fail with an ABORT status. If the export or import process is aborted, you will see an error message detailing the inconsistency and providing you with a "cleanup mode" link. Clicking on the link runs SVU in CLEANUP mode so that you can complete the export/import process.

B.11.2 Using the Standalone Schema Validation Utility

The SVU can be run in standalone mode when there are data inconsistencies reported or observed. To run the utility in standalone mode, you need to execute the script svu_rept.sql as the Oracle Portal schema owner (PORTAL):

SQL> @svu_rept.sql

You will be prompted to specify the mode and type to run the script.

Mode:

- REPORT - Reports data inconsistencies.

- CLEANUP - Cleans up data inconsistencies.

Type:

- ALL - Validates both page group objects and DB Provider objects.

- PAGEGROUP - Validates page group objects only.

- DBPROV - Validates DB Provider objects only.

After you have provided the mode and type, you will be prompted to specify a path to save the log file. You can enter a path like c:\temp\svu.log here. Run the SVU in REPORT mode first, before running it in CLEANUP mode.

IMPORTANT:

- Always take a valid backup of the database before running the SVU in CLEANUP mode.

- If you run the SVU in CLEANUP mode and then in REPORT mode, inconsistencies should not be reported. If any inconsistencies are reported, you must contact Oracle Support Services.

C Integrating JavaServer Pages with Oracle Portal

Oracle Portal gives you the ability to create various kinds of Web pages. You can supplement this ability with JavaServer Pages (JSPs).

This appendix describes how you can secure Oracle Portal to allow access to only approved JSPs, and prevent unauthorized access by JSPs to portlet content. It also describes the steps required to allow access for protected external JSPs that require login.

The following topics are covered in this appendix:

- Using the JavaServer Page Configuration File

- Setting Up a JAZN File for External Communication

C.1 Using the JavaServer Page Configuration File

Because almost any JSP using the tag library can request Oracle Portal portlet content, there is a need for a secure way to ensure that only approved JSPs obtain access. You can control this through two mechanisms:

- The <portal:usePortal> tag in the JSP

- An external JSP configuration file

The configuration file identifies the Oracle Portal instances, and page groups within those instances, to which an external JSP is allowed access.

See Section C.1.1, "Contents of Your JavaServer Page Configuration File" for the specific coding requirements of the configuration file.

Your completed configuration file must then be identified to Oracle Portal. See Section C.1.3, "Location of Your JavaServer Page Configuration File" for an explanation of the step.

This section contains the following sub-sections:

- Contents of Your JavaServer Page Configuration File

- Example JavaServer Page Configuration File

- Location of Your JavaServer Page Configuration File

- External JavaServer Page Login

C.1.1 Contents of Your JavaServer Page Configuration File

The required tags are:

- <jps>

- <portal>

- <database>

- <url>

- <cookie>

- <pageGroups>

- <pageGroup>

C.1.1.1 The <jps> Tag

The <jps> tag is a container tag that provides a list of Oracle Portal instances to which external JSPs can have access.

Opening tag

<jps version="1.0">

Version must be set to 1.0 for the current Oracle Portal release.

Closing tag

</jps>

C.1.1.2 The <portal> Tag

The <portal> tag describes an individual Oracle Portal instance.

Opening tag

<portal name="MyPortal" default="true">

Closing tag

</portal>

Table C-1 The <portal> Tag's Attributes

Attribute

Value

name

Any descriptive name given to an Oracle Portal instance. The name must be unique within the configuration file.

default

A true or false flag indicating whether this portal is the default instance that is used if a usePortal tag does not specify a portal name. If you provide no value, default is set to false.

Only one default portal is allowed for each configuration file.

C.1.1.3 The <database> Tag

The <database> tag provides database connection information about a given Oracle Portal instance. For example:

<database data-source="jdbc/MyPortal"/>

The data-source attribute value is the name of the data source, which must be specified in the data-sources.xml file located in the J2EE_HOME/config directory.

Here is an example of a data-source definition:

<data-source
class="com.evermind.sql.DriverManagerDataSource"
name="MyPortal"
location="jdbc/MyPortal"
xa-location="jdbc/xa/MyPortal"
ejb-location="jdbc/MyPortal"
connection-driver="oracle.jdbc.driver.OracleDriver"
username="portal_app"
password="portal_app"
url="jdbc:oracle:thin:@xyz.oracle.com:1521:orcl"
inactivity-timeout="30"
/>

The username and password attributes must be set to the Oracle Portal application schema user name and password.

C.1.1.4 The <url> Tag

The <url> tag provides connection information to the Oracle Portal instance. For example:

<url protocol="http" host="defg.oracle.com" port="7500" path="portal/pls/portal"/>

Table C-2 The <url> Tag's Attributes

Attribute

Value

protocol

The name of the protocol used to connect to the Oracle Portal instance. Currently, only HTTP and HTTPS protocols are supported. If you do not specify a protocol attribute, the default will be http.

host

The computer name for the Oracle Portal middle tier.

port

Port number. If no port is specified, the default number will be 80.

path

For this release, path must be set to /portal/pls/<PORTAL-DAD-NAME>.

C.1.1.5 The <cookie> Tag

The <cookie> tag describes the Oracle Portal cookie. For example:

<cookie name="portal" maxAge="-1" path="/" domain=".oracle.com"/>

Table C-3 The <cookie> Tag's Attributes

Attribute

Value

name

The name of the cookie. This must be the same as the Oracle Portal instance cookie name. name is a required attribute of the cookie tag.

maxAge

The maximum age of the cookie, specified in seconds. Specify a value of -1 if you want the cookie to persist until browser shutdown. maxAge is a required attribute of the cookie tag.

path

The path on the server to which the browser returns this cookie. path is a required attribute of the cookie tag.

domain

This attribute should be specified only if changes were made to the SSO portlet cookie configuration. See the SSO documentation.

C.1.1.6 The <pageGroups> Tag

The <pageGroups> tag forms a container for the pageGroup tags. This tag has no attributes.

Opening tag

<pageGroups>

Closing tag

</pageGroups>

C.1.1.7 The <pageGroup> Tag

The <pageGroup> tag describes each individual page group's properties. For example:

<pageGroup name="JPSDemo" key="welcome" default="true"/>

Table C-4 The <pageGroup> Tag's Attributes

Attribute

Value

name

The page group name. This must be the name given to the page group when it was created in Oracle Portal.

key

The page group's key. The value must match the Access Key value that was assigned to the page group in Oracle Portal. (Note that a page group identified here must have JSP Access enabled.)

default

A flag set to true or false indicating whether or not this page group is the default page group within this Oracle Portal instance. A default page group is the one used in the usePortal tag if no page group name is supplied. If no value provided for default in this pageGroup tag, it will be set to false.

Only one default page group is allowed for each portal instance.

C.1.2 Example JavaServer Page Configuration File

The following is an example of a JSP configuration file:

Example C-1 Example JavaServer Page Configuration File

<jps version="1.0">
<portal name="MyPortal" default="true">
<database data-source="jdbc/MyPortal"/>
<url host="xyz.oracle.com" port="7500" path="/portal/pls/portal"/>
<cookie name="portal" maxAge="-1" path="/" />
<pageGroups>
<pageGroup name="JPSDemo"  key="welcome" default="true"/>
<pageGroup name="JPSDemo2" key="welcome" default="false"/>
</pageGroups>
</portal>
<portal name="AnotherPortal">
<database data-source="jdbc/AnotherPortal"/>
<url protocol="http" host="abc.oracle.com" port="8888"
path="/portal/pls/portal90"/>
<cookie name="portal90" maxAge="-1" path="/" />
<pageGroups>
<pageGroup name="JPSDemo"  key="welcome"/>
<pageGroup name="JPSDemo1"  key="welcome1"/>
<pageGroup name="JPSDemo2"  key="welcome2"/>
<pageGroup name="JPSDemo3"  key="welcome3"/>
<pageGroup name="JPSDemo4"  key="welcome4"/>
</pageGroups>
</portal>
</jps>

C.1.3 Location of Your JavaServer Page Configuration File

Your JavaServer page configuration file can have any other name, and can be located anywhere in the file system.

You specify the location using a context parameter in the web.xml file, which is located in the directory DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portal\dir_name\war\WEB-INF.

The context parameter in the web.xml file is:

<context-param>
<param-name>oracle.webdb.service.ConfigLoader</param-name>
<param-value>/WEB-INF/wwjps.xml</param-value>
<description>This parameter specifies the location of the JPS
configuration file</description>
</context-param>

C.1.4 External JavaServer Page Login

External JSPs can be categorized by their login requirements:

- Public JSPs, which do not require login (or to which users log in through the Oracle Portal login link)

- Protected JSPs, which do require login

Protected external JSPs have additional setup requirements. These are explained in the next section.

C.2 Setting Up a JAZN File for External Communication

The following steps are required only for protected external JSPs. That is, external JSPs that require login.

In the external JSPs, if you need to log in to the portal, you need to use the following tag syntax:

<portal:usePortal id="AnyPortal" pagegroup="AnyPageGroup" login="true" />

When you execute this JSP, you will be redirected to OracleAS Single Sign-On if you are not already logged on. To make this work, look at the following sections:

- Setting Up mod_osso (if not already set up)

- Setting Up JAZN with LDAP

C.2.1 Setting Up mod_osso

By default, your Oracle HTTP Server is registered with OracleAS Single Sign-On. If that has been changed, and re-registration is necessary, refer to the Oracle Application Server Single Sign-On Administrator's Guide.

C.2.2 Setting Up JAZN with LDAP

JAZN is the internal name for a Java Authentication and Authorization Service (JAAS) provider. JAAS is a Java package that enables applications to authenticate and enforce access controls upon users. The use of JAZN in Oracle Portal is limited to the authentication of external JSPs.

Confirm that the JAZN is working with the LDAP. (You can use the demo provided by the JAZN.)

Do the following additional step:

- Go to DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\124k5v\META-INF\orion-application.xml and add the following:

<jazn provider="LDAP" location="ldap://<OIDHOST>:389" default-realm="oracle">
<jazn-web-app auth-method="SSO" />
</jazn>

Port number 389 is a default port for LDAP servers. However, any other port can be assigned. Contact your Oracle Internet Directory Administrator to obtain <host> and <port> information.

See Also:

For more information:

- Section C.2, "Setting Up a JAZN File for External Communication"

- Oracle Fusion Middleware Services Guide for Oracle Containers for Java EE

D Using the wwv_context APIs

The wwv_context package contains procedures to create and maintain Oracle Text indexes used by Oracle Portal. This appendix describes the content of this package in the following sections:

- Procedures

- Functions

- Constants

- Exceptions

Note:

See Chapter 10, "Configuring the Search Features in Oracle Portal" for more information about Oracle Text indexes and how they are used in Oracle Portal.

D.1 Procedures

The wwv_context package contains these procedures:

add_attribute_section

commit_sync

create_index

create_missing_indexes

create_prefs

createindex

drop_all_indexes

drop_index

drop_invalid_indexes

drop_prefs

dropindex

optimize

set_parallel_degree

set_sync_memory

set_use_doc_index

set_use_url_index

sync

touch_index(p_indexes wwsbr_array)

touch_index

update_index_prefs

D.1.1 add_attribute_section

procedure add_attribute_section(
p_attributeid     in number,
p_attributesiteid in number
)

Adds a new section to the section groups used by the Item and Page indexes. The section group corresponds to an attribute. This changes the index metadata only, it does not update the index data itself. The new sections can be searched but the indexes themselves are not changed.

The indexes are changed only if they exist; if the indexes do not exist, this procedure has no effect.

Parameters:

p_attributeId - ID of the attribute section to add.

p_attributeSiteId - Site ID of the attribute section to add.

D.1.2 commit_sync

procedure commit_sync(
p_index       in varchar2
p_commit_sync in boolean
)

(Oracle Database 10g or later) Specifies whether an Oracle Text index is synchronized immediately after data is committed to your portal, or needs to be synchronized manually using wwv_context.sync (see sync).

If you choose to synchronize an index manually or your database is earlier than Oracle Database 10g, you can run wwv_context.sync directly or create a job that calls wwv_context.sync at regular intervals. wwv_context.sync ignores any index where commit_sync is set to true. See also, Section 10.3.5.4, "Scheduling Index Synchronization".

Note:

The commit_sync property is available only in database versions Oracle Database 10g or later. In earlier versions, Oracle Text indexes can be synchronized manually, or according to a synchronization schedule (certain dates and times). See also Section 10.3.5.1, "Synchronizing Oracle Text Indexes".

Parameters:

p_index - The name of the index. One of the Index Name Constants.

p_commit_sync - Determines whether the index synchronizes immediately after a commit. Set commit_sync to true if you want the index to synchronize automatically whenever data is committed in your portal. Set commit_sync to false if you want to synchronize the index manually using wwv_context.sync.

Exception:

INVALID_INDEX - The name of the index was not recognized.

D.1.3 create_index

procedure create_index(
p_index in varchar2
)

Creates a specific, named Oracle Text index. See also, Section 10.3.3, "Oracle Text Indexes".

Use this procedure for troubleshooting purposes only. Under normal circumstances, use create_missing_indexes to create all of the indexes that are missing, or createindex to drop invalid indexes and then re-create the preferences and missing indexes.

Parameters:

p_index - The name of the index you want to create. One of the Index Name Constants.

Exceptions:

INVALID_INDEX - The name of the index was not recognized.

D.1.4 create_missing_indexes

procedure create_missing_indexes(
p_indexes out wwsbr_array
)

Creates all of the Oracle Text indexes that are missing. An index is considered to be present if it exists according to the view ctx_user_indexes.

This procedure does not check to see if the existing indexes are valid. Use the procedure drop_invalid_indexes to drop any indexes that are not entirely valid.

This procedure creates empty indexes. To populate the indexes you must mark them as 'requiring re-indexing' using the procedure touch_index(p_indexes wwsbr_array), and then you must synchronize the indexes.

This procedure does not create Oracle Text Datastore and Filter preferences; these preferences must already exist. Use the procedure create_prefs to create the preferences, if they do not exist.

Parameters:

p_indexes - Returns an array containing the list of indexes created.

D.1.5 create_prefs

procedure create_prefs

Creates the Datastore and Filter preferences which are both used when creating Oracle Text indexes. See also, Section 10.3.3.2, "Oracle Text Index Preferences".

This procedure does not create any of the Lexer preferences. Use the script sbrimtlx.sql located in the directory ORACLE_HOME\portal\admin\plsql\wws to create Lexer preferences. See also, Section 10.3.3.5, "Multilingual Functionality (Multilexer)".

Oracle Text preferences must exist before the indexes are created. Subsequent changes to these preferences do not take effect until the Oracle Text indexes are dropped and re-created.

D.1.6 createindex

procedure createindex(
p_language in  varchar2 default wwnls_api.nls_default_language,
p_message  out varchar2
)

Creates Oracle Text indexes used by Oracle Portal. See Section 10.3.3, "Oracle Text Indexes" for more information.

This high level procedure performs the following tasks:

- Drops all existing preference objects.

- Drops any invalid indexes.

- Re-creates Oracle Text preferences.

- Creates indexes that are missing (initially empty).

- Marks all indexable Oracle Portal content as requiring re-indexing, for all new indexes.

- Synchronizes indexes, that is, first populates and then optimizes the indexes.

This procedure is equivalent to:

wwv_context.drop_prefs;
wwv_context.drop_invalid_indexes;
wwv_context.create_prefs;
wwv_context.create_missing_indexes(l_indexes);
wwv_context.touch_index(l_indexes);
wwv_context.sync;
wwv_context.optimize;

D.1.7 drop_all_indexes

procedure drop_all_indexes

Drops all the Oracle Text indexes used by Oracle Portal.

This procedure does not drop the Oracle Text preferences. Use the procedure drop_prefs to do this.

D.1.8 drop_index

procedure drop_index(
p_index in varchar2
)

Drops a specific, named Oracle Text index. This procedure does not validate that the index exists.

Parameters:

p_index - The name of the index you want to drop. One of the Index Name Constants.

Exceptions:

INVALID_INDEX - The name of the index was not recognized.

D.1.9 drop_invalid_indexes

procedure drop_invalid_indexes

Drops invalid Oracle Text indexes only, that is, valid Oracle Text indexes are not dropped.

An index is considered to be valid, if the following status columns, in the following views, are all set to 'VALID':

- user_indexes.status

- user_indexes.domidx_status

- user_indexes.domidx_optstatus

- ctx_user_indexes.idx_status

If any status column is not valid or, if the index does not have an entry in both views, it is considered to be invalid and will be dropped. See Section 10.3.8, "Viewing the Status of Oracle Text Indexes" for more information.

D.1.10 drop_prefs

procedure drop_prefs

Drops the Oracle Text Datastore and Filter preferences. See also, Section 10.3.3.2, "Oracle Text Index Preferences".

Datastore and Filter preferences are used when creating the Oracle Text indexes. This procedure does not drop any of the Lexer preferences that are created using the script sbrimtlx.sql. The script is located in the directory ORACLE_HOME\portal\admin\plsql\wws.

D.1.11 dropindex

procedure dropindex(
p_language in varchar2 default wwnls_api.nls_default_language,
p_message  out varchar2
)

Drops all existing Oracle Text indexes used by Oracle Portal. See also, Section 10.3.3, "Oracle Text Indexes".

This procedure is equivalent to:

wwv_context.drop_prefs;
wwv_context.drop_all_indexes;

D.1.12 optimize

procedure optimize(
p_optlevel in varchar2 default ctx_ddl.optlevel_full,
p_maxtime  in number   default null,
p_token    in varchar2 default null
)

Optimizes all existing Oracle Text indexes used by Oracle Portal. Each index is optimized by calling the Oracle Text procedure ctx_ddl.optimize_index().

The parameters for this procedure are the same as those required by the Oracle Text procedure ctx_ddl.optimize_index.

Parameters:

p_optlevel - The optimization level, one of FULL, FAST or TOKEN.

p_maxtime - The time (in minutes) that Oracle Text spends optimizing the indexes.

p_token - Token to optimize (when doing TOKEN optimization).

You will find additional information in the Oracle Text Reference on the Oracle Technology Network (OTN), http://www.oracle.com/technology/products/text/index.html.

D.1.13 set_parallel_degree

procedure set_parallel_degree(
p_index           in varchar2,
p_parallel_degree in pls_integer
)

Sets the degree of parallelism used when an index is synchronized using the procedure wwv_context.sync (see sync). On a multi-processor computer you can run the synchronization operation in parallel. If you use multiple processors during synchronization it can speed up indexing, especially when you have large amounts of data to index.

The default setting is 1, no parallelism. A number greater than 1 turns on parallel synchronization. If you specify a parallel degree that is higher than the total number of processors available in your database server, the degree of parallelism achieved during synchronization might be smaller than requested.

Note:

This setting has no effect if the index synchronizes immediately after a commit (get_commit_sync returns true). See also, commit_sync.

You will find additional information in the Oracle Text Reference on OTN, http://www.oracle.com/technology/products/text/index.html.

Parameters:

p_index - The name of the index. One of the Index Name Constants.

p_parallel_degree - The degree of parallelism to use when the specified index is synchronized.

Exceptions:

INVALID_SETTING - The format or value of p_parallel_degree was not recognized.

INVALID_INDEX - The name of the index was not recognized.

INTERNAL_EXCEPTION - An unexpected internal error occurred.

D.1.14 set_sync_memory

procedure set_sync_memory(
p_index  in varchar2,
p_memory in varchar2
)

Specifies the amount of runtime memory that Oracle Text may use when synchronizing an index using the procedure wwv_context.sync (see sync). You can enter the memory value in bytes, or use the suffixes K, B or G to indicate that the value is in kilobytes, megabytes, or gigabytes respectively. For example, enter the value 10000 to specify 10000 bytes, or 10K to specify 10 kilobytes.

When the memory specified becomes full, the data is written to the database. The more frequently this happens, the slower the indexing performance becomes and the Oracle Text indexes also become more fragmented. Fragmentation can slow down portal search queries. Specifying smaller amounts of memory will impact performance and increase index fragmentation, but might be useful when runtime memory is scarce.

If you set p_memory to Null, the default index memory setting is used. This default value is set using the configurable Oracle Text system parameter DEFAULT_INDEX_MEMORY. If you want to specify a different value, it must be less than the Oracle Text system parameter MAX_INDEX_MEMORY.

For more information, see Oracle Text Reference on OTN, http://www.oracle.com/technology/products/text/index.html.

Note:

This setting has no effect if the index synchronizes immediately after a commit (get_commit_sync returns true). See also, commit_sync.

Parameters:

p_index - The name of the index. One of the Index Name Constants.

p_memory - The maximum amount of memory used to synchronize this index.

Exceptions:

INVALID_SETTING - The format or range of p_memory was not recognized.

INVALID_INDEX - The name of the index was not recognized.

INTERNAL_EXCEPTION - An unexpected internal error occurred.

D.1.15 set_use_doc_index

procedure set_use_doc_index(
p_value in boolean
)

Specifies whether the Document index is required. See also, Section 10.3.7, "Disabling Document and URL Indexing".

The value is cached for the duration of the session to avoid repeated requests for this information.

Parameters:

p_value - Either true or false. When set to true, the Document index is required.

D.1.16 set_use_url_index

procedure set_use_url_index(
p_value in boolean
)

Specifies whether the URL index is required. See Section 10.3.7, "Disabling Document and URL Indexing" for more information.

The value is cached for the duration of the session to avoid repeated requests for this information.

Parameters:

p_value - Either true or false. When set to true, the URL index is required.

D.1.17 sync

procedure sync

Synchronizes all Oracle Text indexes used by Oracle Portal. Each index is synchronized by calling the Oracle Text procedure ctx_ddl.sync_index(). This procedure re indexes any rows that have been updated since the last synchronization. After synchronization, newly added or updated content can be searched. See also, Section 10.3.5.1, "Synchronizing Oracle Text Indexes".

Before synchronization, the pending queue is updated for the table wwsbr_url$. This table contains values for all the URLs attributes stored in Oracle Portal. Rows from this queue are removed when the URL value is equal to the value of the constant wwv_context_util.g_noindex. Rows are set to this value to indicate that the original URL was not indexable by Oracle Text, for example, URLs such as those beginning with https:// or javascript:.

You will find additional information on ctx_ddl.sync_index in Oracle Text Reference documentation on OTN, http://www.oracle.com/technology/products/text/index.html.

D.1.18 touch_index(p_indexes wwsbr_array)

procedure touch_index(
p_indexes in wwsbr_array
)

Touches content for one or more indexes. When an index is touched, all the index content is marked as requiring synchronization. See Section 10.3.5.6, "Synchronizing All the Index Content" for more information.

Once index content is marked in this way, use the procedure sync to re index the marked content.

Note that this procedure operates across multiple virtual private portal subscribers, it is not confined to the current subscriber. The procedure switches to each subscriber in turn and returns back to the original subscriber when complete.

Parameters:

p_indexes - An array containing index names to touch. One or more of the Index Name Constants.

D.1.19 touch_index

procedure touch_index(
p_index in varchar2 default null
)

Touches content for a single index or for all indexes. This procedure is a convenient way to touch a single, named index. Alternatively, you can use the procedure to touch all indexes, by passing the value null. See also, Section 10.3.5.6, "Synchronizing All the Index Content".

This procedure calls touch_index(p_indexes wwsbr_array) mentioned earlier.

Parameters:

p_index - The name of the index to touch, or null to touch all indexes. When specifying a name, use of one of the Index Name Constants.

Refer to Section D.1.18, "touch_index(p_indexes wwsbr_array)" for more information.

D.1.20 update_index_prefs

procedure update_index_prefs

Updates the current Oracle Text index datastore preferences. This procedure is valid only for database versions earlier than Oracle Database 10g.

When datastore preferences are modified after the indexes are created, the changes are not applied to the indexes automatically. Use this procedure to apply datastore preference changes to the Oracle Text indexes.

No action is taken for any indexes that are missing.

D.2 Functions

The wwv_context package contains these functions:

checkindex

doc_index

get_commit_sync

get_parallel_degree

get_sync_memory

get_use_doc_index

get_use_url_index

valid_doc_index

valid_url_index

url_index

D.2.1 checkindex

function checkindex(
p_force in boolean default false
) return boolean

Checks whether all required Oracle Text indexes exist. The Document and URL indexes are optional, so the presence and validity of these indexes are determined by calls to valid_doc_index and valid_url_index. See also, Section 10.3.7, "Disabling Document and URL Indexing".

The value returned by checkindex is cached for the duration of the session. Whenever true is passed to p_force, the status of Oracle Text indexes is re-evaluated, regardless of any previously cached value.

Parameters:

p_force - Either true or false. When set to true, Oracle Text indexes are checked.

Returns:

Returns true if all required indexes exist and are valid.

D.2.2 doc_index

function doc_index
return boolean

Checks whether the Document index is required (using get_use_doc_index) and usable (using valid_doc_index).

Returns:

Returns true if the Document index is both required and valid.

D.2.3 get_commit_sync

function get_commit_sync(
p_index in varchar2)
return boolean

Determines whether an index synchronizes immediately after data commits to your portal, or if it must be synchronized manually. See also, commit_sync.

Note:

The commit_sync property is not available for database versions earlier than Oracle Database 10g. This function returns false when called on an earlier database version.

Parameters:

p_index - The name of the index. One of the Index Name Constants.

Returns:

Returns true if the index is configured to synchronize immediately after data is committed to your portal. Returns false if the index is configured to synchronize manually.

D.2.4 get_parallel_degree

function get_parallel_degree(
p_index in varchar2)
return boolean

Gets the degree of parallelism used when an index is synchronized using the procedure wwv_context.sync (see sync). On a multi-processor computer you can run the synchronization operation in parallel. If you use multiple processors during synchronization it can speed up indexing, especially when you have large amounts of data to index.

The default setting is 1, no parallelism. A number greater than 1 turns on parallel synchronization. If the parallel degree is higher than the total number of processors available in your database server, the degree of parallelism achieved during synchronization might be smaller than that requested.

Note:

The parallelism setting has no effect if the index synchronizes immediately after a commit (get_commit_sync returns true).

You will find additional information in the Oracle Text Reference on OTN, http://www.oracle.com/technology/products/text/index.html.

Parameters:

p_index - The name of the index. One of the Index Name Constants.

Returns:

Returns the degree of parallelism used when synchronizing the specified index.

Exceptions:

INVALID_INDEX - The name of the index was not recognized.

INTERNAL_EXCEPTION - An unexpected internal error occurred.

D.2.5 get_sync_memory

function get_sync_memory(
p_index in varchar2)
return boolean

Gets the amount of runtime memory (in bytes) that Oracle Text may use when synchronizing an index using the procedure wwv_context.sync (see sync).

When this memory becomes full, the data is written to the database. The more frequently this happens, the slower the indexing performance becomes and the Oracle Text indexes also become more fragmented. Fragmentation can slow down portal search queries. Small amounts of memory will impact performance and increase index fragmentation, but might be useful when runtime memory is scarce.

A Null value indicates that the default index memory setting is used. This default value is set using the configurable Oracle Text system parameter DEFAULT_INDEX_MEMORY. For more information, see Oracle Text Reference on OTN, http://www.oracle.com/technology/products/text/index.html.

Note:

The memory setting has no effect if the index synchronizes immediately after a commit (get_commit_sync returns true).

Parameters:

p_index - The name of the index. One of the Index Name Constants.

Returns:

Returns the amount of memory (in bytes) used when synchronizing the specified index.

Exceptions:

INVALID_INDEX - The name of the index was not recognized.

INTERNAL_EXCEPTION - An unexpected internal error occurred.

D.2.6 get_use_doc_index

function get_use_doc_index
return boolean

Determines whether the Document index is required. See also, Section 10.3.7, "Disabling Document and URL Indexing".

The value is cached for the duration of the session to avoid repeated requests for this information.

Returns:

Returns true if the Document index is required.

D.2.7 get_use_url_index

function get_use_url_index
return boolean

Determines whether the URL index is required. See also, Section 10.3.7, "Disabling Document and URL Indexing".

The value is cached for the duration of the session to avoid repeated requests for this information.

Returns:

Returns true if the URL index is required.

D.2.8 valid_doc_index

function valid_doc_index
return boolean

Determines whether the Document index is in a valid, usable state. See also, Section 10.3.7, "Disabling Document and URL Indexing". The function checkindex is called, if it has not yet been called.

The value is cached for the duration of the session to avoid repeated requests for this information.

Returns:

Returns true if the Document index exists and is valid.

D.2.9 valid_url_index

function valid_url_index
return boolean

Determines whether the URL index is in a valid, usable state. See also, Section 10.3.7, "Disabling Document and URL Indexing". The function checkindex is called, if it has not yet been called.

The value is cached for the duration of the session to avoid repeated requests for this information.

Returns:

Returns true if the URL index exists and is valid.

D.2.10 url_index

function url_index
return boolean

Checks whether the URL index is required (using get_use_url_index) and usable (using valid_url_index).

Returns:

Returns true if the URL index is both required and valid.

D.3 Constants

The wwv_context package contains these constants:

- Index Name Constants

- Oracle Text AUTO_FILTER Format Constants

- Oracle Text Job Constants

- URL Unsuitable for Indexing Constant

D.3.1 Index Name Constants

Use the following constants to identify the Oracle Text indexes used by Oracle Portal:

- Page index - wwv_context.PAGE_TEXT_INDEX

- Document index - wwv_context.DOC_TEXT_INDEX

- Perspective index - wwv_context.PERSPECTIVE_TEXT_INDEX

- Item index - wwv_context.ITEM_TEXT_INDEX

- Category index - wwv_context.CATEGORY_TEXT_INDEX

- URL index - wwv_context.URL_TEXT_INDEX

PAGE_TEXT_INDEX

PAGE_TEXT_INDEX constant varchar2(30) := 'WWSBR_CORNER_CTX_INDX'

DOC_TEXT_INDEX

DOC_TEXT_INDEX constant varchar2(30) := 'WWSBR_DOC_CTX_INDX'

PERSPECTIVE_TEXT_INDEX

PERSPECTIVE_TEXT_INDEX constant varchar2(30) := 'WWSBR_PERSP_CTX_INDX'

ITEM_TEXT_INDEX

ITEM_TEXT_INDEX constant varchar2(30) := 'WWSBR_THING_CTX_INDX'

CATEGORY_TEXT_INDEX

CATEGORY_TEXT_INDEX constant varchar2(30) := 'WWSBR_TOPIC_CTX_INDX'

URL_TEXT_INDEX

URL_TEXT_INDEX constant varchar2(30) := 'WWSBR_URL_CTX_INDX'

D.3.2 Oracle Text AUTO_FILTER Format Constants

The Document and URL indexes uses AUTO_FILTER to convert documents into a plain text format suitable for indexing. Not all document types need to be filtered; some document types can be indexed directly. AUTO_FILTER uses the following settings to determine which documents require filtering:

- BINARY_FORMAT - indicates that a document is a format, other than plain text or HTML, but supported by AUTO_FILTER, such as PDF. Such documents are converted into an indexable text format (providing the binary format is supported by AUTO_FILTER).

- TEXT_FORMAT - indicates that a document is either plain text or HTML. When specified, the document is not filtered, but might be character set converted.

- IGNORE - indicates that a document need not be indexed at all; for example, image files.

Note:

AUTO_FILTER replaces the INSO_FILTER, which is now deprecated.

BINARY_FORMAT

BINARY_FORMAT constant varchar2(10) := 'BINARY';

TEXT_FORMAT

TEXT_FORMAT   constant varchar2(10) := 'TEXT';

IGNORE

IGNORE        constant varchar2(10) := 'IGNORE';

D.3.3 Oracle Text Job Constants

Use these constants for managing Oracle Text maintenance jobs:

- SYNC_JOB_PREF - the preference name for storing the synchronization job ID. Used by the index synchronization script textjsub.sql. See also, Section 10.3.5.4, "Scheduling Index Synchronization".

- OPTIMIZE_JOB_PREF - the preference name for storing the optimization job ID. Used by the index optimization script optjsub.sql. See also, Section 10.3.5.8, "Scheduling Index Optimization".

SYNC_JOB_PREF

SYNC_JOB_PREF constant varchar2(20) := 'text_sync_jobid';

OPTIMIZE_JOB_PREF

OPTIMIZE_JOB_PREF constant varchar2(20) := 'text_optimize_jobid';

D.3.4 URL Unsuitable for Indexing Constant

The absolute URL value used to indicate that a row should not be indexed. The URL index is created on the wwsbr_url.absolute_url column and this column is populated by a trigger.

If a URL is not suitable for indexing, such as URLs beginning with javascript:, this constant value is used. See also, Section 10.3.6.2, "Unsupported URLs".

G_NOINDEX

G_NOINDEX constant varchar2(15) := 'wwsbr_noindex'

D.4 Exceptions

INVALID_INDEX

The name of the index was not recognized.

INVALID_INDEX exception

INVALID_SETTING

An invalid value was specified for an API setting.

INVALID_SETTING exception

E Configuring the Portal Tools Providers

Portal Tools includes two Web providers, Web Clipping and OmniPortlet, that enable page designers and portlet developers to build portlets declaratively. With the Web Clipping portlet, you can publish content from remote Web sites as portlets on a portal page. With OmniPortlet, you can publish data from various data sources, such as Web Services, XML, or a database, and display the data in various layouts, such as a table, a chart, or HTML that they define.

This appendix covers the following topics:

- Configuring Web Clipping

- Configuring OmniPortlet

E.1 Configuring Web Clipping

Web Clipping is a browser-based declarative tool that enables you to integrate any Web application with Oracle Portal. It is designed to give you quick integration by leveraging the Web application's existing user interface. Web Clipping has been implemented as a Web provider using the Java Portal Developers Kit, which is a component of Oracle Portal.

With Web Clipping, you can collect Web content into portlets in a single centralized Web page. You can use Web Clipping to consolidate content from Web sites scattered throughout a large organization.

Before you use Web Clipping, you must perform some administrative tasks, including:

- Configuring the Web Clipping Repository

- Registering the Web Clipping Provider (PDK Only)

- Configuring HTTP or HTTPS Proxy Settings

- Configuring Caching

- Adding Certificates for Trusted Sites
Section 7.1.12.1 in Chapter 7, "Securing Oracle Portal" describes how to configure or extend the trusted certificate file. A trusted server certificate file, ca-bundle.crt, generated from Oracle Wallet Manager is shipped with Oracle Portal. This file contains an initial list of trusted server certificates that might be used for navigating to some secure servers using HTTPS. However, because it is not a complete list of all possible server certificates that exist on the Web, this file must be configured or extended to recognize any additional trusted server certificates for any new trusted sites that are visited.

- Configuring Oracle Advanced Security for the Web Clipping Provider
Section 7.1.12.2 in Chapter 7, "Securing Oracle Portal" describes configuring Oracle Advanced Security Option (ASO) to secure and encrypt the channel between itself (on the middle tier) and the database, which hosts the Web Clipping Repository.

E.1.1 Configuring the Web Clipping Repository

Web clippings have definitions that must be stored persistently in the Web Clipping Repository hosted by an Oracle Database.

As the portal administrator, you can configure the Web Clipping Repository by editing the repositoryInfo entry in the provider.xml file located in the following directory:

On UNIX:

DOMAIN_HOME/servers/WLS_PORTAL/tmp/_WL_user/portalTools_11.1.1.1.0/tr7qwp/war/WEB-INF/providers/webClipping

On Windows:

DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\tr7qwp\war\WEB-INF\providers\webClipping

Start with one of the following examples for your repository configuration. The repository can be based on MDS or on a database.

Example (Using MDS):

<repositoryInfo class="oracle.portal.wcs.provider.info.MdsInformation">
<mdsConfigLocation>mds-config.xml</mdsConfigLocation>
</repositoryInfo>

Example (Using Oracle Database defined in datasource):

<repositoryInfo class="oracle.portal.wcs.provider.info.JdbcDbInformation">
<jdbcConnetionName>pref/portletPrefs</jdbcConnectionName>
<useASO>false</useASO>
</repositoryInfo>

Example (Using Oracle 10g Database or later):

<repositoryInfo class="oracle.portal.wcs.provider.info.DatabaseInformation">
<useRAA>false</useRAA>
<databaseHost>mycompany.dbhost.com</databaseHost>
<databasePort>1521</databasePort>
<databaseSid>iasdb</databaseSid>
<databaseUsername>webclip_user</databaseUsername>
<databasePassword>AX3tR</databasePassword>
<useASO>false</useASO>
</repositoryInfo>

Example (Using the PORTAL schema in an Infrastructure Database):

<repositoryInfo class="oracle.portal.wcs.provider.info.DatabaseInformation">
<useRAA>true</useRAA>
<useASO>false</useASO>
</repositoryInfo>

The element meanings and values are shown in Table E-3:

Table E-1 The Web Clipping Repository Settings

Field

Value

repositoryInfo

The class attribute in the repositoryInfo tag specifies which type of repository we are using to store Web Clipping definitions. For now the only two valid values of the class attribute are:

"oracle.portal.wcs.provider.info.MdsInformation"

which signifies that MDS is used to store the Web Clipping definitions and further MDS configuration is pushed to the mds-config.xml file; and

"oracle.portal.wcs.provider.info.DatabaseInformation"

which signifies that an Oracle 9i or later database is used to store the Web Clipping definitions, and the database connection details will be included as children in the repositoryInfo tag.

mdsConfigLocation

This child tag of repositoryInfo is only useful when the repositoryInfo class is oracle.portal.wcs.provider.info.MdsInformation. It points to the location of the MDS configuration file (mds-config.xml) regardless of whether the pathname is absolute or relative.

The definition of absolute pathname is system dependent. On UNIX systems, a pathname is absolute if it begins with a single forward slash "/". On Microsoft Windows systems, a pathname is absolute if it begins with a drive specifier followed by single backslash "\", or if it begins with a double backslash "\\".

When a relative path is specified, it is assumed to be relative to the base directory of depending on where the portalTools EAR file is deployed.

The default value is mds-config.xml, a copy of which is provided in WEB-INF.

useASO

Valid values: true | false

Specify true if you wish to use the Advanced Security Option to encrypt the communication channel between the Web Clipping and the database. This is provided to provide added security in case sensitive data is contained in the clipped content.

useRAA

Acceptable values: true | false

Specify true if the Repository Access APIs are to be used to access the database connection parameters. Choosing true for this is equivalent to making Web Clipping Provider use the default OracleAS Infrastructure Database as the Web Clipping Repository.

Note: When you select this option you do not need to specify any other repositoryInfo tags.

databaseHost

Specify the host name of the Oracle database that is version 9i or later.

databasePort

Specify the port number of the Oracle database listener (usually 1521).

databaseSid

Specify the Oracle SID of the database that you are using to host the Web Clipping Repository.

databaseUsername

Enter the user name used to log into the database.

databasePassword

Enter the password for the specified database user name. Enter a plain text password prefixed with the ! character as shown in the example to allow the Web Clipping Provider to encrypt the password in provider for protection once the producer starts.

E.1.2 Registering the Web Clipping Provider (PDK Only)

Perform this task only if you have downloaded and installed the Web Clipping provider as part of OracleAS PDK.

Note:

If you installed Oracle Portal as part of the Oracle Fusion Middleware installation, the Web Clipping provider is registered by default under the Portlet Builder folder in the Portlet Repository.

After you configure the Web Clipping provider, you must register it as a portlet provider in the Oracle Portal instance. You can then add portlets to a portal page.

To register the Web Clipping provider, perform the following steps:

1. Log on to Oracle Portal.

2. Navigate to the Administer tab on the Oracle Portal Home Page. By default, the Providers portlet is available on this page. If it is not available here, then use the Portal Search feature to locate the Providers portlet.

3. In the Providers portlet, click Register a Portlet Provider.

4. Follow the instructions in the registration wizard, and specify the Web Clipping provider registration settings as shown in Table E-2.

Note:

To distinguish this Web Clipping provider from the seeded Web Clipping provider under the Portlet Builder folder in the Portlet Repository, you must give it a distinguishable name, for example, Web Clipping provider on host ABC.

Table E-5 lists the settings that you must specify.

Table E-2 The Web Clipping Provider Registration Settings

Field

Value

Name

WebClipping_ABC

Display Name

Web Clipping provider on host ABC

Timeout

200 seconds

Timeout Message

Web Clipping provider on host ABC timed out

Implementation Style

Web

URL

http://<host>:<port>/portalTools/webClipping/providers/webClipping

If you want the portlet content to be cached, then specify the Web Cache URL host name and port number to point to the Oracle Web Cache instance. For example:

http://<cache_instance_name>:<cache_port>/portalTools/webClipping/providers/webClipping

The user has the same identity in the Web providers application as in the single sign-on identity

Select this option.

Select User to send user-specific information to the provider

Select this option.

Login Frequency

Once Per User Session

Require Proxy

No (if no proxy is required to contact the Provider Adapter)

5. Click Finish.

You can now use the Web Clipping provider to add portlets to a portal page. The Web Clipping provider is registered, by default, under the Portlet Staging Area folder in the Portlet Repository.

E.1.3 Configuring HTTP or HTTPS Proxy Settings

Your HTTP or HTTPS proxy settings must be set to allow the Web Clipping Studio to connect to Web sites outside of your firewall. As the portal administrator, you can set proxy settings manually according to your HTTP or HTTPS configuration. Edit the appropriate entries in the provider.xml file located in the following directory:

On UNIX:

DOMAIN_HOME/servers/WLS_PORTAL/tmp/_WL_user/portalTools_11.1.1.1.0/tr7qwp/war/WEB-INF/providers/webClipping

On Windows:

DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\tr7qwp\war\WEB-INF\providers\webClipping

The following example shows the relevant portion of provider.xml:

<proxyInfo class="oracle.portal.provider.v2.ProxyInformation">
<httpProxyHost>proxy_hostname</httpProxyHost>
<httpProxyPort>proxy_portnum</httpProxyPort>
<dontProxyFor>list_of_proxies</dontProxyFor>
<proxyUser>proxy_username</proxyUser>
<proxyPassword>proxy_password</proxyPassword>
<proxyType>basic_or_digest</proxyType>
<proxyUseAuth>true_or_false</proxyUseAuth>
<proxyUseGlobal>true_or_false</proxyUseGlobal>
<proxyRealm>realm_name</proxyRealm>
</proxyInfo>

The element meanings and values are shown in Table E-3:

Table E-3 The Web Clipping Provider Proxy Settings

Field

Value

httpProxyHost

Enter the host name of a proxy server if one is required to make a URL connection from the web clipping provider to its data sources.

httpProxyPort

Enter the host name of a proxy server (if one is required) to make a URL connection from the web clipping provider to its data sources. If you specify an httpProxyHost, but not a port, httpProxyPort is set to default port number 80.

dontProxyFor

Enter the name of any domain or hosts to which you can directly connect, bypassing a proxy server. Domain names are the part of a URL that contain the names of a business, or organization, or government agency, for example:

*.oracle.com, *.oraclecorp.com, *.us.oracle.com

Hosts can be fully qualified host names or can be IP addresses. You can also use this element to specify a list of host names to restrict content.

proxyUseAuth

Valid values: true | false

Enter true if your proxy server requires authentication. The authentication parameters are specified by the following tags:

proxyType, proxyRealm, proxyUseGlobal, proxyUser, and proxyPassword.

proxyType

Valid values: Basic | Digest

Choose the type of proxy server this provider. Note: For more information on basic or digest authentication, refer to http://www.faqs.org/rfcs/rfc2617.html.

proxyRealm

Enter the name of the realm of the proxy server that is accessed by the user according to the login information below. If you do not know the name of the realm, contact the proxy server's administrator.

proxyUseGlobal

Valid values: true | false

If true, the <proxyUser> and <proxyPassword> values are used for all users. Users do not see the Proxy Authentication section on the Source tab and Personalize screen.

If false, the page designer must log in from the Proxy Authentication section on the Source tab when they define the portlet. The end user must log in from the Proxy Authentication section on the Personalize screen. If proxyUsername and proxyPassword are supplied, they are only used for public users.

proxyUser

Enter the user name to log in to the proxy server.

proxyPassword

Enter the password for the specified user name. You need to prefix ! before your plain password text as shown in the example. It will then be encrypted in provider.xml for protection once the producer starts.

E.1.3.1 Restricting Users from Clipping Content from Unauthorized External Web Sites

To restrict users from clipping content from unauthorized external Web sites, Web Clipping uses the proxy exception list. This is available only for environments that use a proxy server to reach external Web sites. (Usually, you use the proxy exception list to specify any domain to which you can directly connect, bypassing a proxy server.)

To add an external Web site to the proxy exception list:

1. Go to the Provider Test Page: Web Clipping by entering the following URL:

http://servername:port/portalTools/webClipping/providers/webClipping

2. Go to the Edit Provider: webClipping page.

3. In the Proxy Settings section, for the No proxy for field, enter the Web sites which you want to restrict.

4. Click OK to save the settings and return to the Web Clipping Test page.

Users attempting to reach a Web site in one of the listed domains, from the Web Clipping Studio, will receive an HTTP timeout error.

E.1.4 Configuring Caching

By default, validation-based caching is used through Oracle Portal for all Web Clipping portlets. With validation-based caching, the Parallel Page Engine (PPE) contacts the Oracle Portal provider to determine if the cached item is still valid.

If you have Oracle Web Cache installed, you can elect to use invalidation-based caching through Oracle Web Cache. Note that each type of caching is mutually exclusive; that is, you can use only one or the other, but not both.

With invalidation-based caching, an item remains in the cache until the cache receives notification that the item needs to be refreshed. For example, if the Web Clipping portlet contains content that is updated on a regular basis, the cache will be invalidated. Invalidation-based caching, as shown in Figure E-1, decreases the number of requests the Web Clipping provider must entertain while maintaining the same network traffic for each round trip involving PPE. Depending on your deployment scenario, you may prefer using one caching method over the other.

Figure E-1 Invalidation-Based Caching Provided by Oracle Web Cache

See Section 1.3, "Understanding Caching in Oracle Portal" and Section 6.7, "Managing Oracle Portal Content Cached in Oracle Web Cache" for more information about caching.

By default, the Web Clipping provider uses portal caching (validation-based caching). To use Oracle Web Cache (invalidation-based caching), refer to Section E.1.4.1, "Configuring Caching" for instructions on how to configure caching.

If you decide to use Oracle Web Cache to cache Web clipping content, as a final step, you must use the Portal Navigator and change the connect string for the provider URL to point to a URL with the Oracle Web Cache port. Usually, the Oracle Web Cache port is 7778. Check the Fusion Middleware Control Ports page to verify this value. For example:

http://host:webcacheport/portalTools/webClipping/providers/webClipping

In this configuration, Oracle Web Cache caches Web Clipping content between the Oracle Portal instance and the Web Clipping provider.

E.1.4.1 Configuring Caching

To enable caching with Oracle Web Cache, take the following steps:

1. Check the webcache.xml file in the following directory to verify the accurate values of the invalidation host and port number:
On UNIX:

ORACLE_INSTANCE/config/WebCache/wc1

On Windows:

ORACLE_INSTANCE\config\WebCache\wc1

2. Edit the provider.xml file located in the following directory:
On UNIX:

DOMAIN_HOME/servers/WLS_PORTAL/tmp/_WL_user/portalTools_11.1.1.1.0/tr7qwp/war/WEB-INF/providers/webClipping

On Windows:

DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\tr7qwp\war\WEB-INF\providers\webClipping

In the provider.xml file:

1. Search for the useInvalidationCaching tag and set its value to true to enable Oracle Web Cache invalidation-based caching.

2. Search for the cacheExpires tag and set a default value if you wish to modify that value. This value is in minutes.

E.2 Configuring OmniPortlet

OmniPortlet is a subcomponent of Oracle Portal that enables page designers and developers to easily publish data from various data sources using a variety of layouts. You can base OmniPortlet on almost any kind of data source, such as Web Services, spreadsheet (character-separated values), XML, and even application data from an existing Web page. OmniPortlet enables page designers and content contributors to do the following:

- Access secured data

- Format data using a variety of layouts including charts, forms, and reports

- Accept page parameters

- Pass parameters

- Raise events

- Expose personalizable settings to page viewers

Before you use OmniPortlet, you must perform a few administrative tasks, including:

- Section E.2.1, "Configuring the OmniPortlet Provider"

- Section E.2.2, "Performing Optional OmniPortlet Configurations"

- Section E.2.3, "Registering the OmniPortlet Provider (PDK Only)"

- Section E.2.4, "Configuring the OmniPortlet Provider to Access Other Relational Databases Using DataDirect JDBC Drivers"

E.2.1 Configuring the OmniPortlet Provider

Before you use OmniPortlet, you may need to perform certain administrative tasks depending on how you installed Oracle Portal. If you installed Oracle Portal as part of the Oracle Fusion Middleware release, then most of the configurations are already done.

The administrative tasks that you must perform are as follows:

- Section E.2.1.1, "Configuring HTTP or HTTPS Proxy Settings"

- Section E.2.1.2, "Configuring the Secured Data Repository (PDK only)"

- Section E.2.1.3, "Configuring Caching (PDK Only)"

- Section E.2.1.4, "Configuring OmniPortlet to Access HTTPS URLs"

E.2.1.1 Configuring HTTP or HTTPS Proxy Settings

If a proxy server is required for the provider to make a URL connection to a data source outside the firewall, then you must set up the HTTP or HTTPS Proxy.

Note:

Setting up the HTTP or HTTPS Proxy is applicable only to URL-based data sources such as XML, CSV, Web Services, and Web Page data sources.

You'll need to perform the same steps to configure the proxy settings for the OmniPortlet provider as for the Web Clipping provider by editing the OmniPortlet provider.xml file located in the following directory:

On UNIX:

DOMAIN_HOME/servers/WLS_PORTAL/tmp/_WL_user/portalTools_11.1.1.1.0/1pwj8k/war/WEB-INF/providers/omniPortlet

On Windows:

DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\1pwj8k\war\WEB-INF\providers\omniPortlet

After editing the file you do not need to restart Oracle WebLogic Server for the new settings to take effect. However, you do need to set up the proxyInfo tag in Web Clipping's provider.xml file for Web Page Data Source to work properly. Refer to the Web Clipping provider section, Section E.1.3, "Configuring HTTP or HTTPS Proxy Settings" for more information on configuring Web Clipping proxy settings in provider.xml.

The following example shows the relevant portion of provider.xml:

<proxyInfo class="oracle.portal.provider.v2.ProxyInformation">
<httpProxyHost>proxy.mycompany.com</httpProxyHost>
<httpProxyPort>80</httpProxyPort>
<dontProxyFor>*.mycompany.com</dontProxyFor>
<proxyUseAuth>true</proxyUseAuth>
<proxyType>Basic</proxyType>
<proxyRealm>realm1</proxyRealm>
<proxyUseGlobal>false</proxyUseGlobal>
<proxyUser>scott</proxyUser>
<proxyPassword>!tiger</proxyPassword>
</proxyInfo>

The element meanings and values are shown in Table E-4:

Table E-4 The OmniPortlet Provider Proxy Settings

Field

Value

httpProxyHost

Enter the host name of a proxy server if one is required to make a URL connection from the OmniPortlet provider to its data sources.

httpProxyPort

Enter the host name of a proxy server (if one is required) to make a URL connection from the OmniPortlet provider to its data sources. If you specify an httpProxyHost, but not a port, httpProxyPort is set to default port number 80.

dontProxyFor

Enter the name of any domain or hosts to which you can directly connect, bypassing a proxy server. Domain names are the part of a URL that contain the names of a business, or organization, or government agency, for example:

*.oracle.com, *.oraclecorp.com, *.us.oracle.com

Hosts can be fully qualified host names or can be IP addresses. You can also use this element to specify a list of host names to restrict content.

proxyUseAuth

Valid values: true | false

Enter true if your proxy server requires authentication. The authentication parameters are specified by the following tags:

proxyType, proxyRealm, proxyUseGlobal, proxyUser, and proxyPassword.

proxyType

Valid values: Basic | Digest

Choose the type of proxy server this provider. Note: For more information on basic or digest authentication, refer to http://www.faqs.org/rfcs/rfc2617.html.

proxyRealm

Enter the name of the realm of the proxy server that is accessed by the user according to the login information below. If you do not know the name of the realm, contact the proxy server's administrator.

proxyUseGlobal

Valid values: true | false

If true, the <proxyUser> and <proxyPassword> values are used for all users. Users do not see the Proxy Authentication section on the Source tab and Personalize screen.

If false, the page designer must log in from the Proxy Authentication section on the Source tab when they define the portlet. The end user must log in from the Proxy Authentication section on the Personalize screen. If proxyUsername and proxyPassword are supplied, they are only used for public users.

proxyUser

Enter the user name to log in to the proxy server.

proxyPassword

Enter the password for the specified user name. You need to prefix ! before your plain password text as shown in the example. It will then be encrypted in provider.xml for protection once the producer starts.

E.2.1.2 Configuring the Secured Data Repository (PDK only)

OmniPortlet uses the Web Clipping repository to store credentials needed to access secured data. You must configure the repository if you intend to use the Web Page data source or work with secured data (for example, a SQL database or a URL-based data source with HTTP basic authentication). If you have configured the Web Clipping Repository already, you do not need to configure the Secured Data Repository again because they are the same repository.

To configure the repository, click Edit next to Secured Data Repository on the OmniPortlet Provider Test page. The Edit Provider page is displayed, on which you can enter the repository information. Refer to the Web Clipping provider section, Section E.1.1, "Configuring the Web Clipping Repository" for more information.

E.2.1.3 Configuring Caching (PDK Only)

If you want the portlet content cached using invalidation-based caching, then an Oracle Web Cache instance must be configured as a front end to the provider.

You must use the URL host name and port number to point to the Oracle Web Cache instance when registering the provider as shown in the following example:

http://<cache_instance_name>:<cache_port>/portalTools/omniPortlet/providers/omniPortlet

This task must be performed when registering the OmniPortlet provider. Refer to Section E.2.3, "Registering the OmniPortlet Provider (PDK Only)" for details about registering the OmniPortlet provider.

When an OmniPortlet definition is altered either through the Edit Defaults or Personalize page, the provider generates a request that invalidates and removes the portlet content from the cache. The invalidation request is sent to the invalidation port of the Oracle Web Cache instance. Information about the Oracle Web Cache instance is maintained in the webcache.xml file in the ORACLE_INSTANCE/config/WebCache/wc1 directory. If the Web Cache invalidation settings change, then you must update this file. The following example shows sample entries in the webcache.xml file:

<?xml version="1.0"?>
<webcache>
<invalidation
host="<cache_instance_name>"
port="<cache_invalidation_port>"
authorization="<obfuscated_username_password>"/>
</webcache>

Where:

- <cache_instance_name> is the host name of the Web Cache instance.

- <cache_invalidation_port> is the Web Cache invalidation port.

- <obfuscated_username_password> is the invalidator user name and password.
For information about obfuscating the invalidator user name and password, refer to the Oracle Fusion Middleware Developer's Guide for Oracle Portal.

E.2.1.4 Configuring OmniPortlet to Access HTTPS URLs

You can configure OmniPortlet to access data through HTTPS URLs by doing the following:

- Adding Certificates for Trusted Sites

- Library For HTTPS Access (PDK Only)

Adding Certificates for Trusted Sites

Perform this task only once, either for Web Clipping or for OmniPortlet.

The trusted server certificate file, ca-bundle.crt, generated from Oracle Wallet Manager is shipped with Oracle Portal. This file contains an initial list of trusted server certificates that may be used for navigating to some secure servers using HTTPS. However, because the file does not contain a complete list of all possible server certificates that exist on the Web, this file must be configured or extended to recognize any additional trusted server certificates for any new trusted sites that are visited. Refer to Section 7.1.12.1, "Adding Certificates for Trusted Sites" for details about configuring or extending the trusted certificate file.

Copying the Library for HTTPS Access (PDK Only)

To access HTTPS URLs, OmniPortlet needs access to the files, njssl10.dll (for Windows) or libnjssl10.so (for UNIX).

For providers running on Windows, the njssl10.dll file must be present in a folder defined in the PATH environment variable. If it is not available, then you can copy this library from the ORACLE_HOME/bin directory.

For providers running on UNIX, the libnjssl10.so file must be present in the folder defined in LD_LIBRARY_PATH environment variable. If it is not available, then you can copy this library from the ORACLE_HOME/lib directory.

After copying the library, you must restart the WLS_PORTAL instance.

E.2.2 Performing Optional OmniPortlet Configurations

The following configuration tasks are optional.

Setting the LocalePersonalizationLevel

The default setting for the LocalePersonalizationLevel of OmniPortlet and Simple Parameter Form is none. This mode indicates that, when you edit the portlet defaults by using the Edit Defaults mode, the changes apply to all users, regardless of the current portal session language or the locale of the browser. If you do not want the changes made using the Edit Defaults mode to apply to all users, then you can modify this setting for the OmniPortlet provider by changing the LocalePersonalizationLevel tag to language or locale in the provider.xml file located in the following directory:

On UNIX:

DOMAIN_HOME/servers/WLS_PORTAL/tmp/_WL_user/portalTools_11.1.1.1.0/1pwj8k/war/WEB-INF/providers/omniPortlet

On Windows:

DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\1pwj8k\war\WEB-INF\providers\omniPortlet

For more information about these settings, refer to the PDK-Java Release Notes available at the following location:

ORACLE_HOME/portal/pdkjava/v2/pdkjava.v2.releasenotes.html

Reverting to Using Graph Class to Render Chart Layout Style

OmniPortlet uses the ThinGraph class to render the chart layout style. This provides better multilingual support and removes middle-tier font dependence. The chart style produced in Oracle Portal 11.1.1 may be different from that of earlier versions where Graph class was used. To display the old chart style, you must revert to using the old Graph class.

To do this, perform the following steps:

1. Navigate to the provider.xml file located in the directory
On UNIX:

DOMAIN_HOME/servers/WLS_PORTAL/tmp/_WL_user/portalTools_11.1.1.1.0/1pwj8k/war/WEB-INF/providers/omniPortlet

On Windows:

DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\1pwj8k\war\WEB-INF\providers\omniPortlet

2. Edit the useThinGraph tag as follows:
<useThinGraph>false</useThinGraph>

3. Save the provider.xml file.

E.2.3 Registering the OmniPortlet Provider (PDK Only)

Perform this task only if you have downloaded and installed the OmniPortlet provider as part of OracleAS PDK.

Note:

If you installed Oracle Portal as part of the Oracle Fusion Middleware installation, the OmniPortlet provider is registered by default under the Portlet Builder folder in the Portlet Repository.

After you configure the OmniPortlet provider, you must register it as a portlet provider in the Oracle Portal instance. You can then add portlets to a portal page.

To register the OmniPortlet provider, perform the following steps:

1. Log on to Oracle Portal.

2. Navigate to the Build tab on the Oracle Portal Home Page. By default, the Providers portlet is available on this page. If it is not available here, then use the Portal Search feature to locate the Providers portlet.

3. In the Providers portlet, click Register a Portlet Provider.

4. Follow the instructions in the registration wizard, and specify the OmniPortlet provider registration settings.

Note:

To distinguish this OmniPortlet provider from the seeded OmniPortlet provider under the Portlet Builder folder in the Portlet Repository, you must give it a distinguishable name, for example, OmniPortlet provider on host ABC.

Table E-5 lists the settings that you must specify.

Table E-5 The OmniPortlet Provider Registration Settings

Field

Value

Name

OmniPortlet_ABC

Display Name

OmniPortlet provider on host ABC

Timeout

200 seconds

Timeout Message

OmniPortlet provider on host ABC timed out

Implementation Style

Web

URL

http://<host>:<port>/portalTools/omniPortlet/providers/omniPortlet

If you want the portlet content to be cached, then specify the Web Cache URL name and port number to point to the Oracle Web Cache instance. For example:

http://<cache_instance_name>:<cache_port>/portalTools/omniPortlet/providers/omniPortlet

The user has the same identity in the Web providers application as in the single sign-on identity

Select this option.

Select User to send user-specific information to the provider

Select this option.

Login Frequency

Never

Require Proxy

No (if no proxy is required to contact the Provider Adapter)

5. Click Finish.

You can now use the OmniPortlet provider to add portlets to a portal page. The OmniPortlet provider is registered, by default, under the Portlet Staging Area folder in the Portlet Repository.

E.2.4 Configuring the OmniPortlet Provider to Access Other Relational Databases Using DataDirect JDBC Drivers

The OmniPortlet SQL data source is preconfigured to access Oracle Databases using the Oracle JDBC driver, and ODBC data sources using the JDBC-ODBC driver from Sun Microsystems. Perform this step if you want to access other relational databases with OmniPortlet using the DataDirect JDBC drivers, which are the preferred drivers.

You can configure the OmniPortlet SQL data source to access other relational databases by using DataDirect JDBC drivers. To do this, perform the following steps:

- Installing DataDirect JDBC Drivers

- Registering DataDirect Drivers in OmniPortlet

See Also:

For a list of supported databases, Certification Matrix for Oracle Fusion Middleware and DataDirect JDBC available at

http://www.oracle.com/technology/tech/java/

E.2.4.1 Installing DataDirect JDBC Drivers

DataDirect JDBC drivers are packaged in a single ZIP file containing the different drivers used to access supported databases. Download the ZIP file from the following location:

http://www.oracle.com/technology/software/products/ias/htdocs/utilsoft.html

To install DataDirect JDBC drivers, perform the following steps:

1. Unzip the contents of the ZIP file into a temporary directory, for example /temp/datadirect.

2. Create the ORACLE_HOME/portal/applib directory if it does not already exist.

3. From the /temp/datadirect/lib directory, copy the DataDirect JDBC drivers to the ORACLE_INSTANCE>/applib directory.

4. Check the configuration of the WLS_PORTAL instance to ensure that the DataDirect libraries are loaded. To do this, perform the following steps:

1. Open the DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portal\1qz1z6\APP-INF\classes\META-INF\application.xml file. This file is used to configure all applications in this instance.

2. Add the XML entry, <library path="../applib"/>, to the file if it does not already exist.

E.2.4.2 Registering DataDirect Drivers in OmniPortlet

OmniPortlet is implemented as a Web provider and all the configuration properties are stored in the provider.xml file. To use DataDirect JDBC drivers with OmniPortlet, you must register these drivers in the provider.xml file.

To register the new DataDirect JDBC drivers, perform the following steps:

1. Back up the file, DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\1pwj8k\war\WEB-INF\providers\omniPortlet\provider.xml, and then open the file.

2. Add the drivers that you want to use for the SQL data source configuration entry. To do this, perform the following:

1. Search for the XML tag, driverInfo.

2. Add a new entry after the last driverInfo tag.

Following is an example showing a Microsoft SQL Server entry:

- For OmniPortlet version 9.0.4.1 or later:

<!-- registration of DataDirect Connect for JDBC SQL Server driver -->
<driverInfo class="oracle.webdb.reformlet.data.jdbc.JDBCDriverInfo">
<name>Microsoft SQL Server</name>
<sourceDataBase>other</sourceDataBase>
<subProtocol>sqlserver</subProtocol>
<connectString>mainProtocol:subProtocol://databaseName</connectString>
<driverClassName>com.oracle.ias.jdbc.sqlserver.SQLServerDriver
</driverClassName>
<dataSourceClassName>com.oracle.ias.jdbcx.sqlserver.SQLServerDataSource
</dataSourceClassName>
<connHandlerClass>oracle.webdb.reformlet.data.jdbc.JDBCConnectionHandler
</connHandlerClass>
<connPoolSize>5</connPoolSize>
<loginTimeOut>30</loginTimeOut>
</driverInfo>

- For OmniPortlet versions before 9.0.4.1:

<!-- registration of DataDirect Connect for JDBC SQL Server driver -->
<driverInfo class="oracle.webdb.reformlet.data.jdbc.JDBCDriverInfo">
<name>Microsoft SQL Server</name>
<sourceDataBase>other</sourceDataBase>
<subProtocol>sqlserver</subProtocol>
<connectString>mainProtocol:subProtocol://databaseName</connectString>
<driverClassName>com.oracle.ias.jdbc.sqlserver.SQLServerDriver
</driverClassName>
<connHandlerClass>
oracle.webdb.reformlet.data.jdbc.JDBCODBCConnectionHandler
</connHandlerClass>
<connPoolSize>5</connPoolSize>
<loginTimeOut>30</loginTimeOut>
</driverInfo>

Table E-6 describes the parameters in the driverInfo property.

Table E-6 Parameters in the driverInfo Property

Parameter

Description

name

Name of the database you want to use. This name will be used on the Source tab of the OmniPortlet wizard.

sourceDataBase

Internal value. Set the value to other.

subProtocol

JDBC subprotocol name used by OmniPortlet to create the connection string, for example sqlserver, sybase, or db2.To get the list of subprotocol names, refer to the DataDirect JDBC driver documentation using the links provided at the end of this section.

connectString

Description of the connect string format. For DataDirect drivers, the format is: mainProtocol:subProtocol://databaseName

driverClassName

Name of the driver class. To get the different values, refer to the DataDirect JDBC driver documentation using the links provided at the end of this section.

dataSourceClassName

Name of the data source class that implements connection pooling. This parameter is only available in OmniPortlet version 9.0.4.1 or later. Refer to Table E-7 for the right data source class name for your driver.

connHandlerClass

Class used by OmniPortlet to manage the driver and connection pooling. The value is either of the following:

- For OmniPortlet version 9.0.4.1 or later:
oracle.webdb.reformlet.data.jdbc.JDBCConnectionHandler

- For OmniPortlet versions before 9.0.4.1:
oracle.webdb.reformlet.data.jdbc.JDBCODBCConnectionHandler

connPoolSize

Minimum number of connections that are opened by the connection pool.

loginTimeOut

Maximum time, in seconds, that this data source will wait while attempting to connect to a database.

Table E-7 lists the values for the driverClassName and dataSourceClassName properties for specific DataDirect JDBC drivers.

Table E-7 Parameters and Values for driverClassName and dataSourceClassName

DataDirect Drivers Supported

Properties

Microsoft SQL Server

- Parameter: driverClassName
Value: com.oracle.ias.jdbc.sqlserver.SQLServerDriver

- Parameter: dataSourceClassName
Value: com.oracle.ias.jdbcx.sqlserver.SQLServerDataSource

Sybase

- Parameter: driverClassName
Value: com.oracle.ias.jdbc.sybase.SybaseDriver

- Parameter: dataSourceClassName
Value: com.oracle.ias.jdbcx.sybase.SybaseDataSource

DB2

- Parameter: driverClassName
Value: com.oracle.ias.jdbc.db2.DB2Driver

- Parameter: dataSourceClassName
Value: com.oracle.ias.jdbcx.db2.DB2DataSource

Informix

- Parameter: driverClassName
Value: com.oracle.ias.jdbc.informix.InformixDriver

- Parameter: dataSourceClassName
Value: com.oracle.ias.jdbcx.informix.InformixDataSource

3. Save the provider.xml file.

4. Stop and start the Oracle Fusion Middleware instance.

Note:

If you are using OmniPortlet in a multiple nodes configuration, for example, in a clustering or load-balancing environment, then you must manually copy the provider.xml file on each node.

See Also:

For more information on DataDirect JDBC drivers, refer to the following documentation:

- The white paper titled "How to Use DataDirect JDBC Drivers with OmniPortlet" on the Portlet Development page on Portal Center at
http://www.oracle.com/technology/products/ias/portal/portlet_development_10g1014.html

- Certification Matrix for Oracle Fusion Middleware and DataDirect JDBC available at
http://www.oracle.com/technology/tech/java/

- How to use DataDirect JDBC drivers in OmniPortlet in
Oracle Fusion Middleware Developer's Guide for Oracle Portal

Troubleshooting Information

If you encounter errors or problems when configuring or using the OmniPortlet provider, refer to Appendix G, "Troubleshooting Oracle Portal" for troubleshooting information.

F Setting Up and Maintaining a Virtual Private Portal

This appendix walks you through the steps for setting up and maintaining a virtual private portal (VPP). It works through a case study to demonstrate the various tasks involved in setting up and maintaining a virtual private portal (hosted portal).

The following topics are covered in this appendix:

- Overview of Hosting

- Overview of Steps to Perform for Virtual Private Portals

- Enabling Hosting on an Out-of-the-Box Portal

- ASP Users And Groups

- Adding Subscribers

- Advanced Operations on a Virtual Private Portal

- Restrictions

- Parameters for the Scripts

F.1 Overview of Hosting

Before reviewing the tasks, let us look at why hosting features are beneficial and what some of the known limitations are.

F.1.1 Why Use Hosting?

Consider an Application Service Provider (ASP), Acme, that wants to provide portal services for its customers. Acme wants to give its customers the flexibility to build and customize cost-effective and secure portals. They want customers to create and manage their own users, information, and portal pages securely.

Dedicated portal or database instances for each customer would provide the security they require. Traditionally, implementing fully isolated portal environments for multiple organizations within a company required a dedicated database instance for each organization. This proved expensive in terms of hardware and manpower resources, especially when the number of organizations was large. Manpower and hardware costs fast increased as their customer base grew. A single shared instance is obviously more manageable, but will not provide the level of isolation required to host multiple organizations securely.

A single instance is cheaper and easier to manage, but a traditional portal solution requires complex security rules to be written into the application. What Acme needs is the best of both worlds. VPP provides a platform for ASPs a more manageable way for large Enterprise IT departments to host departmental intranet or extranet portal sites. Oracle Portal introduces a more cost-effective and manageable solution for hosting multiple organizations and provides the benefits of a shared instance model with complete security. When using VPP you are required to add subscribers. A Subscriber is a company that signs up with an ASP (Application Service Provider) and receives a stripe on a hosted Oracle Portal.

F.1.2 Known Limitations

Although a shared instance model has many benefits, there are several things to consider before implementing a VPP environment.

Hosted technology will completely isolate each subscriber or identity realm. The VPP will prompt each user to enter their company ID and name, or set a particular context before portal retrieves any content. The scope of the content and data is limited to the subscriber's context. The portal is secured at the subscriber level and does not allow sharing of any data between one subscriber and another. Sharing of data is not allowed for security reasons. For example, VPP should not be used if Company A and Company B need to share documents.

Making repetitive changes to all subscribers is also more complex. From an administrative perspective, user interface manipulation of the portal must be done for each subscriber.

Example F-1 Scenario 1 - Administering Many Subscribers

Company A, Company B, and Company C have identical portal pages 1, 2, and 3. When an administrator logs in to Company A to change the layout of page 1, it only affects that particular subscriber. To change page 1 on Company B, the administrator for Company B would need to perform the same changes using the portal user interface. Logging in to each subscriber is easy, as long as the number of subscribers is small. When administering lots of subscribers, the best way to manage many portal sites is to update the pages by using portal APIs, or through an automated testing tool to make the changes on each site. This makes managing a large number of subscribers very complex.

Example F-2 Scenario 2 - Upgrading

Another area of consideration is upgrading. When performing portal repository upgrades, every subscriber's data must be upgraded. If Acme hosts 1000 subscribers, the portal repository upgrade must go through every subscriber's data before successful completion.

Assume that an average single repository upgrade takes 10 minutes. As it is not possible to split the upgrade process on a single instance, VPP portal repository upgrade will loop through all existing subscribers. So in this example, it would take 10 minutes for a single upgrade multiplied by the number of subscribers: 10 times 1000 will be 10000 minutes. This has huge downtime implications.

Therefore, small manageable deployments of VPP with about 50 subscribers for each instance is recommended. In cases where you must exceed the recommended maximum number, consider deploying multiple VPP instances. To choose a reasonable set of downtime windows to apply changes and upgrades, it is also recommended that you segment on a time zone basis. You can configure multiple portal repositories that could be upgraded individually. So, you can upgrade 50 subscribers on an instance without affecting all the 1000 subscribers at the same time.

Note:

For clarity, the terms Subscribers and Identity Realm are used interchangeably in this document.

F.2 Overview of Steps to Perform for Virtual Private Portals

The following subsections outline the tasks involved in setting up and managing your hosted installation.

- Enabling Hosting

- Setting Up Users and Groups

- Adding Subscribers

- Removing Subscribers

- Advanced Features

- Pre-Installation Checklist

- Using Oracle Directory Manager

F.2.1 Enabling Hosting

- Enable hosting on Oracle Portal and the OracleAS Single Sign-On (SSO) server.

- Create a basic structure on Oracle Internet Directory for ASP user/group support.

F.2.2 Setting Up Users and Groups

- Set up the virtual private portal with a support and administration infrastructure and users. The ASP uses these to administer the virtual private portal on behalf of their customers.

F.2.3 Adding Subscribers

- Create a new subscriber stripe in the Oracle Portal and SSO schemas. This step includes copying objects like page groups, pages, portlet and providers information so that the default environment and pages can be pre-defined.

- Create a new Oracle Internet Directory subscriber tree, and establish required portal entries in Oracle Internet Directory (for example, seeded groups, users, and privileges).

- Copy ASP groups/users for the new subscriber in Oracle Internet Directory (for example, creating mirror entries, assigning privileges, and so on).

F.2.4 Removing Subscribers

- Remove a subscriber's data in Oracle Portal and SSO schema.

- Delete the whole subscriber sub tree in Oracle Internet Directory.

F.2.5 Advanced Features

- WebDAV enables you to use a URL address as a transparent read and write medium where content can be checked out, edited, and checked in.

- Secure Enterprise Search provides uniform search-and-locate capabilities over multiple repositories, such as Oracle Databases, IMAP servers, Web pages, disk files, and portal page groups.

F.2.6 Pre-Installation Checklist

Before running the scripts to enable virtual private portals, first gather the information to run them. Table F-1 lists and describes the parameters.

Table F-1 Parameters

Parameters

Description

-pc

Database connect string for portal schema, in format of <host>:<port>:<sid>, where <host> is a fully qualified domain name. This is a mandatory parameter.

-ps

Oracle Portal schema name. By default, it is portal.

-sc

Database connect string for SSO schema, in format of <host>:<port>:<sid>, where <host> is a fully qualified domain name. By default, it is the value of -pc parameter.

-ss

SSO schema name. By default, it is the orasso.

-h

Oracle Internet Directory server host name. This is a mandatory parameter.

-p

Oracle Internet Directory server port number. By default, it is 389.

-d

Oracle Internet Directory bind DN. By default, it is cn=orcladmin. This DN must have Oracle Internet Directory administrative privilege, for example, privilege to create new subscribers.

F.2.7 Using Oracle Directory Manager

To begin the process, use the Oracle Directory Manager (ODM). The ODM is a GUI tool to help you administer Oracle Internet Directory. To obtain the passwords for portal and orasso users:

1. Launch the Oracle Directory Manager.

- In the first field, provide the Oracle Internet Directory bind DN (parameter -d). By default, it is cn=orcladmin. This DN must have Oracle Internet Directory admin privilege, for example, privilege to create new subscribers.

- In the second field, provide the password for Oracle Internet Directory bind DN (parameter -w). By default, it is welcome1.

- In the third field, select your Oracle Internet Directory instance. If you have not defined your Oracle Internet Directory instance, click the icon to right of the field and give the server host name (parameter -h) and port number (parameter -p) that Oracle Internet Directory is running on. By default, the port is 389 or 4032.

2. Once you have logged into Oracle Internet Directory, navigate through the menu tree. Entry Management > cn=OracleContext > cn=Products > cn=IAS.
Cn=IAS Infrastructure Databases > orclReferenceName=name of Oracle Internet Directory database.

3. Continue to navigate the tree.

4. Click the orasso user name.

5. In the right pane, find the section called orclpasswordattribute. This is the password for the orasso user (parameter –sw).

6. Click the portal user name.

7. In the right pane, there is a section called orclpasswordattribute. This is the password for the portal user (parameter –pw).

F.3 Enabling Hosting on an Out-of-the-Box Portal

To begin an out-of-the-box Oracle Portal installation, enable hosting on the portal. A C-shell script is provided, that:

- Enables hosting on Oracle Portal and the OracleAS Single Sign-On server.

- Creates a basic structure on Oracle Internet Directory for ASP user/group support

To illustrate how the script works, here is what the Oracle Internet Directory tree looks like before running the script:

Figure F-1 Oracle Internet Directory Tree Before Running the Script

To run the script, type the following at the UNIX command line:

cd ORACLE_HOME/portal/admin/plsql/wwhost
./enblhstg.csh -pc portaldb.acme.com:1521:portaldb -ps portal -sc portaldb.acme.com:1521:portaldb -ss orasso -h oid.acme.com -p 389 -d "cn=orcladmin"

Stop and start the Single Sign-On middle tier.

Refer to Section F.8, "Parameters for the Scripts" for a detailed explanation of parameters.

After running the script, the Oracle Internet Directory tree looks like Figure F-2:

Figure F-2 Oracle Internet Directory Tree After Running the Script

Now the portal instance is hosting enabled. If you go to the portal login screen, you see three input fields (Username, Password, and Company). To login as the default subscriber, you can type acme in the Company field, or leave it blank.

The default subscriber is reserved for the ASP for administrative purposes. For each of its customers, a new subscriber must be created before people can login and use it.

F.4 ASP Users And Groups

Because Acme is the ASP it needs to have a support and administration infrastructure that administers the virtual private portal on behalf of the customers. The virtual private portal provides support for ASP users and groups such that administration of multiple subscriber portals is simple.

These ASP users and groups can have different levels of administrative access into the virtual private portals of the subscribers (customers) of Acme. ASP users can be split into groups according to the privileges they need. For example, Alice needs privileges to manage user accounts; Bob and Joe need privileges to manage page contents. These privilege groups are ASP groups.

These ASP users and groups allow an ASP user to log in to multiple subscribers using a single set of credentials (user name and password), and have the same set of pre-defined privileges in all subscribers. This is achieved by creating mirror entries of ASP users and groups across all subscribers. The user and group entries can then be kept in sync through pre-supplied scripts (see ASP Sync Script section). Note: The synchronization (script or automatic) only synchronizes the users and groups, not the portal privileges.

The following sections show how to set up the virtual private portal with ASP user/group support for Acme, and some other tasks you may want to perform:

- Setting Up ASP Users and Groups

- Restrictions

F.4.1 Setting Up ASP Users and Groups

The master entry for ASP Users and groups resides under the default subscriber. Because these users and groups will have additional access (not all users in the default subscriber can log in to all subscribers) you must set up ASP users/groups explicitly.

When you enabled hosting on your portal, the script creates a group called ASP under the default subscriber's Oracle Internet Directory sub-tree, which is a placeholder for ASP user/group support. You need this to set up ASP users/groups. From now on, this placeholder group will be referred to as the ASP group. Let's look at some examples where Acme could use ASP users and groups:

- Alice needs to manage user accounts for all subscribers.

- Bob and Joe need to manage pages for all subscribers.

- Tom needs to log in to all subscribers but only have normal authenticated user privileges.

To accomplish this, do the following:

- Create users asp_alice, asp_bob, asp_joe and asp_tom in default subscriber.

- Create group asp_UserAdm in default subscriber and assign it privileges to manage user accounts; and also create group asp_PageAdm in default subscriber and assign it privileges to manage pages.

- Add asp_alice as member of asp_UserAdm group.

- Add asp_bob and asp_joe as members of asp_PageAdm group.

- Add asp_UserAdm and asp_PageAdm as members of the ASP group.

- Add user asp_tom as member of the ASP group.

Now you have set up ASP users and groups. The Oracle Internet Directory tree looks like Figure F-3:

Figure F-3 Oracle Internet Directory Tree with Users and Groups

More precisely, ASP users/groups are defined as follows:

- ASP groups are either the ASP group itself or its direct group members.

- ASP users that are a direct user member of any ASP group.

Figure F-4 Membership Structure of Acme Users and Groups

By default, the portal bootstrap users are members of the ASP group, which means that they are by default ASP users. For more information on portal bootstrap users portal, portal_admin, and FMWADMIN, see the Oracle Fusion Middleware User's Guide for Oracle Portal.

When you add a new subscriber, the portal Add Subscriber script automatically creates mirror entries for those ASP users/groups in the new subscriber. Then those users can login and have the corresponding privileges.

F.4.2 Restrictions

There are some restrictions on ASP users/groups set up:

- ASP users and groups can be no more than two levels deep. That is, groups that are not direct members of the ASP group or users that are not direct members of any ASP groups are ignored during mirror entry creation.

- Oracle Internet Directory mandates that user names must be unique (case insensitive) within each subscriber, including those of ASP users. For example, you cannot have two users in subscriber CompanyA called Bob or bob. Because ASP users have mirror entries in every subscriber, use special names for ASP users to prevent user name collisions. This is reflected throughout this document with names such as asp_bob, asp_joe, and the like.

- For similar reasons, use special names for ASP groups, for example, asp_PageAdmin, asp_UserAdmin, and the like. Because hosting scripts handle ASP groups dynamically, do not make a portal seeded group into an ASP group. If you need an ASP group with similar privileges, create a new group and make it a member of the seeded group.

- Manage nondefault subscribers' ASP users and groups only with hosting scripts. Do not manually modify those users, or groups, or both.

- The ASP group is only a placeholder for all ASP users and groups, and is not designed for privilege purposes. Do not assign privileges to the ASP group. Those privileges are not propagated to other subscribers.

F.5 Adding Subscribers

Acme has now set up its ASP users and groups and has enabled the portal for hosting. The next step is to add the customers as subscribers of the virtual private portal. For each of Acme's customers (CompanyA, CompanyB), you will create a new subscriber in the portal. A C-shell script is provided, that:

- Creates a new stripe in the Oracle Portal and SSO schemas. This step copies objects like page groups, pages, portlet and providers information, and the like.

- Creates a new Oracle Internet Directory subscriber tree and establishes required portal entries in Oracle Internet Directory (for example, seeded groups, users, and privileges).

- Copies ASP groups/users to the new subscriber in Oracle Internet Directory (for example, creating mirror entries, assigning privileges, and so on).

To add subscriber CompanyA, enter the following commands at the UNIX command line:

> cd ORACLE_HOME/portal/admin/plsql/wwhost
>./addsub.csh -name CompanyA -id 1001 -type all -pc
portaldb.acme.com:1521:portaldb -pp change_on_install -ps portal -sc
portaldb.acme.com:1521:portaldb -sp change_on_install -ss orasso –a
portal.portaldb.portaldb.acme.com -h oid.acme.com -p 389 -d "cn=orcladmin" -rc "cn=OracleContext" -sd acme -tp ORACLE_INSTANCE/ldap/schema/oid/

Refer to Section F.8, "Parameters for the Scripts" for an explanation of parameters.

Check the output, and contact Oracle technical support if there is any error. After running the script, subscriber CompanyA exists in both Oracle Portal and Oracle Internet Directory. The Oracle Internet Directory tree looks like Figure F-5:

Figure F-5 CompanyA in Both Portal and Oracle Internet Directory

Run the same script to create subscriber CompanyB.

Now you have set up a virtual private portal with two subscribers. To try the ASP users, log in to CompanyA as user asp_alice using the same password as when you created it in default subscriber. Alice should have privileges to do user management tasks.

F.6 Advanced Operations on a Virtual Private Portal

Specific topics covered in this section include:

- Managing ASP Users and Groups

- Removing Subscribers

- Using WebDAV in the Virtual Private Portal

- Setting Up Directory Integration Platform for the Virtual Private Portal

- Partially Prepare (Pre-Cook) Subscribers

F.6.1 Managing ASP Users and Groups

After you have set up all the subscribers, there could be several types of changes to the ASP users/groups structure. For example:

- Bob changed his password in default subscriber, and you must synchronize the new password in all other subscribers.

- Joe left Acme and should no longer be able to login as an ASP user.

- The service contract changed and the ASP is no longer responsible for user account problems. So, the asp_UserAdm group is no longer needed.

- When ASP users/groups are changed in the default subscriber, you must use a provided script to synchronize the changes in all other subscribers.

The synchronization script has three options:

- Password Sync

- Delta (Structure Changes) Sync

- Complete Sync

F.6.1.1 Password Sync

If you use password sync, the script updates passwords for all the ASP user's mirror entries using the password in the default subscriber.

For the first example in the preceding text, you can synchronize Bob's new password using the following commands at the UNIX command line:

> cd ORACLE_HOME/portal/admin/plsql/wwhost

>./syncasp.csh -pc portaldb.acme.com:1521:portaldb -ps portal -h oid.acme.com -p 389 -d "cn=orcladmin" -mode pwd -u asp_bob

Alternatively, if you have enabled the Directory Integration Platform, it synchronizes ASP user password changes automatically so that you do not need to run this script.

F.6.1.2 Delta (Structure Changes) Sync

If you use delta sync, the script searches for users/groups that have been changed in the default subscriber and applies the changes to all other subscribers.

For departing employees or service contract changes, you can synchronize the new ASP structure using the following commands at the UNIX command line:

> cd ORACLE_HOME/portal/admin/plsql/wwhost

>./syncasp.csh -pc portaldb.acme.com:1521:portaldb -ps portal -h oid.acme.com -p 389 -d "cn=orcladmin" -mode dif

Delta sync assumes consistency and integrity of old ASP structures. That is, if the old ASP structure in each subscriber is consistent and correct, then delta sync does the job correctly. Otherwise, you could use the Complete Sync option, which is slower than the delta sync.

F.6.1.3 Complete Sync

The script takes the ASP structure of default subscriber and overwrites the structures of all other subscribers. If delta sync failed to synchronize the ASP structure, consider using this option.

For departing employees or service contract changes, you can synchronize the new ASP structure using the following commands at the UNIX command line:

> cd ORACLE_HOME/portal/admin/plsql/wwhost

>./syncasp.csh -pc portaldb.acme.com:1521:portaldb -ps portal -h oid.acme.com -p 389 -d "cn=orcladmin" -mode all

Complete sync is slower than delta sync, so use only when necessary.

F.6.2 Removing Subscribers

If a subscriber in a portal is no longer needed, or errors occurred during the subscriber creation, you can permanently remove a subscriber using a provided script. The script does the following:

- Removes the subscriber's data in Oracle Portal and SSO schema.

- Deletes the whole subscriber sub tree in Oracle Internet Directory.

For example, to remove a subscriber called nowhere, type the following command at the UNIX command line. However, once you remove a subscriber, there is no way to restore it except from any backups taken of the Oracle Database on which the virtual private portal instance has been installed.

> cd ORACLE_INSTANCE/portal/admin/plsql/wwhost

>./rmsub.csh -name nowhere -pc portaldb.acme.com:1521:portaldb -pp change_on_
install -ps portal -sc portaldb.acme.com:1521:portaldb -sp change_on_install -ss
orasso –a portal.portaldb.portaldb.acme.com -h oid.acme.com -p 389 -d
"cn=orcladmin" -cs 1000

See Section F.8, "Parameters for the Scripts" for more information about the parameters.

F.6.3 Using WebDAV in the Virtual Private Portal

WebDAV is a protocol that supports distributed authoring and versioning. With WebDAV the Internet becomes a transparent read and write medium where content can be checked out, edited, and checked in to a URL address. For details about how WebDAV works with Oracle Portal and how to set up WebDAV, see the Oracle Fusion Middleware User's Guide for Oracle Portal.

Setting up WebDAV in a virtual private portal is the same as setting up WebDAV in an out-of-the-box portal.

Connecting to WebDAV in a virtual private portal is similar to that in an out-of-the-box portal. The only difference is that, when connecting to WebDAV in a virtual private portal, you use:

"<username>@<subscriber_name>" as the username, instead of just ...
"<username>" as required in an out-of-the-box portal.

For example, to connect to WebDAV using user Joe in subscriber CompanyA, use joe@CompanyA as the user name and Joe's password as the password.

When different subscribers use the same URL for WebDAV connection, the client side operating system may cache the connection. For example, if you connected to WebDAV using user portal_admin@acme on a Windows 2000 PC, you may not be able to connect to WebDAV in subscriber CompanyA as user joe@CompanyA because of the operating system cache. For details about how to clear an operating system cache and stored user name and password, see your operating system documents.

F.6.4 Setting Up Directory Integration Platform for the Virtual Private Portal

The Directory Integration Platform is a comprehensive framework that performs synchronization between various directories and directory-enabled applications. One of the services it provides is Provisioning Integration, which can send notifications about directory events to Directory Enabled Applications.

See Also:

Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory

In an out-of-the-box Oracle Portal installation, the Directory Integration Platform is enabled. If you have disabled Directory Integration Platform for a virtual private portal, do the following to re-enable Directory Integration Platform:

1. Run the provided script that enables Directory Integration Platform on existing subscribers.
For example, for UNIX:

enbldip.csh -pc portaldb.acme.com:1521:portaldb -pp change_on_install -ps portal -h oid.acme.com -p 389 -d "cn=orcladmin" -enable

2. Uncomment the calls to oidprovtool in the addsub.csh and rmsub.csh, so that those two scripts take care of Directory Integration Platform profile entries when you add/remove subscribers.
To do this:

1. Open the two files in your editor.

2. Search for lines with the oidprovtool string.

3. Uncomment those lines.

Also, you can do the following to disable Directory Integration Platform on all subscribers in your portal:

1. Run the provided script in at the UNIX command line as follows:

enbldip.csh -pc portaldb.acme.com:1521:portaldb -pp change_on_install -ps portal -h oid.acme.com -p 389 -d "cn=fmwadmin" -disable

2. Comment out the calls to oidprovtool in addsub.csh and rmsub.csh, so that those two scripts ignore Directory Integration Platform profile entries when you add or remove subscribers.
To do this:

1. Open the two files in your editor.

2. Search for lines with oidprovtool.

3. Comment these lines out.

F.6.5 Partially Prepare (Pre-Cook) Subscribers

Creating a new subscriber by running the addsub.csh script can take a few minutes based on how the computer where Oracle Portal, Oracle Internet Directory, and OracleAS Single Sign-On are installed is configured. Along with the data operations that occur when a new subscriber is created, most ASPs have some administrative provisioning and subscriber-specific customizations that they perform when a subscriber is created.

To expedite subscriber registration, the virtual private portal allows ASPs to partially prepare the subscribers. This is done so that when an ASP is registered, the subscriber need only perform post registration customizations and directly assign a virtual private portal stripe to that subscriber. The virtual private portal provides a database-only mode in the addsub.csh script where the data copying is performed on the portal and SSO databases. When the ASP is ready to assign a stripe to a subscriber, it can complete the subscriber creation by running the addsub.csh script using the LDAP mode.

To partially prepare a subscriber in portal and SSO databases, use the -type parameter in addsub.csh. For example, type the following at the UNIX command line:

> cd ORACLE_HOME/portal/admin/plsql/wwhost
>./addsub.csh -name TEMP_COMPANY -id 1003 -type db -pc
portaldb.acme.com:1521:portaldb -pp change_on_install -ps portal -sc
portaldb.acme.com:1521:portaldb -sp change_on_install -ss orasso -h
oid.acme.com -p 389 -d "cn=orcladmin" -rc "cn=OracleContext" -sd acme

You can use a temporary name for company name, like (TEMP_COMPANY) as used in the preceding example. Later, when a customer (example, CompanyC) comes, you can run the following command at the UNIX command line:

> cd ORACLE_HOME/portal/admin/plsql/wwhost
>./addsub.csh -name CompanyC -id 1003 -type ldap -pc
portaldb.acme.com:1521:portaldb -pp change_on_install -ps portal -sc
portaldb.acme.com:1521:portaldb -sp change_on_install -ss orasso -a
portal.portaldb.portaldb.acme.com -h oid.acme.com -p 389 -d "cn=orcladmin"
-rc "cn=OracleContext" -sd acme -tp ORACLE_INSTANCE/ldap/schema/oid/

You must use the same subscriber ID when you partially prepare the subscriber, and give the real name of your customer (CompanyC). The new name will replace the old name (TEMP_COMPANY in the preceding example). The script will create an Oracle Internet Directory subscriber tree for CompanyC and synchronize the Oracle Internet Directory settings to portal schema, which takes less time than creating the subscriber from scratch.

You do have to partially prepare (using -type db option) the subscriber before you can use run addsub.csh with -type ldap option.

Oracle Portal Middle-Tier Installation on the Virtual Private Portal

Follow the steps in Chapter 3, "Pre-Installation and Post-Installation Tasks" to run the Oracle Portal middle-tier installation.

The Oracle Portal middle-tier installation can be run against a virtual private portal.

F.7 Restrictions

The following subsections provide summaries of the restrictions on the different virtual private portal scripts and operations:

- Scripts

- ASP Users/Groups Support

- Add Subscriber

- Remove Subscriber

- Upgrade

F.7.1 Scripts

The virtual private portal configuration and provisioning scripts currently only run on a UNIX C-shell environment.

F.7.2 ASP Users/Groups Support

- The top level ASP group must not have any Oracle Internet Directory privileges assigned to it. Privileges are not copies or synchronized across subscribers. Privileges of the sub-groups of the ASP group are synchronized and copied.

- Any modifications to the ASP user and group structure in Oracle Internet Directory that are performed on any other subscriber other than the default subscriber are not preserved when the subscriber synchronization scripts are run.

- Portal seeded groups should not be designated as ASP groups.

F.7.3 Add Subscriber

Names of new subscribers must be unique within Oracle Internet Directory.

F.7.4 Remove Subscriber

This script cannot be used to remove the default subscriber. To do that, use the Portal Dependency Settings Tool, ptlconfig.

F.7.5 Upgrade

When performing an upgrade from Oracle Portal release 9.0.2.x to 9.0.4.x, the Oracle Text indexes need to be re-created. See Section 10.3.4.1, "Creating All Oracle Text Indexes Using ctxcrind.sql" for information on running the ctxcrind.sql script to re-create all the Oracle Text indexes.

F.8 Parameters for the Scripts

Table F-2 through Table F-6 list and describe all the parameters for the scripts provided for administering a virtual private portal. These scripts can be found in the ORACLE_HOME/portal/admin/plsql/wwhost directory.

Note:

To produce a list of the parameters for any of the scripts, run the script in your UNIX shell without any parameters. If you want the output of the scripts to be saved to a log file, type |& tee <log_filename> at the end of the command, replacing <log_filename> with the name of your log file.

Table F-2 enblhstg.csh

Parameter

Description

-pc

Database connect string for Oracle Portal schema, in format of <host>:<port>:<sid>, where <host> is a fully qualified domain name. This is a mandatory parameter.

-ps

Oracle Portal schema name. By default, it is portal.

-pw

Oracle Portal schema password (no default).

-sc

Database connect string for SSO schema, in format of <host>:<port>:<sid>, where <host> is a fully qualified domain name. By default, it is the value of -pc parameter.

-ss

SSO schema name. By default, it is the orasso

-sw

SSO schema password (no default).

-h

Oracle Internet Directory server host name. This is a mandatory parameter.

-p

Oracle Internet Directory server port number. By default, it is 389.

-d

Oracle Internet Directory bind DN. By default, it is cn=fmwadmin. This DN should have Oracle Internet Directory admin privilege, for example, privilege to create new subscribers.

-w

Password for Oracle Internet Directory bind DN (no default).

Table F-3 addsub.csh

Parameter

Description

-name

Oracle Internet Directory nickname of the new subscriber. This is a mandatory parameter. This name must not have been used by any other subscriber

-id

Internal ID for the new subscriber, which is used within Oracle Portal and OracleAS Single Sign-On. This is a mandatory parameter. It should not have been used by any other subscriber in Oracle Portal or OracleAS Single Sign-On schema.

-type

Valid values are:

- db – only copy seed data in Oracle Portal and OracleAS Single Sign-On schemas.

- ldap – create Oracle Internet Directory entries for Oracle Portal and OracleAS Single Sign-On. You can run the script only using -type ldap option after you add temporary subscriber using -type db option.

- all – default value, do both db and ldap types jobs.

-pc

Database connect string for Oracle Portal schema, in format of <host>:<port>:<sid>, where <host> is a fully qualified domain name. This is a mandatory parameter.

-pp

SYS user password of portal instance. By default, change_on_install.

-ps

Oracle Portal schema name. By default, portal.

-pw

Oracle Portal schema password (no default).

-sc

Database connect string for SSO schema, in format of <host>:<port>:<sid>, where <host> is a fully qualified domain name. By default, it is the value of -pc parameter.

-sp

SYS user password of SSO instance.

-ss

SSO schema name. By default, it is orasso.

-sw

SSO schema password. By default is the value of -ss parameter.

-a

Portal Application name. By default, it is <portal_schema>.<sid>.<dbhost>

-h

Oracle Internet Directory server host name. This is a mandatory parameter.

-p

Oracle Internet Directory server port number. By default, it is 389.

-d

Oracle Internet Directory bind DN. By default, it is cn=fmwadmin. This DN must have Oracle Internet Directory admin privilege, for example, privilege to create new subscribers.

-w

Password for Oracle Internet Directory bind DN (no default).

-rc

Oracle Internet Directory root context DN. By default, it is cn=OracleContext

-sd

Oracle Internet Directory nickname of the template subscriber. By default, it is the nickname of the portal default subscriber.

-tp

File system path of template files for Oracle Internet Directory subscriber creation. By default, it is ORACLE_INSTANCE/ldap/schema/oid/.

Table F-4 rmsub.csh

Parameter

Description

-name

Oracle Internet Directory nickname of an existing nondefault subscriber to be removed. This is a mandatory parameter. Default subscriber cannot be removed using this script, use the ptlconfig tool instead.

-pc

Database connect string for Oracle Portal schema, in format of <host>:<port>:<sid>, where <host> is a fully qualified domain name. This is a mandatory parameter.

-pp

SYS user password of portal instance (no default).

-ps

Oracle Portal schema name. By default, it is portal.

-sc

Database connect string for SSO schema, in format of <host>:<port>:<sid>, where <host> is a fully qualified domain name. By default, it is the value of -pc parameter.

-sp

SYS user password of OracleAS Single Sign-On instance. By default, if OracleAS Single Sign-On and Oracle Portal are on different database instances, it is change_on_install; if OracleAS Single Sign-On and Oracle Portal use the same database instance, it is the value of -pp parameter.

-ss

SSO schema name. By default, it is orasso.

-a

Portal Application name. By default, it is <portal_schema>.<sid>.<dbhost>.

-h

Oracle Internet Directory server host name. This is a mandatory parameter.

-p

Oracle Internet Directory server port number. By default, it is 389.

-d

Oracle Internet Directory bind DN. By default, it is cn=fmwadmin. This DN must have Oracle Internet Directory admin privilege, for example, privilege to create new subscribers.

-w

Password for Oracle Internet Directory bind DN (no default).

-cs

Commit size, specifying the number of rows that can be deleted before a mandatory database commit. By default, it is 1000.

Table F-5 syncasp.csh

Parameter

Description

-mode

This is a mandatory parameter. Valid values are:

- pwd – Synchronize password for one ASP user.

- dif – Synchronize ASP structure changes since last synchronization.

- all – Do a complete synchronization of ASP structure.

-pc

Database connect string for Oracle Portal schema, in format of <host>:<port>:<sid>, where <host> is a fully qualified domain name. This is a mandatory parameter.

-ps

Oracle Portal schema name. By default, portal.

-pw

Oracle Portal schema password (no deafault).

-h

Oracle Internet Directory server host name. This is a mandatory parameter.

-p

Oracle Internet Directory server port number. By default, it is 389.

-d

Oracle Internet Directory bind DN. By default, it is cn=fmwadmin. This DN must have Oracle Internet Directory admin privilege, for example, privilege to create new subscribers.

-w

Password for Oracle Internet Directory bind DN (no default).

-u

This parameter is used with the password sync mode (pwd) to specify the user name whose password must be synchronized.

-l

Log file name.

Table F-6 embldip.csh

Parameter

Description

-pc

Database connect string for Oracle Portal schema, in the format of <host>:<port>:<sid>, where <host> is a fully qualified domain name. This is a mandatory parameter.

-pp

SYS user password of portal instance (no default).

-ps

Oracle Portal schema name. By default, it is portal.

-h

Oracle Internet Directory server host name. This is a mandatory parameter.

-p

Oracle Internet Directory server port number. By default, it is 389.

-d

Oracle Internet Directory bind DN. By default, it is cn=fmwadmin. This DN must have Oracle Internet Directory admin privilege, for example, privilege to create new subscribers.

-w

Password for Oracle Internet Directory bind DN (no default).

-enable

Enables Directory Integration Platform on all subscribers in portal. This parameter precedes the -disable parameter.

-disable

Disables Directory Integration Platform on all subscribers in portal.

G Troubleshooting Oracle Portal

This appendix describes common problems that you may encounter when using Oracle Portal and explains how to solve them. It also gives detailed instructions on how to diagnose Oracle Portal problems. It contains the following topics:

- Problems and Solutions

- Diagnosing Oracle Portal Problems

- Need More Help?

G.1 Problems and Solutions

This section describes common problems and solutions. It contains the following topics:

- Unable to Access Oracle Portal

- Unable to Log In to Oracle Portal

- Problems Creating Category or Perspective Pages

- Problems with Network Address Translation (NAT) Setup

- User and Group Information in Oracle Portal and Oracle Internet Directory Does Not Match

- Problems with Oracle Portal Performance

- Error When Creating Web Folders

- Create New Users and Create New Groups Portlets Do Not Appear

- ORA-2000x Errors in the error_log File

- Remote Web Providers Time Out in a Dynamic DNS Environment

- Problems Related to Memory-Intense Operations

- Unable to Create Oracle Text Indexes

- Problems with MultiLanguage Support for Help

- Stale Style-Sheet Data Is Displayed on Portal Pages

- Stale Content Is Displayed on Portal Pages

- Images Are Not Displayed on Portal Pages

- Unhandled Exception Errors

- Problems in Configuring the OmniPortlet Provider

- Problems in Configuring Oracle Web Cache for the OmniPortlet Provider

- Problems in Accessing Oracle Portal from a Mobile Device

- Error During Export and Import After Upgrading from Oracle Portal 3.0.9 or 9.0.4

- Errors Displayed When the Oracle Portal Language is Traditional Chinese

- Uploaded Content Is Not Returned in Search

G.1.1 Unable to Access Oracle Portal

For example, pages are not displayed, you get an "HTTP 503 Service Unavailable" error, or an "An error occurred while processing the request. Try refreshing your browser. If the problem persists contact the site administrator" error when you try to access Oracle Portal.

Oracle Portal requires Oracle Fusion Middleware components, such as Oracle HTTP Server, Oracle Web Cache, Portal Services, Oracle Metadata Repository, and WLS_PORTAL to be available (up) and running. One or more of these components may be unavailable (down).

Problem 1

Oracle HTTP Server is down.

Solution 1

Display the Oracle Portal home page in Fusion Middleware Control. See Section 8.2, "Using Fusion Middleware Control to Monitor and Administer Oracle Portal" for more information.

Check if the Oracle HTTP Server is up. The Oracle HTTP Server status is displayed in the Fusion Middleware pane on the Oracle Fusion Middleware Control home page.

Figure G-1 HTTP Server Status

- If the status is 'Up', then continue to the next step.

- If the status is 'Down', then start Oracle HTTP Server from Fusion Middleware Control.

To start Oracle HTTP Server using Fusion Middleware Control, do the following:

1. From the Navigation pane, expand Web Tier, and select the Oracle HTTP Server (by default it is ohs1).

2. Right-click ohs1, and select Control > Start Up to start the Oracle HTTP Server.

If Oracle HTTP Server starts successfully, check whether your portal is accessible.

If Oracle HTTP Server fails to start, use Log Viewer to check the Oracle HTTP Server error log files and try to determine the problem. See Section G.2.4, "Using Fusion Middleware Control Log Viewer" for more information.

If you are not using Log Viewer, then check the relevant error log files in the ORACLE_INSTANCE\diagnostics\logs\OHS\ohs1\access_log and ORACLE_INSTANCE\diagnostics\logs\OHS\ohs1\console~OHS~1.log directories.

See Also:

Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server

Problem 2

Oracle Web Cache is down.

Solution 2

Navigate to the Fusion Middleware Control, of the Oracle Portal that is running the Oracle Web Cache process. For details, refer to the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

Check if Oracle Web Cache is up. The Oracle Web Cache status is displayed in the Fusion Middleware System Components table.

- If the status is 'Up', then continue to the next step.

- If the status is 'Down', then start Oracle Web Cache using Fusion Middleware Control.

To access Oracle Web Cache monitoring and administration pages in Fusion Middleware Control, click Web Cache in the Fusion Middleware System Components table.

If Oracle Web Cache starts successfully, check whether your portal is now accessible.

If Oracle Web Cache fails to start, then investigate the Oracle Web Cache error log files and try to determine the problem. See Section G.2.4, "Using Fusion Middleware Control Log Viewer" for more information.

If you are not using Log Viewer, then check the relevant error log files in the ORACLE_INSTANCE\diagnostics\logs\WebCache\wc1\access_log and ORACLE_INSTANCE\diagnostics\logs\WebCache\wc1\event_log directories.

Problem 3

Oracle Portal is down due to incorrect Portal DAD configuration.

Solution 3

Check the status and configuration of the Oracle Portal DAD. Navigate to the Oracle Portal home page in Fusion Middleware Control. From the Oracle Portal home page, click Settings > Database Access Descriptor. Check the DADs table in the Configure Database Access Descriptor page to see if the DAD configured for your portal is up.

- If the status is 'Up', then continue to the next step.

- If the status is 'Down', then click the name of the DAD in the DADs table and verify that all properties are set correctly. Save any changes and then restart both WLS_PORTAL and Oracle HTTP Server for any change to take effect. See Section 5.6.4, "Configuring a Portal DAD Using Fusion Middleware Control" for information about configuring the DAD from the portal's home page.

Note:

You can verify the database connection details for a DAD using SQL*Plus - in the Oracle home directory associated with the Oracle Fusion Middleware for your portal. The DAD Settings page displays the password in an encrypted form and forces you to reenter the password, to ensure that password validity is not the problem.

Check if your portal is accessible now.

Problem 4

Oracle Metadata Repository is down.

Solution 4

Display the Oracle Portal home page in Oracle Fusion Middleware Control. See Section 8.2, "Using Fusion Middleware Control to Monitor and Administer Oracle Portal" for more information.

Look under the Oracle Metadata Repository Used by Portal section.

- If the status is 'Up', then continue to the next step.

- If the status is 'Down', then start the database.

If the database starts successfully, check whether your portal is accessible now.

Problem 5

The WLS_PORTAL service is down.

Solution 5

Display the domain home page (for your Oracle Portal instance), in Oracle Fusion Middleware Control. See Section 8.1, "Using Oracle Enterprise Manager 11g Fusion Middleware Control" for more information.

The WLS_PORTAL status is displayed in the System Components table.

- If the status is 'Up', then continue to the next step.

- If the status is 'Down', then start WLS_PORTAL using Oracle Fusion Middleware Control.

To access WLS_PORTAL monitoring and administration pages in Oracle Fusion Middleware Control, click WLS_PORTAL in either of the following:

- Parallel Page Engine Services page (available from the Component Status table on the Oracle Portal home page)

- Fusion Middleware System Components table

If WLS_PORTAL starts successfully, check whether your portal is now accessible.

If WLS_PORTAL fails to start, then investigate WLS_PORTAL error log files and try to determine the problem. See Section G.2.4, "Using Fusion Middleware Control Log Viewer" for more information.

Problem 6

SQL* Net listener is down, or misconfigured.

Solution 6

Check that the SQL*Net TNS listener is up and running on the host where the metadata repository is installed. Log in to the computer containing the database, change to the ORACLE_INSTANCE/bin directory if you are currently not in the $PATH directory, and use the following command to determine the status of the TNS listener:

lsnrctl status

If the service is not running, then start it by using the following command:

lsnrctl start

If the service is already up and running, then refer to the Oracle Database Net Services Administrator's Guide in the Oracle Database documentation library, for information on how to troubleshoot Oracle Net Services.

Problem 7

Portal Services is reporting some other error.

Solution 7

Perform the following steps to resolve the problem:

1. Navigate to ORACLE_HOME/opmn/bin and issue the opmctl status command. Ensure that key services show an alive status. If not, scan the files under ORACLE_HOME/opmn/logs for more details.

2. Navigate to ORACLE_INSTANCE/webcache/logs. Scan the event_log file for any pointers to the problem.

G.1.2 Unable to Log In to Oracle Portal

You can access the public home page but are unable to log in. Common symptoms of this problem are the following:

- The login page does not appear after you click Login.

- You get an error after you enter your credentials on the OracleAS Single Sign-On login page.

- You get errors on Oracle Portal pages after you have been authenticated.

Problem 1

You may not be able to log in to Oracle Portal due to problems encountered during the process of logging in to Oracle Portal.

The Oracle Portal login process can be logically broken down into three parts:

- Communication between Oracle Portal and OracleAS Single Sign-On

- Communication between Oracle Portal and Oracle Internet Directory

- Assignment of the Home Page

Solution 1

To help diagnose the cause of this problem, look at the solutions focused on each part of the login process.

Verify Communication Between Oracle Portal and OracleAS Single Sign-On

To understand the first part of the login process, assume that Oracle Portal is accessed at:

http://www.company.com/portal/pls/portal/

When you click Login on the public home page you get redirected to the OracleAS Single Sign-On page. For example, the URL changes to:

http://login.company.com:4443/pls/sso

If you enter the user name and password provided by your administrator and click Login, then OracleAS Single Sign-On sends the user information back to Oracle Portal.

To diagnose the cause of a problem encountered in this part of the login process, perform the following steps:

1. Display the OracleAS Single Sign-On home page in the Oracle Enterprise Manager 11g Fusion Middleware Control.
The OracleAS Single Sign-On home page is available from the home page for the Infrastructure home directory instance.

For details, refer to the section on Interpreting and Using the Home Page on the Standalone Console in the Oracle Application Server Single Sign-On Administrator's Guide.

2. Check if Oracle HTTP Server is Up.
Click HTTP_Server displayed in the Related Links section.

- If the status is 'Up', then continue to the next step.

- If the status is 'Down', then start Oracle HTTP Server using Oracle Fusion Middleware Control.

To access Oracle HTTP Server monitoring and administration pages in Oracle Fusion Middleware Control, click HTTP_Server in either of the following:

- OracleAS Single Sign-On home page

- Fusion Middleware System Components table

If Oracle HTTP Server starts successfully, check whether you can log in now.

If Oracle HTTP Server fails to start, then investigate the Oracle HTTP Server error log files and try to determine the problem. See Section G.2.4, "Using Fusion Middleware Control Log Viewer" for more information. If you are not using Log Viewer, then check the relevant error log files in the following directory:

ORACLE_INSTANCE\diagnostics\logs\OHS\ohs1\access.log

3. Check the status and configuration of the OracleAS Single Sign-On DAD.
From the OracleAS Single Sign-On home page, perform the following steps:

1. In the Related Links section of the OracleAS Single Sign-On home page, click HTTP_Server.

2. Click Administration.

3. Click PL/SQL Properties and review the DADs section:

- If the status is 'Up', then continue to the next step.

- If the status is 'Down', then click the name of the DAD in the DAD table and verify that all properties are set correctly. Save any changes and restart Oracle HTTP Server and WLS_PORTAL for any change to take effect.

Check if you can log in now.

4. Check if the database containing the OracleAS Single Sign-On schema is running.
Database information is displayed on the OracleAS Single Sign-On home page in the Oracle Enterprise Manager 11g Fusion Middleware Control. Drill down for further information.

- If the status is 'Up', then continue to the next step.

- If the status is 'Down', then start the database.

If the database starts successfully, check whether your OracleAS Single Sign-On schema is accessible now.

5. Check the status and configuration of the SQL* Net Listener.
Check that the SQL*Net TNS listener is up and running on the host where the Identity Management repository is installed. Log in to the computer containing the database. Change to the ORACLE_INSTANCE/bin directory if you are currently not in the $PATH directory, and use the following to determine the status of the TNS listener:

lsnrctl status

If the service is not running, then start it by using the following:

lsnrctl start

If the service is already up and running, then refer to the Oracle Database Net Services Administrator's Guide in the Oracle Database 11g documentation library, for the specific error number returned, and then take suitable action.

Verify Communication Between Oracle Portal and Oracle Internet Directory

In the second part of the Oracle Portal login process, the credentials provided by OracleAS Single Sign-On are used by Oracle Portal to get Group membership information from Oracle Internet Directory.

To help diagnose the causes of problems encountered in this part of the login process, check the Metadata Repository log.

Verify Assignment of the Home Page

In the final part of the Oracle Portal login process, you are redirected to the appropriate Oracle Portal home page based on your Group membership. The home page preference can be specified at the System, Group, or User level.

If a home page has been specified for you, then it is displayed when you log in. If no home page has been specified for you, but you belong a default group, and a home page has been specified for your default group, then that page is displayed. If a home page has not been specified for you and you either do not belong to a default group or a home page has not been specified for the default group, then the System level default home page is displayed.

To help diagnose the cause of the problem, check if you have View privileges for the home page, at the User, Group, or System level.

When a home page is being displayed, you must have privilege to view the page. The privilege can be granted to one of the following:

- User

- User Group

- Public

If you do not have privileges to view the page at any of the levels in the preceding list, then you receive the "WWC-44131: You do not have permission to perform this operation" error.

At the Group or the System level, verify with an administrator that the group you are part of has correct privileges to view the page.

A portal administrator must perform the following steps to identify a user home page:

- Edit the user profile to find out the default home page and the default group for the user.

- If a default home page is already specified for the user, then stop here. Otherwise, edit the group profile for the default group, and check if a default home page is specified.

- If a default home page has been specified for the default group, then stop here. Otherwise check the default home page from the Global Settings page.

Once the home page is established, the next step is to find out about the privileges granted on the page. Edit the page, and click Access. Check whether or not the page can be viewed by public. In addition, look at the list of grantees. Check if the user or any group that the user belongs to has been given View or higher privileges on the page. Grant the appropriate privileges if needed. If the privilege has been granted to a group that the user is a member of, then ensure that the name of the user appears in the list of members.

G.1.3 Problems Creating Category or Perspective Pages

When you create category or perspective pages, you may encounter the following errors:

- WWS-32022:The category has been created but it was not possible to place the search portlets onto the category page. The category page will not show the items or pages in the category.

- WWS-32023:The perspective has been created but it was not possible to place the search portlets onto the perspective page. The perspective page will not show the items or pages in the perspective.

Problem

When you create a category in a page group, a category page is created based on the category template. Similarly, when you create a perspective, a perspective page is created based on the perspective template. If changes are made to the underlying category or perspective templates, then you may see one of the preceding messages when you create a new category or perspective.

Solution

If either of these errors is displayed, you must first delete the current category or perspective template, and then run scripts to do the following:

- Replace the current category or perspective template with the original version.

- Re-create category or perspective pages that are based on the current template. You can do this either across all page groups, or for specific page groups.

This ensures that all new category or perspective pages are created without errors and that all existing category or perspective pages display their associated items and pages as expected.

See Section B.9, "Using the Category and Perspective Scripts" for more information about where to look for and run these scripts.

G.1.4 Problems with Network Address Translation (NAT) Setup

After following the steps in Section 6.3, "Configuring Multiple Middle Tiers with a Load–Balancing Router", you encounter the following error:

Timeout occurred while retrieving page metadata

Problem

If a NAT bounceback rule is not correctly set up on the LBR when configuring multiple middle tiers, then the response to loopback requests is deleted, causing Oracle Portal pages to time out.

Solution

NAT bounceback rule is set up differently on individual LBRs. Consult your LBR configuration guide for detailed information. Refer to Section 6.3, "Configuring Multiple Middle Tiers with a Load–Balancing Router" for a detailed description on why the LBR needs additional configuration to make loopback communication successful.

G.1.5 User and Group Information in Oracle Portal and Oracle Internet Directory Does Not Match

User and group information in Oracle Portal is not synchronized with the information in Oracle Internet Directory.

Problem

Changes from Oracle Internet Directory are not propagated to Oracle Portal. Oracle Portal uses a provisioning profile to receive notifications when user or group privilege information changes. This enables Oracle Portal to keep its authorization information synchronized with the information stored in Oracle Internet Directory. By default, this provisioning profile is enabled.

Solution

Perform the following steps to help diagnose the cause of this problem:

1. Check if provisioning is enabled.
Perform the following steps to check if provisioning is enabled:

1. Log in to Oracle Portal. Click the Administer tab. On the Portal Builder page, click Global Settings under Services.

2. Click the SSO/OID tab, and scroll down to the Directory Synchronization section. This section enables you to specify whether or not directory synchronization should be enabled. Enable Directory Synchronization should be selected, and by default, Send event notifications every n seconds must be set to 300.

3. If the Directory Synchronization section is not visible or the check box for Enable Directory Synchronization is not checked, then the provisioning profile is not enabled. Enable the provisioning profile by selecting the Enable Directory Synchronization, check box and then clicking OK or Apply.

If you encounter an error, you must re-create the provisioning profile, using oidprovtool tool as shown in the following example:

oidprovtool operation=create ldap_host=myhost.mycompany.com ldap_port=389 \
ldap_user_dn="cn=orcladmin" ldap_user_password=welcome1 application_dn="orclApplicationCommonName=PORTAL,cn=Portal,cn=Products,cn=OracleContext" \
organization_dn="dc=us,dc=mycompany,dc=com" interface_name=PORTAL.WWSEC_OID_SYNC \
interface_type=PLSQL interface_connect_info=myhost:1521:iasdb:PORTAL:password \
schedule=360 event_subscription="USER:dc=us,dc=mycompany,dc=com:DELETE" \
event_subscription="GROUP:dc=us,dc=mycompany,dc=com:DELETE" \
event_subscription="USER:dc=us,dc=mycompany,dc=com:MODIFY(orclDefaultProfileGroup,userpassword)" \
event_subscription="GROUP:dc=us,dc=mycompany,dc=com:MODIFY(uniqueMember)" \
profile_mode=OUTBOUND

2. Check if Oracle Directory Integration Platform is up and running.
Perform the following steps to do this:

1. Display the Oracle Enterprise Manager 11g Fusion Middleware Control. See Section 8.1, "Using Oracle Enterprise Manager 11g Fusion Middleware Control" for more information. Navigate to the Oracle Fusion Middleware Control of the Infrastructure home directory associated with your portal.

2. Oracle Internet Directory status is displayed on the Fusion Middleware page.

- If the status is 'Up', then continue to the next step.

- If the status is 'Down', then start Oracle Internet Directory using Oracle Fusion Middleware Control.

To access the Oracle Internet Directory monitoring and administration pages in Oracle Fusion Middleware Control, click OID in the Fusion Middleware System Components table.

If Oracle Internet Directory starts successfully, then continue to the next step.

If Oracle Internet Directory fails to start, then check the Oracle Internet Directory error log files and try to determine the problem. See Section G.2.4, "Using Fusion Middleware Control Log Viewer" for more information.

3. Check if Oracle Directory Integration Platform is up.
Click OID in the Fusion Middleware System Components table. On the page that follows, click Directory Integration in the Status section.

- If the status is 'Up', then continue to the next step.

- If the status is 'Down', then start the Oracle Directory Integration Platform server using Oracle Enterprise Manager 11g Fusion Middleware Control.

See Also:

- Managing the Oracle Directory Integration and Provisioning Server in the Oracle Fusion Middleware Integration Guide for Oracle Identity Management

- Diagnosing Oracle Directory Integration and Provisioning Server Problems in the Oracle Fusion Middleware Integration Guide for Oracle Identity Management

3. Check the contents of the trace and audit log files.
When changes are propagated, results are written to trace and audit files. Checking the contents of these files can give you additional information about propagation failures. Perform the following steps to check the contents of these files:

1. Log in to the computer that has the Oracle Directory Integration Platform server running.
Typically, the computer that has Oracle Internet Directory installed has the Oracle Directory Integration Platform server.

2. Check for the trace and audit Log Files.
Navigate to the ORACLE_INSTANCE/ldap/odi/log/ directory.

For each provisioning profile, there are two associated files in the log directory: *.trc (trace) and *.aud (audit) log files.

By default, the trace log file contains entries that are generated every 300 seconds, because the default value of Send event notifications every n seconds is 300. This file contains the log of recent information logged by Oracle Directory Integration Platform and also contains any errors that may have been encountered. The trace log file gets recycled after some time.

The audit log file contains a history of all the changes that have been propagated to the provisioning profile. The following is an example of a message found in the audit log file:

Tue Jun 19 17:07:30 GMT 2004  -  Audit Log Start
-----------------------------------------------------
Group Exists Check - DN : cn=super_users,cn=ASDB.COMPANY.US.COM,cn=Database
Instances,cn=SES,cn=Portal,cn=Products,cn=OracleContext,dc=us,dc=co
mpany,dc=com ,GUID (CE0D473B93B521FAE0340003BA109AC2) - Response :
=============Event ID : 2320 - (GROUP_MODIFY)=============
Source     : orclapplicationcommonname= ASDB.COMPANY.COM,cn=database
instances,cn=ses,cn=portal,cn=products,cn=oraclecontext
Time       : 20031209170036z
Object Name: super_users
Object GUID: CE0D473B93B521FAE0340003BA109AC2
Object DN  : cn=super_users,cn= ASDB.COMPANY.COM,cn=Database
Instances,cn=ses,cn=Portal,cn=Products,cn=OracleContext,dc=us,dc=co
mpany,dc=com
AttrName     -      OpType     -     Value
-------------------------------------------
uniquemember    -     ADD    -
cn=portal,cn=users,dc=us,dc=company,dc=com
EVENT_NTFY Response : 1
2320 : Success : 2 : cn=super_users,cn= ASDB.COMPANY.COM,cn=Database
Instances,cn=ses,cn=Portal,cn=Products,cn=OracleContext,dc=us,dc=co
mpany,dc=com
-----------------------------------------------------

The propagation information gets written to the trace log files, and is periodically added to the audit log files. If changes are propagated properly, then the time stamp in the trace log file will be updated:

- If changes are propagated properly, but are not reflected in Oracle Portal, then continue to the "Are Changes Propagated Properly?" section.

- If you do not find the trace and audit log files, then check if a provisioning profile exists by performing the following steps:

1. Log in to Oracle Portal. Click the Administer tab. On the Portal Builder page, click Global Settings under Services.

2. Click the SSO/OID tab and scroll down to the Directory Synchronization section. This section lets you indicate whether or not directory synchronization is enabled. Enable Directory Synchronization must be selected, and Send event notifications every [ ] seconds must be set to 300 by default.

3. If these values are not set, then you must create a provisioning profile as detailed in the following section.

If you do not find the trace and audit log files in the ORACLE_INSTANCE/ldap/odi/log/ directory, then chances are that the provisioning profile has been deleted. To re-create a provisioning profile, run the oidprovtool tool as shown in the example below:

ldap_user_dn="cn=orcladmin" ldap_user_password=welcome1 application_dn="orclApplicationCommonName=PORTAL,cn=Portal,cn=Products,cn=OracleContext" \
organization_dn="dc=us,dc=mycompany,dc=com" interface_name=PORTAL.WWSEC_OID_SYNC \
interface_type=PLSQL interface_connect_info=myhost:1521:iasdb:PORTAL:password \
schedule=360 event_subscription="USER:dc=us,dc=mycompany,dc=com:DELETE" \
event_subscription="GROUP:dc=us,dc=mycompany,dc=com:DELETE" \
event_subscription="USER:dc=us,dc=mycompany,dc=com:MODIFY(orclDefaultProfileGroup,userpassword)" \
event_subscription="GROUP:dc=us,dc=mycompany,dc=com:MODIFY(uniqueMember)" \
profile_mode=OUTBOUND

Are Changes Propagated Properly?

To help diagnose whether or not changes are propagated properly, create, delete, and re-create a user through Oracle Portal (in Oracle Internet Directory). To do this, perform the following steps:

1. Click the Administer tab.

2. Under User, click Create New Users.

3. Edit the profile of the user.

4. Delete the user.

5. Re-create the user with the same name.

Wait for the interval period (the time specified for Send event notification of messages). To minimize your wait time, you can reset this value to less than 300 seconds. After this, log in as the newly created user. If you receive the following error while logging in, then information is not propagating from Oracle Internet Directory to Oracle Portal:

Error "WWC-41742: There is a conflict with your assigned user name. There is a user entry with this name, but with a different globally unique identifier (GUID), which must be resolved before you can log on with this name. Please inform your administrator."

If no information is propagated, then Oracle Portal throws this error, because it has the same user name stored with a different GUID.

If changes are not propagated properly, then it is likely that there is a problem in either Oracle Directory Integration Platform or in the configuration of Oracle Portal with Oracle Directory Integration Platform. If this is an Oracle Portal configuration problem, then run the ptlconfig tool as follows:

ptlconfig -dad <dad> -dipreg

G.1.6 Problems with Oracle Portal Performance

You may experience performance issues with Oracle Portal for example, pages may load slowly.

There could be multiple reasons why your portal is slow. Some of these problems are described here.

Problem 1

Caching is disabled.

Solution 1

- Using Oracle Fusion Middleware Control, check that the Portal's Caching option is set to On as described in Section 5.6.6, "Configuring the Portal Cache Using Fusion Middleware Control".

Problem 2

Page metadata is not cached in Oracle Web Cache. The initial, one-time call from the middle tier to the Oracle Portal schema to determine the Oracle Portal version may have failed.

Solution 2

To resolve this problem, perform the following tasks:

1. Confirm that page metadata is not cached in Oracle Web Cache. To do this, perform the following step:

- Append a page URL with &_debug=1, refresh the browser, and verify that the Oracle Web Cache page metadata cache status is MISS, NON-CACHEABLE.

2. Restart all WLS_PORTAL instances.

3. Perform Step 1 again to determine if page metadata is now cached in Oracle Web Cache.

Problem 3

Low or no reuse of connection pool.

Solution 3

Set the MaxRequestsPerSession parameter to 1000 Oracle Fusion Middleware Control MBean Browser

Note:

Ensure that the MaxRequestsPerSession attribute is not set to 1. Doing this disables connection pooling. For information about the MaxRequestsPerSession attribute, refer to the Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server.

To change the MaxRequestsPerSession attribute:

1. Navigate to the Fusion Middleware Control instance for the appropriate farm.
See Section 8.1, "Using Oracle Enterprise Manager 11g Fusion Middleware Control" for more information.

2. From the Farm menu, select Administration > System MBean Browser.

3. Locate the PlsqlMaxRequestsPerSession MBeans attribute using the Search function, or use the Navigation pane and open Mbeans > oracle.mas.config > PortalConfig > pls/portal.

4. On the Attributes tab, scroll down and click on the PlsqlMaxRequestsPerSession attribute.

5. Reset the attribute value to 1000 and click OK.

6. Restart the Oracle HTTP Server and WLS_PORTAL.
Refer to Section 5.6.3, "Stopping and Starting Portal Components Using Fusion Middleware Control" for information on restarting the Oracle HTTP Server and WLS_PORTAL components.

Problem 4

Site is not responding.

Solution 4

Check the WebCache and OHS logs diagnostic messages to see if there is a need to tune the configuration of these Oracle components.

Oracle Fusion Middleware Control MBean Browser
To change the attribute:

1. Navigate to the Fusion Middleware Control instance for the appropriate farm.
See Section 8.1, "Using Oracle Enterprise Manager 11g Fusion Middleware Control" for more information.

2. From the Farm menu, select Administration > System MBean Browser.

3. Locate the MBeans attribute using the Search function, or use the Navigation pane and open Mbeans > oracle.mas.config > PortalConfig > Global.

4. On the Attributes tab, scroll down and click on the attribute.

5. Reset the attribute value and click OK.

6. Restart the Oracle HTTP Server and WLS_PORTAL.
Refer to Section 5.6.3, "Stopping and Starting Portal Components Using Fusion Middleware Control" for information on restarting the Oracle HTTP Server and WLS_PORTAL components.

Problem 6

Disk input or output not distributed.

Solution 6

Many components, such as the following, access disks all the time:

- Oracle HTTP Server access and error logs

- Portal cached content

- Web content service

- Other local applications

All these components compete for the resources of the file system. To reduce input or output bottlenecks, ensure that you have a good distribution across physical disks.

Problem 7

Too many network hops. Typical problems can be any of the following:

- PPE loopbacks are not configured on clustered Oracle HTTP Server environments.

- Servlet engines run on a computer other than Oracle HTTP Server or mod_weblogic.

- Infrastructure components run across wide networks with multiple routers.

Solution 7

Try to reduce the number of network hops by avoiding or working around the listed problems.

Problem 8

Use of the HTTPS protocol for serving content.

You may have configured your portal to use HTTPS for ordinary content that does not need to be secure.

Solution 8

Avoid the unnecessary use of HTTPS. HTTP works well in most cases. If you really need a secure environment, then use reverse proxy hardware that will manage HTTPS and Secure Socket Layer (SSL). See Section 6.6, "Configuring Oracle Portal to Work with a Reverse Proxy Server" for more information.

See Also:

- Section 7.3.2.1, "Configuring SSL for Oracle Portal"

- Oracle Fusion Middleware Enterprise Deployment Guide for Java EE

Problem 9

After performing all the tasks in the solutions provided, Oracle Portal is still slow.

Solution 9

- Review metric information for Oracle Portal, its host, and other relevant components.
If all the components required by Oracle Portal are up and running as expected, then the next step is to review metric information in Oracle Fusion Middleware Control. Reviewing this information can help you identify the problem.

Click All Metrics in the portal home page to review metric information. Repeat this on home pages for other relevant components (Oracle Web Cache, Oracle HTTP Server, and so on).

- Run Oracle Portal Diagnostics Assistant.
You can diagnose portal-related issues by reviewing the report generated by using Oracle Portal Diagnostics Assistant. See Section G.2.5, "Using Oracle Portal Diagnostics Assistant" for more information.

See Also:

- For more information, refer to the Performance page on the Oracle Portal section of OTN, http://www.oracle.com/technology/products/ias/portal/performance_10g1014.html

- The Performance Monitoring Scripts zip file on OTN, http://www.oracle.com/technology/products/ias/portal/files/portal_performance.zip

- Oracle Fusion Middleware Performance and Tuning Guide

- Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server

Note:

The Performance Monitoring Scripts zip file is also available as part of the Oracle Fusion Middleware installation.

G.1.7 Error When Creating Web Folders

When you try to create Web folders in Oracle Portal, you get an ORA-20504 error, in the Web server error log file.

Problem

The wwdav$path and wwdav$asl tables are corrupt.

Solution

To repopulate the tables, you have to run the DAV Loader (wwdav_loader) utility. You can run the DAV Loader utility by executing the following procedure from SQL*Plus:

set serveroutput on size 1000000
begin
wwdav_loader.create_dav_content;
end;

This re-creates all the DAV data. To get more debugging information, you can also use:

set serveroutput on size 1000000
begin
wwdav_loader.create_dav_content(
p_debug_mode => true);
end;

Running the DAV Loader removes any temporary documents, and any locks on documents, from the DAV tables. Items submitted for approval no longer appear in the DAV Loader until they are accepted or rejected.

In future, to examine whether there are any data corruptions in the DAV schema, you can run the DAV Report utility. To run this utility, perform the following steps:

1. Change the directory to ORACLE_HOME/upgrade/portal/admin/plsql/wwu/, where the davreprt.sql file resides.

2. Log in to SQL*Plus as the PORTAL schema user.

3. Run the DAV Report Utility as follows:

davreprt.sql

This will run through a series of tests. If all tests pass, then no known data corruptions can be found in the DAV schema. If any test fails, then the DAV Loader must be run to correct the data corruption.

G.1.8 Create New Users and Create New Groups Portlets Do Not Appear

The Create New Users and Create New Groups portlets are displayed based on user privileges. The portlets may not appear for a variety of reasons.

Problem 1

You do not have sufficient privileges.

Solution 1

Use the Delegated Administration Service Self-Service Console to verify if you can administer users and groups. If you do not have the required privileges, then request the administrator to grant you the required privileges. However, if you can successfully perform these operations from the Self-Service Console, then it is most likely related to the next two problems. Inform the administrator about the issue.

Problem 2

Oracle Internet Directory is down or the group information in Oracle Internet Directory is incorrect.

Solution 2

If the Group membership information in Oracle Internet Directory is incorrect or if Oracle Internet Directory is not up and running, then perform the following steps to help diagnose the cause of this problem:

1. Display the portal home page in Oracle Enterprise Manager 11g Fusion Middleware Control. See Section 8.1, "Using Oracle Enterprise Manager 11g Fusion Middleware Control" for more information. Navigate to Oracle Fusion Middleware Control Console of the Infrastructure home directory associated with your portal.
Check if Oracle Internet Directory is up. Oracle Internet Directory status is displayed in the Fusion Middleware page.

- If the status is 'Up', then continue to the next step.

- If the status is 'Down', then start Oracle Internet Directory using Oracle Fusion Middleware Control Console or the command line.
To access Oracle Internet Directory monitoring and administration pages in Oracle Fusion Middleware Control Console, click Oracle Internet Directory in the Fusion Middleware System Components table.

If Oracle Internet Directory starts successfully, then check if the Create New Users and Create New Groups portlets are displayed.

If Oracle Internet Directory fails to start, then investigate Oracle Internet Directory error log files and try to determine the problem. See Section G.2.4, "Using Fusion Middleware Control Log Viewer" for more information.

Problem 3

Oracle Portal and Oracle Internet Directory connection configuration is incorrect.

Solution 3

Login to Enterprise Manager and ensure that you have entered the correct OID parameters in the Portal Wire Configuration page.

G.1.9 ORA-2000x Errors in the error_log File

When you attempt to log in to Oracle Portal, you see one of the following errors in the diagnostics log file located in the ORACLE_INSTANCE/diagnostics/logs/OHSComponent/ohs1 directory:

- ORA-20000: "An attempt was made to access the session context without a valid session"
This error denotes that the Oracle Portal session associated with that particular browser session is broken or lost, or that the session cookie itself is missing.

- ORA-20001: "The session cookie is corrupt - unable to obtain session information. Please close your browser and reconnect."
This error indicates a corrupt or otherwise invalid session cookie.

- ORA-20005: "The session context could not be restored because the session is marked as inactive"
This error is raised when the session cookie points to an inactive session. The cookie sent by the browser matches the cookie stored in the session, but the session is not active.

- ORA-20006: "The session context could not be restored because the cookie value does not match the value stored in the session repository"
This error indicates that there is a mismatch between the cookie sent by the browser and the cookie stored in the session.

Note:

It is important to understand that some of these errors are expected. Report the problem to Oracle Support Services only if an unusual number of exceptions is encountered. See Section G.3, "Need More Help?"for more information.

These errors are discussed in detail in the following subsections.

ORA-20000 "An attempt was made to access the session context without a valid session"

This error can be caused by any of the following problems:

Session Row Is Missing

Each session cookie has a corresponding session stored in the portal schema that contains information about the session cookie corresponding session. The data stored in the session includes the session ID, user name, session start time, information about whether the user is logged on or not, what time the user logged on, whether the session is active or marked for cleanup. The ORA-20000 error is raised if the session ID specified in the cookie does not exist in the sessions stored in the portal schema in the Oracle Metadata Repository.

Session Is Cleaned Up

A background job runs frequently to clean up old sessions from the portal schema in the Oracle Metadata Repository. By default, this job is configured to clean up sessions that are older than seven days. An attempt to access a session that has been cleaned up by the background job will result in an ORA-20000 error. See Section B.5, "Managing the Session Cleanup Job" for details.

Session Cookie Is Missing

If more than one DAD is configured for use with the portal schema in an Oracle Metadata Repository, and the cookie name specified in these DADs is not the same, then it will result in the cookie_name value in the wwctx_cookie_info$ table switching values every time a new session creation request is received through one of the DADs. This will result in an ORA-20000 error.

ORA-20001 "The session cookie is corrupt - unable to obtain session information. Please close your browser and reconnect."

The ORA-20001 error can be caused by any of the following problems:

Cookie Is Truncated

If you click Stop on the browser during the transmission of a request, then the cookie may be truncated. The next time you access the browser, the server is unable to properly decrypt the cookie.

Cookie from Another Server Is Received

If you have recently accessed another Oracle Portal that is configured with a domainwide cookie scope, then an ORA-20001 error may be raised. If the cookie name of that portal is the same as your portal cookie name, then Oracle Portal tries to use that cookie. However, because each portal cookie is encrypted using portal-specific keys, Oracle Portal will not be able to decrypt the cookie, and will raise an ORA-20001 error assuming that the cookie is corrupted.

To avoid this namespace collision issue, you must determine the source of these cookies. Closing the browser will clear all the session cookies. You can debug the problem by starting up the browser with cookie warnings turned on, to see where the cookies are obtained from.

Cookie Encryption Key Is Changed

The cookies are encrypted using DES3 encryption. The encryption key is stored in the portal schema in the Oracle Metadata Repository. Its value is typically set during Oracle Portal installation and does not change thereafter. If this value is changed after installation, then it is not possible to decrypt any of the outstanding session cookies. Also, any other values that have been encrypted with this key cannot be decrypted. Note that this value should not be changed.

ORA-20005 "The session context could not be restored because the session is marked as inactive."

The ORA-20005 error results when the session cookie points to an inactive session. The cookie sent by the browser matches the cookie stored in the session, but the session is not active. It indicates that you made a logout request, but another request (for example, a user makes a request to change the language from the Language portlet) was sent before the cookie was reset in the browser.

Session Is Marked Inactive

When the user logs out, it is possible that the session stored in the portal schema gets updated to an inactive state. However, if you click Stop in the browser, then the cookie does not get cleared from the users browser. If this happens, then the browser sends the old cookie, causing Oracle Portal to try to locate the inactive session. When this happens, an ORA-20000 error is raised.

ORA-20006 "The session context could not be restored because the cookie value does not match the value stored in the session repository."

The ORA-20006 error indicates that there is a mismatch between the cookie sent by the browser and the cookie that is stored in the session. This could happen if the cookie changes based on one request, and the user sends another request before the cookie is actually updated in the browser. For example, the user makes a request to change the language from the Language portlet, but sends another request before the first request is complete. This is similar to the ORA-20005 error, with the difference that the cookie itself contains a mismatch between the client and the server.

Time Stamp Does Not Match

The cookie may be decrypted properly, but if the time stamp in the cookie does not match the time stamp in the associated session row, it is considered to be corrupt. This mismatch in time stamp may occur if the user invokes the login twice, if there are network configuration issues, or bugs in the session creation logic, or because of a malicious session attack.

G.1.10 Remote Web Providers Time Out in a Dynamic DNS Environment

A remote Web provider that is located on a computer different from the Oracle Portal middle tier, works when the WLS_PORTAL service is first started, but stops working after some time. After a long timeout interval, the Error: the portlet could not be contacted message is shown in the place of each portlet from the same provider. Portlet timeout interval errors are also found in the WLS_PORTAL WLS_PORTAL-diagnostic.log file. After restarting WLS_PORTAL, the Web provider works again, but only for a limited period of time.

Problem

The possible cause for this problem can be that the Web provider is using dynamic DNS (DDNS) for its Domain Name to IP Address mapping. This means that the IP address that the Web provider domain name resolves to changes over time. Java default caching policy caches IP addresses forever, once it has resolved them. This means the Java cache stores an outdated IP address of the Web provider if the IP address of the Web provider changes, because of DDNS.

Solution

To resolve this problem, you need to perform additional configuration in WLS_PORTAL to prevent remote Web providers from timing out. You must change the sun.net.inetaddr.ttl system property for WLS_PORTAL. On JDK 1.3 and later, you can use the sun.net.inetaddr.ttl system property to specify the "time to live" (TTL) in seconds for cached IP addresses.

Example

1. Edit the opmn.xml file as follows:

<java-option value="-server -Xincgc -Xnoclassgc -Xms256m -Xmx512m -Dsun.net.inetaddr.ttl=120"/>

2. Shut down opmn and all its subprocesses, and restart it for the latest configuration changes to take effect.
To do this, run the following commands:

ORACLE_INSTANCE/opmn/bin/opmnctl stopall
ORACLE_INSTANCE/opmn/bin/opmnctl startall

G.1.11 Problems Related to Memory-Intense Operations

You see the error "ORA-04031: unable to allocate 30192 bytes of shared memory."

Problem

By default, the shared_pool_size value in Oracle Fusion Middleware is 32 megabytes. This can cause problems if you are performing memory-intense operations such as the following:

- Export or Import

- Creating Portal Forms or Reports

Solution

To facilitate memory-intense operations, you must increase the value of the shared_pool_size parameter.

If you are unfamiliar with the steps involved in updating a database initialization parameter, refer to the section, "Managing Initialization Parameters Using a Server Parameter File", in the Oracle Database Administrator's Guide in the Oracle Database 11g documentation library.

Note:

As an optional step, it is suggested that you run Oracle Portal Diagnostics Assistant to view a report of the existing and recommended values of the database. See "Running Oracle Portal Diagnostics Assistant" for details.

G.1.12 Unable to Create Oracle Text Indexes

When trying to create Oracle Text indexes, you may encounter the following errors:

- "Cannot grant CTXAPP role to portal"

- "ERROR: Creating data store procedures in CTXSYS"

- "ERROR: Setting up Oracle Text data stores"

- "An unexpected error has occurred (WWS-32100)"

Problem

You face problems when trying to create Oracle Text indexes.

Solution

Oracle Text must be installed in the same Oracle Database home directory as the portal schema. See Section 10.3.2, "Oracle Text Prerequisites" for details.

Choose one of the following options to resolve this issue:

- Access the database and log in as the Oracle Portal schema owner. Start SQL*Plus and run the inctxgrn.sql script. This script is located in the ORACLE_HOME\portal\admin\plsql\wws directory. Running this script creates the Oracle Text data store procedures and also grants the CTXAPP role to the Oracle Portal schema.

- If you have access to the database, but you do not have a copy of the inctxgrn.sql script, use SQL*Plus to connect to the database as the schema owner and run the following commands:

set serveroutput on size 10000
begin
wwv_context_util.grantCtxRole(user);
end;
@@sbrimtlx

Replace (user) with the Oracle Portal schema owner, for example, portal.

G.1.13 Problems with MultiLanguage Support for Help

Only a subset of the online Help appears to be translated in Oracle Portal.

Problem

In Oracle Portal, there is multi-language support for the online Help. However, only a subset of the context-sensitive Help topics is translated for languages other than Japanese.

Solution

This is expected activity.

G.1.14 Stale Style-Sheet Data Is Displayed on Portal Pages

When editing style sheets, you see stale style-sheet data when previewing or viewing the style sheet in the context of a portal page.

Problem

Changes to style sheets are not reflected on portal pages. This is because the Greenwich Meridian Time (GMT) is appended to the numeric value, which generates the Last-Modified header without correcting the time zone. If the time zone of the original server precedes GMT, then the generated Last-Modified header is actually a future date.

Solution

Perform the diagnostic steps described in the Oracle Application Server Portal Error Messages Guide for the following errors:

WWC-40018: General invalidation message processing exception: %1
WWC-40019: Could not open web cache connection

If the problem is not resolved by these steps, then verify that the date, time, and time zone have been set to the current values on the Oracle Web Cache hosts and the database host. Also, verify that the database time zone has been set to match the database host time zone. The database time zone can be determined by executing the following query:

SQL> SELECT DBTIMEZONE FROM DUAL;

If the database time zone differs from the database host time zone, then set the database time zone to the database host time zone using the ALTER DATABASE SET TIME_ZONE command, and then restart the database.

For example:

SQL> ALTER DATABASE SET TIME_ZONE = '-05:00';

The change will not take effect until the database is restarted.

G.1.15 Stale Content Is Displayed on Portal Pages

The content on your portal pages is not getting refreshed and stale content is displayed.

Problem

Your browser cache settings may be incorrect.

Solution

Ensure that the browser cache setting is not set to Never.

To verify this setting, refer to the "Browser Recommendations" section in the Preface of the Oracle Fusion Middleware User's Guide for Oracle Portal.

G.1.16 Images Are Not Displayed on Portal Pages

When using Oracle Portal, you may face either of the following problems:

- Images are not displayed.

- After logging out of portal, you cannot log in unless you close the browser and open it again.

Problem

Your browser image settings may be incorrect.

Solution

Ensure that images are automatically loaded. To verify this setting, refer to the "Browser Recommendations" section in the Preface of the Oracle Fusion Middleware User's Guide for Oracle Portal.

Note:

It is recommended that this setting is always enabled.

G.1.17 Unhandled Exception Errors

When accessing or using Oracle Portal, you may encounter an unhandled exception error. For example, "Error 30526: An Unhandled Exception has occurred."

Problem

Oracle Portal encounters a database error from which it cannot recover.

Solution

In case of unhandled exception errors, the actual cause of the error is not clear. To gather more information about the possible cause of the error, generate a trace file.

After you have turned tracing on, you can find the generated trace files in the directory specified in the database parameter user_dump_dest. To find out the name of the directory, use either of the following commands:

select value from v$parameter where name = 'user_dump_dest';

show parameter user_dump_dest;

Refer to Section G.2.2, "Generating Trace Files" for the procedure to generate trace files. These trace files are not formatted. Use the tkprof utility to format them.

G.1.18 Problems in Configuring the OmniPortlet Provider

When configuring the OmniPortlet provider to build portlets, you may encounter a number of problems. To resolve many of the problems, you may need to view the OmniPortlet provider application log file, WLS_Portal.log. This log file is available at the following location:

DOMAIN_HOME\servers\WLS_PORTAL\logs

Problem

The required SSL library is not in the library path.

If you installed the OracleAS PDK on a Portal instance, you may encounter the following error:

"java.lang.NoClassDefFoundError: at oracle.security.ssl.OracleSSLCipherSuite.isSSLLibDomestic when accessing HTTPS site with certificate"

Solution

Ensure that the SSL library is in the library path. Refer to "Copying the Library for HTTPS Access (PDK Only)" for more information.

G.1.19 Problems in Configuring Oracle Web Cache for the OmniPortlet Provider

Stale portlet content displays on the portal page, and it does not reflect the portlet definition. This problem may occur because of the following errors in Oracle Web Cache configuration:

Problem 1

The port value is not specified properly in the cache.xml file. You may encounter the following error:

CONFIGURATION: Encountered a Cache Invalidation Exception.
oracle.net.http.HttpConfigurationException: Bad "port" value in configuration element "invalidation"

Solution 1

Set the correct port number in the cache.xml file.

A template copy of the cache.xml file can be found in the ORACLE_INSTANCE/portal/conf directory. To specify the port, modify the configuration file as indicated by the italicized entry in the following example:

<?xml version="1.0"?>
<webcache>
<invalidation
host="cache.us.oracle.com"
port="4001"
authorization="0510198d5df8efd5779406342be2528aa0cccb179ea6b77baf49f019f5075a3a11"/>
</webcache>

Problem 2

The authorization value is not encrypted in the cache.xml file. You may encounter the following error:

CONFIGURATION: Encountered a Cache Invalidation Exception.
oracle.net.http.HttpConfigurationException: Bad "authorization" value in configuration element "invalidation." String un-obfuscation error

Solution 2

Information about the Oracle Web Cache instance is maintained in the cache.xml file in the ORACLE_INSTANCE/portal/conf directory. If the Web Cache invalidation settings change, then you must update this file. Refer to Section E.2.1.3, "Configuring Caching (PDK Only)" for more information.

Problem 3

The oracle.http.configfile system property is not defined. This means that the configuration file for Web Cache Invalidation is not defined. You may encounter the following error when you start the WLS_Portal instance:

Error: CONFIGURATION: Provider Test Page: Web Cache Invalidation config file not defined by "oracle.http.configfile"

G.1.20 Problems in Accessing Oracle Portal from a Mobile Device

Mobile devices do not provide good interfaces for displaying detailed error information when compared with standard desktop browsers. Because of this, a lot of error information is logged in the Oracle Application Server Wireless log file. You can access this log file using a Web-based monitoring tool known as the Activity Logger. Refer to the Oracle Application Server Wireless Administrator's Guide for details about using the Activity Logger.

When you access Oracle Portal through OracleAS Wireless, you may encounter either of the following errors:

- Service Error

- Temporary Error

Service Error

A service error is generated by the OracleAS Wireless server when the wireless server has a problem accessing the back-end server. A service error is displayed as follows:

Service Error

A service error may be generated for any of the following reasons:

- A document that is not of text or vnd.oracle.mobilexml type has been returned to the OracleAS Wireless server.

- A document of text or vnd.oracle.mobilexml type has been returned to the OracleAS Wireless server, but the content is not valid XML.

- A document of text or vnd.oracle.mobilexml type has been returned to the OracleAS Wireless server, but the content is not valid OracleAS Wireless XML.

- An error status has been returned to the OracleAS Wireless server, but there is no attached document that can be returned to the user.

Temporary Error

A temporary error is a message generated by Parallel Page Engine (PPE) if there is a problem in rendering error documents for a mobile device. A temporary error is displayed as follows:

A temporary error has prevented Oracle Portal from servicing your request. (id=<nnnnn>)

The value <nnnn> is the log error ID.

When rendering error documents for standard desktop browsers, PPE takes the error document that resulted from the metadata call to the database, and passes it to the user. This cannot be done for mobile devices because the documents rendered for mobile requests must be in OracleAS Wireless XML.

If PPE is servicing a mobile request and the database renders an error document that is not valid OracleAS Wireless XML, then PPE performs the following tasks:

1. Writes the document into the servlet error log file, DOMAIN_HOME\servers\WLS_PORTAL\logs directory.

2. Assigns a unique ID to the error.

3. Passes a standard error template to the user in the following format:

A temporary error has prevented Oracle Portal from servicing your request. (id=<nnnnn>)

where <nnnn> is the log error ID.

Problems and Workarounds for Service and Temporary Errors

The different problems and workarounds for service errors and temporary errors are discussed in the following subsections.

Note:

After performing a suggested workaround, clear the cache, close the browser, and open it again. This must be done because the error page may be cached and you may encounter the service error again when you try to access the back-end service.

Problem 1

Oracle Application Server is not configured correctly. You encounter a service error.

Solution 1

Verify the Oracle Portal and OracleAS Wireless configurations in Oracle Application Server. For details about verifying these settings, refer to the Oracle Fusion Middleware Administrator's Guide.

Problem 2

You are not authenticated to access Oracle Portal from a mobile device or simulator. This could be because the comparison of IP addresses failed when validating the session cookie during logon. You encounter a service error.

Solution 2

Change the state of IP checking in cookie validation. Refer to Section B.2, "Configuring for IP Check During Session Cookie Validation" for details.

Access Oracle Portal from a mobile device or simulator and check if you still get a service error.

Problem 3

The xml.validation.mode parameter is set to True. If this parameter is set to True, then OracleAS Wireless tries to validate the error message file, which is not in valid XML format. You encounter a service error.

Solution 3

In the OracleAS Wireless instance, ensure that the xml.validation.mode parameter is set to False in the web.xml file located at:

ORACLE_HOME/j2ee/OC4J_Wireless/applications/wdk/wdk-web/WEB-INF

Access Oracle Portal from a mobile device or simulator and check if you still get a service error.

Problem 4

There are changes in OracleAS Wireless actions. You encounter a service error.

Solution 4

Check if any service can be run on the OracleAS Wireless server. For example, check if you can run OracleAS Wireless examples from a mobile device or simulator. For details, refer to the Oracle Application Server Wireless Administrator's Guide.

- If the example services do not work, then you may have to install and configure OracleAS Wireless again. For details, refer to OracleAS Wireless documentation.

- If the example services work properly, then check the OracleAS Wireless server log file for troubleshooting information. The log file stores information about the response from the portal service that is causing problems. Using this information, you can check if portal is returning an error status or invalid OracleAS Wireless XML.

Access the OracleAS Wireless server log file by clicking View Log at the bottom of the OracleAS Wireless Activity Logger. The last 500 lines in the log file are displayed. The wireless server log file is available in the ORACLE_INSTANCE/wireless/logs/ directory or the /var/tmp/ directory.

Based on the information in the log file, perform corrective steps or contact Oracle Support Services.

Note:

You can change the number of lines displayed while viewing the log file, but if you are searching for specific information in a large log file, then it is recommended to view the file using an operating system command, for example, vi, emacs, or more.

Problem 5

There is an error in retrieving metadata. You encounter a temporary error.

Solution 5

Access the servlet error log file, WLS_PORTAL-diagnostic.log, from the DOMAIN_HOME\servers\WLS_PORTAL\logs directory to view troubleshooting information. The servlet error log file records the original error document and its headers, and therefore contains as much information as is available to a standard desktop browser when there is a problem. Use the information in the error log file to perform standard Oracle Portal troubleshooting analysis.

Problem 6

When clicking the login link in the mobile browser, you encounter a service error.

Solution 6

Ensure that the AS Wireless patch and Oracle SSO patch have been applied as described in section 5.7.1 and 5.7.2.

G.1.21 Error During Export and Import After Upgrading from Oracle Portal 3.0.9 or 9.0.4

If you run the Oracle Portal Export and Import, after upgrading from Oracle Portal 3.0.9 or 9.0.4, you may encounter unexpected errors.

Problem 1

If your transport set includes categories or perspectives, the error may be due to category and perspective templates with incorrect page type IDs; that is, the page type ID is 1 instead of 11.

Solution 1

Check your transport set. If categories or perspectives are included, you can fix this issue by running the following script before running the Oracle Portal Export and Import utility:

SQL> @pstpgcre.sql

This script is located at ORACLE_INSTANCE/portal/admin/plsql/wws/pstpgcre.sql. This script drops and re-creates the category and perspective templates and their associated pages.

Refer to Section B.9, "Using the Category and Perspective Scripts" for information on how to use the category and perspective scripts.

Problem 2

When you upgrade from Oracle Portal 3.0.9, category and perspective names are appended with pageid and siteid and this impacts export and import between portals. For example, if you upgrade a category named GENERAL from version 3.0.9 to version 9.0.4, and then upgrade to version 11.1.1, the name of the upgraded category may be GENERAL_12345_0, where 12345 is the pageid and 0 is the siteid.

When you export and import between portals, search portlets that are customized to search for categories or perspectives will lose the category and perspective search criteria, if the source and target portals have different names for the same categories and perspectives.

Solution 2

Ensure that category and perspective names in the source and target portals are exactly the same. For example:

- Change category and perspective names to pre-upgrade names by removing the ID that is appended to the name. For example, change GENERAL_12345_0 back to GENERAL.

- Alternatively, specify new category and perspective names. If there is an existing category or perspective with the name you specify, then you are prompted for a different name.

Note:

Make the same changes in the both the source and target portals.

G.1.22 Errors Displayed When the Oracle Portal Language is Traditional Chinese

When the portal language is set to Traditional Chinese you may see errors while working with portlets, such as the Custom Search portlet, or when using the Navigator.

Problem

Errors while working with portlets can occur if the SHARED_POOL_SIZE of the Oracle Metadata Repository database is set too low.

Solution

As a workaround, increase the SHARED_POOL_SIZE of the Oracle Metadata Repository database. Although the recommended minimum size is 144Mb,this is too low for the Traditional Chinese language. Try increasing the SHARED_POOL_SIZE to 216MB, or higher.

G.1.23 Uploaded Content Is Not Returned in Search

If you have uploaded portal content, and it is not being returned using Oracle Text search in Oracle Portal, it may be due to content not being properly indexed before being made searchable.

Problem

Content has been uploaded to portal, but is not returned when searched.

Solution

Make sure the uploaded content was indexed correctly therefore making it searchable. For example, if a document is not indexed correctly due to the filter, then the tokens will not be in the index, and the terms inside the document will not be searchable as they will not match any tokens in the index.

To ensure content is indexed correctly and is therefore searchable, add the Mimetype and Character set attributes to the file- and url- item types (or create new file- url- item types and add these attributes) and specify the MIME type and character set when uploading content.

G.2 Diagnosing Oracle Portal Problems

Oracle Portal consists of middle and database tiers, each of which consists of numerous components. Components can be distributed across many computers, and they can also simultaneously handle a large number of requests.

You can also use diagnostic tools on Oracle Portal to analyze and resolve issues about how Oracle Portal works.

This section contains the following topics:

- Enabling ECID Logging

- Generating Trace Files

- Viewing the Diagnostic Output of Components

- Using Fusion Middleware Control Log Viewer

- Using Oracle Portal Diagnostics Assistant

- Analyzing Mobile-Related Problems in Oracle Portal

- Enabling Performance Logging

G.2.1 Enabling ECID Logging

To facilitate problem diagnosis, components can record information related to the requests they receive in log files. This section details how to configure and use various log files to diagnose problems, and how an individual request can be traced from start to finish by using the Execution Context Identifier (ECID).

Execution Context Identifier

Because Oracle Portal can satisfy a large number of requests simultaneously, tracing a single request through the various Oracle Portal components can be difficult because the information relating to these requests is intermingled.

Oracle Portal makes use of an ECID, which is a unique number that is assigned to a request and attached to the information recorded for that request. As a request is passed from one component to another, the ECID can be incremented to form a sequence. This means that an individual request can be tracked through any number of components by following this ECID sequence.

An ECID is generated by the first Oracle Fusion Middleware component to receive a request without an ECID. You can observe this generation and propagation in Figure G-2, where a dotted arrow depicts a request with an ECID.

Figure G-2 Request Flow with ECID Generation and Propagation

ECID generation is available in Oracle Web Cache, Oracle HTTP Server, and the Parallel Page Engine (PPE). An ECID is generated only if it does not already exist. In this release, logging of portal invalidations in Oracle Web Cache now includes the ECID of the original request. This can be used to relate invalidations to original edits or personalizations.

See Also:

For more information about ECIDs and how they can help you to correlate messages from Oracle Fusion Middleware components, refer to the Oracle Fusion Middleware Administrator's Guide.

G.2.2 Generating Trace Files

When an internal error is detected by a process, information about the error can be written to a trace file. This information is useful in analyzing unhandled exception errors. Refer to Section G.1.17, "Unhandled Exception Errors" for more information.

You can generate a trace file for the sessions in a database instance by using any of the following methods:

- Using PlsqlBeforeProcedure and PlsqlAfterProcedure

- Setting the sql_trace Parameter

- Setting Database Event 10046

G.2.2.1 Using PlsqlBeforeProcedure and PlsqlAfterProcedure

You can enable SQL tracing for a particular session in a database instance by creating a new DAD and setting values for the procedures, PlsqlBeforeProcedure and PlsqlAfterProcedure.

Note:

You can set values for PlsqlBeforeProcedure and PlsqlAfterProcedure in the original DAD, but this can affect other users. Therefore, it is recommended to create a new DAD.

To enable tracing, perform the following steps:

1. Run the utltrace.sql script in the portal schema. The default portal schema name is portal.

Note:

The script utltrace.sql is available in the ORACLE_INSTANCE/portal/admin/plsql/wwc directory on the Oracle Fusion Middleware Repository Creation Assistant CD-ROM. This CD-ROM is part of the Oracle Fusion Middleware CD-ROM Pack from which you installed Oracle Portal.

For Oracle Portal 11.1.1, the source code of utltrace.sql is available on Oracle Metalink at

http://metalink.oracle.com

2. Create a new DAD, for example portal_trc. Refer to the Oracle Fusion Middleware User's Guide for mod_plsql.

3. Click OK to go back to the PL/SQL properties for the HTTP Server.

4. In the DAD Status section, click the DAD that you created.Click Advanced, and then set the following values:

- PlsqlBeforeProcedure: portal.wwutl_trace.trace_on

- PlsqlAfterProcedure: portal.wwutl_trace.trace_off

5. Stop and start the HTTP Server and WLS_PORTAL.

Note:

The cookie for the new DAD must be the same as the portal DAD so that you can replace the DAD in the portal URL. If the cookie name for the new DAD is different from the portal DAD, then update the cookie name of the new DAD with that of the portal DAD.

Refer to Section 13.2.1, "Checking the PlsqlSessionCookieName Value" for details about checking or updating the cookie name.

6. Change the DAD in the Oracle Portal URL to the new DAD that you defined in Step 2 and use this URL to access Oracle Portal. For example, change:
http://<hostname>:<port>/portal/pls/portal/portal.home

to:

http://<hostname>:<port>/portal/pls/portal_trc/portal.home

After you set the event, two trace files will be written to the user_dump_dest directory. Open and view this file to check for any information about the unhandled exception error that you encountered.

G.2.2.2 Setting the sql_trace Parameter

You can enable tracing by setting the sql_trace database initialization parameter.

After setting an event, for the event to take effect, you must restart the database instance.

To enable tracing for all sessions in the database instance, set the sql_trace parameter to true in SPFILE using the following SQL syntax:

ALTER SYSTEM SET
sql_trace=true
COMMENT = 'turn tracing ON for all sessions'
SCOPE=SPFILE;

To turn tracing off, use the following syntax:

ALTER SYSTEM SET
sql_trace=false
COMMENT = 'turn tracing OFF for all sessions'
SCOPE=SPFILE;

If you are unfamiliar with the steps involved in updating a database initialization parameter file, refer to the section, "Managing Initialization Parameters Using a Server Parameter File", in the Oracle Database Administrator's Guide in the Oracle Database 11g documentation library.

G.2.2.3 Setting Database Event 10046

You can enable tracing for all sessions in a database instance by setting database event 10046. Event 10046 is the equivalent of setting the value of sql_trace to true in the parameter file. In addition, while setting event 10046, you can also specify the level of tracing.

Note:

Setting events should be done only with the help of Oracle Support Services.

Table G-1 describes different trace levels.

Table G-1 Trace Levels

Level

Description

1

Used to enable standard SQL_TRACE functions. This is the default value.

4

Used to enable standard SQL_TRACE functions and to trace bind values.

8

Used to enable standard SQL_TRACE functions and to trace waits.

This is used mainly for identifying latch wait, but it can also be used to identify full table scans and index scans.

12

Used to enable standard SQL_TRACE functionality and to trace bind values and waits.

Note:

When you set a database event, consider the following points:

- You cannot set an event when a database instance is running.

- You can set events without having to mount or open the database. You can run the command with the database instance in NOMOUNT state.

To enable tracing by setting database event 10046 in SPFILE, use the following syntax:

ALTER SYSTEM SET
EVENT = '10325 trace name context forever, level 10:10015 trace name context forever, level 1'
COMMENT = 'Debug tracing of control and rollback'
SCOPE=SPFILE;

If you are unfamiliar with the steps involved in updating a database initialization parameter file, refer to the section, "Managing Initialization Parameters Using a Server Parameter File", in the Oracle Database Administrator's Guide in the Oracle Database 11g documentation library.

G.2.3 Viewing the Diagnostic Output of Components

The various Oracle Portal components can have their diagnostic output configured. The following are the components:

- JPDK

- Portal Services

- Parallel Page Engine

- Oracle Fusion Middleware Portal Developer Kit

- Oracle Metadata Repository

- Oracle Web Cache

G.2.3.1 JPDK

Java Portal Development Kit (JPDK) provides a framework for the construction of Java-based portlets and portlet providers. A Java-based provider or Web provider is written as a Web application. The JPDK includes a logging mechanism that is controlled based on each Provider Adapter.

Table G-2 lists and describes the available logging levels. The acceptable logging level values range from 1 to 8 and build incrementally. For example, at logging level 3, the output for logging levels 1 and 2 are also recorded.

Table G-2 Logging Levels

Logging Level

Description

1

Configuration

2

Severe Errors

3

Warnings

4

Exceptions

5

Performance

6

Detailed Performance Information

7

Information

8

Debug

JPDK Log File Contents

Diagnostic information about a provider adapter is recorded in the servlet context log file named WLS_PORTAL-diagnostic.log.

There are two types of JPDK messages:

- Standard JPDK Messages

- Performance JPDK Messages

Standard JPDK Messages

Here is an example of a standard JPDK message that you might find in a Provider Adapter's WLS_PORTAL-diagnostic.log file:

07/12/31 02:58:59 jpdk: [instance=1926_EXPIRESSAMPLE_886361, id=1024597399815ApplicationServerThread-12,4] Beginning rendering of portlet: 1926_EXPIRESSAMPLE_886361

The content of the standard JPDK message is as follows:

- Date and time: 07/12/31 02:58:59

- Web application: jpdk

- ECID, sequence number: id=1024597399815ApplicationServerThread-12,4

- Portlet instance identifier: instance=1926_EXPIRESSAMPLE_886361

- Message: Beginning rendering of portlet: 1926_EXPIRESSAMPLE_886361

The portlet instance identifier identifies a specific portlet instance on a specific page, and can be broken down as follows:

- Internal sequence number: 1926

- Portlet name: EXPIRESSAMPLE

- Provider identifier: 886361

Additional details about some of these values are shown in Table G-3.

Table G-3 JPDK Standard Message Attributes

Value

Detail

ECID

Some messages carry null ECID and portlet instance identifier values. These are typically SOAP messages from the repository.

Portlet instance identifier

This is the same as ECID except that the portlet instance identifier is null in this case, because the message does not relate to a particular portlet instance.

G.2.3.2 Portal Services

Portal Services performance is logged through Oracle HTTP Server. The default directory for the error_log file is ORACLE_INSTANCE/Apache/Apache/log on UNIX and ORACLE_INSTANCE\Apache\Apache\log on Windows. Logging is controlled by the LogLevel parameter in the configuration file httpd.conf.

G.2.3.3 Parallel Page Engine

The Parallel Page Engine (PPE) is a shared server process servlet that accepts data representing a page layout, and then converts this data into a page containing portlets.

PPE logging can be controlled at the servlet and request level. If a request logging level is not specified, then the servlet level is used for the request. If both servlet and request logging levels are specified, then the higher of the two is used for the request.

Servlet-level Logging

Diagnostic logging setting for Oracle Portal is maintained in the logging.xml file of the WLS_PORTAL instance (DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL).

By default, the logging level is NOTIFICATION:1, which is set at logger "oracle". The Portal logger oracle.portal is the child of the oracle logger and it inherits the logging level of the parent if it is not specified in logging.xml. If needed, you can set logger oracle.portal to have its own logging level. For example:

<logger name="oracle.portal" level="FINE"/>

Performance logging is set in appConfig.xml (DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration\appConfig.xml). By default, it is set to off.

<perfLogMode>off</perfLogMode>

You can turn it on by specifying either on or perf. Performance logging output will be sent to the same target as diagnostic logging.

Table G-4 describes how setting the level for the oracle.portal logger affects the logging output from the PPE.

Table G-4 Logging Levels and Description

Log Level

Description

None

No messages.

Severe

No debug messages, provides information on warnings and errors.

Config

No debug messages, provides information on configuration related messages.

Fine

Provides information on configuration related messages and general debug messages.

Finer

Provide all the information in Fine log level and details of requests made by the PPE.

Finest

Provide all the information in Finer log level and details of the content of requests made by the PPE and metadata parsing.

Request-Level Logging

PPE request-level logging is controlled by the _debug URL parameter. For example, to specify request-level logging for the following URL:

http://myserver.myplace.com:3000/portal/page?_pageid=111&_dad=myDAD&_schema=mySchema

You must manually insert the following:

&_debug=3

The resultant URL is as shown:

http://myserver.myplace.com:3000/portal/page?_pageid=111&_dad=myDAD&_schema=mySchema&_debug=3

Table G-5 lists the values for _debug.

Table G-5 PPE Request Log Levels

Value

Detail

0

Activates page-debugging information

1

Activates page-debugging information

2

Logs to page and sets the request log mode to debug

3

Logs to page and sets the request log mode to request

4

Logs to page and sets the request log mode to content

5

Logs to page and sets the request log mode to parsing

Page Logging

With _debug set to 2, 3, 4, or 5, page logging is activated. This means that messages logged for the request are recorded in the PPE log file, and in the page returned.

Page logging is a means by which you can obtain detailed information relating to a request. As a result, it is also a security issue, for which the urlDebugMode servlet initialization argument is provided.

The urlDebugMode argument can be found alongside oracle.portallogger in the Portal appConfig.xml file (DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration\appConfig.xml):

<urlDebugMode>4</urlDebugMode>

Table G-6 lists the values for the urlDebugMode argument. The default value is 1.

Table G-6 PPE urlDebugMode Levels

Value

Detail

None

Ignore the _debug URL parameter.

0

Allow _debug to be 0.

1

Allow _debug to be 0 or 1.

2

Allow _debug to be 0, 1, or 2.

3

Allow _debug to be 0, 1, 2, or 3.

4

Allow _debug to be 0, 1, 2, 3, or 4.

5

Allow _debug to be 0, 1, 2, 3, 4, or 5.

PPE Log File Contents

PPE diagnostic messages are recorded in the servlet context WLS_PORTAL-diagnostic.log file. This file can be found at:

DOMAIN_HOME\servers\WLS_PORTAL\logs

There are two types of PPE messages:

- Standard PPE Messages

- Performance PPE Messages

Standard PPE Messages

The following is an example of a standard PPE message found in its log file:

03/12/31 11:54:35 portal: id=22020914339,0 DEBUG: active=53  ContentFetcher
Unexpected Exception Request Failed:java.lang.IllegalArgumentException
name=content-fetcher52 label=dbPortlet url=https://abc.company.com:5001/pls/ptl_
9_0_4_0_87/!PTL_9_0_4_0_87.wwpro_app_provider.execute_portlet/391497559/4
time=38975ms timeout=15000ms process=ResponseHeaders

The content of this standard PPE message is as follows:

- Date and time: 03/12/31 11:54:35

- Web application: portal

- logmode flag: DEBUG

- Active count: active=53

- ECID: id=22020914339, 0

- Message: ContentFetcher Unexpected Exception Request Failed

Table G-7 provide details relating to some of these values.

Table G-7 PPE Standard Message Attributes

Value

Detail

logmode flag

Indicates that log mode is debug or higher. If logmode is set to perf and is therefore lower than debug, then the logmode flag is not included in the message.

Active count

Indicates the number of threads in the PPE thread group. If logmode is set to perf and is therefore lower than debug, then the active count is not included in the message.

ECID

Can be null. A message with such a value relates to a PPE background task (such as clearing pooled objects). Background tasks do not relate to a request, and therefore do not have an ECID specified.

Performance PPE Messages

The following is an example of a performance PPE message found in the log file:

07/06/16 06:06:37 portal: [perf] 140.87.20.124
https://abc.company.com:8250/portal/ page?_pageid=40,1&_dad=portal&_
schema=PORTAL&_mode=16 id=8198110376563,1 type=page name=40,1 status=200
user=PORTAL subscriberID=1 reqTime=187ms waitTime=0ms cache=(null) timeout=No
redirects=0 bytes=33865 authLevel=10 webCacheStatus=(null) webCacheExpires=(null)
webCacheAge=(null) csConv=No readTime=No,0ms pageTimeout=No procTime=0ms

G.2.3.4 Oracle Fusion Middleware Portal Developer Kit

Oracle Fusion Middleware Portal Developer Kit (PDK) provides a framework for the construction of portlets and portlet providers in a variety of Web languages including Java, Web Services, XML, ASP, Perl, and PL/SQL. The PDK therefore includes JPDK.

The PDK provides a core logging mechanism, which is augmented by logging in specific developers kits. PDK logging is controlled through a Web-based user interface as shown in Figure G-3.

Figure G-3 PDK Logging Page

This PDK Logging Page can be found at:

http://<host>:<port>/portal/pls/<dad>/<schema>.wwpro_log.render

A sample URL is as follows:

http://myserver.myplace.com:3000/portal/pls/portal/PORTAL.wwpro_log.render

From this page you can apply the logging levels described in Table G-8.

Table G-8 PDK Log Levels

Level

Detail

No debugging

No logging

PROHTTPJ

Provider framework logging

PROGRP

Provider logging

ADAPTER

Federated portal adapter logging

CACHE

Cache logging

FORCE

Internal to Oracle

INVAL

Invalidation logging

PROREG

Provider registration logging

PROLOGIN

Page metadata generation, login, and session initialization logging

PROPROV

Provider communication logging

PROPMR

Portlet metadata repository logging

PROHTTP

Web provider framework logging

All

All logging levels activated

PDK Log File Contents

You can view PDK log entries from the same page used to configure PDK logs, as shown in Figure G-4.

Figure G-4 Log Entries in the PDK Logging Page

G.2.3.5 Oracle Metadata Repository

Oracle Metadata Repository consists of all the metadata, portal content, and PL/SQL code that reside in the Oracle Portal database schema. The PL/SQL code that executes in the Oracle Portal schema also generates diagnostics output that can be correlated with diagnostics output generated from the other components of Oracle Portal.

Because the log file is produced by Oracle Metadata Repository, the database running Oracle Portal must be configured to allow this. To do this, you must use the CREATE DIRECTORY statement to create a directory object.

A directory object specifies an alias for a directory on the server file system where external files and external table data are located.

Note:

All directories are created in a single namespace and are not owned by an individual schema. You can secure access to the files stored within the directory structure by granting object privileges on the directories to specific users.

To use the CREATE DIRECTORY statement, you must have the CREATE ANY DIRECTORY system privilege. When you create a directory, you are automatically granted the READ and WRITE object privileges on that directory. You, or the database administrator, can in turn grant these privileges to other users and roles.

Note:

WRITE privileges on a directory are useful in connection with external tables. They let the grantee determine whether the external table agent can write a log file or a bad file to the directory.

You must also create a corresponding operating system directory for file storage. Your system or database administrator must ensure that the operating system directory has the correct READ and WRITE privileges for Oracle Database processes

Privileges granted for the directory are created independently from the privileges defined for the operating system directory, and the two may, or may not, correspond exactly. For example, an error occurs if a sample user hr is granted READ privilege on the directory object, but the corresponding operating system directory does not have READ privilege defined for the Oracle Database processes.

To create a directory object, use the following syntax:

CREATE [OR REPLACE] DIRECTORY AS 'path_name';

Table G-9 describes the parameters used in CREATE DIRECTORY syntax.

Table G-9 CREATE DIRECTORY Parameters

Semantics

Description

OR REPLACE

Specify OR REPLACE to re-create the directory database object, if it already exists. You can use this clause to change the definition of an existing directory without deleting, re-creating, and regranting database object privileges previously granted on the directory.

Existing users with privileges to access a redefined directory can to access the directory without being granted the privileges again.

directory

Specify the name of the directory object to be created. The maximum length of the directory name is 30 bytes. You cannot qualify a directory object with a schema name.

Oracle Database does not verify that the directory you specify actually exists. Therefore, you must ensure that you specify a valid directory in your operating system. In addition, if your operating system uses case-sensitive path names, then be sure to specify the directory in the correct format. You need not include a trailing slash at the end of the path name.

path_name

Specify the full path name of the operating system directory of the server where the files are located. The single quotation marks are required, with the result that the path name is case-sensitive.

For example, the following statement creates a directory database object that points to a directory on the server:

CREATE DIRECTORY admin AS 'oracle/admin';

The following statement redefines the bfile_dir directory database object to enable access to files stored in the operating system directory /private1/lob/files:

CREATE OR REPLACE DIRECTORY bfile_dir AS '/private1/LOB/files';

In the case of Oracle Database releases earlier than 9.2, for the PL/SQL code to generate diagnostics output, update the database initialization parameter file by adding the following line:

UTL_FILE_DIR=<directory where you want to write the log file>

If you are unfamiliar with the steps involved in updating a database initialization parameter file, refer to the section, "Managing Initialization Parameters Using a Server Parameter File", in the Oracle Database Administrator's Guide in the Oracle Database 11g documentation library.

There can be many UTL_FILE_DIR entries, so if the directory you wish to write to is already defined, then there is no need to modify this file.

Note:

On installing of Oracle Metadata Repository, if the database you are installing into has the UTL_FILE_DIR parameter set, then the Oracle Portal installer configures Oracle Metadata Repository such that it uses the first directory defined by the database parameter as the location for the Oracle Metadata Repository log file. If the UTL_FILE_DIR directory is not configured, then Oracle Metadata Repository logging is not set up on installation.

Oracle Metadata Repository logging is performed through a logging package. This logging package is controlled using the script logcfg.sql which you must run from SQL*Plus.

The logcfg.sql script can be found at:

ORACLE_INSTANCE/portal/admin/plsql/wwc

The logcfg.sql script can take five parameters in the following order: log_level, log_state_level, log_format, log_file, and log_directory. If less than five parameters are supplied, then one or more values are requested. If no value is received in response to this request, then the current value is maintained.

Table G-10 details the logcfg.sql parameters.

Table G-10 Repository Logging Package Parameters

Parameter

Detail

log_level

Describes the level of messages recorded. The values are the following:

- 0: None

- 1: Error

- 2: Warning

- 3: Information

- 4: Trace

- 5: Debug

- 6: Fine Debug

The values build incrementally. The default value is 1.

log_state_level

Describes the level of messages for which state information will automatically be logged. The values are the following:

- 0: None

- 1: Error

- 2: Warning

- 3: Information

- 4: Trace

- 5: Debug

- 6: Fine Debug

The values build incrementally.

log_format

Describes the format of automatically recorded context information, which is different from state information. The values are the following:

- 0: Simple

- 1: Detailed

log_file

Specifies the name of the log file to write to. An attempt is made to create this file if it does not already exist.

log_directory

Specifies the directory in which the log_file parameter exists. This value can be either a physical path or a directory object. If the value is a physical directory, it must be defined in the database parameter file under the UTL_FILE_DIR property. For example:

utl_file_dir=/export/home/oracle/as1014/logs

If the database parameter file is modified, then the database must be restarted for this change to take effect.

If the value is a directory object, then you must specify the directory object name in uppercase. For example, LOGS.

For example, you can run the logcfg.sql script from SQL*Plus as follows:

@logcfg.sql 3 3 1 portal.log /export/home/oracle/as1014/logs

If you point to a directory object instead, then you must specify the directory object name in uppercase. For example, to point to a directory object named logs, you must run the logcfg.sql script from SQL*Plus as follows:

@logcfg.sql 3 3 1 portal.log LOGS

After running logcfg.sql, the usage is displayed:

Configure Portal diagnostics
usage:
logcfg.sql <log_level> <log_state_level> <log_format> <log_file> <log_directory>
If for any of the params a null value is specified the existing value will be maintained.
Log levels:
0 : None (turn diagnostics off)
1 : Error
2 : Warning
3 : Information
4 : Trace
5 : Debug
6 : Fine Debug
Log formats:
0 : Simple
1 : Detailed

The current values are also displayed:

Current settings:
Log level:     3
Log state level:     3
Log format:     1
Log file:     portal.log
Log directory:     /export/home/oracle/as101202/dblogs

To truncate the Oracle Metadata Repository diagnostics log file, run the SQL script logtrunc.sql located at: ORACLE_INSTANCE/portal/admin/plsql/wwc

Repository Log File Contents

The location of the Oracle Metadata Repository diagnostic information is dictated by the repository diagnostics package parameters log_file and log_directory.

The following is an example of an ERROR type message found in the Oracle Metadata Repository log file:

[06-AUG-2007 15:02:15] [ERROR] id=(102733434) ctx=wwsrc_simple_edit.render_simple_edit_prefs user=PORTAL subscriberId=1 language=us userAgent="Mozilla/5.0" ip=192.0.0.1
ORA-30625: method dispatch on NULL SELF
[START-ERROR-STACK]
ORA-30625: method dispatch on NULL SELF
[END-ERROR-STACK]
[START-CALL-STACK]
----- PL/SQL Call Stack -----
object          line          object
handle          number        name
81b35e6c        350           package body PORTAL.WWLOG_API_DIAG
81b35e6c        443           package body PORTAL.WWLOG_API_DIAG
81b35e6c        526           package body PORTAL.WWLOG_API_DIAG
86765ac8        259           package body PORTAL.WWSRC_SIMPLE_EDIT
86765ac8        334           package body PORTAL.WWSRC_SIMPLE_EDIT
84317130        19            package body PORTAL.WWSBR_BASIC_SEARCH
88857980        713           package body PORTAL.WWSBR_SITEBUILDER_PROVIDER
8323ad18        1             anonymous block
87e53d5c        648           package body PORTAL.WWPRO_API_PROVIDER
81ae1e50        2644          package body PORTAL.WWPOB_PAGE
877a0d9c        12            anonymous block
[END-CALL-STACK]
[START-QUERY-STRING]
_providerid=102274117
_portletid=14
_mode=5
_title=Basic%20Search
_referencepath=1875_BASICSEARCH_102274117
_back_url=http%3A%2F%2Fmyserver.myplace.com%3A3000%2Fpls%2Fportal%
_portlet_reference=33_31293_33_1_1
[END-QUERY-STRING]

The message in the log file is as follows:

ORA-30625: method dispatch on NULL SELF: - The message itself.

The log file also has context and state information.

Context Information

Context information is produced in one of two formats, detailed or simple, as specified by log_format parameter. In the following example, the format is detailed:

- 06-AUG-2007 15:02:15: Date and time

- ERROR: Message level

- id=(102733434, 1): ECID

- ctx=wwsrc_simple_edit.render_simple_edit_prefs: Message context

- user=PORTAL: Database user

- subscriberId=1: Subscriber identifier

- language=us: Globalization Support language

- userAgent="Mozilla/5.0": User agent

- ip=192.0.0.1: Client IP address

The simple format is a subset of the detailed format and includes the following information:

- 06-AUG-2007 15:02:15: Date and time

- ERROR: Message level

- ctx=wwsrc_simple_edit.render_simple_edit_prefs: Message context

Table G-11 provides additional details relating to some of these values.

Table G-11 Repository Context Attributes

Value

Detail

Client IP address

Typically, this is the IP address of the client browser or HTTP proxy in use. Because the Oracle Portal page assembly process uses loopback calls, the IP address can also represent the middle tier itself.

Subscriber identifier

This identifies which subscriber has accessed the repository.

User agent

This is description of the browser in use.

State Information

State information consists of the error stack, call stack, and a query string. Examples of each of these are as follows:

Note:

The PL/SQL error stack is displayed only if a message of type ERROR is logged.

Error stack:

[START-ERROR-STACK]
ORA-30625: method dispatch on NULL SELF
[END-ERROR-STACK]

Call stack:

[START-CALL-STACK]
----- PL/SQL Call Stack -----
object          line        object
handle          number      name
81b35e6c        350         package body PORTAL.WWLOG_API_DIAG
81b35e6c        443         package body PORTAL.WWLOG_API_DIAG
81b35e6c        526         package body PORTAL.WWLOG_API_DIAG
86765ac8        259         package body PORTAL.WWSRC_SIMPLE_EDIT
86765ac8        334         package body PORTAL.WWSRC_SIMPLE_EDIT
84317130        19          package body PORTAL.WWSBR_BASIC_SEARCH
88857980        713         package body PORTAL.WWSBR_SITEBUILDER_PROVIDER
8323ad18        1           anonymous block
87e53d5c        648         package body PORTAL.WWPRO_API_PROVIDER
81ae1e50        2644        package body PORTAL.WWPOB_PAGE
877a0d9c        12          anonymous block
[END-CALL-STACK]

Query string:

[START-QUERY-STRING]
_providerid=102274117
_portletid=14
_mode=5
_title=Basic%20Search
_referencepath=1875_BASICSEARCH_102274117
_back_url=http%3A%2F%2Fmyserver.myplace.com%3A3000%2Fpls%2Fportal%
_portlet_reference=33_31293_33_1_1
[END-QUERY-STRING]

Repository Diagnostics Log File Registration

Oracle Enterprise Manager 11g provides a Log Reader and Log Viewer. The Log Reader allows administrators to upload log files to a file-based log repository. The Log Viewer allows administrators to view and query log entries loaded into the repository. See Section G.2.4, "Using Fusion Middleware Control Log Viewer" for more information.

To load and view the Repository Diagnostics log file entries, you must first register the log file with Oracle Enterprise Manager 11g. To do this, edit the following file:

ORACLE_INSTANCE/diagnostics/config/registration/PORTAL.xml

In this file, there is a template entry that you can copy and expand to reflect details of your log file. The template is as follows:

<logs xmlns="http://www.oracle.com/iAS/EMComponent/ojdl" helpIDLogs="psm_cs_xml_log_info">

<!--
<log path="<PATH>" componentId="PORTAL">
<logreader type="SimpleTextLog">
<property name="ComponentId" value="PORTAL"/>
<property name="ModuleId" value="Portal:<INSTANCE>"/>
<property name="TimestampFormat" value="[dd-MMM-yyyy HH:mm:ss]"/>
<property name="TimestampLocale" value="en_US"/>
</logreader>
<logviewer ComponentName="ID_VLOGS_PORTAL_REP@ResourceBundle"
LogType="ERROR"
LogName="Diagnostics for Portal instance <INSTANCE>"/>
</log>
-->

</logs>

Modify the following information in the copied template entry:

- <PATH>: The absolute path and file name of the log file.

- <INSTANCE>: The name of the Oracle Portal target in Oracle Enterprise Manager 11g, if it is defined. If there is no corresponding Oracle Portal target in Oracle Enterprise Manager 11g, then use the name of the Oracle Portal instance and database details, for example, <portal schema name>-<db service name>. This value is used to distinguish this log entry in the Log Viewer from other Oracle Portal instance log entries.

After you have saved the new PORTAL.xml entry, the Log Reader starts uploading the log file periodically, and you can use the Log Viewer to view and query this log file.

Because the Oracle Metadata Repository can be accessed through many middle tiers, you need to do the following:

- Register the Repository Diagnostics log file with one of the Oracle Enterprise Manager 11g Fusion Middleware Control instances that is monitoring an Oracle Portal middle tier.

- If the Oracle Portal database is on a computer other than the Oracle Portal middle tier, ensure that the log file is accessible over a network file system.

- To perform log correlation in a multiple middle-tier environment, you need to register the Repository Diagnostics log file with each Oracle Enterprise Manager 11g instance monitoring an Oracle Portal middle tier.

Note:

Using Oracle Enterprise Manager 11g, you have to update the location of the Repository Diagnostics log file in the PORTAL.xml file located at ORACLE_INSTANCE/diagnostics/config/registration/.

G.2.3.6 Oracle Web Cache

Oracle Web Cache events and errors are stored in an event log. The event log helps you to determine which documents or objects have been inserted into the cache. It can also identify listening port conflicts or startup and shutdown issues. By default, the event log has a file name of event_log and is stored in ORACLE_INSTANCE/webcache/logs on UNIX and ORACLE_INSTANCE\webcache\logs on Windows.

See Also:

Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache

G.2.4 Using Fusion Middleware Control Log Viewer

You can use Oracle Enterprise Manager 11g Fusion Middleware Control to view and query entries from the following log files. This helps you to diagnose issues relating to Oracle Portal. The relevant Oracle Fusion Middleware component log files include the following:

- Portal:<instance>: Displays a single, diagnostic error log file for each portal instance named <customer_specified_log_name>. This log file is generated by the relevant Oracle Metadata Repository.

- HTTP_Server: Displays multiple error or access log files named error_log and access_log. These log files contain all relevant Portal Service logging information.

- WLS_PORTAL: Displays multiple application log files named WLS_PORTAL-diagnostic.log. This log file contains all relevant PPE logging information.

- Web Cache: Displays error and access log file names event_log and access_log.

Before you can use the Oracle Metadata Repository log file with Fusion Middleware Control Log Viewer, you must complete a registration process. Refer to the section "Repository Diagnostics Log File Registration" for instructions.

If your JPDK WLS instance is not located in the Oracle Portal middle tier Oracle home, then you may view its log file only through the local Fusion Middleware Control instance. If you want to perform diagnostic correlation, then you must follow a similar remote registration process to that described for the Oracle Metadata Repository log file when it is remotely located.

In addition to viewing the log file entries with Oracle Fusion Middleware Control Log Viewer, you can also perform advanced diagnostics by correlating entries across log files using the ECID value. See Section G.2.1, "Enabling ECID Logging" for more information. This drill-down correlation is automatically provided by the Oracle Fusion Middleware Control Log Viewer.

To view log file entries, click Logs, which is located at the top and bottom of every Oracle Fusion Middleware Control component home page.

See Also:

For detailed instructions on how to use the Log Viewer, refer to the Oracle Fusion Middleware Administrator's Guide. It describes how to perform advanced queries for diagnostic log file information, search through diagnostic messages (collected from selected Oracle Fusion Middleware components) in the Log Repository, and correlate messages across log files and components.

G.2.5 Using Oracle Portal Diagnostics Assistant

Use Oracle Portal Diagnostics Assistant to gather information if you are troubleshooting issues after Oracle Portal installation. Problems can vary from accessing the Oracle Portal, to users getting errors at different levels within Oracle Portal.

You can diagnose issues by reviewing the results from Oracle Portal Diagnostics Assistant. Alternatively, you can upload the results to Oracle Support Services so that they can assist in troubleshooting the problem for you.

The generated report includes the following sections:

- Errors and violations summary (available only if violations are detected by Oracle Portal Diagnostics Assistant)

- Oracle Portal Repository database information

- OracleAS Single Sign-On database information

- Oracle Internet Directory diagnostics report

- Oracle Text diagnostics report

- Apache error log file analysis

In addition, all Oracle Portal-related configuration files and log files are collected and zipped for your convenience.

To run Oracle Portal Diagnostics Assistant, you need to use the script pda.csh (UNIX) or pda.cmd (Windows). Each time you run the script, a new directory is created for the generated files under the directory where you downloaded the Oracle Portal Diagnostics Assistant zip file. The directory names have a timestamp format, for example, 070623132344 which means:

Year: 07
Month: 06
Day: 23
Hour: 13
Minutes: 23
Seconds: 44

After running Oracle Portal Diagnostics Assistant, locate the appropriate directory and open the HTML report named pda.htm in a browser window. You can navigate through the report and review the diagnostics information.

If you want Oracle Support Services to assist you in troubleshooting the problem, then log on to Oracle Metalink at http://metalink.oracle.com, and upload the generated ZIP file named PDA<directory_name>.zip, for example, PDA040623132344.zip.

For detailed information about using Oracle Portal Diagnostics Assistant and the information collected, refer to the readme file located in the directory in which you downloaded Oracle Portal Diagnostics Assistant.

Running Oracle Portal Diagnostics Assistant

To generate diagnostics information using Oracle Portal Diagnostics Assistant, perform the following steps:

1. Check the Support and Metalink section on OTN for the latest update/patch information for Oracle Portal Diagnostics Assistant at:
http://www.oracle.com/technology/

Download the latest Oracle Portal Diagnostics Assistant script. Support/Upgrade is located in the Product Information section.

2. Ensure that the ORACLE_INSTANCE environment variable is set to the correct Oracle Portal middle tier Oracle home directory.
If you try to run Oracle Portal Diagnostics Assistant from a database Oracle home directory, it fails and no diagnostics information is collected.

3. Navigate to the location where you downloaded and unzipped Oracle Portal Diagnostics Assistant.

4. Run Oracle Portal Diagnostics Assistant on UNIX as follows:

pda.csh
-schema <portal schema name>
-password <portal schema password>
-connect <Portal connect string>
-ssoSchema <SSO schema name>
-ssoPassword <SSO schema password>
-ssoConnect <SSO connect string>
[-apacheLogDir <directory name>]
[-apacheLogName <file name>]
[-logFileLimit <number of rows>]
[-show]
[-showall]

Run the script without any parameters to get Help information.

Table G-12 lists and describes the parameters used with the Oracle Portal Diagnostics Assistant script.

Table G-12 Oracle Portal Diagnostics Assistant Script Parameters

Parameter

Description

-schema

Name of the Oracle Portal schema. This parameter is mandatory. Default = Portal.

-password

Password for the Oracle Portal schema. This parameter is mandatory. Default = portal_schema.

-connect

Connect string for the Oracle Portal schema. Use the format <host>:<port>:<sid>. This parameter is mandatory.

-ssoSchema

Name of the OracleAS Single Sign-On schema. This parameter is mandatory.

-ssoPassword

Password for the OracleAS Single Sign-On schema. This parameter is mandatory.

-ssoConnect

Connect string for the OracleAS Single Sign-On schema. Use the format <host>:<port>:<sid>. This parameter is mandatory.

-apacheLogDir

Directory for Oracle HTTP Server error log file. This parameter is optional. Default = ORACLE_INSTANCE/Apache/Apache/logs.

-apacheLogName

Error log file name. This parameter is optional. Default = error_log.

-logFileLimit

The number of rows in the error log file. This parameter is optional. Default = 10000.

-show

Generates diagnostics information with only the necessary set of queries. This is the default mode for generating diagnostics information when no other parameters are selected.

-showall

Generates diagnostics information with all the queries. This mode has an additional query that retrieves all the portal objects and their privileges from the relevant security table. Because of this, generating diagnostics information in the -showall mode takes a very long time.

The following is an example of running Oracle Portal Diagnostics Assistant on a Unix platform:

# Set the environment
#
setenv ORACLE_INSTANCE /oracle/productsAS
#
# Run PDA
#
pda.csh \
-schema portal  \
-password <portal_password>  \
-connect abc.oracle.com:1521:orcl1 \
-ssoSchema orasso \
-ssoPassword <orasso_password> \
-ssoConnect defg.oracle.com:1521:orcl2
-show

Run Oracle Portal Diagnostics Assistant on Windows as follows:

1. Start up a command prompt, and run the following command:

pda.cmd
-schema <portal schema name>
-password <portal schema password>
-connect <Portal connect string>
-ssoSchema <SSO schema name>
-ssoPassword <SSO schema password>
-ssoConnect <SSO connect string>
[-apacheLogDir <directory name>]
[-apacheLogName <file name>]
[-logFileLimit <number of rows>]
[-show]
[-showall]

Run the script without any parameters to get help information.

Table G-12 lists and describes the parameters used with the Oracle Portal Diagnostics Assistant script.

5. Open the latest HTML report (pda.htm) in a browser window and use the information to help diagnose any Oracle Portal issues.

G.2.6 Analyzing Mobile-Related Problems in Oracle Portal

Mobile devices do not provide good interfaces for displaying detailed error information when compared with standard desktop browsers. The following information will help you analyze mobile-related problems in Oracle Portal.

Using the _debug parameter

All Oracle Portal pages can be run in a special mode where timing and caching information is displayed. If you append the _debug=1 parameter to a page URL, then extra timing information is added to the response that is displayed.

If you want to see the debug information for a few select pages and portlets, you can control the logging level by using the _debug URL parameter. Valid values for _debug are 0, 1, 2, 3, 4, and 5. For details about timing and caching statistics, refer to Section B.6, "Timing and Caching Statistics".

You may encounter problems in using the _debug URL parameter for mobile browser access because of the following reasons:

- The URL that the mobile device uses to access Oracle Portal refers to an OracleAS Wireless service and not Oracle Portal. Therefore, you cannot directly append the _debug=1 parameter to the URL in the mobile browser.

- The method used for rendering information for a mobile device requires the response page to be valid OracleAS Wireless XML. Because the extra information may not be valid OracleAS Wireless XML, it cannot be added inline to a mobile response page.

To resolve this problem and to use the _debug parameter, perform the following tasks:

1. Create a new service in the OracleAS Wireless server to access a page directly, instead of using the default portal service that is registered with OracleAS Wireless. Specify a URL with a format similar to the following:

http://<host.domain>:<port>/portal/pls/portal/MyGroup/MyPage?_debug=1

2. Request the new service not the default portal service in the mobile device.

3. View the servlet log file for the recorded performance information. This information will be in a format similar to the following:

4/23/02 5:38 AM portal: [perf] Information for Portlet 33,31071.
Portlet Timing: 234 msecs (wait=0)
Timing Status:
XSLT Timing: null msecs
Caching information of portlet:
Portlet Cache status:  <I>Web Cache:-</I> MISS,NON-CACHEABLE [N], <I>File System Cache:-</I> MISS,NEW
From Cache:  <I>Web Cache:-</I> -,  <I>File System Cache:-</I> None
From Portlet: Cache Key: NORMAL, Cache Level: USER

4/23/02 5:38 AM portal: [perf] Information for Page 33%2C31060%2C33_31062
Elapsed Time: 2470 msecs
Page meta-time 7 msecs (wait = 994)
Page meta Cache Status:  <I>Web Cache:-</I> MISS,NON-CACHEABLE [N], Cache Expires: null secs, Age in Cache: null secs ,  <I>File System Cache:-</I> MISS,NEW
Login meta-time 1227 msecs (wait = 1)
Login meta Cache Status:  <I>Web Cache:-</I> MISS,NON-CACHEABLE [N], Cache Expires: null secs, Age in Cache: null secs

Mobile Information Useful for Support

If you are not able to resolve mobile-related problems by using the troubleshooting steps described in Section G.1.20, "Problems in Accessing Oracle Portal from a Mobile Device" then contact Oracle Support Services. It would be helpful if you have answers to the following questions before you contact Oracle Support Services:

1. What are the symptoms of the error? For example, did you get error messages, was there a lack of response, or was a blank screen displayed?

2. What is the context of the error?

- Was the user logged on?

- Do all authenticated users experience the same problem?

- Does the public user experience the problem?

- Does the problem occur during the logon phase?

- How far did the user get in logging on?

- Did the user try to log on in the standard manner, or was the user directed to log on?

- Does the problem occur when viewing a page?

- Describe the page structure.

- Do any portlets allow titles to be personalized?

- Can the page be previewed using a standard desktop browser without having OracleAS Wireless in the communication network?

- Does the problem occur when viewing an individual portlet?

- Does the problem occur on all mobile pages, a few pages, or one page?

3. If possible, run the portal service through the OracleAS Wireless debug tool. This requires specific OracleAS Wireless access. For details, refer to the Oracle Application Server Wireless Administrator's Guide.

4. Is there a record for the problem in any of the log files listed in Table G–13?

Table G-13 Error Log Files and Locations

Log Files

Location

OracleAS Wireless Server log files

ORACLE_INSTANCE/wireless/logs/sys_panama.log or /var/tmp/sys_panama.log

Server JVM standard output:

ORACLE_INSTANCE/opmn/logs/OC4J_Wireless_default_island/application.log

Provider JVM standard output:

ORACLE_INSTANCE/j2ee/OC4J_wireless/application-deployments/portal/WLS_OC4J_default_island/application.log

Oracle HTTP Server log files

ORACLE_INSTANCE/Apache/Apache/logs/access_log/application.log and ORACLE_INSTANCE/Apache/Apache/logs/error_log

Parallel Page Engine Server log file

ORACLE_INSTANCE/j2ee/WLS_PORTAL/application-deployments/portal/WLS_PORTAL_default_island_1/application.log

G.2.7 Enabling Performance Logging

To enable performance logging in Oracle Portal, perform the following steps:

1. Open logging.xml, which is located in the DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL directory.

2. Add a logger element with the name as oracle.portal and the level as Notification:16 in the following format:
<logger name="oracle.portal" level="NOTIFICATION:16"/>

Note:

To disable performance logging, either remove the preceding line from logging.xml or change the level to ERROR:1.

3. Restart the WLS_PORTAL server.

The log entries are written to the WLS_PORTAL-diagnostic.log file in the DOMAIN_HOME/servers/WLS_PORTAL/logs directory.

Note:

- To enable mod_plsql performance logging in the Oracle Portal mid tier, set the LogLevel directive to info in the httpd.conf file, which is located in ORACLE_INSTANCE/config/OHS/ohs_component_name (the default name of the OHS component is ohs1).
For the LogLevel directive to take effect, you should also set the OraLogMode directive to apache in the httpd.conf file and restart the OHS server.

For more information see "Log Directives for Oracle HTTP Server" in the Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server.

- To enable performance logging for Oracle Web Cache, configure access logs as described in "Configuring Access Logs" in the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache

G.3 Need More Help?

You can find more solutions on Oracle MetaLink at

http://metalink.oracle.com

If you do not find a solution for your problem, then log a service request.

To help Oracle Support Services troubleshoot the problem, perform the following steps:

1. Run Oracle Portal Diagnostics Assistant.
You can diagnose portal-related issues by reviewing the report generated by Oracle Portal Diagnostics Assistant. You can also refer to Section G.2.5, "Using Oracle Portal Diagnostics Assistant" for more information.

2. Contact Oracle Support Services.
If you cannot establish why your portal is not accessible, then contact Oracle Support Services. To help Oracle Support Services troubleshoot the problem, provide the following information:

- ZIP file generated by Oracle Portal Diagnostics Assistant.

- Details of any command-line scripts that you have run (for example, ptlconfig) including all the parameters used.

- A rough network diagram, showing how your Oracle Fusion Middleware components are configured.

See Also:

Oracle Fusion Middleware Release Notes for Microsoft Windows (32-Bit), available on OTN http://www.oracle.com/technology/documentation/index.html

Index
A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  Q  R  S  T  U  V  W  X

A

access

enforcement, 7.1.4

model, 7.1.4

access control lists, 7.1.9.2, 7.1.9.4, 12.4.1.1.2, 12.4.1.1.3, 12.6.1.2 accessing

port information, 8.4

ACLs, 7.1.9.4 activity log views, 8.3.3 activity reports, 8.3 adding

subscribers, F.2.3, F.5

addsub.csh, F.8 administering OmniPortlet

configuring caching, E.2.1.3

configuring OmniPortlet, E.2

configuring the repository, E.2.1.2

copying the library for HTTPS access, E.2.1.4

administering Web clipping

configuring security

adding certificates for trusted sites, 7.1.12.1

advanced security option (ASO), 7.1.12.2

configuring Web clipping portlet, E.1 configuring Web clipping repository, E.1.1 manually configuring caching, E.1.4.1 manually setting proxy settings, E.1.3 restricting clipping from unauthorized external Web sites, E.1.3.1 setting advanced security option (ASO) parameters, 7.1.12.2 using Web clipping provider test page

advanced security option (ASO), 7.1.12.2

administration

access to, 7.3.2.3.6

global privileges, 7.1.3.1

administrative tools, 5.1.2 administrator role

example, 7.1.7.10.1

Advanced Search link

configuring, 10.2.1.3

defaults, 10.1.3

Advanced Search portlet, 10.1.1, 10.1.1, 10.1.1, 10.1.1, 10.1.1

defaults, 10.1.3

Internet search engine link, 10.2.1.4

Oracle Text enabled/disabled, 10.3.1

search result page, 10.2.1.1

agent

Directory Integration and Provisioning, 7.1.7.3.4

aliases

site for Oracle Web Cache and SSL, 7.3.2.1.4

application entity, 7.1.7.3.1

password, 7.3.2.3.10

Application Server Control

viewing log files, G.2.4

viewing port information, 8.4

application service provider, F.1.1 application.log, G.2.3.1

OmniPortlet provider, G.1.18

applications

mod_osso, 7.1.9.7.1

security, 7.1.9.7

security for external, 7.1.9.7.2

approvals

creating BPEL process definition, 5.5.3

deleting BPEL process definition, 5.5.5

editing BPEL process definition, 5.5.4

architecture

security, 7.1.1, 7.1.7

ASP, F.1.1

users and groups, F.4

audience, Preface AUTHENTICATED_USERS group, 7.1.2.2 authentication

basic, 7.3.1.3.1

enhanced, 7.3.1.3.2

HMAC, 7.3.1.3.1

model, 7.1.4

authorization, 7.1.4

model, 7.1.4

AUTO_FILTER filter

character-set conversion, 10.3.3.7

MIME type conversion, 10.3.3.7

not working, 10.3.7

setting up library path, 10.3.2

use by Document and URL indexes, 10.3.3.1

AUTO_FILTER_FORMAT

API constants, D.3.2

settings, 10.3.3.7

B

basic page administration

changing page group quota, 5.3.6

creating personal pages, 5.3.3

removing the context-sensitive help link, 5.3.12

setting a default home page, 5.3.1

setting maximum file size for uploaded files, 5.3.5

setting the page users see when they log out, 5.3.10

setting the system default style, 5.3.2

setting total space allocated for uploaded files, 5.3.4

specifying an error message page, 5.3.8

specifying the default doctype setting, 5.3.11

Basic Search Box

defaults, 10.1.3

Oracle Text enabled/disabled, 10.3.1

search result page, 10.2.1.1

Basic Search portlet, 10.1.1, 10.1.1, 10.1.1, 10.1.1, 10.1.1

advanced search link, 10.2.1.3

defaults, 10.1.3

Oracle Text enabled/disabled, 10.3.1

search result page, 10.2.1.1

BPEL

message payload, 5.5.6, 5.5.7

process definition

creating, 5.5.3

deleting, 5.5.5

editing, 5.5.4

browser settings

troubleshooting, G.1.15, G.1.16

browsers

accessing Oracle Portal, 5.2.1

C

CA, 1.1.2, 7.1.9.10, 7.3.2.1.4, 7.3.2.1.4

cache

Oracle Internet Directory, 7.1.7.3.4

Oracle Web Cache, 8.2.2.4

Portal Cache, 8.2.2.3

Cache Operations page, OracleAS Web Cache Manager, 9.1.3.2.1 cacheEncryptionKey, 5.6.9.1 cache.xml file

Web Clipping and, E.1.4.1

caching

configuring

Web Clipping and, E.1.4.1

configuring OmniPortlet for, E.2.1.3 OmniPortlet, E.2.1.3 to improve performance, B.1 Web Clipping and, E.1.4 cachjsub.sql, B.1, B.1 case study

virtual private portal, F

category pages, G.1.3 certificate

change trusted, 7.3.2.1.4

creating a wallet, 5.5.2.1.2, 7.3.2.1.4

export request, 7.3.2.1.4

import server user, 7.3.2.1.4

import trusted, 7.3.2.1.4

Oracle Wallet Manager, 5.5.2.1.2, 7.3.2.1.2, 7.3.2.1.4

request, 7.3.2.1.4

trusted, 7.3.2.1.4

certificate authority, 1.1.2, 7.1.9.10, 7.3.2.1.4, 7.3.2.1.4 certificate file, 7.3.2.1.4, 7.3.2.1.5 changing

page group quota, 5.3.6

character set indexing, 10.3.3.7 Clustering page, OracleAS Web Cache Manager, 9.1.3.2 commands to administer credentials, 6.12.2.2 commit_sync procedure, 10.3.5.2, D.1.2 communication

HMAC, 7.3.1.3.1

communication security

for providers, 7.1.9.3

complete

sync, F.6.1.3

components

migrating, 12.9.3

configuration

SSL, 7.3.2.1

configuring OmniPortlet, E.2 configuring Web clipping portlet, E.1 configuring Web clipping repository, E.1.1 container

group, 7.1.7.3.1

content

migration, 12.9.5

content cache, 1.3.2 context-sensitive help link, 5.3.12

removing, 5.3.12

cookie

expiration for OraDAV, 7.1.14.1

cookie domains

modifying the scope to send to all middle-tier servers, B.4.2

creating

category pages, G.1.3

personal page for an existing user, 5.3.3.2

personal page for new users automatically, 5.3.3.1

personal pages, 5.3.3

perspective pages, G.1.3

ctxcrind.sql, 10.3.4.1, 10.3.4.1, 10.3.7, F.7.5 ctxdrind.sql, 10.3.4.3 CTXSYS schema, 10.3.2, 10.3.3.2, 10.3.3.3 Custom Search portlet, 10.1.1, 10.1.1, 10.1.1, 10.1.1, 10.1.1

advanced search link, 10.2.1.3

defaults, 10.1.3

Internet search engine link, 10.2.1.4

Oracle Text enabled/disabled, 10.3.1

search result page, 10.2.1.1

D

DAD

configuring, 5.6.4

DAD entry

creating new, A.2

dads.conf

updating the DAD name, A.2

data

export, 12.4.1.1

data source

OmniPortlet SQL, E.2.4

database objects schema, 12.9.3 database Providers, 13.1.2 DataDirect JDBC drivers, E.2.4

registering with OmniPortlet, E.2.4.2

DBA group, 7.1.2.2 DBPreferenceStore, B.10 default home page, 5.3.1

group, 5.3.1.2

setting, 5.3.1

system, 5.3.1.1

user, 5.3.1.3

default schemas, 7.1.2.3

PORTAL, 7.1.2.3

PORTAL_APP, 7.1.2.3

PORTAL_DEMO, 7.1.2.3

PORTAL_PUBLIC, 7.1.2.3

Delegated Administration Services, 7.1.7.5

mod_osso and OracleAS Single Sign-On, 7.1.7.5.2

delta

sync, F.6.1.2

Design-Time Pages, 12.9.5 development instance, 12.9.5 diagnostic reporting, G.2.5 Directory Integration Platform, F.6.4

global settings, 7.3.1.1.2

virtual private portal, F.6.4

directory synchronization subscription

Oracle Internet Directory entry, 7.1.7.3.1

directory synchronized provisioning, 7.1.7.4 DIT structure

for groups, 7.1.7.3.3

for users, 7.1.7.3.1

nickname attribute, 7.2.2.1

dmsLogging, 5.6.9.1 doctype

setting global default, 5.3.11

document index, 10.3.3.1

disabling, 10.3.7

errors, 10.3.10, 10.3.11.5, 10.3.12.1

get_use_doc_index function, D.2.6

set_use_doc_index procedure, D.1.15

timeout error, 10.3.13.1

valid_doc_index procedure, D.2.8

E

ECID

see Execution Context Identifier, G.2

embldip.csh, F.8 emulation utilities, 12.4.1.1.3 enableWebCacheStaticRules, 5.6.9.1 enabling

hosting, F.2.1, F.3

locales, 5.10.2

territories, 5.10.2

enabling virtual private portal

pre-installation checklist, F.2.6

enblhstg.csh, F.8 enhanced authentication, 7.3.1.3.2 enhancedAuthentication, 7.3.1.3.2 Enterprise Manager

see Oracle Enterprise Manager, 8

environment variable, 7.3.1.3.1, 7.3.1.3.2 error message page

specifying, 5.3.8

error_log, G.2.3.2 errors

Oracle Text indexes, 10.3.10

Oracle Text is not installed, 10.2.2.1

troubleshooting, G

event logging, 8.3.1 event_log, G.2.3.6 events

directory synchronized, 7.1.7.4

Execution Context Identifier (ECID), G.2 export, 12.4.1.1

access control lists, 12.4.1.1.2, 12.4.1.1.3

data, 12.4.1.1

export and import

How Does Export and Import Work?, 12.1

manifest, 12.1

middle-tier versions, 12.2.1

opeasst.csh, 12.4.1.1.3, 12.4.1.1.3

transport sets, 12.1

F

Federated Portal Adapter

security, 7.1.13

FilePreferenceStore, B.10 finding information about Oracle Portal, 5.2 firewall

cluster members separated by, 9.1.3

disabling external to internal communication, 9.1.3.3

internal and external OracleAS Web Cache instances, 9.1.3.1

Fusion Middleware Control

monitoring Oracle Portal, 8.1

using, 8.1

Fusion Middleware Portal Developer Kit

logs, G.2.3.4

G

getting started

Oracle Portal, 5.1

gists in Oracle Text, 10.2.2.2, 10.3.7 Global Inactivity Timeout, 7.1.7.1.2 global privileges, 7.1.3.1 global settings, 7.3.1.1

Directory Integration Platform synchronization, 7.3.1.1.2

group creation base DN, 7.3.1.1.3

group search base DN, 7.3.1.1.4

refresh Oracle Internet Directory cache, 7.3.1.1.1

Global Unique Identifiers, 12.9.5 glossary, Preface group

default home page, 5.3.1.2

Oracle Instant Portal, 7.1.2.2, 7.1.2.2

group privileges

global privileges, 7.1.3.1

group's default home page, 5.3.1.2

setting, 5.3.1.2

groupofNames

subscription profile for groups based on, 7.1.7.4.1

groupOfNames object class

attributes, 7.1.7.3.3, 7.1.7.3.3

groupOfUniqueNames object class, 7.1.7.3.3

attributes, 7.1.7.3.3, 7.1.7.3.3

groups

assigning privileges to, 7.1.7.10.1

attributes in Oracle Internet Directory, 7.1.7.3.3

AUTHENTICATED_USERS, 7.1.2.2

change events, 7.1.7.4

container in Oracle Internet Directory, 7.1.7.3.1

create, 7.1.7.10.1

creation base DN, 7.3.1.1.3

DBA, 7.1.2.2

default, 7.1.2.2

DIT structure, 7.1.7.3.3

enabling as roles, 7.1.7.10.1

Group portlet, 7.1.7.8

in Oracle Internet Directory, 7.1.7.3.1

list of values, 7.1.7.3.5

Portal Group profile, 7.1.7.9

PORTAL_ADMINISTRATORS, 7.1.2.2

PORTAL_DEVELOPERS, 7.1.2.2

portlet access, 7.1.7.5.1

PORTLET_PUBLISHERS, 7.1.2.2

public, 7.1.7.10

RW_ADMINISTRATOR, 7.1.2.2

RW_BASIC_USER, 7.1.2.2

RW_DEVELOPER, 7.1.2.2

RW_POWER_USER, 7.1.2.2

search base DN, 7.3.1.1.4

seeded, 7.1.2.2

updating subscription profile, 7.1.7.4.1

GUID, 12.9.5 guides, Preface

H

Hashed Message Authentication Code, 7.3.1.3.1

HMAC, 7.3.1.3.1

HMAC keys

setting the, 13.2.2

host name

defining for site, 7.3.2.1.5

hosting

enabling, F.2.1

HTML templates, 12.8.1.8 httpd.conf, 11.4

definition, A.1

included oradav.conf file, 5.11

HTTPS

certificate request, 7.3.2.1.4

communication with providers, 7.1.9.10

complete, 7.3.2.1.5

configuration overview, 7.3.2.1.1

configuring with load balancing router, 7.3.2.1.6

creating a wallet, 5.5.2.1.2, 7.3.2.1.4

for Oracle Internet Directory network connection, 7.3.2.2

LDAPS, 7.3.2.3.9

Oracle Web Cache, 7.3.2.1.4

OracleAS Single Sign-On, 7.3.2.1.2

updating the query path URL, 7.3.2.1.2

with load balancing router, 7.3.2.1.6

httpsports, 5.6.9.1

I

IETF(RFC 2798), 7.1.7.3.2, 7.1.7.3.3

import

access control lists, 12.6.1.2

inctxgrn.sql, 10.2.2.1, 10.3.3.3, 10.3.3.4 indexes

Oracle Text, 10.3.4, 10.3.6, 10.3.8, 10.3.9, 10.3.10

inetOrgPerson object class, 7.1.7.3.2

attributes, 7.1.7.3.2

INFRA_ORACLE_HOME, 1.1.2 INSO filter

(deprecated) see AUTO_FILTER, 10.3.2

installation

default groups, 7.1.2.2

default schemas, 7.1.2.3, 7.1.2.3

default users, 7.1.2.1

Internet search engine link

configuring, 10.2.1.4

defaults, 10.1.3

invalidation based caching, B.1 invalidation job

configuring, B.1

invalidation messages, B.1, B.1 invalidation-based caching

OmniPortlet, E.2.1.3

Web Clipping and, E.1.4

invalidations

hard and soft, B.1

J

J2EE security, 7.1.6

Java Portal Development Kit (JPDK), G.2.3.1

JAZN-LDAP, 7.3.1.3.2

JDBC-ODBC driver, E.2.4

JNDI

environment variable, 7.3.1.3.1, 7.3.1.3.2

JPDK, G.2.3.1 JPDK messages, G.2.3.1 JPS, 1 jspRoot, 5.6.9.1 jspSrcAlias, 5.6.9.1

K

key store, 13.2.2

SQL scripts for maintenance, 13.2.2

keystores for WSRP producers, 7.1.10.1

L

languages

Configuring Language Support, 5.10

multilexers in Oracle Text, 10.3.3.5

Set Language portlet, 5.10

LDAPS

for Oracle Internet Directory, 7.3.2.3.9

Lexer preferences, 10.3.3.2 list of values

users and groups, 7.1.7.3.5

Load Balancing Router

accepting and forwarding requests, 9.1.4

load balancing router

accepting and forwarding requests, 6.3.2

configuring Network Address Translation bounce back, 6.3.2

configuring Oracle Portal to be accessed through, 6.3.2

configuring SSL, 7.3.2.1.6

handling invalidation requests, 6.3.2

setting up multiple middle tiers with, 6.3

SSL, 7.3.2.1.6

LocalePersonalizationLevel

setting for OmniPortlet, E.2.2

locales, 5.10.2

enabling the use of, 5.10.2

logcfg.sql, G.2.3.5 logcrind.sql, 10.3.9.2 login frequency, 7.3.1.3.1, 7.3.1.3.2 login portlet

SSL, 7.3.2.3.8

logs

diagnostic log files, 8.2.2.7

Fusion Middleware Portal Developer Kit, G.2.3.4

global privileges, 7.1.3.1

Java Portal Development Kit (JPDK), G.2.3.1

Oracle Metadata Repository, G.2.3.5

Oracle Web Cache, G.2.3.6

Parallel Page Engine, G.2.3.3

portal activity log files, 8.3

Portal Services, G.2.3.2

settings for Oracle Portal, 8.2.2.7

using Log Viewer, G.2.4

M

management, 8

managing

ASP users and groups, F.6.1

max cache, B.1 MaxClients, 11.4 maximum file size for uploaded files, 5.3.5 maxParallelPagePortlets, 5.6.9.1 maxParallelPortlets, 5.6.9.1 MaxRequestsPerSession, G.1.6 memory related issues, G.1.11 memory size used for indexing, 10.3.5.3 message authentication, 7.3.1.3.1

for provider security, 7.1.9.9

message encryption

for provider security, 7.1.9.3.3

messages

JPDK, G.2.3.1

MetaLink, G.3 migrating content, 12.9.5 migrating Portal DB Providers, 12.9.3 MIME type indexing, 10.3.3.7 minTimeout, 5.6.9.1 mod_dav, 5.11 mod_oradav module, 5.11 mod_osso

Delegated Administration Services and OracleAS Single Sign-On, 7.1.7.5.2

for partner applications, 7.1.9.7.1

monitoring

Oracle Portal components, 8

protect packages, 7.3.2.3.7

multilexer

supported in Oracle Text, 10.3.3.5

N

Network Address Translation (NAT) bounce back, 6.3.2

network connection

to Oracle Internet Directory, 7.3.2.2

nickname attribute, 7.2.2.1 N-Tier authentication, 7.1.2.3

O

object privileges, 7.1.3.2

ODBC data sources, E.2.4

ODM, F.2.7

using, F.2.7

offlinePathHtml, 5.6.9.1 offlinePathMxml, 5.6.9.1 OIP_AVAILABLE_USERS, 7.1.2.2 OIP_USER_ADMINS, 7.1.2.2 OmniPortlet

application.log, G.1.18

configuration issues, G.1.18

export and import, 12.8.5.1

registering, E.2.3

registering DataDirect JDBC drivers, E.2.4.2

security, 7.1.11

OmniPortlet administration

configuring, E.2

configuring caching, E.2.1.3

configuring the repository, E.2.1.2

copying the library for HTTPS access, E.2.1.4

OmniPortlet provider

registering, E.2.3

OmniPortlet SQL data source, E.2.4 online help system, 5.10.2 opmn.xml, G.1.10 optimization

AUTO_FILTER, 10.3.3.7

Oracle Text index, 10.3.5

optjsub.sql, D.3.3 Oracle Application Server

configuration files, A.6

viewing port information, 8.4

Oracle Cache

configuring with Web Clipping, E.1.4.1

Web Clipping and, E.1.4

Oracle Certificate Authority, 1.1.2, 7.1.9.10, 7.3.2.1.4, 7.3.2.1.4 Oracle Delegated Administration Services

list of values, 7.1.7.3.5

privileges, 7.1.7.5.1

public roles, 7.1.7.10

Oracle Directory Integration and Provisioning

agent, 7.1.7.3.4

Oracle Directory Integration Platform, 7.1.7.4

requirements, 7.1.7.4

Oracle Directory Manager, F.2.7

using, F.2.7

Oracle Enterprise Manager, 8

using Fusion Middleware Control, 8.1

Oracle Fusion Middleware

configuration files, A

Oracle Help for the Web, 5.10.2 Oracle Instant Portal

group, 7.1.2.2, 7.1.2.2

user, 7.1.2.1

Oracle Internet Directory, 7.1.7.3

application entity, 7.1.7.3.1

cache, 7.1.7.3.4

configuring SSL for network connection, 7.3.2.2

default user accounts, 7.1.7.3.1

directory synchronization subscription entry, 7.1.7.3.1

entries, 7.1.7.3.1

group attributes, 7.1.7.3.3

group container, 7.1.7.3.1

group DIT structure, 7.1.7.3.3

groupOfUniqueNames, 7.1.7.3.3

groups, 7.1.7.3.1

inetOrgPerson, 7.1.7.3.2

LDAPS, 7.3.2.3.9

nickname attribute, 7.2.2.1

orclGroup, 7.1.7.3.3

orclUser, 7.1.7.3.2

orclUserV2, 7.1.7.3.2

privileges for updating information, 7.1.7.5.1

refresh cached parameters, 7.3.1.1.1

user and group list of values, 7.1.7.3.5

user attributes, 7.1.7.3.2

user DIT structure, 7.1.7.3.1

Oracle JDBC driver, E.2.4 Oracle Metadata Repository, 1.1.2, 1.2.1, 2.1.7.2.1, 3.1.2, 3.1.3, 5.1.1, 5.6.4, 5.10.1, 6.3.2, 6.4.2, 6.9, 8.3, G.1.1, G.2.3.5, G.2.4

logcfg.sql, G.2.3.5

logs, G.2.3.5

Oracle MetaLink, G.3 Oracle Net Services, 11.6 Oracle Portal

accessing in browser, 5.2.1

Cache settings, 8.2.2.3

creating users and groups, 7.1.7

finding information, 5.2

getting started, 5.1

log configuration settings, 8.2.2.7

monitoring in Enterprise Manager, 8

troubleshooting, G

upgrade, 3

user and group lists of values, 7.1.7.3.5

Web Cache settings, 8.2.2.4

Oracle Portal Diagnostic Assistant

reports, G.2.5

using, G.2.5

Oracle Portal Log Configuration pagel, 8.2.2.7 Oracle Portal Log Registry, 8.3 Oracle Secure Enterprise Search

configuring in Oracle Portal, 10.2.3

overview, 10.4.1

portlet, 10.4.2

Oracle Text

configuring proxy settings, 10.2.2.4

configuring the base URL, 10.2.2.3

enabling and disabling, 10.2.2.1

indexes, 10.3.4, 10.3.6, 10.3.8, 10.3.9, 10.3.10

overview, 10.3

prerequisites, 10.3.2

setting result options, 10.2.2.2

themes and gists, 10.2.2.2

wwv_context APIs, D

Oracle Text indexes

creating and dropping, 10.3.4

errors, 10.3.10, 10.3.11, 10.3.12.1

maintenance APIs, D

monitoring, 10.3.9

optimizing, 10.3.5.7

re-creating, F.7.5

searching URL content, 10.3.6

status, 10.3.8

synchronizing, 10.3.5.1

troubleshooting, 10.3.13

Oracle Ultra Search

portlet, 10.4.1.1

Oracle Universal Installer, 1.1.2 Oracle Wallet Manager, 5.5.2.1.2, 7.3.2.1.2, 7.3.2.1.4 Oracle Web Cache

configuring SSL port, 7.3.2.1.4, 7.3.2.1.5

configuring with OmniPortlet, E.2.1.3

defining a site, 7.3.2.1.4

issues in configuring OmniPortlet, G.1.19

logs, G.2.3.6

setting for Oracle Portal, 8.2.2.4

specifying published address and protocol for SSL, 7.3.2.1.5

SSL, 7.3.2.1.4

ORACLE_HOME, 1.1.2

conventions, 1.1.2, 1.1.2

distinguishing between, 1.1.2

OracleAS Single Sign-On, 7.1.7.1

corresponding language installation, 5.10.2

Delegated Administration Services and mod_osso, 7.1.7.5.2

SSL, 7.3.2.1.2

ssoreg, 7.3.2.1.2, 7.3.2.1.4, 7.3.2.1.5, 7.3.2.1.6

OracleAS Web Cache

Manager and cluster configuration, 9.1.3.2

Manager and propagating configuration, 9.1.3.2.1

oracle.http.configfile, G.1.19 OraDAV

security, 7.1.14

session cookie expiration, 7.1.14.1

SSL, 7.1.14.2

OraDAV implementation, 5.11 oradav.conf

DAV configuration file, 5.11.1

ORCLADMIN user, 7.1.2.1 orclGroup object class, 7.1.7.3.3

attributes, 7.1.7.3.3

orclUser object class, 7.1.7.3.2 orclUserV2 object class, 7.1.7.3.2

attributes, 7.1.7.3.2

origin server

SSL, 7.3.2.1.5

out-of-the-box portal, F.3 overview

virtual private portal, F.2

P

page group

export, 12.4.1.1

page group quota, 5.3.6

changing, 5.3.6

page groups

global privileges, 7.1.3.1

pages

global privileges, 7.1.3.1

parallel index synchronization, 10.3.5.3 Parallel Page Engine

configuring SSL partially, 7.3.2.1.4

full SSL, 7.3.2.1.5

logs, G.2.3.3

partner applications

secured through mod_osso, 7.1.9.7.1

security, 7.1.9.7.1

Password

changing, 6.12

password

application entity, 7.3.2.3.10

schema, 7.1.7.10.1

sync, F.6.1.1

passwords

safeguard, 7.3.2.3.2

payload

for BPEL, 5.5.6, 5.5.7

pda.cmd script, G.2.5 pda.csh script, G.2.5 PDK

Preference Store Migration/Upgrade Utility, 6.3.6, B.10

see Oracle Fusion Middleware Portal Developer Kit, G.2.3.4

PDK-Java, 6.3.6, B.10 performance issues, G.1.6 personal page

automatically creating for new users, 5.3.3.1

creating for a new user, 5.3.3.2

personal pages, 5.3.3

creating, 5.3.3, 5.3.3

personalization form

sequence of events, 13.4.2

perspective pages, G.1.3 PL/SQL HTTP Adapter, 13, 13.1

Overview, 13.1.1

PlsqlAfterProcedure, G.2.2.1 PlsqlBeforeProcedure, G.2.2.1 PlsqlSessionCookieName

changing the value, A.2

poolSize, 5.6.9.1 port

changing the default, 6.1

defining SSL for site, 7.3.2.1.5

viewing information, 8.4

PORTAL

schema password, 7.1.7.10.1

portal

out-of-the-box, F.3

templates, 12.8.1.7

upgrade, 3

Portal Cache

settings, 8.2.2.3

Portal cache

configuring, 5.6.6, 5.6.7

portal cache

content cache, 1.3.2

session cache, 1.3.2

understanding, 1.3.2

Portal DB Providers

global privileges, 7.1.3.1

migrating, 12.9.3

Portal Dependency Settings

Web Cache, 8.2.2.6

PORTAL schema, 7.1.2.3 Portal Services

logs, G.2.3.2

portal templates, 12.8.1.7 PORTAL_ADMINISTRATORS group, 7.1.2.2 PORTAL_APP schema, 7.1.2.3 portal_dads.conf, A.2 PORTAL_DEMO schema, 7.1.2.3 PORTAL_DEVELOPERS group, 7.1.2.2 PORTAL_PUBLIC schema, 7.1.2.3 PORTLET_PUBLISHERS group, 7.1.2.2 portlets

application security, 7.1.9.7

Group, 7.1.7.8

login, 7.3.2.3.8

Portal Group Profile, 7.1.7.9

Portal User Profile, 7.1.7.7

privileges, 7.1.3.1

programmatic security, 7.1.9.8

provider privileges, 7.1.3.4

security, 7.1.9

User, 7.1.7.6

portlets schema, 12.9.3 ports

used to access Oracle Portal, 5.2.1

post-installation

security checklist, 7.3.2.3

PPE parameter

cacheEncryptionKey, 5.6.9.1

dmsLogging, 5.6.9.1

enableWebCacheStaticRules, 5.6.9.1

httpsports, 5.6.9.1

jspRoot, 5.6.9.1

jspSrcAlias, 5.6.9.1

maxParallelPagePortlets, 5.6.9.1

maxParallelPortlets, 5.6.9.1

minTimeout, 5.6.9.1

offlinePathHtml, 5.6.9.1

offlinePathMxml, 5.6.9.1

poolSize, 5.6.9.1

proxyHost, 5.6.9.1

proxyPort, 5.6.9.1

queueTimeout, 5.6.9.1

requesttime, 5.6.9.1

resourceUrlKey, 5.6.9.1

showError, 5.6.9.1

showPageDebug, 5.6.9.1

stall, 5.6.9.1

urlDebugMode, 5.6.9.1

urlDebugUsers, 5.6.9.1

useDeviceNameCacheKeys, 5.6.9.1

usePort, 5.6.9.1

useScheme, 5.6.9.1

versionOnSplashScreen, 5.6.9.1

x509certfile, 5.6.9.1

pre-cook

subscribers, F.6.5

Preference Store migration and upgrade, B.10 Preference Store Migration/Upgrade Utility, 6.3.6, B.10 PreferenceStore, B.10 preliminary check

failures, 12.9.5

privileges

assigning to a group, 7.1.7.10.1

control for objects, 7.1.3.2

global, 7.1.3.1

global administration, 7.1.3.1

global page group, 7.1.3.1

hiding assignment section on Create Users page, 7.1.7.10.1

OmniPortlet, 7.1.11

on all group privileges, 7.1.3.1

on all logs, 7.1.3.1

on all page groups, 7.1.3.1

on all pages, 7.1.3.1

on all Portal DB Providers, 7.1.3.1

on all portlets, 7.1.3.1

on all providers, 7.1.3.1

on all schemas, 7.1.3.1

on all shared components, 7.1.3.1

on all styles, 7.1.3.1

on all transport sets, 7.1.3.1

on all user profiles, 7.1.3.1

provider, 7.1.3.4

seeded, 7.3.2.3.4

simple parameter form, 7.1.11

production instance, 12.9.5 property

enhancedAuthentication, 7.3.1.3.2

sharedKey, 7.3.1.3.1, 7.3.1.3.1, 7.3.1.3.2

protected resources, 7.1.3 provider

privileges, 7.1.3.4

provider group

privileges, 7.1.3.4

provider groups

global privilege codes for, 7.1.3.4.1

object privilege codes for, 7.1.3.4.2

providers

communication security, 7.1.9.3

database providers and web providers, 13.1.2

global privilege codes for, 7.1.3.4.1

global privileges, 7.1.3.1

HTTPS communication with, 7.1.9.10

message authentication, 7.1.9.9

message encryption, 7.1.9.3.3

object privilege codes for, 7.1.3.4.2

revoke public access to components, 7.3.2.3.5

server authentication, 7.1.9.5

SSL, 7.1.9.11

provideruiacls.xml, 7.1.3.4 provider.xml file

OmniPortlet, E.2.1.1, E.2.4.2

Web Clipping and, E.1.3, E.1.4.1

Web clipping repository, E.1.1

provisioning

events, 7.1.7.4

profile entry in Oracle Internet Directory, 7.1.7.3.1

user and group change events, 7.1.7.4

proxy server

configuring Oracle Portal to use a, 6.5

configuring Web Clipping for, E.1.3

domains, 6.5

use by Oracle Text, 10.2.2.4

proxy settings

Web clipping and, E.1.3

proxyHost, 5.6.9.1 proxyPort, 5.6.9.1 public roles, 7.1.7.10

example, 7.1.7.10.1

Q

query path URL

updating iasconfig.xml, 7.3.2.1.2

queueTimeout, 5.6.9.1

R

redirect

simplifying Oracle Portal URL, 5.6.1

registering

OmniPortlet, E.2.3

OmniPortlet provider, E.2.3

Web Clipping provider, E.1.2

removing

context-sensitive help link, 5.3.12

subscribers, F.2.4, F.6.2

reports

portal activity, 8.3

requesttime, 5.6.9.1 resources

protected, 7.1.3

resourceUrlKey, 5.6.9.1 reverse proxy server

configuring, 6.6

configuring SSL, 7.3.2.1.6

rmsub.csh, F.8 roles

enabling groups as roles, 7.1.7.10.1

example, 7.1.7.10.1

public, 7.1.7.10

routers

configuring load-balancing, 6.3

RW_ADMINISTRATOR group, 7.1.2.2 RW_BASIC_USER group, 7.1.2.2 RW_DEVELOPER group, 7.1.2.2 RW_POWER_USER group, 7.1.2.2

S

Saved Searches portlet, 10.1.1, 10.1.1, 10.1.1, 10.1.1, 10.1.1

sbrimtlx.sql, 10.3.3.2, 10.3.3.5, D.1.5, D.1.10

schema

password, 7.1.7.10.1

Schema Password

changing, 6.12

schemas, 7.1.2.3

default, 7.1.2.3, 7.1.2.3

global privileges, 7.1.3.1

PORTAL, 7.1.2.3

PORTAL_APP, 7.1.2.3

PORTAL_DEMO, 7.1.2.3

PORTAL_PUBLIC, 7.1.2.3

script

cachjsub.sql, B.1

scripts

virtual private portal, F.8

search options, 10

configuring Oracle Portal search portlets, 10.2.1

configuring Oracle Secure Enterprise Search, 10.2.3

configuring Oracle Text search portlets, 10.2.2

deciding how to configure, 10.1.4

default functionality, 10.1.3

Oracle Portal search, 10.1.1, 10.1.1, 10.1.1, 10.1.1, 10.1.1

Oracle Text, 10.1.1

Oracle Ultra Search, 10.1.2

search results

choosing search result pages, 10.2.1.1

limiting results in every page, 10.2.1.2

secupoid.sql, 7.3.2.3.9, 7.3.2.3.10, 7.3.2.3.10, B.3

configuring SSL to connect to Oracle Internet Directory, B.3

running, 7.3.2.3.9

security, 7

about, 7.1

access control lists, 7.1.9.4

access enforcement, 7.1.4

access to administration pages, 7.3.2.3.6

application entity password, 7.3.2.3.10

architecture, 7.1.1, 7.1.7

AUTHENTICATED_USERS group, 7.1.2.2

authorization, 7.1.4

communication for providers, 7.1.9.3

DBA group, 7.1.2.2

default groups, 7.1.2.2

default schemas, 7.1.2.3

default user accounts, 7.1.2.1

Delegated Administration Service, 7.1.7.5

Directory Integration and Provisioning agent, 7.1.7.3.4

directory synchronized events, 7.1.7.4

directory synchronized provisioning, 7.1.7.4

DIT structure, 7.1.7.3.1

external application, 7.1.9.7.2

Federated Portal Adapter, 7.1.13

global administration privileges, 7.1.3.1

global page group privileges, 7.1.3.1

global privileges, 7.1.3.1

global settings, 7.3.1.1

group attributes in Oracle Internet Directory, 7.1.7.3.3

GROUP DELETE event, 7.1.7.4, 7.3.2.1.4

GROUP MODIFY event, 7.1.7.4, 7.3.2.1.4, 7.3.2.1.4

Group portlet, 7.1.7.8

groupOfUniqueNames object class, 7.1.7.3.3

HTTPS communication with providers, 7.1.9.10

inetOrgPerson object class, 7.1.7.3.2

J2EE, 7.1.6

keystores for WSRP producers, 7.1.10.1

leveraging Oracle Security Services, 7.1.6

login portlet, 7.3.2.3.8

model, 7.1.1

monitoring packages, 7.3.2.3.7

object privileges, 7.1.3.2

OmniPortlet, 7.1.11

Oracle Directory Integration Platform, 7.1.7.4

Oracle Internet Directory, 7.1.7.3

Oracle Internet Directory cache, 7.1.7.3.4

OracleAS Single Sign-On, 7.1.7.1

OraDAV security, 7.1.14

ORCLADMIN user, 7.1.2.1

orclGroup object class, 7.1.7.3.3

orclUser object class, 7.1.7.3.2

orclUserV2 object class, 7.1.7.3.2

overview, 7.1.1

partner application, 7.1.9.7.1

Portal Group Profile portlet, 7.1.7.9

Portal User Profile portlet, 7.1.7.7

PORTAL_ADMINISTRATORS group, 7.1.2.2

PORTAL_DEVELOPERS group, 7.1.2.2

PORTLET_PUBLISHERS group, 7.1.2.2

portlets, 7.1.9

post-installation checklist, 7.3.2.3

privileges, 7.1.2

programmatic for portlets, 7.1.9.8

provider message authentication, 7.1.9.9

public access to provider components, 7.3.2.3.5

Refresh Cache for OID Parameters, 7.3.1.1.1

remove unnecessary objects, 7.3.2.3.3

resources protected, 7.1.3

RW_ADMINISTRATOR group, 7.1.2.2

RW_BASIC_USER group, 7.1.2.2

RW_DEVELOPER group, 7.1.2.2

RW_POWER_USER group, 7.1.2.2

safeguard passwords, 7.3.2.3.2

seeded privileges, 7.3.2.3.4

server authentication, 7.1.9.5

session cookie expiration for OraDAV, 7.1.14.1

simple parameter form, 7.1.11

SSL for providers, 7.1.9.11

user attributes in Oracle Internet Directory, 7.1.7.3.2

USER DELETE event, 7.1.7.4, 7.3.2.1.4

USER MODIFY event, 7.1.7.4, 7.3.2.1.4

User portlet, 7.1.7.6

users, 7.1.2

WWSEC_FLAT$ table, 7.1.7.4, 7.3.2.1.4

server authentication

for provider security, 7.1.9.5

session

expiration for OraDAV, 7.1.14.1

session binding

enabling in Oracle Web Cache, 6.3.7, 7.3.2.1.4, 7.3.2.1.5

session cache, 1.3.2 sessions

cookie, B.4.2

setting

default home page, 5.3.1

group's default home page, 5.3.1.2

maximum file size for uploaded files, 5.3.5

page users see when they log out, 5.3.10

system default home page, 5.3.1.1

system default style, 5.3.2

total space allocated for uploaded files, 5.3.4

user's default home page, 5.3.1.3

setting the page users see when they log out, 5.3.10 setting up

ASP users and groups, F.4.1

users and groups, F.2.2

shared components

global privileges, 7.1.3.1

shared key, 7.3.1.3.1 shared_pool_size parameter, G.1.11 sharedKey, 7.3.1.3.1, 7.3.1.3.1, 7.3.1.3.2 shell script

tools, 12.4.1.1.3

showError, 5.6.9.1 showPageDebug, 5.6.9.1 simple parameter form

security, 7.1.11

single sign-on, 7.1.7.1

authentication for applications, 7.1.9.7

site

aliases, 7.3.2.1.4

defining for Oracle Web Cache in SSL environment, 7.3.2.1.4

defining SSL host name and port, 7.3.2.1.5

to server mappings, 7.3.2.1.4, 7.3.2.1.5

specifying

error message page, 5.3.8

specifying an error message page, 5.3.8 sql_trace parameter, G.2.2.2 SSL

certificate request, 7.3.2.1.4

complete, 7.3.2.1.5

configuration overview, 7.3.2.1.1

configuring SSL port, 7.3.2.1.5

configuring SSL port for Oracle Web Cache, 7.3.2.1.4

configuring with load balancing router, 7.3.2.1.6

creating a wallet, 5.5.2.1.2, 7.3.2.1.4

encryption, 7.1.6

for Oracle Internet Directory network connection, 7.3.2.2

for providers, 7.1.9.11

LDAPS, 7.3.2.3.9

Oracle Web Cache, 7.3.2.1.4

OracleAS Single Sign-On, 7.3.2.1.2

OraDAV, 7.1.14.2

origin server, 7.3.2.1.5

Parallel Page Engine, partial, 7.3.2.1.4

specifying published address and protocol, 7.3.2.1.5

updating the query path URL, 7.3.2.1.2

with load balancing router, 7.3.2.1.6

with providers, 7.1.9.10

SSL configuration, 7.3.2.1 SSL query path URL, 7.3.2.1.2 ssoreg, 7.3.2.1.2, 7.3.2.1.4, 7.3.2.1.5, 7.3.2.1.6 stall, 5.6.9.1 status information, 8.2.1, 8.2.1.4 STEM searching, 10.3.3.6 styles

global privileges, 7.1.3.1

subscribers, F.2.3

adding, F.2.3, F.5

pre-cook, F.6.5

removing, F.2.4, F.6.2

subscription profile

updating, 7.1.7.4.1

sync

complete, F.6.1.3

delta, F.6.1.2

password, F.6.1.1

syncasp.csh, F.8 synchronization

Directory Integration and Provisioning agent, 7.1.7.3.4

entry in Oracle Internet Directory, 7.1.7.3.1

manual, 10.3.5.3

on commit, 10.3.5.2, 10.3.8, D.1.2

Oracle Text index, 10.3.5

user and group change events, 7.1.7.4

system

default home page, 5.3.1.1

system default home page, 5.3.1.1

setting, 5.3.1.1

system default style, 5.3.2

setting, 5.3.2

T

TCP/IP, 6.4.1.3

templates

HTML, 12.8.1.8

portal, 12.8.1.7

territories, 5.10.2

enabling the use of, 5.10.2

textjsub.sql, D.3.3 textstat.sql, 10.3.5.1, 10.3.8 themes and gists

disabling, 10.3.7

enabling for Oracle Text, 10.2.2.2

tools, 5.1.2

shell script, 12.4.1.1.3

Top Level Pages, 12.9.5 topology viewer, 8.2.3 total space allocated for uploaded files, 5.3.4 trace files

generating, G.2.2

transport sets

global privileges, 7.1.3.1

troubleshooting, G

browser settings, G.1.15, G.1.16

Federated Portal Adapter, 13.5

unhandled exception errors, G.1.17

trusted certificate, 7.3.2.1.4, 7.3.2.1.5

change, 7.3.2.1.4

import, 7.3.2.1.4

trusted certificates

managing, 7.3.2.1.4

tuning

Oracle Net Services, 11.6

U

Ultra Search

see Oracle Ultra Search, 10.4

unhandled exception errors, G.1.17 UNIX

emulation utilities, 12.4.1.1.3

upgrade, 12.9.5, F.7.5

portal, 3

uploaded files

total space allocated for, 5.3.4

URL index, 10.3.3.1

disabling, 10.3.7

errors, 10.3.10, 10.3.11.6, 10.3.12.2

get_use_url_index function, D.2.7

set_use_url_index procedure, D.1.16

timeout error, 10.3.13.1

valid_url_index procedure, D.2.9

URL searching, 10.3.6 urlDebugMode, 5.6.9.1 urlDebugUsers, 5.6.9.1 useDeviceNameCacheKeys, 5.6.9.1 usePort, 5.6.9.1 user

default home page, 5.3.1.3

Oracle Instant Portal, 7.1.2.1

ORCLADMIN, 7.1.2.1

user accounts

seeded, 7.1.2.1

user certificate

import, 7.3.2.1.4

user profiles

global privileges, 7.1.3.1

user's default home page, 5.3.1.3

setting, 5.3.1.3

user_dump_dest, G.1.17 users

attributes in Oracle Internet Directory, 7.1.7.3.2

change events, 7.1.7.4

default, 7.1.2.1

hiding assignment section on Create Users page, 7.1.7.10.1

list of values, 7.1.7.3.5

Portal User Profile portlet, 7.1.7.7

portlet access, 7.1.7.5.1

safeguard passwords, 7.3.2.3.2

User portlet, 7.1.7.6

users and groups

ASP, F.4

setting up, F.2.2

useScheme, 5.6.9.1 using

ODM, F.2.7

Oracle Directory Manager, F.2.7

utility

Preference Store Migration and Upgrade, B.10

Preference Store Migration/Upgrade, 6.3.6, B.10

UTL_FILE_DIR parameter, G.2.3.5

V

validation-based caching

Web Clipping and, E.1.4

versionOnSplashScreen, 5.6.9.1 viewing

port information, 8.4

virtual hosts

configuring, 6.4

configuring Oracle Web Cache with, 6.4.2

creating entries, 6.4.1

virtual private portal, F

advanced features, F.2.5

advanced operations, F.6

case study, F

Directory Integration Platform, F.6.4

overview, F.2

scripts, F.8

WebDAV, F.6.3

VPP, F

W

wallet

creating, 5.5.2.1.2, 7.3.2.1.4

Oracle Wallet Manager, 5.5.2.1.2, 7.3.2.1.2, 7.3.2.1.4

save, 7.3.2.1.4

Web Cache

see Oracle Web Cache, 8.2.2.4

settings for Oracle Portal, 8.2.2.4

Web clipping administration

configuring, E.1

configuring security

adding certificates for trusted sites, 7.1.12.1

advanced security option (ASO), 7.1.12.2

configuring Web clipping repository, E.1.1 manually configuring caching, E.1.4.1 manually setting proxy settings, E.1.3 restricting clipping from unauthorized external Web sites, E.1.3.1 setting advanced security option (ASO) parameters, 7.1.12.2 using Web clipping provider test page

advanced security option (ASO), 7.1.12.2

Web Clipping provider

registering, E.1.2

Web clipping repository

configuring, E.1.1

Web Providers, 13.1.2 Web providers

avoiding timeout errors, G.1.10

privileges, 7.1.3.4

Web Services for Remote Portlets, 3.1.3 WebDAV

Portal access parameter, 5.11.1

virtual private portal, F.6.3

web.xml

logmode, G.2.3.3

workflow

creating BPEL process definition, 5.5.3

deleting BPEL process definition, 5.5.5

editing BPEL process definition, 5.5.4

WSRP, 1, 1.2.2.1, 1.2.2.1, 1.2.2.2, 1.4, 3.1.3, 7.1.9 WSRP producers

keystores, 7.1.10.1

WWSSO_PAPP_CONFIGURATION_INFO$, A.5 wwv_context APIs

constants, D.3.1

exceptions, D.4

maintaining Oracle Text indexes, D

procedures, D.1, D.2

X

x509certfile, 5.6.9.1

Oracle Legal Notices

Copyright Notice

Copyright © 1994-2014, Oracle and/or its affiliates. All rights reserved.

Trademark Notice

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

License Restrictions Warranty/Consequential Damages Disclaimer

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

Warranty Disclaimer

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

Restricted Rights Notice

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

Hazardous Applications Notice

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Third-Party Content, Products, and Services Disclaimer

This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.

Alpha and Beta Draft Documentation Notice

If this document is in preproduction status:

This documentation is in preproduction status and is intended for demonstration and preliminary use only. It may not be specific to the hardware on which you are using the software. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to this documentation and will not be responsible for any loss, costs, or damages incurred due to the use of this documentation.