Helping Oracle Support to help you
By clemens.utschig on May 22, 2009
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 10.1.3.3 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 10.1.3.4.0
Build time: Sat Dec 06 02:39:55 PST 2008
Build type: release
Source tag: PCBPEL_10.1.3.4.0MLR3_GENERIC_RELEASE
What does the above mean? you run base version 10.1.3.4.0 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.
-> Will show you the execution of bpel activities in the log (very helpful in case of 10.1.3.3 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.
-> 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
-> 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
-> 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 10.1.3.4 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 :)