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

Part Number E12405-15
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

7 Deploying WebCenter Applications

This chapter provides instructions for deploying, undeploying, and redeploying WebCenter Portal applications from an Enterprise Archive, or EAR file, created with Oracle JDeveloper (for information on how to create an EAR file, see "How to Create Deployment Profiles in Oracle JDeveloper" in the Oracle Fusion Middleware Developer's Guide for Oracle WebCenter). It does not contain instructions for deploying or installing Oracle WebCenter Spaces. For information about installing Oracle WebCenter Spaces and other WebCenter components, see "Installing Oracle WebCenter" in the Oracle Fusion Middleware Installation Guide for Oracle WebCenter. For information about deploying WSRP and PDK-Java portlet producer applications, see Section 23.8, "Deploying Portlet Producer Applications."

This chapter includes the following sections:

Audience

The content of this chapter is intended for Fusion Middleware administrators (users granted the Admin or Deployer role through the Oracle WebLogic Server Administration Console). See also, Section 1.8, "Understanding Administrative Operations, Roles, and Tools."

7.1 Deploying WebCenter Portal Applications

This section describes the steps required to deploy a WebCenter Portal application created in JDeveloper to a production domain. The deployment steps in this section assume that you are deploying an EAR file, know its location, and that the domain to which you want to deploy exists.

For information on how to create a WebLogic Server domain, see "Creating a New Domain" in the Oracle Fusion Middleware Installation Guide for Oracle WebCenter. For more information about deploying applications, see Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server.

This section includes the following topics:

7.1.1 Deployment Roadmap

The flow chart and table in this section provide an overview of the prerequisites and tasks required to deploy a WebCenter Portal application to an Oracle WebLogic Managed Server. Figure 7-1 shows the steps to deploy a WebCenter Portal application, and the roles that will carry them out.

Figure 7-1 Deploying a WebCenter Portal Application to a Managed Server

Description of Figure 7-1 follows Packaging the application Selecting the data source Package application security data Create deployment profiles Prepare the target environment Create and provision the Managed Server Create and register the MDS repository Configure the target environment Create the server connection Deploy the application to the Managed Server Deploy with Fusion Middleware Control Deploy with WLST Deploy with WLS Admin Console
Description of "Figure 7-1 Deploying a WebCenter Portal Application to a Managed Server"

Table 7-1 shows the tasks, sub-tasks and who will need to carry them out to deploy a WebCenter portal application from JDeveloper.

Table 7-1 Deploying a WebCenter Portal Application to a Managed Server

Actor Task Sub-task Notes

Developer

1. Package the Application

1.a Select the data source type (package database connections)

You can use either a global data source or an application-level data source.

If using a global data source, then you need to create the data source in the WLS Administration Console before deploying.

If using an application-level data source, then you need to add credential mappings in the WLS Administration Console after deploying.

   

1.b Package application security data

This sub-task consists of packaging the credentials, identity data, and application policies.

   

1.c Create deployment profiles

This sub-task consists of creating the WAR and EAR files.

Administrator

2. Prepare the Target Environment

2.a Create and provision the Managed Server

 
   

2.b Create and register the MDS repository

 
   

2.c Configure the target environment

 
   

2.d Create the server connection

 

Developer

3. Deploy the Application to a Managed Server

 

The final step is to deploy the application to the Managed Server using either Fusion Middleware Control, WLST, or the WLS Admin Console.


7.1.2 Deployment Prerequisites

You can deploy WebCenter Portal applications to any WebLogic Managed Server instance that is provisioned with the Oracle WebCenter libraries.

Note:

Oracle does not recommend deploying WebCenter Portal applications to any of the preconfigured Managed Servers created during the installation, or to the Administration Server. For WebCenter applications created in JDeveloper, follow the process described in "Extending an Existing Domain" in the Oracle Fusion Middleware Installation Guide for Oracle WebCenter to create and provision a new WLS Managed Server before deploying. For portlet producer applications, you can optionally create a new WebLogic Managed Server or deploy to the WC_Portlet server.

Before deploying, you must:

Note:

You must delete runtime customizations (customizations not done through JDeveloper) before deploying an updated application that has had major changes to artifacts such as pages, connections, or task flows.

After completing these steps, continue by deploying the application as described in Section 7.1.6, "Deploying the Application to a WebLogic Managed Server."

7.1.3 Preparing the Application EAR File

Before you deploy an application, you must first create a deployment profile. The deployment profile packages or archives the WebCenter Portal application and its associated files so that the application can be deployed to an Oracle WebLogic Managed Server as an EAR file.

For information on how to create a deployment profile (and the resulting EAR file) for an application, see "Packaging and Deploying a WebCenter Portal Application to a WebLogic Managed Server" in the Oracle Fusion Middleware Developer's Guide for Oracle WebCenter.

7.1.3.1 EAR File Contents

The EAR file packages multiple information artifacts, which include:

  • The application itself: the physical pieces of the application such as .jspx, .jar, and .class files.

  • Application Configuration – which contains the URL endpoints and properties of connections to services and producers that are configured for this application.

  • Application Metadata – which is an export of the application metadata created during the design time of the application.

  • Portlet Customizations – which contain customization settings and data for portlets. This information is maintained within the producer, but is exported when an application with registered producers is packaged. This customization data is packaged with the rest of the metadata of a WebCenter Portal application.

7.1.4 Creating a Managed Server

Before deploying a WebCenter Portal application, you must create a WebLogic Managed Server based on the "Oracle WebCenter Custom Portal" template that contains all the required shared libraries and a MDS Repository. If a WebCenter Portal application has been portletized it should be deployed to the Oracle WebCenter Custom Services Producer server (WC_CustomServicesProducer). A portletized application cannot be deployed to the Oracle WebCenter Custom Portal server as it lacks the required portlet libraries. Note that the Oracle WebCenter Custom Services Producer and Oracle WebCenter Custom Portal servers have not only the MDS schema targeted to them but also WebCenter and Activities.

For instructions on how to create a new managed server, see "Extending an Existing Domain" in the Oracle Fusion Middleware Installation Guide for Oracle WebCenter. For instructions on how to create a new domain, see "Creating a New Domain" in the Oracle Fusion Middleware Installation Guide for Oracle WebCenter.

7.1.5 Creating and Registering the Metadata Service Repository

Before deploying an application to a Managed Server, you may need to create and register a Metadata Service (MDS) repository schema for the application on the WebLogic Domain's Administration Server instance. The target server (Oracle WebCenter Custom Portal server or Oracle WebCenter Custom Services Producer server) already has the MDS data source configured, so this step is only required if you do not want to use the pre-configured server MDS data source. Do not, however, create a new MDS schema if it is being shared by other applications.

Caution:

If you deploy using an MDS schema that was created during the WebCenter installation instead of using a custom schema as described in this section, you risk damaging data in those schemas.

At deployment time, some configuration information and application metadata exported into the EAR file must be imported into a MDS schema for use in the production environment. Importing the metadata occurs automatically during deployment when you select a target metadata schema (as explained in Section 7.1.6, "Deploying the Application to a WebLogic Managed Server").

You create the MDS schema using the Repository Creation Utility (RCU). After creating the MDS schema, you must register it using either Fusion Middleware Control, or from the command line using WLST.

This section contains the following subsections:

7.1.5.1 Creating an MDS Schema Using the Repository Creation Utility

Before you deploy an application, you must first create the MDS schema on a database server instance using the Repository Creation Utility (RCU), and then register it on the administration server for the domain to which you're deploying so that the application's metadata can also be deployed.

When following these instructions, be sure to note the MDS schema name and the login credentials for accessing it. You need this information for subsequent steps in the deployment process.

To create the MDS schema:

  1. Navigate to RCU_HOME/bin and start the RCU with the following command:

    rcu
    

    The RCU Welcome page displays (see Figure 7-2).

    Figure 7-2 RCU Welcome Page

    Description of Figure 7-2 follows
    Description of "Figure 7-2 RCU Welcome Page"

  2. Click Next.

  3. Select Create and click Next.

    The Database Connection Details page displays (see Figure 7-3).

    Figure 7-3 Database Connection Details Page

    Description of Figure 7-3 follows
    Description of "Figure 7-3 Database Connection Details Page"

  4. Provide the connection details for the database to which to add the schema by selecting the Database Type, entering the Host Name, Port, Service Name, Username and Password and clicking Next.

  5. Click OK when prompted by the Prerequisites pop-up.

    The Select Components page displays (see Figure 7-4).

    Figure 7-4 Select Components Page

    Description of Figure 7-4 follows
    Description of "Figure 7-4 Select Components Page"

  6. Check Create a New Prefix and enter a prefix to be prepended to the schema name.

  7. Check the Metadata Services component. All other components should be left unchecked.

  8. Click Next, and click OK when prompted by the Prerequisites pop-up.

    The Schema Passwords page displays (see Figure 7-5).

    Figure 7-5 Schema Passwords Page

    Description of Figure 7-5 follows
    Description of "Figure 7-5 Schema Passwords Page"

  9. Select how the schema password should be applied, and enter and confirm the password.

  10. Click Next.

  11. On the Map Tablespaces page, click Next

  12. When prompted to create the tablespaces, click OK, and then click OK again when the operation is complete.

  13. On the Summary page, click Create to create the schema.

  14. On the Completion Summary page that indicates the successful completion of creating the schema, click Close.

7.1.5.2 Registering an MDS Schema Using Fusion Middleware Control

Before you deploy your application, you must first register the new MDS schema with the domain so that applications running on the Managed Server can access it.

To register an MDS repository using Fusion Middleware Control:

  1. Open Fusion Middleware Control and log in to the target domain.

    For information on logging into Fusion Middleware Control, see Section 6, "Starting Enterprise Manager Fusion Middleware Control."

  2. In the Navigation pane, expand the farm, then WebLogic Domain.

  3. Select the domain to which you want to deploy.

  4. From the WebLogic Domain menu, select Metadata Repositories.

    The Metadata Repositories page displays (see Figure 7-6).

    Figure 7-6 Metadata Repositories Page

    Description of Figure 7-6 follows
    Description of "Figure 7-6 Metadata Repositories Page"

  5. In the Database-Based Repositories section, click Register.

    The Register Database-Based Metadata Repository page displays (see Figure 7-7).

    Figure 7-7 Register Database-based Metadata Repository Page

    Description of Figure 7-7 follows
    Description of "Figure 7-7 Register Database-based Metadata Repository Page"

  6. In the Database Connection section, enter the following information:

    • Database - select the type of database.

    • Host Name - enter the name of the host.

    • Port - enter the port number for the database (for example, 1521).

    • Service Name - enter the service name for the database. The default service name for a database is the global database name, comprising the database name, such as orcl, and the domain name, such as example.com. In this case, the service name would be orcl.example.com.

    • User Name - enter a username for the database which is assigned the SYSDBA role (for example, SYS).

    • Password - enter the password for the user.

    • Role - select a database role (for example, SYSDBA).

  7. Click Query.

    A table is displayed that lists the schemas and their metadata repositories that are available in the database.

  8. Select a repository, then enter the following information:

    • Repository Name - enter a name for the MDS schema.

    • Schema Password - enter the schema password you specified when you created the schema.

  9. Click OK.

    The repository is registered with the Oracle WebLogic Server domain.

7.1.5.3 Registering an MDS Schema Using WLST

You can also use WLST to register a database-based MDS repository from the command line using the registerMetadataDBRepository command.

To register an MDS schema using WLST:

  1. Start WLST as described in Section 1.13.3.1, "Running Oracle WebLogic Scripting Tool (WLST) Commands."

  2. Register the MDS schema using the following command:

    registerMetadataDBRepository(name='mds_name', dbVendor='db_vendor', host='host_name', port='port_number',
    dbName='db_name', user='username', password='password', targetServers='target_server')
    

    Where:

    • mds_name is the name of the MDS schema to register.

    • db_vendor is the vendor of the database being used.

    • host_name is the fully qualified server name of the database server of the Database Server.

    • port_number is the port number of the Database Server.

    • db_name is the name of the database being used to store the MDS.

    • username is the database schema user name.

    • password is the database schema password.

    • target_server is the name of the target server. For multiple targets, separate the target server names with a comma. Be sure to include the WLS administration server in the list of targets so that the MDS database repository name appears in the Deployment Plan dialog when you deploy your application to it.

    For example, to register the MDS schema mds1 on the Oracle database orcl on the target server server1 with the host ID of example.com, you would use the following command:

    registerMetadataDBRepository(name='mds1', dbVendor='ORACLE', host='example.com', 
    port='1521',dbName='orc1', user='username', password='password',  targetServers='server1','AdminServer')
    

7.1.6 Deploying the Application to a WebLogic Managed Server

For WebCenter applications created in JDeveloper, follow the process described in "Extending an Existing Domain" in the Oracle Fusion Middleware Installation Guide for Oracle WebCenter to create and provision a new Oracle WebCenter Custom Portal server, or if portletized, Oracle WebCenter Custom Services Producer server before deploying.

Table 7-2 Deployment Targets

Application Type Managed Server Name

WebCenter Portal application

WC_CustomPortal

Portletized WebCenter Custom Portal

Oracle WebCenter Custom Services Producer

Non-WebCenter Portal Portlet Producer application

WC_Portlet

For portlet producer applications, you can either create a Managed Server instance or deploy to the WC_Portlet server.


Note:

Oracle does not recommend deploying WebCenter Portal applications to any of the preconfigured Managed Servers created during the installation, or to the Administration Server.

WebCenter Portal applications can be deployed in several ways as described in the following sections:

7.1.6.1 Choosing the Information Artifact Store

As explained in Section 7.1.3, "Preparing the Application EAR File," the packaged EAR file consists of several information artifacts, which includes the application binaries, the application configuration, the application metadata, and the portlet customizations.

During the deployment, these information artifacts must be moved to the right information store in the instance where application is deployed. The target information stores for these artifacts are as described in Table 7-3:

Table 7-3 Information Artifact Target Stores

Information Artifact Target Information Store

Application Binaries

Target Server Instance

Application Configuration

MDS

Application Metadata

MDS

Portlet Customizations

Target Producer


Regardless of the tool you choose to deploy, you must supply the target information store locations for correct deployment. The application deployment fails if the MDS location is incorrect or not supplied. The application will still deploy, however, if the target producer is incorrectly specified. If you incorrectly specify the target producer, the portlets are not imported automatically and, consequently, are not operational. If that happens, do one of the following:

Note:

If the application is deployed and the target producer is incorrectly specified but the target exists, the portlets are imported but to the wrong producer and the portlets are not operational.

7.1.6.2 Choosing the Data Source

There are three basic options for data sources:

  • Deploying to a WebCenter Custom Portal Managed Server using pre-existing data sources

  • Deploying to a Managed Server using global data sources not named WebCenterDS or ActivitiesDS

  • Deploying to a Managed Server using local application context data sources of any name

This section describes the benefits and drawbacks of each of these options:

Deploying to a WebCenter Custom Portal Managed Server using pre-existing data sources

This option requires the least effort in enabling a WebCenter Custom Portal application to access the required data sources, and is the recommended deployment path.

To deploy using pre-existing data sources, deselect the Auto Generate and Synchronize weblogic-jdbc.xml Descriptors During Deployment check box on the the Application Properties Deployment screen in JDeveloper.

If your application has existing database connections configured for WebCenterDS and/or ActivitiesDS and these are not named "webcenter/CustomPortal" and "activities/CustomPortal" respectively, either the database connections should be deleted from the application prior to deployment, or the database connections should be created and named following the naming convention.

Deploying to a Managed Server using global data sources not named WebCenterDS or ActivitiesDS

Use this deployment path when the application is not intended to run on a Managed Server created with the WebCenter Custom Portal template, or is intended to run against custom data sources not named "WebCenterDS" or "ActivitiesDS".

For this option the WebCenter Custom Portal application should have had database connections created and associated as either the WEBCENTER or ACTIVITIES schema. The Auto Generate and Synchronize weblogic-jdbc.xml Descriptors During Deployment check box on the Application Properties Deployment screen in JDeveloper should be deselected. The global data sources intended to be used on the WLS server requires them to be created with the JNDI names matching those of the database connections created for the application in the JDeveloper project. For more information, see Creating a JDBC Data Source on OTN.

Deploying to a managed server using local application context data sources of any name

Use this deployment path if the application local context data sources are sufficient.

This choice requires only that the WebCenter Custom Portal application has a database connection created for and associated with WebCenterDS and/or ActivitiesDS (depending on which services are being used in the application). The Application Properties Deployment screen in JDeveloper should have the Auto Generate and Synchronize weblogic-jdbc.xml Descriptors During Deployment check box selected.

7.1.6.3 Deploying Applications Using Oracle JDeveloper

You can deploy WebCenter Portal applications to a WebLogic server instance directly from a development environment using Oracle JDeveloper, if you have the necessary credentials to access the WebLogic server. For more information, see "Creating a WebLogic Managed Server Connection" and "Deploying a WebCenter Portal Application to a Managed Server" in the Oracle Fusion Middleware Developer's Guide for Oracle WebCenter.

7.1.6.4 Deploying Applications Using Fusion Middleware Control

When deploying a WebCenter Portal application using Fusion Middleware Control you must know the location of the WebCenter application archive, and whether a deployment plan exists for the application. See Section 7.1.6.7, "Saving and Reusing the Deployment Plan" for more information about deployment plans.

Note:

Metadata repository and ADF connection details specified during deployment are not stored as part of the deployment plan. You will need to specify these deployment properties each time you deploy the application.

If you plan on updating and deploy the application frequently and want to maintain these configuration changes, it is recommended that you make those configuration changes post-deployment using WLST or Fusion Middleware Control. Such configuration changes are saved in the deployment plan and persisted in the MDS repository and do not need to be set again when you redeploy the application.

To deploy a WebCenter Portal application using Fusion Middleware Control:

  1. Log in to Fusion Middleware Control.

    See Section 6.1, "Displaying Fusion Middleware Control Console."

  2. In the Navigation pane, expand WebLogic Domain and click the domain in which your target Managed Server was created.

  3. From the WebLogic Domain menu, select Application Deployment > Deploy.

    The Select Archive page displays (see Figure 7-8).

    Figure 7-8 Select Archive Page

    Description of Figure 7-8 follows
    Description of "Figure 7-8 Select Archive Page"

  4. In the Archive or Exploded Directory section, do one of the following:

    • Select Archive is on the machine where this web browser is running and enter the location of the archive or click Browse to find the archive file.

    • Select Archive or exploded directory is on the server where Enterprise Manager is running and enter the location of the archive or click Browse to find the archive file.

  5. In the Deployment Plan section, do one of the following:

    • Select Create a new deployment plan when deployment configuration is done to automatically create a new deployment plan after the redeployment process.

    • Select Deployment plan is on the machine where this web browser is running and enter the path to the plan or click Browse to find the plan.

    • Select Deployment plan is on the server where Enterprise Manager is running and enter the path to the plan or click Browse to find the plan.

  6. Click Next.

    The Select Target page displays (see Figure 7-9).

    Figure 7-9 Select Target Page

    Description of Figure 7-9 follows
    Description of "Figure 7-9 Select Target Page"

  7. Select the target server(s) to deploy the application to (see Section 7.1.6, "Deploying the Application to a WebLogic Managed Server" for an overview of selecting the targets) and click Next.

    The Application Attributes page displays (see Figure 7-10).

    Figure 7-10 Application Attributes Page

    Description of Figure 7-10 follows
    Description of "Figure 7-10 Application Attributes Page"

  8. Under Target Metadata Repository, click the icon to display the Select metadata repository window, from where you can select the repository for the application, as shown in Figure 7-11. Use the Repository dropdown to select the required repository and then click OK.

    Note:

    The Target Metadata Repository option only displays if the application has metadata to be imported into the MDS repository. This option does not display for a portlet producer application.

    Figure 7-11 Select Metadata Repository Window

    Description of Figure 7-11 follows
    Description of "Figure 7-11 Select Metadata Repository Window"

  9. Enter the name of the partition to use in the repository (typically, the name of the application). Each application must have a unique partition in the repository.

  10. Click Next.

    The Deployment Settings page displays (see Figure 7-12).

    Figure 7-12 Deployment Settings Page

    Description of Figure 7-12 follows
    Description of "Figure 7-12 Deployment Settings Page"

    You have now provided the Target MDS location (described in Section 7.1.6, "Deploying the Application to a WebLogic Managed Server").

  11. Click the edit icon for Configure ADF Connections to check connection settings associated with the WebCenter Portal application.

    The Configure ADF Connections page displays (see Figure 7-13).

    Figure 7-13 Configure ADF Connections Page

    Description of Figure 7-13 follows
    Description of "Figure 7-13 Configure ADF Connections Page"

  12. Click the edit icon for each connection and check that the connection settings are correct for the target environment (for example, staging or production).

    For a Discussion Forum connection (shown in Figure 7-14), for example, ensure that the URL to the Discussions server, and the user account used to connect to the server are correct for the target environment.

    Figure 7-14 Discussion Forum Connection Settings

    Description of Figure 7-14 follows
    Description of "Figure 7-14 Discussion Forum Connection Settings"

    For WSRP producers, two connections are shown for each producer: a WSRP Producer and a Web Service connection. Typically only the Web Service connection must be changed to the target producer, and this contains four URL endpoints, all of which must be changed. The WSRP Producer connection only configures proxy settings that can be set independent of the default proxy setting for the application server, if this is required.

    If any connections to portlet producers in the EAR file must be changed to point to producers in the target deployment environment, it is important to change them here. This ensures the portlet customizations are imported to the target producers as the application starts. For more information, see Section 7.1.6, "Deploying the Application to a WebLogic Managed Server".

    Note:

    If any target producers are not reachable as the application starts for the first time, the import fails. After the portlet producer becomes reachable, restart the application and try to import again.

    If you do not modify producer connections using the Configure ADF Connections page and they are pointing to incorrect but reachable producer locations (for example, a producer in a development environment), portlets are imported to the incorrect producers.

    To remedy, after deployment use Fusion Middleware Control (see Section 23.2.1, "Registering a WSRP Producer Using Fusion Middleware Control" and Section 23.4.1, "Registering an Oracle PDK-Java Producer Using Fusion Middleware Control") or WLST commands (see Section 23.2.2, "Registering a WSRP Producer Using WLST" or Section 23.4.2, "Registering an Oracle PDK-Java Producer Using WLST") to modify the producer URL endpoint, and then redeploy the application as described in Section 7.3.2, "Redeploying WebCenter Applications Using Fusion Middleware Control".

  13. If required, specify additional deployment options such as the Web modules to include in your application or security migration settings.

  14. In the Deployment Plan section, click Edit Deployment Plan to optionally edit the currently selected Deployment Plan.

  15. In the Deployment Plan section, click Save Deployment Plan to optionally save the currently selected Deployment Plan for reuse when you redeploy the application.

  16. To start the deployment process, click Deploy.

    Fusion Middleware Control displays processing messages.

  17. Click Close in the Deployment Succeeded page.

    The WebCenter application (and its deployment plan) is now deployed on the WebLogic Managed Server instance.

  18. If you restart the WebLogic Managed Server on which you deployed the application during your Fusion Middleware Control session, refresh the Farm from the Farm menu to update the application status.

    Note:

    If you configured connections during deployment these are not stored as part of the deployment plan. You must specify these connection details again the next time you deploy.

7.1.6.5 Deploying Applications Using WLST

To deploy a WebCenter Portal application using the WLST command line, WLST must be connected to the Administration Server. You must invoke the deploy command on the computer that hosts the administration server.

To deploy a WebCenter Portal application using WLST:

  1. Start the WLST shell.

    For information on starting the WLST shell, see Section 1.13.3, "Oracle WebLogic Scripting Tool (WLST)."

  2. Connect to the Administration Server of your WebCenter installation:

    connect("user_name","password","host_id:port")
    

    Where:

    • user_name is the user name to access the Administration server (for example, weblogic).

    • password is the password to access the Administration server (for example, weblogic).

    • host_id is the host ID of the Administration Server (for example, myserver.example.com).

    • port is the port number of the Administration Server (7001 by default)

      You should see the following message:

      Successfully connected to Admin Server 'AdminServer' that belongs to domain 'wc_domain'.
      
  3. Retrieve the MDS configuration by running the following command:

    archive = getMDSArchiveConfig(fromLocation='ear_file_path') 
    

    where ear_file_path is the path and file name of the EAR file you are deploying (for example, /tmp/myEarFile.ear). For more information, see the getMDSArchiveConfig command in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

  4. After retrieving the MDS configuration information from the EAR file, you must set the proper MDS schema information according to your WebCenter setup (for example, your application might be using a database connection based on a specific schema). To set the MDS schema information, run the following command:

    archive.setAppMetadataRepository(repository='respository',partition='partition',type='DB',jndi='jndi')
    

    Where:

    • repository is the name of the database schema (for example, mds-Feb23demo)

    • partition is the individual entity in the repository to allow each application to have its own namespace (for example, webcenter).

    • jndi is the path and name used to allow access by the application server's other components (for example, jdbc/mds/Feb23demo)

  5. After setting the MDS repository information, save function the MDS configuration information with the following command:

    archive.save()
    
  6. Deploy the WebCenter Portal application using the WLST deploy command.

    deploy(app_name, path, [targets] [stageMode], [planPath], [options])
    

    Where:

  • appName is the name of the WebCenter Portal application to be deployed (for example, composerWLSTApp).

  • path is the path to the EAR file to be deployed (for example, /tmp/customApp.ear).

  • targets specifies the target Managed Server(s) to which to deploy the application (for example, CustomAppServer). You can optionally list multiple comma-separated targets. To enable you to deploy different modules of the application archive on different servers, each target may be qualified with a module name, for example, module1@server1. This argument defaults to the server to which WLST is currently connected.

  • [stageMode] optionally defines the staging mode for the application you are deploying. Valid values are stage, nostage, and external_stage.

  • [planPath] optionally defines the name of the deployment plan file. The file name can be absolute or relative to the application directory. This argument defaults to the plan/plan.xml file in the application directory, if one exists.

  • [options] is an optional comma-separated list of deployment options, specified as name-value pairs. For more information about valid options, see the WLST deploy command in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

When you see the following message, the application has been successfully deployed and is ready to be accessed:

Completed the deployment of Application with status completed

Note:

Since WLST does not prompt you to modify connections during deployment, the connection information in the EAR file is used to identify the target producer location in the last start-up. If that location is unreachable, correct the location after deploying the application by bringing up the target producers and restarting the application. Migration of portlet customizations starts automatically.

If the producer connections point to incorrect producers (for example, development producers), and those producers are reachable, the migration of portlet customizations starts using those producers. Since the migration completes, although incorrectly, restarting the application does not automatically restart the migration process.

To remedy this, after deployment, use Fusion Middleware Control (see Section 23.2.1, "Registering a WSRP Producer Using Fusion Middleware Control" and Section 23.4.1, "Registering an Oracle PDK-Java Producer Using Fusion Middleware Control") or WLST commands (see Section 23.2.2, "Registering a WSRP Producer Using WLST" or Section 23.4.2, "Registering an Oracle PDK-Java Producer Using WLST") to modify the producer URL endpoint, and then redeploy the application as described in Section 7.3.2, "Redeploying WebCenter Applications Using Fusion Middleware Control."

7.1.6.6 Deploying Applications Using the WLS Administration Console

You can use the WLS Administration Console to deploy a WebCenter Portal application or a portlet producer application. However, the Console does not offer a means to change ADF connections, including the essential MDS connection. To use the Console to deploy a WebCenter application, the MDS connection in the EAR file must be configured to the target deployment repository. Follow steps 1-5 in Section 7.1.6.5, "Deploying Applications Using WLST", then follow the steps below to deploy a WebCenter Portal application or portlet producer application using the WLS Administration Console.

Note:

Oracle does not recommend deploying WebCenter Portal applications to any of the preconfigured Managed Servers created during the installation, or to the Administration Server. For WebCenter applications created in JDeveloper, follow the process described in "Extending an Existing Domain" in the Oracle Fusion Middleware Installation Guide for Oracle WebCenter to create and provision a new WLS Managed Server before deploying. For portlet producer applications, you can create a Managed Server instance, or optionally deploy to the WC_Portlet server.

To deploy a WebCenter Portal application or portlet producer application using the WLS Administration Console:

  1. Log in to the WLS Administration Console.

    For information on logging into the WLS Administration Console, see Section 1.13.2, "Oracle WebLogic Server Administration Console."

  2. In the Domain Structure pane, click Deployments.

    The Deployments Summary pane displays (see Figure 7-15).

    Figure 7-15 Deployment Summary Pane

    Description of Figure 7-15 follows
    Description of "Figure 7-15 Deployment Summary Pane"

  3. On the Deployment Summary pane, click Install.

    The Install Application Assistant page displays (see Figure 7-16).

    Figure 7-16 Install Application Assistant Page

    Description of Figure 7-16 follows
    Description of "Figure 7-16 Install Application Assistant Page"

  4. Using the Install Application Assistant Path field, locate the EAR file that corresponds to the Web application or portlet producer application you want to install. Select the EAR file and click Next.

    Page 2 of the Install Application Assistant page displays (see Figure 7-17).

    Figure 7-17 Install Application Assistant - Page 2

    Description of Figure 7-17 follows
    Description of "Figure 7-17 Install Application Assistant - Page 2"

  5. Select Install this deployment as an application (for both WebCenter Portal applications and portlet producers) and click Next.

    Page 3 of the Install Application Assistant displays (see Figure 7-18).

    Figure 7-18 Install Application Assistant - Page 3

    Description of Figure 7-18 follows
    Description of "Figure 7-18 Install Application Assistant - Page 3"

  6. Select the deployment target to which to deploy the Web application and click Next.

  7. Review the configuration settings you specified, and click Finish to complete the installation.

    To change a producer URL after deployment, use Fusion Middleware Control (see Section 23.2.1, "Registering a WSRP Producer Using Fusion Middleware Control" and Section 23.4.1, "Registering an Oracle PDK-Java Producer Using Fusion Middleware Control") or WLST commands (see Section 23.2.2, "Registering a WSRP Producer Using WLST" or Section 23.4.2, "Registering an Oracle PDK-Java Producer Using WLST") to modify the producer URL endpoint, and then redeploy the application as described in Section 7.3.2, "Redeploying WebCenter Applications Using Fusion Middleware Control."

7.1.6.7 Saving and Reusing the Deployment Plan

A deployment plan contains the configuration data needed to deploy an archive to a Managed Server. You can create a deployment plan while you're building and testing your application, or when you deploy your EAR file using Fusion Middleware Control as described in Section 7.1.6.4, "Deploying Applications Using Fusion Middleware Control." If there are deployment descriptors packaged within the EAR file, the deployment uses the data in these files. If you need to make any changes to the web.xml file, Oracle recommends that you create a deployment plan.

Once created, a deployment plan can be saved as part of the application properties on the target Managed Server, and re-used when redeploying the application using Fusion Middleware Control, as described in Section 7.3.2, "Redeploying WebCenter Applications Using Fusion Middleware Control," or using WLST as described in Section 7.3.3, "Redeploying WebCenter Applications Using WLST."

7.1.7 Migrating Customizations and Data Between Environments

You can export and import customizations made to pages, WebCenter Services, and portlets (PDK-Java and WSRP version 2 producers) of a deployed application. For more information, see Chapter 37, "Exporting and Importing WebCenter Portal Applications for Data Migration."

7.1.8 Configuring Applications to Run in a Distributed Environment

For information about configuring your WebCenter Portal application to run in a distributed environment, see the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle WebCenter, and "Configuring High Availability for Oracle ADF and WebCenter Applications" in the Oracle Fusion Middleware High Availability Guide.

7.2 Undeploying WebCenter Portal Applications

This section describes how to undeploy a WebCenter Portal application or portlet producer application using Fusion Middleware Control, or from the command line using WLST.

Note:

When a WebCenter Portal application is undeployed, its application credentials and MDS customizations are kept in case the application is redeployed to the same domain. If the application will not be redeployed in this domain, or if it is important to reset these back to initial conditions before the next deployment, then after undeploying an application you can remove the application's credential map from the Credential Store as described in Section 7.2.3, "Removing an Application's Credential Map." You can also remove the MDS repository partition as described in "Deleting a Metadata Partition from a Repository" in the Oracle Fusion Middleware Administrator's Guide.

This section contains the following subsections:

7.2.1 Undeploying WebCenter Applications Using Fusion Middleware Control

This section describes how to undeploy a WebCenter Portal application using Fusion Middleware Control.

To undeploy a WebCenter Portal application using Fusion Middleware Control:

  1. Log in to Fusion Middleware Control.

    See Section 6.1, "Displaying Fusion Middleware Control Console."

  2. From the Navigation pane, expand Application Deployments, then click the application that you want to undeploy.

  3. From the Application Deployment menu, select Application Deployment > Undeploy.

  4. On the confirmation page, click Undeploy.

  5. When the operation completes, click Close.

7.2.2 Undeploying WebCenter Applications Using WLST

This section describes how to undeploy a WebCenter Portal application using WLST.

To undeploy a WebCenter Portal application using WLST:

  1. Start the WLST shell.

    For information on starting the WLST shell, see Section 1.13.3, "Oracle WebLogic Scripting Tool (WLST)."

  2. Connect to the Administration Server of your WebCenter installation:

    connect("user_name","password","host_id:7001")
    

    Where:

    • user_name is the user name to access the administration server (for example, weblogic).

    • password is the password to access the administration server (for example, weblogic).

    • host_id is the host ID of the administration server (for example, myserver.example.com).

      You should see the following message:

      Successfully connected to Admin Server 'AdminServer' that belongs to domain 'wc_domain'.
      
  3. Use the undeploy command to undeploy the application:

    undeploy(app_name,[targets],[options])
    

    Where:

    • app_name is the deployment name for the deployed application.

      [targets] is a list of the target servers from which the application will be removed. Optional. If not specified, defaults to all current targets.

    • [options] is a comma-separated list of deployment options, specified as name-value pairs. Optional. See the deploy command for a complete list of options.

7.2.3 Removing an Application's Credential Map

When a WebCenter Portal application is undeployed, its application credentials are not removed. Consequently, you must manually remove the credential map used for the application after it is undeployed using Fusion Middleware Control.

To remove an application's credentials map using Fusion Middleware Control:

  1. Determine the credentials map name used by the application by inspecting the contents of the application's adf-config.xml and locating the value for adfAppUID. For example:

    <adf:adf-properties-child xmlns="http://xmlns.oracle.com/adf/config/properties">
    <adf-property name="adfAppUID" value="Veeva-7209"/>
    </adf:adf-properties-child>
    

    In this case, Veeva-7209 is the credential map name used by the application.

  2. Log in to Fusion Middleware Control.

    For information on logging into Fusion Middleware Control, see Section 6, "Starting Enterprise Manager Fusion Middleware Control."

  3. In the Navigation pane, expand the WebLogic Domain node and click the target domain (for example, wc_domain).

  4. From the WebLogic Domain dropdown menu, select Security > Credentials.

    The Credentials pane displays (see Figure 7-19).

    Figure 7-19 Credentials Pane

    Description of Figure 7-19 follows
    Description of "Figure 7-19 Credentials Pane"

  5. Select the credential map to remove and click Delete.

  6. Click Yes to confirm deleting the credential map.

7.3 Redeploying WebCenter Portal Applications

This section describes how to redeploy a WebCenter Portal application using Fusion Middleware Control or from the command line using WLST. When you redeploy a new version of an application, you cannot change:

To change deployment targets or application security settings, you must first undeploy the active version of the application. For information on how to undeploy an application, see Section 7.2, "Undeploying WebCenter Portal Applications".

This section contains the following subsections:

7.3.1 Redeployment Considerations

In most cases, when redeploying an application, you want to preserve any changes to application data. Three important pieces of information about an application can be altered after deployment during run-time:

  • Application Configuration -- which includes connection information.

  • Application Metadata -- which includes the customizations and personalizations on the application itself, such as those created when user edits a page and adds content to it.

  • Portlets Preferences-- which includes customizations and personalizations of the portlet instances.

Note:

You must delete runtime customizations (customizations not done through JDeveloper) before redeploying an updated application that has had major changes to artifacts such as pages, connections, or task flows.

The following subsections explain how to preserve these three types of information about an application:

Note:

To preserve application information, you must redeploy using the same MDS partition that was used or created using the initial deployment.

7.3.1.1 Preserving Application Configuration

In most cases, the end-points of services and portlet-producers are different in a test or staging environment than in a production environment. Therefore, when an application is redeployed to a production environment, you must reconfigure the application to work with the production environment services and producers or reuse the configuration used previously. Fusion Middleware facilitates this by storing the configuration information in the MDS repository.

When you deploy the application for the first time, the base document of the application configuration is created in the MDS repository. This configuration is the set of all of the application's connections and their properties that are packaged in the EAR file. After the deployment, you may need to modify the connections using Fusion Middleware Control or WLST in response to production needs. This reconfiguration creates a layer of customization for the configuration changes in the MDS repository.

When you redeploy the application, the configuration packaged with the application is laid down as the base document, but the customizations to the configuration are preserved. Therefore, the application's redeployment settings match the most recent configuration performed.

However, customizations are completely preserved only when there are no changes in the base document. If you redeploy an application where the packaged connection information has changed, the following can be expected:

  • A new connection is added to the packaged configuration. The new connection should display without problems.

  • A connection has been removed in the packaged configuration. If you configured this connection after the last deployment, then the connection does not display after deployment, and you must re-create it.

  • A connection property has been changed in the packaged configuration. The customized properties are used. Connection customizations are managed at the individual connection level, and not at the properties level.

7.3.1.1.1 Preserving Configuration Across Deployment Using WLST

If you use WLST commands to configure the WebCenter Portal application, you can easily combine them into a script to remove all the connections and re-create them for the configuration of the production instance. Using this approach, you can always reconfigure an application to the target configuration without worrying about the details in the packaged configuration.

7.3.1.2 Preserving Service and User Customizations

Application metadata can change post-deployment due to customizations done by users at run time. When you redeploy the application, in most circumstances, you must preserve this customization information so that users see exactly what they were seeing before.

Application and user customizations are stored in the MDS repository, and the same rules apply for preserving application metadata as for preserving configuration settings.

When the application is redeployed, the base documents for all application artifacts are replaced with what is packaged in the EAR file. However, customizations are retained. There is no impact to this information unless the base artifact is changed, in which case the same rules apply as for configuration settings, which are:

  • If new elements are added to the package, then they appear as they are.

  • If elements are removed from the package, for which customizations were created, those customizations are ignored.

  • If elements are changed, then the effect depends on what exactly is changed, but must be verified.

Best Practice Note:

In some cases, you may want to export all application and user customizations in a production application instance and import it into a test or staging instance. You can then test the application against those customizations to see that the new changes do not have an undesired impact.

7.3.1.3 Preserving Portlet Customizations

Portlet customizations are packaged with the metadata in the EAR file. Application startup after deployment kicks off the portlet customization migration to the target producers. The target producers are identified by resolving connection customizations. If you have modified your producer connections before redeployment, then those modified connections are used to identify target producers. Note that if you redeploy an EAR file with the same checksum (that is, the same file) as the pre-existing one, portlet customization and personalizations are not overwritten.

7.3.2 Redeploying WebCenter Applications Using Fusion Middleware Control

This section describes how to redeploy a WebCenter Portal application using Fusion Middleware Control.

To redeploy a WebCenter Portal application using Fusion Middleware Control:

  1. Log in to Fusion Middleware Control. For more information, see Section 6.1, "Displaying Fusion Middleware Control Console."

  2. From the Navigation pane, expand the farm, then WebLogic Domain, and then the domain.

  3. Select the server to which to redeploy the application, and then right click and select Application Deployment - Redeploy from the menu.

    The Select Application page displays (see Figure 7-20).

    Figure 7-20 Select Application Page

    Description of Figure 7-20 follows
    Description of "Figure 7-20 Select Application Page"

  4. Select the application that you want to redeploy.

  5. Click Next to display the Select Archive page (see Figure 7-21).

    Figure 7-21 Select Archive Page

    Description of Figure 7-21 follows
    Description of "Figure 7-21 Select Archive Page"

  6. In the Archive or Exploded Directory section, do one of the following:

    • Select Archive is on the machine where this web browser is running and enter the location of the archive or click Browse to find the archive file.

    • Select Archive or exploded directory is on the server where Enterprise Manager is running and enter the location of the archive or click Browse to find the archive file.

  7. In the Deployment Plan section, do one of the following:

    • Select Create a new deployment plan when deployment configuration is done to automatically create a deployment plan after the redeployment process.

    • Select Deployment plan is on the machine where this web browser is running and enter the path to the plan or click Browse to find the plan.

    • Select Deployment plan is on the server where Enterprise Manager is running and enter the path to the plan or click Browse to find the plan.

  8. Click Next.

    The Application Attributes page displays (see Figure 7-22).

    Figure 7-22 Application Attributes Page

    Description of Figure 7-22 follows
    Description of "Figure 7-22 Application Attributes Page"

  9. In the Context Root of Web Modules section, specify the context root for your application if you have not specified it in application.xml. The context root is the URI for the web module. Each web module or EJB module that contains web services may have a context root.

  10. In the Target Metadata Repository section, select the MDS repository and enter the Partition.

    Caution:

    Be careful to use the same repository connection and partition name that you used when you originally deployed the application. If you do not, all customizations are lost.
  11. Click Next.

    The Deployment Settings page displays (see Figure 7-23).

    Figure 7-23 Deployment Settings Page

    Description of Figure 7-23 follows
    Description of "Figure 7-23 Deployment Settings Page"

  12. On this page, you can perform common tasks before deploying your application, such as configuring connections, or you can edit the deployment plan or save it to a disk. You can:

    • Configure web modules

    • Configure application security for application roles and policies

    • Configure ADF connection settings

  13. Click the edit icon for Configure ADF Connections to check connection settings associated with the WebCenter Portal application.

    Note:

    Editing ADF Connections is only necessary for connections not set after a prior deployment. Any connections configured after a prior deployment will override settings you make during this step.

    The Configure ADF Connections page displays (see Figure 7-24).

    Figure 7-24 Configure ADF Connections Page

    Description of Figure 7-24 follows
    Description of "Figure 7-24 Configure ADF Connections Page"

  14. Click the edit icon for each connection and check that the connection settings are correct for the target environment (for example, staging or production).

    For a Discussion Forum connection (shown in Figure 7-14), for example, ensure that the URL to the discussions server, and the user account used to connect to the server are correct for the target environment.

    Figure 7-25 Discussion Forum Connection Settings

    Description of Figure 7-25 follows
    Description of "Figure 7-25 Discussion Forum Connection Settings"

  15. If required, specify additional deployment options such as the Web modules to include in your application or security migration settings.

  16. Expand Deployment Plan.

    The Deployment Plan settings display (see Figure 7-26).

    Figure 7-26 Deployment Settings Page - Deployment Plan Section

    Description of Figure 7-26 follows
    Description of "Figure 7-26 Deployment Settings Page - Deployment Plan Section"

    You can edit and save the deployment plan to your local hard drive, if you choose, so that you can use those settings to redeploy the application again later. See Section 7.1.6.7, "Saving and Reusing the Deployment Plan" for more information about deployment plans.

  17. Click Redeploy.

  18. When the redeployment completes, click Close.

    Note:

    If you restart the WebLogic Managed Server on which you deployed the application during your Fusion Middleware Control session, refresh the Farm from the Farm menu to update the application status.

7.3.3 Redeploying WebCenter Applications Using WLST

To redeploy a WebCenter Portal application using the WLST command line, WLST must be connected to the administration server. You must invoke the redeploy command on the computer that hosts the administration server.

To redeploy a WebCenter Portal application using WLST:

  1. Start the WLST shell.

    For information on starting the WLST shell, see Section 1.13.3, "Oracle WebLogic Scripting Tool (WLST)."

  2. Connect to the administration server of your WebCenter installation:

    connect("user_name","password","host_id:port")
    

    Where:

    • user_name is the user name to access the administration server (for example, weblogic).

    • password is the password to access the administration server (for example, weblogic).

    • host_id is the host ID of the administration server (for example, myserver.example.com).

    • port is the port number of the Administration Server (7001 by default).

      You should see the following message:

      Successfully connected to Admin Server 'AdminServer' that belongs to domain 'wc_domain'.
      
  3. Use the redeploy command to redeploy the application:

    redeploy(app_name,[planPath],[options])
    

    Where:

    • app_name is the deployment name for the application to redeploy.

    • [planPath] Name of the deployment plan file. The filename can be absolute or relative to the application directory. Optional. This argument defaults to the plan/plan.xml file in the application directory, if one exists.

    • [options] is a comma-separated list of deployment options, specified as name-value pairs. Optional. See the deploy command for a complete list of options.

7.4 Post-Deployment Configuration

After your WebCenter Portal application is deployed, you must check that the settings that were deployed are valid for the target Managed Server. Settings to check include those for security, connections, and data sources.

This section includes the following subsections:

7.4.1 Checking Security Configurations After Deployment

Before deploying your application you must set up the Identity Store and the Policy and Credential Store on the target Managed Server. After deployment, check that the application configurations match those of the target server. You should also check that all other applicable post-deployment security configurations, such as SSL and single sign-on, have been properly configured, as described in Section 27.2.5, "Post-deployment Security Configuration Tasks."

7.4.2 Checking Application Connections After Deployment

After deploying your WebCenter Portal application, check that all of the connections used by your application have been properly set. Connections that you may have to configure or reconfigure include connections for:

  • BPEL Worklists

  • External applications

  • Discussions server

  • Mail server

  • Instant Messaging and Presence (IMP) server

  • Search

  • WSRP producers

  • PDK-Java portlet producers

  • Web Services

  • content repositories

  • personal event server

  • analytics collector

7.4.3 Checking Data Source Connections

After deploying your WebCenter Portal application to a custom Managed Server, check that the data sources that you configured during testing are still valid for the deployed application. For information on how to configure data sources for the Metadata Services (MDS) repository your WebCenter Portal application, see "Configuring JDBC Data Sources" in Oracle Fusion Middleware Configuring and Managing JDBC for Oracle WebLogic Server. Note that when setting up the data source, you must provide a password or the connection may not be created when the application is deployed.

7.4.4 Tuning the Application

After your WebCenter Portal application has been deployed and correctly configured, check the system file limit, data source settings, and JRockit virtual machine (JVM) arguments as described in Section A.4, "Tuning Oracle WebCenter Performance." Also see the chapter on "Oracle WebCenter Performance Tuning" in the Oracle Fusion Middleware Performance and Tuning Guide, and Section 36, "Monitoring Oracle WebCenter Performance" for information on how to diagnose performance problems.