Installing WebSphere Portal

WebSphere Portal provides flexible deployment options ranging from proof-of-concept where you can examine and test functionality to a highly available and scalable production environment.

After installing WebSphere Portal and if you plan to use Mashup integration, run the deploy-portal-mashup-ui task listed in the Mashup integration > Configuring your portal and mashups > Enabling mashup integration in the portal topic. Select the type of setup you need from the list of options. Follow the scenario to install WebSphere Portal.

• Installation methods, options, and sources

  There are multiple installation methods (silent, graphical user interface, and console), options (full or administrator), and sources (CD or CD images).

• Set up a single server

  This scenario is suited to people investigating WebSphere Portal features and capabilities (proof-on-cencept), demonstrating the features to interested third-parties, or developers setting us a development environment. This installation path is intended to provide a simple configuration with all the needed components on one server. The instructions for this single-server configuration are Windows specific.

  The configuration uses a local DB2 database, so you will transfer data from the default database to DB2. However, for test, proof-of-concept environments, and development environments, you can use the out-of-box database. Security is configured as the default federated repository with a built-in file repository.

• Set up a stand-alone production server

  Set up a stand-alone production environment when you do not need a robust clustered environment. A stand-alone server deployment is also useful to determine and validate the needs of your deployment. It enables you to examine and test the functions and features to decide how to accomplish business goals.

• Set up a cluster

  Clusters enable you to scale your WebSphere Portal configuration. Clusters also enable enterprise applications to be highly available because requests are automatically routed to the running servers in the event of a failure. There are numerous cluster configuration, such as horizontal, vertical, multiple, and dynamic.

• Manual database creation and setup

  For most databases, tasks are provided to create the database (create-database), setup the database users (setup-database), and transfer the default data to the database (database-transfer). However, if you want to create databases manually and transfer the data manually, you can use the alternate configuration instructions provided in this section.

• About ReleaseBuilder

  To generate or stage follow-on releases of WebSphere Portal portals, configurations and artifacts need to be moved between systems. ReleaseBuilder enables management of release configurations independent of user configurations. Release configuration data are exported to XML files that can be imported using the XML configuration interface (XmlAccess). Using ReleaseBuilder it is possible to stage release configurations between two portals. This allows you to track which configuration entities were removed, added or changed compared to the previous release generated from a given portal and to apply these differential updates to another portal. Detecting the differences between one configuration and another of the same portal server creates differential updates. A third configuration or "diff", generated by ReleaseBuilder, represents the changes made between the two configurations. The diff can be used to apply not only addition and update modifications but also deletions to the target server.

  This allows two portal servers, for example, a staging server and a production server, to remain in synch. ReleaseBuilder is designed to eliminate the need generate complete XmlAccess exports to move a partial configuration or to manually create XML response files to export a partial configuration. ReleaseBuilder also helps to prevent the problem of configuration bloat on the target server.

• Set up a Personalization server on WAS

  The WebSphere Portal product installs and configures Personalization software by default. However, you can choose to install Personalization to an instance of WAS. When Personalization is installed in this way, it is referred to as the Personalization Server. The Personalization Server enables you to deploy applications that have been developed with IBM WAS, serve personalized content to users, and record site metrics, without requiring that WebSphere Portal also be present on the server machine. While business rules may be run from any WAS installation, a full WebSphere Portal installation is still required as a workspace for authoring rules and campaigns.

• Uninstalling WebSphere Portal

  Uninstalling WebSphere Portal is a multiple step process and the method you use is dependent upon your configuration. Removing WebSphere Portal in a single-server configuration is different from removing WebSphere Portal from a cluster. Manual uninstallation instruction are provided for a single-server configuration in case of an error situation.

• Applying fixes

  Periodically fix packs are released to integrate product code fixes. Between fix pack releases, interim fixes may be recommended or required to ensure product reliability and stability. The Recommended fixes page provides links to fix pack and interim fix downloads, information about what is recommended and what is required, and links to recommended related product fixes. To find the most current service update information, see the Recommended fixes link.

Related information

Deployment scenarios

---