FND Debug Log - Debugging Oracle Apps code

There was a time when every individual Oracle Applications module used its own debugging technique.

But this is changing now, thanks to FND Logging (In 11.5.10 ), hence I would like to share knowledge on this topic.

What is the use of FND Debug Log?
1. It helps you pinpoint the cause of error in standard Oracle Code, by making debug messages to appear in a centralized table named FND_LOG_MESSAGES.
2. You can design and build your custom extensions in a manner that can easily be debugged. This can be done by calling Oracle delivered API’s in your custom code.

Where is the debug message stored, once the logging is turned on?
Debug messages are stored in a table called FND_LOG_MESSAGES
A program written in any technology, either form, or report, or pl/sql or java concurrent program or OAF…all their debug messages will be stored in fnd_log_messages.


How to debug the issue being faced in Oracle Application?
Step 1 Set the following profile options at your user level(your fnd_user)
FND: Debug Log Level
Following possible values are available, but I suggest you set this to "Statement" level when debugging code.
LEVEL_UNEXPECTED : Internal Level Id is 6
LEVEL_ERROR : Internal Level Id is 5
LEVEL_EXCEPTION : Internal Level Id is 4
LEVEL_EVENT : Internal Level Id is 3
LEVEL_PROCEDURE : Internal Level Id is 2
LEVEL_STATEMENT : Internal Level Id is 1

FND: Debug Log Enabled
Set this profile to Yes

FND: Debug Log Module
Set this to %


Step 2
Login to the application and reproduce the problem.

Step 3
SELECT *
FROM fnd_log_messages
WHERE user_id = 209122 /*your FND_USER user_id here*/
AND TIMESTAMP > SYSDATE - .3
ORDER BY log_sequence DESC /*note the order by clause here*/

The result of this select statement will provide the list of all the debug messages, on top will appear the most recent debug messages..


Why should I setup the module name to %, in profile option?
You can set this to po%, if you know for sure that the error was caused by code written in po module. However po code might be internally calling hr code which might inturn be calling fnd code.
Hence it’s best to set this profile value as %.
You may also use comma delimited values i.e po%,hr%,fnd%


Why must I bother debugging Oracle's Standard code when I can quickly raise a tar.
If the issue is with Standard Oracle Code, first thing you must do is to search into Metalink. However having the debug information on error helps your searching ability further. Uploading the debug messages upfront during Tar creation will also help Oracle speedily understand and fix your issues.


Why to set the profile option to statement level?
This profile option has following main levels.-
Error
Warning
Procedure
Statement

I like setting this to "Statement" level as it extracts debug messages at all levels, in one glance. You can latter filter those debug messages by using below SQL for example
select * from fnd_log_messages where user_id = 111 and LOG_LEVEL =5


What if the piece of code causing the error is not appearing in fnd_log_messages?
This is very much possible. The fnd_log_messages might have helped you get close to the culprit piece of code , but may not be able to pinpoint the error as there may not be enough debug messages implanted by Oracle.

You can do one of the below:-
A. Run the database sql trace for the session with bind variables and see the last meaningful SQL statement in the raw trace file.
Please note that PL/SQL statements will not appear in trace, only the SQL Statements will appear, hence you may consider option (b) below
B. Add your own debug messages to the pl/sql code that was delivered by oracle, which you suspect is causing problem. This is a temporary change, and must only be done on development environment, NEVER DO THIS CHANGE ON PRODUCTION.


The size of table FND_LOG_MESSAGES will keep on increasing?
You can run concurrent program “Purge Debug Log and System Alerts”.


I have written a pl/sql concurrent process to interface Purchase Orders from 3rd Party System. How will add debug messages?
fnd_log.STRING(log_level => fnd_log.level_statement
,module => 'xxpo.packagename.procedurename'
,message => 'debug message here');


Will the above debug command create an entry into fnd_log_messages ?
Debug records will be created in fnd_log_messages if and only if you run the interface program after setting the profile options as suggested above.


What if a rollback occurs due to unhandled exception. Will the inserts done to fnd_log_messages be lost?
fnd_log.string eventually calls procedure FND_LOG.STRING_UNCHECKED_INTERNAL2. This procedure uses pragma AUTONOMOUS_TRANSACTION with a commit.
Hence your debug messages will not be lost despite a rollback in parent session.


What if an exception is incurred within the Debug Logging API itself?
Oracle takes well care of this by handling the WHEN OTHERS exception.
It is evident from below Oracle Code for debug API
PROCEDURE STRING(LOG_LEVEL IN NUMBER,
MODULE IN VARCHAR2,
MESSAGE IN VARCHAR2) is

begin
/* Short circuit if logging not turned on at this level */
if (LOG_LEVEL <>
return;
end if;

if FND_LOG_REPOSITORY.CHECK_ACCESS_INTERNAL (MODULE, LOG_LEVEL) then
FND_LOG_REPOSITORY.STR_UNCHKED_INT_WITH_CONTEXT(
LOG_LEVEL => LOG_LEVEL,
MODULE => MODULE,
MESSAGE_TEXT => MESSAGE);
end if;

exception
when others then
NULL; /* supress the exception */
end;

HAPPY LEARNING!

Reducing Patching Downtimes via Shared Apps File Systems

I had a chance conversation with an Apps sysadmin late in the evening at the Collaborate conference. He wearily noted that he had to somehow cover increasing maintenance costs with reduced levels of staffing. The conversation suggested that our support for shared E-Business Suite application tier file systems may be one of our better-kept secrets. If you haven't come across this yet, here's a way of reducing the amount of time that you spend patching.

Scaling Up with Load-Balancers

When your E-Business Suite user base grows beyond a certain size, it's likely that you'll look into deploying multiple application servers in a load-balanced pool of nodes. Your deployment topology might look like this:

Regardless of whether you're running Release 11i or 12, each of these
nodes would need its own disk space and would to be maintained and
patched separately. What a pain.

Different File System Structures in Release 11i and 12

In Release 11i, the Applications tier file system includes the APPL_TOP, the COMMON_TOP, and the Applications technology stack (8.0.6 and iAS ORACLE_HOMEs). In a traditional deployment, each one of these application servers would have its own Applications file system, like this:

In Release 12, the Applications tier file system includes the APPL_TOP, the COMMON_TOP, and the Applications technology stack (10.1.2 and 10.1.3 ORACLE_HOMEs), plus a new INST_TOP. Each node would have the following:

Enter the Shared Application Tier File System

For Release 11i, starting with 11.5.10, it's possible to put the Applications tier file system on a shared disk resource mounted to each Application tier server node in the system, like this:

Similarly, in Release 12, you could put the Applications tier file system on a shared disk resource mounted to each Application tier server node, like this:

Migrating to Shared File Systems

There are a few prerequisites:

• Different nodes must be running the same operating system and the same O/S patches
  
• You must be on a UNIX platform (Windows doesn't support shared file systems)

Certification of Shared File System Solutions

If you've gotten to this point, you're probably wondering, "Is my _____ SAN/NAS shared file system software certified with the E-Business Suite?" File system solutions that customers have recently asked about include:

• Sun StorageTek QFS or Sun Solaris ZFS
  
• Red Hat Linux Global File System
• Symantec / VERITAS File System (VxFS)
  
• Network File System (NFS) mounted disk or a disk array

Supported but not Certified

The short answer is that your shared file system solution is supported but not certified with the E-Business Suite, for either Release 11i or 12. Remember that there's a key distinction between support and certification, which I've covered in detail in this article:

• Certification & Support for Third-Party Products

The complexities of whatever shared disk resource management solution that you're using must be transparent to the E-Business Suite. Aside from that, there aren't any special requirements for shared disk resources. They can be local to the server or on a standalone disk array.

Almost Irresistible

Regardless of which E-Business Suite release you're running, the main advantage of using an Application shared file system is simplicity and ease of patching: when
you apply patches or changes to the shared disk resource,
they're immediately visible on all application tier server nodes. You
patch in a single place and deploy those changes across multiple
servers. You save disk space for each additional application node you
deploy, and it's easier to deploy additional nodes, too.

If you've been wondering how to squeeze more productivity out a packed roster of administration activities, I'd recommend setting up a testbed to try this out. Feel free to post a comment with your experiences with this; I'll make sure your feedback gets back our team.

Related

• Sharing the Application Tier File System in Oracle E-Business Suite 11i (Metalink Note 233428.1)
• Sharing the Application Tier File System in Oracle E-Business Suite Release 12 (Metalink Note 384248.1)
  
• In-Depth: Load-Balancing E-Business Suite Environments
• Advanced Configurations and Topologies for Enterprise Deployments of E-Business Suite 11i (Note 217368.1)
• Using Load-Balancers with Oracle E-Business Suite Release 12 (Metalink Note 380489.1)

HAPPY LEARNING!

Which is Better: Forms Servlet or Socket Mode?

Many products within the Oracle E-Business Suite have screens that are built with Oracle Forms. Oracle Forms can be run in either servlet mode or socket mode. Apps 11i is based on Forms 6i and is configured to run in socket mode by default. Apps 12 is based on Forms 10g and is configured to run in servlet mode by default. What are these modes, and which is better?

What is Forms Servlet Mode?

The Forms Listener Servlet is a Java servlet that delivers the ability to run Oracle Forms applications over HTTP and HTTPS connections. It manages the creation of a Forms Server Runtime process for each client, as well as network communications between the client and its associated Forms Server Runtime process.

The desktop client sends HTTP requests and receives HTTP responses from the web server. The HTTP Listener on the web server acts as the network endpoint for the client, keeping other servers and ports from being exposed at the firewall.

Forms listener servlet diagram showing firewalls desktop client and oc4j container on application tier

What is Forms Socket Mode?

Initial releases of the Oracle Forms Server product used a simple method for connecting the client to the server. The connection from the desktop client to the Forms Listener process was accomplished using a direct socket connection. The direct socket connection mode was suitable for companies providing thin client access to Forms applications within their corporate local area networks. For the direct socket connection mode, the client had to be able to see the server and had to have permission to establish a direct network connection.

Although the direct socket connection mode is perfectly suited for deployments within a company’s internal network, it's not the best choice for application deployment via unsecured network paths via the Internet. A company connected to the Internet typically employs a strict policy defining the types of network connections that can be made by Internet clients to secure corporate networks. Permitting a direct socket connection from an external client exposes the company to potential risk because the true identity of the client can be hard to determine.

Servlet Mode Advantages

1. HTTP and HTTPS traffic is easily recognizable by routers, while socket mode communications is generally considered suspect and treated on an exception basis.
2. Existing networking hardware can be used to support basic functions such as load-balancing and packet encryption for network transit.
3. More resilient to network and firewall reconfigurations.
4. More robust: servlet connections can be reestablished if network connections drop unexpectedly for Forms, Framework, and JSP-based pages.
5. Is the only supported method for generic Oracle Forms customers, and therefore is more thoroughly tested by the Forms and E-Business Suite product groups.
6. Performance traffic can be monitored via tools like Oracle Real User Experience Insight (RUEI).
7. Socket mode is not supported on Windows-based server platforms.

Socket Mode Advantages

1. Uses up to 40% less bandwidth than Forms servlet mode. This may be perceived by Wide Area Network (WAN) users as causing slower responsiveness, depending upon network latency.
2. Uses fewer application-tier JVM resources than servlet mode, due to fewer TCP turns and lack of overhead associated with HTTP POST handling.

Switching Apps Deployments Between Modes

Due to its numerous advantages, Forms servlet mode is the preferred and recommended deployment model for Forms on the web.

There may be circumstances where you need to switch between the default Forms modes. You might wish to switch your Oracle E-Business Suite Release 12 environment to socket mode to improve performance or reduce network load. You might wish to switch your Apps 11i environment to servlet mode as part of your rollout to external web-based end-users outside of your organization.

If you're running Apps 11i and would like to switch to servlet mode, see:

* Using Forms Listener Servlet with Oracle Applications 11i (Note 201340.1)

If you're running Apps 12 and would like to switch to socket mode, see:

* Using Forms Socket Mode in Oracle Applications Release 12 (Note 384241.1)


Happy Learning !