Run the adchkcfg utility to get an html report that lists all the files and profile options that get changed when you run AutoConfig.
1. Execute autoconfig in check mode
2. Check reported changes in $APPL_TOP/admin/
3. Update XML file or customize relevant template appropriately
DO NOT UPDATE configuration files directly without modifying the XML file or template appropriately. The Autoconfig custom template, key to autoconfig stabilization, is a very recent feature and this document will help to define the process.
Following steps must be performed in the sequence to run autoconfig in an On Demand environment:
• Identify Customizations
• Implement Config Changes and Customizations
• Run Autoconfig in the correct sequence
Identify Customizations
Downtime not required in this step as it is a “read-only” operation on the configuration file.
1. Execute Autoconfig in Check Mode
Login using Unix account to Apps user
cd $AD_TOP/bin
Execute following command to run adconfig in a test mode:
${AD_TOP}/bin/adchkcfg.sh contextfile=
This will generate the report containing the differences. The location of the report will be output to your screen that is generally $APPL_TOP/admin/
$ adchkcfg.sh contextfile=PROD_ocvmrh2177.xml appspass= welcome
Testing AutoConfig application and building diffs for this environment.
Loading APPL_TOP environment from /u01/applmgr/1159
o [ Test mode ]
o Using Context: /u01/applmgr/1159/admin/ PROD_ocvmrh2177/out/04051937/ PROD_ocvmrh2177.xml
o Context Value Management will now update the Context file
o Updating Context file ... COMPLETED
o Testing templates from all of the product tops ...
o Testing AD_TOP
o Differences log written out to: /u01/applmgr/1159/admin/PROD_ocvmrh2177/out/04051937/cfgcheck.txt
o The logfile for this session is located at: /u01/applmgr/1159/admin/PROD_ocvmrh2177/log/04051937/adconfig.log
o
2. Identify customization by performing the following steps carefully for every file:
• cd $APPL_TOP/admin/
o (e.g cd /u01/applmgr/1159/admin/PROD_ocvmrh2051/out/03171715)
• ls cfgcheck.txt
o this will have the summary for customization changes
• ls x_*
o this will show the diff associated with each file
o For example, if there is a customization in httpd.conf for a given instance, you will find ‘x_httpd.conf’.
o An example difference file:
o x_appsweb_PROD_ocvmrh2177.cfg
o Checking differences between
o Existing file(<) : /u01/applmgr/common/html/bin/appsweb_PROD_ocvmrh2177.cfg
o New file(>) : /u01/applmgr/1159/admin/PROD_ocvmrh2177/out/04051937/appsweb_PROD_ocvmrh2177.cfg
o Note: You will lose the custom changes in the existing file as listed below. Please resolve the differences before you run AutoConfig in normal mode. Use begin custom/end custom blocks to retain your customizations.
o ==============================================
o Differences
o =====================================================
o 32c32
o > serverURL=/forms/formservlet
o -----
o < serverURL = /forms/formservlet?ifip=100.100.100.100
Implementing Configuration Changes and Customizations
3. Repeat these steps for every configuration file change:
Identify the template file
View the header in the respective configuration file (appsweb_PROD_ocvmrh2177.cfg in above example).
Second line of header would show the name of template file:
Forms Web CGI Configuration File for Oracle Applications 11i
$Header: appsweb.cfg 115.127 2003/11/06 05:15:23 skghosh ship $
Apps templates could be found in $FND_TOP/admin/template or $AD_TOP/admin/template
Review the type of customization
Check the entry for respective change in template file:
Changes which can be implemented in XML file
In above case, template file appsweb.cfg has following entry for serverURL:
serverURL=%s_forms_servlet_serverurl%
If the value is enclosed in % signs, the string within the % is the name of context parameter. When autoconfig runs, it would take the value of this parameter in XML file and update it on this line.
To implement this change properly, you would need to find this parameter in XML file and update it to proper value.
Changes which require template customizations
If the config change were to a value which is hard coded in Template file, you would need to customize the template file. For example:
< CustomLog "| /u01/applmgr/product/iAS/Apache/Apache/bin/rotatelogs /u01/applmgr/product/iAS/Apache/Apache/logs/access_log 86400 " common
-----
> CustomLog /u01/applmgr/product/iAS/Apache/Apache/logs/access_log common
Corresponding template shows:
CustomLog %s_tp%/Apache/Apache/logs/access_log common
To generate correct entry as above, template needs to be modified as follows:
CustomLog "|%s_tp%/Apache/Apache/bin/rotatelogs %s_tp%/Apache/Apache/logs/access_log common
Customizing Templates
Once you have identified which template needs to be customized and what changes are required, perform following steps:
cd $FND_TOP/admin/template (or AD_TOP if template is there)
mkdir custom (if it doesn’t exists)
cp httpd_ias_1022.conf custom (copy current template to custom directory)
Edit httd_ias_1022.conf and make changes as decided above.
When making changes to conf files or templates, care must be taken to use macros that are instantiated by autoconfig and not hardcode any values in the conf files that could potentially cause failures in other scenarios like refresh, clone etc. (e.g.: hard coding ORACLE_SID instead of using macro %s_dbSid% which causes autoconfig to replace it with the proper ORACLE_SID.
Sample MACROS
List of sample macros can be reviewed from the following template file:
$AD_TOP/admin/template/adctxinf.tmp
Differences which can be ignored
If the difference only includes context variables, these can be ignored.
====================================================
Differences
====================================================
262c262
>security.allowedAddresses=127.0.0.1,auohssohi01.oracleoutsourcing.com,%s_allowed_addresses%
Running Autoconfig in correct sequence
For a multi-midtier environment, Profile options needs to be updated from Admin node only. To avoid updating profile options from other nodes, previously we used to run autoconfig with wrong password. However that does create other problems. Here is a better way to do it:
4. Run autoconfig on all MTs except Concurrent Node with following options:
adconfig.sh run=INSTE8_SETUP contextfile=
Previously it was done by running adconfig.sh with wrong password.So that it may not connect to database.hence couldn’t update profile options.
5. Run autconfig on Concurrent Node (incase of PCP it is Primary Concurrent Node)
adconfig.sh contextfile=
If in the future, a new patch is installed, which happens to replace the original template, autoconfig will detect this (via version in the "Header" section of the file) and refuse to proceed with autoconfig until the custom version of conf file is updated. The following error is spit out by autoconfig such a situation is encountered.
"Version Conflicts among development maintained and customized templates encountered; aborting AutoConfig run."
This error occurs when a patch brings a new version of a template that is already customized. In those cases, you are required to customize the new version of the template by comparing the development maintained template with customized template.
6. Perform post-autoconfig steps as per standard process such as starting of services, health check, buddy check etc.
This is regarding TNS failover entries issue .Check the varaible in xml file "s_alt_service_instances".if this is set then some other issue is there else the below statment should resolve there tns failover issue.
To generate the failover aliases, update the database tier context variable s_alt_service_instances.
You can specify a comma-separated description list of "servicename:instance" to manage connect time failover. For example:
'SERVICE_NAME:INSTANCE_NAME1,SERVICE_NAME:INSTANCE_NAME2'
This will generate a TNS alias in the tnsnames.ora file that fails over to INSTANCE_NAME1 when the current instance is not available. If INSTANCE_NAME1 is not available, failover is to INSTANCE_NAME2 instead.
To set up the failover listing, perform the following steps in the order listed:
1.Update the context variable s_alt_service_instances in the database tier context file, applying the failover rules as described above
2.Run AutoConfig on all database tiers
3.Run AutoConfig on all application tiers
These steps will generate the failover TNS alias
All backup configuration files from each AutoConfig session are stored in:
On the application tier:
On the database tier:
where:
You can run restore.sh (Unix) or restore.cmd (Windows) to roll back an AutoConfig session.
