| Oracle® Fusion Middleware Production Operations Guide for Oracle WebLogic Portal 10g Release 3 (10.3.2) Part Number E14245-02 |
|
|
View PDF |
| Oracle® Fusion Middleware Production Operations Guide for Oracle WebLogic Portal 10g Release 3 (10.3.2) Part Number E14245-02 |
|
|
View PDF |
The term application deployment refers to the process of making an application or module available for processing client requests in a WebLogic Server domain. This chapter discusses recommended procedures and best practices for deploying WebLogic Portal applications and shared libraries to the server.
This chapter includes the following topics:
Section 4.2, "Overview of Deployment Descriptors and Config Files"
Section 4.10, "Using Multiple Enterprise Applications in a Single Domain"
Section 4.13, "Using Production Redeployment with WebLogic Portal"
Tip:
Before continuing, we recommend that you review the following WebLogic Server document, "Understanding WebLogic Server Deployment" in Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server.Before you deploy a WebLogic Portal application, you need to configure the destination domain. For detailed information on domain configuration, see Section 3.3, "Creating Your Clustered Domain."
In WebLogic Portal 8.1 and prior versions, an application configuration file named META-INF/application-config.xml was used to configure WebLogic Portal components such as cache, campaigns, behavior tracking, content management, and others.
As of WebLogic Portal 9.2, this configuration file has been removed and its contents moved to a collection of new, schema-compliant, descriptors. These new descriptors are each focused on a single service or group of related services. To view the complete set of descriptor files used by an application in Oracle Enterprise Pack for Eclipse, select the Merged Projects view.
These files are processed using the same infrastructure that WebLogic Server uses to process all the J2EE descriptors (like application.xml or web.xml). These descriptors support merging from J2EE Shared Libraries and also support deployment plans. (For more information on merging, see Section 4.2.1, "Descriptor Merging.") The WebLogic Portal descriptors are installed with default settings that you can override by copying them into your application and editing them. A significant benefit of this configuration is that the contents of your project's EAR file is focused on your project, and not on the WebLogic Portal product code.
This section includes these topics:
Section 4.2.3, "Portal Web Application Deployment Descriptors"
Section 4.2.4, "Enterprise Application Deployment Descriptors"
When the server processes the deployment descriptors, it merges them. All descriptors from the application and from the shared libraries that the application references are merged. For each separate deployment descriptor, a merged "virtual" descriptor is created, which can be used by the server to deploy the application. The rules that govern descriptor merging are explained in Section 2.6.2, "Shared Library Rules of Precedence." Remember that the referencing application and its deployment plan always override settings imported from a referenced library.
If you want to see merge results without deploying an application, you can use the WebLogic Server utility called weblogic.appmerge. This utility takes an application that references shared libraries and creates a J2EE application including the merged contents and merged descriptors. This utility is useful for debugging purposes. For details, see the WebLogic Server document, "Using weblogic.appmerge to Merge Libraries" in Oracle Fusion Middleware Developing Applications for Oracle WebLogic Server.
Oracle Enterprise Pack for Eclipse provides information about shared libraries (also called library modules). You can use Oracle Enterprise Pack for Eclipse to copy files from shared libraries to your application. When you do this, you can then modify the copied file. From then on, the local copy takes precedence over the library module copy. Using the Package Explorer view, you can view and browse the contents of shared libraries.
Another utility, called ddbrowser, is included with the WebLogic Portal installation. This utility inspects your application and shows you all the "mergeable" descriptors. For each descriptor in the application, you can see the contributions from each library as well as the resulting merged descriptor.
To use ddbrowser, run the following command:
java -jar <WLPORTAL_HOME>/p13n/lib/ddbrowser.jar.
A Portal Web Application includes several deployment descriptors. By default, these descriptors are located in the WebContent/WEB-INF directory of the web project. The deployment descriptors are listed in Table 4-1.
Tip:
For a complete listing and detailed description of deployment descriptors associated with WebLogic Server based applications, see the WebLogic Server document "Overview of WebLogic Server Application Development"in Oracle Fusion Middleware Developing Applications for Oracle WebLogic Server.Table 4-1 WebLogic Portal Descriptor Files: Web Application Scoped
| Descriptor | Purpose |
|---|---|
web.xml |
The |
weblogic.xml |
The WebLogic descriptor is a standard WebLogic Server deployment descriptor for web applications that has a number of important descriptor entries. See "web.xml Deployment Descriptor Elements" in Oracle Fusion Middleware Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server. |
wlp-template-config.xml |
Content display templates |
wsrp-consumer-handler-config.xml |
SOAP Handlers and interceptors for WSRP Consumer |
wsrp-consumer-security-config.xml |
WSRP Consumer security configuration |
wsrp-user-property-map.xml |
WSRP Producer/Consumer property mappings |
wsrp-producer-portlet-registry-config.xml |
WSRP Producer UDDI registries |
The J2EE specifications define standard, portable deployment descriptors for J2EE modules and applications. Oracle defines additional WebLogic-specific deployment descriptors for deploying a module or application in the WebLogic Server environment. A WebLogic Portal enterprise application, also called an EAR Project, includes the deployment descriptors listed in Table 4-2. By default, these files are located in the EarContent/META-INF directory of the EAR project.
Tip:
For a complete listing and detailed description of deployment descriptors associated with WebLogic Server based applications, see the WebLogic Server document "Overview of WebLogic Server Application Development" in Oracle Fusion Middleware Developing Applications for Oracle WebLogic Server.Table 4-2 WebLogic Portal Descriptor Files: Enterprise Application Scoped
| Descriptor | Purpose |
|---|---|
application.xml |
This J2EE descriptor specifies the web applications that are associated with an EAR project. |
weblogic-application.xml |
This WebLogic descriptor specifies the J2EE Shared Libraries used by the enterprise application. It also specifies web applications, such as the Propagation Servlet, that are deployed to the EAR. See also the WebLogic Server document "Creating Shared Java EE Libraries and Optional Packages" in Oracle Fusion Middleware Developing Applications for Oracle WebLogic Server. |
p13n-cache-config.xml |
This WebLogic descriptor specifies the cache settings for all caches used by WebLogic Portal. For more information on cache settings, see the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal. |
p13n-config.xml |
P13N features (events, behavior tracking, etc.) |
p13n-security-config.xml |
Security management, including group hierarchy tree caches and role authorization for management. |
p13n-profile-config.xml |
Unified User Profile adapters (formerly in |
netuix-application-config.xml |
Portal Proliferation (sync) |
communities-config.xml |
WebLogic Portal Communities |
content-config.xml |
Content repositories |
wps-config.xml |
Ads and Campaigns |
wsrp-consumer-portlet-registry-config.xml |
Portlet UDDI registries for WSRP |
Table 4-3 lists Web application configuration files. These files are not descriptor files (they cannot be used in deployment plans and they are not merged).
Table 4-3 WebLogic Portal Configuration Files: Web Application Scoped
| Descriptor | Purpose |
|---|---|
wsrp-producer-registry.xml |
This file allows WSRP consumer applications to configure registered producer applications. For example, you can enable local proxy support by setting |
netuix-config.xml |
This file is governed by the XML schema definition file |
beehive-netui-config.xml |
This descriptor specifies netui-specific tags and handler classes. For detailed information on the elements of this descriptor, refer to the Apache Beehive Project reference documentation at |
Deployment plans let you easily tune an application's deployment descriptors on a deployment-by-deployment basis without actually modifying the descriptors themselves in the application EAR file. For instance, you might use a deployment plan to adjust descriptors for a staging environment and another plan to make adjustments for your production environment. Typically, developers set initial baseline descriptor values.
Tip:
See also Section 4.11, "Application Tuning Tips."A deployment descriptor is an XML document used to define the J2EE behavior or WebLogic Server configuration of an application or module at deployment time. A deployment plan is an XML document that resides outside of an application's archive file, and can apply changes to deployment properties stored in the application's existing WebLogic Server deployment descriptors.
For detailed information on deployment plans, see the WebLogic Server document "Configuring Applications for Production Deployment" in Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server. This document describes deployment plans in detail, discusses the XML schema for deployment plans, and explains how to create, edit, and use them.
Note:
The WebLogic Portal Administration Console uses deployment plans to save runtime changes to deployment descriptor values.With application-scoped JDBC, it is possible to use more than one database in a WebLogic Portal domain, allowing each application deployed in the domain to access its own database. WebLogic Server enables this by providing the ability for you to scope JDBC pools to the application level.
Tip:
Using application-scoped JDBC pools in a domain with multiple WebLogic Portal applications is a recommended best practice.When you package your enterprise application, you can include JDBC resources in the application by packaging JDBC modules in the EAR and adding references to the JDBC modules in all applicable descriptor files. When you deploy the application, the JDBC resources are deployed, too. Depending on how you configure the JDBC modules, the JDBC data sources deployed with the application will either be restricted for use only by the containing application (application-scoped modules) or will be available to all applications and clients (globally-scoped modules).
By default, JDBC pools are scoped to the domain level. If you want to scope JDBC pools to the application level, some configuration is required. For detailed information on configuring application-scoped JDBC, see the WebLogic Server document "Targeting Application-Scoped JMS, JDBC, and WLDF Modules" in Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server.
The deployment staging mode determines how deployment files are made available to target servers that must deploy an application or stand-alone module. WebLogic Server provides three different options for staging files: stage mode, nostage mode, and external_stage mode.
By default, WebLogic Portal's default staging mode is "stage." In a clustered environment, you can change this default to "nostage" to reduce the time taken to start the cluster, application, and library deployments. To change the mode, use the Oracle WebLogic Server Administration Console. For more details, see "Controlling Deployment File Copying with Staging Modes" in Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server.
This section explains how to build a portal application and create an EAR file using Oracle Enterprise Pack for Eclipse or from the command line. This section discusses creating both EAR files and exploded EARs.
To deploy a portal application to a production environment, you must first build the application in Oracle Enterprise Pack for Eclipse to compile necessary classes in the portal application and create a deployable EAR file. The EAR can either be compressed (an EAR file) or uncompressed (an exploded EAR directory).
For detailed information on building an application in Oracle Enterprise Pack for Eclipse, see the Oracle Enterprise Pack for Eclipse document "Understanding the Build Process."
To create an exploded EAR directory, first build an EAR file, and then use the Java jar xf command to uncompress the file.
Tip:
After you create an exploded EAR, you might want to rename the application directory so that it has a .ear extension. For example, if the application directory is called myPortalApp, rename the directory to myPortalApp.ear. Adding the .ear makes the configuration common for compressed and exploded deployments, but it is not required.You can export an Ant build file for your project using Oracle Enterprise Pack for Eclipse. For more information, see the Oracle Enterprise Pack for Eclipse document "Creating Custom Ant Build Files for an Application."
This section provides instructions for the deployment of your portal application.
Note:
Although it was required before WebLogic Portal version 9.2, deploying a WebLogic Portal application to the Administration Server is no longer necessary and is not specifically discussed here.Tip:
WebLogic Server documentation explains the deployment process and multiple deployment scenarios in detail. We recommend you review Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server before continuing. For information on automating deployment tasks with WLST see Oracle Fusion Middleware Oracle WebLogic Scripting Tool.This section includes the following topics:
Section 4.7.2, "Deploying to a Staging or Production Environment"
Section 4.7.3, "Redeploying to a Staging or Production Environment"
In a typical development environment, developers use Oracle Enterprise Pack for Eclipse to develop portal components. They typically deploy and run against a local server domain that is configured in Development mode. No Managed Servers are used. The best practice is to use Oracle Enterprise Pack for Eclipse to deploy (publish) and test your application.
In a domain with an Administration Server and one Managed Server or multiple Managed Servers in a cluster, it is strongly recommended that you deploy the portal EAR file to the Managed Server or cluster. Do not deploy to the Administration Server; this reserves the Administration Server for administration functions, allows the Administration Server to operate with a smaller heap, and allows specific fire-walling of administration functions on this server.
The best practice is to configure your staging and production servers in Production mode rather than Development mode.
The WebLogic Server feature that allows applications to be deployed directly to a Managed Server is called Managed Server Independent (MSI) mode. See "Understanding Managed Server Independent Mode" in Oracle Fusion Middleware Managing Server Startup and Shutdown for Oracle WebLogic Server for information on MSI and several limitations of MSI. One of the most important limitations is that security provider data cannot be modified if the Administration Server is down. Another limitation is that any WebLogic Portal configuration that must write to a deployment plan for persistence will not work if the Administration Server is down.
Redeploying means deploying a new version of an existing/running/deployed application. If you redeploy a portal application to a staging or production environment, follow the same procedure as deploying described in the previous section. However, on redeployment, you must propagate datasync and other WebLogic Portal assets to the target database as a separate operation using the propagation tools. See Section 5.7, "General Propagation Scenarios" for more information on redeploying.
If you deploy an exploded EAR file to a managed server, extra configuration is required. You must place a new datasync.properies file in the end user's application under the META-INF directory. In this datasync.properties file, add the following property:
PERSISTENT_STORE=DATABASE_STORE
This change is only required if you deploy an exploded EAR file.
WebLogic Portal product code is included in your application by referencing several J2EE Shared Libraries. These libraries are part of the WebLogic Portal installation. You can also develop your own shared libraries containing your application code. J2EE Shared Libraries allow you to decouple the development life cycles of various portions of your application. These libraries can be versioned and deployed independently, allowing each library to be developed and distributed independently (rather than as a single large EAR file).
Tip:
For detailed information on J2EE Shared Libraries, see the WebLogic Server document "Creating Shared Java EE Libraries and Optional Packages" in Oracle Fusion Middleware Developing Applications for Oracle WebLogic Server. See also Section 2.6, "Using J2EE Shared Libraries in a Team Environment" and the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.This section discusses several aspects of shared libraries:
Figure 4-1 shows a sample enterprise application, myApp.ear. Note that the descriptor weblogic-application.xml includes a reference (shown in bold) to a library called p13n-app-lib. Note, too, that no other information, other than the name p13n-app-lib, is given to describe the library.
The enterprise application locates the library because the <library-ref> element causes the server at runtime to look for a deployed library with the same name. Since the <library-ref> element does not specify any version information, the server looks for the latest, or highest, version number available to it. The name and version number of a shared library is contained in the library itself, in the META-INF/MANIFEST.MF file. For example:
META-INF/MANIFEST.MF
Extension-Name: p13n-app-lib
Specification-Version: 10.3.0
Implementation-Version: 10.3.0
For more information, see Section 4.8.2, "Library Versions." Note that the same pattern applies to the WEB-INF/weblogic.xml file for portal web applications.
To be located by the server, a shared library must be deployed as a library. This deployment differs from the deployment of a runnable application. When a library is deployed as a library, the library file is registered with the server, and is therefore available to referencing applications.
To deploy a library, use the WebLogic Server Console, the weblogic.Deployer command, the wldeploy Ant task, or with a WLST script. For information these methods, see the WebLogic Server documents:
"The WebLogic Server Adminisrtation Console" in Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help.
"weblogic.Deployer Command Line Reference" in Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server
"weblogic.Deployer Command Line Reference" in Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server
"wldeploy Ant Task Reference" in Oracle Fusion Middleware Developing Applications for Oracle WebLogic Server
"WLST Command and Variable Reference" in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference
For example, you can use the WebLogic Server Console to deploy a shared library in exactly the same way you deploy an application, except that a checkbox is available that distinguishes the shared library from a runnable application.
Example 4-1 shows an entry in the server domain's config/config.xml file for the shared library referenced by the application in Example 4-0.
You can deploy several libraries with the same name and different version numbers. The version number that an application uses is specified in the application's configuration file META-INF/weblogic-application.xml or weblogic.xml for Web applications. If no version number is specified, as in Example 4-2, the server selects the highest-versioned available deployed library named p13n-app-lib.
Example 4-2 Library Reference With No Version Specified
<library-ref> <library-name>p13n-app-lib</library-name> </library-ref>
If, on the other hand, you know that version 10.3.0 of p13n-app-lib is inadequate, and your application needs to use version 10.3.1 or higher, you can reference the library as shown in Example 4-3.
Example 4-3 Library Reference With Version Specified
<library-ref> <library-name>p13n-app-lib</library-name> <specification-version>10.3.1</specification-version> </library-ref>
If you want to use a specific version, and no other version, then you can specify the <exact-match> element, as shown in Example 4-4.
If you are using a content repository, you need to create that repository or repositories on the destination server. To do this, use the WebLogic Portal Administration Console as explained in the Oracle Fusion Middleware Content Management Guide for Oracle WebLogic Portal. This means creating only the root repositories, not the content items and types. To move items and types between environments, use the WebLogic Portal propagation tools. For more information on propagation tools, see Chapter 5, "Developing a Propagation Strategy."
You can also specify the default content repository for an enterprise application in the configuration file META-INF/content-config.xml. See Section 4.2.4, "Enterprise Application Deployment Descriptors" for more information.
You can create and run multiple enterprise applications in a single-cluster domain. As shown in Figure 4-2, a single domain can host multiple enterprise applications (EARs). Each EAR deployment can host multiple web applications, and any number of desktops can be created based on the web applications. The web applications and desktops associated with one enterprise application (EAR) are not dependent on those in another enterprise application (they are decoupled).
Figure 4-2 Multiple Enterprise Applications in a Single Domain
The following restrictions apply to this configuration of multiple enterprise applications in a single domain:
Resource names – Names cannot conflict. For example, for each deployment, web application names must be unique. This applies as well to context-root names and their associated CookieName names. For each enterprise application, the WebLogic Portal Administration Console shows all of the portal web applications that are contained in that application.
Note:
Each enterprise application must be managed through its respective WebLogic Portal Administration Console. Some domain-level resources, such as users and groups, can be viewed and managed across enterprise applications from a single WebLogic Portal Administration Console; however, be aware that data in one application may be cached, and updates to the same data made from another application's WebLogic Portal Administration Console may not be immediately visible.Content – If you are deploying multiple enterprise applications within the same domain, and plan to use content management's library services for each application, you must configure each WLP Repository data source (one per WLP Repository) to be XA-enabled. For more information regarding XA connections, see Oracle Fusion Middleware Creating Domains Using the Configuration Wizard.
Note:
Content for each enterprise application is managed through its respective WebLogic Portal Administration Console and Virtual Content Repository. Virtual Content Repositories (as well as the WebLogic Portal Administration Console) are unique to each application cannot be shared.Hardware Limitations – Variables such as heap size, memory, and CPU usage can affect this configuration if the applications are targeted to the same server.
Personalization – The same local property sets cannot be shared between multiple enterprise applications. If common properties must be shared among different enterprise applications, then use Unified User Profile (UUP). Another alternative is to copy and deploy the same property sets to multiple applications. For detailed information on user profiles and property sets and personalization, see the Oracle Fusion Middleware Interaction Management Guide for Oracle WebLogic Portal.
The best practice is to use deployment plans to modify descriptor values before deploying an application. See Section 4.3, "Using Deployment Plans." See also Oracle Fusion Middleware Performance and Tuning for Oracle WebLogic Server.
Oracle WebLogic Portal provides a tool for automatically deploying JSR-286 portlets that are packaged in JSR-286 WAR files. This tool allows application deployers to deploy a pre-built JSR286 application as a portal web application and WSRP producer, which a client application can then access. This tool can be used on a running server to enable additional functionality (portlets) in a user-facing web site without stopping the server.
This section explains how to use the WebLogic Portal Administration Console import tool to deploy JSR-286 portlets and includes these topics:
You can also use the Oracle Enterprise Pack for Eclipse to import JSR-286 portlets into your workspace for development. For details, see the Oracle Fusion Middleware Portlet Development Guide for Oracle WebLogic Portal.
To start the import tool, do the following:
Log in to the WebLogic Portal Administration Console. You can do this by entering the following URL in a browser:
http://servername:port/earProjectNameAdmin
where servername is the IP name of Administration Server, port is the port number, and earProject is the name of the portal Enterprise application that is deployed on the server. For example:
http://localhost:7001/myEarProjectAdmin
Navigate to Configuration & Monitoring | Service Administration. Open the WSRP section in the resource tree and click Import Tool. The utility is shown in Figure 4-3.
This section explains how to use the import tool to import JSR-286 WAR files into an enterprise application.
Under War Files To Import, enter the path to the WAR file containing the JSR-286 compliant portlets to deploy. You can also use the Browse button to navigate to the WAR file. To select multiple WAR files, click Add Another File and enter the path for each WAR file.
Enter a name for the new portal application. Use a unique name for the application. (Do not use a name that matches any existing applications deployed to the server.) The import utility creates this application as an EAR file using the selected templates in the same manner that Oracle Enterprise Pack for Eclipse builds an application. Each JSR-286 WAR file becomes a web application that is packaged in the EAR.
Enter a directory path name in which to place the EAR file (optional). This path is relative to the server start directory. By default, the file is placed in the server start directory (the directory from which the WebLogic Server startup script startWebLogic.cmd or startWebLogic.sh was run). For a single server environment, this directory is the domain directory. For a managed server, this directory is the managed server directory.
Select the Auto-deploy to these targets checkbox to automatically deploy the new portal application to the specified targets (the Administration Server is included by default). Typically, this option is only used for simple development or test deployments. If you want to upload the new application to a more complex environment, such as a staging or production environment, it is recommended that you do not select this checkbox. Instead, use the WebLogic Server Console to deploy the EAR.
Select Deploy as exploded wars to deploy the WAR files exploded inside the EAR file. Only do this if you plan to perform some additional manipulation on individual web application files.
By default, the new portal application will require registration from WSRP consumers when it is exposed as a WSRP producer. To disable this functionality, deselect Require registration from WSRP consumers.
By default, the new portal application will include the Portal Administration Console and Portal Propagation services. To build the EAR without these services, deselect Include the Portal Administration Console and/or Include Portal Propagation services.
Click Perform Import to create the new application. If the auto-deploy option is selected, the newly created EAR file is deployed automatically. If you did not select the checkbox, you must deploy the EAR using the WebLogic Server Console. The new EAR file will be created in the directory you specified in Step 3.
After the new EAR file is deployed, you can add the portlet(s) contained in the imported WAR file(s) to your application. To do this, add the web application as a WSRP producer. After a web application is added as a producer, you can incorporate the application's portlets as you would with any WSRP producer using the WebLogic Portal Administration Console. See the Oracle Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal for details.
Tip:
If your producer and consumer applications share the same server, it is recommended that you enable local proxy mode. Local proxy support allows co-located producer and consumer web applications to short-circuit network I/O and "SOAP over HTTP" overhead. See the section "Using Local Proxy Mode" in the Oracle Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal.This section discusses using the production redeployment technique to redeploy a WebLogic Portal application to a production environment.
Caution:
Production redeployment is known to work for a limited number of use cases. The most reliable and common use case is to add, remove, or update web-tier (file based) resources. For example, typical uses of production redeployment include updating JSP code or updating image files.If your changes require changes to the portal database or other data sources, production redeployment is not generally recommended. Although other more complex uses of production redeployment are possible, they will depend on a number of other factors that are described in this section.
This section includes these topics:
Production redeployment enables a portal administrator to redeploy a new version of an application in a production environment without stopping the deployed application or otherwise interrupting the application's availability to clients. Production redeployment works by deploying a new version of an updated application alongside an older version of the same application. WebLogic Server automatically manages client connections so that only new client requests are directed to the new version. Clients already connected to the application during the redeployment continue to use the older, retiring version of the application until they complete their work.
Tip:
If you plan to use production redeployment with a WebLogic Portal application, we recommend that you also consider using federated portal techniques (WSRP) to maintain and update specific parts of your portal. Such a strategy can augment your redeployment strategy by reducing the overall scope of a given deployment. For detailed information on federated portals, see the Oracle Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal.Production redeployment support in WebLogic Portal is based on support from WebLogic Server. Before continuing, we recommend that you review the following WebLogic Server documentation:
"Using Production Redeployment to Update Applications" in Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server.
"Developing Applications for Production Redeployment" in Oracle Fusion Middleware Developing Applications for Oracle WebLogic Server.
Figure 4-4 depicts a typical production redeployment scenario for a WebLogic Portal application. As the diagram shows, a new portal version, App V2, has been deployed side-by-side with the original App V1. During production redeployment, existing users continue to interact with App V1 while new users interact with App V2. When all user sessions connected to App V1 end or time out, App V1 is undeployed.
The key to understanding how production redeployment works for a portal application is to note that during production redeployment, both the old and new application share the same database, security repository, and content repository.
Figure 4-4 Production Redeployment Overview
Because both applications share the same back-end systems, side effects can occur during production redeployment. To illustrate this, consider the following scenario. Developers have added a new portlet to the App V2 portal's home page. When the new portal is deployed, that portlet and the updated page definition containing the new portlet are placed in the production database. Now, because both the old and new applications share the same database, App V1 may attempt to display the new portlet. Unfortunately, any supporting file-based code that underlies the portlet will not exist in the App V1 deployment, resulting in an error.
This simple example scenario illustrates that side effects during production redeployment typically occur because the shared database contains application-specific references. Potentially, differences that exist between the underlying deployments of the "side-by-side" applications can result in errors. Keep in mind that all external touch points to your application, such as application resources that are referenced in the database, must be consistent between the two applications. For example, the class name of a portlet backing file is stored in the database along with the portlet's definition. If you rename or remove a backing file, existing users accessing the original application may encounter errors. Similarly, if you add a new page to your portal that contains new portlets, during production redeployment the page and portlet definitions will be added to the database and could inadvertently show up in the original application. In this case users of the original application could experience errors.
Tip:
If the only underlying differences between the old and new application are in the collection of files and application code that are not referenced by the database, the production redeployment is likely to be successful.These scenarios illustrate possible side effects that can occur during production redeployment of a WebLogic Portal application. Later sections discuss additional, possible side effects as well as recommended use cases for production redeployment.
Caution:
It is recommended that you perform all the required steps for production redeployment in a staging environment first, before redeploying in a live production environment.Figure 4-5 illustrates the basic steps for production redeployment with a WebLogic Portal installation.
Figure 4-5 Basic Steps to Update a Portal Using Production Redeployment
Place the old application in maintenance mode. See Section 9.1.4, "OnlineMaintenanceModeTask" for details.
Caution:
If your WebLogic Portal site allows visitor customization or administrator activity, it is strongly recommended that you use Maintenance Mode or another strategy to restrict or eliminate such activity during production redeployment. Maintenance mode prevents administrators from making changes to the portal through the WebLogic Portal Administration Console. You can enable Maintenance Mode in the WebLogic Portal Administration Console by selecting Configurations > Service Administration. For more information, refer to the Administration Console online help.Follow the instructions in "Using Production Redeployment to Update Applications" in Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server to deploy the new application "side-by-side" with the old application in the same domain.
Note:
The WebLogic Server document, "Using Production Redeployment to Update Applications" in Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server, offers a detailed, step-by-step procedure for production redeployment that applies to any application deployed on WebLogic Server, including portal applications.Caution:
It is recommended that you initially deploy the new application version in Administration mode. Administration mode makes the application available only via a configured Administration channel. External clients cannot access an application that has been distributed and deployed in Administration mode. For more information, see the WebLogic Server document, "Starting a Distributed Application in Administration Mode" Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server.Use the propagation tools to propagate the updated application from the staging environment to the production environment. Propagation is a required step if any changes to the portal were made using the Administration Console in the staging area.
Note:
For background information on propagation, including use cases, see Chapter 5, "Developing a Propagation Strategy."After propagation, administrators can run the new application and verify that it is functioning properly in the new environment.
Finally, you can switch off Administration mode. The application begins to allow new client connections. At that point all new user connections are directed to the new application. After all user sessions end or time out on the old application, the old application is undeployed.
The following sections discuss possible scenarios for production redeployment and the known limitations of each.
This section describes several scenarios in which application redeployment can be used with WebLogic Portal.
Caution:
If you use production redeployment in any case where database changes are made, you cannot roll back or revert the application to its original state. The database contains representations of portal framework and datasync elements used by the portal at runtime. For example, values for features such as user customization and entitlements are stored in the database.This section discusses the following redeployment scenarios:
Section 4.13.4.1, "Adding, Removing, or Updating a Non-Portal Asset"
Section 4.13.4.2, "Adding, Removing, or Updating Portal Assets with Database Changes"
Adding, removing, or updating a non-portal asset refers to a adding or removing an asset that does not require any change to the database. In this scenario, production redeployment is a safe and recommended technique for achieving zero-downtime redeployment.
Examples:
Adding new images to a portal
Presentation changes, such CSS changes
New servlets or EJBs that are not referenced by a portlet
Caution:
Anytime database changes or changes to any back-end data source are required, production redeployment is not recommended. If you decide to use production redeployment, use extreme caution. Thoroughly test your redeployment in a staging environment first. For more information, see Section 4.13.6, "Side Effects of Production Redeployment."In this scenario, assets that require database changes are added to or removed from the new version of the portal. If you change the structure of a portal, such as by adding a new page to an existing book, upon deployment, the changes are automatically pulled into the database.
In this scenario, WebLogic Portal does not fully support production redeployment. This is because application database rollback is not supported. WebLogic Portal cannot revert the changes in the database once they have been applied.
Note:
Application rollback is not supported whenever you use the propagation tools to propagate portal assets. See Section 6.10, "Rolling Back an Import Process" for more information.Examples:
Adding, removing, or modifying portlets, books, pages
Adding, removing, or modifying datasync files
In this scenario, the newly deployed application requires portal assets to be propagated. Because propagation alters the portal database, application rollback is not supported in this case. For an introduction to propagation, see Chapter 5, "Developing a Propagation Strategy."
Caution:
Anytime database changes or changes to any back-end data source are required, production redeployment is not recommended. If you decide to use production redeployment, use extreme caution. Thoroughly test your redeployment in a staging environment first. For more information, see Section 4.13.6, "Side Effects of Production Redeployment."Note:
Application rollback is not supported whenever you use the propagation tools to propagate portal assets. See Section 6.10, "Rolling Back an Import Process" for more information.This section discusses several issues and limitations related to production redeployment of a WebLogic Portal application. Please review this section before attempting to use application redeployment with a WebLogic Portal application.
This section includes these topics:
Reversing or "rolling back" the production redeployment process switches the state of the active and retiring applications and redirects new client connection requests accordingly. Reverting the production redeployment process might be necessary if you detect a problem with a newly-deployed version of an application, and you want to stop clients from accessing it. Application rollback is described in the WebLogic Server document "Rolling Back the Production Redeployment Process" in Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server.
Generally, anytime your production redeployment changes WebLogic Portal database entries, application rollback is not supported for WebLogic Portal production redeployment. Again, because the old and new applications share the same database, if the database changes during redeployment, those changes cannot be rolled back, leading to possible side effects for users of the original application.
For more information and examples of scenarios where database changes occur, see Section 4.13.4, "Application Redeployment Scenarios."
Because the production redeployment feature executes two full version of the WebLogic Portal application at the same time, you need to consider memory and CPU requirements. While it is impossible to specify the exact amount of memory and CPU that will be required for production redeployment, a good rule of thumb is to double the current running load on the server. For example if the application is taking one gigabyte of memory and using 40% of the current CPU then it should be assumed that the second version will also require the same about of memory and CPU. For this reason, you may want to consider scheduling your production redeployments when there is less user activity and load on the WebLogic Portal server instances.
The WebLogic Portal propagation tools do not support database rollback. For this reason if a deployment scenario requires propagation to be used, roll back of the application cannot be performed.
See Section 6.10, "Rolling Back an Import Process" for more information.
It is recommended that you use the same data store between versions of a WebLogic Portal application.
WebLogic Portal does not support changes to the database schema when using production redeployment.
The WebLogic Portal cache framework only invalidates cache entries for the current application. Any applications that are running during production redeployment will not see cache invalidations. Because of this, it is possible to see stale cache entries between different version of the application.
File-based content repositories are not supported for production redeployment.
Production redeployment is not supported for any application that uses expression-based role policies. For information on defining roles using expressions, see the Oracle Fusion Middleware Security Guide for Oracle WebLogic Portal.
External systems that depend on a WebLogic Portal application can be affected when using production redeployment. Because production redeployment only uses HTTP session management to manage which version of an application a user is connected to, the following non-HTTP frameworks always reference the newer version of the application:
WSRP – A WSRP consumer maintains a session state with a producer on behalf of a user. Therefore, any external application consuming a WSRP portlet will transition to the new application version after the session times out.
EJB – Do not access EJBs from outside of the WebLogic Portal application. See "Using Production Redeployment to Update Applications" in Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server.
JMS – Any MDB processing messages or messages sent to the WebLogic Portal application will be processed by the new version of application.
External Databases – Any databases or database tables that your portal accesses will be processed by the newer version of the application.
Content Management Repositories – If the content management system interacts with portal assets stored in the database, the interactions must be consistent between the old and new versions of the redeployed application. For example, if the newer application is configured to do full text searches, but the original application is not, full text searches will inadvertently appear in the original application.
Other Back-End Resources/Systems – Any back-end systems must not change schema or API or protocol between application versions.
This section lists known side-effects of using production redeployment with a WebLogic Portal application. This section includes these topics:
Customization to desktops are not immediately viewable in new or old versions of a portal application. For example, if an administrator alters users' desktops in the new version of an application, the change may not be immediately viewable. Because customizations are cached for users of the old version of the application, users will not see the new customization until the cache times out.
When the new version of the application is deployed, WebLogic Portal alters the portal database. For example, when a new portlet is added that does not exist in the old application, the database is updated for the new application. Because of this, users currently using the older version of the application may see the portlet but not have the ability to render it because the file system assets do not exist in the older version.
Entitlements have both LDAP and RDBMS artifacts, meaning they will be shared between versioned applications which use the same database. One side effect of this is that a WebLogic Portal Administration Console administrator in the older application could affect entitlements in the versioned application (and vice versa).
A WSRP consumer maintains a session state with a producer on behalf of a user. Therefore, any external application consuming a WSRP portlet will transition to the new application version after the session times out.
|
 Copyright © 2010, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
