Thursday, April 9, 2020

ssue:txkGenADOPWrapper.pl INSTE8_APPLY 1 WARNING: [AutoConfig Error Report] The following report lists errors AutoConfig encountered during each phase of its execution. Errors are grouped by directory and phase. The report format is: [APPLY PHASE] AutoConfig could not successfully execute the following scripts: Directory: /u01/applprod/fs2/FMW_Home/webtier/perl/bin/perl -I /u01/applprod/fs2/FMW_Home/webtier/perl/lib/5.10.0 -I /u01/applprod/fs2/FMW_Home/webtier/perl/lib/site_perl/5.10.0 -I /u01/applprod/fs2/EBSapps/appl/au/12.0.0/perl -I /u01/applprod/fs2/FMW_Home/webtier/ohs/mod_perl/lib/site_perl/5.10.0/x86_64-linux-thread-multi /u01/applprod/fs2/inst/apps/PRODDB_epc-apps12-node41v/admin/install txkGenADOPWrapper.pl INSTE8_APPLY 1 AutoConfig is exiting with status 1 Solution: This happens occasionally when old nodes are left in 12.2 tables. Autoconfig Error: ORA-01422: Exact Fetch Returns More Than Requested Number Of Rows (Doc ID 2212698.1) This should be resolved by running: check by bellow query if any misconfiguration node added in fnd_nodes select node_name from fnd_nodes; on DB Tier: execute fnd_conc_clone.setup_clean Autoconfig on DB (adautocfg.sh) Apps Tier: login and source enviorment file Run adautoconfig verify nodes by select node_name from fnd_nodes; Start service (if it is stopped) for patch FS Autoconfig on Patch fs --ignore errors Autoconfig on Run fs --Should complete successfully now

In E-Business suite R12, by default we have forms servlet mode for opening up the forms. If we check the opmnctl for the OC4J forms services, the forms services are listed as shown below.
-bash-2.05b$ ./adopmnctl.sh status
You are running adopmnctl.sh version 120.4
Checking status of OPMN managed processes…
Processes in Instance: mz2st121_rws60050rems.rws60050rems.us.oracle.com
——————-+——————–+———+———
ias-component | process-type | pid | status
——————-+——————–+———+———
OC4J | oafm | N/A | Down
OC4J | forms | 6394 | Alive
OC4J | oacore | 881 | Alive
HTTP_Server | HTTP_Server | 1044 | Alive
ASG | ASG | N/A | Down
In servlet mode a java servlet called the Forms Listener Servlet manages the communication between the Forms Java Client and the OracleAS Forms Services. The Forms Listener Servlet communicates through the HTTP server port and does not need extra ports to handle the communication between the client and the Oracle Applicaiton Server Forms Services.
Although this is the preferred method for accessing the forms, in R12 one can also use socket mode connectivity for accessing the forms. In case of socket mode a separate port is configured for client to connect to the server. The connection is not made through Apache port. It means that in case the Apache services are down the forms services will be still up.
This may be required in the following situations:
  • Customers network topology is multinode and the forms Services are configured on a node different from the node on which Web services(Web Entry Point and Web Applications) are configured.
  • Customers constrained by network bandwidth, or machine resources may consider socket mode as an alternative to improve performance.
  • To reduce network traffic. The servlet mode uses http protocol on each transaction between a client and the Forms Server requiring the exchange of cookies and http headers which increases network traffic.
  • To reduce consumption of resources use by the JVMS needed in servlet mode architecture.
For difference between socket mode of Forms 6i and Forms 10g check metalink node ID 384241.1.
Enabling Forms Socket Mode
Changing forms servlet mode to forms socket mode is very easy. This needs running of just 1 script and bouncing the services.
Follow the below steps for changing from forms servlet mode to forms socket mode. Also note that both these modes cannot co-exits.
1) Stop all services using adstpall.sh present in $ADMIN_SCRIPTS_HOME location.
Note that while stopping this will call adformsctl.sh script for stopping forms services. This is because the current mode is servlet mode.
2) Run the following command to enable Forms Socket Mode:
$FND_TOP/bin/txkrun.pl -script=ChangeFormsMode \
[-contextfile=<CONTEXT_FILE>] \
-mode=socket \
[-port=<Forms port number>] \
-runautoconfig=<No or Yes> \
-appspass=<APPS password>
Example :
$FND_TOP/bin/txkrun.pl -script=ChangeFormsMode \
-contextfile=$INST_TOP/appl/admin/mycontext.xml \
-mode=socket \
-port=9095 \
-runautoconfig=Yes

In this case you can get the forms port number from context file.
Make sure that autoconfig has run successfully and that it has updated the forms launcher in database.
3) start the services using adstrtall.sh present in $ADMIN_SCRIPTS_HOME
Note that this time it will use adformsrvctl.sh script to start the forms. This is the script for starting forms in socket mode.
Executing service control script:
/slot02/appmgr/inst/apps/SCM3R3X3/admin/scripts/adformsrvctl.sh start
script returned:
****************************************************
You are running adformsrvctl.sh version 120.9.12000000.6
Starting FORMS Server in Socket Mode…
adformsrvctl.sh: exiting with status 0
adformsrvctl.sh: check the logfile /slot02/appmgr/inst/apps/SCM3R3X3/logs/ora/10.1.2/forms/socket.log for more information …
You have new mail in /var/spool/mail/appmgr02
.end std out.
.end err out.
After converting to forms socket mode the ICX_FORMS_LAUNCHER will take below form.

<web_protocol>://<web_host>.<web_domain>:<web_port>/OA_HTML/frmservlet
Also adopmnctl.sh will not list the forms process now.
-bash-3.00$ ./adopmnctl.sh status
You are running adopmnctl.sh version 120.4.12000000.3
Checking status of OPMN managed processes…
Processes in Instance: tkr12r3m_rws60001tch.rws60001tch.us.oracle.com
———————————+——————–+———+———
ias-component | process-type | pid | status
———————————+——————–+———+———
OC4JGroup:OC4J | OC4J:oafm | 14533 | Alive
OC4JGroup:OC4J | OC4J:oacore | 13722 | Alive
OC4JGroup:OC4J | OC4J:oacore | 13723 | Alive
HTTP_Server | HTTP_Server | 13405 | Alive
adopmnctl.sh: exiting with status 0

No comments:

Post a Comment

[ERROR]: The value of s_patch_service_name is not set correctly in atleast one of the context files.

[ERROR]: The value of s_patch_service_name is not set correctly in atleast one of the context files. I got the issue below wh...