Performing searches on multiple forms
The AR System Multi-Form Search (MFS) form serves as an interface (or API) for BMC Remedy AR System applications to be able to perform searches on multiple forms within the system. If you search from a global search field, such as RKMs search, or the global searches supplied by ITSM applications, MFS search is triggered .
The tabs on the AR System Multi-Form Search form represent the logical flow for you to follow to set up a multiple-form search:
- Search Terms — Enter the terms to search for.
- Filter — Enter criteria to limit (or "filter") the entries to be searched.
- Result Data — Enter the additional information you want returned to users (beyond the standard results) after they run a search.
A full-text search adds wildcards to search strings, but wildcards are not used in searches across multiple forms.
For example, if you search for doc with full-text search, the percent wildcard (%) is added before and after the string (for example, %doc%). Results can include strings such as Doctor, Dock, doctrine, and haddock.
Conversely, for searches across multiple forms, wildcards are not added. It is assumed that the applications knows what the actual terms are (because the application is already using full-text search and controlling it more closely).
Entering search terms
The Search Terms tab contains fields in which your application will place text that will be searched across all FTS-indexed forms and fields and to which the user has permissions (unless limited to a subset as defined on the Filter tab. See Entering search criteria). The fields on the Search Terms tab are:
- Must Have
- May Have
- Must Not Have
All the fields are optional, but the Must Have or May Have field must include data to obtain search results. Additionally, the Must Have or May Have field must include data if the Must Not Have field is supplied with a value.
NOT queries can be constructed within the Must Have, May Have, and Must Not Have fields. For example, in the May Have field, you could construct a complex parenthetical query such as:
(keyboard OR mouse) AND computer AND NOT printer
For complex parenthetical queries constructed within the Must Have or May Have fields, you obtain different results.
For example, if you run the query
(keyboard OR mouse) AND computer AND NOT printer, and the database contains records such as:
Record 1 - Keyboard
Record 2 - Mouse
Record 3 - Printer
Record 4 - Computer
Record 5 - Keyboard, Mouse, Computer
Record 6 - Keyboard, Mouse, Computer, Printer
The results obtained are:
For May Have field: Record 1, Record 2, Record, 4
Count: 3 (The records containing any of the three strings are shown in the results)
For Must Have field: Record 5
Count: 1 (The records containing all the three strings together are shown in the results)
You can also shorten the
AND NOT to simply
This produces a result where the entries searched must have computer, and must also have either a keyboard or a mouse, and they must not have a printer.
If you perform an accrue type search in the May Have field (such as
keyboard,mouse,computer), the search results contain keyboard or mouse or computer. If you use the same accrue search in the Must Have field, the search results contain only entries that contain all three.
If the May Have field and Must Have fields each contain a term, the only entries returned are entries that match the Must Have field. However, any entries that also contain the words in the May Have field have a higher score than entries that contain only words found in the Must Have field. For example, if keyboard is in the May Have field and mouse is in the Must Have field, all entries returned contain mouse, but entries that contain both keyboard and mouse have a higher score than those entries that contain only mouse.
To protect itself from memory over usage during searching, AR server truncates the search terms whenever the count of special characters exceeds 10.
For example, AR server truncates the search term @# @# @# @# @# apples @# bananas to @# @# @# @# @# apples.
For any mismatched value of parentheses in a search term, you get the following error:
Unable to complete the full text search operation. (ARERR 657).
Entering search criteria
The Filter tab enables you to limit the entries to be searched. The fields on this tab are optional. They are:
- Form List — Enter a list of form IDs for forms that you want to search. Separate the IDs with semicolons. If this field is blank, all FTS-indexed forms and fields (which the administrator does not specifically exclude and to which the user has rights) are searched.
- Search Filter — Enter an
AND /OR /NOTqualification that uses the configured category fields (defined by Full Text MFS Category Name field property) as well as create and modify date fields. For example, you could supply the following search filter to limit the search:
('status' = "Draft" OR 'status' = "SME Review") AND 'ProductTier1' = "Hardware"
In addition to using category fields, you can use the fields in the following table in a search filter qualification.
Fields for search filter queries
Enables filtering for a specific create date or date range.
Enables filtering for a specific modify date or date range.
Enables filtering to a specific entry ID.
Enables filtering to a specific form ID.
When you filter with dates, you can use the =, <, >, <=, >= operators, for example:
- The following qualification limits entries to those created only on September 1, 2009:
'createTime' = "1251784800"
- The following qualification limits the entries to only those created since September 1, 2009 (open ended):
'createTime' >= "1251784800"
- The following qualification limits the entries to those created only between (and including) the dates of September 1, 2009, and September 15, 2009:
'modifiedTime' >= "1251784800" AND 'modifiedTime' <= "1252994400"
- The following qualification limits the entries to those created only between (and excluding) the dates of September 1, 2009, and September 15, 2009:
'modifiedTime' > "1251784800" AND 'modifiedTime' < "1252994400"
Entering search results data
On the Result Data tab, you design how the result data is returned to the user. Result data is for affecting the data that is to be returned in the search results and to allow defining columns relevant to that data in a result list.
To configure what should be returned with each result, choose an option from Search Result Option:
- No Excerpt/WAH (the default) — Returns only the text that was searched for. (It does not return an excerpt or the words surrounding the result.) This is the most efficient option.
- Excerpt --- Returns the first thirty words of the resulting hit so that the user can read a summary of the content. This option is less efficient than None, but more efficient than Words Around Hit.
- Words Around Hit (WAH) — Returns excerpts that contain the text from the search as well as surrounding text. The text that was searched for is surrounded by brackets (). For example, if printer was searched for, a result might be setting up the printer in the room 1B.
- Count Only — Returns the potential number of matches for the search. (The count is taken before row level permissions are applied, which may reduce the actual result set.)
The following fields are returned with every search request:
- Entry ID
- Excerpt or Words Around Hit (if requested)
- Weight (relevancy score)
- Create Date
- Modify Date
The Optional Return Fields area on the Result Data tab enables you to map a defined category field to one of the Result fields. You can configure up to 20 result fields.
If the name of a category field is supplied in any result field at the time of the search, then that result field is populated with the values from that category field. For example, if you enter the following qualification, the values from the status filter field are returned in Result 1:
'Result 1' = "status"
To define a category field, enter a category name in the Full Text MFS Category Name field property for the field. For more information, see Defining a field for FTS.