Oracle E-Business Suite Blog

The storage of Guest user information is moved from a profile option (GUEST_USER_PWD) to the vault (for security purpose), all the product teams should be aware of this change and they need to modify their code appropriately to refer this new storage to get GUEST user information.

There is no functional impact with these changes as all the ATG code that is referring GUEST_USER_PWD to read guest user information needs to be changed to call FND's new api to fetch the information from vault.

-- Verify the Applications Version
  select fnd_release.major_version from dual;

Example Answer : 12

  select fnd_release.minor_version from dual;

Example Answer : 1

-- Verify the profile option "Guest User Password" no longer exists
  select 1 from fnd_profile_options where
  profile_option_name='GUEST_USER_PWD';

Example Answer : no rows

-- Validate the GUEST user login using FND APIs
  select fnd_web_sec.validate_login('GUEST','ORACLE') from dual;

Example Answer : Y

-- Verify the GUEST user login from the VAULT
  select fnd_vault.get('FND', 'GUEST_USER_PWD') from dual;

Example Answer : GUEST/ORACLE

-- Verify the afdelgstusrpwd.sql file version (used to delete the old profile)
  select f.FILE_ID, f.APP_SHORT_NAME "TOP", f.SUBDIR, f.FILENAME,
  v.VERSION, v.LAST_UPDATE_DATE
  from ad_files f, ad_file_versions v 
  where f.FILE_ID=v.FILE_ID
  and f.FILENAME = 'afdelgstusrpwd.sql'
  order by 6 desc

Example Answer : FND patch/115/sql/afdelgstusrpwd.sql 120.1

In R12.1, FND now provides an API to get the guest user information (username/password) from the vault called : 
FND_WEB_SEC.GET_GUEST_USERNAME_PWD
All the product code that was earlier calling FND_PROFILE.VALUE(‘GUEST_USER_PWD') to read guest user information from profile store must now call FND's new api (FND_WEB_SEC.GET_GUEST_USERNAME_PWD) to get the information.
Similarly the java code that was earlier using profile store to get guest user information must now either write a wrapper over the FND API :  
   FND_WEB_SEC. GET_GUEST_USERNAME_PWD 
or
   Guest.getInstance().getUser() and Guest.getInstance().getPwd
where Guest is FND's class : oracle.apps.fnd.common.Guest.

Reference  - Metalink Note # 788979.1

Comment (1)

The 2nd Round of upgrade to R12.1.1 begins today

Comment (0)

Recently, I was following Metalink note # 556540.1 to Enable SOA Gateway for R12.1 e-business suite. The instance on which I was trying was upgraded from 12.0.4 to R12.1.1.

While performing the step for deploying the Oracle Application Server Adapter using "txkrun.pl -script=CfgOC4JApp", it was initially failing for non-existence of AppsSOAAdapter directory under the $IAS_ORACLE_HOME. After manually creating this directory, we re-tried deploying the Application server adapter, but it failed on the step for undeploying the AppsSOAAdapter with an error "Connector AppsSOAAdapter does not exist!" On checking with support, it appears that the deployment of AppsSOAAdapter was supposed to be part of the R12.1 Maintenance pack. However, support confirmed this issue as reproducible at their end, and a Bug # 8564603 has been opened with development.

The deployment of Application Server adapter completed successfully on a 12.1 Vision instance, though. The AppsSOAAdapter deployment seems to have been included in the RapidInstall.

Support has opened a bug # 8564603 and it is still waiting on development.

 Bug was updated. The fix provided below resolved this issue.

1:- Please log a telnet session into all of your web tiers, set the application envi
ronment, run the commands below and upload the output

cd $APPL_TOP
. ./<SID_SERVER>.env
cd $ORA_CONFIG_HOME/10.1.3/
. ./<SID_SERVER>.env

2:- In the same session

a:- edit the "/kbace3/ktplr12/inst/apps/KTPLR12_trishul/ora/10.1.3/j2ee/oafm/config/oc4j-connectors.xml" file and DELETE the section below

<!-- Connector for SOA Provider - BEGIN -->
<connector name="AppsSOAAdapter" path="AppsSOAAdapter.rar">
</connector>
<!-- Connector for SOA Provider - END -->

b:- Delete or Rename the "/kbace3/ktplr12/apps/tech_st/10.1.3/j2ee/oafm/connectors/AppsSOAAdapter" directory

c:- Delete or Rename the "/kbace3/ktplr12/inst/apps/KTPLR12_trishul/ora/10.1.3/j2ee/oafm/application-deployments
/default/AppsSOAAdapter/oc4j-ra.xml" directory

3:- Open a new telnet session and run the commands below

cd $APPL_TOP
. ./<SID_SERVER>.env
$FND_TOP/bin/txkrun.pl -script=CfgOC4JApp

 

Comment (1)

Starting with the 10g AS upgrade from 10.1.3 to 10.1.3.4, we were faced with issues running the installer from the 10.1.3.4 patchset.  The OPMN processes were failing to start. We had to manually source the environment file under $IAS_ORACLE_HOME and start the opmn manually from another session, before the installer could proceed further.

Another issue with the 10.1.3.4 installer was that, it was failing with a runtime exception when trying to copy files. The installer logs indicated that it was looking for JRE location from the context.xml file within the oraInventory. In our case, the oraInventory directory was the same as Global inventory shared by Rdbms_home, forms home and iAS home. We set the oraInventory to point to the local inventory under $IAS_ORACLE_HOME. As instance chosen for upgrade was a clone copy from production, we had to modify the references from production to target instance, on all the context.xml files under the newly pointed oraInventory. There after, the installer could pickup the right JRE path from the context.xml file, and proceed with the installation.

While in 11i, oracle provided the script OUIsetup.pl for registering an oracle_home with the oraInventory, in the case of R12 oracle provides ouicli.pl which is located under $ORACLE_HOME/appsutil/clone to register an ORACLE_HOME with the central inventory. However, in our case while using this script against the local inventory, it blew away all the files. We had to restore the local inventory, and manually modify references in the context.xml file.

Comment (0)

While starting of with upgrade to Rel 12.1.1, the metalink note # 752619.1 indicated the upgrade of 10g AS from 10.1.3 to 10.1.3.4 as one of the primary step, even before the JDK upgrade. On a same note, metalink note # 454811.1 which provides the steps for upgrading the 10g AS from 10.1.3 to 10.1.3.4, it is again mentioned that the JDK could be upgraded subsequent to the 10g AS upgrade, though the recommended approach could be to upgrade the JDK prior to the 10g AS upgrade.

In reality, when checking with support on the sequence of steps, we came to know that the 10g AS (10.1.3.4) installer uses the JDK 1.6. So, it makes sense to first upgrade the JDK to 1.6, followed by the 10g AS (10.1.3.4) upgrade.

Comment (1)