How to Stop Concurrent Requests from Executing on New Cloned Environment

 If you do not want concurrent requests scheduled in Source to run on a newly cloned environment, Follow the below steps

1. Run “perl adcfgclone.pl appsTier” as normal.
Before starting the application services, run the below update commands


-Take Backup of fnd_concurrent_requests

create table  fnd_concurrent_requests_bkp as select * from fnd_concurrent_requests;

-Terminate ‘Running’ Requests

UPDATE fnd_concurrent_requests
SET phase_code = ‘C’, status_code = ‘X’
WHERE status_code =’R’
OR phase_code = ‘R’
/

-Set Pending jobs to ‘On Hold’

UPDATE fnd_concurrent_requests
SET hold_flag = ‘Y’
WHERE phase_code = ‘P’
AND status_code in (‘Q’,’I’)
/

How can I confirm Profile Option Settings at all levels for a specified Profile Option?

 Run this script to identify Site, and all Responsibility and User values associated with the selected profile option

SELECT A.LAST_UPDATE_DATE,
T.USER_PROFILE_OPTION_NAME “PROFILE OPTION”,
DECODE(A.LEVEL_ID, 10001, ‘SITE’,
10002, ‘APPLICATION’,
10003, ‘RESPONSIBILITY’,
10004, ‘USER’) “LEVEL”,
DECODE(A.LEVEL_ID, 10001, ‘SITE’,
10002, B.APPLICATION_SHORT_NAME,
10003, C.RESPONSIBILITY_KEY,
10004, D.USER_NAME) “LEVEL VALUE”,
A.PROFILE_OPTION_VALUE “PROFILE VALUE”
FROM FND_PROFILE_OPTION_VALUES A,
FND_APPLICATION B,
FND_RESPONSIBILITY C,
FND_USER D,
FND_PROFILE_OPTIONS E,
FND_PROFILE_OPTIONS_TL T
WHERE A.PROFILE_OPTION_ID = E.PROFILE_OPTION_ID
AND E.PROFILE_OPTION_NAME =’&PROFILE_OPTION_NAME’ —Enter profile option name here
AND A.LEVEL_VALUE = B.APPLICATION_ID(+)
AND A.LEVEL_VALUE = C.RESPONSIBILITY_ID(+)
AND A.LEVEL_VALUE = D.USER_ID(+)
AND T.PROFILE_OPTION_NAME = E.PROFILE_OPTION_NAME
ORDER BY E.PROFILE_OPTION_NAME, A.LEVEL_ID DESC;

Oracle Application 12.2.x Dual Filesystem Key features

 In Oracle E-Business Suite (EBS) 12.2, DualFS (short for Dual File System) refers to a feature introduced to support online patching and the zero-downtime patching process. It is used in conjunction with the “online patching” methodology that Oracle introduced starting with 12.2 to enable more efficient patching with minimal disruption to users.

Key Concepts of DualFS in Oracle EBS 12.2:

  1. Separation of Run and Patch File Systems:

    • In Oracle EBS 12.2, the Dual File System divides the Oracle E-Business Suite filesystem into two main parts: a “run” file system and a “patch” file system.
    • The run file system contains the currently active version of your applications and is what users interact with.
    • The patch file system contains the patched version of the Oracle Applications files.
    • The two filesystems allow you to apply patches in a dual-phase approach—one for the run system and one for the patch system.
  2. Online Patching with DualFS:

    • Oracle 12.2 allows you to apply patches without needing to take the entire system down. While patches are being applied to the patch file system, users can continue using the run file system.
    • The patching process involves copying the patched files into the patch filesystem while the system is live. After patches are applied, the system switches over to the patch filesystem with minimal downtime (essentially, zero-downtime patching).
  3. Two Modes of Operation:

    • Run Mode: This is the mode where the system is actively used by end-users, and they interact with the applications.
    • Patch Mode: This is where patches are applied to the “patch” file system. Once patches are successfully applied and validated, the system is switched to use the new patched version.
  4. File System Switch (fs_clone):

    • Once the patching is completed on the patch filesystem, a switch is made between the run and patch file systems using the fs_clone utility. The run file system is switched to the patch file system, making it the active environment for users.
    • This switch takes very little time (a few seconds or minutes), and it does not require taking the entire application down, which results in minimal disruption to end-users.
  5. Benefits of DualFS:

    • Minimized Downtime: The most significant advantage of DualFS is zero-downtime patching. The system doesn’t need to be taken offline for long periods during patch application.
    • Concurrent Patching: Allows patches to be applied concurrently with the normal running of the applications, without disrupting active users.
    • Flexibility in Maintenance: Patching and maintenance can be done during regular business hours, greatly reducing the need for extensive maintenance windows.
  6. Patch Lifecycle:

    • When Oracle releases patches, they can be applied incrementally and sequentially. After applying each patch, the system can be validated, and only once all patches are successfully applied can the final switch be made from the patch file system to the run file system.

By utilizing DualFS, Oracle E-Business Suite 12.2 significantly reduces the impact of patching on business operations, enabling enterprises to maintain a more agile and up-to-date system while ensuring continuity of service.

Concurrent Request failing due to XML publisher directory not available

Issue:
Concurrent Request Failing during OutputPost Processing
Below is the error message from OutputPost Processor Logs:
 [UNEXPECTED]  java.io.FileNotFoundException: /usr/tmp/ERPTEST1/xdokjshyw821_1905677210.fo (No such file or directory)
        at java.io.FileOutputStream.open(Native Method)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:221)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:171)
        at oracle.apps.xdo.common.tmp.TmpFile.createTmpFileJDK118(Unknown Source)
        at oracle.apps.xdo.common.tmp.TmpFile.createTmpFile(Unknown Source)
        at oracle.apps.xdo.template.FOProcessor.getTmpFOFile(Unknown Source)
        at oracle.apps.xdo.template.FOProcessor.createFO(Unknown Source)
        at oracle.apps.xdo.template.FOProcessor.generate(Unknown Source)
        at oracle.apps.xdo.oa.schema.server.TemplateHelper.runProcessTemplate(TemplateHelper.java:5984)
        at oracle.apps.xdo.oa.schema.server.TemplateHelper.processTemplate(TemplateHelper.java:3475)
        at oracle.apps.xdo.oa.schema.server.TemplateHelper.processTemplate(TemplateHelper.java:3564)
        at oracle.apps.fnd.cp.opp.XMLPublisherProcessor.process(XMLPublisherProcessor.java:311)
        at oracle.apps.fnd.cp.opp.OPPRequestThread.run(OPPRequestThread.java:185)

Cause 
The Temporary directory for XML Publisher has not been modified after making the clone so it was pointing to non existing location and getting error out.
Solution
1. Create a new Temporary Directory on OS level for the cloned environment.
2. Make sure that the application owner (APPLMGR) has Read and Write permission this directory.

ADOP fs_clone failing with error : “Could not find patch context file from database”

 Issue:

FS_CLONE is failing with error :Could not find patch context file from database
Error details:
$adop phase=fs_clone
==============
Checking for existing adop sessions.
    No pending session exists.
    Starting new adop session.
===========================================================================
ADOP (C.Delta.12)
Session ID: 43
Node: test1.domain1.com
Phase: fs_clone
Log: /test/erp/apps/fs_ne/EBSapps/log/adop/32/20220121_145748/adop.log
===========================================================================
Verifying existence of context files in database.
    [UNEXPECTED] Could not find patch context file from database
    [UNEXPECTED]Patch edition context file not found in database for host test1.domain1.com

Summary report for current adop session:
    Node test1.domain1.com:
       – Fs_clone status:   Not Started
    For more details, run the command: adop -status -detail

[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 = 2 (Fail)

=========================
Cause:
===
Patch context file not found in fnd_oam_context_files tables.

Solution:
=======
1.Source the patch file system and run autoconfig on patch filesystem to update context file in database.
or
2. Run CtxSynchronizer to upload patch context file to database.
$ $ADJVAPRG oracle.apps.ad.autoconfig.oam.CtxSynchronizer action=upload contextfile=<patch context file name and location> logfile=/tmp/patchctxupload.log

Provide apps password when prompted.

“APP-FND-02704: Unable to alter user APPS_NE to change password” while changing APPS password using FNDCPASS

 Issue: 
Changing apps password using FNDCPASS fails with below error
APP-FND-02704: Unable to alter user APPS_NE to change password.
Oracle error 28003:  has been detected in alterpassword2.

Command to change APPS Password.[Ensure to shut down Application services before changing apps password]
FNDCPASS apps/<apps_pwd> 0 Y system/<password> SYSTEM APPLSYS <new_apps_password>
Error Message from Logfile:
+—————————————————————————+
Application Object Library: Version : 12.2
Copyright (c) 1998, 2013, Oracle and/or its affiliates. All rights reserved.
FNDCPASS:
+—————————————————————————+
Current system time is 10-APR-2020 18:43:36
+—————————————————————————+
Arguments
   FNDCPASS system/***** SYSTEM APPLSYS *****
+—————————————————————————-+
Working…
APP-FND-02704: Unable to alter user APPS_NE to change password.
Oracle error 28003:  has been detected in alterpassword2.
+—————————————————————————+
Concurrent request completed
Current system time is 10-APR-2020 18:43:39
+—————————————————————————+

Cause:
Issue is due to Password_verify_function enables in dba_profiles for APPS,APPLSYS,APPS_NE users
Solution:
Disable the password verify function for APPS,APPLSYS,APPS_NE users in database profiles.
1. Identify the database profile for APPS,APPLSYS,APPS_NE users using below query.
SELECT USERNAME,PROFILE FROM DBA_USERS where USERNAME in (‘APPS’,’APPLSYS’,’APPS_NE’);
SELECT PROFILE,VALUE FROM DBA_PROFILES WHERE  PROFILE=’&profile for user’;
2. Disable password verify function
alter profile <profile_name> limit PASSWORD_VERIFY_FUNCTION null;
3. Run the FNDCPASS command to change password.

FNDCPASS apps/<apps_pwd> 0 Y system/<password> SYSTEM APPLSYS <new_apps_password>

4. After changing apps password, run autoconfig on Middle tier and update EBS datasource for R12.2.x
You can follow the below steps to update apps password in EBS Datasource:
5. Startup Application services

4. Revert back the changes done in step 2

How to change weblogic password from Backend in EBS 12.2.x?

On EBS 12.2.X environments , if you are on R12.AD.C.Delta.7 and R12.TXK.C.Delta.7 or later, we can change Weblogic admin server password using the below script.
1. Startup admin server. Do not start any other services
$. ./EBSapps.env RUN
$ cd $ADMIN_SCRIPTS_HOME
$adadminsrvctl.sh start
2. Run the below script  
perl $FND_TOP/patch/115/bin/txkUpdateEBSDomain.pl -action=updateAdminPassword
[The script will prompt for Current and New Weblogic Password and restarts Weblogic admin server using the new password.]
3. Run fs_clone to propagate the changes to the alternate file system (Patch File system).
$adop phase=fs_clone