Adop Prepare Vs Adop Fs_Clone in Oracle R12.2

In Oracle Apps R12.2

a) adop phase=prepare PHASE DETAILS, What it will do:

Checks that the environment is set to the run APPL_TOP. Checks whether to perform a cleanup, which will be needed if the user failed to invoke cleanup after the cutover phase of a previous online patching cycle.

Checks to see if the database is prepared for online patching:Checks that the FILE_EDITION environment variable value is set to ‘run Checks to see if enough space is available in the database (SYSTEM tablespace should have minimum of 25 GB of free space and APPS_TS_SEED tablespace should have minimum of 5 GB of free space)

Checks the file system, using the TXK script $AD_TOP/patch/115/bin/txkADOPPreparePhaseSanityCheck.pl. This script checks for the file system space, database connections, Apps/System/Weblogic Passwords, Contextfile Validation and so on

Produces a report showing information about the most important tablespaces is generated. This report is created in $APPL_TOP/admin/$TWO_TASK/out.

Checks for the existence of the “Online Patching In Progress” (ADZDPATCH) concurrent program. This program prevents certain predefined concurrent programs from being started, and as such needs to be active while a patching cycle is in progress.

Invokes the TXK script $AD_TOP/patch/115/bin/txkADOPPreparePhaseSynchronize.pl to synchronize the patches which have been applied to the run appltop.

Checks the database for the existence of a patch edition, and creates one if it does not find one

A patch edition is created in the database.

All code objects in the patch edition begin as pointers to code objects in the run edition. Code objects in the patch edition begin as lightweight “stub objects” that point to the actual object definitions, which are inherited from earlier editions. Stub objects consume minimal space, so the database patch edition is initially very small in size.

As patches are applied to the patch edition, code objects are actualized (have a new definition created) in that edition.

9. Calls the $AD_TOP/patch/115/bin/txkADOPPreparePhaseSanityCheck.pl script again to confirm that the database connection to the patch edition is working.

B) adop FS_CLONE PHASE DETAILS, What it will do:

The fs_clone phase is a command (not related to adcfgclone.pl) that is used to synchronize the patch file system with the run file system. The fs_clone phase should only be run when mentioned as part of a specific documented procedure.

This phase is useful if the APPL_TOPs have become very unsynchronized (meaning that there would be a large number of delta patches to apply). It is a heavyweight process, taking a backup of the entire current patch APPL_TOP and then cloning the run APPL_TOP to create a new patch APPL_TOP. As this method requires more time and disk space, it should only be used when the state of the patch file system is unknown. This command must be invoked from the run file system, before the next prepare phase is run.

Oracle R12.2 EBS login flow

Before jumping into the flow, lets brush up the role of APPLSYSPUB, GUEST, APPLSYS and APPS user.

When we login to applications,initially oracle applications connect to public schema, APPLSYSPUB. This schema has sufficient privileges to perform the authentication of an Applications User (FND user), which includes running PL/SQL packages to verify the username/password combination and the privilege to record the success or failure of a login attempt.
The public ORACLE username and password that grants access to the Oracle E-Business Suite initial sign-on form. The default is APPLSYSPUB/PUB.
Once we change the APPLSYSPUB password must propagate the change to application tier configuration files. If the instance is Autoconfig enabled, must edit the CONTEXT file on each tier prior to running Autoconfig.

In the CONTEXT file, locate the autoconfig variable “s_gwyuid_pass” and set it to the new password, then run AutoConfig in each applications nodes.
When Autoconfig is not being used:
If you are not using Autoconfig you must manually edit the following configuration files :
1) FND_TOP/resource/appsweb.cfg
2) OA_HTML/bin/appsweb.cfg
3) FND_TOP/secure/HOSTNAME_DBNAME.dbc

To change password of APPLSYSPUB with FNDCPASS:
$FNDCPASS APPS/[apps_pass] 0 Y SYSTEM/[system_pass] ORACLE APPLSYSPUB [new_passs].

0 & Y are flags for FNDCPASS
0 is request id (request ID 0 is assigned to request ID's which are not submitted via Submit Concurrent Request Form)
'Y' indicates that this method is directly invoked from the command-line and not from the Submit Request Form.

All application tier processes (Apaches) must be restarted following the password change.

Role of GUEST user/schema in Oracle Applications:
GUEST is a dummy schema.
By default it has ORACLE as password.
GUEST/ORACLE password is present in DBC file at $FND_TOP/secure directory as well as at $FND_TOP/secure/SID_hostname directory.
If a user logs in without any role mappings, the user will get the Guest role, which has a default permission of "R".
GUEST user is used by JDBC Drivers and Oracle Self Service Web Applications like istore, irecruitment, iprocurement, ipayables, ireceivables etc to make initial Connection.

Role of APPLSYS & apps user/schema in Oracle Applications:
APPLSYS user is same as other oracle users like AP, AR, GL etc which hold their set of tables, views etc. In the same manner APPLSYS Account holds its set of tables like FND_USER and FND_APPLICATION, AD_APPLIED_PATCHES etc.
Applsys schema has applications technology layer products like FND and AD etc.
Apps is a universal schema, it has synonyms to all base product tables and sequences. This also has code objects for all products (triggers, views, packages, synonyms etc).
APPS is central Schema which holds synonyms for all other Users Database Objects.

Note: APPLSYS and APPS should have same password.

Reason why these contains same password.

Both apps & applsys need to have same password because when you sign on to apps, initially it connects to a public schema called APPLSYSPUB. This validates AOL name and password that we enter (operations/welcome). Once this is verified we select responsibility, this is validated by APPLSYS schema and then it connects to apps schema.
During signon process it uses both applsys and apps, hence this expects both the password to be identical. If the password for applsys & apps are not identical (Different) Try changing apps password to something else and try to login, the validation at the last stage would fail. This would result in failure of application login.

Difference B/W APPLSYSPUB & GUEST:
APPLSYSPUB/PUB - is DB user which is used by any utility to retrieve APPS schema password for further logins.
GUEST/ORACLE - is EBS user with no or max limited privileges to execute authorization function.

That is why Guest user cannot be end dated.

Now lets jump into the login flow:

1.Webserver receives the user request for the particular port number. Web server Binds the request with the port number.

2.Based on the cookie webserver serves the request by sending login page

3.The application user name and password is entered by the user(operations/welcome)

4.DB connection is established using APPLSYSPUB user. This user “APPLSYSPUB” is having access to fnd_user view and a small set of other public tables needed to establish the initial connection.

5.Once DB connection is established FND_USER table is used to get ENCRYPTED_FOUNDATION_PASSWORD.

6.Using GUEST/ORACLE password combination and ENCRYPTED_FOUNDATION_PASSWORD  string obtained from 2 above, we get Apps schema password.

7.Internally it tries to connect to Apps schema with the password retrieved in step 3 above. If the connection fails, then

   a)The GUEST username password is incorrect

   b)The FNDNAM (APPS) environment variable is set incorrectly.

   c)Some other problem prevented a connection


8.Using Apps password obtained in Step 3 and ENCRYPTED_USER_PASSWORD string from FND_USER table, password for Application user (e.g. SYSADMIN) is obtained.

9. The Application user password obtained in Step 5 is compared to the application user password entered by user in login screen. If both passwords match then user is   allowed to get into self-service.

10. A list of responsibilities assigned to that user is shown.  The user picks one of the responsibilities listed.

11. The responsibility and application name is validated by connecting to Applsys schema(fnd_Responsibility, fnd_application…….)
Note: Here we should remember the difference between applsys and apps schema. Applsys schema contains ad,fnd objects whereas apps schema is a global schema contains all application objects.

12. Once the application is validated , Connecting to apps schema to get access application tables. This is the reason why we should have apps and applsys passwords should be same

13. Once a particular form is selected the .dbc file is accessed to get the information about the GUEST username/pwd

============
Note: Oracle doesn't store the hash value of the passwords. It just store the whole password in the encrypted format and get stored in FND_USER table(encrypted_user_password). Thus during authentication of a front end user, it is done on the stored password. Decryption of the stored password takes place FND_WEB_SEC package which is found under apps schema. The decryption key for the user password is the decrypted “ENCRYPTED_FOUNDATION_PASSWORD” of the guest user. Meaning that the first step to decrypt the user password is to decrypt the foundation password of the guest user.

There are certain changes for EBS 12.2 as 10.1.3 application server is replaced by Weblogic server. Thus the login flow will be slight different

When a HTTP request is made for EBS, the request is received by the Oracle HTTP Server (OHS).
When the configuration of OHS is for a resource that needs to be processed by Java, such as logging into EBS, the OHS configuration will redirect the request to the Web Logic Server (WLS) Java process (OACore in this case).
WLS determines the J2EE application that should deal with the request, which is called “oacore”.
This J2EE application needs to be deployed and available for processing requests in order for the request to succeed.   The J2EE application needs to access a database and does this via a datasource which is configured within WLS.
Here is the processing in terms of URL(Login HTTP headers)
When the EBS login works OK, the browser will be redirected to various different URLs in order for the login page to be displayed.  The page flow below shows the URLs that will be called to display the login page:

/OA_HTML/AppsLogin
EBS Login URL
/OA_HTML/AppsLocalLogin.jsp
Redirects to local login page
/OA_HTML/RF.jsp?function_id=1032925&resp_id=-1&resp_appl_id=-1&security_group_id=0&lang_code=US&oas=3TQG_dtTW1oYy7P5_6r9ag..&params=5LEnOA6Dde-bxji7iwlQUg
Renders the login page
The URLs after the user enters username and password, then clicks the “login” button are shown below/OA_HTML/OA.jsp?page=/oracle/apps/fnd/sso/login/webui/MainLoginPG&_ri=0&_ti=640290175&language_code=US&requestUrl=&oapc=2&oas=4hoZpUbqVSrv9IE0iJdY1g..
/OA_HTML/OA.jsp?OAFunc=OANEWHOMEPAGE
/OA_HTML/RF.jsp?function_id=MAINMENUREST&security_group_id=0
Renders user home page
Once the users home page is displayed, the logout flow also redirects to several different URL before returning to the login page:
/OA_HTML/OALogout.jsp?menu=Y
Logout icon has been clicked
/OA_HTML/AppsLogout
/OA_HTML/AppsLocalLogin.jsp?langCode=US&_logoutRedirect=y
Redirects to the login page
/OA_HTML/RF.jsp?function_id=1032925&resp_id=-1&resp_appl_id=-1&security_group_id=0&lang_code=US&oas=r6JPtR7-a4n5U2H3–ytEg..&params=1JU-PCsoyAO7NMAeJQ.9N6auZoBnO8UYYXjUgSPLHdpzU3015KGHA668whNgEIQ4

Custom Top/Application Creation Oracle EBS R12

Custom Top/Application Creation R12 ,R12.2:

SCHEMA NAME : XXERP

TOP NAME : XXERP_TOP

Application : XXERP Custom Application

Data Group : Standard

Request Group : XXERP Request Group

Menu : XXERP_CUSTOM_MENU

Responsibility : XXERP Custom

Step-1

Create a Tablespace in the backened Database for custom schema.

create tablespace XXERP datafile ‘/d01/oracle/PROD/db/apps_st/data/XXERP01.dbf’

size 50M;

Step-2

Create Schema

create user XXERP identified by XXERP default tablespace XXERP temporary tablespace temp quota unlimited on XXERP;

Step-3

Grants Connect and Resource to schema

grant connect, resource to XXERP;

Step-4

Make the directory structure for your custom application files.

cd $APPL_TOP

mkdir XXERP

mkdir -p XXERP/12.0.0

mkdir -p XXERP/12.0.0/admin

mkdir -p XXERP/12.0.0/admin/sql

mkdir -p XXERP/12.0.0/admin/odf

mkdir -p XXERP/12.0.0/sql

mkdir -p XXERP/12.0.0/bin

mkdir -p XXERP/12.0.0/reports

mkdir -p XXERP/12.0.0/reports/US

mkdir -p XXERP/12.0.0/forms

mkdir -p XXERP/12.0.0/forms/US

mkdir -p XXERP/12.0.0/lib

mkdir -p XXERP/12.0.0/out

mkdir -p XXERP/12.0.0/log

Step-5

Create Custom Environment file in APPL_TOP directory

Step-6

Edit customPROD_idba22.env file

export XXERP_TOP=/d01/oracle/PROD/apps/apps_st/appl/XXERP/12.0.0

Step-7

go to last line and add

XXERP_TOP=/d01/oracle/PROD/apps/apps_st/appl/XXERP/12.0.0

Step-8

Register your Oracle Schema.

Login to Applications with System Administrator responsibility

Navigate to Application–>Register

Application = XXERP Custom Application

Short Name = XXERP

Basepath = XXERP_TOP

Description = XXERP Custom Application

Step-9

Register Oracle User

Naviate to Security–>Oracle–>Register

Database User Name = XXERP

Password = XXERP

Privilege = Enabled

Install Group = 0

Description = XXERP Custom Application User

Step-10

Add Application to a Data Group

Navigate to Security–>Oracle–>DataGroup

Step-11

Create custom request group

This will act as a placeholder for any custom reports we wish to make available for the

Custom Responsibility (which is defined at a later stage)

Navigate to Security–>responsibility–>Request

Group = XXERP Request Group

Application = XXERP Custom

Code = XXERP

Description = XXERP Custom Requests

We will not define any requests to add to the group at this stage, but you can add some now if required.

Step-12

Create custom menu

This will act as a placeholder for any menu items we wish to make available for the

Custom Responsibility (which is defined at a later stage). We will create two menus, one

for Core Applications and one for Self Service.

Navigate to Application–>Menu

Menu = XXERP_CUSTOM_MENU

User Menu Name = XXERP Custom Application

Menu Type =

Description = XXERP Custom Application Menu

Seq = 100

Prompt = View Requests

Submenu =

Function = View All Concurrent Requests

Description = View Requests

Seq = 110

Prompt = Run Requests

Submenu =

Function = Requests: Submit

Description = Submit Requests

Step-13

Create new responsibility. Navigate to Security–>Responsibility–>Define

Responsibility Name = XXERP Custom

Application = XXERP Custom

Responsibility Key = XXERPCUSTOM

Description = XXERP Custom Responsibility

Available From = Oracle Applications

Data Group Name = XXERPGroup

Data Group Application = XXERP Custom

Menu = XXERP Custom Application

Request Group Name = XXERP Request Group

Step-14

Add responsibility to user

Navigate to Security–>User–>Define

Add XXERP Custom responsibility to users as required.

Step-15

As we have edited default.env we need to bounce the opmn.

cd $ADMIN_SCRIPTS_HOME

sh adopmnctl.sh stopall

Rest the Application ENvironment and start OPMN

sh adopmnctl.sh startall