5 High Availability

This chapter describes the issues related to Oracle Fusion Middleware high availability.

The following topics are covered in this chapter:

Issues Related to Automatic Service Migration

This section contains the following topic:

Oracle User Messaging Service 12c (12.1.3) Does Not Support Automatic Service Migration

In enterprise deployments that take advantage of high availability, Oracle recommends that you configure Oracle BAM to use Automatic Service Migration, which migrates specific services to a different Managed Server in the cluster when a server fails.

However, in some scenarios where Oracle BAM is producing constant and intensive User Messaging Service (UMS) messages, a Managed Server failure might leave some alert messages stuck in the UMS queues. This is because UMS 12c (12.1.3) does not currently support Automatic Service Migration.

To workaround this issue, you can recover messages in the UMS queues by restarting the failed Oracle BAM Managed Server. To resume the appropriate capacity and load sustainability after a BAM server failure, you must do two things:

  • Restart the failed Managed Server.

  • Fail back the migrated services to the original Managed Server.

For more information, see Failing Back Oracle BAM Services After Automatic Service Migration Occurs in Enterprise Deployment Guide for Oracle SOA Suite.

If a BAM server restart is not compatible with your system's recovery time objectives (RTO), then you can configure UMS with Advanced Queuing (AQ) JMS instead of the default JMS provider. For more information, see Appendix B, Configuring User Messaging Service with AQ JMS, in Administering Oracle User Messaging Service.

Issues Pertaining to Oracle BAM

This section contains the following topic:

Configuring Oracle BAM After Scale Up

Oracle BAM requires additional configuration steps after you configure the domain. See the topic Configuring BAM for High Availability in the 12.1.3 version of the Oracle Fusion Middleware High Availability Guide.

BAM JNDI Foreign Providers Are Not Created When You Add BAM to a Domain With Dynamic SOA Cluster

When adding BAM to the domain, some foreign JNDI providers are created. One of them, the BAMForeignJndiProvider is configured pointing to the SOA Cluster.

When the SOA Cluster is dynamic, that JNDI provider is not properly populated and the foreign JNDI providers are not created during the configuration wizard.

After extending the domain to add BAM, two Foreign JNDI Providers must be created in the domain: BAMForeignJNDIProvider and BPMForeignJNDIProvider.

  1. Create the BAMForeignJNDIProvider.

    1. Login to weblogic console. Navigate to domain > Environment > Services > Foreign JNDI Providers.

    2. Click New.

    3. Change the name to BAMForeignJNDIProvider and click next.

    4. Select SOA Cluster as the target. Click Finish. A Foreign JNDI Provider BAMForeignJNDIProvider will be created.

    5. Click BAMForeignJNDIProvider link. Under General tab, enter the following properties:

            Initial Context Factory : weblogic.jndi.WLInitialContextFactory

      Provider URL : URL for the BAM Servers example, t3://host1:9001,host2:9001

    6. Click Save.

    7. Click the Links tab. Create two links for each of the BAM persistence and configuration services as mentioned in the table below:

    8. Restart the SOA Server (This is required, otherwise, the foreign jndi doesnt work and you will run in to a stackoverflow error).

    Service Local JNDI Name Remote JNDI name

    BAM Persistence service

    OracleBeam#oracle.beam.common.client.service.persistence.BeamPersistence

    OracleBeam#oracle.beam.common.client.service.persistence.BeamPersistence

    BAM Config Service

    ConfigSession#oracle.beam.config.common.ConfigSession

    ConfigSession#oracle.beam.config.common.ConfigSession

  2. Create the BPMForeignJNDIProvider.

    1. Login to the weblogic console. Click Foreign JNDI providers link in home page.

    2. Click New. Change the name to BPMForeignJNDIProvider and click next.

    3. Select BAM cluster as the target. Click Finish. A Foreign JNDI Provider BPMForeignJNDIProvider is created.

    4. Click BPMForeignJNDIProvider link. Under General tab, enter the following properties:

          Initial Context Factor: weblogic.jndi.WLInitialContextFactory

      Provider URL: URL for the BPM Servers e.g t3://soahost1:8001,soahost2:8001

    5. Click Save.

    6. Click the Links tab. Create the links for each of the BPM service listed in the table below.

    7. Restart the BAM servers.

    Service Local JNDI Name Remote JNDI Name

    UserMetadataService

    UserMetadataService

    UserMetadataService

    TaskEvidenceService

    TaskEvidenceServiceBean

    TaskEvidenceServiceBean

    RuntimeConfigService

    RuntimeConfigService

    RuntimeConfigService

    BPMProcessModelService

    ejb/bpm/services/ProcessModelServiceBean

    ejb/bpm/services/ProcessModelServiceBean

    BPMProcessMetadataService

    ejb/bpm/services/ProcessMetadataServiceBean

    ejb/bpm/services/ProcessMetadataServiceBean

    BPMProcessDashboardService

    ejb/bpm/services/ProcessDashboardServiceBean

    ejb/bpm/services/ProcessDashboardServiceBean

    BPMProcessAnalyticsServiceBean

    ejb/bpm/services/ProcessAnalyticsServiceBean

    ejb/bpm/services/ProcessAnalyticsServiceBean

    BPMInstanceQueryService

    ejb/bpm/services/InstanceQueryServiceBean

    ejb/bpm/services/InstanceQueryServiceBean

    BPMInstanceManagementService

    ejb/bpm/services/InstanceManagementServiceBean

    ejb/bpm/services/InstanceManagementServiceBean

    BPMUserAuthenticationService

    ejb/bpm/services/BPMUserAuthenticationServiceBean

    ejb/bpm/services/BPMUserAuthenticationServiceBean

    TaskService

    ejb/bpel/services/workflow/TaskServiceBean

    ejb/bpel/services/workflow/TaskServiceBean

    TaskMetadataService

    ejb/bpel/services/workflow/TaskMetadataServiceBean

    ejb/bpel/services/workflow/TaskMetadataServiceBean

    BPMDataObjectSecurityService

    BPMAnalytics#oracle.bpm.metrics.dataobject.security.IBPMDataObjectSecurityServiceRemote

    BPMAnalytics#oracle.bpm.metrics.dataobject.security.IBPMDataObjectSecurityServiceRemote

Incorrect Migration Policy In UMSJMSJDBCSTORE_AUTO_2 After OSB Extension

If you are adding the OSB dynamic cluster to a domain containing a SOA dynamic cluster, where you already have changed the policy of the UMSJMSJDBCSTORE_AUTO_1 persistent store to something different from off, the UMSJMSJDBCSTORE_AUTO_2 created for OSB_Cluster will inherit that migration policy. This causes a configuration error because the OSB_Cluster doesn't have any leasing configuration by default, and the AdminServer fails to start.

Admin server fails to start by displaying the following error:

weblogic.management.ManagementException: [Management:141266]Parsing 
failure in config.xml: The following failures occurred: 
-- An attempt was made to set the migration-policy of JDBCStore 
UMSJMSJDBCStore_auto_2 to "On-Failure". Before automatic migration of any 
kind can be used, the MigrationBasis must be set in the ClusterMBean.

To correct this issue, follow the option mentioned below:

Manually correct the config.xml. Edit the domain config.xml .

  • Look for the UMSJMSJDBCSTORE_AUTO_2 element that is targeted to the OSB Cluster .

  • Set its <migration-policy> to off.

  • For example:

    <jdbc-store>
        <name>UMSJMSJDBCStore_auto_2</name>
      .. 
    
        <migration-policy>off</migration-policy>
    .....
      </jdbc-store>