Autoconfig in 11i

1. Introduction and Scope

Autoconfig is a tool that supports automated configuration of an Oracle Application Instance.

It manages Oracle Application Release 11i Configuration Files , such as httpd.conf , jserv.properties and appsweb.cfg.

All information required for configuring an Application Instance is collected in a repository , called the Application Context. Autoconfig uses information from the application context file to generate all configuration files and update database profiles.

The application tier context file is an XML file in $APPL_TOP/admin

In Application 11.5.9 Release the Application Context File is named as .xml

The Context Name is a combination of SID and Hostname.
The Application Context file has the standard format _.xml

Limitations:Autoconfig does not undertake all aspects of configuration management, such as Operating System Level that have implication outside the context of Oracle E-Business Suite.

The Application Context Files

This is one of the most critical files in an Autoconfig enabled environment.

The context file contains enough information to configure all the other files necessary to setup and make available a particular environment.

The configuration information are supplied on a standard location, so that Autoconfig simplifies procedure for activities from upgrading a technology stack component through to starting and stopping application services.

Benefits of the Context Files

There is only one location to remember , instead of numerous files and directories distributed across the environment.
Avoid need for repeaded configuration information.
The APPL_TOP enviroment is readily described in one file.
Easier to integrate into the process of cloning new enviroments , as opposed to editing numerous files.
The XML format is easier to read and use than a variety of format , since the configuration information is represented in a platform independent format.
Able to handle Windows Registry Information.

Additional Features on an Autoconfig Enabled Instance

· Support shared APPL_TOP
(Single APPL_TOP distrubuted to multiple machines )

· Support Cloning of APPL_TOPs

· Allows Oracle Application Manager (OAM) and Autoconfig to work together to synchronize multiple nodes.

· Use of a single file allows services to be added or removed without having to modify the core startup/shutdown mechanism.

· Fewer files for Oracle Development to maintain and support , improving robustness and reliability across the E-Business Suite.

How Autocofig Works

Autoconfig uses template files to determine the basic settings that are needed.
There is one template file for each configuration file.

Different version of the template files exists for UNIX and Windows.
For Example :

httpd_ux.conf / httpd_nt.conf
adfrmctl_ux.sh / adfrmctl_nt.sh

The template files are located in the relevant $PROD_TOP/admin/template
Directories. For example :

$AD_TOP/admin/template
$FND_TOP/admin/template

What happens when Autoconfig Runs ?

When Autoconfig runs, it cycles through the various /admin/driver directories looking for Autoconfig template driver files.

Updating Template and Driver Files

A significant advantage of the use of Autoconfig is that template and driver files can be updated via Application Patches.

When patches are applied they have the appropriate template and driver files updated and finally when Autoconfig is run it updates the configuration and settings in a single go.

Template Files are used to specify the basic settings.
Driver Files have the list of names and location of the files for specific products.

adautocfg.sh

The script adautocfg.sh will update configuration files and profile options.

It also does the following ;

* The Instance Specific values that are found on the XML Context files are updated / configured by running the adautocfg.sh
* Copies any Customization that has been performed on the instance.
* Overwrites existing configuration files with new ones.
* Runs SQL Scripts to update database like updating the instance specific profile options.


Autoconfig uses the tmpl.drv files as drivers for the process as these files has the information about which source and destination files has to be merged and the commands/instructions that has are used

When adautocfg.sh scripts completes , it internally calls another script adconfig.sh. To this script adautocfg.sh passes parameters for processing.
adconfig.sh again calls the Java API to start the AutoConfig Engine located in $AD_TOP/java/adconfig.zip.

When AutoConfig is run it scans through each PRODUCT TOP/admin/drivers directory and searches for the appropriate template driver files. The files have the list of files that need to have token replaced along with the special actions that AutoConfig needs to perform.

Once Autoconfig is run it needs no additional input to perform the task.

Before running Autoconfig

- Middle Tier must be down
- Database Tier must be available
-
As Autoconfig runs it evaluates the tokens found in the template file and determines the substitute values required and creates a target file with the appropriate values substituted for the tokens.

The files created are know as target files and they are used during the configuration processes.

Other AutoConfig Scripts �.

adbldxml.sh and adchkcfg.sh

The adbldxml.sh script is used to create the Context File.

The adchkcfg.sh script generates a report that highlights the differences between the original configuration files and those that AutoConfig will generate.


2. Standard configuration steps description

2.1 Prerequisites

The following software component version must exist on the application tier and /or on the database tier.

· JDK 1.3.1
· Zip 2.3
· Unzip 5.x
· Perl 5.xxxx

2.2 Standard Configuration

The following are the activitites performed when a request for Autoconfig run is requested.

· Identify Customizations
· Implement Config Changes and Customizations
. Run Autoconfig in the correct sequence

Identifying Customizations

Identifying Customization is a read-only process and there is no
downtime associated with this operations. It could be safely executed when the instance is up and running. It is also termed as Check Mode of running Autoconfig.

Procedure to Execute Autoconfig in Check Mode

Login using Unix account to Apps user and make sure that the environment is populated.

Run the following command to run Autoconfig in Check Mode
$AD_TOP/bin/adchkcfg.sh contextfile=$APPL_TOP/admin/.xml appspass=
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/_ /out//cfgcheck.txt.
cfgcheck.txt have the summary for customization changes. This file contains the list of files that will under go a change during the next autoconfig run. In the report there will be three sections for each report.
· Existing File
· New File
· Diff File
Existing File is the original location of the Autoconfig Managed File.
New File is the file that gets generated when the autconfig is run. This file is stored in the autoconfig out directory for checking the difference.
Diff File is the file which has x_ as its prefix. This file is the differences output of the New File and the Existing File.
Syntax : DIFF ExistingFile NewFile > DiffFile
An Example differences is
x_appsweb_STESTI_astest02.cfg
Checking differences between
Existing file(<) : /stesti/applmgr/common/html/bin/appsweb_STESTI_astest02.cfg New file(>) :/stesti/applmgr/1159/admin/STESTI_astest02/out/
04051937/appsweb_STESTI_astest02.cfg
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.
====================================================
Differences
=====================================================
32c32
serverURL=/forms/formservlet
----- < serverurl =" /forms/formservlet?ifip=">Implementing Configuration Changes and Customizations

Repeate these step for every configuration file changes

· Identify the template file

View the header in the respective configuration file (appsweb_STESTI_astest02.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 /stesti/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
o List of sample macros can be reviewed from the following template file:
o $AD_TOP/admin/template/adctxinf.tmp
Differences which can be ignored
o If the difference only includes context variables, these can be ignored.
o ====================================================
o Differences
o ====================================================
o 262c262
o < allowedaddresses="">astest02.testsourcing.com"> security.allowedAddresses=127.0.0.1,astest02.testsourcing.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:

Run autoconfig on all MTs except Concurrent Node with following options:
adconfig.sh run=INSTE8_SETUP contextfile= appspass=
Run autconfig on Concurrent Node (incase of PCP it is Primary Concurrent Node)
adconfig.sh contextfile= appspass=

* 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.