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 optionsCons * 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.
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 runtimeCons * 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.
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 propertyAs shown below, I can enter the following text in Runner property of jDeveloper
4. Use the FND Debug Logging feature, to see debug messages on the OA Framework Screen itselfThe debug messages can either been seen on the same screen or those can be spooled into a table named FND_LOG_MESSAGESIn 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.
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.
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
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 jDeveloperCons * 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.
pageContext.raiseDeveloperException(new OAException(“test text here”, OAException.INFORMATION));
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 optionsCons * 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.
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 runtimeCons * 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.
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 propertyAs shown below, I can enter the following text in Runner property of jDeveloper
4. Use the FND Debug Logging feature, to see debug messages on the OA Framework Screen itselfThe debug messages can either been seen on the same screen or those can be spooled into a table named FND_LOG_MESSAGESIn 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.
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.
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
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 jDeveloperCons * 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.
pageContext.raiseDeveloperException(new OAException(“test text here”, OAException.INFORMATION));
Comments