- 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.
- Check the value of the 'status' context variable corresponding to the service group.
- Change the value of this variable to 'enabled' to enable the service group, or to 'disabled' to disable the service group.
- Check the value of the 'status' context variable corresponding to the service group to which the service belongs.
- If the service group is 'disabled', enable the service group.
- If the value of the 'status' context variable corresponding to the service is not already set to 'enabled', change it to 'enabled'.
- 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'.
- In most cases, you simply need to set the service's 'status' context variable to 'disabled'.
- 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 /admin/scripts .
| 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) | start | start |
| Stop individual service (except those that are part of the Web Application Services service group) | stop | stop |
| Start individual managed server (all services that are part of the Web Application Services service group) | admanagedsrvctl.sh start | admanagedsrvctl.cmd start |
| 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 admanagedsrvctl abort | admanagedsrvctl.cmd stop admanagedsrvctl.cmd abort |
| Functionality | UNIX Command | Windows Command |
|---|---|---|
| Start database listener process | addlnctl.sh start | addlnctl.cmd start |
| Stop database listener process | addlnctl.sh stop | addlnctl.cmd stop |
| 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:
40 7241
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: /admin/scripts On Database Tier: /appsutil/scripts/ | This script is used for running AutoConfig. |
| adchkcfg.sh/cmd | On Applications Tier: /bin On Database Tier: /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: /patch/115/bin On Database Tier: /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: /bin On Database Tier: /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: /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
sh /appsutil/bin/adchkcfg.sh \ contextfile= C:\>\appsutil\bin\adchkcfg.cmd contextfile=Application Tier
$ sh /bin/adchkcfg.sh \ contextfile= C:\>\bin\adchkcfg.cmd contextfile=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:
$ sh /appsutil/scripts//adautocfg.sh
C:\>\appsutil\scripts\\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:
$ sh /adstpall.sh
C:\>\adstpall.cmd
Run AutoConfig on the Application Tier
Run AutoConfig on all application tier nodes by executing the applicable command below.
$ sh /admin/scripts/adautocfg.sh
C:\>\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 | /admin/log/ |
| Database | /appsutil/log// |
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:
$ sh /adstrtal.sh
C:\>\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 | /admin/out/ |
| Database | /appsutil/out/ |
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:
$ restore.sh
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
- 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.
- 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
- 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.
- 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:
$INST_TOP/admin/install/afwebprf.sh
$ $AD_TOP/bin/adtmplreport.sh contextfile=$CONTEXT_FILE \ target=$INST_TOP/admin/install/afwebprf.sqlOn 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 admin/template adconfig.txt INSTE8 /admin adconfig.txt 600 LOCK
$ mkdir $FND_TOP/admin/template/customOn Windows:
C:\>mkdir %FND_TOP%\admin\template\custom$ cp -i For example:
$ cp -i $FND_TOP/admin/template/afwebprf.sql \ $FND_TOP/admin/template/custom/afwebprf.sqlOn Windows: C:\>copy For example:
C:\> copy %FND_TOP%\admin\template\afwebprf.sql %FND_TOP%\admin\template\custom\afwebprf.sql/admin/log/ /appsutil/log//
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
$ mkdir /admin/templateOn Windows, create a directory using a command such as:
C:\>mkdir \admin\template
/admin/template/myTemplate.txtOn Windows, create a file such as:
\admin\template\myTemplate.txt
admin admin/sql admin/driver log sql out mesg
- 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.
For example, a driver file entry might contain the following (on one line):
my admin/template myTemplate.txt INSTE8 myConfiguration.txt 660
In this example, AutoConfig would instantiate the template file /admin/template/myTemplate.txt and generate the configuration file myConfiguration.txt into the Portal directory (the Portal directory is instantiated from ) 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 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:
- 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:
/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:
adtmplreport.sh contextfile= listcustom
adtmplreport.cmd contextfile= listcustom
To list all configuration files, their AutoConfig template files and their custom template files, use the appropriate command listed in the table below:
adtmplreport.sh contextfile= adtmplreport.cmd contextfile=To identify the configuration file for a given AutoConfig template file, use the appropriate command listed in the table below:
adtmplreport.sh contextfile= \ template= adtmplreport.cmd contextfile= \ template=To identify the AutoConfig template and custom template file for a given configuration file, use the appropriate command listed in the table below:
adtmplreport.sh contextfile= target= adtmplreport.cmd contextfile= target=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 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:
- 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.
- 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 /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:
- 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.
- 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 /bin/adconfig.pl contextfile= \ [product=] -profile
$ perl /appsutil/bin/adconfig.pl \ contextfile= [product=] -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 TiersTier Location Application /bin Database /appsutil/bin The Check Config utility is run by executing the following command:
$ adchkcfg.sh contextfile= C:\>adchkcfg.cmd contextfile=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.
- 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 /bin/txkrun.pl -script=GenCtxInfRep \ -keyword=""
$ perl /appsutil/bin/txkrun.pl \ -script=GenCtxInfRep -keyword=""
The utility takes the following arguments:
- contextfile (optional): Complete path to the context file. By default, it is set to the value of
- 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 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.
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.
- 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:
admin-ws1.example.com,admin-ws2.example.com 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:
oracle.apps.ad.tools.configuration.wls.filter.EBSConnectionFilterImpl 192.0.2.11 * * allow 192.0.2.12 * * allow 192.0.2.100 * [WLS Admin Server Port] allow http 0.0.0.0/0 * * deny 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
targetAddress localAddress localPort action protocols
- 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:
* * allow * * allow . * * allow * allow http * allow http * allow http * allow http . * allow http * 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.
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:
weblogic.security.net.ConnectionFilterImpl 192.0.2.11 * * allow 192.0.2.12 * * allow 192.0.2.100 * [WLS Admin Server Port] allow http 0.0.0.0/0 * * deny 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.
- 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.
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:
- 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: 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:
- Set a blackout in Oracle Enterprise Manager Grid Control for this environment.
- Perform the steps to change the Oracle WebLogic Server Administration User password following the instructions in this section.
- Test and confirm the updated credentials in the Oracle WebLogic Server Console and verify that adop has completed successfully.
- 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_ (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.
- Source the environment on the run file system.
- Run the commands appropriate for your platform:
- On UNIX, run the command:
- Launch a new session and connect to the Oracle E-Business Suite instance.
- Source the application tier environment file.
- Run the following command:
- 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.
- Connect to the Oracle E-Business Suite instance and source the application tier environment file.
- 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"
/security/ DefaultAuthenticatorInit.ldift /servers//data/ldap /servers//security/boot.properties /servers//data/nodemanager/boot.properties
- is the absolute path of the EBS WebLogic domain
- is the name of the server directory under .
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.
- Start a new session and connect to the Oracle E-Business Suite instance.
- Do not source the application tier environment file.
- Run the following command to source the WebLogic Server domain environment:
$ cd /bin $ source setDomainEnv.sh
$ cd /security $ java weblogic.security.utils.AdminAccount .
- is the same as the value of context variable s_wls_admin_user
- 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.
$ java -Dweblogic.system.StoreBootIdentity=true -Dweblogic.Name=AdminServer weblogic.Server
- 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.
- Log in to the WebLogic Administration console.
- Click the 'Lock & Edit' button.
- In the left panel, click on the EBS Domain link.
- Select the 'Security' tab.
- Click on the 'Advanced' link.
- 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.
- 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.
- Save and activate the changes.
- Log in to the WebLogic Administration console.
- Shut down AdminServer.
$ $ADMIN_SCRIPTS_HOME/adadminsrvctl.sh start
- Log in to the WebLogic Server Administration Console.
- Start all Managed Servers, one at a time.
- Log in to the WebLogic AdminServer console.
- Shut down all Managed Servers.
- Shut down AdminServer.
$ $ADMIN_SCRIPTS_HOME/adnodemgrctl.sh stop
$ADMIN_SCRIPTS_HOME/adadminsrvctl.sh start
To start the Managed Servers: $ $ADMIN_SCRIPTS_HOME/admanagedsrvctl.sh start- Launch a new session and connect to the Oracle E-Business Suite instance.
- Source the application tier environment file.
- 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.
-
On the primary node, run the command:
$ /adstpall.sh -skipNM -skipAdmin
On all secondary nodes, run the command:$ /adstpall.sh
Note: The above examples are for UNIX. If you are using Windows, employ the appropriate equivalent syntax.
$ perl $FND_TOP/patch/115/bin/txkUpdateEBSDomain.pl -action=updateAdminPassword
-
Run the following command on all nodes:
C:\>perl %FND_TOP%\patch\115\bin\txkUpdateEBSDomain.pl -action=updateAdminPassword -allnodes=no
C:\>\adadminsrvctl.cmd stop C:\>\adnodemgrctl.cmd stop
C:\>cd %INST_TOP%\admin\install C:\>adsvNodeManager.cmd
$ /adstrtal.sh
C:\>\adstrtal.cmd
$ 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.
-
On the application tier (as the APPLMGR user).
-
Run EBSapps.env . For example:
EBSapps.env RUN
$ perl /bin/admkappsutil.pl
$ cd $ unzip -o appsutil.zip
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:
$ perl /appsutil/bin/adbldxml.pl$ /appsutil/bin/adconfig.sh \ contextfile= On Windows: C:\>\appsutil\bin\adconfig.cmd contextfile=
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 /bin/adconfig.pl contextfile= \ [product=] -parallel
$ perl /appsutil/bin/adconfig.pl \ contextfile= -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: