Administer > Manage WebSphere Commerce features > WebSphere Commerce integration with WebSphere Portal > Configure WebSphere Portal with WebSphere Commerce
Configure the WebSphere Portal server cluster
Before you begin
Ensure the time difference between the Deployment Manager node and all the WebSphere Portal cluster nodes is less than five minutes.
Procedure
- Install WebSphere Portal on the primary node of the cluster with the Administration option, on top of the above existing WAS 7 instance.
If WebSphere Portal is installed on a separate machine that is different from the Deployment Manager:
- Start the WAS Network Deployment installation wizard. During the installation wizard:
- Select None when prompted at the WebSphere Application Server Environment selection.
- Do not create a Centralized Installation Repository.
- Upgrade the software level to the latest recommended WAS 7 fix level if necessary.
It is highly recommended to use the same WAS maintenance level across the entire WAS cell. That is, use the same WAS level for all WebSphere Portal and WebSphere Commerce installations, and the Deployment Manager.
- Upgrade the WebSphere Portal installation to the latest recommended WebSphere Portal 6.1 fix level.
- Configure WebSphere Portal on the primary node to communicate with the deployment manager. Verify the following properties are set in the configuration task wkplc.properties file.
Verify the following:
- WasPassword is set to the WebSphere Application Server password.
- PortalAdminPwd is set to the WebSphere Portal password.
- WasRemoteHostName is set to the fully qualified hostname of the deployment manager.
- WasSoapPort is set to the SOAP port that the deployment manager is using. The default value is 8879.
- PrimaryNode is set to true.
- ClusterName is set. For example, PortalCluster.
- CellName is the same as the one created by the deployment manager.
See the following topics for platform-specific information:
- Configure the primary node to communicate with the deployment manager on AIX
- Configure the primary node to communicate with the deployment manager on i5/OS
- Configure the primary node to communicate with the deployment manager on Linux
- Configure the primary node to communicate with the deployment manager on Solaris
- Configure the primary node to communicate with the deployment manager on Windows
- Setup the static type of cluster and prepare for cluster federation.
See the following topics for platform-specific information:
- Create a static cluster on AIX
- Create a static cluster on Linux
- Create a static cluster on Solaris
- Create a static cluster on Windows
- Configure a default federated LDAP user repository from the WebSphere Portal primary node, noting the steps provided in the link.
- Update the configuration task wkplc.properties file under the VMM Federated LDAP Properties:
The following is an example to illustrate what properties to update for setting a federated LDAP user repository using a non-SSL connection.
Property Example federated.ldap.id ldap federated.ldap.host Your LDAP hostname federated.ldap.port 389 federated.ldap.bindDN cn=root federated.ldap.bindPassword Your LDAP binding password federated.ldap.ldapServerType IDS federated.ldap.baseDN dc=ibm,dc=com federated.ldap.et.group.searchFilter (objectclass=groupOfUniqueNames) federated.ldap.et.group.objectClasses groupOfUniqueNames federated.ldap.et.personaccount.searchFilter (objectclass=inetOrgPerson) federated.ldap.et.personaccount.objectClasses inetorgperson
- Run ConfigEngine to validate the LDAP property settings using the validate-federated-ldap task.
- Create the federated LDAP repository using the wp-create-ldap task.
- Stop and restart all the servers and node agents to propagate the LDAP changes.
- Validate the federated LDAP repository using the wp-query-repository task.
- Update the configuration task wkplc.properties file under VMM supported entity types configuration:
Property Example personAccountParent cn=users,dc=ibm,dc=com groupParent cn=groups,dc=ibm,dc=com
- Update the default entity type using the wp-update-entitytypes task.
- Stop and restart all the servers and node agents to propagate the LDAP changes.
The PersonAccount default parent must be set to the Default Organization of the LDAP repository, for example, cn=users,dc=ibm,dc=com, if the site allows users to register themselves through WebSphere Portal.
- Start the node agent on the WebSphere Portal server node.
- Optional: Add realm support to the user repository.
What to do next
- After completing the steps to federate and cluster a node, there can be errors while starting up in Portal server if the Portal administrative user is in the LDAP server.
See the following technote to resolve this error:
- If you are planning on creating new users through the WebSphere Portal server, in order to allow users to enter their e-mail address and have this field mapped into an existing LDAP attribute, the following steps may be required on the WebSphere Portal server:
See Map attributes, and the Detailed steps for mapping LDAP attributes in WebSphere Portal 6.1 technote for more information.
- Update the wp_profile/ConfigEngine/properties/wkplc.properties file.
- Search for the wp-update-federated-ldap-attribute-config section.
- Update the properties with the following changes:
federated.ldap.attributes.mapping.ldapName=mail federated.ldap.attributes.mapping.portalName=ibm-primaryEmail federated.ldap.attributes.mapping.entityTypes=PersonAccount
- From the command line, run the following command:
wp_profile/ConfigEngine/ConfigEngine.bat wp-update-federated-ldap-attribute-config
Related information