Skip Headers
Oracle® Fusion Middleware Administering Oracle WebCenter Portal
11g Release 1 (11.1.1.8.3)

Part Number E27738-06
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

39 Understanding WebCenter Portal Life Cycle

This chapter discusses tasks, tools, and techniques for managing WebCenter Portal throughout its life cycle.

This chapter includes the following topics:

Note:

Portal Framework applications have a different life cycle. For more information, see the "Understanding the WebCenter Portal Framework Application Life Cycle" chapter in Oracle Fusion Middleware Developing Portals with Oracle WebCenter Portal and Oracle JDeveloper.

Permissions:

To perform the tasks in this chapter, you must be granted the following roles:

See also, Section 1.8, "Understanding Administrative Operations, Roles, and Tools."

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.

Table 39-1 WebCenter Portal Life Cycle Phases

Life Cycle Phase Primary Actors/Roles Description

Development

  • Portal Developers

  • Web Developers

  • Content Modelers

  • Content Contributors

  • Application Specialists

Developers can use Portal Builder, WebCenter Portal's browser-based tool for developing new portals.

For advanced requirements, developers can use JDeveloper to further develop and deploy portal assets and shared libraries (containing custom portal components).

The development portal typically employs test data and content. Some of the features that are developed in this phase of the life cycle include:

  • portals

  • portlets

  • task flows

  • shared libraries

  • skins

  • navigation models

  • page templates

  • display templates

  • content models

  • data transfer and interportlet communication

  • initial security

Testing

  • Developers

  • QA Engineers

  • System Administrators

The development portal is deployed to an independent testing environment. The test environment typically includes its own Metadata Service (MDS) and policy store that are database-based, and has a dedicated Oracle WebCenter Content instance.

The testing environment may contain test data and test content that will not become part of the production portal.

Portlet producers may be shared between the test and development environments. However, if the usage load is high, Oracle recommends that separate instances be created.

Staging

  • Application Specialists

  • System Administrators

  • Content Contributors

The staging environment provides a stable environment where final configuration and testing takes place before the portal is moved to production. Content contributors add content and refine the portal structure.

Typically, the staging environment includes a dedicated Oracle WebCenter Content server, as well as a dedicated portlet producer server (WC_Portlet), a utilities server for analytics, activity graph, data integration (WC_Utilities), and a collaboration server for discussions and announcements (WC_Collaboration). The staging server is often maintained as a mirror of the production site.

Production

  • Application Specialists

  • System Administrators

  • Content Contributors

  • Knowledge Workers

A production portal is live and available to end users. A portal in production can be modified whilst online with tools like Portal Builder, the Assets page, and Composer. For instance, an administrator might add additional portlets to a portal or reconfigure the content of a portal.

Individual users with proper authorization can also customize their view.

WebCenter Portal provides a set of WLST commands for migrating portals and content to the production environment. See Section 40.7, "Moving Portals from Staging to Production."

Some back-end data must be moved manually. For details, see Section 40.8, "Moving External Portal Data from Staging to Production."

Note: Administrators can propagate metadata changes in staging to production providing that the two environments are kept "in sync", that is, by always making changes in stage first and then pushing the metadata changes to production using deployment or propagation. For details, see Section 40.9, "Managing Portals in Production."


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.

39.2.1 One-Time Setup Tasks

You must perform certain preparatory steps to set up development, test, stage, and production environments for WebCenter Portal. Table 39-2 provides a general list of these preliminary setup tasks and the environments to which they apply.

See Section 39.7, "Setting Up a Staging or Production WebCenter Portal Environment for the First Time."

Table 39-2 Typical One-Time Setup Tasks

Setup Task Development in JDeveloper
(Assets and Shared Libraries only)
Development/Test in Portal Builder Stage Production

Install Oracle JDeveloper and WebCenter Portal extension for JDeveloper

Yes

No

No

No

Install Oracle WebCenter Portal

No

Yes

Yes

Yes

Install Oracle WebLogic Server; create a domain and managed servers

No

Yes

Yes

Yes

Create required database schemas using RCU

No

Yes

Yes

Yes

Install and configure Oracle WebCenter Content

Yes

Yes

Yes

Yes

Install identity management components, such as Oracle Access Manager

No

Yes

Yes

Yes

Create the required Oracle Platform Security Services policies in the policy store

No

Yes

Yes

Yes

Create required user credentials in the credential store

No

Yes

Yes

Yes

Create connections to back end servers

Yes

Yes

Yes

Yes

Set up source control and nightly build scripts

Yes

No

No

No

Create deploy and configure scripts

No

Yes

Yes

Yes

Create backup scripts

No

No

Yes

Yes

Integrate/configure personalization for WebCenter Portal

Yes

Yes

Yes

Yes


39.2.2 Development Environment Tasks

Developers can use Portal Builder, WebCenter Portal's browser-based tool for developing new portals and portal components.

For advanced requirements, developers can use JDeveloper to further develop and deploy portal assets, shared libraries (containing custom portal components), and portlets. In a JDeveloper development environment, each developer has a local JDeveloper instance that is connected to a source control system and a shared Oracle WebCenter Content repository.

39.2.3 Stage Environment Tasks

WebCenter Portal plays a bigger role in the staging environment than in the development environment. Nonetheless, occasional updates from development to portlets, task flows, and portal assets will need to be deployed to the stage environment. To facilitate these more intermittent updates, WebCenter Portal provides a set of WLST commands, as well as comparable menu options in WebCenter Portal, that enable you to import portal asset updates from development to stage. If you want to update portlets and task flows on the staging environment then you redeploy them in the usual way.

For more information, see Section 39.4.1, "Setting Up a Staging Environment for WebCenter Portal" and Chapter 40, "Deploying Portals, Templates, Assets, and Extensions."

39.2.4 Production Environment Tasks

When changes are tested and approved in the stage environment they need to be pushed to the production environment. WebCenter Portal provides a set of WLST commands, as well as import/export options in WebCenter Portal, to push the entire portal server or individual portals, portal templates and assets deployed on stage to production. For more information, see Section 41.5, "Migrating Entire WebCenter Portal to Another Target." and Section 40.7, "Moving Portals from Staging to Production."

In addition, WebCenter Portal provides a WLST command that only propagates changes to portal metadata from stage to production server. For more information, see Section 40.9.3, "Propagating Portal Changes in Staging to Production."

During the export/import process you can, where required, isolate and modify connection information that is variable between environments, like the server names, ports, content management connections, and so on.

Note:

When you deploy changes and updates from stage, new connections that do not exist in the stage environment are created on the target but existing connections configured on production are never modified.

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:

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.

Note:

Figure 39-1 does not depict all possible portal features.

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

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

39.4.1 Setting Up a Staging Environment for WebCenter Portal

The staging environment provides a stable environment where final configuration and testing takes place before the portal is moved to production. Typically, the staging environment includes a dedicated content server, discussions server, as well as dedicated portlet producer servers and utilities server (for analytics, activity graph, data integration). An external LDAP-based identity store, such as Oracle Internet Directory, must be set up for the staging environment too. For a list of typical setup tasks, see Table 39-2, "Typical One-Time Setup Tasks".

If you are setting up the staging environment for the first time, see:

For information on making incremental changes to the staging environment, see:

39.4.2 Adding Content to the WebCenter Portal Staging Environment

Content developers can add content directly to the staging server. Content workflow features in Oracle WebCenter Content can be used to manage content approvals. WebCenter Portal also provides browser tools for creating and editing portal content.

When you create or deploy a portal, WebCenter Portal creates a dedicated folder for the portal on the back-end content server. When you move a portal from stage to production you can optionally, move the portal's content folder along with the portal. See Section 40.7, "Moving Portals from Staging to Production."

39.4.3 Moving a Portal from Staging to Production

Once the staging environment is fully provisioned and tested, it can be moved to the production environment and made accessible to users.When you copy the staging environment to production for the first time, you migrate the entire stage WebCenter Portal instance to the production environment. Subsequently, and once the production environment is live, you can make incremental updates to portal metadata, content, and assets using WLST commands, automated WLST scripts, and/or replication techniques.

Typically, portal updates are performed by a system administrator. For more information, see Section 40.7, "Moving Portals from Staging to Production."

During the update process you can, where required, isolate and modify connection information that is variable between environments, like the server names, ports, content management connections, and so on.F or details, see Section 40.6, "Moving Connections Details from Staging to Production."

Note:

When you deploy changes and updates from stage, new connections that do not exist in the stage environment are created on the target but existing connections configured on production are never modified.

New/updated portal templates and assets can be pushed to the production server by application specialists. See Section 40.2, "Deploying Portal Templates" and Section 40.3, "Deploying Assets."

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:

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.

Table 39-3 WebCenter Portal and WebLogic Server Permission Requirements for Life Cycle Operations

WebCenter Portal Object Tool WebLogic
Server Role
WebCenter Portal Permission

Portal

     

Deploy Portal Directly from WebCenter Portal

WLST

Monitor
(or higher)

Portals - Manage All

Propagate Portal Directly from WebCenter Portal

WLST

Monitor
(or higher)

Portals - Manage All

Import or Export Portal Archive

WLST

Monitor
(or higher)

Portals - Manage All

Import or Export Portal Archive

WebCenter Portal

-

Portals - Manage All

Portal Template

     

Import or Export Portal Template Archive

WLST

Monitor
(or higher)

Portal Templates - Manage All

Import or Export Portal Template Archive

WebCenter Portal

-

Portal Templates - Manage All

Portal Asset

     

Import or Export Asset Archive

WLST

Monitor
(or higher)

Either:

  • Create, Edit, Delete Assets

  • Create, Edit, Delete <Portal_Asset_Type>

Import or Export Asset Archive

WebCenter Portal

-

Portal - Manage Configuration

And either:

  • Create, Edit, Delete Assets

  • Create, Edit, Delete <Portal_Asset_Type>

Import or Export Asset Archive

JDeveloper

-

-

Portal Extension (ADF shared library)

     

Deploy Portal Extension Directly from JDeveloper

JDeveloper

Monitor
(or higher)

Portals - Manage All

Import or Export Portal Extension Archive

JDeveloper

-

-

Portal Connections

     

Import or Export Connections

WLST

Operator
(or higher)

-

Shared Asset

     

Import or Export Asset Archive

WLST

Monitor
(or higher)

Create, Edit, Delete <Shared_Asset_Type>

Import or Export Asset Archive

WebCenter Portal

-

Application - Manage Configuration

Create, Edit, Delete <Shared_Asset_Type>

Import or Export Asset Archive

JDeveloper

-

-

WebCenter Portal (all portals)

     

Import or Export Archive

WLST

Monitor
(or higher)

Application - Manage

Import or Export Archive

Fusion Middleware Control

Monitor
(or higher)

Application - Manage


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.

Note:

Cloning an entire Fusion Middleware production instance from a stage instance, is sometimes referred to as "test to production". For information on how to clone a WebCenter Portal instance together with other Fusion Middleware components, see "Moving Oracle WebCenter Portal to a New Target Environment," in the Oracle Fusion Middleware Administrator's Guide.

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:

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."