Tuesday, May 4, 2010

Not able to create new database connection: FNDSECURITY_APPL_LOGIN_FAILED

We were recently handed over a cloned E-Business Suite 11.5.10.2 instance running on Solaris 64-bit. We just applied the April 2010 CPU patches, and reran AutoConfig (via ‘adautocfg.sh’) (long story) but ran into some funky behavior when trying to hit any of the login pages.

Problem:
  1. Navigating to http://hostname:8000/OA_HTML/AppsLocalLogin.jsp returned an HTTP-500 error
  2. Navigating to http://hostname:8000/oa_servlets/AppsLogin returned a blank page (i.e., empty white page)
  3. Navigating to http://hostname:8000/servlets/weboam/oam/oamLogin (OAM) returned an HTTP-500 error
No errors were showing up in either the Apache “error_logs” or “mod_jserv.log”.

After enabling Jserv debugging, the following showed up in “mod_serv.log” when trying to access the Oracle Applications Manager login page:

[04/05/2010 09:49:03:180] (ERROR) ajp12: Servlet Error: java.lang.ExceptionInInitializerError: null
[04/05/2010 09:49:03:181] (ERROR) an error returned handling request via protocol “ajpv12″
[04/05/2010 09:49:03:181] (ERROR) balance: 25521 internal servlet error in server hostname:20521
[04/05/2010 09:49:03:182] (ERROR) an error returned handling request via protocol “balance”

Not much help since we couldn’t find much info on the “ExceptionInInitializationError” exception.

Investigation:

Fortunately, JVM logging was enabled and there were JVM standard out (e.g., OACoreGroup.0.stdout) and standard error logs (e.g., OACoreGroup.0.stderr) in $IAS_ORACLE_HOME/Apache/Jserv/logs/jvm.

The errors showed:

Exception in static block of jtf.cache.appsimpl.AppsCacheLogger. Stack trace is: oracle.apps.fnd.common.AppsException: oracle.apps.fnd.common.PoolException: Not able to create new database connection: FNDSECURITY_APPL_LOGIN_FAILED
at oracle.apps.fnd.profiles.Profiles.getProfileOption(Profiles.java:1509)
at oracle.apps.fnd.profiles.Profiles.getProfile(Profiles.java:362)

Solution:

The GUEST password in the .dbc files in $FND_TOP/secure were not the same as what was in the context file.

The GUEST password in <hostname>_<sid>.dbc was:
GUEST_USER_PWD=GUEST/GUEST

The GUEST password in the context file $APPL_TOP/admin/<sid>_<hostname>.xml was:
<oa_user type=”GUEST”>
<username oa_va=”s_guest_user”>GUEST</username>
<password oa_var=”s_guest_pass”>ORACLE</password>
</oa_user>

If the context file one was incorrect, we would have had to correct it and rerun AutoConfig, otherwise we would have had to just adjust the .dbc file and restart the app.

To confirm which password was correct, we ran the following SQL as user “apps”:

SELECT fnd_web_sec.validate_login(‘GUEST’, ‘ORACLE’) FROM dual;

This returned a “Y” which indicated that our .dbc file was the problem.

Fixed it, restarted the app, and we were good to go.


Applicable Versions:
  • Oracle E-Business Suite 11i (11.5.10.2)
References:
  • Oracle Support Note 458064.1

Ahmed Aboulnaga

1 comment:

cloudshinepro.com said...
This comment has been removed by the author.