Managing E-Business Suite Configurations with AutoConfig

Work is its own reward.  You can expect great rewards this year.

~ Paraphrased from Dilbert, Scott Adams

Historically, one of the biggest challenges facing any E-Business Suite system administrator was managing the countless configuration files for technology stack components. 

In the past, different E-Business Suite products would each have their own technology stack configuration recommendations.  For example, iProcurement might recommend that a certain parameter be set to a given value in httpd.conf.  Naturally, it's inevitable that a different product family would come along and recommend a completely contradictory setting for the same parameter. 

Further complicating things:  if the hapless system administrator chose to follow either recommendation, there was no guarantee that the new setting wouldn't break a third unrelated product.  It was enough to make grown sysadmins weep.

Enter stage left, AutoConfig

AutoConfig is a tool that automates the management of all configuration files for all E-Business Suite Release 11i technology stack components.  The Applications Technology Group now centrally controls all parameter settings for all configuration files for the E-Business Suite. 

You might reasonably have expected from the start, but there are over 200 products within the E-Business Suite, and gaining agreement from all development groups to centralize this kind of control within the Applications Technology Group was about as simple a political process as nominating a presidential candidate.  This took years.

That's all behind us now, and today, individual product families are no longer permitted to make recommendations for technology stack configurations of any kind, and any changes to known-good parameter settings are now centrally tested to ensure that they work with all 200 or so E-Business Suite products.  It's about time, and you're the main beneficiary.

Beneath the Hood:  AutoConfig

All of the information required for configuring an Applications instance is collected into two local XML repositories called the Applications Context and the Database Context.  This information describes your instance name, location of servers, and so on.  With the latest Rapid Installs, the information you originally provided at install time is the basis for the Applications and Database Context files.

When AutoConfig runs on the Application tier, it merges information from the Applications Context with presupplied configuration file templates to generate all application-tier configuration files and update database profiles.

When AutoConfig runs on the Database tier, it uses information from the Database Context file to generate all configuration files used on the Database tier.

If you're updating the configuration for an existing instance with AutoConfig, it will take a snapshot of your current configuration before installing the new configuration files.  You can roll back your configuration to any snapshot taken at any given date.  This allows you to experiment safely with different configuration options.  Didn't like the effect of the last change?  Just roll back to the previous AutoConfig snapshot.

But wait... there's more.  AutoConfig can also start and stop all technology stack components that it manages, and there are additional options for pregenerating test configuration files and examining the differences with your existing configuration.

AutoConfig Now Preserves Customizations

With all of these great features, as well as AutoConfig's devotion to motherhood and apple pie, the reluctance of sysadmins to use AutoConfig has been a source of some... ahh... perplexity within our team. 

After all, who wouldn't want to use a tool that guarantees a known-good configuration that works for all E-Business Suite products?  Who could possibly want the burden of managing configuration files themselves, with this as an alternative?

Well, a lot of you, as it turns out.  More than we expected, in fact. 

With some digging, we learned that you've invested in building your own custom configurations and don't want us overwriting your hard-earned changes.   Your customizations might address the need to:
  • Start additional services or processes when you start Oracle Applications services
  • Define and add zones to your JServ configuration
  • Extend Forms to integrate with a third party Java version
  • Develop customer applications that are maintained by AutoConfig
That's understandable, so we enhanced AutoConfig.  Your customizations are now preserved after running AutoConfig, and persist even after new AutoConfig templates are installed. 

So, What Did We Miss?

Despite all this, we still have the nagging impression that the majority of E-Business Suite system administrators still don't use AutoConfig.  We really don't know why.

Assuming that you're all rational, there must be good reasons.  Clearly, you have requirements that AutoConfig doesn't meet yet.

If you haven't switched over to AutoConfig yet, I would appreciate your posting a comment about new features that would encourage you to make the switch.

References:

Comments:

You really don't know why most DBAs avoid autoconfig? Really? I'm a independent consultant doing Apps DBA work now for about 8 years. I don't have a single client where autoconfig DOESN'T break a ton of things when it runs. This morning I did two database clones - one for each of two different clients.

With the first client, who is a reference account for Oracle, I have to go in and change about 15-20 profile options after each clone for things like directories, agents, filenames, ports, servernames...

With the second client, who just spent $1M+ on licensing and support fees and runs RAC, I had to make the tnsnames.ora file on my app tier writable only by root so that wonderful Autoconfig doesn't overwrite it, because Autoconfig can't handle RAC worth a darn and tries to always go to a specific instance, rahter then use service names... And don't even get me started on Autoconfig's current inability to handle a instance running multiple languages - I've had that TAR/SR open almost two months.

Autoconfig breaks more things then it fixes. And please don't tell me to open a TAR/SR - I've opened many many many of them on autoconfig issues, and even once I find someone who can speak and read/write English, its unlikely they'll agree to file a bug and work it.

Do you know what would be great? A metalink note that describes what each line of the Autoconfig XML file does and where that gets propogated to.

Feel free to contact me if you want specific examples.

Posted by jay Weinshenker on April 23, 2006 at 06:25 AM PDT #

Hi Steven,

I have been doing some testing the last two weeks involving running the E-Business Suite (11.5.10.2) with Database 10gR2, and I have noticed that the AutoConfig Context file for the Database Tier is no longer synchronised with the Database. When you look at the AutoConfig log files, it clearly states that this feature "is not supported".

What this means is that after you do the 10gR2 upgrade, you cna no longer edit the Context File for the DB Tier using OAM, which clearly goes against all the documentation stating that this is the tool that should be used.

Can you shed any light on why AutoConfig does not support saving the Context file in the database with 10gR2??

Regards,

Paul

Posted by Paul Murgatroyd on April 23, 2006 at 11:27 AM PDT #

Jay, this is exactly the kind of feedback we aren't getting enough of. This is gold.

This appears to break down into two areas: problems with AutoConfig, and problems with the Support process.

AutoConfig Issues:
------------------
Although I explicitly don't want this blog to turn into a support forum, this is a good discussion point. Specifics can lead us to more general improvements, so let's get into some details.

In the spirit of transparency, which allows others to learn from your experiences, I'd appreciate it if you could post a comment and:

a. Provide the version of AutoConfig and the associated template rollup patch that's installed at your first client's site

b. List the 15 - 20 profile options that get overwritten

c. Provide the same version/rollup information for the second RAC customer site (the latest version of AutoConfig should use service names instead of instance names; this is a bug that we thought we'd fixed).

Support Issues:
---------------
If you have Service Requests where you're hitting dead ends with AutoConfig, please send me a private email with the SR numbers. I can't promise anything, but I'd like to look into each of the SRs and find out why feedback like this isn't getting through to us in ATG Development.

Regards,
Steven

Posted by Steven Chan on April 23, 2006 at 03:33 PM PDT #

Paul, that's interesting -- I wasn't aware of this limitation for 10gR2. I'll get someone to look into this, and will post an update when I get to the bottom of this.

Regards,
Steven

Posted by Steven Chan on April 23, 2006 at 03:45 PM PDT #

While I am thinking about it, one of the most annoying aspects of AutoConfig is when dealing with multiple apps tiers, particularly when one of them is in a DMZ. We have been trying to get a DMZ config going for almost two years but the support was just not there, so we had to wait for the Tech Stack to catch up.
The main issue is this: when you run AutoConfig on the DMZ Tier, it overwrites ALL the Site Level profiles on the internal tier, including such important details such as the Login URL. As a result, the system is rendered useless until you rerun AutoConfig on the internal tier to set the Site Level profile back to what they should be.

My own opinion on the solution is simple - Site Level Profiles should either only be maintained by a single Context File, or there should be a flag set when running AutoConfig so that we have the option of skipping Site Level profile updates. It is a real pain to have to rerun AutoConfig every time we update something on the external server. Furthermore, the additional step requires that we schedule as outage with our clients, and they hate us continually taking the system down (and who can blame them!).

AutoConfig is certainly better than where we were witht he earlier releases, but I have forced all our guys to adhere to the AutoConfig customisation rules as defined. It is too much trouble to try and do anything tricky. There have been improvements made so that at least we can now use custom templates, create out own AutoConfig substitution variables etc, but I think there is a fair way to go with the more advanced configurations such as RAC, DMZ setup and scenarios where there may be 5 or more Web/Forms servers thrown into the mix.

I am curious to know - does Oracle ue AutoConfig for the GSI Setup? I understand you have about 50+ Web/Forms servers plus a DMZ, and I would be curious to know how it is managed.

Cheers,

Paul

Posted by Paul Murgatroyd on April 24, 2006 at 02:30 AM PDT #

Paul, one of our lead AutoConfig engineers suggests that either there are some procedural issues at play here, or you may be working with some older patches.

In a DMZ configuration, profile option values are read from the server level for most of the profile options and not from the site level. We would be interested to hear which profile options had to be reset at the site level to point to the internal nodes.

If you could provide your FND and TXK patch levels, along with a list of the profile options in question, we'll get a better sense of what your next steps should be. It's possible that we'll end up tracking this via a formal Service Request, but we'll see.

Regards,
Steven

Posted by Steven Chan on April 24, 2006 at 03:14 PM PDT #

Will be trying the new customization features and hopefully things will be better than the past experiences where we had to keep a list of things to do after every patching and hence AC run.

Posted by Sunil Choudhary on April 24, 2006 at 11:17 PM PDT #

Hi Steven,
We will check what the current behaviour is and see what happens. My understanding is that when you run AutoConfig on the external apps tier, the APPS_WEB_AGENT and Login URL get changed at Site Level, which renders the internal web tier unusable until you rerun the internal apps tier AutoConfig. We are using TXK Rollup L with ATG_PH.H.CU2 (we are still on 11.5.9), but I will have my offsider check what is happening.

Paul

Posted by Paul Murgatroyd on April 25, 2006 at 03:42 PM PDT #

One other Issue i have noticed is with Autoconfig regenerating adconfig.txt

Suppose you run Autoconfig in this order on a Shared ApplTop 3 Node Install
1. Admin Tier (CM)
2. Apache Tier
3. Forms Tier

Now the generated adconfig.txt contains "YES" only for forms and formsdev Node. Assume after a month we apply a patch onto this environment since adconfig.txt contains no for most of the nodes, the behaviour of adpatch is different. Yes if we review the adpatch lgi files we can understand what happened but damagae is already done, we need to rerun the patch ensuring everything is "YES" in adconfig.txt file.

as i understand adconfig.txt controls the behaviour of adpatch and adadmin, if we query metalink for Issues where "Generate Forms" is not available on this Node is due to adconfig.txt, But in a shared appltop we should be able to do any maintainance from any tier??

Another thing i have noticed is if you have implemented Forms Metric Load Balancing in production and you clone production, adcfgclone.pl doesnt ask anything about Forms Metric Configuration and run adconfig and starts the services it happened to me that after cloning from production that my cloned instance registered with Forms Metric Server on Production and any forms session which was load balanced to this Forms metric client started failing, it was really tough to figure why forms metric server was load balancing to a development environment, but damage was done to production Users until if figured that development forms metric client connected to production forms metric server.

Regards
Murali

Posted by Murali on April 27, 2006 at 06:09 AM PDT #

While I can't disagree with the fact there have been issues with autoconfig in the past, I would like to change the tack of the thread slightly. Autoconfig is a great tool and I won't repeat Stevens's comments on the benefits for an apps dba, but I believe it is how autoconfig issues are handled that is vital. The way I see it is that this tool is going to be used to configure apps for the foreseeable future so why fight the tide, resistance is futile. Taking this approach to autoconfig has given me many happy customers and I'll try to elaborate on this with an example of a site visit to a customer who didn't like/use autoconfig...I went to customer X who was reporting many different issues with their apps install after patching. They also complained about the amount of administration that the apps instance required generally (especially when cloning). Upon arriving onsite I watched them apply the patches and then run autoconfig, however after it completed they ran a script and performed a number of manual changes (which was not uncommon before TXK.L but the list was huge). What does the script do I asked... The script actually overwrote 'all' of the apps configuration files with copies from a backup directory. The backup files contained a large number of manual fixes which they had added over time to resolve different issues; these files were then maintained with any new fixes. What they didn't know was that by overwriting the apps configuration files, a huge number of knock on issues were being hit because the new apps code needed the configuration changes made by autoconfig to function properly. As the DBA's were not aware of this it lead to many tar's being logged, which were then harder to diagnose because autoconfig was being sidelined. The situation was also made worse each time because if the customer found a fix that worked before Oracle support did they would use it without getting the fix verified. This led them away from the path of autoconfig (which subsequently invalidated some of these custom workarounds the next time the configuration changed)What to do?I took a clone of production to which I applied the latest ADX and TXK patchsets. These patches alone resolved 70% of the issues in the list but did also introduce some others. I won't bore you with the details of the remaining issues but they fell into the following 3 categoriesAutoconfig maintained configuration issues
Non autoconfig maintained configuration issues
Out of date procedural documentationOnce I had resolved the documentation and autoconfig maintained configuration problems, I moved onto the non-autoconfig maintained configuration issues. I found that most of these had known bugs with workarounds which I then added to a new procedures document (until a fix was released). There were however a number of issues which were not covered. For each of these a bug was logged, some for which I got autoconfig friendly fixes for, some it was easier to do manual updates to the configuration files after an autoconfig run (e.g. virtual host entries in httpd_pls) Customer X is now able to run autoconfig, apply patches and clone without issue and this has continued since I left site. They are currently implementing TXK.L to remove the need for any workarounds or manual updates. This customer is an extreme version but I have seen many variants to the above scenario. Given the diversity of implementations the ebusiness suite has, matched with the constant movement in technology I don't think autoconfig will ever be bug free but by following the rules below it will make life a lot easier...1:- Get any custom fixes verified by Oracle support2:- If an issue is found where autoconfig is not handling a configuration parameter properly ensure that a bug is logged3:- If not on TXK.L ask for autoconfig friendly workarounds in the TAR.4:- If you have any outstanding autoconfig issues ensure that any new ADX or TXK patches are applied to a test instance, Oracle might have fixed the problem for you. 5:- Ensure all procedural documentation is updated as soon a fix or workaround is released.One question I do have though...Is it safe to say that there is no need for functional application testing to occur If I was to apply only ADX and TXK patchsets? A concern many customers have is the project cost of applying none business driven patches into production, I've never been sure if it's required.

Posted by Colin Parry on May 03, 2006 at 10:32 AM PDT #

A very interesting case study, Colin, and eloquently stated. I think this illustrates the core points nicely:

A. AutoConfig is not perfect but is superior to having to manage all of these configuration files manually.

B. We will only get closer to perfect with feedback and suggestions from E-Business Suite DBAs.

As for your question about testing:

I always recommend a minimum set of basic functional tests in a testbed before rolling a new patch into production. At the very least, some of the most important major business flows should be covered for Forms, OAF, and CRM/JTT after applying even small patches.

Regards,
Steven

Posted by Steven Chan on May 04, 2006 at 10:03 AM PDT #

We are using Discoverer 4i in 4 nodes APPL_TOP shared configuration.
As far as I know autoconfig is not managing Discoverer configuration so far.
At least we are editing $IAS_CONFIG/8.0.6/discwb4/util/pref.txt to put a correct MachineIPs address (run $IAS_CONFIG/8.0.6/discwb4/util/applypreferences.sh) each time we running autoconfig (clon).
Is this bit of configuration addressed by latest versions TXK/ADF patches?

Posted by Yury Velikanov on May 07, 2006 at 11:47 PM PDT #

Paul, following up on your comment about the inability to edit the Context File with OAM after the 10gR2 upgrade:  Our engineering team has reproduced this bug internally and is investigating the root cause now.  Something is preventing the context files from being synchronized between OAM and the database tier, so OAM continues to display context files from the old 9i ORACLE_HOMEs.I'll post a cross-reference to a fix as soon as it's available.Regards,Steven

Posted by Steven Chan on May 08, 2006 at 12:12 AM PDT #

Update on the Context File + OAM + 10gR2 upgrade issue referenced above:This is now being tracked in bug 5213480.Regards,Steven

Posted by Steven Chan on May 09, 2006 at 12:31 PM PDT #

Yuri, I'm not sure I follow. Do you have a hardware-based load-balancer in front of your Discoverer 4i four-server cluster?

Regards,
Steven

Posted by Steven Chan on May 09, 2006 at 04:21 PM PDT #

I'm pleased to provide the final update on the Context File + OAM + 10gR2 upgrade issue, bug 5213480:  This is fixed in the latest AutoConfig Template Rollup Patch M:http://blogs.oracle.com/schan/2006/04/autoconfig_template_rollup_pat_1.htmlWe'll be updating our 10gR2 RAC documentation to reflect the new recommendation to install the latest AutoConfig rollup.Regards,Steven 

Posted by Steven Chan on May 10, 2006 at 05:25 AM PDT #

I have a specific issue you can address. I just opened a service request about it, so hopefully it makes it to you. I have a rac install, database and listener on the database tiers, and apps on the middle tiers. I just updated all the template files, and applied the latest autoconfig patches. When running autoconfig for the database RDBMS, autoconfig creates the init<SID>.ora file, specifically the local_listener parameter from the local_listener entry in the xml file. Oddly enough, after running autoconfig, when I shutdown the instance and attempt to bring it up using the newly created init.ora files, I get an error, a syntax error I think with the local_listener parameter. Turns out the value of the local_listener needs single quotes around it to work. So I put single quotes around it in the xml file, rerun autoconfig, and check the init.ora file. The quotes are there, and the instance starts. Yippee!!!! Then I go to use the database, and through a series of events using the aliases in the tnsnames.ora file, and its ifile, I find out that the alias in the tnsnames.ora file that looks like the local_listener entry in the init.ora file also has quotes around it. And that's a very bad thing. Why in the world are you using the same xml parameter to define two different things in autoconfig. I can't not manually change one of them. The Service Request I just opened for this problem is 5442353.992. This is just one of many similar instances of having to chase down where a particular xml file entry is used. Change it in the xml file, and who knows where it's changed out in the environment. Many many hours of grepping templates in all the different APPL_TOPs to find them. Very frustrating. I too would like a document that lists all the parameters in the xml files and the templates where they are actually used. If you search Metalink for any number of the parameters, you never get anything. That's frustrating too. Well, I'll let you chew on this for a while. If you have a quick fix besides making the manual change after every autoconfig run, I sure would like to hear it.

Posted by Rich Sutherland on May 19, 2006 at 11:09 AM PDT #

Rich,Thanks for the specific example.  I've logged the requirement via bug 5226545 to document all AutoConfig parameters formally.  This is being reviewed right now.As for your SR, this behaviour sounds like a bug or a configuration issue, as there shouldn't be any need to go through these gyrations to accomplish the goal with RAC.I'll ask our RAC Development team in ATG to monitor this and back up the Support Engineer assigned to your SR.  They'll escalate to us as needed.Regards,Steven

Posted by Steven Chan on May 22, 2006 at 01:29 AM PDT #

I've finally figured out how to get this blogging infrastructure's administration tool to thread discussions.  As a result, I've just realized that this question went unanswered.You're correct in asserting that AutoConfig doesn't control Discoverer preferences today.  MachineIP in pref.txt is supported only for Discoverer 4i, by the way.  It's not supported in Discoverer 10g, which supports the standard architecture for OracleAS 10g load-balancing.AutoConfig doesn't touch the pref.txt file, so there should be no reason to rerun applypreferences.  If you can verify that this is needed for your environment, I'd like to ask you to log an SR (forward the number to me), so we can investigate further.Regards,Steven 

Posted by Steven Chan on May 25, 2006 at 09:23 AM PDT #

Thanks Steven. I see no update on the SR mentioned but I'll keep looking. Another question I have is specific to the TXK pseudo module. Stated in many places is the fact that the TXK pseudo module is not updated via mini-packs anymore, but thru rollup patches. I opened SR 5445786.992 to ask a question about TXK.M and ADX.F. As you can see when you read the SR the person working on it is quite confused, and not very well written. But he/she did admit the mistake, which was just fine. Then I asked another question which as of yet has gone unanswered, so I'll ask you the same question. I'll restate it here in case the SR isn't clear. In my 11i environments I have TXK.A installed because it came with 11.5.9 Rapid Install. TXK.B mini-pack is not installed. Now as I make my 11i environments rac aware by applying a bunch of patches, I find that TXK.M is the latest rollup patch for TXK pseudo module so I install it, and get things working up to a point which is almost acceptable. Then I go back and investigate the whole mini-pack vs rollup patch again, and find that TXK.B was never applied. My question in the SR that was unskillfully side-stepped was: Do I need to applied TXK.B mini-pack even though I have already applied TXK.M rollup patch? It's again very confusing. When I applied all the autoconfig patches to make my environments rac aware, I ran adconfig using the pre-req function, and it told me of some other patches I needed as pre-reqs, but not TXK.B mini-pack. Just another question in the long list of questions I have about 11i and autoconfig. Thanks. Rich

Posted by Rich Sutherland on May 30, 2006 at 04:19 AM PDT #

I think I forgot to include the SR number in the previous comment. It's 5371250.993. Thanks again. Rich

Posted by Rich Sutherland on May 30, 2006 at 04:21 AM PDT #

Rich,I sympathize with your experiences with Oracle Support.  I'm focussing this blog on news and tips -- and not as a support forum -- so I'll keep my response at the conceptual level.Here's a vital tip for improving your support experiences:  ask only one question per SR.  I know this is a pain, but there's a good reason for this:Oracle reviews SR statistics to track which products, areas, and topics are generating support calls.  This policy allows us to make accurate staffing projections, as well as finger those products that are triggering loads of support calls.  For high-SR-volume products, we attempt to do root cause analysis to reduce the calls at the source.For this reason, Support Engineers are actually not supposed to answer more than one question in a SR, since it messes up the overall tracking.  To answer your question directly:All TXK rollup patches are cumulative.  So, TXK.M includes TXK.B and everything in between.  If you've applied TXK.M, you don't need to apply TXK.B separately.Regards,Steven

Posted by Steven Chan on May 30, 2006 at 06:16 AM PDT #

Another specific example. After applying all the latest AutoConfig patches to make our environments rac aware, there are still a number of system profile options that are set to an instance_machine specific value in the apps. Four to be exact. Not a good thing. Clearly Oracle's direction in AutoConfig is to use an instance_machines specific contextname, but these are system profile options set in the apps, and they shouldn't be instance_machine specific.

When I created new xml files, it asked for instance, machine, and created the xml files that way. For example, we have a 2-node rac database called deva, database only on the database tiers. On the two middle tiers where all the apps reside, we have to manually set the sid on each middle tier to the corresponding database tier, so PCP will function properly (another short coming of AutoConfig). I digress. Sorry.

On the middle tiers (ljcqs112 and ljcqs113), I recreated new xml files as devaa_ljcqs112.xml and devab_ljcqs113.xml. In those xml files, the contextname is set to instance_machine. On 112, the s_contextname in the xml file is set to devaa_ljcqs112. When I run AutoConfig on 112, the previously mentioned options get set to a directory including devaa_ljcqs112. When I run AutoConfig on 113, these options get reset to a directory structure including devab_ljcqs113. So the option values change depending on which middle tier AutoConfig is run. Doh!!!!

I chased down where and how these options get set. One example is XNC_DEBUG_LOG_DIRECTORY set to /sv99/data/common/deva/log/devaa_ljcq112. The template used to set this option is $XNC_TOP/admin/template/xnccmprf.sh, and in that template you see the line:
DEBUG_LOG_DIR="%s_applcsf%/log/%s_contextname%".
This is the same for the other profile options. They are all set using the s_contextname variable from the xml files. If I change that variable, I change the whole AutoConfig process, and totally remove the instance_machine specific environment scripts, directories, etc., and that goes against what Oracle is preaching now.

The other options set like this are:
IGC_DEBUG_LOG_DIRECTORY uses %s_applcsf%/log/%s_contextname%.
Script is $IGC_TOP/admin/template/igccmprf.sh.
CN_IMP_SERVER_PATH uses %s_applcsf%/inbound/%s_contextname%.
Script is $CN_TOP/admin/template/ cncmprf.sh.
AMS_IMP_DATA_PATH uses %s_applcsf%/inbound/%s_contextname%.
Script is $AMS_TOP/admin/template/amscmprf.sh.

Why does AutoConfig use s_contextname for these options? For now to resolve them, I will have to customize 4 more templates to get these options set the way they should be, or do I have to manually set them after running AutoConfig, which is exactly what I am working to get away from.

Granted, if we don't have the modules installed or shared of which these options are a part, there is probably nothing I need to do, but what if we do have these modules installed?

Thanks again. Rich

Posted by Rich Sutherland on June 01, 2006 at 05:14 AM PDT #

Rich, thanks for your detailed case study.  I've asked our RAC team to review this and comment; stay tuned.Regards,Steven 

Posted by Steven Chan on June 01, 2006 at 07:12 AM PDT #

Just to update folks and clarify some delivery questions:

We have combined ADX and TXK rollup patches for configuration management. They will now be combined into TXK rollup patches, the first combined one being:
4709948 TXK (FND) AUTOCONFIG TEMPLATE ROLLUP PATCH M (APRIL 2006)
which includes the last ADX minipack:
3453499 ADX:Patch 11i.ADX.F

TXK produces Rollup patches for AutoConfig, Advanced Configurations, and Rehosted Technologies. These rollup patches get packaged together into a minipack. The last TXK minipack was:
3219567 Patch 11i.TXK.B Technology Stack Minipack B
released Nov-2004, was part of 11.5.10, and contained TXK AutoConfig RUP I (Oct 2004) - bug 3594604.
Each subsequent Rollup patch (RUP) includes the previous one.

Hopefully this clarifies the delivery of AutoConfig code.

On a separate note, I would like to thank everyone who posted comments about AutoConfig features. It took us a long time to get to this point and there are probably a lot more features you want. So if you can continue submitting here your favorite enhancement, we will do our best to include the most desirable ones.

Thanks,
--Ivo Dujmovic
Director of TXK Development Team

Posted by Ivo Dujmovic on June 02, 2006 at 11:59 AM PDT #

Rich

Let me try to answer your RAC specific questions

I am not sure why you have created instance specific xml files manually. Setting of sid values for CP tier has been taken care by Autoconfig. All you need to do is set value of s_cp_twotask to the corresponding SID that you want in the context file and execute autoconfig on each CP tier. Please refer to notes 279956.1 and 312731.1 for setting up of PCP in a RAC environment.

Regarding change of profile option values, Its recommended to set profile values at server level when you have multiple middle tier environment. Autoconfig only changes the profile options, which are set at site level and won't change anything if it has been set at server level.

I hope this helps.

Thanks
Pranjal

Posted by Pranjal Deosthali on June 05, 2006 at 08:18 PM PDT #

Rich, I can sympathize with your frustration.  Hang in there.  Even in the worst-case scenario where your specific
configuration  requirements can't be met by AutoConfig, sticking with
this discussion will help our architects understand what needs to be
improved in future releases.
It sounds like there may be something very particular to your environment that is driving your current approach.  Our RAC architects will be reviewing this thread to see what our next steps should be.Regards,Steven

Posted by Steven Chan on June 07, 2006 at 08:20 AM PDT #

Pranjal,

I really don't know how to respond to you without going back and starting from the beginning to explain to you how our environments are configured. Your comments are as vague as responses I get from Oracle Support on Service Requests I've opened on the same issues.

Posted by Rich Sutherland on June 07, 2006 at 10:57 AM PDT #

Steven,

I had a look at the features in AutoConfig that we can store custom environment variables. One problem I had with the feature was the prefixing of 'c_' to each custom environment variable defined. Given that a large number of custom concurrent programs at a site I work on reference the various custom environment variables it is not feasible to change all these programs to adopt the 'c_%' prefix. Is there a particular reason AutoConfig needs to have the 'c_' prefix to each environment variable? The ideal setup would be to replicate exactly what the custom environment variables defined in the custom environment script custom<$CONTEXT_NAME>.env into AutoConfig without having the 'c_' prefix appended.

Regards,
Mark

Posted by Mark on June 07, 2006 at 01:01 PM PDT #

Rich, Pranjal and our RAC team have taken a closer look at your currently open SR 5442353.992.  Since this blog's ill-suited for support-related investigations, they will be following up with you and your currently assigned Support Engineer via the Metalink SR process at this point.  Regards,Steven

Posted by Steven Chan on June 08, 2006 at 03:22 AM PDT #

Steven,

is there a public API that we can use to access autoconfig settings through SQL/PLSQL?

Regards,

Mark

Posted by Mark on July 12, 2006 at 06:06 PM PDT #

Mark,No, there's no public PL/SQL API for AutoConfig.  What are you trying to accomplish?  Regards,Steven

Posted by Steven Chan on July 13, 2006 at 12:57 AM PDT #

Hi Steven,

https://metalink.oracle.com/metalink/plsql/docs/EBS_R12.1_RCD_ATG_PreRelease.pdf
says autoconfig can be run in parallel. R12.1 has this feature. does this feature comes in 11i?

Thanks
Suresh

Posted by Suresh on August 24, 2008 at 04:44 AM PDT #

Hi, Suresh,

Good timing! We haven't formally announced support for running AutoConfig in parallel for EBS 11i yet. However, there's something in the works right now. Feel free to subscribe or monitor this blog for updates on this upcoming feature, which I'll be posting as soon as we release this formally.

Regards,
Steven

Posted by Steven Chan on August 25, 2008 at 03:20 AM PDT #

Hi Steve, I am looking at the running Autoconfig in parallel in 11i (11.5.9) in specific. What patch do I need to have in order to do that? Appreciate your insights as always. Anil

Posted by Anil on June 06, 2011 at 04:08 AM PDT #

Hi, Anil, Running AutoConfig in parallel is supported only in EBS 12. You will need to be on that release to take advantage of this AutoConfig feature. Regards, Steven

Posted by Steven Chan on June 07, 2011 at 04:29 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
4
5
6
7
8
9
10
11
12
13
14
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today