Ramkumar Menon

Subscribe to Ramkumar Menon feed
Oracle Blogs
Updated: 5 days 19 hours ago

Calling Web Services with HTTP Basic Authentication from BPEL

Wed, 2010-03-31 17:01

Are you using BPEL and hunting for the property names in the partnerlinkBindings that will work for outbound HTTP Basic Authentication?
Here's the answer.

<partnerLinkBinding ...>

  <property name="basicHeaders">credentials</property>

  <property name="basicUsername">WhoAmI</property>

  <property name="basicPassword">thatsASecret</property>


The drop down options in JDeveloper dont seem to work.

Writing Non-ASCII Content into MQ

Fri, 2009-07-17 11:06

I had Arabic characters coming in from a partner webservice that I needed to write out to an MQ.
The default version was not writing out data into the MQ as expected - the Arabic data was being written out as a bunch of unreadable characters.
Following this, I followed the steps mentioned in the document http://download.oracle.com/docs/cd/E12524_01/relnotes.1013/e12523/adapters.htm#CHDDCAGA.
That did the trick!

Debugging root cause of MQ related Errors

Mon, 2009-06-29 16:25

I ran into a few MQ errors. It helped me to take a look at $MQ_INSTALL_DIR\WebSphereMQ\Qmgrs\<QueueManagerName>\errors directory to see whats going on!

DBAdapter - java.sql.SQLException: ORA-00932: inconsistent datatypes: expected - got CLOB

Thu, 2009-03-05 17:49

Observed on BPEL PM

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'));

Tackling &quot;Failed to evaluate correlation query&quot;

Tue, 2009-03-03 19:59

Problem observed on BPEL PM

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.