R12.2 DMZ Url Not Working: Appsdba Oracle Dba R12.2 No Comments
R12.2 DMZ Url Not Working: Appsdba Oracle Dba R12.2 No Comments
R12.2 DMZ Url Not Working: Appsdba Oracle Dba R12.2 No Comments
Related Posts
2. The configuration of the E-Business Suite environment for DMZ requires these profile options
hierarchy type to be set to SERVRESP.
Login to the run file system of the primary application tier node and execute txkChangeProfH.sql
script as shown below.
[apdbatst@apdbasrv02 ~]$ sqlplus apps/<pwd>
SQL> @$FND_TOP/patch/115/sql/txkChangeProfH.sql SERVRESP
Changing the hierarchy type for the Profile APPS_WEB_AGENT
Profile APPS_WEB_AGENT hierarchy type has been
successfully changed to SERVRESP
Changing the hierarchy type for the Profile APPS_SERVLET_AGENT
Profile APPS_SERVLET_AGENT hierarchy type has been
successfully changed to SERVRESP
Changing the hierarchy type for the Profile APPS_JSP_AGENT
Profile APPS_JSP_AGENT hierarchy type has been
successfully changed to SERVRESP
Changing the hierarchy type for the Profile APPS_FRAMEWORK_AGENT
Profile APPS_FRAMEWORK_AGENT hierarchy type has been
successfully changed to SERVRESP
Changing the hierarchy type for the Profile ICX_FORMS_LAUNCHER
Profile ICX_FORMS_LAUNCHER hierarchy type has been
successfully changed to SERVRESP
Changing the hierarchy type for the Profile ICX_DISCOVERER_LAUNCHER
Profile ICX_DISCOVERER_LAUNCHER hierarchy type has been
successfully changed to SERVRESP
Changing the hierarchy type for the Profile ICX_DISCOVERER_VIEWER_LAUNCHER
Profile ICX_DISCOVERER_VIEWER_LAUNCHER hierarchy type has been
successfully changed to SERVRESP
Changing the hierarchy type for the Profile HELP_WEB_AGENT
Profile HELP_WEB_AGENT hierarchy type has been
successfully changed to SERVRESP
Changing the hierarchy type for the Profile APPS_PORTAL
Profile APPS_PORTAL hierarchy type has been
successfully changed to SERVRESP
Changing the hierarchy type for the Profile CZ_UIMGR_URL
Profile CZ_UIMGR_URL hierarchy type has been
successfully changed to SERVRESP
Changing the hierarchy type for the Profile QP_PRICING_ENGINE_URL
Profile QP_PRICING_ENGINE_URL hierarchy type has been
successfully changed to SERVRESP
Changing the hierarchy type for the Profile TCF:HOST
Profile TCF:HOST hierarchy type has been
successfully changed to SERVRESP
3. After the txkChangeProfH.sql script is executed successfully,
a. Shutdown the applications on all nodes.
b. Modify the HTTP port in the $CONTEXT_FILE of the external node to 8001 (port# varies based
on environments) as below on both patch and run FS. Example as below:
<httplistenparameter oa_var="s_http_listen_parameter">8001</httplistenparameter>
<web_port oa_var="s_webport" oa_type="PORT" base="8000" step="1" range="-1" label="Web
Listener Port">8001</web_port>
c. Execute autoconfig on all nodes (sourcing run FS) to set the profile option values at server level.
d. Startup the Application services in the primary application tier node alone to perform the below
operations.
4. Update Node Trust Level and Responsibility trust level. Login as SYSADMIN user from the
Primary (internal) application and set the node ad responsibility trust levels.
a. Navigation: System Administrator -> Profile -> System. Query for Node%Trust%Level for Site and
Server level.
Choose the DMZ (secondary/external) application tier server and set the profile values as “External”
as shown below. The Site level should be left as is to “Normal”
b. Navigation: System Administrator -> Profile -> System. Query for Resp%Trust%Level for Site and
Responsibility level.
Choose the responsibility “apdbak Time Entry-Non-Exempt” and set the profile values as “External”
as shown below. The Site level should be left as is to “Normal”.
Repeat the same step for all responsibilities that would be exposed to DMZ.
7. Verify the SSL setup is identical in the DMZ node to that of its Primary application tier.
8. Validate logins of both the internal and external applications and ensure the responsibilities.
a. Internal Login Home Page for SYSADMIN user.
Symptoms:
For some users, login to internal node gets redirected to external node.
Cause:
In
$IAS_ORACLE_HOME/instances/EBS_web_SID_OHS1/config/OHS/EBS_web_SID/mod_wl_ohs.conf
and apps.conf files, the cluster includes the external node external.domain.com.
Solution:
To fix this issue, make the following changes to the run file system of the internal node:
Remove any reference to external.domain.com from both the files i.e. mod_wl_ohs.conf
and apps.conf.
Node
1:/u02/oracle/EBSPROD/fs1/FMW_Home/webtier/instances/EBS_web_EBSPROD_OHS1/config/OHS/
EBS_web_EBSPROD
Node
2:/u02/oracle/EBSPROD/fs1/FMW_Home/webtier/instances/EBS_web_EBSPROD_OHS3/config/OHS/
EBS_web_EBSPROD
DMZ
Node:/u02/oracle/EBSPROD/fs2/FMW_Home/webtier/instances/EBS_web_EBSPROD_OHS2/config/
OHS/EBS_web_EBSPROD
In this case, Node 2 has entries of the external node.
Take backup of the existing files.
1. Modify
$IAS_ORACLE_HOME/instances/EBS_web_SID_OHS1/config/OHS/EBS_web_SID/mod
_wl_ohs.conf
Remove any reference to external.domain.com.
Change:
WebLogicCluster
erpdmz01.dbaarena.com:7204,erpapp01.dbaarena.com:7204,erpapp02.dbaarena.com:72
04
To:
WebLogicCluster erpapp01.dbaarena.com:7204,erpapp02.dbaarena.com:7204
[applprod@erpapp02 EBS_web_EBSPROD]$ diff mod_wl_ohs.conf mod_wl_ohs.conf_BKP
33c33
WebLogicCluster erpapp01.dbaarena.com:7204,erpapp02.dbaarena.com:7204 --- > WebLogicCluster
erpdmz01.dbaarena.com:7204,erpapp01.dbaarena.com:7204,erpapp02.dbaarena.com:7204
39c39
WebLogicCluster erpapp02.dbaarena.com:7404,erpapp01.dbaarena.com:7404 --- > WebLogicCluster
erpapp02.dbaarena.com:7404,erpapp01.dbaarena.com:7404,erpdmz01.dbaarena.com:7404
45c45
WebLogicCluster erpapp02.dbaarena.com:7604,erpapp01.dbaarena.com:7604 --- > WebLogicCluster
erpapp02.dbaarena.com:7604,erpdmz01.dbaarena.com:7604,erpapp01.dbaarena.com:7604
51c51
WebLogicCluster erpapp02.dbaarena.com:7804,erpapp01.dbaarena.com:7804 --- > WebLogicCluster
erpapp02.dbaarena.com:7804,erpdmz01.dbaarena.com:7804,erpapp01.dbaarena.com:7804
[applprod@erpapp02 EBS_web_EBSPROD]$
To:
BalancerMember erpapp01.dbaarena.com:7204
BalancerMember erpapp02.dbaarena.com:7204
)))))))))))))))))))))))))))))((((((((((((((((((((((((((((
perl $AD_TOP/patch/115/bin/adProvisionEBS.pl \
ebs-delete-managedserver \
-
contextfile=/oracle/product/ebs/fs1/inst/apps/TEST_muthu/appl/admin/TE
ST_muthu.xml \
-managedsrvname=forms_server1 \
-servicetype=forms \
-logfile=/tmp/forms_server1_remove.log
perl $AD_TOP/patch/115/bin/adProvisionEBS.pl \
ebs-delete-managedserver \
-
contextfile=/oracle/product/ebs/fs1/inst/apps/TEST_muthu/appl/admin/TE
ST_muthu.xml \
-managedsrvname=oafm_server1 \
-servicetype=oafm \
-logfile=/tmp/oafm_server1_remove.log
perl $AD_TOP/patch/115/bin/adProvisionEBS.pl \
ebs-delete-managedserver \
-
contextfile=/oracle/product/ebs/fs1/inst/apps/TEST_muthu/appl/admin/TE
ST_muthu.xml \
-managedsrvname=forms-c4ws_server1 \
-servicetype=forms-c4ws \
-logfile=/tmp/forms-c4ws_server1_remove.log
perl $AD_TOP/patch/115/bin/adProvisionEBS.pl \
ebs-create-managedserver
-contextfile=/oracle/product/ebs/fs1/inst/apps/TEST_muthu/appl/admin/T
EST_muthu.xml \
-managedsrvname=oacore_server1 -servicetype=oacore \
-managedsrvport=7206 -logfile=/tmp/forms_server1_add.log
perl $AD_TOP/patch/115/bin/adProvisionEBS.pl \
ebs-create-managedserver
-contextfile=/oracle/product/ebs/fs1/inst/apps/TEST_muthu/appl/admin/T
EST_muthu.xml \
-managedsrvname=forms_server1 -servicetype=forms \
-managedsrvport=7406 -logfile=/tmp/forms_server1_add.log
perl $AD_TOP/patch/115/bin/adProvisionEBS.pl \
ebs-create-managedserver
-contextfile=/oracle/product/ebs/fs1/inst/apps/TEST_muthu/appl/admin/T
EST_muthu.xml \
-managedsrvname=oafm_server1 -servicetype=oafm \
-managedsrvport=7606 -logfile=/tmp/oafm_server1_add.log
perl $AD_TOP/patch/115/bin/adProvisionEBS.pl \
ebs-create-managedserver
-contextfile=/oracle/product/ebs/fs1/inst/apps/TEST_muthu/appl/admin/T
EST_muthu.xml \
-managedsrvname=forms-c4ws_server1 -servicetype=forms-c4ws \
-managedsrvport=7806 -logfile=/tmp/forms-c4ws_server1_add.log
Finally mod_wl_ohs.conf configuration file generate step
perl $FND_TOP/patch/115/bin/txkSetAppsConf.pl \
-ctxfile=$CONTEXT_FILE -outfile=/tmp/apachesync.log
&&&&&&&&&&&&&&&&&&&&&&
Now::
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>.
4) Now let’s add oacore here, you need to choose port no. carefully. So that it should not
conflict the existing oacore_server1 of run file system and oacore_server1 of patch file
system (Since we have only 1 oa core in our existing server, otherwise you need to check
the all oacore_server port from both files system)
run file system :::: HERE default port for oacore_server1 was 7201 and we couldn’t take
7202 because patch file oacore_server1 has value 7202 (See this line in context_file of
patch file system <oacore_server_ports
oa_var="s_oacore_server_ports">oacore_server1:7207</oacore_server_ports>)
Adding oacore_server2:
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
perl $FND_TOP/patch/115/bin/txkSetAppsConf.pl -contextfile=$CONTEXT_FILE
-configoption=addMS -oacore=ebsapp.company.com:7203
Adding oacore_server3:
perl $AD_TOP/patch/115/bin/adProvisionEBS.pl ebs-create-managedserver
-contextfile=$CONTEXT_FILE -managedsrvname=oacore_server3 -servicetype=oacore
-managedsrvport=7204 -logfile=$APPLRGF/TXK/addMS_oacoreserver3.log
Adding oacore_server4:
perl $AD_TOP/patch/115/bin/adProvisionEBS.pl ebs-create-managedserver
-contextfile=$CONTEXT_FILE -managedsrvname=oacore_server4 -servicetype=oacore
-managedsrvport=7205 -logfile=$APPLRGF/TXK/addMS_oacoreserver4.log
Adding oacore_server5
perl $AD_TOP/patch/115/bin/adProvisionEBS.pl ebs-create-managedserver
-contextfile=$CONTEXT_FILE -managedsrvname=oacore_server5 -servicetype=oacore
-managedsrvport=7206 -logfile=$APPLRGF/TXK/addMS_oacoreserver5.log
Adding the same no. of oacore in Patch file system with different port (you must start
the adadmin server in patch file system, later you can stop all in patch file system)::
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>........
Adding oacore_server 2
perl $AD_TOP/patch/115/bin/adProvisionEBS.pl ebs-create-managedserver
-contextfile=$CONTEXT_FILE -managedsrvname=oacore_server2 -servicetype=oacore
-managedsrvport=7207 -logfile=$APPLRGF/TXK/addMS_oacoreserver2.log
Adding oacore_server3
perl $AD_TOP/patch/115/bin/adProvisionEBS.pl ebs-create-managedserver
-contextfile=$CONTEXT_FILE -managedsrvname=oacore_server3 -servicetype=oacore
-managedsrvport=7208 -logfile=$APPLRGF/TXK/addMS_oacoreserver3.log
Adding oacore_server5
perl $AD_TOP/patch/115/bin/adProvisionEBS.pl ebs-create-managedserver
-contextfile=$CONTEXT_FILE -managedsrvname=oacore_server5 -servicetype=oacore
-managedsrvport=7210 -logfile=$APPLRGF/TXK/addMS_oacoreserver5.log
4> Run autoconfig
5> Start application
Adding Managed Server in Oracle EBS R12.2
when i was working on R12.2 environment, i was suppose to increase the JVM(add the manage
server in R12.2) for the oacore to sustain the load (Client Request)
The procedure to increase JVM was quite simple in R12.1 Releases. 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).So we
just need to increase the numprocs in opmn.xml and start the services or run autoconfig with
increase numprocs in Context file.
It is quite different in R12.2.X as OC4J is replaced with Oracle Weblogic Server in Oracle E-
Business Suite Release 12.2, these services are now deployed as applications on individual
managed servers.
Only part of the configuration of these applications and managed servers is still managed via
AutoConfig.Rest of things need to done quite different
In the below,I would be explaining what I learned from that experience and How to add the
manage server in R12.2. I will particularly taking the example of oacore
How to add the manage server in R12.2
1. 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.
2. 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> \
‘oacore_server2’ of type ‘oacore’ with port 9705, run the following command:
$ perl <AD_TOP>/patch/115/bin/adProvisionEBS.pl \
ebs-create-managedserver -contextfile=<CONTEXT_FILE> \
-managedsrvname=oacore_server2 -servicetype=oacore \
-managedsrvport=9705 -logfile=<APPLRGF>/TXK/addMS_oacoreserver2.log
$ 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, if the managed server oacore_server2 has been added on host ‘myserver’ and domain ‘go.com’ with
)))))))))))))))))))))))))))))))))))))))))
253 Views
Tags: add node
Content tagged with add node
, addms
, txksetappsconf.pl
, app tier
No ratings
(0 ratings)
Correct Answer1. Re: Adding app node txkSetAppsConf.pl returns configoption=addMS is not valid