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

Workaround from wrong ESB installation @HA

In one of the installations that we did on High availability environment for ESB we faced an interesting issue. This was faced while doing the installation in the NON-GUI mode. The issue was that while esb is installed, the instance in which esb runtime is supposed to be deployed, has a wrong esb-dt deployed in it. This was because there was no option to specify the design or runtime for the NON-GUI mode (We had used response files from previous installations also). So I will list the work around from this.

When you install using the GUI mode there is always an option specify that runtime(esb-rt) has to be deployed on runtime oc4j instances.

1. First undeploy the esb-dt manually from OC4J_SOA(ESB runtime oc4j instance) of both the nodes.
2. Set the environment by executing the esbsetenv.sh script, located in the ORACLE_HOME/integration/esb/bin directory.
3. Update the ORACLE_HOME/integration/esb/install/ant-tasks/esb_oc4j_install_props.xml file with the values for your configuration.
4. Deploy the Oracle Enterprise Service Bus repository or runtime instance by executing:ant -f $ORACLE_HOME/integration/esb/install/ant-tasks/esboc4j.xml.
5. Verify that the Oracle Enterprise Service Bus repository instance deployment was successful by accessing the Repository Instance Console at:http://hotname:port/esb

Snippet form esb_oc4j_install_props.xml

……..

……….

<property name="home_container_v" value="OC4J_ESBDT"/> -- here replace it with the OC4J_SOA(or your runtime oc4j instance)

<!--

ESB component (runtime or repository) that you want to deploy on OC4J.

Possible values: 'design' (for repository)

'runtime' (for runtime)

-->

<property name="esb_type_v" value="design"/> -- here change it to runtime

……………………………

…………….

…………….

……….

Your ESB server will be up and running fine with the final configurations as specified in the enterprise deployment guide

deploying BPEL processes into High Availability environment using ant

This blog describes how to deploy BPEL processes to a clustered high availability environment. So before going into more details, a few words on my HA environment. The HA clustered environment has 4 nodes with 2 HTTP Server and 2 Application Server, each installed on different nodes. These instances are configured to work in a high availability setup. I will be referring to HTTP Server instances as WEBHOST1 and WEBHOST2 respectively and Application Server instances as APPHOST1 and APPHOST2 respectively.

If you look at the build script created by Jdeveloper when you create a BPEL process, you will be able to see the target called deployProcess which is responsible for deploying the process to a server.

<target name="deployProcess">

<deployProcess

user="${admin.user}" password="${admin.password}"

domain="${domain}" process="${process.name}"

rev="${rev}" dir="${process.dir}/output"

hostname="${http.hostname}" httpport="${http.port}"

verbose="${verbose}"

/>

</target>

In case of normal standalone deployment http.hostname will be same as the host name of application server because BPEL Server will also be on the same host.

In case of clustered HA environment the WEBHOST1 or WEBHOST2 has to be specified as the host name @ http.hostname and WEBHOST1 or WEBHOST2 port as http.port. These values will be configured in build properties file. When you specify the hostname as the WEBHOST(HTTP Server) the deployProcess target will take care of deploying the BPEL processes to all the nodes in the cluster @HA environment.

Hope this helps you in automating the deployment process to different HA environments.

designtime cache has not been initialized @ESB Console

Today I would like to mention one of the issues which I faced while verifying the ESB Console @ HA environment. When I access the ESB Console it throws the following error.

Error::

summary: Designtime cache has not been initialized

Please look in logs for following signs of failure. Fix them and restart. (a) Database access errors (b) ESB Bootstrap errors (c) OC4J class load errors (d) Product installation errors (e) Export ESB params and verify if host and port parameters are correct. Please contact Oracle Support if unable to fix the issue.Fix: -

When I looked in log files I didn’t get much help except that it’s a bootstrap error. I am attaching the snippet from log file

<PAYLOAD>

<MSG_TEXT>ESB bootstrap: Unknown error occured in constructor of ESB resource adapter</MSG_TEXT>

<SUPPL_DETAIL><![CDATA[java.lang.RuntimeException: failed to get ESB_HOME: java.lang.NullPointerException at oracle.tip.esb.configuration.ServiceBusConstants.getESBHome(ServiceBusConstants.java:240) at oracle.tip.esb.configuration.ServiceBusConstants.loadGlobalESBConfigs(ServiceBusConstants.java:328)

………..

………..

<PAYLOAD>

<MSG_TEXT>Warning. Unable to set up connection factory to location esb-dt for a resource adapter in {1}</MSG_TEXT>

</PAYLOAD>

Solution::

The issue was mainly because the ESB environment was not properly setup.

You need to check whether the post installation steps as specified in Enterprise deployment guide are followed.

• Updating the Oracle Enterprise Service Bus Metadata

You need to create an esb-param.properties files with some properties and import those properties into oraesb schema.You will have to modify the host and port in the properties file.

• Configuring JNDIs for the Topic and Topic Connection Factory

This step is also important because the ERROR topics to be used by the ESB processes have to be specified in advance before using ESB Console.

• Configuring the Slide Repository to use the Database as the Repository

This step has to be done in all the runtime and repository instances.

Once you are done with these post installation steps the issue will be solved.

how to deploy BPEL & ESB processes in High availability environment using JDeveloper

I believe most of the BPEL developers will know how to deploy a BPEL process to the server. As part of configuring Jdeveloper we will go to Connections tab, create Application Server connections and using this App server setting you will configure the integration Server Connection.Today we will see how to configure your Jdev connections for deploying into a HA environment.

Let me just give a brief intro of a high availability environment.

Imagine you have a clustered environment with 4 nodes. In this environment I have 2 HTTP Server and 2 Application Server, each installed on different nodes. These instances are configured to work in a high availability setup.

I will be referring to HTTP Server instances as WEBHOST1 and WEBHOST2 respectively and Application Server instances as APPHOST1 and APPHOST2 respectively.

So if you want to deploy a BPEL or ESB process what are the deployment options you are having. One is to deploy to each of these Application servers separately. But it is not a good practice because there are more chances of disparity in the archive that got deployed in both instances of server.

Next option which is considered the best way to follow is to create a group using the OC4J instances from both the servers APPHOST1 and APPHOST2 and then deploy applications (EAR, WAR) to the group.

For my example I will create a group as GEO_GROUP with required oc4j instances.

While creating Application Server connection in JDEV specify one of the APPHosts(APPHOST1 or APPHOST2) as Host Name. Specify the Connect To option as GROUP instead of single instance. OPMN Port as specified in the opmn.xml. Your Application Server Connection is ready. Just test it make sure the opmn port is correct.

For deploying BPEL and ESB processes. You need to create one more Application Server Connection.

This time you need to specify any one of the HTTP_SERVER address(WEBHOST1 or WEBHOST2) as Host name. Connect To option and OC4Jcomponent/Group Name are not relevant to the BPEL/ESB deployment. So just fill in dummy values. No need to test the connection because it will not work .Press OK to complete creation of the Application Server Connection.

While creating Integration Server Connection, select HTTP SERVER connection configured above as App Server Connection from the drop down menu. Specify the HTTP port of the HTTP_SERVER. Then test the connection. You should be getting message same as below.

Application Server: Failed

BPEL Process Manager Server: OK

ESB Server: OK

Now you are ready to go .Start deploying EAR & WAR files using APPHOST Application Server connection and BPEL and ESB processes using WEBHOST integration Server connection.