Skip to Main Content
Return to Navigation

Building Record-Based Verity Indexes

The record-based index extracts data from database tables and inserts the data into BIF and XML files, which are then indexed by Verity. The individual creating the index chooses the records (tables) to be indexed.

Note: The record-based index supports only data that is stored in PeopleSoft databases.

This section discusses how to:

Modifying Record-Based Verity Index Properties

Select select PeopleTools, then select Search Engine, then select Record-Based Indexes to access the Design a Search Index page.

Image: Design a Search Index page (Record-Based)

This example illustrates the fields and controls on the Design a Search Index page (Record-Based). You can find definitions for the fields and controls later on this page.

Design a Search Index page (Record-Based)

Parent Data Record

Record (Table Name)

Enter tables, views, or a PeopleSoft view that contains data. To combine the data from multiple PeopleSoft tables, to create a view on those tables and specify the name of that view here.

WHERE clause to append

Fine-tune the data that you receive by entering a Structured Query Language (SQL) WHERE clause.

Key returned in search results

Use to synthesize the VdkVgwKey, which supports an XML-like syntax enabling you to modify the tag that is returned by Verity.

You have the following options:

  • <pairs/>: Inserts a string of NAME=VALUE;. One such pair is returned for each key of the record.

  • <row/>: Inserts the record keys in a SQL-like syntax.

  • <field fieldname='MYFIELD'/>: Inserts the value of MYFIELD if it exists in the record.

  • <sql stmt='SQL STATEMENT'/>: Inserts the value that is returned by the SQL statement. The system accepts only the first row that is returned, and PeopleSoft software does not support SQL statements returning more than one column.

Edit Key

Click to access the page where you can change the results that are returned by the Key returned in search results functionality.


How to Zone the Index

One Zone: Select to put all of the data into one zone. With this option, the collection builds more quickly but the application can't restrict searches to the portions of the index that come from a particular field.

Field Zones: Select to create one zone for each PeopleSoft field on the record. Applications can specify that they want to access that particular zone in their searches.

Field Name

After you specify a record name, the fields in that record appear in this grid. Select the following options for each field in the record: Verity Field, Word Index, or Has Attachment (each option is explained in the following sections).

Verity Field

Select if the PeopleSoft field should be indexed as a Verity field. In general, PeopleSoft fields that contain a lot of descriptive text, such as description fields, should be indexed as word indexes (See the following definition) and PeopleSoft fields that contain metadata about what is being indexed (such as ProductID) should be indexed as Verity fields.

Word Index

Select if this PeopleSoft field should be indexed as a word index. See the preceding Verity Field definition for guidelines on defining a PeopleSoft field as a Verity field versus defining it as a word index.

Has attachment

Enables you to index attachments that are referenced in the field as uniform resource identifiers (URIs). Refer to the PeopleCode Developer's Guide for a description of file attachments. If this field contains the URL to an attachment, select this check box. The indexer downloads the attachment and indexes it as part of the document. This item is enabled only if the corresponding PeopleSoft field contains character data, because numeric fields cannot contain URLs.

To use this field, you need a record that is designed with this feature in mind. In the record, each row has a text field that contains a URI or an empty string.

The text must be a valid File Transfer Protocol (FTP) URI (including the login and password string) of the following form:

  • ftp://user:pass@host/path/to/filename.doc.

  • A valid record URI of the form record://RECORDNAME/path/to/file.doc.

  • A string of the form <urlid name="A_URLID"/>/path/to/file.doc.

The third form references an entry in the URL table (select Utilities, then select Administration, then select URLs). If the URL ID that is named in the name attribute is valid, the entire URI is rewritten with the part in brackets replaced by the actual URI.

For example, if A_URLID is equal to, the entire string in the previous example becomes and is treated like any other FTP URI.

Rows of data with empty strings in the URI field are ignored with no error.

If the string is one of these three valid URI forms and a document can be retrieved at that URI, the document is indexed with the same key as the rest of the row of data and is searchable.

To add subrecords to the index, select the Subrecords tab, and insert the child records that you want to include in the index.

Adding Subrecords to Verity Search Indexes

Select select PeopleTools, then select Search Engine, then select Record-Based Indexes, then select Subrecords.

To index more than one record as a single document, the records must be hierarchically related. For example, the record that is specified on the previous page must be a parent of all the others. Formally, this means that the keys of each subrecord named must be a superset of the keys of the parent record. The parent record is the one that you specify in the Record (Table Name) field on the Primary Record page.

To add subrecords to an index:

  1. Create and save the index definition.

  2. Select select PeopleTools, then select Search Engine, then select Record-Based Indexes, then select Subrecords.

  3. Click the Add a new row button to insert the names of the records that are children of the parent record that is defined on the Primary Record page.

    On the Primary Record page, the fields of the child record are added to the Fields grid. When you build the index, data from the child records whose keys match the row in the parent record is included as part of the parent record. When an end user searches for data that is found in the child record, the system returns a reference (VdkVgwKey) for the parent record.