ShowTable of Contents
Beginning with WebSphere Portal Server (Portal) Version 6.0, configuration properties are logically grouped as "services" and each service is
assigned a name. The properties associated to each service are stored in WebSphere Application Server (WSAS) as Resource Environment Providers.
Implementation
The Portal configuration properties provide settings to change the way the portal behaves. For example, the LDAP Relative Distinguished Name
and other properties used by the Portal User Management Architecture (PUMA) are grouped in the PumaStoreService. Session-related properties
are grouped in the SessionValidatorService and so on. A complete list of the Portal services can be found in the WebSphere Portal documentation.
The properties and their values are written to the file resources.xml under the Profile root directory:
In a cluster, the file is located on the Deployment Manager under the \clusters directory and properties apply to the entire cell.
Each property-value pair will be contained on its own line under the name of the Provider. For example, the XML for the PumaStoreService Provider
will appear similar to this:
<resources.env:ResourceEnvironmentProvider xmi:id="ResourceEnvironmentProvider_1257636024768"
name="WP PumaStoreService">
<propertySet xmi:id="J2EEResourcePropertySet_1257636024772">
<resourceProperties xmi:id="J2EEResourceProperty_1257636029601" name="store.puma_default.user.add.required.attributes"
value="sn" description="" required="false"/>
<resourceProperties xmi:id="J2EEResourceProperty_1257636029710" name="store.puma_default.user.nonsupported.attributes"
value="certificate,identifier" description="" required="false"/>
<resourceProperties xmi:id="J2EEResourceProperty_1268763772625" name="store.puma_default.user.fbadefault.filter"
value="uid" description="" required="false"/>
<resourceProperties xmi:id="J2EEResourceProperty_1268763774781" name="store.puma_default.group.fbadefault.filter"
value="cn" description="" required="false"/>
</propertySet>
</resources.env:ResourceEnvironmentProvider>
Property Updates
Portal properties can be modified using one of two methods as shown below.
Note: Manual modification of resources.xml is strongly discouraged. An incorrect entry could cause Portal startup to fail and render the Portal inaccessible.
1) Best Practice: Add or Update the property in the WebSphere Application Server Integrated Solutions Console under the "Resources" menu.
Navigate to Resources > Resource Environment > Resource Environment Providers.
In the Resource Environment Providers page, make the appropriate selection, depending on your version of WebSphere Application Server
and your portal environment:
For WebSphere Application Server Version 6.1: Select the appropriate node or cluster from the scopes pull-down list, depending on your
Portal environment.
For WebSphere Application Server Version 7.0: Select the appropriate node or cluster from the scopes pull-down list, or uncheck the
Show Scope selection drop-down checkbox and select one of the following options, depending on your portal environment:
If your portal is running as a single server, select Browse Nodes and select the node. If your portal is installed in a cluster, select Browse Clusters and select
the portal cluster. Select the service to which you want to make changes.
Note: In the list the services are preceded by a prefix that is made up of the letters WP and a blank space, for example WP PumaStoreService.
The example below shows the PumaStoreService. All the properties are defined under the "Custom properties" menu.
2) Add or update the property in the Portal properties file and run the ConfigEngine task update-properties. Again using PumaStoreService:
a) Edit
<wp_profile_root>\PortalServer\config\PumaStoreService.properties.
b) Uncomment an existing property and set the value or add a new property and value.
c)
./ConfigEngine.bat | .sh -DWasUserid=userid -DWasPassword=password update-properties
Note: The configuration task method to set service configuration properties is not available for all properties.
Regardless of the method used, the Portal server must be restarted. In a cluster, synchronize the nodes prior to restarting them.