AutoConfig is the tool, which is used to configure oracle application systems. Its basically a perl script with a shell wrapper over it. At present there are more then 300 configuration files and environment files in application system. Whenever a change is made to any of the configuration parameter, the change needs to be propagated correctly to correct configuration and environment files. Managing such changes in such large number of files is really difficult.
AutoConfig uses a file called context file, which is used to configure changes. Context file is a XML file having all the parameters of application system. These parameters are part of some configuration file for some services or it may be part of some environment file. When we create an application system (using Rapid install), context file gets created automatically will all the parameters and there values. Most of the parameters take default value, where as some parameters takes the value that is supplied at the time of installation.
Optionally we can create context file separately using adbldxml.sh/adbldxml.pl script. These scripts are present in $FND_TOP/bin directory. adbldxml.sh in turn runs oracle.apps.ad.context.GenerateContext java class.
Context variables in the context file are organized in a hierarchical order, hence the choice of xml to store them. These context variables mainly lie under five top level parent nodes i.e.
oa_system,
oa_host,
oa_install,
oa_environments &
oa_processes.
Each top level parent node is further divided into further levels before you reach the real context variables.
Each placeholder in the template file has a corresponding xml node (a context variable) in the context file. They all have a mandatory attribute called oa_var, the attribute value for this attribute is the placeholder name. Each node is primarily identified by the oa_var attribute value and can optionally have other attributes like oa_type, oa_enabled scope and default. The node’s only child is a text node, which stores the placeholder’s environment specific value. From here on I will refer to this text value as the “text value of the context variable”. The description of these context variables along with their oa_var value can be seen in adctxinf.tmp (stored in $AD_TOP/admin/template).
---How it works---
Each configuration file has one (sometimes two, one for NT and one for UNIX) 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 wrapper 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%).
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”.
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.
AutoConfig Scripts
Key AutoConfig configuration scripts on UNIX (command files on Windows) include:
• adautocfg.sh - Wrapper script that passes the name of the specific environment context file to adconfig.sh.
• adconfig.sh - Invoked by adautocfg.sh, this script is a wrapper for adconfig.pl.
• adconfig.pl - Invoked by adconfig.sh, this Perl script calls the Java API to carry out the actual configuration tasks.
Directory Name Directory Contents
------------------------------------------ ------------------------
<INST_TOP>/admin/install/<CONTEXT_NAME> Install scripts
<INST_TOP>/admin/scripts/<CONTEXT_NAME> Control scripts
<INST_TOP>/admin/log/<CONTEXT_NAME> Log files
Phases of Operation
As AutoConfig parses the driver files, it carries out a series of actions, grouped into several distinct phases:
• INSTE8 - Instantiates AutoConfig template files to the AutoConfig configuration files specified in the relevant template driver files.
• INSTE8_SETUP - Executes setup scripts that carry out activities not involving connection to the database.
• INSTE8_PRF - Executes setup scripts that update profile options.
• INSTE8_APPLY - Executes setup scripts that carry out activities involving updates to the database.
• BINCPY - Copies the file mentioned from the source file to the configuration file,creating parent directories for the latter if necessary. AutoConfig will report an error if the source file cannot be found.
• BINCPY_IGERR - Copies the file mentioned from the source file to the configuration file, creating parent directories for the latter if necessary. AutoConfig will not report an error if the source file cannot be found.
AutoConfig carries out these actions in the following order:
1. All INSTE8 and BINCPY actions - Carries out all file instantiations called for during INSTE8, INSTE8_SETUP, INSTE8_PRF and INSTE8_APPLY, and all copying from source files to target configuration files.
2. INSTE8_SETUP actions - For the files that were instantiated in Step 1, AutoConfig runs all SETUP scripts.
3. INSTE8_PRF actions - For the files that were instantiated in Step 1, AutoConfig runs all PRF scripts.
4. INSTE8_APPLY actions - For the files that were instantiated in Step 1, AutoConfig runs all APPLY scripts.
At the end of this process, the required configuration files and profile options have been
created for the E-Business Suite installation.
It may on occasion be necessary to undo configuration changes. You can restore the previous configuration by running the restore.shutility, which enables you to roll back the changes made by an AutoConfig run. This is achieved by utilizing the backup copies of the configuration files that are created when AutoConfig is run.
Note: The backup files are located in
<APPL_TOP>/admin/<CONTEXT_NAME>/out/MMDDhhmm on the application tier, and
<RDBMS_ORACLE_HOME>/appsutil/out/MMDDhhmm on the database tier, where the directory name indicates the month, day, hour and minute of the AutoConfig run.
In R12
$INST_TOP/admin/log/$MMDDHHMM/adconfig.log