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.

JCA Adapter rejectedMessageHandlers Property in ESB

As part of developing an exception framework I was evaluating different options available with ESB for error handling. For ESB process with async routing rule,we will use ERROR_TOPIC for knowing more about the error . In cases with sync routing rules we can use rejectedMessageHandlers property to know more about the error.

Oracle ESB supports the file, queue, and WSIF rejection handler types. As of now JMS and BPEL message handlers are not supported. In one of my previous blogs I had mentioned about how to specify end point properties in an esbsvc file. Similar editing has to be done in case of rejection handlers.

In case of AQ and file, corresponding adapter's esbsvc file has to be edited. You must update this file manually with a text editor outside JDEV and then open the project in Oracle JDeveloper and register it. After registering, you can view and edit the new rejectedMessageHandlers property in the adapter’s Oracle ESB Control Properties tab.

Where to add the property in the esbsvc file is shown below

File Adapter

...

</invocation>

<endpointProperties>

<property name="rejectedMessageHandlers"

value="/home/soa/rejectedMessages/"/>

</endpointProperties>

</service>

AQ Adapter

<property name="rejectedMessageHandlers"

value="queue://jdbc:oracle:thin:@host_name:1521:XE|user/pwd|AQ_RAW_IN_ERROR_QUEUE"/>

understanding error handling in BPEL/ESB

One of the most challenging tasks to the success of the project is to come up with a proper error handling approach. Today I will briefly touch up on the error handling features in BPEL/ESB.

BPEL

When you consider a BPEL process, the errors can be categorized as below.

• Partner link errors.

• Non-partner link errors.

Partner Link Errors

Partner link can throw error in either of the 2 scenarios.

The partner link invocation fails.

The partner link receives a fault.

In case of Partner link errors BPEL 10.1.3.3 provides the Fault Policy management framework which helps you in standardizing the error handling mechanism at domain level, process level, partner link or port Type level depending on your requirements. It provides a generic fault management framework for handling faults in BPEL processes. If a fault occurs during runtime in an invoke activity in a process, the framework catches the fault and performs a user-specified action defined in a fault policy file associated with the activity.

Non-Partner Link Errors

In case of Non-partner link errors you need to manually handle this.

Create a bpel process say NPErrorHandlingBPELProcess. The error handling mechanism has to be defined in this process. Depending on the requirements this BPEL process should initiate the error handling along with sending out notifications and error logging.

Every participating BPEL process needs to use a common Application specific Fault message which will be given as the input to our NPErrorHandlingBPELProcess. Each BPEL process needs to populate the message and invoke the NPErrorHandlingBPELProcess.

ESB

In the case of ESB the error handling is dependent on the type of process. Error handling is processed differently whether asynchronous and synchronous execution is specified for a routing service. ESB errors can be categorized into

Retryable Errors

Errors generated by asynchronous processes come under the category of retryable. When you create a ESB process itself there is an option to define a ERROR TOPIC. In the case of an error the ERROR TOPIC will be used to store the business event along with the payload. So in such scenarios we can retrieve the payload from the Topic by subscribing to the topic and handle it according to your requirements.

Non-Retryable Errors

Errors generated by synchronous ESB processes are non-retryable. The best way as I see it is to use a BPEL process to invoke the ESB processes with synchronous routing service. For synchronous execution, the transaction is rolled back and an error notification is returned to the adapter/service that initiated the processing. Once you have the error notification in the BPEL process you have multiple ways to handle it.

Hope this article helps you in getting started with the different error handling options available in BPEL/ESB.