Oracle E-Business Suite Technology

Earlier versions of AutoPatch (adpatch) would automatically check whether the
prerequisites for the current patch were installed properly.  An important change to the AutoPatch defaults was made in the Applications DBA Minipack 11i.AD.I.2 release:  automatic checks for prerequisite patches are now disabled by default. 

When you run AutoPatch AD.I.2 and higher, sharp-eyed DBAs may notice the following warning:

  Attention: AutoPatch no longer checks for unapplied pre-requisite 
  patches. You must use OAM Patch Wizard for this feature. 
  Alternatively, you can review the README for pre-requisite 
  information.

As of AD.I.2 and higher, if you want prerequisites to be checked, you now must explicitly pass the parameter options=prereq to AutoPatch in addition to any other parameters that you may already be passing.  For example:

  $ adpatch options=prereq

This was a somewhat controversial decision within Development.  Proponents for disabling prerequisite checks correctly note that certain patches won't apply even when their prerequisites have been applied as part of other combined patchsets. 

The downside of this new default behavior is that you may end up applying a patch without knowing that the prerequisites are missing.  This is a particularly tricky problem to debug when dealing with technology stack patches.

So, our standing recommendations are to check a patch's README carefully, or just add the options=prereq parameter manually when running AutoPatch.

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

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:

• Using AutoConfig to Manage System Configurations with Oracle Applications 11i (Metalink Note 165195.1)
• Customizing an AutoConfig Environment (Metalink Note 270519.1)