11 Configuring High Availability for WebCenter Content

Oracle WebCenter Content, an Oracle Fusion Middleware component, is an integrated suite of products designed for managing content. It enables you to leverage industry-leading document management, Web content management, digital asset management, and records management functionality to build your business applications. Building a strategic enterprise content management infrastructure for content and applications helps you to reduce costs, easily share content across the enterprise, minimize risk, automate expensive, time-intensive and manual processes, and consolidate multiple Web sites onto a single platform.

Oracle WebCenter Content offers the following benefits:

• Superior usability: Built-in support for end users, workgroups, content experts, process owners, administrators, and webmasters

• Optimized management: Unified architecture for securely managing documents, files, web content and digital assets

• Hot-pluggable: Out-of-the-box support for Oracle and third-party repositories, security systems, and enterprise applications

This chapter describes some of the Oracle WebCenter Content components from a high availability perspective. This chapter outlines single-instance concepts that are important for designing a high availability deployment.

The chapter includes the following topics:

• Section 11.1, "Oracle WebCenter Content: Imaging High Availability"

• Section 11.2, "Oracle WebCenter Content High Availability"

• Section 11.3, "Oracle WebCenter Content High Availability Configuration Steps"

11.1 Oracle WebCenter Content: Imaging High Availability

This section provides an introduction to Oracle WebCenter Content: Imaging (Imaging) and describes how to design and deploy a high availability environment for Imaging.

This section includes the following topics:

• Section 11.1.1, "Imaging Component Architecture"

• Section 11.1.2, "Imaging High Availability Concepts"

11.1.1 Imaging Component Architecture

Imaging provides organizations with a scalable solution focused on process-oriented imaging applications and image-enabling business applications, such as Oracle E-Business Suite and PeopleSoft Enterprise. It enables annotation and markup of images, automates routing and approvals, and supports high-volume applications for trillions of items.

Imaging is a transactional content management tool; it manages each document as part of a business transaction or process. A transactional document is important to you mostly during the time when the transaction is occurring, typically a relatively short period of time.

Figure 11-1 shows the Imaging internal components (components inside the Imaging package).

Figure 11-1 Imaging Components for a Single Instance

Description of "Figure 11-1 Imaging Components for a Single Instance"

Note the following before you begin setting up an Imaging configuration:

• Imaging is a relatively thin layer of functionality on top of the Oracle Universal Content Manager (WebCenter Content) repository. Imaging provides an imaging facade on WebCenter Content. The repository performs a major portion of resource utilization. For this reason, Oracle recommends configuring WebCenter Content by putting an WebCenter Content instance with every Imaging instance. This configuration provides good utilization of hardware.

• Imaging's largest performance factor is the movement of document content. Imaging is usually used in high-volume scenarios in which hundreds of thousands of documents are ingested per day. These documents are searched for, retrieved, and viewed frequently during the day. It is the movement of document content in and out of the system that has the largest impact on performance. Imaging stores TIF documents that average about 25K bytes in size. However, TIF documents can have multiple pages, which increases their size. Imaging also supports 400 other file formats of varying sizes, including larger sizes.

11.1.1.1 Imaging Component Characteristics

Imaging is a Java EE application that runs in the WebLogic Server Managed Server environment. It includes the following components and subcomponents:

• Servlets: Imaging has a servlet for internal use that provides a mechanism for the REST API and Imaging Applet Viewer to access the system's public API functions.

• EJBs: Imaging uses some EJB concepts internally but has no external facing EJBs.

• Imaging leverages JMS to drive both its Input Agent and its BPEL Agent message-driven beans (MDBs). In Figure 11-1, the BPEL Agent is the collection of BPEL MDBs. These queues should be persistent and provide guaranteed delivery. They should also distribute work across clusters.

• Imaging leverages JAX-WS and JAX-B to implement its Web services and serialization mechanisms.

• Imaging leverages TopLink for its definition persistence as well as configuration. The objects are generally the definitions for applications and searches. In addition, TopLink is used to get user and system preferences.

• Imaging leverages Java Object Cache (JOC) for an internal cache of documents retrieved from the repository and being processed for viewing. These caches exist only locally, and are not shared across the servers.

• The interaction between AXF and BPEL is done through the BPEL remote API, which uses RMI via EJB.

Note:

Imaging does not use Java Transaction API (JTA) because Imaging does not support multi-component transactions.

11.1.1.1.1 Imaging State Information

Because Imaging has a stateful UI but does not support session replication, it requires a sticky load balancing router.

Invocations to the Imaging services using the Imaging API are stateless.

11.1.1.1.2 Imaging Runtime Processes

Imaging's core uses a service-based architecture with a central API, UI and Web Service interface. The UI, which is ADF based, uses Imaging's public API to access the core services. End users can access this API via Web Services. Imaging also provides a thin Java client library that exposes those Web services in a more convenient packaging for Java developers.

Imaging has these agents to perform background processing:

• The Input Agent watches an input directory for incoming lists of documents to ingest.

• The BPEL Agent responds to document create events and creates new BPEL process instances with metadata from the document and a URL to the document attached. In Figure 11-1, the BPEL Agent is the collection of BPEL MDBs.

• The Ticket Agent is a stateless EJB that is invoked off a timer. It is not shown in Figure 11-1. The Ticket Agent is responsible for identifying and removing expired URL tickets. These tickets are used to create clean URLs without parameters.

The Imaging service uses the WebCenter Content document repository for the storage of its scan documents. The WebCenter Content repository is a standalone product to which Imaging communicates via a TCP/IP socket-based connection mechanism provided by WebCenter Content called RIDC.

11.1.1.1.3 Imaging Process Lifecycle

Imaging does not provide any specific death detection, but WebLogic Server Node Manager can be used to keep the server running.

The steps in the Imaging process lifecycle are:

1. Imaging is mostly initialized after domain configuration occurs. The remaining initialization occurs when Imaging starts and the first user logs on.

2. When the first user logs on, full security is granted to the user under the assumption that he can subsequently grant permissions to others. Imaging provides a self-seeding database security mechanism. If Imaging starts and there is no security defined, the first user logging into the system is granted access to all things.

3. After Imaging's first startup, Imaging is "empty." It is the administrative user's responsibility to create connections to the WebCenter Content document repository and BPEL servers.

4. After the first UCM connection is created, the WebCenter Content repository initializes for Imaging's use.

5. The appropriate business object must then be created, including Applications, Searches, and Inputs. The administrative user may choose to import these business objects rather than create them from scratch.

6. If the Agent User is specified in step 1, the agents will be waiting for JMS queue events to begin their work after the servers has been restarted

7. After the server is running and the JAX-WS mechanics are ready, Imaging can receive client requests.

11.1.1.1.4 Imaging Configuration Artifacts

Imaging has the following configuration artifacts:

• All Imaging configuration data is stored within the Imaging database. Configuration does not reside in local files. The configuration parameters are exposed either through the appropriate MBeans (available form Enterprise Manager or WLST) or through Imaging's UI.

• The other Imaging configuration artifacts are the definition objects, which are described in Section 11.1.1.1.5, "Imaging External Dependencies."

• Imaging uses WebCenter Content mechanisms for customizing WebCenter Content for use with Imaging, including management of UCM Profiles and Information Fields.

11.1.1.1.5 Imaging External Dependencies

Imaging has the following external dependencies:

• Imaging requires a database to store its configuration. The database is initially create via RCU and is managed through WebLogic Server JDBC data sources. The database is accessed via TopLink.

• Imaging leverages a variety of Oracle and Java technologies, including JAX-WS, JAX-B, ADF, TopLink, and JMS. These are included with the installation and do not require external configuration.

• Imaging provides Mbeans for configuration. These are available through WLST and the EM Mbean browser. Imaging provides a few custom WLST commands.

• Imaging depends on the existence of an WebCenter Content repository.

The following clients depend on Imaging:

• The Imaging UI is built on its public toolkit (the Imaging API). The UI and core API are distributed in the same EAR file.

• Imaging provides Web services for integrations with other products, and provides a set of Java classes that wrap those Web services as a Java convenience for integrating with other products.

• Imaging provides a URL toolkit to facilitate other applications interacting with Imaging searches and content.

• Imaging provides a REST toolkit for referencing individual pages of documents for web presentation.

Clients connect to Imaging through either:

• JAX-WS for the Web services and/or Java client. These connections are stateless and perform a single function.

• HTTP for access to URL and REST tools:

  • REST requests are stateless and perform a single function.

  • URL tools log into the Imaging UI and provide a more stateful experience with the relevant UI components.

11.1.1.1.6 Imaging Log File Location

All log messages log to server log files of the WebLogic Server that the application is deployed on.

The default location of the diagnostics log file is:

WL_HOME/user_projects/domains/domainName/servers/serverName/logs/
serverName-diagnostic.log

You can use Oracle Enterprise Manager to easily search and parse these log files.

11.1.2 Imaging High Availability Concepts

This section provides conceptual information about using Imaging in a high availability two-node cluster.

11.1.2.1 Imaging High Availability Architecture

Figure 11-2 shows an Imaging high availability architecture:

Figure 11-2 Imaging High Availability Architecture Diagram

Description of "Figure 11-2 Imaging High Availability Architecture Diagram"

Imaging can be configured in a standard two node active-active high availability configuration. Although Imaging's UI layer will not fail over between active servers, its other background processes will.

In the Imaging high availability configuration shown in Figure 11-2:

• The Imaging nodes are exact replicas of each other. All the nodes in a high availability configuration perform the exact same services and are configured through the centralized configuration database, from which all servers pull their configuration.

• A load balancing router with sticky session routing must front-end the Imaging nodes. Oracle HTTP Server can be used for this purpose.

• Imaging can run both within a WebLogic Server cluster or without.

• All the Imaging instances must share the same database connectivity. This can be Oracle RAC for increased high availability potential. Imaging uses TopLink for database actions.

• Imaging requires one common shared directory from which its Input Agent draws inbound data files staged for ingestion. Once an Input Agent pulls input definition files, processing of the input file and images associated will stay isolated to that WebLogic Server instance.

11.1.2.1.1 Starting and Stopping the Cluster

Imaging's agents (Input Agent, BPEL Agent) start as an integral part of the Imaging application residing in the WebLogic Server in the cluster. Based on outstanding work in the JMS queues (which are persisted and preserved across failures), they begin processing immediately. The Input Agent also looks for work in its inbound file directory. If there are files to be processed, they are pushed to the corresponding JMS queues and a server in the cluster consumes it and processes the associated images. WebLogic Server workload managers control the numbers of threads dedicated to the BPEL Agent and Input Agent.

When servers in a cluster stop, the agents finish their activity. The BPEL Agent has a short run cycle and all work is likely completed before shutdown. In flight BPEL invocations are retried three times and JMS logs preserve pending operations. The Input Agent can process files of considerable size; a large input file can take hours to process. The amount of work pending after a stop is preserved in the associated JMS persistence stores. When you restart the server that hosts the Input Agent, the agent starts processing where it left off. Processing image files continues in the server that initially consumed the corresponding input file after restart or server migration.

11.1.2.1.2 Cluster-Wide Configuration Changes

Imaging configuration is stored in the Imaging database and shared by all the Imaging instances in the cluster.

The number of threads for the BPEL Agent and Input Agent for a particular Imaging instance is a WebLogic Server property (stored as configuration of the Imaging application) and is controlled through the Administration Console or with WLST commands.

11.1.2.2 Protection from Failures and Expected Behaviors

To protect the Imaging high availability configuration from failure:

• Use a load balancing router with sticky session routing to front-end the Imaging nodes. Oracle HTTP Server can be used for this purpose.

• Configure timeouts for the load balancing router based on the size of the documents being uploaded or retrieved by Imaging for viewing.

The following features also help protect the Imaging high availability configuration from failure:

• JMS failover is provided by WebLogic Servers's JMS implementation.

• TopLink provides database retry logic.

• For connections to WebCenter Content, retry logic exists for immediate retry attempts to resolve network glitches. Imaging provides a failover mechanism to find other WebCenter Content servers in a cluster. The customer can use a load balancer between Imaging and WebCenter Content to also achieve load balancing/failover goals.

• For connections to BPEL, Imaging performs an immediate retry attempt and then push failed items back into the associated JMS queue for retry after a longer timeout (5 minutes). This JMS retry mechanism is performed three times. Any objects continuing to fail go into a holding queue for user intervention.

• API level integrations (such as JPS) are not retried and are assumed to have internal retry logic.

Node Failure

An Oracle/IPM node failure affects the Agent processes for that node. Any unfinished transactions are abandoned and lost. During a failover, the user sessions in the Imaging UI for that node are lost. Users must log in again and restart. Since each Imaging cluster node is independent, failover is managed by the load balancing router and not by Imaging directly.

Because all the Imaging configuration information is stored in the database and all the nodes are replicas of each other, the configuration information is immediately available to the new node after failover.

These are the implications of an Imaging node failure on external resources:

• For JMS transactions, the assumption is that atomic actions done to JMS are internally transactional, and that any messages received from the queue that had not been completed will be resubmitted. BPEL Agent and Input Agent failure recovery relies on persistence of the local messages to a file system. In the event that messages are in the local node, they will be continued upon start of that node. Other messages will be picked up by nodes still running.

• For database transactions, the database is not responsible for a client failure except that it forces an implicit rollback operation when the disconnect occurs. Database transactions from a database outage will be managed by the necessary database facilities (for example, a failover when an Oracle RAC database is being used, and no failover when a single node database is being used). If there is a node failure in the middle of a database access, the user will most likely need to log in again to retry the UI operation.

• User sessions within Imaging are lost during an Imaging server failure. If you are uploading documents through the Imaging UI and an Imaging server failure occurs, it is possible that you will not receive confirmation of successful manual document uploads. In this case, it is recommended that you search for the existence of the documents that you were uploading when the server failure occurred before you attempt to upload them again; this will help avoid the creation of duplicate documents.

If an external application accesses an Imaging cluster by means of a WebService invocation, it is expected that the front end load balancer will provide the appropriate failover logic when an Imaging server fails. If the application interacts with the Imaging system by directly pushing files to the input directory, it is the application's responsibility to retry should a failure in the file system occur.

If an Input definition file is being processed during the time of the outage, Imaging will maintain the file details and upon restart of that specific node, the local JMS queue will respawn that JMS message for retry. Upon retry, the Input Ingestor will attempt to determine where specifically in the file the shutdown occurred, to pick up where it left off so that no documents from the batch are lost. The definition file is maintained in the Stage directory until the specific node that was processing the definition file is able to fully restart and finish the file.

The input file is the smallest unit of work that the Input Agent can schedule and process. There are multiple elements to be taken into consideration to achieve the highest performance, scalability, and high availability:

• All of the machines in an Imaging cluster share a common input directory.

• Input files from this directory are distributed to each machine via a JMS queue.

• The frequency with which the directory is polled for new files is configurable via the CheckInterval MBeans configuration setting.

• Each machine has a specified number of Input Ingestors, responsible for parsing of the Input Definition files. The number of ingestors is controlled via the Workload manager for the InputAgent and is managed by WebLogic Server.

The optimum performance is achieved when:

• Each Imaging cluster node has the maximum affordable number of parsing agents configured via the Work Manager without compromising the performance of the other Imaging activities, such as the user interface and Web services.

• The inbound flow of documents is partitioned into input files containing the appropriate number of documents. On average there should be two input files queued for every parsing agent within the cluster.

• If one or more machines within a cluster fails, active machines will continue processing the input files. Input files from a failed machine will remain in limbo until the server is restarted. Smaller input files ensure that machine failures do not place large numbers of documents into this limbo state.

For example: Two servers process 10,000 inbound documents per hour. A configuration of 2 parsing agents per server produces acceptable overall performance and ingests 2 documents per second per agent. The 4 parsing agents at 2 documents per second is 8 documents per second, or 28,800 documents per hour. Note that a single input file of 10,000 documents cannot process in an hour because a single parsing agent working at 7,200 documents per hour cannot complete it. However, if you divide the single input file into 8 input files of 1,250 documents, this ensures that all 4 parsing agents are fully used and the 10,000 documents are completed in the one hour period. Also, if one server fails, the other can continue processing the work remaining on its parsing agents until the work is successfully completed.

Outages in Components on Which Imaging Depends

Imaging integrates with Oracle SOA Suite. If the SOA server is taken down, Imaging experiences failures. Imaging retries actions three times. Each attempt is followed by a configurable delay time before it repeats. If after the third attempt the action cannot be completed, then these requests queue in a database table to be resubmitted at a later time. The resubmission is accomplished through WLST commands.

Imaging is not dependent on Oracle WebCenter Portal.

Other Oracle ADF applications do not affect the operation of Imaging.

In the Imaging UI, you can specify a list of WebCenter Content servers that it connects to. It uses a primary server to connect to and allows specifying multiple secondary servers. If the primary UCM server fails, Imaging retries the next UCM server in the list. If all the UCM servers are down, an exception is returned and traced in the Imaging server´s log.

11.1.2.3 Creation of Imaging Artifacts in a Cluster

Searches, inputs, applications (all Imaging structural configurations) are stored within the Imaging database. They become immediately available to all machines in the cluster, including the Web UI layers. The Web UI does not automatically refresh when a new entity is created in another Imaging server in the cluster or in the same server by a different user session; however, you can refresh your web browser to cause a navigation bar refresh for the imaging application.

11.1.2.4 Troubleshooting Imaging

This section describes how to trouble shoot the Imaging server, Advanced Viewer, and Input Agent in a high availability environment.

Additional Imaging troubleshooting information can be found in Oracle WebCenter Content Administrator's Guide for Imaging.

Imaging Server Troubleshooting

Oracle/IPM is a Java EE application deployed on WebLogic Server. All log messages log to server log files of the WebLogic Server that the application is deployed on.

The default location of the diagnostics log file is:

WL_HOME/user_projects/domains/domainName/servers/serverName/logs/
serverName-diagnostic.log

You can use Oracle Enterprise Manager to easily search and parse these log files.

Advanced Viewer Troubleshooting

Imaging primarily provides server side logging, although it does have a client-side component called the Advanced Viewer. This Java Applet uses the standard logging utilities; however, these utilities are disabled in client situations. These utilities can be configured to direct the logging output to either a file or the Java Console via appropriate changes to the logging.properties file for the Java plug-in.

Input Agent Troubleshooting

When the Input Agent for Imaging is uploading documents, if Oracle WebCenter Content fails, messages such as these are generated:

Filing Invoices Input completed successfully with 48 documents processed
successfully out of 50 documents.

In addition, an exception similar to this is generated:

[2009-07-01T16:43:01.549-07:00] [IPM_server2] [ERROR] [TCM-00787]
[oracle.imaging.repository.ucm] [tid: [ACTIVE] .ExecuteThread: '10' for queue:
'weblogic.kernel.Default (self-tuning)'] [userId: <anonymous>] [ecid:
0000I8sgmWtCgon54nM6Ui1AIvEo00005N,0] [APP: imaging#11.1.1.1.0]
A repository error has occurred.
Contact your system administrator for assistance.
[[oracle.imaging.ImagingException: TCM-00787: A repository error has occurred.

Contact your system administrator for assistance.
        stackTraceId: 5482-1246491781549
        faultType: SYSTEM
         faultDetails:
ErrorCode = oracle.stellent.ridc.protocol.ServiceException,
ErrorMessage = Network message format error.
        at
oracle.imaging.repository.ucm.UcmErrors.convertRepositoryError(UcmErrors.
java:109
  .
  .
  .

The Input Agent handles errors by placing the failed documents in an error file, so this behavior and the error messages that are generated under these circumstances are expected.

11.2 Oracle WebCenter Content High Availability

This section provides an introduction to Oracle WebCenter Content (WebCenter Content) and describes how to design and deploy a high availability environment for WebCenter Content.

This section includes the following topics:

• Section 11.2.1, "Oracle WebCenter Content Component Architecture"

• Section 11.2.2, "WebCenter Content High Availability Concepts"

11.2.1 Oracle WebCenter Content Component Architecture

Figure 11-3 shows the WebCenter Content single instance architecture.

Figure 11-3 Oracle WebCenter Content Single Instance Architecture

Description of "Figure 11-3 Oracle WebCenter Content Single Instance Architecture"

An instance of WebCenter Content runs within an Oracle WebLogic Managed Server environment. WebLogic Server is responsible for the WebCenter Content application lifecycle, such as starting and stopping it.

There are two entry points into the WebCenter Content application. One is a listening TCP socket, which can accept connections from clients such as Imaging or Oracle WebCenter Portal. The second is an HTTP listening port, which can accept Web services invocations. The HTTP port is the same port as the Managed Server listen port.

The UCM Server also contains several embedded applications. These can run as applets within the client browser. They include a Repository Manager (RM) for file management and indexing functions and a Workflow Admin for setting up user workflows. For more information on any of these applications, see the Oracle Fusion Middleware Application Administrator's Guide for Content Server.

The UCM Server has three types of persistent stores: the repository (which can be stored in an Oracle database), the search index (which can be stored in an Oracle database), and metadata and web layout information (which can be stored on the file system).

11.2.1.1 WebCenter Content Component Characteristics

WebCenter Content is a servlet that resides in WebLogic Server. A servlet request is a wrapper of a UCM request.

WebCenter Content includes various standalone administration utilities, including BatchLoader and IdcAnalyzer.

JMS and JTA are not used with WebCenter Content.

11.2.1.1.1 WebCenter Content State Information

A request in WebCenter Content is stateless. The session can be persisted in the database to retain authentication information.

11.2.1.1.2 WebCenter Content Runtime Processes

WebCenter Content has a service-oriented architecture. Each request comes into the system as a service. The Shared Services layer parses out the requests and hands the request to the proper handler. Each handler typically accesses the underlying repository to process the request. The three types of repositories and the data that they store are shown in Figure 11-3.

11.2.1.1.3 WebCenter Content Process Lifecycle

You can start and stop WebCenter Content as a WebLogic Server Managed Server. The UCM Administration Server can also be used to start, stop, and configure the UCM instance; the UCM Administration Server still works in the WebLogic Server environment, although it has been deprecated in favor of the WebLogic Administration Console. The load balancer can use the PING_SERVER service to monitor the status of the UCM instance.

During startup, WebCenter Content loads initialization files and data definitions, initializes database connections, and loads localization strings. Through the WebCenter Content internal component architecture, the startup sequence also discovers internal components that are installed and enabled on the system, and initializes those components. The Search/Indexing engine and file storage infrastructure are also initialized.

A client request is typically serviced entirely by one WebCenter Content instance. Existence of other instance in a cluster does not impact client request.

11.2.1.1.4 WebCenter Content Configuration Artifacts

Initialization files are stored in the file system and stored in WebCenter Content system directories.

11.2.1.1.5 WebCenter Content Deployment Artifacts

WebCenter Content uses nostage deployment. That is, all deployment files are local.

11.2.1.1.6 WebCenter Content External Dependencies

WebCenter Content requires WebLogic Server and an external Oracle database.

The following clients depend on WebCenter Content:

• Oracle WebCenter Content: Records (Records)

• Oracle WebCenter Content: Imaging (Imaging

• Oracle WebCenter Portal

The connection from clients is short-lived, and is only needed for the duration of sessionless service.

Clients can connect to WebCenter Content using the HTTP, SOAP/Web Services, JCR, and VCR protocols.

11.2.1.1.7 WebCenter Content Log File Locations

WebCenter Content is a J2EE application deployed on WebLogic Server. Log messages are logged in the server log file of the WebLogic Server that the application is deployed on. The default location of the server log is:

WL_HOME/user_projects/domains/domainName/servers/serverName/logs/
serverName-diagnostic.log

WebCenter Content can also keep logs in:

WebLayoutDir/groups/secure/logs

WebCenter Content trace files can be configured to be captured and stored in:

IntraDocDir/data/trace

To view log files using the WebCenter Content GUI, choose the UCM menu and then choose Administration > Logs.

To view trace files using the WebCenter Content GUI, choose the UCM menu and then choose System Audit Information. Click the View Server Output and View Trapped Output links to view current tracing and captured tracing.

11.2.2 WebCenter Content High Availability Concepts

This section provides conceptual information about using WebCenter Content in a high availability two-node cluster.

11.2.2.1 WebCenter Content High Availability Architecture

Figure 11-4 shows a two-node active-active Oracle WebCenter Content cluster.

Figure 11-4 Oracle WebCenter Content Two-Node Cluster

Description of "Figure 11-4 Oracle WebCenter Content Two-Node Cluster"

In the WebCenter Content high availability configuration shown in Figure 11-4:

• Each node runs independently against the shared file system, the same database schema, and the same search indexes. Each client request is served completely by a single node.

• WebCenter Content can run with a WebLogic Server cluster or an external load balancer. WebCenter Content is also transparent to Oracle RAC and multi data source configuration.

• WebCenter Content nodes can be scaled independently, and there is limited inter-node communication. Nodes communicate via writing and reading to a shared file system. This shared file system must support synchronized write operations.

11.2.2.1.1 Starting and Stopping the Cluster

When the cluster starts, each WebCenter Content node goes through its normal initialization sequence, which parses, prepares, and caches its resources, prepares its connections, and so on. If a node is part of a cluster then in-memory replication is initiated if other cluster members are available. One or all members of the cluster can be started at any one time.

Shutting down a cluster member will only involve that cluster member being unavailable to service requests. When a server is shut down gracefully, it finishes processing current requests, signals its unavailability, and then releases all shared resources and close its file and database connections. All session states are replicated, enabling users originally connected to this cluster member to fail over to another member of the cluster.

11.2.2.1.2 Cluster-Wide Configuration Changes

At the cluster level, new WebCenter Content features or customization of behaviors can be introduced through WebCenter Content internal components. You must restart nodes for them to pick up new changes.

For example, the metadata model can change system wide. For instance, a metadata field can be added, modified, or deleted. The system behavior that was driven by these metadata fields can be changed. This change would automatically be picked up by cluster nodes through notification between nodes.

For changes to occur on each cluster member, the first node needs to have shared folders configured. As long as all the shared folders have the same mount point on each cluster node, the other nodes do not need do make manual changes using WebLogic Server pack/unpack.

11.2.2.2 WebCenter Content and Inbound Refinery High Availability Architecture

WebCenter Content can be configured with one or more Inbound Refinery instances to provide document conversions.

Inbound Refinery is a conversion server that manages file conversions for electronic documents such as documents, digital images, and motion video. It also provides thumbnailing functionality for documents and images, the ability to extract and use EXIF data from digital images and XMP data from electronic files generated from programs such as Adobe Photoshop and Adobe Illustrator, and storyboarding for video. For more information about Inbound Refinery, refer to Oracle Fusion Middleware Administrator's Guide for Conversion.

The number of Inbound Refinery instances which need to be installed will depend on the amount of conversions which need to be supported. For availability, it is recommended that at least two Inbound Refinery instances be installed. All of the Inbound Refinery instances should be made available as providers to all members of a Content Server cluster.

11.2.2.2.1 Content Server and Inbound Refinery Communication

All communication between a Content Server and an Inbound Refinery is initiated by the Content Server. This includes:

• Regular checks of all available Inbound Refinery instances to determine their status.

• The initiation of a job request.

• Retrieval of completed jobs.

The status includes information on whether the Inbound Refinery is available to accept requests. This will depend on how busy the Inbound Refinery is. If no Inbound Refinery instances are available, the request is retried.

When jobs are completed, this information will appear as part of the Content Server's status request. If so, the Content Server will initiate download of the completed job.

11.2.2.2.2 Content Server Clusters and Inbound Refinery Instances

In a Content Server cluster, cluster members share the list of all available Inbound Refinery instances. That is, when a new Inbound Refinery instance is added, it becomes available for any Content Server cluster member to use.

However, each Content Server communicates independently with all the available Inbound Refinery instances. There is no shared status in a Content Server cluster.

Likewise, all Inbound Refinery instances operate completely independently, responding to requests from Content Servers. Inbound Refinery instances do not share any information.

11.2.2.2.3 Inbound Refinery Instances and Load Balancers

Load balancers cannot be used in front of a collection of Inbound Refinery instances for the following reasons:

• A Content Server expects to be able to contact an Inbound Refinery directly to get status and availability information.

• When a job is finished, a Content Server must be able to access the one Inbound Refinery that has the specific job and initiate a download.

11.2.2.2.4 Inbound Refinery Availability

Requests to Inbound Refinery do not occur in real-time since all requests are asynchronous requests mediated by Content Server. Users access Content Servers, and Content Servers then delegate requests to available Inbound Refinery instances. Enough Inbound Refinery instances should be configured so that if one or more fail, there are always other Inbound Refinery instances available to service requests.

A Content Server will never mark an Inbound Refinery as "failed." If unable to contact an Inbound Refinery, then Content Server will choose another available Inbound Refinery and will continue to check the availability of all Inbound Refinery instances. It is the responsibility of a system administrator to manually remove failed Inbound Refinery instances from the Content Server lists.

11.2.2.3 Records High Availability

Records and WebCenter Content share the same architecture. As such, all high availability considerations which apply to WebCenter Content also apply to Records.

When configuring high availability, there are only two differences to note between WebCenter Content and Records:

1. Records stores its file system metadata in a different directory than WebCenter Content.

2. When configuring an HTTP Server in front of an Records cluster, a different session cookie name must be used than that of WebCenter Content.

More details on these two configuration differences are provided in the section below on the Oracle WebCenter Content High Availability Configuration Steps.

11.2.2.4 Protection from Failure and Expected Behaviors

The following features help protect an WebCenter Content node from failure:

• Load balancing can be achieved by using an external load balancer. The session does not need additional sticky state data other than its authentication information.

• The load balancer can be configured in front of WebCenter Content. Multi data sources can be configured with WebCenter Content to support Oracle RAC. Timeouts and retries are also supported.

• WebCenter Content uses standard WebLogic Server persistent session.

• WebCenter Content does not use EJBs.

• Death can be detected using the WebCenter Content PING_SERVER service. When a node is restarted, it does not affect other nodes in the cluster.

• Failover is handled either by the load balancer in front of the WebCenter Content nodes, or by the WLS module in Apache. Ongoing requests from the client would fail, but subsequent requests are rerouted to active nodes. Unfinished transactions would not complete.

• Configuration information from the node is not lost, because it is stored on the shared file system and in the database.

• When a node fails, a database connection between the node and the database should be reclaimed by the database.

• Although instances normally do not get hung, it can occur because of unknown deadlock conditions in the WebCenter Content product or customized versions of WebCenter Content.

• Users with active sessions should not experience any disruption as their sessions fail over to an active server. This includes users with UCM administration applets open.

• After the installation of WebCenter Content is complete, the following value should be set in the config.cfg file. This enables retry logic during an Oracle RAC failover:

  ServiceAllowRetry=true
  

  If this value is not set, user will need to manually retry any operation that was in progress when the failover began.

  The value can be set using the Administration Console for WebCenter Content at the following URL:

  http://<hostname>:<port>/cs
  

  Go to Administration > Admin Server > General Configuration and add ServiceAllowRetry=true to Additional Configuration Variables. Save and restart all the UCM managed servers. The new value should appear in config.cfg at the following location:

  SHARED_DISK_LOCATION_FOR_UCM/ucm/cs/config/config.cfg
  

11.2.2.5 Troubleshooting WebCenter Content High Availability

To troubleshoot WebCenter Content, look in the log files and then in the trace files.

See Section 11.2.1.1.7, "WebCenter Content Log File Locations" for information on the location of WebCenter Content log and trace files and information on how to view log and trace files using the WebCenter Content GUI.

When you try to check in a document after shutting down the active server, you get the following error:

The content item was not successfully checked in.
The authorization token is invalid.
It has either expired or is not appropriate for the current request.
You may need to reload an earlier page in order to proceed.

In such a case you must refresh the page to retrieve the updated token and proceed with the check in.

11.3 Oracle WebCenter Content High Availability Configuration Steps

In a high availability environment such as the one shown in Figure 11-5, it is recommended that Oracle WebCenter Content products be set up in a clustered deployment, where the clustered instances access an Oracle Real Applications Cluster (Oracle RAC) database content repository and a shared disk is used to store the common configuration.

A hardware load balancer routes requests to multiple Oracle HTTP Server instances which, in turn, route requests to the clustered Oracle WebCenter Content servers.

This section provides the installation and configuration steps for the Oracle WebCenter Content high availability configuration shown in Figure 11-5.

It includes the following topics:

• Section 11.3.1, "Shared Storage"

• Section 11.3.2, "Configuring the Oracle Database"

• Section 11.3.3, "Installing and Configuring WCCHOST1"

• Section 11.3.4, "Installing and Configuring WEBHOST1"

• Section 11.3.5, "Configuring the Load Balancer"

• Section 11.3.6, "Installing and Configuring WCCHOST2"

• Section 11.3.7, "Installing and Configuring WEBHOST2"

• Section 11.3.8, "Configuring the Imaging Managed Servers"

• Section 11.3.9, "Configuration of Inbound Refinery Instances"

Note:

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

Figure 11-5 Oracle WebCenter Content High Availability Architecture

Description of "Figure 11-5 Oracle WebCenter Content High Availability Architecture"

The configuration will include the following products:

• Imaging

• WebCenter Content

• Oracle Universal Records Manager (URM)

• Oracle WebCenter Content: Inbound Refinery (Inbound Refinery)

All products will be installed on the same machines, with the exception of Inbound Refinery, which is assumed to be on remote machines.

If you do not want to install Imaging or Records, ignore the references to these products in the configuration steps.

11.3.1 Shared Storage

Cluster members require shared storage to access the same configuration files. This should be set up to be accessible from all nodes in the cluster.

When configuring WebCenter Content/URM clusters, follow these requirements:

• For WebCenter Content clusters, all members of the cluster must point to the same configuration directory. This directory must be on a shared disk accessible to all members of the cluster.

• For Records clusters, all members of the cluster must point to the same configuration directory. This directory must be on a shared disk accessible to all members of the cluster.

11.3.2 Configuring the Oracle Database

Configure the Oracle RAC database before completing this procedure.

The Repository Creation Utility (RCU) ships on its own CD as part of the Oracle Fusion Middleware 11g kit.

To run RCU and create the WebCenter Content schemas in an Oracle RAC database repository, follow these steps on any available host:

1. Issue this command:

   prompt> RCU_HOME/bin/rcu &

2. On the Welcome screen, click Next.

3. On the Create Repository screen, select the Create operation to load component schemas into an existing database.

   Click Next.

4. On the Database Connection Details screen, enter connection information for the existing database as follows:

   Database Type: Oracle Database

   Host Name: Name of the computer on which the database is running. For an Oracle RAC database, specify the VIP name or one node name. Example: WCCDBHOST1-VIP or WCCDBHOST2-VIP

   Port: The port number for the database. Example: 1521

   Service Name: The service name of the database. Example: wccdb.mycompany.com

   Username: SYS

   Password: The SYS user password

   Role: SYSDBA

   Click Next.

   If you enter everything correctly, a dialog box opens with the message Operation Completed. If so, click OK. If not, you will see an error under Messages, such as Unable to connect to the database or Invalid username/password.

5. On the Select Components screen, create a new prefix and select the components to be associated with this deployment:

   Create a New Prefix: for example, DEV

   Components: Select only the components for which you intend to create schemas. Under Oracle AS Repository Components > WebCenter Content, choose these components:

   • Oracle WebCenter Content Server 11g - Complete

   • Oracle WebCenter Content: Records 11g

   Click Next.

   If you entered everything correctly, a dialog box will display with the words "Operation Completed." If so, click OK. If not, you will see an error under Messages that you will need to resolve before continuing.

6. On the Schema Passwords screen, ensure that Use same passwords for all schemas is selected. This password will be used in a later step for Content Server to connect to this database schema.

   Click Next.

7. On the Map Tablespaces screen, click Next.

   When the warning dialog box appears, click OK.

   The tablespace creation results should appear in a dialog with the text Operation completed. Click OK.

8. On the Summary screen, click Create.

9. On the Completion Summary screen, click Close.

11.3.3 Installing and Configuring WCCHOST1

This section describes the installation and configuration steps for WCCHOST1.

This section includes the following topics:

• Section 11.3.3.1, "Installing Oracle WebLogic Server on WCCHOST1"

• Section 11.3.3.2, "Installing Oracle WebCenter Content on WCCHOST1"

• Section 11.3.3.3, "Create a High Availability Domain"

• Section 11.3.3.4, "Start the Administration Server and the Managed Servers on WCCHOST1"

• Section 11.3.3.5, "Disabling Host Name Verification for the Administration Server and the Managed Servers for WCCHOST1 and WCCHOST2"

• Section 11.3.3.6, "Configure the WLS_UCM1 Managed Server"

• Section 11.3.3.7, "Configure the WLS_URM1 Managed Server"

11.3.3.1 Installing Oracle WebLogic Server on WCCHOST1

On WCCHOST1, start the Oracle WebLogic Server installation by running the installer executable file.

See "Understanding Your Installation Starting Point" in Oracle Fusion Middleware Installation Planning Guide for the version of Oracle WebLogic Server to use with the latest version of Oracle Fusion Middleware.

Start the Oracle WebLogic Server installer.

Then follow these steps in the installer to install Oracle WebLogic Server:

1. On the Welcome screen, click Next.

2. On the Choose Middleware Home Directory screen, choose a directory on your computer into which the Oracle WebLogic software is to be installed.

   For the Middleware Home Directory, specify this value:

   /u01/app/oracle/product/fmw
   

   Click Next.

3. On the Register for Security Updates screen, enter your "My Oracle Support" User Name and Password.

4. On the Choose Install Type screen, a window prompts you to indicate whether you want to perform a complete or a custom installation.

   Choose Typical or Custom.

   Click Next.

5. On the Choose Product Installation Directories screen, specify the following values:

   WebLogic Server:

   /u01/app/oracle/product/fmw/wlserver_10.3
   

   Oracle Coherence:

   /u01/app/oracle/product/fmw/coherence_3.5.2
   

6. On the Installation Summary screen, the window contains a list of the components you selected for installation, along with the approximate amount of disk space to be used by the selected components once installation is complete.

   Click Next.

7. On the Installation Complete screen, deselect the Run Quickstart checkbox.

   Click Done.

11.3.3.2 Installing Oracle WebCenter Content on WCCHOST1

To start the Oracle WebCenter Content installer:

Note:

Ensure that your DISPLAY environment variable is set correctly before you run the runInstaller command on UNIX.

• On UNIX (Linux in the following example):

  ./runInstaller -jreLoc file-specification-for-jdk6
  

  On Windows:

  setup.exe
  

  Specify the JRE location, for example: C:\Oracle\Middleware\jdk160_11

Follow these steps in the installer to install Oracle WebCenter Content on the system:

1. If this is the first installation, the Specify Oracle Inventory screen opens.

   Accept the defaults and click OK.

   If you are installing as a normal (non-root) user, the Inventory Location Confirmation dialog box opens. Follow its directions, or select Continue Installation with local inventory and click OK.

2. On the Welcome screen, click Next.

3. On the Prerequisite Checks screen, the installer completes the prerequisite check. If any fail, fix them and restart your installation.

   Click Next.

4. On the Specify Installation Location screen, enter these values:

   For the Middleware Home Directory, specify this value:

   /u01/app/oracle/product/fmw
   

   For the Oracle Home Directory, enter the name of the subdirectory where you will install Oracle WebCenter Content, or use the default. This will be referred to as the WCC_HOME:

   /u01/app/oracle/product/fmw/wcc
   

   Click Next.

5. On the Installation Summary screen, review the selections to ensure that they are correct. If not, click Back to change selections on previous screens, and click Install.

6. On the Installation Progress screen on UNIX systems, a dialog box appears that prompts you to run the oracleRoot.sh script. Open a window and run the script, following the prompts in the window.

   Click Next.

7. On the Installation Complete screen, click Finish to confirm your choice to exit.

Note:

Before you run the Configuration Wizard by following the instructions in Section 11.3.3.3, "Create a High Availability Domain," ensure that you applied the latest Oracle Fusion Middleware patch set and other known patches to your Middleware Home so that you have the latest version of Oracle Fusion Middleware.

See "Understanding Your Installation Starting Point" in Oracle Fusion Middleware Installation Planning Guide for the steps you must perform to get the latest version of Oracle Fusion Middleware.

11.3.3.3 Create a High Availability Domain

This section describes how to run the Oracle Fusion Middleware Configuration Wizard to create and configure a high availability domain into which you can deploy applications and libraries.

To start the Oracle Fusion Middleware Configuration Wizard:

• On UNIX (Linux in the following example):

  WCC_HOME/common/bin/config.sh
  

  Ensure that your DISPLAY environment variable is set correctly before issuing the command above.

  On Windows:

  WCC_HOME/config.cmd
  

To create and configure the Oracle WebCenter Content domain on the computer:

1. On the Welcome screen, select Create a new WebLogic domain.

   Click Next.

2. On the Select Domain Source screen, select the applications that you want to install, for example:

   • Oracle WebCenter Content Imaging - 11.1.1.0

   • Oracle WebCenter Content: Records - 11.1.1.0

   • Oracle WebCenter Content - Inbound Refinery - 11.1.1.0

   • Oracle WebCenter Content: Imaging - 11.1.1.0

   Other products such as Oracle JRF and Oracle Enterprise Manager are also automatically selected.

3. On the Specify Domain Name and Location screen, make these entries:

   • Change the domain name to wccdomain or use the default, base_domain. A directory is created for this domain, for example:

     MW_HOME/user_projects/domains/wccdomain
     

   • Domain Location: accept the default

   • Application Location: accept the default

   Click Next.

4. On the Configure Administrator Username and Password screen:

   • In the Username field, enter a user name for the domain administrator or use the default username, weblogic.

   • In the Password field, enter a user password that is at least 8 characters, for example: welcome1

   • In the Configure User Password field, enter the user password again.

   Click Next.

5. On the Configure Server Start Mode and JDK screen:

   • WebLogic Domain Startup Mode: Select Production Mode.

   • JDK Selection: Choose a JDK from the list of available JDKs or accept the default.

   Click Next.

6. On the Configure JDBC Component Schema screen:

   1. Select all component schemas that appear in the table at the bottom: UCM Schema, IPM Schema, and URM Schema.

   2. For the RAC configuration for component schemas, select Convert to GridLink or Convert to RAC multi data source. For single database configuration, select Don't convert.

   3. Ensure that the following data source appears on the screen. The user names in Table 11-1 assume that you used DEV as the prefix for schema creation from RCU.

      For information about GridLink data source configuration with Oracle RAC, see Section 4.1.2, "GridLink Data Sources and Oracle RAC."

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

      Table 11-1 Configuring Values for Data Sources

      Component Schema	Schema Owner
      UCM Schema	DEV_OCS
      IPM Schema	DEV_IPM
      URM Schema	DEV_URMSERVER

      
      

   4. Click Next.

7. Enter values for the following fields, specifying connect information for the Oracle RAC database that was seeded with RCU.

   For multi data sources, enter values for these fields:

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

   
   Description of "Figure 11-6 Configure RAC Multi Data Source Component Schema Screen"
   
   

   For GridLink data sources, enter values for these fields:

   Figure 11-7 Configure GridLink RAC Component Schema

   
   Description of "Figure 11-7 Configure GridLink RAC Component Schema"
   
   

   1. Driver: For RAC: Select Oracle driver (Thin) for RAC Service-Instance connections, Versions:10, 11. For GridLink: Oracle Driver (Thin) for GridLink Connections, Versions:10 and later

   2. Service Name: Enter the service name of the database. For a GridLink data source, you must enter the RAC service name in lower-case letters followed by the domain name example.com. For example, <mydbservice>.example.com

      Note:

      The Oracle RAC Service name is defined on the database; it is not a fixed name. Oracle recommends that you register/add the RAC service name with the database domain name, for example, example.com

   3. Username prefix: Enter the prefix for the schemas. The user names in Table 11-1 assume that DEV is the prefix used in schema creation from RCU.

   4. Password and Confirm Password: Enter the password for access to the schemas.

   5. For a GridLink data source, enter the SCAN address in the Listener Address field and SCAN port in the Port field. Enter the ONS host and port information in the ONS Host and Port fields, respectively.

      Note:

      Oracle recommends that you use SCAN addresses to specify the host and port for both the TNS listener and the ONS listener in the WebLogic console. You do not need to update a GridLink data source containing SCAN addresses if you add or remove Oracle RAC nodes. Contact your network administrator for appropriately configured SCAN urls for your environment. See SCAN Addresses in the Oracle Fusion Middleware Configuring and Managing JDBC Data Sources for Oracle WebLogic Server guide.

      For a multi data source, click Add. Enter details for Oracle RAC instances.

   6. Update each schema: select one data source at a time and add the appropriate details.

      Ensure that the information is entered for all schemas: UCM Schema, IPM Schema, and URM Schema.

   7. Click Next.

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

   After every schema is specified correctly, click Next.

9. Select JMS Distributed Destination, Administration Server and Managed Servers, Clusters and Machines.

10. In the Select JMS Distributed Destination Type screen, select UDD from the drop-down list for the JMS modules of all Oracle Fusion Middleware components.

    Click Next.

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

    • Name: AdminServer

    • Listen address: Enter a host or virtual hostname.

    • Listen port: 7001

    • SSL listen port: Not applicable.

    • SSL enabled: Leave this checkbox unselected.

    Click Next.

12. On the Configure Managed Servers screen, add an additional Managed Server for each of the existing Servers. For example, add an WLS_UCM2 to match WLS_UCM1. The Listen Port for the second Managed Server should be the same as the first. Set the Listen Address for all the servers to the hostname that the Managed Server runs on.

    For example:

    WLS_UCM1

    Listen Address: WCCHOST1

    Listen Port: 16200

    WLS_UCM2

    Listen Address: WCCHOST2

    Listen Port: 16200

    Do this for all the Managed Servers.

    The Imaging servers require a virtual hostname as the listen addresses for the managed server. These virtual host names and corresponding virtual IPs are required to enable server migration for the Imaging component. You must enable a VIP mapping to WCCHOST1VHN1 on WCCHOST1 and WCCHOST2VHN1 on WCCHOST2, and must also correctly resolve the host names in the network system used by the topology (either by DNS Server or hosts resolution).

    The Inbound Refineries should be configured to reside on separate remote servers, for example: IBR_Server1 on WCCHOST3 and IBR_Server2 on WCCHOST4.

13. On the Configure Clusters screen, create a cluster for each pair of servers. For example, for UCM:

    • Name: UCM_Cluster

    • Cluster Messaging Mode: unicast

    • Multicast Address: Not applicable

    • Multicast Port: Not applicable

    • Cluster Address: Not applicable

    Add similarly for other products: IPM_Cluster, URM_Cluster, and so on.

    Click Next.

14. On the Assign Servers to Clusters screen, assign each pair of Managed Servers to the newly created cluster:

    UCM Cluster:

    • WLS_UCM1

    • WLS_UCM2

    Do this for all the clusters you created in the previous step in this section, such as IPM_Cluster, URM_Cluster, and IBR_Cluster.

    Click Next.

15. On the Configure Machines screen, click the Unix Machine tab, and add the following machines:

    • WCCHOST1

    • WCCHOST2

    • WCCHOST3 (if Inbound Refinery is being configured)

    • WCCHOST4 (if Inbound Refinery is being configured)

16. On the Assign Servers to Machines screen:

    • To the WCCHOST1 machine, assign the AdminServer and all *1 Servers (WLS_UCM1, WLS_IPM1, WLS_URM1).

    • To the WCCHOST2 machine, assign all the *2 Servers (WLS_UCM2, WLS_IPM2, WLS_URM2).

    • If configuring Inbound Refinery, add WLS_IBR1 to WCCHOST3 and WLS_IBR2 to WCCHOST4.

17. On the Configuration Summary screen, click Create to create the domain.

11.3.3.4 Start the Administration Server and the Managed Servers on WCCHOST1

Start the Administration Server:

cd DOMAIN_HOME/bin
startWebLogic.sh &

Configure and start the Node Manager:

WCCHOST1> MW_HOME/oracle_common/common/bin/setNMProps.sh
WCCHOST1> MW_HOME/wlserver 10.3/server/bin/startNodeManager.sh
MW_HOME/oracle_common/common/bin/setNMProps.sh
MW_HOME/wlserver 10.3/server/bin/startNodeManager.sh

Access the Administration Console at http://WCCHOST1:7001/console. In the Administration Console, start the WLS_UCM1, WLS_URM1, and WLS_IPM1 managed servers.

11.3.3.5 Disabling Host Name Verification for the Administration Server and the Managed Servers for WCCHOST1 and WCCHOST2

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 hostname verification.

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

To disable hostname verification on WCCHOST1:

1. In the Administration Console, select Servers, and then AdminServer.

2. Select SSL, and then Advanced.

3. In the Change Center, click Lock & Edit.

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

5. Set Hostname Verification to None.

6. Select WLS_UCM1, SSL, and then Advanced.

7. Set Hostname Verification to None.

8. Repeat Steps 6 and 7 for WLS_URM1 and WLS_IPM1.

9. Restart the AdminServers and all the Managed Servers (for example, WLS_UCM1, WLS_URM1, and WLS_IPM1).

To disable hostname verification on WCCHOST2:

1. In the Administration Console, select WLS_UCM2, SSL, and then Advanced.

2. Set Hostname Verification to None.

3. Repeat Steps 1 and 2 for WLS_URM2 and WLS_IPM2.

4. Restart the AdminServers and all the Managed Servers (for example: WLS_UCM2, WLS_URM2, and WLS_IPM2).

11.3.3.6 Configure the WLS_UCM1 Managed Server

Access the WLS_UCM1 configuration page at http://WCCHOST1:16200/cs.

After you log in, the configuration page opens. WebCenter Content configuration files must be on a shared disk. This example assumes that the shared disk is at /u01/app/oracle/admin/domainName/ucm_cluster.

Set the following values on the configuration page to the values below:

• Content Server Instance Folder: /u01/app/oracle/admin/domainName/ucm_cluster/cs

• Native File Repository Location: /u01/app/oracle/admin/domainName/ucm_cluster/cs/vault

• Web Layout Folder: /u01/app/oracle/admin/domainName/ucm_cluster/cs/weblayout

• User Profile Folder: /u01/app/oracle/admin/domainName/ucm_cluster/cs/profile

• Server Socket: Port 4444

• Socket Connection Address Security Filter: Set to a pipe-delimited list of localhost and HTTP Server Hosts: 127.0.0.1|WEBHOST1|WEBHOST2

• WebServer HTTP Address: Set to the host and port of the load balancer HTTP: wcc.mycompany.com:80

To apply these updates, click Submit and restart the WLS_UCM1 managed server.

11.3.3.7 Configure the WLS_URM1 Managed Server

Access the WLS_URM1 configuration page at http://WCCHOST1:16250/urm.

After you log in, the configuration page opens. The Records configuration files must be on a shared disk. This example assumes that the shared disk is at /u01/app/oracle/admin/domainName/ucm_cluster.

Set the following values on the configuration page to the values below:

• Content Server Instance Folder: /u01/app/oracle/admin/domainName/ucm_cluster/urm

• Native File Repository Location: /u01/app/oracle/admin/domainName/ucm_cluster/urm/vault

• Web Layout Folder: /u01/app/oracle/admin/domainName/ucm_cluster/urm/weblayout

• User Profile Folder:/u01/app/oracle/admin/domainName/ucm_cluster/urm/profile

Verify that the Is new Content Server Instance? check box is not selected.

After making these updates, click Submit and then restart the WLS_URM1 managed server.

11.3.4 Installing and Configuring WEBHOST1

This section describes the installation and configuration steps to perform on WEBHOST1.

11.3.4.1 Installing Oracle HTTP Server on WEBHOST1

This section describes how to install Oracle HTTP Server on WEBHOST1.

1. Ensure that the system, patch, kernel and other requirements are met. These are listed in the Oracle Fusion Middleware Installation Guide for Oracle Web Tier in the Oracle Fusion Middleware documentation library for the platform and version you are using.

2. Ensure that port 7777 is not in use by any service on WEBHOST1 by issuing these commands for the operating system you are using. If a port is not in use, no output is returned from the command.

   On UNIX:

   netstat -an | grep "7777"
   

   On Windows:

   netstat -an | findstr :7777
   

3. If the port is in use (if the command returns output identifying the port), you must free the port.

   On UNIX:

   Remove the entries for port 7777 in the /etc/services file and restart the services, or restart the computer.

   On Windows:

   Stop the component that is using the port.

4. Copy the staticports.ini file from the Disk1/stage/Response directory to a temporary directory.

5. Edit the staticports.ini file that you copied to the temporary directory to assign the following custom ports (uncomment the line where you specify the port number for Oracle HTTP Server):

   # The port for Oracle HTTP server
   Oracle HTTP Server port = 7777
   

6. Start the Oracle Universal Installer for Oracle Fusion Middleware 11g Web Tier Utilities CD installation as follows:

   On UNIX, issue this command: runInstaller.

   On Windows, double-click setup.exe.

   The runInstaller and setup.exe files are in the ../install/platform directory, where platform is a platform such as Linux or Win32.

7. On the Specify Inventory Directory screen, enter values for the Oracle Inventory Directory and the Operating System Group Name. For example:

   Specify the Inventory Directory: /u01/app/oraInventory

   Operating System Group Name: oinstall

   A dialog box opens with the following message:

   "Certain actions need to be performed with root privileges before the install can continue. Please execute the script /u01/app/oraInventory/createCentralInventory.sh now from another window and then press "Ok" to continue the install. If you do not have the root privileges and wish to continue the install select the "Continue installation with local inventory" option"

   Log in as root and run the "/u01/app/oraInventory/createCentralInventory.sh"

   This sets the required permissions for the Oracle Inventory Directory and then brings up the Welcome screen.

   Note:

   The Oracle Inventory screen is not shown if an Oracle product was previously installed on the host. If the Oracle Inventory screen is not displayed for this installation, make sure to check and see:

   1. If the /etc/oraInst.loc file exists

   2. If the file exists, the Inventory directory listed is valid

   3. The user performing the installation has write permissions for the Inventory directory

8. On the Welcome screen, click Next.

9. On the Select Installation Type screen, select Install and Configure and click Next.

10. On the Prerequisite Checks screen, the installer completes the prerequisite check. If any fail, fix them and restart your installation.

    Click Next.

11. On the Specify Installation Location screen:

    • On WEBHOST1, set the Location to:

      /u01/app/oracle/admin
      

    Click Next.

12. On the Configure Components screen:

    • Select Oracle HTTP Server.

    • Select Associate Selected Components with Weblogic Domain.

    Click Next.

13. On the Specify WebLogic Domain screen:

    Enter the location where you installed Oracle WebLogic Server. Note that the Administration Server must be running.

    • Domain Host Name: WCCHOST1

    • Domain Port No: 7001

    • User Name: weblogic

    • Password: ******

    Click Next.

14. On the Specify Component Details screen:

    • Enter the following values for WEBHOST1:

      • Instance Home Location: /u01/app/oracle/admin/ohs_inst1

      • Instance Name: ohs_inst1

      • OHS Component Name: ohs1

    Click Next.

15. On 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 the Oracle HTTP Server port, for example, 7777.

    Click Next.

16. On the Oracle Configuration Manager screen, enter the following:

    • Email Address: Provide the email address for your My Oracle Support account

    • Oracle Support Password: Provide the password for your My Oracle Support account.

    • I wish to receive security updates via My Oracle Support: Click this checkbox.

17. On the Installation Summary screen, ensure that the selections are correct. If they are not, click Back and make the necessary fixes. After ensuring that the selections are correct, click Next.

18. On the Installation Progress screen on UNIX systems, a dialog appears that prompts you to run the oracleRoot.sh script. Open a window and run the script, following the prompts in the window.

    Click Next.

19. On the Configuration Progress screen, multiple configuration assistants are launched in succession; this process can be lengthy.

20. On the Configuration Completed screen, click Finish to exit.

11.3.4.2 Configuring Oracle HTTP Server on WEBHOST1

After installing Oracle HTTP Server on WEBHOST1, add the following lines to the OHS_HOME/instances/ohs_instance1/config/OHS/ohs1/mod_wl_ohs.conf file:

# UCM
<Location /cs>
WebLogicCluster wcchost1:16200,wcchost2:16200
SetHandler weblogic-handler
WLCookieName JSESSIONID

</Location>

<Location /adfAuthentication>
 WebLogicCluster wcchost1:16200,wcchost2:16200
 SetHandler weblogic-handler
 WLCookieName JSESSIONID

</Location> 

# URM
<Location /urm>
WebLogicCluster wcchost1:16250,wcchost2:16250
SetHandler weblogic-handler
WLCookieName JSESSIONID
</Location>

<Location /urm/adfAuthentication>
WebLogicCluster wcchost1:16250,wcchost2:16250
SetHandler weblogic-handler
WLCookieName JSESSIONID

</Location> 

# IBR
<Location /ibr>
WebLogicCluster wcchost1:16300,wcchost2:16300
SetHandler weblogic-handler
WLCookieName JSESSIONID

</Location>

<Location /ibr/adfAuthentication>
WebLogicCluster wcchost1:16300,wcchost2:16300
SetHandler weblogic-handler
WLCookieName JSESSIONID
 
</Location> 

# Imaging Application
<Location /imaging>
    SetHandler weblogic-handler
    WebLogicCluster WCCHOST1VHN1:16000,WCCHOST2VHN1:16000
</Location>
 
# AXF WS Invocation
<Location /axf-ws>
    SetHandler weblogic-handler
    WebLogicCluster WCCHOST1VHN1:16000,WCCHOST2VHN1:16000
</Location>

These lines configure Oracle HTTP Server on WEBHOST1 to route requests to the clustered applications on WCCHOST1 and WCCHOST2.

Note:

The value of WLCookieName is different in earlier software releases. The value was IDCCS_SESSIONID in earlier releases but is JSESSIONID in this release.

After adding these lines, restart Oracle HTTP Server, and then ensure that the applications can be accessed at:

http://WEBHOST1:7777/cs
http://WEBHOST1:7777/urm
http://WEBHOST1:7777/imaging

Note:

More Location tags may need to be added depending on how the applications will be used. For example, WebCenter Content also requires access at /_dav for WebDav access and /idcws for web services access. Consult the product documentation for more details.

11.3.5 Configuring the Load Balancer

Configure the load balancer so that the virtual host (for example, ucm.mycompany.com) routes to the available Oracle HTTP Servers using round-robin load balancing.

You should also configure the load balancer to monitor the HTTP and HTTPS listen ports for each Oracle HTTP Server.

Verify that Oracle WebCenter Content Server can be accessed at http://WEBHOST1:7777/cs.

11.3.6 Installing and Configuring WCCHOST2

This section describes the installation and configuration steps to perform on WCCHOST2.

11.3.6.1 Installing Oracle WebLogic Server on WCCHOST2

To install Oracle WebLogic Server on WCCHOST2, perform the steps in Section 11.3.3.1, "Installing Oracle WebLogic Server on WCCHOST1" on WCCHOST2.

11.3.6.2 Installing WCC on WCCHOST2

To install Oracle WebCenter Content on WCCHOST2, perform the steps in Section 11.3.3.2, "Installing Oracle WebCenter Content on WCCHOST1" on WCCHOST2.

11.3.6.3 Using pack and unpack to Join the Domain on WCCHOST1

Use the pack and unpack commands to enable the WLS_UCM2 managed server on WCCHOST2 to join the Oracle WebCenter Content domain on WCCHOST1.

First, run the pack command on WCCHOST1:

pack -managed=true -domain=/u01/app/oracle/product/WLS/11G/user_projects/domains
/wccdomain -template=wcc_template.jar -template_name="my wcc domain"

After copying the wcc_template.jar file to WCCHOST2, run the unpack command on WCCHOST2:

unpack -domain=/u01/app/oracle/product/WLS/11G/user_projects/domains/wccdomain
-template=wcc_template.jar

11.3.6.4 Start Node Manager and the WLS_UCM2 Server on WCCHOST2

To start Node Manager on WCCHOST2, use this command:

WCCHOST2> MW_HOME/oracle_common/common/bin/setNMProps.sh
WCCHOST2> WL_HOME/wlserver_10.3/server/bin/startNodeManager.sh

Access the Administration Console at http://WCCHOST1:7001/console. In the Administration Console, start the WLS_UCM2 managed server.

11.3.6.5 Start the Managed Servers on WCCHOST2

Access the Administration Console at http://WCCHOST2:7001/console. In the Administration Console, start the WLS_UCM2, WLS_URM2, and WLS_IPM2 managed servers.

11.3.6.6 Configure the WLS_UCM2 Managed Server

Access the WLS_UCM2 configuration page at http://WCCHOST2:16200/cs.

After you log in, the configuration page opens. The WebCenter Content configuration files must be on a shared disk. This example assumes that the shared disk is at /orashare/orcl/ucm.

Set the following values on the configuration page to the values below:

• Content Server Instance Folder: /u01/app/oracle/admin/domainName/ucm_cluster/cs

• Native File Repository Location: /u01/app/oracle/admin/domainName/ucm_cluster/cs/vault

• WebLayout Folder: /u01/app/oracle/admin/domainName/ucm_cluster/cs/weblayout

Verify that the Is new Content Server Instance? check box is not selected.

After making these updates, click Submit and then restart the WLS_UCM2 managed server.

11.3.6.7 Configure the WLS_URM2 Managed Server

Access the WLS_URM2 configuration page at http://WCCHOST2:16250/urm.

After you log in, the configuration page opens. The Records configuration files must be on a shared disk. This example assumes that the shared disk is at /u01/app/oracle/admin/domainName/ucm_cluster.

Set the following values on the configuration page to the values below:

• Content Server Instance Folder: /u01/app/oracle/admin/domainName/ucm_cluster/urm

• Native File Repository Location: /u01/app/oracle/admin/domainName/ucm_cluster/urm/vault

• Web Layout Folder: /u01/app/oracle/admin/domainName/ucm_cluster/urm/weblayout

Verify that the Is new Content Server Instance? check box is not selected.

After making these updates, click Submit and then restart the WLS_URM2 managed server.

11.3.7 Installing and Configuring WEBHOST2

This section describes the installation and configuration steps to perform on WEBHOST2.

11.3.7.1 Installing Oracle HTTP Server on WEBHOST2

This section describes how to install Oracle HTTP Server on WEBHOST2.

1. Ensure that the system, patch, kernel and other requirements are met. These are listed in the Oracle Fusion Middleware Installation Guide for Oracle Web Tier in the Oracle Fusion Middleware documentation library for the platform and version you are using.

2. Ensure that port 7777 is not in use by any service on WEBHOST2 by issuing these commands for the operating system you are using. If a port is not in use, no output is returned from the command.

   On UNIX:

   netstat -an | grep "7777"
   

   On Windows:

   netstat -an | findstr :7777
   

3. If the port is in use (if the command returns output identifying the port), you must free the port.

   On UNIX:

   Remove the entries for port 7777 in the /etc/services file and restart the services, or restart the computer.

   On Windows:

   Stop the component that is using the port.

4. Copy the staticports.ini file from the Disk1/stage/Response directory to a temporary directory.

5. Edit the staticports.ini file that you copied to the temporary directory to assign the following custom ports (uncomment the line where you specify the port number for Oracle HTTP Server):

   # The port for Oracle HTTP server
   Oracle HTTP Server port = 7777
   

6. Start the Oracle Universal Installer for Oracle Fusion Middleware 11g Web Tier Utilities CD installation as follows:

   On UNIX, issue this command: runInstaller.

   On Windows, double-click setup.exe.

   The runInstaller and setup.exe files are in the ../install/platform directory, where platform is a platform such as Linux or Win32.

   This displays the Specify Oracle Inventory screen.

7. On the Specify Inventory Directory screen, enter values for the Oracle Inventory Directory and the Operating System Group Name. For example:

   Specify the Inventory Directory: /u01/app/oraInventory

   Operating System Group Name: oinstall

   A dialog box appears with the following message:

   "Certain actions need to be performed with root privileges before the install can continue. Please execute the script /u01/app/oraInventory/createCentralInventory.sh now from another window and then press "Ok" to continue the install. If you do not have the root privileges and wish to continue the install select the "Continue installation with local inventory" option"

   Log in as root and run the "/u01/app/oraInventory/createCentralInventory.sh"

   This sets the required permissions for the Oracle Inventory Directory and then brings up the Welcome screen.

   Note:

   The Oracle Inventory screen is not shown if an Oracle product was previously installed on the host. If the Oracle Inventory screen is not displayed for this installation, make sure to check and see:

   1. If the /etc/oraInst.loc file exists

   2. If the file exists, the Inventory directory listed is valid

   3. The user performing the installation has write permissions for the Inventory directory

8. On the Welcome screen, click Next.

9. On the Select Installation Type screen, select Install and Configure, and click Next.

10. On the Prerequisite Checks screen, the installer completes the prerequisite check. If any fail, fix them and restart your installation.

    Click Next.

11. On the Specify Installation Location screen:

    • On WEBHOST2, set the Location to:

      /u01/app/oracle/admin
      

    Click Next.

12. On the Configure Components screen:

    • Select Oracle HTTP Server.

    • Select Associate Selected Components with Weblogic Domain.

    Click Next.

13. On the Specify WebLogic Domain screen:

    Enter the location where you installed Oracle WebLogic Server. Note that the Administration Server must be running.

    • Domain Host Name: WCCHOST1

    • Domain Port No: 7001

    • User Name: weblogic

    • Password: ******

    Click Next.

14. On the Specify Component Details screen:

    • Enter the following values for WEBHOST2:

      • Instance Home Location: /u01/app/oracle/admin/ohs_inst2

      • Instance Name: ohs_inst2

      • OHS Component Name: ohs2

    Click Next.

15. On 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 the Oracle HTTP Server port, for example, 7777.

    Click Next.

16. On the Oracle Configuration Manager screen, enter the following:

    • Email Address: Provide the email address for your My Oracle Support account

    • Oracle Support Password: Provide the password for your My Oracle Support account.

    • I wish to receive security updates via My Oracle Support: Click this checkbox.

17. On the Installation Summary screen, ensure that the selections are correct. If they are not, click Back and make the necessary fixes. After ensuring that the selections are correct, click Next.

18. On the Installation Progress screen on UNIX systems, a dialog appears that prompts you to run the oracleRoot.sh script. Open a window and run the script, following the prompts in the window.

    Click Next.

19. On the Configuration Progress screen, multiple configuration assistants are launched in succession; this process can be lengthy.

20. On the Configuration Completed screen, click Finish to exit.

11.3.7.2 Configuring Oracle HTTP Server on WEBHOST2

To configure Oracle HTTP Server on WEBHOST2, follow the instructions in Section 11.3.4.2, "Configuring Oracle HTTP Server on WEBHOST1" on WEBHOST2.

11.3.8 Configuring the Imaging Managed Servers

This section describes how to configure a JMS persistence store for Imaging JMS, how to configure a default persistence store for Transaction Recovery, and how to configure the Imaging Managed Servers with the WebCenter Content Managed Servers. Finally, the steps for configuring Server Migration of the Imaging Managed Servers are described here, also.

This section includes the following topics:

• Section 11.3.8.1, "Configuring a JMS Persistence Store for Imaging JMS"

• Section 11.3.8.2, "Configuring a Default Persistence Store for Transaction Recovery"

• Section 11.3.8.3, "Configuring Imaging with WebCenter Content"

• Section 11.3.8.4, "Configuring BPEL CSF Credentials"

• Section 11.3.8.5, "Configuring the BPEL Connection"

• Section 11.3.8.6, "Setting the Front End HTTP Host and Port"

• Section 11.3.8.7, "Configuring Server Migration for Imaging Instances"

11.3.8.1 Configuring a JMS Persistence Store for Imaging JMS

Configure the location for the JMS persistence stores as a directory that is visible from both nodes. By default, the JMS servers used by Imaging are configured with no persistent store and use WebLogic Server's store (ORACLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/data/store/default). You must change Imaging JMS server persistent store to use a shared base directory as follows:

Note:

See Considerations for Using File Stores on NFS for important information about JMS messages and transaction logs, as well as releasing locks on file stores.

1. Log into the Administration Console.

2. In the Domain Structure window, expand the Services node and then click the Persistence Stores node.

3. In the Change Center, click Lock & Edit.

4. Click New, and then Create File Store.

5. Enter a name (for example 'IPMJMSServer1Store', which enables you identify the service it is created for) and target WLS_IPM1. Enter a directory that is located in shared storage so that it is accessible from both WCCHOST1 and WCCHOST2 (ORACLE_BASE/admin/domain_name/ipm_cluster/jms).

6. Click OK and activate the changes.

7. In the Domain Structure window, expand the Services node and then click the Messaging >JMS Servers node.

8. Click on the IpmJmsServer1 JMS Server (represented as a hyperlink) from the Name column of the table.

9. In the Change Center, click Lock & Edit.

10. In the Persistent Store drop-down list, select IPMJMSServer1Store.

11. Click Save and Activate Changes.

12. Repeat the steps and create IPMJMSServer2Store for IPMJMSServer2.

11.3.8.2 Configuring a Default Persistence Store for Transaction Recovery

Each server has a transaction log which stores information about committed transactions that are coordinated by the server that may not have been completed. The WebLogic Server uses this transaction log for recovery from system fails or network failures. To leverage the migration capability of the Transaction Recovery Service for the servers within a cluster, store the transaction log in a location accessible to the server.

Note:

Preferably, this location should be a dual-ported SCSI disk or on a Storage Area Network (SAN).

To set the location for the default persistence store for WLS_IPM1:

1. Log into the Administration Console.

2. In the Domain Structure window, expand the Environment node and then click the Servers node.

3. Click WLS_IPM1 (represented as a hyperlink) in the Name column of the table.

4. Click the Services tab.

5. In the Change Center, click Lock & Edit.

6. In the Default Store section of the page, enter the path to the folder where the default persistent stores will store its data files. The path directory structure is:

   ORACLE_BASE/admin/domain_name/ipm_cluster_name/tlogs

7. Click Save and activate the changes.

8. Repeat these steps for the WLS_IPM2 server.

   Note:

   To enable migration of the Transaction Recovery Service, specify a location on a persistent storage solution that is available to other servers in the cluster. WCCHOST1 and WCCHOST2 must be able to access this directory, which must exist before you restart the server.

11.3.8.3 Configuring Imaging with WebCenter Content

The Oracle IP/M Cluster should be configured to access the WebCenter Content Cluster.

11.3.8.3.1 Enabling Imaging in UCM

To enable Imaging in Oracle WebCenter Content Server:

1. Log into Oracle WebCenter Content Server at http://WCCHOST1:16200/cs.

2. Open the Administration tray or menu, and choose Admin Server.

3. Click Component Manager.

4. Enable the IpmRepository component.

5. Restart all the managed servers in the UCM cluster.

11.3.8.3.2 Upgrading the Default File Store

Perform these steps to upgrade the default file store in Oracle WebCenter Content Server:

1. Log into Oracle WebCenter Content Server at http://WCCHOST1:16200/cs.

2. Open the Administration tray or menu and choose Providers.

3. Click on the Info link of DefaultFileStore.

4. Click Edit then click Update.

5. Restart all the content servers in the cluster.

11.3.8.3.3 Adding the Imaging Server Listen Addresses to the List of Allowed Hosts in UCM

To add the Imaging Server listen addresses of the WLS_IPM1 and WLS_IPM2 managed servers (WCCHOST1VHN1 and WCCHOST2VHN1, respectively) to the list of allowed hosts in UCM:

1. Edit the file /u01/app/oracle/admin/domainName/ucm_cluster/config/config.cfg and remove or comment out the following line:

   SocketHostAddressSecurityFilter=127.0.0.1|0:0:0:0:0:0:0:1
   

2. Add the following two lines to include the WLS_IPM1 and WLS_IPM2 listen address to the list of addresses that can connect to UCM:

   SocketHostNameSecurityFilter=localhost|localhost.mydomain.com|wcchost1vhn1|wcchost2vhn1
   AlwaysReverseLookupForHost=Yes
   

Restart the UCM servers for the change to take effect.

11.3.8.3.4 Creating a Connection to the UCM System

Perform these steps to create a connection to the UCM system:

1. Log into the WLS_IPM1 imaging console at http://WCCHOST1:16200/ imaging.

2. In the left-hand pane, click Manage Connections, and then Create Content Server Connection.

3. Enter a name and description for the new connection, and then click Next.

4. In the Connection Settings screen, do the following:

   • Ensure that Use Local Content Server is checked.

   • Set the Content Server port to 4444.

   • Add two servers to the Content Server Pool:

     • WCCHOST1:4444

     • WCCHOST2:4444

   Click Next.

5. In the Connection Security screen, leave the default selections for the WebLogic user and then click Next.

6. Review the connection details and click Submit.

11.3.8.4 Configuring BPEL CSF Credentials

When connecting to a BPEL system from Imaging, you must configure the required credential to communicate with the SOA system. To add these credentials:

1. Change directory to the common/bin location under the Oracle WebCenter Content Oracle Home in WCCHOST1 (where your administration servers resides):

   WCCHOST1>cd ORACLE_HOME/common/bin
   

   (ORACLE_HOME is the Oracle WebCenter Content home under MW_HOME/wcc.)

2. Run the Oracle WebLogic Scripting Tool (WLST):

   WCCHOST1>./wlst.sh
   

3. Run connect() and supply the username, password, and administration server URL (t3://WCCHOST1:7001).

   wls:/offline> connect()
   

4. Create a CSF (Credential Store Framework) credential. This credential is the credential that Imaging uses to connect to the BPEL system. It should be a BPEL admin user. CSF credentials are username/password pairs that are keyed by an "alias" and stored inside a named "map" in the CSF. Because of its integration with OWSM web services, Imaging is currently leveraging the standard OWSM CSF map named "oracle.wsm.security". To create a credential, use the createCred WLST command:

   wls:/wcc_domain/serverConfig> createCred(map="oracle.wsm.security", key="basic.credential", user="weblogic", password="password_for_credential")
   

   The "key" in the command is the "alias," which is used for the 'Credential Alias' property of the BPEL connection definition in the Imaging administration user interface (also the Connection.CONNECTION_BPEL_CSFKEY_KEY property in the API). The alias "basic.credential" is used in the example because it is a standard default name used by OWSM and BPEL. However, the alias can be anything as long as it is unique within the map.

5. Run the list credentials command to verify that the credential was created:

   wls:/wcc_domain/serverConfig> listCred(map="oracle.wsm.security", key="basic.credential")
   {map=oracle.wsm.security, key=basic.credential}
   Already in Domain Runtime Tree
   
   [Name : weblogic, Description : null, expiry Date : null]
   PASSWORD: password_for_credential
   

11.3.8.5 Configuring the BPEL Connection

To configure the BPEL connection:

1. Log into the WLS_IPM1 imaging console at http://WCCHOST1VHN1:16000/imaging.

2. In the Left pane, click Manage Connections, then Create Workflow Connection.

3. Click Create BPEL Connection.

4. Enter a BPEL machine name and, optionally, a description.

5. Click Next.

6. In the Connection Settings screen, do the following:

   1. In the provider name field, enter your two SOA server listen addresses separated by a comma: SOAHOST1VHN2, SOAHOST2VHN1

   2. Provide the BPEL port: 8001.

   3. Select the SSL option if the target BPEL system requires it.

   4. Provide the credential alias created earlier in the "Configuring BPEL CSF Credentials" section.

   5. Click the Test Connection button to confirm the connection parameters and see what composites exist on that BPEL machine.

   6. Click Next.

7. Modify the security grants if desired.

8. Click Next then Submit.

11.3.8.6 Setting the Front End HTTP Host and Port

You must set the front end HTTP host and port for the Oracle WebLogic Server Imaging cluster:

1. Log into the Administration Console.

2. In the Change Center, click Lock & Edit.

3. Expand the Environment node in the Domain Structure window.

4. Click Clusters.

5. Select IPM_Cluster.

6. Click the HTTP tab.

7. Set the following values:

   • Frontend Host: wcc.mycompany.com

   • Frontend HTTPS Port: 443

   • Frontend HTTP Port: 80 (if not using SSL)

8. Click Save.

9. Click Activate Changes in the Change Center section of the Administration Console.

10. Restart the servers to make the front end host directive in the cluster take effect.

11.3.8.7 Configuring Server Migration for Imaging Instances

This section describes how to configure server migration for Imaging instances.

11.3.8.7.1 About Configuring Server Migration

The following steps enable server migration for the Imaging managed servers. This enables an Imaging managed server to failover to another node in the case of server or process failure.

To configure server migration for the WebLogic managed servers:

• Step 1: Setting Up a User and Tablespace for the Server Migration Leasing Table

• Step 2: Creating a GridLink or Multi Data Source Using the Oracle WebLogic Administration Console

• Step 3: Editing Node Manager's Properties File

• Step 4: Setting Environment and Superuser Privileges for the wlsifconfig.sh Script

• Step 5: Configuring Server Migration Targets

• Step 6: Testing the Server Migration

11.3.8.7.2 Creating a GridLink or Multi Data Source Using the Oracle WebLogic Administration Console

You create a data source to each of the Oracle RAC database instances during the process of setting up the multi data source, both for these data sources and the global leasing multi data source. When you create a data source:

• Ensure that this is a non-XA data source.

• Use Oracle's Driver (Thin) Version 9.0.1, 9.2.0, 10, 11.

• Data sources do not require support for global transactions. Therefore, do not use any type of distributed transaction emulation/participation algorithm for the data source (do not choose the Supports Global Transactions option, or the Logging Last Resource, Emulate Two-Phase Commit, or One-Phase Commit options of the Supports Global Transactions option), and specify a service name for your database.

• Target these data sources to the cluster(s).

• Make sure the data source's connection pool initial capacity is set to 0 (zero). To do this, select Services, JDBC and then Datasources. In the Datasources screen, click the Datasource Name, click the Connection Pool tab, and enter 0 (zero) in the Initial Capacity field.

• Ensure that an ONS daemon is running on your database servers at all times. You can start the ONS daemon on a database server by running the onsctl command: start

Creating a GridLink Data Source

To create a GridLink Data Source:

1. Log in to the Administration Console.

2. If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.

3. In the Domain Structure tree, expand Services, then select Data Sources.

4. On the Summary of Data Sources page, click New and select GridLink Data Source.

5. Enter the following information:

   1. Enter a logical name for the datasource in the Name field. For example, gridlink

   2. Enter a name for JNDI. For example, jdbc/gridlink.

   3. Click Next.

6. In the Transaction Options page, de-select Supports Global Transactions, and click Next.

7. Select Enter individual listener information and click Next.

8. Enter the following connection properties:

   • Service Name: Enter the service name of the database. For a GridLink data source, you must enter the RAC service name in lower-case letters followed by the domain name example.com. For example, mydbservice.example.com

     Note:

     The Oracle RAC Service name is defined on the database; it is not a fixed name. Oracle recommends that you register/add the RAC service name with the database domain name, for example, example.com.

   • Host Name - The DNS name or IP address of the server that hosts the database. For an Oracle GridLink service-instance connection, this must be the same for each data source in a given multi data source.

   • Port - The port on which the database server listens for connections requests.

   • Database User Name: The database user name. For example, myDataBase.

   • Password: The password. For example, myPassword1.

   • Confirm Password and click Next.

     Tip:

     For more information, see the Oracle Fusion Middleware Administration Console Online Help.

     The console automatically generates the complete JDBC URL. For example:

     jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=left)(PORT=1234))(ADDRESS=(PROTOCOL=TCP)(HOST=right)(PORT=1234))(ADDRESS=(PROTOCOL=TCP)(HOST=center)(PORT=1234)))(CONNECT_DATA=(SERVICE_NAME=myService)))

9. On the Test GridLink Database Connection page, review the connection parameters and click Test All Listeners.

   Oracle WebLogic attempts to create a connection from the Administration Server to the database. Results from the connection test appear at the top of the page. If the test is unsuccessful, correct any configuration errors and retry the test.

   Click Next.

10. In the ONS Client Configuration page, do the following:

    • Select Fan Enabled to subscribe to and process Oracle FAN events.

    • In ONS host and port, enter a comma-separate list of ONS daemon listen addresses and ports for receiving ONS-based FAN events. You can use Single Client Access Name (SCAN) addresses to access FAN notifications.

    • Click Next.

11. On the Test ONS client configuration page, review the connection parameters and click Test All ONS Nodes.

    Click Next.

12. In the Select Targets page, select Dept1_Cluster1 as the target and All Servers in the cluster.

13. Click Finish.

14. Click Activate Changes.

Creating a Multi Data Source

To create a multi data source:

1. Log into the Administration Console using the Admin credentials.

2. In the Domain Structure window, expand the Services node then expand the DataSource node.

3. Click Lock and Edit in the Change Center.

4. Click New then click Multi Data Sources.

5. Enter leasing as the name. Enter jdbc/leasing as the JNDI name.

6. Select Failover as algorithm (default). Click Next.

7. Select the target cluster(s). Click Next.

8. Select non-XA driver (the default). Click Next.

9. Click Create New Data Source.

10. Enter leasing-rac0 as the name. Enter jdbc/leasing-rac0 as the JNDI name. Enter oracle as the database type. For the driver type, select Oracle Driver (Thin) for RAC server-Instance connection Version 10,11.

    Note:

    When you create multi data sources for the leasing table, enter names in the format <MultiDS>-rac0, <MultiDS>-rac1, and so on.

11. Click Next.

12. Deselect Supports Global Transactions. Click Next.

13. Enter the service name, database name (that is, the RAC Node instance name such as racdb1, racdb2), host port, and password for your leasing schema.

14. Click Next.

15. Click Test Configuration and verify that the connection works. Click Next.

16. Target the data source to the cluster(s).

17. Select the data source and add it to the right screen.

18. Click Create a New Data Source for the second instance of your Oracle RAC database, target it to the cluster(s), repeating the steps for the second instance of your Oracle RAC database.

19. Add the second data source to your multi data source.

20. Save and click Activate Changes.

11.3.8.7.3 Testing the Server Migration

The final step is to test the server migration. Perform these steps to verify that server migration is working properly:

From WCCHOST1:

1. Stop the WLS_IPM1 managed server. To do this, run this command:

   WCCHOST1> kill -9 pid
   

   where pid specifies the process ID of the managed server. You can identify the pid in the node by running this command:

   WCCHOST1> ps -ef | grep WLS_IPM1
   

   Note:

   For Windows, the Managed Server can be terminated by using the taskkill command. For example:

   taskkill /f /pid <pid>
   

   Where <pid> is the process Id of the Managed Server.

   To determine the process Id of the Managed Server run the following command and identify the pid of the WLS_IPMn Managed Server.

   MW_HOME\jrockit_160_20_D1.0.1-2124\bin\jps -l -v
   

2. Watch the Node Manager console. You should see a message indicating that WLS_IPM1's floating IP has been disabled.

3. Wait for Node Manager to try a second restart of WLS_IPM1. It waits for a fence period of 30 seconds before trying this restart.

4. Once Node Manager restarts the server, stop it again. Node Manager should now log a message indicating that the server will not be restarted again locally.

From WCCHOST2:

1. Watch the local Node Manager console. After 30 seconds since the last try to restart WLS_IPM1 on WCCHOST1, Node Manager on WCCHOST2 should prompt that the floating IP for WLS_IPM1 is being brought up and that the server is being restarted in this node.

2. Access the soa-infra console in the same IP.

Verification From the Administration Console

The Migration Status table provides information on the migration status.

To verify migration in the Administration Console:

Note:

After a server migrates, to fail it back to its original node/machine, stop the managed server from the Administration Console and then start it again. The appropriate Node Manager starts the managed server on the machine it was originally assigned to.

11.3.9 Configuration of Inbound Refinery Instances

This section provides configuration information for Inbound Refinery instances.

This section includes the following topics:

• Section 11.3.9.1, "Inbound Refinery and Inbound Refinery Cluster Concepts"

• Section 11.3.9.2, "Content Server and Inbound Refinery Configuration"

• Section 11.3.9.3, "Inbound Refinery Instances and Oracle HTTP Server"

11.3.9.1 Inbound Refinery and Inbound Refinery Cluster Concepts

Inbound Refinery instances are not clusterable; they operate completely independently. Several Inbound Refinery instances can be added to the same WebLogic domain, but the following restrictions should be observed:

• No more than one Inbound Refinery per domain per machine can be installed.

• Inbound Refinery instances that are on separate machines must ensure that their configuration is all local and not on shared disk.

The local content requirement is important if you install Inbound Refinery instances on machines that have existing Content Server installations. While configuration in a Content Server cluster must be shared, configuration information of Inbound Refinery instances must not be shared with other Inbound Refinery instances.

11.3.9.2 Content Server and Inbound Refinery Configuration

You can configure a Content Server with one or more Inbound Refinery instances and the same Inbound Refinery can act as a provider to one or more Content Servers. to configure Inbound Refinery instances, see Oracle Fusion Middleware Administrator's Guide for Conversion.

It is recommended that all of the Inbound Refineries which were created in the preceding Configuration be added to the UCM or URM Cluster. This will create a many-to-many relationship in which all members of the UCM/URM cluster can request conversions from any member of the Inbound Refinery cluster.

Inbound Refinery instances can be installed in their own domain or as an extension of an existing domain.

11.3.9.3 Inbound Refinery Instances and Oracle HTTP Server

An Inbound Refinery only needs to be accessed once through HTTP to initialize its configuration. This can be done directly, at the Managed Server's listen address. Do not place an Inbound Refinery behind an HTTP Server.

All subsequent access to an Inbound Refinery is through the socket listener.