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

Deployment Framework in SOA Suite 10.1.3.4

One of the coolest features in BPEL 10.1.3.4 is the deployment framework which makes the job of moving processes between dev, test and production environments much easier. Modifying the bpel.xml file or altering descriptors through the console provide a degree of customization for different environments, but it is all done on a single property at a time basis and requires a lot of work for each environment, especially when it is considered that individual WSDL files may also need to be updated. There is a better way in SOA Suite 10.1.3.4; the deployment framework.
The deployment framework combines the BPEL suitcase with a deployment plan that updates multiple files in the BPEL suitcase with the correct values for the deployment environment. Different deployment plans can be created and maintained for each deployment plan.

It is possible to generate a template BPEL deployment plan from a BPEL suitcase which can then be customized and used with the base BPEL suitcase at deployment time to update the various URLs and properties.
The steps to customize the BPEL Suitcase for each environment are as follows.
· Create a deployment template from the BPEL project or suitcase which will be used as the basis for the deployment plans.
· Create a deployment plan based on the template for each target environment.
· Attach the appropriate deployment plan to the BPEL suitcase or project prior to deploying in the target environment.
· Deploy the BPEL process into the target environment.

To create a deployment template we need to add the following commands to the build.xml ant file that is built by JDeveloper and found in the Resources folder of our BPEL project.


This creates two new ant targets, generate_plan_from_project and generate_plan_from_suitcase. These both create a template deployment plan, either directly from the project files, or from a generated suitcase. A BPEL suitcase is only generated when a BPEL project is deployed or when the project is “made”, so if using the option to generate from a suitcase it is necessary to ensure that the suitcase has previously been created. If the suitcase generated is a revision other than 1.0 then it is necessary to set the revision property in the build.properties file that is found in the Resources folder of the BPEL project in JDeveloper.

# Change below if deploying with process revision other than 1.0
rev = 1.1

The generateplan command in ant uses four attributes
· suitecase or descfile is the source information for the deployment plan.
· planfile is the location of the planfile template to be generated.
· overwrite will replace any existing planfile of the same name.
· verbose turns up the level of reporting.
A sample deployment plan template is shown below. Note the use of two elements:
· is used to replace the value of a property within a specific part of the bpel.xml
· is used to for a string in WSDL and XSD files and it with another string.

Creating a Deployment Plan
Having created a template we can use this to create deployment plans for each specific environment. We do this by creating a copy of the deployment plan by selecting Save As from the file menu in JDeveloper and then editing the and tags to match our target environment.
We will search and replace all instances of our local development machine hostname, w2k3, with the name of our test server, testserver, across wsdl and xsd files. To do this we modify the search and replace elements.

This will cause the BPEL process manager to search all WSDL and schema files “*” in the suitcase at deployment time and replace the string “w2k3” with the string “testserver”. Note that it is possible to have multiple elements.

Attaching a Deployment Plan to a BPEL Suitcase
Having created and saved a deployment plan specific for one or more specific environments we will want to deploy our process into an environment. Before doing this we must first attach the specific deployment plan to the BPEL suitcase. We do this using the following ant command.
<target name="attach_plan">

This will create a file bpeldeployplan.xml in the BPEL suitcase. This is the deployment plan that will be used at deployment time by the BPEL process manager. Note that the name of the deployment plan to use is encoded as an Ant property planfile that must be set in the build.xml. Once attached the deployment plan will be executed when the BPEL suitcase is deployed.

Modifying Ant to Use Deployment Plan
In addition to adding the two tasks above to the build.xml file, it is possible to add the attachment of the plan file as part of the regular deploy process by modifying the dependencies of the process-deploy task by adding the attach_plan dependency after the compile dependency.

Now when building and deploying with ant the deployment plan will be attached to the suitcase before the suitcase is deployed to the target environment. This allows us to provide a different deployment plan for each environment, which can then be deployed from the command line in a reproducible fashion.

Summary
The deployment plans allow a lot of automation in the move from development to production, and because they can be used with editable files and command lines they are easy to include in the version control systems and automated build environments. Congratulations to the BPEL developers on a useful piece of functionality that appeals to those responsible for ensuring consistency of environments rather than developers.

Cheers
Ayush

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.