|Oracle® Fusion Middleware Developer's Guide for Oracle WebCenter
11g Release 1 (11.1.1)
Part Number E10148-04
as the default server (DefaultServer). This chapter also describes how to use JDeveloper to deploy applications to an Oracle WebLogic Managed Server configured to test application deployment or host applications for production.
For information about deploying custom WebCenter applications through other mechanisms, such as Oracle Enterprise Manager Fusion Middleware Control, Oracle WebLogic Administration Console, and WebLogic Scripting Tool (WLST) commands, see the chapter, "Deploying WebCenter Applications" in Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.
This chapter includes the following sections:
This section provides an overview of the Integrated WebLogic Server (or Integrated WLS) and Oracle WebLogic Managed Servers. Using Oracle JDeveloper, you can test your applications on the Integrated WLS and deploy applications to an Oracle WebLogic Managed Server that resides outside Oracle JDeveloper for staging and further testing, or to an actual production environment.
Integrated WebLogic Server
The Integrated WebLogic Server (Integrated WLS) comes packaged with Oracle JDeveloper and is the default server (DefaultServer). The Integrated WLS connection appears as IntegratedWLSConnection in the Resource Palette under IDE Connections > Application Server. With Integrated WLS, you can quickly and easily test your application at design time without having to perform an enterprise deployment.
You can manually start the Integrated WLS by choosing the Run > Start Server Instance menu option in JDeveloper. Doing so creates a single server instance for all applications; any applications you run will then use this server instance. If you choose not to manually start the Integrated WLS, when you run an application, an Integrated WLS instance for that application automatically starts.
Testing custom WebCenter applications on the Integrated WLS helps to improve design-time tasks by:
Optimizing deployment: the requirement to zip and copy files to a separate server for design time testing is eliminated.
Instantly refreshing changes to the application: you can directly run most files from project directories, which enables you to make selected changes and refresh these changes while the application is running. For example, you can modify a task flow on a JSPX page, then refresh the page in the browser to view your changes without redeploying the application.
Removing the requirement to undeploy applications after testing and debugging. If you stop the Integrated WLS, however, applications running on it are automaticall undeployed.
To learn more about testing a custom WebCenter application on the Integrated WLS, refer to Section 38.2, "Testing a Custom WebCenter Application on the Integrated WebLogic Server."
WebLogic Managed Server
An Oracle WebLogic Managed Server resides outside of Oracle JDeveloper as part of a domain, and is managed by an Administration server within that domain. A WebLogic Managed Server hosts applications, along with the libraries and other resources needed by those applications. A domain, which is a logically related group of Oracle WebLogic Server resources, can have any number of Managed Servers. Managed servers can be configured to run applications in a test environment, a production environment, or both.
To learn more about deploying a custom WebCenter application to an Oracle WebLogic Managed Server, see Section 38.3, "Packaging and Deploying a Custom WebCenter Application to a WebLogic Managed Server."
When you run an application in JDeveloper, a server instance named after the application is automatically created. While the application is running, you can switch back and forth between JDeveloper and your browser to make changes at design time in your application, then refresh your JSPX page in your browser to view the changes. While in JDeveloper, you can also watch the progress of your applications, as well as stop the server instance (and thus stop the application).
the Integrated WLS is preconfigured to run applications in Oracle JDeveloper, which means you do not need to create deployment profiles. To run a custom WebCenter application, in the Application Navigator, right-click the .jspx page in the project folder and choose Run. Alternatively, you can manually start the Integrated WLS by choosing Run > Start Server Instance. If you start an Integrated WLS instance manually, then all applications you subsequently run will run on this single instance of the Integrated WLS.
Running the application page triggers the packaging and deployment of your custom WebCenter application on an Integrated WLS instance named after the application. You can stop instances of the Integrated WLS by using the Run Manager panel (shown in Figure 38-1). To stop an instance, just select DefaultServer and click the red Stop icon on the Run Manager tab.
Figure 38-1 Run Manager
Use the DefaultServer Log window (shown in Figure 38-2) to view how the activity is progressing.
Figure 38-2 DefaultServer Log Window
Note:When the Integrated WLS instance stops, the application is undeployed, and therefore, becomes unavailable.
For a more persistent testing scenario, you can deploy your application to the Integrated WLS by right-clicking the application and then selecting Deploy. This deploys the application to the DefaultServer instance and it is always available when the DefaultServer is running. If you choose this method, then you must first create deployment profiles, as described in Section 22.214.171.124, "Creating Deployment Profiles". If you deploy your application to the Integrated WLS, then the Deployment Configuration dialog displays to let you configure and customize deployment settings. The file system MDS repository pre-created by JDeveloper displays in the Repository Name field.
If you manually started the Integrated WLS, you can stop the server instance by choosing Run > Stop Server Instance.
Oracle WebCenter temporarily modifies mds-config in the adf-config.xml file to reconfigure the directory paths for the running application. To clean up any runtime customizations, choose the menu option Build > Clean Runtime MDS Customizations. For example, if you have included Oracle Composer in your application and changed the look and feel at runtime, you can reset these customizations back to your original application by removing the customizations stored in the MDS.
Note:The Integrated WLS creates an archive directory of your custom WebCenter application at
Secure attributes and credentials are migrated by default when running a custom WebCenter application on the Integrated WLS.
When you're ready to test your custom WebCenter application using an external test or staging site, you can deploy your applications directly from JDeveloper to an Oracle WebLogic Managed Server.
For information about deploying custom WebCenter applications using Fusion Middleware Control, Oracle WebLogic Administration Console, and WLST commands, see the chapter, "Deploying WebCenter Applications" in Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.
This section includes the following:
When you deploy custom WebCenter applications, you may also need to migrate your database connections and the related security for connecting to the databases. You will also need to create a set of project-level and application-level deployment profiles that indicates how a custom WebCenter application and its associated files should be packaged so that the application can be deployed to an Oracle WebLogic Managed Server.
This section includes the following:
When you deploy custom WebCenter applications, you'll also need to package your database connections and the related security for connecting to the databases. This section describes what you'll need to know to package a custom WebCenter application that uses one of the two database connection types: JDBC data source and JDBC URL. This section also describes security migration for applications that use database connections that specify passwords, or external applications that specify shared or public credentials.
Based on the policy defined by your administrator (if, for example, your administrator does not allow any application-level data sources), you may need to migrate the database connections and respective credentials to the target server. The packaging options described below allow you to choose how the database connections should be treated.
This section includes the following sub-sections:
If your custom WebCenter application contains JDBC database connections, you'll need to choose how JDeveloper will migrate those database connections to the Oracle WebLogic Managed Server. You can choose from:
Oracle recommends that you choose this type of data source if you plan to deploy an application EAR file to a Managed Server running in production mode using Fusion Middleware Control, the Oracle WebLogic Administration Console, or using a WLST (
To choose a global data source, deselect the Auto Generate and Synchronize weblogic-jdbc.xml Descriptors During Deployment checkbox when you create the EAR file so that JDeveloper does not create an application-level data source with password indirection. Instead, create the global data source using Oracle WebLogic Administration Console after deploying an application to a Managed Server in production mode. For more information on creating global data sources, see the section "Creating a JDBC Data Source" in Oracle Fusion Middleware Configuring and Managing JDBC for Oracle WebLogic Server.
JDeveloper generates an application-level data source with password indirection by default when you run an application on the Integrated WLS. That is, the Auto Generate and Synchronize weblogic-jdbc.xml Descriptors During Deployment checkbox is selected by default in the Application Properties dialog, as shown in Figure 38-3.
Figure 38-3 Auto Generate and Synchronize weblogic-jdbc.xml Descriptors During Deployment Checkbox
To generate an application-level indirection data source, JDeveloper does the following:
<connection>-jdbc.xml file (such as
WC-jdbc.xml) for each connection in the Application Resource.
Sets the indirect password attribute in the
<jdbc-driver-params> <use-password-indirection>true</use-password-indirection> </jdbc-driver-params>
weblogic-application.xml to add each
<connection>-jdbc.xml file as a module. For example:
<module> <name>WC</name> <type>JDBC</type> <path>META-INF/WC-jdbc.xml</path> </module>
Adds a resource reference to each JDBC JNDI name in the
web.xml file, if this file exists. For example:
<resource-ref> <description>WC-Connection</description> <res-ref-name>jdbc/WCDS</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> </resource-ref>
If you choose to generate an application data source with password indirection, then you must add credential mappings using the Oracle WebLogic Administration Console to be able to activate the application. For more information on adding credential mappings, see the section "Creating a JDBC Data Source" in Oracle Fusion Middleware Configuring and Managing JDBC for Oracle WebLogic Server.
Note:Do not use WLST commands to deploy applications that use application-level data sources with password indirection, as WLST cannot set password indirection credential mappings on the server.
The following is applicable if you have configured security in your application using the Configure ADF Security wizard, or the application contains connections with secure attributes such as a database connection password, external applications with shared or public credentials:
If you do not intend to migrate credentials, then deselect the Credentials checkbox in the Security Deployment Options section in the Application Properties dialog (see Figure 38-4).
Figure 38-4 Security Deployment Options
If you retain the default selection in the Security Deployment Options section, then the credential migration will behave as follows, depending on whether the WebLogic domain is in development or production mode:
When you deploy a custom WebCenter application to a Managed Serverrunning in production mode, secure attributes of the connections packaged within your application and any shared or public credentials specified for external applications are not migrated to the domain-level credential store. This is because secure properties are likely to be different between development and production environments. Therefore, you must reconfigure secure attributes of connections and shared or public credentials for external applications using WLST commands or Fusion Middleware Control, as described in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.
When you deploy a custom WebCenter application in development mode, you must first enable credential migration. To enable credential migration for an application to be deployed in development mode, start the Managed Server with
-Djps.app.credential.overwrite.allowed=true, by adding the following option to the
setDomainEnv.sh file located in
set EXTRA_JAVA_PROPERTIES=-Djps.app.credential.overwrite.allowed=true %EXTRA_JAVA_PROPERTIES%
In Figure 38-4, in the Security Deployment Options section, the Users and Groups checkbox is selected by default. This indicates that the users and groups defined in the application's
jazn-data.xml file will be migrated to the identity store configured for the WebLogic Managed Server, if the authenticator configured in the domain allows creation of users and groups. When migrating the identify store, you should deselect this option as users and groups defined in the identity store configured for the Managed Server should be used to access the application.
When the Application Policies checkbox is selected, then the
jps.policystore.migration parameter in the
weblogic-application.xml file is set to
OVERWRITE. This means that during application deployment and redeployment, the application policies packaged with the application will be overwritten on the domain-level policy store for the domain to which the application is being deployed.If the Application Policies checkbox is not selected, then the
jps.policystore.migration parameter is set to
MERGE. This means that the application policies will be migrated during application deployment but not during redeployment, and the existing application policies will not be overwritten.
To deploy your application to a Managed Server that resides outside JDeveloper, you must first create deployment profiles. A deployment profile packages or archives a custom WebCenter application and its associated files so that the application can be deployed to an Oracle WebLogic Managed Server. You create deployment profiles at both the project and the application level.
At the project level, you create a Web Application Archive (WAR) deployment profile, which contains the projects to be deployed and any associated files, such as, pages, Java classes,
web.xml, and so on.
At the application level, you create an Enterprise Archive (EAR) deployment profile that contains application artifacts such as,
jazn-data.xml, metadata archive (MAR) files, and all project-related WAR files. For custom WebCenter applications containing MDS metadata or portlets, a metadata archive file (with the extension .MAR) is automatically generated and included in the EAR file. This file contains all MDS metadata and portlet customization data.
Note:You can deploy Oracle ADF applications, such as custom WebCenter applications, only as EAR files. Therefore, while creating deployment profiles, ensure that the WAR and MAR files of the application are included in the application's EAR file.
This section includes the following sub-sections:
In JDeveloper, in the Application Navigator, right-click ViewController and select New.
In the New Gallery, expand General, select Deployment Profiles, then WAR File, and then click OK.
In the Create Deployment Profile -- WAR File dialog, enter a name for your deployment profile and click OK.
In the WAR Deployment Profile Properties dialog, select the Specify Java EE Web Context Root option, enter a meaningful context root, and then click OK.
The "context root" is the part of the Web application's URL that is appended to the server ID and port number, and to which the servlet name is in turn appended. For example, in the URL
/myWebsite is the context root (or virtual path), and
HelloWorld is the name of the servlet the user is accessing.
In the Project Properties dialog, click OK.
In JDeveloper, in the Application Navigator, right-click the application and select New.
In the New Gallery, expand General, select Deployment Profile, then EAR File, and then click OK.
In the Create Deployment Profile – EAR File dialog, enter a name for your deployment profile and click OK.
In the Edit EAR Deployment Profile Properties dialog, select Application Assembly, then select the project WAR you want to make available in the project file and and click OK.
In the Application Properties dialog, select the deployment options to use and click OK.
For a description of the Auto Generate and Synchronize weblogic-jdbc.xml Descriptors During Deployment option, see Section 126.96.36.199.1, "Packaging the Database Connections." For a description of the Deployment Security Options, see Section 188.8.131.52.2, "Packaging Application Security Data."
In the Application Navigator, right-click the application name, choose Deploy, deployment profile name, to, and then choose to EAR file. This creates the EAR file in the deploy folder located in
\deploy\, as shown in Figure 38-5.
Figure 38-5 EAR Status in Deployment - Log
This section includes the following sub-sections:
Before deploying a custom WebCenter application, you must also create a new WebLogic Managed Server instance and provision it with a required set of shared libraries. You can create and provision a WebLogic Managed Server instance using the WLS Administration Console as described in the section "Creating and Provisioning a WebLogic Managed Server Instance" in Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.
Note:Oracle does not recommend deploying custom WebCenter applications to any of the three pre-configured Managed Servers created during the installation, or to a domain Administration Server.
After creating and provisioning the WebLogic Managed Server instance, you must create and register a Metadata Service Repository (MDS) schema for the application on the WebLogic Domain's Administration Server instance, as described in the section "Creating and Registering the Metadata Service (MDS) Repository" in Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.
From Oracle JDeveloper, you can deploy your applications to Oracle WebLogic Managed Server instances that reside outside JDeveloper. After you've created your deployment profiles, set up the Oracle WebLogic Managed Server instance, and set up the Metadata Service repository, you must create a connection to the Managed Server instance where you will deploy the application.
Before you create a connection to an Oracle WebLogic Managed Server instance, ensure that the target Managed Server instance is up and running.
In JDeveloper, from the File menu, select New.
In the New Gallery, expand General, select Connections, and then Application Server Connection.
In the Create Application Server Connection wizard, for Step 1, enter a name for the new connection (for example,
WLS_CustomApp), and then click Next.
At Step 2, specify the user name and password for authentication, and then click Next.
At Step 3, enter the host name of the WebLogic Managed Server (for example,
webcenter.myserver.example.com) and the port number (for example, 7888).
In the WLS Domain field, specify the name of the domain in which the WebLogic Managed Server instance is created (for example,
wl_server), and then click Next.
At Step 4, click Test Connection.
If the test is successful, you now have a connection to the target WebLogic Managed Server.
When you deploy to a Managed Server, the application EAR file is generated. The EAR file packages the metadata archive (MAR file), which includes the metadata content to be deployed to an MDS repository. Additionally, the
adf-config.xml file is reconfigured with a modified
mds-config for the target deployment environment. Application-wide features, security, caching, and change persistence remain unchanged. Properties for other Oracle components, if any, are also configured in this file. Similarly, JSF and JSTL shared libraries are added in the
weblogic.xml file during packaging.
To deploy a custom WebCenter application to an Oracle WebLogic Managed Server instance:
In JDeveloper, in the Application Navigator, open the application to be deployed.
Right-click the application name, choose Deploy, and then select the deployment profile name.
The Deployment Action dialog displays (see Figure 38-6).
Figure 38-6 Deployment Action Dialog
Select Deploy to Application Server and click Next.
The Select Server dialog displays (see Figure 38-7).
Figure 38-7 Select Server Dialog
Select the connection name of the Managed Server (for example,
WLS_CustomApp), and click Next.
In most cases, you will want to deselect Deploy to all server instances in the domain and select the specific servers and clusters to deploy to using the Server Instances dialog. Refer to the online help for more information about using the Select Server dialog options.
On the Deployment Summary dialog, shown in Figure 38-8, check that all of the deployment options are correct and click Finish to start the deployment.
Figure 38-8 Deployment Summary Dialog
Continue by doing any post-deployment security or data source connnection configurations that may be required as described in the section on "Post-Deployment Configuration" in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.
When migrating a deployed application to a new environment, post-deployment customizations made to pages, WebCenter Web 2.0 Services, and portlets (PDK-Java and WSRP version 2 producers) must be migrated too. Export and import utilities are available to assist with this process. For more information, see the chapter, "Managing Backup, Recovery, Export, and Import of WebCenter" in Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.