Administrator Operator Developer Workbench Portal Customization Portal Layout

Administrator operator developer workbench portal

This preview shows page 102 - 105 out of 150 pages.

Administrator Operator Developer Workbench Portal Customization Portal Layout Portlet Development Page Definition Entitlement Definition Unit Test
Image of page 102
Chapter 4. Deploying, testing, and maintaining a portal 91 Determining what to move To deploy a portal release, resources must be synchronized, packaged, and deployed to a portal server. This is a manual process that involves many people and few tools. Resources can be: Portal configuration (this is stored in the portal database): Portal content tree Portal application configuration, settings, and data Portlet access control information Portal artifacts (these are stored in the file system): Portal configuration (property files) Theme and skin file assets (JSPs, style sheets, images) Portlet code (Java classes, JSPs, XML files) 4.3.1 Automating custom code deployment Although there is no automated method to move portal applications from one environment to another, there are two options: Completely replace the old release with a new release. The drawbacks of this option is that any data that was customized by the user is lost. Although this option works, we do not recommend it. Use the XMLAccess tool to load incremental or differential releases. 4.3.2 Staging concepts A subsequent solution release is staged from the integration to the staging and to the production system. The physical implementation of configuration staging through a series of systems does not really move these configurations between systems. This process is based on repeatable modifications of portal solution releases on multiple systems. For each solution release, a differential portal solution configuration is imported into the system; artifacts are managed manually by manual updates and deletions. What elements of the portal you move depends on the type of release you have. If you have an incremental release, you: Add new resources to a release. Update resource attributes (only add properties to lists). If you have a differential release, you: Maintain all functionality of the incremental release. Delete existing resources. Update resource attributes (add or delete properties in lists). If you have data that has been configured by the user, configure the scope of the portal for a single user. The following process (Figure 4-4 on page 92) is an example of a possible subsequent portal solution staging process. Derivations of this process are possible and expected. It focuses on configuration and artifact management. Important: You must define and test your application deployment process.
Image of page 103
92 WebSphere Portal Best Practices Figure 4-4 A subsequent portal solution staging process 4.3.3 Clustering and deployment In WebSphere Application Server, a cluster is composed of multiple identical copies of an application server. A cluster member is a single application server in the cluster. WebSphere Portal is installed as an enterprise application server within the WebSphere Application Server infrastructure. All of the clustering features available within the WebSphere Application Server infrastructure are also available and apply to WebSphere Portal. Therefore, a
Image of page 104
Image of page 105

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture