Skip Headers
Oracle® Fusion Middleware Developer's Guide for Oracle WebCenter
11g Release 1 (11.1.1.4.0)

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

Go to previous page
Previous
Go to next page
Next
View PDF

9 Understanding the Portal Life Cycle

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

9.1 What is the WebCenter Portal Life Cycle?

The portal life cycle refers to the path a portal takes from development through production. 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 nightly builds. The phases of the portal life cycle are described in Table 9-1.

Table 9-1 Portal Life Cycle Phases

Life Cycle Phase Primary Actors/Roles Description

Development

  • Developers

  • Content Modelers

  • Content Contributors

The development portal is primarily source control and file-based. Developers work locally in JDeveloper and deploy to the Integrated WebLogic server. The development portal typically employs test data and content. Some of the features that are developed in this phase of the life cycle include:

  • portlets

  • task flows

  • shared libraries

  • skins

  • navigation models

  • page templates

  • display templates

  • content models

  • data transfer and interportlet communication

  • security

The code from the development environment is built (usually nightly) and deployed to a clean, independent, targeted environment. WebCenter provides a build script that can be adapted for this purpose. See Section 9.7, "Configuring a Nightly Build Script."

Testing

  • Developers

  • QA Engineers

  • IT Administrators

The development portal is built (usually nightly) and deployed to an independent testing environment. The test environment typically includes a Metadata Service (MDS) and policy store that are database-based, and a dedicated UCM 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. See also Chapter 57, "Testing and Deploying Your Portlets."

Staging

  • Site Managers

  • IT 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 UCM server, as well as dedicated portlet producer server(s). The staging server is often maintained as a mirror of the production site.

Production

  • Site Managers

  • IT Administrators

  • Content Contributors

A production portal is live and available to end users. A portal in production can be modified with tools like the Resource Manager and Oracle Composer. For instance, an administrator might add additional portlets to a portal or reconfigure the contents of a portal.

Individual users with proper authorization can also customize their view. See Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.

WebCenter provides a propagation tool for migrating metadata to the production environment. See Section 9.13, "Using the Propagation Tool to Propagate From Staging to Production."

Content is provisioned using UCM replication tools. See Section 9.14, "Propagating UCM Content."

WebCenter provides WLST commands for importing and exporting portlet preferences. For more information, see Section 9.16, "Migrating Portlet Preferences."


9.2 What Are the Major 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.

9.2.1 One-Time Setup Tasks

You must perform certain preparatory steps to set up the development, build/test, stage, and production environments. Table 9-2 provides a general list of these preliminary setup tasks and the environments to which they apply. See also Section 9.7, "Configuring a Nightly Build Script" and Section 9.8, "Setting Up a Staging or Production Environment for the First Time."

Table 9-2 Typical One-Time Setup Tasks

Setup Task Development Build/Test Stage Production

Install JDeveloper

Yes

No

No

No

Install Oracle WebCenter

Yes

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 UCM

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

Create build scripts

Yes

No

No

No

Create deploy and configure scripts

No

No

Yes

Yes

Integrate/configure WebCenter Personalization Service (WCPS) *

Yes

Yes

Yes

Yes


* For more information on WebCenter Personalization Service (WCPS), see "Managing WebCenter Personalization" in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter and Chapter 62, "Personalizing WebCenter Applications."

Another technique for setting up an environment for the first time is to clone an existing instance. Typically, this strategy is used to clone a production instance from a stage instance. For detailed information on this "test to production" technique, see "Moving from a Test to a Production Environment" in the Oracle Application Server Administrator's Guide.

9.2.2 Development Environment Tasks

In a development environment, each developer has a local JDeveloper instance that is connected to a source control system and a shared UCM repository. Developers store metadata and code in source control. Portlets are deployed independently to a producer server and consumed by the portal.

In a development environment, developers typically build and run the application locally using the Integrated WebLogic Server. Both MDS and the Policy Store are file-based in the local development environment.

For more information, see Chapter 1, "Developer's Quick Start Guide," Chapter 3, "Preparing Your Development Environment," and Chapter 4, "Working Productively in Teams."

9.2.3 Nightly Build Environment Tasks

On a daily basis, developers work in JDeveloper and run code changes locally on the Integrated WebLogic Server, and code changes are checked into a source control system.

If you wish to set up a build environment that produces a clean environment that is built each night, there are certain tasks that must be performed with each build, including:

  • Creating schema (typically with Oracle Repository Creation Utility – RCU)

  • Creating and setting up the domain

  • Creating and configuring managed servers

  • Deploying the application

WebCenter provides sample build scripts that you can modify and use for your environment. See Section 9.7, "Configuring a Nightly Build Script." Nightly builds are usually made available to people within the organization, like QA engineers, technical writers, managers, and others. See also Section 9.4, "Understanding the Build and Test Environments."

For information on integrating WebCenter Personalization Service (WCPS) into your development environment, see Section 62.2, "Integrating WebCenter Personalization in Your Application."

9.2.4 Testing Environment Tasks

Usually, the testing environment is a mirror of the nightly build environment that is accessed by QA engineers. The tasks involved in providing a clean test environment are usually the same as creating a clean build environment. See also Section 9.4, "Understanding the Build and Test Environments."

9.2.5 Stage Environment Tasks

Runtime tools play a bigger role in the staging environment than in the development environment. Nonetheless, occasional updates from development will need to be deployed to the stage environment. To facilitate these more intermittent updates, WebCenter provides a set of deploy and configure scripts that you can copy and modify to suit your environment. The deploy and configure scripts isolate the information that is variable between environments, like the server names, ports, content management connections, and so on. For more information, see Section 9.5.1, "Provisioning the Staging Environment" and Section 9.11, "Deploying and Configuring the Application on Targeted Servers." See also Chapter 57, "Testing and Deploying Your Portlets."

For information on integrating and configuring WebCenter Personalization, see "WebCenter Personalization Prerequisites" in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.

9.2.6 Production Environment Tasks

When changes are tested and approved in the stage environment, they need to be pushed to the production environment. WebCenter provides a Propagation tool in the WebCenter Portal Administration Console that moves all portal metadata from the staging to the production server. For more information, see Section 9.13, "Using the Propagation Tool to Propagate From Staging to Production."

WebCenter provides WLST commands for importing and exporting portlet preferences. For more information, see Section 9.16, "Migrating Portlet Preferences."

9.3 Who Participates in the Portal Life Cycle?

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

9.4 Understanding the Build and Test Environments

Although developers typically build and run locally, an automated nightly build environment is recommended. The build environment represents a clean deployment of the portal application.

To set up the build environment, back end servers and connections must be installed and created once. For example, the build environment requires WebLogic Server instance, and typically includes access to an installed UCM instance. In addition, the build environment includes a database-based MDS and policy store.

Figure 9-1 illustrates the general flow from development to build to test environments.

Note:

Figure 9-1 does not depict all possible portal features. For example, WebCenter Personalization Service (WCPS) is not depicted in the diagram. For more information, see Section 9.12, "Building and Deploying WebCenter Personalization Service Files."

Figure 9-1 Flow from Development to Build to Test Environments

Description of Figure 9-1 follows
Description of "Figure 9-1 Flow from Development to Build to Test Environments"

A common practice is to use Ant-based build scripts to construct the EAR from source control and deploy it. The EAR includes metadata, code, and seeded policies. The build script also packages into the EAR metadata customizations made to portlets. See Section 9.7, "Configuring a Nightly Build Script." Some tasks performed by the build scripts include:

The best practice is to use UCM archive tools to move UCM test content and web assets between the environments. See Section 9.14, "Propagating UCM Content." For information on deploying portlets, see Chapter 57, "Testing and Deploying Your Portlets."

For information on integrating WebCenter Personalization Service (WCPS) into your development environment, see Section 62.2, "Integrating WebCenter Personalization in Your Application."

9.5 Understanding the Staging and Production Environments

This section discusses the staging and production phases of the portal life cycle. Figure 9-2 illustrates the general flow from staging to production environments.

Note:

Figure 9-2 does not depict all possible portal features. For example, WebCenter Personalization Service (WCPS) is not depicted in the diagram. For more information, see Section 9.12, "Building and Deploying WebCenter Personalization Service Files."

Figure 9-2 Flow from Staging to Production Environments

Description of Figure 9-2 follows
Description of "Figure 9-2 Flow from Staging to Production Environments"

9.5.1 Provisioning the Staging Environment

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 UCM server, as well as dedicated portlet producer server(s). For a list of typical setup tasks, see Table 9-2.

If you are setting up the staging environment for the first time, see Section 9.8, "Setting Up a Staging or Production Environment for the First Time." For information on making incremental changes to the staging environment, see Section 9.11, "Deploying and Configuring the Application on Targeted Servers."

If you wish, you can move UCM content and web assets between the testing and staging environment using UCM archive tools. See Section 9.14, "Propagating UCM Content." For information on migrating portlets, see Section 9.16, "Migrating Portlet Preferences."

For a complete list of requirements, dependencies, and options for WebCenter Personalization, see "WebCenter Personalization Prerequisites" in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.

9.5.2 Adding Content to the Staging Environment

Content developers can add content directly to the staging server using UCM content contribution tools and/or the Documents service. Content workflow features of UCM can be used to manage content approvals. WebCenter also provides runtime tools for creating and editing content. For example, you can:

  • Edit existing UCM region data files

  • Create new UCM region data files

  • Edit existing HTML content

  • Upload new images

In addition, the Documents service provides folder-based creation and editing of HTML content and other file types. See also Chapter 29, "Integrating the Documents Service."

9.5.3 Moving the 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. In a live production environment, you can make incremental updates to metadata, content, and web assets using automated scripts and/or replication techniques.

Typically, these updates are performed by a site manager rather than by individual content contributors. For more information, see Section 9.13, "Using the Propagation Tool to Propagate From Staging to Production."

Any content model or region definition changes can be pushed to the production server by the site manager. UCM Replication can be used to replicate content between the stage and production server. See Section 9.14, "Propagating UCM Content."

WebCenter provides WLST commands for importing and exporting portlet preferences. For more information, see Section 9.16, "Migrating Portlet Preferences."

9.6 Tools for Managing the Life Cycle

WebCenter is built on top of JDeveloper and Oracle ADF, which provide several benefits in the life cycle management of your application:

9.7 Configuring a Nightly Build Script

When you create a WebCenter Portal application, an Ant build script and properties file are created automatically for you in the main application directory on the filesystem. These files are:

Before running the build script, be sure JAVA_HOME and ANT_HOME environment variables are set properly. For example:

JAVA_HOME = /path_to_your_java_installation/jdk
ANT_HOME = /path_to_your_ant_installation

To build and deploy your application, use the ant target all. For example:

ant all

If you are using the WebCenter Personalization Server to provide personalization features for your portal, you must perform a manual update to the build.xml file. For details, see Section 9.12.1, "Building the WCPS MAR File."

9.8 Setting Up a Staging or Production Environment for the First Time

For detailed information on setting up and provisioning a staging or production environment for the first time, see "Moving Oracle WebCenter to a New Production Environment," in the Oracle Application Server Administrator's Guide. See also Section 9.15, "Managing Security Through the Life Cycle" for information on moving security policies and credentials to an environment for the first time.

9.9 Moving a WebCenter Portal Application to an Existing Environment

In this scenario, you have a working production environment with Oracle WebCenter installed and configured and you want to test changes in your applications or configuration before rolling those changes into the production environment. For example, you have modified existing security policies or configuration.

Oracle recommends that you use the deploy and configure scripts to update existing environment. Sample scripts are provided with WebCenter, and you are free to modify them to suit your environment. For detailed information, see Section 9.11, "Deploying and Configuring the Application on Targeted Servers" and Section 9.12, "Building and Deploying WebCenter Personalization Service Files."

WebCenter provides a Propagation tool that is built in to the WebCenter Portal Administration Console. The Propagation tool is for moving your application from the staging environment to the production environment. See Section 9.13, "Using the Propagation Tool to Propagate From Staging to Production."

For information on moving UCM content, see Section 9.14, "Propagating UCM Content."

For information on moving security policies and credentials, see Section 9.15, "Managing Security Through the Life Cycle."

For more information, see "Moving Oracle WebCenter to an Existing Production Environment," in the Oracle Application Server Administrator's Guide.

9.10 Deploying to Managed Servers

WebCenter Portal application developers working in JDeveloper typically deploy their application locally to the Integrated WebLogic Server. For other phases of the life cycle – testing, staging, and production – deployment to a suitable managed server is recommended. Or, for portlet development, you need to deploy to the Services Producer Managed Server. For more information on deploying to managed servers, see Section 64.3, "Deploying a WebCenter Portal Application to a WebLogic Managed Server." See also "Templates for WebCenter Portal or WebCenter Producer Applications" in the Oracle Fusion Middleware Installation Guide for Oracle WebCenter and "Creating and Provisioning a WebLogic Managed Server Instance" in Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.

9.11 Deploying and Configuring the Application on Targeted Servers

During its life cycle, a typical portal is deployed to testing, staging, and production servers. This section describes a technique for deploying and configuring a WebCenter portal application on a targeted server.

9.11.1 Introduction

WebCenter provides a configurable script that allows you to easily deploy and configure your application to these server instances. The build and deploy script takes a simple properties file parameter that specifies the server and connection information for the targeted server. You only need to create this properties file one time for each targeted server. Then, you execute the deploy and configure script with the appropriate properties file as a parameter.

Note:

The propagation tool, described in Section 9.13, "Using the Propagation Tool to Propagate From Staging to Production," is primarily used by site administrators to push approved site structure changes to production without incurring any downtime.

Tip:

The build and deploy script isolates the information that is variable between environments, like the server names, ports, content management connections, database connections, and so on. Most aspects of the WebCenter Portal application do not need to change when you redeploy it to another server. For example, the name of the application doesn't change.

9.11.2 Using the Deploy and Configure Script

The deploy and configure script described in this section is primarily used when the production application is mostly read only and live. In this scenario, content contributors make active changes to the staged application and receive content approval before that content is moved to production. Oracle recommends that you use automatic content replication so that content is moved from stage to production after appropriate workflow approvals. See Section 9.14, "Propagating UCM Content."

Security changes are not affected by the deploy and configure scripts. To push site structure changes to production, administrators can use the propagation tool, as described in Section 9.13, "Using the Propagation Tool to Propagate From Staging to Production." See also Section 9.15, "Managing Security Through the Life Cycle."

To deploy and configure your application to a target environment:

  1. In a terminal window, go to the directory that contains the deploy and configure scripts. These scripts are called: create_profile.csh and deploy_and_config.csh. These files reside in WEBCENTER_HOME/webcenter/scripts/stage2prod, where WEBCENTER_HOME is the directory where WebCenter is installed.

    Note:

    The deploy and configure scripts in stage2prod are samples only. You are free to develop your scripts in a different location (after copying the sample and making changes to it for your deployed environment).
  2. First, you need to provide some target environment-specific information in the setup.properties file, like the target server URL, user name, and password. Simply open the file setup.properties and add the appropriate values for the target environment. A sample file is shown in Example 9-1.

    Example 9-1 Sample setup.properties File

    # Adminserver
    admin.jmx.url=t3\://hostname\:7001
    admin.user=weblogic
    admin.password=welcome1
     
    # Application
    webcenter.app.name=webapp
    webcenter.app.server=WC_Spaces
    webcenter.app.version=V2.0
    
  3. Update the create_profile.csh and deploy_and_config.csh to reflect the deployed environment.

    setenv WC_HOME <webcenter_home>
    setenv SCRIPTS_DIR <scripts_home>
    

    WC_HOME is the WebCenter Home and SCRIPTS_DIR is where the scripts are located. By default, the scripts are here: $WC_HOME/webcenter/scripts/stage2prod. If you copied the scripts to another location, then set SCRIPTS_DIR to that location.

  4. Run the create_profile script. The input to this script is the setup.properites file. For example, in a Linux environment, enter:

    ./create_profile.sh setup.properties
    

    This script examines your application environment and produces an output properties file called profile.properties.

  5. If you wish, rename the output file, profile.properties to a name that reflects the target environment. For example, if the target environment is your stage environment, you might call the file output file wstage.properties.

    The profile.properties file specifies all the configuration information needed to run the portal on the target environment. For example, it includes settings for content management repository, omni portlet, WSRP producers, WebCenter Personalization server, and others. Example 9-2 shows a sample profile.properties file.

    Example 9-2 Sample profile.properties File

    webcenter.wcps.app.name=wcps-services
    webcenter.wcps.app.server=WC_Utilities
    admin.jmx.url=t3\://hostname\:7001
    doclib.Content.cis.socket.host=hostname
    app.mds.jndi=jdbc/mds/SpacesDS
    webcenter.app.archive=/net/hostname/scratch/webapp.ear
    doclib.Content.cis.socket.port=9444
    webcenter.wcps.archive=/net/hostname/scratch/wcps.mar
    webcenter.app.name=webapp
    admin.user=weblogic
    app.mds.repository=mds-SpacesDS
    app.mds.partition=wcps-services
    webcenter.app.version=V2.0
    web.OmniPortlet.url=http\://hostname\:7101/portalTools/omniPortlet/providers/omniPortlet
    app.restart=false
    webcenter.app.server=WC_Spaces
    

    Note:

    All properties in the profile.properties must have a value. If a property is not needed, delete it or comment it out rather than leave the value empty.
  6. Run create_profile to create a properties file for each of your target environments. For example, you might create one each for your test, stage, and production environments.

  7. Run the deploy-confg script. The input to this script is the profile.properties file (or whatever you renamed the file). For example, in a Linux environment, might enter:

    ./deploy_and_config.csh wcstage.properties
    

The deploy_and_config script takes one of two "modes" as input. These modes are deploy_config and p13n_metadata. For example:

./deploy_and_config.csh p13n_metadata

The deploy_config mode is the default mode if no input is passed to deploy_and_config.csh. The deploy_config mode does the deployment and configuration tasks. If you only need to update the update of personalization metadata, you can override the default behavior by passing in p13n_metadata as the input to the script.

This script deploys and configures the WebCenter Portal application to run on the target environment.

9.12 Building and Deploying WebCenter Personalization Service Files

This section explains how to build and deploy WebCenter Personalization Service (WCPS) files.

Note:

For information on integrating and configuring WebCenter Personalization, see "WebCenter Personalization Prerequisites" in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.

9.12.1 Building the WCPS MAR File

WebCenter provides an Ant task for building the WCPS MAR file. Oracle recommends that you add this task to your nightly build script if you are using WCPS.

  1. Create an Ant build script for your WebCenter Portal application. For details, see Section 9.7, "Configuring a Nightly Build Script."

  2. Open the build.xml file in an editor.

  3. Add an Ant target for the build-mar task to the build.xml file, as shown in Example 9-3.

    Note:

    The Ant task supports nested <fileset> elements to specify the locations under which to scan for scenario and namespace XML files. This element supports all the standard Ant fileset semantics. Table 9-3 illustrates the use of <fileset>.

    Example 9-3 Example deploy-wcps-mar Target Element

    <target name="build-wcps-mar">
    <taskdef name="build-mar"
            classname="oracle.wcps.tools.ant.BuildMARTask"
            uri="oracle:webcenter:wcps"> <classpath> <pathelement  path="${oracle.jdeveloper.home}/jdev/extensions/oracle.wcps.tools.common/oracle.wcps.tools.ant.jar"/>
    </classpath>
    </taskdef>
    <basename property="application.name"
             file="${oracle.jdeveloper.workspace.dir}"/>
    <wcps:build-mar xmlns:wcps="oracle:webcenter:wcps"
                   destFile="deploy/${application.name}-wcps.mar"
                   appName="${application.name}"
                   scenarionamespace="SomeThingElse"
                   failonfilescanerror="false" failonempty="true"> <fileset dir="${oracle.jdeveloper.workspace.dir}">
    <include name="Portal/**/*.xml"/>
    <exclude name="Portal/public_html/**"/>
    </fileset>
    </wcps:build-mar>
    </target>
    
  4. Add the task to the depends attribute on the all target. For example:

    <target name="all" depends="deploy,build-wcps-mar"/>
    
  5. Save the build.xml file.

This build-mar Ant task supports the attributes listed in Table 9-3.

Table 9-3 Attributes Supported by the Ant Task

Attribute Required Description

destfile

Yes

The location of the .mar file to write. It will be overwritten if it exists.

appname

Yes

The application name. Typically, the base name of the .jws file.

scenarionamespace

No

The scenario namespace. Defaults to the application name, same (just as JDeveloper does).

failonfilescanerror

No

(Boolean) Specifies whether to have the task fail the build if it cannot scan a specified file. Defaults to true.

fileonempty

No

(Boolean) Specifies whether to have the task fail the build if no WCPS files are found. Defaults to false.


Note that if you do not set failonfilescanerror="false", you might see errors similar to this one:

BUILD FAILED:
Unable to read C:\opt\jdev-applications\Application1\Model\classes\.data\00000000\00000000.jdb

Either narrow your file sets (for example, use *.xml) or specify failonfilescanerror="false", in which case it will just display a warning.

9.12.2 Deploying WCPS Files to a Server

To deploy WCPS files to a server:

  1. In JDeveloper, open your portal project. If you want to use WLST commands to perform this deployment, see Section 9.12.4, "Importing and Exporting MAR Files."

  2. From the Application menu, select Deploy Personalization Files and then select To Server.

  3. In the Deploy to Server dialog, select the server to which you want to deploy the service. See Figure 9-3.

    Figure 9-3 The Deploy To Server Dialog

    Description of Figure 9-3 follows
    Description of "Figure 9-3 The Deploy To Server Dialog"

    Note:

    Optionally, click the Add button to add a server to the list.
  4. Click the "..." button to select a specific server instance. For example, the running DefaultServer.

  5. Click OK when you are finished.

  6. Check, the Message - Log window for details on the deployment. The log will indicate if the deployment of the metadata files was completed successfully.

9.12.3 Deploying WCPS Files to an Archive File

You can deploy your WCSP files to a metadata archive (MAR) file on the file system. To deploy to a MAR file:

  1. In JDeveloper, open your portal project.

  2. From the Application menu, select Deploy Personalization Files and then select To Filesystem.

  3. In the Deploy to Filesystem dialog, select Create Metadata Archive and specify a location and name for the MAR file.

The MAR file can then be updated to the server using command line utilities described in Section 9.12.4, "Importing and Exporting MAR Files."

9.12.4 Importing and Exporting MAR Files

To update a WCPS server with new files from a Metadata Archive (MAR) file, use the following WLST commands to connect to the server and import the metadata.

wlst:> connect('<username>', '<password>', 't3://admin-server-hostname:7001')
wlst:> importMetadata(application='wcps-services', server='WC_Utilities', fromLocation='<mar file>', remote='true')

To export the WCPS from the server into a MAR file on the filesystem, use these WLST commands to connect to the server and export the metadata:

wlst:> connect('<username>', '<password>', 't3://admin-server-hostname:7001')
wlst:> exportMetadata(application='wcps-services', server='WC_Utilities', toLocation='<mar file>', remote='true')

For more information on MDS WLST commands, refer to the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference on the Oracle Technology Network.

If you're running on the IntegratedWebLogicServer in a development environment, the connect URL is t3://localhost:7101 and the server is DefaultServer.

9.13 Using the Propagation Tool to Propagate From Staging to Production

The WebCenter Portal Administration Console includes a propagation tool for moving portal metadata from a staging to a production server. Site administrators use this tool occasionally to push approved site structure changes to the production server without incurring any downtime.

Note:

The Propagation tool supports propagating portal metadata and WebCenter Personalization Server (WCPS) files. For more information, see Section 9.13.4, "Propagating WCPS Files."

Note:

WebCenter provides WLST commands for importing and exporting portlet preferences. Use these commands to replicate portlet preference data between the stage and production servers. For more information, see Section 9.16, "Migrating Portlet Preferences."

9.13.1 Introduction to the Propagation Tool

WebCenter provides a propagation tool to move a portal metadata from staging to production. In practice, the staging environment and the production remain identical until changes are made to the staged portal. When the changes are tested and approved, an administrator uses the propagation tool to "push" the changes to the production server. This transfer does not require the production server to be restarted.

When properly configured, the Propagation tool shows up as a tab in the WebCenter Portal Administration Console, as shown in Figure 9-4.

Figure 9-4 The Propagation Tab

Description of Figure 9-4 follows
Description of "Figure 9-4 The Propagation Tab "

The Label History part of the Propagation tab lists the labels that were created for each propagation, labels created outside of the Propagation tab, such as labels created during deployment and labels created using WLST. Each label includes a list of files that change since the last propagation was performed. To view the contents of a label, click the arrow button to the left of the label name, as shown in Figure 9-5.

Figure 9-5 The Propagation Tab with Labels Opened

Description of Figure 9-5 follows
Description of "Figure 9-5 The Propagation Tab with Labels Opened"

9.13.2 Configuring the Propagation Tool

Note:

If you are using the Propagation tool and if any of the MDS document file names contain multi-byte NLS characters, the stage machine should be configured for that NLS.

The Propagation tab only shows up in the WebCenter Portal Administration Console if the portal deployed to the staging server has a URL Connection configured. This URL connection must point to the production server and it must be named ProductionURLConnection.

You have two choices for configuring the URL Connection: you can use Oracle Enterprise Manager or Oracle WebLogic Scripting Tool (WLST). This section explains both techniques.

9.13.2.1 Configuring the URL Connection With Oracle Enterprise Manager

To configure the URL Connection with Oracle Enterprise Manager:

  1. In a browser, open Oracle Enterprise Manager for your staging server domain. For details on starting Oracle Enterprise Manager, see Oracle Enterprise Manager Administrator's Guide.

  2. In the navigation tree, open the Application Deployments folder and then open the Internal Applications folder.

  3. In the Internal Applications folder, click on the application, as shown in Figure 9-6.

    Figure 9-6 Selecting the Application in Enterprise Manager

    Description of Figure 9-6 follows
    Description of "Figure 9-6 Selecting the Application in Enterprise Manager"

  4. In the Create Connection box, select the URL connection type and enter ProductionURLConnection as the Connection Name. See Figure 9-7.

    Note:

    You must name the connection ProductionURLConnection. The name is case sensitive.

    Figure 9-7 Create Connection

    Description of Figure 9-7 follows
    Description of "Figure 9-7 Create Connection"

  5. In the URL Connections box, click Edit.

  6. Complete the URL Connection dialog box as follows.

    • URL – Enter the URL (including hostname and port number) of the production server.

    • Username – Enter a username for the connection.

    • Password – Enter a password for the connection.

    • Authentication Realm – You must enter a value for the Authentication Realm. Do not leave this field blank. You can enter any arbitrary string, such as ProductionRealm.

      You can accept the default values for the remaining fields. See Figure 9-8.

      Figure 9-8 URL Connection Dialog

      Description of Figure 9-8 follows
      Description of "Figure 9-8 URL Connection Dialog"

  7. Click OK after you complete the URL Connection dialog.

  8. Click Apply in the upper-right corner of the Enterprise Manager window.

9.13.2.2 Configuring the URL Connection with WLST

You can use a Oracle WebLogic Scripting Tool (WLST) command to create the URL Connection. Note that the parameters to the command are equivalent to the values entered in the URL Connection dialog in Enterprise Manager, described in the previous section, Section 9.13.2.1, "Configuring the URL Connection With Oracle Enterprise Manager."

The following is an example of the WLST command with sample values specified for each parameter. Replace these values with values that pertain to your production server:

adf_createHttpURLConnection(appName='portalApp', name='ProductionURLConnection', url='http://production_adminserver_host:7001', user='weblogic', password='password_for_weblogic', realm='ProductionRealm'

For information on WLST, see the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference on the Oracle Technology Network.

9.13.3 Propagating Portal Metadata

Use the propagation tool when you want to move changes made on the staging portal to the production portal.

  1. Be sure the propagation tool is configured, as described in Section 9.13.2, "Configuring the Propagation Tool." To use the propagation tool, you must have Administrator's privileges.

  2. Open the WebCenter Portal Administration Console. By default, the administration console is located at this URL:

    http://<server>:<port>/<context_root>/admin
    

    For more information on using the WebCenter Portal Administration Console, see "Using the WebCenter Portal Administration Console" in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.

  3. Select the Propagation tab.

    Note:

    If you don't see the Propagation tab it could be because you don't have administrator's privileges or the propagation tool was not configured properly as explained in Section 9.13.2, "Configuring the Propagation Tool."
  4. Click Propagate to transfer the files to the production server.

9.13.4 Propagating WCPS Files

The propagation tool supports moving WebCenter Personalization Service (WCPS) files from staging to production. The propagation tool automatically exports metadata from the application's MDS repository on the source server, then imports the metadata to the application's MDS repository on the target server.

The ability for the propagation tool to move WCPS files depends on the following conditions:

  • The WebCenter Portal application's MDS repository must point to the same database as the mds-wcpsDS datasource. This is the default configuration. See, for example, Figure 9-2 for a general illustration. In general, propagation will work correctly if you do not change the default database configuration.

  • On both the source and destination servers, the application's MDS store must use the same partition name as the MDS store for wcps-services. In a standard portal configuration, this partition is webcenter-portal.

    Note:

    Typically, there is a one to two minute delay between when the propagation tool is initialized and when the WCPS REST services are notified of the MDS changes. This delay does not occur when you use the WLST commands to propagate WCPS files, as explained in Section 9.12.4, "Importing and Exporting MAR Files."

9.14 Propagating UCM Content

Oracle recommends that you use either manual or automated replication to move content from one environment to another. Another option is to manually propagate content; however, this option is only recommended if the source and target servers are unable to communicate with each other.

For detailed information on the tools and options for propagating UCM content, see "Managing System Migration and Archiving" in the Oracle Fusion Middleware System Administrator's Guide for Oracle Content Server. That chapter explains how to propagate UCM content by exporting and importing archive files. In addition, the chapter explains how to set up and use replication. Replication can automate the export, import, and transfer functions. For example, you can use replication to automatically export from one content server instance, transfer the archive to another computer, and import to another content server instance.

9.15 Managing Security Through the Life Cycle

This section discusses techniques for migrating security policies and credentials from one environment to another. Migration can be either automatic or manual. Automatic migration is typically used when the application is first deployed. Manual migration is used on redeployment.

9.15.1 Migrating Security Policies for First-Time Deployment

When jazn-data.xml with application policies is packaged in the EAR file, Oracle Platform Security Services (OPSS) performs policy migration based on the application configuration settings in weblogic-application.xml. Example 9-4 shows the recommended settings in weblogic-application.xml to achieve automatic policy migration for first-time deployment.

Example 9-4 Settings for Automatic Policy Migration (weblogic-application.xml)

<wls:application-param>
    <wls:param-name>jps.policystore.migration</wls:param-name>
    <wls:param-value>MERGE</wls:param-value>
</wls:application-param>
 
<wls:application-param>
    <wls:param-name>jps.policystore.removal</wls:param-name>
    <wls:param-value>OFF</wls:param-value>
</wls:application-param>
 
<wls:listener>
    <wls:listener-class>oracle.security.jps.wls.listeners.JpsApplicationLifecycleListener</wls:listener-class>
</wls:listener>

JpsApplicationLifecycleListener must be specified in weblogic-application.xml to enable policy and credential migration. Oracle recommends that jps.policystore.migration should be set to MERGE. With this configuration, polices packaged in jazn-data.xml will be always migrated during fist time deployment. Oracle also recommends that jps.policystore.removal should be set to OFF so that application policies are not deleted from the policy store when the application is undeployed.

9.15.2 Migrating Security Policies On Redeployment

On redeployment, it is important to avoid overwriting policy changes made on the production system. When jps.policystore.migration parameter is set to MERGE, all new policies from the stage environment will be merged with production policies. With this setting, any changes made to existing policies, such as changing permissions for a role, deleting a role, or removing membership of a role, will not be migrated during redeployment, because such migration would cause a conflict.

If you want to overwrite the production policies with the staging environment security policies packaged in jazn-data.xml, use the migrateSecurityStore WLST command. See Oracle Fusion Middleware Application Security Guide for details on migrateSecurityStore command.

9.15.3 Migrating Credentials for First-Time Deployment

Application credential migration support is similar to application policy migration. JpsApplicationLifecycleListener supports credential migration in application deployment and redeployment with extra security enforcements.

With application credentials in cwallet.sso and packaged in an EAR file in the META-INF/ directory, OPSS will perform credential migration to system credential store based on the configuration settings in weblogic-application.xml.

Example 9-4 shows the recommended settings in weblogic-application.xml to achieve automatic credential migration for first-time deployment.

Example 9-5 Settings for Automatic Credential Migration (weblogic-application.xml)

<wls:application-param>
    <wls:param-name>jps.credstore.migration</wls:param-name>
    <wls:param-value> MERGE </wls:param-value>
</wls:application-param>

Oracle recommends that jps.credstore.migration should be set to MERGE so that at deployment and redeployment time all new credentials will be migrated. This setting will only migrate new credential key/value from cwallet.sso. Modification done to existing credential keys will not be migrated.

9.15.4 Migrating Credentials On Redeployment

If credentials are modified on stage and need to be moved to production, use the command migrateSecurityStore to migrate modified credentials. See Oracle Fusion Middleware Application Security Guide for details on migrateSecurityStore command.

9.16 Migrating Portlet Preferences

WebCenter provides WLST commands for importing and exporting portlet preferences. Exported preferences (customizations and personalizations) can be imported into a target application – for example, exported from the staging application and imported into the production application. For more information, see exportPortletClientMetadata and importPortletClientMetadata in "Oracle WebCenter Custom WLST Commands" in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference. Also ensure that export and import are enabled. See Chapter 56, "Coding Portlets."

See also Chapter 57, "Deploying a Portlet Application to an Oracle WebLogic Managed Server Instance."