39 Understanding WebCenter Portal Life Cycle

39.1 What is the WebCenter Portal Life Cycle?

The portal life cycle describes the process of creating a portal using Portal Builder through deployment to a production instance. Many actors participate in the life cycle including software developers, content modelers, content contributors, IT administrators, portal site administrators. The phases of the life cycle typically include development, testing, staging, and production. Each phase requires certain tasks to be performed. Some tasks are performed only once, like setting up a content repository. Others are performed more frequently, like creating backups, and performing nightly builds. The phases of the portal life cycle are described in Table 39-1.

39.2 What Are the Major WebCenter Portal Life Cycle Tasks?

Each phase of the life cycle requires actors (developers, administrators, content contributors, and others) to perform certain tasks. This provides an overview of the kinds of tasks that are performed during each phase of the portal life cycle.

• Section 39.2.1, "One-Time Setup Tasks"

• Section 39.2.2, "Development Environment Tasks"

• Section 39.2.3, "Stage Environment Tasks"

• Section 39.2.4, "Production Environment Tasks"

39.3 Who Participates in the WebCenter Portal Life Cycle?

Many different people participate in the portal life cycle. In general, these people (the primary actors in Table 39-1) fall into one or more of these general roles:

• Developer – Uses JDeveloper to build/extend/deploy portlets, task flows, portal assets, and shared libraries for WebCenter Portal, and also manages source control.

• Web developer – Uses Portal Builder to build and develop portals.

• System administrator – Uses WLST commands to move portals between different environments. Creates backups and restores from backups. Maintains build and source control systems.

  Has full administrative privileges for WebCenter Portal. Uses WebCenter Portal administration to modify global layouts, enable tools and services, delegate security settings, and more.

• Application specialist – Uses the Assets page to extend the portal structure and define reusable components for the portal.

• Content modeler – Uses Oracle WebCenter Content's Site Studio designer to model content.

• Content contributor – Develops whatever content appears in or is available from the portal, including images, document files, video and audio content, and so on.

• Knowledge worker - End user or consumer of the production portal. Finds, creates, and updates content. Collaborates with other business users.

39.4 Understanding WebCenter Portal Staging and Production Environments

This section discusses the staging and production phases of portal life cycle. Figure 39-1 illustrates the general flow from staging to production environments. The figure shows that initially you migrate the entire WebCenter Portal instance from staging to the production environment.

Subsequent updates to portals and any new portals that are developed on stage can then be migrated to production as and when required. You can migrate updates on stage directly to production using deploy or propagate WLST commands or you can export stage updates to an file and import them on the production server through Portal Builder or using export and import WLST commands.

Figure 39-1 Flow from WebCenter Portal Staging to Production Environments

Description of "Figure 39-1 Flow from WebCenter Portal Staging to Production Environments"

39.5 Tools for Managing WebCenter Portal Life Cycle

WebCenter Portal provides a set of tools and utilities that enable you to design, build, and deploy portals, and move information between development—test—stage— production environments or WebCenter Portal installations:

• Oracle JDeveloper and Oracle ADF – Oracle JDeveloper and Oracle ADF provide the tools and framework to build and deploy portlets, and to extend and deploy portal assets.

  You can also develop custom task flows and other custom components for your portal and deploy them to a shared library for use in WebCenter Portal.

• Round-Trip Development: Round-trip development refers to features and techniques that allow you to export portal assets from WebCenter Portal and import them back to JDeveloper for maintenance or enhancement. For more information on round-trip development, see "Using Iterative and Round-Trip Development Techniques" in Oracle Fusion Middleware Developing Portals with Oracle WebCenter Portal and Oracle JDeveloper.

• Enterprise deployment: When you are ready to deploy your portal to a production environment, you can use the exportWebCenterPortals and importWebCenterPortals WLST commands. For more information, see Section 40.9.2, "Directly Deploying Portals From Staging to Production" and Section 40.1.2, "Deploying Portal Archives."

  Alternatively, if you want to keep your stage and production environments connected and "in sync " so you can propagate metadata changes from stage to production, use the WLST command deployWebCenterPortals. See also, Section 40.1, "Deploying Portals."

• Browser-based administration tools: Various browser-based tools enable administrators to configure, manage, and monitor portal deployments:

  • Portal Builder Administration

  • Enterprise Manager Fusion Middleware Control Console

  • WebLogic Server Administration Console

  For more information, see Section 1.13, "Oracle WebCenter Portal Administration Tools". See also, Table 39-3, "WebCenter Portal and WebLogic Server Permission Requirements for Life Cycle Operations".

• Scripting tools: Enable system administrators to configure, manage, backup, and restore portal deployments.

  For more information, see Section 1.13.3, "Oracle WebLogic Scripting Tool (WLST)."

39.6 Permissions Required to Perform WebCenter Portal Life Cycle Operations

Table 39-3 describes which WebLogic Server roles and WebCenter Portal permissions are required to perform lifecycle operations.

39.7 Setting Up a Staging or Production WebCenter Portal Environment for the First Time

If you are setting up stage and production environments for WebCenter Portal for the first time, follow instructions in Oracle Fusion Middleware Installation Guide for Oracle WebCenter Portal. Once both environments are set up and your stage environment is ready to be migrated to the production server, refer to Chapter 41, "Migrating Entire WebCenter Portal to Another Target."

See also Section 39.11, "Managing Security Through the WebCenter Portal Life Cycle" for information on moving security policies and credentials to an environment for the first time.

39.8 Managing WebCenter Portal Deployment from Your Development Environment

After testing new portal assets and extensions, developers will typically deploy new components to an archive and give them to an administrator for deployment to WebCenter Portal. For example, portal asset archives (.ear files), ADF libraries (.jar files) and shared libraries (.war files).

Developers can deploy portal assets/extensions to WebCenter Portal directly from JDeveloper if given the appropriate permissions to do so. For example, while developers might be allowed to deploy assets/extensions in the test environment but prevented from deploying to stage and production servers. For details, see "Deploying Extensions Directly to the Portal Server" and "Uploading Assets Directly to WebCenter Portal" in Oracle Fusion Middleware Developing Portals with Oracle WebCenter Portal and Oracle JDeveloper.

39.9 Managing Portal Changes in Staging to Production

In practice, the staging environment and the production remain identical until changes are made to the stage environment. You can move approved changes to production in two ways:

• Export updates on stage to a file and then use Portal Builder or WLST commands to import the changes in the file on the production server

• Deploy updates on stage directly to production using deploy or propagate WLST commands.

The propagation feature is useful for migrating changes to portal metadata (pages, assets, portlets dropped on to pages, and so on). Propagation does not require the production server to be restarted or incur any downtime because propagation only transfers changes to portal metadata. If you want to use the propagation feature, you must move the first set of changes to production using the deployWebCenterPortal command—this command re-creates the entire stage portal on the production instance and creates a matching label on the stage portal and the production portal, for example LABEL_1. Subsequently, when you propagate changes from stage to production the portal's label increments by 1 in both the stage and production environment. You can only propagate portal changes to another portal instance if the labels match.

For more information, see Section 40.9, "Managing Portals in Production."

See also, Appendix E, "Labeling During WebCenter Portal Lifecycle."

39.10 Managing Changes in Production Back Into Staging

You can export individual production portals to an archive and import them back to your staging site, using WLST commands or Portal Builder Administration. For more information, see Section 40.1.2.2, "Deploying Portal Archives to a Different Server."

If you want mirror your entire production system to stage, you have two options; either back up/restore your production WebCenter Portal instance or clone the WebLogic Server that is running your production WebCenter Portal instance. For details, see Chapter 41, "Managing WebCenter Portal Backup, Recovery, and Cloning."

39.11 Managing Security Through the WebCenter Portal Life Cycle

This section discusses techniques for migrating portal security policies and credentials from one WebCenter Portal environment to another.

Security Policy for a Single Portal

Each portal has its own security policy. When you deploy a portal on a WebCenter Portal instance for the first time you must include the portal's security policy. On redeployment, the security policy is optional. For example, if you redeploying a portal from staging to production, often it is important not to overwrite policy changes made on the production system. See also, Section 40.1, "Deploying Portals."

Security Policy for an Entire WebCenter Portal Application (all portals, including the Home portal)

When you back up (or export) an entire WebCenter Portal application, security policies for the Home portal and individual portals are included in the archive so you can move/restore the security information on one instance to another. For details, see Section 41.5, "Migrating Entire WebCenter Portal to Another Target."

Back-end Identity Store and Credential Store for WebCenter Portal

When you migrate to another instance, you must migrate the back-end components for security, such as Identity Store, Credential Store, Policy Store. For details, see Section 41.6.7, "Backing Up and Restoring Policy Stores (LDAP and Database)" and Section 41.6.8, "Backing Up and Restoring Credential Stores (LDAP and Database)."

39.12 Managing Backups Through the WebCenter Portal Life Cycle

For more information, see Chapter 41, "Managing WebCenter Portal Backup, Recovery, and Cloning."