5 High Availability
The following topics are covered in this chapter:
Issues Related to Automatic Service Migration
This section contains the following topic:
Parent topic: High Availability
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.
Parent topic: Issues Related to Automatic Service Migration
Issues Pertaining to Oracle BAM
This section contains the following topic:
- Configuring Oracle BAM After Scale Up
- BAM JNDI Foreign Providers Are Not Created When You Add BAM to a Domain With Dynamic SOA Cluster
Parent topic: High Availability
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.
Parent topic: Issues Pertaining to Oracle BAM
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.
-
Create the BAMForeignJNDIProvider.
-
Login to weblogic console. Navigate to domain > Environment > Services > Foreign JNDI Providers.
-
Click New.
-
Change the name to BAMForeignJNDIProvider and click next.
-
Select SOA Cluster as the target. Click Finish. A Foreign JNDI Provider BAMForeignJNDIProvider will be created.
-
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
-
Click Save.
-
Click the Links tab. Create two links for each of the BAM persistence and configuration services as mentioned in the table below:
-
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
-
-
Create the BPMForeignJNDIProvider.
-
Login to the weblogic console. Click Foreign JNDI providers link in home page.
-
Click New. Change the name to BPMForeignJNDIProvider and click next.
-
Select BAM cluster as the target. Click Finish. A Foreign JNDI Provider BPMForeignJNDIProvider is created.
-
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
-
Click Save.
-
Click the Links tab. Create the links for each of the BPM service listed in the table below.
-
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
-
Parent topic: Issues Pertaining to Oracle BAM
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>
Parent topic: High Availability