Use of Dynamic JNDI

Hi Guys

This is my first Post in 2010.I came across a very useful and unusual scenario where i have to select the JNDI at run time.
Here is the way how we do it.

Scenario-
We have two database schemas, India and US each containing Employee
table. If the employee's location is india, we
want to insert it into India schema, if he works in US, the insertion should be
done in the employee table of US Schema.
The credentials, and possibly even database host name, port number for the two schema can be different. Thus we have two different JNDI entries for
these two schemas – eis/DB/US and eis/DB/India. But, for inserting into these
different databases, we want to use a single Database adapter. Normally, the JNDI on
which the adapter is based is specified during design time. So we want to change the
JNDI value for the adapter at runtime, based on whether the employee is of US or India.

Please make sure that the two JNDIs (eis/DB/US and eis/DB/India)are created in the application server pointing to their respective databases.

After doing this , create a simple BPEL project which has a single invoke to the database.Make sure you have a switch activity which have a condition on employees location.Based on the employee's location assign its respective JNDI and then invoke the DB Adapter.

Now the question arrises how you will assign the JNDI?
You need to add the below xml fragment in your assign activity and assign it to the partner link(in our case it is DB adapter).

<EndpointReference
xmlns="http://schemas.xmlsoap.org/ws/2003/03/addressing">
<Address>eis/DB/India</Address>
</EndpointReference>

Once you complete it,just deploy the code and test it.
It works.

Cheers.

Modify Transaction Timeout Settings

We generally face the time out issue during the run time, when the data being fetched is large.Thus to avoid this issue we need to increase the time out settings. Suppose we want to have a transaction timeout of 600 seconds to enable.

We need to change the following files and bounce the oc4j instance to have the timeout setting effective :

• Change transaction-manager.xml at $J2EE_HOME/config(change the attribute transaction-timeout to 600) as follows :
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://xmlns.oracle.com/oracleas/schema/transaction-manager-10_0.xsd"
transaction-timeout="600"
max-concurrent-transactions="-1" >

• Change all occurances of transaction-timeout in $J2EE_HOME/application-deployments/orabpel/ejb_ob_engine/orion-ejb-jar.xml to 600.

• Login to BPEL Console, and from “Manage Domains” change the following property :
syncMaxWaitTime to 600

BPEL Exception : ORABPEL-05002

Error ORABPEL-05002 in domain log
Failed to handle dispatch message ... exception ORABPEL-05002Message handle error.An exception occurred while attempting to process the message "com.collaxa.cube.engine.dispatch.message.invoke.InvokeInstanceMessage";the exception is: Transaction was rolled back: timed out;nested exception is: java.rmi.RemoteException:No Exception - originate from:java.lang.Exception: No Exception - originate from:; nested exception is: java.lang.Exception: No Exception - originate from:

The root cause of this problem is poor performance of the dehydration store database. Following are the possible ways to overcome such problem:
1.If you are using Oracle Lite as dehydration store, switch to use Oracle 9i or 10g.( Better use 10g above version 10.2.0.1)
2. Increase the maxConnection number of the BPELServerDataSource. OC4J has too few available connections to the dehydration database.Location: /j2ee/home/config/data-sources.xml
(NOTE: If you are using10.1.3.4, then you need not worry because it is already set as maximum by default)
3. Size of message is too big. Two ways to deal with this problem:
a. Increase the transaction timeoutLocation :/j2ee/home/config/server.xml
b. Decrease the auditLevel from BPELConsole. It will reduce the amount of data saved to the dehydration store.Location: BPEL Console -> Manage BPEL Domain -> Configurations tab.

I hope this will solve your problem

Rollbacking EBS API's using BPEL

We are performing multiple activities in sequence( updating a database using database adapter , calling a Oracle EBS API using oracle applications adapter and inserting data in a queue using JMS adapter or AQ adapter etc.) Now our requirement is to roll back all the activities if any of the above mentioned activity fails.Solution: To achieve this we need to configure our BPEL process for JCA-XA transactions. This is requires following set up:

1. Set up JNDI name in oc4j-ra.xml and datasources.xml2. Make Changes in BPEL.xml to make your bpel to participate in transaction.For this we need to set the property transaction of BPEL and all partner links to participate as shown below.


<>
< id="TestTransaction2" src="TestTransaction2.bpel">
<>< name="client">
< name="wsdlLocation">TestTransaction2.wsdl

< name="TestAccount">
< name="wsdlLocation">TestAccount.wsdl
< /property>
< name="retryInterval">60< /property>
< name="transaction">participate< /property>
< /partnerLinkBinding>
< name="TestLocation">
< name="wsdlLocation">TestLocation.wsdl< /property>
< name="retryInterval">60< /property>
< name="transaction">participate< /property>
< /partnerLinkBinding>
< name="OA_Rollback">
< name="wsdlLocation">OA_Rollback.wsdl< /property>
< name="retryInterval">60< /property>
participate< /property>
< /partnerLinkBinding>
< /partnerLinkBindings>
<>
< faultpolicy="TestConditionPolicy">
< /faultPolicyBindings>
<>< name="transaction" encryption="plaintext">participate< /property>
< /configurations>
< /BPELPr>

Here we need to make sure that fault policy applied to BPEL is not sending your BPEL to manual intervention. Because while sending the BPEL on manual intervention all the activities gets committed so rollback will not be possible in that case.
Once above setup is done we are good to go. Now we have two possibilities:

1. BPEL is not configured to catch the faults thrown.
2. BPEL is configured to catch the faults thrown.

BPEL is not configured to catch the fault thrown:In this case as soon as the fault is thrown , all the activities automatically gets rolled back.
Disadvantage: Here the disadvantage is all the activities which are part of the transaction will get rolled back and we will not be able to see anything on BPEL console. It will appear that BPEL instance was never created.
BPEL is configured to catch the faults thrown
In this we have to explicitly call the rollback. This can be done in two ways:

1. Explicitly throwing the bpelx:rollbackFault
< name="Throw_1" faultname="bpelx:rollback">
Once the error is caught by the fault handler we can do the activities we want to and after that we can throw the rollback fault which will result in to the rollback of all activities part of the rolled back transaction.
In this case also disadvantage is we will not be able to see anything on BPELCONSOLE.

2. Calling a procedure containing the rollback statement.
This procedure will look like following
PROCEDURE "XXDPI_ROLLBACK" AS
BEGIN
rollback;
END;
Now once the error is caught you can explicitly call this procedure to cause the rollback of statements executed on a particular database. So if there are multiple databases, you will have to multiple such procedures.

Advantage: Advantage of this approach is that your BPEL instance still remains there and u can easily see what has actually happened and all the database statements executed also gets roll backed.

Renaming a deployed BPEL process

1. Open the bpel.xml file in your Jdeveloper.
2. Inside the file, go to the ‘BPEL Process Id’ and ‘src’ tag and change those values to the desired name and save it.
3. Redeploy the BPEL Process on the same server and you will see its new name in the BPEL Console.