Compilation Error in BPEL- XML parsing failed because ""

While you compile BPEL processes you may sometimes get an error like

[Error ORABPEL-10902]: compilation failed
[Description]: in .... XML parsing failed because "". [Potential fix]: n/a.

Solution
For getting the line number in which error occurs you need to add verbose="true" to the bpelc command in the build.xml file

<target name="compile">
<bpelc input="${process.dir}/bpel/bpel.xml" out="${process.dir}/output"
rev="${rev}" verbose="true" home="${bpel.home}"/>
</target>

Then execute the target from Jdev.You will get detailed steps of compilation and the line in which validation has failed.

ESB synchronous v/s asynchronous routing rule

I was always under the impression that for both synchronous and asynchronous ESB routing service, different flows based on different routing rules are independent of whether each flow is successful or not. So to clear my understanding I took help from my colleague Anindya. He came up with a simple test scenario to differentiate between synchronous & asynchronous routing rules.

First he tested the synchronous ESB scenario

There is a file adapter reading the input, and then it will invoke our Routing service which will have 2 routing rules. One rule will call an outbound DBAdapter to insert to a table and other the outbound File adapter to write to a file. Both routing rules are not having any filter conditions.

The ESB process will look like this

In the first run it inserts 2 rows into database

In this case CUSTID is the primary key.

So a rerun with same input will result in a primary key violation and error condition in DBAdapter.

The output in ESB console is

Since our routing rule was synchronous operation, the failure at one of the endpoints brings the process to a standstill there by throwing back the error to the invoking service. The parallel routing rule is not executed.

Second test with Asynchronous ESB scenario

Just modify the ESB process by changing the routing rule to Asynchronous operation and initiate the ESB process using same input. You will see that our second routing rule executes independent of whether other routing rule is successful or not. In effect error in one routing rule will not affect other routing rules and there for it is always wise to use asynchronous routing rules for multiple destinations.

Hope this help J