enable Active-Passive configuration for BPEL Adapters in HA

Recently I was doing some analysis on the Active-passive configurations to be enabled while working on HA enabled clustered environment with multiple nodes. There are some adapters which needs to be configured in Active-Passive mode. File and FTP Adapters are a must two that must be setup in an active-passive configuration. This is due to file system restrictions that make it impossible to avoid race conditions when two nodes attempt to retrieve the same file. Same will be the case with AQ or JMS adapters that subscribe to the same messaging topic since each will consume the same message.

How to achieve that?

The Adapter Framework supports active fail-over of inbound Adapter Services. You can achieve this by adding a property to a particular JCA activation agent (in bpel.xml) as shown in the following example:

<BPELSuitcase>

<BPELProcess id="HAAdapterTest" src="HAAdapterTest.bpel">

<partnerLinkBindings>

<partnerLinkBinding name="File_in">

<property name="wsdlLocation">File_in.wsdl</property>

</partnerLinkBinding>

<partnerLinkBinding name="DB_out">

……………….

</partnerLinkBinding>

…………

…………

</partnerLinkBindings>

<activationAgents>

<activationAgent className="oracle.tip.adapter.fw.agent.jca.JCAActivationAgent" partnerLink="File_in">

<property name="clusterGroupId">GeoClusterId</property>

<property name="portType">Read_ptt</property>

<property name="input" type="LogicalDirectory">/home/geo/hatest</property> </activationAgent>

</activationAgents>

</BPELProcess>

</BPELSuitcase>

If the BPEL PM servers (JVMs) in the cluster are located across TCP/IP subnet boundaries, then it is necessary to add the attribute clusterAcrossSubnet=true.

In a cluster group, the multiple activations of the same adapter Activation Agent will be detected implicitly and automatically by all the instances of the adapter framework active in that cluster. Only one node activation will be allowed to actually start the reading or publishing messages. The adapter framework instances chooses one among them, randomly as to who should assume the Primary Activation responsibility. The other activations (instances) in the cluster will initiate to a hot stand-by state, without actually invoking EndpointActivation on the JCA resource adapter.

If a primary activation at some point becomes unresponsive, is deactivated manually or if it crashes/exits, then any one of the remaining adapter framework members of the cluster group will immediately detect this, and reassign the primary activation responsibility to one of activation agents standing by.

This feature uses JGroups underneath for the implementation, hence the clusterGroupId property. These features require cluster and JGroups configuration in

$ORACLE_HOME/bpel/system/config/collaxa-config.xml and $ORACLE_HOME/system/config/jgroups-protocol.xml. All BPEL instances

participating in the cluster must share the same cluster name in collaxa-config.xml,and the same multicast address and port in jgroups-protocol.xml.

Try it out if you have HA clustered environment. J