1. Disaster Recovery Guide
  2. Recommendations for Oracle Fusion Middleware Components

2 Recommendations for Oracle Fusion Middleware Components

Learn about the disaster protection requirements for Oracle Fusion Middleware components in different Oracle product suites and recommendations for synchronizing those components.

Oracle Fusion Middleware Disaster Recovery uses storage replication to synchronize the middle tier content, and uses Oracle Data Guard to synchronize data in Oracle databases and custom application databases that are included in your topology.

Note:

Certain artifacts such as Oracle Inventory, the beahomelist, the oratab and the oraInst.loc files are common across all Oracle product deployments. These artifacts change very rarely and need not be part of the regular storage replication and synchronization activity. Oracle recommends that you place Oracle Inventory, the beahomelist, the oratab, and the oraInst.loc files on the local disk of your systems. These artifacts should be manually updated upon creation, as well as upon applying patch updates. If required by your environment, these artifacts can also be on shared storage. For information about managing Oracle Inventory, see Managing Oracle Inventory.

For related information, see the following documents:

This chapter includes the following sections:

  • Recommendations for Oracle WebLogic Server
    Oracle WebLogic Server is a scalable, enterprise-ready Java Platform, Enterprise Edition (Java EE) application server.
  • Recommendations for Oracle SOA Suite
    Oracle SOA Suite is an Oracle Fusion Middleware component that provides a complete set of service infrastructure components for designing, deploying, and managing SOA composite applications.
  • Recommendations for Oracle Business Intelligence Suite
    Oracle Business Intelligence Suite (Oracle BI) is a portfolio of technology and applications that provides the industry's first integrated, end-to-end Enterprise Performance Management System, including Oracle Business Intelligence foundation and tools as well as financial performance management applications, operational Oracle Business Intelligence applications, and data warehousing.
  • Recommendations for Oracle WebCenter Portal
    Oracle WebCenter Portal is an Oracle Fusion Middleware component that provides a personalized, secure, and efficient way of presenting and consuming information, collaborating with others, and interacting with applications in the context of business processes.
  • Recommendations for Oracle WebCenter Content
    Oracle WebCenter Content is an integrated suite of products designed to manage enterprise content.

2.1 Recommendations for Oracle WebLogic Server

Oracle WebLogic Server is a scalable, enterprise-ready Java Platform, Enterprise Edition (Java EE) application server.

The Oracle WebLogic Server infrastructure supports the deployment of many types of distributed applications, and is an ideal foundation for building applications based on the Oracle Fusion Middleware product suite.

The following artifacts and considerations apply to all WebLogic Server components, along with the component-specific recommendations.

  • Artifacts on the File System

    Oracle home: The Oracle home consists of a WebLogic home that has the WebLogic Server binary files.

    Domain home: The domain home contains the configuration data and the applications for the WebLogic domain.

  • Network Artifacts

    Oracle recommends that you use a virtual alias (instead of physical host names) as the listen address for both Oracle WebLogic Administration server and the Managed Servers. As long as this alias can be resolved on both the production and standby sites, there is no need to update this value after a Disaster Recovery operation.

    If your environment requires whole server migration to be configured, then use the virtual host name as the listen address of the Managed Servers that are configured for whole server migration. To avoid manually updating the listen address after a Disaster Recovery operation, ensure that the host name can be resolved on both the primary and standby sites.

    Configure the load balancer virtual host, which is used for accessing the WebLogic Server applications, on both the production and standby sites.

The rest of this section describes Disaster Recovery recommendations for the following Oracle WebLogic Server components:

Parent topic: Recommendations for Oracle Fusion Middleware Components

2.1.1 Recommendations for Oracle WebLogic Server Java Message Service (JMS) and Transaction Logs (T-Logs)

Learn about the Oracle WebLogic Server JMS and T-Log artifacts and what Oracle recommends for disaster recovery.

  • Artifacts on the File System:

    File-based persistent stores: The file store location for the JMS and T-Log when you use a file-based persistent store.

  • Artifacts in the Database:

    The schema that contains the JMS messages, when you use database-based persistent stores. The schema that contains Logging Last Resource (LLR) transaction log records for WebLogic applications that leverage the JDBC LLR option.

    When automatic whole server migration is configured, the required leasing table is in the database.

  • Special Considerations:

    • Messages are lost if they were enqueued after the system restore point time but never processed. Message duplicates are generated for messages enqueued before the restore point time, but dequeued and acknowledged or committed (processed) after this time.

    • If the persistent store is a custom store that is dedicated to JMS use, then you can delete the entire store.

    • Restoring different parts of the system to different points in time can lead to inconsistent data. This can occur when the message store, transaction log, or application database are synchronized differently. For example, a message may reference a database row that does not exist, or the reverse. This may delete unprocessed messages in addition to duplicate messages.

    • If the store is not dedicated to JMS use, then use the Oracle WebLogic Server JMS message management administrative tooling. This tooling can perform import, export, move, and delete operations from the Administration Console, MBeans, and WebLogic Scripting Tools (WLST).

    • When applications use both queues and topics, ensure that you manipulate both the queue and topic subscriptions.

  • Synchronization Recommendations:

    • If JMS data is critical, then synchronize transaction log data and JMS data in real time by using synchronous replication. Using synchronous replication may have performance implications.

    • If data consistency between tiers is important, then ensure that the database and application tiers are replicated at the same time. This helps ensure that the different tiers recover to the same exact point in time.

    • Use Oracle Data Guard to replicate the primary site and standby site when you use database-based persistent stores.

    • When you use a storage device that does not support block-level snapshot capabilities, shut down the JMS server to create a consistent backup. This ensures that the persistence store is not being written to while the copy operation is being performed. In a clustered environment, shut down one server at a time, back it up, and restart it. You also can create a script to perform these operations by using WLST.

  • Recovery Recommendations:

    Recover the database schema that contains the persistent stores for the Administration Server and the Managed Servers in the WLS domain to the most recent point in time.

    Also, use the following recovery recommendations to avoid duplicate messages.

Avoiding Duplicate Messages

Perform the following procedure before recovery to filter messages in the JMS queue after persistent-store recovery, to avoid processing duplicate messages:

Note:

Do not drain and discard messages without being certain that the messages contain no data that must be preserved. The recovered messages may include unprocessed messages with important application data, in addition to duplicate messages that have already been processed.

  1. Sign in to the Oracle WebLogic Server Administration Console.

  2. Before recovery, configure JMS server to pause Production, Insertion, and Consumption operations at Startup. This ensures that no new messages are produced or inserted into the destination or consumed from the destination before you drain stale messages. To do this:

    1. Expand Services, then Messaging, and then JMS Servers.

    2. On the Summary of JMS Servers page, click the JMS server that you want to configure for message pausing.

    3. On the Configuration: General page, click Advanced to define the message pausing options. Select Insertion Paused At Startup, Production Paused At Startup, and Consumption Paused At Startup.

    4. Click Save.

    5. To activate these changes, in the Change Center of the Administration Console, click Activate Changes.

Use the following procedure after recovery:

  1. After you recover the persistent store, start the Managed Servers.

  2. Drain the stale messages from JMS destinations by following these steps:

    1. Expand Services, then Messaging, and then JMS Modules.

    2. Select a JMS module, and then select a destination.

    3. Select Monitoring, and then click Show Messages.

    4. Click Delete All.

Resume operations by following the instructions listed in step 2.

Parent topic: Recommendations for Oracle WebLogic Server

2.1.2 Recommendations for Oracle Platform Security Services

Learn about the Oracle Platform Security Services artifacts and what Oracle recommends for disaster recovery.

  • Artifacts in the Database:

    Oracle Platform Security Services have database dependencies.

  • Synchronization Recommendations:

    You must manually synchronize the application tier with the standby site after you make configuration changes and applying patches.

    You should configure Oracle Data Guard for the Oracle database metadata repositories.

    When the application tier synchronization is initiated on the storage, Oracle recommends that you synchronize the standby database. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database. See Synchronizing Databases Manually and Applying Redo Data to Physical Standby Databases.

  • Recovery Recommendations:

    Recover the Administration Server and the Managed Servers in the WebLogic Server domain.

Parent topic: Recommendations for Oracle WebLogic Server

2.2 Recommendations for Oracle SOA Suite

Oracle SOA Suite is an Oracle Fusion Middleware component that provides a complete set of service infrastructure components for designing, deploying, and managing SOA composite applications.

Oracle SOA Suite enables services to be created, managed, and orchestrated into SOA composite applications that combine multiple technology components.

A SOA composite application consists of:

  • Service components: Service components are the basic building blocks of SOA composite applications. Service components implement part of the overall business logic of the SOA composite application. Oracle BPEL Process Manager, Oracle Mediator, Oracle Human Workflow, and Business Rules are examples of service components.

  • Binding components: Binding components connect SOA composite applications to external services, applications, and technologies. Binding components are organized into two groups:

    • Services: Provide the outside world with an entry point to the SOA composite application. The WSDL file of the service advertises its capabilities to external applications. The service bindings define how a SOA composite service can be invoked. For example, through SOAP.

    • References: Enable messages to be sent from the SOA composite application to external services. For example, the same functionality that partner links provide for BPEL processes, but at the higher SOA composite application level.

Note:

In older Oracle SOA Suite releases, such as 11g, the soa-infra and service-engine configuration files were stored in local or shared storage files as part of the domain configuration. Starting with Oracle SOA Suite 12c R1, those files reside in the metadata repository database. Thus, soa-infra and service-engine configuration changes are now immediately propagated across a cluster.

The Disaster Recovery recommendations for Oracle SOA Suite assume that you are using Oracle SOA Suite 12c R2 (12.2.1) release.

Oracle SOA Suite artifacts are stored on the local or shared file system as well as in the metadata repositories. Composite artifacts are stored in the metadata repository, and binary files and domain-related configuration files are stored on a local or shared file system.

Common Artifacts and Considerations for All Oracle SOA Suite Components

The following artifacts and considerations apply to all the Oracle SOA Suite components, along with the component-specific considerations.

Artifacts on the File System

Oracle home: The Oracle home consists of a WebLogic home that has the WebLogic Server binary files and an Oracle home that contains the Oracle SOA Suite binary files.

Oracle Common Home: This is Oracle home that contains the binary and library files required for the Oracle Enterprise Manager Fusion Middleware Control and Java Required Files (JRF).

Domain home: The domain home contains the configuration data and SOA composites for the SOA domain.

Network Artifacts

Oracle recommends that you use virtual host name as the listen address for both the Oracle WebLogic Administration Server and Managed Server. As long as this host name can be resolved on both the production and standby sites, there is no need to update this value after a Disaster Recovery operation. See Oracle Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite for instructions for updating an IP address to a virtual host name.

The load balancer virtual hosts required for accessing the Oracle SOA Suite components should be configured on both the production and standby sites.

Artifacts in the Database

Oracle SOA Suite schemas, Service Infrastructure and Service Engine configurations, and composite definitions are stored in the Oracle SOA Suite database and metadata repository.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after you make changes in the domain-related configuration, deploy composites, and apply patches.

You should configure Oracle Data Guard for the Oracle SOA Suite database and metadata repository.

When the application tier synchronization is initiated on the storage, Oracle recommends that you synchronize the standby database. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database. See Synchronizing Databases Manually and Applying Redo Data to Physical Standby Databases.

Recovery Recommendations

The database must be recovered to the most recent point in time to ensure that the latest composite definitions and in-flight instances are restored.

In-flight instances require matching the composite definition to continue processing. For this reason, the metadata repository (where composite definitions are stored) and Oracle SOA Suite database (where the process state is maintained) must be recovered to the same point in time.

In redeployed composites, a database recovery ensures consistency between the dehydrated in-flight processes and their corresponding definition because the process definition is stored in database repository where dehydrated instances are stored.

The following sections describe Disaster Recovery recommendations for Oracle SOA Suite components:

Parent topic: Recommendations for Oracle Fusion Middleware Components

2.2.1 Recommendations for Oracle SOA Service Infrastructure

Oracle SOA Service Infrastructure is a Java EE application that provides the foundation services for running Oracle SOA Suite.

This Java EE application is a runtime engine that is automatically deployed when Oracle SOA Suite is installed. You deploy composites (the basic artifacts in a Service Component Architecture) to the Oracle SOA Infrastructure and it provides the required services for the composites to run. Oracle SOA Infrastructure provides deployment, wiring, and thread management services for the composites. These services sustain the lifecycle and runtime operations of the composite.

This section describes various Oracle SOA Service Infrastructure artifacts and provides recommendations for disaster recovery.

Artifacts in the Database

Composite definition and configuration files are stored in the MDS repository. The composite instance state persistence is stored in the Oracle SOA Service Infrastructure database.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after you make changes in the domain-related configuration, deploy composites, and apply patches.

You should configure Oracle Data Guard for the Oracle SOA Suite database and metadata repository.

When the application tier synchronization is initiated on the storage, Oracle recommends that you synchronize the standby database. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

The database must be recovered to the most recent point in time to ensure that the latest composite definitions and in-flight instances are restored.

Parent topic: Recommendations for Oracle SOA Suite

2.2.2 Recommendations for Oracle BPEL Process Manager

The Oracle BPEL Process engine is the service engine running in an Oracle SOA Service Infrastructure that allows the execution of BPEL processes.

A BPEL process provides the standard for assembling a set of discrete services into an end-to-end process flow, and developing synchronous and asynchronous services into end-to-end BPEL process flows. It provides process orchestration and storage of long-running, asynchronous processes.

This section describes the various Oracle BPEL Process Manager artifacts and provides recommendations for disaster recovery.

Artifacts in the Database

Process definition and configuration files are stored in the MDS repository. The BPEL process state persistence is stored in the Oracle SOA Suite database.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after you make domain-related configuration changes and apply patches.

You should configure Oracle Data Guard for the Oracle SOA Suite database and metadata repository.

When the application tier synchronization is initiated on the storage, Oracle recommends that you synchronize the standby database. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

The database must be recovered to the most recent point in time to ensure that the latest process definitions and in-flight instances are restored. Idempotent Oracle BPEL Process Manager processes are recommended, because no cleanup is required after you perform a Disaster Recovery operation. If non-idempotent Oracle BPEL Process Manager processes are used, then processes must be cleaned up from the dehydration store after you perform Disaster Recovery operation, especially when a process is in flight.

Parent topic: Recommendations for Oracle SOA Suite

2.2.3 Recommendations for Oracle Mediator

Oracle Mediator is a service engine within the Oracle SOA Service Infrastructure that provides the framework to mediate between providers and consumers of services and events.

Oracle Mediator runs in place with the SOA Service Infrastructure Java EE application.

This section describes various Oracle Mediator artifacts and provides recommendations for disaster recovery.

Artifacts in the Database

The Mediator service engine stores messages in the database for asynchronous routing for parallel routing rules. The Mediator component instance state and audit details are also stored in the database.

The metadata repository stores the Mediator component definition as part of the composite definition.

Note:

Sequential routing rules do not persist their messages into the database as part of the execution.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after you make changes in the domain-related configuration and apply patches.

You should configure Oracle Data Guard for the Oracle SOA Suite database and metadata repository.

When the application tier synchronization is initiated on the storage, Oracle recommends that you synchronize the standby database . This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

The database must be recovered to the most recent point in time, along with the Administration Server and the Managed Server running the SOA application.

Parent topic: Recommendations for Oracle SOA Suite

2.2.4 Recommendations for Oracle Human Workflow

Oracle Human Workflow is a service engine running in the Oracle SOA Service Infrastructure that allows the execution of interactive human-driven processes and the human interaction support such as approvals, rejects, and reassign actions.

The Human Workflow service consists of several services that handle various aspects of human interaction with a business process.

This section describes the various Oracle Human Workflow artifacts and provides recommendations for disaster recovery.

Artifacts in the Database

Human workflow instance data and other worklist data such as vacation rules, group rules, flex field mappings, and view definitions are stored in the database.

The metadata repository is used to store shared human workflow service definitions and schemas that are used by SOA composites.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after you make changes in the domain configuration and apply patches.

You should configure Oracle Data Guard for the Oracle SOA Suite database and metadata repository.

When the application tier synchronization is initiated on the storage, Oracle recommends that you synchronize the standby database . This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

The database must be recovered to the most recent point in time, along with the Managed Server running the SOA application. The Oracle Human Workflow engine uses Oracle User Messaging Service to send and receive notifications. See Recommendations for Oracle User Messaging Service for details about Oracle User Messaging Service.

Parent topic: Recommendations for Oracle SOA Suite

2.2.5 Recommendations for Oracle B2B

Oracle B2B connects SOA composite applications to external services, applications, and technologies, and offers a multi-protocol gateway that supports industry-recognized business-to-business (B2B) standards.

Oracle B2B extends Oracle SOA Suite with business protocol standards, such as electronic data interchange (EDI), ebXML, HL7, and RosettaNet. Oracle B2B is implemented as a binding component within the SOA Service Infrastructure.

This section describes the various Oracle B2B artifacts and provides recommendations for disaster recovery.

Artifacts on the File System

JMS Store: The volume that contains the file-based JMS persistent store. Table 2-1 shows the JMS queues that Oracle B2B uses internally.

Table 2-1 JMS Queues Used by Oracle B2B

JMS Artifact Name Type JNDI Name

dist_B2BEventQueue_auto

Distributed queue

jms/b2b/B2BEventQueue

dist_B2B_IN_QUEUE_auto

Distributed queue

jms/b2b/B2B_IN_QUEUE

dist_B2B_OUT_QUEUE_auto

Distributed queue

jms/b2b/B2B_OUT_QUEUE

dist_B2BBroadcastTopic_auto

Distributed topic

jms/b2b/B2BBroadcastTopic

Artifacts in the Database

Oracle B2B message and message state persistence are stored in the Oracle SOA Suite database along with the partners, documents, and channels definitions. The metadata repository is used for storing Oracle B2B metadata.

Special Considerations

If these adapters are used, the external FTP servers and email servers should be available on the standby site .

Synchronization Recommendations

For information about Oracle B2B JMS queue synchronization and recovery, see Recommendations for Oracle WebLogic Server Java Message Service (JMS) and Transaction Logs (T-Logs).

The application tier must be manually synchronized with the standby site after you make changes in the domain-related configuration and apply patches.

You should configure Oracle Data Guard for the Oracle SOA Suite database and metadata repository.

When the application tier synchronization is initiated on the storage, Oracle recommends that you synchronize the standby database. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

The database must be recovered to the most recent point in time, along with the Managed Server running the SOA application. Oracle B2B stores state information within JMS queues and the SOA runtime database, so recovering the database and the Managed Server ensures that the application runs normally.

Parent topic: Recommendations for Oracle SOA Suite

2.2.6 Recommendations for Oracle Web Services Manager

Oracle Web Services Manager (Oracle WSM) provides a policy framework to manage and secure web services consistently across your organization. Oracle Web Services Manager consists of the Policy Manager and the Agent.

Oracle WSM provides capabilities to build, enforce, execute, and monitor web services policies including security, Web Services Reliable Messaging, Message Transmission Optimization Mechanism, and addressing policies.

The Policy Manager reads and writes security and management policies, including predefined and custom policies from the MDS repository. The Policy Manager is a stateless Java EE application. It exposes its capabilities through stateless session beans. Although the Policy Manager does not cache any data, the underlying MDS infrastructure does.

The Agent is responsible for policy enforcement, execution, gathering of runtime statistics. The agent is available on all Oracle Fusion Middleware Managed Servers and is configured on the same server as the application it protects. The agent consists of two pieces: the Policy Access Point (PAP) and the Policy Interceptor.

This section describes various Oracle Web Services Manager artifacts and provides recommendations for disaster recovery.

Artifacts in the Database

The MDS repository is used for storing the policies.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after you make changes in the domain-related configuration and apply patches.

You should configure Oracle Data Guard for Oracle database metadata repositories.

When the application tier synchronization is initiated on the storage, Oracle recommends that you synchronize the standby database . This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then manually synchronize the standby database.

Recovery Recommendations

The database must be recovered to the most recent point in time, along with the Managed Server running the SOA application. All policies are stored in the MDS repository, so recovering the database and the Managed Server ensures that the application runs normally.

Parent topic: Recommendations for Oracle SOA Suite

2.2.7 Recommendations for Oracle User Messaging Service

Oracle User Messaging Service enables two-way communication between users and deployed applications and it supports a variety of channels, such as email, IM, SMS, and text-to-voice messages.

Oracle User Messaging Service is integrated with Oracle Fusion Middleware components such as Oracle BPEL Process Manager, Oracle Human Workflow, Oracle Business Activity Monitoring (BAM), and Oracle WebCenter Portal. It is typically deployed with Oracle User, along with Oracle SOA Service Infrastructure. Oracle User Messaging Service is made up of UMS Server, UMS Drivers, and UMS Client applications.

This section describes various Oracle User Messaging Service artifacts and provides recommendations for disaster recovery.

Artifacts on the File System

JMS Store: The volume that contains the file-based JMS persistent store. Table 2-2 shows the JMS resources that Oracle User Messaging Service uses.

Table 2-2 JMS Resources Used by Oracle User Messaging Service

JMS Artifact Name Type JNDI Name

OraSDPMAppDefRcvQ1_auto

Distributed queue

OraSDPM/Queues/OraSDPMAppDefRcvQ1

OraSDPMDriverDefSndQ1_auto

Distributed queue

OraSDPM/Queues/OraSDPMDriverDefSndQ1

OraSDPMEngineCmdQ_auto

Distributed queue

OraSDPM/Queues/OraSDPMEngineCmdQ

OraSDPMEngineRcvQ1_auto

Distributed queue

OraSDPM/Queues/OraSDPMEngineRcvQ1

OraSDPMEngineSndQ1_auto

Distributed queue

OraSDPM/Queues/OraSDPMEngineSndQ1

OraSDPMWSRcvQ1_auto

Distributed queue

OraSDPM/Queues/OraSDPMWSRcvQ1

Artifacts in the Database

Oracle User Messaging Service depends on an external database repository to maintain the message and configuration state.

Special Considerations

Oracle User Messaging Service uses JMS to deliver messages among messaging applications. By default, it is configured to use a file-based persistent JMS store; therefore, it depends on the storage device where those files are located.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after you make changes in the configuration, deploy additional Oracle User Messaging Service drivers, and apply patches.

You should configure Oracle Data Guard for Oracle database metadata repositories.

When the application tier synchronization is initiated on the storage, Oracle recommends that you synchronize the standby database. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

The database must be recovered to the most recent point in time, along with the Managed Server running the usermessagingserver application. Oracle User Messaging Service maintains the message and configuration state in an external database repository along with persisting messages in JMS queues, so recovering the database and the Managed Server ensures that the application functions without any issues. For recommendations on synchronizing JMS data, see Synchronization Recommendations in Recommendations for Oracle WebLogic Server Java Message Service (JMS) and Transaction Logs (T-Logs).

Parent topic: Recommendations for Oracle SOA Suite

2.2.8 Recommendations for Oracle Java EE Connector Architecture (JCA) Adapters

Oracle JCA Adapters are JCA binding components that allow the Service Infrastructure to communicate by using different protocols.

Oracle JCA Adapters are deployed as a JCA resource (RAR) and are not part of the Oracle SOA Service Infrastructure.

The Oracle JCA Adapters include:

  • Oracle Technology Adapters

  • Legacy Adapters

  • Packaged-Application Adapters

  • Oracle Adapter for Oracle Applications

See the Oracle Fusion Middleware Understanding Technology Adapters for additional information about the types of Oracle JCA Adapters.

This section describes the various Oracle JCA Adapter artifacts and provides recommendations for disaster recovery.

Artifacts on the File System

Certain adapters use local or shared-storage files, for example:

  • JMS adapters utilizing WebLogic JMS with file-based persistence store: The persistence store must be synchronized with the standby site to resume processing after failover.

  • Inbound and outbound files from either File or FTP adapters: The relevant files must be synchronized with the standby site to resume processing after failover.

Adapter configuration is maintained in the weblogic-ra.xml deployment descriptor for the ear JCA resource (RAR). When the file is created, the location of each weblogic-ra.xml file is determined by the administrator, and must be replicated to the standby site.

Artifacts in the Database

Adapter artifacts are generated at design time as part of the composite project. These artifacts are stored with the rest of the composite definition in the metadata repository.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after you make changes in the domain-related configuration, that is adapter configuration changes, and apply patches.

You should configure Oracle Data Guard for the Oracle SOA Suite database and metadata repository.

When the application tier synchronization is initiated on the storage, Oracle recommends that you synchronize the standby database . This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then manually synchronize the standby database.

Recovery Recommendations

The database must be recovered to the most recent point in time, along with the Managed Server running the JCA Adapters and the Administration Server.

Parent topic: Recommendations for Oracle SOA Suite

2.2.9 Recommendations for Oracle Business Activity Monitoring

Oracle Business Activity Monitoring (Oracle BAM) provides the tools for monitoring business services and processes in the enterprise and allows quick correlation of market indicators to the actual and changing business processes.

Oracle BAM provides the necessary tools and runtime services to create dashboards that display real-time data inflow and define rules to send alerts under specified conditions.

This section describes various Oracle BAM artifacts and provides recommendations for disaster recovery.

Artifacts in the Database

Oracle BAM data and report metadata is stored in the Oracle BAM database that contains Oracle BAM schemas.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after you make domain-related configuration changes and apply patches.

You should configure Oracle Data Guard for the Oracle SOA Suite database that contains the Oracle BAM schemas and the metadata repository.

When the application tier synchronization is initiated on the storage, Oracle recommends that you synchronize the standby database . This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

The database must be recovered to the most recent point in time, along with the Managed Server running Oracle BAM.

Parent topic: Recommendations for Oracle SOA Suite

2.2.10 Recommendations for Oracle Business Process Management

The Oracle Business Process Management ( Oracle BPM) Suite provides an integrated environment for developing, administering, and using business applications centered around business processes.

Oracle BPM Suite provides a seamless integration of all stages of the application development life cycle from design-time and implementation to runtime and application management.

The Oracle BPM Suite is layered on the Oracle SOA Suite and shares many of the same product components, including:

  • Oracle Business Rules

  • Oracle Human Workflow

  • Oracle adapter framework for integration

  • SOA Composite Architecture

This section describes the various Oracle BPM artifacts and provides recommendations for disaster recovery.

Artifacts on the File System

BPM JMS Persistent Store (BPMJMSFileStore_auto): The file-based JMS persistent store. The persistence store must be synchronized with the standby site to resume processing after failover.

Artifacts in the Database

Process definition, deployed applications, and configuration files are stored in the Oracle Metadata Services (MDS) repository. Oracle BPM also uses a separate MDS partition to share projects and project templates between process analysts and process developers.

Synchronization Recommendations

The application tier must be manually synchronized with the standby site after you make changes in the domain-related configuration and apply patches.

You should configure Oracle Data Guard for the Oracle SOA Suite database and metadata repository.

When the application tier synchronization is initiated on the storage, the standby database is also updated to the same point in time. This is recommended if a snapshot Standby database is used.

Recovery Recommendations

The database must be recovered to the most recent point in time, along with the Managed Server running the SOA application.

Parent topic: Recommendations for Oracle SOA Suite

2.3 Recommendations for Oracle Business Intelligence Suite

Oracle Business Intelligence Suite (Oracle BI) is a portfolio of technology and applications that provides the industry's first integrated, end-to-end Enterprise Performance Management System, including Oracle Business Intelligence foundation and tools as well as financial performance management applications, operational Oracle Business Intelligence applications, and data warehousing.

Oracle BI has the following components:

  • Administration Server: runs in a dedicated Java virtual system and is used for administering the system. When you use two or more servers for High Availability, the Administration Server exists on both hosts but is only active on one host.
  • Managed Server: runs in a dedicated Java virtual system and provides the runtime environment for the Java-based services and applications.
  • Node Manager: provides management services for the Administration Server, Managed Servers, and the System Components.
  • System Components: server processes that provide the core services to Oracle BI. Oracle BI components are as follows:

    • BI Server

    • BI Scheduler

    • BI Java Host

    • BI Preservation Server

    • Cluster Controller

Other domain contents includes the configuration file, WebLogic Server Tool commands, security, and connection information that are required to run Oracle BI.

Oracle BI artifacts are stored on the local or shared file system as well as in the metadata repositories. Composite artifacts are stored in the metadata repository, and binary files and domain-related configuration files are stored on a local or shared file system.

For more information about Oracle BI Architecture, see Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Business Intelligence.

This section contains the following recommendations:

Parent topic: Recommendations for Oracle Fusion Middleware Components

2.3.1 Common Recommendations for All Oracle Business Intelligence Suite Components

Learn about what Oracle recommends for all Oracle Business Intelligence Suite (Oracle BI) components.

The following artifacts and considerations apply to all Oracle BI components, in addition to the component specific considerations.

Artifacts on the File System

Oracle home—The Oracle home consists of a WebLogic home that has the WebLogic Server binary files and an Oracle home that contains the Oracle BI Suite binary files.

Domain home—The domain home contains the WebLogic Administration Server and WebLogic Managed Server configuration data, logs, and Oracle BI applications for the domain.

Singleton Data Directory (SDD)–A directory that contains the metadata and other cross-cluster files. There is exactly one SDD for each domain. The SDD path (by default, DOMAIN_HOME/bidata) is defined in the file bi-environment.xml which is located at theDOMAIN_HOME/config/fmwconfig/bienv/core/bi-environment.xml directory.

Network Artifacts

Oracle recommends that you use the virtual host name as the listen address for both the Oracle WebLogic Administration Server and the WebLogic Managed Server. As long as this host name can be resolved on both the production and standby sites, there is no need to update this value after a Disaster Recovery operation.

You should configure the load balancer virtual host, that is required for accessing the Oracle BI components, on both the production and standby sites.

Artifacts in the Database

The Oracle Business Intelligence schemas are located in the Oracle Business Intelligence database.

Schema-based metadata–This is nondesign-time metadata that is stored in database schemas, including schemas for the Scheduler, usage statistics, event polling, repository files, and the Oracle BI Presentation Catalog.

Synchronization Recommendations

The directory tier must be manually synchronized with the standby site after you change the domain configuration, or deploy composites, or apply patches.

You should configure Oracle Data Guard for the Oracle BI database and metadata repository.

Oracle recommends synchronizing the standby database, when the application tier synchronization is initiated on the storage. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database. See Applying Redo Data to Physical Standby Databases in Oracle Data Guard Concepts and Administration.

Recovery Recommendations

The database that contains the Oracle Business Intelligence schemas must be recovered to the most recent point in time, along with the Identity Management component in question.

Parent topic: Recommendations for Oracle Business Intelligence Suite

2.3.2 Recommendations for Oracle Business Intelligence Enterprise Edition (EE)

Oracle Business Intelligence Enterprise Edition (Oracle BI EE) brings business visibility and insight to a wide variety of users in an enterprise.

Oracle BI EE is a comprehensive set of enterprise business intelligence tools and infrastructure, including a scalable and efficient query and analysis server, an ad-hoc query and analysis tool, interactive dashboards, proactive intelligence and alerts, real-time predictive intelligence, and an enterprise reporting engine.

The following are recommendations that are specific to Oracle BI EE.

Artifacts in the Database

BIPLATFORM schema is part of the Oracle BI EE database.

Special Considerations

You should configure load balancer virtual hosts for Oracle BI EE on both the production and the standby sites.

Synchronization Recommendations

Synchronize the application tier manually with the standby site after you change the configuration or apply patches.

When the application tier synchronization is initiated on the storage, Oracle recommends that you synchronize the standby database . This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

Recover the Middleware home, the domain, and the Oracle instance that contains the Oracle BI EE components. On Windows, import Oracle BI EE Registry entries. Recover the database to the most recent point in time, if needed.

Parent topic: Recommendations for Oracle Business Intelligence Suite

2.3.3 Recommendations for Oracle Business Intelligence Publisher

Oracle Business Intelligence Publisher (BI Publisher, formerly XML Publisher) allows you to create highly formatted reports that are suitable for printing Business Intelligent reports.

BI Publisher reports are built on top of BI Publisher data models. BI Publisher data model can consist of data sets from a wide range of sources, such as subject areas from the Oracle Business Intelligence Server or analyses, SQL queries against relational data bases, MDX queries against Subbase, LDAP, web services, Microsoft Excel, HTTP feeds, or XML files. BI Publisher supports a wide range of layout types, so you can create the full range of documents that your organization might need. Within Oracle Business Intelligence Enterprise Edition you can view, create, edit, and schedule BI Publisher reports and then include them in the dashboard pages.

The following are recommendations that are specific to BI Pubisher.

Artifacts in the Database

BIPLATFORM schema is a part of the Oracle Business Intelligence Publisher database.

Special Considerations

You should configure load balancer virtual hosts for Oracle Business Intelligence Publisher on both the production and standby sites.

Synchronization Recommendations

Synchronize the application tier manually with the standby site after you make changes in the configuration or apply patches.

When the application tier synchronization is initiated on the storage, Oracle recommends that you synchronize the standby database. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

Recover the WebLogic Managed Server that contains the BI Publisher component.

Parent topic: Recommendations for Oracle Business Intelligence Suite

2.4 Recommendations for Oracle WebCenter Portal

Oracle WebCenter Portal is an Oracle Fusion Middleware component that provides a personalized, secure, and efficient way of presenting and consuming information, collaborating with others, and interacting with applications in the context of business processes.

Oracle WebCenter Portal optimizes the connections between people, information, and applications; provides a context for users to navigate, discover, and access content relevant to your business needs.

Oracle WebCenter Portal includes the following servers, applications, and services:
  • Portal Managed Servers:
    • Portal application and services
    • Analytics Collector service
  • Collaboration Managed Servers:

    • Discussions application and services

  • Portlet Managed Servers:

    • Portlet Producer services

    • Pagelet Producer service

This section contains the following recommendations:

Parent topic: Recommendations for Oracle Fusion Middleware Components

2.4.1 Common Recommendations for All Oracle WebCenter Portal Components

Learn about what Oracle recommends for all Oracle WebCenter Portal components.

The following artifacts and considerations apply to all Oracle WebCenter Portal components:

Artifacts on the File System

Oracle home—The Oracle home consists of a WebLogic home that has the Oracle WebLogic Server binary files.

Domain home—The domain home contains the configuration data and the applications for the WebLogic domain.

There are no shared files ystem persistence store requirements for any Oracle WebCenter Portal runtime components.

Network Artifacts

Oracle recommends that you use a virtual alias (instead of physical host names) as the listen address for both Oracle WebLogic Administration server and the Oracle Managed Servers. As long as this alias can be resolved on both the production and standby sites, there is no need to update this value after a Disaster Recovery operation.

Oracle WebCenter Portal does not require whole server migration or service migration to be configured. No special considerations are needed in this regard.

You should configure the load balancer virtual host, which is used to access the Oracle WebCenter Portal applications and services, on both the production and standby sites.

Artifacts in the Database

Oracle WebCenter Portal stores all data and metadata in database schemas created with the Repository Creation Utility. Application runtime configuration metadata is store through the Metadata Services Repository (MDS).

Synchronization Recommendations

Synchronize the application tier manually with the standby site after you make changes in the domain-related configuration, deploy applications or shared libraries, or apply patches.

You should configure Oracle Data Guard for the Oracle WebCenter Portal database and metadata repository.

Oracle recommends that you synchronize the standby database, when the application tier synchronization is initiated on the storage. This synchronization can occur automatically when Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database. See Applying Redo Data to Physical Standby Databases in Oracle Data Guard Concepts and Administration, and Synchronizing Databases Manually.

Recovery Recommendations

You must be recover the database to the most recent point in time to ensure that the latest composite definitions and inflight instances are restored.

Parent topic: Recommendations for Oracle WebCenter Portal

2.4.2 Recommendations for Oracle WebCenter Portal Server

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

The following are recommendations that are specific to Oracle WebCenter Portal Server:

Artifacts in the Database

Portal application data is stored in the WEBCENTER database schema. Portal customized metadata is stored in the MDS database schema

Synchronization Recommendations

Synchronize the application tier manually with the standby site after you change the configuration, deploy applications, or apply patches.

You should be configure Oracle Data Guard for the Oracle database containing the WEBCENTER schema, and metadata repository.

When the application tier synchronization is initiated on the storage, Oracle recommends that you synchronize the standby database . This synchronization can occur automatically when Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database. See Applying Redo Data to Physical Standby Databases in Oracle Data Guard Concepts and Administration, and Synchronizing Databases Manually.

Recovery Recommendations

You must be recover the database that contains the WEBCENER schema and MDS repository, to the most recent point in time, along with the Oracle WebCenter Portal domain.

Parent topic: Recommendations for Oracle WebCenter Portal

2.4.3 Recommendations for Oracle WebCenter Analytics

Oracle WebCenter Portal allows for a single active analytics collector registration. The Analytics Collector receives usage metrics from the Portal application. All connections to the Analytics Collector are stateless.

Following an Enterprise Deployment Guide topology deployment, each portal server has one active local analytics collector service that is responsible for collecting metrics for all portal traffic on that portal server. The recommended configuration is to set the portal's common connection registration to localhost, and the default port of 31314. Each portal server connects locally. Load-balancer configurations are not required and no configuration changes are needed for failover to the secondary site for analytics functionality.

The following are recommendations that are specific to Oracle WebCenter Analytics:

Artifacts in the Database

Analytics Collector data is stored in the Oracle WebCenter Portal's ACTIVITIES schema.

Synchronization Recommendations

Synchronize the application tier manually with the standby site after you make any changes in the configuration for the Analytics Collector MBeans, the Portal's Analytics service registration, or apply patches.

You should configure Oracle Data Guard for the Oracle database containing the Oracle WebCenter Portal schemas and the metadata repository.

When the application tier synchronization is initiated on the storage, Oracle recommends that you synchronize the standby database . This synchronization can occur automatically when Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database. See Applying Redo Data to Physical Standby Databases in Oracle Data Guard Concepts and Administration, and Synchronizing Databases Manually.

Recovery Recommendations

You must recover the database that contains the ACTIVITIES schema to the most recent point in time, along with the Oracle WebCenter Portal domain.

Parent topic: Recommendations for Oracle WebCenter Portal

2.4.4 Recommendations for Oracle WebCenter Discussion Server

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

The following are recommendations that are specific to Oracle WebCenter Discussion Server:

Artifacts in the Database

The Discussions Server schema stores metadata and data and is part of the Oracle WebCenter Portal schemas.

Synchronization Recommendations

Synchronize the application tier manually with the standby site after you change the configuration, deploy applications, or apply patches.

You should configure Oracle Data Guard for the Oracle database that contains the Oracle Discussion Server schema and metadata repository.

When the application tier synchronization is initiated on the storage, Oracle recommends that you synchronize the standby database . This synchronization can occur automatically when Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database. See Applying Redo Data to Physical Standby Databases in Oracle Data Guard Concepts and Administration, and Synchronizing Databases Manually.

Recovery Recommendations

You must recover the database that contains the Discussion Server schema to the most recent point in time along with the Oracle WebCenter Portal domain.

Parent topic: Recommendations for Oracle WebCenter Portal

2.4.5 Recommendations for Oracle WebCenter Portlet and Pagelet Services

Oracle WebCenter Portal supports deployment and execution of both standards-based portlets (WSRP 2.0), and traditional Oracle (Portlet Developer Kit) PDK-Java based portlets. Oracle WebCenter Portal provides several ready-to-use producers.

The following are recommendations that are specific to Oracle WebCenter Portlet and Pagelet:

Artifacts in the Database

The PORTLET schema stores user customized data and is part of the Oracle WebCenter Portal schemas. The MDS repository stores portlet metadata and configuration information.

Synchronization Recommendations

Synchronize the application tier manually with the standby site after you change the configuration, deploy applications, or apply patches.

You should configure Oracle Data Guard for the Oracle database that contains the PORTLET schema and metadata repository.

When the application tier synchronization is initiated on the storage, Oracle recommends that you synchronize the standby database . This synchronization can occur automatically when Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database. See Applying Redo Data to Physical Standby Databases in Oracle Data Guard Concepts and Administration, and Synchronizing Databases Manually.

Recovery Recommendations

You must recover the database that contains the PORTLET schema and MDS repository to the most recent point in time along with the Oracle WebCenter Portal domain.

Parent topic: Recommendations for Oracle WebCenter Portal

2.5 Recommendations for Oracle WebCenter Content

Oracle WebCenter Content is an integrated suite of products designed to manage enterprise content.

Oracle WebCenter Content enables you to leverage industry-leading document management, web content management, digital asset management, and records management functionality to build your business applications. The ability to manage the enterprise content helps you reduce costs, share content across the enterprise, minimize risk, automate manual processes, and consolidate multiple web sites onto a single platform.

Oracle Enterprise Content Management includes the following components:

  • Oracle WebCenter Content

  • Oracle WebCenter Content: Inbound Refinery

  • Oracle WebCenter Content: Enterprise Capture

  • Oracle WebCenter Content: Content User Interface

This section contains the following recommendations:

Parent topic: Recommendations for Oracle Fusion Middleware Components

2.5.1 Common Recommendations for All Oracle WebCenter Content Components

Learn about what Oracle recommends for all Oracle WebCenter Content components.

The following artifacts and considerations apply to all Oracle WebCenter Content components:

Artifacts on the File System

MW_HOME—The Middleware home consists of a WebLogic home that has the WebLogic Server binaries and an Oracle home that contains the Oracle WebCenter Content binaries.

Oracle_Common_Home—The Oracle home that contains the binary and library files required for the Oracle Enterprise Manager Fusion Middleware Control and Java Required Files.

Domain Home—The domain home contains the Administration Server and Managed Server configuration data and Oracle WebCenter Content applications for the domain.

Oracle Instance—The Oracle instance contains the configuration data for non-J2EE Oracle WebCenter Content applications such as OPMN configuration and Enterprise Manager Agent configuration data.

WebCenter Content Shared Directories files— In a clustered implementation of WebCenter Content as per Enterprise Deployment guidelines shared directories are required for domain configuration as well as WebCenter Content shared directory files such as data, audit, and vault directories.

Network Artifacts

Oracle recommends that you use a virtual alias (instead of physical host names) as the listen address for both Oracle WebLogic Administration server and the Oracle Managed Servers. As long as this alias can be resolved on both the production and standby sites, there is no need to update this value after a Disaster Recovery operation.

You must configure the load balancer virtual host, which is used for accessing Oracle WebCenter Content Management components, on both the production and standby sites.

Artifacts in the Database

The Oracle WebCenter Content schemas are located in the Oracle WebCenter Content database.

Synchronization Recommendations

Synchronize the directory tier manually with the standby site after you make configuration changes, deploy applications, and apply patches.

You should configure Oracle Data Guard for the Oracle database metadata repository.

When the application tier synchronization is initiated on the storage, Oracle recommends that you synchronize the standby database. This synchronization can occur automatically when Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

You must recover the database that contains the Oracle WebCenter Content schemas to the most recent point in time along with the Identity Management component in question.

Parent topic: Recommendations for Oracle WebCenter Content

2.5.2 Recommendations for Oracle WebCenter Content

Oracle WebCenter Content provides a unified application for several different kinds of content management.

Through user-friendly interfaces, roles-based authentication and security models, Oracle WebCenter Content empowers users throughout the enterprise to view, collaborate on or retire content. This ensures that all accessible, distributed, or published information is secure, accurate, and up-to-date.

The following are recommendations that are specific to Oracle WebCenter Content:

Artifacts in the Database

The OCS (Oracle Content Schema) schema is part of the Oracle WebCenter Content database.

Artifacts in the File System

WebCenter Content shared directories along with any Oracle Secure Files or the setup of file-based persistent stores need to be replicated across to the standby site for having them disaster protected.

Special Considerations

You should configure the load balancer virtual host, which is required for the Oracle WebCenter Content on both the production and standby sites.

Synchronization Recommendations

Synchronize the directory tier manually with the standby site after you change the configuration, deploy applications, or apply patches.

You should configure Oracle Data Guard for the Oracle database repositories.

When the application tier synchronization is initiated on the storage, Oracle recommends that you synchronize the standby database. This synchronization can occur automatically when Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

For file-based persistent stores, you must synchronize the file-based persistent stores on the standby site.

Recovery Recommendations

You must recover Oracle WebCenter Content with the OCS and MDS schemas to the most recent point in time.

Parent topic: Recommendations for Oracle WebCenter Content

2.5.3 Recommendations for Oracle WebCenter Content Inbound Refinery

Oracle WebCenter Content Inbound Refinery is a conversion server that manages file conversions for electronic assets such as documents, digital images, and motion video.

Oracle WebCenter Content Inbound Refinery provides thumbnail functionality for documents and images, storyboarding for video, and the ability to extract and use EXIF data from digital images and XMP data from electronic files that are generated from programs such as Adobe Photoshop and Adobe Illustrator. You can use Oracle WebCenter Content Inbound Refinery to convert content items stored in Oracle Content Server.

The following are recommendations that are specific to Oracle WebCenter Content Inbound Refinery:

Artifacts in the Database

Oracle WebCenter Content Inbound Refinery does not have any database dependencies.

Special Considerations

You should configure the load balancer virtual host, which is required for Oracle WebCenter Content Inbound Refinery on both the production and the standby sites.

Synchronization Recommendations

Synchronize the directory tier manually with the standby site after you change the configuration or apply patches.

Recovery Recommendations

Recover the Oracle WebCenter Content Inbound Refinery instance.

Parent topic: Recommendations for Oracle WebCenter Content

2.5.4 Recommendations for Oracle WebCenter Content Enterprise Capture

Oracle WebCenter Enterprise Capture (Enterprise Capture) provides organizations with a single system to capture both paper and electronic documents.

Enterprise Capture supports both centralized and distributed image capture from a user-friendly web interface capable of using high-volume, production-level scanners. Support for the industry-standard TWAIN scanning interface enables Enterprise Capture to use a wide variety of industry-leading document imaging. Enterprise Capture provides organizations with a single system to capture both paper and electronic documents scanners to digitize paper content. Existing electronic document files can be easily captured by users or automatically captured through an importing process that can monitor an email server or network folder. Once captured, documents are organized and indexed by applying metadata through manual or automated processes that use bar code recognition technology. After documents are completed, they are committed into a content management system. Enterprise Capture is fully integrated with Oracle WebCenter Content to provide organizations with one system to capture, store, manage, and retrieve their mission critical business content.

The following are recommendations that are specific to Oracle WebCenter Content Enterprise Capture:

Artifacts in the Database

Resides in Oracle WebCenter Enterprise Capture schema.

Artifacts in the File System

There are no file system artifacts for Enterprise Capture unless its JMS servers are stored in file-based persistent stores. The recommendation is to configure JMS servers with database-based persistent stores so that Oracle Data Guard is leveraged to replicate the database schema across sites.

Special Considerations

You should configure the load balancer virtual host, which is required for Oracle WebCenter Content Inbound Refinery, on both the production and the standby sites.

Synchronization Recommendations

Synchronize the directory tier manually with the standby site after you change the configuration or apply patches.

Recovery Recommendations

You must recover Enterprise Capture with the Enterprise Capture schema to the most recent point in time along with the Managed Server running the Oracle WebCenter Content Capture application, and the associated instances.

Parent topic: Recommendations for Oracle WebCenter Content

2.5.5 Recommendations for Oracle WebCenter Content: Content User Interface

WebCenter Content User Interface is a user-friendly and a feature-rich user interface for managing Oracle WebCenter Contented based on Oracle Application Development Framework.

The following are recommendations that are specific to Oracle WebCenter Content User Interface:

Artifacts in the Database

The Metadata Services schemas (MDS) are part of the Oracle WebCenter Content User Interface.

Special Considerations

You must configure load balancer virtual hosts for Oracle WebCenter Content User Interface on both the production and standby sites.

Synchronization Recommendations

Synchronize the directory tier manually with the standby site after you change the configuration or apply patches.

When the application tier synchronization is initiated on the storage, Oracle recommends that the standby database be synchronized. This synchronization occurs automatically because Oracle Data Guard is configured in Managed Recovery mode (the recommended configuration) for the database. If the standby database is not in Managed Recovery mode, then you should manually synchronize the standby database.

Recovery Recommendations

Recover the Managed Servers running the Oracle WebCenter Content User Interface application, along with the Administration Server.

Parent topic: Recommendations for Oracle WebCenter Content