Doc ID: 1905593.1 Configuration management of Oracle HTTP Server and web applications in Oracle E-Business Suite Release 12.2

Release 12.2 OHS configuration File maintenance (Doc ID 1676430.1)
and
Managing Configuration of Oracle HTTP Server and Web Application Services in Oracle E-Business Suite Release 12.2 (Doc ID 1905593.1)
Shown here:
This document provides an overview of configuration management of Oracle HTTP Server and web applications in Oracle E-Business Suite Release 12.2. It also lists the known issues in configuration management. The most current version of this document can be obtained in My Oracle Support Knowledge Document 1905593.1, Managing Configuration of Oracle HTTP Server and Web Application Services in Release 12.2, by Oracle E-Business Suite Development.
A change log is available at the end of this document.
In This Document
This document is divided into the following sections:

Section 1: Overview
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, as described in this document, native Oracle WebLogic Server and Fusion Middleware tools are used to manage these files.
In Oracle E-Business Suite Release 12, the oacore, oafm, forms and forms-c4ws services were deployed as applications on OC4J instances and were 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 via AutoConfig. This document describes those areas that remain managed by AutoConfig and those that are not.
Note: You are strongly encouraged to be on the latest AD/TXK codelevel. Refer to My Oracle Support Knowledge Document 1583092.1, Oracle E-Business Suite Release 12.2: Suite-Wide Rollup and AD/TXK Delta Information, and apply the most recent delta patches.
It is important to read the release notes for those patches, since they may require other patches. Refer to My Oracle Support Knowledge Document 1617461.1, Applying the Latest AD and TXK Release Update Packs to Oracle E-Business Suite Release 12.2.
The instructions in this document are applicable only for AD/TXK Delta 4 codelevel and higher which is the minimum supported codelevel for AD/TXK at this time.
Section 2: Tools for Configuration Synchronization
In Oracle E-Business Suite Release 12.2, some Oracle HTTP Server configurations and WebLogic configurations are managed via AutoConfig while some are managed natively via Fusion Middleware Control and 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’.
Following tools are used for performing this synchronization:

Script Name	Location	Purpose
adRegisterWLSListeners.pl	On Applications Tier: <AD_TOP>/bin	This script is used to listen to changes to the WebLogic Server configuration parameters and update the context variables accordingly. Note: This script is not able to synchronize changes to Oracle HTTP Server configuration.
adSyncContext.pl	On Applications Tier: <AD_TOP>/bin	This script is used to explicitly pull the values of the WebLogic Server and Oracle HTTP Server configuration parameters and synchronize the corresponding context variable values accordingly.

2.1 Run adRegisterWLSListeners Tool on the Application Tier
As noted previously, some Oracle E-Business Suite Release 12.2 configurations are managed via AutoConfig, and some are managed natively via Fusion Middleware Control or Oracle WebLogic Server Administration Console.
The adRegisterWLSListeners tool performs automatic synchronization of context variables with the corresponding Oracle WebLogic Server configuration parameters.
Note: This tool does not listen for changes to the Oracle HTTP Server configuration parameters.
On UNIX instances, the tool is started automatically on the primary node whenever WebLogic Administration Server is started.
On Windows instances, the tool needs to be explicitly started up on the primary node every time WebLogic Administration Server is started up.
Execute the following command to start adRegisterWLSListeners.pl:
$ perl <AD_TOP>/bin/adRegisterWLSListeners.pl contextfile=<CONTEXT_FILE>
Once started, adRegisterWLSListeners keeps running, listening for changes to the WebLogic Server configuration and synchronizing the context files stored in the database. The tool automatically stops when WebLogic Administration Server is shut down.
2.2 Run SyncContext on the Application Tier
The SyncContext tool is used for explicit synchronization of the context variables with the WebLogic Server and Oracle HTTP Server configurations.
It differs from adRegisterWLSListeners.pl in that it is able to synchronize the context file with the Oracle HTTP Server configuration changes as well.
Execute the following command to run adSyncContext.pl on a respective Application tier node.
$ perl <AD_TOP>/bin/adSyncContext.pl contextfile=<CONTEXT_FILE>
Note: The Node Manager and the WebLogic AdminServer must be running during execution of adSyncContext.pl.
Section 3: Managing Configuration of Oracle HTTP Server
As mentioned in Section 1, AutoConfig manages only a limited set of Oracle HTTP Server Configuration files in Release 12.2. Most Oracle HTTP Server configuration files are now managed via native Oracle WebLogic Server and Fusion Middleware tools.
3.1 Updating AutoConfig-Managed Oracle HTTP Server Configurations
The table below shows the Oracle HTTP Server configuration templates that are managed by AutoConfig in Oracle E-Business Suite Release 12.2. The configurations defined in these files can be customized by customizing the templates.

Template Name	Configuration File
ssl_terminator_conf_FMW.tmp	ssl_terminator.conf
trusted_conf_FMW.tmp	trusted.conf
oracle_apache_conf_FMW.tmp	oracle_apache.conf
oracle_apache_ssl_conf_FMW.tmp	oracle_apache_ssl.conf
url_fw_conf_FMW.tmp	url_fw.conf
url_fw_ws_conf_FMW.tmp	url_fw_ws.conf
security2_dmz_conf_FMW.tmp	security2_dmz.conf
security2_conf_FMW.tmp	security2.conf
security2_conf_FMW_nt.tmp	security2.conf
custom_conf_FMW.tmp	custom.conf
webgate_conf_FMW.tmp	webgate.conf

Note: For more information regarding customization of AutoConfig templates, refer to Chapter 3: Technical Configuration in Oracle E-Business Suite Setup Guide for Release 12.2.

3.2 Updating Seeded Oracle HTTP Server Configurations
During creation of the Oracle HTTP Server instance, AutoConfig performs the first instantiation of configuration files such as httpd.conf and mod_wl_ohs.conf. After the installation or upgrade to Release 12.2 is complete, seeded Oracle HTTP Server configurations are generally managed via Fusion Middleware Control. In certain specific cases, however, manual editing of the configuration files may be needed: this will be advised separately where required.
Note: For further information, refer to Section 3.3: Getting Started Using Oracle Enterprise Manager Fusion Middleware Control in Oracle Fusion Middleware Administrator’s Guide. This book can be found in the Oracle Fusion Middleware Documentation Library.
When modifying Oracle HTTP Server protocols or port numbers, these values must be updated in both the context file as well as in the configuration files. This is to ensure that the new values are updated in the AutoConfig-managed database profile values as well.
To modify HTTP server protocols or port numbers, perform the following steps on the run file system:

Login to Oracle Fusion Middleware Control Console.
Select Web Tier Target under EBS Domain.
Select Administation > Advanced Configuration.
Edit the relevant file to update the respective HTTP configuration parameter value.
Run the following command on all application tier nodes:

$ perl <AD_TOP>/bin/adSyncContext.pl contextfile=<CONTEXT_FILE>

Run AutoConfig on all application tier nodes.
Restart HTTP services by executing the following command on the run file system:On UNIX:

$ sh <ADMIN_SCRIPTS_HOME>/adapcctl.sh stop
$ sh <ADMIN_SCRIPTS_HOME>/adapcctl.sh start
On Windows:
C:\><ADMIN_SCRIPTS_HOME>/adapcctl.cmd stop
C:\><ADMIN_SCRIPTS_HOME>/adapcctl.cmd start
3.3 Running Oracle HTTP Server on a Privileged Port
On a UNIX system, the TCP/IP port numbers below 1024 are special in that only processes with root privileges are allowed to listen on those ports. If you wish to configure Oracle HTTP Server to run on a privileged port, you must first edit the HTTP port as specified in Section 3.2 and then perform the following additional steps to enable Oracle HTTP Server to run as root. These steps are required for both SSL and non-SSL privileged ports.

Execute the following commands as the root user on both the run file system and the patch file system.

$ chown root <FMW_HOME>/webtier/ohs/bin/.apachectl
$ chmod 6750 <FMW_HOME>/webtier/ohs/bin/.apachectl

Restart HTTP services by executing the following command on the run file system:On UNIX:

$ sh <ADMIN_SCRIPTS_HOME>/adapcctl.sh stop
$ sh <ADMIN_SCRIPTS_HOME>/adapcctl.sh start
On Windows:
C:\><ADMIN_SCRIPTS_HOME>/adapcctl.cmd stop
C:\><ADMIN_SCRIPTS_HOME>/adapcctl.cmd start
For more information, see: Starting Oracle HTTP Server on a Privileged Port, Oracle Fusion Middleware Administrator’s Guide for Oracle HTTP Server.
Section 4: Managing Configuration of Web Application services
In Oracle E-Business Suite Release 12.2, the oacore, oafm, forms, forms-c4ws and oaea services are deployed as applications on individual managed servers. Some of the configuration parameters of these services are managed at the application level while others are managed at individual managed server level.
4.1 Updating Configuration Parameters for Individual Applications
The basic configurations of the oacore, oafm, forms, forms-c4ws and oaea applications are maintained in their respective deployment plans. The deployment plan for an application contains configurable parameters such as session timeout, log file rotation size, and log file rotation time. Each deployment plan is delivered as an AutoConfig template containing a limited set of context variables.
AutoConfig instantiates the deployment plan initially. Subsequently, AutoConfig only updates the existing deployment plan: this is needed in case any of the context variables used in the deployment plan have been customized.
The only parameters that can be updated using AutoConfig are for the oacore application. Following is the list of parameters in the deployment plan for oacore application that is managed via AutoConfig:

Parameter	Value
help_InitParam_ohwConfigFileURL	file:%s_ora_config_home%/FMW/oacore/config/ohwconfig.xml
CGIServlet_InitParam_cgiDir	%s_config_home%/admin/install
CGIServlet_InitParam_*.pl	%s_adperlprg%
oowa_InitParam_log_main_file	%s_logs_dir%/ora/FMW/oacore/oowa.log
oowa_InitParam_log_spl2_file	%s_logs_dir%/ora/FMW/oacore/oowa.log
LoopProcServlet_InitParam_ARCHIVE	%s_applptmp%
TransmitServlet_InitParam_ARCHIVE	%s_applptmp%

The remaining parameters for each application need to be updated through the WebLogic Server Administration Console, as follows:

Log on to the WebLogic Server Administration Console.
Click on the ‘Deployments’ link in the left panel for ‘Domain Structure.’
Examine the page that gives a summary of all deployments.
If the configuration is to be customized at the application level, click on the application whose configuration is to be updated. For example, if updating oacore configuration, click on the link for ‘oacore’ and take the desired action.
If the configuration changes are to be done at the Web Application level, click on the link for the respective Web Application in the Deployments page, and select the ‘Configuration’ tab to customize the configuration parameters for the application.
After editing and setting the parameters, click on the ‘Save’ button. This updates the deployment plan for the application.
Once all configuration changes have been saved, click on the ‘Activate Changes’ button in the ‘Change Center’ panel to activate the changes.

Note: For further information, refer to Section 3.4: Getting Started Using Oracle WebLogic Server Administration Console in Oracle Fusion Middleware Administrator’s Guide 11g Release 1 (11.1.1). This book can be found in the Oracle Fusion Middleware Documentation Library.
4.2 Managing Configuration Parameters for Individual Managed Servers
4.2.1 Customizing Managed Server Configuration via WebLogic Server Administration Console
4.2.2 Managing Classpath and JVM Arguments for the Managed Server
4.2.3 Resetting Managed Server Classpath and JVM Arguments to Default Values
4.2.4 Changing the Port Numbers of the Managed Servers
4.2.1 Customizing Managed Server Configuration via WebLogic Server Administration Console
The managed server configuration can be customized via native WebLogic tools such as the WebLogic Server Administration Console and WLST commands.
Use the following steps to customize the managed server configuration via the WebLogic Server Administration Console.

Log on to the WebLogic Server Administration Console.
Click on the ‘Servers’ link. This link takes you to a page containing a summary of the WebLogic Administration Server and all managed servers.
Click on the managed server whose configuration needs to be updated. A page containing various tabs for the settings of the managed server appears.
Update the configuration parameters as needed.
Click the ‘Save’ button to save the configuration changes.
Once the customizations are complete and saved, click the ‘Activate Changes’ button in the ‘Change Center’ panel to activate the changes.

Note: If the managed server port number is to be changed, in addition to updating the port number via the native WebLogic tools you must also perform the additional steps in Section 4.2.4.
4.2.2 Managing Classpath and JVM Arguments for the Managed Server
The classpath and JVM arguments of a managed server can be modified from the WebLogic Server Administration Console or through WLST commands as specified above, which is the preferred way.
In addition, in case these properties are to be set from the command line, it can be done as follows:

To set the managed server classpath, execute the following command:

$ perl <AD_TOP>/patch/115/bin/adProvisionEBS.pl ebs-set-managedsrvproperty \
-contextfile=<CONTEXT_FILE> -managedsrvname=<MANAGED SERVER NAME> \
-managedsrvclasspath=”<COMPLETE MANAGED SERVER CLASSPATH>”

Note: The above command will overwrite the existing managed server’s classpath to the value specified for the argument -managedsrvclasspath.
So it should be ensured that the complete managed server classpath is provided in the above command. The existing managed server classpath value can be obtained from the WebLogic AdminServer Console, by navigating to the respective managed server as specified in Section 4.2.1 and then clicking on the ‘Server Start‘ tab.
Only in the unlikely case when the value cannot be retrieved from the WebLogic AdminServer Console, the default value supplied for the managed server classpath in the context file can be used. Refer to Section 4.2.3 for details of the managed server classpath context variables.

To set the managed server JVM arguments, execute the following command:

$ perl <AD_TOP>/patch/115/bin/adProvisionEBS.pl ebs-set-managedsrvproperty \
-contextfile=<CONTEXT_FILE> -managedsrvname=<MANAGED SERVER NAME> \
-serverstartargs=”<COMPLETE LIST OF JVM ARGUMENTS>”
Note: The above command will overwrite the existing managed server’s JVM arguments to the value specified for the argument -serverstartargs.
So it should be ensured that the complete set of JVM arguments for the managed server is provided in the above command. The existing JVM arguments for the managed server can be obtained from the WebLogic AdminServer Console, by navigating to the respective managed server as specified in Section 4.2.1 and then clicking on the ‘Server Start‘ tab.
Only in the unlikely case when the value cannot be retrieved from the WebLogic AdminServer Console, the default value supplied for the managed server JVM arguments in the context file can be used. Refer to Section 4.2.3 for details of the context variables for the managed server JVM arguments.

During startup of a managed server using the adstrtal.sh/cmd script or the individual control script admanagedsrvctl.sh/cmd, the Oracle E-Business Suite-specific library path is updated in the managed server JVM arguments. If the JVM arguments have already been customized for the managed server, the E-Business Suite specific library path is prepended to the list of customized library paths.
4.2.3 Resetting Managed Server Classpath and JVM Arguments to Default Values
If you need to reset the managed server classpath or JVM arguments to the default values, refer to the default values in the context file and update these properties using either the native WebLogic tools or the adProvisionEBS.pl script used in Section 4.2.2.
The default values for the managed server classpath can be identified from the context variables listed in the following table:

Service Type	Context Variable
oacore	s_oacore_classpath
oafm	s_oafm_classpath
forms	s_forms_classpath
forms-c4ws	s_forms-c4ws_classpath

The default values for the managed server JVM arguments can be identified from the context variables listed in the following table:

Service Type	Context Variable
oacore	s_oacore_jvm_start_options
oafm	s_oafm_jvm_start_options
forms	s_forms_jvm_start_options
forms-c4ws	s_forms-c4ws_jvm_start_options

4.2.4 Changing the Port Numbers of the Managed Servers
To change the port number of a managed server, you must first edit the port number by following the steps in Section 4.2.1.
Then perform the following steps on all application tier nodes participating in the same cluster that this managed server is part of:

Source the run file system.
Execute the following command to delete references of the old managed server port in the OHS configuration files mod_wl_ohs.conf and apps.conf:

$ perl <FND_TOP>/patch/115/bin/txkSetAppsConf.pl \
-contextfile=<CONTEXT_FILE> \
-configoption=removeMS \
-oacore=<host>.<domain>:<port> \
-oafm=<host>.<domain>:<port> \
-forms=<host>.<domain>:<port> \
-formsc4ws=<host>.<domain>:<port> \
-ekanban=<host>.<domain>:<port> \
-accessgate=<host>.<domain>:<port> \
-yms=<host>.<domain>:<port>
where

The argument contextfile accepts the complete path to the context file.
The arguments oacore, oafm, forms, formsc4ws, ekanban, accessgate and yms accept a comma-separated list of managed server details in the following format:
<host>.<domain>:<port>
- host, domain and port are the hostname, domain and port of the managed server whose reference is to be deleted.

For example, if the port number of the managed server oacore_server3 on host ‘testserver’ and domain ‘example.com’ is being changed from 7205 to 7305, the following command should be executed to remove references of port 7205:
$ perl <FND_TOP>/patch/115/bin/txkSetAppsConf.pl -contextfile=<CONTEXT_FILE> \
-configoption=removeMS -oacore=testserver.example.com:7205

Execute the following command to add back the managed server entry in the OHS configuration files with the new port:

$ perl <FND_TOP>/patch/115/bin/txkSetAppsConf.pl \
-contextfile=<CONTEXT_FILE> \
-configoption=addMS \
-oacore=<host>.<domain>:<port> \
-oafm=<host>.<domain>:<port> \
-forms=<host>.<domain>:<port> \
-formsc4ws=<host>.<domain>:<port>
where

The argument contextfile accepts the complete path to the context file.
The arguments oacore, oafm, forms, formsc4ws accept a comma-separated list of managed server details in the following format:
<host>.<domain>:<port>
- host and domain are the hostname and domain name of the newly added node
- port is the port of the new managed server whose reference is to be added

For example, to add back entry of managed server oacore_server3 on host ‘testserver’ and domain ‘example.com’ with port 7305, the following command should be executed:
$ perl <FND_TOP>/patch/115/bin/txkSetAppsConf.pl -contextfile=<CONTEXT_FILE> \
-configoption=addMS -oacore=testserver.example.com:7305

If Oracle HTTP Server is enabled on the node, restart it as follows:On UNIX:

$ sh <ADMIN_SCRIPTS_HOME>/adapcctl.sh stop
$ sh <ADMIN_SCRIPTS_HOME>/adapcctl.sh start
On Windows:
C:\><ADMIN_SCRIPTS_HOME>/adapcctl.cmd stop
C:\><ADMIN_SCRIPTS_HOME>/adapcctl.cmd start
4.3 Additional Steps Needed on Non-Shared Multi-Node Systems
Configuration changes performed via Oracle WebLogic Server (WLS) Console to any of the oacore, oafm, forms and forms-c4ws applications are reflected in the associated deployment plans. The changes are made automatically to the deployment plan on the node where the AdminServer is running.
If you have a multi-node system, you must manually update the deployment plans on the other nodes so that the plans on all nodes are synchronized.
The deployment plans are located as follows:

<EBS_ORACLE_HOME>/deployment_plans/oacore/plan.xml
<EBS_ORACLE_HOME>/deployment_plans/oafm/plan.xml
<EBS_ORACLE_HOME>/deployment_plans/forms/plan.xml
<EBS_ORACLE_HOME>/deployment_plans/forms-c4ws/plan.xml

If any configuration changes are made to a deployment plan via WLS Console, follow the steps below to synchronize the deployment plans on the other nodes.

Edit the relevant deployment plan to enter the new configuration value in the variable-definition section.For example, if the Session cookies max age parameter is changed via WLS console, you must make a corresponding update to the variable WeblogicApplication_SessionDescriptor_CookieMaxAgeSecs in the variable-definition section of the deployment plan.
Save the deployment plan.
Restart the managed server.

4.4 Customizing the Number of Instances of a Particular Service Type
By default, every application tier node contains only a single instance of the oacore, oafm, forms and forms-c4ws services. If more instances of a particular service are required on an application tier node, new managed servers must be created. Similarly, if the number of instances of a particular service needs to be reduced, the relevant managed server needs to be deleted.
Note: For the oacore service, Oracle recommends up to 150-200 concurrent users per JVM of size 2 GB.

4.4.1 Adding a new managed server
Addition of managed servers needs to be done on the run file system when there is no active ADOP cycle. During the next adop prepare, the Configuration Change Detector identifies that the addition has been made and the managed servers are automatically synced up from the run file system to the patch file system. The synchronization also gets done when fs_clone is executed.
Note: Managed server creation should be done only through the adProvisionEBS.pl script as mentioned in this section. Managed servers should not be created from the WebLogic Server Administration Console.
To add a new managed server of a specific service type, perform the following steps on the run file system:

Execute the following command to add a new managed server. This will create a managed server and add a new entry to the context file for starting and stopping the new managed server via the adstrtal and adstpall scripts:

$ perl <AD_TOP>/patch/115/bin/adProvisionEBS.pl \
ebs-create-managedserver -contextfile=<CONTEXT_FILE> \
-managedsrvname=<MANAGED_SERVER_NAME> -servicetype=<SERVICE_TYPE> \
-managedsrvport=<MANAGED_SERVER_PORT> -logfile=<LOGFILE>
For example, to add a managed server ‘oacore_server2’ of type ‘oacore’ with port 7203, run the following command:
$ perl <AD_TOP>/patch/115/bin/adProvisionEBS.pl \
ebs-create-managedserver -contextfile=<CONTEXT_FILE> \
-managedsrvname=oacore_server2 -servicetype=oacore \
-managedsrvport=7203 -logfile=<APPLRGF>/TXK/addMS_oacoreserver2.log

Note:

- The managed server name must be of the form <SERVICE_TYPE>_server<n>, where n is an integer.
- As well as being free, the port number for each managed server must be unique: no two managed servers across the run and
- patch file systems can have the same port number.

Startup the managed server as follows:On Unix:

$ sh <ADMIN_SCRIPTS_HOME>/admanagedsrvctl.sh start <MANAGED SERVER NAME>
On Windows:
C:\><ADMIN_SCRIPTS_HOME>\admanagedsrvctl.cmd start <MANAGED SERVER NAME>
For example, to startup the newly added managed server ‘oacore_server2’, execute the following command:
$ sh <ADMIN_SCRIPTS_HOME>/admanagedsrvctl.sh start oacore_server2

Perform the following steps on all application tier nodes participating in the same cluster where this managed server is added:

1. Source the run file system.
2. Execute the following command to add details of the newly added managed servers into the OHS configuration files mod_wl_ohs.conf and apps.conf on the current node:

The argument contextfile accepts the complete path to the context file.
The arguments oacore, oafm, forms, formsc4ws accept a comma-separated list of managed server details in the following format:
<host>.<domain>:<port>
- host and domain are the hostname and domain name of the newly added node
- port is the port of the new managed server whose reference is to be added

For example, if the managed server oacore_server2 has been added on host ‘testserver’ and domain ‘example.com’ with port 7205, the following command should be executed:
$ perl <FND_TOP>/patch/115/bin/txkSetAppsConf.pl -contextfile=<CONTEXT_FILE> \
-configoption=addMS -oacore=testserver.example.com:7205

If Oracle HTTP Server is enabled on the node, restart it as follows:On UNIX:

$ sh <ADMIN_SCRIPTS_HOME>/adapcctl.sh stop
$ sh <ADMIN_SCRIPTS_HOME>/adapcctl.sh start
On Windows:
C:\><ADMIN_SCRIPTS_HOME>\adapcctl.cmd stop
C:\><ADMIN_SCRIPTS_HOME>\adapcctl.cmd start
4.4.2 Removing a managed server
The following steps should be executed in order to delete a managed server from the domain. As in the case of managed server addition, deletion of managed servers should be done on the run file system, with synchronization between the run and the patch file systems subsequently being performed automatically during adop prepare execution or during fs_clone.
Note: Managed server deletion should be done only through the adProvisionEBS.pl script as mentioned in this section. Managed servers should not be deleted from the WebLogic Server Administration Console.
To delete a managed server of a specific service type, perform the following steps on the run file system:

Perform the following steps on the application tier where the managed server resides.
1. If the managed server to be deleted is running, shut it down as follows:On Unix:

$ sh <ADMIN_SCRIPTS_HOME>/admanagedsrvctl.sh stop <MANAGED SERVER NAME>
On Windows:
C:\><ADMIN_SCRIPTS_HOME>\admanagedsrvctl.cmd stop <MANAGED SERVER NAME>
For example, before deleting a managed server ‘oacore_server2’, execute the following command to shut it down.
$ sh <ADMIN_SCRIPTS_HOME>/admanagedsrvctl.sh stop oacore_server2

1. Run the command below on the application tier node where the managed server resides. This will delete the managed server, and also update the respective context variables that contain references to the deleted managed server.

$ perl <AD_TOP>/patch/115/bin/adProvisionEBS.pl \
ebs-delete-managedserver \
-contextfile=<CONTEXT_FILE> -managedsrvname=<MANAGED_SERVER_NAME> \
-servicetype=<SERVICE_TYPE> -logfile=<LOGFILE>
For example, for deleting a managed server ‘oacore_server2’ of type ‘oacore’, execute the following command:
$ perl <AD_TOP>/patch/115/bin/adProvisionEBS.pl \
ebs-delete-managedserver \
-contextfile=<CONTEXT_FILE> -managedsrvname=oacore_server2 \
-servicetype=oacore -logfile=<APPLRGF>/TXK/delMS_oacoreserver2.log

Perform the following steps on all application tier nodes participating in the same cluster as the deleted managed server:
1. Source the run file system.
2. If the deleted managed server is part of the cluster configuration defined on the current node, execute the following command to delete details of the managed server from the OHS configuration files mod_wl_ohs.conf and apps.conf on the current node:

The argument contextfile accepts the complete path to the context file.
The arguments oacore, oafm, forms, formsc4ws, ekanban, accessgate and yms accept a comma-separated list of managed server details in the following format:
<host>.<domain>:<port>
- host, domain and port are the hostname, domain and port of the managed server whose reference is to be deleted.

For example, to remove references of the deleted managed server oacore_server2 with port 7205 on host ‘testserver’ and domain ‘example.com’, the following command should be executed:
$ perl <FND_TOP>/patch/115/bin/txkSetAppsConf.pl -contextfile=<CONTEXT_FILE> \
-configoption=removeMS -oacore=testserver.example.com:7205

If Oracle HTTP Server is enabled on the node, restart it as follows:On UNIX:

$ sh <ADMIN_SCRIPTS_HOME>/adapcctl.sh stop
$ sh <ADMIN_SCRIPTS_HOME>/adapcctl.sh start
On Windows:
C:\><ADMIN_SCRIPTS_HOME>\adapcctl.cmd stop
C:\><ADMIN_SCRIPTS_HOME>\adapcctl.cmd start
Section 5: Updating the Classpath and JVM Arguments of the WebLogic AdminServer
When the WebLogic AdminServer is started, the classpath and JVM arguments are picked up from the values of the context variables s_adminserver_classpath and s_nm_jvm_startup_properties respectively.
In order to update these WebLogic AdminServer properties, perform the following steps on the run file system of the primary node:

Update the respective context variable ( s_adminserver_classpath for updating the AdminServer classpath and s_nm_jvm_startup_properties for updating the AdminServer JVM arguments).
Run AutoConfig on the Application tier.
Bounce the WebLogic AdminServer as follows:On UNIX:

$ sh <ADMIN_SCRIPTS_HOME>/adadminsrvctl.sh stop
$ sh <ADMIN_SCRIPTS_HOME>/adadminsrvctl.sh start
On Windows:
C:\><ADMIN_SCRIPTS_HOME>\adadminsrvctl.cmd stop
C:\><ADMIN_SCRIPTS_HOME>\adadminsrvctl.cmd start
Note: Setting the WebLogic AdminServer classpath or JVM arguments from the WebLogic Administration Console or using WLST will not enforce any changes to these properties as the values will be always picked up from the respective context variables as mentioned above.
Section 6: Known Issues
This section lists any known issues with the AutoConfig-related configuration management of Oracle E-Business Suite Release 12.2 environments.
Issue 1
On a multi-node installation with the Forms Services and Batch Processing Services enabled on separate nodes, OAM fails to update the context variables on the Batch Processing Services node.
Solution:
Check whether the Listener Service is up on the Forms Services node. If the service is down, start the service using one of the following options:

Start the TNS listener service manually using the following command:On UNIX:

$ $INST_TOP/admin/scripts/adalnctl.sh start <TWO_TASK>
On Windows:
C:\>%INST_TOP%\admin\scripts\adalnctl.cmd start <LOCAL>

Enable management of the TNS Listener Service using the adstrtal or adstpall scripts on the Forms Services node.
1. Enable the TNS Listener Service by following the steps mentioned earlier.
2. Stop all the application tier services using adstpall.sh or adstpall.cmd.
3. Start all the application tier services using adstrtal.sh or adstrtal.cmd.

Post Views: 5

Leave a Comment Cancel Reply