5 Managing Oracle WebCenter Portal on IBM WebSphere

This chapter contains information about installing, building, and managing Oracle WebCenter Portal applications and components on IBM WebSphere.

This chapter contains the following sections:

5.1 Overview - Roadmaps

The roadmaps in this section provide an overview of the steps required to install and configure WebCenter Portal on IBM WebSphere and point you to more detailed documentation. The steps required depend on whether you want to use WebCenter Portal: Spaces or build your own WebCenter Portal applications using WebCenter Portal: Framework. For details, see:

Click the flow charts for more information on how to complete each step.

5.1.1 Getting the Spaces Application Up and Running on IBM WebSphere

Figure 5-1 illustrates the installation and configuration process for WebCenter Portal: Spaces in a simple, non-clustered environment.

Figure 5-1 Getting the Spaces Application Up and Running on IBM WebSphere

Getting Spaces up and running on IBM WebSphere Perform pre-install tasks for Oracle WebCenter Portal Verify system requirements Install and configure a database Create Schemas Install IBM WebSphere Application Server and create Middleware Home Install WebCenter Portal Download WebCenter Portal software Install WebCenter Portal products Install other Fusion Middleware products as required Install Oracle WebCenter Content (Content Server) Install Oracle SOA Suite (BPEL Server) Install IBM HTTP Server (IHS) Configure WebSphere cell for WebCenter Portal Start Configuration Wizard Create new cell or extend an existing cell Select required WebCenter Portal products Configure JDBC component schemas Perform post-install tasks for Oracle WebCenter Portal Set JDBC driver variables (DB2 only) Start the node and deployment manager Open WebSphere admin console Start WebCenter Portal servers Install and configure security components Install and configure OID as external LDAP ID store Configure Spaces admin user Reassociate credential and policy stores Set cookie paths for Spaces application modules Verify the installation Configure single sign-in (SS0) Configure SSL Configure trust service for REST Configure user registry settings Configure pagelet producer admin user Configure discussions admin user Extend cell for WebCenter Content (Content Server) Set up Content Server for WebCenter Portal Install and configure inbound refinery Configure dynamic converter Configure IHS for single sign-on Connect the Spaces application to Content Server Include context root in connection configuration Configure, and connect backend components for WebCenter Portal services Connect to analytics collector Connect to BPEL server Connect to discussion server Configure Spaces workflows Register portlet producers Register pagelet producer Connect to presence server Configure SES search Configure personalization Connect to mail server Connect to events server

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 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 the Spaces Application Up and Running on IBM WebSphere - Simple Topology

Task and link to more information Mandatory or Optional? Notes

Verify system requirements

Mandatory

  

Install and configure a database

Mandatory

  

Create schemas for the Spaces application

Mandatory

  

Install IBM WebSphere Application Server and create Middleware Home

Mandatory

  

Install Oracle WebCenter Portal

Mandatory

  

Install other products as required:

Optional

Oracle WebCenter Content is mandatory for content presenter, wikis and blogs, and recommended for the Documents service and the Spaces application.

SOA is mandatory for the Worklist service and Spaces 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: Spaces

Mandatory

  

Perform general post-install tasks for WebCenter Portal:

Mandatory

  

Install and configure mandatory security components:

Mandatory

An external LDAP server is mandatory on IBM WebSphere.

All WebCenter Portal applications require an Oracle Internet Directory LDAP server.

Configure optional security components:

Optional

  

Extend cell for Oracle WebCenter Content Server:

Mandatory

Mandatory for content presenter, wikis and blogs, and recommended for the Documents service.

Install and configure back-end components for WebCenter Portal services:

Optional

Mandatory for the WebCenter Portal services you want to use

5.1.2 Creating a WebSphere Cell for Framework Application Deployments

Figure 5-2 illustrates the installation and configuration process if you want to build your own WebCenter Portal applications (referred to as 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 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 Framework Application Deployments

Creating a WebSphere Cell for Framework Applications Perform pre-install tasks for Oracle WebCenter Portal Verify system requirements Install and configure a database Create schemas Install IBM WebSphere Application Server and create Middleware Home Install WebCenter Portal Download WebCenter Portal software Install WebCenter Portal products Install Oracle WebCenter Content (Content Server) Install Oracle SOA Suite (BPEL Server) Install IBM HTTP Server (IHS) Configure WebSphere cell for WebCenter Portal Start Configuration Wizard Create new cell or extend an existing cell Create custom portal server for Framework applications Create custom server for Portlet Producer applications Configure JDBC component schemas Perform post-install tasks for Oracle WebCenter Portal Set JDBC driver variables (DB2 only) Start the node and deployment manager Open WebSphere admin console Start WebCenter Portal servers Install and configure security components Install and configure OID as external LDAP ID store Reassociate credential and policy stores Verify the installation Configure single sign-in (SS0) Configure SSL Configure trust service for REST Configure user registry settings Configure pagelet producer admin user Configure discussions admin user Extend cell for WebCenter Content (Content Server) Set up Content Server for WebCenter Portal Install and configure inbound refinery Configure dynamic converter Configure IHS for single sign-on Connect application to Content Server Include context root in connection configuration Configure, and connect backend components for WebCenter Portal services Connect to analytics collector Connect to BPEL server Connect to discussion server Connect to mail server Register portlet producers Register pagelet producer Use JDeveloper to build and deploy applications using WebCenter Portal: Framework Connect to presence server Configure SES search Configure personalization Connect to events server

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 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 Framework Application Deployments - Simple Topology

Task and link to more information Mandatory or Optional? Notes

Verify system requirements

Mandatory

  

Install and configure a database

Mandatory

  

Create schemas for Framework applications

Mandatory

  

Install IBM WebSphere Application Server and create Middleware Home

Mandatory

  

Install Oracle WebCenter Portal

Mandatory

  

Install other products as required:

Optional

Oracle WebCenter Content is mandatory for content presenter, wikis and blogs, and the Documents service.

SOA is mandatory for the Worklist service and Spaces 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

Oracle does not recommend deploying WebCenter Portal applications or WebCenter Portal 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:

Mandatory

  

Install and configure mandatory security components:

Mandatory

An external LDAP server is mandatory on IBM WebSphere.

All WebCenter Portal applications require an Oracle Internet Directory LDAP server.

Configure optional security components:

Optional

  

Extend cell for Oracle WebCenter Content Server:

Optional

Mandatory for content presenter, wikis and blogs, and the Documents service.

Configure, and connect back-end components for WebCenter Portal:

    

Use JDeveloper to build and deploy applications using WebCenter Portal: Framework

    

5.2 Differences Installing and Configuring WebCenter Portal on IBM WebSphere

This section describe differences between installing and configuring WebCenter Portal install on WebLogic Server and IBM WebSphere:

5.2.1 Installing WebCenter Portal Products on IBM WebSphere

Use the WebCenter Portal installer to install the binaries for all WebCenter Portal products on IBM WebSphere. The instructions are similar to those provided for Oracle WebLogic Server in "Installing Oracle WebCenter Portal" 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 the Spaces Application

To configure an IBM WebSphere cell for the Spaces application:

  1. Start the IBM WebSphere version of Oracle Fusion Middleware Configuration Wizard:

    WC_ORACLE_HOME/common/bin/was_config.sh

    For details, see "Using the Configuration Wizard" in the Oracle Fusion Middleware Configuration Guide for IBM WebSphere Application Server.

  2. On the Select Domain Source screen, select Oracle WebCenter Spaces and any other WebCenter Portal products you want to install, such as the Discussions Server, Portlet Producers, Analytics Collector, and so on.

    For details, see "Selecting Oracle WebCenter Portal Products for Configuration" in the Oracle Fusion Middleware Installation Guide for Oracle WebCenter Portal.

5.2.3 Configuring an IBM WebSphere Cell for Framework Applications

If you want to deploy applications built using WebCenter Portal: Framework to an IBM WebSphere application server you must configure a suitable server using 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 Spaces application.

  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: WC_ORACLE_HOME/common/bin/was_config.sh.

    For details, see "Using the Configuration Wizard" in the 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:

      WC_ORACLE_HOME/common/templates/was/oracle.wc_custom_portal_template_11.1.1.jar

    • On Windows operating systems, the template is available here:

      WC_ORACLE_HOME\common\templates\was\oracle.wc_custom_portal_template_11.1.1.jar

    For details, see "Creating a Custom Managed Server for Framework Applications" in the 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 WebCenter Portal: Framework to an IBM WebSphere application server you must configure a suitable server using 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 Spaces application.

  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:

    WC_ORACLE_HOME/common/bin/was_config.sh

    For details, see "Using the Configuration Wizard" in the 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:

      WC_ORACLE_HOME/common/templates/was/oracle.wc_custom_services_producer_template_11.1.1.jar

    • On Windows operating systems, the template is available here:

      WC_ORACLE_HOME\common\templates\was\oracle.wc_custom_services_producer_template_11.1.1.jar

    For details, see "Creating a Custom Managed Server for Portlet Producer Applications" in the Oracle Fusion Middleware Installation Guide for Oracle WebCenter Portal.

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

This section includes the following subsections:

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

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 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 WebCenter Portal 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.8, "Task 8: 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 WebCenter Portal servers using the IBM WebSphere Administrative Console or Fusion Middleware Control. For details, see Section 2.8, "Task 8: Start the IBM WebSphere Servers".

The default names for WebCenter Portal servers in a WebCenter Portal:Spaces installation are:

  • WC_Spaces

  • WC_Collaboration

  • WC_Portlet

  • WC_Utilities

The default names for WebCenter Portal servers for Framework applications and portlet producer deployments are:

  • WC_CustomPortal (Framework applications)

  • WC_CustomServicesProducer (Portlet producer applications)

5.2.6 Installing External LDAP ID Store for WebCenter Portal Applications

An LDAP server is not automatically installed and configured when you install Oracle WebCenter Portal products on IBM WebSphere. Before you can configure WebCenter Portal, you must install and configure Oracle Internet Directory (OID) as the external LDAP ID store for your WebCenter Portal applications. For instructions on how to set up external LDAP ID stores, such as Oracle Internet Directory, see Section 8.1, "IBM WebSphere Identity Stores".

Note:

All WebCenter Portal applications, including Spaces, 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 the Spaces Application

After installing Oracle WebCenter Portal products on IBM WebSphere and setting up your LDAP ID store, you must manually grant the Spaces 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 "Granting the Spaces Administrator Role" in Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter Portal.

Note:

Oracle Fusion Middleware Administrator's Guide for 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 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 WebCenter 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 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 WebCenter Portal products on IBM WebSphere Application Server - Network Deployment (ND), you must reassociate your policy store with an external LDAP (either Oracle Internet Directory 11gR1 or 10.1.4.3), or a database. Note that when using an external LDAP-based store, the credential store and policy store must be configured to use the same LDAP server. For detailed steps see "Configuring the Policy and Credential Store" in Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter Portal.

5.2.11 Setting Cookie Paths for WebCenter Portal 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 the Spaces application (/webcenter), access Enterprise Manager (/em), and then move back to Spaces (/webcenter) you are prompted to log in to Spaces 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 following the steps below.

  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 Spaces application is webcenter.

  4. Click Manage Modules (Figure 5-3).

    Figure 5-3 Enterprise Applications - Manage Modules

    Manage Modules screenshot

    A list of modules displays (Figure 5-4).

    Figure 5-4 List of Modules to Manage

    List of modules for Spaces

  5. Set the cookie path for each module listed in Table 5-3:

    Table 5-3 Cookie Paths for 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 (Spaces Application).

    2. Click Session Management (Figure 5-5).

      Figure 5-5 Configure Module

      Configure Module screenshot

    3. Select the Enable cookies check box (Figure 5-6).

      Figure 5-6 Configure Module - Enable Cookies

      Enable cookies for a module

    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

      Set cookie path for a module

    6. Click OK and then Save.

    7. Select the Override session management check box, and then click OK.

    8. Repeat steps a through f for each module listed in Table 5-3.

  6. Restart the server on which the Spaces 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

      Set Cookie Path for a Module

5.2.12 Verifying the 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 WebCenter Portal's Spaces application:

    http://WC_Spaces_server_host:WC_Spaces_server_port/webcenter

    The default port number for the Spaces application is 8888.

  • To access 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 Oracle WebCenter Analytics Collector, Oracle WebCenter Activity Graph Engines and Oracle WebCenter Personalization:

    http://WC_Utilities_server_host:WC_Utilities_server_port/activitygraph-engines

    To access Oracle WebCenter Activity Graph Engines:

    http://WC_Utilities_server_host:Wc_Utilities_server_port/activitygraph-engines/Login.jsp

    To access Oracle WebCenter Personalization:

    http://WC_Utilities_server_host:Wc_Utilities_server_port/wcps/api/property/resourceIndex

    The default port number for Oracle WebCenter Analytics Collector, Oracle WebCenter Activity Graph Engines and Oracle WebCenter Personalization is 8891.

  • To access WebCenter OmniPortlet and Web Clipping Portlets:

    http://WC_Portlet_server_host:WC_Portlet_server_port/portalTools/

    The default port number for WebCenter Portlets is 8889.

  • To access Oracle WebCenter Portal's Discussion 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 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 the WebCenter Portal 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

    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

Configuring trust information screenshot

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 applications (Spaces and Framework applications) and also for high availability environments. For more information about using the IBM HTTP Server, see:

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

      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

      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

      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

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

    2. Click Generate Plug-in (Figure 5-15).

      Figure 5-15 Configure HTTP Server - Generate Plug-in

      Configure HTTP Server - Generate Plug-in

    3. Click Propagate Plug-in (Figure 5-16).

      Figure 5-16 Configure HTTP Server - Propagate Plug-in

      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

    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

HTTP Server Port - Application Accessible

5.2.16 Configuring Single Sign-On for WebCenter Portal Applications

This section includes the following sub sections:

5.2.16.1 Configuring OAM 11g Single Sign-On

This section describes how to set up single sign-on for WebCenter Portal installations on IBM WebSphere, using Oracle Access Manager (OAM) 11g (Figure 5-19).

Note:

WebCenter Portal 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 WebCenter Portal Installations on IBM WebSphere

Configuring OAM SSO for WebCenter Portal on 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 9, "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 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 applications to require certificate based authentication

  • Configure other WebCenter Portal components for single sign-on

To set up single sign-on for WebCenter Portal applications, using OAM 11g:

  1. Install Oracle Access Manager 11g.

    See Chapter 9, "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:

      WC_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 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 9.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 9.10.2.2, "Configuring OPSS for SSO Logout with Oracle Access Manager" 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 9.10.2.3, "Configuring oamAuthenProvider.jar in the IBM WebSphere classpath". Do this for all servers in the install.

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

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

    5. Restart WebTier and all the servers, including the Node Manager in WebSphere.

  8. Configure WebCenter Portal applications to require certificate based authentication.

    For detailed steps, see Section 5.2.16.2, "Configuring WebCenter Portal Applications for Single Sign-On".

  9. Configure other WebCenter Portal components for single sign-on:

    • WebCenter Portal: SpacesDiscussions serverWorklist serviceRSS news feed serviceEnterprise ManagerSecure Enterprise SearchContent Server

    For details steps, see "Additional Single Sign-on Configurations" in Oracle Fusion Middleware Administrator's Guide for 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 Applications for Single Sign-On

If you want Spaces or any other application built using WebCenter Portal: Framework, to participate in single sign-on, you must specify CLIENT-CERT as the authentication method for Trust Access Interceptors. By default, all WebCenter Portal 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 any WebCenter Portal application to participate in single sign-on.

Follow these steps to change authentication method for WebCenter Portal applications:

  1. Locate web.xml for the WebCenter Portal application.

    • For the Spaces application, 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 WebCenter Portal 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. 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 the WebCenter Portal application, and then click Update.

      To update web.xml for the Spaces application, 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 Spaces application, enter: spaces-was.war/WEB-INF/web.xml

      For a 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 the Spaces application, navigate to: WebSphere enterprise Applications > webcenter > Manage Modules > spaces-was.war > View Deployment Descriptor

  5. Restart the WebCenter Portal application.

  6. Access the WebCenter 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: Spaces install:

    • Spaces 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 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 subsections:

5.2.17.1 Obtaining the SSL Port for WebCenter Portal 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 your WebCenter Portal application is deployed. Select Application servers> <cell name>

    For the Space application, 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 the Space application, for example, https://myhost.com:8788/webcenter

    Figure 5-20 Port Information for WC_Spaces

    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

    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

    Importing 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

    Specifying the 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 WebCenter Portal Installations on IBM WebSphere

Use the IBM WebSphere Administrative Console to clone 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 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 WebCenter Portal 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 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 WebCenter Portal Cluster Topology

Figure 5-24 shows a typical cluster set up for a Spaces application deployment.

Figure 5-24 WebCenter Portal Cluster Topology - Spaces Application

Cluster Topology - Spaces

Figure 5-25 shows a typical cluster set up for applications built using WebCenter Portal: Framework, that is, Framework applications and Portlet Producer applications.

Figure 5-25 WebCenter Portal Cluster Topology - Framework and Portlet Producer Applications

Cluster Topology - Framework and Portlet Producers

5.2.19.2 Install Required 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 WebCenter Portal Products on IBM WebSphere".

5.2.19.3 Configure a New WebSphere Cell on WCPHOST1

On the first WebCenter Portal host (WCPHOST1), create a new WebSphere cell:

  1. Launch the Configuration Wizard using:

    WC_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 WebCenter Portal products and configure JDBC schemas, as required.

    For details, see "Using the Configuration Wizard" in the 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 WebCenter Portal machine (WCPHOST2), is not yet federated to the cell on WCPHOST1, perform the following steps:

  1. Launch the Configuration Wizard using:

    WC_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 8.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:

    WC_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 WebCenter Portal Applications on IBM WebSphere

The following sections describe differences and restrictions when developing and deploying WebCenter Portal applications on IBM WebSphere:

5.3.1 Configuring a WebSphere Application Server Connection in JDeveloper

If you want to deploy a WebCenter Portal 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, see Section 4.2.4, "Creating an Application Server Connection" and "Connecting and Deploying Java EE Applications to Application Servers" in Oracle Fusion Middleware User's Guide for Oracle JDeveloper.

5.3.2 Deploying WebCenter Portal Applications on IBM WebSphere Directly from JDeveloper

Deploying WebCenter Portal applications directly from Oracle JDeveloper to IBM WebSphere Server is largely the same as described in Oracle Fusion Middleware Developer's Guide for Oracle WebCenter Portal.

The differences are as follows:

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 WebCenter Portal 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 "Setting Up a Database Connection" in Oracle Fusion Middleware Developer's Guide for Oracle WebCenter Portal.

  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

    Connection Name - WebCenter/CustomPortal

    Figure 5-27 Associate webcenter/CustomPortal Connection to WebCenterDS

    Associate to Data Source Dialog - 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

    Connection Name - Activities/CustomPortal

    Figure 5-29 Associate activities/CustomPortal Connection to ActivitiesDS

    Associate to Data Source Dialog - ActivitiesDS

The database connections appear in the navigator as follows:

Figure 5-30 Application Navigator - Database Connections to Seeded Data Sources

Database Connections to Seeded Data Sources

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

Oracle recommends that WebCenter Portal applications built using WebCenter Portal: Framework 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 WebCenter Portal 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 "Setting Up a Database Connection" in Oracle Fusion Middleware Developer's Guide for Oracle WebCenter Portal.

  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

    Connection Name - WebCenter/CustomPortal

    Figure 5-32 Associate MyWebCenter Connection to WebCenterDS

    Associate to Data Source Dialog - 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

    Connection Name - Activities/CustomPortal

    Figure 5-34 Associate MyActivities Connection to ActivitiesDS

    Associate to Data Source Dialog - ActivitiesDS

The database connections appear in the navigator as follows:

Figure 5-35 Application Navigator - Database Connections to Data Sources

Database Connections to Seeded Data Sources

5.3.2.3 Creating Database Connections to Custom Data Sources

Custom data sources are not automatically created when you deploy WebCenter Portal applications built using WebCenter Portal: Framework 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 "Setting Up a Database Connection" in Oracle Fusion Middleware Developer's Guide for Oracle WebCenter Portal.

  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

    Connection Name - WebCenter/CustomPortal

    Figure 5-37 Associate Custom Database Connection to WebCenterDS

    Associate to Data Source Dialog - 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 List service.

    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

    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

    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

    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.6, "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

    Configure Credentials for Secure Database Access

  4. Configure a JBDC provider (Figure 5-42).

    Figure 5-42 Configure a JBDC Provider

    Configure a JBDC Provider

    Figure 5-43 Create and Save the JBDC Provider

    Create 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

    Create the JBDC Provider

  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

      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

      Configure the Data Source

    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

      Configure the Data Source

  8. Click Next. Confirm the changes and click Finish (Figure 5-48).

    Figure 5-48 Save Data Source Configuration

    Configure the Data Source

  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 WebCenter Portal Applications Using SSL

When you deploy WebCenter Portal 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 WebCenter Portal Applications From JDeveloper

Applications do not start automatically after deployment or redeployment from JDeveloper. You have to start the WebCenter Portal application manually using IBM WebSphere Administrative Console or wsadmin commands. For details, see Deploying WebCenter Portal Application EARs using WebSphere Admin Console and Deploying WebCenter Portal Application EARs using wsadmin Commands.

5.3.3 Targeting Application EAR and WAR Files for IBM WebSphere Deployment

If you want to deploy WebCenter Portal 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 "Creating a WAR Deployment Profile" and "Creating an Application-level EAR Deployment Profile" in Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.

Figure 5-49 Configure WebSphere Targeted EAR and WAR Deployment Profiles

Surrounding text describes Figure 5-49 .

5.3.4 Deploying WebCenter Portal Application EARs using WebSphere Console and wsadmin

If your WebCenter Portal 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:

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 "Deploying WebCenter Portal: Framework Applications" in Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter Portal.

5.3.4.2 Deploying WebCenter Portal Application EARs using WebSphere Admin Console

To deploy a WebCenter Portal 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 WebCenter Portal Application EAR Location

    Enter the location of your application EAR

  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 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 WebCenter Portal Application EAR Installation

    Saving WebCenter Portal Application EAR Installation

  9. Select the name of your newly installed application, and click Start (Figure 5-52).

    Figure 5-52 Starting the WebCenter Portal Application

    Starting the WebCenter Portal Application

Your application is now available.

5.3.4.3 Deploying WebCenter Portal 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 WebCenter Portal 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

    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 WebCenter Portal 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 Framework Application Connection to IMAP and SMTP with SSL

The steps to secure an IMAP/ SMTP connection with SSL for a 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 the steps "Securing a WebCenter Portal Application's Connection to IMAP and SMTP with SSL" in Oracle Fusion Middleware Administrator's Guide for 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 Framework application.

  4. Log into the application and provide your mail credentials.

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

During its life cycle, a typical portal is deployed to testing, staging, and production servers. WebCenter Portal provides configurable scripts (create_profile_was.csh and deploy_and_config_was.csh) that allow you to easily deploy and configure 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 Framework application deployed on WebLogic Server throughout its life cycle is described in detail in "Understanding the WebCenter Portal Life Cycle" in Oracle Fusion Middleware Developer's Guide for Oracle WebCenter Portal. 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 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 WC_ORACLE_HOME/webcenter/scripts/stage2prod, where WC_ORACLE_HOME is the directory where WebCenter 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 WC_HOME <webcenter_home>
setenv SCRIPTS_DIR <scripts_home>

    WC_HOME is the WebCenter Home and SCRIPTS_DIR is where the scripts are located. By default, the scripts are here: $WC_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 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 Framework application 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 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. Therefore, 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 WebCenter Portal Components on IBM WebSphere

This section includes the following sub sections

5.4.1 Running WebCenter Portal wsadmin Commands

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

Run WebCenter Portal wsadmin commands from the /common/bin directory of the Oracle WebCenter Portal home:

(UNIX) WC_ORACLE_HOME/common/bin/wsadmin.sh
(Windows) WC_ORACLE_HOME\common\bin\wsadmin.bat

To invoke online help for 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 WebCenter Portal WLST commands, see Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

5.4.2 Managing WebCenter Portal Applications With Fusion Middleware Control

You can start, stop, or restart a WebCenter Portal cell and manage WebCenter Portal 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 the Spaces Application (Figure 5-54)

    • Related Components section - you cannot navigate directly to the Spaces application.

    • Related Components section - a link to the WebSphere Cell on which the Spaces application is deployed displays instead of a WebLogic Server link.

  • Home Page for Framework Applications - You cannot navigate to the IBM WebSphere Administrative Console.

Figure 5-54 Fusion Middleware Control Home Page for Spaces Deployment on IBM WebSphere

FMW Control home page for Spaces deployment on WebSphere

5.5 Restrictions Using WebCenter Portal on WebSphere

This section describes WebCenter Portal features that are not supported on WebSphere. It contains the following sections:

5.5.1 Oracle WebCenter Adapter for SharePoint Not Supported on WebSphere

You cannot connect WebCenter Portal application deployments on IBM WebSphere to Microsoft Sharepoint repositories.

5.5.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.6.0).

5.5.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.6 Troubleshooting WebCenter Portal on WebSphere

Use the information in this section to help troubleshoot issues with WebCenter Portal on WebSphere. It contains the following sections:

5.6.1 Diagnosing java.lang.RuntimeException or java.lang.NullPointerException

If you attempt to access a WebCenter Portal 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 Applications".

5.6.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.6.3 Session Timeouts in Spaces Applications

Two different settings drive the session timeout in a Spaces application:

  • Global timeout (LTPA timeout property)

  • Application timeout (wcSessionTimeoutPeriod attribute in webcenter-config.xml)

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 setting in webcenter-config.xml so that users automatically navigate to the Spaces session timeout page.

To set the LTPA timeout:

  1. Determine the current value of wcSessionTimeoutPeriod.

    To find out how to export the latest webcenter-config.xml from MDS, see "Setting a Session Timeout for the Spaces Application" in Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter Portal.

  2. Log in to the IBM Administrative Console.

  3. Navigate to: Security> Global Security> LTPA

  4. Set LTPA timeout (Figure 5-55).

    Figure 5-55 LTPA Timeout

    LTPA Timeout Setting

  5. Restart the servers.

5.6.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 your WebCenter Portal 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 your Spaces application is using space membership workflows and these workflows are deployed on a SOA server that is in the same cell as WebCenter Portal: Spaces, 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 Application Modules Post Deployment".

5.6.5 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.6.6 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 WebCenter Portal wsadmin Commands".

5.6.7 Unable to Deploy Spaces Workflows when the SOA MDS schema is Running on DB2

The composite that manages Spaces 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-56):

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-56 scs_CommunityWorkflows Fails to Deploy

scs_CommunityWorkflows Fails to Deploy

If you want to use the Spaces 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.