6
Oracle Ultra Search

This chapter provides information about issues associated with Oracle Ultra Search. Oracle Ultra Search is a high-level search component supplied with the Oracle Collaboration Suite that you can use to search across other Oracle Collaboration Suite components, corporate Web servers, databases, mail servers, file servers, and Oracle9iAS Portal instances. It uses information you provide to crawl through the various disparate repositories of information in your company searching for documents according to your search criteria. Oracle Ultra Search searches over 150 proprietary document types.

See Also: Oracle Ultra Search User's Guide

This chapter includes the following sections:

• What's New in Ultra Search?
• Known Bugs

6.1 What's New in Ultra Search?

The following sections describe new features of Ultra Search.

6.1.1 Ultra Search Welcome Page

The Ultra Search welcome page is now at the following location:

http://host:port/ultrasearch/welcome/

In previous releases, it was at the following location:

http://host:port/ultrasearch/

6.1.2 Default Ultra Search Instance

The Ultra Search installer creates a default out of the box Ultra Search instance based on the default Ultra Search test user, so users can test Ultra Search functionality based on the default instance after installation.

The default instance name is WK_INST. It is created based on the database user WK_TEST. In other words, WK_TEST is the instance administrator for WK_INST. The default user password is WK_TEST.

For security purposes, WK_TEST is locked after the installation. You must login to the database as DBA role, unlock the user, then change the password. (The password expires after the installation.) Make sure to update the cached schema password using the administration tool Edit Instance page after you change the password in the database.

The default instance is also used by the Ultra Search sample application. You must update the data-sources.xml file, as described in the "Configuring the Middle Tier Component" section of the Oracle Ultra Search User's Guide.

6.1.3 Document Relevancy Boosting Limitations

You can override the search results and influence the order that documents are ranked in the query result list with document relevancy boosting. This can promote important documents to higher scores and make them easier to find.

Relevancy boosting has the following limitations:

• Comparison of the user's query against the boosted queries uses exact string match. This means that the comparison is case-sensitive and space-aware. Therefore, a document with a boosted score for "Ultra Search" is not boosted when user enters "ultrasearch".
• Relevancy boosting requires that the query application pass in the search term in the Query API getResult() method call. The sample applications are designed to pass the basic search terms as the boost term. Advanced search criteria based on search attributes are ignored.

6.1.4 Translations for Complete Sample Query Application

The Ultra Search Complete Sample Query Application (search.jsp) is translated into many languages. Oracle Collaboration Suite Release 1 supported 28 languages. However, to maintain consistency with other applications in Oracle Collaboration Suite Release 2, Ultra Search will support only the official languages available in Oracle Collaboration Suite Release 2.

Therefore, the languages that were originally supported in Oracle Collaboration Suite Release 1 will now be overridden with English. These languages are represented by the following locale codes:

• ar
• ca
• cs
• da
• el
• fi
• hu
• iw
• nl
• no
• pl
• ro
• ru
• sk
• sv
• th
• tr

Data entered through the administration tool for the above languages (such as data group display names, attribute display names, and so on) will not be overridden. Therefore, if you use the search.jsp application in one of the above languages, then strings used by the application will appear in English, but user data will appear as entered by the user.

6.1.5 Dynamic Page Indexing Control

For Web data sources, there is a new option to index or not index dynamic pages. The default value is Yes, so dynamic URLs are crawled and indexed.

For data sources already crawled with this option, setting Index Dynamic Page to No and recrawling the data source removes all dynamic URLs from the index.

Some dynamic pages appear as multiple search hits for the same page, and you might not want them all indexed. Other dynamic pages are each different and need to be indexed. You must distinguish between these two kinds of dynamic pages. In general, dynamic pages that only change in menu expansion without affecting its contents should not be indexed. Consider the following three URLs:

http://itweb.oraclecorp.com/aboutit/network/npe/standards/naming_convention.html

http://itweb.oraclecorp.com/aboutit/network/npe/standards/naming_
convention.html?nsdnv=14z1

http://itweb.oraclecorp.com/aboutit/network/npe/standards/naming_
convention.html?nsdnv=14

The question mark ('?') in the URL indicates that the rest of the strings are input parameters. The duplicate hits are essentially the same page with different side menu expansion. Ideally, the same query should yield only one hit:

http://itweb.oraclecorp.com/aboutit/network/npe/standards/naming_convention.html

Dynamic page index control applies to the whole data source. So, if a Web site has both kinds of dynamic pages, then you need to define them separately as two data sources in order to control the indexing of those dynamic pages.

6.1.6 Cookie Support

If you register authentication information for a data source, then the Ultra Search administration tool automatically turns on cookie support. You can override this and turn cookies support off.

6.1.7 Crawler Cache Deletion Control

During crawling, documents are stored in the cache directory. Every time the preset size is reached, crawling stops and indexing starts. In previous releases, the cache file was always deleted when indexing was done. You can now specify not to delete the cache file when indexing is done. This option applies to all data sources. The default is to delete the cache file after indexing.

6.1.8 Set the Environment to Use the INSO Filter

The Ultra Search crawler uses the Oracle Text INSO filter ctxhx, which requires that your shared library path environment variable contain the
$ORACLE_HOME/ctx/lib path. Without that, filtering fails for any binary document.

At installation, the Oracle Installer automatically sets the variable to include $ORACLE_HOME/ctx/lib. However, if, after the installation, you restart the database, you must manually set your shared library path environment variable to include $ORACLE_HOME/ctx/lib before starting the Oracle process. You must restart the database to pick up the new value for filtering to work.

For example, on AIX set the LIBPATH environment variable to include
$ORACLE_HOME/ctx/lib.

6.2 Known Bugs

The following table describes the known bugs for Ultra Search for this release.

Table 6-1 Ultra Search Known Bugs

Bug Number	Description
3008044	The LIBPATH environment variable is not picked up during installation. The $ORACLE_HOME/ctx/lib file is not added to the library path environment variable during installation when the Oracle database (Infrastructure Metadata Repository) is started. After the installation, when you run the Ultra Search crawler, the following error message is displayed in the crawler log file: Filter process error: ld.so.1: /private/ias/lbalacha/M8/ctx/bin/ctxhx: fatal : libsc_lo.so: open failed: No such file or directory WKG-30065: http://dlsun1710:7777/dataSet6/simple.pdf: filtering failed Workaround: To correct the problem, restart the database (Infrastructure Metadata Repository) and make sure that $ORACLE_HOME/ctx/lib is included in the library path environment variable for the session in which you are starting the database.
2881313	Error received registering Ultra Search portlet. http://middle_tier:port/pls/portal navigating through: builder -> navigator -> providers -> Oracle9iAS Providers The error message is: Error: Error accessing remote provider group server: http://middle_tier:port/jpdk/soaprouter (WWC-43733) To correct the problem, update the following file: $ORACLE_HOME/j2ee/OC4J_Portal/applications/jpdk/jpdk/WEB_INF/services.xml Change the value of option key=FileProviderGroupMgr.dir to specify the full path of the directory, not using the ORACLE_HOME environment variable.