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
