Understanding the Portal Server Configuration
So far, you have seen and hopefully understood how to install and verify the WebSphere
Portal server. Now you will see how the Portal server’s configuration data is stored in the
default Cloudscape database and in files in the file system. If you want to configure and
maintain your portal server in a production environment then you need to have a
complete understanding of this configuration so pay close attention to this information.
As shown in the illustration above, the WebSphere Portal server will store most of the
configuration data in the Cloudscape database. The name of the database is wpsdb by
default. Different parts of the configuration are stored in different schemas in the wpsdb
database. The remaining part of the configuration (DB connections and Deployment
Descriptors for example) will be stored as property files in the file system.
What follows is a brief description of the important schema names and the type of
information that is stored in the wpsdb database schemas:
• Release, Likeminds, Feedback: These schemas store data of Pages, Portlets, Portlet
instances, Themes, Templates, Personalization rules and Policies. This data is not
modified during the portal runtime.
• Customization: This schema stores information specific to users (for example
PortletData).
• Community, Jcr: These schemas store data of shared documents and resources. This
data will be modified during runtime.
• wmm: This schema stores user registry data used to authenticate users.
Having the portal configuration in the Cloudscape database is fine for education and
demonstration purposes. However, this configuration data does not scale as user volume
increases and does not support portal cluster configuration data or multiple realms. You
need to move this configuration to a robust RDBMS (like DB2, Oracle, Sybase, MS SQL
Server or Informix for example) in production environments. You also need to move user
registry data from the Cloudscape database (stored in the wmm schema) to an LDAP
server (like IBM Tivoli Directory Server for example) in production environments.
