Technical Configuration

Introduction

AutoConfig has historically been the tool to support automated configuration of the Oracle E-Business Suite instance. The information required for configuring an Applications instance is collected into two local repositories, called the Applications context file and the database context file. When AutoConfig runs on the application tier, it uses information from the Applications context file to generate 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 and update database profiles.

Configuration Management Tools

Fusion Middleware Control: This tool provides a high-level view of Oracle WebLogic Server (WLS). More significantly for the Oracle E-Business Suite DBA, it is used to configure Oracle HTTP Server. HTTP settings include: virtual hosts, performance directives, log configuration, ports, mod_perl, and mod_wl_ohs. Fusion Middleware Control also includes links to Oracle Application Manager and Oracle WebLogic Server Admin Console.

WebLogic Server Administration Console: Handles Oracle WebLogic Server settings and managed servers. Examples include: oacore, oafm, forms, and forms-c4ws services.

Oracle Application Manager and AutoConfig: Handles Oracle Database settings. Examples include: SID name, Listener, dbPorts.) Also handles some Oracle E-Business Suite settings. Examples include: Concurrent Processing, Profile Options, Developer 10g settings, product-specific settings.

Configuration Management Changes

In Oracle E-Business Suite Release 12.2, OC4J has been replaced with Oracle WebLogic Server. This has resulted in a reduced role for AutoConfig in the configuration of the Oracle HTTP Server and the oacore, oafm, forms and forms-c4ws services.

Up to and including Oracle E-Business Suite Release 12.1.3, AutoConfig was used to manage the entire Oracle HTTP Server configuration and OC4J instance configuration. In Oracle E-Business Suite Release 12.2, it manages only a part of the Oracle HTTP Server configuration. It also only partially manages the configuration of the oacore, oafm, forms and forms-c4ws services. The remaining scope of AutoConfig remains the same as prior to Oracle E-Business Suite Release 12.2.

This chapter details those aspects of configuration management that are still undertaken by AutoConfig. It goes on to describe the role of Oracle WebLogic Server in Oracle E-Business Suite Release 12.2, and also mentions some important WLS administrative and troubleshooting tasks.

Key configuration changes and features in Release 12.2 include:

Fusion Middleware Control provides a high-level view of Oracle WebLogic Server, and is the only place where you can configure your HTTP Server. Examples of HTTP settings are: virtual hosts, performance directives, log configuration, ports, mod_perl, and mod_wl_ohs. Fusion Middleware Control also has links to Oracle Application Manager and WLS Admin Console.
WebLogic Server Administration Console handles Oracle WebLogic Server settings and managed servers. Examples include oacore, oafm, forms, and forms-c4ws services.
EBS Installation Central Inventory option (from the AD-TXK Delta 7 codelevel), to provide support on the application tier of UNIX platforms for an inventory that is specific to a particular Oracle E-Business Suite instance. This feature is useful where there are multiple Oracle E-Business Suite installations on the same host. In particular, it allows safe simultaneous running of fs_clone on the different instances.

Note: For a full description of the EBS Central Inventory option, refer to the 'Check Inventory Setup' subsection in the 'Before You Start' section of Chapter 3, Patching Procedures, in Oracle E-Business Suite Maintenance Guide.

In a wider context , the changes are as described in the following table:

Summary of Configuration Management Changes in Release 12.2
Configuration Activity	Prior to Release 12.2	In Release 12.2
Oracle E-Business Suite Database, Concurrent Processing, Oracle Developer 10g, profile options, and other Oracle E-Business Suite components.	Oracle Applications Manager.	Oracle Applications Manager.
Changes to HTTP Configuration.	All HTTP configuration was managed via AutoConfig templates. Configuration changes were done by editing the respective context variables and subsequently running AutoConfig.	Most HTTP configuration is managed via native Oracle WebLogic Server tools, Fusion Middleware Control, or manually editing of the configuration files. Only a limited set of HTTP configuration files are maintained via AutoConfig. More details are given later in this chapter.
Changes to configuration of oacore, oafm, forms and forms-c4ws services.	All configuration settings for the oacore, oafm, forms and forms-c4ws services were managed via AutoConfig templates. Configuration changes were accomplished by editing context variables and running AutoConfig.	Properties for the oacore, oafm, forms and forms-c4ws services, including the classpath and JVM arguments, need to be updated through native WebLogic tools such as WebLogic Administration Console. The context variable values are used only to set the initial values during managed server creation. More details are given later in this chapter.
Managing JVM instances of the oacore, oafm, forms and forms-c4ws services.	The number of instances of a service was controlled via Oracle Process Manager (OPMN). This number could be modified by editing the nprocs context variable, running AutoConfig, then stopping and restarting the services.	Each JVM instance of a service corresponds to a managed server of that service type. The number of instances needs to be controlled by explicitly creating or deleting managed servers for the service. More details are given later in this chapter.

Oracle WebLogic Server Requirements and Usage

Oracle E-Business Suite Release 12.2 requires WebLogic Server Basic. This is a license-constrained version of WebLogic Server that is available in licenses for certain Oracle products.

WebLogic Server Basic is used in Oracle E-Business Suite Release 12.2 to support the following features:

WLS Clusters. Specifically, one WLS cluster per EBS domain.
Hardware-based load-balancers in front of a WLS cluster in an EBS domain.
Use of the WLS proxy on an OHS server, directing load to one or more WLS instances on one or more managed servers in a WLS Cluster. The cluster is defined by AutoConfig via the configuration file deployed on the OHS server.
Session re-instantiation from one managed server to another managed server within the same cluster. Although transactions in progress during failure of one managed server will be lost, the user's session will be re-established and migrated to another managed server in the cluster.

Rapid Install deploys one WebLogic domain for Oracle E-Business Suite, with four different application types being provisioned out of the box:

oacore - Used to provide core functionality in Oracle E-Business Suite application tier Java code, including OAF-based functionality for Oracle E-Business Suite products.
oafm - Used for web services, Secure Enterprise Search, Oracle Transport Agent, and other components.
forms - Serves all Oracle Forms functionality.
forms-c4ws - Exposes Oracle Forms-based functionality as web services.

An additional application type, which is not deployed out-of-the-box, may be provisioned if additional Oracle applications are installed:

oaea: Used when installing additional Oracle applications such as Oracle E-Business Suite AccessGate, eKanban, and Spatial.

Oracle E-Business Suite creates one cluster for each application type deployed in the EBS WLS domain:

oacore_cluster1
oafm_cluster1
forms_cluster1
forms-c4ws_cluster1
oaea_cluster1

Managed server names for these clusters are grouped as follows:

oacore_server1 for Node1, oacore_server2 for Node 2, etc.
oafm_server1 for Node 1, oafm_server2 for Node 2, etc.
forms_server1 for Node 1, forms_server2 for Node 2, etc.
forms-c4ws_server1 for Node 1, forms-c4ws_server2 for Node 2, etc.
oaea_server1 for Node 1, oaea_server2 for Node 2, etc.

Important: WLS clusters in EBS WLS domains must be created and managed with the Oracle E-Business Suite cluster provisioning tools. Do not use the native WLS administration tools.

AutoConfig Scope and Components

The Release 12.2 application tier is AutoConfig-enabled, and has an Applications context file stored in the INST_TOP as <INST_TOP>/appl/admin/<CONTEXT_NAME>.xml. The Release 12.2 database tier created via Rapid Install is also AutoConfig-enabled, and has a database context file stored in the RDBMS ORACLE_HOME as <RDBMS_ORACLE_HOME>/appsutil/<CONTEXT_NAME>.xml.

Key AutoConfig components include those listed in the following table:

Key AutoConfig Components
Component	Description
Applications context	An XML repository located in the INST_TOP that contains information specific to the APPL_TOP.
Database context	An XML repository located in the RDBMS ORACLE_HOME that contains information specific to that database tier.
AutoConfig template files	Files containing named tags that are replaced with instance-specific information from the appropriate context, in the process of instantiation.
AutoConfig driver files	Every Oracle E-Business Suite product maintains a driver file used by AutoConfig. The driver file lists the AutoConfig file templates and their destination locations.
AutoConfig scripts	A set of scripts that provide a simplified interface to the AutoConfig APIs.

Cloning

You can create a copy of an Oracle E-Business Suite Release 12.2 system using Rapid Clone. For details, see the following My Oracle Support Knowledge Documents:

Document 1383621.1, Cloning Oracle E-Business Suite Release 12.2 with Rapid Clone
Document 1614793.1, Cloning Single Sign-on Enabled Oracle E-Business Suite Release 12.2 Environments
Document 1679270.1, Cloning Oracle E-Business Suite Release 12.2 RAC Enabled Systems with Rapid Clone

Using AutoConfig to Manage Oracle E-Business Suite Services

This section describes how AutoConfig manages Oracle E-Business Suite services and processes. It also describes how port pools are used.

In previous Oracle E-Business Suite releases, the Applications services were categorized into service groups according to the type of service provided. In Oracle E-Business Suite Release 12.2, this concept has been extended by the introduction of additional services and service groups.

Most notably, the Web Administration service group has been introduced in Release 12.2. This service group contains WebLogic Administration server, and - unlike other service groups - can be enabled only on one of the Application tier nodes. In other words, it is not supported to enable WebLogic Administration server on any other Application tier node except the node on which it was enabled during Rapid Install.

Also, unlike previous releases of Oracle E-Business Suite Release 12.x, the Root Service Group now comprises Node Manager and not Oracle Process Manager (OPMN). In Oracle E-Business Suite Release 12.2, OPMN only manages Oracle HTTP Server. Consequently, it is now part of the Web Entry Point Services service group.

The following table shows the AutoConfig-managed service groups and services that exist in Release 12.2.

Note: Only the UNIX versions of the service control scripts are shown: the Windows equivalents have a .cmd suffix instead of .sh.

AutoConfig-Managed Service Groups and Services
Service Group	Service(s)	Service Control Script
Root Service	Node Manager	`adnodemgrctl.sh`
Web Administration	WebLogic Admin Server	`adadminsrvctl.sh`
Web Entry Point Services	Oracle HTTP Server Oracle Process Manager	`adapcctl.sh` `adopmnctl.sh`
Web Application Services	oacore oafm forms forms-c4ws	`admanagedsrvctl.sh` `admanagedsrvctl.sh` `admanagedsrvctl.sh` `admanagedsrvctl.sh`
Batch Processing Services	Oracle TNS Listener Concurrent Manager Fulfillment Server Oracle ICSM	`adalnctl.sh` `adcmctl.sh` `jtffmctl.sh` `ieoicsm.sh`
Other Services	Forms Server Oracle MWA Service	`adformsrvctl.sh` `mwactlwrpr.sh`

Note: A particular service will be started or stopped via the adstrtal or adstpall scripts only if the service and its service group are both enabled.

Modifying AutoConfig-Managed Services and Service Groups

Depending on the requirement of a particular Applications instance, it is possible to modify the set of Applications services and service groups that will be started and stopped via the adstrtal and adstpall scripts respectively. This can be done by enabling the required services and service groups, and disabling those that are not required.

Checking whether a service group/service is enabled or disabled

There are two options here:
- A complete list of the status of all service groups and services is available in Section 2 of the report generated by the Check Config utility (adchkcfg).
- The log files generated by the adstrtal and adstpall scripts list the Application service groups and the services that are managed via AutoConfig. This list also reports whether a particular service group or service is enabled or disabled.
Enabling or disabling a service group

In Oracle E-Business Suite Release 12.2, all services except the Web Administration Service Group can be enabled or disabled on any or all Application tier nodes. This is done as follows:
1. Check the value of the 'status' context variable corresponding to the service group.
2. Change the value of this variable to 'enabled' to enable the service group, or to 'disabled' to disable the service group.
Enabling a service

A service can be enabled as follows:
1. Check the value of the 'status' context variable corresponding to the service group to which the service belongs.
2. If the service group is 'disabled', enable the service group.
3. If the value of the 'status' context variable corresponding to the service is not already set to 'enabled', change it to 'enabled'.
4. In case of the oacore, oafm, forms and forms-c4ws services, there may be more than one instance of the service. To cater for this, check that the context variable corresponding to the name of the service contains the name of the managed server to be enabled. If not, add it to the list, using a comma as a separator.
  
  For example, if there are two oacore managed servers (oacore_server1 and oacore_server2) defined on the same Application tier node, and oacore_server2 needs to be enabled, then the value of the context variable s_oacorename needs to be changed from 'oacore_server1' to 'oacore_server1,oacore_server2'. Also, if the context variable 's_oacore_managed_server' does not contain an entry for 'oacore_server2', the value of this context variable also needs to be changed to 'oacore_server1,oacore_server2'.
Disabling a Service

A service can disabled as follows:
1. In most cases, you simply need to set the service's 'status' context variable to 'disabled'.
2. Services of type oacore, oafm, forms or forms-c4ws require an additional step. Where such a service's 'status' context variable is set to 'enabled' and there is more than one instance of the service, you must remove the name of the managed server to be disabled from the context variable corresponding to the name of the service.
  
  For example, if there are two oacore managed servers (oacore_server1 and oacore_server2) defined on the same Application tier node, and oacore_server2 needs to be disabled, then the value of the context variable s_oacorename must be changed from 'oacore_server1, oacore_server2' to 'oacore_server1'.

Commands to Manage Oracle E-Business Suite Service Processes

Commands for managing processes on the Applications tier

The adstrtal and adstpall scripts can be used to start and stop all the AutoConfig-managed application tier services in a single operation. Alternatively, it is possible to administer the individual services separately using their respective service control scripts. The oacore, oafm, forms and forms-c4ws services can also be managed by starting and stopping the respective managed servers via the WebLogic Server Administration Console.

All the scripts listed in the table below are located in <INST_TOP>/admin/scripts.

Commands for Managing Processes on the Applications Tier
Functionality	UNIX Command	Windows Command
Start Applications services	`adstrtal.sh`	`adstrtal.cmd`
Stop Applications services	`adstpall.sh`	`adstpall.cmd`
Start individual service (except those that are part of the Web Application Services service group)	`<control_script> start`	`<control_script> start`
Stop individual service (except those that are part of the Web Application Services service group)	`<control_script> stop`	`<control_script> stop`
Start individual managed server (all services that are part of the Web Application Services service group)	`admanagedsrvctl.sh start <managed_server_name>`	`admanagedsrvctl.cmd start <managed_server_name>`
Stop individual managed server (all services that are part of the Web Application Services service group) The 'stop' command will shut down the managed server only after no user sessions remain connected, while the 'abort' command will shut down the managed server immediately.	`admanagedsrvctl stop <managed_server_name>` `admanagedsrvctl abort <managed_server_name>`	`admanagedsrvctl.cmd stop <managed_server_name>` `admanagedsrvctl.cmd abort <managed_server_name>`

Commands for managing processes on the Database tier

All the scripts listed in the table below are located in <RDBMS ORACLE_HOME>/appsutil/scripts/<CONTEXT_NAME>.

Commands for Managing Processes on the Database Tier
Functionality	UNIX Command	Windows Command
Start database listener process	`addlnctl.sh start <SID>`	`addlnctl.cmd start <SID>`
Stop database listener process	`addlnctl.sh stop <SID>`	`addlnctl.cmd stop <SID>`
Start database server process	`addbctl.sh start`	`addbctl.cmd start`
Stop database server process	`addbctl.sh stop`	`addbctl.cmd stop`

Port Pools

If you look at the context file for an existing Oracle E-Business Suite Release 12.2 system,, you will see each WebLogic server has a base port number. For example, the oacore server has a base port of 7201. During installation of Oracle E-Business Suite, you can if desired specify a port pool. If you specify port pool = 40 during installation, the resulting port number used for the oacore server will be 7201 + 40 = 7241.

So for this example, in the context file you will see:

<PORT_POOL oa_var="s_port_pool">40</PORT_POOL>
<wls_oacoreport oa_var="s_wls_oacoreport" oa_type="PORT" base="7201" step="1" range="-1" label="WLS OACORE Application Port">7241</wls_oacoreport>

The run and patch file systems for a Release 12.2 system must each use a different port pool. And if you install two separate Oracle E-Business Suite Release 2.2 environments on the same server, they also must use different port pools.

As the same web ports are used for both fs1 and fs2, the entry points for users will also be the same. However, different ports are used for WLS administration activities on the patch file system while the run file system is in use. You may find it useful to make a note of the WLS Admin ports.

Note: If you change the port numbers used by a running WLS managed server, you should then restart the server to ensure that the new values are picked up.

Using AutoConfig Tools for System Configuration

The following table summarizes the AutoConfig tools. Further details of each tool are provided later in this chapter.

Note: On Windows, command files (.cmd suffix) are the equivalent of UNIX scripts (.sh suffix).

AutoConfig Tools
Script Name	Location	Purpose
`adautocfg.sh/cmd`	On Applications Tier: `<INST_TOP>/admin/scripts` On Database Tier: `<RDBMS_ORACLE_HOME>/appsutil/scripts/<CONTEXT_NAME>`	This script is used for running AutoConfig.
`adchkcfg.sh/cmd`	On Applications Tier: `<AD_TOP>/bin` On Database Tier: `<RDBMS_ORACLE_HOME>/appsutil/bin`	This script may be run before running AutoConfig to review the changes on running AutoConfig. This will generate a report showing the differences between the existing configuration and what the configuration would be after running AutoConfig.
`GenCtxInfRep.pl`	On Applications Tier: `<FND_TOP>/patch/115/bin` On Database Tier: `<RDBMS_ORACLE_HOME>/appsutil/bin`	This script can be used to find out detailed information about context variables and the templates in which they are used, given all or part of a context variable name as a keyword.
`adtmplreport.sh/cmd`	On Applications Tier: `<AD_TOP>/bin` On Database Tier: `<RDBMS_ORACLE_HOME>/appsutil/bin`	This script can be used to gather information regarding the location of the AutoConfig templates, provided the location of the instantiated files and vice versa.
`admkappsutil.pl`	On Applications Tier: `<AD_TOP>/bin`	This script is used while applying patches to the database tier. Running this script generates `appsutil.zip`, which may be copied over to the database tier to migrate the patch to the database tier.

As well as the above tools, there are start and stop tools that are used to manage the run-time processes of Oracle E-Business Suite services. These tools are described later in this chapter.

As mentioned earlier, AutoConfig is used to automate system configuration. This section describes how the AutoConfig tools can be used for this purpose. Actions performed by these tools will typically be performed in the order shown in the following subsections.

Preview Effects of Running AutoConfig

Before running AutoConfig, the Check Config utility may be run to review the changes that would occur in the file system as well as the database in the next AutoConfig run. This step is optional.

Execute the applicable command to run the Check Config utility:

Database Tier

On UNIX:

sh <RDBMS_ORACLE_HOME>/appsutil/bin/adchkcfg.sh \
contextfile=<CONTEXT_FILE>

On Windows:

C:\><RDBMS_ORACLE_HOME>\appsutil\bin\adchkcfg.cmd contextfile=<CONTEXT_FILE>

Application Tier

On UNIX:

$ sh <AD_TOP>/bin/adchkcfg.sh \
contextfile=<CONTEXT_FILE>

On Windows:

C:\><AD_TOP>\bin\adchkcfg.cmd contextfile=<CONTEXT_FILE>

This utility is described in more detail later.

Run AutoConfig on the Database Tier

Running AutoConfig on the database tier is required after:

Migrating a patch to the database tier, the Check Config utility reports any potential changes to the templates.
Performing customizations on the database tier.
Performing a database or application tier upgrade.
Restoring the database or Oracle Home from a backup.
Upgrading JDK on the database tier.
Manually cleaning up the Net Services Topology Information using one of the supported procedures. Subsequently, AutoConfig must be run on the application tier nodes as well.
Registration of an Oracle RAC node.
Setting up the APPL_TOP on a shared file system.
Carrying out any other operation where the documentation states that AutoConfig should be run on the database tier.

Execute the following command to run AutoConfig on the database tier:

On UNIX:

$ sh <RDBMS_ORACLE_HOME>/appsutil/scripts/<CONTEXT_NAME>/adautocfg.sh

On Windows:

C:\><RDBMS_ORACLE_HOME>\appsutil\scripts\<CONTEXT_NAME>\adautocfg.cmd

Be aware of the following important points:

The database server and database listener must remain running during an AutoConfig run, but all other database tier services should be shut down.
AutoConfig may change your environment files, so after running it you should always set the environment (and thereby pick up any changed variables) before you run any Oracle E-Business Suite utilities.

Stop Application Tier Services

Before running AutoConfig on the Application tier, all application tier services must be stopped. This can be done using the following command:

On UNIX:

$ sh <ADMIN_SCRIPTS_HOME>/adstpall.sh

On Windows:

C:\><ADMIN_SCRIPTS_HOME>\adstpall.cmd

Run AutoConfig on the Application Tier

Run AutoConfig on all application tier nodes by executing the applicable command below.

On UNIX:

$ sh <INST_TOP>/admin/scripts/adautocfg.sh

On Windows:

C:\><INST_TOP>\admin\scripts\adautocfg.cmd

Be aware of the following important points:

The database server and database listener must remain available during the AutoConfig run, but all other database tier services should be shut down.
Running AutoConfig may change your existing environment files.
After running AutoConfig, you should always set the environment before you run any Oracle E-Business Suite utilities, to pick up any changed environment variables.

Review AutoConfig Log Files

AutoConfig logfiles are stored in directories as described in the following table:

AutoConfig Log File Locations
Tier	Directory
Application	<INST_TOP>/admin/log/<MMDDhhmm>
Database	<RDBMS_ORACLE_HOME>/appsutil/log/<CONTEXT_NAME>/<MMDDhhmm>

One log file is created per AutoConfig session. It will contain details of every action that AutoConfig performed during the run.

Start All Application Tier Services

After running AutoConfig, start up all the application tier services by executing the applicable command below:

On UNIX:

$ sh <ADMIN_SCRIPTS_HOME>/adstrtal.sh

On Windows:

C:\><ADMIN_SCRIPTS_HOME>\adstrtal.cmd

Rolling Back an AutoConfig Session

Each AutoConfig run creates a rollback script you can use to revert to the previous configuration settings if necessary. The script and backup configuration files from each AutoConfig session are stored in the following locations:

Locations for Script and Backup Configuration Files for an AutoConfig Session
Tier	Directory
Application	<INST_TOP>/admin/out/<MMDDhhmm>
Database	<RDBMS_ORACLE_HOME>/appsutil/out/<CONTEXT_NAME><MMDDhhmm>

where: <MMDDhhmm> = <month, day, hour, minute> of AutoConfig run.

Note: Rollback only needs to be performed in the event of a problem with an AutoConfig session.

To roll back an AutoConfig session, execute the following commands:

On UNIX:

$ restore.sh

On Windows:

C:\>restore.cmd

Tools for Configuration Synchronization

In Oracle E-Business Suite Release 12.2, only some Oracle HTTP Server and WebLogic Server configuration is managed using AutoConfig. The larger part is managed natively, using Fusion Middleware Control or WebLogic Server Administration Console. A new mechanism has been introduced to keep the context variables and the OHS configuration parameters (where applicable) in synchronization. This mechanism is called the 'feedback loop'.

For details about the tools performing this synchronization, adRegisterWLSListeners.pl and adSyncContext.pl, see My Oracle Support Knowledge Document 1905593.1, Managing Configuration of Oracle HTTP Server and Web Application Services in Oracle E-Business Suite Release 12.2.

Customizing AutoConfig-Managed Configurations

AutoConfig simplifies and standardizes configuration management tasks in an Oracle E-Business Suite environment. At the start of each AutoConfig-managed file, you will see the following header:

################################################################ 
# Do not edit settings in this file manually. They are managed
# automatically and will be overwritten when AutoConfig runs.
# For more information about AutoConfig, refer to
# Oracle E-Business Suite Setup Guide.
################################################################

The configuration generated by AutoConfig may not always meet your specific requirements, however, and it may be necessary to customize AutoConfig for your environment.

Examples where you might want to customize AutoConfig include:

Start additional services or processes when you start Oracle E-Business Suite services
Extend Oracle Forms to integrate with a third party Java version
Develop custom applications that are to be maintained by AutoConfig

Implementing AutoConfig Customizations

This section addresses the different types of AutoConfig customizations and how to implement them. After identifying your customization needs, perform the steps associated with them.

Oracle supports the following types of customization:

Changing the value of an existing context variable
Adding a new context variable to the context file
Customizing an AutoConfig template file delivered by Oracle
Creating a customer-owned AutoConfig template file

Each of these will be considered in turn.

Changing the Value of an Existing Context Variable
1. Edit the context variable value
  
  Use the Oracle Applications Manager Context Editor to change values of existing context variables. Refer to the Help pages available on Oracle Applications Manager: the relevant information is located in the System Configuration > AutoConfig > Manage Custom Parameters section.
2. Run AutoConfig
  
  Depending on whether the context variable belongs to the application tier or the database tier, run AutoConfig on the appropriate tier, following the steps mentioned earlier in this chapter.
Adding a New Context Variable to the Context File
1. Add the context variable
  
  Use the Oracle Applications Manager Context Editor if you want to add a context variable that is not maintained by AutoConfig. Refer to the Help pages available on Oracle Applications Manager: the relevant information is located in the System Configuration > AutoConfig > Manage Custom Parameters section.
2. Run AutoConfig
  
  Depending on whether the context variable belongs to the application tier or the database tier, run AutoConfig on the appropriate tier, following the steps mentioned earlier in this chapter.

Customizing an AutoConfig Template File Delivered by Oracle

If you want to customize an existing AutoConfig template file, perform the following steps in the order listed:

Determine the AutoConfig template file you want to customize

Execute the appropriate command as listed in one of the tables below to identify the AutoConfig template file that corresponds to the configuration file you want to customize:

Command for UNIX
Tier	Command
Application	<AD_TOP>/bin/adtmplreport.sh \ contextfile=<CONTEXT_FILE> target=<configurationfile>
Database	<RDBMS ORACLE_HOME>/appsutil/bin/adtmplreport.sh \ contextfile=<CONTEXT_FILE> target=<configurationfile>

Command for Windows
Tier	Command
Application	<AD_TOP>\bin\adtmplreport.cmd \ contextfile=<CONTEXT_FILE> target=<configurationfile>
Database	<RDBMS ORACLE_HOME>\appsutil\bin\adtmplreport.cmd \ contextfile=<CONTEXT_FILE> target=<configurationfile>

For example, if you want to customize:

$INST_TOP/admin/install/afwebprf.sh

On UNIX:

$ $AD_TOP/bin/adtmplreport.sh contextfile=$CONTEXT_FILE \ 
target=$INST_TOP/admin/install/afwebprf.sql

On Windows:

C:\>%AD_TOP%\bin\adtmplreport.cmd contextfile=%CONTEXT_FILE% target=%INST_TOP%\admin\install\afwebprf.sql

The adtmplreport utility returns the name and location of the AutoConfig template file. For the above UNIX example, it would return:

$INST_TOP/admin/install/afwebprf.sql

Be aware that you cannot customize all AutoConfig template files. A file cannot be customized if the keyword "LOCK" appears in the template file's entry in the product driver file. AutoConfig ignores custom template files that are marked with "LOCK". For example, the following entry in <AD_TOP>/admin/driver/adtmpl.drv will prevent customization of the file adconfig.txt:

ad admin/template adconfig.txt INSTE8 <s_at>/admin adconfig.txt 600 LOCK

Important: The customizations must be implemented on both the run edition file system and the patch edition file system. Therefore, once the above steps have been completed on the run edition file system, execute Steps 1 to 4 on the patch edition file system to migrate the customizations.

Create the Custom Template Directory

Create a directory named custom at the location where the AutoConfig template file resides.

For example, if you want to customize <FND_TOP>/admin/template/afwebprf.sql, run the following command as the applmgr user:

On UNIX:
```
$ mkdir $FND_TOP/admin/template/custom
```
On Windows:
```
C:\>mkdir %FND_TOP%\admin\template\custom
```

Copy the AutoConfig template File

Copy the AutoConfig template file to the custom template file. Run the following command as the applmgr user:

On UNIX:

$ cp -i <AutoConfig template file> <Custom template file>

For example:

$ cp -i $FND_TOP/admin/template/afwebprf.sql \
$FND_TOP/admin/template/custom/afwebprf.sql

On Windows:

C:\>copy <AutoConfig template file> <Custom template file>

For example:

C:\> copy %FND_TOP%\admin\template\afwebprf.sql %FND_TOP%\admin\template\custom\afwebprf.sql

Edit the Custom Template File

Edit the custom template file with the text editor of your choice, such as vi on UNIX or Wordpad on Windows (do not use Word or any other editor that introduces non-printing characters).

Warning: Editing AutoConfig template files is not supported. Be sure to edit only custom template files.
Verify Your Customizations

Execute the adchkcfg utility as described earlier. When this utility runs, it instantiates any custom template files in place of the corresponding AutoConfig template file. The utility generates a report with information about all files and profile options that will be changed during the next normal run of AutoConfig. Verify that your customizations will be applied as expected in your next AutoConfig run.

The adchkcfg.sh (on UNIX) and adchkcfg.cmd (on Windows) scripts instantiate the templates into the location listed in the table below:
Location for Templates
Tier Directory
Application
<INST_TOP>/admin/log/<MMDDhhmm>
Database
<RDBMS_ORACLE_HOME>/appsutil/log/<CONTEXT_NAME>/<MMDDhhmm>
Run AutoConfig

Run AutoConfig as described earlier. When AutoConfig runs, it instantiates any custom template files in place of the corresponding AutoConfig template files.

Creating a Customer-Owned AutoConfig Template File

Creating your own AutoConfig template file will enable you to develop custom applications that AutoConfig can configure and maintain. Perform the following steps in the order listed.

Define a product_top

Running AD Splice will add an entry to the context file ($CONTEXT_FILE) for either new products or for existing products where the entry was previously missing.

For example, the product top definition for the product 'my' might look like the following:
```
OA_VAR = c_mytop
 Default Value = %s_at%/my/12.0.0
 Title = My Product top
 Description = This is my product top
 OA_TYPE = PROD_TOP
```
AutoConfig later replaces the string "%s_at%" with the corresponding APPL_TOP directory structure for both run and patch edition file systems. That is, the context files for both the run and patch file systems will be updated to accommodate the new product_top.

Note: For more information, refer to My Oracle Support Document 1577707.1, Creating a Custom Application in Oracle E-Business Suite Release 12.2.
Create the customer-owned AutoConfig template directory

Create the directory where your AutoConfig template files will reside. Run the applicable command as the applmgr user:

On UNIX, create a directory using a command such as:
```
$ mkdir <c_mytop>/admin/template
```
On Windows, create a directory using a command such as:
```
C:\>mkdir <c_mytop>\admin\template
```
Develop the customer-owned AutoConfig template file

Create the custom AutoConfig template file in the custom product top AutoConfig template directory. There are no file name restrictions, and the new template file can be of any type that can store text, such as text file, shell script, Perl script, or SQL script. To use AutoConfig instantiation, enter your context variables in the file. When AutoConfig runs, it replaces the context variables with the associated values from the context file.

On UNIX, create a file such as:
```
<c_mytop>/admin/template/myTemplate.txt
```
On Windows, create a file such as:
```
<c_mytop>\admin\template\myTemplate.txt
```
Confirm that AD Splice has created the custom product directories

AD Splice will create the following $CUSTOM_TOP directories for you:
```
admin
admin/sql
admin/driver
log
sql
out
mesg
```

Develop a customer-owned AutoConfig driver file

Every file you want AutoConfig to instantiate needs an entry in an AutoConfig driver file, which instructs AutoConfig where to place a generated configuration file.

The driver file must be placed in the custom AutoConfig driver directory. The name for the driver file is defined as <product>tmpl.drv. Driver file entries consist of <TAB> or <SPACE> separated fields.

The following table lists the fields and their contents.

AutoConfig Driver File Format
Field Name	Description
Product Name	Specifies the short name for the product
AutoConfig template directory	Directory underneath the product top that hosts the AutoConfig template file
AutoConfig template file	Name of the template file to be processed by AutoConfig
Action	Action that AutoConfig performs on the AutoConfig template file. Possible values are: INSTE8: AutoConfig instantiates the template each time it is run. INSTE8_SETUP: In addition to instantiating, execute the resulting configuration file during the SETUP Phase of each run of AutoConfig. INSTE8_PRF: In addition to instantiating, execute the resulting configuration file during the PROFILE Phase of each run of AutoConfig. INSTE8_APPLY: In addition to instantiating, execute the resulting configuration file during the APPLY Phase of each run of AutoConfig. INSTALL: AutoConfig instantiates the template file only if the resulting configuration file does not already exist. INSTALL_SETUP: In addition to instantiating, AutoConfig executes the resulting configuration file during the SETUP phase if the configuration file does not already exist. INSTALL_PRF: In addition to instantiating, AutoConfig executes the resulting configuration file during the PROFILE phase if the configuration file does not already exist. INSTALL_APPLY: In addition to instantiating, AutoConfig executes the resulting configuration file during the APPLY phase if the configuration file does not already exist.
Configuration directory	AutoConfig places the instantiated configuration file in this directory.
Configuration file	Name of the instantiated configuration file.
Configuration file permission (UNIX only)	AutoConfig generates the configuration file with the provided UNIX-style permissions.

For example, a driver file entry might contain the following (on one line):

my admin/template myTemplate.txt INSTE8 <s_pt> myConfiguration.txt 660

In this example, AutoConfig would instantiate the template file <MY_TOP>/admin/template/myTemplate.txt and generate the configuration file myConfiguration.txt into the Portal directory (the Portal directory is instantiated from <s_pt>) with permissions of 660 (read and write for user and group).

To have AutoConfig instantiate the above example template file, the driver file would need to contain the line:

my admin/template myTemplate.txt INSTE8 <s_pt> myConfiguration.txt 660

Note: This should be entered on a single line.

In this example, the driver file would be named mytmpl.drv.

Important: If you are adding customizations to an existing custom product top, you must copy the updated custom files from the run edition file system to the patch edition file system.

Advanced Features of AutoConfig Customizations

This section discusses advanced features available when using AutoConfig Customizations.

Debugging customizations

If problems arise with customizations that you implemented, it may be useful to run AutoConfig with the AutoConfig template files, ignoring any custom template files. Run the following command:

On UNIX:
```
$ <AD_TOP>/bin/adconfig.sh -nocustom contextfile=<CONTEXT_FILE>
```
On Windows:
```
C:\><AD_TOP>\bin\adconfig.cmd -nocustom contextfile=<CONTEXT_FILE>
```
Preserving customizations after updates

You must review your customizations whenever a TXK patch delivers a new version of an AutoConfig template file for which you edited the corresponding custom template file. If the customizations are still required, copy the new version of the AutoConfig template file to the custom template directory, and edit the custom template file with your customizations.

Important: AutoConfig checks that your custom template files are of the same versions as the AutoConfig template files, and will not run if it detects any version mismatch.

Using Reports

The report produced by the adtmplreport utility can:

List all customized files in an Oracle E-Business Suite instance.
List all AutoConfig template files, their custom template files and their configuration files.
Identify the name and location of the AutoConfig template file and the custom template file for a given configuration file.
Identify the name and location of the configuration file for a given AutoConfig template file.

The report utility is located as described in the table below:

Report Utility Locations
Platform	Command
UNIX	<AD_TOP>/bin
Windows	<RDBMS ORACLE_HOME>/appsutil/bin

To list all files that you customized in an Oracle E-Business Suite instance, use the appropriate command listed in the table below:

Commands to List Customized Files
Platform	Command
UNIX	adtmplreport.sh contextfile=<CONTEXT_FILE> listcustom
Windows	adtmplreport.cmd contextfile=<CONTEXT_FILE> listcustom

To list all configuration files, their AutoConfig template files and their custom template files, use the appropriate command listed in the table below:

Commands to List Configuration Files, AutoConfig Template Files, and Custom Template Files
Platform	Command
UNIX	adtmplreport.sh contextfile=<CONTEXT_FILE>
Windows	adtmplreport.cmd contextfile=<CONTEXT_FILE>

To identify the configuration file for a given AutoConfig template file, use the appropriate command listed in the table below:

Commands to Identify Configuration Files
Platform	Command
UNIX	adtmplreport.sh contextfile=<CONTEXT_FILE> \ template=<templatefilepath>
Windows	adtmplreport.cmd contextfile=<CONTEXT_FILE> \ template=<templatefilepath>

To identify the AutoConfig template and custom template file for a given configuration file, use the appropriate command listed in the table below:

Commands to Identify the AutoConfig Template and Custom Template File for a Configuration File
Platform	Command
UNIX	adtmplreport.sh contextfile=<CONTEXT_FILE> target=<configurationfile>
Windows	adtmplreport.cmd contextfile=<CONTEXT_FILE> target=<configurationfile>

AutoConfig Customization Limitations and Restrictions

This section discusses the limitations and restrictions that exist when using AutoConfig customizations.

Limitations with customizing tnsnames.ora, listener.ora and sqlnet.ora

When running AutoConfig on the application tier, it generates tnsnames.ora, listener.ora and sqlnet.ora files based on the information present in the FND_NET_SERVICES table. If you need to add custom parameters, you must use the IFILE feature of these configuration files. For example, if there is a need to add TRACE_DIRECTORY to tnsnames.ora, you must add this to the file pointed to by the IFILE parameter rather than adding it directly to the tnsnames.ora file.

Note: It is not supported to customize admk80ln_ux.sql or any other file involved in the generation of these files.

Patching AutoConfig

In Release Oracle E-Business Suite Release 12.2, AutoConfig must be enabled on both the application tier and the database tier if it is to be patched.

Applying the Latest AutoConfig Updates

To obtain the latest AutoConfig updates on both the applications tier and the database tier, perform the following steps in the order listed.

Copy AutoConfig to the RDBMS ORACLE_HOME

Update the RDBMS ORACLE_HOME file system with the new AutoConfig files by performing the following steps:
1. On the application tier (as the APPLMGR user).
  1. Run EBSapps.env.
    
    For example:
```
EBSapps.env RUN
```
  2. Create the appsutil.zip file by running the following command:
```
$ perl <AD_TOP>/bin/admkappsutil.pl
```
    This will create appsutil.zip in <INST_TOP>/admin/out.
2. On the database tier (as the ORACLE user):
  1. Copy or FTP the appsutil.zip file to the RDBMS ORACLE_HOME, then run the following commands:
```
$ cd <RDBMS ORACLE_HOME>
$ unzip -o appsutil.zip
```
Run AutoConfig

Run AutoConfig on the database tier, and then on the applications tier.

Important: This step must be SKIPPED if you have installed a NEW Oracle home (for example, upgraded the database from 11g to 12c), and have been referred here from Step 1 of "Enabling AutoConfig on a New Oracle Home," because at this stage there is no Database Context File to pass to adconfig.sh as that is created in a later step (that is, Step 3 of "Enabling AutoConfig on a New Oracle Home").

Enabling AutoConfig on a New Oracle Home

In Release 12.2, AutoConfig is enabled by default on the application tier. However, it might not be enabled on the database tier in the following scenarios:

The database tier was not created by Rapid Install.
Cross-platform migration has been performed on the database tier.
The database has been upgraded to Oracle Database 11g.
The database tier has been upgraded as part of an Oracle E-Business Suite upgrade from Release 11i to 12.2.

To enable AutoConfig on the database tier, perform the following steps in the order listed:

Copy AutoConfig to the RDBMS ORACLE_HOME

Update the RDBMS ORACLE_HOME file system by following the steps in Applying the Latest AutoConfig Updates above.
Install Java Runtime Environment (JRE) on the Database tier

The JRE resides in the <ORACLE_HOME>/appsutil/jre directory on the database tier. Ensure that the JRE on the database tier is at a certified version of JRE 7.0 for your operating system as listed in Section 9: Upgrading to Latest JRE 7.0 on Database Tier Node, Using the Latest JDK 7.0 Update with Oracle E-Business Suite Release 12.2, My Oracle Support Knowledge Document 1530033.1.
Generate the Database Context File

Execute the following command to create your database context file:
```
$ perl <RDBMS_ORACLE_HOME>/appsutil/bin/adbldxml.pl
```
Important: If you run the adbldxml.pl utility for an instance that is part of an Oracle RAC environment, all the Oracle RAC instances must be running so that adbldxml.pl can connect to them and gather information about the configuration.

Run AutoConfig on the Database tier

Run AutoConfig on the database tier by executing one of the following commands:

On UNIX:

$ <RDBMS_ORACLE_HOME>/appsutil/bin/adconfig.sh \
contextfile=<context_file>

On Windows:

C:\><RDBMS_ORACLE_HOME>\appsutil\bin\adconfig.cmd contextfile=<context_file>

Advanced AutoConfig Features and Additional Utilities

This section gives an overview of some of the advanced AutoConfig features and utilities.

Running AutoConfig in Parallel Across Multiple Nodes

This feature enables AutoConfig to be executed simultaneously across multiple nodes of an Oracle E-Business Suite Release 12.2 instance. AutoConfig can be run in this parallel mode by executing the following command:

On the Application tier:

$ perl <AD_TOP>/bin/adconfig.pl contextfile=<CONTEXT_FILE> \
[product=<product_top>] -parallel

On the Database tier:

$ perl <ORACLE_HOME>/appsutil/bin/adconfig.pl \
contextfile=<CONTEXT_FILE> -parallel

Important: When running AutoConfig simultaneously on multiple nodes, the -parallel option must be specified when running AutoConfig on each node. If it is not, the execution of AutoConfig processes on individual nodes will not be synchronized, and possibly result in inconsistent filesystem or database.

Profiling An AutoConfig Run

The AutoConfig Performance Profiler feature can be used to profile an AutoConfig run and generate a consolidated report in HTML format. The report displays a summarized view listing all the product tops along with the total instantiation/execution time of the templates within them. The profile report comprises the following sections:

Summary

This section of the report shows the profile information for all product tops processed in the current AutoConfig run. It shows the following:
- Product Top: Short name of each product top.
- Instantiation Time: Total time taken to instantiate templates from each product top.
- Execution Time: Total time taken to execute scripts from each product top.
- Time (%): Percentage of AutoConfig execution time taken to instantiate and execute scripts from each product top.
- Status: Whether or not all the templates from each product top were successfully instantiated and executed.
The profile information for individual templates can be seen by drilling down into the product tops listed in the summary section.
Details

This section contains the profile information for all product templates instantiated and executed in the current AutoConfig run. It shows the following:
- Script Name: Target name of the template.
- Instantiation Time: Time taken to instantiate the template.
- Execution Time: Time taken to execute the instantiated template.
- Time (%): Percentage of product top processing time taken to process the template.
- Status: Whether or not the template was successfully processed.
- Execution Summary: Contains the source and target locations of the template and the execution report of the script. This summary can be viewed by clicking on the script name link in the detailed report.

AutoConfig can be run in profile mode by issuing the following commands:

On the Application Tier:

$ perl <AD_TOP>/bin/adconfig.pl contextfile=<CONTEXT_FILE> \
[product=<product_top>] -profile

On the Database Tier:

$ perl <ORACLE_HOME>/appsutil/bin/adconfig.pl \
contextfile=<CONTEXT_FILE> [product=<product_top>] -profile

Using the Check Config Utility

The Check Config utility (adchkcfg) is used to review the configuration changes that will take effect on an Oracle E-Business Suite instance during the next AutoConfig run. It identifies the potential changes to both the file system as well as the database. It can be run on both the application tier and the database tier.

The utility is located in the location listed in the table below:

Check Config Utility Location for the Application and Database Tiers
Tier	Location
Application	`<AD_TOP>/bin`
Database	`<ORACLE_HOME>/appsutil/bin`

The Check Config utility is run by executing the following command:

On UNIX:

$ adchkcfg.sh contextfile=<CONTEXT_FILE>

On Windows:

C:\>adchkcfg.cmd contextfile=<CONTEXT_FILE>

This script generates both HTML and text reports. The reports provide information about all file changes, profile option changes and other important database updates that will be done during the next normal execution of AutoConfig. Information is organized under the following two tabs:

File System Changes

This report is divided into the following sections:
- AutoConfig Context File Changes: Displays information about the location of the context file, the content of the currently active context file, the content of the context file that will be generated in the next AutoConfig run. In addition it also displays an HTML report highlighting the differences between the current and the new context file, if any.
- Service Group Status: Displays the status of the Service Groups and the corresponding services on the applications tier. This section is present only in the report generated on the applications tier.
- Changed Configuration Files: Displays a list of all the files that will be changed during an AutoConfig execution. For each file, information is displayed about the location of the runtime file, the content of the currently active file, the content of the file that will be generated in the next AutoConfig run. In addition, an HTML report highlights the differences between the current and the new configuration file, plus the location of the AutoConfig template file (if applicable).
- New Configuration Files: Displays a list of all the new files that will be created during an AutoConfig execution. For each file, information is displayed about the location of the runtime file, the content of the new file and the location of the AutoConfig template file.
- Template Customizations: Displays a list of all customized AutoConfig templates and reports the difference between the original AutoConfig template and the customized template.
Database Changes

This report is divided into the following sections:
- Profile Value Changes: Displays details of only those profiles whose value would be changed in the next AutoConfig run. For each such profile, the current value in the Database, the new AutoConfig value that would be set for it, the Profile Level and the name of the AutoConfig script that changes the profile value is displayed.
- Profile Values: Displays details as in previous section for all Apps Database profiles managed by AutoConfig, irrespective of whether their value would change or not in the next AutoConfig run.
- Other Database Updates: Displays details for important database updates (non-profile changes) that will be performed in the next AutoConfig run. The table name, column name, current column value in the database, and new AutoConfig value are displayed, along with the name of the updating AutoConfig script and a brief description.

The script also creates a zip file report, ADXcfgcheck.zip, which contains all the files and reports mentioned above. The ADXcfgcheck.zip file can be copied to a local client device, and the HTML report viewed there without breaking the hyperlinks in the report.

Using the Context Variable Information Utility

This command line utility can be used to find out detailed information about context variables and the templates in which they are used. The utility accepts all or part of a context variable name and generates an HTML or text report containing information about the matched context variables, including description, default vale, and current value. The variable description contains recommended settings, range of allowed values, and links to documents that provide detailed usage information. Additionally, the utility lists the configuration templates where the respective context variables are used.

After the Application tier environment file has been sourced, you can run the Context Variable Information utility as follows:

On the Application tier:

$ perl <FND_TOP>/bin/txkrun.pl -script=GenCtxInfRep \
-keyword="<keyword>"

On the Database tier:

$ perl <ORACLE_HOME>/appsutil/bin/txkrun.pl \
-script=GenCtxInfRep -keyword="<keyword>"

The utility takes the following arguments:

contextfile (optional): Complete path to the context file. By default, it is set to the value of <CONTEXT_FILE!>
keyword (required): All or part of a context variable name.
reporttype (optional): The report type. Valid values are 'html' (the default) and 'text'.
outfile (required): The report file. If only the name of the report file is provided, and not the complete path, the report will be generated in the <APPLTMP> directory.

Using AutoConfig on an Oracle RAC Instance

This section guides you through the steps that need to be performed when your Oracle Release 12.2 instance is running in an Oracle Real Application Clusters (Oracle RAC) environment.

Oracle E-Business Suite Release 12.2 delivers the infrastructure to generate a complete tnsnames.ora file required for Oracle RAC. This includes:

Instance aliases for each database tier node.
Load balance aliases with address lists for each database tier node.
FNDSM and FNDFS aliases (used by the CP Service Manager) for each application tier node.
Virtual hostname support.

The tnsnames.ora file is dynamically generated using the Net Services Topology Data Model. The Net Services Topology Data Model stores the entire topological information about a single Oracle E-Business Suite environment.

Complete the steps below to support AutoConfig on Oracle RAC:

Review init.ora: AutoConfig will not overwrite your existing init.ora file. However, when no init.ora file exists, AutoConfig will generate an init.ora that is compatible with Oracle RAC. It is advisable to create a backup of the existing init.ora file, and let AutoConfig generate a new init.ora file. This will ensure that the init.ora file conforms to Oracle's standards: for example, use of DB_Name as the service name, and handling of local and remote listeners.
Migrate AutoConfig Patch to Database tier: Follow the steps given above to migrate the AutoConfig Patch to the database tier.
Run AutoConfig on all Database tier nodes: Run AutoConfig on all database tier nodes, following the instructions given earlier.
Run AutoConfig on Application tier: Run AutoConfig on each Application tier node. Use the adautocfg.sh (or adautocfg.cmd) command described earlier.
Restart the database listener: Stop and restart your database listener.

Your system is now AutoConfig-enabled with Oracle RAC, and the system configuration can be managed as described earlier.

Managing Oracle HTTP Server Configurations

Prior to Oracle E-Business Suite Release 12.2, AutoConfig managed all Oracle HTTP Server configuration files throughout the system lifecycle. In Release 12.2, AutoConfig is only involved in the initial setup of the Oracle HTTP Server configuration files.

Later, it can optionally be used to manage and customize a limited set of Oracle HTTP Server configuration files. Otherwise, native Oracle WebLogic Server and Fusion Middleware tools are used to manage these files.

Important: For a comprehensive description of this area, refer to My Oracle Support Knowledge Document 1905593.1, Managing Configuration of Oracle HTTP Server and Web Application Services in Oracle E-Business Suite Release 12.2.

Managing Configuration of Web Application Services

In Oracle E-Business Suite Release 12, the oacore, oafm, forms, and forms-c4ws services were OC4J instances managed by Oracle Process Manager (OPMN). Because Oracle WebLogic Server has replaced OC4J in Oracle E-Business Suite Release 12.2, these services are now deployed as applications on individual managed servers. Consequently, only part of the configuration of these applications and managed servers is still managed through AutoConfig.

Configuring Oracle WebLogic Server Connection Filters

When you deploy Oracle E-Business Suite Release 12.2, it is important to secure Web Application Services such as Oracle WebLogic Server. By default, all the existing application tier nodes of the Oracle E-Business Suite instance are allowed unrestricted access to Oracle WebLogic Server ports. Also, by default, there are no trusted hosts defined for the Oracle WebLogic Server Administration ports, which are used by the Oracle WebLogic Server Administration Console and Fusion Middleware Control. In order to allow your administrators access to these consoles, you must specify the hosts that your administrators are using as trusted hosts for accessing the Oracle WebLogic Server Administration ports. The following guidelines help you secure your environment by configuring trusted hosts and connection filters.

Only Allow Access to Oracle WebLogic Server Administration Ports from Trusted Hosts

If you have applied the Critical Patch Update (CPU) released in April 2019, then you can use the context variable s_wls_admin_console_access_nodes to specify the trusted hosts used by administrators that require access to the Oracle WebLogic Server Administration Console and Fusion Middleware Control. Set this context variable to a list of trusted hosts that are allowed to access the consoles using the Oracle WebLogic Server Administration ports.

Note: If you cannot list the specific host names or IP addresses for all your trusted hosts, then you can use alternative methods to allow access to the Oracle WebLogic Server Administration ports. See Alternative Methods to Allow Access to Oracle WebLogic Server Administration Ports from Trusted Hosts for Oracle E-Business Suite Release 12.2, My Oracle Support Knowledge Document 2542826.1.

If you do not configure the s_wls_admin_console_access_nodes context variable as described in the following steps, or use one of the alternative methods to specify trusted hosts, then you will not be able to access the Oracle WebLogic Server Administration Console or Fusion Middleware Control.

Log in to the primary node of the Oracle E-Business Suite instance.
Start the Oracle WebLogic Admin Server from the run file system, if it is not already running.
Take a backup of the run file system context file.
Edit the run file system context file to set the value for the s_wls_admin_console_access_nodes context variable to the list of trusted hosts that are allowed to access the Admin Server. For each host, specify either the fully qualified domain name or the IP address. Use commas to separate the hosts in the list. For example:
```
<s_wls_admin_console_access_nodes oa_var="s_wls_admin_console_access_nodes">admin-ws1.example.com,admin-ws2.example.com</s_wls_admin_console_access_nodes>
```
Note: When you add the fully qualified domain name or the IP address for a host to the list in thes_wls_admin_console_access_nodes context variable, ensure that the host name is resolvable from all application tier nodes of the Oracle E-Business Suite instance.
Run AutoConfig.
Stop and restart the Oracle WebLogic Admin Server.

Note: You will be able to access the Oracle WebLogic Server Administration Console after restarting the Oracle WebLogic Admin Server.
Run the fs_clone operation (adop phase=fs_clone) to synchronize the changes in this setting to the patch file system.

After you save this configuration, which allows access only to trusted hosts, you will be able to access the Oracle WebLogic Server Administration Console and Fusion Middleware Control only from client browsers executed from the hosts specified in the preceding steps.

Note: If you need to make changes without having access to the Oracle WebLogic Server Administration Console, you can update or remove the connection filter rules by editing the $DOMAIN_HOME/config/config.xml file. However, changes added this way will be overwritten by the next AutoConfig run.

Only Allow Direct Access to Oracle WebLogic Server from Trusted Hosts

You should allow access to Oracle WebLogic Server only through your known web entry points. You can restrict connections to Oracle WebLogic Server by configuring Oracle WebLogic Server network connection filters.

If you have applied the April 2019 CPU, then Oracle WebLogic Server network connection filters are enabled by default. In this case the rules use a connection filter class for Oracle E-Business Suite called oracle.apps.ad.tools.configuration.wls.filter.EBSConnectionFilterImpl.

After you apply the April 2019 CPU and stop and restart the Oracle WebLogic Admin Server, all the existing application tier nodes of the Oracle E-Business Suite instance will be allowed unrestricted access to Oracle WebLogic Server.

The connection filter rules appear in the $DOMAIN_HOME/config/config.xml file in the following format:

<connection-filter>oracle.apps.ad.tools.configuration.wls.filter.EBSConnectionFilterImpl</connection-filter> 
<connection-filter-rule>192.0.2.11 * * allow</connection-filter-rule> 
<connection-filter-rule>192.0.2.12 * * allow</connection-filter-rule> 
<connection-filter-rule>192.0.2.100 * [WLS Admin Server Port] allow http</connection-filter-rule> 
<connection-filter-rule>0.0.0.0/0 * * deny</connection-filter-rule>

In this example, there are two Oracle HTTP Server WebTiers front-ending the WebLogic managed servers with the IP addresses 192.0.2.11 and 192.0.2.12, and the IP address of the trusted host for accessing the Oracle WebLogic Server Administration Console is 192.0.2.100. The WLS Admin Server port on the application tier in the rule for access to the Oracle WebLogic Server Administration Console will be set to the appropriate port based on whether it is on the run file system or the patch file system.

Before you add a new Oracle E-Business Suite application tier node, you must add a connection filter rule for the new node to the Oracle WebLogic Admin Server for both the run file system and the patch file system. For instructions, see:

Section 5.3, Adding a New Application Tier Node to an Existing System, Cloning Oracle E-Business Suite Release 12.2 with Rapid Clone, My Oracle Support Knowledge Document 1383621.1
Section 4: Adding a Node to the Shared Application Tier File System, Sharing The Application Tier File System in Oracle E-Business Suite Release 12.2, My Oracle Support Knowledge Document 1375769.1

Manually Enabling Oracle WebLogic Server Connection Filters (Conditionally Required)

If you have not applied the April 2019 CPU, you can restrict connections to Oracle WebLogic Server by manually configuring Oracle WebLogic Server network connection filters in the Oracle WebLogic Server Administration Console. See: Using Network Connection Filters, Oracle Fusion Middleware: Programming Security for Oracle WebLogic Server.

Caution: If you choose to configure Oracle WebLogic Server network connection filters manually, you may encounter issues when adding nodes or performing a clone with Rapid Clone. The fixes for these issues are provided in the April 2019 CPU. If you have not applied the April 2019 CPU, perform the following steps as a workaround:

Disable the network connection filters.
Add the node or perform the clone.
Manually re-enable the network connection filters.

To set network connection filters at the relevant WebLogic domain, perform the following steps on the run file system when there is no active online patching cycle:

Log in to the Oracle WebLogic Server Administration Console.
In the Domain Structure section, select the domain.
Click the Security tab, and then click the Filter tab.
In the Connection Filter attribute field, specify the following value:
```
weblogic.security.net.ConnectionFilterImpl
```
In the Connection Filter rules field, specify the rules in the following format:
```
targetAddress localAddress localPort action protocols
```
Specify the following rules to control access to your WebLogic managed servers.
- For each Oracle HTTP Server WebTier that front-ends your WebLogic managed servers, create a rule allowing unrestricted access.
- For each admin workstation that needs to access the Oracle WebLogic Server Administration Console for administration purposes, create two rules allowing access, one for the Admin Server port on the application tier for the run file system and one for the Admin Server port on the application tier for the patch file system.
- Finally, create a rule denying access to IPs other than those explicitly allowed.
These rules should appear as follows:
```
<IP_address_of_Oracle_HTTP_Server_1> * * allow  
<IP_address_of_Oracle_HTTP_Server_2> * * allow  
...
<IP_address_of_Oracle_HTTP_Server_N> * * allow    
<IP_address_of_Admin_workstation_1> * <Admin_Server_Port_for_RunFS> allow http     
<IP_address_of_Admin_workstation_1> * <Admin_Server_Port_for_PatchFS> allow http    
<IP_address_of_Admin_workstation_2> * <Admin_Server_Port_for_RunFS> allow http     
<IP_address_of_Admin_workstation_2> * <Admin_Server_Port_for_PatchFS> allow http    
...
<IP_address_of_Admin_workstation_N> * <Admin_Server_Port_for_RunFS> allow http     
<IP_address_of_Admin_workstation_N> * <Admin_Server_Port_for_PatchFS> allow http    
0.0.0.0/0 * * deny  
```
For example, suppose that you have two Oracle HTTP Server WebTiers front-ending your WebLogic managed servers with the IP addresses 192.0.2.11 and 192.0.2.12. Additionally, suppose that the AdminServer port on the application tier for the run file system is 7001, the AdminServer port on the application tier for the patch file system is 7002, and the IP address of the admin workstation is 192.0.2.100. To allow access only through the Oracle HTTP Server WebTiers, to allow WebLogic Admin Server access only from the admin workstation, and to deny access from all other IPs, specify the following rules:
```
192.0.2.11 * * allow 
192.0.2.12 * * allow 
192.0.2.100 * 7001 allow http  
192.0.2.100 * 7002 allow http  
0.0.0.0/0 * * deny
```
Note: If you enable TLS for WebLogic Admin Server, then when you create the rules allowing WebLogic Admin Server access to the admin workstation, you must specify the TLS port you enabled, and you must specify https instead of http. For example:
```
192.0.2.11 * * allow 
192.0.2.12 * * allow 
192.0.2.100 * 17001 allow https
192.0.2.100 * 17002 allow https
0.0.0.0/0 * * deny
```
See Section 5.4: Enable TLS for WLS AdminServer, Enabling TLS in Oracle E-Business Suite Release 12.2, My Oracle Support Knowledge Document 1367293.1.
Click Save.
Restart Oracle WebLogic Server.

All configuration changes made to the run file system will be propagated to the patch file system during the prepare phase of the next online patching cycle. If you want to propagate these changes to the current patch file system immediately, you can do so using the fs_clone operation (adop phase=fs_clone) which will synchronize the run and patch file systems.

The connection filter rules appear in the $DOMAIN_HOME/config/config.xml file in the following format:

<connection-filter>weblogic.security.net.ConnectionFilterImpl</connection-filter> 
<connection-filter-rule>192.0.2.11 * * allow</connection-filter-rule> 
<connection-filter-rule>192.0.2.12 * * allow</connection-filter-rule> 
<connection-filter-rule>192.0.2.100 * [WLS Admin Server Port] allow http</connection-filter-rule> 
<connection-filter-rule>0.0.0.0/0 * * deny</connection-filter-rule>

The WLS Admin Server port on the application tier in the rule for access to the Oracle WebLogic Server Administration Console will be set to the appropriate port based on whether it is on the run file system or the patch file system.

Disabling Web Services Atomic Transactions

As part of the effort to reduce attack surface, it is recommended that you disable Web services atomic transactions (WSAT) in Oracle WebLogic Server. If you have applied the April 2019 CPU, then Web services atomic transactions are disabled by default.

Manually Disabling Web Services Atomic Transactions (Conditionally Required)

If you have not applied the April 2019 CPU, you can disable Web services atomic transactions manually. To do so, perform the following steps on the run file system as the user that owns the Oracle E-Business Suite product files, usually applmgr.

Note: In some systems the Oracle E-Business Suite product files may be owned by the oracle user.

To disable WSAT for the Oracle WebLogic Server admin server, perform the following steps:
- Navigate to System Administration: Oracle Applications Manager > AutoConfig.
- Select the application tier context file, and choose Edit Parameters.
- Search for the s_nm_jvm_startup_properties variable by selecting OA_VAR in the search list of values and entering s_nm_jvm_startup_properties in the search text box. Then choose Go.
- In the Value field for the s_nm_jvm_startup_properties variable, append -Dweblogic.wsee.wstx.wsat.deployed=false to any existing value. Then choose Save.
- Enter a reason for the update, such as Disabling Web services atomic transactions. Then choose OK.
Additional Information: See: Using Web Services Atomic Transactions, Oracle Fusion Middleware: Programming Advanced Features of JAX-WS Web Services for Oracle WebLogic Server 10.3.6.
Set the -Dweblogic.wsee.wstx.wsat.deployed parameter to false for all managed servers in your environment.
- Log in to the Oracle WebLogic Server Administration Console. For example: http://apps.example.com:7001/console
- Click Lock & Edit.
- In the Domain Structure section, select your Oracle E-Business Suite domain. Then navigate to Environment > Servers and select one of the managed servers.
- Click the Server Start tab, and in the Arguments field, append -Dweblogic.wsee.wstx.wsat.deployed=false to any existing value. Then click Save.
- Repeat the two previous steps for all remaining managed servers in your environment.
- Click Activate Changes.
Stop the application tier services, using the adstpall.sh script on UNIX or the adstpall.cmd script on Windows.
Run AutoConfig on the application tier, using the adautocfg.sh script on UNIX or the adautocfg.cmd script on Windows.
Restart the application tier services, using the adstrtal.sh script on UNIX or the adstrtal.cmd script on Windows.

Using Profiles in Oracle WebLogic Server

Within Oracle E-Business Suite Release 12.2, Oracle WebLogic Server provides the ability to view runtime statistics related to JDBC datasources via the Administration Console. When performance issues or details from monitored runtime statistics indicate there may be a problem within the domain, specific profiles can be enabled to help you pinpoint the source of the problem. To do this, go to Administration Console and navigate as follows:

Domain Structure: Domain Services > DataSources > (Defined Data Source) > Diagnostics Tab

For more information, refer to the System Administration section of the Oracle Fusion Middleware Online Documentation Library, available at https://docs.oracle.com.

While profiling can be a valuable diagnostic tool, within Oracle E-Business Suite Release 12.2 the Data Source configuration is specifically configured to maintain long-running connections. This means that all objects collected when profiling is enabled will remain in memory until the connection is destroyed, eventually resulting in out-of-memory errors within Oracle WebLogic Server.

The time needed for an out-of-memory error to occur will depend several factors, including:

The amount of profiling enabled
The size of the JVM
The number of users accessing the application

To minimize the chances of experiencing an out of memory error, the following guidelines for profiling are recommended:

If possible, only use profiling when access to the system is limited
Before enabling profiling, try to identify the steps needed to reproduce the profiling data that is to be captured
After profiling is complete, restart Oracle WebLogic Server before opening the system to the general user population

In addition, alternative strategies to profiling should be considered for production environments. These include enabling JDBC Debug, or obtaining periodic dumps using WebLogic Diagnostic Framework tools.

Changing the Oracle WebLogic Server Administration User Password

The option to set the Oracle WebLogic Server Administration User password to a non-default value is available during Oracle E-Business Suite installation. This section describes the procedure to use (on the run file system) if you need to change the password at a later time.

Important: If you need to change the Administration User password, you must change the Node Manager password first. If you do not do this, the WebLogic Server configuration change will not be detected and the next online patching cycle may fail.

The Oracle WebLogic Server domain EBS_domain_<SID> (dedicated to Oracle E-Business Suite) uses Node Manager to control the Administration Server and the managed servers. For this domain, the Node Manager and Oracle WebLogic Server Administration User passwords must be same or the AD control scripts will not work properly.

By default, Oracle WebLogic Server used with Oracle E-Business Suite enforces the following password validation rules:

Minimum password length: 8
Minimum number of non-alphabetic characters, including numeric characters or special characters such as %, *, #, or }: 1

Important: If any provider-specific attributes have been changed for either the default WebLogic Authentication provider (DefaultAuthenticator) or the default Password Validation provider (SystemPasswordValidator), the new password must adhere to the above rules.

The password-changing instructions that follow should be performed on the run file system. The password change will be automatically propagated to the patch file system during the next adop prepare phase or fs_clone operation.

For more information, see: "Changing the Administrative User Password" in Chapter 3 of Oracle Fusion Middleware Administrator's Guide 11g Release 1 (11.1.1).

Shut down all application tier services except the Admin Server.
1. On the primary node, run the command:
```
 $ <ADMIN_SCRIPTS_HOME>/adstpall.sh -skipNM -skipAdmin
```
  On all secondary nodes, run the command:
```
 $ <ADMIN_SCRIPTS_HOME>/adstpall.sh 
```
Note: The above examples are for UNIX. If you are using Windows, employ the appropriate equivalent syntax.
Change the Oracle WebLogic Server Administration User password by performing the following steps as applicable.
1. Source the environment on the run file system.
2. Run the commands appropriate for your platform:
  - On UNIX, run the command:
```
$ perl $FND_TOP/patch/115/bin/txkUpdateEBSDomain.pl -action=updateAdminPassword
```
  - On Windows, open a DOS command window and perform the following steps on the nodes directed:
    1. Run the following command on all nodes:
```
C:\>perl %FND_TOP%\patch\115\bin\txkUpdateEBSDomain.pl -action=updateAdminPassword -allnodes=no
```
      Warning: Do not specify -allnodes=no on UNIX platforms.
    2. Run the following commands on the primary node only:
```
C:\><ADMIN_SCRIPTS_HOME>\adadminsrvctl.cmd stop
C:\><ADMIN_SCRIPTS_HOME>\adnodemgrctl.cmd stop
```
    3. Start Node Manager by running the following commands on all nodes:
```
C:\>cd %INST_TOP%\admin\install
C:\>adsvNodeManager.cmd
```
    4. When prompted, enter the new password you just set.
    5. Close the DOS command window.
From a terminal window, start all services on all nodes using the appropriate command for your platform.
- On UNIX, run the command:
```
$ <ADMIN_SCRIPTS_HOME>/adstrtal.sh 
```
- On Windows run the command:
```
C:\><ADMIN_SCRIPTS_HOME>\adstrtal.cmd
```
You now need to perform an fs_clone operation to change the WebLogic EBS Domain password on the patch file system:
1. Launch a new session and connect to the Oracle E-Business Suite instance.
2. Source the application tier environment file.
3. Run the following command:
```
$ adop phase=fs_clone
```

If the Admin Password of an EBS WebLogic Domain is lost or forgotten

As noted earlier, the EBS WebLogic domain uses Node Manager to control startup of the AdminServer and Managed Servers. For the EBS WebLogic domain, the Node Manager and WebLogic AdminServer passwords must be same. If the passwords are different, the AD control scripts will not work properly.

If the AdminServer password has been lost or forgotten, it can be reset by carrying out the following steps on the run file system. As described in the final step, an fs_clone operation should then be performed to synchronize the run and patch file systems.

Shut down all running services. Since the AdminServer password is not known, the servers cannot be stopped from the console and so must be killed as follows.
1. Connect to the Oracle E-Business Suite instance and source the application tier environment file.
2. Identify the PIDs of Node Manager, AdminServer, and all running Managed Servers:
```
$ ps -ef | grep "NodeManager"
$ ps -ef | grep "weblogic.Name=AdminServer"
$ ps -ef | grep "weblogic.Name=forms-c4ws_server"
$ ps -ef | grep "weblogic.Name=forms_server"
$ ps -ef | grep "weblogic.Name=oafm_server"
$ ps -ef | grep "weblogic.Name=oacore_server"
```
3. Kill all these processes, starting with Node Manager and followed by the Managed Servers.
Back up these folders, and then delete them:
```
<EBS_DOMAIN_HOME>/security/ DefaultAuthenticatorInit.ldift
<EBS_DOMAIN_HOME>/servers/<server_name>/data/ldap
<EBS_DOMAIN_HOME>/servers/<server_name>/security/boot.properties
<EBS_DOMAIN_HOME>/servers/<server_name>/data/nodemanager/boot.properties
```
Where:
- <EBS_DOMAIN_HOME> is the absolute path of the EBS WebLogic domain
- <server_name> is the name of the server directory under <EBS_DOMAIN_HOME>.
If the password is not reset correctly, the backed up files and folders can be restored.

Note: For certain servers, the boot.properties file may be present in only one location of the two specified above. In such a case, back it up and then delete it.
Set up a new environment to change the WLS AdminServer password.
1. Start a new session and connect to the Oracle E-Business Suite instance.
2. Do not source the application tier environment file.
3. Run the following command to source the WebLogic Server domain environment:
```
$ cd <EBS_DOMAIN_HOME>/bin
$ source setDomainEnv.sh
```
4. Run the following commands:
```
$ cd <EBS_DOMAIN_HOME>/security
$ java weblogic.security.utils.AdminAccount <wls_adminuser> <wls_admin_new_password> .
```
  Where:
  - <wls_adminuser> is the same as the value of context variable s_wls_admin_user
  - <wls_admin_new_password> is the new WLS AdminServer password you wish to set.
  Note: Do not omit the trailing period ('.') in the above command: it is needed to specify the current domain directory.
Start AdminServer from the command line. You will be prompted for the WebLogic Server username and password, so that the AdminServer boot.properties file can be generated.
1. Go to the EBS Domain Home:
```
$ cd <EBS_DOMAIN_HOME>
```
2. Start AdminServer:
```
$ java <s_nm_jvm_startup_properties> -Dweblogic.system.StoreBootIdentity=true -Dweblogic.Name=AdminServer weblogic.Server
```
  Where:
  - <s_nm_jvm_startup_properties> is the same as the value of context variable ss_nm_jvm_startup_properties
  The above command prompts for the WebLogic Server username and password:
```
Enter username to boot WebLogic server:
Enter password to boot WebLogic server: 
```
  Provide the same credentials as you provided in Step 3.
Change the Node Manager password.
1. Log in to the WebLogic Administration console.
2. Click the 'Lock & Edit' button.
3. In the left panel, click on the EBS Domain link.
4. Select the 'Security' tab.
5. Click on the 'Advanced' link.
6. Edit the 'Node Manager password' field and set it to the new WebLogic Server password. The password should be same as set in Step 3.
7. Edit the 'Confirm Node Manager Password' field and set it to the new WebLogic Server password. The password should be same as set in Step 3.
8. Save and activate the changes.
The first time, AdminServer has to be stopped from the Admin console. Follow these steps:
1. Log in to the WebLogic Administration console.
2. Shut down AdminServer.
Set up your environment to start AdminServer again. AdminServer should now be started using the normal AD script, which will also start Node Manager using the new password.
1. Launch a new session and connect to the Oracle E-Business Suite instance.
2. Source the application tier environment file.
3. Start AdminServer with the following command:
```
$ $ADMIN_SCRIPTS_HOME/adadminsrvctl.sh start
```
Start the Managed Servers. For the first time, all Managed Servers should be started from the WebLogic Server Admin console. This step will create boot.properties files for the respective Managed Servers. Follow these steps:
1. Log in to the WebLogic Server Administration Console.
2. Start all Managed Servers, one at a time.
Shut down all the Managed Servers. This is so the new credentials will be picked up at the next startup. Follow these steps:
1. Log in to the WebLogic AdminServer console.
2. Shut down all Managed Servers.
3. Shut down AdminServer.
Shut down Node Manager using the normal AD script.
```
$ $ADMIN_SCRIPTS_HOME/adnodemgrctl.sh stop
```
Copy the boot.properties file for each Managed Server.

WebLogic Server native scripts use the boot.properties file. The above steps have created the boot.properties file under <EBS_DOMAIN_HOME>/servers/<Managed Server name>/data/nodemanager, which is used by Node Manager. For each Managed Server, copy the newly-generated boot.properties file from<EBS_DOMAIN_HOME>/servers/<Managed Server name>/data/nodemanager to <EBS_DOMAIN_HOME>/servers/<Managed Server name>/security.

The EBS WebLogic Server domain password has now been changed, and all servers can now be started using the normal AD scripts.

To start AdminServer:
```
$ADMIN_SCRIPTS_HOME/adadminsrvctl.sh start
```
To start the Managed Servers:
```
$ $ADMIN_SCRIPTS_HOME/admanagedsrvctl.sh start <managed_server_name>
```
The above steps have changed the Oracle WebLogic AdminServer password on the run file system. You now need to perform an fs_clone operation, to change the WebLogic EBS Domain password on the patch file system:
1. Launch a new session and connect to the Oracle E-Business Suite instance.
2. Source the application tier environment file.
3. Run the following command:
```
$ adop phase=fs_clone
```

Known Issues

For the most current list of known issues with the AutoConfig-related configuration management of Oracle E-Business Suite Release 12.2 environments, see My Oracle Support Knowledge Document, 1905593.1, Managing Configuration of Oracle HTTP Server and Web Application Services in Oracle E-Business Suite Release 12.2.

Tuesday, November 5, 2019

Only Allow Access to Oracle WebLogic Server Administration Ports from Trusted Hosts

Technical Configuration

Introduction

Configuration Management Tools

Configuration Management Changes

Oracle WebLogic Server Requirements and Usage

AutoConfig Scope and Components

Cloning

Using AutoConfig to Manage Oracle E-Business Suite Services

Modifying AutoConfig-Managed Services and Service Groups

Commands to Manage Oracle E-Business Suite Service Processes

Port Pools

Using AutoConfig Tools for System Configuration

Preview Effects of Running AutoConfig

Run AutoConfig on the Database Tier

Stop Application Tier Services

Run AutoConfig on the Application Tier

Review AutoConfig Log Files

Start All Application Tier Services

Rolling Back an AutoConfig Session

Tools for Configuration Synchronization

Customizing AutoConfig-Managed Configurations

Implementing AutoConfig Customizations

Advanced Features of AutoConfig Customizations

AutoConfig Customization Limitations and Restrictions

Patching AutoConfig

Applying the Latest AutoConfig Updates

Enabling AutoConfig on a New Oracle Home

Advanced AutoConfig Features and Additional Utilities

Running AutoConfig in Parallel Across Multiple Nodes

Profiling An AutoConfig Run

Using the Check Config Utility

Using the Context Variable Information Utility

Using AutoConfig on an Oracle RAC Instance

Managing Oracle HTTP Server Configurations

Managing Configuration of Web Application Services

Configuring Oracle WebLogic Server Connection Filters

Only Allow Access to Oracle WebLogic Server Administration Ports from Trusted Hosts

Only Allow Direct Access to Oracle WebLogic Server from Trusted Hosts

Manually Enabling Oracle WebLogic Server Connection Filters (Conditionally Required)

Disabling Web Services Atomic Transactions

Manually Disabling Web Services Atomic Transactions (Conditionally Required)

Using Profiles in Oracle WebLogic Server

Changing the Oracle WebLogic Server Administration User Password

Known Issues

No comments:

Post a Comment

Database Options/Management Packs Usage Reporting for Oracle Databases 11.2 and later (Doc ID 1317265.1)