6 Configuring High Availability for Oracle ADF and WebCenter Applications

This chapter describes high availability concepts and configuration procedures for Oracle Application Development Framework (Oracle ADF) and Oracle WebCenter.

This chapter includes the following sections:

6.1 Oracle ADF and High Availability Concepts

Oracle ADF is an end-to-end application framework that builds on Java Platform, Enterprise Edition (Java EE) standards and open-source technologies to simplify and accelerate implementing service-oriented applications. Oracle ADF is suitable for enterprise developers who want to create applications that search, display, create, modify, and validate data using web, wireless, desktop, or web services interfaces. Used in tandem, Oracle JDeveloper 11g and Oracle ADF provide an environment that covers the full development lifecycle from design to deployment, with drag-and-drop data binding, visual UI design, and team development features built in.

6.1.1 Understanding Oracle ADF

In line with community best practices, applications built using the Fusion web technology stack achieve a clean separation of business logic, page navigation, and user interface by adhering to a model-view-controller (MVC) architecture supported by the following layers.

As shown in Figure 6-1, in an MVC architecture:

  • The model layer represents the data values related to the current page

  • The view layer contains the UI pages used to view or modify that data

  • The controller layer processes user input and determines page navigation

  • The business service layer handles data access and encapsulates business logic

Figure 6-1 Overview of Oracle ADF Architecture

Overview of Oracle ADF Architecture
Description of "Figure 6-1 Overview of Oracle ADF Architecture"

6.1.1.1 Oracle ADF Components

The core module in the framework is Oracle ADF Model, a declarative data binding facility that implements the JSR-227 specification. This specification provides an API for accessing declarative data binding metadata. The Oracle ADF Model layer enables a unified approach to bind any user interface to any business service, without the need to write code.

The other modules that make up a Fusion web application technology stack are:

  • Oracle ADF Business Components, which simplifies building business services.

  • Oracle ADF Faces, which offers a rich library of AJAX-enabled UI components for Web applications built with JavaServer Faces (JSF).

  • Oracle ADF Controller, which integrates JSF with Oracle ADF Model. The ADF Controller extends the standard JSF controller by providing additional functionality, such as reusable task flows that pass control not only between JSF pages, but also between other activities, for instance method calls or other task flows.

Figure 6-2 illustrates where each Oracle ADF module fits in the Fusion web application architecture.

Figure 6-2 Simple Oracle ADF Architecture

Simple Oracle ADF Architecture
Description of "Figure 6-2 Simple Oracle ADF Architecture"

6.1.1.1.1 ADF Business Components

ADF Business Components are prebuilt application objects that accelerate the job of delivering and maintaining high-performance, richly functional, database-centric services. When building service-oriented Java EE applications, developers implement the core business logic as one or more business services. These backend services provide clients with a way to query, insert, update, and delete business data as required while enforcing appropriate business rules. ADF Business Components provides a ready-to-use implementation of Java EE design patterns and best practices.

Oracle ADF Business Components provides the following key components to simplify building database-centric business services:

  • Entity object

    An entity object represents a row in a database table and simplifies modifying its data by handling all data manipulation language (DML) operations. It can encapsulate business logic to ensure that business rules are consistently enforced. Developers can associate an entity object with others to reflect relationships in the underlying database schema to create a layer of business domain objects to reuse in multiple applications.

  • View object

    A view object represents a SQL query and simplifies working with its results. Developers use the SQL language to join, project, filter, sort, and aggregate data into the shape required by the end-user task being represented in the user interface. This includes the ability to link a view object with other entity objects to create master-detail hierarchies of any complexity. When end users modify data in the user interface, view objects collaborate with entity objects to consistently validate and save the changes.

  • Application module

    An application module is the transactional component that UI clients use to work with application data. It defines an updateable data model and top-level procedures and functions (called service methods) related to a logical unit of work related to an end-user task.

For more information about Oracle ADF Business Components, go to the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.

6.1.1.1.2 ADF Model Layer

In the model layer, Oracle ADF Model implements the JSR-227 service abstraction called the data control. Data controls abstract the implementation technology of a business service by using standard metadata interfaces to describe the service's operations and data collections, including information about the properties, methods, and types involved. In Oracle JDeveloper, developers can view that information as icons that they can easily drag and drop onto a page. When the developer drags the representation of the service onto the page, Oracle JDeveloper automatically creates the bindings from the page to the services. At runtime, the ADF Model layer reads the information describing the application's data controls and data bindings from appropriate XML files and implements the two-way connection between the user interface and the application's business service.

Oracle ADF provides out-of-the-box data control implementations for the most common business service technologies. Using Oracle JDeveloper and Oracle ADF together provides a declarative, drag-and-drop data binding experience for building user interfaces. Along with support for ADF Business Components application modules, ADF Model also provides support for the following service technologies:

  • Enterprise JavaBeans (EJB) session beans and JPA entities

  • JavaBeans

  • Web services

  • XML

  • CSV files

For more information about Oracle ADF Model, go to the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.

6.1.1.1.3 ADF Controller

In the controller layer, where handling page flow of the web applications is a key concern, ADF Controller provides an enhanced navigation and state management model on top of JSF. JDeveloper supports declarative creation of task flows that can manage application control between different types of activities, such as pages, methods on managed beans, declarative case statements, or calls to other task flows.

For more information about Oracle ADF Controller, go to the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.

6.1.1.1.4 ADF Faces Rich Client

ADF Faces rich client (ADF Faces for short), is a set of standard JSF components that include built-in AJAX functionality. AJAX is a combination of asynchronous JavaScript, dynamic HTML (DHTML), XML, and XmlHttpRequest communication channel. This combination allows requests to be made to the server without fully rerendering the page. While AJAX allows rich client-like applications to use standard internet technologies, JSF provides server-side control, which reduces the dependency on an abundance of JavaScript often found in typical AJAX applications.

ADF Faces provides over 100 rich components, including hierarchical data tables, tree menus, in-page dialogs, accordions, dividers, and sortable tables. ADF Faces also provides ADF Data Visualization components, which are Flash- and SVG-enabled components capable of rendering dynamic charts, graphs, gauges, and other graphics that can provide a real-time view of underlying data. Each component also supports customization and skinning, along with internationalization and accessibility.

To achieve these front-end capabilities, ADF Faces components use a rendering kit that handles displaying the component and also provides the JavaScript objects needed for the rich functionality. This built-in support enables developers to build rich applications without needing extensive knowledge of the individual technologies on the front or back end.

For more information about ADF Faces, including the architecture and detailed information about each of the components, go to the Oracle Fusion Middleware Web User Interface Developer's Guide for Oracle Application Development Framework.

6.1.1.2 Oracle ADF Single Node Architecture

You can install the Oracle ADF runtime to the Oracle WebLogic Server using either the Oracle JDeveloper Installer or the Oracle Fusion Middleware Application Developer Installer. The Application Developer Installer also lets you optionally install Fusion Middleware Control to provide web-based administration support for all Managed Servers in the domain. The Oracle JDeveloper installer does not install Fusion Middleware Control. Both of these options are described in the deployment chapter of the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.

When you use the Application Developer Installer to install the Oracle ADF runtime, it results in the creation of an Oracle Application Developer home directory (by default, Oracle_APPDEV1) located under the Middleware home. After the administrator uses the domain configuration wizard to create an Application Developer domain (base_domain) based on the JRF domain template, the administrator can configure the topology of the server. In a typical set up, the domain contains an Administration server containing the WLS Administration Console and Fusion Middleware Control. Typically, the Oracle ADF runtime libraries (part of the Java Required Files) get deployed to the Managed Servers, in addition to the user-facing custom Fusion web applications. To provide customization and personalization features, an optional MDS repository may also be installed, and needs to be configured separately. Figure 6-3 shows a basic single-node Oracle ADF architecture.

Figure 6-3 Basic Single-Node Oracle ADF Architecture

Description of Figure 6-3 follows
Description of "Figure 6-3 Basic Single-Node Oracle ADF Architecture"

For more information about domains and servers, see the Oracle Fusion Middleware Administrator's Guide.

6.1.1.3 Oracle ADF External Dependencies

If the Fusion web application involves customization using Oracle Metadata Services (MDS), you should register your MDS repository with the Oracle WebLogic Server domain before you deploy the application. For information about registering MDS, see the Oracle Fusion Middleware Administrator's Guide.

Then, when you deploy the application, JDeveloper prompts you to choose the target metadata repository or shared metadata repository. You will be able to choose from the list of metadata repositories registered with the Oracle WebLogic Administration Server.

To ensure that you receive the metadata repository prompt, the application's adf-config.xml file must define a cust-config element in the mds-config section. This element specifies an ordered and named list of customization classes. A customization class is the interface that MDS uses to define which customization applies to the base definition metadata. In JDeveloper, you can use the overview editor for the adf-config.xml file to define a cust-config element.

For information about configuring the adf-config.xml file for MDS, see the chapter on customizing with MDS in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.

For more information about the MDS architecture and metadata repositories (database and file-based) and archives (EAR, MAR), refer to the Oracle Fusion Middleware Administrator's Guide.

6.1.1.4 Oracle ADF Log File

The operations performed by the Fusion web application are logged directly to the WebLogic Managed Server where the application is running:

DOMAIN_HOME/servers/server_name/logs/server_name-diagnostic.log

The log files for the different WebLogic Managed Servers are also available from the Oracle WebLogic Server Administration Console. To verify the logs, access the Oracle WebLogic Server Administration Console http://<admin_server_host>:<port>/console and click on Diagnostics-Log Files.

This log's granularity and logging properties can be changed using Oracle Enterprise Manager Fusion Middleware Control (Fusion Middleware Control). Fusion Middleware Control is a Web browser-based, graphical user interface that you can use to monitor and administer a farm. To receive high availability warning diagnostic messages for Oracle ADF, the level should be set to FINE, as described in Section 6.1.4.3, "Troubleshooting Oracle ADF Replication and Failover Issues."

For more information about the level of diagnostics you can specify for Fusion web applications, see the chapter on testing and debugging in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.

For details about using Fusion Middleware Control to change the log settings of WebLogic Managed Servers and Oracle ADF, see the Oracle Fusion Middleware Administrator's Guide.

6.1.2 Oracle ADF High Availability Considerations

Fusion web applications built on the Oracle ADF technology stack are Java EE applications (and J2EE applications). You should observe the same best practices for Fusion web applications as you would any other Java EE application in a high availability environment.

6.1.2.1 Oracle ADF Scope and Session State

At runtime, ADF objects such as the binding container and managed beans are instantiated. Each of these objects has a defined life span set by its scope attribute.

There are six types of scopes in a Fusion web application:

  • Application scope: The object is available for the duration of the application.

  • Session scope: The object is available for the duration of the session.

  • Page flow scope: The object is available for the duration of a bounded task flow.

  • Request scope: The object is available from the time an HTTP request is made until a response is sent back to the client.

  • Backing bean scope: Used for managed beans for page fragments and declarative components only, the object is available from the time an HTTP request is made until a response is sent back to the client.

  • View scope: The object is available until the view ID for the current view activity changes. This scope can be used to hold values for a given page. However, unlike request scope, which can be used to store a value needed from one page to the next, anything stored in view scope will be lost once the view ID changes.

When the Fusion web application runs in a clustered environment, a portion of the application's state is serialized and copied to another server or a data store at the end of each request so that the state is available to other servers in the cluster.

When you are designing an application to run in a clustered environment, you must:

  • Ensure that all managed beans with a life span longer than one request are serializable (that is, they implement the java.io.Serializable interface). Specifically, beans stored in session scope, page flow scope, and view scope need to be serializable.

  • Ensure that Oracle ADF is aware of changes to managed beans stored in ADF scopes (view scope and page flow scope) and enable the tracking of changes to ADF memory scopes.

When a value within a managed bean in either view scope or page flow scope is modified, the application needs to notify Oracle ADF so that it can ensure the bean's new value is replicated.

In Example 6-1, an attribute of an object in view scope is modified.

Example 6-1 Code that Modifies an Object in viewScope

Map<String, Object> viewScope =
    AdfFacesContext.getCurrentInstance().getViewScope();
MyObject obj = (MyObject)viewScope.get("myObjectName");
Obj.setFoo("newValue");

Without additional code, Oracle ADF will be unaware of this change and will not know that a new value needs to be replicated within the cluster. To inform Oracle ADF that an object in an ADF scope has been modified and that replication is needed, use the markScopeDirty() method, as shown in Example 6-2. The markScopeDirty() method accepts only viewScope and pageFlowScope as parameters.

Example 6-2 Additional Code to Notify Oracle ADF of Changes to an Object

controllerContext ctx = ControllerContext.getInstance();
ctx.markScopeDirty(viewScope);

This code is needed for any request that modifies an existing object in one of the ADF scopes. If the scope itself is modified by the scope's put(), remove(), or clear() methods, it is not necessary to notify Oracle ADF.

To enable ADF Controller to track changes to ADF memory scopes and replicate the page flow scope and view scope within the server cluster, you can enable the<adf-scope-ha-support> parameter in the adf-config.xml file, as described in Section 6.1.3.3, "Configuring adf-config.xml."

For more information about ADF object scopes, see the chapter on Fusion page lifecycle in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.

6.1.2.2 Oracle ADF Failover and Expected Behavior

An Oracle WebLogic cluster provides application high availability. If one member of the cluster is unavailable, any other available member of the cluster is able to handle the request.

Session Failover Requirements

For seamless failover of a Fusion web application, the application must meet the following conditions:

  • The application is in a cluster and at least one member of the application cluster is available to serve the request.

  • For stateful applications, state replication is configured correctly as described in Section 6.1.3, "Configuring Oracle ADF for High Availability."

  • If you are using Oracle HTTP Server, the server is configured with the WebLogicCluster directive to balance among all available application instances.

  • If you are using a hardware load balancer, the load balancer is:

    • Routing traffic to all available instances

    • Configured correctly with a health monitor to mark unavailable instances

    • Configured to support persistence of session state

Expected Behavior for Application Failover

If the environment has been configured correctly, application users do not notice when an application instance in a cluster becomes unavailable. The sequence of events in an application failover is, for example, as follows:

  1. A user makes a request and is routed by a hardware load balancer to instance A of the application.

  2. Instance A of the application becomes unavailable because of node failure, process failure, or network failure.

  3. The hardware load balancer marks instance A as unavailable.

  4. The user makes a subsequent request. The request is routed to instance B.

  5. Instance B is configured as a replication partner of Instance A and has the user's session state.

  6. The application resumes using the session state on Instance B and the user continues working without interruption.

6.1.2.3 Oracle ADF Active Data Services

The Fusion technology stack includes the Active Data Service (ADS), which allows you to bind ADF Faces components to an active data source using the ADF Model layer. In JDeveloper, you configure individual components in your JSF pages to display active data. When you configure components to use active data, data is pushed to the client whenever a change event is raised by the data source. The data is pushed from the server to the client and displayed by the browser.

To support failover for pages configured to display active data, it is necessary to enable failover for the ADF Business Components application module and to enable ADF Controller to track changes to the ADF memory scopes. With these ADF settings configured, when failover occurs, the ADF server will detect the failover and request all pages configured to display active data to refresh themselves, after that ADS restarts and data is pushed to the client.

For details about how to enable failover for the Fusion web application, see Section 6.1.3, "Configuring Oracle ADF for High Availability."

For more information about using Oracle ADF Faces components with an active data service, see the chapter on ADS in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.

6.1.2.4 Configuring the ADF Application Module for Oracle RAC

When configuring the ADF application module to access a highly available database system, such as redundant databases or Oracle Real Application Clusters (Oracle RAC) as the backend, the data source must be container-defined. In this scenario, it is required to use a multi data source; however, from the standpoint of the application module configuration, the naming convention for the multi data source is the same as it is an non-multi data source. This ensures that the correct data source will be used at runtime. For details about configuring multi data sources for high availability applications, see Section 4.1.3, "Configuring Multi Data Sources with Oracle RAC.".

6.1.3 Configuring Oracle ADF for High Availability

To support automatic replication and failover for web applications within a clustered environment, Oracle WebLogic Server supports mechanisms for replicating HTTP session state across clusters. You can configure Oracle ADF to ensure the Fusion web application's state can be restored from any server in the cluster.

6.1.3.1 Configuring Application Modules

An application module is the transactional component that UI clients use to work with application data. It defines an updateable data model and top-level procedures and functions (called service methods) related to a logical unit of work related to an end-user task. An application module supports storing of its transaction state as a snapshot in the database. It also supports the reverse operation of activating the transaction state from one of these saved snapshots.

To enable support for ADF Business Components failover, set the jbo.dofailover parameter to true so that the application module state is saved on release. This allows Oracle ADF to restore the application module state from a snapshot saved from a previous checkin. By contrast, when the failover feature is disabled, which it is by default, then application module state is saved only when the application is reused by a subsequent user session and only when the application module pool cannot find an unused application module.

You can set this parameter in your application module configuration on the Pooling and Scalability tab of the Edit Business Components Configuration dialog.

To configure application modules for high availability:

  1. Launch JDeveloper and open the application.

  2. In the Application Navigator, expand the project that contains the data model and locate the application module.

  3. Right-click the application module and select Configurations.

  4. Click Edit.

  5. Click the Pooling and Scalability tab.

  6. Select the Failover Transaction State Upon Managed Release checkbox.

  7. Click OK to close the Edit Business Components Configuration dialog.

  8. Click OK to close the Manage Configurations dialog.

For more information about Oracle ADF state management facilities and how to use them, see the chapter on application state management in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.

6.1.3.2 Configuring weblogic.xml

To enable support for replicating HTTP session state, you must assign a value to the persistent-store-type element in the Oracle WLS weblogic.xml file. The value replicated_if_clustered ensures that the in-effect persistent store type will be replicated so that sessions on the clustered environment are stored in accordance with the value set for the cluster of servers to which this server belongs.

To configure the weblogic.xml file for high availability:

  1. Launch JDeveloper and open the application.

  2. In the Application Navigator, expand the project that contains the web application and expand the WEB-INF folder.

  3. Double-click the weblogic.xml file, and click the Source tab to edit the file.

  4. In the file, add the persistent-store-type definition to the session-descriptor element:

    <weblogic-web-app>
    <session-descriptor>
    <persistent-store-type>
    replicated_if_clustered
    </persistent-store-type>
    </session-descriptor>
</weblogic-web-app>

6.1.3.3 Configuring adf-config.xml

When you are designing an application to run in a clustered environment, you must make sure that Oracle ADF is aware of changes to managed beans stored in ADF scopes (view scope and page flow scope).

When a value within a managed bean in either view scope or page flow scope is modified, the application needs to notify Oracle ADF so that it can ensure the bean's new value is replicated.

To enable ADF Controller to track changes to ADF memory scopes and replicate the page flow scope and view scope within the server cluster, you must set the ADF Controller parameter <adf-scope-ha-support> in the application's adf-config.xml file to true. For example, when set to true for an application and that application adds or removes a bean from a page flow scope during a request, the change will automatically replicated within a cluster.

The adf-config.xml file is the central configuration file for all ADF components. The file contains sections to configure the runtime behavior for ADF components, including, ADF Controller.

To configure the adf-config.xml file for high availability:

  1. Launch JDeveloper and open the application.

  2. In the Application Navigator, expand the Application Resources.

  3. Select Descriptors, and then select the ADF META-INF node.

  4. Double-click the adf-config.xml file, and click the Source tab to edit the file.

  5. Add the following to the file:

    <adf-controller-config xmlns="http://xmlns.oracle.com/adf/controller/config">
 <adf-scope-ha-support>true</adf-scope-ha-support>
</adf-controller-config>

For more information about using the adf-config.xml file to configure ADF, see the chapter on creating complex task flows in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.

6.1.4 Troubleshooting Oracle ADF High Availability

This section describes procedures for troubleshooting possible issues with Oracle ADF.

6.1.4.1 Troubleshooting Oracle ADF Development Issues

When you develop the Fusion web application in Oracle JDeveloper, the integrated development environment provides support for detecting potential High Availability issues. The warnings that JDeveloper provides are generated by the audit framework and will be triggered to display in the JDeveloper source editors. The warnings the editors display are based on the audit rules for High Availability applications.

The High Availability audit rules that JDeveloper enables by default are:

  1. ADF Controller Configuration - High Availability for ADF Scopes is not Enabled simply warns the developer that the adf-scope-ha-support flag in the adf-config.xml file is set is not set to true. This audit rule fires only when the <adf-controller-config> element is present the ADF application-level configuration file (adf-config.xml).

  2. ADF Page Flows - EL Bean is Modified warns the developer when the class calls a setter method on a bean to indicate that the scope must be marked dirty (using the ControllerContext.markScopeDirty() method). This audit rule fire only when the adf-scope-ha-support flag in the adf-config.xml file is set to true.

  3. ADF Page Flows - Managed Bean Class Not Serializable warns the developer that a managed bean has a non-serializable class defined in viewScope, pageFlowScope, or sessionScope. This audit rule fire only when the adf-scope-ha-support flag in the adf-config.xml file is set to true.

You can modify the High Availability audit rule settings using the Preference dialog in JDeveloper. From the JDeveloper toolbar, choose Tools - Preferences, under Audit - Profiles expand ADF Controller Configuration or ADF Pages Flows and make the desired audit rule selections.

You can also trigger the audit by choosing Build - Audit project.jpr from the JDeveloper toolbar.

6.1.4.2 Troubleshooting Oracle ADF Deployment Issues

Fusion web applications are deployed when the managed server is first started. Use the Oracle WebLogic Server Administration Console first to check that all application deployments were successful:

Click Deployments in the left hand pane. The right hand pane shows the application deployments and their status. The state of all applications, assuming all the servers are running, should be ACTIVE.

If an application deployment has failed, the server logs may provide some indication of why the application was not deployed successfully. The server logs are located in the DOMAIN_HOME/servers/server_name/logs directory. Common issues include:

  • Unavailability of external resources, such as database resources. Examine the error, fix it, and attempt to redeploy the application.

  • The appropriate applications or libraries are not targeted correctly to the right managed server or Cluster.

6.1.4.3 Troubleshooting Oracle ADF Replication and Failover Issues

State Replication is most prominent in failover scenarios. A user working on one server may discover that, upon failover:

  • Windows may be closed or state might be reset.

  • Screens may require a reset.

  • The application may be redirecting to the logon screen.

The following steps provide guidance in troubleshooting and diagnosing state replication issues.

  1. Confirm that this is not a known replication issue.

    See Section 6.1.2.2, "Oracle ADF Failover and Expected Behavior" for possible expected behaviors. Before proceeding to further diagnose the issue, first confirm that the failover behavior is not an expected behavior.

  2. Check load balancer settings.

    For replication and failover to function correctly, the load balancer must be configured with the appropriate persistence settings. For more details on configuring Hardware Load Balancers for Oracle WebLogic Server, see Oracle Fusion Middleware Using Clusters for Oracle WebLogic Server.

  3. Check the cluster status.

    Replication occurs within the context of a cluster. For failover to be successful, there must be at least one other healthy member of the cluster available. You can check cluster status in one of two ways:

    • Check the cluster status using the Oracle WebLogic Server Administration Console - In the Left-hand pane, click on Servers. Verify the state of all servers in the cluster.

    • Check the cluster status using weblogic.Admin utility The weblogic.Admin command can be used to query the state of all servers in a specific cluster. For example:

      $ java weblogic.Admin -url Adminhost:7001 -username <username> -password
 <password>  CLUSTERSTATE -clustername Spaces_Cluster

      This example returns:

      There are 2 server(s) in cluster: Spaces_Cluster
The alive servers and their respective states are listed below:
Application Server---RUNNING
Managed Server---RUNNING

  4. Check cluster communications.

    Although Cluster members may all be running, there may be communication issues which prevent them from communicating replication information to each other. There are two types of cluster communication configurations. Troubleshooting depends on the cluster type:

    • Checking Unicast cluster communications - For Unicast clusters, managed servers must be able to access each other's hosts and each other's default listening port.

      Ensure that all individual managed servers have their Listen Address set correctly. You can find this setting by selecting Configuration, General for each managed server.

    • Checking Multicast cluster communications - For multicast clusters, servers must be able to intercept the same multicast traffic. Ensure that multicast is configured correctly by running the WebLogic utility utils.MulticastTest on each machine. For example:

      $ java utils.MulticastTest -H

  5. Confirm Oracle WLS application configuration.

    Oracle WLS is not configured by default for failover by default. In-memory replication takes place only with the proper setting in the weblogic.xml file:

    <session-descriptor>
<persistent-store-type>replicated_if_clustered</persistent-store-type>
</session-descriptor>

    A persistent-store-type of replicated is also acceptable. This setting can be made in JDeveloper, as described in Section 6.1.3.2, "Configuring weblogic.xml."

  6. Confirm Oracle ADF Business Components configuration.

    Oracle ADF is not configured by default for failover by default. Failover is supported only with the proper setting in the ADF Business Components configuration file (bc4j.xml):

    <AppModuleConfig ...
 <AM-Pooling jbo.dofailover="true"/>
</AppModuleConfig>

    This setting is made in JDeveloper through the Edit Business Components Configuration dialog, as described in Section 6.1.3.1, "Configuring Application Modules."

  7. Confirm Oracle ADF Controller configuration.

    Oracle ADF is not configured by default to replicate changes to ADF objects in ADF memory scopes. ADF object replication is supported only with the proper setting in the ADF application-level configuration file (adf-config.xml):

    <adfc:adf-controller-config>
 <adfc:adf-scope-ha-support>true</adfc:adf-scope-ha-support>
</adfc:adf-controller-config>

    This setting is made in JDeveloper through the source editor, as described in Section 6.1.3.3, "Configuring adf-config.xml."

  8. Check default logger messages.

    By default the ADF log display high-level messages (INFO level). The default logging often reports problems with serialization and replication without the need to enable more detailed log messages. For more information about the log, see Section 6.1.1.4, "Oracle ADF Log File."

  9. Enable log messages for ADF high availability applications.

    Configure the ADF logger to output runtime messages for high availability. By default the ADF log display high-level messages (INFO level). You enable high availability diagnostics for ADF Controller by setting the logging level in Fusion Middleware Control to FINE.

    When enabled, the logger outputs a warning if the adfc:adf-scope-ha-support setting in the adf-config.xml file is not set. For more information about the ADF logger, see Section 6.1.1.4, "Oracle ADF Log File."

  10. Enable debug.

    Check the server logs for any unusual messages on managed server startup. In particular, if the managed server is unable to locate other members of the cluster. The server logs are located in the DOMAIN_HOME/servers/{SERVER_NAME}/logs directory.

    For further debugging, enable the flags DebugCluster, DebugClusterAnnouncements, DebugFailOver, DebugReplication, and DebugReplicationDetails. Each flag can be enabled with the weblogic.Admin utility:

    $ java weblogic.Admin -url Adminhost:7001 -username <username> -password
 <password> SET -type ServerDebug -property DebugCluster true

  11. Enable component state serialization checking.

    Enable server checking to ensure no unserializable state content on session attributes is detected. This check is disabled by default to reduce runtime overhead. Serialization checking is supported by the Java server system property org.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION.

    For high availability testing, start off by validating that the Session and JSF state is serializable by launching the application server with the system property:

    -Dorg.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION=session,tree

    If a JSF state serialization failure is detected, relaunch the application server with the system property to enable component and property flags and rerun the test:

    -Dorg.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION=all

6.2 Configuring an Oracle ADF High Availability Deployment

This section describes how to configure an example Oracle ADF high availability deployment.

Note:

Oracle strongly recommends reading the release notes for any additional installation and deployment considerations prior to starting the setup process.

6.2.1 Terminology for Directories and Directory Environment Variables

This list describes the directories and variables used in this section:

  • ORACLE_BASE: This environment variable and related directory path refers to the base directory under which Oracle products are installed.

  • MW_HOME: This environment variable and related directory path refers to the location where Oracle Fusion Middleware resides.

  • WL_HOME: This environment variable and related directory path contains installed files necessary to host a WebLogic Server.

  • ORACLE_HOME: This environment variable and related directory path refers to the location where Oracle Fusion Middleware SOA Suite is installed.

  • DOMAIN directory: This directory path refers to the location where the Oracle WebLogic domain information (configuration artifacts) is stored.

  • ORACLE_INSTANCE: An Oracle instance contains one or more system components, such as Oracle Web Cache, Oracle HTTP Server, or Oracle Internet Directory. An Oracle instance directory contains updateable files, such as configuration files, log files, and temporary files.

The values used and recommended for consistency for this directories are:

  • ORACLE_BASE: /u01/app/oracle

  • MW_HOME (application tier): ORACLE_BASE/product/fmw

  • WLS_HOME: MW_HOME/wlserver_10.3

  • ORACLE_HOME: MW_HOME/adf

6.2.2 Using RCU to Load Fusion Middleware Schemas in the Database

This step is required only if your ADF application needs to use any of schemas that are part of Oracle Fusion Middleware. Typically, this is done if the ADF application uses MDS repository, in which case you must install the 11g (11.1.1) Oracle Fusion Middleware Metadata Store into a Real Application Clusters (RAC) database before you install Oracle Fusion Middleware. Oracle Fusion Middleware provides a tool, the Oracle Fusion Middleware Repository Creation Utility (RCU), to create the component schemas in an existing database. See the Oracle Fusion Middleware Repository Creation Utility User's Guide for more information about installing RCU.

6.2.2.1 Running RCU

Run RCU to install the required metadata for Oracle Fusion Middleware 11g:

  1. Start up RCU using the following command:

    RCU_HOME/bin/rcu &

  2. In the Welcome screen, click Next.

  3. In the Create Repository screen, select Create to load component schemas into a database, and click Next.

  4. In the Database Connection Details screen, enter connection information for your database:

    • Database Type: Select Oracle Database

    • Host Name: Enter the name of the node that is running the database. For an Oracle RAC database, specify the VIP name, or one of the node names as the host name: ADFDBHOST1VIRTUAL.

    • Port: The port number for the database: 1521

    • Service Name: Enter the service name of the database: adfha.mycompany.com

    • Username: SYS

    • Password: Enter the password of the SYS user.

    • Role: SYSDBA

    Click Next.

  5. If you receive the following message, click Ignore or Stop:

    The database you are connecting is with non-UTF8 charset, if you are going to use this database for multilingual support, you may have data loss. If you are not using for multilingual support you can continue, otherwise, Oracle strongly recommends using a UTF-8 database.

  6. In the Select Components screen, select Create a New Prefix, and enter a prefix to use for the database schemas, for example, ADFHA.

    Write down the schema names so they are available in later procedures.

    Select the following schemas:

    • AS Common Schemas

    • Metadata Services

    Click Next.

  7. In the Schema Passwords screen, enter passwords for the main and additional (auxiliary) schema users, and click Next.

  8. In the Map Tablespaces screen, choose the tablespaces for the selected components, and click Next.

  9. In the Summary screen, click Create.

  10. In the Completion Summary screen, click Close.

See the Oracle Fusion Middleware Repository Creation Utility User's Guide for more information about installing RCU.

6.2.3 Installing Oracle HTTP Server on WEBHOST1

To install Oracle HTTP Server on WEBHOST1:

  1. Verify that the servers meet the following requirements:

    • The system, patch, kernel, and other requirements meet the requirements specified in the Oracle Fusion Middleware Repository Creation Utility User's Guide.

    • This example uses port 7777. If you choose port 7777, ensure that it is not used by any service on the nodes. You can verify this by running the following command:

      UNIX:
netstat -an | grep 7777

Windows:
netstat -an | findstr 7777

  2. If port 7777 is in use, choose another port, or make it available.

  3. On UNIX platforms, if the /etc/oraInst.loc or /var/opt/oracle/oraInst.loc file exists, check that its contents are correct. Specifically, check that the inventory directory is correct, and that you have write permissions for that directory.

    If the /etc/oraInst.loc file does not exist, skip this step.

  4. Start Oracle Universal Installer for Oracle Fusion Middleware 11g Webtier Utilities CD installation as follows:

    For UNIX, run this command: ./runInstaller

    For Windows, double-click setup.exe.

  5. In the Specify Inventory Directory screen, enter the location for the inventory and the user group, and click OK.

  6. Execute the root privileged actions as indicated in the dialog, and click OK.

  7. In the Welcome screen, click Next.

  8. In the Select Installation Type screen, select Install and Configure, and click Next.

  9. In the Prerequisite Checks screen, ensure that all the prerequisites are met, and click Next.

  10. In the Specify Installation Location screen, set the location to:

    /u01/app/oracle/product/11.1.1/ohs_1

    Click Next.

  11. In the Configure Components screen:

    • Select Oracle HTTP Server.

    • Do not select Associate Selected Components with WebLogic Domain.

    Click Next.

  12. In the Specify Component Details screen, enter the following values:

    • Instance Home Location:

      /u01/app/oracle/product/11.1.1/ohs_1/instances/ohs_instance1

    • Instance Name: ohs_instance1

    • OHS Component Name: ohs1

    Click Next.

  13. In the Specify Webtier Port Details screen:

    • Select Specify Custom Ports. If you specify a custom port, select Specify Ports using Configuration File and then use the Browse function to select the file.

    • Enter Oracle HTTP Server port. For example, enter 7777.

    Click Next.

    Note:

    For more information about setting ports, refer to the Oracle Fusion Middleware Installation Guide for Oracle SOA Suite.

  14. In the Configuration Summary screen, ensure that the selections are correct, and click Install.

  15. In the Installation Progress screen:

    For UNIX systems, a dialog box appears prompting you to run the oracleRoot.sh script. Open a command window and run the script, following the prompts.

    Click Next.

  16. In the Configuration screen, several configuration assistants are started in succession. When the configuration assistants are finished, the Configuration Completed screen appears.

  17. In the Configuration Completed screen, click Finish to exit.

6.2.3.1 Validating Oracle HTTP Server

To verify that Oracle HTTP Server is set up correctly, access the root URL context of the server by entering the following URL in a web browser:

WebHost1:7777/

If Oracle HTTP Server is set up correctly, the Hello World page appears in the browser.

6.2.4 Installing the Oracle Fusion Middleware Home

Use the information in these sections to install Oracle Fusion Middleware components:

6.2.4.1 Installing Oracle WebLogic Server

To install Oracle WebLogic Server on all nodes in the application tier:

  1. On UNIX platforms, if the /etc/oraInst.loc or /var/opt/oracle/oraInst.loc file exists, check that its contents are correct. Specifically, check that the inventory directory is correct and that you have write permissions for that directory.

    If the /etc/oraInst.loc file does not exist, skip this step.

  2. Start the Oracle WebLogic Server installer.

    On UNIX (Linux used in this example):
APPHOST1> server103_linux32.bin

On Windows:
APPHOST1> server103_win32.exe

  3. In the Welcome screen, click Next.

  4. In the Choose Middleware Home Directory screen:

    • Select Create a New Middleware Home.

    • For the Middleware Home Directory field, enter:

      ORACLE_BASE/product/fmw

    Click Next.

  5. In the Register for Security Updates screen, enter your contact information for security update notifications, and click Next.

  6. In the Choose Install Type screen, select Custom, and click Next.

  7. In the JDK Selection screen, select only JROCKIT SDK1.6.0_05, and click Next.

  8. In the Choose Product Installation Directories screen, accept the following directory:

    ORACLE_BASE/product/fmw/wlserver_10.3

    Click Next.

  9. In the Installation Summary screen, click Next.

  10. In the Installation Complete screen, deselect Run QuickStart, and click Done.

6.2.4.2 Installing Oracle Fusion Middleware for Oracle ADF Applications

To install Oracle Fusion Middleware for Oracle ADF, use the Application Developer Install and perform the following on all the nodes in the application tier:

  1. Start the Oracle Fusion Middleware for Oracle Fusion Middleware 11g Application Developer installer:

    On UNIX (Linux used in this example):
APPHOST1> runInstaller

On Windows:
APPHOST1> setup.exe

    When Oracle Fusion Middleware 11g Application Developer installer prompts you for a JRE/JDK location enter the Oracle SDK location created in the Oracle WebLogic Server installation in Section 6.2.4.1, "Installing Oracle WebLogic Server," for example:

    ORACLE_BASE/product/fmw/jrockit_160_05_R27.6.2-20

  2. In the Welcome screen, click Next.

  3. In the Prerequisite Check screen, verify that the checks complete successfully, and click Next.

  4. In the Specify Installation Location screen:

    • For Middleware Home, enter: ORACLE_BASE/product/fmw

    • For Oracle Home Directory, enter the directory you want to use, for example: adf

    Click Next.

  5. In the Installation Summary screen, click Install.

  6. In the Installation Complete screen, click Finish.

6.2.5 Administration Server High Availability

For information about configuring Oracle WebLogic Server Administration Server, see Chapter 10, "Active-Passive Topologies for Oracle Fusion Middleware High Availability."

6.2.6 Running the Configuration Wizard on APPHOST1 to Create the WebLogic Server ADF Domain

Run the Oracle Fusion Middleware Configuration Wizard from the adf directory in the Middleware home to create a domain containing the administration server and Oracle components.

  1. Start Oracle WebLogic Server Configuration Wizard from the MW_HOME/common/bin directory using the following command:

    APPHOST1> ./config.sh

  2. In the Welcome screen, select Create a New WebLogic Domain and click Next.

  3. In the Select Domain Source screen, select Generate a domain configured automatically to support the following products, and select the following products:

    • Oracle Enterprise Manager - 11.1.1.0

    • Oracle JRF - 11.1.1.0

    Click Next.

  4. Enter the Domain Name, Domain Location, and Application Location and click Next.

  5. In the Configure Administrator Username and Password screen, enter the username and password to be used for the domain's administrator, and click Next.

  6. In the Configure Server Start Mode and JDK screen, make the following selections:

    • WebLogic Domain Startup Mode: select Production Mode

    • JDK Selection: select JROCKIT SDK1.6.0_05

    Click Next.

  7. In the Select Optional Configuration screen, select the following:

    • Administration Server

    • Managed Servers, Clusters and Machines

    Click Next.

  8. In the Customize Server and Cluster Configuration screen, select Yes, and click Next.

  9. In the Configure the Administration Server screen, enter the following values:

    • Name: AdminServer

    • Listen Address: APPHOST1

    • Listen Port: 7001

    • SSL listen port: NA

    • SSL enabled: Leave unchecked

    Click Next.

  10. In the Configure Managed Servers screen, add the following managed servers:

    Managed Server Name Listen Address Listen Port SSL Listen Port SSL Enabled
    WLS_ADF1 Hostname of APPHOST1 8889 NA unchecked
    WLS_ADF2 Hostname of APPHOST2 8889 NA unchecked

    Click Next.

  11. In the Configure Clusters screen, add the following cluster:

    • Name: ADF_CLUSTER

    • Cluster Messaging Mode: unicast

    • Cluster Address Enabled: Leave blank

    Click Next.

  12. In the Assign Servers to Clusters screen, assign the following servers to the Cluster:

    • ADF_CLUSTER:

      • WLS_ADF1

      • WLS_ADF2

    Click Next.

  13. In the Configure Machines screen:

    • Delete the LocalMachine that appears by default.

    • Click the Unix Machine tab, and add the following machines:

      Name Node Manager Listen Address
      APPHOST1 Hostname of APPHOST1
      APPHOST2 Hostname of APPHOST2

    Click Next.

  14. In the Assign Servers to Machines screen, assign servers to machines as follows:

    • APPHOST1: AdminServer, WLS_ADF1

    • APPHOST2: WLS_ADF2

  15. In the Configuration Summary screen, click Create.

  16. In the Creating Domain screen, click Done.

6.2.6.1 Creating boot.properties for the Administration Server and Managed Servers on APPHOST1

This is an optional step for enabling the Administration Server to start up without prompting you for the administrator username and password. Create a boot.properties file for the Administration Server and for the managed servers on APPHOST1.

For the Administration Server, follow these steps:

  1. Create the following directory:

    APPHOST1> mkdir -p MW_HOME/wls/user_projects/domains/adfdomain/servers/AdminServer/security

  2. Use a text editor to create a file named boot.properties in the directory created in the previous step, and enter the following lines in the file:

    username=adminUser
password=adminUserPassword

    For example:

    username=weblogic
password=weblogic

    Note:

    When you start up the Administration Server or Managed Server, the username and password entries in the file are encrypted.

    For security reasons, minimize the time the entries in the file are left unencrypted. After you edit the file, start up the server as soon as possible in order for the entries to be encrypted.

For the WLS_ADF Managed Servers, follow these stesp:

  1. Copy the file you created for the Administration Server to all servers:

    APPHOST1> mkdir -p servers/WLS_ADF1
APPHOST1> mkdir -p servers/WLS_ADF1/security

  2. Use a text editor to create a file named boot.properties in the directory created in the previous step, and enter the following lines in the file:

    username=adminUser
password=adminUserPassword

    For example:

    username=weblogic
password=weblogic

6.2.7 Starting the System in APPHOST1

This section describes procedures for starting the system in APPHOST1.

6.2.7.1 Starting the Administration Server on APPHOST1

To start the Administration Server on APPHOST1 run the following commands:

APPHOST1> cd ORACLE_BASE/product/fmw/user_projects/domains/adfdomain/bin
APPHOST1> ./startWebLogic.sh

6.2.7.2 Validating the Administration Server

To verify that the administration server is properly configured, follow these steps:

  1. In a Web browser, go to http://VIP1:7001/console.

  2. Log in as the administrator.

  3. Verify that the WLS_ADF1 and WLS_ADF2 managed servers are listed.

  4. Verify that the ADF_Cluster cluster is listed.

  5. Verify that you can access Enterprise Manager at http://VIP1:7001/em.

6.2.7.3 Disabling Host Name Verification for the Administration Server and Managed Servers for APPHOST1 and APPHOST2

This step is required if you have not set up SSL communication between the Administration Server and the Node Manager. If SSL is not set up, you receive an error message unless you disable host name verification.

You can re-enable host name verification when you have set up SSL communication between the Administration Server and the Node Manager.

To disable host name verification on APPHOST1:

  1. In Oracle WebLogic Server Administration Console, select Administration Server, SSL, and then Advanced.

  2. Click Lock and Edit.

  3. When prompted, save the changes and activate them.

  4. Set Hostname Verification to None.

  5. Select WLS_ADF1, SSL, and then Advanced.

  6. Set Hostname Verification to None.

To disable host name verification on APPHOST2:

  1. In Oracle WebLogic Server Administration Console, select WLS_ADF2, SSL, and then Advanced.

  2. Set Hostname Verification to None.

6.2.7.4 Starting Node Manager on APPHOST1

Perform these steps to start Node Manager on APPHOST1:

  1. Run the setNMProps.sh script, which is located in the ORACLE_HOME/common/bin directory, to set the StartScriptEnabled property to true before starting Node Manager:

    OAHOST1> cd ORACLE_HOME/common/bin
SOAHOST1> ./setNMProps.sh

    Note:

    You must use the StartScriptEnabled property to avoid class loading failures and other problems.

  2. Start Node Manager:

    APPHOST1> cd ORACLE_BASE/product/fmw/wlserver_10.3/server/bin
APPHOST1> ./startNodeManager.sh

6.2.8 Installing Oracle WebLogic Server and Oracle ADF on APPHOST2

Repeat the procedures for installing WebLogic Server and Oracle ADF for APPHOST2, start with Section 6.2.3, "Installing Oracle HTTP Server on WEBHOST1." The directory paths for binary files and domains used when installing new nodes must be exactly the same as those used for the first node. If these paths and domains are not exactly the same as those used for the first node, failover does not occur.

6.2.9 Propagating the Domain Configuration to APPHOST2 with pack/unpack Utilities

Follow these steps to propagate the domain configuration to APPHOST2 using pack/unpack utilities:

  1. Run the following pack command on APPHOST1 to create a template pack:

    APPHOST1> cd ORACLE_BASE/product/fmw/wlserver_10.3/common/bin
APPHOST1> ./pack.sh -managed=true -domain=ORACLE_BASE/product/fmw/user_projects/domains/adfdomain/
-template=adfdomaintemplate.jar 
-template_name=adf_domain_template

  2. Run the following scp command command on APPHOST1 to copy the template file created in the previous step to APPHOST2:

    APPHOST1> scp adfdomaintemplate.jar
 user@node2:ORACLE_BASE/product/fmw/wlserver_10.3/common/bin

  3. Run the unpack command on APPHOST2 to unpack the propagated template:

    APPHOST2> cd ORACLE_BASE/product/fmw/wlserver_10.3/common/bin
APPHOST2> ./unpack.sh
 -domain=ORACLE_BASE/product/fmw/user_projects/domains/adfdomain/
 -template=adfdomaintemplate.jar

6.2.9.1 Creating boot.properties for the Administration Server and Managed Servers on APPHOST2

Create a boot.properties file for the Administration Server and for the Managed Servers on APPHOST2 by following these steps:

  1. Create the following directories:

    APPHOST1> mkdir -p MW_HOME/wls/user_projects/domains/adfdomain/servers/WLS_ADF2
APPHOST2> mkdir -p MW_HOME/wls/user_projects/domains/adfdomain/servers/WLS_ADF2/security

  2. Use a text editor to create a file named boot.properties in the directory created in the previous step, and enter the following lines in the file:

    username=adminUser
password=adminUserPassword

    For example:

    username=weblogic
password=weblogic

    Note:

    When you start up the Administration Server or Managed Server, the username and password entries in the file are encrypted.

    For security reasons, minimize the time the entries in the file are left unencrypted. After you edit the file, start up the server as soon as possible in order for the entries to be encrypted.

6.2.9.2 Starting Node Manager on APPHOST2

To start the Node Manager on APPHOST2, repeat the steps from Section 6.2.7.4, "Starting Node Manager on APPHOST1" on APPHOST2.

6.2.9.3 Configuring the ADF Application for Replication

Use the procedures in this section to configure your application for replication.

Clustering Requirement

The application must be deployed to an Oracle WebLogic Cluster. This automatically establishes a replication channel for the multiple instances of the application.

Note:

In a Unicast cluster, the default replication channel is configured using the Listen address of each managed server. Therefore, the Listen address should be configured to be a specific IP address or host name, instead of being configured to listen on Any.

Oracle ADF Replication

It is essential that Oracle ADF is configured properly. The following tag should be present in the adf-config.xml file, one of the Application Resources, for a stateful application:

<adfc:adf-controller-config><adfc:adf-scope-ha-support>true</adfc:adf-scope-ha-support></adfc:adf-controller-config>

Applications must also have replication enabled. Oracle WebLogic Server allows several types of persistent stores for replication. For more information on persistent stores, see the Oracle Fusion Middleware Using Clusters for Oracle WebLogic Server manual.

The ADF application can be enabled by for this by default with the following setting in the weblogic.xml file:

<session-descriptor>
<persistent-store-type>replicated_if_clustered</persistent-store-type>
</session-descriptor>

The replicated_if_clustered setting disables replication for standalone application environments, and uses in-memory replication within a cluster environment.

Ensure that any custom application is configured for in-memory replication.

6.2.9.4 Deploying the ADF Application

After the cluster has been set up, the ADF application can be deployed. Be aware of the following:

6.2.9.5 Configuring Oracle HTTP Server for the Administration Server and Oracle WebCenter Managed Servers

Enable Oracle HTTP Server to route to the administration server that contains Oracle WebCenter Managed Servers by setting the WebLogicCluster parameter to the list of nodes in the cluster. Follow these steps:

  1. Add the following lines to the OHS_HOME/instances/ohs_instance1/config/OHS/ohs1/mod_wl_ohs.conf file:

    # Spaces
<Location /applicationMountpoint>
    WebLogicCluster apphost1.com:8888,apphost2.com:8889
    SetHandler weblogic-handler
</Location>

  2. Restart Oracle HTTP Server on WEBHOST1:

    WEBHOST1> OHS_HOME/instances/ohs_instance1/bin/opmnctl restartproc ias-component=OHS_COMPONENT1

6.2.9.6 Validating Access through Oracle HTTP Server

Verify the URLs to ensure that appropriate routing and failover is working from the HTTP Server to Oracle WebCenter cluster. Follow these steps:

  1. Start WLS_Spaces1, WLS_Spaces2, WLS_Portlet1 and WLS_Portlet2 from the WebLogic Server Administration Console as follows:

    1. Access the Administration Console at the following URL:

      http://APPHOST1/console

    2. Click on one of the Managed Servers, for example, WLS_Spaces1.

    3. Select the Control tab.

    4. Select Start to start the Managed Server.

    5. Repeat the previous steps for each Managed Server.

    6. Verify direct access to the Managed Servers using the following URLs: (JOE: Ask Pradeep if applicationMountpoint in this example and in steps 3 and 6 should be a variable (in CodeInlineItalic font, and if so, whether he has an example of what to specify).

      apphost1:8888/applicationMountpoint

apphost2:8888/applicationMountpoint

apphost1:8889/applicationMountpoint

apphost2:8889/applicationMountpoint

  2. While WLS_ADF2 is running, stop WLS_ADF1 from Oracle WebLogic Server Administration Console.

  3. Access the following URL and verify the appropriate functionality:

    WebHost1:7777/applicationMountpoint

  4. Start WLS_ADF1 from the WebLogic Server Administration Console.

  5. Stop WLS_ADF2.

  6. Access the following URL and verify the appropriate functionality:

    WebHost2:7777/applicationMountpoint

6.3 Oracle WebCenter and High Availability Concepts

The information in this section guides you through the issues and considerations necessary for designing an Oracle WebCenter high availability cluster.

6.3.1 Understanding Oracle WebCenter

Oracle WebCenter combines the standards-based, declarative development of Java Server Faces (JSF), the flexibility and power of portals, and a set of integrated Web 2.0 services.

6.3.1.1 Oracle WebCenter Components

Figure 6-4 illustrates an Oracle WebCenter application and its associated components, portlets, and services.

Figure 6-4 Oracle WebCenter Application Components

Oracle WebCenter Application Components
Description of "Figure 6-4 Oracle WebCenter Application Components"

Oracle WebCenter includes the following components.

  • Oracle WebCenter Spaces offers a single, integrated, Web-based environment for social networking, communication, collaboration, and personal productivity through a robust set of services and applications.

    WebCenter Spaces is built using JSF, Oracle ADF, WebCenter Framework, WebCenter Web 2.0 services, and Composer. Oracle WebCenter Spaces provides:

    • A browser-based, community-focused application targeting the business user

    • Personal Space is an environment that provides personal productivity tools, such as emails and notes.

    • Group Space is a rich team collaboration platform.

    • Threaded discussions, blogs, wikis, worklists, announcements, RSS, recent activities, and search

  • Oracle WebCenter Portlets Framework supports deployment and execution of both standards-based portlets (JSR 168, WSRP 1.0 and 2.0), and traditional Oracle PDK-Java based portlets. Oracle WebCenter provides several out-of-the-box producers, such as OmniPortlet, Web Clipping, Rich Text Portlet, and WSRP Tools.

  • Oracle WebCenter Framework provides the following capabilities:

    • Runtime customization, which lets you make in-place changes to the application without redeploying it.

    • Support for JSR-168 standards-based WSRP portlets, and PDK-Java portlets

    • Content integration through JCR (JSR170) including Oracle Content Server, file system, Oracle Portal, Documentum, Sharepoint, and Lotus

    • JSF-Portlet Bridge, which lets you expose JSF pages and Oracle ADF task flows as standards-based portlets

  • Oracle WebCenter Discussion Server provides the ability to integrate discussion forums and announcements into your applications.

  • Oracle WebCenter Wiki and Blog server provides the ability to integrate wikis and blogs into your applications. It also supports features that enable application users to create their own wikis and blogs.

Oracle WebCenter Spaces and WebCenter custom applications can also integrate with the following WebCenter Web 2.0 social networking and personal productivity services:

  • Instant Messaging and Presence (IMP) - Provides the ability to observe the status of other authenticated users (whether online, offline, busy, or idle) and to contact them instantly.

  • Announcements - Provides the ability to post announcements about important activities and events to all authenticated users.

  • Wiki - Provides the ability for geographically diverse teams to originate and collaborate on Web documents.

  • Blog - Provides the ability to post announcements about important activities and events to all authenticated users.

  • Discussions - Provides the ability to create threaded discussions, posing and responding to questions, and searching for answers. Also provides an effective group communication mechanism for important activities and events.

  • Mail - Provides easy integration with IMAP and SMTP mail servers to enable users to perform simple mail functions such as viewing, reading, creating, and deleting messages, creating messages with attachments, and replying to or forwarding existing messages.

  • Worklists - Provides a personal, at-a-glance view of business processes that require attention. These can include a request for document review, and other types of business process that come directly from enterprise applications.

  • Recent Activities - Provides a summary view of recent changes to documents, discussions, and announcements.

  • Notes - Available in Oracle WebCenter Spaces, the Notes service provides the ability to "jot down" and retain quick bits of personally relevant information.

  • Search - Provides the ability to search tags, services, the application, or an entire site. This includes integrating Oracle Secure Enterprise Search for WebCenter searches.

  • RSS - Provides the ability to access the content of many different Web sites from a single location—a news reader.

  • Tags - Provides the ability to assign one or more personally relevant keywords to a given page or document.

  • Documents - Provides content management and storage capabilities, including content upload, file and folder creation and management, file check out, versioning, and so on.

  • Lists - Available in Oracle WebCenter Spaces, the Lists service provides the ability to create, publish, and manage lists and tables. Users can create lists from prebuilt structures or create their own custom lists.

  • Links - Provides the ability to view, access, and associate related information; for example you can link to a solution document from a discussion thread.

  • Events - Available in WebCenter Spaces, the Events service provides the ability to create and maintain a schedule of events relevant to a wider group of users. Events are published to all authenticated users.

For information about how to configure these WebCenter Web 2.0 social networking and personal productivity services, see Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.

6.3.1.2 Oracle WebCenter Single-node Architecture

Oracle WebCenter installation creates a WebCenter directory under the Middleware home directory. The installation creates a WebCenter domain (wc_domain), which contains the Administration Server and three WebLogic Managed Servers: WLS_Spaces (which hosts Oracle WebCenter Spaces), WLS_Portlets (which hosts Oracle WebCenter Portlets), and WLS_Services (which hosts Oracle WebCenter Discussion server, the Oracle WebCenter Wiki and Blog server, and any additional WebCenter Web 2.0 services that you choose to integrate).

An optional fourth managed server (an application server) can be used to run custom WebCenter applications. Typically, there is one custom managed server per custom Webcenter application. When you create additional managed servers, they are provisioned with the appropriate libraries to enable them to draw upon the same external resources as Oracle WebCenter Spaces. For more information about managed servers, see “Understanding Oracle Fusion Middleware Concepts” in the Oracle Fusion Middleware Administrator's Guide. Figure 6-5 shows a basic single-node Oracle WebCenter architecture.

Figure 6-5 Basic Single-Node Oracle WebCenter Architecture

Basic Single-Node Oracle WebCenter Architecture
Description of "Figure 6-5 Basic Single-Node Oracle WebCenter Architecture"

6.3.1.3 Oracle WebCenter State and Configuration Persistence

Oracle WebCenter Spaces runs as a Java EE application with application state and configuration persisted to the MDS repository. User session information within the application is held locally in memory. In a cluster environment, this state is replicated to other members of the cluster.

Customizations within a portlet or service environment is persisted by that service. Out of the box, Oracle portlets and any custom portlets you build, the Discussion Server, and Wiki Server all have their own database persistence mechanisms.

6.3.1.4 Oracle WebCenter External Dependencies

Table 6-1 shows the access type for each of the WebCenter components and services. The Configuration column lists the type of information provided to Oracle WebCenter to configure or initialize the connection. The Access column lists the protocol used in runtime access of the service.

The Discussion Server and the wiki/blog server are also service providers to Oracle WebCenter. Oracle Portlets also exposes Portlet Producers as services.

Unavailability of these services does not prevent Oracle WebCenter Spaces application from starting, although application errors may be seen when running. The exception is the MDS repository: WebCenter Spaces does not work without the MDS repository. WebCenter Spaces partially works without the WebCenter database, if it is a different physical database from the MDS repository.

Table 6-1 Oracle WebCenter Access Types

Service Configuration Access

Discussion server

HTTP access to Discussion server administration

SOAP/HTTP

Wiki/blog server

HTTP access to Wiki server administration

SOAP/HTTP

Presence server

HTTP access to Presence server

SOAP/HTTP

Oracle Content Server

Socket connection to the Administration Server. HTTP access is required only if the content server needs to be accessed outside WebCenter.

JCR 1.0 over socket or HTTP

MDS repository and schemas

JDBC

JDBC

Search

HTTP access to Search server

HTTP

Mail server

IMAP/SMTP server

IMAP/SMTP

Worklist

HTTP access to BPEL server

SOAP/HTTP

Portlets

HTTP location of provider WSDLs

SOAP/HTTP

Configure each of the external services independently for high availability. Oracle WebCenter's framework provides only one point of access for external services.

For HTTP Services, for example, the access URL should be directed to a load balancer, which provides access to multiple service providers on the back end.

Instructions for configuring Oracle WebCenter Discussion and Wiki Servers for high availability are provided in Section 6.4.5, "Running Oracle Fusion Middleware Configuration Wizard on APPHOST1 to Create the WebLogic Server WebCenter Domain."

For the MDS repository and schemas, Oracle recommends an Oracle Real Application Clusters (RAC) database as the back-end database. Instructions for configuring Oracle RAC as a database provider are in Section 6.4.5, "Running Oracle Fusion Middleware Configuration Wizard on APPHOST1 to Create the WebLogic Server WebCenter Domain."

For information about multi data source configuration with RAC and the MDS repository, see Section 4.1.2, "Using Multi Data Sources with Oracle RAC."

6.3.1.5 Oracle WebCenter Configuration Considerations

The main configuration files for WebCenter applications are listed and described in Table 6-2. Both these files are supplied within the WebCenter application deployment .EAR file.

Table 6-2 Oracle WebCenter Configuration Files

Artifact Purpose

adf-config.xml

Stores basic configuration for Application Development Framework (ADF) and WebCenter application settings, such as which discussions server or mail server the WebCenter application is currently using.

connections.xml

Stores basic configuration for connections to external services.

WebCenter applications and portlet producers both use the Oracle Metadata Services (MDS) repository to store their configuration data and they access the MDS repository as a JDBC data source within the Oracle WebLogic framework.

The MDS repository stores post deployment configuration changes for WebCenter applications and portlet producers as customizations. MDS uses the original deployed versions of adf-config.xml and connection.xml as base documents and stores all subsequent customizations separately into MDS using a single customization layer.

When a WebCenter application starts up, customizations stored in MDS are applied to the appropriate base documents and the WebCenter application uses the merged documents (base documents with customizations) as the final set of configuration properties.

For WebCenter applications that are deployed to a server cluster, all members of a cluster read from the same location in the MDS repository.

Typically, there is no need for administrators to examine or manually change the content of base documents (or MDS customization data) for files such as adf-config.xml and connection.xml as Oracle provides several administration tools for post deployment configuration.

Note:

Oracle does not recommend editing adf-config.xml or connection.xml by hand (unless specifically instructed to do so) as this can lead to misconfiguration.

WebCenter applications and portlet producers store post-deployment configuration information in MDS but configuration information for Oracle WebCenter Discussions Server and Oracle WebCenter Wiki and Blog Server is stored in the file system (see Table 6-3).

Table 6-3 Oracle WebCenter Configuration Location

Application Configuration Stored in MDS Configuration Stored in the File System

WebCenter Spaces

Yes

No

Custom WebCenter applications

Yes

No

Portlet producers

Yes

No

Discussions server

No

Yes

Wiki and Blog server

No

Yes

The Oracle WebCenter Discussions Server stores configuration information in DOMAIN_DIR/config/fmwconfig/servers/SERVER_NAME/owc_discussions_11.1.1.1.0/jive_startup.xml. This configuration information is specific to a particular instance of the discussions server.

The Oracle WebCenter Wiki and Blog Server stores configuration information in the server's deployment directory. For example, $DOMAIN_HOME/servers/SERVER_NAME. Its configuration file, application_config.script, is located in $WIKI_HOME/WEB-INF/classes. For example, DOMAIN_HOME/servers/WLS_Services/stage/owc_wiki/11.1.1.1.0/owc_wiki/WEB-INF/classes.

6.3.1.6 Oracle WebCenter Log File Locations

The operations performed by Oracle WebCenter, Portlet Producers, and Discussion and Wiki Servers are logged directly to the WebLogic Managed Server where the application is running:

DOMAIN_HOME/servers/SERVER_NAME/logs/SERVER_NAME.log

The log files for the different WebLogic Managed Servers are also available from Oracle WebLogic Server Administration Console. To verify the logs, access Oracle WebLogic Server Administration Console http://<admin_server_host>:<port>/console and click on Diagnostics-Log Files.

In addition, a diagnostic log is produced in the log directory for the managed server. This log's granularity and logging properties can be changed through the DOMAIN_HOME/config/fmwconfig/servers/SERVER_NAME/logging.xml file.

6.3.2 WebCenter High Availability Architecture and Failover Considerations

An Oracle WebLogic cluster provides high availability for applications. When one member of the cluster is unavailable, another member of the cluster handles the request.

Each of the managed servers in an Oracle WebCenter deployment can be deployed as a cluster, with different cluster members either on the same node, or on different nodes. In Figure 6-6, all requests sent to the cluster can be served equally by either member of the cluster.

The following sections contain more information on the runtime and configuration aspects of an Oracle WebCenter cluster.

Figure 6-6 Oracle WebCenter Two-Node High Availability Architecture

Oracle WebCenter Two-Node High Availability Architecture
Description of "Figure 6-6 Oracle WebCenter Two-Node High Availability Architecture"

6.3.2.1 Oracle WebCenter Applications

All of the managed servers in Oracle WebCenter are provisioned with both system libraries and Oracle ADF libraries. In addition, Table 6-4 lists the applications which run on each of the managed servers.

Table 6-4 Oracle WebCenter Managed Servers and Applications

Managed Server Application(s)

Spaces

webcenter

webcenter-help

Portlets

portalTools

wsrp-tools

Services (Discussion/Wiki Server)

owc_discussions

owc_wiki

6.3.2.2 Oracle WebCenter Startup Order

When a managed server is started, applications and libraries are started in the following order:

  1. Oracle System libraries, known as the JRF libraries

  2. Oracle ADF libraries

  3. Instrumentation applications, such as Oracle DMS

  4. Oracle WebCenter applications, shown in Table 6-1

The startup order is also the order of dependency. If a dependent component does not deploy successfully, a later component may not function correctly. The successful startup of Oracle WebCenter applications themselves is independent of the availability of dependent services.

6.3.2.3 Deploying WebCenter Application on a Cluster

For an Oracle WebCenter cluster deployment, such as the one shown in Figure 6-6, follow these rules for the targeting of applications, libraries, and system resources:

  • Target applications and libraries to the cluster target. For example, target the Oracle WebCenter application to the Spaces cluster.

  • JDBC resources to the cluster target.

Oracle WebCenter applications and Wiki server are deployed as Oracle WebLogic stage applications. During the initial deployment of each application, the deployment files are received from the Administration Server and deployed locally. The exception is the Oracle WebCenter Wiki and Blogs Server application, which is deployed as a nostage application.

Cluster Communications

By default, each Oracle WebCenter cluster is configured as unicast. To configure your Oracle WebCenter cluster for multicast, see Oracle Fusion Middleware Using Clusters for Oracle WebLogic Server.

6.3.2.4 Oracle WebCenter State Replication

Oracle WebCenter relies on Oracle ADF, which has several stateful components. WebCenter itself is also a stateful application. Therefore, you must configure state replication in cluster scenarios.

For more information on how state replication works in Oracle WebLogic Server, see Oracle Fusion Middleware Using Clusters for Oracle WebLogic Server.

Oracle WebLogic Server supports two types of state replication:

  • In-memory replication - Using in-memory replication, Oracle WebLogic Server copies a session state from one server instance to another. The primary server creates a primary session state on the server to which the client first connects, and a secondary replica on another WebLogic Server instance in the cluster. The replica is kept up to date so that it may be used if the server that hosts the servlet fails.

  • JDBC-based persistence - In JDBC-based persistence, Oracle WebLogic Server maintains the HTTP session state of a servlet or JSP using file-based or database-based persistence.

Properly configuring state replication requires both configuring the environment and configuring the application properly. For information on state replication behavior under failover conditions see Section 6.3.2.7, "Expected Behavior for Application Failover."

For more information on diagnosing state replication issues see Section 6.3.2.4, "Oracle WebCenter State Replication."

6.3.2.5 Understanding the Distributed Java Object Cache

Oracle WebCenter applications use a distributed Java Object Cache for greater performance. Configure this cache across all Oracle WebCenter clusters, with one distributed cache per cluster.

Table 6-5 lists some examples of the type of objects which Oracle WebCenter places in the Java Object Cache.

Table 6-5 Oracle WebCenter Object Types for Java Object Cache

Oracle WebCenter Component Object Cached

Discussion Forums

Topics and Forums.

Announcements

Announcements.

Presence

Presence Subscription list.

Worklist

Called Worklist items, such that cached data is used until refresh is called.

Content Integration (DocLib)

"isProvisoned" and "isConfigured" state.

Content Integration (Portal adapter)

JCR: type information and metadata obtained from the repository.

Service Framework

Userprofile. Queried usernames.

Recent Activity

Recent activity results per user.

Spaces Application

Global List of all space names, template names in the instance.

List of all spaces/templates on which a user has access.

Page Service

List of pages in a scope.

WSRP Server

Preference store values of wsrp producers.

IMP service

User's presence/subscription status

Doclib

Provisioning and configuration checks for doclib service for Spaces application configuration

Collaboration

Collaboration services cache objects in the Java Object Cache on a per user session basis. These cached user sessions are destroyed when the HTTP session is destroyed.

Worklist

Worklist caches the called items so that unless the refresh button is clicked, or the every fifteen minute refresh poll is triggered, the same items are displayed as the user changes the sort and group by settings. The display is also cached by group and sort order settings, updating when a change occurs. This is read only data which, if not present, is fetched and stored on the cache.

Spaces

The list of all templates and public spaces are maintained in the Java Object Cache. This is shared by all users, in addition to the list of spaces and templates that a particular user can access. These are cahced per user. A template created on one JVM does not show up if the template cache has been initialized in another JVM, unless JOC distributes the data, or an admin in the second JVM does an explicit refresh where the cache is rebuilt.

Doclib

Doclib uses Java Object Cache to cache provisioning and configuration checks for doclib services, as applies to Spaces appplication configuration. For provisioning, cached objects are flagged as distributed. They are replicated by a correctly configured Java Object Cache in a high availability environment, the confiuguration cached state is kept locally. All cached objects are flagged to expire after one minute. Caching reduces the number of times UCM calls are made to check the state of the UCM Server, as the Spaces application repeatedly checks provisioning and configuration to control service rendering in the UI.

Recent Activity

The list of recent activity results are cached for each user to prevent a requery of results each time the recent activity taskflow or RSS feed is viewed. The cache is automatically refreshed every fifteen minutes, or can be manually refreshed using the refresh icon in the recent activity taskflow.

For Java Object Cache configuration procedures, see Section 6.4.13, "Configuring the Java Object Cache."

6.3.2.6 Oracle WebCenter Protection from Failover and Expected Behavior

An Oracle WebLogic cluster provides application high availability. If one member of the cluster is unavailable, any other available member of the cluster is able to handle the request.

Session Failover Requirements

For seamless failover of an Oracle WebCenter application, the application must meet the following conditions:

  • The application is in a cluster and at least one member of the application cluster is available to serve the request.

  • For stateful applications, state replication is configured correctly as described in Section 6.4.15, "Configuring Oracle WebCenter for Replication."

  • If you are using Oracle HTTP Server, the server configuration is configured with the WebLogicCluster directive to balance among all available application instances.

  • If you are using a hardware load balancer, the load balancer is:

    • Routing traffic to all available instances

    • Configured correctly with a health monitor to mark unavailable instances

    • Configured to support persistence of session state

6.3.2.7 Expected Behavior for Application Failover

If the environment has been configured correctly, application users do not notice when an application instance in a cluster becomes unavailable. The sequence of events in an application failover is, for example, as follows:

  1. A user makes a request and is routed by a hardware load balancer to instance A of the application.

  2. Instance A of the application becomes unavailable because of node failure, process failure, or network failure.

  3. The hardware load balancer marks instance A as unavailable.

  4. The user makes a subsequent request. The request is routed to instance B.

  5. Instance B is configured as a replication partner of Instance A and has the user's session state.

  6. The application resumes using the session state on Instance B and the user continues working without interruption.

Exceptions to Expected Behavior

For Oracle WebCenter, the known exceptions to these expected behaviors are as follows:

  • Oracle ADF Pop-ups - Open pop-ups are closed on failover. This affects many components which otherwise have no exceptions. The following components are affected:

    • Composer (property inspector Popup)

    • Lists

    • Links (link deletion popup)

    When failover occurs, the action which led to the popup must be repeated in order to make it reappear. The specific ways in which this appears in Oracle WebCenter Spaces, as well as suggested remedies are listed in Table 6-6.

    Table 6-6 Oracle WebCenter Troubleshooting Scenarios

    Action Before Failover After Failover Suggested Remedy

    Go to any page and click Create Page.

    Type in a name, select a theme, and click OK. When you select the theme, the page creation popup is closed.

    Repeat the operation.

    Launch Manage Pages.

    Perform any operation within the popup, except for closing the popup, for example, click Page Actions. When you perform any operation, the Manage Pages popup is closed.

    Repeat the operation.

    Launch Manage Pages, click Page Actions against a page, and then the Delete option in the menu.

    Click OK on the confirmation popup. Clicking OK not only closes the confirmation popup, but the Manage Pages popup also gets closed as part of the request, and the effect of the deletion (which may have gone through) is not visible among the tabs.

    Relaunch the Manage Pages popup to see if the page has been deleted. If not, try deleting once again.

    Launch Personalize Applications popup. Perform any operation that sends a request, other than clicking OK, for example, expand the Applications node.

    Perform any operation that sends a request, other than clicking OK, for example, expand the Applications node. When you perform any operation that sends a request to the server, the Personalize Applications popup is closed.

    Repeat the operation

    Launch Preferences.

    Switch between the Preferences tabs (General, Accounts, Messaging, Search) in step ii. When you switch between the Preference tabs, the Preferences popup is closed.

    Repeat the operation

    Launch Manage Favorites ii. Stop the server, perform any operation other than closing the popup, for example. expand a folder, click Edit favorite information.

    Perform any operation other than closing the popup, for example, expand a folder, and click Edit favorite information. When you perform any operation, the Manage Favorites popup is closed.

    Relaunch the Manage Favorites popup to see if the operation was successful. If not, retry the operation.

  • Component Specific Issues - Other issues which are specific to different components in Oracle WebCenter are listed in Table 6-7.

    Table 6-7 Oracle WebCenter Exceptions to Expected Behavior

    Oracle WebCenter Component Exceptions to Expected Behavior

    Community Events

    When changing certain fields (start or end date/hour/minute), the event form is closed when failover occurs.

    Portlets

    Failures are fully transparent.

    Lists

    Failures are fully transparent.

    Links

    Failures are fully transparent.

    Search

    In the midst of a long-running query. The results that come back are not guaranteed (note there is no "write" operation here), the user can just reissue the query.

    Tagging

    Failures are fully transparent.

    Recent Activities

    The open/close state of the tree nodes is not replicated. After after failover, the tree of results closes all of the nodes. The nodes need to be reopened.

    Worklist

    Failures are fully transparent.

    Doclib

    When a user uploads a document and a document with the same name already exists, the user is taken to the Confirm new version screen. While on that screen, the file is stored in a temporary local location. If failover occurs at that moment, the uploaded file is lost and the user must restart the upload process.

6.3.2.8 Monitoring Logging of Application Deployments

Use Oracle WebLogic Server Administration Console to check the status of the application deployments. You can also use Oracle WebLogic Server infrastructure and Enterprise Manager Fusion Middleware Control for starting stopping, and monitoring Oracle WebCenter processes.

6.3.2.9 Oracle WebCenter Cluster-wide Configuration Changes

For Oracle WebCenter Spaces and Portlet Producers, all configuration data is stored in the MDS repository. Additional cluster deployments automatically read the latest configuration upon application startup.

For Oracle Discussion Server, the configuration information should be moved over from an existing cluster server. This is done automatically by the pack/unpack utility of Oracle WebLogic Server. Oracle recommends this procedure.

For Oracle WebCenter Wiki and Blogs Server, most of the configuration is stored in the database, however, there is also configuration specific to custom templates located in the deployment directory. For cluster installations, all Wiki Servers in the cluster should share this deployment directory.

6.3.2.10 Maintaining Configuration in a Clustered Environment

Oracle WebCenter Spaces and Portlet Producers store their configuration in the MDS repository. Any changes made to the configuration of one server in the cluster are immediately visible to all other members.

Changes to Oracle WebCenter Discussion Server are not frequent, however, when they do occur, the changes must be reapplied to other members of the cluster. You can do this by connecting directly to each Discussion Server, instead of using the load balancer, and making the necessary administration changes.

Oracle Wiki Server maintains its configuration in the database, and in the local deployment directory. You need to apply the configuration to each node.

6.4 Configuring High Availability for Oracle WebCenter

Figure 6-6 illustrates a two-node Oracle WebCenter cluster running on two Oracle WebLogic Servers in one WebLogic Server domain. Oracle WebLogic Servers are front-ended by Oracle HTTP Server which load balances incoming requests to them. An Oracle RAC database is used for storing metadata and schemas. Shared storage is used for shared Oracle Wiki and Blog Server configuration. VIPs are used for the administration server (for manual failover).

Note:

Oracle strongly recommends reading the release notes for any additional installation and deployment considerations prior to starting the setup process.

Note:

All command examples are for k or bash shell. No C shell examples are provided.

6.4.1 Preparing the Environment: Prerequisite Steps Before Setting up an Oracle WebCenter High Availability Configuration

The following sections provide prerequisite steps before setting up an Oracle WebCenter high availability configuration.

For information about platform-specific commands, see the Oracle Fusion Middleware Installation Guide for Oracle WebCenter.

6.4.1.1 Database Prerequisites

Oracle WebCenter supports the following database versions:

  • Oracle Database 10g (10.2.0.4 or later)

  • Oracle Database 11g (11.1.0.7 or later)

To determine the database version, execute the following query:

SQL>select version from sys.product_component_version where product like 'Oracle%';

6.4.1.2 VIP and IP Prerequisites

To configure a virtual IP for the administration server, see Section 10.2.2.3, "Transforming the Administration Server for Cold Failover Clusters."

6.4.1.3 Installing and Configuring the Database Repository

This section describes how to install and configure the database repository.

Oracle Clusterware

  • For 10g Release 2 (10.2), see the Oracle Database Oracle Clusterware and Oracle Real Application Clusters Installation Guide.

  • For 11g Release 1 (11.1), see the Oracle Clusterware Installation Guide.

Automatic Storage Management

  • For 10g Release 2 (10.2), see the Oracle Database Oracle Clusterware and Oracle Real Application Clusters Installation Guide.

  • For 11g Release 1 (11.1), see the Oracle Real Application Clusters Installation Guide.

  • When you run the installer, select the Configure Automatic Storage Management option in the Select Configuration page to create a separate Automatic Storage Management home.

Oracle Real Application Clusters

  • For 10g Release 2 (10.2), see Oracle Database Oracle Clusterware and Oracle Real Application Clusters Installation Guide.

  • For 11g Release 1 (11.1), see Oracle Real Application Clusters Installation Guide.

You must install the 11g (11.1.1) Oracle Fusion Middleware repository into a Real Application Cluster database before you install the Oracle Fusion Middleware components. Oracle Fusion Middleware provides a tool, Oracle Fusion Middleware Repository Creation Utility (RCU), to create the component schemas in an existing database.You install RCU in its own, separate Oracle home.

See Oracle Fusion Middleware Repository Creation Utility User's Guide for more information about installing RCU.

Database Initialization Parameters

Ensure that the following initialization parameter is set to the required value. It is checked by Repository Creation Assistant.

Table 6-8 Required Initialization Parameters

Parameter Required Value Parameter Class

PROCESSES

300 or greater

Static

To check the value of the initialization parameter using SQL*Plus, you can use the SHOW PARAMETER command.

As the SYS user, issue the SHOW PARAMETER command as follows:

SQL> SHOW PARAMETER processes

Set the initialization parameter using the following command:

SQL> ALTER SYSTEM SET processes=300 SCOPE=SPFILE

Restart the database.

Note:

The method that you use to change a parameter's value depends on whether the parameter is static or dynamic, and on whether your database uses a parameter file or a server parameter file. See the Oracle Database Administrator's Guide for details on parameter files, server parameter files, and how to change parameter values.

6.4.1.4 Installing and Configuring an LDAP Provider

For production environments, it is a mandatory requirement for Oracle WebCenter high availability topologies to have an external LDAP policy store. For more information on the supported policy stores, as well as instructions on configuring LDAP, see the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.

6.4.1.5 Terminology for Directories and Directory Environment Variables

The follow list describes the directories and variables used in this chapter:

  • ORACLE_BASE: This environment variable and related directory path refers to the base directory under which Oracle products are installed.

  • MW_HOME: This environment variable and related directory path refers to the location where Fusion Middleware (FMW) resides.

  • WL_HOME: This environment variable and related directory path contains installed files necessary to host a WebLogic Server.

  • ORACLE_HOME: This environment variable and related directory path refers to the location where Oracle WebCenter is installed.

  • DOMAIN_HOME: This directory path refers to the location where the Oracle WebLogic Domain information (configuration artifacts) is stored.

The values used and recommended for consistency for this directories are:

ORACLE_BASE:

/u01/app/oracle

MW HOME (Apptier):

ORACLE_BASE/product/fmw

WLS_HOME:

MW_HOME/wlserver_10.3

ORACLE_HOME:

MW_HOME/WC1

6.4.1.6 Using Oracle Fusion Middleware Repository Creation Utility to Load the Fusion Middleware Schemas in the Database

Install the 11g (11.1.1) Oracle Fusion Middleware Metadata Store and WebCenter schemas into a Real Application Cluster database before you install Oracle Fusion Middleware WebCenter components. Oracle Fusion Middleware provides a tool, Oracle Fusion Middleware Repository Creation Utility (RCU), to create the component schemas in an existing database. See the Oracle Fusion Middleware Repository Creation Utility User's Guide for more information about installing RCU.

6.4.1.6.1 Running RCU

Run RCU to install the required metadata for Oracle Fusion Middleware 11g.

  1. Start up RCU using the following command:

    RCU_HOME/bin/rcu &

  2. In the Welcome screen, click Next.

  3. In the Create Repository screen, select Create to load component schemas into a database, and click Next.

  4. In the Database Connection Details screen, enter connection information for your database:

    • Database Type: Select Oracle Database.

    • Host Name: Enter the name of the node that is running the database. For an Oracle RAC database, specify the VIP name, or one of the node names as the host name: WCDBHOST1VIRTUAL.

    • Port: The port number for the database: 1521

    • Service Name: Enter the service name of the database: wcha.mycompany.com

    • Username: SYS

    • Password: Enter the password for the SYS user.

    • Role: SYSDBA

  5. Click Next.

  6. If you receive the following warning message, click Ignore or Stop:

    The database you are connecting is with non-UTF8 charset, if you are going to use this DB for multilingual support, you may have data loss. If you are not using for multilingual support you can continue, otherwise we strongly recommend using UTF-8 database.

  7. In the Select Components screen, select Create a New Prefix, and enter a prefix to use for the database schemas, for example, WCHA

    Write down the schema names so they are available in later procedures.

    • Select the following schemas:

      • AS Common schemas:

        Metadata Services

      • WebCenter Infrastructure:

        WebCenter Suite

  8. Click Next.

  9. In the Schema Passwords screen, enter passwords for the main and additional (auxiliary) schema users, and click Next.

  10. In the Map Tablespaces screen, choose the tablespaces for the selected components, and click Next.

  11. in the Summary screen, click Create.

  12. In the Completion Summary screen, click Close.

See Oracle Fusion Middleware Installation Concepts and Repository Creation Utility User's Guide for more information about using RCU.

6.4.2 Installing Oracle HTTP Server on WebHost1

To install Oracle HTTP Server on WEBHOST1:

  1. Verify that the servers meet the following requirements:

    • The system, patch, kernel, and other requirements meet the requirements specified in the Oracle Fusion Middleware Repository Creation Utility User's Guide.

    • This example uses port 7777. If you choose port 7777, ensure that it is not used by any service on the nodes. You can verify this by running the following command:

      Unix:

      netstat -an | grep 7777

      Windows:

      netstat -an | findstr 7777

    If port 7777 is in use, choose another port, or make it available.

  2. On UNIX platforms, if the /etc/oraInst.loc or /var/opt/oracle/oraInst.loc file exists, check that its contents are correct. Specifically, check that the inventory directory is correct, and that you have write permissions for that directory.

    If the /etc/oraInst.loc file does not exist, skip this step.

  3. Start Oracle Universal Installer for Oracle Fusion Middleware 11g Webtier Utilities CD installation as follows:

    For UNIX, run this command: ./runInstaller.

    For Windows, double-click setup.exe.

  4. In the Specify Inventory Directory screen, enter the location for the inventory and the user group, and click OK.

  5. Execute the root privileged actions as indicated in the dialog, and click OK.

  6. In the Welcome screen, click Next.

  7. In the Select Installation Type screen, select Install and Configure, and click Next.

  8. In the Prerequisite Checks screen, ensure that all the prerequisites are met, and click Next.

  9. In the Specify Installation Location screen, set the location to:

    /u01/app/oracle/product/11.1.1/ohs_1

  10. Click Next.

  11. In the Configure Components screen:

    • Select Oracle HTTP Server.

    • Do not select Associate Selected Components with WebLogic Domain.

    • Click Next.

  12. In the Specify Component Details screen, enter the following values:

    • Instance Home Location: app/oracle/product/11.1.1/ohs_1/instances/ohs_instance1

    • Instance Name: ohs_instance1

    • OHS Component Name: ohs1

  13. Click Next.

  14. In the Specify Webtier Port Details screen, do the following:

    • Select Specify Custom Ports. If you specify a custom port, select Specify Ports using Configuration File and then use the Browse function to select the file.

    • Enter Oracle HTTP Server port. For example, enter 7777.

    Click Next.

    Note:

    For more information on setting ports, refer to Oracle Fusion Middleware Installation Guide for Oracle SOA Suite.

  15. Click Next.

  16. In the Configuration Summary screen, ensure that the selections are correct, and click Install.

  17. In the Installation Progress screen:

    For UNIX systems, a dialog box appears prompting you to run the oracleRoot.sh script. Open a command window and run the script, following the prompts.

    Click Next.

  18. In the Configuration screen, several configuration assistants are started in succession. When the configuration assistants are finished, the Configuration Completed screen appears.

  19. In the Configuration Completed screen, click Finish to exit.

6.4.2.1 Validating Oracle HTTP Server

To verify that Oracle HTTP Server is set up correctly, access the root URL context of the server by using the following URL a browser:

WebHost1:7777/

If Oracle HTTP Server is set up correctly, the Hello World page appears in the browser.

6.4.3 Installing Oracle Fusion Middleware Home

Use the following procedures to install Oracle Fusion Middleware components:

6.4.3.1 Installing Oracle WebLogic Server

To install Oracle WebLogic Server on all nodes in the application tier:

  1. On UNIX platforms, if the /etc/oraInst.loc or /var/opt/oracle/oraInst.loc file exists, check that its contents are correct. Specifically, check that the inventory directory is correct and that you have write permissions for that directory.

    If the /etc/oraInst.loc file does not exist, skip this step.

  2. Start Oracle WebLogic Server Installer.

    On UNIX, (Linux used in this example):

    APPHOST1> server103_linux32.bin

    On Windows:

    APPHOST1> server103_win32.exe

  3. In the Welcome screen, click Next.

  4. In the Choose Middleware Home Directory screen:

    • Select Create a New Middleware Home

    • For the Middleware Home Directory field, enter ORACLE_BASE/product/fmw

    • Click Next.

  5. In the Register for Security Updates screen, enter your contact information for security update notifications, and click Next.

  6. In the Choose Install Type screen, select Custom, and click Next.

  7. In the JDK Selection screen, select only JROCKIT SDK1.6.0_05, and click Next.

  8. In the Choose Product Installation Directories screen, accept the following directory:

    ORACLE_BASE/product/fmw/wlserver_10.3

    Click Next.

  9. In the Installation Summary screen, click Next.

  10. In the Installation Complete screen, deselect Run QuickStart, and click Done.

6.4.3.2 Installing Oracle Fusion Middleware for Oracle WebCenter

To install Oracle Fusion Middleware for Oracle WebCenter on all the nodes in the application tier:

  1. Start Oracle Fusion Middleware for Oracle Fusion Middleware 11g WebCenter Installer:

    On UNIX, (Linux used in this example):

    APPHOST1> runInstaller

    On Windows:

    APPHOST1> setup.exe

    When Oracle Fusion Middleware 11g WebCenter Installer prompts you for a JRE/JDK location enter Oracle SDK location created in the Oracle WebLogic Server installation, for example, ORACLE_BASE/product/fmw/jrockit_160_05_R27.6.2-20.

  2. In the Welcome screen, click Next.

  3. In the Prerequisite Check screen, verify that the checks complete successfully, and click Next.

  4. In the Specify Installation Location screen:

    • For Middleware Home, enter ORACLE_BASE/product/fmw

    • For Oracle Home Directory, enter the directory you want to use, for example, wc

    Click Next.

  5. In the Installation Summary screen, click Install.

  6. In the Installation Complete screen, click Finish.

6.4.4 Enabling the Administration Server VIP

For information about configuring virtual IPs for the administration server, see Chapter 10, "Active-Passive Topologies for Oracle Fusion Middleware High Availability."

6.4.5 Running Oracle Fusion Middleware Configuration Wizard on APPHOST1 to Create the WebLogic Server WebCenter Domain

Run Oracle Fusion Middleware Configuration Wizard from the WebCenter directory in the Middleware home to create a domain containing the Administration Server and Oracle WebCenter components. Ensure that the database where you installed the repository is running. For Oracle RAC databases, Oracle recommends having all the instances running.

  1. Start Oracle WebLogic Server Configuration Wizard from the ORACLE_HOME/common/bin directory using the following command:

    APPHOST1> ./config.sh

  2. In the Welcome screen, select Create a New WebLogic Domain, and click Next.

  3. In the Select Domain Source screen, select Generate a domain configured automatically to support the following products, and select the following products:

    When you select Webcenter Spaces, WSM Policy Manager and Oracle JRF are selected automatically.

    • Oracle WebCenter Spaces - 11.1.1.0

    • Oracle Enterprise Manager - 11.1.1.0

    • Oracle Portlet Producers - 11.1.1.0

    • Oracle Wiki and Blog Server - 11.1.1.0

    • Oracle WebCenter Discussion Server - 11.1.1.0

    • Oracle JRF - 11.1.1.0

    Click Next.

  4. Enter the Domain Name, Domain Location, and Application Location and click Next.

  5. In the Configure Administrator Username and Password screen, enter the username and password to be used for the domain's administrator, and click Next.

  6. In the Configure Server Start Mode and JDK screen, make the following selections:

    • WebLogic Domain Startup Mode: select Production Mode

    • JDK Selection: select JROCKIT SDK1.6.0_05.

    Click Next.

  7. In the Configure JDBC Data Sources screen. select Configure selected component schemas as RAC multi data source schemas in the next pane.

    The Repository Creation Utility creates the necessary schemas in the Oracle database. You provide a custom prefix for these schemas. Table 6-9 lists the data sources, the schemas used and the managed servers to which they are assigned.

    1. Ensure that the following data source appears on the screen.

      Table 6-9 Oracle WebCenter Data Sources

      Data Source Schema Name

      OWCWikiDS

      Prefix_wiki

      DiscussionsDS

      Prefix_discussions

      PortletDS

      Prefix_portlet

      WebCenterDS

      Prefix_webcenter

      mds-SpacesDS

      Prefix_mds

      OWSM MDS

      Prefix_mds

    2. Select Configure all data sources as RAC multi data sources in the next panel.

    3. Click Next.

  8. In the Configure RAC Multi Data Source Component Schema screen, click the Add button to add the Host name, Instance name, and Listen port of both RAC nodes.

    Figure 6-7 Configure RAC Multi Data Source Component Schema Screen

    Configure RAC Multi Data Source Component Schema screen

    Leave one schema checked and uncheck the other schemas.

    1. In the Driver drop-down list, select Oracle's Driver (Thin) for RAC Service-Instance connections.

    2. Enter the Service name.

    3. Enter the Prefix_Username for Oracle WebCenter schemas.

    4. Enter the Password for the schemas.

    5. Click Add to enter the details for the first RAC instance.

    6. Update each multi data source schema by selecting one data source at a time and adding the appropriate details.

    Click Next.

  9. In the Test JDBC Data Sources screen, the connections are tested automatically. The Status column displays the results. Ensure that all connections were successful. If not, click Previous to return to the previous screen and correct your entries.

    Click Next when all the connections are successful.

  10. In the Select Optional Configuration screen, select the following:

    Figure 6-8 Select Optional Configuration Screen

    Select Optional Configuration screen

    • Administration Server

    • Managed Servers, Clusters and Machines

  11. In the Customize Server and Cluster Configuration screen, select Yes, and click Next.

  12. In the Configure the Administration Server screen, enter the following values:

    • Name: AdminServer

    • Listen Address: Enter the VIP address used in Section 6.4.4.

    • Listen Port: 7001

    • SSL listen port: N/A

    • SSL enabled: leave unchecked

    Click Next.

  13. In the Configure Managed Servers screen, add the following managed servers:

    Table 6-10 Configuring Managed Servers

    Name Listen Address Listen Port SSL Listen Port SSL Enabled

    WLS_Portlet

    Hostname of APPHOST1

    8889

    n/a

    unchecked

    WLS_Portlet2

    Hostname of APPHOST2

    8889

    n/a

    unchecked

    WLS_Spaces

    Hostname of APPHOST1

    8888

    n/a

    unchecked

    WLS_Spaces2

    Hostname of APPHOST2

    8888

    n/a

    unchecked

    WLS_Services

    Hostname of APPHOST1

    8890

    n/a

    unchecked

    WLS_Services2

    Hostname of APPHOST2

    8890

    n/a

    unchecked

    Click Next.

  14. In the Configure Clusters screen, add the following cluster:

    • Name: Portlet_Cluster

    • Cluster Messaging Mode: unicast

    • Cluster Address Enabled: leave blank

    • Name: Services_Cluster

    • Cluster Messaging Mode: unicast

    • Cluster Address Enabled: leave blank

    Click Next.

  15. In the Assign Servers to Clusters screen, assign the following servers to clusters:

    • Spaces_Cluster

      WLS_Spaces

      WLS_Spaces2

    • Portlet_Cluster

      WLS_Portlet

      WLS_Portlet2

    • Services_Cluster

      WLS_Services

      WLS_Services2

    Click Next.

  16. In the Configure Machines screen:

    • Delete the LocalMachine that appears by default.

    • Click the Unix Machine tab, and add the following machines:

    Table 6-11 Configuring Machines

    Name Node Manager Listen Address

    APPHOST1

    Hostname of APPHOST1

    APPHOST2

    Hostname of APPHOST2

    Click Next.

  17. In the Assign Servers to Machines screen, assign servers to machines as follows:

    Figure 6-9 Assign Servers to Machines Screen

    Assign Servers to Machines screen

    • APPHOST1: WLS_Spaces1, WLS_Porlet1, WLS_Services1

    • APPHOST2: WLS_Spaces2, WLS_Porlet2, WLS_Services2

    Click Next.

  18. In the Configuration Summary screen, click Create.

  19. In the Creating Domain screen, click Done.

6.4.6 Creating boot.properties for the Administration Server and for Managed Servers on APPHOST1

This is an optional step for enabling the Administration Server to start up without prompting you for the administrator username and password. Create a boot.properties file for the Administration Server and for the managed servers on APPHOST1.

For the Administration Server:

  1. Create the following directory:

    APPHOST1> mkdir -p MW_HOME/wls/user_projects/domains/wcdomain/servers/AdminServer/security

  2. Use a text editor to create a file called boot.properties in the directory created in the previous step, and enter the following lines in the file:

    username=adminuser
password=password

    Note:

    When you start up the Administration Server, the username and password entries in the file are encrypted.

    For security reasons, minimize the time the entries in the file are left unencrypted. After you edit the file, start up the server as soon as possible in order for the entries to be encrypted.

For the WLS_Spaces1 managed server:

  1. Create the following directories:

    APPHOST1> mkdir ORACLE_BASE/product/fmw/user_projects/domains/wcdomain/servers/WLS_Spaces1

APPHOST1> mkdir ORACLE_BASE/product/fmw/user_projects/domains/wcdomain/servers/WLS_Spaces1/security

  2. Use a text editor to create a file called boot.properties in the security directory created in the previous step, and enter the following lines in the file:

    username=adminuser
password=password

  3. Repeat Steps 2 and 3 for the WLS_Portlet1 and WLS_Services1 Managed Servers on APPHOST1.

Note:

When you start up the administration server, the username and password entries in the file are encrypted.

For security reasons, minimize the time the entries in the file are left unencrypted. After you edit the file, start up the server as soon as possible in order for the entries to be encrypted.

6.4.7 Starting the System in APPHOST1

This section describes procedures for starting the system in APPHOST1

6.4.7.1 Starting the Administration Server on APPHOST1

To Start the Administration Server on APPHOST1 run the following commands:

APPHOST1> cd ORACLE_BASE/product/fmw/user_projects/domains/wcdomain/bin

APPHOST1> ./startWebLogic.sh

6.4.7.2 Validating the Administration Server

To verify that the Administration Server is properly configured:

  1. In a browser, go to http://VIP1:7001/console.

  2. Log in as the administrator.

  3. Verify that the WLS_Spaces1 and WLS_Spaces2 managed servers are listed.

  4. Verify that the Spaces_Cluster cluster is listed.

  5. Verify that you can access Enterprise Manager at http://VIP1:7001/em.

6.4.7.3 Disabling Host name Verification for the Administration Server and the Managed Servers for APPHOST1 and APPHOST2

This step is required if you have not set up SSL communication between the Administration Server and the Node Manager. If SSL is not set up, you receive an error message unless you disable host name verification.

You can re-enable host name verification when you have set up SSL communication between the Administration Server and the Node Manager.

To disable host name verification on APPHOST1:

  1. In Oracle WebLogic Server Administration Console, select Administration Server, SSL, and then Advanced.

  2. Click Lock and Edit.

  3. When prompted, save the changes and activate them.

  4. Set Hostname Verification to None.

  5. Select WLS_Spaces1, SSL, and then Advanced.

  6. Set Hostname Verification to None.

  7. Repeat Step 3 for WLS_Portlet1 and WLS_Services1.

To disable host name verification on APPHOST2:

  1. In Oracle WebLogic Server Administration Console, select WLS_Spaces2, SSL , and then Advanced.

  2. Set Hostname Verification to None.

  3. Repeat Steps 1 and 2 for WLS_Portlet2 and WLS_Services2.

6.4.7.4 Starting Node Manager on APPHOST1

Perform these steps to start Node Manager on APPHOST1:

  1. Set the JAVA_OPTIONS environment variable to define the StartScriptEnabled property before starting Node Manager. On APPHOST1, run the following command:

    APPHOST1> export JAVA_OPTIONS=-DStartScriptEnabled=true

    Note:

    You must use the StartScriptEnabled property to avoid class loading failures and other problems.

  2. Start Node Manager:

    APPHOST1> cd ORACLE_BASE/admin/DOMAIN_NAME/mserver/DOMAIN_NAME/servers

APPHOST1> ./startNodeManager.sh

After you have started Node Manager for the first time, you can edit the nodemanager.properties file to set the StartScriptEnabled property. The nodemanager.properties file does not exist until Node Manager is started for the first time.

To set the StartScriptEnabled property in the nodemanager.properties file:

  • Add the following line to the ORACLE_BASE/wls/wlserver_10.3/common/nodemanager/nodemanager.properties file:

    StartScriptEnabled=true

When this property is set in the nodemanager.properties file, you no longer need to define it in the JAVA_OPTIONS environment variable.

6.4.8 Install WebLogic Server and Oracle WebCenter on APPHOST2

Repeat the procedures for installing WebLogic Server and Oracle WebCenter for APPHOST2, start with Section 6.4.2, "Installing Oracle HTTP Server on WebHost1". The directory paths for binary files and domains used when installing new nodes must be exactly the same as those used for first node. If these paths and domains are not exactly the same as those used for the first node, failover is does not occur.

6.4.9 Propagating the Domain Configuration to APPHOST2 with pack/unpack Utilities

Follow these steps to propagate the domain configuration to APPHOST2 using Pack/Unpack utilities:

  1. Run the following pack command on APPHOST1 to create a template pack:

    APPHOST1> cd ORACLE_BASE/product/fmw/wlserver_10.3/common/bin
APPHOST1> ./pack.sh -managed=true -domain=ORACLE_BASE/product/fmw/user_projects/domains/wcdomain/
-template=wcdomaintemplate.jar 
-template_name=wc_domain_template

  2. Run the following command on APPHOST1 to copy the template file created in the previous step to APPHOST2 using, in this example, scp:

    APPHOST1> scp wcdomaintemplate.jar
 APPHOST2:ORACLE_BASE/product/fmw/wlserver_10.3/common/bin

  3. Run the unpack command on APPHOST2 to unpack the propagated template:

    APPHOST2> cd
 ORACLE_BASE/product/fmw/wlserver_10.3/common/bin
APPHOST2> ./unpack.sh
 -domain=ORACLE_BASE/product/fmw/user_projects/domains/wcdomain/
 -template=wcdomaintemplate.jar

6.4.10 Starting Node Manager on APPHOST2

To start the Node Manager on APPHOST2, repeat the steps from Section 6.4.7.4, "Starting Node Manager on APPHOST1." on APPHOST2.

6.4.11 Configuring Oracle HTTP Server for the Administration Server and Oracle WebCenter Managed Servers

Enable Oracle HTTP Server to route to the Administration Server that contains Oracle WebCenter managed servers, by setting the WebLogicCluster parameter to the list of nodes in the cluster.

  1. Add the following lines to the OHS_HOME/instances/ohs_instance1/config/OHS/ohs1/mod_wl_ohs.conf file:

    # Spaces
<Location /webcenter>
    WebLogicCluster apphost1.com:8888,apphost2.com:8889
    SetHandler weblogic-handler
</Location>
 
<Location /webcenterhelp>
    WebLogicCluster apphost1.com:8888,apphost2.com:8888
    SetHandler weblogic-handler
</Location>
 
<Location /rss>
    WebLogicCluster apphost1.com:8888,apphost2.com:8888
    SetHandler weblogic-handler
</Location>
 
# Portlet
<Location /portalTools>
    WebLogicCluster apphost1.com:8889,apphost2.com:8889
    SetHandler weblogic-handler
</Location>
 
<Location /wsrp-tools>
    WebLogicCluster apphost1.com:8889,apphost2.com:8889
    SetHandler weblogic-handler
</Location>
 
# Discussions and Wiki
<Location /owc_discussions>
    WebLogicCluster apphost1.com:8890,apphost2.com:8890
    SetHandler weblogic-handler
</Location>
 
<Location /owc_wiki>
    WebLogicCluster apphost1.com:8890,apphost2.com:8890
    SetHandler weblogic-handler
</Location>

  2. Restart Oracle HTTP Server on WEBHOST1:

    WEBHOST1> OHS_HOME/instances/ohs_instance1/bin/opmnctl restartproc ias-component=OHS_COMPONENT1

6.4.11.1 Validating Access through Oracle HTTP Server

Verify the URLS to ensure that appropriate routing and failover is working from the HTTP Server to Oracle WebCenter cluster.

  1. Start WLS_Spaces1, WLS_Spaces2, WLS_Portlet1 and WLS_Portlet2 from the WebLogic Server Administration Console as follows:

    1. Access the Administration Console at the following URL

      http://APHHOST1/console

    2. Click Servers.

    3. Open the Control tab.

    4. Select WLS_Spaces1, WLS_Spaces2, WLS_Portlet1 and WLS_Portlet2.

    5. Click Start.

    6. Verify direct access to the managed servers using the following URLs:

      apphost1:8888/webcenter

      apphost2:8888/webcenter

      apphost1:8889/portaltools

      apphost2:8889/portaltools

  2. While WLS_Spaces2 and WLS_Portlet2 are running, stop WLS_Spaces1 and WLS_Portlet1 from Oracle WebLogic Server Administration Console.

  3. Access the following URLs and verify the appropriate functionality:

    • WebHost1:7777/webcenter

    • WebHost1:7777/portalTools

  4. Start WLS_Spaces1 and WLS_Portlet1 from the WebLogic Server Administration Console.

  5. Stop WLS_Spaces2 and WLS_Portlet2.

  6. Access the following URLs and verify the appropriate functionality:

    • WebHost1:7777/webcenter

    • WebHost1:7777/portalTools

6.4.12 Configuring Manual Failover of the Administration Server to APPHOST2

For information about configuring the administration server for high availability, see Section 10.2.2.3, "Transforming the Administration Server for Cold Failover Clusters."

6.4.13 Configuring the Java Object Cache

The Java Object Cache (JOC) should be configured among all the servers running WebCenter Spaces. This local cache is provided to increase the performance of Oracle WebCenter Spaces.

The Java Object Cache can be configured using the MW_HOME/webcenter/scripts/configure-joc.py script. This is a Python script which can be used to configure JOC in the managed servers. The script runs in WLST online mode and expects Admin Server to be up and running.

Note:

After configuring the Java Object Cache using the wlst commands or configure-joc.py script, all affected managed servers should be restarted for the configurations to take effect.

Usage

  1. Connect to the Administration Server using the command-line Oracle Weblogic Scripting Tool (WLST), for example:

    MW_HOME/wc/common/bin/wlst.sh
$ connect()

    Enter the Oracle Weblogic Administration user name and password when prompted.

  2. After connecting to the Administration Server using wlst, start the script using the execfile command, for example:

    wls:/mydomain/serverConfig>execfile('MW_HOME/webcenter/scripts/configure-joc.py')

  3. All the input parameters are prompted by the script. The script can be used to perform the following JOC configurations:

    1. Configure JOC for all the managed servers for a given cluster.

      Enter 'y' when the script prompts whether you want to specify a cluster name, and also specify the cluster name and discover port, when prompted. This discovers all the managed servers for the given cluster and configure the JOC. The discover port is common for the entire JOC configuration across the cluster. For example:

      Do you want to specify a cluster name (y/n) <y>
Enter Cluster Name : Spaces_Cluster
Enter Discover Port : 9999

    2. Configure JOC for all specified managed servers.

      Enter 'n' when the script prompts whether you want to specify a cluster name, and also specify the managed server and discover port, when prompted. For example:

      Do you want to specify a cluster name (y/n) <y>n
Enter Managed Server and Discover Port (eg WLS_Spaces1:9999, WLS_Spaces2:9999) : WLS_Spaces1:9999,WLS_Spaces2:9999

      This example configures JOC only for the specified managed server (that is, WLS_Spaces1 & WLS_Spaces2). The discover port is specified with the managed server (for example, WLS_Spaces1:2222).

    3. Exclude JOC configuration for some managed servers.

      The script allows you to specify the list of managed servers for which the JOC configuration "DistributeMode" will be set to 'false'. Enter 'y' when the script prompts whether you want to exclude any servers from JOC configuration, and enter the managed server names to be excluded, when prompted. For example:

      Do you want to exclude any server(s) from JOC configuration (y/n) <n>y
Exclude Managed Server List (eg Server1,Server2) : WLS_Spaces1,WLS_Spaces3

    4. Disable the distribution mode for all managed servers.

      The script allows you to disable the distribution to all the managed servers for a specified cluster. Specify 'false' when the script prompts for the distribution mode. By default, the distribution mode is set to 'true'.

6.4.14 Running CacheWatcher to verify Java Object Cache

You can execute a utility called CacheWatcher to verify your java object cache configuration. To execute CachWatcher:

For MW_ORA_HOME below use the location of the Oracle WebCenter installation (FMW_HOME/Oracle_WC1)

  1. For MW_ORA_HOME use the location of the Oracle WebCenter installation, for example, MW_HOME/Oracle_WC1.

  2. For DOMAIN_HOME, use the full path to the location of your domain, under MW_HOME/user_projects/domains. Server_Name refers to a managed server name, for example, WLS_Portlet1.

  3. On any machine, for example, APPHOST1, execute the following:

    "java -classpath WLS_HOME/WebCenter_oracle_home/modules/
oracle.javacache_11.1.1/cache.jar:WLS_HOME/WebCenter_oracle_home/modules/oracle.odl_11.1.1/ojdl.jar oracle.ias.cache.CacheUtil 
watch -config=DOMAIN_HOME/config/fmwconfig/servers/Server_Name/javacache.xml"

  4. On APPHOST2, execute the following:

    "java -classpath MW_HOME/modules/oracle.javacache_11.1.1/
cache.jar:MW_HOME/modules/oracle.odl_11.1.1/ojdl.jar
oracle.ias.cache.CacheUtil watch -config=absolute_path_of_your_config_file"

  5. At the CacheWatcher's prompt, type lc and then press Enter.

    A group view appears.

    The group view indicates the number of cache members. The following is an example of a CacheWatcher run:

    java -classpath MW_HOME/modules/oracle.javacache_11.1.1/
cache.jar:MW_HOME/modules/oracle.odl_11.1.1/ojdl.jar
oracle.ias.cache.CacheUtil watch -config=DOMAIN_HOME
/config/fmwconfig/servers/WLS_Spaces_Server/javacache.xml"
cache> lc
VID:    2
Size:   2
Column: 0123456789
CL:     JJ
GRP0:   11
...
Member Table:
#1. J57161:145.87.9.15:86AAC2E:11B28D57BE4:-7FFE, 0
#2. J35578:145.87.9.14:-9E92850:11B28D5F7E0:-7FFF, 1

    After starting CacheWatcher on each host, find two members from the view.

    Note:

    CacheWatcher itself is considered a distribute cache instance. To terminate the CacheWatcher shell, type exit and press Enter.

6.4.15 Configuring Oracle WebCenter for Replication

Use the procedures in this section to configure Oracle WebCenter for replication.

Clustering Requirement

The application must be deployed to an Oracle WebLogic Cluster. This automatically establishes a replication channel for the multiple instances of the application.

Note:

In a Unicast cluster, the default replication channel is configured using the Listen address of each managed server. Therefore, the Listen address should be configured to be a specific IP address or host name, instead of being configured to listen on Any.

Oracle ADF Replication

Oracle WebCenter relies on Oracle ADF components, therefore, essential that Oracle ADF is configured properly. The following tag should be present in the adf-config.xml file, one of the Application Resources, for a stateful application:

<adfc:adf-controller-config><adfc:adf-scope-ha-support>true</adfc:adf-scope-ha-support></adfc:adf-controller-config>

In Oracle WebCenter applications, this is already been enabled by default.

Application Replication

Applications must also have replication enabled. Oracle WebLogic Server allows several types of persistent stores for replication. For more information on persistent stores, seeOracle Fusion Middleware Using Clusters for Oracle WebLogic Server.

For Oracle WebCenter, applications are enabled by default with the following setting in the weblogic.xml file:

<session-descriptor>
<persistent-store-type>replicated_if_clustered</persistent-store-type>
</session-descriptor>

The replicated_if_clustered setting disables replication for stand-alone application environments, and uses in-memory replication within a cluster environment.

Ensure that any custom application is configured for in-memory replication.

6.4.16 Scaling the Topology

You can scale out and scale up an Oracle WebCenter topology. When you "scale up" the topology, you add new managed servers to nodes that are already running one or more managed servers. When you "scale out" the topology, you add new managed servers to new nodes.

6.4.16.1 Scaling Up the Topology (Adding Managed Servers to Existing Nodes)

In this case, you already have a node that runs a managed server configured with WebCenter components. The node contains a Middleware home and a WebCenter directory in shared storage.

You can use the existing installations (Middleware home, and domain directories) for creating new Oracle WebCenter and servers. There is no need to install WebCenter binaries in a new location, or to run pack and unpack.

Follow these steps for scaling up the topology:

  1. Using the Administration Console, clone WLS_Spaces1 or WLS_Portlet1 or WLS_Services1 into a new managed server. The source managed server to clone should be one that already exists on the node where you want to run the new managed server.

    To clone a managed server:

    1. Select Environment -> Servers from the Administration Console.

    2. Select the managed server that you want to clone (for example, WLS_Spaces1 or WLS_Portlet1).

    3. Select Clone.

    Name the new managed server SERVER_NAMEn, where n is a number to identify the new managed server.

  2. For the listen address, assign the host name or IP to use for this new managed server.

    Ensure the port number for this managed server is availble on this node.

  3. If the managed server being scaled out is WLS_Services, then follow these extra steps:

    1. Start up the managed server at least once, to create the managed servers deployment directories for Oracle Wiki. The managed server can then be shut down.

    2. Create a soft link from this new servers config directories to that of the shared Wiki Server directories:

      $ ln -s DOMAIN_HOME/servers/WLS_ServicesN/stage/owc_wiki/11.1.1.1.0/owc_wiki/attachments/ /shared/owc_wiki/attachments
$ ln -s DOMAIN_HOME/servers/WLS_ServicesN/stage/owc_wiki/11.1.1.1.0/owc_wiki/templates/ /shared/owc_wiki/templates

  4. Reconfigure the Oracle HTTP Server module with the new member in the cluster. See Oracle HTTP Server configuration.

6.4.16.2 Scaling Out the Topology (Adding Managed Servers to New Nodes)

In scaling out your topology, you add new managed servers configured with Oracle WebCenter applications to new nodes.

Before performing the steps in this section, check that you meet these requirements:

  • In your topology, there are existing nodes running managed servers configured with Oracle WebCenter applications.

  • The new node can access the existing home directories for WebLogic Server and Oracle WebCenter. You use the existing installations in shared storage for creating a new managed server. There is no need to install WebLogic Server or WebCenter binaries in a new location, or to run pack and unpack.

Follow these steps for scaling out the topology:

  1. On the new node, mount the existing Middleware home, which includes the WebCenter installation and the domain directory, and ensure that the new node has access to this directory, just like the rest of the nodes in the domain.

  2. Create a new machine for the new node that will be used, and add the machine to the domain.

  3. Update the machine's Node Manager's address to map the IP of the node that is being used for scale out.

  4. Using the Administration Console, clone WLS_Spaces1/WLS_Portlet1/WLS_Services1 into a new managed server and name it WLS_(SERVER_TYPE)n, where n is a number.

    The steps assume that you are adding a new server to node n, where no managed server was running.

  5. For the listen address of the managed server, assign the host name or IP to use for the new managed server.

  6. If the managed server being scaled out is WLS_Services then follow these extra steps:

    1. Start up the managed server at least once, to create the managed servers deployment directories for Oracle Wiki. The managed server can then be shut down.

    2. Create a soft link from this new servers config directories to that of the shared Wiki Server directories:

      $ ln -s DOMAIN_HOME/servers/WLS_ServicesN/stage/owc_wiki/11.1.1.1.0/owc_wiki/attachments/ /shared/owc_wiki/attachments
$ ln -s DOMAIN_HOME/servers/WLS_ServicesN/stage/owc_wiki/11.1.1.1.0/owc_wiki/templates/ /shared/owc_wiki/templates

  7. Reconfigure the Oracle HTTP Server module with the new member in the cluster (see Oracle HTTP Server configuration).

  8. Start Node Manager on the new node: using the installation in shared storage from the already existing nodes, start Node Manager passing as parameter the host name of the new node:

    NEW_NODE> MW_HOME/wlserver_10.3/server/bin/startNodeManager <new_node_ip>

    If you used the paths shown in Section 6.4.3.1, "Installing Oracle WebLogic Server," MW_HOME would be ORACLE_BASE/product/fmw.

  9. Start and test the just added managed server from the Administration Console.

    Access the application on the newly created managed server (http://HOST:port/webcenter). The application should be functional.

  10. Add the New managed server to the Java Object Cache Cluster (see Section 6.4.13, "Configuring the Java Object Cache").

6.4.17 Troubleshooting Oracle WebCenter High Availability

This section describes procedures for troubleshooting possible issues with Oracle WebCenter.

6.4.17.1 Troubleshooting Oracle WebCenter Deployment Issues

Oracle WebCenter Applications are deployed when the managed server is first started. Use Oracle WebLogic Server Administration Console first to check that all application deployments were successful:

Click Deployments in the left hand pane. The right hand pane shows the application deployments and their status. The state of all applications, assuming all the servers are running, should be ACTIVE.

If an application deployment has failed, the server logs may provide some indication of why the application was not deployed successfully. The server logs are located in the DOMAIN_HOME/servers/{SERVER_NAME}/logs directory. Common issues include:

  • Unavailability of external resources, such as database resources. Examine the error, fix it, and attempt to redeploy the application.

  • The appropriate applications or libraries are not targeted correctly to the right managed server or Cluster.

6.4.17.2 Troubleshooting Oracle WebCenter Replication and Failover Issues

State Replication is most prominent in failover scenarios. A user working on one server may discover that, upon failover:

  • Windows may be closed or state might be reset.

  • Screens may require a reset.

  • The application may be redirecting to the logon screen.

The following steps provide guidance in troubleshooting and diagnosing state replication issues.

  1. Confirm that this is not a known replication issue.

    See Section 6.3.2.7, "Expected Behavior for Application Failover" for possible expected behaviors. Before proceeding to further diagnose the issue, first confirm that the failover behavior is not an expected behavior.

  2. Check load balancer settings.

    For replication and failover to function correctly, the load balancer must be configured with the appropriate persistence settings. For more details on configuring Hardware Load Balancers for Oracle WebLogic Server, see Oracle Fusion Middleware Using Clusters for Oracle WebLogic Server.

  3. Check the cluster status.

    Replication occurs within the context of a cluster. For failover to be successful, there must be at least one other healthy member of the cluster available. You can check luster status in one of two ways:

    • Check the cluster status using Oracle WebLogic Server Administration Console - In the Left-hand pane, click on Servers. Verify the state of all servers in the cluster.

    • Check the cluster status using weblogic.Admin utility The weblogic.Admin command can be used to query the state of all servers in a specific cluster. For example:

      $ java weblogic.Admin -url Adminhost:7001 -username <username> -password
 <password>  CLUSTERSTATE -clustername Spaces_Cluster

      This example returns:

      There are 2 server(s) in cluster: Spaces_Cluster
The alive servers and their respective states are listed below:
WLS_Spaces---RUNNING
WLS_Spaces2---RUNNING

  4. Check cluster communications.

    Although Cluster members may all be running, there may be communication issues which prevent them from communicating replication information to each other. There are two types of cluster communication configurations. Troubleshooting depends on the cluster type:

    • Checking Unicast cluster communications - For Unicast clusters, managed servers must be able to access each other's hosts and each other's default listening port.

      Ensure that all individual managed servers have their Listen Address set correctly. You can find this setting by selecting Configuration, General for each managed server.

    • Checking Multicast cluster communications - For multicast clusters, servers must be able to intercept the same multicast traffic. Ensure that multicast is configured correctly by running the WebLogic utility utils.MulticastTest on each machine. For example:

      $ java utils.MulticastTest -H

  5. Confirm application configuration.

    Oracle WebCenter applications are configured correctly by default. For user applications, in-memory replication take place only with the proper configuration in weblogic.xml:

    <session-descriptor>
<persistent-store-type>replicated_if_clustered</persistent-store-type>
</session-descriptor>

    A persistent-store-type of replicated is also acceptable.

  6. Enable Debug.

    Check the server logs for any unusual messages on managed server startup. In particular, if the managed server is unable to locate other members of the cluster. The server logs are located in the DOMAIN_HOME/servers/{SERVER_NAME}/logs directory.

    For further debugging, enable the flags DebugCluster, DebugClusterAnnouncements, DebugFailOver, DebugReplication, and DebugReplicationDetails. Each flag can be enabled with the weblogic.Admin utility:

    $ java weblogic.Admin -url Adminhost:7001 -username <username> -password
 <password> SET -type ServerDebug -property DebugCluster true

6.4.17.3 Troubleshooting Lost Changes to Policies

Problem: Policies are refreshed at an interval defined in jps-config.xml by the variable oracle.security.jps.ldap.policystore.refresh.interval. By default, this interval is ten minutes. If a server is lost, any recent policy changes that occurred since the last refresh may appear to be lost. For example, roles created immediately before the failover may be seen as unavailable.

Solution: The policies are still in the back-end policy store but the cache needs to be refreshed for the policy information to be restored. Re-try after a few minutes or login and logout of the application to force a policy cache refresh.

6.5 Configuring High Availability for Custom Oracle ADF and WebCenter Applications

This section describes procedures for configuring custom Oracle ADF and WebCenter applications for high availability

6.5.1 Configuring a Custom Application Cluster

The following are the necessary steps for configuring a cluster for deploying Oracle WebCenter Custom Applications;

  1. Access Oracle WebLogic Server Administration Console at http://server_name:7001/console.

  2. Type the admin username and password to login.

  3. On the Home page, click Servers from the Domain Configuration section.

  4. On the Summary of the page section, click New.

  5. Type in your own server name for your Custom App Server, and a port number, for example 8898.

  6. Leave other selections as default, and click Finish to generate the managed server.

  7. From the Creation Summary page, click the server you just created. Click the Machine drop-down and select LocalMachine.

  8. Click Save at the bottom of the page.

  9. Repeat steps 4 to 8 to create more managed servers as required.

  10. To create a cluster, on the Home page, click Clusters.

  11. On the right-hand pane, click New to create a new cluster.

  12. Give the cluster a name and leave the default of Unicast.

  13. Click OK to create the cluster.

  14. Click the cluster name, then click the Servers tab.

  15. Click the Add button to add servers.

  16. From the drop-down list, select the previously created managed servers, and then click Finish.

6.5.2 Provisioning the Custom Application Cluster

Once you have created the cluster, provision it with the correct libraries, applications, and data sources.

  1. Click the Deployment link from the Domain Structure section.

  2. Notice several shared libraries are deployed, make sure the following libraries are targeted to the newly created cluster:

    1. Click the library link.

    2. Click the Target tab on top.

    3. Click the check box of the newly created cluster.

    4. Click the Save button.

    The shared library lists to set the target to are:

    • adf.oracle.domain(1.0,11.1.1.0.0)

    • adf.oracle.domain.webapp(1.0,11.1.1.1.0)

    • jsf(1.2,1.2.9.1)

    • jstl(1.2,1.2.0.1)

    • ohw-rcf(5,5.0)

    • ohw-uix(5,5.0)

    • UIX(11,11.1.1.1.0)

    • oracle.adf.dconfigbeans(1.0,11.1.1.0.0)

    • oracle.dconfig-infra

    • oracle.jrf.system.filter

    • oracle.jsp.next(11.1.1,11.1.1)

    • oracle.sdp.client(11.1.1,11.1.1)

    • oracle.soa.workflow.wc(11.1.1,11.1.1)

    • oracle.webcenter.framework(11.1.1,11.1.1)

    • oracle.webcenter.framework.view(11.1.1,11.1.1)

    • oracle.webcenter.skin(11.1.1,11.1.1)

    • oracle.wsm.seedpolicies(11.1.1,11.1.1)

    • oracle.portlet-producer.jpdk(11.1.1,11.1.1)

    • oracle.portlet-producer.wsrp(11.1.1,11.1.1)

    Set the target for each one of these libraries to target to the new managed server.In addition, set the target to deploy to the Cluster for the following applications:

    • DMS Application

  3. From left pane of Oracle WebLogic Server Administration Console, click Services, JDBC, and then Data Sources. Make sure the following data sources are targeted to the newly created Cluster:

    • mds-OWSM

      Note:

      If you created your own MDS schema for your custom applications, assign the new MDS schema to the new Cluster, and omit the two pre-defined MDS schemas.

  4. From the left pane of Oracle WebLogic Server Administration Console, click Environment, and then Startup & Shutdown classes. The following list of classes become available:

    • Audit Loader Startup Class

    • DMS-Startup

    • JMX Framework Startup Class

    • JOC-Startup

    • JPS-Startup Class

    • JRF Startup Class

    • ODL-Startup

    • OWSM Startup Class

    Target all those classes to the new Cluster by clicking:

    The name of each startup/shutdown class, Target tab, the CustomManagedServer checkbox, and then click Save.

    When you complete these steps, you can start the managed server using Oracle WebLogic Server Administration Console and you can now deploy custom applications. Deploy custom applications to the Cluster target, not the managed server target.

  5. Target all those classes to the new Cluster by clicking the name of each startup/shutdown class, the Target tab, and the CustomManagedServer checkbox.

  6. Click Save

  7. Activate the changes.

When you complete these steps, you can start the managed server using Oracle WebLogic Server Administration Console and you can now deploy custom applications. Deploy custom applications to the Cluster target, not the managed server target.

To continue configuring the WebCenter high availability deployment, see the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.