Ramkumar Menon's Blog

I had a simple BPEL on Weblogic install - and was looking for a place to host some static XML content on the server. On OC4J, it was simple - just dump the content in the appropriate directories under htdocs, and you are done.
In a simple WLS install like the one I have, it doesn't work that way.
So I created a simple Web Project, added all my XML contents into it, and deployed the ear file into WLS, just like any J2EE application. Here you go - you can now access all the hosted content at the contextURI that you specified at deployment time!

Well, I use JDeveloper 10.1.3.3 - and needed to create and deploy a simple Java Web Service into WLS. I tried using the standard deploy-to-weblogic app server connection - but alas! - I ran into some deployment issues while deploying JWS from JDev 10.1.3.3 to WLS 9.2. The same error repeats if I pick up the ear file and deploy it directly from the WLS admin console.

But hey, there was a simple way to get it done.
Just use the WLS service generation build scripts - it will do the job just as well.

Here is a snippet of the build script that I used to deploy my WS onto WLS.

<project name="BuildHelloWorldService" default="ear">
<target name="ear">
<servicegen destEar="ears/HelloWorldService.ear" warName="HelloWorldService.war" contextURI="hello">
<classpath>
<pathelement path="${java.class.path}" />
<pathelement location="D:\oraBPEL\bpel\lib\orabpel.jar"/>
<pathelement location="D:\oraBPEL\bpel\lib\xmlparserv2.jar"/>
</classpath>
<service targetNamespace="http://xmlns.hello.com/"
serviceURI="/HelloWorldService"
generateTypes="True"
expandMethods="True"
javaClassComponents="com.hello.HelloWorld,com.hello.HelloWorldUtil,com.hello.util.HelloUtil"
serviceName="HelloWorldService"
style="document">
</service>
</servicegen>
</target>

Note that servicegen is an 8.1 release ant task. WLS 9.2 has updated ant tasks that you can leverage to build services from your java classes. I used it only for my local testing.
You can find detailed information on useful ant tasks for service generation, client stub generation and others on the WLS 9.2 documentation page.

http://e-docs.bea.com/wls/docs92/webserv/anttasks.html

Problem observed on BPEL PM 10.1.3.3.

I developed a simple BPEL process that uses BPEL correlation to receive callbacks into the process.
For this purpose, I altered the process WSDL to add one more operation.
The initiating operation was named "processOrder". I decided to name the callback operation as "processOrderCallback".
I promptly defined two properties on the correlation set and provided aliases for both for the invocation and callback messages.
When I invoke the process, it throws up a CubeException and goes to recovery mode.
Why? Possibly because the callback operation name is a "superstring" of the invocation operation name.
When I looked at the logs, I could see that the engine was trying to evaluate the correlation query for the callback on the initiating message.
What I did next - just renamed the operation to "receiveOrderCallback" and re-ran the instance.
Bingo! - it worked.

Observed on BPEL PM 10.1.3.3.

We had a set of master-detail tables that had one of the columns as a CLOB, and a process that is polling for new or changed records on these tables.
When the process is deployed, the endpoint activation fails complaining "Expected - CLOB".

The reason is that when the toplink query is generated, it generates a DISTINCT clause in the select statement, and DISTINCT clause cannot be applied if one of the return columns are CLOBs.
The solution - Open up the toplink mappings XML file and update the batch-attribute reading value to "false" from "true".

We figured this out from the Troubleshooting and Workarounds section of the Adapters documentation.
I am inlining the relvant snippet from the document for convenience.

A SELECT returning CLOB values must not use the DISTINCT clause. The simplest way to avoid DISTINCT is to disable batch attribute reading from A to B. Batch reading is a performance enhancement that attempts to simultaneously read all Bs of all previously queried As. This query uses a DISTINCT clause. Use joined reading instead, or neither joined reading nor batch attribute reading.

Because both DISTINCT and CLOBs are common, you may see this problem in other scenarios. For example, an expression like the following uses a DISTINCT clause:

SELECT DISTINCT dept.* from Department dept, Employee emp WHERE ((dept.ID =
emp.DEPTNO) and (emp.name = 'Bob Smith'));