Friday, 19 May 2017

Register table and Columns to AOL

To register the table and columns in AOL the navigation is: 

There is no way to register table and columns in AOL via front end.

To register table and column in AOL you can use the below API called ad.dd package.

First create a table and grants to apps and create synonyms that table after that.

1.register table:-

Syntax and Example : 

 ad.dd_register_table('application short name',
                                   'table name',
                                   'table or view or synonym',
                                    'size'
                                    ,unused space'
                                    ,'used space');
COMMIT
/

2. Register columns :-

Syntax and Example :

ad.dd_register_column('application_short_name',
                                      'table_name',
                                      'index of the column',
                                      'column_name',
                                      'size',
                                       N,
                                       Y);

COMMIT
/

3. Check registered table and Columns :- 

A. You can use the below queries to check the registered columns :-

  select table_id  --into p_table_id
    from  fnd_tables
    where 1=1--application_id = p_apps_id
      and table_name = 'TABLE_NAME';

select * 
from fnd_columns 
where table_id = p_table_id;

Or


B.navigate to the below tab :-

Open Appliaction Developer---> Appliaction--->Database--->table.(In table mention the table name(which you want to query), user table name,columns,user column name). 

Thursday, 11 May 2017

Navigation to Check WF mailer E-mail Address

Navigation :-

Oracle Workflow Administrator  -> Oracle applications manager -> Workflow manager -> Service component -> Workflow notification mailer.


It will look like the below :-


Wednesday, 10 May 2017

AutoConfig (adconfig)

Background:

Oracle Applications has a complex architecture with many pieces of technology. For example Apache Web server, Apache Jserv, Forms Listener servlet (or forms server) etc. each of these has its own set of configuration files , which need to be set up correctly to function properly. Moreover Oracle Applications uses many profile options (e.g. Applications Web Agent, Applications Framework Agent etc) and other bits of information in the database to make the navigation seamless. These also need to be set correctly to function properly.Oracle Applications 11i consists of lots of configuration files and lots of profile options, which need to be all correctly set for the applications to work. Managing these profile options and configuration files manually may give errors.So Autoconfig is a tool provided by the Oracle E-Business Suite to maintain these files and profile options. We can say AutoConfig is a collection of templated configuration files that are used in combination with the appropriate database and applications context files to produce standardized environments.

What Is AutoConfig? 

Autoconfig is an 11i configuration tool (set of java classes run from perl/shell scripts) introduced in 11.5.4, which eliminates the need to manually maintain these configuration files and profile options.
Autoconfig maintains the environment specific values for the 11i environment in an xml file (stored in $APPL_TOP/admin). When autoconfig  run it overwrites the existing configuration files with new ones that it creates by merging the templates and the context file, it also updates the database by running the script it instantiates (merging a template with the values in the context file is termed as instantiating the template in Oracle parlance) from the script templates. That’s essentially what autoconfig does i.e. Instantiating configuration files from templates and updating database with values from the xml file. It does not move directories, check for availability of ports, update DNS entries and so on. These have to be done manually.


Please Note: Application context file called the .xml contains the configuration

information for the application tier & is located in $APPl_TOP/admin for each

node of application tier.

Database context file called the .xml contains the configuration information for

the database tier & is located in $ORACLE_HOME/appsutil/
  

How does it work?

Each configuration file has one corresponding template file (provided by autoconfig patches, stored in $PROD_TOP/admin/template directory). Profile options and other instance specific information in the database is maintained by many sql scripts, called from shell/perl scripts. These scripts also have corresponding template files (also provided by autoconfig patches, in $PROD_TOP/admin/templates).
In these template files all the environment specific values are replaced by placeholders (like %s_webhost%).

 Following entry in httpd.conf 


 Timeout 300  is replaced by following in its template
$FND_TOP/admin/template/httpd_ux_ias1022.conf
Timeout %s_ohstimeout%      
Environment specific values for this placeholder is stored in an environment specific xml file (called application context file) stored in $APPL_TOP/admin.
 For e.g. 
 For the above placeholder the value stored in the xml file is:  
 <ohstimeout oa_var="s_ohstimeout">300</ohstimeout> 
  
Each placeholder has a corresponding xml node in the context file. The placeholder name is the value for the “oa_var” attribute of the xml node, the placeholder name without the prefix “s_” (generally) is the node name for the xml node and the value is stored as a child text node. These xml nodes are termed as context variables by Oracle documentation and each node primarily is identified by its oa_var attribute value. So effectively we can say that in the above case we replace “300” by context variable “ohstimeout” whose oa_var value is “s_ohstimeout”.

Configuration files can be easily created from the template file by just replacing all the placeholders with the corresponding values from the context file. This process is termed as “instantiating the template” in Oracle documentation. 

Driver files (stored in $PROD_TOP/admin/driver) store information about what to do with each template (e.g. instantiate it and replace the existing configuration file with it, instantiate it and run it). These files are named as <PROD_TOP>tmpl.drv (e.g. adtmpl.drv, fndtmpl.drv etc.) They contain one line for each template they manage.

When autoconfig (adconfig.pl or adconfig.sh) runs it just processes the driver file for each product, line by line doing what the driver file instructs it to do. The order of execution of each line is not sequential as we shall see later. The diagram below depicts the autoconfig functionality.




Updating Context file

Suppose we want to update the active port from to 80 , for this we will edit the application context file as follows:

Step 1 :Start all services 
$ $COMMON_TOP/admin/scripts/adstrtal.sh APPS/ APPSPASSWORD Step 2 :log on to OAM & click site map. 
Step 3:Click AutoConfig from the list of System Configuration features in the Administration tab. 
Step 4 : Click the Edit Parameter button for the application tier context file to access the Context File Parameters page & then click the system tab. 
Step 5 : Click the Focus icon (blue triangle) for oa_web_server. This expands oa_web_server and shows the web server related parameters. 
Step 6:Update the Web Port (s_active_webport) parameter from <> to 80.  Step 7 : Save it & answer the tab.Then logout of OAM

Location of AutoConfig Script
The autoconfig script uses information from the context file to generate all applications configuration files & updates database profiles. It is located in

Application tier:
$COMMON_TOP/admin/scripts/CONTEXT_NAME/adautoconfig.sh

Database tier:
$ORACLE_HOME/appsutil/scripts/CONTEXT_NAME/adautoconfig.sh

Configure the oracle application system with the updated Applications context file.

Step 1 : Stop all services 
$ $COMMON_TOP/admin/scripts/adstpall.sh APPS/ APPSPASSWORD

Step 2:Run the autoconfig script, $adautocfg.sh & respond to the prompts. 

Step 3:Check log files for any errors.log file for autoconfig is adconfig.log & is located in /admin//log/MMDDhhmm/ 

Step 4: Restart all services : 
$ $COMMON_TOP/admin/scripts/adstrtal.sh APPS/APPSPASSWORD



Rolling back an autoconfig session

Each execution of AutoConfig creates a roll back script in case we want to revert back to the previous configuration settings. For this we perform the following steps:

Step 1 :Shut down all services: 
$ cd $COMMON_TOP/admin/scripts/ 

$ adstpall.sh APPS/ 

Step 2:Restore AutoConfig session. 
$ cd $APPL_TOP>/admin//out/MMDDhhmm 
$ restore.sh 

Step 3 : Restart all services: 
$ $COMMON_TOP/admin/scripts//adstrtal.sh APPS/
Restoring the previous configuration 

Now we will use OAM AutoConfig to restore the Applications Context.

Step 1 :Log on to the Oracle Application Manager (OAM) & click site map.You will be able to log on but some services will be down. 
Step 2: Click AutoConfig from the list of System Configuration features in the Administration tab. 
Step 3 : Click the Show History button for the application tier context file to access the Context File History page. 
Step 4 :Click the Show Differences from Current Configuration button to see the recently updated parameters & Select Restore Previous Value for the Web Port and Discoverer Port parameters. 
Step 5 :Save & respond the tabs. Log out of OAM. 
Step 6 :Shut down all services: 
$ cd $COMMON_TOP/admin/scripts/ 
$ adstpall.sh APPS/ 
Step 7 :Run the AutoConfig script, adautocfg.sh & Respond to the prompts. 
Step 8 : View the log file and check for any errors. 
Step 9 : Restart all services: 
$ $COMMON_TOP/admin/scripts//adstrtal.sh APPS/ 
Step 10 :Log on to the Oracle Application Manager (OAM)

If the status of some services appears to be down, click the Refresh icon to update the  status.

If we want some more information , Then we can check following Metalink Notes : 
218089.1 Autoconfig FAQ 
165195.1 Using AutoConfig to Manage System Configurations with Oracle
Applications 11i 
387859.1 Using AutoConfig to Manage System Configurations in Oracle
Applications Release 12 
270519.1 Customizing an AutoConfig Environment 
364927.1 How To Run Autoconfig On Database Tier (DB-Tier) 
341322.1 How to change the hostname of an Applications Tier using AutoConfig 
338003.1 How to change the hostname and/or port of the Database Tier using AutoConfig 
315674.1 How To Verify if Autoconfig is Enabled on 11.5.x 
391406.1 How to get a clean Autoconfig Environment




Monday, 8 May 2017

How To License A New Product in Oracle Applications

After purchasing a license for an Application Product/Module, the first thing is to use license manager to record that the product/module is now licensed. 

Step 1 : Access oracle application home page as SYSADMIN and select Oracle Application
Manager (OAM) and then select Site Map -> Administration tab -> License Manager



License Manager is a web based utility in Oracle Applications Manager .It consists of  License Manager home page ,a group of licensing pages and report pages, as shown in below screenshot.

Step 2:  Click on products section




Step 3 : If we want to use License Manager to register Component Application, then we need to select License Component Application and click Continue.



Step 4: License Component Application product page appears as shown in below screenshot. Here this page lists all Application modules expanded to show individual components. The Boxes next to products that are already registered are grayed without a check. Click the blue triangle to expand and Click the check box next to the product(s), we want to register and click next and Submit the changes.




Step 5 : Click on OK , We have licensed the selected component application .


Step 6 : The Products are now licensed but not ready to be used as none of the Forms/Packages etc would have been compiled and loaded into the Database for these new Products. We need to use adadmin to generate the files for the new Product/s as shown below.
(a)   Login as applmgr and run the environment file
Su applmgr 
. ./APPSORA.env
(b)   run adadmin
[applmgr@erp ~] $ adadmin
(c)    Select Generate Application Files menu

(d)   Select all of the following Menu options:

-  Generate message files
-  Generate forms files
-  Generate report files
-  Generate graphic files
-  Generate product JAR files
(e)   Back to ADADMIN Main Menu
(f)     Select all of the following Menu options:
-  Compile APPS schema
-  Compile menu information
-  Compile flexfields
(g)    Now run AUTOCONFIG,as shown below:
             
            $ cd /$COMMON_TOP/admin/scripts/PROD_erp
$ adautocfg.sh

Friday, 5 May 2017

Oracle AD Controller

 AD Controller is ad utilities used to monitor/ control the workers execution.
How to run AD controller. 
Step 1 : Login as Applications Tier  user & run the environment file.
su applmgr cd /d01/oracle/prodappl
. ./APPSORA.env
Step 2 : Run the following AD controller command.
                              [applmgr@erp ~]$ adctrl          
You will be prompted for the location of  APPL_TOP location , password of APPLSYS and APPS.  After providing the above information the AD controller menu will appear as shown below.
AD Controller Menu ---------------------------------------------------

1.  Show worker status

2.  Tell worker to restart a failed job

3.  Tell worker to quit

4.  Tell manager that a worker failed its job

5.  Tell manager that a worker acknowledges quit

6.  Restart a worker on the current machine

7.  Exit


        How to check the status of the workers?
After adctrl is started, we have to choose the first option "Show worker status".




Please Note: If there is no session ,used by the workers, then the following message will appear:
Error: The FND_INSTALL_PROCESSES table does not exist.
This table is used for communication with the worker processes, and if it does not exist, it means that the workers are not running, because the ad utility has not started them yet.
We should check the file adctrl.log for errors.
This is because the FND_INSTALL_PROCESSES table is created when AD parallel jobs start (not the AD utility) and is dropped when the task is completed.

        The meaning of each worker status.

STATUS
Description
Waiting
The worker is idle.
Assigned
A job was assigned by the manager to a worker but the worker didn't start the job.
Running
The worker is running a job.
Failed
The job failed due to an error.
Fixed, Restart
When a jobs restart after the error has been fixed (during this time the worker run the failed job).
Restarted
After the error has been fixed, the worker will have the status "Fixed, Restart" and after that "Restarted". (The status will not change to "Running")
Completed
The job was completed and the manager did not yet assigned another job to that worker.

Database Processing Phases concept


When a database patch/ operation will run, the tasks are divided into functions of the kind of modification. This is done by Oracle when the patch is created. Suppose a patch will create 4 tables and 4 sequences. In this case the patch driver contains 2 phases, one for tables creation and one for sequences creation. Because the sequences could be created in the same time, this will be done in parallel by using more workers.  

Here are some Database Processing Phases:

seq = create sequence

tab = create tables, synonyms, grants privileges on tables

pls = create package specification

plb = create package body  

vw = create views

Fixing a "Failed" worker


When a job fails for the 1st time, the job is deferred at the end of the phase and another job is assigned to that worker. 

 

If the job fails 2nd time, 

-  If the run time of the job was  < 10 min => the job is deferred at the end of the   phase and another job is assigned to that worker. 

-  if the run time of the job was >= 10 min => the job status will be "Failed".

 If the job fails 3nd time => the job status will be "Failed".

 To review the worker log information you have to check into 

$APPL_TOP/admin/<SID>/log/adworkNNN.log

Example: adwork001.log will be the log file for the worker number 1.

 After fixing the error we have to start (if is not already started) AD Controller and to use the option 2 "Tell worker to restart a failed job". When prompted we have to specify the worker which must be restarted. If all the workers are failed, we can type all to restart all the workers. 

Restarting a Failed Patch Process

During a patch process (or adadmin process) if a job fails and cannot be restarted the patch must be restarted. 

 Here are the steps for doing this:

3.  Tell worker to quit    (for all workers)  => to manually shutdown/ quit the workers  

4.  Tell manager that a worker failed its job                  

5.  Tell manager that a worker acknowledges quit    => the manager will stop, the AutoPatch will stop.  

restart the patch 

PLEASE NOTE: When the patch will restart all the information in the database about this session must be accurate. 

How to determine if a process is Hanging or not 


a)   We can check the log file to see if some information is added or not to the log file.

b)   We can determine if the worker process is consuming CPU by issuing below command.

        $ ps -eo pcpu,pid,user,args | grep workerid 

(c) We check if there are any child processes, which are consuming CPU by issuing following command:
                            $ ps -eo pcpu,pid,ppid,user,args | grep <Parent Process> | grep -v grep

Restarting a Hanging Worker Process

 
a)  kill at the OS level the processes associated with the Hanging Worker Process.

    $ kill -9 ProcesssNumber 

b)  fix the problem  

c)   Restart the worker (or the job)

Restart an AD utility after a Node Crash


a)  Start AD Controller 

b)  Choose "4. Tell manager that a worker failed its job" 

c)   Choose "2. Tell worker to restart a failed job"

d)  Restart the AD utility that was running when the node crashed.

Shutting down the Manager 

a)     Start AD Controller  

b)    Choose "3. Tell worker to quit" 

c)     Verify that no worker processes are running