Understanding the WebCenter Portal Lifecycle

27 Understanding the WebCenter Portal Lifecycle

To administer WebCenter Portal effectively, it is important to have a general understanding of the tasks, tools, and techniques for managing WebCenter Portal throughout its lifecycle.

Permissions:

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

WebLogic Server: Admin role granted through the Oracle WebLogic Server Administration Console.
WebCenter Portal: Administrator role granted through WebCenter Portal Administration.

Topics:

27.1 What Is the WebCenter Portal Life Cycle?

The portal life cycle describes the process of creating a portal using WebCenter Portal through deployment to a production instance. Many actors participate in the life cycle including software developers, content modelers, content contributors, IT administrators, and 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 27-1.

Table 27-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 WebCenter Portal's browser-based tooling 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 Portal assets such as skins, page templates, and Content Presenter display templates Visualization and custom visualization templates shared libraries data transfer and interportlet communication initial security Portlets
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. Components such as application data sources and portlet producers may be shared between the test and development environments.
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`),and a collaboration server for discussions and announcements (`WC_Collaboration`). Also, an external LDAP-based identity store, such as Oracle Internet Directory, must be set up for the staging environment. The staging server is often maintained as a mirror of the production site. Occasional updates from development to portlets, task flows, and portal assets will need to be deployed to the stage environment. WebCenter Portal administration enables 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. Note: Oracle WebCenter Portal has deprecated the support for Jive features (announcements and discussions/discussion forums). Hence, Jive features are not available in 14.1.2 instances.
Production	Application Specialists System Administrators Content Contributors Knowledge Workers	A production portal is live and available to end users. Individual users with proper authorization can also customize their view. You can use WebCenter Portal administration to move portals and content to the production environment. Some back-end data must be moved manually. You can also use WLST commands for moving portals and content. Administrators can propagate portal changes in staging to production provided that the two environments are kept "in sync", that is, by always making changes in stage first and then pushing the changes to production using deployment or propagation. A portal in production can be modified whilst online in WebCenter Portal. However, changes made directly on the production server must be minimal.

27.2 What Are the Major WebCenter Portal Lifecycle Tasks?

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

27.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 27-2 provides a general list of these preliminary setup tasks and the environments to which they apply.

Table 27-2 Typical One-Time Setup Tasks

Setup Task	Development in JDeveloper (Assets and Shared Libraries only)	Development/Test in WebCenter Portal	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

27.2.2 Understanding WebCenter Portal Staging and Production Environments

This section discusses the staging and production phases of the WebCenter Portal lifecycle. Figure 27-1 illustrates the general flow from staging to production environments. 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. This also involves migration of the policy store, MDS data (application integration, REST endpoints, SQL data sources), and all WebCenter Portal data stored on the Content Server repository.

Subsequently, and once the production environment is live, you can propagate portal changes on production as and when required. Any new portals that are developed on stage can be individually deployed to production. Also, if required, you can redeploy existing portals.

You can manually move connections separately for all portals from one WebCenter Portal instance to another.

For information about the various lifecycle tasks that you perform on stage and production environments, see Lifecycle Tasks.

Note:

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

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

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

27.2.3 Lifecycle Tasks

Table 27-3 describes the tasks that you may need to perform in the WebCenter Portal lifecycle.

Table 27-3 Lifecycle Tasks

Lifecycle Task	Description	Tools Used	How To Do?
Migrate the entire portal instance	Once both staging and production environments are set up and configured, copy your WebCenter Portal instance on stage to the target for the first time.	Enterprise Manager Fusion Middleware Control Console WLST	Migrating Entire WebCenter Portal to Another Target
Deploy portals	Deploy portals directly to the target or create a portal archive and import it on the target. You can also export individual production portals to an archive and import them back to your staging site.	WebCenter Portal WLST	Deploying Portals
Deploy individual assets	You can share assets or migrate assets to other WebCenter Portal instances. You can also download assets and edit and extend them in tools such as Oracle JDeveloper, and then deploy them back to WebCenter Portal. Developers can deploy portal assets/extensions to WebCenter Portal directly from JDeveloper if they have the required permissions.	WebCenter Portal WLST	Deploying Portal Templates Deploying Assets
Propagate portal changes	You can propagate portal changes made in staging to production if your stage and production environments are connected and kept "in sync". In portal propagation, only the incremental changes made to a portal on the source are pushed to the target server.	WebCenter Portal WLST	Propagating and Redeploying Portals in Production
Redeploy portals	After initial deployment of a portal, you can choose to redeploy the portal to the target. When you redeploy a portal, it is deleted and re-created as a new portal.	WebCenter Portal WLST	Redeploying a Portal Using WebCenter Portal
Migrate connections	When you deploy a portal, its connection are also deployed. You can move connections for all portals separately from one WebCenter Portal instance to another.	WLST	Moving Connections Details from Staging to Production
Backup	To recover data from disasters, such as the loss of database hardware, inadvertent removal of data from file or database, it is important to back up individual portals as well as the entire WebCenter Portal instance on a frequent basis.	WebCenter Portal WLST	Backing Up Individual Portals Backing Up an Entire WebCenter Portal Installation
Recover	You can completely restore one or more portals or your entire WebCenter Portal installation from a backup archive.	WebCenter Portal WLST	Restoring Portals from a Backup Restoring an Entire WebCenter Portal Installation Restoring WebCenter Portal from Backups Using Scripts

27.3 Permissions Required to Perform WebCenter Portal Lifecycle Operations

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

Table 27-4 WebCenter Portal and WebLogic Server Permission Requirements for Lifecycle Operations

WebCenter Portal Object	Tool	WebLogic Server Role	WebCenter Portal Permission
WebCenter Portal (application level)
Import or export archive	Fusion Middleware Control	`Monitor` (or higher)	`Application: Manage`
Import or export archive	WLST	`Monitor` (or higher)	`Application: Manage`
Portal — Direct deployment/Archive import
Directly deploy a portal or import a portal archive	WebCenter Portal		`Portal Server – Deploy` (source) `Portals: Manage Configuration` (source) `Portals - Create Portals` (target)
Directly deploy a portal or import a portal archive	WLST	`Monitor` (or higher)	`Portal Server – Deploy` (source) `Portals: Manage Configuration` (source) `Portals - Create Portals` (target)
Redeploy or propagate a portal or re-import a portal archive	WebCenter Portal		`Portal Server – Deploy` (source) `Portals: Manage Configuration` (source) `Portals: Manage Security and Configuration` (target) `Portals - Create Portals` (target)
Redeploy or propagate a portal or re-import a portal archive	WLST	`Monitor` (or higher)	`Portal Server – Deploy` (source) `Portals: Manage Configuration` (source) `Portals: Manage Security and Configuration` (target) `Portals - Create Portals` (target)
Portal — Export an Archive
Export a portal archive	WebCenter Portal	-	`Portals: Manage Security and Configuration`
Export a portal archive	WLST	`Monitor` (or higher)	`Portals: Manage Security and Configuration`
Portal Template
Export or import a portal template archive	WebCenter Portal	-	`Portal Templates: Manage All`
Export or import a portal template archive	WLST	`Monitor` (or higher)	`Portal Templates: Manage All`
Portal Asset
Export or import an asset archive	WebCenter Portal/REST API	-	`Portal: Manage Configuration` And either: `Create, Edit, Delete Assets` `Create, Edit, Delete <Portal_Asset_Type>`
Export or import an asset archive	WLST	`Monitor` (or higher)	Either: `Create, Edit, Delete Assets` `Create, Edit, Delete <Portal_Asset_Type>`
Shared Library
Deploy portal extension directly from JDeveloper	JDeveloper	`Monitor` (or higher)	`Portals: Manage All`
WebCenter Portal Connections
Export or import all WebCenter Portal connections	WLST	`Operator` (or higher)	-
Shared Asset
Import or export asset archive	WebCenter Portal	-	`Application: Manage Configuration` `Create, Edit, Delete <Shared_Asset_Type>`
Import or export asset archive	WLST	`Monitor` (or higher)	`Create, Edit, Delete <Shared_Asset_Type>`

27.4 Managing Security Through the WebCenter Portal Lifecycle

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, 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 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 Backing Up and Restoring Policy Stores (LDAP and Database) and Backing Up and Restoring Credential Stores (LDAP and Database).