HTTP 404 error after logging into Oracle EBS 12.2.6 url

Issue Description

We recently upgraded the Oracle EBS Version to 12.2.6 from 12.1.3. After Upgrade, one user reported he is getting erro HTTP 404 when he login to the application url.



Cause:

User has set his preferences to load a Custom Start Page after login. The custom html was not available after the upgrade.Hence he is getting error HTTP 404 as in screenshot. He is unable to reset the preferences as the page is not loading.

Solution:

In this case, only option is to modify the profile option 'Application Start Page' for the specific user  to a correct value.

Oracle EBS 12.2.x: ADOP error during Cutover phase

Background of the issue: I was applying hrblobal driver in a multi-node Production environment. Our Production application EBS has one Primary node and one DMZ Node.

After applying hrglobal driver using the online patching cycle, Cutover phase thrown below error message

==

Applying patch(es): <6390830> on node EBSDMZ failed.
If you choose to proceed with cutover, node EBSDMZ will be marked as abandoned.
Do you want adop to continue processing on completed nodes [y/n]? n
    As per user choice, adop will not proceed further with processing.

==

If we Provide input as 'Y' above, EBSDMZ node will be abandoned and we need to register the DMZ node again.


Solution:

1.Apply Patch on DMZ node using options=nodb and restart the cutover phase

On DMZ Node
=====
Source the patch filesystem
adop phase=apply patchtop=$PER_TOP/patch/115 patches=driver:hrglobal.drv allnodes=NO action=nodb options=forceapply

2. Restart Cutover phase on Master node

Oracle Applications Patching : ADOP Prepare phase failed due to missing information in FND_NODES.

Applying Patches to Oracle EBS and Oracle Database is one of the main activities for an Oracle database administration.We Often get errors during Oracle patching, which could be due to environment issue or a configuration issue or an Oracle Bug.

Checking Patch logfiles and Oracle Patching worker logfiles is very important to identify and troubleshoot the patching error.

Recently, while i am applying patch on a Production environment, Prepare phase in Oracle EBS online patching failed due to below  error

Error Details:Information missing in FND_NODES table for one or more application tier nodes.


=================================================
ADOP (C.Delta.9)
Session ID: 19
Node: prodapp01
Phase: prepare
Log: /applmgr/Oracle/PRODAPP/fs_ne/EBSapps/log/adop/19/20171230_095636/adop.log
===========================================================================

Validating configuration on node: [prodapp01].
    Log: /applmgr/Oracle/PRODAPP/fs_ne/EBSapps/log/adop/19/20171230_095636/prepare/validate/rwerpprodapp01
[ERROR]: Information missing in FND_NODES table for one or more application tier nodes. For details, refer to log file on the relevant node.
[WARNING]: There could be issues while validating the ports used for E-Business Suite instance against ports used in /etc/services. Refer the log file for more details.
[WARNING]: Either some of the required entries in /etc/hosts file might be missing (e.g. localhost or hostname) OR the file /etc/hosts could not be read.
[WARNING]: Found invalid cross references in FS config files.
    [UNEXPECTED]Error occurred running "perl /applmgr/Oracle/PRODAPP/fs2/EBSapps/appl/ad/12.0.0/patch/115/bin/txkADOPValidations.pl  -contextfile=/applmgr/Oracle/PRODAPP/fs2/inst/apps/PRODAPP_prodapp01/appl/admin/PRODAPP_prodapp01.xml -patchctxfile=/applmgr/Oracle/PRODAPP/fs1/inst/apps/PRODAPP_prodapp01/appl/admin/PRODAPP_prodapp01.xml -phase=prepare -logloc=/applmgr/Oracle/PRODAPP/fs_ne/EBSapps/log/adop/19/20171230_095636/prepare/validate/prodapp01 -promptmsg=hide"
    [UNEXPECTED]Error 1 occurred while Executing txkADOPValidation script on prodapp01


[STATEMENT] Please run adopscanlog utility, using the command

"adopscanlog -latest=yes"

to get the list of the log files along with snippet of the error message corresponding to each log file.


adop exiting with status = 1 (Fail)
=================================================


Analysis
The environment on which issue is reported has two middle Tier nodes. Primary node is the Master node and DMZ tier is the slave node.
Due to autoconfig failure on Oracle EBS Slave node, Support_Web  column is not updated in FND_NODES after autoconfig execution.
SUPPORT_WEB column for DMZ node is null in FND_NODES


Solution

1. Bring down Middle Tier Services
2. Run autoconfig on all the Middle Tier nodes
3. Startup the Middle Tier Services
4. Verify that FND_NODES table has correct information
5. Restart adop Prepare Phase

How to Retreive password of a front end user in Oracle EBS?

Sometimes, an Oracle database administrator requires to login as the user to reproduce the issue and troubleshoot.It is easy to recover the password of front end users in Oracle EBS by creating the Decrypt package.

Please be cautious and do not misuse this script. This should be used in test environments only.


Create package and Package body

-- Package
CREATE OR REPLACE PACKAGE get_pwd
AS
   FUNCTION decrypt (KEY IN VARCHAR2, VALUE IN VARCHAR2)
      RETURN VARCHAR2;
END get_pwd;
/
--Package Body
CREATE OR REPLACE PACKAGE BODY get_pwd
AS
   FUNCTION decrypt (KEY IN VARCHAR2, VALUE IN VARCHAR2)
      RETURN VARCHAR2
   AS
      LANGUAGE JAVA
      NAME 'oracle.apps.fnd.security.WebSessionManagerProc.decrypt(java.lang.String,java.lang.String) return java.lang.String';
END get_pwd;
/



Execute the below  Query to retrieve the password

SELECT usr.user_name,
       get_pwd.decrypt
          ((SELECT (SELECT get_pwd.decrypt
                              (fnd_web_sec.get_guest_username_pwd,
                               usertable.encrypted_foundation_password
                              )
                      FROM DUAL) AS apps_password
              FROM fnd_user usertable
             WHERE usertable.user_name =
                      (SELECT SUBSTR
                                  (fnd_web_sec.get_guest_username_pwd,
                                   1,
                                     INSTR
                                          (fnd_web_sec.get_guest_username_pwd,
                                           '/'
                                          )
                                   - 1
                                  )
                         FROM DUAL)),
           usr.encrypted_user_password
          ) PASSWORD
  FROM fnd_user usr
 WHERE usr.user_name = '&USER_NAME';

How to Compile Forms in Oracle Applications Release 11i and Release 12?

Steps to compile forms  in  Oracle Applications Release 12.1.x and 12.2.x

Login to Application Tier node as applmgr user

Change to $AU_TOP/forms/US

Execute the Below command to generate form files.

frmcmp_batch userid=apps/<password> module=formname.fmb
output_file=$PROD_TOP/forms/US/<name>.fmx module_type=form batch=no compile_all=special

After execution of the above command, verify there are no compilation errors in output displayed and the fmx is created succesfully.


Steps to compile forms  in  Oracle Applications Release 11i

Login to Application Tier node as applmgr user

Change to $AU_TOP/forms/US

Execute the Below command to generate form files.

f60gen module=$AU_TOP/forms/US/<custom_form>.fmb  userid=apps/<passwd> output_file=$PRODUCT_TOP/forms/<customformname>.fmx module_type=form compile_all=yes


Tips:

Use command "f60gen help=y" or "frmcmp_batch.sh help=y" to find the optional parameters.

Using Compile_all= yes changes cached version in the source file in addition to compiling pl/sql in the utput fmx file.

Oracle EBS DBA Utilities :FNDLOAD

What are the objects loaded using FNDLOAD in Oracle Applications?

FNDLOAD (Generic Loader) is a concurrent Program which is used to move metadata between database and text file representations.The loader reads a configuration file to determine what data to access.

FNDLOAD can download data from an application entity into a portable, editable text file. This file can then be uploaded into any other database to copy the data. Conversion between database store and file format is specified by a configuration file that is read by the loader. FNDLOAD downloads data from a database according to a configuration (.lct) file, and converts the data into a data file (.ldt file). FNDLOAD can then upload this data to another database using a configuration file.

The loader operates in one of two modes: download or upload. In the download mode, data is downloaded from the database to a text file; in the upload mode, data is uploaded from a text file to the database.

Syntax to upload/download concurrent Programs using FNDLOAD:

To Download:

FNDLOAD apps/** 0 Y DOWNLOAD $FND_TOP/patch/115/import/afcpprog.lct  PROGNAME.ldt PROGRAM APPLICATION_SHORT_NAME="APPLICATION_SHORT_NAME CONCURRENT_PROGRAM_NAME="Program_Name"

To Upload:

FNDLOAD apps/$apps_password 0 Y UPLOAD $FND_TOP/patch/115/import/afcpprog.lct PROGNAME.ldt UPLOAD_MODE=REPLACE CUSTOM_MODE=FORCE

Below are the application entities which can be uploaded/downloaded using FNDLOAD.

FND Messages

Lookups

EBS Front End Users

Responsibilities

Alerts

Concurrent Programs

Profile Options

Request Groups 

Menus

ADOP Options: cleanup_mode

ADOP cleanup_mode

Run with adop cleanup phase.

Provides control over the extent of cleanup operations.

If no value is specified, cleanup is performed in standard mode, which does the same as quick mode but also drops obsolete code objects.

Values: quick/full

Purpose:

cleanup_mode=quick performs the minimum necessary cleanup to complete the online patching cycle. Use this mode if you want to start a new online patching cycle as soon as possible.

cleanup_mode=full performs all possible cleanup tasks for maximum recovery of space from unused database editions, objects and columns. Full cleanup is required after aborting an online patching cycle.

Usage:

adop phase=cleanup cleanup_mode=full

adop phase=cleanup cleanup_mode=quick

ADOP Options: actualize_all

Whenever adop prepare phase is initiated, a new patch edition is created in the database.During Online patching (ADOP) : An additional column ZD_EDITION_NAME is populated in the seed tables.As we do more online patching cycles, the number of entries for database editions will increase. This affects system performance and also increases cleanup time.When the number of old database editions reaches 25 or more, you should consider dropping all old database editions by running the adop actualize_all phase and then performing a full cleanup.

To drop older database editions, follow the below steps:

$ adop phase=prepare
$ adop phase=actualize_all
$ adop phase=finalize finalize_mode=full
$ adop phase=cutover
$ adop phase=cleanup cleanup_mode=full

How to Restore context file in oracle applications?

Scenario: Your Applications context file is either accidentally deleted or Corrupted. You do not have any latest backup of context file available.

Below are the steps to recreate context file 

The Applications context file can be retrieved by running the adclonectx.pl script.

perl /clone/bin/adclonectx.pl retrieve

Above script prompts for Database connection Info, apps username/password , Available Context files and the location to which context files can be restored.When prompted for the context file to be retrieved, select the option of retrieving the Applications tier context file that has been lost and retrieve it to the default location as in $CONTEXT_FILE parameter.

The above command can be used only when INST_TOP the is still intact. Incase if INST_TOP is also lost, the Applications tier context file may be retrieved as follows:

Execute the following command on the Database tier:

perl /appsutil/clone/bin/adclonectx.pl retrieve

When prompted for the context file to be retrieved, select the option of retrieving the Applications tier context file that has been lost.Choose the location to any writeable location and copy the restored context file to the value specified in $CONTEXT_FILE parameter on Application Tier.

To retrieve the Database tier context file,

Execute the following command on the Database tier:

perl /appsutil/clone/bin/adclonectx.pl retrieve

When prompted for the context file to be retrieved, select the Database tier context file and retrieve it to the default location ($CONTEXT_FILE on DB node).

Oracle Applications R12.2.5 New Features: dualfs in cloning

From Oracle Applications Release 12.2.5 Version, we have dualfs option for cloning applications tier.We can use this feature in earlier 12.2.x versions also, if AD-TXK Delta 7 patch is applied.Before AD-TXK Delta 7, it was required to run adcfgclone twice on run and patch filesystems.Using dualfs option,we can create both run and patch fs at one time.

-bash$ perl adcfgclone.pl appsTier dualfs

                     Copyright (c) 2002, 2015 Oracle Corporation
                        Redwood Shores, California, USA

                        Oracle E-Business Suite Rapid Clone

                                 Version 12.2

                      adcfgclone Version 120.63.12020000.56

Enter the APPS password :

Enter the Weblogic AdminServer password :

Do you want to add a node (yes/no) [no] :


Running: Context clone...

Log file located at /u01/VISN/fs1/EBSapps/comn/clone/bin/CloneContext_1023194859.log

Provide the values required for creation of the new APPL_TOP Context file.

Target System Hostname (virtual or normal) [appsmt] :

Target System Database SID : VISN

Target System Database Server Node [r12erpt] : appsdb

Target System Database Domain Name [domain.com] :

Target System Base Directory : /u01/VISN

Target System Base Directory set to /u01/VISN

Target System Current File System Base set to /u01/VISN/fs1

Target System Other File System Base set to /u01/VISN/fs2

Target System Fusion Middleware Home set to /u01/VISN/fs1/FMW_Home
Target System Other File System Fusion Middleware Home set to /u01/VISN/fs2/FMW_Home

Target System Web Oracle Home set to /u01/VISN/fs1/FMW_Home/webtier
Target System Other File System Web Oracle Home set to /u01/VISN/fs2/FMW_Home/webtier

Target System Appl TOP set to /u01/VISN/fs1/EBSapps/appl
Target System Other File System Appl TOP set to /u01/VISN/fs2/EBSapps/appl

Target System COMMON TOP set to /u01/VISN/fs1/EBSapps/comn
Target System Other File System COMMON TOP set to /u01/VISN/fs2/EBSapps/comn

Target System Instance Home Directory [V] : /u01/VISN

Target System Current File System Instance Top set to /u01/VISN/fs1/inst/apps/VISN_appsmt

Do you want to preserve the Display [appsmt:0.0] (y/n)  : n

Target System Display [r12erpt:0.0] : appsmt:3.0

Target System Root Service [enabled] :

Target System Web Entry Point Services [enabled] :

Target System Web Application Services [enabled] :

Target System Batch Processing Services [enabled] :

Target System Other Services [disabled] :


Do you want the target system to have the same port values as the source system (y/n) [y] ? : n

Target System Port Pool [0-99] : 88

Checking the port pool 88
done: Port Pool 88 is free
Report file located at /u01/VISN/fs1/inst/apps/VISN_appsmt/admin/out/portpool.lst

UTL_FILE_DIR on database tier consists of the following directories.

1. /usr/tmp
2. /usr/tmp
3./u01/VISN/product/12.1.0/appsutil/outbound/VISN_appsmt
4. /usr/tmp
Choose a value which will be set as APPLPTMP value on the target node [1] : 3
The new APPL_TOP context file has been created :
  /u01/VISN/fs1/inst/apps/VISN_appsmt/appl/admin/VISN_appsmt.xml
Check Clone Context logfile /u01/VISN/fs1/EBSapps/comn/clone/bin/CloneContext_1023194859.log for details.

Creating Patch file system context file.....

Log file located at /u01/VISN/fs1/EBSapps/comn/clone/bin/CloneContextPatch_1023194973.log

Target System Other File System Instance Top set to /u01/VISN/fs2/inst/apps/VISN_appsmt

Target System Port Pool [0-99] : 89

Checking the port pool 89
done: Port Pool 89 is free
Report file located at /u01/VISN/fs2/inst/apps/VISN_appsmt/admin/out/portpool.lst
The new APPL_TOP context file has been created :
 /u01/VISN/fs2/inst/apps/VISN_appsmt/appl/admin/VISN_appsmt.xml
Check Clone Context logfile /u01/VISN/fs1/EBSapps/comn/clone/bin/CloneContextPatch_********.log for details.

FMW Pre-requisite check log file location : /u01/VISN/fs1/EBSapps/comn/clone/FMW/logs/prereqcheck.log
Running: FMW pre-req check...

Configuring: Run file system....
LogFile located at /u01/VISN/fs1/inst/apps/VISN_appsmt/admin/log/clone/run/RCloneApplyAppstier_*******.log