Chapter 13: AutoConfig, Oracle Application Manager, and Other Management Tools

---

Two big changes that 11i brought that will, at some point, impact all Apps administrators are AutoConfig and the new Oracle Applications Manager interface. Both are powerful tools for your Applications DBA arsenal; both have features that will allow you to more easily, efficiently, and quickly do your job; and both have idiosyncrasies that mean learning them and learning how to deal with them can be a challenge.

AutoConfig

AutoConfig is a tool that came with later releases of 11i. It can be migrated to via a patch set if you are using a previous version. This tool supports the automatic configuration of Applications instances and collects all information needed to facilitate that automation into repositories (Applications Context for the application layer and Database Context for the database layer). When AutoConfig runs, it takes the information from these context files and uses them to help you to maintain the configuration of your system.

There are many benefits to migrating your system to AutoConfig enabled, not the least of which is the ability to clone with Rapid Clone. There is also the ability to maintain the configuration of the Application Layer, centralization of the configuration or all instances into one simple interface, and the ease of maintaining the maintenance tool itself (alterations and updates to the AutoConfig utility are delivered in the form of a patch).

The components that make up the AutoConfig environment are included in Table 13.1 with brief descriptions of each.

Table 13.1: AutoConfig Components

Component	Description
Applications Context	The Applications Context is a XML repository that is located within in the APPL_TOP. It contains configuration information that is specific to that particular APPL_TOP in the admin directory and the file has the naming convention of <SID>.xml (VIS.xml). While the files in the Context are easily readable (they are in XML format, they will open in a browser if you try to open them) and editable with any text editor, it is important that you not manually alter them, as AutoConfig can get a little testy if you do.
Database Context	The Database Context differs from the Applications Context only in that it resides within the RDBMS's ORACLE_HOME and contains configuration information that is specific to that database tier and its components. Again, it is important not to alter any of the files in the Context directly. All editing can be done through the context editor.
AutoConfig File Templates	These template files include generically configured named tags. These named tags are later replaced with your instance-specific configuration information from whichever Context you are dealing with.
AutoConfig Driver File	Every product in the Oracle E-Business Suite maintains a driver file used by AutoConfig. The driver file lists the AutoConfig file templates and their destination locations.
AutoConfig Scripts	A set of scripts that provide a simplified interface to the AutoConfig APIs.
Context Editor	While not entirely an AutoConfig component, the Context Editor (also comes as a patch) allows you the ability to edit the information found in the Context's context files. This is the only means of editing that AutoConfig appears to approve of as it manages the formatting in such a way that it does not cause AutoConfig to complain.

To determine if your system is AutoConfig enabled, look into your APPL_TOP directory, the admin subdirectory, and if you find a XML (most likely named <SID>.xml) then you are probably AutoConfig enabled on the middle tier. You will find the database version of the same thing in the $ORACLE_HOME/appsutil/ directory with the same naming convention. This file is used by the AutoConfig utility to make all configuration changes to the 11i environment.

If you are not AutoConfig enabled, make sure that you are at the correct versions of all of the required software and the correct patch sets before you start the migration process.

The commands that are used to run AutoConfig are found, on the application layer, in the $COMMON_TOP/admin/scripts/ <CONTEXT_NAME or SID> directory (this is where AutoConfig puts all of your start and stop scripts for the services on your application layer as well) and are either adautocfg.sh or adautocfg.cmd depending on whether you are on UNIX or Windows. It takes, as its argument, the APPS password on your system.

Keep in mind that when you run AutoConfig, it was built to maintain the out-of-the-box configuration. Whenever you run it, it creates a listing of all of the files that it intends to change. There are hundreds of files that it can make alterations to. The changes that it makes are based on its preexisting knowledge of what a typical configuration includes. If your environment differs greatly from the norm, you may find that the changes that it makes are unacceptable. Backups are made of these changed files; if you find that there are issues after you run AutoConfig, you can retrieve the backups of these files and replace the offending files. This is both good and bad news. Yes, you can get the old settings back, and quickly and easily get your system back up and running. However, you do not have any way to inform AutoConfig of the things that you just did or the things that you did not like that it did. You will now have to remember which files that it changed that you did not agree with the alterations in, and every time you run AutoConfig you will have to replace that file again. Every execution of the AutoConfig utility creates a rollback script that can be run to roll back all of the changes. If you want to roll back all of the changes that AutoConfig placed into your system, you can run the rollback script. The scripts are placed, on the application layer, in the following directory:

 %APPL_TOP%\admin\<CONTEXT NAME (or SID)>\out\ <MMDDhhmm> 

On the database layer, it is in the following directory:

 $ORACLE_HOME/appsutil/out/<CONTEXT NAME (or SID)>/<MMDDhhmm> 

The final directory — the MMDDhhmm directory — is created at runtime of AutoConfig. It is in the format Month Day hour minute. The log files of the AutoConfig session are in the same paths, but instead of "out" they will be in a "log" directory.

On Windows, you will find restore.cmd and, on UNIX, you will find restore.sh.

One very important note to keep in mind, restore does not make database changes. If AutoConfig changed any profile options, you will have to manually change these back, and since it may not have kept a record of what changes it was planning to make, you may have to manually find them.

Want to find out what changes that AutoConfig will plan on making? You can do this, too. I do it every time I have to run AutoConfig — when I patch, when I clone, any time anything suggests that AutoConfig be used to maintain my system. There is a script that can be run that will tell you what changes AutoConfig will make including all additions to directory structure, changes and deletions to files, and any binary file alterations that it intends to make. The script can be found in the following directory structures:

 Application Layer %APPL_TOP%\bin Database Layer $ORACLE_HOME/appsutil/bin 

The command to determine all changes that AutoConfig will make follows:

UNIX:

 adchkcfg.sh contextfile=<full path to context file> appspass=< your APPSpwd> 

Windows:

 adchkcfg.cmd contextfile=<full path to context file> appspass=< your APPSpwd> 

ADCHKCFG will create a file that contains a list of all configuration files that AutoConfig intends to change and the status of the files that it intends to change in relationship to the files that exist. Table 13.2 provides a description of the different statuses that can appear in that file, what they mean, and the ramifications that go along with the actions that they signify.

Table 13.2: ADCHKCFG File Statuses and Ramifications

Status	Comment and Ramifications
SAME	There exists a text file that is identical to the file that AutoConfig will create.
CHANGED	There exists a text file with different contents when compared with the file that AutoConfig will create. This means that, if this is not the first AutoConfig session that you have run, AutoConfig has discovered that the file in question was changed manually, outside of Context Editor and outside of AutoConfig. Be careful and examine files that have this status. They are likely to be the ones that will have to be replaced if something breaks.
UPDATE	There exists a text file with different contents when compared with the file that AutoConfig will create. AutoConfig has decided that it was not your fault, but that the file was updated by a new version. AutoConfig does not care in these cases.
SIMILAR	There exists a text file and it is similar to the file that AutoConfig will create. The differences in this case include the existence of different white space or a different order to the contents, but the same contents exist in the file. AutoConfig is not completely happy, but you probably will not get complained at by the utility and you probably will not have to worry about these files but you might want to check anyway. Sometimes, especially in the JServ files, order matters.
NEW	There is no current text file existing where AutoConfig will create the new file. You might want to make note of these.
DIRNEW	No directory exists where AutoConfig will create the new directory. It plans on putting something into this new directory. It may be planning on moving something that you used to know where it was and that you use frequently (like adstrtall.cmd or adstpal.sh or your database startup and shutdown scripts). You may have to do some creative hunting to find things after you run AutoConfig. While you probably do not care a lot where these new directories are, pay attention to them; they will probably be important at some point.
BINSAME	There already exists a binary file that is identical to the one that AutoConfig will create.
BINDIFF	There already exists a binary file that is different from the one that AutoConfig will create. Make note of these; you may have to retrieve the backups and overlay these if something breaks.
BINNEW	No binary file exists. AutoConfig will create the file in the location specified.

---