Friday, September 9, 2011

Forms.ear File Deploying issues...

**********************************************************

Some issues during Deploying forms.ear file during CPU patching in R12.

**********************************************************

Application: 12.1.3

Database : Release 11.2.0.2.0 Production on Fri Sep 9 10:16:46 2011

Activity : 11.2.0.2 UPgrade & 12.1.3 Upgrade.

Description:

Actual issue occured in CPU patching for Oct'10.

Deploy Forms 10.1.2 .ear files on EBSO R12 instance

Script to deploy :

perl $FND_TOP/bin/txkrun.pl -script=CfgOC4JApp -applicationname=forms -runautoconfig=No -oc4jpass=xxxxxxx

*** ALL THE FOLLOWING FILES ARE REQUIRED FOR RESOLVING RUNTIME ERRORS

*** Log File = /ramuG/mtlog/RAMUG_kiranginni01/logs/appl/rgf/TXK/txkCfgOC4JApp_Fri_Sep_9_03_37_07_2011.log

Program : /ramuG/applmgr/1200/fnd/12.0.0/patch/115/bin/txkCfgOC4JApp.pl started @ Fri Sep 9 03:37:07 2011

*** Log File = /ramuG/mtlog/RAMUG_kiranginni01/logs/appl/rgf/TXK/txkCfgOC4JApp_Fri_Sep_9_03_37_07_2011.log

Errors encountered running /ramuG/applmgr/1200/fnd/12.0.0/patch/115/bin/txkCfgOC4JApp.pl

*******FATAL ERROR*******

PROGRAM : /ramuG/applmgr/1200/fnd/12.0.0/patch/115/bin/txkCfgOC4JApp.pl(/ramuG/applmgr/1200/fnd/12.0.0/bin/txkrun.pl)

TIME : Fri Sep 9 03:37:09 2011

FUNCTION: (eval) [ Level 1 ]

ERRORMSG: Invalid OC4J password for : forms

Used OC4J password as welcome and it didn't worked....

Need to follow below steps to get reset to temporary value ( ) and proceed with script execution:

Steps :

a)

Back up the original system-jazn-data.xml file

cp -p $INST_TOP/ora/10.1.3/j2ee/forms/config/system-jazn-data.xml $INST_TOP/ora/10.1.3/j2ee/forms/config/system-jazn-data.xml.ori

b) Change oc4jadmin password in file $INST_TOP/ora/10.1.3/j2ee/forms/config/system-jazn-data.xml for oc4jadmin user in credentials line as below:

old example lines:

OC4J Administrator

{903}AhyuIQ23dQEuEVA0Mv5B65CKXjWcC4/a

new lines:

OC4J Administrator

!welcome

The "Oc4j Instance password" has now become "welcome" with the above change.

c) Post-deployment step:

Reverting the value back to normal:

cp -p $INST_TOP/ora/10.1.3/j2ee/forms/config/system-jazn-data.xml.ori $INST_TOP/ora/10.1.3/j2ee/forms/config/system-jazn-data.xml

Step a ==> Done.

Step b ==> Done.

Deployment step:

perl $FND_TOP/bin/txkrun.pl -script=CfgOC4JApp -applicationname=forms -runautoconfig=No -oc4jpass=

Here : = welcome

Terminal O/p as follows :

Issue 2 : >>

*** ALL THE FOLLOWING FILES ARE REQUIRED FOR RESOLVING RUNTIME ERRORS

*** Log File = /ramuG/mtlog/RAMUG_kiranginni01/logs/appl/rgf/TXK/txkCfgOC4JApp_Fri_Sep_9_04_58_37_2011.log

Program : /ramuG/applmgr/1200/fnd/12.0.0/patch/115/bin/txkCfgOC4JApp.pl started @ Fri Sep 9 04:58:37 2011

*** Log File = /ramuG/mtlog/RAMUG_kiranginni01/logs/appl/rgf/TXK/txkCfgOC4JApp_Fri_Sep_9_04_58_37_2011.log

*****************************************************

Required values for starting OC4J instance "forms":

====================================================

s_formsstatus = enabled

s_forms_nprocs = 1 (value should be greater than 0)

Existing values from the context file:

======================================

s_formsstatus = enabled

s_forms_nprocs = 2

----------------------------------------------

*** Values for context variables are VALID ***

----------------------------------------------

*****************************************************

Stopping all OPMN processes.

OPMN stopped.

Errors encountered running /ramuG/applmgr/1200/fnd/12.0.0/patch/115/bin/txkCfgOC4JApp.pl

*******FATAL ERROR*******

PROGRAM : /ramuG/applmgr/1200/fnd/12.0.0/patch/115/bin/txkCfgOC4JApp.pl(/ramuG/applmgr/1200/fnd/12.0.0/bin/txkrun.pl)

TIME : Fri Sep 9 04:58:40 2011

FUNCTION: TXK::Process::run [ Level 3 ]

MESSAGES:

Command error: = 38400, = /ramuG/product/1013/opmn/bin/opmnctl startproc instancename=forms

STACK TRACE

TXK::Error::abort('TXK::Error','HASH(0x9c242bc)') called at /ramuG/applmgr/1200/au/12.0.0/perl/TXK/Common.pm line 299

TXK::Common::doError('TXK::Process=HASH(0xa4d4a70)','Command error: = 38400, = /ramuG/product/1013...','undef') called at /ramuG/applmgr/1200/au/12.0.0/perl/TXK/Common.pm line 314

TXK::Common::setError('TXK::Process=HASH(0xa4d4a70)','Command error: = 38400, = /ramuG/product/1013...') called at /ramuG/applmgr/1200/au/12.0.0/perl/TXK/Process.pm line 449

TXK::Process::run('TXK::Process=HASH(0xa4d4a70)','HASH(0xa387b30)') called at /ramuG/applmgr/1200/fnd/12.0.0/patch/115/bin/txkCfgOC4JApp.pl line 1587

TXK::RunScript::execOPMNControl('HASH(0xa5715e0)') called at /ramuG/applmgr/1200/fnd/12.0.0/patch/115/bin/txkCfgOC4JApp.pl line 606

require /ramuG/applmgr/1200/fnd/12.0.0/patch/115/bin/txkCfgOC4JApp.pl called at /ramuG/applmgr/1200/au/12.0.0/perl/TXK/RunScript.pm line 105

TXK::RunScript::require('TXK::RunScript','/ramuG/applmgr/1200/fnd/12.0.0/patch/115/bin/txkCfgOC4JApp.pl') called at /ramuG/applmgr/1200/au/12.0.0/perl/TXK/Script.pm line 177

eval {...} called at /ramuG/applmgr/1200/au/12.0.0/perl/TXK/Script.pm line 177

TXK::Script::run('TXK::Script=HASH(0xa3ad6d8)','/ramuG/mtlog/RAMUG_kiranginni01/logs/appl/rgf/TXK','/ramuG/applmgr/1200/fnd/12.0.0/patch/115/bin/txkCfgOC4JApp.pl') called at /ramuG/applmgr/1200/fnd/12.0.0/bin/txkrun.pl line 174

$

Getting this Error

Upon Investigation found Note :

$FND_TOP/bin/txkrun.pl -script=DeployForms-c4ws Fails with Fatal Error forms-c4ws Already Exists (Doc ID 1165653.1)

Implementing the solution:

1. To get the /txkDeployForms-c4ws.pl to deploy, rename the file that already exists and run again.

Move the current deployment:

Example:

mv /devapps2/appldev/DPHUB/apps/tech_st/10.1.3/j2ee/forms-c4ws /devapps2/appldev/DPHUB/apps/tech_st/10.1.3/j2ee/forms-c4ws.ori

In our case :

$INST_TOP/ora/10.1.3/j2ee/forms-c4ws is moved and ran below script again :

perl $FND_TOP/bin/txkrun.pl -script=CfgOC4JApp -applicationname=forms -runautoconfig=No -oc4jpass=welcome

*****************************************************

Required values for starting OC4J instance "forms":

====================================================

s_formsstatus = enabled

s_forms_nprocs = 1 (value should be greater than 0)

Existing values from the context file:

======================================

s_formsstatus = enabled

s_forms_nprocs = 2

----------------------------------------------

*** Values for context variables are VALID ***

----------------------------------------------

*****************************************************

Stopping all OPMN processes.

OPMN stopped.

OPMN started.

Deplolying Application : "forms" onto OC4J instance: "forms"

Application deployed successfully.

Stopping and starting OC4J instances.

Started OC4J instances.

Binding webApp : "forms" with webmodule : "formsweb" for OC4J instance: "forms"

Web application bound successfully.

Stopping OPMN.

OPMN stopped.

Program : /ramuG/applmgr/1200/fnd/12.0.0/patch/115/bin/txkCfgOC4JApp.pl completed @ Fri Sep 9 05:06:48 2011

End of /ramuG/applmgr/1200/fnd/12.0.0/patch/115/bin/txkCfgOC4JApp.pl : No Errors encountered

Now, Script successfully deployed…

Now reverting the copied script back to get original Password (This is must for security Concerns)....

c) Post-deployment step: ==> Done.

Reverting the value back to normal:

cp -p $INST_TOP/ora/10.1.3/j2ee/forms/config/system-jazn-data.xml.ori $INST_TOP/ora/10.1.3/j2ee/forms/config/system-jazn-data.xml

Thread 2:- >>>

==============

In some cases we face issue 3 if "s_formsstatus" is in DISABLED status in $CONTEXT_FILE.

Fix:

a) Take a backup of your $CONTEXT_FILE

b) Modify s_formsstatus to ENABLED

c) Run check Autoconfig : adchkcfg.sh and resolve any differences to preserve your customizations

d) Run Autoconfig to get it populated in the scripts.

e) Now run Deployment script

f) Revert s_formsstatus to DISABLED again (Original value)

g) Run Autoconfig to get it populated in the Scripts.

Thread 3:- >>

================

During check config we had issue that this is hanging. Script hanged after generating the differences.

Solution: you can ignore by pressing CTRL + C and utilize the generated differences to preserve customizations.

Note : once all the above procedure is done and autoconfig is successfully completed, you can see that this bug is rectified either. You can now verify that by running adchkcfg.sh again and see it completing successfully without hanging this time.

Thanks

Kiran Ginni

No comments:

Post a Comment