AutoConfig Customization

Autoconfig is a very effective configuration management tool, but there are times when it falls short of meeting all our requirements and it becomes necessary to customize it. Following are some of the examples where you would need to customize autoconfig. You need to add another zone to the Jserv.  In this case you would have to customize oracle supplied autoconfig template which corresponds to jserv.properties configuration file, to add entries for another zone, you would also have to create a custom template for the properties file for this new custom zone. You may also need to add some custom context variables to the context file for this new custom template. You have some custom product tops. You would have to add these custom product top environment variables to the formservlet.ini file to access the custom forms. In this case you will have to customize the formservlet.ini’s autoconfig template to add your custom product top variables. You can construct these product tops based on the $APPL_TOP's context variable i.e.%s_at%/<custom_product_top> or you can create new context variable for each custom producttop. In that case you will have to add these to the context file as custom context variables. You have developed a custom application and you want autoconfig to maintain all the configuration files of this custom application. In this case you will have to create custom driver files, custom templates and probably some custom context variables. All the above examples show that there are three types of customizations that should satisfy most of the custom requirements:

Adding custom context variables to the context file

Customizing an AutoConfig template file delivered by Oracle.

Creating custom Autoconfig templates and custom Autoconfig driver.

Adding Custom Context Variables:

Adding a context variable to the context file means, adding a node in the context file with mandatory attribute oa_var and optional attributes oa_type, oa_enabled and scope. This node will have only one child node that will be a text node holding the value of the context variable. Autoconfig doesn’t care where or at what level this node is put in the file. So to make this work you can use any xml parser and add the node to the context file at any position you like and it will serve the purpose. But there are two drawbacks to this method. One this would cause maintenance problem since it will be difficult to differentiate between custom and seeded context variables and secondly oracle's software is not aware of this customization, which means whenever we run adbldxml.pl oradclonectx.pl to clone the context file, we will loose our custom entries. The first problem can be easily overcome by adding all custom context variables under a top level xml node oa_customized and starting all the custom node oa_var values from "c_". Now we can easily distinguish between custom and seeded context variables and it’s easy to maintain since we know where all the customizations lie in the context file. In the context file section, I mentioned that the context file is created by plugging in instance specific values into the context file template $AD_TOP/admin/adxmlctx.tmp. So adding xml node oa_customized and all our custom variables under oa_customized to this template would take care of the second problem too. Now let's look at different ways of adding custom context variables.

Oracle Application Manager:

Oracle Application Manager from version 2.1 onwards provides us with extensive ways to manipulate the context files. Updating the context variables is one of them, which we looked at earlier. It also provides us with the option of adding custom context variables. Adding custom context variables in OAM results in following sequence of events:

OAM saves the custom context variable details like name, attribute oa_var value, attribute oa_type value, title and description into table fnd_oam_context_custom.

OAM updates the existing row's status to 'H' (History) for adxmlctx.tmp infnd_oam_context_files.

OAM inserts a new row for adxmlctx.tmp with status 'S'. This new adxmlctx.tmp has ourcustom context variable added under node oa_customized.

OAM Requests FNDFS listener of the destination node to update the adxmlctx.tmp on thefile system.

OAM Repeats the process for all the context files with status='S' and context_type=’A’

Using perl module TXK::XML:

Oracle Application Manager is indeed a neat way to add custom context variables but there are a few problems. We have to add one variable at a time, so in our report server configuration file example, for replacing maxconnect, cachesize, maxidle, initengine and englife we will have to repeat the process 5 times. This can be quite cumbersome as the number of variables to be added increase. Secondly we need access to Oracle Applications but there are times (like configuring a clone) when we want to add custom context variables but OAM is unavailable. This calls for a programmatic method to add custom context variables.Using perl module TXK::XML we can write a small perl program to add many context variables atone shot without needing any access to Oracle Application Manager. For doing this we have to first load the context file and the context template file as TXK::XML object and then use add Node method of TXK::XML package(class for OOP enthusiasts) to add the custom nodes. The only thing to note is that add Node expects a reference to a hash containing all the information about the node to be added. I am going to show you a piece of code for adding custom variables. It will add the custom variables mentioned in the above example of reports server configuration file. Following table details the information about the context variables we are adding.

The only question that remains is, how do we know REP60_server.ora is the template for reportsserver configuration file. In this case I found out by “grepping” for the configuration file name in the driver files (mostly adtmpl.drv and fndtmpl.drv since they manage most of the configuration files).The third field in the template’s file entry in the product driver gives us the template name. Before ADX.F this was the only way to find template files for configuration files. With ADX.F, since oracle has decided to completely support autoconfig customizations, they have provided a script $AD_TOP/bin/adtmplreport.sh to find out the template names. This script in turn runs the javaclass oracle.apps.ad.tools.configuration.ATTemplateReport. This script is a generic script to generate report on all the autoconfig templates and corresponding configuration files. But it also provides a way to find out the template file from the given configuration file and vice versa. It alsoreports if there is a custom template for the given configuration file.

adtmplreport.sh contextfile=/u01/home/applHOPP/admin/HOPP_jinzo.xml \ target=/u01/app/oracle/product/config/HOPP_jinzo/8.0.6/reports60/server/REP60_HOPP.ora verbose#########################################################################Generating Report .....#########################################################################APPL_TOP Context[AD_TOP]TEMPLATE FILE : /u01/home/applHOPP/ad/11.5.0/admin/template/REP60_server.oraTARGET FILE : /u01/app/oracle/product/config/HOPP_jinzo/8.0.6/reports60/server/REP60_HOPP.ora