NaturalOracle DataGaurd tutorial Series Coming Soon!! Natural
For Any queries, please mail us at support@funoracleapps.com

Understanding APPLSYSPUB user in Oracle Application

No comments

APPLSYSPUB (also known as the GATEWAY user)

The default password is 'PUB' and in case you change it, the password should be always in Upper Case. 
It is a public schema. which helps in validating Application user credentials when we login to Oracle Application.


Significance of Applsyspub 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.
Once authentication is successfully completed, Oracle Application allows to connect to apps schema and allows to choose a responsibility. By using responsibility, we can use HTML or Oracle forms interface to access data that resides in product schema.

How to change password of APPLSYSPUB FNDCPASS utility is used to change the applsyspub password.

$FNDCPASS APPS/[apps_pass] 0 Y SYSTEM/[system_pass] ORACLE APPLSYSPUB [new_passs].0 & Y are flags for FNDCPASS0 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.
  • 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.

How to fetch the APPLSYSPUB user password


1. echo $GWYUID


APPLSYSPUB/PUB

2. grep -i applsyspub $FND_SECURE/$TWO_TASK.dbc

GWYUID=APPLSYSPUB/PUB

3. grep -i s_gwyuid_pass $CONTEXT_FILE

   password oa_var=”s_gwyuid_pass”-- PUB -- password


No comments :

Post a Comment

Find Oracle Application Profiles Change in N Day

No comments
We can use below script to check Oracle EBS profile changed in last N days.

SELECT p.profile_option_name SHORT_NAME,
  n.user_profile_option_name "PROFILE NAME",
  DECODE(v.level_id, 10001, 'Site', 10002, 'Application', 10003, 'Responsibility', 10004, 'User', 10005, 'Server', 10007, 'SERVRESP', 'UnDef') LEVEL_SET,
  DECODE(TO_CHAR(v.level_id), '10001', '', '10002', app.application_short_name, '10003', rsp.responsibility_key, '10005', svr.node_name, '10006', org.name, '10004', usr.user_name, '10007', 'Serv/resp', 'UnDef') "CONTEXT",
  v.profile_option_value VALUE,
  v.LAST_UPDATE_DATE
FROM fnd_profile_options p,
  fnd_profile_option_values v,
  fnd_profile_options_tl n,
  fnd_user usr,
  fnd_application app,
  fnd_responsibility rsp,
  fnd_nodes svr,
  hr_operating_units org
WHERE p.profile_option_id = v.profile_option_id (+)
AND p.profile_option_name = n.profile_option_name
--and upper(n.user_profile_option_name) like upper('&profile_name')
AND TRUNC(v.LAST_UPDATE_DATE) > TRUNC(sysdate-&days)
AND usr.user_id (+)           = v.level_value
AND rsp.application_id (+)    = v.level_value_application_id
AND rsp.responsibility_id (+) = v.level_value
AND app.application_id (+)    = v.level_value
AND svr.node_id (+)           = v.level_value
AND org.organization_id (+)   = v.level_value
AND v.LAST_UPDATE_DATE       IS NOT NULL
AND n.language='US'
ORDER BY last_update_date DESC,
  short_name,
  level_set;

No comments :

Post a Comment

Granting privileges on an object may cause object invalidation's in the current edition(Use AD_ZD.GRANT_PRIVS Only)

No comments

Granting privileges on an object may cause object invalidation in the current edition.

Grants cannot be performed in the run edition when the application is being used.

In 12.2 When grants are given to "Stub objects" it invalidates all dependent stub objects. 
"stub objects" are simply pointers to an actual object definition from an ancestor edition that is still being inherited by the given edition.

Henceforth granting in 12.2 ; should be using only ad_zd.grant_privs instead of 'grant' (DDL) directly

There are occasions where you might want to grant privileges to objects in the APPS schema; for example, you might want to create a database user with read-only privileges. However, due to the way that editioned objects are treated, granting a privilege on an editioned object directly may cause temporary invalidation of any dependent objects. 



The concept here is to execute the GRANT statement for a given editioned object in the edition containing the actual copy of that editioned object.  This is an unfortunate consequence of Edition-based Redefinition. This is fixed in Delta 6 with a new API: AD_ZD.GRANT_PRIVS.  The AD_ZD.GRANT_PRIVS procedure is meant to operate on EBS APPS "logical" objects, meaning the object present or exposed in the APPS schema and identified by its name or synonym in the APPS schema.  Such an object could be:

 1. An editioned code object,  actually present in the APPS schema.
 2. An effectively-editioned table (APPS Synonym -> Editioning View -> Table).

The GRANT_PRIVS API is specialized to the task of granting permissions on EBS objects (exposed in APPS) to other users.  For grants on editioned custom objects, you could make synonym to the custom object in APPS, and then run GRANT_PRIVS on that synonym name.  We could look at extending the support in GRANT_PRIVS to directly handle custom objects not exposed to APPS.

Workaround 1: Move to the Delta 6 code level (or higher) and grant privileges using AD_ZD.GRANT_PRIVS procedure instead of direct DDL

Workaround 2: Start an online patching cycle (adop phase=prepare), connect to the patch edition (source EBSapps.env patch), execute native DB grant statements in the patch edition, then complete the patching cycle (finalize, cutover, cleanup).

To avoid such invalidation, use the procedure AD_ZD.GRANT_PRIVS:


procedure  GRANT_PRIVS( X_PERMISSIONS in VARCHAR2,
                        X_OBJECT_NAME in  VARCHAR2,
                        X_GRANTEE     in VARCHAR2,
                        X_OPTIONS     in VARCHAR2 default NULL);
end;


Parameters: 

•X_PERMISSIONS: Permissions to be granted to the grantee.  This should be in upper case.
•X_OBJECT_NAME: Object to which the permission(s) apply. This should be in the exact case as defined and must exist in the database.  By default, objects will have uppercase names.
•X_GRANTEE: Other schemas and roles receiving the grant.
•X_OPTIONS: Grant options, for example: ‘WITH GRANT OPTION’.


Example
================

If you want to grant SELECT on FND_USER To XCUST Schema then you must use below syntax

To Grant:

SQL> exec AD_ZD.grant_privs('SELECT', 'FND_USER', 'XCUST');

PL/SQL procedure successfully completed.

To Revoke:

SQL> exec AD_ZD.revoke_privs('SELECT', 'FND_USER', 'XCUST');

PL/SQL procedure successfully completed.

No comments :

Post a Comment

Dropping Old Editions With the Actualize_all Phase

No comments

In EBS R12.2, as each online patching cycle is completed, the database will accumulate an additional old database edition. An additional column ZD_EDITION_NAME is populated in the seed tables.If the number of these grows too large, system performance will start to be affected. When the number of old database editions reaches 25 or more, we should consider dropping all old database editions by running the adop actualize_all phase and then performing a full cleanup. I normally consider to do it, once the count reaches 15 editions in my Production environment.

Important: This procedure will take a large amount of time (significantly longer than a normal patching cycle), and should only be performed when there is no immediate need to start a new patching cycle.

Before starting, you should ensure that the system has the recommended database patches and latest AD-TXK code level installed.


When no patches need to be applied in Online Patching

To proceed, run the following commands in the order shown:
$ adop phase=prepare
$ adop phase=actualize_all
$ adop phase=finalize finalize_mode=full
$ adop phase=cutover
$ adop phase=cleanup cleanup_mode=full

Old database editions would be cleared now


OR

Every-time online patching is performed:

$ adop phase=prepare
$ adop phase=apply patches=1,2,3
$ adop phase=actualize_all
$ adop phase=finalize finalize_mode=full
$ adop phase=cutover
$ adop phase=cleanup cleanup_mode=full

It has to be performed just before phase=finalize/cutover

No comments :

Post a Comment

How to Pass Apps Credentials Automatically to ADCGNJAR

No comments
Please use below script to automatically pass apps credentials.

{ sleep 1s; echo apps; sleep 1s; echo appspassword;} | adcgnjar

No comments :

Post a Comment