TROUBLESHOOTING VERITY

This document is intended to assist with Troubleshooting Verity a 3 party integrated solution delivered with PeopleSoft PeopleTools for building and searching indexes. Please notify us if any mistakes are made, factual or editorial. This is a living document and has already experienced changes, so any version you have is potentially out of date unless you received it from Global Customer Support.
5/16/2010
rd

VERITY A 3rd PARTY INTEGRATED SOLUTION

Verity is a search engine delivered by PeopleTools to build an index collection and to search on that collection. Index builds are delivered with all PeopleSoft applications including: 1. CRM 2. HCM 3. EPRO 4. FIN 5. PORTAL Verity is installed with PeopleTools and is installed differently depending on the version of PeopleTools you have. Here are the ways Verity can be installed: * Prior to PeopleTools 8.44: Verity had to be installed separately. Refer to the PeopleTools Installation Guide: Appendix B/C. * PeopleTools 8.44 and above: Verity is installed as part of the PeopleTools installation. It is located under <PS_HOME>/verity * PeopleTools 8.50: Verity will need to be installed from http://edelivery.oracle.com into the <PS_HOME>/verity directory.

FIRST STEPS WHEN SUSPECTING A VERITY ISSUE

To Begin Troubleshooting a Verity index issue the first step is to verify the Verity version being used. Currently PeopleTools versions 8.48, 8.49 and 8.50 must have Verity version 6.2.1 installed. To check the version of Verity installed, launch the mkvdk. Here is the location per platform. WINDOWS= %PS_HOME%\bin\server\WINX86>mkvdk UNIX= $PS_HOME/bin/server. To run enter mkvdk.bin You will see a header with the version information such as this:
mkvdk - Verity, Inc. Version 6.2.0 *Note: Even though version 6.2.1 might be installed the utilities such as mkvdk and rckvdk will show only the base version of 6.2.0

INDEX BUILD ISSUES

Typically any issue building the Index is not a Verity issue but could be a problem with the Index build process through the application. The index builds are created by an Application Engine process and run through the process scheduler. (Generally, should any problems occur without being specific), the vast majority of them can be resolved with the following steps: 1) Create a new Run Control ID instead of using an existing one.

2) Make sure the Process Scheduler runs on the same machine and in the same <PS_HOME> as the Application Server. At least for initial testing purposes of the index and search the index can later be copied or accessed from a shared drive if necessary. A temporary Process Scheduler can be setup for this purpose and later shutdown. 3) Check the Veritybuild.log, the Application Engine process logs or the sysinfo.log to verify the index build was successful. These are owned by the different Applications. On Unix, the Veritybuild.log is found under $PS_HOME/data/search. The sysinfo.log can be found under: $PS_HOME/data/search/EMPLOYEE/{dbname}/ENG. One or the other will be created and will record errors or success messages. 4) Check if the files were properly created by navigating to the <PS_HOME> of your Process Scheduler server. For the Portal Registry index for example Go to: $PS_HOME/data/search/Employee/{dbname}/ENG (assuming it is English other languages will appear in their own folders if they exist). In this directory, look for: input.bif and input.xml, then check in the /parts folder which should contain .ddd and .did files.

If the Application Engine process fails, there are errors in the veritybuild.log or sysinfo.log or the index files are missing then the problem is with the index build. So after trying the above a Service Request can be logged with the application group which delivered the Index such as CRM or HCM.

INDEX SEARCH ISSUES

Once the index is built and successful through the Process Scheduler it is time to verify the search works. Test the search connecting to the same application server that is in the same <PS_HOME> as the process scheduler the index was built on. Once the search is working with the Initial index build and setup on the same <PS_HOME>, then the additional application servers can access the index residing in the data/search directory in the <PS_HOME> where the process scheduler resides. This will be a mapped or shared drive configured in the psappsrv.cfg file. For a multiple-appserver environment see KM: E-VERITY: Verity Index in a Multiple Appserver Environment (Doc ID

1086793.1)
The following are the most common search issues: 1. Index builds to success but search returns no data. This can happen for the following reasons: a. The Index location was moved to an alternate location by setting the path in the psprcs.cfg file or the psappsrv.cfg file. This must be tested in the default location of data/search. See KM Doc ID 637641.1 How to specify an alternate location for Verity Indexes. To test properly leave the Index section blank in the psprcs.cfg file and in the psappsrv.cfg file. 2. The .ddd and .did files are not in the parts directory. Example of the parts directory: $PS_HOME/data/search/<dbname>/ENG/parts. Verify the files were actually created here. 3. The Windows search server is not running. If using Search Type=3 make sure the Search server is up and running.

Windows Search Server Search Type=3

The option to setup and use a search server was added with PeopleTools version 8.48 in order to accommodate application servers hosted on HPUX-IA servers since Verity was not certified for use on the Itanium HP servers. This is no longer an issue with PT 8.49.14 and higher and Verity version 6.2.1.

Additional Considerations
Prior to testing application indexes it is best to build the Portal Registry search index. This will help to eliminate the Verity engine issues and verifies the issue is application related. For information on Building and troubleshooting the Portal Registry search index refer to the following KM: E-PORTAL: Building and Troubleshooting The Portal Registry Search Index(Doc ID 650402.1) When opening a Service Request with GCS support be sure to choose the application which owns the index being run. If the issue is verity specific then a Service Request should be logged with PeopleTools.