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: