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

BPEL transaction timeout error

In some scenarios where BPEL process takes a long time for processing records, it may encounter timeout-errors like com.oracle.bpel.client.delivery.ReceiveTimeOutException. The transaction of the process will be rolled back and as a result of this BPEL process instances will not get created in BPEL console. The solution lies in configuring the Transaction timeout property at multiple places relevant to the BPEL process manager so that BPM allows the process to complete the processing of records without timing out the operation.

1. Configure the transaction-timeout property in Oracle_Home\j2ee\oc4j_instance\config\transaction-manager.xml. For example 7200 secs –(2 hours) would be good enough.

2. Cluster Toplogy -> [Oc4j_instance] -> Administration -> Transaction Manager (JTA) -> Administration -> Transaction Timeout. Here Oc4j_instance will be the one where Orabpel is deployed.

3. Configure the syncMaxWaitTime property in Oracle_Home\bpel/domains/domain_name/config/domain.xml. for example set 600 sec (10 min) if you expect your BPEL process instance to finish within this time frame.

Refer the section Setting Properties for BPEL Processes to Successfully Complete and Catch Exception Errors




Restart the oc4j for changes to reflect. Cheers J

ESB internal topics

One of the queries I used to get in ESB was on the role of different JMS topics used in ESB.

I am listing down the main topics used in ESB.

There are 2 parts of the ESB engine - ESB designtime server & ESB runtime server

The ESB designtime server (ESBDT) provides interfaces for all metadata changes from JDeveloper, ant-based import/export or browser-based ESB Control changes.

The ESB runtime server (ESBRT) loads an in-memory cache at startup that contains all service metadata and artifacts such that services run straight from memory.

Async Topic - used for storage of messages that are delivered asynchronously.

Error Topic - will have the messages that could not be delivered due to an error.

Monitor Topic – ESBDT subscribes to this topic to get tracking messages from ESBRT

Control Topic – ESB runtime servers listen on the control topic to get notified of any metadata changes

Resub Topic – This topic stores the payload for esb instances where retryable error has occured.

The primary mechanism of interaction between ESBDT and the ESBRT nodes is through

JMS topics. The ESBDT subscribes to both a monitor and error topic to which all ESBRT instances publish their monitoring and error messages. ESBDT then persists that information to the database. The ESBDT also publishes administration messages to a control topic to which all ESBRT instances subscribe.

thats it for today cheers :)