Helping Oracle Support to help you

Given my involvement with many customers over the last years, I guess I have seen countless tars and bugs filed internally as well as by our customers.

Sometimes even I have trouble understanding what the problem is and hence help diagnosing it becomes more a journey than a fast paced effort - so I figured I would come up with a list of thoughts of how you can help support to diagnose issues quicker and eventually, in case you hit a bug, get a fix for it faster.

a) Rather than "my fileadapter does not work" - be specific - e.g. "My async BPEL process is triggered by a polling file adapter with strategy XYZ (e.g. delete after read). Although the log says it is activated, the file is never read and no process instance started

b) I am running on BPEL Process Manager is correct, but will likely cause "which exact version are you running on". This can be easily found by running $OH/bpel/bin/obversion.bat/sh


Oracle BPEL Server version
Build: 0
Build time: Sat Dec 06 02:39:55 PST 2008
Build type: release
Source tag: PCBPEL_10.

What does the above mean? you run base version with MLR 3 (Bundle patch 3) on top of it.

c) Providing the right information versus providing all information.
I cannot recall how often I get .tar/.rar files with gigabytes of logs. While this is often the first attempt to capture the error and the surrounding context, it becomes extremely difficult to analyze what's really going on. Hence here are the loggers you need to know.

.collaxa.cube.engine.bpel -> Will show you the execution of bpel activities in the log (very helpful in case of when your instance is rolled back and you might want to understand why) -> All inbound traffic (invoke, as callback) goes through the delivery service layer (deliverybean, deliveryhandler, deliveryservice, deliveryhelper). Logically here is the resolution of correlation sets, callback attempts that are made, you can find out which process (version, and operation) is called.

.collaxa.cube.engine.dispatch -> The dispatcher layer is at the core of the bpel engine, and every request (e.g. to activate a scope, or start a process runs through the dispatch layer, by calling endrequest in the cube engine). If you need a detailed view of messages that are sent around (e.g. to expire or callback an activity), this is the place to go

.collaxa.cube.xml -> This one comes in handy for ALL xml traffic. As the bpel engine works on top of dom trees, especially for non working xpath queries, this one will reveal what's wrong -> Every call from the BPEL engine (or your process) goes through the ws(if) handlers, and specifically through the wsinvocationmanager stack. Hence turning this logger on will show you - on the inbound side - what we are doing with the soap message that you post and on the outbound side everything until the message leaves the engine

.collaxa.cube.activation-> In case you are using inbound adapters, those are managed by the adapter framework, and configured through activation agents (each of those correlates to a thread spawned for inbound messages). Hence for inbound reading, polling issues - that is a good one.

d) The famous testcase
In most cases (with a localized problem) a testcase is the best thing you can get us to help figuring out whether you run into a bug or not. Especially on we added quite a lot of enhancements to the console (including export process artifact). If you want to help us the step further, use a bpelTest testcase, so we can verify the fix immediately and also add it in a matter of minutes to our internal testsuites for the engine.

- so much for my first post in years .. especially with 11g regular posting is back :)


Hi Clemens, good to have you back in the field! Awesome. Cheers, Mike

Posted by Mike van Alst on June 15, 2009 at 08:04 PM PDT #

great view. i think the same

Posted by Dru on December 09, 2009 at 11:30 PM PST #

Post a Comment:
  • HTML Syntax: NOT allowed

Tips and tricks straight from the SOA / BPM development team at Oracle HQ


« February 2015