7 Deploying WebCenter Applications

7.1.2.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 custom WebCenter application.

7.1.3.1 Creating and Provisioning a WebLogic Managed Server Instance

You can create a WebLogic Managed Server instance using the WLS Administration Console, or using Fusion Middleware Control. You can also create a WebLogic Managed Server instance and provision it using WLST commands in a Jython script. A sample Jython script that you can modify to suit the needs of your local environment is available for download from the Oracle Technology Network (OTN). Using a script is a good approach in circumstances where new Managed Servers must be created on an on-going basis.

These three options are described in the following sections:

• Section 7.1.3.1.1, "Creating and Provisioning a WebLogic Managed Server Using a Jython Script"

• Section 7.1.3.1.2, "Creating and Provisioning a WebLogic Managed Server Using the WLS Administration Console"

• Section 7.1.3.1.3, "Creating a WebLogic Managed Server Using Fusion Middleware Control"

7.1.3.2 Creating and Registering the Metadata Service Repository

Before you can deploy an application to a Managed Server, you must first create and register a Metadata Service (MDS) repository schema for the application on the WebLogic Domain's Administration Server instance.

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.4, "Deploying the Application to a WebLogic Managed Server Instance").

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:

• Creating an MDS Schema Using the Repository Creation Utility

• Registering an MDS Schema Using Fusion Middleware Control

• Registering an MDS Schema Using WLST

7.1.3.3 Configuring the Target Environment

After your target Managed Server has been created and provisioned, but before you deploy your custom WebCenter application, you must configure your JDBC database connections, and connections to the Identity Store and Policy and Credential Store.

This section contains the following subsection:

• Section 7.1.3.3.1, "Configuring the JDBC Data Source"

7.1.4.1 Deploying Applications Using Oracle JDeveloper

You can deploy custom WebCenter 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 Custom WebCenter Application to a Managed Server" in the Oracle Fusion Middleware Developer's Guide for Oracle WebCenter.

7.1.4.2 Deploying Applications Using Fusion Middleware Control

When deploying a custom WebCenter 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.4.5, "Saving and Reusing the Deployment Plan" for more information about deployment plans.

To deploy a custom WebCenter 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-12).

   Figure 7-12 Select Archive Page

   
   Description of "Figure 7-12 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-13).

   Figure 7-13 Select Target Page

   
   Description of "Figure 7-13 Select Target Page"
   
   

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

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

   Figure 7-14 Application Attributes Page

   
   Description of "Figure 7-14 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-15. 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-15 Select Metadata Repository Window

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

    Figure 7-16 Deployment Settings Page

    
    Description of "Figure 7-16 Deployment Settings Page"
    
    

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

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

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

    Figure 7-17 Configure ADF Connections Page

    
    Description of "Figure 7-17 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-18), 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-18 Discussion Forum Connection Settings

    
    Description of "Figure 7-18 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.4, "Deploying the Application to a WebLogic Managed Server Instance".

    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 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 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:

    When after deploying, you reconfigure connections for custom WebCenter applications, these post-deployment customizations are preserved in the MDS repository and do not need to be set again when you redeploy the application.

7.1.4.3 Deploying Applications Using WLST

To deploy a custom WebCenter 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 custom WebCenter application using WLST:

1. Start the WLST shell.

   For information on starting the WLST shell, see Section 1.12.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 custom WebCenter application using the WLST deploy command.

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

   Where:

• appName is the name of the custom WebCenter 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

7.1.4.4 Deploying Applications Using the WLS Administration Console

You can use the WLS Administration Console to deploy a custom WebCenter 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.4.3, "Deploying Applications Using WLST", then follow the steps below to deploy a custom WebCenter application or portlet producer application using the WLS Administration Console.

To deploy a custom WebCenter 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.12.2, "Oracle WebLogic Server Administration Console."

2. In the Domain Structure pane, click Deployments.

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

   Figure 7-19 Deployment Summary Pane

   
   Description of "Figure 7-19 Deployment Summary Pane"
   
   

3. On the Deployment Summary pane, click Install.

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

   Figure 7-20 Install Application Assistant Page

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

   Figure 7-21 Install Application Assistant - Page 2

   
   Description of "Figure 7-21 Install Application Assistant - Page 2"
   
   

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

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

   Figure 7-22 Install Application Assistant - Page 3

   
   Description of "Figure 7-22 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 7.3.2, "Redeploying WebCenter Applications Using Fusion Middleware Control."

7.1.4.5 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.4.2, "Deploying Applications Using Fusion Middleware Control." If there are deployment descriptors packaged within the EAR file, the deployment uses the data in these files.

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.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.2 Preserving Application Metadata

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

Application customizations and personalizations 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 and personalizations 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 or personalizations were created, those personalizations or customizations are ignored.

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

7.3.1.3 Preserving Portlet Customizations and Personalizations

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.