Cumulative Patch Certification with Applications

Numbers of questions coming for information about the certification of Cumulative Patches with Applications installation. First of all, it is important to clarify the types of Discoverer solutions to 'Apps certification' :

1. Custom Solution
   - Custom solution is built by customer and is not dependent on any 'Apps certification' ;
   - Custom solution is simply using the Discoverer native functionality to connect to EBS DB.
   
2. (2) BIS Solution
   - BIS is an Oracle pre-built and shipped with EBS solution.
   - This solution comprises of BAs, folders, workbooks, etc.
   - The 'Apps certification' means that BIS Dev team tests all BAs and workbooks with a new Discoverer version against EBS.
   

In any case customers using Discoverer 10.1.2.2 against EBS 11i are still fully supported and all new problems will be handled normally even reported to Development as bugs if needed. Concerning the Cumulative Patches, you can go for any Cum. Patch version higher than Cum.Patch 3 (6155500) (You may want to skip Cum.Patch 5 6472361, which I see is not fully stable).

AS Patch Set 10.1.2.3

Application Server/Developer Suite Patch Set 10.1.2.3.0 is production on Windows and Solaris.

Patch 5983622
PLACEHOLDER BUG FOR AS/DS 10.1.2.3 PATCHSET RELEASE
Release iAS 10.1.2.3
Product Oracle Application Server Products

This is used patching Admin/Desktop on Windows too.

Note Discoverer 10.1.2.3 is not certified with EBS as well as bug fixes into cp4, cp5 and cp6 are not fixed in 10.1.2.3. CP for 10.1.2.3 will include all the missing bug fixes on top of 10.1.2.3.

Connect to Discoverer Plus/Viewer is Very Slow in the Connection Phase

OracleAS Discoverer Plus 10.1.2 installation, is really slow in the connection phase, both from APPS links and Standalone connection. After the insert of the login details in the Connect Box it is showing for approx 20 minutes the following page :

Request Progress

Processing your request
The page you have requested is taking some time to process. Please wait...

The Cause is that the Connect descriptor resolve slowly as it did not contain a valid entry.

Having the following entry in the sqlnet.ora :

NAMES.DIRECTORY_PATH= (LDAP, TNSNAMES, EZCONNECT, ONAMES, HOSTNAME)

will delay the authentication, as it will first try to authenticate the connect descriptor through OID, where it does not exist.

A simple configuration gain is to change the way the client looks up the connect descriptor. This connect descriptor must be translated by Oracle Net into the network protocol location of the database (IP address and port number) and the name of the database service.

There are a variety of methods to store this information, such as in a TNSNAMES.ORA (TNSNAMES) file, Oracle Internet Directory (OID - LDAP), Oracle Names (ONAMES) or using the Host Naming Adapter.

The default connect descriptor lookup path is to first look in the local naming file TNSNAMES.ORA, then to try the well-known Oracle Names servers, and then finally to try the Host Naming Adapter. The parameter that influences this lookup order is NAMES.DIRECTORY_PATH parameter in the SQLNET.ORA file.

-- To implement the solution, Update the sqlnet.ora file in the Discoverer ORACLE_HOME from :

NAMES.DIRECTORY_PATH= (LDAP, TNSNAMES, EZCONNECT, ONAMES, HOSTNAME)

to

NAMES.DIRECTORY_PATH= (TNSNAMES)

if the connect descriptor is configured to be resolved via tnsnames.ora, otherwise order the list with the right connect descriptor which is used first.