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

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

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

42 Deploying Portal Framework Applications

This chapter provides instructions for deploying, undeploying, and redeploying Portal Framework applications from an Enterprise Archive, or EAR file, created with Oracle JDeveloper.

For information on how to create an EAR file, see the "Deploying a Portal Framework Application to a WebLogic Managed Server" section in Oracle Fusion Middleware Developing Portals with Oracle WebCenter Portal and Oracle JDeveloper.

This chapter does not contain instructions for deploying or installing Oracle WebCenter Portal's out-of-the box portal application "WebCenter Portal". For information about installing WebCenter Portal and its related components, see the "Installing Oracle WebCenter Portal" chapter in Oracle Fusion Middleware Installation Guide for Oracle WebCenter Portal. For information about deploying WSRP and PDK-Java portlet producer applications, see Section 21.11, "Deploying Portlet Producer Applications."

Permissions:

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

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

42.1 Deploying Portal Framework Applications

This section describes the steps required to deploy a Portal Framework 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 the "Creating a New Domain" section in Oracle Fusion Middleware Installation Guide for Oracle WebCenter Portal. For more information about deploying applications, see Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server.

This section includes the following topics:

42.1.1 Deployment Roadmap

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

Figure 42-1 Deploying a Portal Framework Application to a Managed Server

Description of Figure 42-1 follows
Description of "Figure 42-1 Deploying a Portal Framework Application to a Managed Server"

Table 42-1 shows the tasks, sub-tasks and who will need to carry them out to deploy a Portal Framework application from JDeveloper.

Table 42-1 Deploying a Portal Framework 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

 

Administrator

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.


42.1.2 Deployment Prerequisites

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

Note:

Oracle does not recommend deploying Portal Framework applications to any of the preconfigured Managed Servers created during the installation, or to the Administration Server. For Portal Framework applications, follow the process described in the "Extending an Existing Domain" section in Oracle Fusion Middleware Installation Guide for Oracle WebCenter Portal to create and provision a new WLS Managed Server before deploying applications. 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 42.1.6, "Deploying the Application to a WebLogic Managed Server."

42.1.3 Preparing the Application EAR File

Before you deploy an application, you must first create a deployment profile. The deployment profile packages the Portal Framework 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 the "Packaging a Framework Application" section in Oracle Fusion Middleware Developing Portals with Oracle WebCenter Portal and Oracle JDeveloper.

42.1.3.1 EAR File Contents

The EAR file packages multiple information artifacts, which include:

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

  • Application Configuration – which contains the URL endpoints and properties of connections to tools and 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 Portal Framework application.

42.1.4 Creating a Managed Server

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

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

42.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 Portal Custom Portal server or Oracle WebCenter Portal 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 the MDS schema that was created during the WebCenter Portal 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 the 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 42.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:

42.1.5.1 Creating the 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 42-2).

    Figure 42-2 RCU Welcome Page

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

  2. Click Next.

  3. On the Create Repository page, select Create, and then click Next.

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

    Figure 42-3 Database Connection Details Page

    Description of Figure 42-3 follows
    Description of "Figure 42-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 42-4).

    Figure 42-4 Select Components Page

    Description of Figure 42-4 follows
    Description of "Figure 42-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 under AS Common Schemas. 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.

  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.

42.1.5.2 Registering the 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 the 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 42-5).

    Figure 42-5 Metadata Repositories Page

    Description of Figure 42-5 follows
    Description of "Figure 42-5 Metadata Repositories Page"

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

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

    Figure 42-6 Register Database-based Metadata Repository Page

    Description of Figure 42-6 follows
    Description of "Figure 42-6 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.

42.1.5.3 Registering the 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 the 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.

    • 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 name 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')
    

42.1.6 Deploying the Application to a WebLogic Managed Server

Table 42-2 lists the Managed Servers to which you can deploy your various applications.

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

Table 42-2 Deployment Targets

Application Type Managed Server Name

Portal Framework applications

WC_CustomPortal

WebCenter Portal Portlet Producer applications

WC_CustomServicesProducer

Non-WebCenter Portal Portlet Producer applications

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 Portal Framework applications to any of the preconfigured Managed Servers created during the installation, or to the Administration Server.

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

42.1.6.1 Choosing the Information Artifact Store

As explained in Section 42.1.3, "Preparing the Application EAR File," the packaged EAR file consists of several information artifacts, which includes application binaries, application configuration, application metadata, and 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 42-3:

Table 42-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.

42.1.6.2 Choosing the Data Source

There are three basic options for data sources:

  • Deploying to Oracle WebCenter Portal's 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 Oracle WebCenter Portal's Custom Portal Managed Server using pre-existing data sources

This option requires the least effort in enabling a Portal Framework 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 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 Oracle WebCenter Custom Portal template, or is intended to run against custom data sources not named "WebCenterDS" or "ActivitiesDS".

For this option the Portal Framework 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 the "Creating a JDBC Data Source" section in Oracle Fusion Middleware Configuring and Managing JDBC Data Sources for Oracle WebLogic Server.

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 Portal Framework application has a database connection created for and associated with WebCenterDS and/or ActivitiesDS (depending on which tools and 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.

42.1.6.3 Deploying Applications Using Oracle JDeveloper

You can deploy Portal Framework 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 the "Creating a WebLogic Managed Server Connection" and "Deploying a Portal Framework Application to a Managed Server" sections in Oracle Fusion Middleware Developing Portals with Oracle WebCenter Portal and Oracle JDeveloper.

42.1.6.4 Deploying Applications Using Fusion Middleware Control

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

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 to update 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 Portal Framework 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 42-7).

    Figure 42-7 Select Archive Page

    Description of Figure 42-7 follows
    Description of "Figure 42-7 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 42-8).

    Figure 42-8 Select Target Page

    Description of Figure 42-8 follows
    Description of "Figure 42-8 Select Target Page"

  7. Select the target server(s) to deploy the application and click Next.

    The Application Attributes page displays (see Figure 42-9).

    Figure 42-9 Application Attributes Page

    Description of Figure 42-9 follows
    Description of "Figure 42-9 Application Attributes Page"

  8. Under Target Metadata Repository, click the icon to display the Metadata Repositories window, from where you can select the repository for the application, as shown in Figure 42-10. Use the Repository drop-down list 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 42-10 Select Metadata Repository Window

    Description of Figure 42-10 follows
    Description of "Figure 42-10 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 42-11).

    Figure 42-11 Deployment Settings Page

    Description of Figure 42-11 follows
    Description of "Figure 42-11 Deployment Settings Page"

    You have now provided the Target MDS location (described in Section 42.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 Portal Framework application.

    The Configure ADF Connections page displays (see Figure 42-12).

    Figure 42-12 Configure ADF Connections Page

    Description of Figure 42-12 follows
    Description of "Figure 42-12 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 42-13), 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 42-13 Discussion Forum Connection Settings

    Description of Figure 42-13 follows
    Description of "Figure 42-13 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 42.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 correct this, after deployment use Fusion Middleware Control (see Section 21.2.1, "Registering a WSRP Producer Using Fusion Middleware Control" and Section 21.4.1, "Registering an Oracle PDK-Java Producer Using Fusion Middleware Control") or WLST commands (see Section 21.2.2, "Registering a WSRP Producer Using WLST" or Section 21.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 42.3.2, "Redeploying Portal Framework 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 Portal Framework 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.

42.1.6.5 Deploying Applications Using WLST

To deploy a Portal Framework 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 Portal Framework 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 Oracle WebCenter Portal installation:

    connect("user_name","password","host_name: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_name is the host name 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 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 Oracle WebCenter Portal 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 the MDS configuration information with the following command:

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

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

    Where:

  • appName is the name of the Portal Framework 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 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 21.2.1, "Registering a WSRP Producer Using Fusion Middleware Control" and Section 21.4.1, "Registering an Oracle PDK-Java Producer Using Fusion Middleware Control") or WLST commands (see Section 21.2.2, "Registering a WSRP Producer Using WLST" or Section 21.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 42.3.2, "Redeploying Portal Framework Applications Using Fusion Middleware Control."

42.1.6.6 Deploying Applications Using the WLS Administration Console

You can use the WLS Administration Console to deploy a Portal Framework 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 Portal Framework application, the MDS connection in the EAR file must be configured to the target deployment repository. Follow steps 1-5 in Section 42.1.6.5, "Deploying Applications Using WLST," then follow the steps below to deploy a Portal Framework application or portlet producer application using the WLS Administration Console.

Note:

Oracle does not recommend deploying Portal Framework applications to any of the preconfigured Managed Servers created during the installation, or to the Administration Server. For Portal Framework applications created in JDeveloper, follow the process described in the "Extending an Existing Domain" section in Oracle Fusion Middleware Installation Guide for Oracle WebCenter Portal to create and provision a new 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 Portal Framework 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 Summary of Deployments page displays (see Figure 42-14).

    Figure 42-14 Deployment Summary

    Description of Figure 42-14 follows
    Description of "Figure 42-14 Deployment Summary"

  3. On the Deployment Summary pane, click Install.

    The Install Application Assistant page displays (see Figure 42-15).

    Figure 42-15 Install Application Assistant Page

    Description of Figure 42-15 follows
    Description of "Figure 42-15 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 42-16).

    Figure 42-16 Install Application Assistant - Page 2

    Description of Figure 42-16 follows
    Description of "Figure 42-16 Install Application Assistant - Page 2"

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

    Page 3 of the Install Application Assistant displays (see Figure 42-17).

    Figure 42-17 Install Application Assistant - Page 3

    Description of Figure 42-17 follows
    Description of "Figure 42-17 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 21.2.1, "Registering a WSRP Producer Using Fusion Middleware Control" and Section 21.4.1, "Registering an Oracle PDK-Java Producer Using Fusion Middleware Control") or WLST commands (see Section 21.2.2, "Registering a WSRP Producer Using WLST" or Section 21.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 42.3.2, "Redeploying Portal Framework Applications Using Fusion Middleware Control."

42.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 42.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 42.3.2, "Redeploying Portal Framework Applications Using Fusion Middleware Control," or using WLST as described in Section 42.3.3, "Redeploying Portal Framework Applications Using WLST."

42.1.7 Migrating Customizations and Data Between Environments

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

42.1.8 Configuring Applications to Run in a Distributed Environment

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

42.2 Undeploying Portal Framework Applications

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

Note:

When a Portal Framework 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 42.2.3, "Removing an Application's Credential Map." You can also remove the MDS repository partition as described in the "Deleting a Metadata Partition from a Repository" section in Oracle Fusion Middleware Administrator's Guide.

This section contains the following subsections:

42.2.1 Undeploying Portal Framework Applications Using Fusion Middleware Control

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

To undeploy a Portal Framework 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.

42.2.2 Undeploying Portal Framework Applications Using WLST

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

To undeploy a Portal Framework 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 Portal installation:

    connect("user_name","password","host_name: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_name is the host name 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 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.

42.2.3 Removing an Application's Credential Map

When a Portal Framework 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 select the target domain (for example, wc_domain).

  4. From the WebLogic Domain drop-down menu, select Security > Credentials.

    The Credentials pane displays (see Figure 42-18).

    Figure 42-18 Credentials Pane

    Description of Figure 42-18 follows
    Description of "Figure 42-18 Credentials Pane"

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

  6. Click Yes to confirm deleting the credential map.

42.3 Redeploying Portal Framework Applications

This section describes how to redeploy a Portal Framework 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 42.2, "Undeploying Portal Framework Applications".

Note:

Some system .EAR files, such as wcps-services.ear and wsrp-tools-as.ear, are not versioned and were not intended to be redeployed. Redeploying these files will generate an error.

This section contains the following subsections:

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

42.3.1.1 Preserving Application Configuration

In most cases, the end-points of tools and 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.

42.3.1.1.1 Preserving Configuration Across Deployment Using WLST

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

42.3.1.2 Preserving Service and User Customizations

Application metadata can change post-deployment due to customizations done by users at runtime. 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.

42.3.1.3 Preserving Asset Customizations

Users can create new assets at runtime using the Assets page. If you plan to redeploy the application and want to preserve runtime-created assets, before redeployment you must first download the assets from the running application and import the resulting archive file into the design-time environment.

If you do not download and import runtime-created assets, they are lost upon redeployment of the application. Any new pages created at runtime that use the lost assets are still available even though the assets themselves are no longer available in the Assets page. This is because the generic-site-resources.xml file, which is updated at runtime when new assets are created, is overwritten on redeployment by the design-time version of the file.

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

42.3.2 Redeploying Portal Framework Applications Using Fusion Middleware Control

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

To redeploy a Portal Framework 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 42-19).

    Figure 42-19 Select Application Page

    Description of Figure 42-19 follows
    Description of "Figure 42-19 Select Application Page"

  4. Select the application that you want to redeploy.

  5. Click Next to display the Select Archive page (see Figure 42-20).

    Figure 42-20 Select Archive Page

    Description of Figure 42-20 follows
    Description of "Figure 42-20 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 42-21).

    Figure 42-21 Application Attributes Page

    Description of Figure 42-21 follows
    Description of "Figure 42-21 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 42-22).

    Figure 42-22 Deployment Settings Page

    Description of Figure 42-22 follows
    Description of "Figure 42-22 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 Portal Framework 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 42-23).

    Figure 42-23 Configure ADF Connections Page

    Description of Figure 42-23 follows
    Description of "Figure 42-23 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 42-24), 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 42-24 Discussion Forum Connection Settings

    Description of Figure 42-24 follows
    Description of "Figure 42-24 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 42-25).

    Figure 42-25 Deployment Settings Page - Deployment Plan Section

    Description of Figure 42-25 follows
    Description of "Figure 42-25 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 42.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.

42.3.3 Redeploying Portal Framework Applications Using WLST

To redeploy a Portal Framework 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 Portal Framework 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 Oracle WebCenter Portal installation:

    connect("user_name","password","host_name: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_name is the host name 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.

42.4 Post-Deployment Configuration

After your Portal Framework 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:

42.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 30.2.5, "Post-deployment Security Configuration Tasks."

42.4.2 Checking Application Connections After Deployment

After deploying your Portal Framework 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

42.4.3 Checking Data Source Connections

After deploying your Portal Framework 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 Portal Framework application, see the "Configuring JDBC Data Sources" chapter in Oracle Fusion Middleware Configuring and Managing JDBC Data Sources 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.

42.4.4 Tuning the Application

After your Portal Framework 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 27.5, "Tuning Oracle WebCenter Portal Performance". Also see the "Oracle WebCenter Portal Performance Tuning" chapter in Oracle Fusion Middleware Performance and Tuning Guide, and Section 27, "Monitoring Oracle WebCenter Portal Performance" for information on how to diagnose performance problems.