Oracle® Fusion Middleware

Third-Party Application Server Guide

11g Release 1 (11.1.1.8)

E17852-04

July 2013

This document describes how to install, configure, and use selected Oracle Fusion Middleware products with IBM WebSphere.

Oracle Fusion Middleware Third-Party Application Server Guide, 11g Release 1 (11.1.1.8)

E17852-04

Copyright © 2011, 2013 Oracle and/or its affiliates. All rights reserved.

Primary Author:  Peter LaQuerre

Contributing Authors: Barbara Buerkle, Gail Flanegin, Helen Grembowicz, Rosie Harvey, Kevin Hwang, Christine Jacobs, Peter Jew, Mark Kennedy, Liz Lynch, Robert May, Mike Meditzky, Vinaye Misra, Carlos Subi, Len Turmel, Bonnie Vaughan

Contributors: Mike Blevins, Robert Campbell, Dave Felts, Jeni Ferns, Nick Greenhalgh, Harry Hsu, Suman Karmakar, Hareesh Kolpuru, Vasant Kumar, Dennis Leung, Dan MacKinnon, Mark Miller, Kevin Minder, Vinod Nimmagadda, Vijay Ramanathan, Michael Rubino, Roy Sandjaja, Reza Shafii, Vishal Sharma, Stephen Sherman, Payal Srivastra, Sitaraman Swaminathan, Ken Vincent, Prakash Yamuna, Lisa Zitek-Jones

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 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.

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.

Contents

Preface

- Audience

- Documentation Accessibility

- Related Documents

- Conventions

1 Introduction to Third-Party Application Servers

- 1.1 What Is a Third-Party Application Server?

- 1.2 Oracle Fusion Middleware Components That Support Third-Party Application Servers

- 1.3 Overview of the Oracle Fusion Middleware IBM WebSphere Support

- 1.3.1 Supported IBM WebSphere Application Servers

- 1.3.2 Understanding the Topology of Oracle Fusion Middleware on IBM WebSphere

- 1.3.2.1 Typical Oracle Fusion Middleware Topology on IBM WebSphere Application Server - ND

- 1.3.2.2 Typical Oracle Fusion Middleware Topology on IBM WebSphere Application Server

- 1.4 Documentation Resources for Using Oracle Fusion Middleware on IBM WebSphere

2 Installing and Configuring Oracle Fusion Middleware on IBM WebSphere

- 2.1 Task 1: Review the System Requirements and Certification Information

- 2.2 Task 2: Obtain the Necessary Software Media or Downloads

- 2.3 Task 3: Identify a Database and Install the Required Database Schemas

- 2.4 Task 4: Install the IBM WebSphere Software

- 2.4.1 IBM Online Resources for Obtaining and Installing the IBM WebSphere Software

- 2.4.2 Important Considerations Before Installing the IBM WebSphere Software

- 2.4.2.1 Using the Correct IBM WebSphere Installer for Your Platform

- 2.4.2.2 About the Sample Applications and Default Profiles During the IBM WebSphere Installation

- 2.4.2.3 About the WAS_HOME Directory Path

- 2.5 Task 5: Install Oracle Fusion Middleware

- 2.5.1 General Installation Instructions for the Supported Oracle Fusion Middleware Products

- 2.5.2 Special Instructions When Installing Oracle Fusion Middleware with IBM WebSphere

- 2.6 Task 6: Configure Your Oracle Fusion Middleware Components in a New IBM WebSphere Cell

- 2.6.1 General Information About Using the Configuration Wizard on IBM WebSphere

- 2.6.2 Component-Specific Information About Using the Configuration Wizard on IBM WebSphere

- 2.6.3 Troubleshooting Errors When Configuring a Cell on Windows 2003 and 2008

- 2.7 Task 7: Start the IBM WebSphere Servers

- 2.8 Task 8: Verify the Configuration of the IBM WebSphere Cell

- 2.9 Task 9: Install and Configure an LDAP Server

- 2.9.1 General Information About Supported LDAP Servers and Identity Stores

- 2.9.2 Oracle Fusion Middleware Component-Specific LDAP Information

3 Managing Oracle Fusion Middleware on IBM WebSphere

- 3.1 Summary of the Oracle Fusion Middleware Management Tools on IBM WebSphere

- 3.1.1 Using the WebSphere Administrative Console

- 3.1.1.1 About the IBM WebSphere Administrative Console

- 3.1.1.2 Locating the Port Number and URL of the IBM WebSphere Administrative Console

- 3.1.2 Using Oracle Enterprise Manager Fusion Middleware Control

- 3.1.2.1 About Oracle Enterprise Manager Fusion Middleware Control

- 3.1.2.2 Locating the Port Number and URL for Fusion Middleware Control

- 3.1.2.3 Displaying Fusion Middleware Control

- 3.1.2.4 Viewing an IBM WebSphere Cell from Fusion Middleware Control

- 3.1.2.5 Viewing an IBM WebSphere Server from Fusion Middleware Control

- 3.1.2.6 Viewing an IBM WebSphere Application Deployment from Fusion Middleware Control

- 3.1.2.7 Performing Oracle Fusion Middleware-Specific Administration Tasks for the Cell

- 3.1.2.8 Differences When Using Fusion Middleware Control on IBM WebSphere

- 3.1.3 Using the Oracle Fusion Middleware wsadmin Commands

- 3.1.3.1 About the Oracle Fusion Middleware wsadmin Command-Line Shell

- 3.1.3.2 Starting the Oracle Fusion Middleware wsadmin Command-Line Shell and Connecting to the Deployment Manager

- 3.1.3.3 Using the Oracle Fusion Middleware wsadmin Command-Line Online Help

- 3.1.3.3.1 Listing the Oracle Fusion Middleware wsadmin Command Categories

- 3.1.3.3.2 Listing the Commands Within an Oracle Fusion Middleware wsadmin Command-Line Category

- 3.1.3.3.3 Getting Help on a Specific Oracle Fusion Middleware wsadmin Command

- 3.1.3.4 Differences Between the wsadmin Commands and the WebLogic Scripting Tool (WLST) Commands

- 3.1.3.5 Differences Between Oracle Fusion Middleware wsadmin Commands and IBM WebSphere Wsadmin Commands

- 3.2 Basic Administration Tasks on IBM WebSphere

- 3.2.1 Referring to IBM WebSphere DIrectory Paths on Windows Systems

- 3.2.2 Starting and Stopping Servers on IBM WebSphere

- 3.2.2.1 Starting and Stopping IBM WebSphere Servers with Profile Scripts

- 3.2.2.2 Starting and Stopping IBM WebSphere Servers with Fusion Middleware Control

- 3.2.3 Configuring Metadata Services (MDS) on IBM WebSphere

- 3.2.3.1 Differences in MDS Command-Line Features on IBM WebSphere

- 3.2.3.1.1 Using the registerMetadataDBRepository authAlias parameter on IBM WebSphere

- 3.2.3.1.2 Using the registerMetadataDBRepository targetServers Parameter on IBM WebSphere

- 3.2.3.1.3 More Information About the registerMetadaDBRepository Command on IBM WebSphere

- 3.2.3.2 Differences in MDS Fusion Middleware Control Pages on IBM WebSphere

- 3.2.4 Configuring Oracle Fusion Middleware Logging on IBM WebSphere

- 3.2.5 Using the Oracle Fusion Middleware Diagnostic Framework on IBM WebSphere

- 3.2.5.1 Setting Up the Diagnostic Framework on IBM WebSphere

- 3.2.5.2 Restrictions When Using the WebLogic Server Diagnostic Framework (WLDF) on IBM WebSphere

- 3.2.6 Differences in Dump Sampling Commands

- 3.2.7 Creating a Data Source in an IBM WebSphere Cell

- 3.3 Deploying Applications on IBM WebSphere

- 3.3.1 Preparing to Deploy Oracle Fusion Middleware Applications on IBM WebSphere

- 3.3.2 Methods for Deploying Oracle Fusion Middleware Applications on IBM WebSphere

- 3.3.3 Deploying Applications that Require MDS Deployment Plan Customizations on IBM WebSphere

- 3.4 Configuring Oracle Fusion Middleware High Availability on IBM WebSphere

- 3.4.1 Documentation Resources for Configuring Oracle Fusion Middleware High Availability on IBM WebSphere

- 3.4.2 Configuring Java Object Cache for Oracle Fusion Middleware on IBM WebSphere

4 Managing Oracle SOA Suite on IBM WebSphere

- 4.1 Configuring Oracle SOA Suite and Oracle BAM Against an External LDAP Server on IBM WebSphere

- 4.1.1 Configuring SOA Suite Users and Groups in an External LDAP Server

- 4.1.2 Configuring Oracle SOA Suite and Oracle BAM in an External LDAP Server

- 4.2 Differences and Restrictions When Developing and Deploying Oracle SOA Suite Applications on IBM WebSphere

- 4.2.1 Oracle SOA Suite wsadmin and WLST Command Differences

- 4.2.2 Configuring the WebSphere Application Client for Use with Oracle JDeveloper

- 4.2.2.1 How to Configure the WebSphere Application Client for Use with Oracle JDeveloper on the Same Computer

- 4.2.2.1.1 IBM WebSphere ND: Finding Server Information from the IBM Console

- 4.2.2.1.2 IBM WebSphere AS: Finding Server Information from the IBM Console

- 4.2.2.2 How to Configure the WebSphere Application Client for Use with Oracle JDeveloper on Different Computers

- 4.2.2.2.1 Installing the WebSphere Application Client

- 4.2.2.2.2 Creating the wsadmin.sh/bat File

- 4.2.2.2.3 Running wsadmin.sh or wsadmin.bat from the Command Line

- 4.2.2.2.4 Editing the sas.client.props File

- 4.2.2.2.5 Creating an Application Server Connection in Oracle JDeveloper

- 4.2.3 Configuring the Proxy on IBM WebSphere Server

- 4.2.4 Creating an Application Server Connection

- 4.2.5 Deploying SOA Composite Applications

- 4.2.6 Using the Diagnostic Framework

- 4.2.7 Using EJB Bindings

- 4.2.7.1 EJB Service Binding

- 4.2.7.2 EJB Client

- 4.2.7.3 EJB Reference Binding

- 4.2.8 AQ Technology Adapter and WebSphere 7.0

- 4.2.9 JMS Technology Adapter on WebSphere 7.0

- 4.2.9.1 Avoiding JMS Adapter Connection Leaks

- 4.2.10 Oracle Database Adapter on WebSphere 7.0

- 4.3 Differences and Restrictions When Managing Oracle SOA Suite Components on IBM WebSphere

- 4.3.1 Configuring the Deployment Manager to Detect the Remote Node Agent

- 4.3.2 Publishing Services to a UDDI Registry

- 4.3.3 Oracle Enterprise Manager Fusion Middleware Control Console Shortcut Links

- 4.3.4 DefaultToDo Task Flow is Configured to Use HTTPS

- 4.3.5 Configuring the current-dateTime Function to Display Output in Seconds

- 4.3.6 Obtaining the Locator Object

- 4.3.7 Running the Facade API Client on IBM WebSphere

- 4.4 Differences and Restrictions When Managing Oracle BAM on IBM WebSphere

- 4.4.1 Configuring Oracle BAM Adapter

- 4.4.1.1 Configuring Oracle BAM Adapter Properties

- 4.4.1.2 Configuring Oracle BAM Connection Factories

- 4.4.1.3 Configuring Trusted Domains

- 4.4.2 Using Oracle Data Integrator with Oracle BAM

- 4.4.3 Using ICommand

- 4.4.3.1 Configuring Oracle BAM Server Port

- 4.4.3.2 Configuring Login Security

- 4.4.4 Configuring Logging for Oracle BAM on IBM WebSphere

- 4.4.5 Configuring Trusted Domains

- 4.4.6 Configuring Security

- 4.4.6.1 Configuring Login Security for Standalone Oracle BAM Components on IBM WebSphere

- 4.4.6.2 Configuring Oracle BAM to Use CLIENT_CERT Authentication on IBM WebSphere

- 4.4.6.3 Creating User/Group Mappings for Oracle BAM on IBM WebSphere

- 4.4.7 Using Oracle Internet Directory with Oracle BAM

- 4.4.8 Configuring Enterprise Message Sources to Connect to Remote JMS Queue/Topics

- 4.4.9 Using Oracle BAM Data Controls

- 4.4.9.1 Exceptions in JDeveloper

- 4.4.9.2 Application Server Connection Parameters

- 4.4.10 Configuring the LTPA Timeout for Active Data Reports

5 Managing Oracle WebCenter Portal on IBM WebSphere

- 5.1 Overview - Roadmaps

- 5.1.1 Getting WebCenter Portal Up and Running on IBM WebSphere

- 5.1.2 Creating a WebSphere Cell for Portal Framework Application Deployments

- 5.2 Differences Installing and Configuring Oracle WebCenter Portal on IBM WebSphere

- 5.2.1 Installing Oracle WebCenter Portal Products on IBM WebSphere

- 5.2.2 Configuring an IBM WebSphere Cell for WebCenter Portal

- 5.2.3 Configuring an IBM WebSphere Cell for Portal Framework Applications

- 5.2.4 Configuring an IBM WebSphere Cell for Portlet Producer Applications

- 5.2.5 Performing General Post-install Tasks for Oracle WebCenter Portal on WebSphere

- 5.2.5.1 Setting JDBC Driver Variables (DB2 only)

- 5.2.5.2 Starting the Node Agent and Deployment Manager

- 5.2.5.3 Opening IBM WebSphere Administrative Console

- 5.2.5.4 Starting WebCenter Portal Servers

- 5.2.6 Installing External LDAP ID Store for WebCenter Portal or Portal Framework Applications

- 5.2.6.1 Setting the Connection Pool on IBM WebSphere When Connecting to an External LDAP Server

- 5.2.7 Configuring an Admin User for WebCenter Portal

- 5.2.8 Configuring an Admin User for the Discussions Server

- 5.2.9 Configuring an Admin User for Pagelet Producer and Activity Graph Applications

- 5.2.10 Reassociating the Credential and Policy Store

- 5.2.11 Setting Cookie Paths for WebCenter Portal and Portal Framework Application Modules Post Deployment

- 5.2.12 Verifying a WebCenter Portal Installation on IBM WebSphere

- 5.2.13 Configuring User Registry Settings for External LDAP ID Store

- 5.2.14 Configuring Trust Service Information for the REST Service

- 5.2.15 Installing and Configuring IBM HTTP Server

- 5.2.16 Configuring Single Sign-On for WebCenter Portal or Portal Framework Applications

- 5.2.16.1 Configuring OAM 11g Single Sign-On

- 5.2.16.2 Configuring WebCenter Portal and Portal Framework Applications for Single Sign-On

- 5.2.17 Configuring SSL for WebCenter Portal or Portal Framework Applications

- 5.2.17.1 Obtaining the SSL Port for WebCenter Portal or Portal Framework Applications

- 5.2.17.2 Importing SSL Certificates on IBM WebSphere

- 5.2.18 Cloning Oracle WebCenter Portal Installations on IBM WebSphere

- 5.2.19 Configuring WebCenter Portal or Portal Framework Applications for High Availability on IBM WebSphere

- 5.2.19.1 Typical Oracle WebCenter Portal Cluster Topology

- 5.2.19.2 Install Required Oracle WebCenter Portal Components on Both Hosts

- 5.2.19.3 Configure a New WebSphere Cell on WCPHOST1

- 5.2.19.4 Federate WCPHOST2 and Configure Cell

- 5.2.19.5 Configure a Load Balancer

- 5.2.19.6 Configure Oracle Internet Directory as the LDAP Identity Store

- 5.2.19.7 Reassociate the Identity Store

- 5.2.19.8 Configure Distributed Java Object Cache

- 5.2.19.9 Configure Clustering for Discussions

- 5.2.19.10 Configure Activity Graph

- 5.3 Differences Developing and Deploying Portal Framework Applications on IBM WebSphere

- 5.3.1 Configuring a WebSphere Application Server Connection in JDeveloper

- 5.3.2 Deploying Portal Framework Applications on IBM WebSphere Directly from JDeveloper

- 5.3.2.1 Creating Database Connections for Seeded Data Sources on Out-of-the-Box Server

- 5.3.2.2 Creating Database Connections for Seeded Data Sources on Other Target Servers

- 5.3.2.3 Creating Database Connections to Custom Data Sources

- 5.3.2.4 Deploying Portal Framework Applications Using SSL

- 5.3.2.5 Deploying and Redeploying Portal Framework Applications From JDeveloper

- 5.3.3 Targeting Application EAR and WAR Files for IBM WebSphere Deployment

- 5.3.4 Deploying Portal Framework Application EARs using WebSphere Console and wsadmin

- 5.3.4.1 Deployment Prerequisites

- 5.3.4.2 Deploying Portal Framework Application EARs using WebSphere Admin Console

- 5.3.4.3 Deploying Portal Framework Application EARs using wsadmin Commands

- 5.3.5 Securing a Portal Framework Application Connection to IMAP and SMTP with SSL

- 5.3.6 Using the Deploy and Configure Script for Portal Framework Applications Deployed on WebSphere

- 5.3.7 Creating SQL Data Controls for Applications Deployed on WebSphere Administration Server

- 5.4 Differences Managing Oracle WebCenter Portal Components on IBM WebSphere

- 5.4.1 Running Oracle WebCenter Portal wsadmin Commands

- 5.4.2 Managing WebCenter Portal and Portal Framework Applications With Fusion Middleware Control

- 5.4.3 (WebCenter Portal Only) Migrating Portal Changes

- 5.5 Patching Oracle WebCenter Portal on IBM WebSphere from 11.1.1.7 to 11.1.1.8

- 5.6 Patching Oracle WebCenter Portal on IBM WebSphere from 11.1.1.6 to 11.1.1.8

- 5.7 Upgrading WebCenter Portal Framework Applications to 11.1.1.8

- 5.8 Restrictions Using Oracle WebCenter Portal on WebSphere

- 5.8.1 Oracle WebCenter Adapter for SharePoint Not Supported on WebSphere

- 5.8.2 Process Spaces Not Supported on WebSphere

- 5.8.3 Activity Rank for Oracle Secure Enterprise Search Not Supported on WebSphere

- 5.8.4 Web Clipping Portlet Not Supported on WebSphere

- 5.9 Troubleshooting Oracle WebCenter Portal on WebSphere

- 5.9.1 Diagnosing java.lang.RuntimeException or java.lang.NullPointerException

- 5.9.2 Connection Timeout Errors

- 5.9.3 Session Timeouts in WebCenter Portal

- 5.9.4 Session Timeouts Due to Inactivity

- 5.9.5 Access Denied Error When Importing WebCenter Portal

- 5.9.6 Users Can Log In With Old Passwords

- 5.9.7 WASX7015E: NameError Exception Running WSADMIN Commands

- 5.9.8 Unable to Deploy WebCenter Portal Workflows When the SOA MDS Schema is Running on DB2

- 5.9.9 HTTP 500 Error Accessing Portal Workflow Notifications in the Worklist Task Flow

- 5.9.10 OAM Single Sign-On Logout Not Working

- 5.9.11 Workflow Related Error Messages in Log Files

- 5.9.12 jiveURL Error Messages in Log Files

- 5.9.13 DCS Stack Messages in Log Files

- 5.9.14 Error Messages Exporting and Importing Portal Changes

6 Managing Oracle WebCenter Content on IBM WebSphere

- 6.1 Installing Oracle WebCenter Content on IBM WebSphere

- 6.1.1 Changing Java Socket Factories in the IBM JDK

- 6.1.2 Installing Oracle WebCenter Content Products on IBM WebSphere

- 6.1.3 Setting JDBC Driver Environment Variables for a DB2 Database

- 6.2 Configuring Oracle WebCenter Content on IBM WebSphere

- 6.2.1 Configuring Oracle WebCenter Content on IBM WebSphere

- 6.2.2 Propagating cwallet.sso Changes to the Deployment Manager

- 6.2.3 Specifying Deployment with SSL

- 6.2.4 Configuring an LDAP Server for Oracle WebCenter Content Users and Groups on IBM WebSphere

- 6.2.5 Configuring an Administration User for WebCenter Content

- 6.2.6 Setting Cookie Paths for Oracle WebCenter Content Application Modules

- 6.2.7 Setting Up Node Manager

- 6.2.8 Launching the IBM WebSphere Administrative Console

- 6.2.9 Increasing the Java VM Heap Size for an Oracle WebCenter Content Application Server

- 6.2.10 Configuring the Report Library for Records Management in Content Server

- 6.2.11 Configuring Session Persistence in a Clustered Environment

- 6.2.12 Using Oracle WebCenter Content wsadmin Commands Instead of WLST Commands

- 6.3 Configuring Oracle WebCenter Content Applications on IBM WebSphere

- 6.3.1 Mapping the weblayout Directory

- 6.3.2 Changing the Authentication Method for Oracle WebCenter Content Applications

- 6.4 Administering Oracle WebCenter Content Applications on IBM WebSphere

- 6.4.1 Starting or Restarting Content Server on IBM WebSphere

- 6.4.2 Logging In to WebCenter Content Server and Records

- 6.4.3 Managing an Oracle WebCenter Content Cell and Servers from the IBM WebSphere Administrative Console

- 6.4.4 Managing an Oracle WebCenter Content Cell, Servers, and Applications from Fusion Middleware Control

7 Managing Oracle Data Integrator on IBM WebSphere

- 7.1 Differences and Restrictions When Installing and Configuring Oracle Data Integrator Applications on IBM WebSphere

- 7.1.1 Creating a New IBM WebSphere Cell

- 7.2 Differences When Managing Oracle Data Integrator on IBM WebSphere

- 7.2.1 Creating a New Server in an IBM WebSphere Cell

- 7.2.2 Setting the Desired Logging Level on IBM WebSphere

- 7.2.3 Configuring OPMN on IBM WebSphere

8 Managing Web Services on IBM WebSphere

- 8.1 Configuring a Default Administrative User from the LDAP Directory

- 8.2 Configuring Oracle WSM on IBM WebSphere

- 8.2.1 Configuring Oracle WSM

- 8.2.2 Connecting to the Oracle WSM Policy Manager

- 8.3 Differences and Restrictions When Developing Web Services Applications on IBM WebSphere

- 8.3.1 High Availability

- 8.3.2 Asynchronous Web Services

- 8.3.3 JDeveloper

- 8.4 Differences and Restrictions When Managing Web Services Components on IBM WebSphere

- 8.4.1 Automatic Discovery of Oracle WSM Policy Manager

- 8.4.2 Web Services Atomic Transactions

- 8.4.3 No Support for Native Web Services

- 8.4.4 Reliable Messaging

- 8.4.5 Enterprise Manager Fusion Middleware Control

- 8.5 Using the Web Services wsadmin Commands

- 8.5.1 Executing the Web Services wsadmin Commands

- 8.5.2 WebServices wsadmin Commands

- 8.5.3 wsmManage wsadmin Commands

9 Managing Oracle Fusion Middleware Security on IBM WebSphere

- 9.1 IBM WebSphere Identity Stores

- 9.1.1 Configuring a Registry

- 9.1.2 Seeding a Registry

- 9.2 Recommendation for Multiple-Node Environments

- 9.3 Configuring the Trust Association Interceptor

- 9.4 Migrating Policies at Deployment

- 9.4.1 jps.policystore.migration

- 9.4.2 jps.policystore.applicationid

- 9.4.3 jps.policystore.removal

- 9.5 Migrating Credentials at Deployment

- 9.5.1 jps.credstore.migration

- 9.6 Reassociating Policies with reassociateSecurityStore

- 9.7 Deployment Mode

- 9.8 Configuring the JpsFilter and the JpsInterceptor

- 9.9 Using System Variables in Code Source URLs

- 9.10 Sample opss-application File

- 9.11 About the File web.xml

- 9.12 Executing Common Audit Framework wsadmin Commands

- 9.13 Configuring TAI to Work with OPSS

- 9.13.1 Configuring TAI with the WebSphere Console

- 9.13.2 Configuring the OPSS Keystore Service

- 9.14 Creating a Data Source

- 9.15 Executing Keystore Service Commands

- 9.16 Setting Parameters for Custom Audit Service Registration

10 Managing Oracle Business Intelligence on IBM WebSphere

- 10.1 Introduction to Oracle Business Intelligence on IBM WebSphere

- 10.1.1 Using Oracle Business Intelligence on IBM WebSphere

- 10.1.2 Using Both IBM WebSphere and WebLogic Server

- 10.2 Differences Installing and Configuring Oracle Business Intelligence on IBM WebSphere

- 10.2.1 Installing Oracle Business Intelligence on IBM WebSphere

- 10.2.1.1 Guidelines for Installing on Oracle Business Intelligence on IBM WebSphere

- 10.2.1.2 Summary of Software Only Install Procedure on IBM WebSphere

- 10.2.2 Configuring Oracle Business Intelligence in a New IBM WebSphere Cell

- 10.2.3 Configuring for BI Publisher on IBM WebSphere

- 10.2.3.1 Manually Configuring for BI Publisher on IBM WebSphere

- 10.2.3.2 Using the Administration Page in BI Publisher on IBM WebSphere

- 10.2.4 Configuring for Oracle RTD on IBM WebSphere

- 10.2.4.1 Disabling Parent Class Loading

- 10.2.4.2 Configuring Constraints for User-Defined Web Policy Sets

- 10.2.4.2.1 Configuring Policy Set Constraint Using Fusion Middleware Control

- 10.2.4.2.2 Configuring Policy Set Constraint Using Wsadmin

- 10.2.4.3 Installing Oracle RTD Client-Side Files

- 10.2.4.4 Populating the Example Data Tables

- 10.2.5 Starting and Stopping Components on IBM WebSphere

- 10.2.6 Determining Ports for Oracle BI Components on IBM WebSphere

- 10.2.7 Configuring for Security of Oracle Business Intelligence on IBM WebSphere

- 10.2.7.1 Configuring the LDAP-Based Identity Store on IBM WebSphere

- 10.2.7.1.1 Step 1: Ensuring the Prerequisites for the Identity Store on IBM WebSphere

- 10.2.7.1.2 Step 2: Configuring Required Users and Groups in the Provider for IBM WebSphere

- 10.2.7.1.3 Step 3: Creating the Properties File for the Identity Store on IBM WebSphere

- 10.2.7.1.4 Step 4: Updating the BISystemUser Credential on IBM WebSphere

- 10.2.7.1.5 Step 5: Reassociating Oracle Business Intelligence with the Identity Store on IBM WebSphere

- 10.2.7.1.6 Step 6: Synchronizing the Configuration on IBM WebSphere

- 10.2.7.1.7 Step 7: Refreshing the GUIDs on IBM WebSphere

- 10.2.7.2 Configuring SSO for Oracle Business Intelligence on IBM WebSphere

- 10.2.7.2.1 Step 1: Installing and Configuring Oracle Business Intelligence on IBM WebSphere

- 10.2.7.2.2 Step 2: Configuring the IBM HTTP Server for IBM WebSphere

- 10.2.7.2.3 Step 3: Configuring Oracle Access Manager and Oracle Internet Directory on IBM WebSphere

- 10.2.7.2.4 Step 4: Registering the WebGate Agent with Oracle Access Manager on IBM WebSphere

- 10.2.7.2.5 Step 5: Updating the Application Policy for Oracle Business Intelligence on IBM WebSphere

- 10.2.7.2.6 Step 6: Installing and Configuring WebGate on IBM WebSphere

- 10.2.7.2.7 Step 7: Configuring IBM WebSphere for SSO in Oracle Access Manager and IAP

- 10.2.7.2.8 Step 8: Configuring the Logout for Oracle Business Intelligence on IBM WebSphere

- 10.2.7.2.9 Step 9: Updating Oracle Business Intelligence for SSO on IBM WebSphere

- 10.2.7.2.10 Step 10: Restarting the Processes for IBM WebSphere

- 10.2.7.3 Configuring SSL for Oracle Business Intelligence on IBM WebSphere

- 10.2.8 Configuring for Map Views in Oracle Business Intelligence on IBM WebSphere

- 10.2.9 Configuring for Actions that Invoke a Java Method on IBM WebSphere

- 10.2.10 Configuring for Oracle BI for Microsoft Office on IBM WebSphere

- 10.2.11 Configuring for Scaling the Deployment of Oracle Business Intelligence on IBM WebSphere

- 10.2.11.1 Configuring for Scaling Out JEE Components on IBM WebSphere

- 10.2.11.2 Configuring for Scaling Out System Components on IBM WebSphere

- 10.2.11.3 Creating an Oracle RTD Cluster on IBM WebSphere

- 10.2.11.3.1 Associating Users and Groups for Oracle RTD on IBM WebSphere

- 10.2.11.3.2 Setting Clustering Properties for Oracle RTD

- 10.2.12 Configuring for Load Balancing with the IBM HTTP Server

- 10.2.12.1 Step 1: Configuring the IBM HTTP Server for Oracle Business Intelligence on IBM WebSphere

- 10.2.12.2 Step 2: Configuring Oracle Business Intelligence to Recognize the Load Balancer on IBM WebSphere

- 10.2.12.3 Step 3: Verifying the Configuration of the Load Balancer on IBM WebSphere

- 10.3 Deinstalling Oracle Business Intelligence and IBM WebSphere

- 10.4 Upgrading Oracle Business Intelligence to Run on IBM WebSphere

- 10.5 Troubleshooting Oracle Business Intelligence on IBM WebSphere

- 10.5.1 Verifying the Configuration of Oracle Business Intelligence on IBM WebSphere

- 10.5.2 Viewing Log Files for Oracle Business Intelligence on IBM WebSphere

- 10.5.3 Diagnosing java.lang.RuntimeException or java.lang.NullPointerException for Oracle Business Intelligence on IBM WebSphere

11 Managing OAM Identity Assertion on IBM WebSphere

- 11.1 Introduction to OAM Identity Assertion on IBM WebSphere

- 11.1.1 Scenario 1: Oracle Access Manager 10g (10.1.4.3) with the IAP on IBM WebSphere

- 11.1.2 Scenario 2: OAM 11g with the IAP and IBM WebSphere

- 11.2 Installing Components for the Oracle Access Manager IAP for IBM WebSphere

- 11.3 Introduction to the Oracle Access Manager 10g (10.1.4.3) Configuration Tool

- 11.4 Provisioning WebGate and Configuring OAM 10g (10.1.4.3) and the IAP for IBM WebSphere

- 11.5 Provisioning and Configuring OAM 11g for the IAP and IBM WebSphere

- 11.5.1 About Provisioning WebGates and AccessGates with OAM 11g

- 11.5.2 Provisioning Agents and Creating OAM 11g Policies for IBM WebSphere

- 11.6 Installing the Required WebGate for the IHS Web Server

- 11.7 Preparing the IHS Web Server

- 11.8 Preparing the Login Form for 10.1.4.3 WebGate

- 11.9 Configuring IBM WebSphere for OAM SSO and the IAP

- 11.9.1 Configuring a Stand Alone LDAP Registry for OAM in IBM WebSphere

- 11.9.2 Adding and Configuring a Virtual Host in IBM WebSphere

- 11.9.3 Configuring IHS Reverse Proxy in the IBM WebSphere Console

- 11.9.4 Creating the Interceptor Entry in the IBM WebSphere Console

- 11.9.5 Configuring the OAM TAI Configuration File

- 11.9.5.1 About Configuring the OAM TAI Configuration File

- 11.9.5.2 Configuring the OAM TAI Configuration File

- 11.10 Configuring SSO Logout for Oracle Access Manager 10g

- 11.10.1 Configuring Logout for Generic (or Non-ADF) Applications

- 11.10.2 Configuring Logout for ADF-Coded Applications

- 11.10.2.1 Configuring 10g WebGate for Logout with OAM 10g

- 11.10.2.2 Configuring SSO Logout for OPSS with ADF-coded applications and OAM 10g Webgate

- 11.10.2.3 Configuring oamAuthenProvider.jar in the IBM WebSphere classpath

- 11.10.2.4 Verifying SSO Logout

- 11.11 Configuring SSO Logout for Access Manager 11g

- 11.12 Known Issues

A Fusion Middleware Control Page Reference

- A.1 Understanding the Information on the IBM WebSphere Cell Home Page

- A.2 Understanding the Information on the WebSphere Application Server Home Page

- A.3 Understanding the Information on the IBM WebSphere Application Deployment Home Page

Preface

This preface contains the following sections:

- Audience

- Documentation Accessibility

- Related Documents

- Conventions

Audience

This manual is intended for Oracle Fusion Middleware system administrators who are responsible for installing and managing Oracle Fusion Middleware on third-party application servers, such as IBM WebSphere.

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.

Related Documents

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

- Oracle Fusion Middleware Configuration Guide for IBM WebSphere Application Server

- Oracle Fusion Middleware Administrator's Guide for Oracle Application Development Framework

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.

1 Introduction to Third-Party Application Servers

This chapter introduces the Oracle Fusion Middleware 11g support for third-party application servers.

This chapter contains the following sections:

- Section 1.1, "What Is a Third-Party Application Server?"

- Section 1.2, "Oracle Fusion Middleware Components That Support Third-Party Application Servers"

- Section 1.3, "Overview of the Oracle Fusion Middleware IBM WebSphere Support"

- Section 1.4, "Documentation Resources for Using Oracle Fusion Middleware on IBM WebSphere"

1.1 What Is a Third-Party Application Server?

A third-party application server is an application server provided by a vendor other than Oracle.

Oracle supports Oracle WebLogic Server as the primary platform for Oracle Fusion Middleware software components. However, to accommodate customers who want to run specific Oracle Fusion Middleware component software, such as Oracle SOA Suite, on application servers other than Oracle WebLogic Server, Oracle supports the third-party application servers described in this document.

1.2 Oracle Fusion Middleware Components That Support Third-Party Application Servers

You can configure the following Oracle Fusion Middleware components on supported third-party application servers:

- Oracle SOA Suite

- Oracle WebCenter Portal

- Oracle WebCenter Content

- Oracle Data Integrator

- Oracle Business Intelligence

- Oracle Application Development Framework (Oracle ADF)

- Oracle Application Developer Runtime

For this release of Oracle Fusion Middleware 11g, Oracle supports only IBM WebSphere Application Server as a third-party application server for these Oracle Fusion Middleware products.

1.3 Overview of the Oracle Fusion Middleware IBM WebSphere Support

The following sections provide more detail about the supported Oracle Fusion Middleware features on IBM WebSphere:

- Supported IBM WebSphere Application Servers

- Understanding the Topology of Oracle Fusion Middleware on IBM WebSphere

1.3.1 Supported IBM WebSphere Application Servers

Oracle supports the following third-party application server products for specific Oracle Fusion Middleware products and certain Oracle Fusion Middleware configurations:

- IBM WebSphere Application Server - Network Deployment (ND) 7.0.0

- IBM WebSphere Application Server 7.0.0

Note that you must also use a supported Fix Pack, which is downloaded separately and applied to the base 7.0.0 installation.

Note:

If you are using an IBM DB2 database, then download the latest DB2 JDBC drivers. For more information, see Section 2.4.1, "IBM Online Resources for Obtaining and Installing the IBM WebSphere Software".

For more information, see Section 2.2, "Task 2: Obtain the Necessary Software Media or Downloads".

For the most accurate and up-to-date information about the IBM WebSphere Application Server versions and Fix Packs required and supported by Oracle Fusion Middleware, see the certification information on the Oracle Technology Network (OTN), as described in Section 2.1, "Task 1: Review the System Requirements and Certification Information".

Note:

In this guide, IBM WebSphere is used to reference both IBM WebSphere Application Server (AS) and IBM WebSphere Application Server Network Deployment (ND). The specific product names are used when appropriate.

1.3.2 Understanding the Topology of Oracle Fusion Middleware on IBM WebSphere

When you install and configure Oracle Fusion Middleware on IBM WebSphere, the resulting topology depends on whether you are running IBM WebSphere Application Server or IBM WebSphere Application Server - ND.

- Typical Oracle Fusion Middleware Topology on IBM WebSphere Application Server - ND

- Typical Oracle Fusion Middleware Topology on IBM WebSphere Application Server

1.3.2.1 Typical Oracle Fusion Middleware Topology on IBM WebSphere Application Server - ND

When you install and configure Oracle Fusion Middleware with IBM WebSphere Application Server - ND, the configuration process automatically creates an IBM WebSphere cell that contains a special server, in addition to the Deployment Manager, called the OracleAdminServer.

This OracleAdminServer hosts the key infrastructure pieces of Oracle Fusion Middleware, including the Java Required Files (JRF) and Oracle Enterprise Manager product templates:

- The JRF template provides important Oracle libraries and other capabilities that support new versions of APIs that many Oracle Fusion Middleware products and applications depend upon.

- The Oracle Enterprise Manager template provides Oracle Enterprise Manager Fusion Middleware Control, which you can use to manage the Oracle Fusion Middleware products you install and configure.

Additional products are installed on additional servers in the newly created IBM WebSphere cell.

When you configure your IBM WebSphere cell for use with Oracle Fusion Middleware, you can also include additional servers and clusters in your cell, and you can configure the Oracle Fusion Middleware products to work with an Oracle Real Application Clusters (Oracle RAC) database.

1.3.2.2 Typical Oracle Fusion Middleware Topology on IBM WebSphere Application Server

When you install and configure Oracle Fusion Middleware with IBM WebSphere Application Server, only one server is created. This one server is used both for administration and for application hosting.

1.4 Documentation Resources for Using Oracle Fusion Middleware on IBM WebSphere

You can refer to the following additional documentation resources for information about running Oracle Fusion Middleware on IBM WebSphere:

- The IBM WebSphere documentation available on the WebSphere Application Server Information Center for basic conceptual information about IBM WebSphere, as well details about installing IBM WebSphere.

- This document for an overview of the Oracle Fusion Middleware support for IBM WebSphere, a summary of the overall steps required to install and configure Oracle Fusion Middleware on IBM WebSphere, and a high-level listing of the features and tools available for installing and managing Oracle Fusion Middleware on IBM WebSphere.

- Oracle Fusion Middleware Configuration Guide for IBM WebSphere Application Server for complete information on the capabilities of the Oracle Fusion Middleware Configuration Wizard, including information about creating and modifying cells, how to add additional servers and clusters to a cell, and how to configure Oracle Fusion Middleware products to support an Oracle Real Application Clusters (Oracle RAC) database.
Oracle Fusion Middleware Configuration Guide for IBM WebSphere Application Server does not provide information for Oracle Business Intelligence.

- Specific sections of the Oracle Fusion Middleware documentation library for information about specific feature areas described in this guide. As you review this document, note the links to specific Oracle documentation that can help you successfully develop and administer your Oracle Fusion Middleware applications on IBM WebSphere.

2 Installing and Configuring Oracle Fusion Middleware on IBM WebSphere

This chapter describes how to install and configure Oracle Fusion Middleware with IBM WebSphere.

Note:

This chapter provides basic information about how to install and configure a single instance of Oracle Fusion Middleware on IBM WebSphere. If you are interested in configuring a high availability environment on IBM WebSphere, then review the content in this chapter, and then see Section 3.4, "Configuring Oracle Fusion Middleware High Availability on IBM WebSphere".

This chapter contains the following tasks:

- Section 2.1, "Task 1: Review the System Requirements and Certification Information"

- Section 2.2, "Task 2: Obtain the Necessary Software Media or Downloads"

- Section 2.3, "Task 3: Identify a Database and Install the Required Database Schemas"

- Section 2.4, "Task 4: Install the IBM WebSphere Software"

- Section 2.5, "Task 5: Install Oracle Fusion Middleware"

- Section 2.6, "Task 6: Configure Your Oracle Fusion Middleware Components in a New IBM WebSphere Cell"

- Section 2.7, "Task 7: Start the IBM WebSphere Servers"

- Section 2.8, "Task 8: Verify the Configuration of the IBM WebSphere Cell"

- Section 2.9, "Task 9: Install and Configure an LDAP Server"

2.1 Task 1: Review the System Requirements and Certification Information

Before performing any upgrade or installation you should read the Oracle Fusion Middleware System Requirements and Specifications to ensure that your environment meets the minimum installation requirements for the products you are installing.

The system requirements document covers information such as hardware and software requirements, minimum disk space and memory requirements, and required system libraries, packages, or patches.

In addition, you should review the Oracle Fusion Middleware Supported System Configurations. The certification document covers supported installation types, platforms, operating systems, databases, JDKs, and third-party products.

2.2 Task 2: Obtain the Necessary Software Media or Downloads

For this installation and configuration procedure, you will need to obtain the following software:

- IBM WebSphere 7.0 and any required Fix Packs for the IBM WebSphere software.
For more information, see Section 2.4.1, "IBM Online Resources for Obtaining and Installing the IBM WebSphere Software.".

For specific information the software requirements, refer to Section 2.1, "Task 1: Review the System Requirements and Certification Information".

- If you are using an IBM DB2 database, be sure to download the latest DB2 JDBC drivers for the JDBC data source connections for required Oracle Fusion Middleware schemas.
For more information, see the Section 2.4.1, "IBM Online Resources for Obtaining and Installing the IBM WebSphere Software".

- Oracle Fusion Middleware Repository Creation Utility 11g Release 1 (11.1.1.6.0) or later

- One of the following Oracle Fusion Middleware software products, which are supported on IBM WebSphere:

- Oracle Application Development Runtime 11g Release 1 (11.1.1.6.0) or later

- Oracle SOA Suite 11g Release 1 (11.1.1.6.0) or later

- Oracle WebCenter Portal 11g Release 1 (11.1.1.6.0) or later

- Oracle WebCenter Content 11g Release 1 (11.1.1.6.0) or later

- Oracle Business Intelligence 11g Release 1 (11.1.1.7.0) or later

Note:

The version numbers included here were accurate at the time this document was published. For specific software requirements, refer to the references in Section 2.1, "Task 1: Review the System Requirements and Certification Information".

For information about where to download the software, refer to the Oracle Fusion Middleware Download, Installation, and Configuration Readme Files on the Oracle Technology Network (OTN).

2.3 Task 3: Identify a Database and Install the Required Database Schemas

The following Oracle Fusion Middleware products require a metadata repository with required schemas to be installed in a supported database:

- Oracle SOA Suite

- Oracle WebCenter Portal

- Oracle WebCenter Content

- Oracle Business Intelligence

You cannot configure these products without first installing the required schemas in a supported database.

To create or update schemas in a database, use the Repository Creation Utility (RCU).

Note:

It is recommended that all metadata repositories reside on a database at the same site as the products to minimize network latency issues.

For information about identifying the schemas required for specific Oracle Fusion Middleware products, as well as information about the database requirements and running RCU, refer to Oracle Fusion Middleware Repository Creation Utility User's Guide.

If you are installing Oracle WebCenter Content, then also refer to "Creating Oracle WebCenter Content Schemas with the Repository Creation Utility" in the Oracle Fusion Middleware Installing and Configuring Oracle WebCenter Content.

For information on the databases supported by Oracle Fusion Middleware, see the certification information described in Section 2.1, "Task 1: Review the System Requirements and Certification Information".

Make a note of the database connection information and the passwords for the schemas you create with the Repository Creation Utility. You will need these later when you configure the Oracle Fusion Middleware products.

2.4 Task 4: Install the IBM WebSphere Software

Oracle Fusion Middleware supports both the IBM WebSphere Application Developer - Network Deployment (ND) and IBM WebSphere Application Server (AS) products.

To install and configure Oracle Fusion Middleware with IBM WebSphere, you must first install (but not configure) IBM WebSphere 7.0 and apply the latest Fix Pack for IBM WebSphere 7.0.

Refer to the following sections for more information:

- IBM Online Resources for Obtaining and Installing the IBM WebSphere Software

- Important Considerations Before Installing the IBM WebSphere Software

2.4.1 IBM Online Resources for Obtaining and Installing the IBM WebSphere Software

Refer to the following IBM resources for more information.

Note that Oracle is not responsible for the content in the following links. These references are provided for convenience only. Be sure to refer to the IBM documentation provided with or referenced by your IBM WebSphere software distribution:

- To obtain and install the IBM WebSphere software, refer to the IBM WebSphere documentation. For more information, see Section 1.4, "Documentation Resources for Using Oracle Fusion Middleware on IBM WebSphere".

- For more information about the Fix Packs available for IBM WebSphere 7.0, refer to the Fix list for IBM WebSphere Application Server V7.0 on the IBM Support Web site.
You install the Fix Packs using the IBM WebSphere Update Installer. For more information, see the information about the Maintenance Download Wizard for WebSphere Application Server V7.0 on the IBM Support Web site.

- If you are using an IBM DB2 database, be sure to review and download the latest DB2 JDBC drivers, which are available at the following IBM Web site:

http://www-01.ibm.com/support/docview.wss?uid=swg21363866

In particular, be sure to download and install IBM DB2 driver version 4.13.102 or later.

2.4.2 Important Considerations Before Installing the IBM WebSphere Software

Before you perform the IBM WebSphere installation, note the following requirements for Oracle Fusion Middleware products:

- Using the Correct IBM WebSphere Installer for Your Platform

- About the Sample Applications and Default Profiles During the IBM WebSphere Installation

- About the WAS_HOME Directory Path

2.4.2.1 Using the Correct IBM WebSphere Installer for Your Platform

Note that like Oracle WebLogic Server, IBM WebSphere is available for different platforms. Some platforms, such as Linux 64-bit platforms, require unique IBM WebSphere installers.

Before you begin your IBM WebSphere installation, be sure you have obtained the correct IBM WebSphere installer for your platform.

2.4.2.2 About the Sample Applications and Default Profiles During the IBM WebSphere Installation

Do not install any sample applications or create any profiles during the IBM WebSphere installation process.

The goal is to install the IBM WebSphere software on disk in a directory available to the Oracle Fusion Middleware software installation, which you will perform later. You will use the Oracle Fusion Middleware Configuration wizard to configure the required IBM WebSphere profiles.

2.4.2.3 About the WAS_HOME Directory Path

When you install the IBM WebSphere software, you are prompted for the location where you want to install the software. For the purposes of this documentation, this location is later referred to as the WAS Home, or WAS_HOME in examples.

If you accept the default values that are provided during the installation, then the WAS_HOME is installed in the following directory structure:

DISK/IBM/WebSphere/Application Server

Create the WAS_HOME for the IBM WebSphere software on the same host where you plan to install the Oracle Fusion Middleware software.

Make a note of this path. You will be asked to identify the location of the IBM WebSphere directory when you configure Oracle Fusion Middleware.

2.5 Task 5: Install Oracle Fusion Middleware

The following sections provide information on installing Oracle Fusion Middleware with IBM WebSphere:

- General Installation Instructions for the Supported Oracle Fusion Middleware Products

- Special Instructions When Installing Oracle Fusion Middleware with IBM WebSphere

2.5.1 General Installation Instructions for the Supported Oracle Fusion Middleware Products

For general instructions on installing any of the Oracle Fusion Middleware products that are supported on IBM WebSphere, refer to Table 2-1.

Table 2-1 Locating Installation Information for Oracle Fusion Middleware Products

Product

Installation Instructions

Oracle Application Developer Runtime

"Installation Instructions" in Oracle Fusion Middleware Installation Guide for Application Developer

Oracle SOA Suite

"Installation Instructions" in Oracle Fusion Middleware Installation Guide for Oracle SOA Suite and Oracle Business Process Management Suite

Oracle WebCenter Portal

"Installing Oracle WebCenter Portal" in Oracle Fusion Middleware Installation Guide for Oracle WebCenter Portal

Oracle WebCenter Content

"Using the Installer for Oracle WebCenter Content" in Oracle Fusion Middleware Installing and Configuring Oracle WebCenter Content

Oracle Business Intelligence

"Installing Oracle Business Intelligence" in Oracle Fusion Middleware Installation Guide for Oracle Business Intelligence

2.5.2 Special Instructions When Installing Oracle Fusion Middleware with IBM WebSphere

Note the following special instructions that apply when you are installing Oracle Fusion Middleware products on IBM WebSphere:

- When you are prompted to specify a JRE/JDK location, you can specify the following directory in the IBM WebSphere home:

(UNIX) WAS_HOME/java
(Windows) WAS_HOME\java

For example, if you are using the default location for a typical IBM WebSphere Application Server directory on a UNIX operating system:

diskname/IBM/WebSphere/AppServer/java

- Before installing Oracle WebCenter Content, you need to change the Java socket factories to the default JSSE implementation. For more information, see Section 6.1.1, "Changing Java Socket Factories in the IBM JDK."

- For information on Oracle Business Intelligence, see Section 10.2, "Differences Installing and Configuring Oracle Business Intelligence on IBM WebSphere."

- When you are prompted to provide a Middleware home, note that you can enter a new Middleware home directory path.
When you install Oracle Fusion Middleware products on Oracle WebLogic Server, you create the Middleware home, when you install Oracle WebLogic Server. This is because Oracle WebLogic Server is included in the Middleware home.

In contrast, when you install Oracle Fusion Middleware on IBM WebSphere, you create the Middleware home when you install the Oracle Fusion Middleware software. This is because the IBM WebSphere software is not installed inside the Middleware home. It is installed in a separate directory structure.

- When you select IBM WebSphere as your application server and you are prompted for the Application Server Location, enter the path to the IBM WebSphere application server directory you created in Section 2.4, "Task 4: Install the IBM WebSphere Software".
For example:

diskname/IBM/WebSphere/AppServer/

2.6 Task 6: Configure Your Oracle Fusion Middleware Components in a New IBM WebSphere Cell

Note:

For information on Oracle Business Intelligence, see Section 10.2.2, "Configuring Oracle Business Intelligence in a New IBM WebSphere Cell"

To configure Oracle Fusion Middleware components in an IBM WebSphere environment, you use a special version of the Oracle Fusion Middleware Configuration Wizard.

This section describes how to use the Configuration Wizard to configure your Oracle Fusion Middleware products in a simple IBM WebSphere cell. For complete information about using the Oracle Fusion Middleware Configuration Wizard, including information about adding servers and clusters to a cell, refer to the Oracle Fusion Middleware Configuration Guide for IBM WebSphere Application Server.

Note:

The instructions here describe how to use the Configuration Wizard to configure your components. However, you can also use the WebSphere wsadmin command-line utility to configure your Oracle Fusion Middleware components.

- For more information about using the wsadmin command-line utility, see Section 3.1.3, "Using the Oracle Fusion Middleware wsadmin Commands".

- For more information about configuring components with wsadmin, see "Using wsadmin to Configure Oracle Fusion Middleware" in the Oracle Fusion Middleware Configuration Guide for IBM WebSphere Application Server.

To configure your Oracle Fusion Middleware product in a new IBM WebSphere cell:

1. If you have installed the Oracle Fusion Middleware schemas in an IBM DB2 database, then be sure to perform the required preconfiguration steps.
For more information, see "Before You Begin" in the Oracle Fusion Middleware Configuration Guide for IBM WebSphere Application Server.

2. Start the Oracle Fusion Middleware Configuration Wizard by running the following command in the Oracle home of the product you want to configure:

(UNIX) MW_HOME/ORACLE_HOME/common/bin/was_config.sh
(Windows) MW_HOME\ORACLE_HOME\common\bin\was_config.cmd

Consider the following notes when starting the Configuration Wizard:

- Be sure to start the IBM WebSphere version of the Configuration Wizard. For more information, see "Starting the Configuration Wizard" in Oracle Fusion Middleware Creating WebSphere Cells Using the Configuration Wizard.

- In the preceding example, note that you must replace the ORACLE_HOME with the path to the Oracle home of the product you are about to configure. For example, if you are configuring an Oracle SOA home, enter the following on a UNIX system:

SOA_ORACLE_HOME/common/bin/was_config.sh

3. Follow the instructions on the screen to configure a new IBM WebSphere cell.
Refer to the following for more information:

- General Information About Using the Configuration Wizard on IBM WebSphere

- Component-Specific Information About Using the Configuration Wizard on IBM WebSphere

- Troubleshooting Errors When Configuring a Cell on Windows 2003 and 2008

2.6.1 General Information About Using the Configuration Wizard on IBM WebSphere

Note the following information as you advance through the Configuration Wizard:

- Be sure to make a note of the values you enter on the Specify Cell, Profile, and Node Name Information screen. You will need these later when you are starting and managing the cell. In particular, make note of the values you enter in the Deployment Manager Profile Name field and the Application Server Profile Name field.

- When the Add Products to Cell screen appears, refer to the following:
"Fusion Middleware Product Templates" in the Oracle Fusion Middleware Domain Template Reference if you have questions about what capabilities are configured when you select each template.

Component-Specific configuration information in the appropriate chapter of this guide. For more information, see Section 2.6.2, "Component-Specific Information About Using the Configuration Wizard on IBM WebSphere".

- If you select a product that requires a database schema, you will be prompted for database connection information for each required schema. To fill out this screen, use the database and schema information you noted in Section 2.3, "Task 3: Identify a Database and Install the Required Database Schemas".

- If you are using an IBM DB2 database to host your Oracle Fusion Middleware schemas, be sure to use a supported IBM DB2 JDBC driver. For more information, see Section 2.4.1, "IBM Online Resources for Obtaining and Installing the IBM WebSphere Software".

- When you are prompted for advanced options, you can click Next and use the default settings. Refer to Section 1.3.2, "Understanding the Topology of Oracle Fusion Middleware on IBM WebSphere" for information on the topologies that will be created using the default settings.
If you wish to modify the default settings (for example, if you want to target the products to different servers in the cell), refer to Oracle Fusion Middleware Configuration Guide for IBM WebSphere Application Server.

2.6.2 Component-Specific Information About Using the Configuration Wizard on IBM WebSphere

For component-specific configuration information, refer to the following:

- Chapter 4, "Managing Oracle SOA Suite on IBM WebSphere"

- Chapter 5, "Managing Oracle WebCenter Portal on IBM WebSphere"

- Chapter 6, "Managing Oracle WebCenter Content on IBM WebSphere"

2.6.3 Troubleshooting Errors When Configuring a Cell on Windows 2003 and 2008

When IBM WebSphere is installed on Windows 2003 or Windows 2008, the following error sometimes displays when you attempt to create a cell:

WebSphere Profile Update Failed!
No Changes Were Saved To The WebSphere Profile
Profile Location: x:\mydir\APPSER~1\profiles\Dmgr02
Reason Exception saving changes to WebSphere configuration

The issue is due to the Jython libraries shipped with IBM WebSphere. As a workaround:

1. Locate and edit the file:

WAS_HOME\optionalLibraries\jython\Lib\javaos.py

2. Locate the function: _getOsType

3. Edit the _osTypeMap variable to return "nt" as the default.

_osTypeMap = (
( "nt", r"(nt)|(Windows NT)|(Windows NT 4.0)|(WindowsNT)|"
r"(Windows 2000)|(Windows XP)|(Windows CE)" ),
( "dos", r"(dos)|(Windows 95)|(Windows 98)|(Windows ME)" ),
( "mac", r"(mac)|(MacOS.*)|(Darwin)" ),
( "None", r"(None)" ),
( "nt", r"(.*)" ), # default - posix seems to vary mast widely
)

4. Save the changes.

2.7 Task 7: Start the IBM WebSphere Servers

After you finish configuring the Oracle Fusion Middleware software successfully, you can start the IBM WebSphere Deployment Manager, Node, and Servers.

The following procedure shows the sequence you must use to start the deployment manager, the node, and the servers in the cell.

Notes:

Before you start any Oracle WebCenter Content Node or Server, see "Verifying the Oracle WebCenter Content Configuration" in the Oracle Fusion Middleware Installing and Configuring Oracle WebCenter Content for information about postinstallation tasks that need to be completed before you log in to a server for the first time.

For information on starting Oracle BI components on IBM WebSphere, see Section 10.2.5, "Starting and Stopping Components on IBM WebSphere."

In the following examples, replace the names of the deployment manager and profile name with the values you entered in the Configuration Wizard in Section 2.6, "Task 6: Configure Your Oracle Fusion Middleware Components in a New IBM WebSphere Cell":

1. Start the Deployment Manager:
Navigate to the following directory in the IBM WebSphere home and enter the following command:

(UNIX) profiles/deployment_mgr_name/bin/startManager.sh
-profileName dmgr_profileName
(Windows) profiles\deployment_mgr_name\bin\startManager.cmd
-profileName dmgr_profileName

For example, on a UNIX operating system:

/disk01/IBM/WebSphere/AppServer/profiles
/Dmgr01/bin/startManager.sh -profileName Dmgr01

2. Start the node:
Navigate to the following directory in the IBM WebSphere home and enter the following command:

(UNIX) profiles/profile_name/bin/startNode.sh -profileName profileName
(Windows) profiles\profile_name\bin\startNode.cmd -profileName profileName

For example, on a UNIX operating system:

/disk01/IBM/WebSphere/AppServer/profiles /Custom01/bin/startNode.sh
-profileName custom01

3. Start the OracleAdminServer server:
Navigate to the following directory in the IBM WebSphere home and enter the following command:

(UNIX) profiles/profile_name/bin/startServer.sh OracleAdminServer
-profileName profileName
(Windows) profiles\profile_name\bin\startServer.cmd OracleAdminServer
-profileName profileName

For example, on a UNIX operating system:

/disk01/IBM/WebSphere/AppServer/profiles/Custom01/bin/startServer.sh
OracleAdminSErver
-profileName Custom01

4. Start any additional servers that were configured as part of your IBM WebSphere cell.
After you start the OracleAdminServer, you can start the other servers using the IBM WebSphere Administrative Console or Oracle Enterprise Manager Fusion Middleware Control. For more information, see Section 3.1, "Summary of the Oracle Fusion Middleware Management Tools on IBM WebSphere".

Alternatively, you can use the startServer script, as follows:

Navigate to the following directory in the IBM WebSphere home and enter the following command:

(UNIX) profiles/profile_name/bin/startServer.sh server_name
-profileName profileName
profiles\profile_name\bin\startServer.cmd server_name
-profileName profileName

For example, for an Oracle SOA Suite cell on a UNIX operating system:

/disk01/IBM/WebSphere/AppServer/profiles
/Custom01/bin/startServer.sh soa_server1
-profileName Custom01

The typical servers that are configured for each of the Oracle Fusion Middleware components are listed in Table 2-2.

Table 2-2 Typical Oracle Fusion Middleware Component-Specific Managed Servers in an IBM WebSphere Cell

Component

Typical Managed Servers

Oracle SOA Suite

soa_server1, bam_server1

Oracle WebCenter Portal

WC_Spaces, WC_Collaboration, WC_Portlet, WC_Utilities

Oracle WebCenter Content

UCM_server1, URM_server1, or IBR_server1

Oracle Business Intelligence

bi_server1

2.8 Task 8: Verify the Configuration of the IBM WebSphere Cell

To verify the installation, use the IBM WebSphere Administration Console and Oracle Enterprise Manager Fusion Middleware Control to verify that the management tools are working and the servers are up and running.

Refer to Section 3.1, "Summary of the Oracle Fusion Middleware Management Tools on IBM WebSphere" for more information on locating the URLs for these Web-based management tools.

2.9 Task 9: Install and Configure an LDAP Server

Most Oracle Fusion Middleware components require a supported LDAP server. However, an LDAP server is not automatically installed and configured when you install Oracle Fusion Middleware components on IBM WebSphere. Oracle Fusion Middleware components do not support WebSphere's built-in file-based user registry

Important Note:

To configure an LDAP-based identity store for Oracle Fusion Middleware, see Section 9.1, "IBM WebSphere Identity Stores".

2.9.1 General Information About Supported LDAP Servers and Identity Stores

For information about the LDAP servers that Oracle Fusion Middleware supports, see the certification information on the Oracle Technology Network (OTN):

http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html

2.9.2 Oracle Fusion Middleware Component-Specific LDAP Information

For information about configuring users and roles for each Oracle Fusion Middleware component that is supported on IBM WebSphere, see the appropriate section below:

- Section 4.1.1, "Configuring SOA Suite Users and Groups in an External LDAP Server".

- Section 5.2.7, "Configuring an Admin User for WebCenter Portal"

- Section 5.2.8, "Configuring an Admin User for the Discussions Server"

- Section 6.2.4, "Configuring an LDAP Server for Oracle WebCenter Content Users and Groups on IBM WebSphere"

- Section 8.1, "Configuring a Default Administrative User from the LDAP Directory"

3 Managing Oracle Fusion Middleware on IBM WebSphere

This chapter provides basic information about managing Oracle Fusion Middleware on IBM WebSphere.

This chapter contains the following topics:

- Section 3.1, "Summary of the Oracle Fusion Middleware Management Tools on IBM WebSphere"

- Section 3.2, "Basic Administration Tasks on IBM WebSphere"

- Section 3.3, "Deploying Applications on IBM WebSphere"

- Section 3.4, "Configuring Oracle Fusion Middleware High Availability on IBM WebSphere"

3.1 Summary of the Oracle Fusion Middleware Management Tools on IBM WebSphere

After you install and configure Oracle Fusion Middleware on IBM WebSphere, you can verify the configuration, and monitor and manage the components of the Oracle Fusion Middleware installation, using one of several management tools.

The following sections introduce the management tools:

- Using the WebSphere Administrative Console

- Using Oracle Enterprise Manager Fusion Middleware Control

- Using the Oracle Fusion Middleware wsadmin Commands

3.1.1 Using the WebSphere Administrative Console

This section contains the following topics:

- About the IBM WebSphere Administrative Console

- Locating the Port Number and URL of the IBM WebSphere Administrative Console

3.1.1.1 About the IBM WebSphere Administrative Console

The IBM WebSphere Administrative Console, also known as the IBM WebSphere Integrated Solutions Console, provides a web-based interface for managing the IBM WebSphere environment.

Note that you cannot manage Oracle Fusion Middleware products, such as Oracle SOA Suite, Oracle WebCenter Portal, Oracle WebCenter Content, or Oracle Business Intelligence from the IBM WebSphere Administrative Console, but you can use the console to monitor and manage the cell and the servers on which the Oracle Fusion Middleware products are deployed.

For more information about the IBM WebSphere Administrative Console, see the IBM WebSphere documentation, as well as the online help for the console.

3.1.1.2 Locating the Port Number and URL of the IBM WebSphere Administrative Console

Before you can display the IBM WebSphere Administrative Console, you must identify the port number on which is running.

To locate the port number and URL of the IBM WebSphere Administrative Console:

1. In a text editor, open the following properties file:

WAS_HOME/profiles/deployment_mgr_name/properties/portdef.props

2. Locate the value of the WC_Adminhost property.

3. Open a browser and enter the following URL:

http://hostname:WC_Adminhost_port/ibm/console

For example:

http://host42.example.com:9002/ibm/console

3.1.2 Using Oracle Enterprise Manager Fusion Middleware Control

This section contains the following topics:

- About Oracle Enterprise Manager Fusion Middleware Control

- Locating the Port Number and URL for Fusion Middleware Control

- Displaying Fusion Middleware Control

- Viewing an IBM WebSphere Cell from Fusion Middleware Control

- Viewing an IBM WebSphere Server from Fusion Middleware Control

- Viewing an IBM WebSphere Application Deployment from Fusion Middleware Control

- Performing Oracle Fusion Middleware-Specific Administration Tasks for the Cell

- Differences When Using Fusion Middleware Control on IBM WebSphere

3.1.2.1 About Oracle Enterprise Manager Fusion Middleware Control

Oracle Enterprise Manager Fusion Middleware Control is a web browser-based, graphical user interface that you can use to monitor and administer Oracle Fusion Middleware.

Fusion Middleware Control organizes a wide variety of performance data and administrative functions into distinct, web-based home pages for cells, servers, components, and applications. The Fusion Middleware Control home pages make it easy to locate the most important monitoring data and the most commonly used administrative functions from your web browser.

For more information, refer to "Getting Started Using Oracle Enterprise Manager Fusion Middleware Control" in the Oracle Fusion Middleware Administrator's Guide.

Note that the information provided in the Oracle Fusion Middleware Administrator's Guide is specific to using Fusion Middleware Control on Oracle WebLogic Server. For more information, see Section 3.1.2.8, "Differences When Using Fusion Middleware Control on IBM WebSphere".

3.1.2.2 Locating the Port Number and URL for Fusion Middleware Control

To locate the port number for Fusion Middleware Control:

1. Use your web browser to open the IBM WebSphere Administrative Console.

2. In the navigation panel, select Servers > Server Types > WebSphere application servers.

3. Click OracleAdminServer to display the configuration properties of the server.

4. In the Communications section of the resulting page, expand Ports to list the important port values for the OracleAdminServer.

5. Locate the value of the WC_Defaulthost port.

3.1.2.3 Displaying Fusion Middleware Control

To display Fusion Middleware Control, create a new web browser window or tab, and enter the following URL:

http://hostname:WC_Defaulthost_port/em

For example:

http://host42.example.com:9002/em

Log in to Fusion Middleware Control using the same administration credentials that you use when logging in to the IBM WebSphere Administrative Console.

3.1.2.4 Viewing an IBM WebSphere Cell from Fusion Middleware Control

From Fusion Middleware Control, you can manage the Oracle Fusion Middleware products that you have installed and configured as part of the IBM WebSphere cell.

When you first log in to Fusion Middleware Control, the IBM WebSphere Cell home page appears (Figure 3-1). From this page, you can view the servers, applications, and clusters that are associated with the cell.

You can also navigate to the management pages for the Oracle Fusion Middleware components you have installed and configured. For example, if you have installed and configured Oracle SOA Suite, then expand the SOA folder in the Target Navigation Pane, and then click soa-infra to administer and monitor the SOA Infrastructure.

For more information about how to navigate within Oracle Enterprise Manager Fusion Middleware Control, see "Navigating Within Fusion Middleware Control" in the Oracle Fusion Middleware Administrator's Guide.

From the WebSphere Cell menu, you can perform Oracle Fusion Middleware administration functions. For help on a menu command, select the command, and then select Enterprise Manager Help from the Help menu on the resulting page.

Figure 3-1 Viewing the IBM WebSphere Cell from Fusion Middleware Control

3.1.2.5 Viewing an IBM WebSphere Server from Fusion Middleware Control

Each server in an IBM WebSphere cell has its own home page in Fusion Middleware Control.

To view the home page for a specific server:

1. In the Fusion Middleware Control Target Navigation Pane, expand the WebSphere Cell folder.

2. Expand the cell name, and click the server name.

From the WebSphere Application Server home page you can view general information about the server, display the IBM WebSphere Administrative Console, and view the status of the applications deployed to the server.

For a description of the features and options available on the IBM WebSphere Application Server home page, see Section A.1, "Understanding the Information on the IBM WebSphere Cell Home Page".

From the WebSphere Application Server menu, you can perform Oracle Fusion Middleware administration functions. For help on a menu command, select the command, and then--on the resulting page--select Enterprise Manager Help from the Help menu.

3.1.2.6 Viewing an IBM WebSphere Application Deployment from Fusion Middleware Control

Each application deployment in your IBM WebSphere cell has its own home page in Fusion Middleware Control.

An application deployment is an instance of a deployed application. For example, if you deploy the same application to two servers, then you have two deployments of the same application.

To view an application deployment in Fusion Middleware Control:

1. Navigate to the IBM WebSphere cell home page or an IBM WebSphere application server home page.

2. Locate the list of application deployments, and click the application name.

For a description of the features and options available on the IBM WebSphere Application Server home page, see Section A.3, "Understanding the Information on the IBM WebSphere Application Deployment Home Page".

From the Application Deployment menu, you can perform Oracle Fusion Middleware administration functions. For help on a menu command, select the command, and then--on the resulting page--select Enterprise Manager Help from the Help menu.

3.1.2.7 Performing Oracle Fusion Middleware-Specific Administration Tasks for the Cell

Oracle Enterprise Manager Fusion Middleware Control, when used with the IBM WebSphere Administrative Console, provides you with the tools you need to manage Oracle Fusion Middleware when it is installed and configured on IBM WebSphere.

You perform common IBM WebSphere administration tasks from the IBM WebSphere Administrative Console, and you can perform administration tasks that are specific to Oracle Fusion Middleware from the Fusion Middleware Control home pages.

3.1.2.8 Differences When Using Fusion Middleware Control on IBM WebSphere

When you use Oracle Enterprise Manager Fusion Middleware Control to manage Oracle Fusion Middleware products on IBM WebSphere, you will notice some differences from the features and functionality available when using it with Oracle WebLogic Server.

The differences vary, depending on whether you are using IBM WebSphere - Network Deployment (ND) or IBM WebSphere Application Server (AS).

Some specific menu commands and features available in an Oracle WebLogic Server environment are not available when you are managing Oracle Fusion Middleware in an IBM WebSphere environment. If a command or feature is not available, then it is not supported in the IBM WebSphere environment.

Table 3-1 describes some of the differences you might experience when managing Oracle Fusion Middleware on an IBM WebSphere cell, as opposed to an Oracle WebLogic Server domain.

Table 3-1 Summary of Differences When Managing IBM WebSphere As Opposed to Oracle WebLogic Server Domain

Feature or Functional Area

Differences on IBM WebSphere ND

Additional differences on IBM WebSphere AS

Managing an Oracle Fusion Middleware Farm

There is no concept of an Oracle Fusion Middleware farm when you are running on IBM WebSphere; instead, the first page that Fusion Middleware Control displays when you log in is the IBM WebSphere Cell home page.

From the Cell home page, you can navigate to the other home pages that have monitoring and administrative features for the Oracle Fusion Middleware components. You can also link easily to the IBM WebSphere Administrative Console when necessary.

Same as ND.

Monitoring IBM WebSphere from Fusion Middleware Control

There are no IBM WebSphere performance metrics and no performance summary page for the IBM WebSphere cell or server pages.

Same as ND.

Searching log files for messages by transactional attributes.

There is no support for transaction level logging using Execution Context Identifier (ECID) for IBM WebSphere.

Same as ND.

Deployment of Fusion Middleware Control in the cell

When you are managing an IBM WebSphere cell, Fusion Middleware Control runs on the OracleAdminServer, which is created when you configure Oracle Fusion Middleware products using the Configuration Wizard.

You can then use Fusion Middleware Control to manage all the servers and applications deployed to the servers in the cell.

Single instance management only. Fusion Middleware Control must be running on the server that is being managed.

Application deployment from Fusion Middleware Control

You cannot deploy applications from Fusion Middleware Control on IBM WebSphere. Instead, you can use the IBM WebSphere Administrative Console or deploy directly from Oracle JDeveloper.

For more information, see Section 3.3, "Deploying Applications on IBM WebSphere".

Same as ND.

Management of SOA Applications.

See Chapter 4, "Managing Oracle SOA Suite on IBM WebSphere".

See Chapter 4, "Managing Oracle SOA Suite on IBM WebSphere".

Management of Oracle WebCenter Portal Applications

See Chapter 5, "Managing Oracle WebCenter Portal on IBM WebSphere".

See Chapter 5, "Managing Oracle WebCenter Portal on IBM WebSphere"

Management of Oracle WebCenter Content

See Chapter 6, "Managing Oracle WebCenter Content on IBM WebSphere".

See Chapter 6, "Managing Oracle WebCenter Content on IBM WebSphere".

Management of Oracle Fusion Middleware Web services.

See Chapter 8, "Managing Web Services on IBM WebSphere".

See Chapter 8, "Managing Web Services on IBM WebSphere".

Management of Oracle Business Intelligence

See Chapter 10, "Managing Oracle Business Intelligence on IBM WebSphere"

See Chapter 10, "Managing Oracle Business Intelligence on IBM WebSphere"

Management of Oracle Platform Security Services (OPSS) features

See Chapter 9, "Managing Oracle Fusion Middleware Security on IBM WebSphere"

See Chapter 9, "Managing Oracle Fusion Middleware Security on IBM WebSphere"

3.1.3 Using the Oracle Fusion Middleware wsadmin Commands

The WebSphere Application Server wsadmin tool is a command-line utility that can be run in two modes:

- Interactive mode, where you enter commands directly in the shell

- Scripting mode, where you specify a Jython (.py) script on the command line

The examples in this chapter assume you are using interactive mode and the wsadmin command-line shell. For information about using scripting mode, refer to the IBM WebSphere documentation.

You can use the wsadmin tool to manage WebSphere Application Server as well as the configuration, application deployment, and server run-time operations.

Oracle Fusion Middleware provides a set of wsadmin commands that are used exclusively to manage the Oracle Fusion Middleware components that are configured in your IBM WebSphere cell.

For more information about the Oracle Fusion Middleware wsadmin commands and how to use them, refer to the following sections:

- Section 3.1.3.1, "About the Oracle Fusion Middleware wsadmin Command-Line Shell"

- Section 3.1.3.2, "Starting the Oracle Fusion Middleware wsadmin Command-Line Shell and Connecting to the Deployment Manager"

- Section 3.1.3.3, "Using the Oracle Fusion Middleware wsadmin Command-Line Online Help"

- Section 3.1.3.4, "Differences Between the wsadmin Commands and the WebLogic Scripting Tool (WLST) Commands"

- Section 3.1.3.5, "Differences Between Oracle Fusion Middleware wsadmin Commands and IBM WebSphere Wsadmin Commands"

3.1.3.1 About the Oracle Fusion Middleware wsadmin Command-Line Shell

A command-line shell is a command-line environment where a specific set of commands are available and supported. Within the shell, you can run these commands, obtain help on the commands, and perform administration tasks that are specific to the environment you are managing.

The Oracle Fusion Middleware wsadmin command-line shell is an Oracle Fusion Middleware-specific implementation of the wsadmin tool. From this shell, you can:

- Run the Oracle Fusion Middleware-specific wsadmin commands.

- List the available Oracle Fusion Middleware wsadmin commands.

- Obtain online help for the Oracle Fusion Middleware wsadmin commands.

3.1.3.2 Starting the Oracle Fusion Middleware wsadmin Command-Line Shell and Connecting to the Deployment Manager

Start the Oracle Fusion Middleware wsadmin command-line shell from common/bin directory of the Oracle home of the product you are managing.

For a complete list of the arguments you can use when starting wsadmin, refer to the IBM WebSphere documentation.

In a typical Oracle Fusion Middleware wsadmin session, you will want to specify the profile name and connect to the deployment manager of the cell that you are managing.

Note:

The following examples assume that you have already installed and configured an IBM WebSphere cell, using the instructions in Chapter 2, "Installing and Configuring Oracle Fusion Middleware on IBM WebSphere".

Alternatively, if you want to run the wsadmin shell before configuring a cell, refer to "Prerequisite Environment Setup" in the Oracle Fusion Middleware Configuration Guide for IBM WebSphere Application Server.

The following example shows how you can start the wsadmin shell.

Note that this example assumes the IBM WebSphere Deployment Manager is on the local host and is using the default SOAP port. If the Deployment Manager is on a different host, then you will need to specify the host and port using additional command-line arguments. For more information, see the IBM WebSphere documentation and wsadmin command-line help.

To start the wsadmin shell, use this command syntax:

(UNIX) ORACLE_HOME/common/bin/wsadmin.sh
-profileName profilename
-connType SOAP
-user admin_user
-password admin_password

(Windows) ORACLE_HOME\common\bin\wsadmin.cmd
-profileName profilename
-connType SOAP
-user admin_user
-password admin_password

The following example uses the complete path for the wsadmin script on a UNIX operating system:

/disk01/Oracle/Middleware/Oracle_SOA1/common/bin/wsadmin.sh -profileName soaDmgr05

Example 3-1 shows an example of starting the Oracle Fusion Middleware wsadmin command-line shell after you have changed directory to the common/bin directory in the Oracle Fusion Middleware product Oracle home on a UNIX system. The example also shows some typical output messages when you start the shell.

Example 3-1 Starting the Oracle Fusion Middleware Wsadmin Command-Line Shell

./wsadmin.sh -profileName soaDmgr05 -connType SOAP -user wasTest -password welcome1
IN SOA WsadminEnv.sh...
WSADMIN_CLASSPATH=:/scratch/wasTest/mwhome_soa_100719/oracle_common/soa/modules/oracle.soa.mgmt
_11.1.1/soa-infra-mgmt.jar:/scratch/wasTest/mwhome_soa_100719/ ...
.
.
.
WASX7209I: Connected to process "dmgr" on node soaCellManager05 using SOAP connector;  The type of
process is: DeploymentManager

CFGFWK-24021:  OracleHelp loaded.
CFGFWK-24022:  For information on Oracle modules enter 'print OracleHelp.help()'
WASX7031I: For help, enter: "print Help.help()"
wsadmin>

3.1.3.3 Using the Oracle Fusion Middleware wsadmin Command-Line Online Help

The following sections describe some key features of the Oracle Fusion Middleware wsadmin command-line shell:

- Listing the Oracle Fusion Middleware wsadmin Command Categories

- Listing the Commands Within an Oracle Fusion Middleware wsadmin Command-Line Category

- Getting Help on a Specific Oracle Fusion Middleware wsadmin Command

3.1.3.3.1 Listing the Oracle Fusion Middleware wsadmin Command Categories

To list the available categories of Oracle Fusion Middleware commands in the Oracle Fusion Middleware wsadmin command-line shell, use the following command:

wsadmin>print OracleHelp.help()

Example 3-2 shows an example of the output of the print OracleHelp.help() command when you run it from the Oracle Common home.

If you run the command from an Oracle Fusion Middleware component Oracle home (for example, an Oracle SOA Suite, Oracle WebCenter Portal, or Oracle WebCenter Content Oracle home), then the output will include information on the component-specific wsadmin commands.

Example 3-2 Listing the Available Commands from the Oracle Fusion Middleware wsadmin Command-Line Shell

wsadmin>print OracleHelp.help()

ADFMAdmin                   ADFM Lifecycle Management Commands.
MDSAdmin                    MDS Lifecycle Management Commands.
OracleDFW                   Lists commands for FMW diagnostic framework.
OracleDMS                   Lists commands for FMW performance metrics and
events.
OracleHelp                  Provides help for Oracle modules.
OracleJRF                   Commands for configuring Managed Servers with
Oracle Java Required Files (JRF)
OracleLibOVDConfig          List commands for managing OVD configuration
OracleMWConfig              Oracle Middleware Configuration Tool.
OracleMWConfigUtilities     Oracle Middleware Configuration Tool Utilities.
OracleODL                   Lists commands for FMW diagnostic logging.
URLConnection               List Commands for managing ADF Based URL
Connections
WebServices                 Lists commands for Oracle WebServices Management.
audit                       Lists commands for Common Audit Framework
igfconfig                   List commands for manageing IGF configuration
opss                        Oracle platform security services Commands.
wsmManage                   Lists commands for Oracle WSM Policy Management.

wsadmin>

3.1.3.3.2 Listing the Commands Within an Oracle Fusion Middleware wsadmin Command-Line Category

To list the commands associated with a particular category, enter the category name inside single quotation marks within the parentheses. For example:

wsadmin>print OracleHelp.help('OracleODL.help')

Example 3-3 shows an example of listing the commands in a particular category.

Example 3-3 Listing a Specific Category of Oracle Fusion Middleware wsadmin Commands

wsadmin>print OracleHelp.help('OracleODL')

Commands for FMW diagnostic logging

configureLogHandler     Configure Java logging handlers.
displayLogs             Search and display the contents of diagnostic log
files.
getLogLevel             Returns the level of a given Java logger.
listLogHandlers         Lists Java log handlers configuration.
listLoggers             Lists Java loggers and their levels.
listLogs                Lists log files for FMW components.
setLogLevel             Sets the level of a given Java logger.

wsadmin>

3.1.3.3.3 Getting Help on a Specific Oracle Fusion Middleware wsadmin Command

To get help on a specific Oracle Fusion Middleware wsadmin command:

wsadmin>print OracleHelp.help(category.command)

Example 3-4 shows an example of the online help output for a specific Oracle Diagnostic Logging command.

Example 3-4 Example of Online Help for a Specific Oracle Fusion Middleware wsadmin Command

wsadmin>print OracleHelp.help('OracleODL.listLogs')

Lists log files for FMW components.

Returns a PyArray with one element for each log. The elements of the
array are javax.management.openmbean.CompositeData objects describing
each log.

Syntax:
listLogs([options])
- options: optional list of name-value pairs.

o target: the name of a Weblogic server, or an OPMN managed FMW component.
For an OPMN managed component the syntax for the target is
"opmn:<instance-name>/<component-name>".

The target argument can be an array of strings containing one or more
targets. In connected mode the default target includes all running
Weblogic servers in the domain that have JRF enabled.
In disconnected mode there is no default, the target option is required.

o oracleInstance: defines the path to the ORACLE_INSTANCE (or Weblogic
domain home). The command will be executed in disconnected mode when
this parameter is used.

o unit: defines the unit to use for reporting file size. Valid
values are B (bytes), K (kilobytes), M (megabytes), G (gigabytes),
or H (display size in a human-readable form, similar to Unix's "ls
-h" option). The default value is H.

o fullTime: a Jython Boolean value. If true, reports the full time
for the log file last modified time. Otherwise displays a short
version of the time. The default value is false.

Example:
1. listLogs()
2. listLogs(target="server1")
3. listLogs(target="opmn:instance1/ohs1")
4. listLogs(oracleInstance="/middleware/user_projects/domains/base_domain",
target="server1")
wsadmin>

3.1.3.4 Differences Between the wsadmin Commands and the WebLogic Scripting Tool (WLST) Commands

Many of the Oracle Fusion Middleware wsadmin commands that are supported for IBM WebSphere have equivalent WebLogic Scripting Tool (WLST) commands.

To find information about the equivalent WLST command, refer to the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

To list all the Oracle Fusion Middleware wsadmin command categories (or modules) use the OracleHelp.help() command, as shown in Example 3-2.

In many cases, the only difference between the WLST command and the wsadmin command is that you must prefix each wsadmin command with the category name. Example 3-6 shows how you might use the listLoggers command in WLST. Example 3-7 shows the same command in wsadmin.

Example 3-5 Using the ListLoggers Command in WLST

wls:/base_domain/serverConfig> listLoggers(pattern="oracle.dms.*")
-----------------------+-----------------
Logger                 | Level
-----------------------+-----------------
oracle.dms             | <Inherited>
oracle.dms.aggregator  | <Inherited>
oracle.dms.collector   | <Inherited>
oracle.dms.context     | <Inherited>
oracle.dms.event       | <Inherited>
oracle.dms.instrument  | <Inherited>
oracle.dms.jrockit.jfr | <Inherited>
oracle.dms.reporter    | <Inherited>
oracle.dms.trace       | <Inherited>
oracle.dms.translation | <Inherited>
oracle.dms.util        | <Inherited>
wls:/base_domain/serverConfig>

Example 3-6 Using the ListLoggers Command in Wsadmin

wsadmin>OracleODL.listLoggers(pattern="oracle.dms.*")
-----------------------+-----------------
Logger                 | Level
-----------------------+-----------------
oracle.dms             | WARNING:1
oracle.dms.aggregator  | NOTIFICATION:1
oracle.dms.collector   | NOTIFICATION:1
oracle.dms.context     | NOTIFICATION:1
oracle.dms.event       | NOTIFICATION:1
oracle.dms.instrument  | NOTIFICATION:1
oracle.dms.reporter    | NOTIFICATION:1
oracle.dms.trace       | NOTIFICATION:1
oracle.dms.translation | NOTIFICATION:1
oracle.dms.util        | NOTIFICATION:1
wsadmin>

3.1.3.5 Differences Between Oracle Fusion Middleware wsadmin Commands and IBM WebSphere Wsadmin Commands

Note the following difference between running Oracle Fusion Middleware wsadmin commands and the standard IBM WebSphere wsadmin commands:

- You must run the Oracle Fusion Middleware commands from the common/bin directory of the Oracle Fusion Middleware Oracle home.

- The Oracle Fusion Middleware wsadmin commands use the Jython scripting language exclusively.

3.2 Basic Administration Tasks on IBM WebSphere

The following sections provide information about some basic administration tasks you can perform when running Oracle Fusion Middleware on IBM WebSphere:

- Referring to IBM WebSphere DIrectory Paths on Windows Systems

- Starting and Stopping Servers on IBM WebSphere

- Configuring Metadata Services (MDS) on IBM WebSphere

- Configuring Oracle Fusion Middleware Logging on IBM WebSphere

- Using the Oracle Fusion Middleware Diagnostic Framework on IBM WebSphere

- Creating a Data Source in an IBM WebSphere Cell

3.2.1 Referring to IBM WebSphere DIrectory Paths on Windows Systems

If you are providing the path to the WebSphere Application Server on a Windows operating system, and a directory name in the path includes a space, you need to supply a shortened name, with a tilde character (~) followed by a 1 instead of the character before the space.

For example, the default location of a WebSphere Application Server on a Windows operation system is in a subdirectory of Program Files, a directory name that includes a space:

C:\Program Files\IBM\WebSphere\Appserver

This location needs to be specified as follows:

C:\Progra~1\IBM\WebSphere\Appserver

If you are browsing to this location, the Browse button incorrectly populates the field with the space rather than C:\Progra~1.

3.2.2 Starting and Stopping Servers on IBM WebSphere

There are two methods for starting and stopping the servers in your IBM WebSphere cell:

- Starting and Stopping IBM WebSphere Servers with Profile Scripts

- Starting and Stopping IBM WebSphere Servers with Fusion Middleware Control

3.2.2.1 Starting and Stopping IBM WebSphere Servers with Profile Scripts

Just as with any other IBM WebSphere cell, you can use profile scripts to start and stop the servers in a cell you configured for Oracle Fusion Middleware.

For example, to stop the OracleAdminServer, navigate to the following directory in the IBM WebSphere home, and enter the following command:

On UNIX operating systems:

profiles/profile_name/bin/stopServer.sh OracleAdminServer
-profileName profileName

On Windows operating systems:

profiles\profile_name\bin\stopServer.cmd OracleAdminServer
-profileName profileName

For example, on a UNIX operating system:

/disk01/IBM/WebSphere/ApplicationServer/profiles
/Custom01/bin/stopServer.sh OracleAdminSErver
-profileName Custom01

For examples of how to start the servers in your IBM WebSphere cell, see Section 2.7, "Task 7: Start the IBM WebSphere Servers".

For more information about the scripts that are generated for each profile, refer to the IBM WebSphere documentation.

3.2.2.2 Starting and Stopping IBM WebSphere Servers with Fusion Middleware Control

You can also stop and start IBM WebSphere servers from Oracle Enterprise Manager Fusion Middleware Control.

For example, to stop a server from Fusion Middleware Control:

1. Navigate to the Server home page.
For more information, see Section 3.1.2.5, "Viewing an IBM WebSphere Server from Fusion Middleware Control".

2. From the WebSphere Application Server menu, select Control, and then select Shut down.
Fusion Middleware Control displays a confirmation dialog box.

3. Click Shutdown.

Note:

Fusion Middleware Control is deployed to the OracleAdminServer. As a result, if you stop the OracleAdminServer, then Fusion Middleware Control will be stopped, and you must use the profile scripts to start the servers.

For more information, see Section 3.2.2.1, "Starting and Stopping IBM WebSphere Servers with Profile Scripts".

3.2.3 Configuring Metadata Services (MDS) on IBM WebSphere

On IBM WebSphere, you can manage Oracle Fusion Middleware Metadata Services (MDS) using Oracle Enterprise Manager Fusion Middleware Control and the wsadmin command-line utility, just as you can other Oracle Fusion Middleware components.

Refer to the following sections for more information about the differences from configuring MDS on Oracle WebLogic Server:

- Differences in MDS Command-Line Features on IBM WebSphere

- Differences in MDS Fusion Middleware Control Pages on IBM WebSphere

3.2.3.1 Differences in MDS Command-Line Features on IBM WebSphere

All the wsadmin commands that you use to manage MDS on IBM WebSphere have equivalent WebLogic Scripting Tool (WLST) commands, which are documented in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

In addition, refer to the wsadmin online help for information about any differences between the MDS commands available in WLST and in wsadmin.

For example, note the following differences when using the registerMetadataDBRepository command on IBM WebSphere:

- The command has an additional parameter on IBM WebSphere (authAlias).

- The existing targetServers parameter allows you to specify a target WebSphere server or cluster for the repository, rather than a Oracle WebLogic Server instance.

For more information, see the following:

- Using the registerMetadataDBRepository authAlias parameter on IBM WebSphere.

- Using the registerMetadataDBRepository targetServers Parameter on IBM WebSphere

- More Information About the registerMetadaDBRepository Command on IBM WebSphere

3.2.3.1.1 Using the registerMetadataDBRepository authAlias parameter on IBM WebSphere

Use the authAlias argument to create or use an existing authentication alias for connecting to the database where the MDS schema resides. For example:

- If you do not provide a value for the authAlias parameter, then Oracle Fusion Middleware assumes that the authentication alias name is the same as the metadata repository name.

- If you provide a user name and password, then Oracle Fusion Middleware creates a new authentication alias either by using the value of the authAlias parameter as the alias name if it is provided, or by using the name of the metadata repository as alias name if the authAlias parameter is not provided.

- If you do not provide a user name and password, then Oracle Fusion Middleware assumes you want to connect to the database using the existing authentication alias, which is either the value of the authAlias parameter or the name of the metadata repository if the authAlias parameter is not provided.

3.2.3.1.2 Using the registerMetadataDBRepository targetServers Parameter on IBM WebSphere

Use the targetServers parameter to specify the WebSphere servers or clusters to which this repository will be registered. If this argument is not specified, then the repository will be registered only to the DeploymentManager.

The server or cluster must be specified in the form of specifying a configuration object in the wsadmin scripting tool. A configuration object can be specified as multiple /type:name/ value pairs in the containment path string. For example:

'/Cell:myCell/Node:myNode/Server:myServer/'

The containment path must be a path that contains the correct hierarchical order.

To specify multiple servers or clusters, separate the names with a comma.

Note that if you later add additional servers or clusters to the cell, you must do one of the following to ensure that the repository is available from the new servers or clusters that were added after the initial registration of the repository:

- Use the deregisterMetadataDBRepository command to deregister the repository from all the initial targets, then run the registerMetadataDBRepository command again to reregister the repository with more targets. Note that the data source will be unavailable on all servers until you run the registerMetadataDBRepository command the second time.

- Manually create the data source on the new servers or clusters, using the exact same properties as the data source you created with the registerMetadataDBRepository command.

3.2.3.1.3 More Information About the registerMetadaDBRepository Command on IBM WebSphere

For more information about using the registerMetadataDBRepository command on IBM WebSphere, review the wsadmin online help for the command:

wsadmin> print MDSAdmin.help('registerMetadataDBRepository')

For more information about using wsadmin command-line online help, see Section 3.1.3.3, "Using the Oracle Fusion Middleware wsadmin Command-Line Online Help".

3.2.3.2 Differences in MDS Fusion Middleware Control Pages on IBM WebSphere

When you are using Fusion Middleware Control to manage the MDS repository on IBM WebSphere, there are some differences in the Fusion Middleware Control pages. These differences are due to the differences in the basic administration functions for Oracle WebLogic Server and IBM WebSphere.

For example:

- On Oracle WebLogic Server, the Metadata Repository home page includes a Targeted Servers region, which identifies Oracle WebLogic Server servers that can access the repository. This region is not available on IBM WebSphere.

- On IBM WebSphere, the Register Database-Based Metadata Repository page provides the ability to specify an authentication alias, which can be used to represent the credentials required to connect to the repository database.

3.2.4 Configuring Oracle Fusion Middleware Logging on IBM WebSphere

There are several ways to change the configuration of log files for the Oracle Fusion Middleware products when running with IBM WebSphere.

Consider the following when modifying the log configuration:

- To change the log levels, you can use the IBM WebSphere Administrative Console, Fusion Middleware Control, or the OracleODL commands in the Oracle Fusion Middleware wsadmin command-line shell.
Note that in IBM WebSphere, java.util.logging is implemented differently than in Oracle WebLogic Server; specifically, child loggers do not inherit the log level property from the parent. However, you can change the log levels for a logger and its descendants, by using the wsadmin commands shown in Example 3-7.

Note that in Example 3-7, the two spaces before the OracleODL.setLogLevel command are required. The spaces indicate that this line is a continuation of the previous line.

- To change other configuration properties, you can use Fusion Middleware Control, or the OracleODL commands in the wsadmin command line.

- The name of the log configuration file is websphere-logging.xml. Note, however, that you should not edit the file directly; you should use Fusion Middleware Control, the wsadmin command line, or the IBM WebSphere Administrative Console to modify the file.

- The main diagnostic log file is located in the following directory:

SERVER_LOG_ROOT/server_name-diagnostic.log

For more information about the SERVER_LOG_ROOT environment variable, see the IBM WebSphere documentation.

Note that some Oracle Fusion Middleware components also generate their own logs, which are also stored in this location.

Example 3-7 Sample Oracle Fusion Middleware Wsadmin Script that Sets Logging Levels

wsadmin>myLoggers = OracleODL.listLoggers(pattern="oracle.dms.*")
-----------------------+-----------------
Logger                 | Level
-----------------------+-----------------
oracle.dms             | WARNING:1
oracle.dms.aggregator  | NOTIFICATION:1
oracle.dms.collector   | NOTIFICATION:1
oracle.dms.context     | NOTIFICATION:1
oracle.dms.event       | NOTIFICATION:1
oracle.dms.instrument  | NOTIFICATION:1
oracle.dms.reporter    | NOTIFICATION:1
oracle.dms.trace       | NOTIFICATION:1
oracle.dms.translation | NOTIFICATION:1
oracle.dms.util        | NOTIFICATION:1
wsadmin>print myLoggers{'oracle.dms.translation': 'NOTIFICATION:1', 'oracle.dms.context':
'NOTIFICATION:1', 'oracle.dms.event': 'NOTIFICATION:1', 'oracle.dms':
'NOTIFICATION:1', 'oracle.dms.util': 'NOTIFICATION:1', 'oracle.dms.aggregator':
'NOTIFICATION:1', 'oracle.dms.reporter': 'NOTIFICATION:1', 'oracle.dms.trace':
'NOTIFICATION:1', 'oracle.dms.instrument': 'NOTIFICATION:1',
'oracle.dms.collector': 'NOTIFICATION:1'}
wsadmin> for loggerName in myLoggers.keys():
wsadmin>  OracleODL.setLogLevel(target="OracleAdminServer", logger=loggerName, level="FINE")
wsadmin>
wsadmin>OracleODL.listLoggers(pattern="oracle.dms.*")
-----------------------+-----------------
Logger                 | Level
-----------------------+-----------------
oracle.dms             | WARNING:1
oracle.dms.aggregator  | TRACE:1
oracle.dms.collector   | TRACE:1
oracle.dms.context     | TRACE:1
oracle.dms.event       | TRACE:1
oracle.dms.instrument  | TRACE:1
oracle.dms.reporter    | TRACE:1
oracle.dms.trace       | TRACE:1
oracle.dms.translation | TRACE:1
oracle.dms.util        | TRACE:1

3.2.5 Using the Oracle Fusion Middleware Diagnostic Framework on IBM WebSphere

You can use the Oracle Fusion Middleware Diagnostic Framework on IBM WebSphere. However, review the following information for limitations and additional information:

- Setting Up the Diagnostic Framework on IBM WebSphere

- Restrictions When Using the WebLogic Server Diagnostic Framework (WLDF) on IBM WebSphere

3.2.5.1 Setting Up the Diagnostic Framework on IBM WebSphere

Because the Automatic Diagnostic Repository (ADR) binaries are not automatically installed when Oracle Fusion Middleware is installed on IBM WebSphere, the Diagnostic Framework cannot access the ADR to store incidents.

To allow incident creation on IBM WebSphere, you must install the ADR binaries and configure each WebSphere server to point to those binaries.

Perform the following steps:

1. Download and install the Oracle Database Instant Client binaries version 11.2.0.1 from Oracle Technology Network (OTN).

http://www.oracle.com/technology/software/tech/oci/instantclient/index.html

Select your operating system, then select Basic.

2. Install the downloaded files on the host on which IBM WebSphere is running.

3. Configure the IBM Websphere server to set the system property oracle.adr.home to the location of the installed Oracle Database Instant Client binaries, using the WebSphere Integrated Solutions Console.
For example, to set the property on distributed platforms:

1. Expand Servers, then Server Types. Select WebSphere application servers.

2. On the Application servers page, select the server.

3. In the Server Infrastructure section of the server page, expand Java and process management, then select Process Definition.

4. In the Process Definition page, select Java Virtual Machine.

5. Select Custom Properties, then click New.

6. For Name, enter oracle.adr.home.

7. For Value, enter the location of the installed files.

8. Click Apply, then Save.

3.2.5.2 Restrictions When Using the WebLogic Server Diagnostic Framework (WLDF) on IBM WebSphere

When using the WebLogic Server Diagnostic Framework (WLDF) on IBM WebSphere, note that the watch and notification features are not supported.

For more information about the features of the Diagnostic Framework, see "Diagnosing Problems" in the Oracle Fusion Middleware Administrator's Guide.

3.2.6 Differences in Dump Sampling Commands

When you use the command line to manage dump sampling commands, note that while the WLST commands use true or false as values passed to certain parameters, the comparable wsadmin commands use 0 and 1.

3.2.7 Creating a Data Source in an IBM WebSphere Cell

Creating a data source is a common administration task, which is required when configuring certain aspects of your Oracle Fusion Middleware environment.

Data sources that connect to the product schemas installed by the Repository Creation Utility are created when you run the Configuration Wizard. However, there are other scenarios where you might need to create a data source--for example, you might need a data source for the applications you deploy.

To create a data source on IBM WebSphere, you can use the IBM WebSphere Administrative Console.

The following example shows how to create an IBM WebSphere data source for an Oracle database. Creating the database involves the following tasks:

- Task 1, "Create an authentication alias for the Oracle database you want to access"

- Task 2, "Create a JDBC data provider for the Oracle database"

- Task 3, "Modify the JDBC data provider to use the latest Oracle database classes"

- Task 4, "Create a JDBC data source that uses the Oracle database JDBC provider"

- Task 5, "Test the Data Source Connection"

Task 1   Create an authentication alias for the Oracle database you want to access

1. Log in to the IBM WebSphere Administrative Console and navigate to Security > Global Security.

2. On the Global Security page, select Java Authentication and Authorization Service > J2C Authentication Data.

3. Click New.

4. On the General Properties page enter the information shown in Table 3-2.

5. Save the new authentication alias to the master configuration.

Table 3-2 Authentication Alias General Properties for an Oracle Database Data Source

Element

Description

Alias

Enter a name for the alias. Use a name that identifies the purpose of the credentials assigned to the alias. For example, OracleDBalias.

User ID

Enter the Oracle database user name you will use to connect to the database.

Note: Where required, also include the role. For example, if you are connecting as SYS, then enter the following in this field:

SYS as SYSDBA

Password

Enter the password for the database user.

Description

Optionally, enter a description that describes the purpose of the authentication alias.

Task 2   Create a JDBC data provider for the Oracle database

1. Log in to the IBM WebSphere Administrative Console and navigate to Resources > JDBC > JDBC Providers.

2. Select the appropriate Scope for the data provider you are about to create.

3. Click New.
The IBM WebSphere Administrative Console displays a three-step wizard to guide you through the JDBC provider creation process.

4. In Step 1 of the JDBC provider wizard, make the selections shown in Table 3-3.

5. In Step 2 of the JDBC provider wizard, accept the default values.
Note: You will modify these later in the procedure.

6. In Step 3 of the JDBC provider wizard, verify the values you entered and selected so far.

7. Click Finish to create the initial provider and return to the JDBC Providers page.

Table 3-3 Recommended Values to Select When Creating an IBM WebSphere Data Source for an Oracle Database

Element

Recommended Value

Database Type

Select Oracle from the drop-down menu.

Provider Type

Select Oracle JDBC Driver from the drop-down menu.

Implementation Type

Select Connection pool data source from the drop-down menu.

Name

Provide a unique name for the JDBC provider, or use the default name.

Description

Optionally, provide a description of the JDBC provider. This can be useful if you are creating multiple data sources for specific purposes.

Task 3   Modify the JDBC data provider to use the latest Oracle database classes

1. Click the name of the database provider in the list of JDBC providers.

2. In the General properties section of the page, replace the value in the Class path field with the following:

${COMMON_COMPONENTS_HOME}/modules/oracle.jdbc_11.1.1/ojdbc6dms.jar
${COMMON_COMPONENTS_HOME}/modules/oracle.dms_11.1.1/dms.jar
${COMMON_COMPONENTS_HOME}/modules/oracle.odl_11.1.1/ojdl.jar

Press Enter to separate the path locations so they appear on one line each, as shown in Figure 3-2.

3. Click OK to return to the JDBC Providers page.

4. Click Save to save your changes to the master configuration.

Figure 3-2 Summary of IBM WebSphere JDBC Provider Values for an Oracle Database

Task 4   Create a JDBC data source that uses the Oracle database JDBC provider

1. Log in to the console and navigate to Resources > JDBC > Data Sources.

2. Select the appropriate Scope for the data source you are about to create.

3. Click New.
The IBM WebSphere Administrative Console displays a five-step wizard to guide you through the data source creation process.

4. In Step 1 of the data source wizard, enter a name for the data source and a JNDI location.
For example, use myOracleDS as the data source name and jdbc/myOracleDS as the JNDI location.

5. In Step 2 of the data source wizard, select Select an existing JDBC provider and select the JDBC provider you created earlier in this procedure from the drop-down menu.

6. In Step 3 of the data source wizard, do the following:

1. In the URL field, enter the connection string for the Oracle database, using the following format:

jdbc:oracle:thin:@hostname:port:SID

For example:

jdbc:oracle:thin:@host42.example.com:1521:DB43

2. From the Data store helper class name menu, select the appropriate class name, based on whether you are connecting to a 10g or 11g Oracle database.

3. Optionally, select Use this data source in container managed persistence (CMP).
See the IBM WebSphere Administrative Console online help for information about the purpose of this option.

7. In Step 4 of the data source wizard, use the Component-managed authentication alias menu to select the authentication alias you created for the Oracle database earlier in this procedure.
See the IBM WebSphere Administrative Console online help for information about the other options on the page.

8. In Step 5 of the wizard, review your changes. If they are accurate, click Finish to return to the Data Sources page.

9. Save the configuration changes, as directed in the console.

Task 5   Test the Data Source Connection

On the Data Sources page, select the data source and click Test Connection to verify your data source configuration.

3.3 Deploying Applications on IBM WebSphere

Refer to the following sections for information on deploying your Oracle Fusion Middleware applications on IBM WebSphere:

- Preparing to Deploy Oracle Fusion Middleware Applications on IBM WebSphere

- Methods for Deploying Oracle Fusion Middleware Applications on IBM WebSphere

- Deploying Applications that Require MDS Deployment Plan Customizations on IBM WebSphere

3.3.1 Preparing to Deploy Oracle Fusion Middleware Applications on IBM WebSphere

Before you can deploy Oracle Fusion Middleware applications (such as ADF, Oracle SOA Suite, Oracle WebCenter Portal, Oracle WebCenter Content, or Oracle Business Intelligence applications) to IBM WebSphere, you must follow certain steps for preparing the environment.

For example, you must ensure that the Java Required Files (JRF) template has been applied to the IBM WebSphere servers. This can be accomplished by configuring the environment using the Oracle Fusion Middleware Configuration Wizard, as described in Chapter 2, "Installing and Configuring Oracle Fusion Middleware on IBM WebSphere" and in the Oracle Fusion Middleware Configuration Guide for IBM WebSphere Application Server.

3.3.2 Methods for Deploying Oracle Fusion Middleware Applications on IBM WebSphere

The primary methods for deploying your Oracle Fusion Middleware applications to IBM WebSphere are as follows:

- If you are working in a development or testing environment, then you can deploy your applications directly from Oracle JDeveloper.
For information about configuring Oracle JDeveloper with an IBM WebSphere environment, see "Deploying the Application" in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.

For information about deploying Oracle SOA Suite, Oracle WebCenter Portal, Oracle WebCenter Content, or Oracle Business Intelligence applications, refer to the corresponding chapter in this guide and the appropriate product development guide.

- If you are working in a testing or production environment, then you can deploy application archives--for example, Enterprise Archive (EAR) files--from the IBM WebSphere Administration Console.

3.3.3 Deploying Applications that Require MDS Deployment Plan Customizations on IBM WebSphere

To deploy an application that requires MDS Deployment Plan customizations, you must use Oracle JDeveloper, unless you use the MDS wsadmin commands to customize the MDS deployment plan.

After you customize the deployment plan, you can then deploy the application archive from the IBM WebSphere Administrative Console.

3.4 Configuring Oracle Fusion Middleware High Availability on IBM WebSphere

The following sections provide information on configuring Oracle Fusion Middleware components for high availability on IBM WebSphere:

- Documentation Resources for Configuring Oracle Fusion Middleware High Availability on IBM WebSphere

- Configuring Java Object Cache for Oracle Fusion Middleware on IBM WebSphere

3.4.1 Documentation Resources for Configuring Oracle Fusion Middleware High Availability on IBM WebSphere

When configuring a high availability environment for the Oracle Fusion Middleware components that you install and configure on IBM WebSphere, refer to the following resources:

- The IBM WebSphere documentation available on the WebSphere Application Server Information Center.

- The Oracle Fusion Middleware High Availability Guide, which describes basic high availability concepts for Oracle Fusion Middleware components on Oracle WebLogic Server.

- The Oracle Fusion Middleware Enterprise Deployment Guides, which provide specific reference topologies for configuring the various Oracle Fusion Middleware components in a Oracle WebLogic Server-based production environment.

- Section 5.2.19, "Configuring WebCenter Portal or Portal Framework Applications for High Availability on IBM WebSphere" for specific information about configuring Oracle WebCenter Portal for high availability.

- Section 10.2.11, "Configuring for Scaling the Deployment of Oracle Business Intelligence on IBM WebSphere" for specific information about configuring Oracle Business Intelligence for high availability.

- The Oracle Fusion Middleware Release Notes for your platform, for information about known issues and workarounds when configuring Oracle Fusion Middleware components on IBM WebSphere.

In addition, refer to "Using wsadmin to Configure Oracle Fusion Middleware" in the Oracle Fusion Middleware Configuration Guide for IBM WebSphere Application Server, which provides examples of how you can use the wsadmin command-line to:

- Create servers, clusters, and cluster members on IBM WebSphere

- Create data sources for communicating with an Oracle Real Application Clusters database

- Federate remote nodes to an existing cell

3.4.2 Configuring Java Object Cache for Oracle Fusion Middleware on IBM WebSphere

When configuring high availability for Oracle Fusion Middleware, the Oracle Fusion Middleware High Availability Guide and Oracle Fusion Middleware Enterprise Deployment Guides suggest using Java Object Cache (JOC) to increase the performance of Oracle Web Services Manager and Oracle WebCenter Portal.

To configure JOC in such scenarios, Oracle Fusion Middleware provides a custom script called configure-joc.py. This script is not supported on IBM WebSphere.

As an alternative, you can use the following procedure to configure JOC for Oracle Fusion Middleware on IBM WebSphere:

1. Locate and edit the javacache.xml file for each the server in the cluster.
The javacache.xml file is located in the Deployment Manager directory for each server:

WAS_HOME/profiles/dmgr_proile_name/config
/cells/cell_name
/nodes/node_name
/servers/server_name
/fmwconfig/javacache.xml

For example, if you have configured a cluster called WC_Spaces, and the cluster contains two servers, WC_Spaces and WC_Spaces2, then you can locate the javacache.xml file as follows:

WebSphere/AppServer/profiles/Dmgr01/config/cells/Cell01/nodes/Node01/servers/WC_Spaces/fmwconfig/javacache.xml

WebSphere/AppServer/profiles/Dmgr01/config/cells/Cell01/nodes/Node01/servers/WC_Spaces2/fmwconfig/javacache.xml

2. Make the following changes to the javacache.xml file:

- Set the enabled attribute of the <communicationService> element to TRUE.

- Remove the outOfProc="false" attribute from the <packet-distributer> element.

- Add the <distributor-location> elements with the host and port of the servers in the cluster

Example 3-8 provides a sample javacache.xml file that has been modified for use on IBM WebSphere. In the example, replace host with the host address and replace port with the port used for JOC communication. You can select any free port.

3. Login to the IBM WebSphere Administrative Console and navigate to the Nodes page (System administration > Nodes).

4. Select all nodes in the cluster and click on Full Resynchronize.

5. Restart all servers in the cluster.

Example 3-8 Sample javacache.xml File - Modified for IBM WebSphere

<?xml version="1.0" encoding="UTF-8"?>
<cache-configuration
xmlns="http://www.oracle.com/oracle/ias/cache/configuration11"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" max-objects="5000"
max-size="10" private="false"    cache-dump-path="jocdump" system="false" clean-interval="60"
version="11.1.1.2.0"
internal-version="110000">
<communicationService enabled="true">
<v2 ssl-config-file=".sslConfig" init-retry="300" init-retry-delay="2000"
enable-ssl="false" auto-recover="false">
<packet-distributor enable-router="false" startable="true"
dedicated-coordinator="false" >
<distributor-location host="myhost1.example.com"
port="9988" ssl="true"/>
<distributor-location host="myhost2.exmaple.com" port="9988"
ssl="true"/>
</packet-distributor>
</v2>
</communicationService>
<diskCache size="10" count="5000" ping-interval="60"/>
<logging override-parent="false" location="javacache.log"
default-level="SEVERE"/>
<dms enabled="false"/>
</cache-configuration>

4 Managing Oracle SOA Suite on IBM WebSphere

This chapter contains information about managing Oracle SOA Suite applications and components on IBM WebSphere.

This chapter contains the following sections:

- Section 4.1, "Configuring Oracle SOA Suite and Oracle BAM Against an External LDAP Server on IBM WebSphere"

- Section 4.2, "Differences and Restrictions When Developing and Deploying Oracle SOA Suite Applications on IBM WebSphere"

- Section 4.3, "Differences and Restrictions When Managing Oracle SOA Suite Components on IBM WebSphere"

- Section 4.4, "Differences and Restrictions When Managing Oracle BAM on IBM WebSphere"

In this chapter, IBM WebSphere is used to reference both IBM WebSphere Application Server (AS) and IBM WebSphere Application Server Network Deployment (ND). The specific product names are used when appropriate.

4.1 Configuring Oracle SOA Suite and Oracle BAM Against an External LDAP Server on IBM WebSphere

If you are installing and configuring Oracle SOA Suite on IBM WebSphere, then you must install and configure a supported LDAP server before you can configure the Oracle SOA Suite components in a new IBM WebSphere cell. For more information, see Section 4.1.1, "Configuring SOA Suite Users and Groups in an External LDAP Server."

If you are installing Oracle BAM on IBM WebSphere, then you must perform additional configuration steps for Oracle SOA Suite and Oracle BAM against the external LDAP server. For more information, see Section 4.1.2, "Configuring Oracle SOA Suite and Oracle BAM in an External LDAP Server."

4.1.1 Configuring SOA Suite Users and Groups in an External LDAP Server

When you install Oracle SOA Suite with IBM WebSphere, an internal LDAP server is not automatically configured with SOA users and groups. You must manually perform these configuration tasks in an external LDAP server, such as Oracle Internet Directory, after installation.

For information on the LDAP servers that are supported by Oracle Fusion Middleware, refer to the certification information on the Oracle Technology Network. For more information, see Section 2.1, "Task 1: Review the System Requirements and Certification Information".

The following provides an overview of the tasks to perform when configuring your supported LDAP server for use with Oracle SOA Suite:

1. Use your LDAP management tool to create two groups (Operator group and Monitor group) and two users (Operator user and Monitor user).
Note that the management tool you use to create the users and groups will vary, depending up on the LDAP server you are using. For example, if you are using Oracle Internet Directory, refer to information about using the Oracle Directory Services Manager in the Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

2. In the IBM WebSphere Administrative Console, create the following mappings:

- User roles for operator and monitor

- Group roles for operator and monitor

For example, the following page shows the Administrative user roles section with the monitor user ashish (second check box) and the operator user opuser (fourth check box) available for selection. You perform similar mappings for group roles on a separate page.

3. Log in to Oracle Enterprise Manager Fusion Middleware Control with administrator access.

4. In the navigator, right-click soa-infra, and select Security > Application Roles.

5. Map the SOA roles to the Operator and Monitor roles.

- For SOAOperator role, add the Operator group as a member.

- For SOAMonitor role, add the Monitor group as a member.

For additional information about switching LDAP authentication providers, see the following documentation:

- To switch LDAP authentication providers if the corresponding LDAP server contains the user or users who start the domain, see Section "Requirements for Using an LDAP Authentication Provider" in Oracle Fusion Middleware Securing Oracle WebLogic Server.

- To add an Oracle Internet Directory, Oracle Virtual Directory, or other authentication provider using WLST commands, see Section "Configuring Additional Authentication Providers" in Oracle Fusion Middleware Oracle WebLogic Scripting Tool.

4.1.2 Configuring Oracle SOA Suite and Oracle BAM in an External LDAP Server

To use the external LDAP server with Oracle BAM on IBM WebSphere, the user OracleSystemUser must be added to the external LDAP server.

In addition, the following post-installation steps must be executed on IBM WebSphere:

1. Create the properties file to use as the input for configuring the identity store. For example, the Oracle Internet Directory properties file could look like this:

user.search.bases=dc=com
group.search.bases=dc=com
subscriber.name=dc=com
ldap.host=mymachine.example.com
ldap.port=17234
admin.id=cn=orcladmin
admin.pass=orcladmin1
user.filter=(&(cn=%v)(objectclass=person))
group.filter=(&(cn=%v)(objectclass=groupofuniquenames))
user.id.map=*:cn
group.id.map=*:cn
group.member.id.map=groupofuniquenames:uniquemember
ssl=false

2. Go to the MW_HOME/oracle_common/common/bin directory, where MW_HOME is the directory in which Oracle SOA Suite is installed. Then run:

./wsadmin.sh -conntype SOAP -user <username> -password <password>

Replace <username> and <password> with the WebSphere user and password for your IBM WebSphere installation.

3. Run the following command to configure the identity store:

Opss.configureIdentityStore(propsFileLoc="(<complete_path_LDAP.properties>")

For example:

Opss.configureIdentityStore(propsFileLoc="C:\oid.properties")

4. Then run the following command to reassociate the identity store:

Opss.reassociateSecurityStore(domain="WAS_policy_store",admin="<LDAPAdminUser>",
password="<LDAPAdminpassword>", ldapurl="ldap://<LDAPHost>:<LDAPPort>",
servertype="<LDAPSERVERTYPE>", jpsroot="cn=jpsroot")

For example:

Opss.reassociateSecurityStore(domain="WAS_policy_store",admin="cn=orcladmin", password="orcladmin1",
ldapurl="ldap://mymachine.example.com:17234", servertype="OID", jpsroot="cn=jpsroot")

4.2 Differences and Restrictions When Developing and Deploying Oracle SOA Suite Applications on IBM WebSphere

The following sections describe differences and restrictions when developing and deploying Oracle SOA Suite applications on IBM WebSphere:

- Section 4.2.1, "Oracle SOA Suite wsadmin and WLST Command Differences"

- Section 4.2.2, "Configuring the WebSphere Application Client for Use with Oracle JDeveloper"

- Section 4.2.3, "Configuring the Proxy on IBM WebSphere Server"

- Section 4.2.4, "Creating an Application Server Connection"

- Section 4.2.5, "Deploying SOA Composite Applications"

- Section 4.2.6, "Using the Diagnostic Framework"

- Section 4.2.7, "Using EJB Bindings"

- Section 4.2.8, "AQ Technology Adapter and WebSphere 7.0"

- Section 4.2.9, "JMS Technology Adapter on WebSphere 7.0"

- Section 4.2.10, "Oracle Database Adapter on WebSphere 7.0"

4.2.1 Oracle SOA Suite wsadmin and WLST Command Differences

All Oracle SOA Suite wsadmin commands supported by IBM WebSphere have equivalent WebLogic Scripting Tool (WLST) commands.

Note:

Project Lifecycle commands are not supported on IBM WebSphere AS and ND. This means there are no wsadmin commands in IBM WebSphere AS or ND that are equivalent to the WLST project lifecycle commands.

Table 4-1 describes differences between wsadmin and WLST.

Table 4-1 Differences Between wsadmin and WLST

Issue

WLST

wsadmin

wsadmin command line syntax

WLST commands are prefixed with sca_. For example:

sca_deployComposite('http://
adc10:9080','/tmp/sca_HelloWorld_
rev1.0.jar')

All wsadmin commands are prefixed with "soa." to the front of sca_. For example:

soa.sca_deployComposite('http://
adc10:9080', '/tmp/sca_
HelloWorld_rev1.0.jar')

Boolean type

You use true/false or 1/0.

You must use 1/0.

Composite management commands

You run WLST commands in offline mode.

You run wsadmin commands in online mode. Command names and signatures are slightly different from WLST commands:

- Mb is attached to the end of the command.

- Signatures do not include properties for host, port, user, or password.

To start a composite:

soa.sca_startCompositeMb(compositeName,
revision, label, partition)

To stop a composite:

soa.sca_stopCompositeMb(compositeName,
revision, label, partition)

To activate a composite:

soa.sca_activateCompositeMb(compositeName,
revision, label, partition)

To retire a composite:

soa.sca_retireCompositeMb(compositeName,
revision, label, partition)

To assign a default composite:

soa.sca_assignDefaultCompositeMb(compositeName,
revision, partition)

To get a default composite revision:

soa.sca_getDefaultCompositeRevisionMb(composite
Name, partition)

To list deployed composites:

soa.sca_listDeployedCompositesMb()

To list all composites in the given partition:

soa.sca_listCompositesInPartitionMb(partition)

Note:

wsadmin online commands using MBeans may not provide specific error details. Instead, you may see just an MBeanException.

Execute Oracle SOA Suite wsadmin commands from the SOA_ORACLE_HOME/common/bin directory:

cd SOA_ORACLE_HOME/common/bin
./wsadmin.sh

To invoke online help for Oracle SOA Suite commands, enter the following:

wsadmin> print OracleHelp.help('soa')

To invoke online help for a specific command, enter the following:

wsadmin> print OracleHelp.help('soa.sca_deployComposite')

For more information about wsadmin commands, see Section 3.1.3, "Using the Oracle Fusion Middleware wsadmin Commands".

For information about the equivalent Oracle SOA Suite WLST commands, see Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

4.2.2 Configuring the WebSphere Application Client for Use with Oracle JDeveloper

This section contains these topics:

- Section 4.2.2.1, "How to Configure the WebSphere Application Client for Use with Oracle JDeveloper on the Same Computer"

- Section 4.2.2.2, "How to Configure the WebSphere Application Client for Use with Oracle JDeveloper on Different Computers"

4.2.2.1 How to Configure the WebSphere Application Client for Use with Oracle JDeveloper on the Same Computer

This section describes how to configure the WebSphere Application Client for use with Oracle JDeveloper when the two are on the same computer.

1. copy the sas.client.props file from:
WEBSPHERE_HOME/profiles/DmgrXX/properties/

to:

WEBSPHERE_HOME/properties/.

2. Edit the sas.client.props file as follows:

com.ibm.CORBA.securityServerHost=<Server Host Name>
com.ibm.CORBA.securityServerPort=<JMX/BOOTSTRAP Port> (BOOTSTRAP ADDRESS
of SOA SERVER)
com.ibm.CORBA.loginSource=properties
com.ibm.CORBA.loginUserid=<Admin UserName> (weblogic/wasadmin)
com.ibm.CORBA.loginPassword=<PlainText or Encoded Password>
(weblogic1/wasadmin1)

# Does this client support/require SSL connections?
com.ibm.CSI.performTransportAssocSSLTLSRequired=false
com.ibm.CSI.performTransportAssocSSLTLSSupported=false

3. Restart the WebSphere servers.

4. Log in to Oracle JDeveloper and navigate to New, then to Connections, then to Application Server Connections.

5. Create an application server connection and enter the necessary information. To do this:

1. Navigate to File, then New, then Connections, then Application Server Connection. This starts a Create Application Server Connection wizard. Enter the connection name and for the connection type choose WebSphere Server 7.x. Click Next.

2. Specify the username; the default is wasadmin. Specify the password; the default is welcome1. Click Next.

3. Enter server details as shown in Figure 4-1.

Figure 4-1 Configuring Server Details for an Application Server Connection

Note the following:

- For an ND installation, enter the server details for the Deployment Manager. To find these values, refer to Section 4.2.2.1.1, "IBM WebSphere ND: Finding Server Information from the IBM Console."

- There should be no spaces in the path to wsadmin.sh/bat. If you are on Windows, use the DOS equivalent path; for example, instead of C:\Program Files\ use C:\Progra~1\.

- If you have an IBM WebSphere server installed locally, then enter the path to wsadmin.bat file in the "Wsadmin Script File location"; otherwise, specify the location to this file from the IBM WebSphere client installation.

- On the server configuration page, for the 'Server Name' enter SOA SERVER—not the deployment manager server name.

- For the target cell and target node names, enter the application server node name and cell name—not the deployment manager node and cell name.

- On the JMX configuration page, for the 'RMI Port' enter BOOTSTRAP ADDRESS of SOA SERVER.

Click Next.

6. If you are planning to browse (SOA) server over JMX, then select Enable JMX for this connection.
To find the RMI Port value, refer to Section 4.2.2.1.2, "IBM WebSphere AS: Finding Server Information from the IBM Console."

If you have an IBM WebSphere server installed locally, then enter the path to wsadmin.bat file in the "Wsadmin Script File location"; otherwise, specify the location to this file from the IBM WebSphere client installation.

Click Next.

7. You might see the SSL Signer Exchange Prompt. If so, click Y to continue. This dialog appears only once for each host and server.

8. Test your connection and make sure that all tests are successful. To do this, on the Test tab click Test Connection. All tests should pass as follows:

Testing WsAdmin ... success.
Testing JSR-160 ... success.
Testing DeploymentConfig ... success.
Testing JSR-160 for SOA ... success.

If any of the tests fail, then deployment and browsing may not work.

4.2.2.1.1 IBM WebSphere ND: Finding Server Information from the IBM Console

In the Create Application Server Connection wizard, on the Configuration page, enter the following:

SOAP Connector Port =  System administration -> Deployment Manager -> Configuration -> Ports -> SOAP_CONNECTOR_ADDRESS

Server Name = System administration -> Deployment Manager -> Configuration -> Name

Target Node = System administration -> Deployment Manager -> Runtime -> Node name

Target Cell =  System administration -> Deployment Manager -> Runtime-> Cell name

In the Create Application Server Connection wizard, on the JMX page, enter the following:

RMI Port =  System administration -> Deployment Manager -> Configuration -> Ports -> BOOTSTRAP_ADDRESS

4.2.2.1.2 IBM WebSphere AS: Finding Server Information from the IBM Console

In the Create Application Server Connection wizard, on the Configuration page, enter the following:

SOAP Connector Port = Servers -> Server Types -> Websphere Application Servers -> <YourServerName> -> Configuration -> Ports -> SOAP_CONNECTOR_ADDRESS

Server Name = Servers -> Server Types -> Websphere Application Servers -> <YourServerName> -> Configuration -> Name

Target Node = Servers -> Server Types -> Websphere Application Servers -> <YourServerName> -> Runtime -> Node name

Target Cell = Servers -> Server Types -> Websphere Application Servers -> <YourServerName> -> Runtime-> Cell name

In the Create Application Server Connection wizard, on the JMX page, enter the following:

RMI Port = Servers -> Server Types -> Websphere Application Servers -> <YourServerName> -> Configuration -> Ports -> BOOTSTRAP_ADDRESS

4.2.2.2 How to Configure the WebSphere Application Client for Use with Oracle JDeveloper on Different Computers

This section describes how to configure the WebSphere Application Client for use with Oracle JDeveloper when the two are on different computers. Once the WebSphere Application Client is properly configured, Oracle JDeveloper can remotely connect to an IBM WebSphere Server. This enables you to perform actions such as the following in Oracle JDeveloper:

- Remote deployment of SOA composite applications and J2EE applications

- Browsing of SOA composite applications on a remote server

4.2.2.2.1 Installing the WebSphere Application Client

1. Follow the WebSphere Application Client installation steps provided in the IBM documentation.

2. When selecting WebSphere Application Client features for installation, ensure that you select the following components when prompted:

- IBM Developer Kit

- Standalone thin clients and resource adapters

3. Apply the latest fix packs through the IBM Update Installer.
For more information, see Section 1.3.1, "Supported IBM WebSphere Application Servers".

4.2.2.2.2 Creating the wsadmin.sh/bat File

1. Make a copy of the example file provided in the instructions at the WebSphere Application Server Information Center that describe how to run the wsadmin tool remotely in a Java 2 Platform, Standard Edition environment.

2. Edit the wsadmin.sh file (for Linux) or the wsadmin.bat file (for Windows) as follows:

1. Set the WAS_HOME variable to your WebSphere Application Client home directory:

On...

Set...

Linux

WAS_HOME=/home/user/IBM/WebSphere/AppClient

Windows

set WAS_HOME=C:\IBM\WebSphere\AppClient

2. Set the USER_INSTALL_ROOT variable to WAS_HOME:

On...

Set...

Linux

USER_INSTALL_ROOT=${WAS_HOME}

Windows

set USER_INSTALL_ROOT=%WAS_HOME%

3. Set the wsadminHost variable to your remote IBM WebSphere Application Server host name:

On...

Set...

Linux

wsadminHost=-Dcom.ibm.ws.scripting.host=www.example.com

Windows

set wsadminHost=-Dcom.ibm.ws.scripting.host=www.example.com

4. Set the wsadminPort variable to your remote IBM WebSphere Server SOAP connector port:

On...

Set...

Linux

wsadminPort=-Dcom.ibm.ws.scripting.port=8879

Windows

set wsadminPort=-Dcom.ibm.ws.scripting.port=8879

5. Edit the C_PATH variable to use the WebSphere Application Client JAR files:

On...

Set...

Linux

C_PATH="${WAS_HOME}/properties:${WAS_HOME}

/runtimes/com.ibm.ws.admin.client_7.0.0.jar:${WAS_HOME}

/plugins/com.ibm.ws.security.crypto.jar"

Windows

set C_PATH="%WAS_HOME%\properties;%WAS_

HOME%\runtimes\com.ibm.ws.admin.client_7.0.0.jar;%WAS_

HOME%\plugins\com.ibm.ws.security.crypto.jar"

6. If installing on Windows, perform the following modifications to the wsadmin.bat file.

1. Add @setlocal to the beginning of the file.

2. Replace the following code:

if exist "%JAVA_HOME%\bin\java.exe" (
set JAVA_EXE="%JAVA_HOME%\bin\java" )
else (
set JAVA_EXE="%JAVA_HOME%\jre\bin\java" )

with the following code:

set JAVA_EXE="%JAVA_HOME%\jre\bin\java"

3. Remove all quotations from the following Java system properties:.

set CLIENTSOAP=-Dcom.ibm.SOAP.ConfigURL=file:%USER_INSTALL_
ROOT%\properties\soap.client.props
set CLIENTSAS=-Dcom.ibm.CORBA.ConfigURL=file:%USER_INSTALL_
ROOT%\properties\sas.client.props
set CLIENTSSL=-Dcom.ibm.SSL.ConfigURL=file:%USER_INSTALL_
ROOT%\properties\ssl.client.props
set CLIENTIPC=-Dcom.ibm.IPC.ConfigURL=file:%USER_INSTALL_
ROOT%\properties\ipc.client.props

4. Remove all trailing white space characters from the entire file.

4.2.2.2.3 Running wsadmin.sh or wsadmin.bat from the Command Line

Ensure that the script works by running wsadmin.sh or wsadmin.bat from the command line. Note the following:

- You may need to enter the user name and password at the login prompt.

- You may need to accept the server certificate by clicking Y at the signer exchange prompt.

4.2.2.2.4 Editing the sas.client.props File

See Step 20 of Section 4.2.4, "Creating an Application Server Connection" for instructions.

4.2.2.2.5 Creating an Application Server Connection in Oracle JDeveloper

Follow the instructions in Section 4.2.4, "Creating an Application Server Connection" to create an application server connection, and enter the following information when prompted:

- Use the wsadmin.sh or wsadmin.bat file you created in this section (for example, /home/user/IBM/AppClient/wsadmin.sh).

- Use the runtimes directory of the WebSphere Application Client (for example, /home/user/IBM/AppClient/runtimes).

- Use the properties directory that contains sas.client.props (for example, /home/user/IBM/AppClient/properties).

4.2.3 Configuring the Proxy on IBM WebSphere Server

1. Log in to the IBM WebSphere Administrative Console:

host:port/ibm/console

2. Go to Application servers > ServerName > Process definition > Java Virtual Machine > Custom properties.

3. Define the following properties and values.

Property

Value

http.proxyHost

proxyhost.example.com

http.proxyPort

80

http.proxySet

true

4. Restart the server.

4.2.4 Creating an Application Server Connection

You must create a connection to the IBM WebSphere Server to which to deploy a SOA composite application. During application server connection creation, you are prompted for configuration information on several wizard pages. Table 4-2 describes where to find this information on IBM WebSphere Administrative Console for which you are prompted. The locations differ based on the type of IBM WebSphere Server you are using, and the server where the application is being deployed.

Table 4-2 Location of Application Server Connection Configuration Details

Connection Wizard Fields

For IBM WebSphere Application Server - Network Deployment (ND), Select...

For IBM WebSphere Application Server 7.0, Select...

Configuration Page

- SOAP Connector Port

System administration > Deployment manager > Configuration > Ports > SOAP_CONNECTOR_ADDRESS

Servers > Server Types > WebSphere Application Servers > Your_Server_Name > Configuration > Ports > SOAP_CONNECTOR_ADDRESS

- Server Name

System administration > Deployment manager > Configuration > Name

Servers > Server Types > WebSphere Application Servers > Your_Server_Name > Configuration > Name

- Target Node

System administration > Deployment manager > Runtime > Node name

Servers > Server Types > WebSphere Application Servers > Your_Server_Name > Runtime > Node name

- Target Cell

System administration > Deployment manager > Runtime > Cell name

Servers > Server Types > WebSphere Application Servers > Your_Server_Name > Runtime > Cell name

JMX Page

- RMI Port

System administration > Deployment manager -> Configuration > Ports > BOOTSTRAP_ADDRESS

Servers > Server Types > WebSphere Application Servers > Your_Server_Name > Configuration > Ports > BOOTSTRAP_ADDRESS

Note:

If you are using IBM WebSphere ND as the server type and you are deploying the application to the deployment manager server, then use the second column in the table to locate the configuration information you need.

To create an application server connection:

1. From the File main menu, select New.

2. In the General list, select Connections.

3. Select Application Server Connection, and click OK.
The Name and Type page appears.

4. In the Connection Name field, enter a name for the connection.

5. In the Connection Type list, select WebSphere Server 7.x to create a connection to IBM WebSphere Server.

6. Click Next.
The Authentication page appears.

7. In the Username field, enter the user authorized for access to the application server.

8. In the Password field, enter the password for this user.

9. Click Next.
The Configuration page appears. If you are not sure about the information to enter on this page, see Table 4-2.

10. In the Host Name field, enter the host on which the IBM WebSphere Server is installed. If no name is entered, the name defaults to localhost.

11. In the SOAP Connector Port field, enter the port number of the server on which IBM WebSphere Server is installed. The default SOAP connector port is 8879.

12. In the Server Name field, enter the name assigned to the target application server for this application.

13. In the Target Node field, enter the name of the target node for this connection. A node is a grouping of managed servers (for example, hostNode01, where host is the name of the host on which the node resides).

14. In the Target Cell field, enter the name of the target cell for this connection. A cell is a group of processes that host runtime components (for example, hostNode01Cell, where host is the name of the host on which the node resides).

15. In the Wsadmin script location field, enter or browse for the location of the wsadmin script file to use for defining the system login configuration for this application server connection (for example, WAS_HOME\bin\wsadmin.bat for Windows or WAS_HOME/bin/wsadmin.sh for Unix).

Note:

Do not enter spaces in the path to the wsadmin.sh or wsadmin.bat file. For example, if on Windows, use the DOS equivalent path of C:\Progra~1\ instead of C:\Program Files\.

16. Click Next.
The JMX page appears.

17. If you want to browse the SOA Infrastructure and deploy over JMX, select Enable JMX for this connection.

18. In the RMI Port field, enter the port number for the IBM WebSphere Server's RMI connector port. If you are not sure about the information to enter on this page, see Table 4-2.

19. In the WebSphere Runtime Jars Location field, enter or browse for the IBM WebSphere Server's runtime JAR files (for example, WAS_HOME/runtimes).

20. In the WebSphere Properties Location (for secure MBean access) field, enter or browse for the location of the file that contains the properties for the security configuration and MBeans that are enabled (for example, WAS_HOME/profiles/profile_name/properties). This field is optional (for some Oracle JDeveloper use cases), but is required for SOA browsing and deployment. The location you specify must contain the sas.client.props file. Details about the contents of the sas.client.props file are as follows:

- Authentication:
The sas.client.props file is required for authentication, and must be edited as follows:

com.ibm.CORBA.securityServerHost=Server_Host_Name
com.ibm.CORBA.securityServerPort=RMI/BOOTSTRAP_Port

com.ibm.CORBA.loginSource=properties
com.ibm.CORBA.loginUserid=User_Name
com.ibm.CORBA.loginPassword=Plain_Text_or_Encoded_Password

- Encode password:
To encode the password in the sas.client.props file, save this file with a clear text password and then run the following utility:

On Windows:

WAS_HOME\bin\PropFilePasswordEncoder.bat
..\properties\sas.client.props com.ibm.CORBA.loginPassword

On UNIX:

WAS_HOME/bin/PropFilePasswordEncoder.sh
../properties/sas.client.props com.ibm.CORBA.loginPassword

- SSL (If not required):
In most cases, SSL is not required for JMX. You must explicitly disable SSL as follows:

# Does this client support/require SSL connections?
com.ibm.CSI.performTransportAssocSSLTLSRequired=false
com.ibm.CSI.performTransportAssocSSLTLSSupported=false

- SSL (If required):
If you require SSL for JMX, do not configure ssl.client.props. Instead, you must append the necessary SSL configuration details to sas.client.props for Sun JRE clients, since Oracle JDeveloper runs in the Sun JRE.

Edit the following two sections in sas.client.props:

- Edit the section on SSL connection requirements.

# Does this client support/require SSL connections?
com.ibm.CSI.performTransportAssocSSLTLSRequired=false
com.ibm.CSI.performTransportAssocSSLTLSSupported=true

- Append the following syntax to the end of sas.client.props. For the com.ibm.ssl.trustStore property, you can use the path to any *.jks truststore.

#--------------------------------------------------------------

# SSL configuration alias referenced in ssl.client.props
#--------------------------------------------------------------

com.ibm.ssl.alias=JDeveloperSSLSettings
com.ibm.ssl.protocol=SSL
com.ibm.ssl.securityLevel=HIGH
com.ibm.ssl.trustManager=SunX509
com.ibm.ssl.keyManager=SunX509
com.ibm.ssl.contextProvider=SunJSSE
com.ibm.ssl.enableSignerExchangePrompt=gui

com.ibm.ssl.trustStoreName=DemoTrustStore
com.ibm.ssl.trustStore=c:/YOUR_JDEVHOME/your_server/
lib/DemoTrust.jks

com.ibm.ssl.trustStorePassword=DemoTrustKeyStorePassPhrase
com.ibm.ssl.trustStoreType=JKS
com.ibm.ssl.trustStoreProvider=SUN
com.ibm.ssl.trustStoreFileBased=true
com.ibm.ssl.trustStoreReadOnly=false

- Upon the first invocation of JMX (typically when you click Test Connection on the Test page of this wizard), the SSL Signer Exchange dialog can appear. Click y to accept the server certificate. Note that a ThreadDeath error is displayed that can safely be ignored.

- Provide the keystore location through the system properties in either of the following ways:

Note:

When configuring the truststore location through the system properties on Windows operating systems, you must enter a forward slash (/) in the path. For example, c:/to/path/truststore.

From the command prompt:

$JDEV_INSTALL_DIR/jdev/bin/jdev
-J-Djavax.net.ssl.trustStore=c:/path/to/truststore
-J-Djavax.net.ssl.trustStorePassword=DemoTrustKeyStorePassPhrase

In the jdev.conf file:

AddVMOption   -Djavax.net.ssl.trustStore=c:/path/to/truststore
AddVMOption   -Djavax.net.ssl.trustStorePassword=DemoTrust
KeyStorePassPhrase

- Multiple WAS connections
Since one sas.client.props file is required for each application server connection, Oracle recommends that you create a directory for each application server, copy sas.client.props to that directory, and edit the file as necessary.

21. Click Next.

22. Click Test Connection to test your server connection.

23. If the connection is successful, click Finish. Otherwise, click Back to make corrections in the previous dialogs. Even if the connection test is unsuccessful, a connection is created.

4.2.5 Deploying SOA Composite Applications

Deployment of SOA Composite Applications from Oracle JDeveloper to IBM WebSphere Server is largely the same as described in Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

The only exception is the appearance of the Deploy using SSL check box on the SOA Servers page of the deployment wizard. This differs from Oracle WebLogic Server, where the Deploy using SSL check box instead appears on the Configuration page of the Create Application Server Connection wizard page.

Table 4-3 describes what occurs when you select this check box during IBM WebSphere Server deployment.

Table 4-3 Deployment to HTTPS and HTTP Servers

If This Checkbox Is...

Then...

Selected

An HTTPS server URL must exist to deploy the composite with SSL. Otherwise, deployment fails.

If the server has only an HTTP URL, deployment also fails. This enables you to ensure that SSL deployment must not go through a non-SSL HTTP URL, and must only go through an HTTPS URL

Not selected

An HTTP server URL must exist to deploy to a non-SSL environment. Otherwise, deployment fails.

If the server has both HTTPS and HTTP URLs, deployment occurs through a non-SSL connection. This enables you to force a non-SSL deployment from Oracle JDeveloper, even though the server is SSL-enabled.

4.2.6 Using the Diagnostic Framework

Be aware of the following issues when using the Diagnostic Framework on IBM WebSphere.

- Watches and notifications are not supported.

- The Automatic Diagnostic Repository (ADR) binaries must be installed manually as described in Section 3.2.5.1, "Setting Up the Diagnostic Framework on IBM WebSphere."

4.2.7 Using EJB Bindings

If a SOA composite application includes an EJB service, you must perform the following configuration procedures for the EJB service binding to work properly:

- Section 4.2.7.1, "EJB Service Binding"

- Section 4.2.7.2, "EJB Client"

- Section 4.2.7.3, "EJB Reference Binding"

4.2.7.1 EJB Service Binding

You must set up credentials for EJB JNDI binding before deploying a composite that contains an EJB service binding.

1. Create an entry for Oracle Platform Security Services (OPSS) (for example, with SOA as the name and Deployer as the key.

1. Go to the MW_HOME/oracle_common/common/bin directory.
where MW_HOME is the directory in which Oracle SOA Suite is installed.

2. Make the wsadmin.sh file executable (if it is not already):

chmod +x wsadmin.sh

3. Execute the following command, and enter the password when prompted:

./wsadmin.sh -host localhost -port 8880 -conntype SOAP -user adminusername
-lang jython

The port number is the SOAP_CONNECTOR_ADDRESS of the host used to connect to the server for deployment. In the IBM Administrative Console, navigate to the Ports table via Deployment Manager > Ports to locate the value.

4. Enter the following command to create the credentials:

Opss.createCred(map="SOA",key="Deployer",user="adminusername",password="password
")

2. Assign the JNDI reading, writing, and binding roles to the administrator user.

Note:

The JNDI binding role does not need to be granted to the Administrator. However, it must match the user you specified with the Opss command in Step d.

1. Log in to the WebSphere Administrative Console.

2. Click and expand Environment > Naming.

3. Click CORBA naming service groups.

4. Click the Add button.

5. Select all the roles in the selection box at the top.

6. Search for groups using the wildcard ("*")

7. Select the Administrators group (to which the adminusername user belongs).

8. Click OK.

9. Click the Save link.

10. Restart the server.

4.2.7.2 EJB Client

Generate stubs for the EJB interfaces using the createEJBStubs.sh utility and ensure that the stubs are in the client classpath.

4.2.7.3 EJB Reference Binding

You must include the EJB stubs for the external EJB interface in the composite SCA-INF/classes or SCA-INF/lib directory.

4.2.8 AQ Technology Adapter and WebSphere 7.0

For the AQ Adapter to work correctly on the WebSphere 7.0 platform, you need to use the IBM WebSphere Administrative Console to provide specific connection factory and data source properties.

For the connection factory, you need to set the following custom property for the connection pool: defaultConnectionTypeOverride = unshared

For the AQ adapter dataSource, ensure that validate existing pooled connections is checked. The associated interval can be set to 0. See the following screen shot.

Also for the AQ adapter dataSource, you must define the same property as a custom property for the connection pool by setting the following: defaultConnectionTypeOverride = unshared

See the following screen shot.

You also need to set the maximum connections value of AQAdapter J2C connection factories to a higher value than the default of 10. You can find this entry in the WebSphere Application Server J2C connection factories -> <Name of AQAdapter> -> Connection pools panel.

4.2.9 JMS Technology Adapter on WebSphere 7.0

If you are developing composite applications to run on WebSphere 7.0, you need to use the Third Party option when modelling the JMS adapter with the Default Messaging JMS provider. You can specify that the adapter uses a third-party JMS Provider, by supplying a value to the FactoryProperties parameter in the weblogic-ra.xml file. Specifically, you can provide the ThirdPartyJMSProvider value to the FactoryProperties parameter.

When deployed on WebSphere 7.0, the JMS Adapter will not work with an AQJMS provider, unless you use the Adapter Configuration Wizard to set defaultConnectionTypeOverride as unshared for both the adapter connection factory pool and for the queue/topic connection factory pool. See the following screen shot.

You also need to set the maximum connections value of JMS Adapter J2C factories to a higher value than the default of 10. You can find this entry in the WebSphere Application Server J2C connection factories > Name of JMS Adapter > Connection pools panel.

4.2.9.1 Avoiding JMS Adapter Connection Leaks

While running JMS Adapter use cases on WebSphere 7.0, you might encounter the following error from a connection leak:.

java.lang.IllegalStateException: ConnectionManager is null

To avoid connection leaks, update the maximum and minimum connection value for the JMS Adapter to the same value at Queue connection factories > Connection_factory_name > Connection pools and J2C connection factories > J2C_Connection_Factoryname > Connection Point.

4.2.10 Oracle Database Adapter on WebSphere 7.0

For the Oracle Database Adapter to work properly, you need to the set the maximum connections value of the DB adapter J2C connection factories, using the WebSphere Admin Server. This value needs to be set to a higher value than the default of 10. You can find this entry under J2C connection factories > Name of DB-Adapter > Connection pools. The preferred value is 100.

4.3 Differences and Restrictions When Managing Oracle SOA Suite Components on IBM WebSphere

The following sections describe differences and restrictions when managing Oracle SOA Suite components on IBM WebSphere:

- Section 4.3.1, "Configuring the Deployment Manager to Detect the Remote Node Agent"

- Section 4.3.2, "Publishing Services to a UDDI Registry"

- Section 4.3.3, "Oracle Enterprise Manager Fusion Middleware Control Console Shortcut Links"

- Section 4.3.4, "DefaultToDo Task Flow is Configured to Use HTTPS"

- Section 4.3.5, "Configuring the current-dateTime Function to Display Output in Seconds"

- Section 4.3.6, "Obtaining the Locator Object"

- Section 4.3.7, "Running the Facade API Client on IBM WebSphere"

4.3.1 Configuring the Deployment Manager to Detect the Remote Node Agent

When configuring Oracle SOA Suite in an IBM WebSphere high availability environment, ensure that you stop and restart the Deployment Manager before configuration of the second node. If you do not perform these steps, the Deployment Manager does not detect the remote node agent.

1. Run the Configuration Wizard on host1:

MW_HOME/ORACLE_HOME/common/bin/was_config.sh

1. Create and configure an IBM WebSphere cell.

2. Install Oracle SOA Suite components into the cell.

2. Start the Deployment Manager by navigating to the following directory in the IBM WebSphere home and entering the following command:

profiles/deployment_mgr_name/bin/startManager.sh
-profileName dmgr_profileName

For example:

/disk01/IBM/WebSphere/AppServer/profiles
/Dmgr01/bin/startManager.sh -profileName Dmgr01

3. Stop node agent1. (It starts automatically after configuration completion.)

MW_HOME/user_projects/domains/bifoundation_cell/bifoundation_cell
node0/bin/stopNode.sh -username user_name -password password

4. For Oracle WebCenter Content, synchronize the node:

WAS_HOME/bin/syncNode.sh localhost SOAP_CONNECTOR_ADDRESS -profileName
profile_name -username was_admin_user -password was_password

5. Stop the Deployment Manager.

6. Restart the Deployment Manager.

If you do not perform Steps 5 and 6, after you finish configuration of host2 and restart node agent2, when you go to the IBM WebSphere Administrative Console, the node agent on host2 (remote node) is shown as down when it is actually running. This is because the Deployment Manager fails to detect the remote node agent.

7. Run the Configuration Wizard on host2 (remote host), as described in Step 1.

1. Federate the host. For information, see Section 5.2.19.4, "Federate WCPHOST2 and Configure Cell."

2. Configure an IBM WebSphere cell.

8. Stop node agent2, as described in Step 3.

9. For Oracle WebCenter Content, synchronize node2, as described in Step 4.

10. Start node agent1.

MW_HOME/user_projects/domains/bifoundation_cell/bifoundation_cell_
node0/bin/startNode.sh -username user_name -password password

11. Start the administration server by navigating to the following directory in the IBM WebSphere home and entering the following command:

profiles/profile_name/bin/startServer.sh OracleAdminServer
-profileName profileName

For example:

/disk01/IBM/WebSphere/AppServer/profiles/Custom01/bin/startServer.sh
OracleAdminSErver
-profileName Custom01

12. Start SOA server1 by navigating to the following directory in the IBM WebSphere home and entering the following command:

profiles/profile_name/bin/startServer.sh server_name-profileName profileName

For example:

/disk01/IBM/WebSphere/AppServer/profiles
/Custom01/bin/startServer.sh soa_server1
-profileName Custom01

13. Start node agent2, as described in Step 10.

14. Start SOA server2, as described in Step 12.

4.3.2 Publishing Services to a UDDI Registry

You cannot publish service binding components to the Universal Description, Discovery, and Integration (UDDI) registry from Oracle Enterprise Manager Fusion Middleware Control on IBM WebSphere.

4.3.3 Oracle Enterprise Manager Fusion Middleware Control Console Shortcut Links

Oracle Enterprise Manager Fusion Middleware Control does not include shortcut links to the WebSphere Administrative Console from the following locations:

- The Server Data Source JNDI and Server Transaction Data Source JNDI fields of the Data Sources section of the SOA Infrastructure Common Properties page

- The Related Links menu available on service engine pages.

To log in to IBM WebSphere, you must go directly to the WebSphere Administrative Console.

4.3.4 DefaultToDo Task Flow is Configured to Use HTTPS

Oracle SOA Suite on IBM WebSphere is configured to use HTTPS. This means the DefaultToDo task flow also uses HTTPS because the DefaultToDo task flow host name, port, and protocol are based on the SOA Server URL.

If a valid certificate is not available on the server, then DefaultToDo would not be accessible in Microsoft Internet Explorer and Google Chrome, while Mozilla Firefox would issue a warning and then allow the user to proceed. If necessary, use Oracle Enterprise Manager Fusion Middleware Control to change the SOA Server URL.

4.3.5 Configuring the current-dateTime Function to Display Output in Seconds

The current-dateTime function returns the current datetime value in the ISO format of CCYY-MM-DDThh:mm:ss.sTZD (where s denotes the time in milliseconds). If you want to display the output in seconds, perform the following steps:

1. Log in to the IBM WebSphere Administrative Console.

2. Click Servers > Server Types > WebSphere application servers.

3. Click the name of the server on which you want this function to display output in seconds (for example, server1).

4. Under Server Infrastructure, click Java and Process Management > Process definition.

5. Under Additional Properties, click Java Virtual Machine.

6. In the Generic JVM arguments field, append the following to the end:

-Dcom.oracle.soa.xpath.datetimeWithoutMillis=true

7. Click OK and save your changes to the master configuration.

8. Restart the server.

4.3.6 Obtaining the Locator Object

The following system property is required for Java client code to successfully obtain the Locator object when run against an IBM WebSphere Application Server-based SOA installation:

static
{
System.setProperty("oracle.fabric.config.platform", "websphere");
}

After setting this property, the Locator object is obtained. If you instead attempt to obtain the Locator object with the following code:

LocatorFactory.createLocator(jndiProps);

The following exception error occurs:

Exception in thread "main" java.lang.NoClassDefFoundError:
weblogic/security/Security
at
oracle.soa.management.internal.ejb.WLSPrivilegedExecutionContext.
getCurrentSubject(WLSPrivilegedExecutionContext.java:30)
at oracle.soa.management.internal.ejb.EJBLocatorImpl.lookupBean
(EJBLocatorImpl.java:817)
at oracle.soa.management.internal.ejb.EJBLocatorImpl.
lookupFinderBean
(EJBLocatorImpl.java:803)
at oracle.soa.management.internal.ejb.EJBLocatorImpl.<init>
(EJBLocatorImpl.java:170)
at oracle.soa.management.facade.LocatorFactory.createLocator
(LocatorFactory.java:35)

4.3.7 Running the Facade API Client on IBM WebSphere

Note:

You must use the IBM JDK.

1. Set the JAVA_HOME and PATH variables appropriately to point to the IBM Java location.

2. Include the following code in the IBM WebSphere client runtime classpath:

<path id="clientclasspath.was">
<pathelement
location="${WAS_HOME}/runtimes/com.ibm.ws.ejb.thinclient_7.0.0.jar"/>
<pathelement location="${WAS_HOME}/runtimes/com.ibm.ws.orb_7.0.0.jar"/>
<pathelement location="${WAS_HOME}/plugins/com.ibm.ws.wccm.jar"/>
<pathelement
location="${WAS_HOME}/deploytool/itp/plugins/com.ibm.websphere.
v7_7.0.3.v20110824_2356/wasJars/sas.jar"/>

<pathelement
location="${WAS_HOME}/deploytool/itp/plugins/com.ibm.websphere.v7_
7.0.3.v20110824_2356/wasJars/ibmjceprovider.jar"/>
<pathelement location="${WAS_HOME}/java/jre/lib/ibmjsseprovider2.jar"/>

<!-- Other class path entries -->

</path>

3. Pass the following system properties while running the Facade API client. In the following segment of code, "${full_path}" points to the directory location in which sas.client.props and ssl.client.props are present.
These files are present in the IBM WebSphere installation directory in the following location. However, before passing them as the above system properties, you must modify them as follows:

1. Copy the following files to an appropriate directory, which is represented as ${full_path}.

cp ${WAS_HOME}/profiles/DefaultTopology/DefaultServer/properties/
sas.client.props ${full_path}

cp ${WAS_HOME}/profiles/DefaultTopology/DefaultServer/properties/
ssl.client.props ${full_path}

2. Modify the following entries in sas.client.props:

com.ibm.CORBA.securityServerHost=localhost #your host name
com.ibm.CORBA.securityServerPort=2800 #this should point to the bootstrap
port

# RMI/IIOP user identity
com.ibm.CORBA.loginUserid=wasadmin #was user
com.ibm.CORBA.loginPassword=password #was password

3. Ensure the user.root property is correct in ssl.client.props:

user.root=/${WAS_HOME}/profiles/DefaultTopology/DefaultServer

4. Pass the following code as system properties:

<sysproperty key="com.ibm.SSL.ConfigURL"
value="file:${full_path}/ssl.client.props"/>

<sysproperty key="com.ibm.CORBA.ConfigURL"
value="file:${full_path}/sas.client.props"/>

<sysproperty key="java.security.auth.login.config"
value="${WAS_HOME}/profiles/DefaultTopology/DefaultServer/properties
/wsjaas_client.conf"/>

<!-- The below three properties are optional and required if you want to
capture logs for debugging. Detailed failure can be found in
the client.log using the above setup -->

<sysproperty key="com.ibm.CORBA.CommTrace" value="true"/>
<sysproperty key="com.ibm.CORBA.Debug" value="true"/>
<sysproperty key="com.ibm.CORBA.Debug.Output" value="/tmp/client.log"/>

<!-- Optional properties end -->

4. Ensure that you pass the security credentials when creating the Locator.
For example:

Hashtable<String, Object> h = new Hashtable<String, Object>();
h.put(Context.INITIAL_CONTEXT_FACTORY,
"com.ibm.websphere.naming.WsnInitialContextFactory");
h.put(Context.PROVIDER_URL, "iiop://localhost:2800");
h.put(Context.SECURITY_PRINCIPAL, "wasadmin");
h.put(Context.SECURITY_CREDENTIALS, "password");
final Locator loc = LocatorFactory.createLocator(h);

5. Set the following property in your client code:

static {
System.setProperty("oracle.fabric.config.platform", "websphere");
}

After performing these steps, the following segment of code runs successfully:

CompositeInstanceFilter filter = new CompositeInstanceFilter();
filter.setCompositeDN("default/HelloWorld!1.0");
List<CompositeInstance> lCompositeInstance =
loc.getCompositeInstances(filter);

If you skip or incorrectly run any of Steps 1 through 5, the above-mentioned code that uses the Facade API such as loc.getCompositeInstances(filter); does not work and can throw the following exception:

java.lang.RuntimeException: Caller doesn't have enough permission
to call this method.

4.4 Differences and Restrictions When Managing Oracle BAM on IBM WebSphere

The following sections describe differences and restrictions when using Oracle BAM on IBM WebSphere:

- Section 4.4.1, "Configuring Oracle BAM Adapter"

- Section 4.4.2, "Using Oracle Data Integrator with Oracle BAM"

- Section 4.4.3, "Using ICommand"

- Section 4.4.4, "Configuring Logging for Oracle BAM on IBM WebSphere"

- Section 4.4.5, "Configuring Trusted Domains"

- Section 4.4.6, "Configuring Security"

- Section 4.4.7, "Using Oracle Internet Directory with Oracle BAM"

- Section 4.4.8, "Configuring Enterprise Message Sources to Connect to Remote JMS Queue/Topics"

- Section 4.4.9, "Using Oracle BAM Data Controls"

- Section 4.4.10, "Configuring the LTPA Timeout for Active Data Reports"

4.4.1 Configuring Oracle BAM Adapter

Configuration of Oracle BAM Adapter on IBM WebSphere is largely the same as described in Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite. The exception is that you use the IBM WebSphere Administrative Console (instead of the Oracle WebLogic Server Administration Console) to configure Oracle BAM Adapter.

Refer to Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite for complete information. The information provided in this section simply highlights the selections you make when using the IBM WebSphere Administrative Console to configure Oracle BAM Adapter properties, connection factories and trusted domains.

Note:

When updating property values in the IBM WebSphere Administrative Console, click the property to open a page, enter the values as needed, and click OK. To commit the changes, click Save. Then restart Oracle SOA Server.

4.4.1.1 Configuring Oracle BAM Adapter Properties

In the IBM WebSphere Administrative Console, you navigate to Resources > Resource Adapters (Figure 4-2) to locate the Oracle BAM Adapter resource.

Figure 4-2 Resources and Resource Adapters Panels in Administrative Console

In the Resource Adapter summary table, you click the Oracle BAM Adapter resource name to configure the properties (for example, OracleBAMAdapter or BAM ADC Adapter as shown Figure 4-3. The name varies depending on how it was deployed).

Figure 4-3 Resource Adapter Summary Table

On the Configuration page, you click Custom properties in the Additional Properties section on the right (Figure 4-4) to display all the properties you can configure for the selected Oracle BAM Adapter, as shown in Figure 4-5.

Figure 4-4 Additional Properties Section

Figure 4-5 Custom Properties Page of Oracle BAM Adapter

4.4.1.2 Configuring Oracle BAM Connection Factories

Before deploying applications that use Oracle BAM Adapter, a connection factory to Oracle BAM Server must be configured. You can configure both Remote Method Invocation (RMI) and Simple Object Access Protocol (SOAP) connection factories.

After clicking an Oracle BAM Adapter resource name as shown in Figure 4-3, on the Configuration page, you click J2C connection factories in the Additional Properties section on the right (Figure 4-6) to display a list of configured connection factories that you can use with the resource adapter.

Figure 4-6 Additional Properties Section

If there are no connection factories listed on the J2C Connection Factories page, click New to create and configure an Oracle BAM connection factory to Oracle BAM Server (Figure 4-7). You can create connection factories for RMI-based calls and SOAP-based calls.

Figure 4-7 J2C Connection Factories Page

When creating RMI-based and SOAP-based connection factories, provide a connection factory name, a JNDI name, and the Connection factory interface for each type (Figure 4-8 and Figure 4-9).

Figure 4-8 New J2C Connection Factory Configuration

Figure 4-9 SOAP Connection Factory Configuration

Figure 4-10 shows the J2C Connection Factories page with two connection factories created and listed in the table. Note that the node and cell names will vary depending on the deployment.

Figure 4-10 J2C Connection Factories Page

To configure the properties for a connection factory, click the connection factory name (for example, bamrmi or bamsoap), then on the Configuration page click Custom properties on the right. Figure 4-11 and Figure 4-12 show the custom properties you can configure for a RMI-based connection factory and a SOAP-based connection factory, respectively. Note that with RMI-based connection factories, InstanceName is the connection name for Oracle BAM Adapter (for example, ADCAdapter1), and PortNumber is the BOOTSTRAP_ADDRESS of the Oracle BAM Server. With SOAP-base connection factories, PortNumber is the WC_defaulthost of Oracle BAM Server.

Figure 4-11 Connection Factory Custom Properties for RMI-Based Calls

Figure 4-12 Connection Factory Custom Properties for SOAP-Based Calls

Figure 4-12 also shows a SOAP-based connection factory configured for HTTP. To configure an HTTPS SOAP-based connection factory, create a new connection factory and specify the IsHTTPSEnabledWebService property value as true.

4.4.1.3 Configuring Trusted Domains

When using the RMI connection between a SOA composite application and Oracle BAM Server, that is when they are deployed in different cells, trusted domain configuration must be done in the IBM WebLogic Administrative Console. For more information, see Section 4.4.5, "Configuring Trusted Domains."

4.4.2 Using Oracle Data Integrator with Oracle BAM

Setting up the Oracle BAM and Oracle Data Integrator integration with Oracle BAM Server running on IBM WebSphere is largely the same as described in Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite, with a few exceptions. The exceptions are:

1. If you already have an installation of Oracle Data Integrator 10g working with an older version of Oracle BAM, you must have another installation of Oracle Data Integrator 10g to work with the current release of Oracle BAM. You cannot use the same Oracle Data Integrator 10g installation to work with multiple versions of Oracle BAM.

2. Apache Ant is required to run the installation script. Set the environment variable ANT_HOME to the location where ANT is installed before you run the bam_odi_configuration.sh (bam_odi_configuration.bat) script.

3. Set the following environment variables before you run the installation script:

- JAVA_HOME: Root directory of the supported version of Java Development Kit (see the Oracle BAM support matrix on Oracle Technology Network web site for supported JDK versions).

- WAS_HOME: The location of the IBM WebSphere Application Server installation directory.

- WAS_CLIENT_PROPS: Directory where the sas.client.props file that the user wants to use resides.

4. Before you run the installation script, make sure login security values in sas.client.props and the server port value in BAMICommandConfig.xml are configured properly. For information, see Section 4.4.3, "Using ICommand."

5. After running the installation script and before using Oracle Data Integrator with Oracle BAM Server running on IBM WebSphere, make sure the server port value in BAMODIConfig.xml is configured to the same server port value as in step 4 above. To change the value, locate BAMODIConfig.xml in $ODI_HOME/oracledi/lib/config, then uncomment the line for the server port value.

4.4.3 Using ICommand

When a standalone Oracle BAM client (such as ICommand, Oracle Data Integrator, and Oracle BAM Data Control) connects to Oracle BAM Server, the configuration file (for example BAMICommandConfig.xml), which is read when the Oracle BAM client code is invoked, must point to the server on which the Oracle BAM Server instance is running.

In addition, login security must be configured before standalone Oracle BAM clients can connect to Oracle BAM Server.

4.4.3.1 Configuring Oracle BAM Server Port

By default ICommand looks for Oracle BAM Server on port 2809. If the Oracle BAM Server port number is changed from the default during the setup and configuration of Oracle BAM on IBM WebSphere, then you must manually change the port number from 2809 to the new port number in the BAMICommandConfig.xml file.

Locate the BAMICommandConfig.xml file in SOA_ORACLE_HOME/bam/config.

The property to change is:

<ServerPort>2809</ServerPort>

To determine the correct port value to use:

- On IBM WebSphere ND: Use the IBM WebSphere Administrative Console to navigate to Servers > Server Types > WebSphere Application Servers > [bam_server_name] > Ports to locate the BOOTSTRAP_ADDRESS value of the Oracle BAM Server.

- On IBM WebSphere AS: Look at the BOOTSTRAP_ADDRESS value in the file portdef.props, which is located in WAS_HOME/was_profiles/DefaultTopology/was_as/ServerName/properties.

The BAMICommandConfig.xml file should also have the following ServerPlatform property:

<ServerPlatform>websphere</ServerPlatform>

4.4.3.2 Configuring Login Security

For information, see Section 4.4.6.1, "Configuring Login Security for Standalone Oracle BAM Components on IBM WebSphere."

4.4.4 Configuring Logging for Oracle BAM on IBM WebSphere

To configure logging for Oracle BAM on IBM WebSphere, you have to use either the IBM WebSphere Administrative Console or execute wsadmin scripts.

To use the IBM WebSphere Administrative Console to configure logging:

1. Log in to the IBM WebSphere Administrative Console.

2. In the navigation panel, expand Servers > Server Types.

3. Select WebSphere application servers, then select the server that is hosting the Oracle BAM application (for example, bam-server1 on IBM WebSphere ND or ServerName on IBM WebSphere AS).

4. On the Configuration tab, Troubleshooting section, select Change Log Detail Levels, then expand [All Components].
You will see a list of known loggers.

5. Scroll down and select the desired oracle.bam logger.

6. Select Message And Trace Levels and set the desired level.
You can set levels at any point in the package hierarchy right down to the individual class. This mechanism is analogous to modifying the logging.xml file.

7. Click Apply or OK, then click Save to the master configuration.
This saves the changes permanently so they are in effect even if you restart IBM WebSphere.

The log files are located at WAS_HOME/was_profiles/DefaultTopology/was_as/ServerName/logs/ServerName, (for example, ServerName-diagnostic.log), where ServerName is the name of the server that is hosting Oracle BAM.

Alternatively, you can execute wsadmin scripts to set the level for all the current descendants of a logger. For example:

wsadmin> myLoggers = OracleODL.listLoggers(pattern="oracle.bam.common.*")
wsadmin> for loggerName in myLoggers.keys():
wsadmin>   OracleODL.setLogLevel(target="ServerName", logger=loggerName,level="FINE")

4.4.5 Configuring Trusted Domains

When Oracle BAM Server components require a connection to a remote server, trusted domain configuration must be done in the IBM WebSphere Administrative Console. For example, when Enterprise Message Sources (EMS) in Oracle BAM needs to connect to a topic/queue on a JMS server that is installed on a different IBM WebSphere instance, you have to set up the domain trust between the IBM WebSphere instances.

To perform communication with another server, IBM WebSphere has to retrieve a signer certificate from a secure remote SSL port during the handshake. The signer exchange process for setting up SSL to external servers such as Lightweight Directory Access Protocol (LDAP) is greatly simplified on IBM WebSphere. Instead of manually obtaining the remote server's signer certificate and then importing it into the appropriate trust store each time, the signer certificate retrieved from the remote port can be stored in an existing local trust store. Oracle BAM Server components that require a connection to the remote server can then use the validated signer certificate from the keystore.

To configure a trusted domain by obtaining and validating a signer certificate from a remote port:

1. Log in to the IBM WebSphere Administrative Console.

2. In the navigation panel, expand Security, then click SSL certificate and key management.

3. Click Key stores and certificates.
The Keystore usages dropdown should show SSL keystores as the value.

4. Select a trust store (for example, NodeDefaultTrustStore).

5. Click Signer certificates, then click Retrieve from port.
This option opens an SSL connection to retrieve the certificate.

6. Enter the host name of the machine on which the signer resides.

7. Enter the SSL port on the host machine.

8. Enter an alias.

9. Click Retrieve signer information.

10. Verify the signer certificate information and the SHA digest of the certificate, which is used to ensure the information has not been modified in transit.

11. Click Apply or OK to add the signer certificate to the selected trust store.

4.4.6 Configuring Security

Login security must be configured before standalone Oracle BAM clients (such as Oracle Data Integrator, Oracle BAM Data Control and ICommand) can connect to Oracle BAM Server on IBM WebSphere.

Oracle BAM web applications by default use FORM as the authentication security method. To use the CLIENT_CERT authentication security method on IBM WebSphere, you must configure it manually.

To provide secure access to Oracle BAM web applications on IBM WebSphere, you must assign users to roles that provide the necessary permissions.

See the following for more information:

- Section 4.4.6.1, "Configuring Login Security for Standalone Oracle BAM Components on IBM WebSphere"

- Section 4.4.6.2, "Configuring Oracle BAM to Use CLIENT_CERT Authentication on IBM WebSphere"

- Section 4.4.6.3, "Creating User/Group Mappings for Oracle BAM on IBM WebSphere"

4.4.6.1 Configuring Login Security for Standalone Oracle BAM Components on IBM WebSphere

For standalone clients like Oracle Data Integrator, Oracle BAM Data Control and ICommand to connect to Oracle BAM Server on IBM WebSphere, certain property values must be set in the sas.client.props file, which is required for initial authentication of the standalone client by IBM WebSphere.

Edit the sas.client.props file to include the following properties:

com.ibm.CORBA.securityEnabled=true
com.ibm.CORBA.loginSource=properties
com.ibm.CORBA.securityServerHost=localhost
com.ibm.CORBA.securityServerPort=2809
com.ibm.CORBA.loginUserid=username
com.ibm.CORBA.loginPassword=password
com.ibm.CSI.performTransportAssocSSLTLSRequired=false
com.ibm.CSI.performTransportAssocSSLTLSSupported=false

...where securityServerPort is the deployment manager server BOOTSTRAP_ADDRESS value.

Using WAS_HOME as the root folder for the IBM WebSphere installation, the location of the sas.client.props file is:

- WAS_HOME/profiles/<deployment_manager_profile_name>/properties on IBM WebSphere ND

- WAS_HOME/was_profiles/DefaultTopology/was_as/ServerName/properties on IBM WebSphere AS

Details about the properties to configure in sas.client.props are found in Table 4-4, "Login Security Properties for the sas.client.props File".

Table 4-4 Login Security Properties for the sas.client.props File

Property to add...

Value to use...

Additional note about the property...

com.ibm.CORBA.securityEnabled

true

Must be set to this value

com.ibm.CORBA.loginSource

properties

Must be set to this value

com.ibm.CORBA.securityServerHost

<hostname>

Use localhost or the host name

com.ibm.CORBA.securityServerPort

<serverport>

Default port is 2809

The correct value can be determined by looking at the BOOTSTRAP_ADDRESS value:

- Use the IBM WebSphere Administrative Console to navigate to Servers > Server Types > WebSphere Application Servers > [bam_server_name] > Ports to locate the BOOTSTRAP_ADDRESS value of the Oracle BAM Server on IBM WebSphere ND

- Look at the BOOTSTRAP_ADDRESS value in the file portdef.props, which is located in WAS_HOME/was_profiles/DefaultTopology/was_as/ServerName/properties on IBM WebSphere AS

com.ibm.CORBA.loginUserid

<userid>

For example, adminusername

com.ibm.CORBA.loginPassword

<password>

For example, password1

The loginPassword needs to be encrypted using the PropFilePasswordEncoder utility. The command to encrypt a password is:

WAS_HOME/bin/PropFilePasswordEncoder.sh <path>/sas.client.props -SAS

where <path> of the sas.client.props file is:

- WAS_HOME/profiles/<deployment_manager_profile_name>/properties on IBM WebSphere ND

- WAS_HOME/was_profiles/DefaultTopology/was_as/ServerName/properties on IBM WebSphere AS

Instructions on how to use the utility are also provided in sas.client.props.

com.ibm.CSI.performTransportAssocSSLTLSRequired

false

SSL is not required

com.ibm.CSI.performTransportAssocSSLTLSSupported

false

SSL is not required

4.4.6.2 Configuring Oracle BAM to Use CLIENT_CERT Authentication on IBM WebSphere

On IBM WebSphere, Oracle BAM web applications must use FORM as the authentication security method and Oracle BAM web services must use BASIC as the authentication security method. Unlike Oracle WebLogic Server, IBM WebSphere does not provide a fallback mechanism for authentication methods, which means you cannot specify more than one authentication method. If you wish to use the CLIENT_CERT authentication security method for Oracle BAM web applications, you must configure it manually by following these steps:

1. Extract the existing oracle-bam-was.ear, located in MW_HOME/Oracle_SOA1/bam/applications, for example.

2. Modify the deployment descriptor web.xml in bam-web.war by replacing "FORM" with "CLIENT_CERT". For example:

<login-config>
<auth-method>CLIENT-CERT</auth-method>
</login-config>

3. Repackage bam-web.war with the edited deployment descriptor.

4. Deploy the modified oracle-bam-was.ear.

4.4.6.3 Creating User/Group Mappings for Oracle BAM on IBM WebSphere

After installing Oracle BAM on IBM WebSphere AS or IBM WebSphere ND, you must specify the users and groups that are mapped to the security roles for Oracle BAM.

To create user/group mappings for Oracle BAM on IBM WebSphere:

1. Log in to the IBM WebSphere Administrative Console:
host:port/ibm/console

2. On IBM WebSphere ND, navigate to the Console Preferences page in System administration. Select Synchronize changes with Nodes and click Apply.
This ensures that all changes saved to the master configuration are propagated across the nodes.

3. In the navigation panel, expand Applications > Application Types.

4. Select WebSphere enterprise applications, then select oracle-bam.

5. On the Configuration tab, Detail Properties section, select Security role to user/group mapping.

6. Select the bamuser checkbox, then click Map Users.

7. Click Search to display a list of available users.

8. Select cn=adminusername,dc=com and move it to the Selected list, then click OK twice.

9. Save the change and restart Oracle BAM Server.

Alternatively, you can use the wsadmin command-line utility to configure the mapping. For example:

wsadmin> AdminApp.edit('oracle-bam','[-MapRolesToUsers
["bamuser" "No" "Yes" "cn=OracleSystemUser,dc=com" """bamuser" "No" "Yes" "cn=adminusername,dc=com"""]')
wsadmin> AdminConfig.save()

4.4.7 Using Oracle Internet Directory with Oracle BAM

Using Oracle Internet Directory with Oracle BAM on IBM WebSphere is largely the same as described in Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite. The user OracleSystemUser must exist in the LDAP server. In addition, you must create user/group mappings for Oracle BAM on IBM WebSphere.

For instructions, see Section 4.4.6.3, "Creating User/Group Mappings for Oracle BAM on IBM WebSphere."

4.4.8 Configuring Enterprise Message Sources to Connect to Remote JMS Queue/Topics

For Enterprise Message Sources (EMS) on Oracle BAM Server to look up JMS resources hosted on a remote provider, you must first set up the trust between the local IBM WebSphere server (where Oracle BAM is deployed) and the remote IBM WebSphere server (where the JMS provider is configured). Then you set up the JMS resource on the remote server by creating a service integration bus, a JMS topic connection factory, and a JMS topic.

To connect to a remote JMS queue/topic from EMS:

1. Set up the trust between the remote IBM WebSphere instance and the local IBM WebSphere instance. For instructions, see Section 4.4.5, "Configuring Trusted Domains."

2. On the remote IBM WebSphere instance, log in to the IBM WebSphere Administrative Console.

3. To create a service integration bus, follow these steps:

1. In the navigator panel, expand Service integration. Click Buses, then click New.

2. Enter a name for your new bus (for example, MyBus).
Note that this name should be different from the bus name in your local IBM WebSphere instance.

3. Deselect Bus security.

4. Click Next, then click Finish.

5. On the Buses page, click the bus name you just created.

6. On the Configuration tab, Topology section, click Bus members then click Add.

7. Choose the server to add to the bus from the dropdown list (for example, JrfNode:JrfServer).

8. Click Next, accepting all default values until you get to the Summary page, then click Finish.

4. To create a JMS topic connection factory, follow these steps:

1. In the navigation panel, expand Resources > JMS.

2. Click Topic connection factories.

3. Expand Scope, then select the node and server as the scope from the dropdown list (for example, Node=JrfNode,Server=JrfServer).
The scope identifies the level to which the resource (JMS topic connection factory) is visible.

4. Click New, then select Default messaging provider as the provider that supports the topic connection factory instance, and click OK.

5. In the Administration section of the Configuration page, enter a display name for the resource (for example, myNewTopicCF) and the JNDI name for the resource (for example, jms/myNewTopicCF).In the Connection section, from the Bus name dropdown list, select the bus to connect to (for example, MyBus).
This is the service integration bus that the connection factory is used to create connections to.

6. Enter the name of the target that is used to determine the messaging engine (for example, JrfNode.JrfServer).
This is the bus member (server) you added in step 3g above.

7. Select Bus member name as the type from the Target Type dropdown list.

8. In the Provider endpoints box, enter <yourhostname>:7277: as the endpoint used to connect to a bootstrap server, then click OK.

5. To create a JMS topic, follow these steps:

1. In the navigator panel, expand Resources > JMS.

2. Click Topics.

3. Expand Scope, then select the node and server as the scope from the dropdown list (for example, Node=JrfNode,Server=JrfServer).

4. Click New, then select Default messaging provider as the provider that supports the topic destination instance, and click OK.

5. In the Administration section of the Configuration page, enter a display name for the resource (for example, myNewTopic) and the JNDI name for the resource (for example, jms/myNewTopic).In the Connection section, from the Bus name dropdown list, select the bus hosting the topic (for example, MyBus).

6. From the Topic space dropdown list, select Create Service Integration Bus destination.

7. Enter a name for the topic space and click Next, then click Finish.
The topic space name you created should now be listed in the Topic space dropdown list.

8. Click OK.

6. Save to the master configuration. Restart the server.

7. In Oracle BAM Architect on the local IBM WebSphere instance, create a new EMS definition using the remote provider URL, the remote connection factory (for example, jms/myNewTopicCF) and the remote topic (for example, jms/MyNewTopic) you created.

4.4.9 Using Oracle BAM Data Controls

Creating and using Oracle BAM data controls in Oracle JDeveloper is largely the same as described in Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite. Note, however, the exceptions described in Section 4.4.9.1, "Exceptions in JDeveloper."

When deploying an Oracle ADF application that uses Oracle BAM data controls, make sure you deploy the application to an IBM WebSphere application server where ADF shared libraries are available. Before deploying, the properties of the application server connection to IBM WebSphere created in JDeveloper must include the parameters as described in Section 4.4.9.2, "Application Server Connection Parameters."

4.4.9.1 Exceptions in JDeveloper

A few exceptions must be noted before using Oracle BAM data controls in JDeveloper. They are:

1. Copy the JAR files in Table 4-5 from IBM WebSphere to the following Oracle JDeveloper directory:

JDEV_HOME/jdeveloper/was

Table 4-5 IBM WebSphere JAR Files to Copy and their Locations

JAR File to Copy

Location of JAR File on IBM WebSphere

com.ibm.ws.admin.client_7.0.0.0.jar

WAS_HOME/runtimes

com.ibm.ws.ejb.thinclient_7.0.0.jar

WAS_HOME/runtimes

com.ibm.ws.jpa.thinclient_7.0.0.jar

WAS_HOME/runtimes

com.ibm.ws.orb_7.0.0.jar

WAS_HOME/runtimes

ejb3exceptions.jar

WAS_HOME/runtimes

ibmorb.jar

WAS_HOME/java/jre/lib

oracle.webservices.standalone.client.jar

MW_HOME/oracle_common/modules/oracle.webservices_11.1.1

tools.jar

WAS_HOME/java/lib

wsclient_extended.jar

MW_HOME/oracle_common/webservices

2. Add the BAMCommonConfig.xml file to JDEV_HOME/jdeveloper/jdev/extensions/oracle.bam.jar.
Note that oracle.bam.jar is available only after you have installed soa-jdev-extension.zip.

BAMCommonConfig.xml should be added to the config directory in the root directory of the JAR file.

The BAMCommonConfig.xml file should contain the following properties:

<ServerPlatform>websphere</ServerPlatform>
<ServerName>HOSTNAME</ServerName>
<ServerPort>BAMSERVERBOOTSTRAPADDRESS</ServerPort>

For example:

<ServerPlatform>websphere</ServerPlatform>
<ServerName>myserver</ServerName>
<ServerPort>2801</ServerPort>

4.4.9.2 Application Server Connection Parameters

At runtime, Oracle BAM data controls in an Oracle ADF application use the Oracle BAM connection to connect to Oracle BAM Server on IBM WebSphere. Deploying an Oracle ADF application to IBM WebSphere is largely the same as deploying an ADF application to Oracle WebLogic Server. Note, however, that you must deploy the application to an IBM WebSphere application server where ADF shared libraries are available (for example, OracleAdminServer on IBM WebSphere ND). To enable this, certain parameters must be correctly set in the JDeveloper deployment profile for the application.

When you create the application server connection to IBM WebSphere in JDeveloper, on the Configuration page of the Create Application Server Connection wizard, make sure the parameters are properly set as shown in Table 4-6.

Table 4-6 Configuration Parameters for Server Connection

Parameter

Description

SOAP Connector Port

Port number of the host used to connect to the server for deployment, as defined in <SOAP_CONNECTOR_ADDRESS> on the IBM WebSphere Administrative Console.

Server Name

Name of server (as defined in IBM WebSphere) where the application is deployed.

Target Node

Name of the node (as defined in IBM WebSphere) where the application is deployed.

Target Cell

Name of the cell (as defined in IBM WebSphere) where the application is deployed.

Then on the JMX page of the Create Application Server Connection wizard, make sure the RMI port parameter is properly set as shown in Table 4-7.

Table 4-7 JMX Parameters for Server Connection

Parameter

Description

RMI Port

Port number of the IBM WebSphere application server's RMI connector port, as defined in <BOOTSTRAP_ADDRESS> on the IBM WebSphere Administrative Console.

Note:

In the IBM WebSphere Administrative Console, the locations where you can find the values of <SOAP_CONNECTOR_ADDRESS> and <BOOTSTRAP_ADDRESS>, and the runtime node and cell names, differ based on the type of IBM WebSphere Server you are using and the server where the application is being deployed (for example, soa_server1 or the deployment manager server dmgr). For more information, see Table 4-2, "Location of Application Server Connection Configuration Details", which describes where to find the information in the IBM WebSphere Administrative Console.

4.4.10 Configuring the LTPA Timeout for Active Data Reports

On IBM WebSphere, the Lightweight Third Party Authentication (LTPA) timeout value specifies the period of time during which the server credentials from another server are valid. After the timeout period expires, the server credential from the other server must be revalidated.

The default LTPA timeout value is 120 minutes, which means the user is logged out after 120 minutes. The LTPA token and associated sessions are terminated and reauthentication is needed. This would affect, for example, users who have Oracle BAM applications and active data reports open in the browser for longer than 120 minutes.

To allow users to remain logged in for more than 120 minutes without having to log in again to reauthenticate credentials, set the LTPA timeout value to a higher number.

To change the LTPA timeout value:

1. Log in to the IBM WebSphere Administrative Console.

2. In the navigation panel, expand Security and click Global Security.

3. In the Authentication section on the right, click LTPA.

4. In the LTPA timeout field, enter a value in minutes.
For example, to allow users to remain logged in for two days, enter 2880 minutes.

5 Managing Oracle WebCenter Portal on IBM WebSphere

This chapter contains information about installing, building, and managing WebCenter Portal, WebCenter Portal Framework applications, and related components on IBM WebSphere.

This chapter contains the following topics:

- Section 5.1, "Overview - Roadmaps"

- Section 5.2, "Differences Installing and Configuring Oracle WebCenter Portal on IBM WebSphere"

- Section 5.3, "Differences Developing and Deploying Portal Framework Applications on IBM WebSphere"

- Section 5.4, "Differences Managing Oracle WebCenter Portal Components on IBM WebSphere"

- Section 5.5, "Patching Oracle WebCenter Portal on IBM WebSphere from 11.1.1.7 to 11.1.1.8"

- Section 5.6, "Patching Oracle WebCenter Portal on IBM WebSphere from 11.1.1.6 to 11.1.1.8"

- Section 5.7, "Upgrading WebCenter Portal Framework Applications to 11.1.1.8"

- Section 5.8, "Restrictions Using Oracle WebCenter Portal on WebSphere"

- Section 5.9, "Troubleshooting Oracle WebCenter Portal on WebSphere"

5.1 Overview - Roadmaps

The roadmaps in this section provide an overview of the steps required to install and configure Oracle WebCenter Portal on IBM WebSphere and point you to more detailed documentation. The steps required depend on whether you want to use the out-of-the-box WebCenter Portal application or build your own Portal Framework applications using JDeveloper. For details, see:

- Getting WebCenter Portal Up and Running on IBM WebSphere

- Creating a WebSphere Cell for Portal Framework Application Deployments

Click the flow charts for more information on how to complete each step.

Note:

If you have an existing Oracle WebCenter Portal installation (11.1.1.7.0) and you want to apply the latest patch (11.1.1.8.0), follow the patching steps in Section 5.5, "Patching Oracle WebCenter Portal on IBM WebSphere from 11.1.1.7 to 11.1.1.8."

For general information about Oracle's support for IBM WebSphere Application Server, such as supported versions, see Section 1.3.1, "Supported IBM WebSphere Application Servers."

5.1.1 Getting WebCenter Portal Up and Running on IBM WebSphere

Figure 5-1 illustrates the installation and configuration process for WebCenter Portal in a simple, non-clustered environment.

Figure 5-1 Getting WebCenter Portal Up and Running on IBM WebSphere

Note:

For deployment in a clustered environment, see Section 3.4, "Configuring Oracle Fusion Middleware High Availability on IBM WebSphere" and Section 5.2.19, "Configuring WebCenter Portal or Portal Framework Applications for High Availability on IBM WebSphere."

Click the flow chart or use Table 5-1 to navigate to the appropriate documentation.

Table 5-1 Getting WebCenter Portal Up and Running on IBM WebSphere - Simple Topology

Task and link to more information

Mandatory or Optional?

Notes

Verify system requirements

Mandatory

See also, Section 2.1, "Task 1: Review the System Requirements and Certification Information."

Install and configure a supported database

Mandatory

For up-to-date information about which Oracle or IBM DB2 database versions are supported with IBM WebSphere Application Server, refer to the certification matrix on Oracle Technology Network (OTN). For details, see Section 2.1, "Task 1: Review the System Requirements and Certification Information."

Create schemas for WebCenter Portal

Mandatory

Install IBM WebSphere Application Server and create Middleware Home

Mandatory

Install Oracle WebCenter Portal

Mandatory

Install other products as required:

- Oracle WebCenter Content

- Oracle SOA Suite

- IBM HTTP Server (IHS)

Optional

Oracle WebCenter Content is mandatory for content presenter, wikis and blogs, and recommended for the documents tool and WebCenter Portal.

SOA is mandatory for worklists portal workflows.

IHS is recommended for Oracle WebCenter Content Server integration and for single sign-on (SSO) since SSO is needed to stop multiple login prompts), and is required for REST and SOA.

Create new WebSphere cell for WebCenter Portal

Mandatory

Perform general post-install tasks for WebCenter Portal:

- Set JDBC driver variables (DB2 only)

- Start the node and deployment manager

- Open WebSphere Admin console

- Start WebCenter Portal servers

Mandatory

Install and configure mandatory security components:

- Install and configure Oracle Internet Directory (OID) as an external LDAP ID store

- Configure admin user for WebCenter Portal

- Reassociate credential and policy stores

- Set cookie paths for WebCenter Portal modules

- Verify the WebCenter Portal installation

Mandatory

An external LDAP server is mandatory on IBM WebSphere.

The WebCenter Portal application requires an Oracle Internet Directory LDAP server.

Configure optional security components:

- Configure default admin user from LDAP for WSM

- Configure WSM on WebSphere

- Configure discussions admin user

- Configure activity graph engine admin user

- Configure pagelet producer admin user

- Configure user registry settings

- Configure the trust service for REST

- Configure SSL

- Configure single sign-in (SS0)

Optional

Oracle Web Services Manager (WSM)

Extend cell for Oracle WebCenter Content Server:

- Extend cell for WebCenter Content (includes Content Server)

- Configure Content Server for WebCenter Portal

- Connect WebCenter Portal to Content Server

Mandatory

Mandatory for content presenter, wikis and blogs, and recommended for the documents tools.

Install and configure back-end components for tools and services:

- Connect to analytics collector

- Connect to BPEL server

- Connect to discussion server

- Connect to events server

- Configure personalization

- Connect to presence server

- Connect to mail server

- Configure SES Search

- Configure portal workflows

- Register portlet producers

- Register pagelet producer

Optional

Mandatory for the tools and services you want to use

5.1.2 Creating a WebSphere Cell for Portal Framework Application Deployments

Figure 5-2 illustrates the installation and configuration process if you want to build your own portal applications (referred to as Portal Framework application) and deploy them in a simple, non-clustered environment.

Note:

For deployment in a clustered environment, see Section 3.4, "Configuring Oracle Fusion Middleware High Availability on IBM WebSphere" and Section 5.2.19, "Configuring WebCenter Portal or Portal Framework Applications for High Availability on IBM WebSphere."

Click the flow chart or use Table 5-2 to navigate to the appropriate documentation.

Figure 5-2 Creating a WebSphere Cell for Portal Framework Application Deployments

Note:

For deployment in a clustered environment, see Section 3.4, "Configuring Oracle Fusion Middleware High Availability on IBM WebSphere" and Section 5.2.19, "Configuring WebCenter Portal or Portal Framework Applications for High Availability on IBM WebSphere."

Click the flow chart or use Table 5-2 to navigate to the appropriate documentation.

Table 5-2 Creating a WebSphere Cell for Portal Framework Application Deployments - Simple Topology

Task and link to more information

Mandatory or Optional?

Notes

Verify system requirements

Mandatory

See also, Section 2.1, "Task 1: Review the System Requirements and Certification Information."

Install and configure a database

Mandatory

For up-to-date information about which Oracle or IBM DB2 database versions are supported with IBM WebSphere Application Server, refer to the certification matrix on Oracle Technology Network (OTN). For details, see Section 2.1, "Task 1: Review the System Requirements and Certification Information."

Create schemas for Portal Framework applications

Mandatory

Install IBM WebSphere Application Server and create Middleware Home

Mandatory

Install Oracle WebCenter Portal

Mandatory

Install other products as required:

- Oracle WebCenter Content

- Oracle SOA Suite

- IBM HTTP Server (IHS)

Optional

Oracle WebCenter Content is mandatory for content presenter, wikis and blogs, and documents tools.

SOA is mandatory for the worklists.

IHS is recommended for Oracle WebCenter Content Server integration and for single sign-on (SSO) since SSO is needed to stop multiple login prompts), and is required for REST and SOA.

Create new WebSphere cell for the Portal Framework application:

- Create a custom managed server for the Portal Framework application

- Create a custom managed server for Portlet Producer applications

Mandatory

Oracle does not recommend deploying Portal Framework applications or Portlet Producer applications to the Administration Server or any of the default managed servers created during Oracle WebCenter Portal installation.

Perform post-install tasks for WebCenter Portal Framework deployments:

- Set JDBC driver variables (DB2 only)

- Start the node and deployment manager

- Open WebSphere Admin console

- Start the managed servers

Mandatory

Install and configure mandatory security components:

- Install and configure Oracle Internet Directory (OID) as an external LDAP ID store

- Reassociate credential and policy stores

- Verify the installation

Mandatory

An external LDAP server is mandatory on IBM WebSphere.

All Portal Framework applications require an Oracle Internet Directory LDAP server.

Configure optional security components:

- Configure default admin user from LDAP for WSM

- Configure WSM on WebSphere

- Configure discussions admin user

- Configure activity graph engine admin user

- Configure pagelet producer admin user

- Configure user registry settings

- Configure the trust service for REST

- Configure SSL

- Configure single sign-in (SS0)

Optional

Oracle Web Services Manager (WSM)

Extend cell for Oracle WebCenter Content Server:

- Extend cell for Oracle WebCenter Content (includes Content Server)

- Configure Content Server for the WebCenter Portal Framework application

- Connect the Portal Framework application to Content Server

Optional

Mandatory for content presenter, wikis and blogs, and documents tool.

Configure, and connect back-end components for the Portal Framework application:

- Connect to analytics collector

- Connect to BPEL server

- Connect to discussion server

- Connect to events server

- Connect to mail server

- Connect to presence server

- Configure personalization

- Configure SES search

- Register portlet producers

- Register pagelet producer

Use JDeveloper to build and deploy Portal Framework applications.

5.2 Differences Installing and Configuring Oracle WebCenter Portal on IBM WebSphere

This section describes differences between installing and configuring Oracle WebCenter Portal install on WebLogic Server and IBM WebSphere:

- Installing Oracle WebCenter Portal Products on IBM WebSphere

- Configuring an IBM WebSphere Cell for WebCenter Portal

- Configuring an IBM WebSphere Cell for Portal Framework Applications

- Configuring an IBM WebSphere Cell for Portlet Producer Applications

- Performing General Post-install Tasks for Oracle WebCenter Portal on WebSphere

- Installing and configuring mandatory security components:

- Installing External LDAP ID Store for WebCenter Portal or Portal Framework Applications

- Configuring an Admin User for WebCenter Portal

- Configuring an Admin User for the Discussions Server

- Configuring an Admin User for Pagelet Producer and Activity Graph Applications

- Reassociating the Credential and Policy Store

- Setting Cookie Paths for WebCenter Portal and Portal Framework Application Modules Post Deployment

- Verifying a WebCenter Portal Installation on IBM WebSphere

- Optional security configuration:

- Configuring User Registry Settings for External LDAP ID Store

- Configuring Trust Service Information for the REST Service

- Installing and Configuring IBM HTTP Server

- Configuring Single Sign-On for WebCenter Portal or Portal Framework Applications

- Configuring SSL for WebCenter Portal or Portal Framework Applications

- Cloning Oracle WebCenter Portal Installations on IBM WebSphere

- Configuring WebCenter Portal or Portal Framework Applications for High Availability on IBM WebSphere

5.2.1 Installing Oracle WebCenter Portal Products on IBM WebSphere

Use the Oracle WebCenter Portal installer to install the binaries for all Oracle WebCenter Portal products on IBM WebSphere. The instructions are similar to those provided for Oracle WebLogic Server in the "Installing Oracle WebCenter Portal" section in Oracle Fusion Middleware Installation Guide for Oracle WebCenter Portal.

There are a few differences when installing on IBM WebSphere. For details see Section 2.5.2, "Special Instructions When Installing Oracle Fusion Middleware with IBM WebSphere."

5.2.2 Configuring an IBM WebSphere Cell for WebCenter Portal

To configure an IBM WebSphere cell for the out-of-the-box WebCenter Portal application:

1. Start the IBM WebSphere version of Oracle Fusion Middleware Configuration Wizard:

WCP_ORACLE_HOME/common/bin/was_config.sh

For details, see the "Using the Configuration Wizard" section in the Oracle Fusion Middleware Configuration Guide for IBM WebSphere Application Server.

2. Select the appropriate configuration option, such as Create and Configure Cell, click Next.

3. On the Add Products to Cell screen:

1. Select the Oracle WebCenter Portal product you want to install, such as the Discussions Server, Portlet Producers, Analytics Collector.

Note:

Do not select all the WebCenter Portal products you want to configure at once. Choose a single product (with all of its dependent products), complete the wizard, and then repeat step 3 to configure other product groups.

2. Click Next, and complete the wizard.

For details, see the "Selecting Oracle WebCenter Portal Products for Configuration" section in Oracle Fusion Middleware Installation Guide for Oracle WebCenter Portal.

4. Repeat step 3 to configure another WebCenter Portal product, if required.

5.2.3 Configuring an IBM WebSphere Cell for Portal Framework Applications

If you want to deploy Portal Framework applications built using JDeveloper to an IBM WebSphere application server you must configure a suitable server using Oracle WebCenter Portal's Custom Portal Template.

For Custom Portal Template to display in the Oracle Fusion Middleware Configuration Wizard you need to set a system property before you run the Configuration Wizard:

Note:

This step is not required if you are configuring a cell for the out-of-the-box application WebCenter Portal.

1. Set the JVM_ARG environment variable:

setenv CONFIG_JVM_ARGS -DTemplateCatalog.enable.selectable.all=true

2. Start the IBM WebSphere version of Oracle Fusion Middleware Configuration Wizard using: WCP_ORACLE_HOME/common/bin/was_config.sh.
For details, see the "Using the Configuration Wizard" section in Oracle Fusion Middleware Configuration Guide for IBM WebSphere Application Server.

3. On the Select Domain Source screen, select Base this domain on an existing template, and click Browse to locate the template:

- On UNIX operating systems, the template is located at:

WCP_ORACLE_HOME/common/templates/was/oracle.wc_custom_portal_template_11.1.1.jar

- On Windows operating systems, the template is available here:

WCP_ORACLE_HOME\common\templates\was\oracle.wc_custom_portal_template_11.1.1.jar

For details, see the "Creating a Portal Managed Server for Portlet Producer Applications" section in Oracle Fusion Middleware Installation Guide for Oracle WebCenter Portal.

5.2.4 Configuring an IBM WebSphere Cell for Portlet Producer Applications

If you want to deploy Portlet Producer applications built using JDeveloper to an IBM WebSphere application server you must configure a suitable server using Oracle WebCenter Portal's Custom Services Producer Template.

For Custom Services Producer Template to display in the Oracle Fusion Middleware Configuration Wizard you need to set a system property before you run the Configuration Wizard:

Note:

This step is not required if you are configuring a cell for the out-of-the-box application WebCenter Portal.

1. Set the JVM_ARG environment variable:

setenv CONFIG_JVM_ARGS -DTemplateCatalog.enable.selectable.all=true

2. Start the IBM WebSphere version of Oracle Fusion Middleware Configuration Wizard:

WCP_ORACLE_HOME/common/bin/was_config.sh

For details, see the "Using the Configuration Wizard" section in Oracle Fusion Middleware Configuration Guide for IBM WebSphere Application Server.

3. On the Select Domain Source screen, select Base this domain on an existing template, and click Browse to locate the template:

- On UNIX operating systems, the template is located at:
WCP_ORACLE_HOME/common/templates/was/oracle.wc_custom_services_producer_template_11.1.1.jar

- On Windows operating systems, the template is available here:
WCP_ORACLE_HOME\common\templates\was\oracle.wc_custom_services_producer_template_11.1.1.jar

For details, see the "Creating a Portal Managed Server for Portlet Producer Applications" section in Oracle Fusion Middleware Installation Guide for Oracle WebCenter Portal.

5.2.5 Performing General Post-install Tasks for Oracle WebCenter Portal on WebSphere

This section includes the following topics:

- Setting JDBC Driver Variables (DB2 only)

- Starting the Node Agent and Deployment Manager

- Opening IBM WebSphere Administrative Console

- Starting WebCenter Portal Servers

5.2.5.1 Setting JDBC Driver Variables (DB2 only)

If you are using a DB2 database, you must set the following environment variables to include the full path to db2jcc4.jar, db2jcc_license_cu.jar and db2jcc_license_cisuz.jar:

- DB2_JCC_DRIVER_NATIVEPATH

- DB2_JCC_DRIVER_PATH

You must do this immediately after installing Oracle WebCenter Portal products using the Configuration Wizard. If you do not do this, all DB2 connection tests will fail.

If you are deploying your own Portal Framework applications to IBM WebSphere, you must also set these two environment variables at the Deployment Manager scope. If you do not, the JDeveloper MDS deployment wizard cannot query or allow configuration to DB2 back-end MDS repositories, and this causes issues at application runtime.

Note:

Some additional steps are required to enable the MDS schema to run on a DB2 database. If you have not done so already, read the "Notes for Using an IBM DB2 Database for the MDS Schema" section in Oracle Fusion Middleware System Requirements and Specifications.

To set DB2 driver environment variables:

1. Log in to the IBM WebSphere Administrative Console:

https://host:port/ibm/console

2. Navigate to Environment > WebSphere variables

3. Set DB2 driver variables for the server node:

1. From the Scope drop down, select the node containing your Oracle WebCenter Portal installation.

2. Locate and set the following JBDC variables:
DB2_JCC_DRIVER_NATIVEPATH

DB2_JCC_DRIVER_PATH

Specify the location of the required DB2 drivers (db2jcc4.jar, db2jcc_license_cu.jar and db2jcc_license_cisuz.jar).

Refer to your IBM WebSphere documentation to find the location of these drivers. Look for the topic entitled "Data source minimum required settings for DB2 with the application server" or similar.

3. Save both settings.

4. If you are using a cluster, repeat step 3 for each node in the cluster.

5. To test the DB2 connection:

1. Navigate to Resources > JDBC >Data sources.

2. Select a data source in the table, and click Test Conection.

6. If you are deploying your own Portal Framework applications to IBM WebSphere, repeat step 3 at the Deployment Manager scope.

1. From the Scope drop down, select the Node=ManagerNode, Server=dmgr scope where ManagedNode maps to the Manage Node of your installation.

2. Create and set JBDC variables, as above:
DB2_JCC_DRIVER_NATIVEPATH

DB2_JCC_DRIVER_PATH

3. Save both settings.

5.2.5.2 Starting the Node Agent and Deployment Manager

After using the Configuration Wizard to install and configure Oracle WebCenter Portal products on IBM WebSphere, start up the deployment manager for the cell and the application node as described in Section 2.7, "Task 7: Start the IBM WebSphere Servers."

The IBM WebSphere Administration Console is accessible after starting the node and deployment manager.

5.2.5.3 Opening IBM WebSphere Administrative Console

IBM WebSphere Administrative Console provides a web-based interface for managing the IBM WebSphere environment. The IBM WebSphere Administrative Console is similar to Oracle WebLogic Server Administration Console, that is, while you cannot use the console to manage Oracle WebCenter Portal products, you can use the console to monitor and manage the cell and the servers on which Oracle WebCenter Portal and other Oracle Fusion Middleware products are deployed. For more information, see Section 3.1.1, "Using the WebSphere Administrative Console."

5.2.5.4 Starting WebCenter Portal Servers

After installing and configuring Oracle WebCenter Portal on IBM WebSphere and starting both the deployment manager and node, you can start the Oracle WebCenter Portal servers using the IBM WebSphere Administrative Console or Fusion Middleware Control. For details, see Section 2.7, "Task 7: Start the IBM WebSphere Servers."

The default names for Oracle WebCenter Portal servers in a WebCenter Portal installation are:

- WC_Spaces

- WC_Collaboration

- WC_Portlet

- WC_Utilities

The default names for Oracle WebCenter Portal servers for Portal Framework applications and portlet producer deployments are:

- WC_CustomPortal (Portal Framework applications)

- WC_CustomServicesProducer (Portlet producer applications)

5.2.6 Installing External LDAP ID Store for WebCenter Portal or Portal Framework Applications

An LDAP server is not automatically installed and configured when you install Oracle WebCenter Portal products on IBM WebSphere. Before you can configure Oracle WebCenter Portal, you must install and configure Oracle Internet Directory (OID) as the external LDAP ID store for WebCenter Portal or your Portal Framework applications. For instructions on how to set up external LDAP ID stores, such as Oracle Internet Directory, see Section 9.1, "IBM WebSphere Identity Stores."

Note:

WebCenter Portal and all Portal Framework applications must use Oracle Internet Directory (OID).

Once the LDAP ID store is set up, you must set the CONNECTION_POOL_CLASS property in cell's jps-config.xml. For details, Section 5.2.6.1, "Setting the Connection Pool on IBM WebSphere When Connecting to an External LDAP Server."

5.2.6.1 Setting the Connection Pool on IBM WebSphere When Connecting to an External LDAP Server

To avoid excessive database connections, you must add the following <serviceInstance> entry to the cell's jps-config.xml:

<property name="CONNECTION_POOL_CLASS" value="oracle.security.idm.providers.stdldap.JNDIPool"/>

1. Modify jps-config.xml using a text editor:

1. Open the following file:

WAS_HOME/profiles/dmgr_profile_name/
config/cells/myCell/fmwconfig/jps-config.xml

Where Dmgr01 maps to the Deployment Manager name, and myCell maps to the cell name.

2. Specify the following:

<serviceInstance name="idstore.ldap.0" provider="idstore.ldap.provider">
<property name="subscriber.name" value="dc=us,dc=oracle,dc=com"/>
<property name="CONNECTION_POOL_CLASS" value="oracle.security.idm.providers.stdldap.JNDIPool"/>
<property name="bootstrap.security.principal.key" value="bootstrap_idstore"/>
<property name="idstore.type" value="OID"/>
<property name="ldap.url" value="ldap://example.com:3060"/>
<property name="bootstrap.security.principal.map" value="BOOTSTRAP_JPS"/>
<property name="user.login.attr" value="mail"/>
<property name="username.attr"  value="mail"/>
<extendedProperty>
<name>user.search.bases</name>
<values>
<value>cn=Users,dc=us,dc=oracle,dc=com</value>
</values>
</extendedProperty>
<extendedProperty>
<name>group.search.bases</name>
<values>
<value>cn=Groups,dc=us,dc=oracle,dc=com</value>
</values>
</extendedProperty>
</serviceInstance>

2. Restart all the servers.

5.2.7 Configuring an Admin User for WebCenter Portal

After installing Oracle WebCenter Portal products on IBM WebSphere and setting up your LDAP ID store, you must manually grant the WebCenter Portal administrator role to a user in the ID store.

You can configure the administrative user through Fusion Middleware Control or use the Opss.grantAppRole wsadmin command as shown in this example:

Opss.grantAppRole(appStripe='webcenter', appRoleName='s8bba98ff_4cbb_40b8_beee_296c916a23ed#-#Administrator',principalClass='weblogic.security.principal.WLSUserImpl', principalName='myadmin')

For more information, see the "Granting the WebCenter Portal Administrator Role" section in Oracle Fusion Middleware Administering Oracle WebCenter Portal.

Note:

Oracle Fusion Middleware Administering Oracle WebCenter Portal describes how to run the equivalent WebLogic WLST command. The way you run IBM WebSphere wsadmin commands is slightly different to WLST, so if you are new to wsadmin, refer to Section 5.4.1, "Running Oracle WebCenter Portal wsadmin Commands."

5.2.8 Configuring an Admin User for the Discussions Server

If you chose to install Oracle WebCenter Portal's Discussion Server while installing Oracle WebCenter Portal on WebSphere you must configure an administrative user for the discussions server using the wsadmin command WebCenter.addDiscussionsServerAdmin.

For example:

WebCenter.addDiscussionsServerAdmin(appName='owc_discussions_11.1.1.4.0',name='myadmin',type='USER')

Where:

- myadmin is a user in the identity store with administrative privileges in the portal application.

- owc_discussions_11.1.1.4.0 is the name of the discussion server application installed on IBM WebSphere.

For information on how to run WebCenter Portal wsadmin commands, see Section 5.4.1, "Running Oracle WebCenter Portal wsadmin Commands".

See also, "addDiscussionsServerAdmin" in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

Note:

After adding an admin user using wsadmin you must restart the WC_Collaboration server.

5.2.9 Configuring an Admin User for Pagelet Producer and Activity Graph Applications

If you chose to install Oracle WebCenter Pagelet Producer or Oracle WebCenter Activity Graph Engines while installing Oracle WebCenter Portal on WebSphere you must assign administrative permissions to an appropriate user or a group through the following roles:

Application Name

Admin Role

pageletproducer

EnsembleAdmin

activitygraph-engines

activity-graph-admins

To configure administrators:

1. Log in to the IBM WebSphere Administrative Console.

2. Navigate to Applications > Application Types > WebSphere enterprise applications.

3. Configure an administrative user for the Pagelet Producer admin application:

1. Select pageletproducer.

2. Click Security role to user/group mapping.

3. Select the EnsembleAdmin role and the click either Map Users... or Map Groups... to assign one or more users/groups to this admin role.

4. Click OK.

4. Configure administrative user for the Activity Graph Engine application:

1. Select activitygraph-engines_11.1.1.6.0.

2. Click Security role to user/group mapping.

3. Select the activity-graph-admins role and the click either Map Users... or Map Groups... to assign one or more users/groups to this admin role.

4. Click OK.

5. Restart WC_Portlet (pageletproducer) and WC_Utilities (activitygraph-engines), as required.

5.2.10 Reassociating the Credential and Policy Store

When you install Oracle WebCenter Portal products on IBM WebSphere Application Server, you must reassociate your credential and policy store with an external LDAP (either Oracle Internet Directory 11gR1 or 10.1.4.3), or an Oracle database. For detailed steps see the "Configuring the Policy and Credential Store" section in Oracle Fusion Middleware Administering Oracle WebCenter Portal.

5.2.11 Setting Cookie Paths for WebCenter Portal and Portal Framework Application Modules Post Deployment

By default, applications deployed on IBM WebSphere have their cookie path set to "/". This default setting means that all applications on the same IBM WebSphere cell share the same session identifier and therefore, as you move between applications, the session identifier value for the previous application is overwritten. For example, if you access WebCenter Portal (/webcenter), access Enterprise Manager (/em), and then move back to WebCenter Portal (/webcenter) you are prompted to log in to WebCenter Portal again because the previous session identifier value is overwritten at the point when you log in to Enterprise Manager (/em).

To avoid session invalidation as you move between applications, specify a unique cookie path for each application:

1. Log in to the IBM WebSphere Administrative Console.

https://host:port/ibm/console

2. Navigate to Applications > WebSphere enterprise applications.

3. Select the name of your application from the list.
For example, the name of the WebCenter Portal application is webcenter.

4. Click Manage Modules (Figure 5-3).

Figure 5-3 Enterprise Applications - Manage Modules

A list of modules displays (Figure 5-4).

Figure 5-4 List of Modules to Manage

5. Set the cookie path for each module listed in Table 5-3:

Table 5-3 Cookie Paths for Oracle WebCenter Portal Modules

Module Name

Cookie Path

spaces-was.war

/webcenter

webcenter-rest-was.war

/rest

search-crawler-was.war

/rsscrawl

webcenter-rss-was.war

/rss

sharepoint-servlet-was.war

/wcsdocs

1. Click the module name, for example spaces-was.war (WebCenter Portal application).

2. Click Session Management (Figure 5-5).

Figure 5-5 Configure Module

3. Select the Enable cookies check box (Figure 5-6).

Figure 5-6 Configure Module - Enable Cookies

4. Click Enable cookies link.

5. Enter the appropriate cookie path for the selected module (Figure 5-7). For details, see Table 5-3.

Figure 5-7 Configure Module - Set Cookie Path

6. Click OK and then Save.

7. Select the Override session management check box.

8. (In a clustered environment only) Select the Distributed environment settings link, select Memory-to-memory replication, and then click OK.

9. Click OK.

10. Repeat steps a through j for each module listed in Table 5-3.

6. Restart the server on which the WebCenter Portal application is deployed.

1. Navigate to Servers > WebSphere Application servers.

2. Select the WC_Spaces check box, and click Restart (Figure 5-8).

Figure 5-8 Restart WC_Spaces Server

5.2.12 Verifying a WebCenter Portal Installation on IBM WebSphere

To verify your WebCenter Portal installation, start your browser and enter the following URLs:

- To access the IBM WebSphere Administration Server console:

https://dmgr_server_host:WC_Adminhost_port/ibm/console

You will be prompted for the username and password credentials that you specified on the Specify Deployment Manager Information screen of the Configuration Wizard.

To discover the port numbers required to access individual servers, such as WC_Spaces, OracleAdminServer, and so on, navigate to the server in the IBM WebSphere Administration Server console, select the Ports link and look for "WC_defaulthost". See also, Section 3.1.1.2, "Locating the Port Number and URL of the IBM WebSphere Administrative Console."

- To access Enterprise Manager:

http://OracleAdminServer_host:OracleAdminServer_port/em

- To access the out-of-the-box WebCenter Portal application:

http://WC_Spaces_server_host:WC_Spaces_server_port/webcenter

The default port number for WebCenter Portal is 8888.

- To access the pagelet producer:

http://WC_Portlet_server_host:WC_Portlet_server_port

The default port number for pagelet producer is 8889.

To access the pagelet producer console:

http://WC_Portlet_server_host:WC_Portlet_server_port/pageletadmin

- To access the analytics collector, activity graph engines, and personalization:

http://WC_Utilities_server_host:WC_Utilities_server_port/activitygraph-engines

To access activity graph engines:

http://WC_Utilities_server_host:Wc_Utilities_server_port/activitygraph-engines/Login.jsp

To access personalization:

http://WC_Utilities_server_host:Wc_Utilities_server_port/wcps/api/property/resourceIndex

The default port number for analytics collector, activity graph engines, and personalization is 8891.

- To access OmniPortlet and Web Clipping portlets:

http://WC_Portlet_server_host:WC_Portlet_server_port/portalTools/

The default port number for portlets is 8889.

- To access the discussions server:

http://WC_Collaboration_server_host:WC_Collaboration_server_port/owc_discussions

The default port number for the discussions server is 8890.

5.2.13 Configuring User Registry Settings for External LDAP ID Store

Several additional user registry settings may be required after configuring the external LDAP ID store:

- Enable nested user group searching - IBM WebSphere supports nested user groups however, they are not automatically included in LDAP searches as enabling them impacts performance. If your Oracle WebCenter Portal installation utilizes nested user groups you can enable this feature.

- Configure the user login attribute - If required, you can set the user login attribute to an attribute other than cn. For example, if set to mail, LDAP searches utilize the username that is used to log in to WebCenter Portal or Portal Framework application.

To configure these settings:

1. Log in to the IBM WebSphere Administrative Console.

2. Navigate to Global security > Standalone LDAP registry.

3. Under Additional properties, click Advanced Lightweight Directory Access Protocol (LDAP) user registry settings.

4. Specify the user login attribute in User filter and User ID map (Figure 5-9).
For example, to configure the mail attribute, enter:

- User filter - (&(mail=%v)(objectclass=inetOrgPerson))

- User ID map - inetOrgPerson:mail

Figure 5-9 Advanced LDAP User Registry Settings

5. Select the Perform a nested group search check box.

6. Click OK.

7. Modify jps-config.xml using a text editor:

1. Open the MW_HOME/user_projects/domains/my_domain/config/fmwconfig/jps-config.xml

2. Specify the user login attribute in the LDAP properties user.login.attr and username.attr to mail.
For example, to configure the mail attribute, enter:

<serviceInstance provider="idstore.ldap.provider" name="idstore.ldap.0">
<!-- existing props ... ->
<property name="user.login.attr" value="mail"/>
<property name="username.attr"  value="mail"/>
<extendedProperty>
... ...
</extendedProperty>
</serviceInstance>

3. Restart all the servers.

5.2.14 Configuring Trust Service Information for the REST Service

This section describes how to configure an identity asserter for the REST service.

1. Login to the IBM WebSphere Administrative Console.

2. Navigate to Security > Global Security.

3. In the Authentication section, expand Web and SIP security, and then click Trust Association.

4. Select the Enable trust association check box and save the changes.

5. In the Additional Properties section, click Interceptors.

6. Click New.

7. For Interceptor class name, enter the fully qualified Trust Service TAI name:

oracle.security.jps.was.providers.trust.TrustServiceAsserterTAI

The Trust Association Interceptor (TAI) class is in the jps-was.jar file located in the standard Oracle Platform Security Services (OPSS) jar distribution directory.

8. Save the changes (Figure 5-10).

Figure 5-10 Configuring Trust Information

5.2.15 Installing and Configuring IBM HTTP Server

This section describes how to install and configure an IBM HTTP Server to front end the WebSphere Application Server hosting Oracle WebCenter Portal. An IBM HTTP server is required to implement single sign-on for WebCenter Portal or Portal Framework applications and also for high availability environments. For more information about using the IBM HTTP Server, see:

- Section 5.2.16, "Configuring Single Sign-On for WebCenter Portal or Portal Framework Applications"

- Section 5.2.19, "Configuring WebCenter Portal or Portal Framework Applications for High Availability on IBM WebSphere"

To install and configure an IBM HTTP Server:

1. Install the IBM HTTP Server, and take note of the Server Name and the HTTP Port.
For detailed installation instruction, refer to IBM HTTP Server documentation. See also, Section 1.4, "Documentation Resources for Using Oracle Fusion Middleware on IBM WebSphere."

2. Configure the HTTP Server, specifying the server name and port you specified in step 1.

1. Log in to the IBM WebSphere Administrative Console.

2. Navigate to Servers >Web Servers > New.

3. Enter the Server name that you defined during IBM HTTP server installation. For example, webserver1 (Figure 5-11).
Ensure that the server type is IBM HTTP Server.

Figure 5-11 Configure HTTP Server - Server Name

4. Click Next

5. Enter the port that you defined during HTTP server installation. For example 8080 (Figure 5-12).

Figure 5-12 Configure HTTP Server - Port

6. Click Next and Finish.

3. Create a virtual host entry to enable access to the port specified in step 1.
If the port is not accessible, error messages similar to that shown display:

SRVE0255E: A WebGroup/Virtual Host to handle /webcenter/ has not been defined.

SRVE0255E: A WebGroup/Virtual Host to handle host:8080 has not been defined.

1. In the WebSphere Administrative Console, navigate to Environment, Virtual Hosts> default_host> Host Aliases (Figure 5-13).

Figure 5-13 Configure Virtual Host -default_host

2. On the Host Aliases page, select New.

3. For Port, enter the port number specified in step 1 (Figure 5-14).
Leave Host Name as *.

Figure 5-14 Configure default_host - Port

4. Generate and propagate the Web Server plug-in that coordinates the wiring between the WebSphere Application Server and the HTTP Server front end.
Note: You must repeat this step each time there is a change to applications deployed on the servers.

1. In WebSphere Administrative Console, navigate to Servers >Web Servers and select the HTTP server that you created.

2. Click Generate Plug-in (Figure 5-15).

Figure 5-15 Configure HTTP Server - Generate Plug-in

3. Click Propagate Plug-in (Figure 5-16).

Figure 5-16 Configure HTTP Server - Propagate Plug-in

5. Update the Web Server httpd.conf file to refer to the correct plug-in file:

1. Click the Web Server.

2. Next to Configuration file name, click Edit.

3. Scroll down to see the property WebSpherePluginConfig and confirm that it is pointing to the plugin-cfg.xml file under this Web Server's directory name (for example, /IHS_HOME/Plugins/config/<WebServerName>/plugin-cfg.xml).

4. Click Apply and then OK.

5. Click OK again to return to the Web Servers page.

6. Click Start.
Note: If the instance is already running, click Stop, then Start (Figure 5-17).

Figure 5-17 Configure HTTP Server - Start

7. Restart the WebSphere server on which the WebCenter Portal application is deployed.

8. Restart the HTTP server to enable the virtual host and Web Server plug-in.

The WebCenter Portal application should now be accessible on the HTTP Server port (Figure 5-18).

Figure 5-18 HTTP Server Port - Application Accessible

5.2.16 Configuring Single Sign-On for WebCenter Portal or Portal Framework Applications

This section includes the following topics:

- Section 5.2.16.1, "Configuring OAM 11g Single Sign-On"

- Section 5.2.16.2, "Configuring WebCenter Portal and Portal Framework Applications for Single Sign-On"

5.2.16.1 Configuring OAM 11g Single Sign-On

This section describes how to set up single sign-on for Oracle WebCenter Portal installations on IBM WebSphere, using Oracle Access Manager (OAM) 11g (Figure 5-19).

Note:

WebCenter Portal or Portal Framework applications deployed on IBM WebSphere support Oracle Access Manager (OAM) 11g. Earlier versions, such as Oracle Access Manager (OAM) 10g, are not supported on IBM WebSphere.

Figure 5-19 Configuring OAM Single Sign-On for Oracle WebCenter Portal Installations on IBM WebSphere

Oracle Access Manager Identity Assertion Provider for IBM WebSphere can be used to provide authentication and single sign-on with Oracle Access Manager (OAM) 11g. Chapter 11, "Managing OAM Identity Assertion on IBM WebSphere" describes the Oracle Access Manager Identity Assertion Provider is detail. The purpose of this section is to guide you through single sign--on configuration requirements for WebCenter Portal and Portal Framework applications. The main steps are:

- Install Oracle Access Manager 11g

- Install and configure IBM HTTP Server

- Register the WebGate agent

- Restart IHS

- Install WebGate 10g

- Configure IBM WebSphere for OAM single sign-on

- Configure logout details

- Configure WebCenter Portal or Portal Framework applications to require certificate based authentication and SSO synchronization filter

- Configure other Oracle WebCenter Portal components for single sign-on

To set up single sign-on for WebCenter Portal or Portal Framework, using OAM 11g:

1. Install Oracle Access Manager 11g.
See Chapter 11, "Managing OAM Identity Assertion on IBM WebSphere."

2. Install and configure IBM HTTP Server.
See Chapter 5, "Installing and Configuring IBM HTTP Server."

3. Register the WebGate agent on the machine where OAM 11g is installed before installing WebGate on IBM HTTP Server.
You can register the WebGate agent using the OAM Console or, if you have administrator rights, you can use the oamreg tool. Follow the steps below to register the WebGate agent using the oamreg tool in inband mode.

1. Navigate to the following directory on the Oracle Access Manager server:

IDM_HOME/oam/server/rreg/client/

2. On the command line, untar RREG.tar.gz

gunzip RREG.tar.gz
tar -xvf RREG.tar

The tool used to register the agent is located in the following location:

(UNIX) RREG_HOME/bin/oamreg.sh
(Windows) RREG_HOME\bin\oamreg.bat

Note:

RREG_HOME is the directory where you extracted the contents of RREG.tar.gz/rreg.

3. Set the following environment variables in the oamreg.sh or oamreg.bat script:
OAM_REG_HOME - Set this variable to the absolute path to the directory where you extracted the contents of RREG.tar/rreg.

JDK_HOME - Set this variable to the absolute path to the directory where Java/JDK is installed on your machine.

4. Change directories to RREG_HOME/input and copy the following files to this location:

WCP_ORACLE_HOME/webcenter/scripts/webcenter.oam.conf
SOA_ORACLE_HOME/soa/prov/soa.oam.conf
WC_CONTENT_ORACLE_HOME/common/security/oam.conf

5. Create a new file named WebCenterOAM11gRequest.xml to serve as a parameter file to the oamreg tool.
Copy and paste the example below, and then replace the contents within $$webtier..$$ with your WebTier host and port IDs, and $$oam...$$ with the OAM host and administration server port.

<?xml version="1.0" encoding="UTF-8"?>

<!--
Copyright (c) 2009, 2010, Oracle and/or its affiliates. All rights reserved.
NAME: OAMRequest.xml - Template (with all options) for OAM Agent Registration Request file
DESCRIPTION: Modify with specific values and pass file as input to the tool.
-->
<OAMRegRequest>
<serverAddress>http://$$oamhost$$:$$oamadminserverport$$</serverAddress>
<hostIdentifier>$$webtierhost$$_webcenter</hostIdentifier>
<agentName>$$webtierhost$$_webcenter</agentName>
<agentBaseUrl>http://$$webtierhost$$:$$webtierport$$</agentBaseUrl>
<applicationDomain>$$webtierhost$$_webcenter</applicationDomain>
<autoCreatePolicy>true</autoCreatePolicy>
<primaryCookieDomain>example.com</primaryCookieDomain>
<logOutUrls>
<url>/oamsso/logout.html</url>
</logOutUrls>
</OAM11GRegRequest>

6. Change to the RREG_Home directory.

7. Run the following command:

RREG_HOME/bin/oamreg.sh inband input/WebCenterOAM11gRequest.xml

When prompted for agent credentials enter your OAM administrator credentials.

Enter your WebGate password.

Enter yes when asked whether you want to import a URIs file. Specify the full path to the RREG_HOME/input/webcenter.oam.conf file you copied there earlier.

You should see output like that below indicating that registration has been successful:

----------------------------------------
Request summary:
OAM11G Agent Name:example_webcenter
Base URL: http://example.com:8080
URL String:example_webgate
Registering in Mode:inband
Your registration request is being been sent to the Admin server at: http://example.com:7001
----------------------------------------
Inband registration process completed successfully! Output artifacts are created in the output folder

Note: ObAcessClient.xml is generated in the output folder. You will need this file later on after you install WebGate.

8. Change to the RREG_HOME/input directory.

9. From the OAM Console, you should now be able to see the following artifacts:
- 10g WebGate agent named $$webtierhost$$_webcenter

- host identifier by the same name

- an application domain with the same name containing authentication and authorization policies which in turn contain protected and public policies

10. Go to Application Domain> $$webtierhost$$_webcenter > Authentication Policies. You should be able to see the following policies:
Exclusion Scheme

Protected Resource Policy

Public Resource Policy

WebCenter REST Policy

11. Open the WebCenter Portal REST Policy and change the Authentication Scheme to BasicScheme (from the default LDAPScheme).

12. Open the Resources tab and search for resources with their Authentication Policy set to Exclusion Scheme. You should see the following resources:

/rsscrawl*
/rsscrawl/.../*
/sesUserAuth*
/sesUserAuth/.../*
/services-producer/portlets*
/services-producer/portlets/.../*
/wsrp-tools/portlets*
/wsrp-tools/portlets/.../*

13. Select the /rsscrawl* resource in the search results and click Edit.

14. Change the Protection Level from Protected to Excluded and click Apply. Note that the resource's authentication policy and authorization policy is removed.

15. Close the Resources tab and repeat the steps for the remaining Exclusion Scheme resources.
When you now search for resources with their Authentication Policy set to Exclusion Scheme you should see no results.

16. If your installation includes SOA and Content Server deployments, you must update your application policy with SOA and Content Server resources.
Create a policy update file called WebCenterOAM11gPolicyUpdate.xml (under RREG_HOME/input) as shown in the example below, replacing the content within $$webtier..$$ with your Web Tier host and port IDs, and $$oam...$$ with the OAM host and administration server port:

<?xml version="1.0" encoding="UTF-8"?>

<!--
Copyright (c) 2009, 2011, Oracle and/or its affiliates. All rights reserved.

NAME: UpdatePolicyRequest.xml - Template for updating application domain and/or policies without changes to any agent profile
DESCRIPTION: Modify with specific values and pass file as input to the tool
-->
<PolicyRegRequest>

<serverAddress>http://$$oamhost$$:$$oamadminserverport$$</serverAddress>
<hostIdentifier>$$webtierhost$$_webcenter</hostIdentifier>
<applicationDomainName>$$webtierhost$$_webcenter</applicationDomainName>

</PolicyRegRequest>

17. Run the following command:

RREG_HOME/bin/oamreg.sh policyUpdate input/WebCenterOAM11gPolicyUpdate.xml

Enter your OAM credentials when prompted.

Enter yes when asked whether you want to import a URIs file, and specify RREG_HOME/input/soa.oam.conf.

Your policy updates with SOA resources.

18. Run the policyUpdate command again, this time specifying RREG_HOME/input/oam.conf to update the policy with Content Server resources. Your policy now contains WebCenter Portal, SOA and Content Server artifacts.

4. Restart IBM HTTP Server (IHS).

5. Install WebGate 10g.
OAM 11g can work with both WebGate 10g and 11g but IBM HTTP Server currently only supports WebGate 10g. Therefore, you must download and install WebGate 10g.

1. Download WebGate 10g from Oracle Technology Network. The installable is called Oracle Access Manager 10g - non OHS11g Webgates and 3rd Party Integrations.
For Windows, select Oracle_Access_Manager10_1_4_3_0_Win32_IHS22_WebGate installer

For Linux, select Oracle_Access_Manager10_1_4_3_0_linux_IHS22_WebGate installer

For Linux, ensure that the GCC libraries are available. If your IHS is 32 bit, choose 32 bit libraries and if your IHS is 64 bit, choose 64 bit libraries.

Also, ensure that User and Group options are correctly set in IHS_Install_Dir/conf/httpd.conf. Change settings User nobody and Group nobody to the names of the user and group performing the set up and restart the Web Tier.

2. During installation, specify a location for installing WebGate.
Note: If you ran the installer before and it had failed for some reason, choose a different installation directory.

3. Specify the location of the GCC libraries.

4. Enter the following WebGate details:
WebGate Id: <agentName> chosen in the previous step, that is, $$webtierhost$$_webcenter

WebGate Password: <password> entered to run oamreg.sh

Access Server Name: oam_server1 (determine this value from OAMConsole)

Access Server HostName: $$oamhost$$

Access Server Port: 5575 (determine this value from OAMConsole)

5. Select to automatically update of httpd.conf and specify the location of httpd.conf from your WebTier. Typically, <webtier>/conf/httpd.conf

6. Finish the wizard.
WebGate successfully installed.

6. Configure IBM WebSphere for OAM single sign-on.
Detailed steps are provided in Section 11.9, "Configuring IBM WebSphere for OAM SSO and the IAP." To summarize, you must:

1. Configure a stand alone LDAP registry for OAM in IBM WebSphere.

2. Add and configure a virtual host in IBM WebSphere.

3. Configure IHS reverse proxy in the IBM WebSphere Console.

Note:

Ensure you remove all occurrences of <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/"/> and also you make this change each time you generate and propagate the web server plugin.

4. Create the Interceptor entry in the IBM WebSphere Console.

5. Configure the OAM TAI configuration file.
If you choose to copy oamtai.xml, ensure that you make the change in the Deployment Manager profile directory as this is the source of truth for other application server profiles.

The values you provide in oamtai.xml are similar to those you provided during WebGate installation. Here's a sample oamtai.xml for reference:

<?xml version="1.0" encoding="UTF-8"?>
<OAM-configuration>
<AAAClientConnect>
<Parameters>
<param name = "hostPort" value ="example.com:8080"/>

<param name = "resource" value ="/Authen/SSOToken"/>
<param name = "operation" value ="GET"/>
<param name = "AccessGateName" value ="myWG10g"/>
<param name = "AccessGatePassword" value ="welcome1"/>
<param name = "AccessServerHost" value ="oam.example.com"/>
<param name = "AccessServerPort" value ="5575"/>
<param name = "AccessServerName" value ="oam_server1"/>
<param name = "TransportSecurity" value ="open"/>
<param name = "debug" value ="false"/>
<param name = "minConn" value ="1"/>
<param name = "maxConn" value ="1"/>
<param name = "timeOutForConnPool" value ="30000"/>
<!--
Note:Following parameter is used for Anonymous User Authentication. Configure anonymous user value here
-->
<param name = "Anonymous" value =""/>
<!--
Note:Following parameters are required for Header Based Assertion.
Uncomment it if and only if in case Header based assertion.
1. If you configure the headername here, then the same name will be used
to configure as return attribute in OAM policy.
Don't change the assertion type parameter value. Only uncomment the parameter entry.
2.  If you do not configure the header name here, the default header name
is "OAM_REMOTE_USER" and the same should be configured in OAM policy.
Don't change the assertion type parameter value. Only uncomment parameter entry.
-->
<param name = "assertionType" value ="HeaderBasedAssertion"/>
<param name = "customHeaderName" value ="OAM_REMOTE_USER"/>
</Parameters>
</AAAClientConnect>
</OAM-configuration>

7. Configure logout details.

1. Configure the single sign-on logout provider.
Follow steps in Section 11.10.2.2, "Configuring SSO Logout for OPSS with ADF-coded applications and OAM 10g Webgate" to update jps-config.xml. Ensure that the jps-config.xml you update is from the Deployment Manager profile directory as this is the source of truth for other application server profiles.

2. Add oamAuthenProvider.jar to the classpath.
Follow steps in Section 11.10.2.3, "Configuring oamAuthenProvider.jar in the IBM WebSphere classpath." Do this for all servers in the install.

3. Add ssofilter.jar to the classpath.
See Section 5.2.16.2, "Configuring WebCenter Portal and Portal Framework Applications for Single Sign-On" for details on how to update the SSO filter in web.xml.

4. Create logout.html in WebGate.
i Navigate to <WebGate install directory>/access/oamsso

ii Create a file called logout.html with the following content and configure SERVER_LOGOUTURL for your installation:

<html>
<head>
<script language="javascript" type="text/javascript">
///////////////////////////////////////////////////////
//Before using, you need to change the values of:
//a. "oamserverhost" to point to the host where the OAM 11g Server is running.
//b. "port" to point to the port where the OAM 11g Server is running.
/////////////////////////////////////////////////////////////////////
var SERVER_LOGOUTURL = "http://example.com:14100/oam/server/logout";
//////////////////////////////////////////////////////////////////
function delCookie(name,path,domain) {
var today = new Date();
var deleteDate = new Date(today.getTime() - 48 * 60 * 60 * 1000); // minus 2 days
var cookie = name + "="
+ ((path == null) ? "" : "; path=" + path)
+ ((domain == null) ? "" : "; domain=" + domain)
+ "; expires=" + deleteDate;
document.cookie = cookie;
}

function delOblixCookie() {
// set focus to ok button
var isNetscape = (document.layers);
if (isNetscape == false || navigator.appVersion.charAt(0) >= 5) {
for (var i=0; i<document.links.length; i++) {
if (document.links[i].href == "javascript:top.close()") {
document.links[i].focus();
break;
}
}
}
delCookie('ObTEMC', '/');
delCookie('ObSSOCookie', '/');
delCookie('LtpaToken', '/');
delCookie('LtpaToken2', '/');
// in case cookieDomain is configured
// delete same cookie to all of subdomain
var subdomain;
var domain = new String(document.domain);
var index = domain.indexOf(".");
while (index > 0) {
subdomain = domain.substring(index, domain.length);
if (subdomain.indexOf(".", 1) > 0) {
delCookie('ObTEMC', '/', subdomain);
delCookie('ObSSOCookie', '/', subdomain);
delCookie('LtpaToken', '/', subdomain);
delCookie('LtpaToken2', '/', subdomain);
}
domain = subdomain;
index = domain.indexOf(".", 1);
}
}
function handleLogout() {
//get protocol used at the server (http/https)
var webServerProtocol = window.location.protocol;
//get server host:port
var webServerHostPort = window.location.host;
//get query string present in this URL
var origQueryString = window.location.search.substring(1);
var newQueryString = "";
//vars to parse the querystring
var params = new Array();
var par = new Array();
var val;

if (origQueryString != null && origQueryString != "") {
params = origQueryString.split("&");
for (var i=0; i<params.length; i++) {
if (i == 0)
newQueryString = "?";

if (i > 0)
newQueryString = newQueryString + "&";

par = params[i].split("=");

//prepare a new query string, if the end_url value needs to be changed
newQueryString = newQueryString + (par[0]);
newQueryString = newQueryString + "=";
val = par[1];

if ("end_url" == par[0]) {
//check if val (value of end_url) begins with "/" or "%2F" (is it an URI?)
if (val.substring(0,1) == "/" || val.substring(0,1) == "%") {
//modify the query string now
val = webServerProtocol + "//" + webServerHostPort + val;
}
}
newQueryString = newQueryString + val;
}
}

//delete oblix cookies
delOblixCookie();

//redirect the user to this URL
window.location.href = SERVER_LOGOUTURL + newQueryString;
}
</script>
</head>

<body onLoad="handleLogout();">

</body>
</html>

5. Update httpd.conf in WebTier.

1. Navigate to <webtier install directory>/conf/httpd.conf

2. Add the following entries in the webgate section

Alias /oamsso "<webage-install-dir>/access/oamsso"

6. Restart WebTier and all the servers, including the Node Manager in WebSphere.

8. Configure WebCenter Portal or Portal Framework applications to require certificate based authentication and SSO synchronization filter.
For detailed steps, see Section 5.2.16.2, "Configuring WebCenter Portal and Portal Framework Applications for Single Sign-On."

9. Configure other Oracle WebCenter Portal components for single sign-on:

- WebCenter Portal

- Discussions server

- Worklists

- RSS news feeds

- Secure Enterprise Search

- Content Server

- Enterprise Manager

For details steps, see the "Additional Single Sign-on Configurations" section in Oracle Fusion Middleware Administering Oracle WebCenter Portal.

Note: Since IBM WebSphere only supports one auth-method, once SSO is configured, access through via IBM WebSphere ports results in an error as the required OAM headers are not available. Access to all the applications must be through the Web tier.

5.2.16.2 Configuring WebCenter Portal and Portal Framework Applications for Single Sign-On

If you want WebCenter Portal or any other Portal Framework application, to participate in single sign-on, you must specify CLIENT-CERT as the authentication method for Trust Access Interceptors. By default, WebCenter Portal and all Portal Framework applications specify FORM or BASIC as their authentication mechanism.

Unlike Oracle WebLogic Server, IBM WebSphere does not support multiple comma separated authentication-method and therefore, you must change the authentication method to CLIENT-CERT for WebCenter Portal or Portal Framework applications to participate in single sign-on.

Follow these steps to change authentication method for portal applications:

1. Locate web.xml for WebCenter Portal or the Portal Framework application.

- For WebCenter Portal, go to the machine where IBM WebSphere Application Server is installed and navigate to:

PROFILE_DIR/config/cells/
cellname/applications/webcenter.ear/
deployments/webcenter/spaces-was.war/WEB-INF/web.xml

- For other Portal Framework applications, go to the machine where IBM WebSphere Application Server is installed and navigate to the application WAR file. For example:

PROFILE_DIR/config/cells/
cellname/applications/MyPortalApp.ear/
deployments/MyPortalApp/portal-app.war/WEB-INF/web.xml

2. Copy web.xml to a temporary location.

3. Open web.xmlin a text editor.

1. Remove (or comment out) the <login-config> section as follows:

<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/oracle/webcenter/webcenterapp/view/templates/
publichtml/LoginGateway.jsp</form-login-page>

<form-error-page>/oracle/webcenter/webcenterapp/view/templates/
publichtml/LoginGateway.jsp?login_fail=true</form-error-page>
</form-login-config>
</login-config>

2. Replace with the following <login-config> section:

<login-config>
<auth-method>CLIENT-CERT</auth-method>
</login-config>

3. Add the SSO synchronization filter:

<filter>
<display-name>SSOSessionSynchronizationFilter</display-name>
<filter-name>SSOSessionSynchronizationFilter</filter-name>
<filter-class>oracle.security.was.filter.SSOSessionSynchronizationFilter</filter-class> </filter>
<filter-mapping>
<filter-name>SSOSessionSynchronizationFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

4. Save the changes.

4. Redeploy the updated web.xmlfile:

1. Log in to the IBM WebSphere Administrative Console:
https://host:port/ibm/console

2. Navigate to Applications > Application Types > WebSphere enterprise applications.

3. Locate and select WebCenter Portal or your Portal Framework application, and then click Update.
To update web.xml for WebCenter Portal, for example, locate the application named webcenter.

4. Choose the option Replace or add a single file.

5. Specify the path to the web.xml file you want to replace. Start the path from the name of the application's archive file (.war):

war_file_name/WEB-INF/web.xml

For example:

For the WebCenter Portal, enter: spaces-was.war/WEB-INF/web.xml

For a Portal Framework application, enter: MyPortalApp.war/WEB-INF/web.xml

6. Click Next.

7. In the section Specify the path to the file, enter the full path to the web.xml file you updated in step 3.

8. Click Next.

9. Click OK and Save Changes.
Wait for a couple of minutes for the changes to be propagated.

10. To confirm the change, navigate to the application's deployment descriptor:
For example, for WebCenter Portal, navigate to: WebSphere enterprise Applications > webcenter > Manage Modules > spaces-was.war > View Deployment Descriptor

5. Restart the WebCenter Portal or your Portal Framework application.

6. Access the portal application and, if single sign-on is configured, the web.xml changes take effect.

7. Repeat similar steps to update any other Web application that participates in single sign-on, for example:
WebCenter Portal install:

- WebCenter Portal Application:
webcenter/spaces-was.war

- REST API Web Application:
webcenter/webcenter-rest-was.war

- RSS Web Application:
webcenter/webcenter-rss-was.war

- Activity Graph Engines Application:
activitygraph-engines_11.1.1.6.0/activityGraph-engines.war

- Pagelet Producer Admin:
pagelet-producer_11.1.1.6.0/pageletadmin.war

- Pagelet Producer Proxy:
pagelet-producer_11.1.1.6.0/ensembleproxy.war

- Services Producer:
services-producer_11.1.1.6.0/services-producer-was.war

- Worklist Application:
WebCenterWorklistDetailApp/WebCenterWorklistDetail_was.war

SOA Suite install:

- SOA Infra Application:
soa-infra/fabric.war

- UMS Application:
usermessagingserver/sdpmessaginguserprefs-ui-web.war

- UMS SCA:
usermessagingsca-ui-worklist/sdpmessagingsca-ui-worklist-was.war

- Composer Application:
composer/soa-composer-was.war

- To Do Task Flow:
DefaultToDoTaskFlow/DefaultToDoTaskFlow.war

WebCenter Content install:

- Content Server:
Oracle WebCenter Content-Content Server/cs.war

- Inbound Refinery:
Oracle WebCenter Content-Inbound Refinery/ibr.war

5.2.17 Configuring SSL for WebCenter Portal or Portal Framework Applications

Typically, SSL is enabled between the browser and HTTP server. If you need a SSL connection between your IBM HTTP Server and WebSphere nodes (because of your topology/hardened security requirements) or between the browser and WebSphere node directly, you may need to do addition configuration.

This section contains the following topics:

- Chapter 5, "Obtaining the SSL Port for WebCenter Portal or Portal Framework Applications"

- Chapter 5, "Importing SSL Certificates on IBM WebSphere"

5.2.17.1 Obtaining the SSL Port for WebCenter Portal or Portal Framework Applications

For SSL between the browser and the WebSphere node, obtain the SSL port as follows:

1. Log in to the IBM WebSphere Administrative Console.

2. Navigate to the WebSphere cell on which WebCenter Portal or your Portal Framework application is deployed. Select Application servers> <cell name>
For WebCenter Portal, for example, navigate to Application servers> WC_Spaces.

3. Select Ports.
A list of ports displays. Use the SSL port WC_defaulthost_Secure to access your application securely (Figure 5-20).For WebCenter Portal, for example, https://myhost.com:8788/webcenter

Figure 5-20 Port Information for WC_Spaces

5.2.17.2 Importing SSL Certificates on IBM WebSphere

To import SSL certificates on IBM WebSphere:

1. Log in to the IBM WebSphere Administrative Console.

2. In the navigation panel, expand Security, then click SSL certificate and key management.

3. Click Key stores and certificates.
The Keystore usages dropdown should show SSL keystores (Figure 5-21).

Figure 5-21 Keystores and Certificates Configuration

4. Select a trust store (for example, CellDefaultTrustStore).

5. Click Personal Certificate.

6. Select Import (Figure 5-22).

Figure 5-22 CellDefaultTrustStore - Import Personal Certificates

7. Select Key store file and specify the location of your keystore (.jks) file (Figure 5-23).

Figure 5-23 Specifying Keystore Location

8. For Type, select JKS, and then enter a Password.

9. Click OK to import the certificates from the keystore.

10. Restart the application server.

5.2.18 Cloning Oracle WebCenter Portal Installations on IBM WebSphere

Use the IBM WebSphere Administrative Console to clone Oracle WebCenter Portal installations on WebSphere as follows:

1. Log in to the IBM WebSphere Administrative Console.

2. Navigate to Servers > Server Types > WebSphere application servers.

3. Create a server template based on the server you want to clone:

1. Click the Templates... button.

2. On the Server Templates screen, click New and select the server for the template.

3. Click OK.

4. Enter a Name for your server template, then click OK.

4. Navigate to Servers > Server Types > WebSphere application servers.

5. Create an application server based on the template you created in the previous step:

1. Click New.

2. Complete Step 1: Select a node.

3. For Step 2: Select a server template, select the template.

4. Complete Step 3 and Step 4 as required.

The new application server has the same resources as the specified template.

5.2.19 Configuring WebCenter Portal or Portal Framework Applications for High Availability on IBM WebSphere

This section describes a typical WebCenter Portal cluster topology and explains some additional set up steps that are required for clustered deployments on IBM WebSphere.

This section is not meant to provide comprehensive information for configuring high availability for Oracle WebCenter Portal on IBM WebSphere. For more information about the resources available when configuring high availability on WebSphere, see Section 3.4, "Configuring Oracle Fusion Middleware High Availability on IBM WebSphere."

For an overview of the steps required for setting up high availability for Oracle WebCenter Portal on IBM WebSphere, refer to the following:

1. Install Required Oracle WebCenter Portal Components on Both Hosts

2. Configure a New WebSphere Cell on WCPHOST1

3. Federate WCPHOST2 and Configure Cell

4. Configure a Load Balancer

5. Configure Oracle Internet Directory as the LDAP Identity Store

6. Reassociate the Identity Store

7. Configure Distributed Java Object Cache

8. Configure Clustering for Discussions

9. Configure Activity Graph

5.2.19.1 Typical Oracle WebCenter Portal Cluster Topology

Figure 5-24 shows a typical cluster set up for a WebCenter Portal deployment.

Figure 5-24 Cluster Topology - WebCenter Portal Application

Figure 5-25 shows a typical cluster set up for Portal Framework and Portlet Producer applications built using JDeveloper.

Figure 5-25 Cluster Topology - Portal Framework and Portlet Producer Applications

5.2.19.2 Install Required Oracle WebCenter Portal Components on Both Hosts

In a clustered environment, you must install and configure a suitable database, IBM WebSphere Application Server, Oracle Fusion Middleware (WebCenter Portal, WebCenter Content, SOA Suite), and IBM HTTP Server on both hosts. In this section, the hosts are referred to as WCPHOST1 and WCPHOST2.

See also, Section 5.2.1, "Installing Oracle WebCenter Portal Products on IBM WebSphere."

5.2.19.3 Configure a New WebSphere Cell on WCPHOST1

On the first Oracle WebCenter Portal host (WCPHOST1), create a new WebSphere cell:

1. Launch the Configuration Wizard using:

WCP_ORACLE_HOME/common/bin/was_config.sh

2. On the Select Configuration Option page, click Create and Configure Cell.

3. On the following screens, select Oracle WebCenter Portal products and configure JDBC schemas, as required.
For details, see the "Using the Configuration Wizard" section in Oracle Fusion Middleware Configuration Guide for IBM WebSphere Application Server.

4. On the Select Optional Configuration page, click Application Servers, Clusters and End Points.

5. On the Configure Cluster page, add the new cluster and the first member, and select Enabled memory to memory replication.

6. Finish creating the cell by completing the Configuration Wizard.

7. Start the Deployment Manger:

WAS_HOME/profiles/dmg_profile_name/bin/startManager.sh

8. Start the node agent on the WCPHOST1 using:

WAS_HOME/profiles/profile_name/bin/startNode.sh.

5.2.19.4 Federate WCPHOST2 and Configure Cell

If the second Oracle WebCenter Portal machine (WCPHOST2), is not yet federated to the cell on WCPHOST1, perform the following steps:

1. Launch the Configuration Wizard using:

WCP_ORACLE_HOME/common/bin/was_config.sh

2. On the Select Configuration Option page, click Federate Machine and Configure Cell.

3. Enter Deployment Manager details for WCPHOST1 or the machine where the Deployment Manager is located.
You can find the machine details at the following location:

WAS_HOME/profiles/dmgr_profile_name/logs/AboutThisProfile.txt

4. On the Add Products to Cell page, click Next.
You do not need to select any products on this page.

5. On the Select Optional Configuration page, click Application Servers, Clusters and End Points.

6. On the Configure Additional Cluster Members page, add the second server for the cluster associated with this node.

7. Finish federating the machine by completing the Configuration Wizard.

8. Start the node agent on Machine2 by opening:

WAS_HOME/profiles/profile_name/bin/startNode.sh

5.2.19.5 Configure a Load Balancer

Configure an IBM HTTP server for load balancing in a clustered IBM WebSphere environment. For detailed steps, see Section 5.2.15, "Installing and Configuring IBM HTTP Server."

5.2.19.6 Configure Oracle Internet Directory as the LDAP Identity Store

Set up Oracle Internet Directory (OID) as the external LDAP ID store for WebCenter Portal applications:

1. Install and configure Oracle Internet Directory (OID).

2. Configure the LDAP registry.
Create a properties file for your Oracle Internet Directory LDAP ID store and then run the wsadmin configuration command Opss.configureIdentityStore. For detailed steps, see Section 9.1.1, "Configuring a Registry."

3. Perform a full resynchronization for all nodes:

1. Login to the IBM WebSphere Administrative Console and navigate to the Nodes page (System administration > Nodes).

2. Select all nodes in the cluster and click Full Resynchronize.

4. Restart all servers in the cluster.

5.2.19.7 Reassociate the Identity Store

Perform the following steps to reassociate the identity store:

1. Connect to the Dmgr server using wsadmin:

WCP_ORACLE_HOME/common/bin/wsadmin.sh -conntype SOAP -user <admin username> -password <password> -port <admin SOAP port> -host <Dmgr host>

2. Run the security store reassociate wsadmin command:

Opss.reassociateSecurityStore(domain="Cell_WebSphere",servertype="OID", ldapurl="ldap://<host>:<port>", jpsroot="<jpsroot>",
admin="<admin username>", password="<admin password>")

3. Perform a full resynchronization for all nodes:

1. Login to the IBM WebSphere Administrative Console and navigate to the Nodes page (System administration > Nodes).

2. Select all nodes in the cluster and click Full Resynchronize.

4. Restart all servers in the cluster.

5.2.19.8 Configure Distributed Java Object Cache

For details how to configure the distributed Java Object Cache (JOC), see Section 3.4.2, "Configuring Java Object Cache for Oracle Fusion Middleware on IBM WebSphere."

5.2.19.9 Configure Clustering for Discussions

Configure clustering options for discussions, deployed on the WC_Collaboration servers:

1. Create an Admin user for the discussions server:
For details, see Section 5.2.8, "Configuring an Admin User for the Discussions Server."

2. Restart all WC_Collaboration servers in the cluster.

3. For each server in the WC_Collaboration cluster, configure unicast cluster communication:

1. Log into the IBM WebSphere Administrative Console.

2. Expand Servers, expand Server Types, then click WebSphere application servers.

3. Click WC_Collaboration, the server on which the discussions application is deployed.

4. Under Server Infrastructure, expand Java and Process Management, then click Process definition.

5. On the process definition page, under Additional Properties, click Java Virtual Machine.

6. On the Java virtual machine page, under Additional Properties, click Custom properties.

7. Create the following variables. Click New, enter the name, enter the value, then click OK.
Name: tangosol.coherence.wka1, Value=WCPHOST1

Name: tangosol.coherence.wka2, Value=WCPHOST2

Name: tangosol.coherence.localhost, Value=WCPHOST1

Name: tangosol.coherence.wka1.port, Value=8089

Name: tangosol.coherence.wka2.port, Value=8089

Name: tangosol.coherence.localport, Value=8089

4. Repeat step 3 for WC_Collaboration2, swapping WCPHOST1 for WCPHOST2, and WCHost2 for WCHost1:
Name: tangosol.coherence.wka1, Value=WCPHOST1

Name: tangosol.coherence.wka2, Value=WCPHOST2

Name: tangosol.coherence.localhost, Value=WCPHOST1

Name: tangosol.coherence.wka1.port, Value=8089

Name: tangosol.coherence.wka2.port, Value=8089

Name: tangosol.coherence.localport, Value=8089

5. Restart all WC_Collaboration servers in the cluster.

5.2.19.10 Configure Activity Graph

The activity graph application (activitygraph-engines) cannot be targeted to a cluster. As IBM WebSphere does not allow you to target an application to a server that is part of a cluster, you must create a new server for the activity graph application:

1. Create a server template based on the WC_Utilities server

1. Log into the IBM Admin Console.

2. Expand Servers, expand Server Types, then click WebSphere application servers.

3. Click Templates.

4. Click New.

5. Select WC_Utilities as the server for the template, then click OK.

6. Enter the name for the server template, then click OK.

2. Create the new server based on the newly created server template:

1. Expand Servers, expand Server Types, then click WebSphere application servers.

2. Click New.

3. Select the node where this server is located, enter the server name, then click Next.

4. Select the template you just created, then click Next.

5. Select Generate Unique Ports, then click Next.

6. Click Finish.

3. Re-target the application to the new server:

1. Expand Applications, expand Application Types, then click WebSphere enterprise applications.

2. Click activitygraph-engines_11.1.1.4.0.

3. Under Modules, click Manage Modules.

4. Select all modules, select the target server you created in step 2, and click Apply.

5. Click OK.

5.3 Differences Developing and Deploying Portal Framework Applications on IBM WebSphere

The following topics describe differences and restrictions when developing and deploying WebCenter Portal Framework applications on IBM WebSphere:

- Configuring a WebSphere Application Server Connection in JDeveloper

- Deploying Portal Framework Applications on IBM WebSphere Directly from JDeveloper

- Targeting Application EAR and WAR Files for IBM WebSphere Deployment

- Deploying Portal Framework Application EARs using WebSphere Console and wsadmin

- Securing a Portal Framework Application Connection to IMAP and SMTP with SSL

- Using the Deploy and Configure Script for Portal Framework Applications Deployed on WebSphere

- Creating SQL Data Controls for Applications Deployed on WebSphere Administration Server

5.3.1 Configuring a WebSphere Application Server Connection in JDeveloper

If you want to deploy a Portal Framework application to an IBM WebSphere Server that resides outside JDeveloper, you must ensure that the target server is up and running with the required libraries, and then you must.set up a connection to the target WebSphere server.

During application server connection creation, you are prompted for configuration information on several wizard pages. Table 5-4 describes where to find this information in the IBM WebSphere Administrative Console for which you are prompted.

Table 5-4 Location of Application Server Connection Configuration Details

Connection Wizard Fields

For IBM WebSphere Application Server - 7.0,
Select...

For IBM WebSphere Application Server - Network Deployment (ND),
Select...

Configuration Page

- SOAP Connector Port

System administration > Deployment manager > Configuration > Ports > SOAP_CONNECTOR_ADDRESS

System administration > Deployment manager > Configuration > Ports > SOAP_CONNECTOR_ADDRESS

- Server Name

System administration > Deployment manager > Configuration > Name

Servers > Server Types > WebSphere Application Servers > Your_Server_Name > Configuration > Name

- Target Node

System administration > Deployment manager > Runtime > Node name

Servers > Server Types > WebSphere Application Servers > Your_Server_Name > Runtime > Node name

- Target Cell

System administration > Deployment manager > Runtime > Cell name

Servers > Server Types > WebSphere Application Servers > Your_Server_Name > Runtime > Cell name

For more information about creating an application server connection, see the Oracle JDeveloper online help or Section 4.2.4, "Creating an Application Server Connection."

5.3.2 Deploying Portal Framework Applications on IBM WebSphere Directly from JDeveloper

Deploying Portal Framework applications directly from Oracle JDeveloper to IBM WebSphere Server is largely the same as described in Oracle Fusion Middleware Developing Portals with Oracle WebCenter Portal and Oracle JDeveloper.

The differences are as follows:

- Database connection configuration for seeded data sources is different on IBM WebSphere. For details, see:

- Creating Database Connections for Seeded Data Sources on Out-of-the-Box Server

- Creating Database Connections for Seeded Data Sources on Other Target Servers

- Database connection configuration for custom data sources is different on IBM WebSphere. For details, see:

- Creating Database Connections to Custom Data Sources

Note:

Custom data sources are not automatically created when you deploy WebCenter Portal applications to a WebSphere Application Server through JDeveloper or Fusion Middleware Control.

- The Deploy using SSL check box does not appear on the Create Application Server Connection wizard page. See Section 5.3.2.4, "Deploying Portal Framework Applications Using SSL."

- Deployed applications do not start automatically after deployment. You have to start the WebCenter Portal application manually using the console. See Section 5.3.2.5, "Deploying and Redeploying Portal Framework Applications From JDeveloper."

5.3.2.1 Creating Database Connections for Seeded Data Sources on Out-of-the-Box Server

Servers created using WC_CustomPortal and WC_CustomServicesProducer templates automatically come pre-seeded with two data sources (WebCenter and Activities):

Data Source

Data Source Name

JNDI Name

WC_CustomPortal Template

WebCenter

webcenter/CustomPortalDS

jdbc/webcenter/CustomPortalDS

Activities

activities/CustomPortalDS

jdbc/activities/CustomPortalDS

WC_CustomServicesProducer Template

WebCenter

webcenter/CustomServicesProducerDS

jdbc/webcenter/CustomServicesProducerDS

Activities

activities/CustomServicesProducerDS

jdbc/activities/CustomServicesProducerDS

No additional configuration is required if you want to deploy a working Portal Framework application directly to a WC_CustomPortal or WC_CustomServicesProducer server, through JDeveloper.

Optionally, if you plan to test the application in JDeveloper's embedded WebLogic Server, you must manually create the relevant database connections, ensuring that the database connection names map to the data sources in the target server as follows:

Data Source

Database Connection Name

WebCenter

webcenter/CustomPortal or webcenter/CustomServicesProducer

Activities

activities/CustomPortal or activities/CustomServicesProducer

When the bindings are generated in the deployment descriptor, the above connection names are prefixed with the sting "jdbc/" and appended with the string "DS".

To enable application testing in the embedded WebLogic Server, create database connections for seeded data sources as follows (this example illustrates deployment to a WC_CustomPortal server):

1. In JDeveloper, create a database connection.
For general steps, see the "Setting Up a Database Connection" section in Oracle Fusion Middleware Developing Portals with Oracle WebCenter Portal and Oracle JDeveloper.

2. To connect to the WebCenter Portal database, ensure that:

- Connection Name = webcenter/Custom Portal (Figure 5-26)

- Associate to Data Source = WebCenterDS (Figure 5-27)

Figure 5-26 Database Connection Name - WebCenter/CustomPortal

Figure 5-27 Associate webcenter/CustomPortal Connection to WebCenterDS

3. To connect to the Activities database, ensure that:

- Connection Name = activities/Custom Portal (Figure 5-28)

- Associate to Data Source = ActivitiesDS (Figure 5-29)

Figure 5-28 Database Connection Name - activities/CustomPortal

Figure 5-29 Associate activities/CustomPortal Connection to ActivitiesDS

The database connections appear in the navigator as follows:

Figure 5-30 Application Navigator - Database Connections to Seeded Data Sources

5.3.2.2 Creating Database Connections for Seeded Data Sources on Other Target Servers

Oracle recommends that Portal Framework applications built using JDeveloper are deployed on servers created using the WC_CustomPortal template (and come pre-seeded with WebCenter and Activities data sources). However, if you must deploy your Portal Framework application to a different target server (such as WC_CustomServicesProducer) and want to use the WebCenter or Activities data sources that have been created or pre-exist on the target server, you must manually create database connections to the WebCenter and Activities data sources.

To ensure that the correct bindings are generated for the data sources in the target server, the names of the database connections must match up with the existing JNDI name (if any). When the bindings are generated in the deployment descriptor, connection names are prefixed with the sting "jdbc/" and appended with the string "DS". For example:

Data Source

JNDI Name

Database Connection Name

WebCenter

jdbc/MyWebCenterDS

MyWebCenter

Activities

jdbc/ActivitiesDS

MyActivities

Failure to create a database connection results in run time failures with log entries such as:

Caused by: javax.naming.NameNotFoundException:
Context: Cell1/nodes/Server1Node/servers/WC_Spaces,
name: jdbc/webcenter/CustomPortalDS:
First component in name webcenter/CustomPortalDS not found.
Root exception is org.omg.CosNaming.NamingContextPackage.NotFound:
IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]

Failure to create binding entries that do not match an existing data source JNDI name result in run time failures with log entries such as:

Caused by: javax.naming.NameNotFoundException:
Context: Cell1/nodes/Server1Node/servers/WC_Spaces,
name: jdbc/MyWebCenterDS:
First component in name MyWebCenterDS not found.
[Root exception is org.omg.CosNaming.NamingContextPackage.NotFound:
IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]

To create database connections for seeded data sources on a server other than WC_CustomPortal:

1. In JDeveloper, create a database connection.
For general steps, see the "Setting Up a Database Connection" section in Oracle Fusion Middleware Developing Portals with Oracle WebCenter Portal and Oracle JDeveloper.

2. To connect to the WebCenter Portal database, ensure that:

- Connection Name = <matches the JNDI name>
For example, if the JNDI name is jdbc/MyWebCenterDS, the connection name must be MyWebCenter (Figure 5-31)

- Associate to Data Source = WebCenterDS (Figure 5-32)

Figure 5-31 Database Connection Name - MyWebCenter

Figure 5-32 Associate MyWebCenter Connection to WebCenterDS

3. To connect to the ACTIVITIES database, ensure that:

- Connection Name = <matches the JNDI name>
For example, if the JNDI name is jdbc/MyActivitiesDS, the connection name must be MyActivities (Figure 5-33)

- Associate to Data Source = ActivitiesDS (Figure 5-34)

Figure 5-33 Database Connection Name - MyActivities

Figure 5-34 Associate MyActivities Connection to ActivitiesDS

The database connections appear in the navigator as follows:

Figure 5-35 Application Navigator - Database Connections to Data Sources

5.3.2.3 Creating Database Connections to Custom Data Sources

Custom data sources are not automatically created when you deploy Portal Framework applications to an IBM WebSphere Application Server through JDeveloper and Fusion Middleware Control. If you want to use data sources other than those provided by the template (WebCenter and Activities), you must create the custom data sources manually using the IBM WebSphere Administrative Console.

Firstly, at design-time, you must create a database connection and map it to the WebCenter or Activities schema. Once complete, you can note down the associated JNDI name that the application will use post deployment and create a data source that maps to that JNDI name.

Mapped Data Source

Database Connection Name

JNDI Name

WebCenter or Activities

<DatabaseConnectionName>

jdbc/<DatabaseConnectionName>DS

For example:

WebCenterDS

MyLists

jdbc/MyListsDS

To create the database connection and verify the JNDI name:

1. In JDeveloper, create a database connection.
For general steps, see the "Setting Up a Database Connection" section in Oracle Fusion Middleware Developing Portals with Oracle WebCenter Portal and Oracle JDeveloper.

2. To connect to a custom data source instead of the default WebCenter Portal database, ensure that:

- Connection Name = <any name> For example, MyLists (Figure 5-36)

- Associate to Data Source = WebCenterDS or ActivitiesDS (Figure 5-37)

Figure 5-36 Custom Database Connection Name - MyLists

Figure 5-37 Associate Custom Database Connection to WebCenterDS

This step ensures that when you deploy the application, deployment descriptor updates map the MyLists data source name to all usages of the WebCenter schema for this application. For instance, in this example, the MyLists data source specifies an alternative back-end repository for the Lists tool.

Similarly, you can specify an alternative data source for all usages of the Activities schema.

3. To examine the content of the EAR file and validate the mapping, deploy the application to the file system (ensuring the target platform is specified as IBM WebSphere), and then click the EAR file in the JDeveloper log file (Figure 5-38)

Figure 5-38 EAR File Deployed to IBM WebSphere

4. Select the WAR file, and navigate to WEB-INF/ibm-web-bnd.xml (Figure 5-39).

Figure 5-39 WAR File Deployed to IBM WebSphere

5. Open WEB-INF/ibm-web-bnd.xml to verify that the binding entry maps the MyLists entry to WebCenterDS usages in the application (Figure 5-40).
Note: The binding-name is jdbc/MyListsDS—the database connection name prefixed with "jdbc" and appended with "DS". This information must be used when you create the data source for the target server, using the IBM WebSphere Administrative Console.

Figure 5-40 ibm-web-bnd.xml Deployed to IBM WebSphere

To create a data source using the IBM WebSphere Administrative Console:

1. Log in to the IBM WebSphere Administrative Console.

https://host:port/ibm/console

2. Navigate to Guided Activities > Connecting to a database.
See also, Section 3.2.7, "Creating a Data Source in an IBM WebSphere Cell."

3. Configure credentials for secure database access (Figure 5-41).

Figure 5-41 Configure Credentials for Secure Database Access

4. Configure a JBDC provider (Figure 5-42).

Figure 5-42 Configure a JBDC Provider

Figure 5-43 Create and Save the JBDC Provider

5. Modify the JDBC provider to use the latest Oracle database classes (Figure 5-44):

${COMMON_COMPONENTS_HOME}/modules/oracle.jdbc_11.1.1/ojdbc6dms.jar
${COMMON_COMPONENTS_HOME}/modules/oracle.dms_11.1.1/dms.jar
${COMMON_COMPONENTS_HOME}/modules/oracle.odl_11.1.1/ojdl.jar

and save your changes to the master configuration.

Figure 5-44 Add the Latest Oracle Database Classes

6. Skip the step "Configure WebSphere variables."

7. Configure a data source:

1. Enter the JNDI Name exactly as it appears in the application bindings (Figure 5-45). For example: jdbc/MyListsDS

Figure 5-45 Configure the Data Source

2. Click Next. Select the JBDC Provider you created earlier and enter the JBDC URL to the database connection you created in JDeveloper (Figure 5-46).

Figure 5-46 Configure the JDBC Provider

3. Click Next. For Container-managed authentication alias, select the alias created earlier, for example MyListUser, and leave all the other fields blank (Figure 5-47).

Note:

Component managed authentication is required if you plan to build SQL data controls. For details, see Section 5.3.7, "Creating SQL Data Controls for Applications Deployed on WebSphere Administration Server."

Figure 5-47 Select the Data Source Security Alias

8. Click Next. Confirm the changes and click Finish (Figure 5-48).

Figure 5-48 Save Data Source Configuration

9. Restart the servers to effect the new authentication alias MyListUser.

10. Test the data source connection.

11. Deploy the application and it verify that it uses the new custom data source.

5.3.2.4 Deploying Portal Framework Applications Using SSL

When you deploy Portal Framework applications to IBM WebSphere from JDeveloper, a Deploy using SSL check box displays on the deployment wizard. This differs from Oracle WebLogic Server deployment, where the Deploy using SSL check box instead appears on the Create Application Server Connection wizard (Configuration page).

Table 5-5 describes what occurs when you select this check box during IBM WebSphere Server deployment.

Table 5-5 Deployment to HTTPS and HTTP Servers

If This Checkbox Is...

Then...

Selected

An HTTPS server URL must exist to deploy the application with SSL.

If the server only has an HTTP URL, deployment fails.

Not selected

An HTTP server URL must exist to deploy to a non-SSL environment. Otherwise, deployment fails.

If the server has both HTTPS and HTTP URLs, deployment occurs through a non-SSL connection. This enables you to force a non-SSL deployment from Oracle JDeveloper, even though the server is SSL-enabled.

5.3.2.5 Deploying and Redeploying Portal Framework Applications From JDeveloper

Applications do not start automatically after deployment or redeployment from JDeveloper. You have to start the Portal Framework application manually using IBM WebSphere Administrative Console or wsadmin commands. For details, see Section 5.3.4.2, "Deploying Portal Framework Application EARs using WebSphere Admin Console" and Section 5.3.4.3, "Deploying Portal Framework Application EARs using wsadmin Commands."

5.3.3 Targeting Application EAR and WAR Files for IBM WebSphere Deployment

If you want to deploy Portal Framework applications to IBM WebSphere you must ensure that the application's WAR deployment profile and EAR deployment profile are configured with Platform set to WebSphere (Figure 5-49). For details, see the "Creating a WAR Deployment Profile" and "Creating an Application-level EAR Deployment Profile" sections in Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.

Figure 5-49 Configure WebSphere Targeted EAR and WAR Deployment Profiles

5.3.4 Deploying Portal Framework Application EARs using WebSphere Console and wsadmin

If your Portal Framework application is packaged in an EAR file, you can use the IBM WebSphere Console or wsadmin command (AdminApp.install) to deploy the application to WebSphere:

- Deployment Prerequisites

- Deploying Portal Framework Application EARs using WebSphere Admin Console

- Deploying Portal Framework Application EARs using wsadmin Commands

Note:

Applications do not start automatically after deployment or redeployment from JDeveloper. You have to start the WebCenter Portal application manually using the IBM WebSphere Administrative Console or using wsadmin commands.

5.3.4.1 Deployment Prerequisites

Before you deploy the EAR file:

- Ensure that the WAR and EAR deployment descriptors used to generate the EAR file specify "WebSphere" as the target platform. See Section 5.3.3, "Targeting Application EAR and WAR Files for IBM WebSphere Deployment."

- Update the archive's MDS configuration using the wsadmin command MDSAdmin.getMDSArchiveConfig and archive.setAppMetadataRepository.
For example:

wsadmin>archive = MDSAdmin.getMDSArchiveConfig(fromLocation='/scratch/oracle/jdeveloper/mywork/myPortalFwkApp/deploy/myPortalFwkApp_application1.ear')
wsadmin>archive.setAppMetadataRepository(repository='mds-CustomPortalDS',partition='myPortalFwkApp_application1',type='DB',jndi='jdbc/mds/CustomPortalDS')
Operation "setAppMetadataRepository" successful.
wsadmin>archive.save()

See also the "Deploying Portal Framework Applications" section in Oracle Fusion Middleware Administering Oracle WebCenter Portal.

5.3.4.2 Deploying Portal Framework Application EARs using WebSphere Admin Console

To deploy a Portal Framework application EAR file using IBM WebSphere Console:

Note:

For more information, see the IBM WebSphere documentation.

1. Log in to the IBM WebSphere Administrative Console.

2. Navigate to Applications > New Application >New Enterprise Application.

3. Enter the location of your application EAR file and click Next (Figure 5-50).

Figure 5-50 Specifying the Portal Framework Application EAR Location

4. On the Preparing for the application installation page, accept the default Fast Path install option, and click Next.

5. On the Specify options for installing enterprise applications and modules page, accept all the default settings, and click Next.

6. On the Map modules to servers page, choose the target server for your application
For example:

- For Portal Framework applications, choose WC_CustomPortal

- For Portlet Producer applications, choose WC_CustomServicesProducer

7. On the summary page select to Finish to install.

8. Select Save (Figure 5-51).

Figure 5-51 Saving Portal Framework Application EAR Installation

9. Select the name of your newly installed application, and click Start (Figure 5-52).

Figure 5-52 Starting the Portal Framework Application

Your application is now available.

5.3.4.3 Deploying Portal Framework Application EARs using wsadmin Commands

The steps in this section recommend using Command Assistance to ascertain the correct command syntax and parameter values for application EAR file deployment. While not mandatory, Command Assistance is highly recommended when compiling scripts for lifecycle operations such as deployment.

Note:

For more information, see IBM WebSphere documentation.

1. Complete steps 1 through 5 in Section 5.3.4.2, "Deploying Portal Framework Application EARs using WebSphere Admin Console."

2. On the summary page, select View administrative scripting command for last action (Figure 5-53).

Figure 5-53 Viewing Deployment Scripting Commands

3. Copy the AdminApp.install command displayed and paste into a suitable text editor.

4. Edit the EAR file path in the copied command to match the location of your ear file.

5. Deploy your application using the wsadmin command:

1. Open the wsadmin command prompt connected to the deployment manager.

2. Paste the updated command.

3. Execute the wsadmin command.

4. Save the command.

For example:

wsadmin>AdminApp.install('/scratch/oracle/jdeveloper/mywork/PortalFwkApp/deploy/PortalFwkApp_application1.ear',
'[ -nopreCompileJSPs -distributeApp -nouseMetaDataFromBinary -deployejb -appname PortalFwkApp_application1
-createMBeansForResources -noreloadEnabled -nodeployws -validateinstall warn -noprocessEmbeddedConfig -filepermission
.\.dll=755#.\.so=755#.\.a=755#.\.sl=755 -noallowDispatchRemoteInclude  -noallowServiceRemoteInclude
-asyncRequestDispatchType DISABLED -nouseAutoLink -MapModulesToServers [[ oracle.adf.share.was.jar oracle.adf.share.was.jar,
META-INF/ejb-jar.xml WebSphere:cell=Cell1,node=Server1Node,server=WC_CustomPortal+WebSphere:cell=Cell1,
node=Server1Node,server=webserver1 ][ Jersey PortalFwkApp_webapp1.war,WEB-INF/web.xml
WebSphere:cell=Cell1,node=Server1Node,server=WC_CustomPortal+WebSphere:cell=Cell1,node=Server1Node,server=webserver1 ]]]' )
wsadmin>AdminConfig.save()

6. Start the newly deployed Portal Framework application using the IBM WebSphere Administrative Console or using wsadmin commands.
For example:

wsadmin>AdminControl.invoke('WebSphere:name=ApplicationManager,process=WC_CustomPortal,
platform=proxy,node=Server1Node,version=7.0.0.19,type=ApplicationManager,mbeanIdentifier=ApplicationManager,cell=Cell1,spec=1.0',
'startApplication', '[PortalFwkApp_application1]', '[java.lang.String]')

5.3.5 Securing a Portal Framework Application Connection to IMAP and SMTP with SSL

The steps to secure an IMAP/ SMTP connection with SSL for a Portal Framework application deployed on IBM WebSphere are slightly different to that on Oracle WebLogic Server. On WebSphere, you need to specify an additional property in the trust store—trustStoreType:

1. Follow steps in the "Securing a Portal Framework Application's Connection to IMAP and SMTP with SSL" section in Oracle Fusion Middleware Administering Oracle WebCenter Portal.

2. Add the following property to the truststore:

-Djavax.net.ssl.trustStore=C:\mail\jssecacerts
-Djavax.net.ssl.trustStorePassword=changeit
-Djavax.net.ssl.trustStoreType=JKS

For example:

set JAVA_PROPERTIES=-Dplatform.home=%WAS_HOME% -Dwls.home=%WAS_HOME%
-Dweblogic.home=%WAS_HOME%
-Djavax.net.ssl.trustStore=C:\mail\jssecacerts
-Djavax.net.ssl.trustStorePassword=changeit
-Djavax.net.ssl.trustStoreType=JKS

3. Restart the Portal Framework application.

4. Log into the application and provide your mail credentials.

5.3.6 Using the Deploy and Configure Script for Portal Framework Applications Deployed on WebSphere

During its life cycle, a typical portal is deployed to testing, staging, and production servers. Oracle WebCenter Portal provides configurable scripts (create_profile_was.csh and deploy_and_config_was.csh) that allow you to easily deploy and configure Portal Framework applications to these server instances and Oracle recommends that you use these deployment scripts rather than ojdeploy.

Note:

The deploy and configure scripts in stage2prod are samples only. You are free to develop your scripts in a different location (after copying the sample and making changes to it for your deployed environment).

The portal lifecycle and the tasks, tools, and techniques for managing a Portal Framework application deployed on WebLogic Server throughout its life cycle is described in detail in the "Understanding the WebCenter Portal Framework Application Life Cycle" section in Oracle Fusion Middleware Developing Portals with Oracle WebCenter Portal and Oracle JDeveloper. The process is largely the same for WebSphere deployments, however, the script names are different and there is WebSphere-specific content in both setup.properties and profile.properties.

To deploy and configure an application to a WebSphere using Oracle WebCenter Portal scripts:

1. In a terminal window, go to the directory that contains the deploy and configure scripts. These scripts are called: create_profile_was.csh and deploy_and_config_was.csh. These files reside in WCP_ORACLE_HOME/webcenter/scripts/stage2prod, where WCP_ORACLE_HOME is the directory where Oracle WebCenter Portal is installed.

Note:

These scripts need access to wsadmin.properties and soap.client.props files to authenticate and connect to the WebSphere deployment manager's SOAP port. Ensure that both wsadmin.properties and soap.client.props are present in the directories referenced by the scripts. For more information on how wsadmin.sh uses wsadmin.properties and soap.client.props, refer to IBM WebSphere documentation.

2. Provide target environment-specific information in the setup.properties file, such as the target server URL, user name, and password. Open the file setup.properties and add the appropriate values for the target environment. A sample file is shown in Example 5-1.

Example 5-1 Sample setup.properties File

# WebSphere Server
webcenter.app.node=DefaultCellFederatedNode

# Application
webcenter.app.name=webapp
webcenter.app.server=WC_CustomPortal
webcenter.app.version=V2.0

3. Update create_profile_was.csh and deploy_and_config_was.csh to reflect the deployed environment.

setenv WCP_ORACLE_HOME <webcenter_home>
setenv SCRIPTS_DIR <scripts_home>

WCP_ORACLE_HOME is the Oracle WebCenter Portal Home and SCRIPTS_DIR is where the scripts are located. By default, the scripts are here: $WCP_ORACLE_HOME/webcenter/scripts/stage2prod. If you copied the scripts to another location, then set SCRIPTS_DIR to that location.

4. Run the create_profile_was script. The input to this script is the setup.properites file. For example, in a Linux environment, enter:

./create_profile_was.csh

This script examines your application environment and produces an output properties file called profile.properties.

5. If you wish, rename the output file, profile.properties to a name that reflects the target environment. For example, if the target environment is your stage environment, you might call the file output file wcstage.properties.
The profile.properties file specifies all the configuration information needed to run the portal on the target environment. For example, it includes settings for the content repository, OmniPortlet, WSRP producers, personalization for Oracle WebCenter Portal and more. Example 5-2 shows a sample profile.properties file.

Example 5-2 Sample profile.properties File

webcenter.wcps.app.name=wcps-services
webcenter.wcps.app.server=WC_Utilities
doclib.Content.cis.socket.host=hostname
app.mds.jndi=jdbc/mds/SpacesDS
webcenter.app.archive=/net/hostname/scratch/webapp.ear
doclib.Content.cis.socket.port=9444
webcenter.wcps.archive=/net/hostname/scratch/wcps.mar
webcenter.app.name=webapp
app.mds.repository=mds-SpacesDS
app.mds.partition=wcps-services
webcenter.app.version=V2.0
web.OmniPortlet.url=http\://hostname\:7101/portalTools/omniPortlet/providers/omniPortlet
app.restart=false
webcenter.app.server=WC_CustomPortal
# Websphere Server SPECIFIC properties
webcenter.app.node=DefaultCellFederatedNode
webcenter.app.deployoptions=[ -nopreCompileJSPs -distributeApp
-nouseMetaDataFromBinary -nodeployejb -appname PortalApp1_application1
-createMBeansForResources -noreloadEnabled -nodeployws -validateinstall warn
-noprocessEmbeddedConfig -filepermission
.*\\.dll\=755\#.*\\.so\=755\#.*\\.a\=755\#.*\\.sl\=755
-noallowDispatchRemoteInclude -noallowServiceRemoteInclude
-asyncRequestDispatchType DISABLED -nouseAutoLink -MapResRefToEJB [[ PortalApp1_
webapp1.war "" PortalApp1_webapp1.war,WEB-INF/web.xml jdbc/WebCenterDS
javax.sql.DataSource jdbc/WebCenterDS "" "" "" ][ PortalApp1_webapp1.war ""
PortalApp1_webapp1.war,WEB-INF/web.xml jdbc/ActivitiesDS javax.sql.DataSource
jdbc/ActivitiesDS "" "" "" ]]
-MapModulesToServers [[ PortalApp1_webapp1.war PortalApp1_webapp1.war,WEB-INF/web.xml
WebSphere\:cell\=DefaultCell,node\=DefaultCellFederatedNode,server\=WC_CustomPortal]]
-MapWebModToVH [[ PortalApp1_webapp1.war PortalApp1_webapp1.war,WEB-INF/web.xml default_host

Note:

Your environment -specific values will replace the sample values shown in Example 5-2. If a property is not needed, delete it or comment it out rather than leave the value empty.

6. Run create_profile_was to create a properties file for each of your target environments. For example, you might create one each for your test, stage, and production environments.

7. Run the deploy_and_config_was script. The input to this script is the profile.properties file (or whatever you renamed the file). For example, in a Linux environment, might enter:

./deploy_and_config_was.csh wcstage.properties

The deploy_and_config_was script takes one of two "modes" as input. These modes are deploy_config and p13n_metadata. For example:

./deploy_and_config_was.csh p13n_metadata

The deploy_config mode is the default mode if no input is passed to deploy_and_config_was.csh. The deploy_config mode does the deployment and configuration tasks. If you only need to update the personalization metadata, you can override the default behavior by passing in p13n_metadata as the input to the script.

This script deploys and configures the Portal Framework applications to run on the target environment.

5.3.7 Creating SQL Data Controls for Applications Deployed on WebSphere Administration Server

If you want to build SQL data controls for WebCenter Portal or Portal Framework applications deployed on IBM WebSphere that use data sources other than the out-of-the-box data sources (WebCenter and Activities), follow the instructions here:

Note:

If the SQL data control is consumed in a task flow, the task flow displays only the first 25 rows of data. This is a known limitation.

1. Create the custom data sources manually using the IBM WebSphere Administrative Console. See Section 5.3.2.3, "Creating Database Connections to Custom Data Sources."
However, to be able to create a SQL data control from custom data source, you must configure security alias information as follows:

Setup security aliases screen:

- Component-managed authentication alias - Select the user connection alias from the Component-managed authentication alias dropdown menu.

- Container-managed authentication alias - Select none from the Container-managed authentication alias dropdown menu.

2. Assign administrator roles to users who will create data controls.
Mbeans are used to access data sources available on the IBM WebSphere Application Server. By default, global security is enabled on the server and only users assigned an administrator role can access Mbeans. Users who are not assigned an administrator role will not be able to see any data sources when they try to create a SQL data control so you must assign an administrator role to each user who may need to create SQL data controls.

To assign an administrator role to a user:

1. Log in to the IBM WebSphere Administrative Console and navigate to Security > Global Security.

2. Click the Administrative user roles link.

3. Click Add.

4. Select the role (any of deployer, operator, configurator, monitor, administrator, adminsecuritymanager, auditor) and search for the user.

5. Select the user from the Available list and move to the Mapped to role list.

6. Click OK.

5.4 Differences Managing Oracle WebCenter Portal Components on IBM WebSphere

This section includes the following topics:

- Section 5.4.1, "Running Oracle WebCenter Portal wsadmin Commands"

- Section 5.4.2, "Managing WebCenter Portal and Portal Framework Applications With Fusion Middleware Control"

- Section 5.4.3, "(WebCenter Portal Only) Migrating Portal Changes"

5.4.1 Running Oracle WebCenter Portal wsadmin Commands

All Oracle WebCenter Portal wsadmin commands have equivalent WLST (WebLogic Scripting Tool) commands which are documented in detail in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

Table 5-6 describes some general differences when running wsadmin commands on IBM WebSphere.

Table 5-6 Differences Between WebCenter wsadmin and WLST

Issue

WLST

wsadmin

Command Names

WLST commands are documented in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference. For example:

createMailConnection
setWebCenterIdStoreSearchConfig
exportWebCenterApplication

All wsadmin command names are prefixed with "WebCenter." For example:

WebCenter.createMailConnection
WebCenter.setWebCenterIdStoreSearchConfig
WebCenter.exportWebCenterApplication

Note: The WebCenter. prefix is case sensitive.

Boolean Type

You can use true/false or 1/0.

For example:

setMailConnection(appName='webcenter', name='MyMailServer', default=1)

setMailConnection(appName='webcenter', name='MyMailServer', default=true)

You must use 1/0

For example:

WebCenter.setMailConnection
(appName='webcenter', name='MyMailServer', default=1)

applicationVersion

Valid argument.

Not used.

cloneWebCenterManagedServer command

Used to clone WebLogic managed servers when setting up a cluster

Not applicable.

exportWebCenterPortalChanges

Not applicable

Exports portal metadata changes for a named portal to a portal archive (.par file).

importWebCenterPortalChanges

Not applicable

Imports portal metadata changes for a named portal from a portal archive (.par file).

Run Oracle WebCenter Portal wsadmin commands from the /common/bin directory of the Oracle WebCenter Portal home:

(UNIX) WCP_ORACLE_HOME/common/bin/wsadmin.sh
(Windows) WCP_ORACLE_HOME\common\bin\wsadmin.bat

To invoke online help for Oracle WebCenter Portal commands, enter the following:

wsadmin> print OracleHelp.help('WebCenter')

To invoke online help for a specific command, enter the command name:

wsadmin> print OracleHelp.help('WebCenter.createMailConnection')

For more information about wsadmin commands, see Section 3.1.3, "Using the Oracle Fusion Middleware wsadmin Commands."

For information about the equivalent Oracle WebCenter Portal WLST commands, see Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

5.4.2 Managing WebCenter Portal and Portal Framework Applications With Fusion Middleware Control

You can start, stop, or restart an Oracle WebCenter Portal cell and manage WebCenter Portal or Portal Framework applications deployed on IBM WebSphere with Fusion Middleware Control. The functionality is the same as that described for WebLogic deployments. The only differences are as follows:

- Navigation Tree - a WebSphere Cell folder displays in the navigation tree instead of WebLogic Domain folder.

- Home Page for WebCenter Portal (Figure 5-54)

- Related Components section - you cannot navigate directly to the WebCenter Portal application.

- Related Components section - a link to the WebSphere Cell on which the WebCenter Portal application is deployed displays instead of a WebLogic Server link.

- Home Page for Portal Framework Applications - You cannot navigate to the IBM WebSphere Administrative Console.

Figure 5-54 Fusion Middleware Control Home Page for a WebCenter Portal Deployment on IBM WebSphere

5.4.3 (WebCenter Portal Only) Migrating Portal Changes

You can export metadata changes for a named portal to a portal archive (.par file) and import them to another target.

Portal metadata changes:

- Include: new pages, page edits, page and task flow customizations (global customizations and user customizations)

- Exclude: subportals, security, any changes to content and data, user customizations to portlets

Notes:

- You can only export changes for a portal that was previously exported using the exportWebCenterPortals command.
Similarly, you can only import changes for a portal that was previously imported using the importWebCenterPortals command.

- You must have at least the Monitor role and the WebCenter Portal permission Portals - Manage All to run this command.

In the source environment, run the wsadmin command WebCenter.exportWebCenterPortalChanges to export metadata changes for a named portal to an archive:

WebCenter.exportWebCenterPortalChanges(appName, fileName, portalName, [server, applicationVersion])

In the target environment, run the command WebCenter.importWebCenterPortalChanges to import portal metadata changes from the archive:

WebCenter.importWebCenterPortalChanges(appName, fileName, [server, applicationVersion])

For command syntax, see the "exportWebCenterPortalChanges" and "importWebCenterPortalChanges" sections in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

Here is an example:

Example 1 - Exporting portal metadata changes to an archive

The following example exports metadata changes for a portal named myPortal to an archive named myPortalChangesExport.par:

exportWebCenterPortalChanges(appName='webcenter', fileName='myPortalChangesExport.par', portalName='myPortal')

Example 2 - Importing portal metadata changes from an archive

The following example imports portal metadata changes from an archive named myPortalChangesExport.par:

exportWebCenterPortalChanges(appName='webcenter', fileName='myPortalChangesExport.par')

See also, Section 5.9.14, "Error Messages Exporting and Importing Portal Changes".

5.5 Patching Oracle WebCenter Portal on IBM WebSphere from 11.1.1.7 to 11.1.1.8

To migrate an existing Oracle WebCenter Portal 11.1.1.7 installation on IBM WebSphere to WebCenter Portal version 11.1.1.8, follow these steps. Follow the same steps in a clustered WebCenter Portal environment:

1. Determine your existing Oracle Web Services Manager (OWSM) security policy URIs for WebCenter Portal, Discussions, and Portlet Producer web service end points, so you can restore the policies in your patched instance:

1. Ensure the following managed servers are up and running:
WC_Spaces - WebCenter Portal application

WC_Collaboration - Discussions application

WC_Portlet - Portlet producers, including the WebCenter Services Portlets producer

Any other custom managed servers on which custom portlet producers are deployed.

2. Connect to the Dmgr server using wsadmin:

WCP_ORACLE_HOME/common/bin/wsadmin.sh -conntype SOAP -user <admin username> -password <password> -port <admin SOAP port> -host <Dmgr host>

3. To determine the policy used by the WebCenter Portal application, run the following command:

WebServices.listWebServicePolicies(application='/Node_name/WC_Spaces/webcenter', moduleOrCompName='webcenter', moduleType='web',
serviceName='SpacesWebService', subjectName='SpacesWebServiceSoapHttpPort')

Where, Node_name refers to the name of the node in which the server is running, and WC_Spaces is the name of the managed server on which the WebCenter Portal application is deployed. The other parameters are all fixed.

If you are using the out-of-the-box OWSM security policy, the command displays information in the following format:

SpacesWebServiceSoapHttpPort :security : oracle/wss11_saml_or_username_token_with_message_protection_service_policy, enabled=true
Attached policy or policies are valid; endpoint is secure.

Note down the security policy name highlighted in bold so you can restore the setting after patching your instance.

4. To determine the policy used by the discussions application, run the following command:

WebServices.listWebServicePolicies(application='/Node_name/WC_Collaboration/owc_discussions_11.1.1.4.0', moduleOrCompName='owc_discussions', moduleType='web',
serviceName='OWCDiscussionsServiceAuthenticated', subjectName='OWCDiscussionsServiceAuthenticated')

Where, Node_name refers to the name of the node in which the server is running, and WC_Collaboration is the name of the managed server on which discussions server is deployed. The other parameters are all fixed.

If you are using the out-of-the-box OWSM security policy, the command's result is of the following format:

OWCDiscussionsServiceAuthenticated :security : oracle/wss10_saml_token_service_policy, enabled=true
Attached policy or policies are valid; endpoint is secure.

Note down the security policy URI highlighted in bold so you can restore the setting after patching your instance.

5. To determine the policy used by the WebCenter Services Portlets producer, run the following command:

WebServices.listWebServicePolicies(application='/Node_name/WC_Portlet/services-producer', moduleOrCompName='services-producer',
moduleType='web', serviceName='WSRP_v2_Service', subjectName='WSRP_v2_Markup_Service')

Where, Node_name refers to the name of the node in which the server is running, and WC_Portlet is the name of the managed server on which this producer is deployed. The other parameters are all fixed.

The WebCenter Services Portlets producer is available out-of-the-box from WebCenter Portal release 11.1.1.6.0 onward. If this producer is deployed in your instance, run the command above and note down the security policy URI displayed so you can restore the setting after patching your instance.

6. For any custom portlet producers deployed in your instance, run the following command:

WebServices.listWebServicePolicies(application='/Node_name/WC_Portlet/TestJSR286#1.0', moduleOrCompName='TestJSR286',
moduleType='web',serviceName='WSRP_v2_Service', subjectName='WSRP_v2_Markup_Service')

Where, Node_name refers to the name of the node in which the server is running and WC_Portlet is the name of the managed server on which the producer is deployed, and the custom portlet producer is named TestJSR286 (version 1.0). The other parameters are all fixed.

You may have various custom portlet producers deployed in your WebCenter Portal instance that have Oracle WSM security policies attached to web service end points (WSRP_v2_Markup_Service). If you intend to redeploy the custom portlet producers after patching your instance, note down the security policy URI (highlighted in bold) for each custom portlet producer so you can restore the security setting after patching.

The following is a sample output for the command:

WSRP_v2_Markup_Service :
security : oracle/wss10_saml_token_service_policy, enabled=true
Attached policy or policies are valid; endpoint is secure.

2. Stop the IBM WebSphere deployment manager, node managers, and all the server processes.
For more information, see Section 3.2.2, "Starting and Stopping Servers on IBM WebSphere."

3. Back up your existing Oracle WebCenter Portal instance (or clustered Oracle WebCenter Portal instance).
Follow your usual back up process. For example, if you are running Linux and the /scratch/WAS directory contains your IBM WebSphere and Oracle WebCenter Portal installation, you can use the tar utility as follows:

sudo su

tar -cvhf backup-#DATE#.tar /scratch/WAS

4. Back up your existing database and database schemas.
See also, the "Backing Up Your Database and Database Schemas" section in Oracle Fusion Middleware Patching Guide.

5. Install Oracle WebCenter Portal 11.1.1.8 into your existing Oracle Middleware home (11.1.1.7):

1. Download and install WebCenter Portal, as described in Chapter 2, "Installing and Configuring Oracle Fusion Middleware on IBM WebSphere."

2. Ensure that Oracle Middleware Home, specifies your existing install location.

3. Click Yes when asked to confirm that you want to upgrade your existing Oracle Middleware Home (Figure 5-55).

Figure 5-55 Upgrade Existing Oracle WebCenter Portal Installation

4. Complete the installation (screens 5 to 8).

Note:

If the Oracle WebCenter Portal instance is part of a cluster, perform the install step on each node where Oracle WebCenter Portal is installed. The deployment manager will push out application changes to the other nodes using the node agent, and application redeployment will take place when the other nodes and server are restarted.

6. Use the Patch Set Assistant to update all the required schemas, including WEBCENTER, MDS, ACTIVITIES, DISCUSSIONS, and DISCUSSIONS_CRAWLER schemas.
To determine which schemas you need to patch, refer to the "Which Schemas Need to be Updated with Patch Set Assistant?" section in Oracle Fusion Middleware Patching Guide.

Before running Patch Set Assistant, you should check to make sure that your database is up and running and that the schema you want to upgrade is at the version supported for upgrade. See also the "Which Schemas Need to be Updated with Patch Set Assistant?" section in Oracle Fusion Middleware Patching Guide.

7. Start the upgraded IBM WebSphere deployment manager and node agent.
On a Linux installation for example, where the IBM WebSphere profile's manager is named "Manager" and the node agent is named "Server1", enter:

/scratch/WAS/WebSphere/AppServer/profiles/Manager/bin/startManager.sh

/scratch/WAS/WebSphere/AppServer/profiles/Server1/bin/startNode.sh

For detail, see Section 2.7, "Task 7: Start the IBM WebSphere Servers."

Note:

In a clustered environment, start the node agent on each node in the cluster.

8. Upgrade all the shared libraries and the policy store:

1. Delete all .class files in WCP_Oracle_Home/common/wsadmin and WCP_Oracle_Home/common/script_handlers.
For example:

cd <WCP_Oracle_Home>/common/wsadmin
rm -rf *.class
cd <WCP_Oracle_Home>/common/script_handlers
rm -rf *.class

2. Connect to the Dmgr server using wsadmin:

WCP_ORACLE_HOME/common/bin/wsadmin.sh -conntype SOAP -user <admin username> -password <password> -port <admin SOAP port> -host <Dmgr host>

3. Run the WebCenter.upgradeSharedLibraries wsadmin command to upgrade the required shared libraries:

WebCenter.upgradeSharedLibraries()

4. Run the WebCenter.upgradeWebCenterPermissions wsadmin command to update the policy store:

WebCenter.upgradeWebCenterPermissions()

9. Redeploy the enterprise applications listed in Table 5-7 to the specified locations.

Note:

You can ignore applications that are not deployed in your existing Oracle WebCenter Portal 11.1.1.7.0 installation.

Table 5-7 Enterprise Applications Requiring Redeployment

Application Name

Application EAR Location

DMS Application 11.1.1.1.0

MW_HOME/oracle_common/modules/oracle.dms_11.1.1/dms-was.ear

FMW Welcome Page Application_11.1.0.0.0

MW_HOME/oracle_common/modules/oracle.jrf_11.1.1/fmw-welcome.ear

Dmgr DMS Application 11.1.1.1.0

MW_HOME/oracle_common/modules/oracle.dms_11.1.1/dms-was.ear

activitygraph-engines 11.1.1.4.0

MW_HOME/WCP_ORACLE_HOME/activitygraph/archives/applications/activityGraph-engines-was.ear

analytics-collector 11.1.1.4.0

MW_HOME/WCP_ORACLE_HOME/analytics-collector/archives/applications/analytics-collector-jee-was.ear

em

MW_HOME/oracle_common/sysman/archives/fmwctrl/app/em.ear

owc_discussions 11.1.1.4.0

MW_HOME/WCP_ORACLE_HOME/discussionserver/owc_discussions-was.ear

pagelet-producer 11.1.1.6.0

MW_HOME/WCP_ORACLE_HOME/ensemble/archives/applications/pagelet-producer-was.ear

portalTools

MW_HOME/WCP_ORACLE_HOME/webcenter/modules/oracle.portlet.server_11.1.1/portalTools.ear

services-producer

MW_HOME/WCP_ORACLE_HOME/webcenter/archives/services-producer-was.ear

wcps-services 11.1.1.4.0

MW_HOME/WCP_ORACLE_HOME/wcps-services-app/archives/applications/wcps-services-was.ear

webcenter

MW_HOME/WCP_ORACLE_HOME/archives/applications/webcenter-was.ear

webcenter-help

MW_HOME/WCP_ORACLE_HOME/archives/applications/webcenter-help-was.ear

wsil-nonwls

MW_HOME/oracle_common/modules/oracle.webservices_11.1.1/wsil-nonwls.ear

wsm-pm

MW_HOME/oracle_common/modules/oracle.wsm.pm_11.1.1/wsm-pm-was.ear

wsrp-tools

MW_HOME/WCP_ORACLE_HOME/webcenter/modules/oracle.portlet.server_11.1.1/wsrp-tools-was.ear

To redeploy applications, follow these steps:

1. Log in to the IBM Administrative Console.

2. Navigate to Applications> Application Types> WebSphere Enterprise Applications.

3. Select the name of the application you want to redeploy, for example DMS Application 11.1.1.1.0 and click Update (Figure 5-56).

Figure 5-56 Update Enterprise Application Deployment

4. In the Application Update Options screen, select Replace the entire application, and then enter the full path to the EAR file in the Remote file system (Figure 5-57).
For example, if your MW_HOME is /scratch/WAS/Middleware, enter /scratch/WAS/Middleware/oracle_common/modules/oracle.dms_11.1.1/dms-was.ear.

Figure 5-57 Application Upgrade - Specify Full Path to Application EAR File

5. Click Next.

6. In the Preparing for the Application Updates screen, keep the defaults and click Next (Figure 5-58).

Figure 5-58 Application Upgrade - Preparing for the Application Update Screen

7. In the Select Installation Options screen, keep the defaults, and click Next (Figure 5-59).

Figure 5-59 Application Upgrade - Select Installation Options Screen

8. In the Map Modules to Servers screen, keep the defaults, and click Next (Figure 5-60).

Figure 5-60 Application Upgrade - Map to Modules Screen

9. In the Summary screen, keep the defaults, and click Finish.
Installation progress messages are displayed (Figure 5-61).

Figure 5-61 Application Upgrade - Application Installed Successfully

10. Click Save.

11. Repeat step 6 for each application in Table 5-7 that you need to redeploy.

10. Update the security role mapping of the wsm-pm application.
When you redeploy the wsm-pm application some required security role mapping configuration is lost which you need to re-apply as follows:

1. Log in to the IBM Administrative Console.

2. Navigate to Applications> Application Types> WebSphere Enterprise Applications.

3. Select the wsm-pm application link.

4. Select Security role to user/group mapping.

Figure 5-62 Update Security Role Mapping for wsm-pm

5. Select policy.Accessor, policy.Updater, policy.User roles as shown in Figure 5-63.
These three roles must be mapped to the same users as policyViewer.

You do not need to map users to policyQuerier.

Figure 5-63 Map Security Roles for wsm-pm

6. Select Map Users, and map the same users as policyViewer.
In the example shown (Figure 5-63), the administrative user for policyViewer is orcladmin.

7. Click OK.

11. Restore the Oracle Web Services Manager (OWSM) security policies settings that you recorded earlier in Step 1:

1. Ensure the WC_Spaces, WC_Collaboration, and WC_Portlet managed servers are running.
If custom portlet producers are deployed to any custom managed servers, ensure those servers are also up and running.

2. Connect to the Dmgr server using wsadmin:

WCP_ORACLE_HOME/common/bin/wsadmin.sh -conntype SOAP -user <admin username> -password <password> -port <admin SOAP port> -host <Dmgr host>

3. Run the following command to attach the Oracle WSM security policy to the web service endpoint (SpacesWebService):

WebServices.attachWebServicePolicy(applicaton='webcenter', moduleOrCompName='webcenter', moduleType='web', serviceName'SpacesWebService', 'SpacesWebServiceSoapHttpPort',
policyURI='oracle/wss11_saml_or_username_token_with_message_protection_service_policy')

Where oracle/wss11_saml_or_username_token_with_message_protection_service_policy is the policy setting you recorded in Step 1c.

4. Run the following command to attach the Oracle WSM security policy to the web service endpoint (OWCDiscussionsServiceAuthenticated) for discussions:

WebServices.attachWebServicePolicy(applicaton='owc_discussions_11.1.1.4.0', moduleOrCompName='owc_discussions', moduleType='web',  serviceName='OWCDiscussionsServiceAuthenticated',
subjectName='OWCDiscussionsServiceAuthenticated', policyURI='oracle/wss10_saml_token_service_policy')

Where oracle/wss10_saml_token_service_policy is the policy setting you recorded in Step 1d.

5. Run the following command to attach the Oracle WSM security policy to the web service endpoint (services-producer) for the WebCenter Services Portlets producer:

WebServices.attachWebServicePolicy(applicaton='services-producer', moduleOrCompName='services-producer', moduleType='web',
serviceName='WSRP_v2_Service', subjectName='WSRP_v2_Markup_Service', policyURI='oracle/wss10_saml_token_service_policy')

Where oracle/wss10_saml_token_service_policy is the policy setting you recorded in Step 1e.

Note:

This step is required only if you are patching from release 11.1.1.6.0, and the WebCenter Services Portlets producer is deployed.

6. Run the following command to attach the Oracle WSM security policy to the web service endpoint (WSRP_v2_Markup_Service) for a custom portlet producer, for example, if your portlet producer's name is TestJSR286, and it is deployed to the WC_Portlet managed server with version 1.0, run the following command:

WebServices.attachWebServicePolicy(applicaton='TestJSR286#1.0', moduleOrCompName='TestJSR286', moduleType='web',
serviceName='WSRP_v2_Service', subjectName='WSRP_v2_Markup_Service', policyURI='oracle/wss10_saml_token_service_policy')

Where oracle/wss10_saml_token_service_policy is the policy setting you recorded in Step 1f.

Note:

This step is required only if any custom portlet producers are deployed in your WebCenter Portal environment. You must run the WebServices.attachWebServicePolicy command for each custom portlet producer separately.

12. Set unique cookie paths for WebCenter Portal and Portal Framework applications.
For details, see Section 5.2.11, "Setting Cookie Paths for WebCenter Portal and Portal Framework Application Modules Post Deployment."

13. Restart all the servers, including the node manager in IBM WebSphere to effect the security mapping updates.

5.6 Patching Oracle WebCenter Portal on IBM WebSphere from 11.1.1.6 to 11.1.1.8

To migrate an existing Oracle WebCenter Portal 11.1.1.6 installation on IBM WebSphere to WebCenter Portal version 11.1.1.8, follow these steps. Follow the same steps in a clustered WebCenter Portal environment:

1. Determine your existing Oracle Web Services Manager (OWSM) security policy URIs for WebCenter Portal, Discussions, and Portlet Producer web service end points, so you can restore the policies in your patched instance:

1. Ensure the following managed servers are up and running:
WC_Spaces - WebCenter Portal application

WC_Collaboration - Discussions application

WC_Portlet - Portlet producers, including the WebCenter Services Portlets producer

Any other custom managed servers on which custom portlet producers are deployed.

2. Connect to the Dmgr server using wsadmin:

WCP_ORACLE_HOME/common/bin/wsadmin.sh -conntype SOAP -user <admin username> -password <password> -port <admin SOAP port> -host <Dmgr host>

3. To determine the policy used by the WebCenter Portal application, run the following command:

WebServices.listWebServicePolicies(application='/Node_name/WC_Spaces/webcenter', moduleOrCompName='webcenter',
moduleType='web', serviceName='SpacesWebService', subjectName='SpacesWebServiceSoapHttpPort')

Where, Node_name refers to the name of the node in which the server is running, and WC_Spaces is the name of the managed server on which the WebCenter Portal application is deployed. The other parameters are all fixed.

If you are using the out-of-the-box OWSM security policy, the command displays information in the following format:

SpacesWebServiceSoapHttpPort :security : oracle/wss11_saml_or_username_token_with_message_protection_service_policy, enabled=true
Attached policy or policies are valid; endpoint is secure.

Note down the security policy name highlighted in bold so you can restore the setting after patching your instance.

4. To determine the policy used by the discussions application, run the following command:

WebServices.listWebServicePolicies(application='/Node_name/WC_Collaboration/owc_discussions_11.1.1.4.0', moduleOrCompName='owc_discussions', moduleType='web',
serviceName='OWCDiscussionsServiceAuthenticated', subjectName='OWCDiscussionsServiceAuthenticated')

Where, Node_name refers to the name of the node in which the server is running, and WC_Collaboration is the name of the managed server on which discussions server is deployed. The other parameters are all fixed.

If you are using the out-of-the-box OWSM security policy, the command's result is of the following format:

OWCDiscussionsServiceAuthenticated :security : oracle/wss10_saml_token_service_policy, enabled=true
Attached policy or policies are valid; endpoint is secure.

Note down the security policy URI highlighted in bold so you can restore the setting after patching your instance.

5. To determine the policy used by the WebCenter Services Portlets producer, run the following command:

WebServices.listWebServicePolicies(application='/Node_name/WC_Portlet/services-producer', moduleOrCompName='services-producer',
moduleType='web', serviceName='WSRP_v2_Service', subjectName='WSRP_v2_Markup_Service')

Where, Node_name refers to the name of the node in which the server is running, and WC_Portlet is the name of the managed server on which this producer is deployed. The other parameters are all fixed.

The WebCenter Services Portlets producer is available out-of-the-box from WebCenter Portal release 11.1.1.6.0 onward. If this producer is deployed in your instance, run the command above and note down the security policy URI displayed so you can restore the setting after patching your instance.

6. For any custom portlet producers deployed in your instance, run the following command:

WebServices.listWebServicePolicies(application='/Node_name/WC_Portlet/TestJSR286#1.0', moduleOrCompName='TestJSR286',
moduleType='web',serviceName='WSRP_v2_Service', subjectName='WSRP_v2_Markup_Service')

Where, Node_name refers to the name of the node in which the server is running and WC_Portlet is the name of the managed server on which the producer is deployed, and the custom portlet producer is named TestJSR286 (version 1.0). The other parameters are all fixed.

You may have various custom portlet producers deployed in your WebCenter Portal instance that have Oracle WSM security policies attached to web service end points (WSRP_v2_Markup_Service). If you intend to redeploy the custom portlet producers after patching your instance, note down the security policy URI (highlighted in bold) for each custom portlet producer so you can restore the security setting after patching.

The following is a sample output for the command:

WSRP_v2_Markup_Service :
security : oracle/wss10_saml_token_service_policy, enabled=true
Attached policy or policies are valid; endpoint is secure.

2. Stop the IBM WebSphere deployment manager, node managers, and all the server processes.
For more information, see Section 3.2.2, "Starting and Stopping Servers on IBM WebSphere."

3. Back up your existing Oracle WebCenter Portal instance (or clustered Oracle WebCenter Portal instance).
Follow your usual back up process. For example, if you are running Linux and the /scratch/WAS directory contains your IBM WebSphere and Oracle WebCenter Portal installation, you can use the tar utility as follows:

sudo su

tar -cvhf backup-#DATE#.tar /scratch/WAS

4. Back up your existing database and database schemas.
See also, the "Backing Up Your Database and Database Schemas" section in Oracle Fusion Middleware Patching Guide.

5. Install Oracle WebCenter Portal 11.1.1.8 into your existing Oracle Middleware home (11.1.1.6):

1. Download and install WebCenter Portal, as described in Chapter 2, "Installing and Configuring Oracle Fusion Middleware on IBM WebSphere."

2. Ensure that Oracle Middleware Home, specifies your existing install location.

3. Click Yes when asked to confirm that you want to upgrade your existing Oracle Middleware Home (Figure 5-55).

Figure 5-64 Upgrade Existing Oracle WebCenter Portal Installation

4. Complete the installation (screens 5 to 8).

Note:

If the Oracle WebCenter Portal instance is part of a cluster, perform the install step on each node where Oracle WebCenter Portal is installed. The deployment manager will push out application changes to the other nodes using the node agent, and application redeployment will take place when the other nodes and server are restarted.

6. Use the Patch Set Assistant to update all the required schemas, including WEBCENTER, ACTIVITIES, DISCUSSIONS, and DISCUSSIONS_CRAWLER schemas.
To determine which schemas you need to patch, refer to the "Which Schemas Need to be Updated with Patch Set Assistant?" section in Oracle Fusion Middleware Patching Guide.

Before running Patch Set Assistant, you should check to make sure that your database is up and running and that the schema you want to upgrade is at the version supported for upgrade. See also, the "Which Schemas Need to be Updated with Patch Set Assistant?" section in Oracle Fusion Middleware Patching Guide.

7. Start the upgraded IBM WebSphere deployment manager and node agent.
On a Linux installation for example, where the IBM WebSphere profile's manager is named "Manager" and the node agent is named "Server1", enter:

/scratch/WAS/WebSphere/AppServer/profiles/Manager/bin/startManager.sh

/scratch/WAS/WebSphere/AppServer/profiles/Server1/bin/startNode.sh

For detail, see Section 2.7, "Task 7: Start the IBM WebSphere Servers."

Note:

In a clustered environment, start the node agent on each node in the cluster.

8. Upgrade all the shared libraries and the policy store:

1. Delete all .class files in WCP_Oracle_Home/common/wsadmin and WCP_Oracle_Home/common/script_handlers.
For example:

cd <WCP_Oracle_Home>/common/wsadmin
rm -rf *.class
cd <WCP_Oracle_Home>/common/script_handlers
rm -rf *.class

2. Connect to the Dmgr server using wsadmin:

WCP_ORACLE_HOME/common/bin/wsadmin.sh -conntype SOAP -user <admin username> -password <password> -port <admin SOAP port> -host <Dmgr host>

3. Run the WebCenter.upgradeSharedLibraries wsadmin command:

WebCenter.upgradeSharedLibraries()

4. Update the policy store

WebCenter.upgradeWebCenterPermissions()

9. Redeploy the enterprise applications listed in Table 5-7 to the specified locations.

Note:

You can ignore applications that are not deployed in your existing Oracle WebCenter Portal 11.1.1.6.0 installation.

Table 5-8 Enterprise Applications Requiring Redeployment

Application Name

Application EAR Location

DMS Application 11.1.1.1.0

MW_HOME/oracle_common/modules/oracle.dms_11.1.1/dms-was.ear

FMW Welcome Page Application_11.1.0.0.0

MW_HOME/oracle_common/modules/oracle.jrf_11.1.1/fmw-welcome.ear

Dmgr DMS Application 11.1.1.1.0

MW_HOME/oracle_common/modules/oracle.dms_11.1.1/dms-was.ear

activitygraph-engines 11.1.1.4.0

MW_HOME/WCP_ORACLE_HOME/activitygraph/archives/applications/activityGraph-engines-was.ear

analytics-collector 11.1.1.4.0

MW_HOME/WCP_ORACLE_HOME/analytics-collector/archives/applications/analytics-collector-jee-was.ear

em

MW_HOME/oracle_common/sysman/archives/fmwctrl/app/em.ear

owc_discussions 11.1.1.4.0

MW_HOME/WCP_ORACLE_HOME/discussionserver/owc_discussions-was.ear

pagelet-producer 11.1.1.6.0

MW_HOME/WCP_ORACLE_HOME/ensemble/archives/applications/pagelet-producer-was.ear

portalTools

MW_HOME/WCP_ORACLE_HOME/webcenter/modules/oracle.portlet.server_11.1.1/portalTools.ear

services-producer

MW_HOME/WCP_ORACLE_HOME/webcenter/archives/services-producer-was.ear

wcps-services 11.1.1.4.0

MW_HOME/WCP_ORACLE_HOME/wcps-services-app/archives/applications/wcps-services-was.ear

webcenter

MW_HOME/WCP_ORACLE_HOME/archives/applications/webcenter-was.ear

webcenter-help

MW_HOME/WCP_ORACLE_HOME/archives/applications/webcenter-help-was.ear

wsil-nonwls

MW_HOME/oracle_common/modules/oracle.webservices_11.1.1/wsil-nonwls.ear

wsm-pm

MW_HOME/oracle_common/modules/oracle.wsm.pm_11.1.1/wsm-pm-was.ear

wsrp-tools

MW_HOME/WCP_ORACLE_HOME/webcenter/modules/oracle.portlet.server_11.1.1/wsrp-tools-was.ear

To redeploy applications, follow these steps:

1. Log in to the IBM Administrative Console.

2. Navigate to Applications> Application Types> WebSphere Enterprise Applications.

3. Select the name of the application you want to redeploy, for example DMS Application 11.1.1.1.0 and click Update (Figure 5-56).

Figure 5-65 Update Enterprise Application Deployment

4. In the Application Update Options screen, select Replace the entire application, and then enter the full path to the EAR file in the Remote file system (Figure 5-57).
For example, if your MW_HOME is /scratch/WAS/Middleware, enter /scratch/WAS/Middleware/oracle_common/modules/oracle.dms_11.1.1/dms-was.ear.

Figure 5-66 Application Upgrade - Specify Full Path to Application EAR File

5. Click Next.

6. In the Preparing for the Application Updates screen, keep the defaults and click Next (Figure 5-58).

Figure 5-67 Application Upgrade - Preparing for the Application Update Screen

7. In the Select Installation Options screen, keep the defaults, and click Next (Figure 5-59).

Figure 5-68 Application Upgrade - Select Installation Options Screen

8. In the Map Modules to Servers screen, keep the defaults, and click Next (Figure 5-60).

Figure 5-69 Application Upgrade - Map to Modules Screen

9. In the Summary screen, keep the defaults, and click Finish.
Installation progress messages are displayed (Figure 5-61).

Figure 5-70 Application Upgrade - Application Installed Successfully

10. Click Save.

11. Repeat step 6 for each application in Table 5-7 that you need to redeploy.

10. Update the security role mapping of the wsm-pm application.
When you redeploy the wsm-pm application some required security role mapping configuration is lost which you need to re-apply as follows:

1. Log in to the IBM Administrative Console.

2. Navigate to Applications> Application Types> WebSphere Enterprise Applications.

3. Select the wsm-pm application link.

4. Select Security role to user/group mapping.

Figure 5-71 Update Security Role Mapping for wsm-pm

5. Select policy.Accessor, policy.Updater, policy.User roles as shown in Figure 5-63.
These three roles must be mapped to the same users as policyViewer.

You do not need to map users to policyQuerier.

Figure 5-72 Map Security Roles for wsm-pm

6. Select Map Users, and map the same users as policyViewer.
In the example shown (Figure 5-63), the administrative user for policyViewer is orcladmin.

7. Click OK.

11. Restore the Oracle Web Services Manager (OWSM) security policies settings that you recorded earlier in Step 1:

1. Ensure the WC_Spaces, WC_Collaboration, and WC_Portlet managed servers are running.
If custom portlet producers are deployed to any custom managed servers, ensure those servers are also up and running.

2. Connect to the Dmgr server using wsadmin:

WCP_ORACLE_HOME/common/bin/wsadmin.sh -conntype SOAP -user <admin username> -password <password> -port <admin SOAP port> -host <Dmgr host>

3. Run the following command to attach the Oracle WSM security policy to the web service endpoint (SpacesWebService) for WebCenter Portal:

WebServices.attachWebServicePolicy(applicaton='webcenter', moduleOrCompName='webcenter', moduleType='web',
serviceName'SpacesWebService', 'SpacesWebServiceSoapHttpPort', policyURI='oracle/wss11_saml_or_username_token_with_message_protection_service_policy')

Where oracle/wss11_saml_or_username_token_with_message_protection_service_policy is the policy setting you recorded in Step 1c.

4. Run the following command to attach the Oracle WSM security policy to the web service endpoint (OWCDiscussionsServiceAuthenticated) for discussions:

WebServices.attachWebServicePolicy(applicaton='owc_discussions_11.1.1.4.0', moduleOrCompName='owc_discussions', moduleType='web',
serviceName='OWCDiscussionsServiceAuthenticated', subjectName='OWCDiscussionsServiceAuthenticated', policyURI='oracle/wss10_saml_token_service_policy')

Where oracle/wss10_saml_token_service_policy is the policy setting you recorded in Step 1d.

5. Run the following command to attach the Oracle WSM security policy to the web service endpoint (services-producer) for the WebCenter Services Portlets producer:

WebServices.attachWebServicePolicy(applicaton='services-producer', moduleOrCompName='services-producer', moduleType='web',
serviceName='WSRP_v2_Service', subjectName='WSRP_v2_Markup_Service', policyURI='oracle/wss10_saml_token_service_policy')

Where oracle/wss10_saml_token_service_policy is the policy setting you recorded in Step 1e.

Note:

This step is required only if you are patching from release 11.1.1.6.0, and the WebCenter Services Portlets producer is deployed.

6. Run the following command to attach the Oracle WSM security policy to the web service endpoint (WSRP_v2_Markup_Service) for a custom portlet producer, for example, if your portlet producer's name is TestJSR286, and it is deployed to the WC_Portlet managed server with version 1.0, run the following command:

WebServices.attachWebServicePolicy(applicaton='TestJSR286#1.0', moduleOrCompName='TestJSR286', moduleType='web',
serviceName='WSRP_v2_Service', subjectName='WSRP_v2_Markup_Service', policyURI='oracle/wss10_saml_token_service_policy')

Where oracle/wss10_saml_token_service_policy is the policy setting you recorded in Step 1f.

Note:

This step is required only if any custom portlet producers are deployed in your WebCenter Portal environment. You must run the WebServices.attachWebServicePolicy command for each custom portlet producer separately.

12. Run the ADFAdmin.updateADFLibrary wsadmin command to add the Batik SVG libraries to the ADF View JRF classpath and the Apache JARs to the application classpath. The Apache JARs are required for remote ADF task flows:

ADFAdmin.updateADFLibrary('DefaultCell', 'DefaultCellFederatedNode', OracleAdminServer')

13. Set unique cookie paths for WebCenter Portal and Portal Framework applications.
For details, see Section 5.2.11, "Setting Cookie Paths for WebCenter Portal and Portal Framework Application Modules Post Deployment."

14. Restart all the servers, including the node manager in IBM WebSphere to effect the security mapping updates.

5.7 Upgrading WebCenter Portal Framework Applications to 11.1.1.8

After migrating to WebCenter Portal 11.1.1.8, follow the steps in this section to upgrade your existing Portal Framework application deployments:

1. Upgrade JDeveloper and WebCenter Portal's Extension for Oracle JDeveloper to 11.1.1.8.

2. Open the Portal Framework application that you wish to upgrade in JDeveloper.

3. In JDeveloper, repackage the Portal Framework application in an EAR file.

4. Redeploy the EAR to IBM WebSphere, overwriting your existing deployment.

5. To ensure that the Portal Framework application always redirects to the home page after log in, set up a custom filter for the Web Container that processes log in requests:

1. Log on to the IBM WebSphere console.

2. Select Servers > Application Servers > server_name > Web Container settings > Web Container.

3. Under Additional Properties select Custom Properties.

4. On the Custom Properties page, click New.

5. On the settings page, enter Name and Value as follows:
Name: com.ibm.ws.webcontainer.invokeFiltersCompatibility

Value: true

6. Click OK.

7. Click Save on the console task bar.

8. Restart the server.

For detailed information on any of these steps, see Oracle Fusion Middleware Developing Portals with Oracle WebCenter Portal and Oracle JDeveloper.

5.8 Restrictions Using Oracle WebCenter Portal on WebSphere

This section describes Oracle WebCenter Portal features that are not supported on WebSphere. It contains the following topics:

- Oracle WebCenter Adapter for SharePoint Not Supported on WebSphere

- Process Spaces Not Supported on WebSphere

- Activity Rank for Oracle Secure Enterprise Search Not Supported on WebSphere

- Web Clipping Portlet Not Supported on WebSphere

5.8.1 Oracle WebCenter Adapter for SharePoint Not Supported on WebSphere

You cannot connect WebCenter Portal or Portal Framework application deployments on IBM WebSphere to Microsoft Sharepoint repositories.

5.8.2 Process Spaces Not Supported on WebSphere

The Oracle BPM Process Spaces workspace is not supported on IBM WebSphere for this release (11.1.1.7.0).

5.8.3 Activity Rank for Oracle Secure Enterprise Search Not Supported on WebSphere

The use of activity graph ranking to improve the relevancy of Oracle Secure Enterprise Search results is unavailable on IBM WebSphere deployments.

5.8.4 Web Clipping Portlet Not Supported on WebSphere

The Web Clipping portlet is not supported on IBM WebSphere. The Web Clipping portlet must be deployed and run on an Oracle WebLogic Server.

5.9 Troubleshooting Oracle WebCenter Portal on WebSphere

Use the information in this section to help troubleshoot issues with Oracle WebCenter Portal on WebSphere. It contains the following topics:

- Diagnosing java.lang.RuntimeException or java.lang.NullPointerException

- Connection Timeout Errors

- Session Timeouts in WebCenter Portal

- Session Timeouts Due to Inactivity

- Access Denied Error When Importing WebCenter Portal

- Users Can Log In With Old Passwords

- WASX7015E: NameError Exception Running WSADMIN Commands

- Unable to Deploy WebCenter Portal Workflows When the SOA MDS Schema is Running on DB2

- HTTP 500 Error Accessing Portal Workflow Notifications in the Worklist Task Flow

- OAM Single Sign-On Logout Not Working

- Workflow Related Error Messages in Log Files

- jiveURL Error Messages in Log Files

- DCS Stack Messages in Log Files

5.9.1 Diagnosing java.lang.RuntimeException or java.lang.NullPointerException

If you attempt to access WebCenter Portal or a Portal Framework application that is not yet connected to an identity store, one of the following error messages display:

Caused by: java.lang.RuntimeException: User Principal could not be found forauthenticated user.
at oracle.webcenter.framework.service.Utility.getUserName

Caused by: java.lang.NullPointerException
at
oracle.webcenter.framework.service.Utility$1.run(Utility.java:1023)
at
oracle.webcenter.framework.service.Utility$1.run(Utility.java:1020)
at java.security.AccessController.doPrivileged(AccessController.java:251

You must install and configure an LDAP ID store for your application. For more information, see Section 5.2.6, "Installing External LDAP ID Store for WebCenter Portal or Portal Framework Applications."

5.9.2 Connection Timeout Errors

If your application is processing large data sets you might experience timeout errors. To prevent frequent timeouts, consider increasing the requestTimeout property for wsadmin commands and for Enterprise Manager.

The default timeout values are as follows:

- For the call from the wsadmin environment to the deployment manager. The default for is 180 seconds.

- For the connection between the deployment manager and the node agent, the default is 600 seconds.

- For the connection between the node agent and the runtime deployment target, the default is 600 seconds.

To modify the com.ibm.SOAP.requestTimeout property for wsadmin commands:

1. Edit the Deployment Manager soap.client.props file.

2. Modify the com.ibm.SOAP.requestTimeout value. Enter a value in seconds.
For example, enter 18000 for a 5 hour timeout.

3. Restart Deployment Manager.

4. Restart the OracleAdminServer.

To modify the Request Timeout for Enterprise Manager:

1. Log in to the IBM Administrative Console.

2. Navigate to: Servers> Server Types> WebSphere application servers> OracleAdminServer> Container Settings> Container Services> ORB service

3. Update the value for "Request timeout"

4. Restart the OracleAdminServer.

5.9.3 Session Timeouts in WebCenter Portal

Two different settings drive the session timeout in a WebCenter Portal:

- Global timeout (LTPA timeout property)

- Application timeout (Session Timeout property. Out-of-the-box, the session timeout is 45 minutes.)

The lowest of these two values determine the session timeout that is used.

Oracle recommends that you set the global LTPA timeout to be a minute longer than the WebCenter Portal session timeout so that users automatically navigate to the WebCenter Portal session timeout page.

To set the LTPA timeout:

1. Determine the current session timeout value by navigating to the WebCenter Portal Administration> Configuration> General page.
See also, the "Setting Session Timeout Settings" section in Oracle Fusion Middleware Using Oracle WebCenter Portal.

2. Log in to the IBM Administrative Console.

3. Navigate to: Security> Global Security> LTPA

4. Set LTPA timeout (Figure 5-73).

Figure 5-73 LTPA Timeout

5. Restart the servers.

5.9.4 Session Timeouts Due to Inactivity

By default, application modules deployed on IBM WebSphere have their cookie path set to "/". If one or more WAR modules running on the same server as WebCenter Portal or your Portal Framework application's WAR have the same cookie path, you may encounter the following message:

Because of inactivity, your session has timed out and is no longer active. Click OK to reload page

If you encounter such messages, specify a unique cookie path for each application WAR.

For example, if WebCenter Portal is using portal membership workflows and these workflows are deployed on a SOA server that is in the same cell as WebCenter Portal, you must update the cookie path for the JSessionID cookie to match the module name. In this case the module name is WebCenterWorklistDetail, so set the "Cookie Path" property to /WebCenterWorklistDetail.

For detailed steps, see Section 5.2.11, "Setting Cookie Paths for WebCenter Portal and Portal Framework Application Modules Post Deployment."

5.9.5 Access Denied Error When Importing WebCenter Portal

On IBM WebSphere, the getConfiguredApplications permission is required to import WebCenter Portal using the wsadmin command WebCenter.importWebCenterApplication. Before running the import command, grant the getConfiguredApplications permission as follows:

Opss.grantPermission(codeBaseURL="file:${wc.oracle.home}/webcenter/modules/oracle.webcenter.framework_11.1.1/-", ermClass="oracle.security.jps.service.policystore.PolicyStoreAccessPermission, permTarget="context=SYSTEM", permActions="getConfiguredApplications")

5.9.6 Users Can Log In With Old Passwords

User credentials are cached by default on IBM WebSphere. If you change your password, the old password may still work until you enter your new password. Credential caching is controlled through the security cache property: com.ibm.websphere.security.util.authCacheEnabled

If you want to turn off user credential caching, update the JVM setting as follows:

com.ibm.websphere.security.util.authCacheEnabled=false

Note:

Setting this property to false impacts performance so Oracle recommends the default setting (true).

See also, IBM WebSphere documentation at: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tsec_authusers.html

5.9.7 WASX7015E: NameError Exception Running WSADMIN Commands

If you run WSADMIN commands without the required prefix (WebCenter.) or enter an incorrect prefix you see a NameError similar to that below:

wsadmin>webcenter.listWorklistConnections('webcenter')
WASX7015E: Exception running command:
"webcenter.listWorklistConnections('webcenter')"; exception information:
com.ibm.bsf.BSFException: exception from Jython:
Traceback (innermost last):
File "<input>", line 1, in ?
NameError: webcenter

In this example, the incorrect prefix webcenter. must be replaced with WebCenter., that is:

wsadmin>WebcCenter.listWorklistConnections('webcenter')

See also Section 5.4.1, "Running Oracle WebCenter Portal wsadmin Commands."

5.9.8 Unable to Deploy WebCenter Portal Workflows When the SOA MDS Schema is Running on DB2

The composite that manages WebCenter Portal's workflows (sca_CommunityWorkflows) sometimes fails to deploy on a SOA server whose MDS schema is running on a DB2 database.

In such cases, the following message displays in Enterprise Manager (Figure 5-74):

Deploying on partition "default" of "/Cell_WebSphere/soa_server1/soa-infra" ...
Deploying on "/Cell_WebSphere/soa_server1/soa-infra" failed!
There was an error deploying the composite on soa_server1: Deployment Failed:
Unable to transfer file: [jcc][10120][11936][4.8.86] Invalid operation: Lob
is closed. ERRORCODE=-4470 SQLSTATE=null.

Figure 5-74 scs_CommunityWorkflows Fails to Deploy

If you want to use the WebCenter Portal workflows to manage space membership or want to deploy any other BPEL composite on a DB2 back end, modify JBDC data source properties as follows:

1. Log in to the IBM Administrative Console.

2. Navigate to: Resources> JDBC> Data Sources> mds-soa

3. Select Custom properties.

4. Click New and create a custom property with the following values
Name: progressiveStreaming

Value: 2

Description: Disable Progressive Streaming to read lob after result set is closed.

5. Click OK.

6. Restart the SOA server.

7. In Enterprise Manager, confirm that the required BPEL composite is now deployed and available as expected.

5.9.9 HTTP 500 Error Accessing Portal Workflow Notifications in the Worklist Task Flow

If WebCenter Portal workflows fail to register several shared libraries at deployment time, you may see the following HTTP 500 error when you access portal workflow notifications, such as a portal membership invitation, from a Worklist task flow in the WebCenter Portal:

Error 500: javax.servlet.ServletException: SRVE0207E: Uncaught initialization exception created by servlet

The associated BPEL server log entry for this error in /IBM/WebSphere/AppServer/profiles/Server1/logs/soa_server1/soa_server1/SystemOut.log is:

java.lang.IllegalStateException: Application was not properly initialized at startup, could not find Factory: javax.faces.context.FacesContextFactory

To resolve the error, navigate to the application (WebCenterWorklistDetailApp) in the Admin Console and include the missing shared library references (oracle.jsp.next_11.1.1_11.1.1 and adf.oracle.domain_1.0_11.1.1.2.0):

1. Go to IBM WebSphere Administration Console.

2. Select Applications > Application Types > WebSphere Enterprise Applications > WebCenterWorklistDetailApp > Shared library references.

3. Manually add adf.oracle.domain_1.0_11.1.1.2.0 and oracle.jsp.next_11.1.1_11.1.1.

4. Restart the application.

Note:

The same issue can occur for other applications, such as usermessagingsca-ui-worklist. If this is the case, follow similar steps to resolve the issue.

5.9.10 OAM Single Sign-On Logout Not Working

Global logout is not available in an Oracle Access Manager (OAM) Single Sign-On setup on WebSphere if the following property is set to true in your WebSphere instance:

com.ibm.ws.security.addHttpOnlyAttributeToCookies=true

5.9.11 Workflow Related Error Messages in Log Files

After successfully installing and configuring WebCenter Portal 11.1.1.8.0 and starting the WC_Spaces managed server you may see the following errors in the logs:

- WAS_HOME/profiles/Custom01/logs/WC_Spaces/SystemOut.log

[3/28/13 19:49:21:636 PDT] 0000002a error         W
oracle.webcenter.webcenterapp.internal.view.backing.PreferenceBackingBean getMessagingURL SDP Messaging URL cannot be obtained due to
Cannot retrieve portal workflow configuration. Please contact your administrator.

- WAS_HOME/profiles/Custom01/logs/WC_Spaces/WC_Spaces-diagnostic.log

[WC_Spaces] [WARNING] [WCS-19363][oracle.webcenter.webcenterapp.error] [tid: WebContainer : 2] [userId:wasadmin] [ecid: disabled,0]
[APP: webcenter] SDP Messaging URL cannot be obtained due to
Cannot retrieve portal workflow configuration. Please contact your administrator.

Both errors display if Oracle SOA is not configured for your WebCenter Portal instance. You can ignore both errors.

5.9.12 jiveURL Error Messages in Log Files

After successfully installing and configuring WebCenter Portal 11.1.1.8.0 and starting the WC_Spaces managed server you may see the following errors in the log:

WAS_HOME/profiles/Custom01/logs/WC_Collaboration/SystemOut.log

[3/28/13 15:24:21:181 PDT] 0000002f Jive-WARN     W
No URL set for property  'jiveURL', this will cause RSS links to fail.

This message warns that RSS feeds will not work as the jiveURL property is not set. If you do not wish to see this error message, run the following wsadmin command:

WebCenter.setDiscussionsServerProperty(appName='owc_discussions', key='jiveURL', value='http://host:port/owc_discussions')

5.9.13 DCS Stack Messages in Log Files

Sometimes upon starting Admin Server and WebCenter Portal instances on WebSphere, the following entries are seen in the log files:

WAS_HOME/profiles/Dmgr01/logs/dmgr/SystemOut.log

WAS_HOME/profiles/Custom01/logs/nodeagent/SystemOut.log

WAS_HOMEprofiles/Custom01/logs/OracleAdminServer/SystemOut.log

WAS_HOME/profiles/Custom01/logs/WC_Spaces/SystemOut.log

WAS_HOME/profiles/Custom01/logs/WC_Collaboration/SystemOut.log

[3/28/13 19:29:10:160 PDT] 0000000e RoleViewLeade I   DCSV8030I: DCS Stack DefaultCoreGroup at Member Cell01\Node01\WC_Collaboration:
Failed  to join or establish a view with member
[Cell01\CellManager01\dmgr]. The reason is Not all candidates are connected ConnectedSetMissing= [ ]ConnectedSetAdditional [Cell01\slc02poqNode01\nodeagent].

These warnings can be ignored if you can access the Admin Server, WebCenter Portal instances, and corresponding web pages. If you cannot access or log in, refer to IBM support documentation at: http://www-01.ibm.com/support/docview.wss?uid=swg21245012

5.9.14 Error Messages Exporting and Importing Portal Changes

Section 5.4.3, "(WebCenter Portal Only) Migrating Portal Changes" describes how to propagate portal changes to another portal instance. Internal labels keep the source and target portal instances, such as stage and production portals, in-sync and you can only propagate portal changes to another portal instance when these labels match. For details, see the "Labeling During WebCenter Portal Lifecycle" appendix in Oracle Fusion Middleware Administering Oracle WebCenter Portal.

These labels are for internal use only so there is no need for you to view or manage these labels. If there is a mismatch between the source and target labels an error message displays. For example:

Scenario 1: You attempt to export portal changes but the portal's initial base label, which is the starting point for exporting changes, is missing from the source portal so the following message displays:

Cannot export portal changes. Internal label for the portal <portal name> does not exist on the source. Export the portal from the source before attempting to export portal changes

Scenario 2: You attempt to import portal changes but the target portal's initial base label, which is the starting point for importing changes, is missing from the target portal so the following message displays:

Cannot import portal changes. Internal label for the portal <portal name> does not exist on the target. Export the portal from the source and then import the portal on the target to synchronize the portals before attempting to import portal changes

Scenario 3: You attempt to export portal changes but the internal label to be used on export already exists on the source so the following message displays:

Cannot export portal changes. Internal label already exists on the source.

Scenario 4: You attempt to import portal changes but the internal label in the portal archive already exists on the target so the following message displays:

Cannot import portal changes. Internal label obtained from the portal archive already exists on the target. Export the portal from the source and then import the portal on the target to synchronize the portals before attempting to import portal changes. Alternatively, specify a portal archive that contains more recent changes and try again

Scenario 5: You attempt to import portal changes but the internal label in the archive is lower than the label on the target so the following message displays:

Cannot import portal changes. The target portal {0} already contains the changes from the specified archive. If necessary, export the portal from the source and then import the portal on the target to synchronize the portals before attempting to import further portal changes. Alternatively, specify a portal archive that contains more recent changes and try again.

6 Managing Oracle WebCenter Content on IBM WebSphere

This chapter contains information about managing Oracle WebCenter Content applications on IBM WebSphere Application Servers. It describes differences in performing some Oracle WebCenter Content installation, configuration, and administration tasks on IBM WebSphere from performing these tasks on Oracle WebLogic Server. It also specifies restrictions for some tasks on IBM WebSphere.

This chapter contains the following sections:

- Section 6.1, "Installing Oracle WebCenter Content on IBM WebSphere"

- Section 6.2, "Configuring Oracle WebCenter Content on IBM WebSphere"

- Section 6.3, "Configuring Oracle WebCenter Content Applications on IBM WebSphere"

- Section 6.4, "Administering Oracle WebCenter Content Applications on IBM WebSphere"

6.1 Installing Oracle WebCenter Content on IBM WebSphere

The following sections describe differences for performing some Oracle WebCenter Content installation tasks on IBM WebSphere instead of on Oracle WebLogic Server:

- Changing Java Socket Factories in the IBM JDK

- Installing Oracle WebCenter Content Products on IBM WebSphere

- Setting JDBC Driver Environment Variables for a DB2 Database

6.1.1 Changing Java Socket Factories in the IBM JDK

If you are using the IBM JDK with Oracle WebCenter Content and an IBM WebSphere Application Server version earlier than 7.0.0.27, certain functionality will not work correctly unless the Java socket factories are changed. For example, during installation, the check for patches feature would fail to connect to Oracle Support. The IBM JRE has its own Secure Sockets Layer (SSL) socket factories, which you need to change to the default JSSE implementation before installing Oracle WebCenter Content.

Note:

If you are using version 7.0.0.27 or a later version of IBM WebSphere Application Server, this procedure is unnecessary and may cause an error during installation. For version 7.0.0.27 or later, you need to use the default java.security file.

To change Java socket factories in the IBM JDK:

1. Open the WAS_HOME/java/lib/security/java.security file in a text editor.

Note:

If you are providing the path to a IBM WebSphere on a Windows operating system, and a directory name in the path includes a space, you need to supply a shortened name, with a tilde character (~) followed by a 1 instead of the character before the space. For example, the default location of a WebSphere Application Server on a Windows operation system is in a subdirectory of Program Files, a directory name that includes a space:

C:\Program Files\IBM\WebSphere\Appserver

This location needs to be specified as follows:

C:\Progra~1\IBM\WebSphere\Appserver

If you are browsing to this location, the Browse button incorrectly populates the field with the space rather than C:\Progra~1.

2. Uncomment the default JSSE implementation:

# Default JSSE socket factories
ssl.SocketFactory.provider=com.ibm.jsse2.SSLSocketFactoryImpl
ssl.ServerSocketFactory.provider=com.ibm.jsse2.SSLServerSocketFactoryImpl

3. Comment out the WebSphere SSL implementation:

WebSphere socket factories (in cryptosf.jar)
#ssl.SocketFactory.provider=com.ibm.websphere.ssl.protocol.SSLSocketFactory
#ssl.ServerSocketFactory.provider=com.ibm.websphere.ssl.protocol.SSLServerSocketFactory

4. Save the file.

Alternatively, you can set these properties before a call is made to the Oracle Universal Installer API.

6.1.2 Installing Oracle WebCenter Content Products on IBM WebSphere

Use the Oracle Fusion Middleware 11g WebCenter Content Installer to install the binaries for the following Oracle WebCenter Content products on IBM WebSphere.

- Oracle WebCenter Content (WebCenter Content, which includes Oracle WebCenter Content Server)

- Oracle WebCenter Content: Inbound Refinery (Inbound Refinery)

- Oracle WebCenter Content: Records (Records)

For information about the general installation process on IBM WebSphere, see Chapter 2, "Installing and Configuring Oracle Fusion Middleware on IBM WebSphere." For details about differences that apply to all Oracle Fusion Middleware components, see Section 2.5.2, "Special Instructions When Installing Oracle Fusion Middleware with IBM WebSphere."

Note:

The Middleware home directory must be outside of the IBM WebSphere home directory (WAS_HOME), on the same host, so that updates to the application server do not affect the Middleware home directory.

The installation instructions are similar to those provided for Oracle WebLogic Server in the "Installing Oracle WebCenter Content" chapter and "Installation Screens for Oracle WebCenter Content" appendix of Oracle Fusion Middleware Installing and Configuring Oracle WebCenter Content.

6.1.3 Setting JDBC Driver Environment Variables for a DB2 Database

If you are using a DB2 database, you must set the following environment variables to include the full paths to db2jcc4.jar, db2jcc_license_cu.jar, and db2jcc_license_cisuz.jar:

- DB2_JCC_DRIVER_NATIVEPATH

- DB2_JCC_DRIVER_PATH

Do this immediately after installing Oracle WebCenter Content products. If you do not do this, all DB2 connection tests will fail.

To set JDBC driver environment variables for a DB2 Database:

1. Open the IBM WebSphere Administrative Console, at this URL:

https://host:port/ibm/console

2. Log in as an administrator, expand Environment on the left of the console, and click WebSphere variables.

3. From the Scope list on the WebSphere Variables page, choose the node that contains your Oracle WebCenter Content installation.

4. Locate and set the following JBDC variables:

- DB2_JCC_DRIVER_NATIVEPATH

- DB2_JCC_DRIVER_PATH

Specify the location of the required DB2 drivers (db2jcc4.jar, db2jcc_license_cu.jar, and db2jcc_license_cisuz.jar). For example:

DB2_JCC_DRIVER_NATIVEPATH = WAS_HOME/deploytool/itp/plugins/com.ibm.datatools.db2_2.1.102.v20100709_0407/driver

DB2_JCC_DRIVER_PATH    WAS_HOME/deploytool/itp/plugins/com.ibm.datatools.db2_2.1.102.v20100709_0407/driver

In the example, WAS_HOME refers to the location where IBM WebSphere is installed, as described in Section 2.4.2.3, "About the WAS_HOME Directory Path."

Note:

If you are providing the path to a WebSphere Application Server on a Windows operating system, and a directory name in the path includes a space, you need to supply a shortened name, with a tilde character (~) followed by a 1 instead of the character before the space. For example, the default location of a WebSphere Application Server on a Windows operation system is in a subdirectory of Program Files, a directory name that includes a space:

C:\Program Files\IBM\WebSphere\Appserver

This location needs to be specified as follows:

C:\Progra~1\IBM\WebSphere\Appserver

If you are browsing to this location, the Browse button incorrectly populates the field with the space rather than C:\Progra~1.

5. Save both settings.

6. If you are using a cluster, repeat these steps for each node in the cluster.

7. To test the DB2 connection:

1. Expand Resources and JDBC on the left of the console, and click Data sources.

2. Select a data source in the table, and click the Test Connection button.

6.2 Configuring Oracle WebCenter Content on IBM WebSphere

The following sections describe differences for performing some configuration tasks for configuring Oracle WebCenter Content on IBM WebSphere instead of on Oracle WebLogic Server:

- Configuring Oracle WebCenter Content on IBM WebSphere

- Propagating cwallet.sso Changes to the Deployment Manager

- Specifying Deployment with SSL

- Configuring an LDAP Server for Oracle WebCenter Content Users and Groups on IBM WebSphere

- Configuring an Administration User for WebCenter Content

- Setting Cookie Paths for Oracle WebCenter Content Application Modules

- Setting Up Node Manager

- Launching the IBM WebSphere Administrative Console

- Increasing the Java VM Heap Size for an Oracle WebCenter Content Application Server

- Configuring the Report Library for Records Management in Content Server

- Configuring Session Persistence in a Clustered Environment

- Using Oracle WebCenter Content wsadmin Commands Instead of WLST Commands

6.2.1 Configuring Oracle WebCenter Content on IBM WebSphere

Configuration of Oracle WebCenter Content on IBM WebSphere is largely the same as the configuration of Oracle WebCenter Content described in Oracle Fusion Middleware Installing and Configuring Oracle WebCenter Content. After you have successfully run the Oracle Fusion Middleware 11g WebCenter Content Installer and created application schemas, you can deploy and configure WebCenter Content (and Content Server), Inbound Refinery, and Records as applications.

Each Oracle WebCenter Content application is deployed to a WebSphere Application Server Java EE container. The XML files are the same as for Oracle WebLogic Server.

For information about using the Fusion Middleware Configuration Wizard, including information about adding servers and clusters to a cell, see the Oracle Fusion Middleware Configuration Guide for IBM WebSphere Application Server.

The configuration screen in Figure 6-1 shows templates for Oracle WebCenter Content applications and related templates that you can add to a WebSphere Application Server cell.

Figure 6-1 Add Products to Cell Screen

6.2.2 Propagating cwallet.sso Changes to the Deployment Manager

The updates to the cwallet.sso file, in some cases, are not propagated from the Oracle WebCenter Content managed server to the Deployment Manager. In these cases, you must propagate the change manually.

After you complete the WebCenter Content configuration on the Content Server Configuration page or enable the PdfWatermark or BpelIntegration component, the WebCenter Content managed server updates the cwallet.sso file in the WAS_PROFILES/UCM_SERVER_NAME/config/cells/UCM_CELL_NAME/fmwconfig/ directory when it restarts. In these cases, you need to propagate the changes back to the Deployment Manager immediately after the restart.

To propagate the changes, copy the cwallet.sso file to this directory:

WAS_PROFILES/DEPLOYMENT_MANAGER_NAME/config/cells/UCM_CELL_NAME/fmwconfig/

6.2.3 Specifying Deployment with SSL

You can configure WebCenter Content, Inbound Refinery, or Records for deployment with or without Secure Socket Layer (SSL). For this configuration on Oracle WebLogic Server, the Fusion Middleware Configuration Wizard provides an SSL Enabled checkbox and SSL listen port field for each server on the Configure Managed Servers screen. For SSL configuration on IBM WebSphere, the Configuration Wizard provides an Enabled checkbox and Port field for each end point on the Configure End Points screen.

All ports, including SSL ports, are enable by default on IBM WebSphere. The End Point Type column on the Configure End Points screen indicates whether a port is for SSL, with "(SSL)" at the end of the column value. Figure 6-2 shows an example of this screen.

Figure 6-2 Configure End Points Screen

6.2.4 Configuring an LDAP Server for Oracle WebCenter Content Users and Groups on IBM WebSphere

When you configure Oracle WebCenter Content on IBM WebSphere, an internal Lightweight Directory Application Protocol (LDAP) server is not automatically configured with users and groups for the WebCenter Content (Content Server), Inbound Refinery, or Records applications. You must manually perform these configuration tasks in an external LDAP server, such as Oracle Internet Directory, after installation and before you start the application servers.

For information about the LDAP servers that Oracle Fusion Middleware supports, see the Oracle Fusion Middleware Supported System Configurations.

For information about installing and configuring a supported LDAP server, see Section 4.1.2, "Configuring Oracle SOA Suite and Oracle BAM in an External LDAP Server." To switch LDAP authentication providers, follow the instructions in this section.

6.2.5 Configuring an Administration User for WebCenter Content

The WebCenter Content administrator has to have an entry in the LDAP authentication provider and in the Administrators group. If the Administrators group does not exist in the LDAP provider, you need to create it there.

The default administrator for IBM WebSphere is wasadmin. You can add this user to the Administrators group through Fusion Middleware Control.

6.2.6 Setting Cookie Paths for Oracle WebCenter Content Application Modules

By default, applications deployed on IBM WebSphere have their cookie path set to "/". This default setting means that all applications on the same IBM WebSphere cell share the same session identifier and therefore, as you move between applications, the session identifier value for the previous application is overwritten. For example, if you access Content Server (/cs), access Enterprise Manager (/em), and then move back to Content Server (/cs) you are prompted to log in to Content Server again because the previous session identifier value is overwritten at the point when you log in to Enterprise Manager (/em).

To avoid session invalidation as you move between applications, specify a unique cookie path for each application:

1. Log in to the IBM WebSphere Administrative Console.

https://host:port/ibm/console

2. Navigate to Applications > WebSphere enterprise applications.

3. Select the name of your application from the list.

4. Click Manage Modules (Figure 6-3).

Figure 6-3 Enterprise Applications - Manage Modules

A list of application modules displays.

5. Set the cookie path for each Oracle WebCenter Content application module.

1. Click the module name.

2. Click Session Management (Figure 6-4).

Figure 6-4 Configure Module

3. Select the Enable cookies check box (Figure 6-5).

Figure 6-5 Configure Module - Enable Cookies

4. Click the Enable cookies link.

5. Enter the appropriate cookie path for the selected module.

6. Click OK and then Save.

7. Select the Override session management check box.

8. (In a clustered environment only) Select the Distributed environment settings link, select Memory-to-memory replication, and then click OK.

9. Click OK.

10. Repeat steps a through i for each module.

6. Restart the server on which the application is deployed.

1. Navigate to Servers > WebSphere Application servers.

2. Select the check box for the server, and click Restart.

6.2.7 Setting Up Node Manager

After using the Fusion Middleware Configuration Wizard to install and configure Oracle WebCenter Content products on IBM WebSphere, start the IBM WebSphere Deployment Manager, Node Manager, and application servers, as described in Section 2.7, "Task 7: Start the IBM WebSphere Servers."

For Oracle WebCenter Content, you must also run the syncNode script, as follows:

WAS_HOME/bin/syncNode.sh localhost SOAP_CONNECTOR_ADDRESS -profileName profile_name -username was_admin_user -password was_password

The SOAP_CONNECTOR_ADDRESS is the value of Management SOAP connector port in the WAS_HOME/profiles/profile_name/logs/AboutThisProfile.txt or com.ibm.ws.scripting.port in the WAS_HOME/profiles/profile_name/properties/wsadmin.properties file.

Note:

The syncNode script should be run only one time, during the first startup sequence. Run it after step 1, "Start the Deployment Manager," in Section 2.7, "Task 7: Start the IBM WebSphere Servers."

6.2.8 Launching the IBM WebSphere Administrative Console

The IBM WebSphere Administrative Console provides a web-based interface for managing the WebSphere Application Server environment. The IBM WebSphere Administrative Console is similar to the Oracle WebLogic Server Administration Console. You cannot use the IBM WebSphere Administrative Console to manage the Oracle WebCenter Content applications, but you can use the console to monitor and manage the cell and the servers on which WebCenter Content, Inbound Refinery, and Records are deployed. For more information, see Section 3.1.1, "Using the WebSphere Administrative Console."

6.2.9 Increasing the Java VM Heap Size for an Oracle WebCenter Content Application Server

You need to increase the size of the heap allocated for the Java Virtual Machine (VM) on which each Oracle WebCenter Content application runs to at least 1 GB (1024 MB) for the IBM JDK. If you do not increase the Java VM heap size, then Oracle support and development will not accept escalation of runtime issues, especially out-of-memory issues.

You can use the IBM WebSphere Administrative Console to adjust the heap size for a Java VM. To increase the heap size, you set the values of the JVM startup parameter.

To increase the Java VM heap size for an Oracle WebCenter Content application server with the IBM WebSphere Administrative Console:

1. Log in to the IBM WebSphere Administrative Console as an administrator at https://hostname:WC_Adminhost_port/ibm/console; for example:

https://host42.example.com:9002/ibm/console

2. In the navigation tree on the left, shown in Figure 6-6, expand Servers and Server Types, and click WebSphere application servers.

Figure 6-6 Server Types

3. On the Application servers page, shown in Figure 6-7, click an Oracle WebCenter Content application server for which you want to increase the heap size.

Figure 6-7 Application servers Page

4. On the General Properties page, shown in Figure 6-8, expand Java Process Management, and click Process Definition.

Figure 6-8 General Properties Page

5. On the Process Definition page, shown in Figure 6-9, click Java Virtual Machine under Additional Properties.

Figure 6-9 Process definition Page

6. Set the Initial Heap, Max Heap, and Generic JVM Arguments fields to the values shown in Figure 6-10.

Figure 6-10 JVM Startup Parameters

The PermSize value in the Generic JVM Arguments section needs to be half of the MaxPermSize value.

7. Save the changed values to the local configuration.

8. Repeat steps 3 through 7 for each Oracle WebCenter Content application server.

9. Restart the Oracle WebCenter Content application servers, as described in Section 3.2.2, "Starting and Stopping Servers on IBM WebSphere."

6.2.10 Configuring the Report Library for Records Management in Content Server

If you plan to configure the Records Management feature in Content Server, you need configure the report library for Records Management after the server node is created for WebCenter Content, before starting the server for the first time. Without this library, you cannot check in any templates to Content Server.

To configure the report library, you need to add the oracle.xdo.runtime.ear library manually from the IBM WebSphere Administrative Console.

Note:

This library is not needed for Oracle WebCenter Content: Records

To configure the report library for Records Management in Content Server:

1. From the IBM WebSphere Administrative Console, click Shared Libraries under Environment, on the left.

2. In the shared libraries display, select the scope value as the WebCenter Content node that needs the library.

3. If the oracle.xdo.runtime.ear library does not already exist in the Shared Libraries list, click New, and enter these values:

Name=oracle.xdo.runtime_1_11.1.1.3.0
Classpath=
WCC_ORACLE_HOME/ucm/idc/components/ReportPublisher/lib/APP-INF/lib

4. Click Apply.

5. In the Servers section on the left, under Server Types, click WebSphere application servers.

6. In the table on the Application servers screen, click Oracle WebCenter Content.

7. In the installed applications display, click WebCenter Content.

8. In the application configuration display, under References, click Shared library references.

9. Select the Oracle WebCenter Content application, and click the Reference Shared Libraries button.

10. In the Shared Library Mapping display, select oracle.xdo.runtime_1_11.1.1.3.0 on the left, move the selection to the right, and click OK.

11. In the Reference Shared Libraries display, click OK.

12. Under Messages at the top, click Save to save the local configuration to the master configuration.

For information about adding the Records Management feature to Content Server, see "Configuring Records Management in Content Server" in Oracle Fusion Middleware Installing and Configuring Oracle WebCenter Content.

6.2.11 Configuring Session Persistence in a Clustered Environment

The configuration for session persistence in a clustered environment is different for WebSphere Application Server than for Oracle WebLogic Server, in which the element <persistent-store-type>replicated_if_clustered</persistent-store-type> can be set in the servlet to provide session persistence. In WebSphere Application Server, the web container's session management property for session persistence is sessionPersistenceMode, which is stored in the WAS_HOME/profiles/profile_name/config/cells/cell_name/nodes/node_name/servers/server_name/server.xml file.

You can display the current sessionPersistenceMode value in the IBM WebSphere Administrative Console.

You can set the session persistence mode while creating a cluster through the IBM WebSphere Administrative Console. If you use the Fusion Middleware Configuration Wizard to create a cluster, after the cluster is created, you must configure the session persistence mode manually, through the IBM WebSphere Administrative Console, and then restart the application servers.

To display the session persistence mode in the IBM WebSphere Administrative Console:

1. Log in to the IBM WebSphere Administrative Console as an administrator at https://hostname:WC_Adminhost_port/ibm/console.

2. Expand Servers and Server Types on the left, and click WebSphere application servers.

3. Click an Oracle WebCenter Content application server on the Application Servers page.

4. Expand Web Container Settings, and click Web container, under Container Settings on the Configuration page for the application server.

5. Click Session management, under Additional Properties on the Web container page.

6. Click Distributed environment settings, under Additional Properties on the Session management page.

7. The Configuration page for Distributed environment settings displays the current sessionPersistenceMode value under General Properties, as the selected value for Distributed sessions.
The value of sessionPersistenceMode can be None, Database, or Data_Replication (displayed as the Memory-to-memory replication mode on the console.

To set the session persistence mode for a cluster:

- If you use the IBM WebSphere Administrative Console to create a cluster, you must select the option Configure HTTP session memory-to-memory replication.
When this option is selected, a replication domain is created automatically, and the sessionPersistenceMode property is automatically set to the Data_Replication mode for each member of the new cluster. The created Replication domain, which has the same name as the cluster name, is automatically set for the Replication Domain property.

- If you use the Fusion Middleware Configuration Wizard to create a cluster, the Configuration Wizard does not present any options for cluster creation, and it creates the new cluster without creating a replication domain.
The sessionPersistenceMode property is not set to the Data_Replication mode for each cluster member. In this case, you must configure sessionPersistenceMode manually, as the following procedure describes.

To configure the session persistence mode manually:

1. Log in to the IBM WebSphere Administrative Console as an administrator at https://hostname:WC_Adminhost_port/ibm/console.

2. Create a replication domain (if there is none, or if you want to create a new replication domain for a cluster you created through the Fusion Middleware Configuration Wizard):

1. Expand Environment on the left of the console, and click Replication domains.

2. Click the New button on the Replication domains page.

3. Enter the domain name, and select the option Entire Domain under Number of Replicas.

4. Click the Apply or OK button, and then Save.

3. Set the sessionPersitenceMode property value for every server member in the cluster:

1. Expand Servers and Server Types on the left, and click WebSphere application servers.

2. Click an Oracle WebCenter Content application server on the Application Servers page.

3. Expand Web Container Settings, and click Web container, under Container Settings on the Configuration page for the application server.

4. Click Session management, under Additional Properties on the Web container page.

5. Click Distributed environment settings, under Additional Properties on the Session management page.

6. Select the Memory-to-memory replication option, under Distributed sessions on the Configuration page for Distributed environment settings (to set sessionPersistenceMode to Data_Replication.

7. On the Configuration page for Memory-to-memory replication, select the replication domain you created for this cluster.

8. Select the proper Replication mode for your configuration.

9. Click the Apply or OK button, and then Save.

4. Restart the Oracle WebCenter Content application servers, as described in Section 3.2.2, "Starting and Stopping Servers on IBM WebSphere."

6.2.12 Using Oracle WebCenter Content wsadmin Commands Instead of WLST Commands

All Oracle WebCenter Content wsadmin commands supported by WebSphere Application Server have equivalent WebLogic Scripting Tool (WLST) commands. Table 6-1 describes differences between wsadmin and WLST.

Table 6-1 Differences Between wsadmin and WLST Commands

Issue

WLST

wsadmin

Command Names

WLST commands are documented in "Oracle WebCenter Content Custom WLST Commands" in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

All wsadmin command names are prefixed with "UCM." For example:

UCM.getUCMHttpServerAddress
UCM.setUCMServerPort
UCM.getUCMMailServer

Boolean Type

true/false or 1/0.

1/0 only

server, applicationVersion

Valid arguments

Not used

Offline or Online

Run WLST commands in offline mode

Run wsadmin commands in online mode

Clone command

Used to clone WebLogic managed servers when setting up a cluster

n/a

Note:

The wsadmin online commands using MBeans may not provide specific error details. Instead, you may see just an MBeanException message.

Execute Oracle WebCenter Content wsadmin commands from the /common/bin directory in the WebCenter Content Oracle home:

cd WCC_ORACLE_HOME/common/bin
./wsadmin.sh

To invoke online help for Oracle WebCenter Content commands, enter the following command:

wsadmin> print OracleHelp.help('UCM')

To invoke online help for a specific command, enter the following command:

wsadmin> print OracleHelp.help('command_name')

To use the commands, you must be connected to a running WebSphere Application Server instance that has the UCM Config MBeans deployed. The MBeans are typically installed in the server. To connect to a server instance, run the wsadmin.sh script with these options:

./wsadmin.sh -conntype SOAP -port port -user username -password password

For example:

./wsadmin.sh -conntype SOAP -port 8879 -user wasadmin -password password

Table 6-2 shows the wsadmin commands that are available for Oracle WebCenter Content server configuration.

Table 6-2 wsadmin Commands for Oracle WebCenter Content

wsadmin Command

Description

UCM.getUCMCSVersion

Gets the version of the running instance of Content Server.

UCM.getUCMHttpServerAddress

Returns the Content Server HTTP Server Address.

UCM.getUCMIPAddressFilter

Gets the IP Address Filter Configuration Parameter.

getUCMMailServer

Returns the Content Server Mail Server Configuration Value.

UCM.getUCMServerPort

Gets the Server Port Configuration Parameter from the config.cfg file and displays it.

UCM.getUCMServerUptime

Gets the amount of time the Content Server instance has been up.

UCM.getUCMSmtpPort

Gets the Content Server SMTP Port Value.

UCM.getUCMSysAdminAddress

Gets the Content Server Administrator Mail Address from the config.cfg file.

UCM.getUCMUseSSL

Gets the SSL Value from the config.cfg file and displays the value as true or false.

UCM.setUCMHttpServerAddress

Sets the Content Server HTTP Server Address.

UCM.setUCMIpAddressFilter

Sets the IP Address Filter Configuration Parameter.

UCM.setUCMMailServer

Sets the Content Server Mail Server Configuration Value.

UCM.setUCMServerPort

Sets the Server Port Configuration Parameter.

UCM.setUCMSmtpPort

Sets the Content Server SMTP Port Value.

UCM.setSysAdminAddress

Sets the Content Server Administrator Mail Address.

UCM.setUCMUseSSL

Sets the SSL Value to true or false, thereby enabling or disabling the use of SSL.

Example 6-1 shows the syntax and an example of the UCM.getUCMMailServer command.

Example 6-1 Get the Content Server Mail Server

Syntax:  UCM.getUCMMailServer(AppName)

Example: UCM.getUCMMailServer('Oracle WebCenter Content - Content Server')

Example 6-2 shows the syntax and an example of the UCM.setUCMServerPort command.

Example 6-2 Set the Content Server Port

Syntax:  UCM.setUCMServerPort(value,AppName)

Example: UCM.setUCMServerPort(4444,'Oracle WebCenter Content - Content Server')

Example 6-3 shows the help output and an example for the UCM.setUCMServerPort command.

Example 6-3 Get the Content Server Version

wsadmin>print OracleHelp.help('UCM.getUCMCSVersion')

Gets the value of Content Server Version from the Content Server API's and displays it.

Syntax:

getUCMCSVersion() or getUCMCSVersion(application_name).

Example:

Example Output: 11g.1.1.0
Example Setting: getUCMCSVersion('Oracle WebCenter Content Server')

wsadmin>UCM.getUCMCSVersion()
11gr1-trunk-idcprod1-111007T175404(Build: 7.3.3.183)
wsadmin>

For more information about wsadmin commands, see Section 3.1.3, "Using the Oracle Fusion Middleware wsadmin Commands."

For information about the equivalent Oracle WebCenter Content WLST commands, see "Oracle WebCenter Content Custom WLST Commands" in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

6.3 Configuring Oracle WebCenter Content Applications on IBM WebSphere

For information about the postinstallation configuration of Oracle WebCenter Content applications, see these chapters in Oracle Fusion Middleware Installing and Configuring Oracle WebCenter Content:

- "Configuring Oracle WebCenter Content Applications"

- "Completing the WebCenter Content Configuration"

- "Completing the Inbound Refinery Configuration"

- "Completing the Records Configuration"

The following sections describe differences for performing some postinstallation configuration tasks for Oracle WebCenter Content applications on IBM WebSphere instead of on Oracle WebLogic Server:

- Mapping the weblayout Directory

- Changing the Authentication Method for Oracle WebCenter Content Applications

Important:

The first user to log in to Oracle WebCenter Content Server must be the administrator of the cell, to complete the configuration of Content Server. For more information, see "Completing the Initial WebCenter Content Configuration" in Oracle Fusion Middleware Installing and Configuring Oracle WebCenter Content.

6.3.1 Mapping the weblayout Directory

The weblayout directory is the directory where WebCenter Content stores all the content checked into the server. This location is also where the content and other web assets are retrieved by the servlet or web server. WebCenter Content configures the mapping of the context root to a file system path at runtime in the servlet initializations. This configuration is done because the administrator can change the file system location of the weblayout directory during the initial configuration of Content Server, which happens the first time it is accessed.

For WebSphere Application Server, the weblayout directory is mapped to the HttpRelativeWebRoot value at runtime by appending the context root for WebCenter Content, /cs/ by default, to the URL for the weblayout directory. You can locate this directory on a network file system to accommodate a large collection of content.

Figure 6-11 shows the postinstallation configuration page for Content Server. Before using Content Server, you need to make sure the context root for WebCenter Content is appended to the path for the weblayout directory, make any other configuration changes, and click SUBMIT to confirm the Content Server configuration. Then you need to and restart Content Server, as described in Section 6.4.1, "Starting or Restarting Content Server on IBM WebSphere."

Figure 6-11 Content Server Postinstallation Configuration

For information about the other values on the WebCenter Content Configuration page, see "Completing the Initial Configuration of Content Server" in Oracle Fusion Middleware Installing and Configuring Oracle WebCenter Content.

6.3.2 Changing the Authentication Method for Oracle WebCenter Content Applications

If you want an Oracle WebCenter Content application to participate in single sign-on, you must specify CLIENT-CERT as the authentication method. By default, Oracle WebCenter Content applications specify FORM their authentication method. Unlike Oracle WebLogic Server, WebSphere Application Server does not support multiple, comma-separated authentication methods. You must change the authentication method to CLIENT-CERT for any Oracle WebCenter Content application to participate in single sign-on.

To change the authentication method for an Oracle WebCenter Content application:

1. Locate the web.xml file for the application.
For example, on a UNIX machine where WebSphere Application Server is installed, locate web.xml at

WAS_HOME/profiles/profile_name/
config/cells/cellName/applications/
Oracle Universal Content Management - Content Server.ear/
deployments/Oracle WebCenter Content - Content Server/cs.war/WEB-INF/web.xml

2. Copy web.xml to a temporary location.

3. Open web.xml in a text editor, and make these changes:

1. Remove (or comment out) the following <login-config> element:

<login-config>
<auth-method>FORM</auth-method>
<realm-name>idcauth</realm-name>
<form-login-config>
<form-login-page>/login/login.htm</form-login-page>
<form-error-page>/login/error.htm</form-error-page>
</form-login-config>
</login-config>

2. Replace it with the following <login-config> element:

<login-config>
<auth-method>CLIENT-CERT</auth-method>
</login-config>

3. Save the changes.

4. Redeploy the updated web.xml file:

1. Open the IBM WebSphere Administrative Console, at https://hostname:WC_Adminhost_port/ibm/console; for example:

https://host42.example.com:9002/ibm/console

2. Log in as an administrator.

3. Expand Applications and Application Types on the left of the console, and click WebSphere enterprise applications.

4. Select Oracle Universal Content Management - Content Server, and click the Update button.

5. Choose Replace or add a single file.

6. Specify the path to the web.xml file you want to replace, starting with the name of the application's archive file (.war):
cs.war/WEB-INF/web.xml

7. Click Next.

8. In the section Specify the path to the file, enter the full path to the web.xml file you updated in Step 3.

9. Click Next, and follow through until the application is saved.

10. Click OK, and then click Save Changes.
Wait for a couple of minutes for the changes to be propagated.

11. To confirm the changes, navigate to the application's deployment descriptor, and view it.
Under WebSphere Enterprise Applications, choose Oracle Universal Content Management - Content Server, then Manage Modules, then cs.war, and then View Deployment Descriptor.

5. Restart the WebCenter Content application server, as described in Section 3.2.2, "Starting and Stopping Servers on IBM WebSphere."

6.4 Administering Oracle WebCenter Content Applications on IBM WebSphere

The following sections describe differences for performing some administration tasks for Oracle WebCenter Content Applications on IBM WebSphere instead of on Oracle WebLogic Server:

- Starting or Restarting Content Server on IBM WebSphere

- Logging In to WebCenter Content Server and Records

- Managing an Oracle WebCenter Content Cell and Servers from the IBM WebSphere Administrative Console

- Managing an Oracle WebCenter Content Cell, Servers, and Applications from Fusion Middleware Control

For information about Oracle Fusion Middleware administration on IBM WebSphere, see Chapter 3, "Managing Oracle Fusion Middleware on IBM WebSphere".

For information about administering Content Server in a WebCenter Content application server, see Oracle Fusion Middleware Administering Oracle WebCenter Content.

For information about managing the Inbound Refinery and Records applications, see Oracle Fusion Middleware Managing Oracle WebCenter Content.

6.4.1 Starting or Restarting Content Server on IBM WebSphere

The Oracle WebCenter Content application (WebCenter Content), includes Oracle WebCenter Content Server (Content Server). You can start the WebCenter Content application server on IBM WebSphere with a profile or with Fusion Middleware Control. Then you can start a web browser and log in to Content Server. After you start the WebCenter Content application server, Content Server does not start until you access it for the first time.

To start Content Server on IBM WebSphere:

1. Start the WebCenter Content application server, as described in Section 3.2.2, "Starting and Stopping Servers on IBM WebSphere."

2. Go to the Content Server web interface, which is at this URL by default:

http://hostname:16200/cs

In the URL, hostname is the name of the machine (or host) on which Oracle WebCenter Content Server is running.

If a different port was configured for the WebCenter Content application server, specify that port instead of 16200. The default SSL port is 16201. For WebCenter Content, and Content Server, you can configure any port in the range 16200-16299.

3. Log in to Content Server with the user name and password that you used to start the WebCenter Content application server.

To restart Content Server on IBM WebSphere:

1. Log out from the Content Server web interface.

2. Shut down the WebCenter Content application server, as described in Section 3.2.2, "Starting and Stopping Servers on IBM WebSphere."

3. Start the WebCenter Content application server, as described in Section 3.2.2, "Starting and Stopping Servers on IBM WebSphere."

4. Go to the Content Server web interface, which is at this URL by default:

http://hostname:16200/cs

In the URL, hostname is the name of the machine (or host) on which Oracle WebCenter Content Server is running.

If a different port was configured for the WebCenter Content application server, specify that port instead of 16200. The default SSL port is 16201. For WebCenter Content, and Content Server, you can configure any port in the range 16200-16299.

5. Log in to Content Server with the user name and password that you used to start the WebCenter Content application server.

6.4.2 Logging In to WebCenter Content Server and Records

Logging in to the Content Server web interface also logs you in to the Records web interface if WebCenter Content and Records are deployed to the same WebSphere cell. If you log in to Content Server from a browser and then go to the Records URL from another browser tab, you will not be prompted to log in to Records. The login credentials pass from Content Server to Records.

Logging out from Content Server also logs you out from Records.

This is different from logging in to Content Server and Records configured in the same Oracle WebLogic Server domain, where you need to log in to the web interface for each Managed Server separately.

6.4.3 Managing an Oracle WebCenter Content Cell and Servers from the IBM WebSphere Administrative Console

You can manage an Oracle WebCenter Content cell and its servers from the IBM WebSphere Administrative Console, which provides a web-based interface for managing the WebSphere Application Server environment. For more information, see Section 3.1.1, "Using the WebSphere Administrative Console."

6.4.4 Managing an Oracle WebCenter Content Cell, Servers, and Applications from Fusion Middleware Control

You can manage Oracle WebCenter Content applications (components) as well as their cell and servers from Oracle Enterprise Manager Fusion Middleware Control, which provides a web-based interface for monitoring and administering Oracle Fusion Middleware. For more information, see Section 3.1.2, "Using Oracle Enterprise Manager Fusion Middleware Control."

7 Managing Oracle Data Integrator on IBM WebSphere

This chapter contains information about managing Oracle Data Integrator on IBM WebSphere.

This chapter contains the following sections:

- Section 7.1, "Differences and Restrictions When Installing and Configuring Oracle Data Integrator Applications on IBM WebSphere"

- Section 7.2, "Differences When Managing Oracle Data Integrator on IBM WebSphere"

7.1 Differences and Restrictions When Installing and Configuring Oracle Data Integrator Applications on IBM WebSphere

The following section describes differences and restrictions when installing and configuring Oracle Data Integrator on IBM WebSphere:

- Section 7.1.1, "Creating a New IBM WebSphere Cell"

7.1.1 Creating a New IBM WebSphere Cell

Before running WebSphere Configuration Wizard (was_config.sh) to create a cell, you must edit the WAS_HOME/bin/wsadmin.sh file and move the $javaOption \ entry so that it is located below the $PERF_JVM_OPTIONS \ entry.

This will prevent certain error messages during the cell creation and configuration.

7.2 Differences When Managing Oracle Data Integrator on IBM WebSphere

This section contains the following:

- Section 7.2.1, "Creating a New Server in an IBM WebSphere Cell"

- Section 7.2.2, "Setting the Desired Logging Level on IBM WebSphere"

- Section 7.2.3, "Configuring OPMN on IBM WebSphere"

7.2.1 Creating a New Server in an IBM WebSphere Cell

If you want to create a new server other than odi_server1 in your IBM WebSphere cell, you must do the following after creating the cell but before starting any of the servers or processes:

1. Edit the following file and make sure the proper front-ending host and port values are in place:
On UNIX operating systems:

WAS_HOME/profiles/dmgr-profile-name/config/cells/cell-name/nodes/node-name/servers/odi_server1/fmwconfig/jrf-port-config.properties

On Windows operating systems:

WAS_HOME\profiles\dmgr-profile-name\config\cells\cell-name\nodes\node-name\servers\odi_server1\fmwconfig\jrf-port-config.properties

2. Copy this file into the following directory:
On UNIX operating systems:

WAS_HOME/profiles/dmgr-profile-name/config/cells/cell-name/nodes/node-name/servers/new_server_name/fmwconfig/jrf-port-config.properties

On Windows operating systems:

WAS_HOME\profiles\dmgr-profile-name\config\cells\cell-name\nodes\node-name\servers\new_server_name\fmwconfig\jrf-port-config.properties

Replace new_server_name with the name of the new server you created in the WebSphere Configuration Wizard.

This process must be repeated for each new server created in the cell.

7.2.2 Setting the Desired Logging Level on IBM WebSphere

Oracle Data Integrator defines all the loggers in the fmwconfig/logging.xml file. The parent of all ODI loggers is oracle.odi and this is set with a default log-level of CONFIG (ODL level: "NOTIFICATION:16"). All the descendent loggers oracle.odi.* (for example, oracle.odi.agent) are not set with any default logging level.

On WebLogic Server, if the logging level is not set for a logger, then its parent's logging level is automatically used. On IBM WebSphere, a logger that is not set with a logging level is automatically assigned the default level INFO ("NOTIFICATION:1").

Because of this behavior, the session start/end messages (which are at CONFIG level) are not getting logged on IBM WebSphere.

To work around this issue, you must set the desired logging level for each logger using Fusion Middleware Control or the wsadmin script.

Using Fusion Middleware Control:

To set the logging level using Fusion Middleware Control, assuming the name of your Managed Server is odi_server1:

1. Select WebSphere_Cell > Cell_WebSphere > odi_server1.

2. Right-click on odi_server1, then select Logs > Log Configuration.

3. In the Log Configuration page, select the logger (for example, oracle.odi.agent) and change the logging level as desired.

Using the wsadmin Script

To set the logging level using the wsadmin script, assuming the Managed Server is named odi_server1:

1. Start the wsadmin script from the ORACLE_HOME/common/bin directory.

2. Run the following command to view the current logging level of a logger (for example, oracle.odi.agent):

OracleODL.listLoggers(target="odi_server1", pattern="oracle.odi.agent")

3. Run the following command to change the logging level of oracle.odi.agent to CONFIG ("NOTIFICATION:16"):

OracleODL.setLogLevel(target="odi_server1", logger="oracle.odi.agent", level="CONFIG")

4. Run the following commands if you want to change the logging levels of all the loggers that are descendants of the parent logger oracle.odi to CONFIG ("NOTIFICATION:16"):

myLoggers = OracleODL.listLoggers(target="odi_server1", pattern="oracle.odi.*")
for loggerName in myLoggers.keys():
OracleODL.setLogLevel(target="odi_server1", logger=loggerName, level="CONFIG")

You must press Enter twice after the last command.

7.2.3 Configuring OPMN on IBM WebSphere

The Standalone Agent can be managed from Fusion Middleware Control using OPMN, which is available when installing Oracle Web Tier. Installing Oracle Web Tier and OPMN does not result in the proper configuration when deployed on IBM WebSphere, so there are some additional steps needed to complete the configuration.

Follow the instructions in this section to properly configure OPMN in order to manage the Standalone Agent from Fusion Middleware Control on IBM WebSphere Server.

1. Install Oracle Data Integrator and IBM WebSphere application server.

2. Install Oracle Web Tier in order to get OPMN, and make sure:

1. Oracle Web Tier must be installed in the same Oracle home as Oracle Data Integrator.

2. When installing Oracle Web Tier, choose the Install Software - Do Not Configure option on the Select Installation Type screen.

3. The default instance name is instance1, which will be used in the examples below. If you choose a difference instance name, remember to replace instance1 with your own instance name.

3. In order to configure OPMN to manage a Standalone Agent, with or without registering the OPMN instance to an Administration Server, OPMN needs a properties file containing the properties defined in Table 7-1. Note that the values shown may differ from your system configuration.
The list of properties required are given in the ODI_HOME/oracledi/agent/bin/agentcreate.properties file. Create a copy of this file and provide values for these properties as applicable to your Standalone Agent.

For example, if you wish to manage two Standalone Agent processes using OPMN, create one copy of agentcreate.properties for each agent (perhaps ODIAgent1.properties and ODIAgent2.properties).

Note:

The name of the file does not need to match the name of the agent.

Table 7-1 Parameters in agentcreate.properties

Parameter

Description

Example (Your Configurations May Differ)

PORTNO

HTTP(S) port number that the Standalone Agent listens on.

PORTNO=9787

JMXPORTNO

JMX port of the ODI Standalone Agent.

JMXPORTNO=9787

PROXY_PORT

OPMN proxy port number.

PROXY_PORT=98767

JAVA_HOME

Location of the JVM used by the ODI Standalone Agent.

JAVA_HOME=/home/Oracle/Middleware/jdk6_35

ORACLE_OPMN_HOME

Oracle home directory for Oracle Web Tier.

ORACLE_OPMN_HOME=/home/Oracle/Middleware/Oracle_WT1

ORACLE_ODI_HOME

Oracle home directory for Oracle Data Integrator.

ORACLE_ODI_HOME=/home/Oracle/Middleware/Oracle_ODI1

INSTANCE_HOME

OPMN Instance home directory.

INSTANCE_HOME=/home/Oracle/Middleware/Oracle_WT1/instances/instance1

COMPONENT_TYPE

Set this property to odiagent.

COMPONENT_TYPE=odiagent

COMPONENT_NAME

Name of the agent you want to add. This will be its identification in OPMN.

COMPONENT_NAME=OracleDIAgent

ODI_MASTER_DRIVER

Name of the JDBC driver used to connect the Master Repository.

ODI_MASTER_DRIVER=oracle.jdbc.OracleDriver

ODI_MASTER_URL

JDBC URL used to connect the Master Repository. Use the format:

jdbc:oracle:thin:@db_host:port:sid

ODI_MASTER_URL=jdbc:oracle:thin@examplehost.exampledomain:1521:orcl

ODI_MASTER_USER

Database account used to connect the Master Repository. This should be the prefix and schema name of the ODI schema created in the database using RCU.

ODI_MASTER_USER=DEV_ODI_REPO

ODI_MASTER_ENCODED_PASS

Database account password. The password must be encoded with the encode.[sh|bat] password command.

ODI_MASTER_ENCODED_PASS=hpfatLEoMR6zAK3T1PoP5LXDS

ODI_SECU_WORK_REPO

Name of the Work Repository to connect. This Work Repository must be attached to the master repository.

ODI_SECU_WORK_REPO=WORKREP

ODI_SUPERVISOR_ENCODED_PASS

OracleDI supervisor user password. The password must be encoded with the encode.[sh|bat] password command.

ODI_SUPERVISOR_ENCODED_PASS=hpfatLEoMR6zAK3T1PoP5LXDS

MASTER_REPO_EXTERNAL_ID

External ID of the ODI Master Repository. This can be obtained from the Master Repository editor in ODI Studio.

MASTER_REPO_EXTERNAL_ID=12345

4. Define the environment variables shown in Table 7-2:

Table 7-2 Environment Variables to Define for OPMN Configuration

Variable

Description

MW_HOME

Path to the Middleware home directory.

OPMN_HOME

Path to the Web Tier Oracle home directory (For example, MW_HOME/Oracle_WT1).

ODI_AGENT_HOME

Path to the Standalone Agent directory (for example, ODI_HOME/oracledi/agent).

5. Run the following commands:

sed -ie "s|%WAS_HOME%|$WAS_HOME|g" $WT_ORACLE_HOME/opmn/bin/opmnctl
cp $MW_HOME/oracle_common/.product.properties $WT_ORACLE_HOME
sed -ie "s|WAS |WAS|" $WT_ORACLE_HOME/.product.properties

6. Prepare a password file for the IBM WebSphere default truststore, which is required for OPMN commands. Create the file WAS_HOME/profiles/profile_name/etc/SampleClientTrustFile.jks
Then, create the file WAS_HOME/profiles/profile_name/etc/password.txt and in the file, enter the default password WebAS followed by a new line.

7. Create an OPMN instance using the opmnctl createinstance command. This command must be run in the same shell where the ODI_AGENT_HOME environment variable has been defined:

cd WT_ORACLE_HOME/opmn/bin
./opmnctl createinstance
-oracleInstance WT_ORACLE_HOME/instances/instance2
-oracleHome WT_ORACLE_HOME
-adminHost administration_server_hostname
-adminPort administation_server_port
-logLevel FINER
-wasCell was_cell_name
-wasNode was_node_name
-wasTrustStore WAS_HOME/profiles/profile_name/etc/SampleClientTrustFile.jks
-wasTrustStorePasswordFile WAS_HOME/profiles/profile_name/etc/password.txt

Be sure to replace the variables with the actual values on your own system.

8. Set the INSTANCE_HOME environment variable as WT_ORACLE_HOME/instances/instance1, then run the following command:

sed -ie "s|%WAS_HOME%|$WAS_HOME|g" $INSTANCE_HOME/bin/opmnctl

9. Create an OPMN component for the ODI Standalone Agent in the instance created above using the opmnctl createcomponent command:

cd WT_ORACLE_HOME/instances/instance2/bin
./opmnctl createcomponent
-componentType "odiagent"
-componentName "odi_sa_agent1"
-propertiesFile ODI_HOME/oracledi/agent/bin/agentcreate.properties
-logLevel FINER
-wasCell was_cell_name
-wasNode was_node_name
-wasTrustStore WAS_HOME/profiles/profile_name/etc/SampleClientTrustFile.jks
-wasTrustStorePasswordFile WAS_HOME/profiles/profile_name/etc/password.txt

10. Start the ODI Standalone Agent:

./opmnctl startall

11. Login to Fusion Middleware Control and verify that the Standalone Agent has been discovered.

8 Managing Web Services on IBM WebSphere

Oracle Infrastructure Web Services and Oracle Web Services Manager are supported on IBM WebSphere, with some limitations. The tasks required to secure and administer Oracle Infrastructure Web services are described in Oracle Fusion Middleware Security and Administrator's Guide for Web Services. This chapter provides specific information for managing Oracle Fusion Middleware Web services on IBM WebSphere, and describes the limitations.

This chapter contains the following sections:

- Section 8.1, "Configuring a Default Administrative User from the LDAP Directory"

- Section 8.2, "Configuring Oracle WSM on IBM WebSphere"

- Section 8.3, "Differences and Restrictions When Developing Web Services Applications on IBM WebSphere"

- Section 8.4, "Differences and Restrictions When Managing Web Services Components on IBM WebSphere"

- Section 8.5, "Using the Web Services wsadmin Commands"

8.1 Configuring a Default Administrative User from the LDAP Directory

On WebSphere, Oracle Platform Security Services (OPSS) supports LDAP-based registries only; in particular, it does not support WebSphere's built-in file-based user registry. For information about configuring an LDAP registry and seeding the registry with users and groups required by Fusion Middleware components such as Oracle WSM, see Chapter 9, "Managing Oracle Fusion Middleware Security on IBM WebSphere.".

By default, the Oracle WSM Policy Manager uses the wasadmin administrative user to communicate with the server. If this user is not available in the LDAP, you must configure the policy manager to use a principle administrative user from the LDAP as described in the following procedure.

1. Configure the LDAP registry as described in "IBM WebSphere Identity Stores" and restart the server.

Note:

The remaining steps in this procedure use the following sample primary user properties: cn=orcladmin,cn=Users,dc=us,dc=oracle,dc=com and orcladmin-csf-key for the jndi.lookup.csf.key that will be used for the administrator user access. The values for these properties will vary depending on your environment.

2. Update the credential store cwallet.sso file and the security role mappings using wsadmin commands as follows:

Opss.createCred (map='oracle.wsm.security', key='orcladmin-csf-key',
user='cn=orcladmin,cn=Users,dc=us,dc=oracle,dc=com', password='welcome1',
desc='wsm-pm admin user csf-key')

AdminApp.edit ('wsm-pm', '[-MapRolesToUsers [[policy.Updater
AppDeploymentOption.No AppDeploymentOption.No
cn=orcladmin,cn=Users,dc=us,dc=oracle,dc=com "" AppDeploymentOption.No
"user:cn=orcladmin,cn=Users,dc=us,dc=oracle,dc=com" "" ]]]']

AdminApp.edit('wsm-pm', '[ -MapRolesToUsers [[ policy.Accessor
AppDeploymentOption.No AppDeploymentOption.No
cn=orcladmin,cn=Users,dc=us,dc=oracle,dc=com "" AppDeploymentOption.No " |user:cn=orcladmin,cn=Users,dc=us,dc=oracle,dc=com" "" ]]]' )

AdminApp.edit('wsm-pm', '[ -MapRolesToUsers [[ policy.User
AppDeploymentOption.No AppDeploymentOption.No
cn=orcladmin,cn=Users,dc=us,dc=oracle,dc=com "" AppDeploymentOption.No "
user:cn=orcladmin,cn=Users,dc=us,dc=oracle,dc=com" "" ]]]' )

AdminApp.edit('wsm-pm', '[ -MapRolesToUsers [[ policyViewer AppDeploymentOption.No AppDeploymentOption.No cn=orcladmin,cn=Users,dc=us,dc=oracle,dc=com "" AppDeploymentOption.No " |user:cn=orcladmin,cn=Users,dc=us,dc=oracle,dc=com" "" ]]]' )

AdminConfig.save()

exit

Note:

The syntax for the policyViewer property differs from that of the other properties in that it does not include the separating period. Specifically, the syntax for these properties is policy.Updater, policy.Accessor, policy.User, policyViewer.

3. Restart the server.

8.2 Configuring Oracle WSM on IBM WebSphere

The following sections describe how to configure Oracle WSM and connect to the policy manager:

- Configuring Oracle WSM

- Connecting to the Oracle WSM Policy Manager

8.2.1 Configuring Oracle WSM

Oracle WSM is installed by default when you install Oracle Fusion Middleware SOA Suite or Oracle Application Development Runtime. For more information about installation, see Chapter 2, "Installing and Configuring Oracle Fusion Middleware on IBM WebSphere."

To configure Oracle Fusion Middleware in a new IBM WebSphere environment, you use a special version of the Oracle Fusion Middleware Configuration Wizard as described in "Using the Configuration Wizard" in Configuration Guide for IBM WebSphere Application Server.

To configure Oracle WSM when you create or extend a cell using the Configuration Wizard, be sure to select the following options in the Add Products to Cell screen:

- Oracle Enterprise Manager for WebSphere

- Oracle WSM Policy Manager

If you plan to use asynchronous Web services, select Oracle JRF WebServices Asynchronous services also. For more information, see "Asynchronous Web Services".

Note:

Oracle JRF for WebSphere is automatically selected as a dependency when you select any of the above products.

8.2.2 Connecting to the Oracle WSM Policy Manager

In a WebSphere environment, the Oracle WSM Policy Manager does not run on the same server as Oracle Enterprise Manager. Therefore, the Oracle WSM automatic discovery feature cannot locate and connect to an Oracle WSM Policy Manager. To connect to the policy manager, use the following procedure:

1. In the navigator pane of Enterprise Fusion Middleware Control, expand WebSphere Cell to view the cells.

2. Select the cell for which you want to configure the policy manager.

3. Right-click the name of the cell and from the menu select Web Services then Platform Policy Configuration.
The Platform Policy Configuration page displays, as shown in Figure 8-1.

Figure 8-1 Platform Policy Configuration

4. Select the Policy Accessor tab.
The Policy Accessor tab enables you to explicitly set a remote JNDI provider URL and corresponding csf-key credentials to access a Policy Manager on a remote server.

5. Click Add to define the remote JNDI provider.
In the Add New Configure Property window, specify the following values:

1. In the Name field, enter the JNDI provider URL property as java.naming.provider.url.

2. In the Value field, enter the URL for the server on which the policy manager is running. For example:

corbaloc:iiop:hostname:rmiport

where hostname specifies the DNS name or IP address of the WebSphere server and rmiport specifies the port number on which the policy manager is running.

3. Click OK.

6. Click Add to define a corresponding csf-key credential property.
If the location of the Oracle WSM Policy Manager is provided in the java.naming.provider.url property, the jndi.lookup.csf.key provides the credential configuration.

Note:

The csf-key that you specify in this step must match the csf-key specified for the Policy Manager administrative user in the credential store. For more information about adding an Oracle WSM Policy Manager administrative user to the credential store, see "Configuring a Default Administrative User from the LDAP Directory".

In the Add New Configure Property window, specify the following values:

1. In the Name field, enter the name of the JNDI provider's csf-key credential property as jndi.lookup.csf.key.

2. In the Value field, enter the csf-key credentials.
Because the Policy Manager is security enabled, the csf-key specifies the java.naming.security.principal and java.naming.security.credentials when using the JNDI URL to look up a Policy Manager.

For example, using the sample provided in "Configuring a Default Administrative User from the LDAP Directory", the administrative user is orcladmin and the csf-key is orcladmin-csf-key.

3. Click OK.
Figure 8-2 shows the Policy Accessor tab with the java.naming.provider.url and jndi.lookup.csf.key property settings.

Figure 8-2 Policy Accessor Property Settings

For information about additional properties you can set on the Policy Accessor tab, see "Configuring Web Service Policy Retrieval" in Oracle Fusion Middleware Security and Administrator's Guide for Web Services.

7. Optionally, select the Policy Cache tab.
The Policy Cache tab allows you to tune the behavior of the policy cache delay for Web service endpoints, which can help to avoid network calls and increase performance when fetching policies from a remote Oracle WSM Policy Manager.

8. To modify an existing policy cache property, select it and then click Edit. In the Edit Policy Cache Property window, you can edit the Value field to change the default amount for the property.
You may want to edit the following property:

- cache.tolerance – This ensures that the policy set retrieved from the Web service endpoint policy cache is the most current version (that is, it has not exceeded the cache.tolerance value). If it is determined that the policy set is stale, the updated policy set is retrieved from the Oracle WSM policy manager and refreshed in the Web service endpoint policy cache. The default is 60000 milliseconds (1 minute).

9. To add another property, click Add, and in the Add New Policy Cache Property window, specify the necessary values.

10. To delete an existing property, select it and then click Delete.

11. Click Apply to apply the property updates.

8.3 Differences and Restrictions When Developing Web Services Applications on IBM WebSphere

The following sections describe the differences when developing Web services applications on IBM WebSphere:

- High Availability

- Asynchronous Web Services

- JDeveloper

8.3.1 High Availability

Not all high availability (HA) features may be available at the same quality of service levels as WebLogic Server.

For example, Jython scripts are not available to configure the Java Object Cache in a clustered environment.

8.3.2 Asynchronous Web Services

Asynchronous Web services are supported on platforms other than WebLogic Server. For asynchronous Web services to function, the following JMS default queues must be present:

- oracle.j2ee.ws.server.async.DefaultRequestQueue

- oracle.j2ee.ws.server.async.DefaultResponseQueue

- oracle.j2ee.ws.server.async.DefaultRequestErrorQueue

- oracle.j2ee.ws.server.async.DefaultResponseErrorQueue

- weblogic.jms.XAConnectionFactory

To create these queues, you must configure Oracle JRF Asynchronous Web Services using the Oracle Fusion Middleware Configuration Wizard. You do so in the Add Products to Cell screen in the Configuration Wizard as described in "Configuring Oracle WSM". Once you have created or extended a cell with this template, the JMS queues are available for use.

8.3.3 JDeveloper

When using JDeveloper, the remote Oracle WSM policy store on a WebSphere server is not available.

8.4 Differences and Restrictions When Managing Web Services Components on IBM WebSphere

The following sections describe the differences and restrictions for managing Web services components on IBM WebSphere:

- Automatic Discovery of Oracle WSM Policy Manager

- Web Services Atomic Transactions

- No Support for Native Web Services

- Reliable Messaging

- Enterprise Manager Fusion Middleware Control

8.4.1 Automatic Discovery of Oracle WSM Policy Manager

Automatic discovery of the Oracle WSM policy manager is not supported by third-party application servers, such as WebSphere. For details about connecting to the policy manager, see "Configuring Oracle WSM on IBM WebSphere".

8.4.2 Web Services Atomic Transactions

Web Services Atomic Transactions (WSAT) are not supported and will result in runtime errors.

8.4.3 No Support for Native Web Services

Native Web services, such as those that are deployed to a stack other than the Oracle Infrastructure Web Services stack, are not exposed in the WSIL. Only the deployed Oracle Infrastructure Web Services are listed. The WSIL application is deployed on every server as part of the JRF template and the URI to access the application is /inspection.wsil. The wsil application uses basic HTTP authentication to ensure that only authorized users can access the list of Web services.

8.4.4 Reliable Messaging

WS-Reliable Messaging (WS-RM) is supported on IBM WebSphere with the following limitations:

- WS-RM includes support for persistent database (DB) message store with Oracle databases only.

- WS-RM supports clustering only when Coherence is installed and available. This behavior is the same as WebLogic Server on all the platforms where Coherence is available.

8.4.5 Enterprise Manager Fusion Middleware Control

On IBM WebSphere, you access the Web services pages in Fusion Middleware Control using either of the following methods:

- From the main WebSphere Cell menu, select Web Services, then the desired Web services page, as shown in Figure 8-3.

Figure 8-3 Web Services Menu

- In the navigation pane, right-click on the target cell name, then select Web Services, then the desired Web services page.

The following limitations and differences apply when managing Web services using Fusion Middleware Control:

- You cannot view or manage Web services at the server level.

- The bulk policy attachment feature is not available.

- The registered sources and services, and publish to UDDI features are not available.

- The Application Deployment Summary page does not include the list of Web Services, or the Most Requested table.

- Native WebSphere Web services are not supported.

- The Usage Analysis page displays the WebSphere cell and server names.

8.5 Using the Web Services wsadmin Commands

The Web services wsadmin commands are identical to the custom Web services WebLogic Scripting Tool (WLST) commands provided for WebLogic Server. The Web services commands are grouped into two categories:

- WebServices—These commands consist of the Web service and client management commands, and the policy management commands. For a complete list of these commands, see "WebServices wsadmin Commands".

- wsmManage—These commands consist of the policy set management commands, the import/export repository commands, and the Oracle WSM repository maintenance commands. For a complete list of these commands, see "wsmManage wsadmin Commands".

Note:

Because the Oracle WSM Policy Manager is security enabled, you must pass Java system properties, such as username and password, when invoking wsadmin. For details about invoking wsadmin and using the wsadmin commands, see "Using the Oracle Fusion Middleware wsadmin Commands"

Refer to the following sections for more information:

- Executing the Web Services wsadmin Commands

- WebServices wsadmin Commands

- wsmManage wsadmin Commands

8.5.1 Executing the Web Services wsadmin Commands

To execute the wsadmin commands, you must prefix each command with the category name. That is, each command in the WebServices category must be preceded by WebServices, and each command in the wsmManage category must be preceded with wsmManage. For example:

- To execute a command in the WebServices category, such as the listWebServices() command, enter the following:

wsadmin>WebServices.listWebServices(None, None, 'true')

/NonTLRCell/OracleAdminServer/j2wbasicPolicy :
moduleName=j2wbasicPolicy, moduleType=web, serviceName=WssUsernameService
enableTestPage: true
enableWSDL: true

JRFWssUsernamePort      http://host.example.com:9002/j2wbasicPolicy/WssUsername
enable: true
enableREST: false
enableSOAP: true
maxRequestSize: -1
loggingLevel: NULL
wsat.flowOption: NEVER
wsat.version: DEFAULT
security : oracle/wss_username_token_service_policy, enabled=true, effective=true
addressing : oracle/wsaddr_policy, enabled=true
(global) security : oracle/binding_authorization_permitall_policy, enabled=true
/policysets/global/app-only-web-service-policies : Application("j2wbasicPolicy")
Attached policy or policies are valid; endpoint is secure.

- To execute a command in the wsmManage category, such as the listPolicySets() command, enter the following:

wsadmin>wsmManage.listPolicySets()

Global Policy Sets in Repository:
all-cells-default-web-service-policies
app-only-web-service-policies

8.5.2 WebServices wsadmin Commands

The following table identifies the WebServices management wsadmin commands that are supported on WebSphere, and provides links to the reference documentation in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference. Sample procedures for using the commands are described in the following chapters in Oracle Fusion Middleware Security and Administrator's Guide for Web Services:

- Administering Web Services

- Managing Web Service Policies

- Attaching Policies to Web Services

Note:

You can use these commands as described in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference and Oracle Fusion Middleware Security and Administrator's Guide for Web Services. However, in a WebSphere environment, you must execute the commands as described in "Executing the Web Services wsadmin Commands".

Table 8-1 WebServices wsadmin Commands Supported on IBM WebSphere

Command

Description

listWebServices

List the Web service information for an application, composite, or cell.

listWebServicePorts

List the Web service ports for a Web service application or SOA composite.

listWebServiceConfiguration

List Web services and port configuration for an application or SOA composite.

listWebServiceClients

List Web service client information for an application, SOA composite, or cell.

listWebServiceClientPorts

List Web service client ports information for an application or SOA composite.

listWebServiceClientStubProperties

List Web service client port stub properties for an application or SOA composite.

setWebServiceConfiguration

Set or change the Web service port configuration for a Web service application or SOA composite.

setWebServiceClientStubProperty

Set, change, or delete a single stub property of a Web service client port for an application or SOA composite.

setWebServiceClientStubProperties

Configure the set of stub properties of a Web service client port for an application or SOA composite.

listAvailableWebServicePolicies

Display a list of all the available Oracle Web Services Manager (WSM) policies by category or subject type.

listWebServicePolicies

List Web service port policy information for a Web service in an application or SOA composite.

listWebServiceClientPolicies

List Web service client port policies information for an application or SOA composite.

attachWebServicePolicy

Attach a policy to a Web service port of an application or SOA composite.

attachWebServicePolicies

Attach multiple policies to a Web service port of an application or SOA composite.

attachWebServiceClientPolicy

Attach an Oracle WSM policy to a Web service client port of an application or SOA composite.

attachWebServiceClientPolicies

Attach multiple policies to a Web service client port of an application or SOA composite.

enableWebServicePolicy

Enable or disable a policy attached to a port of a Web service application or SOA composite.

enableWebServicePolicies

Enable or disable multiple policies attached to a port of a Web service application or SOA composite.

enableWebServiceClientPolicy

Enable or disable a policy of a Web service client port of an application or SOA composite.

enableWebServiceClientPolicies

Enable or disable multiple policies of a Web service client port of an application or SOA composite.

detachWebServicePolicy

Detach an Oracle WSM policy from a Web service port of an application or SOA composite.

detachWebServicePolicies

Detach multiple Oracle WSM policies from a Web service port of an application or SOA composite.

detachWebServiceClientPolicy

Detach a policy from a Web service client port of an application or SOA composite.

detachWebServiceClientPolicies

Detach multiple policies from a Web service client port of an application or SOA composite.

setWebServicePolicyOverride

Configure the Web service port policy override properties of an application or SOA composite.

8.5.3 wsmManage wsadmin Commands

The following table identifies the wsmManage commands that are supported on WebSphere, and provides links to the reference documentation in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference. Sample procedures for using these commands are described in the following chapters in Oracle Fusion Middleware Security and Administrator's Guide for Web Services:

- Creating and Managing Policy Sets

- Managing Application Migration Between Environments

- Maintaining the Oracle WSM MDS Repository

Note:

You can use these commands as described in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference and Oracle Fusion Middleware Security and Administrator's Guide for Web Services. However, in a WebSphere environment, you must execute the commands as described in "Executing the Web Services wsadmin Commands".

Table 8-2 wsmManage Commands Supported on IBM WebSphere

Command

Description

beginRepositorySession

Begin a session to modify the Oracle MDS repository.

commitRepositorySession

Write the contents of the current session to the Oracle MDS repository.

abortRepositorySession

Abort the current Oracle MDS repository modification session, discarding any changes that were made to the repository during the session.

describeRepositorySession

Describe the contents of the current repository session.

attachPolicySet

Attach a policy set to the specified resource scope.

attachPolicySetPolicy

Attach a policy to a policy set using the policy's URI.

detachPolicySetPolicy

Detach a policy from a policy set using the policy's URI.

clonePolicySet

Clone a new policy set from an existing policy set.

createPolicySet

Create a new, empty policy set.

deletePolicySet

Delete a specified policy set.

deleteAllPolicySets

Delete all or selected policy sets from within the Oracle WSM repository.

displayPolicySet

Display the configuration of a specified policy set.

enablePolicySet

Enable or disable a policy set.

enablePolicySetPolicy

Enable or disable a policy attachment for a policy set using the policy's URI.

listPolicySets

Lists the policy sets in the repository.

modifyPolicySet

Specify an existing policy set to be modified in the current session.

setPolicySetPolicyOverride

Add a configuration override to a policy reference in the current policy set.

setPolicySetConstraint

Specify a run-time constraint value for a policy set selected within a session.

setPolicySetDescription

Specify a description for the policy set selected within session.

validatePolicySet

Validate existing policy set in the repository or in a session.

migrateAttachments

Migrates direct policy attachments to global policy attachments if they are identical.

importRepository

Import a set of documents from a supported ZIP archive file into the repository. You can provide the location of a file that describes how to map physical information from the source environment to the target environment.

exportRepository

Export a set of documents from the repository into a supported ZIP archive. If the specified archive already exists, you can choose whether to overwrite the archive or merge the documents into the existing archive.

upgradeWSMPolicyRepository

Upgrade the Oracle WSM predefined policies stored in the Oracle MDS repository with any new predefined policies that are provided in the latest installation of the Oracle Fusion Middleware software.

resetWSMPolicyRepository

Delete the existing policies stored in the Oracle MDS repository and refresh it with the latest set of predefined policies that are provided in the new installation of the Oracle Fusion Middleware software.

9 Managing Oracle Fusion Middleware Security on IBM WebSphere

This chapter contains information about managing Oracle Fusion Middleware security on IBM WebSphere, and it explains the particularities of some Oracle Platform Security Services (OPSS) features on that platform.

OPSS is a security platform that can be used to secure applications deployed in any of the supported platforms or in standalone applications.

Only topics that apply specifically to IBM WebSphere are included in this chapter; those that apply uniformly to all platforms are not described here, but can be found in Oracle Fusion Middleware Application Security Guide.

In regards to OPSS scripts:

On IBM WebSphere, OPSS scripts have a slightly different syntax (than that used on the WebLogic platform): script names are prefixed with the string "Opss." Unless explicitly stated, arguments remain identical to the WebLogic case.

This chapter contains the following sections:

- Section 9.1, "IBM WebSphere Identity Stores"

- Section 9.2, "Recommendation for Multiple-Node Environments"

- Section 9.3, "Configuring the Trust Association Interceptor"

- Section 9.4, "Migrating Policies at Deployment"

- Section 9.5, "Migrating Credentials at Deployment"

- Section 9.6, "Reassociating Policies with reassociateSecurityStore"

- Section 9.7, "Deployment Mode"

- Section 9.8, "Configuring the JpsFilter and the JpsInterceptor"

- Section 9.9, "Using System Variables in Code Source URLs"

- Section 9.10, "Sample opss-application File"

- Section 9.11, "About the File web.xml"

- Section 9.12, "Executing Common Audit Framework wsadmin Commands"

- Section 9.13, "Configuring TAI to Work with OPSS"

- Section 9.14, "Creating a Data Source"

- Section 9.15, "Executing Keystore Service Commands"

- Section 9.16, "Setting Parameters for Custom Audit Service Registration"

9.1 IBM WebSphere Identity Stores

On IBM WebSphere, OPSS supports LDAP-based registries only; in particular, it does not support WebSphere's built-in file-based user registry.

For information about the list of LDAP authenticators supported for Oracle Fusion Middleware, visit http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html

For the special configuration required for the Open LDAP 2.2, see Oracle Fusion Middleware Application Security Guide.

The configuration and seeding of a repository is explained in the following sections:

- Configuring a Registry

- Seeding a Registry

9.1.1 Configuring a Registry

The configuration of an LDAP registry on IBM WebSphere is accomplished with the command configureIdentityStore, an online administration command with the following syntax:

wsadmin> Opss.configureIdentityStore(propsFileLoc="fileLocation")

propsFileLoc specifies the location of the file that contains the property settings for the identity LDAP identity store. This command modifies the configuration file jps-config.xml to include the specifications in the property file.

After running Opss.configurIdentityStore, the server must be restarted.

The following properties are required and must be specified in property settings file:

- ldap.host

- ldap.port

- admin.id

- admin.pass

- idstore.type

- user.search.bases

- user.id.map

- group.id.map

- group.member.id.map

- group.search.bases

- primary.admin.id

The following list includes optional properties specific to a IBM WebSphere registry:

- group.filter

- user.filter

The following sample illustrates the property settings for an Oracle Directory Server Enterprise Edition identity store:

user.search.bases=cn=Users,dc=us,dc=oracle,dc=com
group.search.bases=cn=Groups,dc=us,dc=oracle,dc=com
subscriber.name=dc=us,dc=oracle,dc=com
user.selected.create.base=cn=Users,dc=us,dc=oracle,dc=com
group.selected.create.base=cn=Users,dc=us,dc=oracle,dc=com
ldap.host=myhost.example.com
ldap.port=3060
# admin.id must be the full DN of the user in the LDAP
admin.id=cn=orcladmin
admin.pass=welcome1
user.filter=(&(uid=%v)(objectclass=person))
group.filter=(&(cn=%v)(objectclass=groupofuniquenames))
user.id.map=*:uid
group.id.map=*:cn
group.member.id.map=groupofuniquenames:uniquemember

# In case of type=ACTIVE_DIRECTORY, the primary.admin.id indicates a user
# who has admin permissions in the LDAP,and it must be the name of the user
# for example, for user "cn=tom", the primary.admin.id is "tom"
# for any other type, the primary.admin.id is wasadmin or orcladmin
primary.admin.id=orcladmin

# optional, default to "OID"
idstore.type=IPLANET

# other, optional identity store properties can be configured in this file.
username.attr=cn

# if ssl is set to true, SSL has to be set as explained in the procedure below
# before executing the command
ssl=false

The list of valid identity store types is the following:

- OID

- IPLANET

- OVD

- ACTIVE_DIRECTORY

- OPEN_LDAP

If ssl was set to true, before invoking the command, proceed as follows:

1. In the WAS console, navigate to Security > Global security.

2. In User account repository, select Available realm definitions, and then Standalone LDAP registry; then click Configure.

3. In SSL setting, click SSL configurations, select CellDefaultSSLSettings > Key stores and certificates > CellDefaultTrustStore.

4. Set Path: ${CONFIG_ROOT}/cells/dmgrCell/DummyClientTrustFile.jkd

5. Set Password: myWebAS

6. Set Type: JKS

7. Click OK then Save.

8. Import the Client_keystore.jks to DummyClientTrustFile.jks by invoking a command like the following:

$keytool -importkeystore -srckeystore client_keystore.jks -destkeystore
<WAS_Profile>/dmgr/etc/DummyClientTrustFile.jks -srcstoretype JKS
-deststoretype JKS  -srcstorepass welcome1 -deststorepass myWebAS

9. Copy the file DummyClientTrustFile.jks to path specified in step 4 above:

cp <WAS_Profile>/dmgr/etc/DummyClientTrustFile.jks
<WAS_Profile>/dmgr/config/cells/dmgrCell/

9.1.2 Seeding a Registry

Some Oracle Fusion Middleware components require that certain users and groups be present in the IBM WebSphere identity store. To ensure that this requirement is met, use any tools to seed the required data; in particular, you can use an LDIF file and the LDAP utility bulkload to load users and groups into the identity store. Here is a sample LDIF file:

dn: cn=OracleSystemUser,dc=com
userPassword: welcome1
sn: OracleSystemUser
cn: OracleSystemUser
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top

dn: cn=OracleSystemGroup,dc=com
cn: OracleSystemGroup
objectclass: groupOfUniqueNames

dn: cn=Administrators,dc=com
cn: Administrators
objectclass: groupOfUniqueNames

dn: cn=SystemMDBRole,dc=com
cn: SystemMDBRole
objectclass: groupOfUniqueNames
uniquemember: cn=OracleSystemUser,dc=com

9.2 Recommendation for Multiple-Node Environments

In environments where several server instances are distributed across multiple machines, it is highly recommended that the OPSS security store be LDAP- or DB-based configured in the dmgr server.

If, however, a file- based store is used in a multiple-node environment (not recommended), any changes to the store should be performed in the dmgr server so that those changes can be propagated to all other servers in the environment. The data on servers other than dmgr is refreshed based on caching configuration.

9.3 Configuring the Trust Association Interceptor

HTTP clients can pass identity information to WebSphere Application Server using the Trust Association Interceptor (TAI). OPSS uses TAI as the asserter that intercepts calls coming into WebSphere cells to support identity propagation across containers and cells.

To configure TAI, proceed as follows:

1. Login to the IBM WebSphere Administrative Console.

2. Select Security > Click Global Security.

3. In the opened page, navigate to Authentication.

4. Expand Web and SIP security, and click Trust Association.

5. Check the box Enable Trust Association and save your changes.

6. Return to the Trust Association page and click Additional Properties > Interceptors.

7. Click New.

8. In the Interceptor Class Name box, enter the following string:

oracle.security.jps.was.providers.trust.TrustServiceAsserterTAI

This class is packaged in the JAR file jps-was.jar.

9. Save your changes.

9.4 Migrating Policies at Deployment

The migration of application policies at deployment is controlled by several parameters configured in the file META-INF/opss-application.xml. For an example of this file, see Sample opss-application File. To reassociate the policy store after deployment, see Reassociating Policies with reassociateSecurityStore.

The supported parameters, including configuration examples, are explained in the following sections:

- jps.policystore.migration

- jps.policystore.applicationid

- jps.policystore.removal

Note that the following parameters are not supported on IBM WebSphere:

JpsApplicationLifecycleListener
Jps.apppolicy.idstoreartifact.migration
Jps.policystore.migration.validate.principal

9.4.1 jps.policystore.migration

This parameter specifies whether the migration should take place, and, when it does, whether it should merge with or overwrite matching policies present in the target store.

On IBM WebSphere, it is configured as illustrated in the following fragment:

<service type="POLICY_STORE">
<property name="jps.policystore.applicationid" value="stripeid" />
<property name="jps.policystore.migration" value="overwrite" />
<property name="jps.policystore.removal" value="off" />
</service>

For more details about this parameter, see Oracle Fusion Middleware Application Security Guide.

9.4.2 jps.policystore.applicationid

This parameter specifies the target stripe into which policies are migrated.

On IBM WebSphere, it is configured as illustrated in the following fragment:

<service type="POLICY_STORE">
<property name="jps.policystore.applicationid" value="stripeid" />
<property name="jps.policystore.migration" value="overwrite" />
<property name="jps.policystore.removal" value="off" />
</service>

For more details about this parameter, see Oracle Fusion Middleware Application Security Guide.

9.4.3 jps.policystore.removal

This parameter specifies whether the removal of policies at undeployment should not take place.

On IBM WebSphere, it is configured as illustrated in the following fragment:

<service type="POLICY_STORE">
<property name="jps.policystore.applicationid" value="stripeid" />
<property name="jps.policystore.migration" value="overwrite" />
<property name="jps.policystore.removal" value="off" />
</service>

For more details about this parameter, see Oracle Fusion Middleware Application Security Guide.

9.5 Migrating Credentials at Deployment

The migration of application credentials at deployment is controlled by a parameter configured in the file META-INF/opss-application.xml. For an example of this file, see Sample opss-application File.

The supported parameter, including a configuration example, are explained in the following section:

- jps.credstore.migration

Note that the following parameter is not supported on IBM WebSphere:

jps.ApplicationLifecycleListener

9.5.1 jps.credstore.migration

This parameter specifies whether the migration should take place, and, when it does, whether it should merge with or overwrite matching credentials present in the target store.

On IBM WebSphere, it is configured as illustrated in the following fragment:

<service type="CREDENTIAL_STORE">
<property name="jps.credstore.migration" value="overwrite" />
</service>

Setting jps.credstore.migration to overwrite requires that the system property jps.app.credential.overwrite.allowed be set to true.

For more details about this parameter, see Oracle Fusion Middleware Application Security Guide.

9.6 Reassociating Policies with reassociateSecurityStore

For complete details about the scrip reassociateSecurityStore to reassociate the policy store, see Oracle Fusion Middleware Application Security Guide. Since this script is likely to run for some time, to avoid exceptions, one may need to reset the default connection to the server timeout to an appropriate larger value.

To reset the default connection timeout, proceed as follows:

1. Open the file soap.client.props, located in the properties subdirectory of the profile_root directory, for edit.

2. In that file, modify the value of the property com.ibm.SOAP.requestTimeout to a desire value, such as 1200 (seconds).

3. Save and close the file.

The following is a sample run of this scrip:

wsadmin> Opss.reassociateSecurityStore(domain="farm", servertype="DB_ORACLE", jpsroot="cn=jpsroot", datasourcename="opss_ds")

9.7 Deployment Mode

On IBM WebSphere, deployment is supported only in online mode; no offline deployment is supported.

9.8 Configuring the JpsFilter and the JpsInterceptor

On IBM WebSphere, both the JpsFilter and the JpsInterceptor must be manually configured.

For the properties supported and configuration examples, see Oracle Fusion Middleware Application Security Guide.

9.9 Using System Variables in Code Source URLs

The system variables oracle.deployed.app.dir and oracle.deployed.app.ext can be used to specify a URL independent of the platform. For a configuration example using these variables, see Oracle Fusion Middleware Application Security Guide.

9.10 Sample opss-application File

The following sample illustrates the contents of the opss-application.xml file.

<?xml version="1.0" encoding="UTF-8" standalone='yes'?>
<opss-application  xmlns="http://xmlns.oracle.com/oracleas/schema/11/opss-application-11_1.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/oracleas/schema/11/opss-application-11_1.xsd" schema-major-version="11" schema-minor-version="1">
<services>
<service type="POLICY_STORE">
<property name="jps.policystore.applicationid" value="stripeid" />
<property name="jps.policystore.migration" value="MERGE" />
</service>
<service type="CREDENTIAL_STORE">
<property name="jps.credstore.migration" value="MERGE" />
</service>
</services>
</opss-application>

9.11 About the File web.xml

The element <auth-method> in a web.xml file is WebLogic-specific and not supported on IBM WebSphere; if found, it must be replaced with the equivalent functionality supported for IBM WebSphere's web.xml files.

9.12 Executing Common Audit Framework wsadmin Commands

To run audit commands, provided by Oracle Fusion Middleware's Common Audit Framework, you need to do the following:

1. Start the Oracle Fusion Middleware wsadmin command-line shell.

2. Prefix the audit commands with the keyword Audit. For example:

wsadmin> Audit.getAuditPolicy()
wsadmin> Audit.setAuditPolicy()

wsadmin> Audit.setAuditRepository
(['switchToDB'],['dataSourceName'],['interval'])
(see Section 9.14, "Creating a Data Source" for a related topic)

For details about the audit commands, see the Oracle Fusion Middleware Application Security Guide.

9.13 Configuring TAI to Work with OPSS

This section describes the settings required for TAI to work with the OPSS keystore on the WebSphere platform, in the following sections:

- Section 9.13.1, "Configuring TAI with the WebSphere Console"

- Section 9.13.2, "Configuring the OPSS Keystore Service"

9.13.1 Configuring TAI with the WebSphere Console

To set the Trust Association Interceptor, proceed as follows:

1. Login to WebSphere administrative console.

2. Click Security > Global Security.

3. In the Authentication section, expand Web and SIP security.

4. Click Trust Association, select the check box Enable trust association, and save the settings.

5. Back in the Global Security page, in the Additional Properties section click Interceptors.

6. Click New and enter the following fully-qualified name as the interceptor class name:

oracle.security.jps.was.providers.trust.TrustServiceAsserterTAI

7. Save your changes.

9.13.2 Configuring the OPSS Keystore Service

To configure the OPSS Keystore Service on WebSphere, run the following script with the appropriate values:

# Update following values with correct value
user = "wasadmin"
password = "<password>"
wlsurl = "http(s)://<host>:<port>"

wlsServerName = "AdminServer1"
stripeName = "opss"

#-----------------------------------------------
ksName = "trustservice_ks" + "_" + wlsServerName
tsName = "trustservice_ts"
aliasName = wlsServerName

print "Importing certificate for : " + wlsServerName
print "Stripe Name: " + stripeName

print "TrustStore Name: " + tsName
print "Alias Name: " + aliasName

#-----------------------------------------------
connect(user, password, wlsurl)

svc = getOpssService(name='KeyStoreService')

svc.listKeyStores(appStripe=stripeName)

# Need it to switch Trust service to using FKS
svc.createKeyStore(appStripe=stripeName, name=ksName, password="", permission=true)

svc.createKeyStore(appStripe=stripeName, name=tsName, password="", permission=true)

svc.importKeyStoreCertificate(appStripe=stripeName, name=tsName, password="", alias=aliasName, keypassword="", type="TrustedCertificate", filepath="AdminServer1client.cer")

svc.listKeyStoreAliases(appStripe=stripeName, name=tsName, password="", type="TrustedCertificate")

exit()

9.14 Creating a Data Source

To create a JDBC data source in a WebSphere cell, proceed as follows:

1. Login to the WebSphere Console and navigate to Resources > JDBC > DataSources.

2. Select the appropriate Scope from the pull-down list.

3. Click the button New to display the Create a data source page, and go through the steps listed on the left panel.

4. In step 1, enter a Data Source Name and a JNDI Name; note that the Scope box is read-only and contains the scope selected earlier on. Click Next to go to the next step.

5. In step 2.1, set the Database Type to Oracle, Implementation Type to Connection Pool Data Source, and enter a Name for the provider. Click Next to go to the next step.

6. In step 2.2, ensure that the path designated by the variable ORACLE_JDBC_DRIVER_PATH is correctly set. Click Next to go to the next step.

7. In step 3, set JDBC URL to the appropriate value; a sample value is jdbc:oracle:thin:@xyz12345.example.com:4321:orcl. Click Next to go to the next step.

8. In step 4, click the link Global J2C Authentication Alias to display the page Data Sources > JAAS - J2C Authentication Data.

9. In that page, click New to display the New page.

10. In the New page, enter an Alias, and set User ID and Password to the user name and password of the data base user. Click OK to go back to the JAAS-J2C Authorization page.

11. In that page, if necessary, expand the Message box and click Save.

12. Use the Previous button on your browser to go back to the page in step 4 above. To be able to see the authentication alias you entered, refresh the page by clicking the Previous and Next buttons on your browser.

13. Set Component-Managed Authentication Alias and Container-Managed Authentication Alias to the authentication alias you entered (which should now show on the pull-down lists), and Mapping-Configuration Alias to DefaultPrincipalMapping. Click Next.

14. Click Finish and then Save, to save the specified data source.

15. To validate the newly created data source, navigate to the DataSource page and click Test Connection.

Note:

Some of the steps in the preceding procedure can be accomplished in pages not referenced in the procedure; examples of these pages are the Creating a JDBC Provider and Creating J2C Authentication Data pages.

9.15 Executing Keystore Service Commands

This section provides information about running Keystore Service commands that is specific to IBM WebSphere.

permission Option Requires Quotes

Certain Keystore Service commands include the permission option. When running commands containing this option on IBM WebSphere, enclose the permission option's value in single quotes (''). For example:

wsadmin>Opss.createKeyStore(appStripe='owsm', name='keystore1',
password='password',permission='true')

JDK/JRE Provisioning Requirement

For Keystore Service operations like generateKeyPair/generateSecretKey to work, the IBM WebSphere JDK/JRE needs to be provisioned with unlimited security warranty (that is, with the unlimited strength policy files installed).

9.16 Setting Parameters for Custom Audit Service Registration

You can perform custom registration of your application to the audit service by configuring OPSS deployment descriptors, as explained in Register Application with the Registration Service in the Oracle Fusion Middleware Application Security Guide. On IBM WebSphere you set these registration parameters in the opss-application.xml file.

10 Managing Oracle Business Intelligence on IBM WebSphere

This chapter contains information about installing and managing Oracle Business Intelligence components on IBM WebSphere.

This chapter includes the following sections:

- Section 10.1, "Introduction to Oracle Business Intelligence on IBM WebSphere"

- Section 10.2, "Differences Installing and Configuring Oracle Business Intelligence on IBM WebSphere"

- Section 10.3, "Deinstalling Oracle Business Intelligence and IBM WebSphere"

- Section 10.4, "Upgrading Oracle Business Intelligence to Run on IBM WebSphere"

- Section 10.5, "Troubleshooting Oracle Business Intelligence on IBM WebSphere"

10.1 Introduction to Oracle Business Intelligence on IBM WebSphere

Oracle Business Intelligence provides a full range of business intelligence capabilities that allow you to collect up-to-date data from your organization, present the data in easy-to-understand formats, and deliver data in a timely fashion to the employees in your organization. These capabilities enable your organization to make better decisions, take informed actions, and implement more-efficient business processes.

This section includes the following topics for using Oracle Business Intelligence on IBM WebSphere:

- Using Oracle Business Intelligence on IBM WebSphere

- Using Both IBM WebSphere and WebLogic Server

For complete information on Oracle Business Intelligence, see the documentation at the following location:

http://docs.oracle.com/cd/E23943_01/bi.htm

10.1.1 Using Oracle Business Intelligence on IBM WebSphere

Many of the features of Oracle Business Intelligence behave the same, regardless of whether you install Oracle Business Intelligence on WebLogic Server or on IBM WebSphere. The following list outlines these features:

- Analyses, Dashboards, Actions, Agents, Conditions, KPIs, Scorecards, BI Composer, Oracle Business Intelligence Mobile, Oracle Real-Time Decisions, and Marketing Server — You use the feature in the same way on both WebLogic Server and IBM WebSphere.

- Actions — You use actions that involve web services in the same way on both WebLogic Server and IBM WebSphere. Actions that involve Enterprise Java Beans (EJB) require manual configuration, as described in Section 10.2.9, "Configuring for Actions that Invoke a Java Method on IBM WebSphere."

- Map Views — You use the feature in the same way on both WebLogic Server and IBM WebSphere, but you must manually configure Oracle Fusion Middleware MapViewer, as described in Section 10.2.8, "Configuring for Map Views in Oracle Business Intelligence on IBM WebSphere."

- Oracle BI Publisher — You use the feature in nearly the same way on both WebLogic Server and IBM WebSphere, but manual configuration is required as described in Section 10.2.3, "Configuring for BI Publisher on IBM WebSphere." Scheduling is available for reports using ActiveMQ as a provider, rather than the WebLogic JMS queues. For information on ActiveMQ, see "Scheduler Configuration Reference" in Oracle Fusion Middleware Administrator's Guide for Oracle Business Intelligence Publisher.

- System Management — Features including starting, stopping and configuring Oracle Business Intelligence using Fusion Middleware Control, and using the Catalog Manager. Monitoring metrics, using the Log Viewer, and moving from test to production are not available in this release.

- Single Sign On and Secure Socket Layers — You use the feature in the same way on both WebLogic Server and IBM WebSphere, but manual configuration is required as described in Section 10.2.7.2, "Configuring SSO for Oracle Business Intelligence on IBM WebSphere" and Section 10.2.7.3, "Configuring SSL for Oracle Business Intelligence on IBM WebSphere."

- Oracle BI Web Services — You use the feature in the same way on both WebLogic Server and IBM WebSphere with the exception of Oracle Business Intelligence Metadata Web service and Web Services for SOA, which are not available for IBM WebSphere.

- High-Availability — You use the feature in the same way on both WebLogic Server and IBM WebSphere, but manual configuration is required as described in Section 10.2.11, "Configuring for Scaling the Deployment of Oracle Business Intelligence on IBM WebSphere."

- Upgrading — You can upgrade Oracle Business Intelligence if you have an installation on Oracle WebLogic Server, as described in Section 10.4, "Upgrading Oracle Business Intelligence to Run on IBM WebSphere."

- Oracle BI for Microsoft Office — You use the feature in nearly the same way on both WebLogic Server and IBM WebSphere, but manual configuration is required as described in Section 10.2.10, "Configuring for Oracle BI for Microsoft Office on IBM WebSphere."

The following list describes the limitations of Oracle Business Intelligence on IBM WebSphere for this release:

- Windows, Solaris, and SLES/SUSE platforms are not supported.

- IBM WebSphere Application Server Standalone is not supported.

- The Sample Application for Oracle Business Intelligence is not supported. The SampleAppLite application is supported.

- The following features are not available with IBM WebSphere for this release: Full-text catalog search, multitenancy, Financial Reporting, Calculation Manager, Smart View integration, Essbase Administration Services and Analytic Provider Services, Oracle BI Services for SOA, and Oracle WebCenter Portal integration. The IBM WebSphere integration is not available for an Exalytics In-Memory Machine.

10.1.2 Using Both IBM WebSphere and WebLogic Server

You can use Oracle Business Intelligence components on IBM WebSphere without having WebLogic Server installed, with one exception. If you plan to upgrade from an earlier version of Oracle Business Intelligence, then you must have Oracle Business Intelligence on both WebLogic Server and IBM WebSphere for Release 11g, as described in Section 10.4, "Upgrading Oracle Business Intelligence to Run on IBM WebSphere."

10.2 Differences Installing and Configuring Oracle Business Intelligence on IBM WebSphere

Use the first three chapters of this guide for basic information on installing and configuring Oracle Business Intelligence on IBM WebSphere. This section provides procedures that outline the differences between installing and configuring Oracle Business Intelligence on IBM WebSphere instead of on Oracle WebLogic Server:

- Installing Oracle Business Intelligence on IBM WebSphere

- Configuring Oracle Business Intelligence in a New IBM WebSphere Cell

- Configuring for BI Publisher on IBM WebSphere

- Configuring for Oracle RTD on IBM WebSphere

- Starting and Stopping Components on IBM WebSphere

- Determining Ports for Oracle BI Components on IBM WebSphere

- Configuring for Security of Oracle Business Intelligence on IBM WebSphere

- Configuring for Map Views in Oracle Business Intelligence on IBM WebSphere

- Configuring for Actions that Invoke a Java Method on IBM WebSphere

- Configuring for Oracle BI for Microsoft Office on IBM WebSphere

- Configuring for Scaling the Deployment of Oracle Business Intelligence on IBM WebSphere

- Configuring for Load Balancing with the IBM HTTP Server

10.2.1 Installing Oracle Business Intelligence on IBM WebSphere

Installing Oracle Business Intelligence on IBM WebSphere is similar to installing on Oracle WebLogic Server. When installing on IBM WebSphere, you use the Software-Only installation type to create an IBM WebSphere cell rather than a domain in WebLogic Server.

This section contains the following topics:

- Guidelines for Installing on Oracle Business Intelligence on IBM WebSphere

- Summary of Software Only Install Procedure on IBM WebSphere

10.2.1.1 Guidelines for Installing on Oracle Business Intelligence on IBM WebSphere

Keep the following points in mind as you prepare for installation:

- Ensure that an appropriate version of IBM WebSphere is installed, as specified in the certification document.
See Section 2.1, "Task 1: Review the System Requirements and Certification Information" for details on the certification document.

- Ensure that you use the Repository Creation Utility to configure the BIPLATFORM and MDS schemas that Oracle Business Intelligence uses.
For information, see "Create Database Schemas Using the Repository Creation Utility (RCU)" in Oracle Fusion Middleware Installation Guide for Oracle Business Intelligence.

- Do not install Oracle Business Intelligence into an existing IBM WebSphere cell, which can decrease system security.

- Install IBM WebSphere and Oracle Business Intelligence on the same host.

10.2.1.2 Summary of Software Only Install Procedure on IBM WebSphere

Table 10-1 provides a summary of the procedure for installing Oracle Business Intelligence on IBM WebSphere using the Software Only install type. For complete information on this install type, see "Software Only Install" in Oracle Fusion Middleware Installation Guide for Oracle Business Intelligence.

Table 10-1 Summary of Software Only Install Procedure

Screen

Actions

None

Start Oracle Business Intelligence 11g Installer.

Welcome

Click Next to continue

Install Software Updates

Specify your My Oracle Support account information and software update preferences.

Click Next to continue.

Select Installation Type

Click Software Only Install.

Select this option to copy the software binary files to the target computer. You do not configure the components until after the installation finishes.

Click Next to continue.

Prerequisite Checks

Click Next to continue.

Specify Installation Location

Specify the Oracle Middleware Home location for IBM WebSphere and the Oracle Business Intelligence Home location.

For information on the directory in which IBM WebSphere is installed, see Section 2.4.2.3, "About the WAS_HOME Directory Path."

The locations for the Fusion Middleware Home and the Oracle Home must not be within the directory in which IBM WebSphere is installed.

Click Next to continue.

Application Server

Review and confirm that the IBM WebSphere application server and its location are automatically selected.

Click Next to continue.

Security Updates

Specify your My Oracle Support account information and security update preferences.

Click Next to continue.

Summary

Verify the information on this screen.

Click Back to change the information in a previous screen.

Click Save to save the settings for the installation in a response file.

Click Install to begin the installation

Installation Progress

When the installation is 100% complete, click Next to continue

Complete

Click Finish to exit Oracle Business Intelligence 11g Installer.

10.2.2 Configuring Oracle Business Intelligence in a New IBM WebSphere Cell

To configure Oracle Business Intelligence on IBM WebSphere, you use the Configuration Assistant, similar to how you configure on Oracle WebLogic Server. The Configuration Assistant creates an IBM WebSphere cell, configures the BI_PLATFORM and MDS database schemas, and configures the Oracle Business Intelligence system.

The following procedure describes how to use the Configuration Assistant for Oracle Business Intelligence on IBM WebSphere.

To configure Oracle Business Intelligence software on IBM WebSphere:

1. Set the environment variable and run the Configuration Assistant using commands such as the following ones:

setenv WAS_HOME <install-directory>
ORACLE_HOME/bin/config.sh

2. Configure a new Oracle Business Intelligence system, with a cell and appropriate user name and password.
You cannot scale out or extend the system using the Configuration Assistant.

3. At the end of the configuration process, all processes should be running. See Section 10.5.1, "Verifying the Configuration of Oracle Business Intelligence on IBM WebSphere" for information on viewing running processes.

4. After running the Configuration Assistant, perform the following steps to complete the configuration:

1. Log into the IBM WebSphere Administrative Console.

2. Navigate to Servers, Server Types, and WebSphere Application Servers.

3. Click on the server to which you must apply the custom property, which is usually biserver1.

4. Under Configuration and Container settings, click Web Container Settings, then click Web container.

5. Under Configuration and Additional Properties, click Custom Properties.

6. On the Custom Properties page, click New.

7. On the Settings page, enter com.ibm.ws.webcontainer.invokeFilterInitAtStartup as the name of the property to added in the Name field and enter true in the Value field.
Note that some properties are case-sensitive.

8. Click OK.

9. Click Save in the Messages box that is displayed.

10. Restart the server so that the custom property can take effect.

10.2.3 Configuring for BI Publisher on IBM WebSphere

BI Publisher is installed and primarily configured as part of the process of installing and configuring Oracle Business Intelligence. You must perform additional procedures as described in the following topics:

- Manually Configuring for BI Publisher on IBM WebSphere

- Using the Administration Page in BI Publisher on IBM WebSphere

10.2.3.1 Manually Configuring for BI Publisher on IBM WebSphere

To manually configure for BI Publisher on IBM WebSphere:

1. Stop the processes for IBM WebSphere as described in Section 10.2.5, "Starting and Stopping Components on IBM WebSphere."

2. In a text editor, open the following file:
user_projects/domains/bifoundation_cell/bifoundation_cell_dmgr0/config/cells/bifoundation_cell/fmwconfig/system-jazn-data.xml

3. Locate the app-role section of the file and add an entry for the wasadmin user, as shown in the following example:

<app-role>
<name>BIAdministrator</name>
<display-name>BI Administrator Role</display-name>
<guid>BB2BA241CC0411E1BF58057424DD2C21</guid>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<members>
<member>
<class>weblogic.security.principal.WLSGroupImpl</class>
<name>BIAdministrators</name>
</member>
<member>
<class>weblogic.security.principal.WLSUserImpl</class>
<name>wasadmin</name>
</member>
</members>
</app-role>

Ensure that you add the wasadmin line for the WLSUserImpl class, and not for the WLSGroupImpl class.

4. Save and close the file.

5. Display the Administration page for BI Publisher by entering the following URL:
http://host-name:port-num/xmlpserver

6. Select Administration and Server Configuration. Select Oracle BI EE Catalog for Catalog Type and select Apply.

7. Configure for ActiveMQ, as described in "Configuring BI Publisher for ActiveMQ" in Oracle Fusion Middleware Administrator's Guide for Oracle Business Intelligence Publisher.

8. Restart the processes for IBM WebSphere as described in Section 10.2.5, "Starting and Stopping Components on IBM WebSphere."

10.2.3.2 Using the Administration Page in BI Publisher on IBM WebSphere

When you use BI Publisher on IBM WebSphere, you must use the Administration page to specify the Oracle BI Presentation Catalog. You must always use the following procedure when using the Administration page on IBM WebSphere.

To use the Administration page of BI Publisher on IBM WebSphere:

1. Log in to BI Publisher on the managed server that is running on the same host computer as the OracleAdminServer and the Dmgr for IBM WebSphere.
The managed server is likely named bi_server1.

2. Click Administration and make the appropriate changes.

3. Click Apply.

4. In the IBM WebSphere Administration console, click System Administration, then Nodes.

5. Select all the scaled-out nodes for Oracle Business Intelligence.

6. Click Full Resynchronize button and watch for that to succeed.

7. Click Applications, Application Types, and WebSphere enterprise applications.

8. Select bipublisher_11.1.1 in the application list.

9. Click Stop and watch for the application to show as "Stopped" in the list

10. Select bipublisher_11.1.1 in the application list.

11. Click Start and watch for the application to show as "Started" in the list.

The administration changes are saved and replicated to all nodes of the cluster for Oracle Business Intelligence.

10.2.4 Configuring for Oracle RTD on IBM WebSphere

Oracle RTD is installed and primarily configured as part of the process of installing and configuring Oracle Business Intelligence. You must perform additional procedures as described in the following topics:

- Disabling Parent Class Loading

- Configuring Constraints for User-Defined Web Policy Sets

Then, depending on your system configuration and requirements, you may need to perform the following procedures:

- Installing Oracle RTD Client-Side Files

- Populating the Example Data Tables

10.2.4.1 Disabling Parent Class Loading

To enable Oracle RTD Inline Services to be deployed in Oracle Real-Time Decisions Studio, you must disable parent class loading in the IBM WebSphere Administration Console, as described in the following procedure. If you want to use SSL with Oracle RTD, then see Section 10.2.7.3, "Configuring SSL for Oracle Business Intelligence on IBM WebSphere."

To manually configure for Oracle RTD on IBM WebSphere:

1. In the IBM WebSphere Administration console, select Applications, Application Types, WebSphere enterprise applications, Oracle RTD, and Class loading and update detection.

2. Select Classes loaded with local class loader first (parent last).

3. Save your change.

10.2.4.2 Configuring Constraints for User-Defined Web Policy Sets

Oracle RTD automatically supports certain specific web service policies. If you define your own server-wide web policy sets, you must configure constraints for those policy sets. If you do not do so, the Oracle RTD client-side tools may not work correctly, such as content panes not appearing on Decision Center logins.

Note:

If the Oracle RTD client-side files are configured on a separate machine to the server, you must configure the constraints for user-defined web policy sets on both client and server machines.

You can configure the policy set constraints either in Fusion Middleware Control or through using wsadmin commands.

10.2.4.2.1 Configuring Policy Set Constraint Using Fusion Middleware Control

General information about configuring policy set constraints is available in "Specifying Run-time Constraints in Policy Sets" in Oracle Fusion Middleware Security and Administrator's Guide for Web Services, and detailed instructions appear in "Using Fusion Middleware Control."

Specifically for Oracle RTD, follow the instructions in "Using Fusion Middleware Control," and in the Enter Constraint page, perform the following steps:

1. Select the options Enabled and !(NOT) Operator.

2. For HTTP Header Name, enter rtd_scope.

3. For HTTP Header Value, enter internal.

10.2.4.2.2 Configuring Policy Set Constraint Using Wsadmin

General information about entering wsadmin commands is available in Section 3.1.3, "Using the Oracle Fusion Middleware wsadmin Commands."

The wsadmin commands dealing with policy sets appear in the wsmManage category. For more information, see Section 8.5, "Using the Web Services wsadmin Commands" and Section 8.5.3, "wsmManage wsadmin Commands."

Specifically for Oracle RTD, on initial creation of the policy set, you must include the following line:

wsmManage.setPolicySetConstraint("!HTTPHeader('rtd_scope', 'internal')")

If the policy set has already been created, modify the policy set as follows, after replacing <YourPolicySet> with your particular policy set name:

wsmManage.beginRepositorySession()
wsmManage.modifyPolicySet('<YourPolicySet> ')
wsmManage.setPolicySetConstraint("!HTTPHeader('rtd_scope', 'internal')")
wsmManage.commitRepositorySession()

10.2.4.3 Installing Oracle RTD Client-Side Files

To install Oracle RTD client-side files, perform the procedures described in "Installing Oracle RTD Client-Side Files" in Oracle Fusion Middleware Administrator's Guide for Oracle Real-Time Decisions.

10.2.4.4 Populating the Example Data Tables

If you want to use the two example Inline Services, CrossSell and DC_Demo, that are included with Oracle Real-Time Decisions, perform the procedures described in "Populating the Example Data Tables (Optional)" in Oracle Fusion Middleware Administrator's Guide for Oracle Real-Time Decisions.

10.2.5 Starting and Stopping Components on IBM WebSphere

The following procedure shows the sequence that you must use to stop and start the various components that allow Oracle Business Intelligence to run in the cell. See Section 2.7, "Task 7: Start the IBM WebSphere Servers" for additional information on starting processes.

Note:

You can include the commands for starting and stopping components in a script that is appropriate for the operating system. Running a script is more convenient than entering each command separately each time.

The steps in the following procedure assume that the user_projects directory is under the MW_HOME/user_projects directory. However, the user_projects directory can be located under WAS_HOME/user_projects or another directory that was selected when Oracle Business Intelligence was installed.

To start and stop components on IBM WebSphere:

1. Log into the Administration node for Oracle Business Intelligence and open a terminal window.

2. Stop all components by entering the following commands:

MW_HOME/instances/instance1/bin/opmnctl stopall
MW_HOME/user_projects/domains/bifoundation_cell/bifoundation_cell_node0/bin/stopServer.sh bi_server1 -username user_name -password password
MW_HOME/user_projects/domains/bifoundation_cell/bifoundation_cell_node0/bin/stopServer.sh bi_server1 -username user_name -password password
MW_HOME/user_projects/domains/bifoundation_cell/bifoundation_cell_node0/bin/stopServer.sh OracleAdminServer -username user_name -password password
MW_HOME/user_projects/domains/bifoundation_cell/bifoundation_cell_node0/bin/stopNode.sh -username user_name -password password
MW_HOME/user_projects/domains/bifoundation_cell/bifoundation_cell_dmgr/bin/stopManager.sh -username user_name -password password

3. Start the Deployment Manager by entering the following command:

MW_HOME/user_projects/domains/bifoundation_cell/bifoundation_cell_dmgr/bin/startManager.sh -username user_name -password password

4. Start the node by entering the following command:

MW_HOME/user_projects/domains/bifoundation_cell/bifoundation_cell_node0/bin/startNode.sh -username user_name -password password

5. Start the OracleAdminServer server by entering the following command:

MW_HOME/user_projects/domains/bifoundation_cell/bifoundation_cell_node0/bin/startServer.sh OracleAdminServer -username user_name -password password

6. Start the Managed Server by entering the following command:

MW_HOME/user_projects/domains/bifoundation_cell/bifoundation_cell_node0/bin/startServer.sh bi_server1 -username user_name -password password

7. Restart OPMN components by entering the following commands:

MW_HOME/instances/instance1/bin/opmnctl startall
MW_HOME/instances/instance1/bin/opmnctl status

10.2.6 Determining Ports for Oracle BI Components on IBM WebSphere

When you install Oracle Business Intelligence with IBM WebSphere, you use different port numbers to access various components than you use on WebLogic Server. Port numbers can also differ between SSL and non-SSL environments and in scaled-out environments. See Chapter 3, "Managing Oracle Fusion Middleware on IBM WebSphere" and the documentation for IBM WebSphere for information on locating ports for various processes such as Fusion Middleware Control and the IBM WebSphere Administration Console.

Table 10-2 describes port numbers that are generally assigned and the URLs for accessing the components.

Table 10-2 Typical Port Numbers and URLs for Components

Component

Non-SSL Port Number

SSL Port Number

URL

Oracle BI Presentation Services

9704

9804

http://host-name:port-num/analytics or

https://host-name:port-num/analytics

Oracle BI Publisher

9704

9804

http://host-name:port-num/xmplserver or

https://host-name:port-num/xmplserver

Fusion Middleware Control

9002

9003

http://host-name:port-num/em or

https://host-name:port-num/em

IBM WebSphere Administration Console

Not available

9043 or 9045

https://host-name:port-num/ibm/console

10.2.7 Configuring for Security of Oracle Business Intelligence on IBM WebSphere

You must ensure that you implement appropriate security when using Oracle Business Intelligence on IBM WebSphere. This section contains the following topics on security:

- Configuring the LDAP-Based Identity Store on IBM WebSphere

- Configuring SSO for Oracle Business Intelligence on IBM WebSphere

- Configuring SSL for Oracle Business Intelligence on IBM WebSphere

Ensure that you are familiar with the information on security that is provided in the documentation for IBM WebSphere and for Oracle Business Intelligence. If you use Oracle Business Intelligence, then see Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition. If you use Oracle RTD, then see "Security for Oracle Real-Time Decisions" in Oracle Fusion Middleware Administrator's Guide for Oracle Real-Time Decisions.

10.2.7.1 Configuring the LDAP-Based Identity Store on IBM WebSphere

When you install Oracle Business Intelligence with IBM WebSphere, the system is installed using an XML-based identity store that is not secure. This identity store allows for easy configuration of an instance of Oracle Business Intelligence that is running after installation. You can use Oracle BI Presentation Services, but with restricted access. You must use an LDAP-based identity store to access more features of Oracle Business Intelligence while securing the system.

After you install Oracle Business Intelligence with IBM WebSphere, you must configure an LDAP-based identity store such as Oracle Internet Directory or Microsoft Active Directory, as described in the following sections.

The following sections describe how to configure Oracle Internet Directory or Microsoft Active Directory as the external identity store for use when authenticating and authorizing access to Oracle Business Intelligence and the IBM WebSphere Administration Console Web interface. The steps are similar for the two types of identity store, as described in the following list:

- Step 1: Ensuring the Prerequisites for the Identity Store on IBM WebSphere

- Step 2: Configuring Required Users and Groups in the Provider for IBM WebSphere

- Step 3: Creating the Properties File for the Identity Store on IBM WebSphere

- Step 4: Updating the BISystemUser Credential on IBM WebSphere

- Step 5: Reassociating Oracle Business Intelligence with the Identity Store on IBM WebSphere

- Step 6: Synchronizing the Configuration on IBM WebSphere

- Step 7: Refreshing the GUIDs on IBM WebSphere

10.2.7.1.1 Step 1: Ensuring the Prerequisites for the Identity Store on IBM WebSphere

Before you begin configuring the identity store, ensure that the following are true:

- You have installed Oracle Business Intelligence on IBM WebSphere using the instructions in this chapter.

- You have administrator access to a computer that has an installed Oracle Internet Directory or Active Directory instance on which you can create groups and users.

- The "wasadmin" user exists in the LDAP-based identity store with which you are reassociating.

10.2.7.1.2 Step 2: Configuring Required Users and Groups in the Provider for IBM WebSphere

See "Configuring Alternative Authentication Providers" in Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition for information on configuring Oracle Internet Directory or Active Directory as authentication providers.

10.2.7.1.3 Step 3: Creating the Properties File for the Identity Store on IBM WebSphere

To create the properties file for the LDAP-based identity store on IBM WebSphere:

1. Log into the Administration node for Oracle Business Intelligence and open a terminal window.

2. Create a .properties file that can provide the details for the identity store to IBM WebSphere and the JPS subsystem.

3. Save your changes to the file.

The following examples provide sample properties files that you can create. You must modify the user and group search base properties based on the information that you gathered in Section 10.2.7.1.2, "Step 2: Configuring Required Users and Groups in the Provider for IBM WebSphere.". You must modify the following values as appropriate:

- user.search.bases — The container within which users are found.

- group.search.bases — The container within which groups are found.

- subscriber.name — The root directory for this subscription.

- ldap.host — The host name of the instance for the identity store.

- ldap.port — The port number on which the instance for the identity store is available.

- admin.id — The full distinguished name of the user who binds to the service for the identity store. For example, cn=orcladmin

- admin.pass — The password of the user who binds to the service for the identity store.

The following example shows a properties file for use with Oracle Internet Directory.

user.search.bases=cn=Users,dc=us,dc=oracle,dc=com
group.search.bases=cn=Groups,dc=us,dc=oracle,dc=com
subscriber.name=dc=us,dc=oracle,dc=com
ldap.host=myserver.example.com
ldap.port=3060
# admin.id must be the full DN of the user in the LDAP
admin.id=cn=orcladmin
admin.pass=password-name
user.filter=(&(uid=%v)(objectclass=person))
group.filter=(&(cn=%v)(objectclass=groupofuniquenames))
user.id.map=:uid
group.id.map=:cn
group.member.id.map=groupofuniquenames:uniquemember
ssl=false
# primary.admin.id indicates the user you want to be the primary
# administrative user on WebSphere. It should be a user under user.search.bases.
# later you need to use this user's user name and password to manage or
# start/stop the server.
primary.admin.id=wasadmin
# optional, default to "OID"
idstore.type=OID
# other, optional identity store properties can be configured in this file.
username.attr=cn

The following example shows a properties file for use with Active Directory.

user.search.bases=cn=Users,dc=smartinc,dc=com
group.search.bases=cn=Builtin,dc=smartinc,dc=com
subscriber.name=dc=smartinc,dc=com
ldap.host=ad.smartinc.com
ldap.port=389
# admin.id must be the full DN of the user in the LDAP
admin.id=cn=admin,cn=Users,dc=smartinc,dc=com
admin.pass=password-name
user.filter=(&(samaccountname=%v)(objectclass=user))
group.filter=(&(samaccountname=%v)(objectclass=group))
user.id.map=:samaccountname
group.id.map=:cn
group.member.id.map=group:member
ssl=false
# primary.admin.id indicates the user you want to be the primary
# administrative user on WebSphere. It should be a user under user.search.bases.
# later you need to use this user's user name and password to manage or
# start/stop the server.
primary.admin.id=wasadmin
# optional, default to "OID"
idstore.type=ACTIVE_DIRECTORY
# other, optional identity store properties can be configured in this file.
username.attr=cn

10.2.7.1.4 Step 4: Updating the BISystemUser Credential on IBM WebSphere

When you install Oracle Business Intelligence, the file-based identity store assigns the BISystemUser a password. You must use a command in IBM WebSphere for the new identity store to recognize the user name and password for the BISystemUser.

To update the BISystemUser credential on IBM WebSphere:

1. From a terminal window on the computer on which IBM WebSphere is running, enter the following commands:

setenv WAS_HOME IBM_WebSphere_install_dir
cd MW_HOME
./Oracle_BI1/common/bin/wsadmin.sh -connType SOAP -host localhost -port 8879
wsadmin> Opss.updateCred(map="oracle.bi.system",key="system.user",user="BISystemUser",password="password-name")

Note:

When you enter the wsadmin.sh command, the system prompts you for the user name and password. These commands assume that the SOAP port is 8879. You can verify port numbers by viewing the AboutThisProfile.txt file in the following directory:

MW_HOME/user_projects/domains/bifoundation_cell/bifoundation_cell_dmgr0/logs/AboutThisProfile.txt

See Chapter 3, "Managing Oracle Fusion Middleware on IBM WebSphere" for additional information on ports.

10.2.7.1.5 Step 5: Reassociating Oracle Business Intelligence with the Identity Store on IBM WebSphere

You must reassociate Oracle Business Intelligence with the identity store so that information about users is available to Oracle Business Intelligence.

To reassociate Oracle Business Intelligence with the identity store on IBM WebSphere:

1. In the same terminal window in which you updated the BISystemUser credential, enter the following commands:

wsadmin> Opss.configureIdentityStore(propsFileLoc="/<dir-name>/ldap.properties")
wsadmin> quit

2. If you use Oracle RTD on IBM WebSphere, then to ensure that Oracle RTD functions properly, you must associate the Oracle RTD role "users" with all authenticated users and groups (which includes the user "wasdmin"), as described in the following steps:

1. In the IBM WebSphere Administration console, select Applications, Application Types, WebSphere enterprise applications, and OracleRTD.

2. Edit the OracleRTD application and select Security role to user/group mapping.

3. Select the Role users, click Map Special Subjects, and select All Authenticated in Application's Realm.

4. Click OK twice and save your changes.

5. Restart the processes for IBM WebSphere and OPMN as described in Section 10.2.5, "Starting and Stopping Components on IBM WebSphere."

Note:

You must also remap the "wasadmin" user if you plan to use map views. For information, see Section 10.2.8, "Configuring for Map Views in Oracle Business Intelligence on IBM WebSphere."

10.2.7.1.6 Step 6: Synchronizing the Configuration on IBM WebSphere

You must use the syncNode command to force a configuration synchronization to occur between the node and the Deployment Manager (dmgr) for the cell in which the node is configured. You must also restart processes to allow the system to recognize and activate the new security settings.

Note:

Run the commands as shown in the following steps. The user name and password in all of these commands are for the currently configured IBM WebSphere administrator and not for the one in the new identity store configuration.

To synchronize the configuration on IBM WebSphere:

1. Log into the Administration node for Oracle Business Intelligence and open a terminal window.

2. Stop all components as described in Section 10.2.5, "Starting and Stopping Components on IBM WebSphere."

3. Start all components as described in Section 10.2.5, "Starting and Stopping Components on IBM WebSphere."

4. Perform the following steps for synchronization:

1. Stop the node using the following command:

MW_HOME/user_projects/domains/bifoundation_cell/bifoundation_cell_node0/bin/stopNode.sh -username user_name -password password

2. Manually synchronize the node by running the syncNode.sh command from the profile_root/bin directory, using the following syntax:

MW_HOME/user_projects/domains/bifoundation_cell/bifoundation_cell_node0/bin/syncNode.sh DMGRT_host_name DMGRT_SOAP_prt -username user_name -password password

3. Start the node using the following command

MW_HOME/user_projects/domains/bifoundation_cell/bifoundation_cell_node0/bin/startNode.sh -username user_name -password password

5. After all processes have restarted, ensure that you can log into the IBM WebSphere Administration Console and Oracle Business Intelligence using the new user details from the identity store. That is, log in with the user that is specified in the primary.admin.id value of the properties file.

For additional information on starting processes, see Section 10.2.5, "Starting and Stopping Components on IBM WebSphere."

10.2.7.1.7 Step 7: Refreshing the GUIDs on IBM WebSphere

See "Refreshing User GUIDs" in Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition for information on updating any metadata references to user GUIDs in the Oracle BI repository and in the Oracle BI Presentation Catalog.

10.2.7.2 Configuring SSO for Oracle Business Intelligence on IBM WebSphere

Note:

Unless otherwise indicated, the information in this section applies to Oracle BI Enterprise Edition, Oracle BI Publisher, and Oracle Real-Time Decisions.

You can use Oracle Single Sign-On with Oracle Business Intelligence on IBM WebSphere by relying on Oracle Access Manager 11g for authentication and authorization of its users. Figure 11-2 describes this process.

The SSO configuration requires the following components, typically on two host computers:

- Host Computer #1

- Oracle Business Intelligence 11g

- IBM HTTP Server 7

- WebGate 10g

- Host Computer #2

- Oracle Access Manager (OAM) 11g

- Oracle Internet Directory (OID) 11g

If you plan to use Oracle Single Sign-On with Oracle Business Intelligence on IBM WebSphere, then you must configure it manually, as described in the following sections:

- Step 1: Installing and Configuring Oracle Business Intelligence on IBM WebSphere

- Step 2: Configuring the IBM HTTP Server for IBM WebSphere

- Step 3: Configuring Oracle Access Manager and Oracle Internet Directory on IBM WebSphere

- Step 4: Registering the WebGate Agent with Oracle Access Manager on IBM WebSphere

- Step 5: Updating the Application Policy for Oracle Business Intelligence on IBM WebSphere

- Step 6: Installing and Configuring WebGate on IBM WebSphere

- Step 7: Configuring IBM WebSphere for SSO in Oracle Access Manager and IAP

- Step 8: Configuring the Logout for Oracle Business Intelligence on IBM WebSphere

- Step 9: Updating Oracle Business Intelligence for SSO on IBM WebSphere

- Step 10: Restarting the Processes for IBM WebSphere

10.2.7.2.1 Step 1: Installing and Configuring Oracle Business Intelligence on IBM WebSphere

You must install and configure Oracle Business Intelligence on the first host computer, as described in Section 10.2.1, "Installing Oracle Business Intelligence on IBM WebSphere" and Section 10.2.2, "Configuring Oracle Business Intelligence in a New IBM WebSphere Cell."

10.2.7.2.2 Step 2: Configuring the IBM HTTP Server for IBM WebSphere

You must install and configure the IBM HTTP Server on the first host computer to work in front of IBM WebSphere to receive all web requests and route them to the Oracle Business Intelligence instance that is integrated with IBM WebSphere.

To configure the IBM HTTP Server for IBM WebSphere:

1. Install the IBM HTTP Server, and take note of the Server Name and the HTTP Port.
For detailed installation instruction, refer to IBM HTTP Server documentation.

2. Configure the HTTP Server, specifying the server name and port number that you specified in Step 1.

1. Log into the IBM WebSphere Administrative Console.

2. Navigate to Servers, Server Types, Web Servers, and New.

3. Select the node and type:
Node = Select the default node, which has a format such as host-nameNode01.

Server Name = Enter the name that you entered for the HTTP Server Plug-in, such as webserver1.

Type = Select IBM HTTP Server.

4. Select IHS as the web server template.

5. Enter the following properties for the new web server:
Port = 8080

Web server installation location = /dir-name/IBM/HTTPServer

Plug-in installation location = /dir-name/IBM/HTTPServer/Plugins

Application mapping = All

6. Click Next, Finish, and Save.

3. Create a virtual host entry to enable access to the port number that you specified in Step 1.
If the port is not accessible, then error messages similar to the following ones are displayed:

SRVE0255E: A WebGroup/Virtual Host to handle /webcenter/ has not been defined.

SRVE0255E: A WebGroup/Virtual Host to handle host:8080 has not been defined.

1. In the IBM WebSphere Administrative Console, navigate to Environment, then Virtual Hosts, then default_host, and Host Aliases.

2. On the Host Aliases page, select New.

3. For Port, enter the port number that you specified in Step 1.
Leave Host Name as *.

4. Click Save.

4. Generate and propagate the Web Server plug-in that coordinates the wiring between the IBM WebSphere Application Server and the IBM HTTP Server front end.

Note:

You must repeat this step each time there is a change to applications that are deployed on the servers.

1. In the IBM WebSphere Administrative Console, navigate to Servers, Server Types, then Web Servers, and select the HTTP server that you created, such as webserver1.

2. Click Generate Plug-in.

3. Verify that the HTTP server that you created is selected, and click Propagate Plug-in.

5. Apply the analytics application to IBM WebSphere by following these steps:

1. In the IBM WebSphere Administration console, select Applications, Application Types, WebSphere Enterprise Applications, analytics_11.1.1, and ManageModules.

2. Select the two WAR files that are listed there for analytics.

3. Click Apply, then OK.

4. Click Review, select Synchronize Changes with Nodes, and click Save.

6. Update the httpd.conf file for the web server by following these steps:

1. Click the Web Server.

2. Next to Configuration file name, click Edit.

3. Scroll down and change the user and group from "nobody" and "nobody" to the user name and group name of the current user.
Change the User nobody and Group nobody settings to the names of the user and group who perform the configuration.

4. Click Apply, then OK.

5. Click OK to return to the Web Servers page.

7. Restart the Deployment Manager, the Node Agent, the OracleAdminServer, and other components, as described in Section 10.2.5, "Starting and Stopping Components on IBM WebSphere."

10.2.7.2.3 Step 3: Configuring Oracle Access Manager and Oracle Internet Directory on IBM WebSphere

You must configure Oracle Access Manager and Oracle Internet Directory, as described in Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service and Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

10.2.7.2.4 Step 4: Registering the WebGate Agent with Oracle Access Manager on IBM WebSphere

You must register the WebGate agent with Oracle Access Manager before you install WebGate. The WebGate agent intercepts HTTP requests from users for Web resources and forwards them to the Access Server for authentication and authorization. You can register the WebGate agent using the OAM Console or, if you have administrator rights, you can use the oamreg tool.

To register the WebGate instance with Oracle Access Manager using a graphic user interface on IBM WebSphere:

1. Log into the Administration Console for Oracle Access Manager.

2. On the Home page, click New OAM 10g Webgate.

3. Enter the details to create the instance, as described in the following list:

- Name = IHS_host_name_biwas, for example myhost_biwas

- Base URL: The URL for the IBM HTTP Server, for example http://myhost:8080

- Access Client Password = The password for Oracle Access Manager

- Host identifier = Same as Name

- User defined params = Leave blank

- Security= Open

- Resource Lists = For Protected Resource List enter the following:
/…/*

/

For Public Resource List = Leave blank

4. Click OK.

To register the WebGate instance in inband mode with Oracle Access Manager using the oamreg command tool on IBM WebSphere:

1. Navigate to the following directory on the Oracle Access Manager server:

IDM_HOME/oam/server/rreg/client/

2. On the command line, untar RREG.tar.gz

gunzip RREG.tar.gz
tar -xvf RREG.tar

The tool used to register the agent is located in the following location:

(UNIX) RREG_HOME/bin/oamreg.sh
(Windows) RREG_HOME\bin\oamreg.bat

Note:

RREG_HOME is the directory where you extracted the contents of RREG.tar.gz/rreg.

3. Set the following environment variables in the oamreg.sh or oamreg.bat script:
OAM_REG_HOME - Set this variable to the absolute path to the directory where you extracted the contents of RREG.tar/rreg

JDK_HOME - Set this variable to the absolute path to the directory where Java/JDK is installed on your machine.

4. Change directories to RREG_HOME/input and create the bi.oam.conf file using the following example:

###########################################################################
# Copyright (c) 2009, 2013, Oracle and/or its affiliates. All rights reserved.
#
# This is a configuration file, to be used with the OAM Config Tool, for
# configuring policies in OAM in order to facilitate Single Sign On.
#
# Protected URIs:-
# A Protected URI (resource) implies that a user must be authenticated
# before accessing that resource. Upon accessing a protected uri, the
# user is redirected to the OAM login page for authentication.
# Subsequently, upon successful authentication, the user is redirected to the
# original requested resource.
#
# Public URIs:-
# A Public URI (resource), on the contrary, implies that a user be allowed
# access to that resource without authentication.
#
# This file essentially contains a list of protected and public URIs belonging
# to an Application.
#
# Refer to the documentation of OAM Config Tool for anything related to
# the OAM Config tool's usage and the documentation of OAM for anything
# related to OAM in general.
#
##########################
# File format description
##########################
# 1. Any line beginning with '#' is considered a comment and would be ignored
# 2. Likewise any empty line or any line beginning with ' ' (space) is ignored
# 3. All the Protected URIs must be listed followed by the keyword:
#    "protected_uris".
# 4. All the Public URIs must be listed followed by the keyword: "public_uris"
#
#    Note that Public URIs are optional. But you need to have at least one
#    Protected URI listed
#
##########################
# Basic configuration
##########################
# 1. One Policy domain is created in OAM based on the parameter
#    "app_domain", passed to the OAM Config Tool, during its execution.
#
# 2. This Policy domain is configured with an Authentication scheme
#    that requires the user to authenticate.
#
# 3. All the URIs listed following the keyword, "protected_uris" are
#    created as "resources" in OAM i.e. all these are protected by the
#    default authentication scheme configured in OAM.
#
# 4. All the URIs listed following the keyword, "public_uris" are
#    added to a default public policy in OAM. This policy is configured
#    with an Anonymous Authentication Scheme, allowing access to everyone.
#
##########################
# Advanced configuration
##########################
# Note that under this configuration, the configuration listed as part of
# "Basic configuration" are also done in addition to the below.
#
# The OAM Config Tool can also be used to configure user defined Policies in
# OAM. The policies can be configured to be protected with a default
# authentication scheme (protected) or with an anonymous authentication scheme
# (public).
#
# Format for specifying Protected and Public Policies are the same, except that
# the Protected Policies must be listed under "protected_uris" whereas the
# Public Policies must be listed under "public_uris"
#
# 1. To specify the name of a Policy:
#    - Line without leading "/" implies the name of the policy.
#    - Only for public policy, if no name is specified then by default, the
#       name used is "public_<app_domain>". Note that all protected policies
#       must have a name.
#
# 2. To specify a URL Pattern for a policy:
#    - List the URL Pattern next to the resource separated by one or more spaces
#    - List the URL pattern for every resource in that policy
#    For example:
#        policy for allowing access to all images/scripts under /uri1 and /uri2
#        /uri1   /.../{*.js,*.gif}
#    /uri2   /.../{*.js,*.gif}
#
# 3. To specify a Query String for a policy:
#    - List the resource followed by the querystring (separated by '?')
#    - List the Query String for every resource in that policy
#    For example:
#        public policy with query string
#        /uri3?{SoapImpl*,WSDL,privateWSDL}
#        /uri4?{SoapImpl*,WSDL,privateWSDL}
#
##############################################################################
#
#
########################
#Product Name: BI (includes BI EE, RTD, EPM, BIP)
########################
#
###########################
protected_uris
###########################
/analytics/saw.dll
/aps
/bicontent
/bioffice
/calcmgr
/hr
/workspace
/ui
/xmlpserver
*
###########################
public_uris
###########################
Default Public Policy
/analytics
/analytics/saw.dll/wsdl
/bioffice/services/saw
/ui/do/logout
/xmlpserver/services
/xmlpserver/report_service
/xmlpserver/ReportTemplateService.xls
/xmlpserver/Guest
/biservices
/biofficeclient/OracleBIOffice.exe
/hr/modules/com/hyperion/reporting/web/repository/HRRepositoryXML.jsp
/analytics/saw.dll?{SoapImpl*,WSDL,wsdl,privateWSDL,privatewsdl}

5. Create a file called oam_request.xml using the following example to serve as the parameter file for the oamreg tool.

<?xml version="1.0" encoding="UTF-8"?>
<OAMRegRequest>
<serverAddress>http://$$oamhost$$:$$oamadminserverport$$</serverAddress>
<hostIdentifier>$$ihshost$$_biwas</hostIdentifier>
<agentName>$$ihshost$$_biwas</agentName>
<agentBaseUrl>http://$$ihshost$$:$$ihsport$$</agentBaseUrl>
<applicationDomain>$$ihshost$$_biwas</applicationDomain>
<autoCreatePolicy>true</autoCreatePolicy>
<primaryCookieDomain>.myserver.example.com</primaryCookieDomain>
<logOutUrls>
<url>/oamsso/logout.html</url>
</logOutUrls>
</OAMRegRequest>

Replace the variable contents within $$ihshost:ihsport$$ with the server name and port number for the IBM HTTP Server. Replace $$oam...$$ with the host name for Oracle Access Manager and the port number for the Administration Server.

6. Change to the RREG_Home directory.

7. Enter the following command:
RREG_HOME/bin/oamreg.sh inband input/oam_request.xml

Complete the following steps:

1. When prompted for the agent credentials, enter the administrator credentials for Oracle Access Manager.

2. Enter the password for Webgate.

3. Enter Yes when asked to import a URIs file and specify the full directory name of the RREG_HOME/input/bi.oam.conf file.

You see a message that indicates that the registration was successful. Notice that the ObAcessClient.xml file is generated in the output folder. Keep the file available for copying in a later step after you install WebGate.

10.2.7.2.5 Step 5: Updating the Application Policy for Oracle Business Intelligence on IBM WebSphere

You must update the application policy with resources for Oracle Business Intelligence.

To update the application policy with resources for Oracle Business Intelligence on IBM WebSphere:

1. Change to the RREG_HOME/input directory on the computer for Oracle Access Manager. The directory name is often IDM_HOME/oam/server/rreg

2. Create a policy update file called bi_policy_update.xml and include the following text:

<?xml version="1.0" encoding="UTF-8"?>
<PolicyRegRequest>
<serverAddress>http://$$oamhost$$:$$oamadminserverport$$</serverAddress>
<hostIdentifier>$$ihshost$$_biwas</hostIdentifier>
<applicationDomainName>$$ihshost$$_biwas</applicationDomainName>
</PolicyRegRequest>

Replace the variable contents with the appropriate server names and port numbers. For example, for serverAddress, specify the URL for the computer for Oracle Access Manager, such as http://myhost:17731.

For hostIdentifier and applicationDomainName, enter myhost_biwas

3. Edit the oamreg.sh file to ensure that the OAM_REG_HOME and JAVA_HOME variables are set correctly. The JAVA_HOME variable must be set to:
dir_name/MW_HOME/IM_HOME/jdk

4. Enter the following command:
RREG_HOME/bin/oamreg.sh policyUpdate input/bi_policy_update.xml

Complete the following steps:

1. When prompted for the agent credentials, enter the administrator credentials for Oracle Access Manager.

2. Enter the password for Webgate.

3. Enter Yes when asked to import an URIs file and specify the full directory name of the RREG_HOME/input/bi.oam.conf file.

The policy is updated with resources for Oracle Business Intelligence.

5. Restart the IBM HTTP Server.

10.2.7.2.6 Step 6: Installing and Configuring WebGate on IBM WebSphere

Although Oracle Access Manager 11g can work with WebGate 10g and 11g, currently the IBM HTTP Server supports only WebGate 10g. You can locate the installation file for WebGate on the Oracle Access Manager page on Oracle Technology Network. Ensure that you have performed the previous steps in this process before installing WebGate.

To install and configure Webgate on IBM WebSphere:

1. Download WebGate 10g from Oracle Technology Network. The installable file is called Oracle Access Manager 10g - non OHS11g Webgates and 3rd Party Integrations.
For Windows, select Oracle_Access_Manager10_1_4_3_0_Win32_IHS22_WebGate installer

For Linux, select Oracle_Access_Manager10_1_4_3_0_linux_IHS22_WebGate installer

For Linux, ensure that the GCC libraries are available. If the IBM HTTP Server is 32-bit, then select 32-bit libraries. If the IBM HTTP Server is 64-bit, then select 64-bit libraries. The GCC libraries are provided in a .cpio file. Copy this file to any directory and enter one of the following commands:

cpio -i xxxx.cpio
cat xxxx.cpio | cpio -idmv

When the command finishes, you see a .zip file in the directory. Unzip the file using a command such as unzip -q file-name.zip

When the command finishes, you see two libraries in the same directory. You use these libraries in this procedure.

2. Ensure that you edit the httpd.conf file, as described in Section 10.2.7.2.2, "Step 2: Configuring the IBM HTTP Server for IBM WebSphere."

3. On the computer on which the IBM HTTP Server is installed, run the WebGate Installer as the user who is running the IBM HTTP Server.

4. Specify a location for installing Webgate.

Note:

If you ran the installer once and it failed, then select a different directory for installation.

5. Specify the location of the GCC libraries.

6. When asked to specify the WebGate details, enter the following:

- WebGate Id — Specify the agent name that you entered in "Step 5: Updating the Application Policy for Oracle Business Intelligence on IBM WebSphere" such as $$ihshost$$_biwas.

- WebGate Password — Specify the password that you entered while running the oamreg.sh script.

- Access Server Name — Specify a value such as oam_server1. Determine this value from the Oracle Access Manager Console.

- Access Server HostName — Specify $$oamhost$$.

- Access Server Port — Specify a value such as 5575. Determine this value from the Oracle Access Manager Console. Select System Configuration, then Server Instances, then oam_server1, then OAM Proxy, then Port.

7. Specify the automatic update of the httpd.conf file, and specify the proper location of the httpd.conf file for the IBM HTTP Server, which is usually IHS_HOME/conf.

8. Complete the wizard.
WebGate is now successfully installed.

9. Restart the IBM HTTP Server.

10.2.7.2.7 Step 7: Configuring IBM WebSphere for SSO in Oracle Access Manager and IAP

Follow the instructions in Section 11.9, "Configuring IBM WebSphere for OAM SSO and the IAP," which include the following steps:

- Configuring a Standalone LDAP Registry for Oracle Access Manager in IBM WebSphere. This configuration happens automatically when you perform Step 5: Reassociating Oracle Business Intelligence with the Identity Store on IBM WebSphere. Ensure that the configuration points to the correct Oracle Internet Directory instance.

- Adding and configuring a virtual host in IBM WebSphere. You can omit this step. You updated the default_host when you installed and associated the IBM HTTP Server. Do not create another host; use the one that you already have.

- Configuring the reverse proxy for the IBM HTTP Server in the IBM WebSphere Console. You can omit this step and use webserver1 instead. Ensure that you remove any entries that refer to "/*". Leave other entries intact (such as "/analytics/*"); otherwise, the IBM HTTP Server does not forward URLs for Oracle Business Intelligence to the IBM WebSphere server

- Creating the Interceptor Entry in the IBM WebSphere Console. When adding the OAMTrustAssociationInterceptor.jar file to the classpath for IBM WebSphere, you must add the file for OracleAdminServer and for bi_server1.

- Configuring the TAI configuration file for Oracle Access Manager.
If you select the option of copying the oamtai.xml file in the fmwconfig directory, then ensure that the change is made in the profile directory for the Deployment Manager. This directory is the source of truth for other application server profiles.

The values that you specify in the oamtai.xml file are similar to what you provide during the installation of WebGate. The following shows a sample oamtai.xml file:

<OAM-configuration>
<AAAClientConnect>
<Parameters>
<param name = "hostPort" value ="adc2100132:8080"/>
<param name = "resource" value ="/Authen/SSOToken"/>
<param name = "operation" value ="GET"/>
<param name = "AccessGateName" value ="myserver_biwas"/>
<param name = "AccessGatePassword" value ="welcome1"/>
<param name = "AccessServerHost" value ="myserver.example.com"/>
<param name = "AccessServerPort" value ="5575"/>
<param name = "AccessServerName" value ="oam_server1"/>
<param name = "TransportSecurity" value ="open"/>
<param name = "debug" value ="false"/>
<param name = "minConn" value ="1"/>
<param name = "maxConn" value ="1"/>
<param name = "timeOutForConnPool" value ="30000"/>
<!--
Note:Following parameter is used for Anonymous User Authentication. Configure anonymous user value here
-->
<param name = "Anonymous" value =""/>

<param name = "assertionType" value ="HeaderBasedAssertion"/>
<param name = "customHeaderName" value ="OAM_REMOTE_USER"/>
</Parameters>
</AAAClientConnect>
</OAM-configuration>

10.2.7.2.8 Step 8: Configuring the Logout for Oracle Business Intelligence on IBM WebSphere

For Oracle BI EE only, you configure the logout by creating a logout.html file.

To configure the logout for Oracle Business Intelligence on IBM WebSphere:

1. Follow the directions in Section 11.10.2.2, "Configuring SSO Logout for OPSS with ADF-coded applications and OAM 10g Webgate."

2. Create the logout.html file based on the following example:

<html>
<head>
<meta http-equiv="Content-Language" content="en-gb">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<title>New Page 1</title>
</head>
<body>

<p>Logging out...</p>

<script language="JavaScript">
window.location="/analytics";
</script>
</body>
</html>

3. Store the file in the IHS_HOME/htdocs directory.

4. Configure for the display of the file by following these steps:

1. Locate and log into the Oracle Access Manager Server.

2. Select Access System Configuration, then Access Gate Configuration.

3. Select the access gate that is associated with the instance of Oracle Business Intelligence.

4. Add /logout.html to the Web Server Client - LogOutURLs field.

5. Follow the steps in Section 11.10.2.2, "Configuring SSO Logout for OPSS with ADF-coded applications and OAM 10g Webgate."

6. Follow the steps in Section 11.10.2.3, "Configuring oamAuthenProvider.jar in the IBM WebSphere classpath" for the OracleAdminServer and for bi_server1.

7. Follow the steps in Section 11.10.2.4, "Verifying SSO Logout".

Note:

To work around an issue with Oracle Business Intelligence on IBM WebSphere, ensure that you close the browser after logging out. If you leave the browser open, then you risk retaining the session such that other users can access the browser and use Oracle Business Intelligence without logging in.

10.2.7.2.9 Step 9: Updating Oracle Business Intelligence for SSO on IBM WebSphere

For Oracle BI EE only, you must use Fusion Middleware Control to enable SSO for Oracle Access Manager.

To update Oracle Business Intelligence for SSO on IBM WebSphere:

1. Log into Fusion Middleware Control.

2. Expand the Business Intelligence folder and select the coreapplication node.

3. Click Lock and Edit Configuration to enable changes to be made.

4. Display the Single Sign On tab of the Security page.

5. Select Enable SSO, then select Oracle Access Manager as the SSO provider.

6. In the SSO Provider Logoff URL box, enter the following value:
http://host-name:8080/logout.html

where host-name is the computer on which the IBM HTTP Server is running.

7. Click Apply, then Activate Changes.

10.2.7.2.10 Step 10: Restarting the Processes for IBM WebSphere

Restart the processes for IBM WebSphere as described in Section 10.2.5, "Starting and Stopping Components on IBM WebSphere," ensuring that you restart the IBM HTTP Server and Oracle Business Intelligence.

10.2.7.3 Configuring SSL for Oracle Business Intelligence on IBM WebSphere

Note:

Unless otherwise indicated, the information in this section applies to Oracle BI Enterprise Edition, Oracle BI Publisher, and Oracle Real-Time Decisions.

If you plan to use Secure Socket Layers (SSL) with Oracle Business Intelligence on IBM WebSphere, then you must configure it manually. (By default, SSL ports are turned on for IBM WebSphere if you followed the default installation flow for Oracle Business Intelligence.) The objectives of the manual configuration are to have a system in which all the Oracle Business Intelligence components communicate through SSL and to allow outside connections over HTTPS only. The following list outlines the differences between using SSL on IBM WebSphere and on Oracle WebLogic Server:

- The format of the certificate authority public certificate for IBM WebSphere is different. Oracle Business Intelligence uses .DER (for binary files) and .PEM certificates. The default certificates for IBM WebSphere use .p12 format. Because Oracle Business Intelligence supports only .DER and .PEM formats, you must convert the default certificates for IBM WebSphere.

- You do not configure SSL for Oracle Business Intelligence using the Security tab within Fusion Middleware Control. For IBM WebSphere, you use the JMX MBeans within the System MBean Browser.

To configure SSL for Oracle Business Intelligence on IBM WebSphere:

1. Verify that SSL is active on IBM WebSphere using the following steps:

1. In the IBM WebSphere Administration console, select the following from the left-hand tree: servers/server types/websphere application servers

2. Select bi_server1 and ports, and for WC_defaulthost, click "view associated transports".
Set the Enabled flag and the SSL Enabled flag for both HttpQueueIbBoundDefault and WCInboundDefault.

3. Repeat Step b for any other servers that are configured.

2. Convert the CA public certificate to either the .DER (for binary files) or .PEM format that Oracle Business Intelligence recognizes. The following steps provide an example of this conversion:

1. Change to the following directory that stores the CA public certificate:
MW_HOME/user_projects/domains/bifoundation_cell/bifoundation_cell_dmgr0/config/cells/bifoundation_cell/trust.p12

2. Enter the following command:
openssl pkcs12 -in trust.p12 -out WAStrust.pem -nodes

3. Enter the appropriate password to create a PEM version of the certificate that is named WASTrust.pem.
See IBM WebSphere documentation available on the WebSphere Application Server Information Center for information on passwords for certificates.

3. (Oracle BI EE Only) Follow the instructions in "Configuring SSL Communication Between Components" in Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition with the following exceptions:

1. When selecting the generateSSLCertificates operation, use the CA public certificate that you created in the previous step, and select the appropriate format.

2. Restart the system components for Oracle Business Intelligence after completing the certification generation, as described in Section 10.2.5, "Starting and Stopping Components on IBM WebSphere."

4. (Oracle BI EE Only) Follow the instructions in "Enabling the SSL Configuration" in Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition.

5. (Oracle BI EE Only) Test the SSL configuration by following the instructions in "Confirming SSL Status Using the MBean Browser" in Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition

6. (Oracle RTD Only) Perform the following steps:

1. Configure IBM WebSphere to use the same store in its SSL configuration.
In the IBM WebSphere Administration console, select Security, SSL certificate and key management , SSL configurations, CellDefaultSSLSettings. Change the Trust Store name to the following:

BITrustStore ((cell):bifoundation_cell)

2. Expand the MW_HOME/Oracle_BI1/clients/rtd/rtd_client_11.1.1.zip file to a directory on the computer. That directory is referred to as RTD_HOME in this procedure.

3. Copy the MW_HOME/user_projects/domains/bifoundation_cell/bifoundation_cell_dmgr0/config/cells/bifoundation_cell/BITrustStore.jks file to the RTD_HOME/etc/ssl directory, creating the directory if it does not yet exist.

4. Configure Oracle RTD Studio to use the trusted store by changing the last line in the RTD_HOME/eclipse/eclipse.ini file to read as follows:
-Djavax.net.ssl.trustStore="..\etc\ssl\BITrustStore.jks

For CommandLineDeploy, execute the following command:

java -Djavax.net.ssl.trustStore="dir-nameBITrustStore.jks -jar deploytool.jar -deploy -sslConnection true ILS user-name password host-name port-num

For example:

Java -Djavax.net.ssl.trustStore=C:/RTD_HOME/etc/ssl/BITrustStore.jks -jar deploytool.jar -deploy -sslConnection true"C:/RTD_HOME/examples/CrossSell" weblogic psw dadvmh0044 9804

For Load Generator, in the RTD_HOME/scripts/sdexec.cmd script, uncomment the following line:

rem set TRUST_STORE_OPTS=-Djavax.net.ssl.trustStore="%SD_ROOT%\etc\ssl\sdtrust.store"

and replace it with the following one:

Djavax.net.ssl.trustStore=dir-nameBITrustStore.jks

For example:

-Djavax.net.ssl.trustStore=..\etc\ssl\BITrustStore.jks

For Batch Console, execute the following command:

java -Djavax.net.ssl.trustStore="dir-name/BITrustStore.jks" -jar batch-console.jar -url https://:

For example:

Java -Djavax.net.ssl.trustStore="c:/RTD_HOME/etc/ssl/BITrustStore.jks" -jar batch-console.jar -url https://localhost:ssl_port

5. Restart the Managed Server for Oracle Business Intelligence.

7. Turn off the non-HTTPS ports using the following steps:

1. In the IBM WebSphere Administration console, select the following from the left-hand tree: servers/server types/websphere application servers

2. Select bi_server1 and ports, and for WC_defaulthost, click "view associated transports".

3. Click HttpQueueIbBoundDefault, deselect the Enabled flag, and click Apply, then Save.

4. Repeat Steps b and c for WCInboundDefault.

5. Repeat Steps b and c for OracleAdminServer.

8. If you installed IBM WebSphere with Fix Pack 23 or later, then you can use TLS-based cipher suites, which do not function well with Oracle Business Intelligence. Perform the following steps to work around this issue:

1. In the IBM WebSphere Administration console, select Security, SSL certificate and key management , SSL configurations, NodeDefaultSSLSettings, and Quality of protection (QoP) settings.

2. In the Protocol box, select SSLv3 instead of the default of SSL_TLS, which does not work with Fix Pack 23.

9. Restart the system components for Oracle Business Intelligence, as described in Section 10.2.5, "Starting and Stopping Components on IBM WebSphere."

10. Verify that you cannot connect to Oracle Business Intelligence using the HTTP port, but that you can connect using the HTTPS port.

10.2.8 Configuring for Map Views in Oracle Business Intelligence on IBM WebSphere

If you want to use map views in analyses in Oracle Business Intelligence, then you must manually configure Oracle Fusion Middleware MapViewer. The EAR file for MapViewer exists in exploded directory form in the ORACLE_HOME/bifoundation/jee directory. Perform this step before completing the steps in Section 10.2.7.1, "Configuring the LDAP-Based Identity Store on IBM WebSphere," otherwise authorization exceptions can occur.

To manually configure for map views on IBM WebSphere:

1. Delete the two JSF libraries that are packaged inside MapViewer using the following commands:

rm ORACLE_HOME/bifoundation/jee/mapviewer.ear/web.war/WEB-INF/lib/jsf-api.jar rm ORACLE_HOME/bifoundation/jee/mapviewer.ear/web.war/WEB-INF/lib/jsf-impl.jar

Because IBM WebSphere contains JSF libraries, any JSF libraries that are packaged within the ear files of applications create conflicts.

2. Deploy the ear file for MapViewer using these steps:

1. In the IBM WebSphere Administration console, select Applications, Application Types, and WebSphere enterprise applications.

2. Click Install.

3. Select Remote file system and enter the remote servers path to the ORACLE_HOME/bifoundation/jee/mapviewer.ear file.
Note that you cannot select the mapviewer.ear file, because the file has already been exploded. Instead, you must specify another .ear in the same location, then change the name of the file to mapviewer.ear.

4. Click Next through the remaining pages.

5. Save the configuration.

3. Update the security role mappings using these steps:

1. In the IBM WebSphere Administration console, select Applications, Application Types, WebSphere Enterprise Applications, and Oracle MapViewer.

2. Edit the Oracle MapViewer application and select Security role to user/group mapping.

3. Select the following two roles: map_admin_role and secure_maps_role.

4. Click Map Roles.

5. Click Search to search users in the identity store.

6. Select the user in the list; for example, "wasadmin".

7. Click OK twice and save your changes.

4. Restart the processes for IBM WebSphere and OPMN as described in Section 10.2.5, "Starting and Stopping Components on IBM WebSphere."

10.2.9 Configuring for Actions that Invoke a Java Method on IBM WebSphere

In Oracle BI EE, you can create actions that invoke Java methods in Enterprise Java Beans (EJBs). These Java methods return objects that implement the remote EJB interface that Oracle BI EE can use. For Oracle WebLogic Server, you use the information in Oracle Fusion Middleware Integrator's Guide for Oracle Business Intelligence Enterprise Edition to configure this action type. For IBM WebSphere, you create a web service around an EJB. For complete information on creating an EJB web service, see the IBM web site and other internet locations.

10.2.10 Configuring for Oracle BI for Microsoft Office on IBM WebSphere

If you want to use Oracle Business Intelligence for Microsoft Office, then you must configure it manually.

To manually configure for Oracle BI for Microsoft Office on IBM WebSphere:

1. Deploy the ear file for the BI Office server using these steps:

1. In the IBM WebSphere Administration console, select Applications, Application Types, and WebSphere Enterprise Applications.

2. Click Install.

3. Select Remote file system and enter the remote servers path to the ORACLE_HOME/bifoundation/jee/bioffice.ear file.

4. Click Next through the remaining pages to accept the default selections, with one exception. On Step 2, "Map Modules to Servers," do not accept the default of OracleAdminServer. Instead, select the EAR file box, select bi_cluster from the list of servers, and click Apply. Verify that bi_cluster is displayed in the Server column, and click Next.

5. Save the configuration.

2. On the BI Office Server, change the SawBaseURL property in the bioffice.xml file to the following value:
http://host-name:port/analytics/saw.dll

Because of how Oracle BI for Microsoft Office is deployed on IBM WebSphere, you must change the property value in the file in each of these locations:

MW_HOME/user_projects/domains/bifoundation_cell/bifoundation_cell_node0/installedApps/BI_Cell/bioffice.ear/bioffice.war/WEB-INF/
MW_HOME/user_projects/domains/bifoundation_cell/bifoundation_cell_node0/config/cells/BI_Cell/applications/bioffice.ear/deployments/bioffice/bioffice.war/WEB-INF
MW_HOME/user_projects/domains/bifoundation_cell_dmgr0/config/cells/BI_Cell/applications/bioffice.ear/deployments/bioffice/bioffice.war/WEB-INF

For more information, see "Setting Properties in the bioffice.xml Configuration File" in Oracle Fusion Middleware User's Guide for Oracle Business Intelligence Enterprise Edition.

3. Deploy the war file for the BI Office client using these steps:

1. In the IBM WebSphere Administration console, select Applications, Application Types, and WebSphere Enterprise Applications.

2. Click Install.

3. Select Remote file system and enter the remote servers path to the ORACLE_HOME/bifoundation/jee/biofficeclient.war file.

4. Click Next through the remaining pages to accept the defaults, with two exceptions. First on Step 1, "Map Modules to Servers," change from the default of OracleAdminServer to bi_cluster, as described in Step 1 of this procedure.
Secondly, specify the following value for the web context root:

/biofficeclient

5. Save the configuration.

4. Restart the processes for IBM WebSphere as described in Section 10.2.5, "Starting and Stopping Components on IBM WebSphere."

10.2.11 Configuring for Scaling the Deployment of Oracle Business Intelligence on IBM WebSphere

On Oracle WebLogic Server, you scale the deployment of Oracle Business Intelligence using Fusion Middleware Control. On IBM WebSphere, you perform manual configuration steps in combination with Fusion Middleware Control for both JEE components and system components for Oracle Business Intelligence.

Scaling allows you to increase or decrease the capacity of a system by making effective use of resources. For example, user web requests can be directed to one of many Oracle BI Presentation Services components. In turn, each Presentation Services component can take advantage of the availability of multiple Oracle BI Servers.

You can scale both vertically and horizontally. Vertical scaling involves adding more Oracle Business Intelligence components to the same computer, to make increased use of the hardware resources on that computer. Horizontal scaling involves adding more computers to the environment. For example, Oracle Business Intelligence is horizontally scaled by distributing the processing of requests across multiple computers.

The following sections describe how to configure for scaling:

- Configuring for Scaling Out JEE Components on IBM WebSphere

- Configuring for Scaling Out System Components on IBM WebSphere

- Creating an Oracle RTD Cluster on IBM WebSphere

10.2.11.1 Configuring for Scaling Out JEE Components on IBM WebSphere

To configure for scaling out JEE components on IBM WebSphere:

1. Use the Administration Console for IBM WebSphere to verify that the following conditions are met:

- Oracle Business Intelligence is installed with IBM WebSphere on the first host computer.

- The installation of Oracle Business Intelligence on the first host computer includes two servers, which are named OracleAdminServer and bi_server1. The installation also includes a Node Agent and a single Deployment Manager.

- The servers are managed as a cluster for IBM WebSphere that is called bi_cluster.

2. Install IBM WebSphere on the second host computer. Ensure that you select None as the installation type and click Finish on the Installation Results page.

3. Apply any patches as appropriate for IBM WebSphere on the second host computer, so that the second computer runs the same version as the first computer. Before applying patches, ensure that no processes for IBM WebSphere are running. For example, use the stopNode.sh script to stop the Node Agent.

4. Run the Profile Management Tool as follows:

- Start the Profile Management Tool.
To launch the tool, run its script (often named pmt.sh), which is usually found in the following location:

WAS_HOME/bin/ProfileManagement/pmt.sh

For complete information on running and using the Profile Management Tool, see the documentation for IBM WebSphere.

Click Launch Profile Management Tool and Create.

- On the Environment Selection page, select Custom profile, then click Next.

- On the Profile Creation Options page, select Advanced profile creation, then click Next.

- On the Profile Name and Location page, set the name to a value such as the following one
cell-name_node0 (for example, bifoundation_cell_node0)

Set the profile location to nearly the same value as on the first server. Specify the same directory structure on the second host computer as it is on the first host computer, as shown in the following example:

/scratch/shiphomes/MWHOME/user_projects/domains/bifoundation_cell/bifoundation_cell_node0

Click Next.

- On the Node and Host Names page, click Next.

- On the Federation page, specify the SOAP port number, user name, and password for the Deployment Manager on the first host computer. You can find the port number for SOAP in the AboutThisProfile.txt file, which is stored in the logs directory of the Deployment Manager on the first host computer. Look for the property that is named Management SOAP Connector Port.
Specify the administrator user name and password for connecting to IBM WebSphere on the first host computer.

The details that you specify on the Federation page connect the installation of IBM WebSphere to the cluster configuration on the first host computer.

- Click Next multiple times to move through the Security Certificate and Port Values Assignment pages.

- On the Profile Creation Summary page, click Create.

- On the Profile Creation Complete page, clear the Launch the First Steps console box and click Finish.

- Close the Profile Management Tool window.

5. Install Oracle Business Intelligence on the second host computer and select the following options:

- For installation type, select Software-Only.

- Install Oracle Business Intelligence in the same directory structure on the second host computer as it is installed on the first host computer, such as /mydir/myname/mw_home.

6. Create an IBM Managed Server (similar to bi_server1 on the first node) to handle the JEE applications for Oracle Business Intelligence on the new node. Ensure that you have the following details to include in the command that runs the creation script:

- host-name — The name of the first host computer, where the Deployment Manager is installed and running.

- port-num — The port number for SOAP for the Deployment Manager. The default number is 8879.
For information on port numbers, see Section 10.2.6, "Determining Ports for Oracle BI Components on IBM WebSphere."

- admin-user — The user name for the Deployment Manager.

- admin-password — The password for the Deployment Manager.

- node-name — The local node name.
When you installed IBM WebSphere on the second host computer, a node was created there. To learn the name of this node, display the IBM WebSphere Administration Console, select System Administration and Nodes. Look for the name of the node on the second host computer.

- server-name — The name of the server to create. Give the server a unique name, such as bi_serverx, where x is an integer. If a server named bi_server1 already exists on the computer, then name this server bi_server2.

Perform the following steps to create the server:

1. Ensure that the WAS_HOME environment variable is set to the directory for IBM WebSphere on the second host computer.

2. Start the node (which you stopped in a previous step) on the second host computer, using a command such as the following one:

MW_HOME/user_projects/domains/bifoundation_cell/bifoundation_cell_node0/bin/startNode.sh -username user_name -password password

3. Enter the following command to run the script to create the server:
ORACLE_HOME/common/bin/wsadmin.sh -connType SOAP -host host-name -port port-num -username admin-user -password admin-password -f ORACLE_HOME/bifoundation/was_install/WASScaleOutJEE.py -localNodeName node-name -serverName server-name

The new server is created and managed as a new member of the pre-existing cluster, which is called bi_cluster. The node is synchronized, and the new server is running.

7. Use the following settings to increase the performance in high-load environments. You must change these settings from their default values.
In the IBM WebSphere Administration console, update the Default and WebContainer thread pools for each server in the bi_cluster cluster. Increase the minimum and maximum pool sizes to improve performance. For example, select Application Servers, bi_serverx, Thread pools, and WebContainer and specify the following values, if the community numbers around 1800 users:

Minimum Size = 200

Maximum Size = 200

8. Restart the processes for IBM WebSphere and OPMN as described in Section 10.2.5, "Starting and Stopping Components on IBM WebSphere."

9. Verify the following:

- That the list of applications that are running on the first host computer (such as bi_server1) are also running on the second host computer (such as bi_server2.) Use the IBM WebSphere Administration console to view the running applications.

- That you can access Oracle Business Intelligence on the second host computer, which makes use of the system components (such as Presentation Services and the BI Server) on the first host computer.
For information on accessing Oracle Business Intelligence, see Section 10.2.6, "Determining Ports for Oracle BI Components on IBM WebSphere."

10.2.11.2 Configuring for Scaling Out System Components on IBM WebSphere

To configure for scaling out system components on IBM WebSphere:

1. Ensure that you have successfully followed the steps in Section 10.2.11.1, "Configuring for Scaling Out JEE Components on IBM WebSphere."

2. Prepare to create a new instance by entering the following commands on its host computer:

cd MW_HOME
chmod ug+x Oracle_BI1/opmn/bin/opmnctl

3. Run the opmnctl createinstance command to create an Oracle instance, using the following syntax:
./Oracle_BI1/opmn/bin/opmnctl createinstance -wascell cell-name -wasNode node-name -wasTrustStore store-name -adminHost host-name -adminPort port-num -instanceName instance-name-oracleInstance instance-name

The following provides a sample createinstance command:

./Oracle_BI1/opmn/bin/opmnctl createinstance -wasCell bifoundation_cell -wasNode myNode01 -wasTrustStore /scratch/shiphomes/MW_HOME/user_projects/domains/bifoundation_cell/bifoundation_cell_node0/config/cells/bifoundation_cell/BITrustStore.jks -adminHost myHose -adminPort 8880 -instanceName instance2 -oracleInstance instances/instance2

The following list describes the arguments in the syntax:

- wasCell — The cell that includes the Administration Server, whose name is located in the following directory:
../user_projects/domains/cell-name/node-name/config/cells

- wasNode — The node that includes the Administration Server, whose name is located in the following directory:
../user_projects/domains/cell-name/node-name/config/cells/cell-name/nodes

- wasTrustStore — The cell-wide trust store for Oracle Business Intelligence that makes a secure connection with the OracleAdminServer. The store has a name such as the following:
MW_HOME/user_projects/domains/cell-name/node-name/config/cells/cell-name/BITrustStore.jks

- adminHost — The host name for the Administration Server.

- adminPort — The SOAP Connector port number for the Administration Server, which is stored in the following file:
../user_projects/domains/cell-name/node-name/config/cells/cell-name/nodes/node-name/serverindex.xml

Open the file and locate serverEntries with serverName OracleAdminServer. The port number is the SOAP_CONNECTOR_ADDRESS.

- instanceName — The name for the new Oracle instance, such as instance2.

- oracleInstance — The directory for the new Oracle instance, such as instances/instance2.

4. When prompted, enter the user name and password for the administrator and the password for the trust store.
To retrieve the password for the trust store manually, you must start a wsadmin console and enter the following commands:

wsadmin>Opss.listCred(map="oracle.bi.enterprise",key="bi.truststore.user")
[Name : BITrustStore, Description : "BI TrustStore User", expiry Date : null
]

5. Start OPMN on the second host computer using a command such as the following one:
./instances/instance2/bin/opmnctl startall

6. Notify the Administration Server of the new component on the scaled-out host computer using the following steps:

1. On the host computer for the Administration Server, log into Fusion Middleware Control.

2. Expand the Business Intelligence folder and select the coreapplication node.

3. Click Lock and Edit Configuration to enable changes to be made

4. Display the Scalability tab of the Capacity Management page to see the new instance.

5. Change the number of BI Servers, Presentation Servers, or JavaHosts using the arrow keys.
To vertically scale the system components, increment the number of each component to be greater than 0 for a given host.

6. Click Apply, then Activate Changes.

7. Return to the Business Intelligence Overview page and click Restart.

10.2.11.3 Creating an Oracle RTD Cluster on IBM WebSphere

An Oracle RTD cluster is the entire set of Oracle RTD instances that run any combination of the Oracle RTD services, namely Decision Server, Decision Center, Learning Services, and Batch Services.

The first stage in configuring an Oracle RTD cluster is to configure a JEE cluster, as described in Section 10.2.11.1, "Configuring for Scaling Out JEE Components on IBM WebSphere."

Subsequently, you must perform the following additional procedures on each server of the JEE cluster:

- Associating Users and Groups for Oracle RTD on IBM WebSphere

- Setting Clustering Properties for Oracle RTD

Note:

For load balancing in a cluster, you must tell the load balancer that the application is clustered. Therefore, for load balacing, you must deploy Oracle RTD (or ensure that it has already been deployed) on the cluster and on the HTTP Server. For more information on load balancing, see Section 10.2.12, "Configuring for Load Balancing with the IBM HTTP Server."

10.2.11.3.1 Associating Users and Groups for Oracle RTD on IBM WebSphere

In the Administration Console for IBM WebSphere, you must specify which users are allowed to access Oracle RTD. The most straightforward way is, for the Oracle RTD application, to associate the Oracle RTD role "users" to all authenticated users and groups.

To register users and groups for Oracle RTD on IBM WebSphere:

1. In the IBM WebSphere Administration console, select Applications, Application Types, WebSphere enterprise applications, and OracleRTD.

2. Edit the OracleRTD application and select Security role to user/group mapping.

3. Select the Role users, click Map Special Subjects, and select All Authenticated in Application's Realm.

4. Click OK twice and save your changes.

5. Restart the processes for IBM WebSphere and OPMN as described in Section 10.2.5, "Starting and Stopping Components on IBM WebSphere."

10.2.11.3.2 Setting Clustering Properties for Oracle RTD

The following two properties must be set up on each server of the JEE cluster to enable clustering for Oracle RTD:

- SDGroupName is the name of the Oracle RTD cluster. Each Oracle RTD instance in the JEE cluster must have the same SDGroupName.

- rtd.InstanceName specifies the unique name of the Oracle RTD instance within the cluster.

To set up the clustering properties for Oracle RTD:

1. In the IBM WebSphere Administration console, select Servers, Server Types, WebSphere application servers, then select the appropriate server.

2. In the Server infrastructure section, select Java and Process Management, Process definition, Java Virtual Machine, Custom properties, and New.

3. Enter Name and Value for both SDGroupName and rtd.InstanceName.
Ensure that the value for SDGroupName is the same on all servers of the cluster, and that the value for rtd.InstanceName is different on each server.

4. Click OK to save your changes.

5. Restart the processes for IBM WebSphere and OPMN as described in Section 10.2.5, "Starting and Stopping Components on IBM WebSphere."

6. Repeat these steps on each server of the cluster.

10.2.12 Configuring for Load Balancing with the IBM HTTP Server

You can configure IBM HTTP Server as the load balancer for Oracle Business Intelligence on IBM WebSphere, as described in the following sections:

- Step 1: Configuring the IBM HTTP Server for Oracle Business Intelligence on IBM WebSphere

- Step 2: Configuring Oracle Business Intelligence to Recognize the Load Balancer on IBM WebSphere

- Step 3: Verifying the Configuration of the Load Balancer on IBM WebSphere

10.2.12.1 Step 1: Configuring the IBM HTTP Server for Oracle Business Intelligence on IBM WebSphere

The first step is to configure the IBM HTTP Server. Complete the procedure that is described in Section 10.2.7.2.2, "Step 2: Configuring the IBM HTTP Server for IBM WebSphere."

10.2.12.2 Step 2: Configuring Oracle Business Intelligence to Recognize the Load Balancer on IBM WebSphere

To configure Oracle Business Intelligence for the load balancer on IBM WebSphere:

1. Log into Fusion Middleware Control and display the System MBean Browser.

2. Locate the BIDomain MBean, which has details such as the following:
MBean Name = oracle.biee.admin:cell=bifoundation_cell,type=BIDomain,node=slc01ncjNode01,group=Service,process=OracleAdminServer

Description = MBean for managing a BI Domain

3. Lock the configuration to allow you to make changes.

4. In the FrontEndLoadBalancerBaseURL field, specify the value that you saw when installing the load balancer. In this example, you enter the value http://analytics.example.com.

5. Click the Apply button.

6. Commit your changes.

7. Use Fusion Middleware Control to restart Presentation Services and activate your changes.

10.2.12.3 Step 3: Verifying the Configuration of the Load Balancer on IBM WebSphere

To verify that the load balancer is configured properly for Oracle Business Intelligence on IBM WebSphere:

1. In a web browser, enter the URL to start Presentation Services. For information, see Section 10.2.6, "Determining Ports for Oracle BI Components on IBM WebSphere."

2. Create an analysis with two columns and attach an action link to one of the columns using the Interaction tab of the Column Properties dialog.

3. Save the analysis.

4. Create an agent to run the analysis and save that agent.

5. Run the agent.
When the agent has finished running, you see an alert on the Oracle Business Intelligence home page, which is the result of the agent running the analysis.

6. Click View for the agent.

7. Hover the mouse pointer over the links in the column that you added to the action link. You see that the links include the URL for the load balancer, rather than for the server name and port number for Oracle Business Intelligence.

10.3 Deinstalling Oracle Business Intelligence and IBM WebSphere

You need not deinstall Oracle Business Intelligence unless you are updating to a new IBM WebSphere release. If you want to deinstall Oracle Business Intelligence, then use the following procedure.

To deinstall Oracle Business Intelligence on IBM WebSphere:

1. Ensure that IBM WebSphere and the Oracle Business Intelligence system are running.

2. Deinstall the components for Oracle Business Intelligence as described in "Deinstalling Oracle Business Intelligence" in Oracle Fusion Middleware Installation Guide for Oracle Business Intelligence.

3. Stop processes in IBM WebSphere and OPMN, as described in Section 10.2.5, "Starting and Stopping Components on IBM WebSphere."

4. Optionally, you can delete profiles to remove all of the user data such as the repository, catalog, and log files. Delete profiles by entering the following command:
WAS_HOME/bin/manageprofiles.sh -deleteAll

5. Delete the domain home and instances for example, MW_HOME/instance MW_HOME/user_projects and the binary files in the MW_HOME directory.

10.4 Upgrading Oracle Business Intelligence to Run on IBM WebSphere

You can upgrade an existing Oracle Business Intelligence system to run on IBM WebSphere:

- If you have a 10g Release of Oracle Business Intelligence that is running on Oracle WebLogic Server.

- If you have a previous 11g Release of Oracle Business Intelligence that is running on Oracle WebLogic Server.

To upgrade Oracle Business Intelligence to run on IBM WebSphere:

1. Install Oracle Business Intelligence Release 11.1.1.7 on Oracle WebLogic Server, using the instructions in Oracle Fusion Middleware Installation Guide for Oracle Business Intelligence. Ensure that you select the Enterprise Install and select Oracle WebLogic Server as the application server.

2. Upgrade from the earlier release of Oracle Business Intelligence to Release 11.1.1.7, using the instructions in Oracle Fusion Middleware Upgrade Guide for Oracle Business Intelligence. Ensure that you upgrade the repository and Oracle BI Presentation Catalog.

3. Install Oracle Business Intelligence Release 11.1.1.7 on IBM WebSphere. Ensure that you select the Software-Only Install and follow the instructions in this chapter

4. Move the repository from the instance that is running with Oracle WebLogic Server to the instance that is running with IBM WebSphere using the following steps:

1. Copy the source repository file (.rpd) from the computer for Oracle WebLogic Server to an appropriate directory for Oracle Business Intelligence on the computer for IBM WebSphere.

2. Use Fusion Middleware Control on the computer for IBM WebSphere to upload the repository file. For information, see "Using Fusion Middleware Control to Upload a Repository and Set the Oracle BI Presentation Catalog Location" in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

3. Use the Oracle BI Administration Tool to update connection pool and database settings in the repository. The repository file might contain data source connection information from the Oracle WebLogic Server environment that must be changed to the connection settings for the IBM WebSphere environment.

5. Move the Oracle BI Presentation Catalog from the instance that is running with Oracle WebLogic Server to the instance that is running with IBM WebSphere using the following steps:

1. Copy the files for the source catalog from the computer for Oracle WebLogic Server to an appropriate directory for Oracle Business Intelligence on the computer for IBM WebSphere.

2. Use Fusion Middleware Control on the computer for IBM WebSphere to specify the location of the catalog. For information, see "Using Fusion Middleware Control to Upload a Repository and Set the Oracle BI Presentation Catalog Location" in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

6. Start Oracle Business Intelligence on IBM WebSphere and verify that you can open the catalog and see the upgraded analyses and other objects.

10.5 Troubleshooting Oracle Business Intelligence on IBM WebSphere

Use the information in this section to help troubleshoot issues with Oracle Business Intelligence with IBM WebSphere. This section contains the following topics:

- Verifying the Configuration of Oracle Business Intelligence on IBM WebSphere

- Viewing Log Files for Oracle Business Intelligence on IBM WebSphere

- Diagnosing java.lang.RuntimeException or java.lang.NullPointerException for Oracle Business Intelligence on IBM WebSphere

10.5.1 Verifying the Configuration of Oracle Business Intelligence on IBM WebSphere

Before you perform any troubleshooting steps, verify that the configuration is running properly. The following list describes how to verify that processes are configured and running:

- View the processes that are running in Oracle Process Manager and Notification Server by entering a command such as the following:
MW_HOME/instances/instance1/bin/opmnctl status

- Verify that you can log into Oracle BI Presentation Services and other components by entering the appropriate URLs. See Section 10.2.6, "Determining Ports for Oracle BI Components on IBM WebSphere" for details on locating the port number to include when starting Presentation Services and other components on IBM WebSphere.

- Verify that you can see two servers in the IBM WebSphere Administration console. One server is called OracleAdminServer, and the other is called bi_server1. You can see various components running on each of the servers.

10.5.2 Viewing Log Files for Oracle Business Intelligence on IBM WebSphere

If you have any issues with the configuration of Oracle Business Intelligence on IBM WebSphere, then check the log files that are described in the following list:

- Administration Server Log Files:

- user_projects/domains/cell_name/node_name/logs/OracleAdminServer/SystemOut.log

- user_projects/domains/cell_name/node_name/logs/OracleAdminServer/SystemErr.log

- Oracle BI Server Log Files:

- user_projects/domains/cell_name/node_name/logs/bi_server1/SystemOut.log

- user_projects/domains/cell_name/node_name/logs/bi_server1/SystemErr.log

10.5.3 Diagnosing java.lang.RuntimeException or java.lang.NullPointerException for Oracle Business Intelligence on IBM WebSphere

If you attempt to access an instance of Oracle Business Intelligence that is not yet connected to an identity store, then you might see an error message that relates to the identity store.

You must install and configure an identity store for Oracle Business Intelligence. For more information, see Section 10.2.7.1, "Configuring the LDAP-Based Identity Store on IBM WebSphere."

11 Managing OAM Identity Assertion on IBM WebSphere

Oracle Access Manager Identity Assertion Provider for IBM WebSphere can be used to provide authentication and single sign-on with Oracle Access Manager 10g (10.1.4.3) through Access Manager 11g (11.1.1.7).

Note:

IBM WebSphere is shorthand for IBM WebSphere Application Server. For more information, see "Supported IBM WebSphere Application Servers".

This chapter includes the following topics:

- Section 11.1, "Introduction to OAM Identity Assertion on IBM WebSphere"

- Section 11.2, "Installing Components for the Oracle Access Manager IAP for IBM WebSphere"

- Section 11.3, "Introduction to the Oracle Access Manager 10g (10.1.4.3) Configuration Tool"

- Section 11.4, "Provisioning WebGate and Configuring OAM 10g (10.1.4.3) and the IAP for IBM WebSphere"

- Section 11.5, "Provisioning and Configuring OAM 11g for the IAP and IBM WebSphere"

- Section 11.6, "Installing the Required WebGate for the IHS Web Server"

- Section 11.7, "Preparing the IHS Web Server"

- Section 11.8, "Preparing the Login Form for 10.1.4.3 WebGate"

- Section 11.9, "Configuring IBM WebSphere for OAM SSO and the IAP"

- Section 11.10, "Configuring SSO Logout for Oracle Access Manager 10g"

- Section 11.11, "Configuring SSO Logout for Access Manager 11g"

- Section 11.12, "Known Issues"

11.1 Introduction to OAM Identity Assertion on IBM WebSphere

Oracle Access Manager Identity Assertion Provider is part of Oracle Fusion Middleware. Oracle provides an Identity Assertion Provider for IBM WebSphere that can be used to intercept and validate OAM sessions and generate IBM WebSphere-specific sessions.

IBM WebSphere allows Single Sign On (SSO) with external authenticators by using the Trust Association Interceptor (TAI). TAI interfaces provide mechanisms for external authenticators to perform user authentication and then assert the identity to IBM WebSphere. Oracle Access Manager Identity Assertion Provider for IBM WebSphere uses the TAI interface to assert the user identity from the OAM session to IBM WebSphere. Upon receiving user identity information from the Identity Assertion Provider, IBM WebSphere queries the existence of the user in the user registry.

Oracle Access Manager Identity Assertion Provider for IBM WebSphere needs a valid OAM session for asserting the user identity to IBM WebSphere. Typically this is achieved by using an IBM HTTP Server (IHS) reverse proxy to front-end IBM WebSphere. OAM WebGate is installed on the IHS proxy and used to authenticate users against Oracle Access Manager. WebGate generates an OAM session token upon successfully authenticating a user. The IHS proxy then forwards this session token to IBM WebSphere. The Identity Assertion Provider intercepts the request and asserts the user identity from the session token for IBM WebSphere.

The Identity Assertion Provider provides identity assertion using either the HTTP Cookie or HTTP Request Headers. Accordingly, the IAP can be configured for Cookie based assertion or header based assertion.

- Cookie-based Assertion: Is based on OAM Session Token (ObSSOCookie). In this configuration, the Identity Assertion Provider checks availability of ObSSOCookie and validates it. On successful validation, user identity in the session cookie is asserted to IBM WebSphere.

- Header-based Assertion: Is based on HTTP Request Header. In this configuration, the Identity Assertion Provider checks availability of a particular (configurable) request header in the request. If available, the user identity within the header is asserted to IBM WebSphere.

For more information, see the following topics:

- Scenario 1: Oracle Access Manager 10g (10.1.4.3) with the IAP on IBM WebSphere

- Scenario 2: OAM 11g with the IAP and IBM WebSphere

11.1.1 Scenario 1: Oracle Access Manager 10g (10.1.4.3) with the IAP on IBM WebSphere

This scenario describes a Java EE application that relies on Oracle Access Manager 10g (10.1.4.3) for authentication and authorization of its users. This application has been deployed on IBM WebSphere and can use the Identity Assertion Provider to provide SSO with Oracle Access Manager 10g (10.1.4.3).

Figure 11-1 Components and Process Flow with OAM 10g (10.1.4.3) and the IAP

Description of "Figure 11-1 Components and Process Flow with OAM 10g (10.1.4.3) and the IAP"

Process overview: Identity Assertion on IBM WebSphere

1. Browser to IHS Proxy Web Server: User accesses the IBM WebSphere resource using the proxy IHS host and port, which triggers the 10g (10.1.4.3) WebGate installed on IHS Web server to authenticate and authorize the user.

2. WebGate to Access Server: WebGate communicates with OAM 10g (10.1.4.3) Access Server using Oracle Access Protocol (OAP). Access Server checks the Policy Store to locate any policies protecting the requested resource. WebGate through Access Server collects credential information from the user based on the Authentication Scheme specified and then validates whether the user can be authenticated. On successful authentication, WebGate through Access Server authorizes the user to access the requested resource on the IHS Web server. Additionally, WebGate sets authorization headers in the request as specified in the OAM Policy.

3. Web Server to IBM WebSphere: IHS Web Server acts as a proxy for IBM WebSphere and forwards the request to IBM WebSphere after successful authorization by OAM 10g (10.1.4.3) WebGate. IHS Web Server will also forward the HTTP Cookies and Request Headers set in the request to the IBM WebSphere.
Requests are intercepted at IBM WebSphere by OAM IAP. The TAI of OAM then validates the Cookie and HTTP Header. OAM IAP communicates with 10g (10.1.4.3) Access Server for Cookie-based assertions, to validate the session token and retrieve user information for the session. The TAI asserts this user identity to IBM WebSphere.

IBM WebSphere checks for the existence of user in the user registry (configured LDAP instance) supplied by the OAM IAP. If the user is found, the assertion is successful. IBM WebSphere does not check for or request user's password in this scenario.

4. SSO Logout: See "Configuring SSO Logout for Oracle Access Manager 10g".

11.1.2 Scenario 2: OAM 11g with the IAP and IBM WebSphere

This scenario describes a Java EE application that relies on Oracle Access Manager 11g for authentication and authorization of its users. The Java EE application is deployed on IBM WebSphere to use the OAM IAP for IBM WebSphere for integrating the SSO with Oracle Access Manager 11g.

Figure 11-2 Components and Process Flow with OAM 11g and the IAP

Process overview: Identity Assertion with Oracle Access Manager 11g

1. Browser to IHS Proxy Web Server: The user accesses the resource (Sample Application on IBM WebSphere) using the proxy IHS host and port, which triggers the OAM 10g (10.1.4.3) WebGate installed to authenticate and authorize the user.

2. OAM 10g (10.1.4.3) IHS WebGate communicates with OAM 11g Server across the Oracle Access Protocol (OAP).
OAM 11g Server checks its policy store to locate policies protecting the resource.

WebGate and OAM 11g Server collect credentials from the user based on the authentication scheme specified in the policy, and the OAM 11g Server validates if the user can be authenticated.

On successful authentication, WebGate and OAM Server authorize the user before access to the requested resource on the IHS Web server is granted. WebGate sets authorization headers in the request as specified in the OAM policy.

3. Web Server to IBM WebSphere: IHS Web Server acts as a proxy for IBM WebSphere and forwards the request to IBM WebSphere after successful authorization by OAM 10g (10.1.4.3) WebGate. IHS Web Server also forwards to IBM WebSphere the HTTP Cookies and Request Headers set in the request.
Requests are intercepted at IBM WebSphere by OAM IAP. The TAI for OAM then validates the Cookie or HTTP Header. OAM IAP communicates with OAM 11g Server for Cookie-based assertions, to validate the session token, and retrieve user information for the session. TAI is responsible for asserting this user identity to IBM WebSphere.

IBM WebSphere checks the existence of the user (supplied by the OAM IAP) in its user registry (configured LDAP instance). If user is found in the user registry, the assertion is successful. IBM WebSphere does not request nor check the user's password in this scenario.

4. SSO Logout: See "Configuring SSO Logout for Oracle Access Manager 10g".

11.2 Installing Components for the Oracle Access Manager IAP for IBM WebSphere

This section outlines the tasks you must perform to enable OAM Identity Assertion with IBM WebSphere, with steps for both 10g and 11g OAM releases.

The Oracle Access Manager IAP for IBM WebSphere is available as part of Oracle Fusion Middleware suite for IBM WebSphere. The IAP for IBM WebSphere jar is located at:

MW_HOME/oracle_common/modules/oracle.oamprovider_11.1.1/
OAMTrustAssociationInterceptor.jar

Oracle Access Manager IAP for IBM WebSphere configuration file is located at:

MW_HOME/oracle_common/modules/oracle.oamprovider_11.1.1/
domain_config_was/oamtai.xml

Note:

Oracle Access Manager 10g (10.1.4.3) components and installation differs from Oracle Access Manager 11g components and installation. However, all other component installation tasks are the same.

Task overview: Installing components for IBM WebSphere, OAM, and the IAP

1. Install and set up IBM WebSphere as described in Chapter 2, "Installing and Configuring Oracle Fusion Middleware on IBM WebSphere."

2. IBM HTTP Server 7.x can be used as a reverse proxy in front of IBM WebSphere.

Note:

For IBM HTTP Server 7.x, use IHS22 WebGate package.

3. Oracle Access Manager: Install either of the following:

- OAM 10g (10.1.4.3): As described in the Oracle COREid Access and Identity Installation Guide and includes:
Identity Server
Access Server
Policy Manager
Web Components (OHS 11g): WebPass, Policy Manager, WebGate

- OAM 11g: As described in Oracle Fusion Middleware Installation Guide for Oracle Identity Management, which includes:
Oracle Access Manager 11g
Oracle Identity Manager 11g
Oracle WebLogic Server

4. WebGate: Required for either OAM 10g or OAM 11g, and can be installed after provisioning as described later in this chapter.

11.3 Introduction to the Oracle Access Manager 10g (10.1.4.3) Configuration Tool

Skip this topic if you have OAM 11g deployed.

This section introduces OAMCfgTool (oamcfgtool.jar) is a platform-agnostic configuration tool for use with Oracle Access Manager 10g (10.1.4.3).

See Also:

Oracle Fusion Middleware Application Security Guide for more information on OAMCfgTool

OAMCfgTool is a command-line utility provided to automatically run a series of scripts and set up policies. OAMCfgTool requires a set of parameters as inputs to create the required form-based authentication scheme, policy domain, access policies, and a WebGate profile for the Identity Asserter for single sign-on for IBM WebSphere.

Note:

OAMCfgTool requires JRE 1.5 or 1.6. Internationalized login forms for Fusion Middleware applications are supported with the policies protecting those applications.

With OAM 10g (10.1.4.3) deployed, if you do not use the OAM Config Tool you must manually create the host-identifier, authentication schemes, and OAM policy manually using the Access System Console, as described in the Oracle Access Manager Access Administration Guide.

Example 11-1 a sample template for the configuration file for creating the required artifacts for the OAM IAP for IBM WebSphere. Additional information follows the example.

Example 11-1 Sample URIs_config File for OAMCfgTool and the IAP for IBM WebSphere

-- Template-starts --
###################################
#
# OAM-WAS Integration using OAM IAP
#
###################################
protected_uris

###################################
#Resources protected with default authentication scheme
/webcenter/adfAuthentication

###################################
public_uris
###################################
#Public Policy required for Cookie Based Assertion
Cookie Based Assertion
/Authen/SSOToken
-- Template-ends --

Example 11-2 illustrates a sample of the command-line syntax for OAMCfgTool when configuring artifacts for OAM 10g (10.1.4.3) and the IAP for IBM WebSphere.

Example 11-2 OAMCfgTool Syntax Configures Artifacts for OAM 10g (10.1.4.3) IAP

(echo ldappwdjava -jar oamcfgtool.jar
mode=CREATE app_domain=OAMPolicy_for_WAS-IAP
uris_file=/path-to-template-config-file
web_domain=host-id-name
ldap_host=wxyz
ldap_port=6633
ldap_userdn=orcladmin
ldap_base=ldap-base-dn
oam_aaa_host=abcd
oam_aaa_port=7789
oam_aaa_mode=open
log_file=OAMCfg_date.log
log_level=INFO
output_ldif_file=<LDIF_filename>
-noprompt

The above sample command produces the following artifacts:

- OAMPolicy_for_WAS-IAP, OAM Policy for protecting IBM WebSphere resources specified under protected_uris and public_uris

- OraDefaultAnonAuthNScheme, Anonymous Authentication Scheme used by OAMPolicy_for_WAS-IAP

- OraDefaultFormAuthNScheme, Form Authentication Scheme used by OAMPolicy_for_WAS-IAP

- Other OAM authentication scheme configuration

For a known resource, the public URI policy needs a Return Attribute in the Authorization Actions for Cookie-based assertion, as shown in Table 11-1. In this case, the return name OAM_REMOTE_USER is not configurable in oamtai.xml.

Table 11-1 Authorization Actions for "Cookie-based Assertion" in Public URI Policy

Type

Name

Return Attribute

HeaderVar

OAM_REMOTE_USER

uid

To enable Header-based assertion, you must set the Return Attribute in Authorization Actions of the Resource (protected_uris) protection policy. With Header-based Assertion, the return name OAM_REMOTE_USER is configurable in the oamtai.xml file and you must ensure that the Header-based Assertion section is uncommented.

Table 11-2 Authorization Actions for "Header Based Assertion" in Protected URI Policy

Type

Name

Return Attribute

HeaderVar

OAM_REMOTE_USER

uid

11.4 Provisioning WebGate and Configuring OAM 10g (10.1.4.3) and the IAP for IBM WebSphere

Skip this topic if you have OAM 11g deployed.

This section provides the steps to obtain the OAMCfgTool, provision the required WebGate, create a form authentication scheme, and create a policy domain and OAM 10g (10.1.4.3) policies for the IAP and IBM WebSphere.

See Also:

"Introduction to the Oracle Access Manager 10g (10.1.4.3) Configuration Tool"

To acquire OAMCfgTool and configure OAM 10g (10.1.4.3) for the IAP for IBM WebSphere:

1. Obtain the OAMCfgTool as follows:

1. Log in to Oracle Technology Network at:

http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html

2. Locate the OAMCfgTool ZIP file with Access Manager Core Components (10.1.4.3.0):

oamcfgtool<version>.zip

3. Extract and copy oamcfgtool.jar to the computer hosting the IBM WebSphere application to protect.

4. Confirm that JDK 1.6 (or the latest version) is installed and configured on the host computer.

5. Change to the file system directory containing OAMCfgTool.

2. Provision WebGate, Create the Authentication Scheme, and Policy Domain: Run the following command using values for your environment. For example:

(echo ldappwdjava -jar oamcfgtool.jar
mode=CREATE app_domain=OAMPolicy_for_WAS-IAP
uris_file=/path-to-template-config-file
web_domain=host-id-name
ldap_host=wxyz
ldap_port=6633
ldap_userdn=orcladmin
ldap_base=ldap-base-dn
oam_aaa_host=abcd
oam_aaa_port=7789
oam_aaa_mode=open
log_file=OAMCfg_date.log
log_level=INFO
output_ldif_file=<LDIF_filename>
-noprompt

3. Review the information provided by the tool. For example, the parameter and values in Step 3 provide the following information:

Processed input parameters
Initialized Global Configuration
Successfully completed the Create operation.
Operation Summary:
Policy Domain  : OAMPolicy_for_WAS-IAP
Host Identifier: OAMPolicy_for_WAS-IAP
Access Gate ID : OAMPolicy_for_WAS-IAP_AG

4. Update host identifiers to include possible host-variations.

5. Add following authorization actions to the "Header Based Assertion" Policy.
Type Name Return Attribute

HeaderVar OAM_REMOTE_USER uid

6. Proceed to "Installing the Required WebGate for the IHS Web Server".

11.5 Provisioning and Configuring OAM 11g for the IAP and IBM WebSphere

Skip this section if you have OAM 10g (10.1.4.3) deployed.

This section provides the following topics:

- About Provisioning WebGates and AccessGates with OAM 11g

- Provisioning Agents and Creating OAM 11g Policies for IBM WebSphere

11.5.1 About Provisioning WebGates and AccessGates with OAM 11g

This topic introduces OAM 11g access clients, known as policy-enforcement agents, and the process that is required to set up the trust mechanism between the agent and Oracle Access Manager 11g SSO. The process is known as provisioning (also known as registering an agent).

Only registered policy enforcement agents can communicate with an OAM Server, and process information when a user attempts to access a protected resource. Users with valid OAM Administrator credentials can register an OAM Agent using the Administration Console.

You can register a WebGate agent before you install it. Required WebGate or AccessGate configuration files are created during registration and stored in the following path:

DOAMIN_NAME/output/$Agent_NAME

During registration, you can also create an application domain and default policies. For this reason, registering an agent is also known as "registering a partner application".

During registration, the Agent is presumed to be on the same Web server as the application it is protecting. However, the Agent can be on a proxy Web server and the application can be on a different host.

During Agent registration:

- One key is generated per agent, accessible to the WebGate through a local wallet file on the client host, and to OAM Server through the Java Key Store on the server side.
The Agent specific key must be accessible to WebGates through a secure local storage on the client machine.

- A key is generated for the partner (application) during registration. (except for 10g (10.1.4.3) WebGate agents).

- An OAM application domain is created, named after the Agent, and populated with default authentication and authorization policies. The new application domain uses the same host identifier that was specified for the Agent during registration.

After registration, agent details appear in the OAM Administration Console and are propagated to all Managed Servers in the cluster. If you choose to automatically create policies during agent registration, you can also view and manage the application domain and policies that were registered with the partner application.

Table 11-3 describes each of named text fields where you enter requested information on the Create OAM Agent page.

Table 11-3 Create OAM Agent Pages for OAM 11g and 10g (10.1.4.3) Agents

OAM Agent Element

Description

Agent Name

The identifying name for this WebGate Agent. This is often the name of the computer that is hosting the Web server used by WebGate.

Note: If the Agent Name exists, an error occurs and registration fails. If the host identifier exists, the unique Agent Base URL is added to the existing host identifier and registration proceeds.

Agent Base URL

Optional

The host and port of the computer on which the Web server for the agent is installed. For example, http://my_ohs_host:port or https://my_host:port. The port number is optional.

Note: A particular Agent Base URL can be registered once only. There is a one-to-one mapping from the Agent's Base URL to the Web server domain on which the WebGate is installed (as specified with the <hostidentifier> element). However, one domain can have multiple Agent's Base URLs.

Access Client Password

An optional, unique password for this WebGate, which was assigned during WebGate registration.

When a registered WebGate connects to an OAM 11g Server, the password is used for authentication to prevent unauthorized WebGates from connecting to OAM 11g Servers and obtaining policy information.

Security

Level of communication transport security between the Agent and the OAM Server (this must match the level specified for the OAM Server):

- Open--No transport security

- Simple--SSL v3/TLS v1.0 secure transport using dynamically generated session keys

- Cert--SSL v3/TLS v1.0 secure transport using server side x.509 certificates. Choosing this option displays a field where you can enter the Agent Key Password, discussed separately within this table.

Host Identifier

This identifier represents the Web server host.

Auto Create Policies

During agent registration, you can have authentication and authorization policies created automatically. This option is checked (enabled) by default.

Default: Enabled

Note: If you already have a domain and policies registered, you can simply add new resources to it. If you clear this option (no check), no application domain or policies are generated automatically.

Protected Resource (URI) List

URIs for the protected application: /myapp/login, for example. Each URI for the protected application should be specified in a new row of the table for the Protected Resource List.

Default: 2 resources are protected by default.

/.../*
/

The default matches any sequence of characters within zero or more intermediate levels spanning multiple directories.

Add all IBM WebSphere resources to be protected to this list.

Public Resource (URI) List

Each public application should be specified in a new row of the table for the Public Resource List.

Add a field and enter URI values for the public applications and resources. Each URI should be specified in a new row of the table for the Public Resource List.

Add all IBM WebSphere resources that should not be protected to this list.

Note: /Authen/SSOToken is an additional public resource that is used by the Oracle Access Manager Identity Assertion Provider.

See Also:

Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service for more information

11.5.2 Provisioning Agents and Creating OAM 11g Policies for IBM WebSphere

This topic describes how to provision agents and create policies for OAM 11g.

At least one OAM Server instance must be running in the same mode as the agent. Otherwise, agent registration fails. After provisioning, you can change the communication mode of the OAM Server if needed. Communication between the agent and server continues to work as long as the WebGate mode is at least at the same level as the OAM Server mode (or higher).

To register an agent and create policies for the OAM 11g IAP for IBM WebSphere:

1. Log in to the Oracle Access Manager Console as usual. For example: http://host:port/oamconsole.

2. On the Welcome page, SSO Agent panel, click New OAM 10g Agent.
Alternatively: From the System Configuration tab, Access Manager Settings section, expand the SSO Agents node, double-click OAM Agents node, then click the desired Create ... Webgate button in the upper-right corner.

3. On the Create: OAM Agent page, enter required details (those with an *) to register this OAM Agent, as shown in Table 11-3.

4. Protected Resource List: In this table, enter individual resource URLs to be protected by this OAM Agent, as shown in Table 11-3.

5. Public Resource List: In this table, enter individual resource URLs to be public (not protected), as shown in Table 11-3, including /Authen/SSOToken used by the Oracle Access Manager Identity Assertion Provide.

6. Confirm that the Auto Create Policies box is checked (or clear the box to disable this function).

7. Click Apply to submit the registration (or close the page without applying changes).

8. Check the Confirmation window for the location of generated artifacts and then close the window.

9. Repeat steps 2-8 to register an additional AccessGate and policies for use by WebGate, as follows:

- Enter a name for this AccessGate registration.

- Select the appropriate Security mode.

- Do not specify a Base URL.

- Check Auto Create Policies

- Click Apply

10. Proceed to "Installing the Required WebGate for the IHS Web Server".

11.6 Installing the Required WebGate for the IHS Web Server

This topic applies to both OAM 10g and 11g deployments. In addition to the generic instructions for both deployments, there are individual steps for OAM 10g and 11g. Ignore any steps that do not apply to your deployment.

After provisioning, you can install the 10g (10.1.4.3) WebGate for IHS to operate with Oracle Access Manager. Ignore any steps that do not apply to your environment.

To download and install the 10g (10.1.4.3) WebGate for IHS:

1. Locate and download the WebGate installer as follows:

1. Go to Oracle Fusion Middleware 11gR1 Software Downloads at:

http://www.oracle.com/technology/software/products/middleware/htdocs/fmw_11_download.html

2. Click Accept License Agreement, at the top of the page.

3. From the Access Manager WebGates (10.1.4.3.0) row, click the download link for the desired platform and follow on-screen instructions.

4. Store the WebGate installer in the same directory with any 10g (10.1.4.3) Access System Language Packs you want to install.

2. Launch the WebGate installer for your platform, installation mode, and Web server, and then:

1. Dismiss the Welcome screen by clicking Next.

2. Respond with administrator privileges when asked.

3. Specify the installation directory for the WebGate. For example:
/OracleAccessManager/WebComponent/

4. Linux or Solaris: Specify the location of the GCC runtime libraries on this computer.

5. Language Pack—Choose a Default Locale and any other Locales to install, then click Next.

6. Record the installation directory name in the preparation worksheet if you haven't already, then click Next to continue.
The WebGate installation begins, which may take a few seconds. On Windows systems, a screen informs you that the Microsoft Managed Interfaces are being configured.

3. OAM 10g (10.1.4.3) Deployment: Continue installation, as described in the 10g (10.1.4.3) Oracle COREid Access and Identity Installation Guide, and:

1. Specify the same values when you install the WebGate that were specified when provisioning the WebGate using OAMCfgTool, earlier.

2. Specify any additional requested values to properly finish the installation

3. Copy the files to the WebGate host: WebGate_install_dir/access/oblix/config.

4. Restart the WebGate Web server.

5. Proceed to "Preparing the IHS Web Server".

4. OAM 11g Deployment: Cancel the WebGate installer (without finishing) and gather WebGate 10g (10.1.4.3) provisioning artifacts (and certificate files, if needed). For example:

1. On the OAM AdminServer host, locate and copy the updated OAM Agent ObAccessClient.xml configuration file (and any certificate artifacts). For example:
DOMAIN_HOME/output/$Agent_Name/

ObAccessClient.xml
password.xml (if needed)
aaa_key.pem (your private key generated by openSSL)
aaa_cert.pem (signed certificates in PEM format)

2. On the OAM Agent host, add the artifacts to the WebGate directory path. For example:
WebGate_install_dir/access/oblix/lib/ObAccessClient.xml
WebGate_install_dir/access/oblix/config

3. Restart the WebGate Web server.

4. Run the EditHTTPConf tool to update IHS Server configuration for WebGate.

5. Restart the OAM Server that is hosting the Agent.

6. Proceed to "Preparing the IHS Web Server".

11.7 Preparing the IHS Web Server

With IHS2 WebGate, the IHS httpd.conf file includes entries for adding the /oamsso directory to the Web Server root. However, if you have an earlier Oracle Access Manager IHS2 WebGate, you must add the following entries under the WebGate block of the httpd.conf file.

To prepare the IHS Web server:

1. On the computer hosting the WebGate, locate IHS httpd.conf file and confirm the following entries exist (if they do not add them):

Alias /oamsso "<webage-install-dir>/access/oamsso"
Satisfy All
</LocationMatch>

2. Proceed with "Preparing the Login Form for 10.1.4.3 WebGate".

11.8 Preparing the Login Form for 10.1.4.3 WebGate

If you have Oracle Access Manager 11g, the OAM Server instance provides the Login form and you can skip this procedure.

This section describes how to acquire the proper login forms for use with the provisioned and installed 10g (10.1.4.3) IHS WebGate.

Note:

The forms provided with 10g (10.1.4.3) WebGates cannot be used with OAM 11g Servers.

In an OAM 10g (10.1.4.3) deployment, if you have:

- 10g (10.1.4.3) IHS2 WebGate (or later), find login.html in WebGate_install_dir/access/oamsso/login.html.

- Earlier 10g (10.1.4.3) IHS2 WebGate, you must create the directory and place a sample login.html file manually, as described in the following procedure.

To preview the login.html file for 10g (10.1.4.3) IHS WebGate:

1. OAM 10g (10.1.4.3) with 10g (10.1.4.3) IHS2 WebGate (or later), preview login.html in WebGate_install_dir/access/oamsso/login.html.

2. OAM 10g (10.1.4.3) with 10g (10.1.4.2.0) or earlier WebGate for IHS2:

1. Create an /oamsso subdirectory in the following path: WebGate_install_dir/oamsso.

2. Create and add to the new /oamsso directory a login.html file with the following elements:

<!--Sample login Page Code -->
<form name="loginForm" method="post" action="/access/sso">
<b> Username: </b> <input name="userid" type="text" maxLength="80" size="20" value="">
<b> Password: </b> <input type="password" maxLength="255" size="20"
name="password" autocomplete="off">
<input type="submit" value="Login" name="submit">
</form>

3. Proceed to "Configuring IBM WebSphere for OAM SSO and the IAP".

11.9 Configuring IBM WebSphere for OAM SSO and the IAP

This section provides the following topics:

- Configuring a Stand Alone LDAP Registry for OAM in IBM WebSphere

- Adding and Configuring a Virtual Host in IBM WebSphere

- Configuring IHS Reverse Proxy in the IBM WebSphere Console

- Creating the Interceptor Entry in the IBM WebSphere Console

- Configuring the OAM TAI Configuration File

11.9.1 Configuring a Stand Alone LDAP Registry for OAM in IBM WebSphere

This section describes how to configure a stand-alone LDAP registry for OAM within IBM WebSphere.

To configure a stand alone LDAP registry for OAM in IBM WebSphere:

1. Login to your IBM WebSphere console. For example:

http://host:port/ibm/console

2. Go to Security, Global Security.

3. Under User account repository in Available realm definitions, select Standalone Ldap Registry and click Configure.

4. Under General Properties, fill in fields to configure the LDAP directory that is used by OAM:
Primary administrative user name <OAM admin username>
Server user identity: keep the default selection
Type of Ldap Server: <LDAP Directory Type for OAM>
Host: < host name where LDAP directory resides>
Port : <LDAP directory bind port>
Base DN: <LDAP base DN>
Bind DN: <LDAP bind DN>
Password: <LDAP password>
Search timeout: keep the default value (120 seconds)
Keep default Reuse connection and Ignore case for authorization (checked)

5. Click Apply and OK and save this configuration.

6. On the same page, under Additional Properties, click Advanced Lightweight Directory Access Protocol (LDAP) user registry settings and fill in fields under the General Properties:
User filter: (&(uid=%v)(objectclass=inetOrgPerson))
Group filter: (&(cn=%v)(objectclass=ldapsubentry))
User ID Map: uid
Group ID Map: cn
Group Member ID Map: nsRole:nsRole

7. Click Apply and OK and save this configuration.

8. On the same page, under Related Items, click Trusted authentication realms - inbound and confirm that the LDAP entry (host:port) is trusted.

9. Click Test connection to verify the connection configuration.

10. Restart IBM WebSphere.
If Standalone LDAP Registry is not selected as "Current realm" then under "User account repository" in "Available realm" definitions, select "Standalone Ldap Registry" and click "Set As Current".

11. From now onward, log in to the IBM WebSphere console using OAM LDAP directory login credentials (as registered with IBM WebSphere).

11.9.2 Adding and Configuring a Virtual Host in IBM WebSphere

You must bind your Web applications to virtual hosts (logical name for configuring Web applications to a particular host name). When you request a resource, IBM WebSphere maps the request to an alias of a defined virtual host.

To add and configure a virtual host in IBM WebSphere for the enterprise application:

1. Login to your IBM WebSphere console. For example: http://host:port/ibm/console

2. Go to Environment, Virtual Hosts, and click New

3. Enter the General Properties for your environment, as follows:

1. Add name: IHS host name and click on Ok and then save the changes.

2. Click the recently created entry IHS host name:

4. Under Additional Properties, click Host Aliases, and then click New.

5. Fill in details for General Properties for your environment, as follows:

1. Host: Host name where IHS server resides

2. Port: IHS port

6. Click OK to save the changes and continue with the next steps to configure the virtual host in your deployed enterprise application.

7. Go to Applications, WebSphere Enterprise Applications, and:

1. Click <enterprise application>.

2. Under Web Module Properties, click Virtual Hosts.

3. Select all the Web modules and apply the virtual host that you added.

4. Click OK, then save the changes.

8. Restart IBM WebSphere where the enterprise application is deployed.

9. Proceed to "Configuring IHS Reverse Proxy in the IBM WebSphere Console".

11.9.3 Configuring IHS Reverse Proxy in the IBM WebSphere Console

This section describes how to configure the IHS server in reverse proxy mode within the IBM WebSphere console.

To configure IHS in reverse proxy mode within IBM WebSphere:

1. Login to your IBM WebSphere console. For example:

http://host:port/ibm/console

2. Go to Server Types, Web Servers.

3. Click New, and provide IHS Web server details.

4. Save changes to see a server entry for IHS.

5. Generate and configure the server plug-in:

1. Select the ServerName and click Generate Plug-in.

2. Navigate to Plug-in Properties, then Additional Properties, and then to Request and Response.

3. Select Accept content for all requests.

4. Click OK and then Save.

5. Select the ServerName and click Generate Plug-in again, and then click Propagate Plug-in.

6. Configure the IHS Web server to act as a reverse proxy for IBM WebSphere, as follows:

Note:

For published Web Site Access with the IHS Plug-in, perform Step d as described and add site URLS to Oracle Access Manager policies. For more information, see the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.

1. Locate plugin-cfg.xml in IHS_install_dir/Plugins/config/ServerName.

2. Remove the following entry:

<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid"
Name="/*"/>

3. Make UCM URLs available by adding the following entries:

<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/adfAuthentication/*"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/cs/*"/>

4. Published Web Site Access with IHS Plug-in: Add URLs in plugin-cfg.xml(it's needed to add site URLs in OAM policy too. For example, if Bing11G is the context root for the Web site, your need to add:

<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/_dav/cs/*"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/_dav/urm/*"/>

5. Remove Redundant entries: Of the 2 entries <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/_dav/*"/>, one is for UCM, the other is for URM. These can conflict. To use SSO URLs in DIS WEI:

<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/_dav/cs/*"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/_dav/urm/*"/>

7. Restart the IHS Web server.

8. Proceed to "Creating the Interceptor Entry in the IBM WebSphere Console".

11.9.4 Creating the Interceptor Entry in the IBM WebSphere Console

Tasks are the same whether you are using Oracle Access Manager 10g (10.1.4.3) or Oracle Access Manager 11g.

At runtime, the IBM WebSphere extension class loader loads classes. The extension class loader class path is specified by the ws.ext.dirs system property. Therefore, you must add the IAP for IBM WebSphere OAMTrustAssociationInterceptor.jar file in the IBM WebSphere classpath:

The IAP for IBM WebSphere OAMTrustAssociationInterceptor.jar file is available from the following path:

MW_HOME/oracle_common/modules/oracle.oamprovider_11.1.1/
OAMTrustAssociationInterceptor.jar

To add the OAMTrustAssociationInterceptor.jar to the IBM WebSphere classpath:

1. In IBM WebSphere console go to Servers, Server Types, WebSphere Application, Servers, and select the appropriate server.

2. Under the Server Infrastructure section, click Java And Process Management, and then Process Definition.

3. In Additional properties, select Java Virtual Machine, Custom Properties.

4. In the property ws.ext.dirs, add the value for OAMTrustAssociationInterceptor.jar. For example:

MW_HOME/oracle_common/modules/oracle.oamprovider_11.1.1/ OAMTrustAssociationInterceptor.jar

5. Confirm that the two values are separated by colon.

6. Create the Interceptor entry for the OAM IAP, as follows:

1. In the IBM WebSphere console, go to Security, Global Security, and ensure that "Enable Application Security" is checked.

2. Under the "Authentication" section, click "Web and SIP Security" tab, and then click the Trust association link.

1. Under General Properties, check the "Enable Trust Association".

2. Under Additional Properties, click Interceptors link.

3. Under General Properties, click Under New, and provide the Interceptor class name as follows:

oracle.security.was.providers.tai.OAMTrustAssociationInterceptorImpl

7. Proceed to "Configuring the OAM TAI Configuration File" to configure oamtai.xml as a custom property of Interceptor class path.

11.9.5 Configuring the OAM TAI Configuration File

The oamtai.xml configuration file is used by the OAM Trust Association Interceptor. You must configure the file and modify it for your environment. For details, see:

- About Configuring the OAM TAI Configuration File

- Configuring the OAM TAI Configuration File

11.9.5.1 About Configuring the OAM TAI Configuration File

The oamtai.xml configuration file is available in the following path:

MW_HOME/oracle_common/modules/oracle.oamprovider_11.1.1/domain_config_was
/oamtai.xml

This file stores the details that are used by the TAI at run time to establish a connection with 10g (10.1.4.3) OAM Access Server (or 11g OAM Server).

There are two ways to configure the oamtai.xml file:

- Either copy oamtai.xml to was_profile_dir/config/cells/cell_name/fmwconfig/oamtai.xml.

- Or perform Step 1 in the following procedure to configure oamtai.xml as a custom property of the Interceptor entry added earlier.

You must modify the oamtai.xml file to establish a connection to the Access Server, using parameters in Table 11-4 and values for your deployment. To enable Header based assertion, ensure that the Header Based Assertion section in oamtai.xml is not commented and use the same customHeadername in both oamtai.xml and the OAM policy.

Table 11-4 oamtai.xml Configuration File Parameters

Parameter

Required or Not

Description

hostPort

Required

Hostname and port of the IHS Web server where the resource is hosted.

Note: The host:port should be one of the host name variations present in OAM.

resource

Required

The URL to the protected resource.

Default = /Authen/SSOToken or the value in the OAM policy if you have updated it.

ip

Optional

IP address of the client computer that needs to access the resource.

operation

Required

Operation requested to access the Authen/SSOToken.

accessGateName

Required

A unique name, without spaces, that identifies the AccessGate to be used while interacting with OAM. With OAMCfgTool the name is derived from the app_domain value, appended with _AG.

AccessGatePassword

Required

A unique password to verify and identify the AccessGate when interacting with OAM. This prevents unauthorized AccessGates from connecting and obtaining policy information. With OAMCfgTool, this is specified with the app_agent_password parameter. This should differ for each WebGate/AccessGate instance.

accessServerHost

Required

OAM Access Server (or OAM 11g Server) host name.

accessServerPort

Required

OAM Access Server (or OAM 11g Server) port number.

accessServerName

Optional

Name of the OAM Access Server, as identified in the profile (or OAM 11g Server registration).

transportSecurity

Required

The level of transport security between the 10g (10.1.4.3) Access Server and associated WebGates must match. The default value is Open. You can specify a different value with OAMCfgTool oam_aaa_mode value.

The following parameters trustStore, keyStore, keyStorePass and globalPass values are required when transport security mode is 'Simple' or 'Cert'

- trustStore: Specify the absolute path to the trust store.

- keyStore: Specify the absolute path to the key store

- keyStorePass: Specify the keystore password,

- globalPass: Specify the global passphrase value that was defined during IHS WebGate installation and configuration.

debug

Required

Turns OAM debugging on or off.

Default: false

minConn

Required

The minimum number of connections that this AccessGate can establish with Access Servers. This number must be the same as or less than the number of Access Servers that are actually associated with the WebGate.

maxConn

Required

The maximum number of connections that this AccessGate can establish with Access Servers. This number must be the same as or greater than the number of Access Servers that are actually associated with the WebGate.

timeOutForConnPool

Required

Connection pool time out period. Specify any value in milliseconds.

Default: 30000 (milliseconds)

Anonymous

Required

Configures the anonymous user value.

Note: Following two parameters assertionType and customHeaderName are required for Header Based Assertion. Uncomment it if and only if in case of Header based assertion.

- If user configures the headername here, then the same name will be used to configure as return attribute in OAM policy. And don't change the value of assertion type parameter only uncomment parameter entry

- If user will not be configuring the header name here, then default header name is "OAM_REMOTE_USER" and same should be configured in OAM policy. Also don't change the value of assertion type parameter only uncomment parameter entry

assertionType

Required

The value should be 'HeaderBasedAssertion', don't change it

customHeaderName

Required

Default value used is " OAM_REMOTE_USER", or according to the OAM Policy if you have updated it.

Note: You can provide any value as long as the same value is used in the OAM policy while configuring the Header. Otherwise you must use the default value "OAM_REMOTE_USER" while configuring the policy. In both cases, ensure that the "assertionType" parameter entry in the oamtai.xml file is uncommented.

Note:

WebGate timeout should be greater than LTPA timeout. Otherwise, the IAP is not triggered which could cause the WebGate session to time out. If this occurs, a user who logs in with a different userID could get access to the resource because the previously generated LTPA token still exists. LTPA timeout default value is 120 minutes; therefore, the WebGate profile requires a WebGate timeout value greater than 120 minutes.

11.9.5.2 Configuring the OAM TAI Configuration File

The following procedure describes how to configure oamtai.xml for your environment.

Skip Step 1 if oamtai was copied to the following path: was_profile_dir/config/cells/cell_name/fmwconfig/oamtai.xml.

To configure oamtai.xml as a custom property of the Interceptor:

1. Custom Interceptor Property:

1. In the IBM WebSphere console, go to Security, Global Security.

2. Under the "Authentication" section, click "Web and SIP Security tab"; click the Trust association link.

3. Click the Trust association link.

4. Under Additional Properties, click Interceptors link.

5. Select the Interceptor class name oracle.security.was.providers.tai.OAMTrustAssociationInterceptorImpl

6. Under Custom Properties, add a property with the absolute path of oamtai.xml details for the oamtai.xml file:
Name: OAMTaiProperty

Value: was_profile_dir/config/cells/cell_name/fmwconfig/oamtai.xml

2. Modify oamtai.xml: Use parameters in Table 11-4 with values for your deployment to a establish a connection with the Access Server.

3. Header Based Assertion: In the oamtai.xml file, perform the following steps.

1. Uncomment the "assertionType" entry and retain the value "HeaderBasedAssertion".

2. Uncomment the "customHeaderName" entry and set the value as desired (Table 11-4).

4. Save the file.

5. OAM Policy: Use the same "customHeaderName" value when configuring the OAM policy.

6. Restart IBM WebSphere for changes to take affect.

7. Proceed as needed for your deployment:

- Configuring SSO Logout for Oracle Access Manager 10g

- Configuring SSO Logout for Access Manager 11g

11.10 Configuring SSO Logout for Oracle Access Manager 10g

Oracle recommends that you leverage JavaScript to clear client cookies for situations not addressed by Oracle Access Manager logout. This can be accomplished by developing a custom logout application, which is the URL (end_url query parameter) to which Oracle Access Manager redirects after completing its global logout. This logout application will be responsible for clearing all the client cookies that were created during the session.

Note:

- When all WebSphere Servers are in the same domain, the sample Javascript (ADF, non-ADF) provided should suffice.

- When WebSphere Servers are in multiple domains, Oracle recommends that the custom logout application be developed as described in the previous paragraph.

This section describes logout with the Oracle Access Manager IAP for IBM WebSphere.

- Configuring Logout for Generic (or Non-ADF) Applications

- Configuring Logout for ADF-Coded Applications

11.10.1 Configuring Logout for Generic (or Non-ADF) Applications

In non-ADF applications, logout is initiated when an application causes the invocation of the logout.html that is configured as the target in the application's logout link.

The logout.html file can be placed at the Web server's doc root, or it can be part of the IBM WebSphere application.

If you are using your own logout.html, you can embed Example 11-3 JavaScript to invoke "delOblixCookie" upon loading the page body. The LTPAToken is deleted by JavaScript; ObSSOCookie is deleted by WebGate.

<body onload="delOblixCookie();">

Example 11-3 JavaScript to invoke delOblixCookie

function delCookie(name,path,domain) {
var today = new Date();
var deleteDate = new Date(today.getTime() - 48 * 60 * 60 * 1000); // minus 2
days
var cookie = name + "="
+ ((path == null) ? "" : "; path=" + path)
+ ((domain == null) ? "" : "; domain=" + domain)
+ "; expires=" + deleteDate;
document.cookie = cookie;
}
function delOblixCookie() {
// set focus to ok button
var isNetscape = (document.layers);
if (isNetscape == false || navigator.appVersion.charAt(0) >= 5) {
for (var i=0; i<document.links.length; i++) {
if (document.links[i].href == "javascript:top.close()") {
document.links[i].focus();
break;
}
}
}
delCookie('ObTEMC', '/');
delCookie('ObSSOCookie', '/');
delCookie('LtpaToken', '/');
delCookie('LtpaToken2', '/');
// in case cookieDomain is configured
// delete same cookie to all of subdomain
var subdomain;
var domain = new String(document.domain);
var index = domain.indexOf(".");
while (index > 0) {
subdomain = domain.substring(index, domain.length);
if (subdomain.indexOf(".", 1) > 0) {
delCookie('ObTEMC', '/', subdomain);
delCookie('ObSSOCookie', '/', subdomain);
delCookie('LtpaToken', '/', subdomain);
delCookie('LtpaToken2', '/', subdomain);
}
domain = subdomain;
index = domain.indexOf(".", 1);
}
}

To configure logout for generic (non-ADF) applications:

1. Locate the desired logout.html file.

2. Add the JavaScript in Example 11-3 to logout.html to invoke "delOblixCookie" upon loading the page body.

11.10.2 Configuring Logout for ADF-Coded Applications

In ADF coded Fusion Middleware applications such as Oracle WebCenter Portal application, single sign off is achieved through OPSS. For details, see the following topics:

- Configuring 10g WebGate for Logout with OAM 10g

- Configuring SSO Logout for OPSS with ADF-coded applications and OAM 10g Webgate

- Configuring oamAuthenProvider.jar in the IBM WebSphere classpath

- Verifying SSO Logout

11.10.2.1 Configuring 10g WebGate for Logout with OAM 10g

This topic provides an example (Example 11-4) and procedure that you can use and customize to logout an application protected by OAM 10g with a 10g WebGate.

If you are using your own logout.html, you can embed Example 11-3 JavaScript to invoke "delOblixCookie" upon loading the page body. The LTPAToken is deleted by JavaScript; ObSSOCookie is deleted by WebGate.

Note:

Example 11-4 applies only for an end URI of a single word. For a long URI, you must update the parsing logic accordingly.

To configure WebGate for logout:

1. Create and edit logout.html for the WebGate based on Example 11-3 and Example 11-4: add and call the function handleLogout() for redirecting the logout request to the end URL specified in the logout URL; Invoke delOblixCookie() function from within handleLogout() and then redirect to the end URL.

Example 11-4 Sample logout.html Script

<html>
<head>
<script language="javascript" type="text/javascript">

function handleLogout() {

//get protocol used at the server (http/https)
var webServerProtocol = window.location.protocol;
//get server host:port
var webServerHostPort = window.location.host;
//get query string present in this URL
var origQueryString = window.location.search.substring(1);

//vars to parse the querystring
var params = new Array();
var par = new Array();
var val;

if (origQueryString != null && origQueryString != "") {

params = origQueryString.split("&");

//search for end_url and redirect the user to this
for (var i=0; i<params.length; i++) {

par = params[i].split("=");
if ("end_url" == par[0]) {
endUrlVal = par[1];

//check if val (value of end_url) begins with "/" or "%2F" (is it an URI?)
if (endUrlVal.substring(0,1) == "/" || endUrlVal.substring(0,1) == "%") {
if (endUrlVal.substring(0,1) == "%")
endUrlVal = "/" + endUrlVal.substring(3);

//modify the end_url value now
endUrlVal = webServerProtocol + "//" + webServerHostPort + endUrlVal;
}
//redirect the user to this URL
window.location.href = endUrlVal;
}
}
}
}
</script>
</head>
<body onLoad="handleLogout();">
<h3>You have been logged out<h3>

</body>
</html>

2. Store your logout.html script to WebGate_install_dir/oamsso/logout.html

3. In the httpd.conf file, ensure following entries exist under the WebGate block:

Alias /oamsso "<webage-install-dir>/access/oamsso
<LocationMatch "/oamsso/*">
Satisfy All
</LocationMatch>

4. Add JavaScript in Example 11-3 to invoke "delOblixCookie" upon loading the page body logout.html to invoke "delOblixCookie" upon loading the page body.

5. Proceed to "Configuring SSO Logout for OPSS with ADF-coded applications and OAM 10g Webgate".

11.10.2.2 Configuring SSO Logout for OPSS with ADF-coded applications and OAM 10g Webgate

Application configuration for logout depends on whether you have an ADF-coded application integrated with OPSS versus not integrated with OPSS. This topic focuses on ADF-coded applications that are integrated with OPSS.

The following procedure is similar to configuring logout for 10g WebGates, with a specific step for ADF-coded applications, which must send the end_url value to identify where to redirect the user after logout processing. However, with ADF-coded applications, logout occurs when the application causes the following URI to be invoked:

/<app context root>/adfAuthentication?logout=true&end_url=<any uri>

To configure OPSS for SSO Logout with OAM:

1. Locate and open the jps-config .xml file in the following path:

was_profile_dir/config/cells/cell_name/fmwconfig/jps-config.xml

2. Within jps-config .xml, add the following <propertySet name="props.auth.uri.0"> element and values:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<jpsConfig xmlns="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_
1.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_
1.xsd">
<property value="off" name="oracle.security.jps.jaas.mode"/>
<propertySets>
.
<propertySet name="props.auth.uri.0">
<property name="logout.url" value="/oamsso/logout.html"/>
<property name="login.url.BASIC" value="/${app.context}/adfAuthentication"/>
<property name="login.url.ANONYMOUS" value="/${app.context}/adfAuthentication"/>
<property name="login.url.FORM" value="/${app.context}/adfAuthentication"/>
</propertySet>
<propertySet name="props.auth.level.0">
<property value="0" name="type-level:ANONYMOUS"/>
<property value="1" name="type-level:BASIC"/>
<property value="2" name="type-level:FORM"/>
.
</propertySets>

3. Within jps-config .xml, add the following <serviceProviders> element and values:

...
</propertySets>
<serviceProviders>
<serviceProvider class="oracle.security.jps.internal.sso.SsoService
Provider" name="sso.provider.0" type="SSO"/>
</serviceProviders>

4. Within jps-config .xml, add the following <serviceInstances> element and values:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
...
</serviceProviders>
<serviceInstances>
.
.
<serviceInstance provider="sso.provider.0" name="sso.inst.0">
<property value="oracle.security.jps.wls.internal.sso.WlsToken
Provider" name="token.provider.class"/>
<property value="2" name="default.auth.level"/>
<property value="oracle.security.wls.oam.providers.sso.OAMSSO
ServiceProviderImpl" name="sso.provider.class"/>
<property value="OAMSSOToken" name="token.type"/>
<propertySetRef ref="props.auth.uri.0"/>
<propertySetRef ref="props.auth.level.0"/>
</serviceInstance>
.
.
</serviceInstances>

5. Within jpsContexts, add the highlighted <serviceInstanceRef ref="sso.inst.0"/> element and value:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
...
</serviceInstances>
<jpsContexts default="default">
<jpsContext name="default">
<serviceInstanceRef ref="credstore"/>
<serviceInstanceRef ref="keystore"/>
<serviceInstanceRef ref="policystore.xml"/>
<serviceInstanceRef ref="audit"/>
<serviceInstanceRef ref="idstore.ldap"/>
<serviceInstanceRef ref="sso.inst.0"/>
</jpsContext>
</jpsContexts>
</jpsConfig>

6. Proceed to "Configuring oamAuthenProvider.jar in the IBM WebSphere classpath".

11.10.2.3 Configuring oamAuthenProvider.jar in the IBM WebSphere classpath

To perform logout through OPSS, you must configure oamAuthnProvider.jar in the IBM WebSphere classpath. This is similar to adding the interceptor jar in the IBM WebSphere classpath in "Creating the Interceptor Entry in the IBM WebSphere Console".

The oamAuthnProvider.jar file is available from the following path:

MW_HOME/oracle_common/modules/oracle.oamprovider_11.1.1/
oamAuthnProvider.jar

To add oamAuthnProvider.jar to the IBM WebSphere classpath:

1. In the IBM WebSphere console go to Servers, Server Types, WebSphere Application, Servers, and select the appropriate server.

2. Under the Server Infrastructure section, click Java And Process Management, and then click Process Definition.

3. In Additional properties, select Java Virtual Machine, Custom Properties.

4. In the ws.ext.dirs property, add the value for oamAuthnProvider.jar after the entry for OAMTrustAssociationInterceptor.jar and confirm that the two values are separated by a colon. For example:

ws.ext.dir   MW_HOME/oracle_common/modules/oracle.oamprovider_11.1.1/
OAMTrustAssociationInterceptor.jar:MW_HOME/oracle_common/modules/
oracle.oamprovider_11.1.1/oamAuthnProvider.jar

5. Restart IBM WebSphere.

6. Proceed to "Verifying SSO Logout"

11.10.2.4 Verifying SSO Logout

To verify SSO logout:

1. From a browser, enter the URL of the protected resource. For example:

http://host:port/<app context root>/adfAuthentication

2. Confirm that the login page appears and sign in using proper credentials

3. Confirm that the protected resource is served

4. Open a new browser tab or window and access the same resource to confirm that the second attempt does not require another login

5. Logout from one tab using a URL like the following sample:

http://host:port/<app context root>/adfAuthentication?logout=true&end_url=<any
uri>

6. Access the resource again to confirm that a login page appears.

11.11 Configuring SSO Logout for Access Manager 11g

Logout is initiated when an application causes the invocation of the logout.html file configured for the OAM Agent (in this case, a 10g WebGate). The application might also pass end_url as a query string to logout.html. The end_url parameter could either be a URI or a URL.

See Also:

Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service

- About Centralized Logout Processing for 10g Webgate with OAM 11g Server

- Example 15-1: logout.html Script

- Configuring Centralized Logout for 10g Webgate with OAM 11g

Task overview: Configuring centralized logout for Oracle Access Manager 11g

1. Create a default logout page (logout.html) and make it available on the WebGate installation directory: For example, WebGate_install_dir/oamsso/logout.html.

2. In your logout.html, confirm that the logOutUrls parameter is configured for each resource WebGate and that <callBackUri> is the second value as part of 'logOutUrls'.

3. In your logout.html, confirm (from Step 1), confirm that the user is redirected to the central logout URI on the OAM Server, "/oam/server/logout'.

4. Optional: Allow the application to pass the end_url parameter indicating where to redirect the user after logout.

5. Check the OHS Web server configuration file, httpd.conf, on which the 10g WebGate is configured and if the following lines exist delete them.

<LocationMatch "/oamsso/*">
Satisfy any
</LocationMatch>

6. Proceed to "Configuring Centralized Logout for ADF-Coded Applications with OAM 11g", as needed for your deployment.

11.12 Known Issues

Problem:

Oracle Access Manager Identity Assertion Provider for IBM WebSphere does not support the Simple security mode.

Problem: Inconsistent

Oracle Access Manager Identity Assertion Provider for IBM WebSphere does not generate an LTPA token after successful authentication and valid ObSSOCookie generation.

Error
403: AuthenticationFailed

And the following error in the trace log:

com.ibm.websphere.security.WebTrustAssociationFailedException: Can not assert
user identity as LoggedIn user value is null

Solution

Refresh the browser 2 or 3 times. A valid LTPA token is generated.

For the server to communicate with a client in Simple transport security mode, a Master Secret Key is required. Sun JDK has an API that generates the Master Secret Key. However, IBM WebSphere contains the IBM JDK which does not have the API to generate the Master Secret Key.

A Fusion Middleware Control Page Reference

This appendix describes the features and options available on the Fusion Middleware Control pages that appear when you are managing an IBM WebSphere cell that was configured for Oracle Fusion Middleware.

This appendix contains the following sections:

- Section A.1, "Understanding the Information on the IBM WebSphere Cell Home Page"

- Section A.2, "Understanding the Information on the WebSphere Application Server Home Page"

- Section A.3, "Understanding the Information on the IBM WebSphere Application Deployment Home Page"

A.1 Understanding the Information on the IBM WebSphere Cell Home Page

The Cell home page is divided into the following regions:

- Summary Region of the Cell Home Page

- Deployments Region of the Cell Home Page

- Servers Region of the Cell Home Page

- Clusters Region of the Cell Home Page

Summary Region of the Cell Home Page

The Summary region of the Cell home page provides general information about the cell, as well as a link to the IBM WebSphere Administrative Console, which you can use to manage the cell.

Table A-1 describes the fields available in the General section of the Summary region.

Table A-1 Fields Available in the General Section of the Summary Region

Element

Description

Cell Name

The name given to the cell when the cell was configured with the Oracle Fusion Middleware Configuration Wizard.

Version

The version of IBM WebSphere that was used to configure the Cell.

Note that this version number can also identify which set of patches have been applied to the IBM WebSphere installation.

Administrative Console Port

The non-secure port used to access the IBM WebSphere Administrative Console. Specifically, this is the port identified by WC_Adminhost_port in the following URL:

http://hostname:WC_Adminhost_port/ibm/console

Administrative Console Secure Port

The secure port used to access the IBM WebSphere Administrative Console. Specifically, this is the port identified by WC_Adminhost_secure port in the following URL:

https://hostname:WC_Adminhost_secure_port/ibm/console

SOAP Connector Port

The port used for communications with the administrative server via the Simple Object Access Protocol (SOAP).

Bootstrap Port

This is the value of the bootstrap port for the administrative server. This port is required when you are installing the IBM WebSphere Application Client software and when using utilities such as the IBM WebSphere dumpNameSpace tool.

Deployment Mode

The deployment mode of the IBM WebSphere software.

For example, this field indicates whether this is an IBM WebSphere Application Server - Network Deployment installation or an IBM WebSphere Application Server deployment.

Deployments Region of the Cell Home Page

This region lists the applications that have been deployed to the servers in the cell. Each application deployment is listed, as well as the deployment name, status, and target servers where the deployment is running.

Click the name of an application deployment to display the WebSphere Application Deployment home page, which provides more information about each application deployment.

The chart identifies the percentage of deployments that are currently up and running, as opposed to those that are down or not available.

Internal applications are those that are required by Oracle Fusion Middleware. The internal applications are deployed automatically and are required by the Oracle Fusion Middleware products you installed and configured in the cell.

Servers Region of the Cell Home Page

This region lists the servers in the cell. The chart identifies the percentage of servers that are up and running, as opposed to those that are down or not available.

For each server, the region lists the server name, status, and--if it resides in a cluster--the name of the cluster.

Clusters Region of the Cell Home Page

This region lists the clusters currently configured in the cell. For each cluster, it provides the cluster name, status, and a list of the servers in the cluster.

A.2 Understanding the Information on the WebSphere Application Server Home Page

The WebSphere Application Server home page is divided into the following regions:

- Summary Region of the WebSphere Application Server Home Page

- Deployments Region of the WebSphere Application Server Home Page

Summary Region of the WebSphere Application Server Home Page

The Summary region of the WebSphere Application Server home page provides general information about the server, as well as a link to the IBM WebSphere Administrative Console, which you can use to manage the server.

Table A-2 describes the fields available in the General section of the Summary region.

Table A-2 Fields Available in the General Section of the Summary Region of the Applicatin Server Page

Element

Description

Cell Name

The name given to the cell when the cell was configured with the Oracle Fusion Middleware Configuration Wizard.

Node Name

The name of the node that contains this server.

Version

The version of IBM WebSphere that was used to configure the Cell.

Note that this version number can also identify which set of patches have been applied to the IBM WebSphere installation.

WebSphere Home

The full path of the directory where the current IBM WebSphere software was installed and configured.

Host

The fully-qualified name of the host where the server is currently running.

Deployments Region of the WebSphere Application Server Home Page

This region lists the applications that have been deployed to the server. Each application deployment is listed, including the deployment name and status.

Click the name of an application deployment to display the WebSphere Application Deployment home page, which provides more information about each application deployment.

The chart identifies the percentage of deployments that are currently up and running, as opposed to those that are down or not available.

Internal applications are those that are required by Oracle Fusion Middleware. The internal applications are deployed automatically and are required by the Oracle Fusion Middleware products you installed and configured in the cell.

A.3 Understanding the Information on the IBM WebSphere Application Deployment Home Page

The Application Deployment page is divided into the following sections:

- Summary Region on the IBM WebSphere Application Deployment Page

Summary Region on the IBM WebSphere Application Deployment Page

The Summary region of the WebSphere Application Deployment home page provides general information about the application, as well as a link to the IBM WebSphere Administrative Console, which you can use to manage the application.

Table A-3 describes the fields available in the General section of the Summary region.

Table A-3 Fields Available in the General Section of the Summary Region of the Application Deployment Page

Element

Description

Application Type

The type of application. For example, this field indicates whether the application was deployed as an enterprise archive (EAR) or other archive type.

Cell Name

The name given to the cell when the cell was configured with the Oracle Fusion Middleware Configuration Wizard.

Node Name

The name of the node that contains the server where the application was deployed.

Deployed On

The name of the server where this instance of the application is deployed.

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.