Hi Vishal,

Each method of debugging OA Framework pages has its own merits, and hence you must apply one of the techniques that suites the most to your situation.


1. Use System.out.println
When running the OA Framework pages from jDeveloper itself, you can write debug messages using System.out.println.
These debug messages will be displayed in the console of jDeveloper.
Pro
* Ease of use, as you simply enter free text messages
* Debug messages simply appear without the need to set any profile options
Cons
* Too much typing, which can be avoided when using the debugger of jDeveloper.
* You can debug only those pieces of code that you suspect are causing the error. Unlike to this approach, using jDeveloper debugging, breakpoints can be set for exceptions/classes as well.

Click here to see a quick working demo for debuging OA Framework using System.out.println





2. Use jDeveloper inbuilt Debugger
This happens to be my favourite mechanism to debug OA Framework Pages, for the following reasons
Pro
* To get started just one breakpoint is required, as more and more breakpoints can be added in runtime itself.
* You can set generic breakpoints, for example, you can set breakpoint on exceptions, which will take you to the exact line of code from where the exception was being raised
* jDeveloper makes it possible to try different scenarios, for example, you can change the variable values at runtime
Cons
* Given that you do not have source code of base classes, debugger usually dives into those classes without giving many visible details. One may find this annoying.
* Some versions of OAFwk raise exceptions[caught internally by Oracle] like Classcast exception even before the page renders.
Debugger often pauses when those exceptions are raised. This can be overcome by clicking on “resume button” of debugger.

Click here for demo of debugging via jdeveloper debugger
The demo in above link also shows how you can change the variable values at runtime.

Click here for demo of using debugger to trap classcast exceptions
The demo in above link shows how you can set breakpoints for specific Exceptions that can be raised from OA Framework Pages




3. Use jDeveloper debugging feature, by changing Java VM runtime option Djbo.debugoutput
Lets say, for this exercise, I wish to find the exact piece of SQL Statement that my screen fires, when doing an update.
In order to do so, we can append text -Djbo.debugoutput=console to runner property
As shown below, I can enter the following text in Runner property of jDeveloper


Have a look at this demo to visually see this debugging technique



4. Use the FND Debug Logging feature, to see debug messages on the OA Framework Screen itself
The debug messages can either been seen on the same screen or those can be spooled into a table named FND_LOG_MESSAGES
In jDeveloper, you must include OADiagnostic in the “Run Options”.
This is effectively similar to setting profile option “FND Diagnostics” to Yes in eBusiness Suite.
Using this option, you will be able to click on Diagnostics to enable On-Screen display of debug messages.

Pro
* The debug messages seen using this technique are exactly the same as the debug messages seen in eBusiness Suite, once FND%Log% profile options are available.
* There is tremendous amount of debug messages in FND classes given by Oracle.
* This approach is the most useful when investigating red coloured error message “Please contact your system administrator”
Cons
* Prior to 11.5.10, this option might bring your application session down to its knee. But I notice from 11.5.10 onwards, these debug messages are captured very efficiently.
* The debugging is limited to the debug messages in place. To maximise the listing of debug messages, try to use statement level debugging.

Click here for the demo of doing on-screen debugging for OA Framework pages





5. SQL Trace for Oracle Framework Sessions
We often use this technique for tracing the SQL statements executed by Oracle Forms or by concurrent programs.
The same technique can be applied to OA Framework too.
You can run the SQL*Trace either when running the application pages from “OA Framework” or when running OA Framework pages from within eBusiness Suite.
For jDev, ensure that OA Diagnostics has been included in jDeveloper Project property “Run Options”.
Alternately ensure that profile option “FND Diagnostics” has been setup against your username.

Click here for the demo of SQL*Trace on OA Framework Pages






6. Use FND Logging profile options to capture debug messages into a table named FND_LOG_MESSAGES
Use the FND Debug Logging feature, to see debug messages.
The debug messages can either been seen on the same screen or those can be spooled into a table named FND_LOG_MESSAGES

Please click on this link to see an article on FND Logging





7. Use raiseDeveloperException.
I had all but forgotten about this technique, until I discussed this paper with Mr Senthil prior to its publication.
He reminded of raiseDeveloperException. You can raise debug messages to be displayed in OA Framework pages using raiseDeveloperException.
By doing so, your debug messages will be visible onto the top portion of the screen.
This is very similar to System.out.println, however the key difference being that raiseDeveloperException displays the debug message on top portion of the page itself.
Pro
* Ease of use, as you simply enter free text messages
* Debug messages simply appear without the need to set any profile options
* Debug messages appear on the top portion of the page and hence the ease of visibility when testing your code in jDeveloper
Cons
* Too much typing, which can be avoided when using the debugger of jDev.
* You can debug only those pieces of code that you suspect are causing the error.

Click here for the working demo of this technique to debug OA Framework Page.