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:

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:

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

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

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

Managed server names for these clusters are grouped as follows:

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:

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.

Commands to Manage Oracle E-Business Suite Service Processes

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:

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:

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:

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:

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:

Each of these will be considered in turn.

Advanced Features of AutoConfig Customizations

This section discusses advanced features available when using AutoConfig Customizations.

AutoConfig Customization Limitations and Restrictions

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

Patching AutoConfig

In 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.

  1. 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

  2. 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:

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

  1. 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.

  2. 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.

  3. 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.

  4. 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:

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:

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

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:

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:

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:

The utility takes the following arguments:

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:

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:

  1. 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.

  2. Migrate AutoConfig Patch to Database tier: Follow the steps given above to migrate the AutoConfig Patch to the database tier.

  3. Run AutoConfig on all Database tier nodes: Run AutoConfig on all database tier nodes, following the instructions given earlier.

  4. Run AutoConfig on Application tier: Run AutoConfig on each Application tier node. Use the adautocfg.sh (or adautocfg.cmd) command described earlier.

  5. 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.

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.

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.

  1. Log in to the primary node of the Oracle E-Business Suite instance.

  2. Start the Oracle WebLogic Admin Server from the run file system, if it is not already running.

  3. Take a backup of the run file system context file.

  4. 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.

  5. Run AutoConfig.

  6. 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.

  7. 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:

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:

  1. Disable the network connection filters.

  2. Add the node or perform the clone.

  3. 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:

  1. Log in to the Oracle WebLogic Server Administration Console.

  2. In the Domain Structure section, select the domain.

  3. Click the Security tab, and then click the Filter tab.

  4. In the Connection Filter attribute field, specify the following value:

    weblogic.security.net.ConnectionFilterImpl

  5. 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.

  6. Click Save.

  7. 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.

  1. 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.

  2. 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.

  3. Stop the application tier services, using the adstpall.sh script on UNIX or the adstpall.cmd script on Windows.

  4. Run AutoConfig on the application tier, using the adautocfg.sh script on UNIX or the adautocfg.cmd script on Windows.

  5. Restart the application tier services, using the adstrtal.sh script on UNIX or the adstrtal.cmd script on Windows.

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.

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:

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

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: Just before you begin the steps to change the Oracle WebLogic Server Administration User password, you must ensure that any automated script connecting to the Oracle WebLogic Server Console is first disabled. After you finish changing the password, you must update any such script with the new password before restarting it. If an automated script runs with an old password, then the Oracle WebLogic Server AdminServer account will be locked after five failed connection attempts, which will cause adop sessions to fail.

In particular, if you are monitoring Oracle E-Business Suite using Oracle Enterprise Manager Grid Control, you should perform the following steps when changing the Oracle WebLogic Server Administration User password:

  1. Set a blackout in Oracle Enterprise Manager Grid Control for this environment.

  2. Perform the steps to change the Oracle WebLogic Server Administration User password following the instructions in this section.

  3. Test and confirm the updated credentials in the Oracle WebLogic Server Console and verify that adop has completed successfully.

  4. End the blackout for the Oracle Enterprise Manager Grid Control monitoring agent for this environment.

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:

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).

  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.

  2. 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

        Note: On UNIX platforms, this command will initiate the change on all nodes.

      • 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

        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.

  3. 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

  4. 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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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

  8. 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.

  9. 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.

  10. Shut down Node Manager using the normal AD script.

    $ $ADMIN_SCRIPTS_HOME/adnodemgrctl.sh stop

  11. 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>

  12. 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.