Oracle® Fusion Middleware Third-Party Application Server Guide 11g Release 1 (11.1.1.6) Part Number E17852-02 |
|
|
PDF · Mobi · ePub |
This chapter contains information about installing, building, and managing Oracle WebCenter Portal applications and components on IBM WebSphere.
This chapter contains the following sections:
Differences Installing and Configuring WebCenter Portal on IBM WebSphere
Differences Developing and Deploying WebCenter Portal Applications on IBM WebSphere
Differences Managing WebCenter Portal Components on IBM WebSphere
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:
Getting the Spaces Application Up and Running on IBM WebSphere
Creating a WebSphere Cell for Framework Application Deployments
Click the flow charts for more information on how to complete each step.
Figure 5-1 illustrates the installation and configuration process for WebCenter Portal: Spaces 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-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 |
---|---|---|
Mandatory |
||
Mandatory |
||
Mandatory |
||
Install IBM WebSphere Application Server and create Middleware Home |
Mandatory |
|
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. |
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 |
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.
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 |
---|---|---|
Mandatory |
||
Mandatory |
||
Mandatory |
||
Install IBM WebSphere Application Server and create Middleware Home |
Mandatory |
|
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 |
This section describe differences between installing and configuring WebCenter Portal install on WebLogic Server and IBM WebSphere:
Configuring an IBM WebSphere Cell for the Spaces Application
Configuring an IBM WebSphere Cell for Framework Applications
Configuring an IBM WebSphere Cell for Portlet Producer Applications
Performing General Post-install Tasks for WebCenter Portal on WebSphere
Installing and configuring mandatory security components:
Optional security configuration:
Configuring WebCenter Portal Applications for High Availability 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".
To configure an IBM WebSphere cell for the Spaces application:
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.
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.
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.Set the JVM_ARG environment variable:
setenv CONFIG_JVM_ARGS -DTemplateCatalog.enable.selectable.all=true
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.
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.
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.Set the JVM_ARG environment variable:
setenv CONFIG_JVM_ARGS -DTemplateCatalog.enable.selectable.all=true
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.
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.
This section includes the following subsections:
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:
Log in to the IBM WebSphere Administrative Console:
https://host:port/ibm/console
Navigate to Environment > WebSphere variables
Set DB2 driver variables for the server node:
From the Scope drop down, select the node containing your WebCenter Portal installation.
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.
Save both settings.
If you are using a cluster, repeat step 3 for each node in the cluster.
To test the DB2 connection:
Navigate to Resources > JDBC >Data sources.
Select a data source in the table, and click Test Conection.
If you are deploying your own WebCenter Portal applications to IBM WebSphere, repeat step 3 at the Deployment Manager scope.
From the Scope drop down, select the Node=ManagerNode, Server=dmgr scope where ManagedNode maps to the Manage Node of your installation.
Create and set JBDC variables, as above:
DB2_JCC_DRIVER_NATIVEPATH
DB2_JCC_DRIVER_PATH
Save both settings.
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.
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".
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)
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".
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"/>
Modify jps-config.xml
using a text editor:
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.
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>
Restart all the servers.
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".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.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:
Log in to the IBM WebSphere Administrative Console.
Navigate to Applications > Application Types > WebSphere enterprise applications.
Configure an administrative user for the Pagelet Producer admin application:
Select pageletproducer.
Click Security role to user/group mapping.
Select the EnsembleAdmin role and the click either Map Users... or Map Groups... to assign one or more users/groups to this admin role.
Click OK.
Configure administrative user for the Activity Graph Engine application:
Select activitygraph-engines_11.1.1.6.0.
Click Security role to user/group mapping.
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.
Click OK.
Restart WC_Portlet (pageletproducer) and WC_Utilities (activitygraph-engines), as required.
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.
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.
Log in to the IBM WebSphere Administrative Console.
https://host:port/ibm/console
Navigate to Applications > WebSphere enterprise applications.
Select the name of your application from the list.
For example, the name of the Spaces application is webcenter
.
Click Manage Modules (Figure 5-3).
A list of modules displays (Figure 5-4).
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 |
Click the module name, for example spaces-was.war (Spaces Application).
Click Session Management (Figure 5-5).
Select the Enable cookies check box (Figure 5-6).
Click Enable cookies link.
Enter the appropriate cookie path for the selected module (Figure 5-7). For details, see Table 5-3.
Click OK and then Save.
Select the Override session management check box, and then click OK.
Repeat steps a through f for each module listed in Table 5-3.
Restart the server on which the Spaces application is deployed.
Navigate to Servers > WebSphere Application servers.
Select the WC_Spaces check box, and click Restart (Figure 5-8).
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.
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:
Log in to the IBM WebSphere Administrative Console.
Navigate to Global security > Standalone LDAP registry.
Under Additional properties, click Advanced Lightweight Directory Access Protocol (LDAP) user registry settings.
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
Select the Perform a nested group search check box.
Click OK.
Modify jps-config.xml
using a text editor:
Open the MW_HOME/user_projects/domains/my_domain/config/fmwconfig/jps-config.xml
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>
Restart all the servers.
This section describes how to configure an identity asserter for the REST service.
Login to the IBM WebSphere Administrative Console.
Navigate to Security > Global Security.
In the Authentication section, expand Web and SIP security, and then click Trust Association.
Select the Enable trust association check box and save the changes.
In the Additional Properties section, click Interceptors.
Click New.
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.
Save the changes (Figure 5-10).
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:
Section 5.2.16, "Configuring Single Sign-On for WebCenter Portal Applications"
Section 5.2.19, "Configuring WebCenter Portal Applications for High Availability on IBM WebSphere"
To install and configure an IBM HTTP Server:
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".
Configure the HTTP Server, specifying the server name and port you specified in step 1.
Log in to the IBM WebSphere Administrative Console.
Navigate to Servers >Web Servers > New.
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.
Click Next
Enter the port that you defined during HTTP server installation. For example 8080 (Figure 5-12).
Click Next and Finish.
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
.
In the WebSphere Administrative Console, navigate to Environment, Virtual Hosts> default_host> Host Aliases (Figure 5-13).
On the Host Aliases page, select New.
For Port, enter the port number specified in step 1 (Figure 5-14).
Leave Host Name as *.
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.
In WebSphere Administrative Console, navigate to Servers >Web Servers and select the HTTP server. you created.
Click Generate Plug-in (Figure 5-15).
Click Propagate Plug-in (Figure 5-16).
Update the Web Server httpd.conf
file to refer to the correct plug-in file:
Click the Web Server.
Next to Configuration file name, click Edit.
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
).
Click Apply and then OK.
Click OK again to return to the Web Servers page.
Click Start.
Note: If the instance is already running, click Stop, then Start (Figure 5-17).
Restart the WebSphere server on which the WebCenter Portal application is deployed.
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):
This section includes the following sub sections:
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.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:
Install Oracle Access Manager 11g.
See Chapter 9, "Managing OAM Identity Assertion on IBM WebSphere".
Install and configure IBM HTTP Server.
See Chapter 5, "Installing and Configuring IBM HTTP Server".
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.
Navigate to the following directory on the Oracle Access Manager server:
IDM_HOME/oam/server/rreg/client/
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 ofRREG.tar.gz/rreg
.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.
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
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>
Change to the RREG_Home
directory.
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.
Change to the RREG_HOME
/input
directory.
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
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
Open the WebCenter REST Policy and change the Authentication Scheme to BasicScheme
(from the default LDAPScheme
).
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/.../*
Select the /rsscrawl*
resource in the search results and click Edit.
Change the Protection Level from Protected
to Excluded
and click Apply. Note that the resource's authentication policy and authorization policy is removed.
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.
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>
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.
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.
Restart IBM HTTP Server (IHS).
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.
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.
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.
Specify the location of the GCC libraries.
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)
Select to automatically update of httpd.conf
and specify the location of httpd.conf
from your WebTier. Typically, <webtier>/conf/httpd.conf
Finish the wizard.
WebGate successfully installed.
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:
Configure a stand alone LDAP registry for OAM in IBM WebSphere.
Add and configure a virtual host in IBM WebSphere.
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.Create the Interceptor entry in the IBM WebSphere Console.
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>
Configure logout details.
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.
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.
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>
Update httpd.conf
in WebTier.
Navigate to <webtier install directory>/conf/httpd.conf
Add the following entries in the webgate
section
Alias /oamsso "<webage-install-dir>/access/oamsso"
Restart WebTier and all the servers, including the Node Manager in WebSphere.
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".
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.
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:
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
Copy web.xml
to a temporary location.
Open web.xml
in a text editor.
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>
Replace with the following <login-config>
section:
<login-config> <auth-method>CLIENT-CERT</auth-method> </login-config>
Save the changes.
Redeploy the updated web.xml
file:
Log in to the IBM WebSphere Administrative Console:
https://host:port/ibm/console
Navigate to Applications > Application Types > WebSphere enterprise applications.
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
.
Choose the option Replace or add a single file.
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
Click Next.
In the section Specify the path to the file, enter the full path to the web.xml
file you updated in step 3.
Click Next.
Click OK and Save Changes.
Wait for a couple of minutes for the changes to be propagated.
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
Restart the WebCenter Portal application.
Access the WebCenter Portal application and, if single sign-on is configured, the web.xml
changes take effect.
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
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:
For SSL between the browser and the WebSphere node, obtain the SSL port as follows:
Log in to the IBM WebSphere Administrative Console.
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.
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
To import SSL certificates on IBM WebSphere:
Log in to the IBM WebSphere Administrative Console.
In the navigation panel, expand Security, then click SSL certificate and key management.
Click Key stores and certificates.
The Keystore usages dropdown should show SSL keystores (Figure 5-21).
Select a trust store (for example, CellDefaultTrustStore).
Click Personal Certificate.
Select Import (Figure 5-22).
Select Key store file and specify the location of your keystore (.jks) file (Figure 5-23).
For Type, select JKS, and then enter a Password.
Click OK to import the certificates from the keystore.
Restart the application server.
Use the IBM WebSphere Administrative Console to clone WebCenter Portal installations on WebSphere as follows:
Log in to the IBM WebSphere Administrative Console.
Navigate to Servers > Server Types > WebSphere application servers.
Create a server template based on the server you want to clone:
Click the Templates... button.
On the Server Templates screen, click New and select the server for the template.
Click OK.
Enter a Name for your server template, then click OK.
Navigate to Servers > Server Types > WebSphere application servers.
Create an application server based on the template you created in the previous step:
Click New.
Complete Step 1: Select a node.
For Step 2: Select a server template, select the template.
Complete Step 3 and Step 4 as required.
The new application server has the same resources as the specified template.
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:
Figure 5-24 shows a typical cluster set up for a Spaces application deployment.
Figure 5-25 shows a typical cluster set up for applications built using WebCenter Portal: Framework, that is, Framework applications and Portlet Producer applications.
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".
On the first WebCenter Portal host (WCPHOST1), create a new WebSphere cell:
Launch the Configuration Wizard using:
WC_ORACLE_HOME/common/bin/was_config.sh
On the Select Configuration Option page, click Create and Configure Cell.
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.
On the Select Optional Configuration page, click Application Servers, Clusters and End Points.
On the Configure Cluster page, add the new cluster and the first member, and select Enabled memory to memory replication.
Finish creating the cell by completing the Configuration Wizard.
Start the Deployment Manger:
WAS_HOME/profiles/dmg_profile_name/bin/startManager.sh
Start the node agent on the WCPHOST1 using:
WAS_HOME/profiles/profile_name/bin/startNode.sh.
If the second WebCenter Portal machine (WCPHOST2), is not yet federated to the cell on WCPHOST1, perform the following steps:
Launch the Configuration Wizard using:
WC_ORACLE_HOME/common/bin/was_config.sh
On the Select Configuration Option page, click Federate Machine and Configure Cell.
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
On the Add Products to Cell page, click Next.
You do not need to select any products on this page.
On the Select Optional Configuration page, click Application Servers, Clusters and End Points.
On the Configure Additional Cluster Members page, add the second server for the cluster associated with this node.
Finish federating the machine by completing the Configuration Wizard.
Start the node agent on Machine2 by opening:
WAS_HOME/profiles/profile_name/bin/startNode.sh
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".
Set up Oracle Internet Directory (OID) as the external LDAP ID store for WebCenter Portal applications:
Install and configure Oracle Internet Directory (OID).
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".
Perform a full resynchronization for all nodes:
Login to the IBM WebSphere Administrative Console and navigate to the Nodes page (System administration > Nodes).
Select all nodes in the cluster and click Full Resynchronize.
Restart all servers in the cluster.
Perform the following steps to reassociate the identity store:
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>
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>")
Perform a full resynchronization for all nodes:
Login to the IBM WebSphere Administrative Console and navigate to the Nodes page (System administration > Nodes).
Select all nodes in the cluster and click Full Resynchronize.
Restart all servers in the cluster.
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".
Configure clustering options for Discussions, deployed on the WC_Collaboration servers:
Create an Admin user for the Discussions server:
For details, see Section 5.2.8, "Configuring an Admin User for the Discussions Server".
Restart all WC_Collaboration servers in the cluster.
For each server in the WC_Collaboration cluster, configure unicast cluster communication:
Log into the IBM WebSphere Administrative Console.
Expand Servers, expand Server Types, then click WebSphere application servers.
Click WC_Collaboration, the server on which the Discussions application is deployed.
Under Server Infrastructure, expand Java and Process Management, then click Process definition.
On the process definition page, under Additional Properties, click Java Virtual Machine.
On the Java virtual machine page, under Additional Properties, click Custom properties.
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
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
Restart all WC_Collaboration servers in the cluster.
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:
Create a server template based on the WC_Utilities server
Log into the IBM Admin Console.
Expand Servers, expand Server Types, then click WebSphere application servers.
Click Templates.
Click New.
Select WC_Utilities as the server for the template, then click OK.
Enter the name for the server template, then click OK.
Create the new server based on the newly created server template:
Expand Servers, expand Server Types, then click WebSphere application servers.
Click New.
Select the node where this server is located, enter the server name, then click Next.
Select the template you just created, then click Next.
Select Generate Unique Ports, then click Next.
Click Finish.
Re-target the application to the new server:
Expand Applications, expand Application Types, then click WebSphere enterprise applications.
Click activitygraph-engines_11.1.1.4.0.
Under Modules, click Manage Modules.
Select all modules, select the target server you created in step 2, and click Apply.
Click OK.
The following sections describe differences and restrictions when developing and deploying WebCenter Portal applications on IBM WebSphere:
Configuring a WebSphere Application Server Connection in JDeveloper
Deploying WebCenter Portal Applications on IBM WebSphere Directly from JDeveloper
Targeting Application EAR and WAR Files for IBM WebSphere Deployment
Deploying WebCenter Portal Application EARs using WebSphere Console and wsadmin
Securing a Framework Application Connection to IMAP and SMTP with SSL
Using the Deploy and Configure Script for WebCenter Portal Applications Deployed on WebSphere
Creating SQL Data Controls for Applications Deployed on WebSphere Administration Server
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 |
||
|
System administration > Deployment manager > Configuration > Ports > SOAP_CONNECTOR_ADDRESS |
System administration > Deployment manager > Configuration > Ports > SOAP_CONNECTOR_ADDRESS |
|
System administration > Deployment manager > Configuration > Name |
Servers > Server Types > WebSphere Application Servers > Your_Server_Name > Configuration > Name |
|
System administration > Deployment manager > Runtime > Node name |
Servers > Server Types > WebSphere Application Servers > Your_Server_Name > Runtime > Node name |
|
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.
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:
Database connection configuration for seeded data sources is different on IBM WebSphere. For details, see:
Database connection configuration for custom data sources is different on IBM WebSphere. For details, see:
Note:
Custom data sources are not automatically created when you deploy WebCenter Portal applications to a WebSphere Application Server through JDeveloper or Fusion Middleware Control.The Deploy using SSL check box does not appear on the Create Application Server Connection wizard page. See "Deploying WebCenter Portal Applications Using SSL".
Deployed applications do not start automatically after deployment. You have to start the WebCenter Portal application manually using the console. See "Deploying and Redeploying WebCenter Portal Applications From JDeveloper".
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):
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.
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)
To connect to the Activities database, ensure that:
Connection Name = activities/Custom Portal (Figure 5-28)
Associate to Data Source = ActivitiesDS (Figure 5-29)
The database connections appear in the navigator as follows:
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:
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.
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)
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)
The database connections appear in the navigator as follows:
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:
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.
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)
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.
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)
Select the WAR file, and navigate to WEB-INF/ibm-web-bnd.xml
(Figure 5-39).
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.
To create a data source using the IBM WebSphere Administrative Console:
Log in to the IBM WebSphere Administrative Console.
https://host:port/ibm/console
Navigate to Guided Activities > Connecting to a database.
See also, Section 3.2.6, "Creating a Data Source in an IBM WebSphere Cell".
Configure credentials for secure database access (Figure 5-41).
Configure a JBDC provider (Figure 5-42).
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.
Skip the step "Configure WebSphere variables".
Configure a data source:
Enter the JNDI Name exactly as it appears in the application bindings (Figure 5-45). For example: jdbc/MyListsDS
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).
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".Click Next. Confirm the changes and click Finish (Figure 5-48).
Restart the servers to effect the new authentication alias MyListUser.
Test the data source connection.
Deploy the application and it verify that it uses the new custom data source.
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. |
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.
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.
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:
Deploying WebCenter Portal Application EARs using WebSphere Admin Console
Deploying WebCenter Portal Application EARs using wsadmin Commands
Note:
Applications do not start automatically after deployment or redeployment from JDeveloper. You have to start the WebCenter Portal application manually using the IBM WebSphere Administrative Console or using wsadmin commands.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.
To deploy a WebCenter Portal application EAR file using IBM WebSphere Console:
Note:
For more information, see the IBM WebSphere documentation.Log in to the IBM WebSphere Administrative Console.
Navigate to Applications > New Application >New Enterprise Application.
Enter the location of your application EAR file and click Next (Figure 5-50).
On the Preparing for the application installation page, accept the default Fast Path install option, and click Next.
On the Specify options for installing enterprise applications and modules page, accept all the default settings, and click Next.
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
On the summary page select to Finish to install.
Select Save (Figure 5-51).
Select the name of your newly installed application, and click Start (Figure 5-52).
Your application is now available.
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.Complete steps 1 through 5 in Section 5.3.4.2, "Deploying WebCenter Portal Application EARs using WebSphere Admin Console".
On the summary page, select View administrative scripting command for last action (Figure 5-53).
Copy the AdminApp.install command displayed and paste into a suitable text editor.
Edit the EAR file path in the copied command to match the location of your ear file.
Deploy your application using the wsadmin command:
Open the wsadmin command prompt connected to the deployment manager.
Paste the updated command.
Execute the wsadmin command.
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()
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]')
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
:
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.
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
Restart the Framework application.
Log into the application and provide your mail credentials.
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 instage2prod
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:
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 towsadmin.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.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.
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.
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
.
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.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.
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.
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.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.
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:
Log in to the IBM WebSphere Administrative Console and navigate to Security > Global Security.
Click the Administrative user roles link.
Click Add.
Select the role (any of deployer, operator, configurator, monitor, administrator, adminsecuritymanager, auditor) and search for the user.
Select the user from the Available
list and move to the Mapped to role
list.
Click OK.
This section includes the following sub sections
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 WebCenter.createMailConnection WebCenter.setWebCenterIdStoreSearchConfig WebCenter.exportWebCenterApplication Note: The |
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.
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.
This section describes WebCenter Portal features that are not supported on WebSphere. It contains the following sections:
Oracle WebCenter Adapter for SharePoint Not Supported on WebSphere
Activity Rank for Oracle Secure Enterprise Search Not Supported on WebSphere
You cannot connect WebCenter Portal application deployments on IBM WebSphere to Microsoft Sharepoint repositories.
The Oracle BPM Process Spaces workspace is not supported on IBM WebSphere for this release (11.1.1.6.0).
The use of Activity Graph ranking to improve the relevancy of Oracle Secure Enterprise Search results is unavailable on IBM WebSphere deployments.
Use the information in this section to help troubleshoot issues with WebCenter Portal on WebSphere. It contains the following sections:
Diagnosing java.lang.RuntimeException or java.lang.NullPointerException
Unable to Deploy Spaces Workflows when the SOA MDS schema is Running on DB2
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".
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:
Edit the Deployment Manager soap.client.props
file.
Modify the com.ibm.SOAP.requestTimeout
value. Enter a value in seconds.
For example, enter 18000 for a 5 hour timeout.
Restart Deployment Manager.
Restart the OracleAdminServer.
To modify the Request Timeout for Enterprise Manager:
Log in to the IBM Administrative Console.
Navigate to: Servers> Server Types> WebSphere application servers> OracleAdminServer> Container Settings> Container Services> ORB service
Update the value for "Request timeout"
Restart the OracleAdminServer.
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:
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.
Log in to the IBM Administrative Console.
Navigate to: Security> Global Security> LTPA
Set LTPA timeout (Figure 5-55).
Restart the servers.
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".
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 tofalse
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
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".
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.
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:
Log in to the IBM Administrative Console.
Navigate to: Resources> JDBC> Data Sources> mds-soa
Select Custom properties.
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.
Click OK.
Restart the SOA server.
In Enterprise Manager, confirm that the required BPEL composite is now deployed and available as expected.