Manage Workflow Notification Mailer in Test R11i Instances

Following a clone, be sure to validate the a test email address has been set for the Workflow Notification Mailer. Failing to do so, could result in issues where users receive emails that they may assume are from the production system. This will cause a lot of confusion amoung the users.

The Workflow Test Email address can be set outside of OAM. This is useful for automating the change. Oracle Support ID 459932.1. 'How To Set A Different "Test Email Address" For The Workflow Notification Without Connecting To OAM.' Describes the process. Be sure to run through the process manually in a test system to validate the steps. Add details on performing any such steps to your cloning documentation.

From within OAM you can perform the following steps to change the Test Email Address:

• At the OAM Dashboard, navigate to Workflow Manager.
• At Workflow Manager, select the Service Components link.
• At Service Components page, select the Workflow Notification Mailer link.
• From here, edit the mailer to set the Test Email Address to a valid email address for your organization.

When the steps have been completed, be sure to test the mailer to validate the email has been changed.

You may want to assign each test instance it's own email address. Having all instances send information to one addess will result in confusion if workflow related testing needs to be performed. Also, don't forget to regularly purge the emails from the test address. Failure to remove old emails can result in a large amount of wasted space on your email servers.

Bug 8207550 Not Dropping FA_JOURNAL_INTERIM Tables

If you run the Create Journal Entries request set in 11.5.10.2, you may have some unneeded tables hanging around in your system. The code to drop the FA_JOURNAL_INTERIM table has been inadvertently commented out of FAXCJEB.pls, allowing the tables to remain after they are no longer needed.


ISSUE

BUG 8207550 FA_JOURNALS_INTERIM tables are not dropped after Create Journal Entry.


SYMPTOM

FA_JOURNALS_INTERIM tables remain present in the database after Create Journal Entries run.


SOLUTION

There is no patch currently available to resolve this issue. You may choose to allow the tables to remain in your system, or these tables can be safely removed after the completion of the Create Journal Entries run.


TIP

If you aren't currently doing so, you should consider implementing a check for newly created objects in your database. This can help you identify objects that are not properly cleaned up.


REFERENCES

757666.1, FA_JOURNALS_INTERIM Tables are Not Dropped after Successful Create Journal Entry and Journal Import

732925.1, Journal Import Fails After Depreciation Run. Depreciation Journal Is Unbalanced

Minimum Requirements for 11.5.10 Extended Support

While Premier Support for 11i ends in November 2010, Extended Support will pick up and be available for free until November 2011.

Current bug fixes will continue to be available for older patch levels. However, EBS customers must meet a minimum baseline patch level in order to receive any new bug fixes. The minimum baseline requirement is spelled out in:

883202.1 Minimum Baseline Patch Requirements for Extended Support on Oracle E-Business Suite 11.5.10

Please note that, per the doc, the baseline versions may change in the future and any such changes will be communicated in the document.

Bug 8819967 with JRE Plugin and R11i Oracle Sourcing

If you have migrated from JInitiator to the native SUN JRE Plugin and utlize the Oracle Sourcing module, you will need to apply this fix to your enviornment.

ISSUE
BUG 8819967 JINI 1.3.1.21 is hardcoded into applet

SYMPTOM
You've upgraded to use the SUN JRE Plugin, however, when using Oracle Sourcing, the application attempts to launch the JInitiator.

SOLTUION
Apply Patch 8819967
or
11.5.10 PRC RUP XIII

TIP
If you have not migrated to SUN JRE Plugin, please consider doing this. Note that JInitiator has been desupported.

R11i REFERENCE
290807.1, Deploying Sun JRE (Nativ Plug-in) for Windows Clients in Oracle E-Business Suite 11i

R12 REFERENCE
393931.1, Deploying Sun JRE (Native Plug-in) for Windows Clients in Oracle E-Business Suite Release 12

APPS Schema security changes delivered with HR EOY Phase I patch 8947666 for R11i

As an APPS DBA, there are occurences where an application patch will do things you don't expect. That is why reviewing the readme document and performing regression testing is important.


Some odd behaviour was seen when applying the HR EOY Phase I patch (8947666) for 2009. A customization in place that required the APPS account to access a data dictionary table stopped working after the patch was applied. After a little research the issue was traced to some security changes Oracle bundled with the EOY Phase I patch.

The EOY Phase I patch includes a call to adrevdba.sql in the directory $AD_TOP/patch/115/sql. This script will revoke some grants from the APPS user. The specific commands run are:


revoke dba from apps;

revoke select any dictionary from apps;


These grants are not required for functioning of the application. The grants are being revoked by Oracle to help secure the application. If these grants used by any custom work, they will need to be granted after the patch has been applied. Future patches may also revoke the grants, so they will need to be monitored after patching to validate they still exist.

The custom code using these grants should be reviewed to determine if the grants are neccessary. Changes should be made to the code to work around the requirement for the grants. This will allow for a more secured application.