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.

how to optimally configure the number of database connections in BPEL

In any project one of the most important step towards performance tuning is to configure the number of connections to the DB .If the number of requests are more than the number of connections to database, the requests will have to wait till the connections are free. It is not easy to come up with the number of connections required to connect to the DB. It depends on lot of factors like the load on the server, how many threads are simultaneously required to process a request. You can only come up with an optimal number depending on the different dependent factors. Today I will discuss the dependent factors that you need to consider when you work on a BPEL Server.

First we will look at what type of requests are processed inside the server

Usually it can be categorized as one-way invocation and two-way invocation (request-response model)

For both types of invocation, under normal scenarios the threads processing the requests will use one connection each.

Below I am listing the different factors which will influence the max-connection attribute of connection-pool.

• dspMaxThreads BPEL Property

This property sets the maximum number of active dispatcher threads that process messages during peak load times. It depends on the load of the server-expected maximum parallel requests. Usually dspMaxThreads <= WorkerBean threads.

• nonBlockingInvoke BPEL Property

Even though you use Flow or FlowN in your bpel process Oracle BPEL Process Manager executes it in a single thread, executing the branches sequentially instead of in parallel. When nonBlockingInvoke property is set to true, the process manager creates a new thread to perform each branch’s invoke activity in parallel.

• WorkerBean

Oracle BPEL Server uses an MDB called WorkerBean to perform processing. In the case of one-way invocation(durable process) the request to the server is placed in a queue. Inside Oracle BPEL Server, a message-driven bean (MDB), WorkerBean, monitors the queue for invocation requests and then it is dequeued and assigned a new thread for servicing the request

• InvokerBean

The invoker bean is used only for nonblocking invoke activities. When nonBlockingInvoke property is set to true, BPEL Server spawns a new thread to execute the invocation. InvokerBean is the one which creates new threads to service the request.

The number of connections required is evaluated on the basis of the above factors.

• For a simple scenario

Maximum DB Connections >= (WorkerBean listener threads) + (Maximum concurrent request-response invocations)

• If you are having only one domain

dspMaxThreads = (WorkerBean listener threads)

Maximum DB Connections >= (dspMaxThreads) + (Maximum concurrent request-response invocations)

• If you are having multiple domains

Σdomains dspMaxThreads = (WorkerBean listener threads)

Maximum DB Connections >= (Σdomains dspMaxThreads) + (Maximum concurrent request-response invocations)

• If nonBlockingInvoke is set to true

Maximum DB Connections >= (InvokerBean listener threads) + (WorkerBean listener

threads)+ (maximum concurrent request-response invocations)

You need to know the place where you can configure the data-source connection. The file can be found in ORACLE_HOME/ j2ee/home/config /data-sources.xml.

The following shows the place where you need to configure the number of connections

<connection-pool name=” MY_CONNECTION_POOL”

min-connections='xx'

max-connections='yy'

……

…..

…..

…….

/>

After you change the value you need to restart the server for the setting to take effect.