Using the Enhanced Search Engine

To enhance your ability to obtain better search results, examples and explanations of the available types of searches are provided here.

Simple Search

The simple search is the most basic type of search. The search engine searches for CIs according to CI data and synonyms for CI data. CI data can include class names and attributes.

Simple Search Examples

• If you enter all Unix or all business application, this triggers a search by class name, since Unix and business application are class names. The search results include all Unix machines in the system (when searching for all Unix), or all business applications in the system (when searching for all business application).

• If you enter all Windows, since windows is a class name synonym for NT, a search by class type is triggered for all Windows PCs in the system.

• If you enter Windows version 2008, since version is a synonym of the property discovered_os_name, this triggers a search for all Windows PCs where the property discovered_os_name = 2008.

• If you enter Windows with more than 4GB of memory, since memory is a synonym of the property memory_size, this triggers a search by property condition for all Windows PCs with the attribute memory_size > 4GB.

  Note
  Searches can be performed with any type of pre-defined unit. Out-of-the-box definitions are provided for kilobyte, megabyte, and gigabyte.

• If you enter all nodes changed last week, all Unix machines created today, or all Windows changed since Aug 21st 2013, the search engine can interpret this correctly to yield appropriate results.

Search According to CMDB Structure

Searches Based on CI Relationships

If you enter Windows 2008, the search engine looks for CIs with the class name or property Windows that have a related CI with a property value 2008. This could include, for example, a Windows server connected to SQL server 2008.

Search by Path

• If you enter Windows London, this triggers a search that yields results of all Windows PCs in the system that are connected directly or indirectly to the London CI.

• If you enter all Windows owned by John, the search engine returns all Windows PCs owned by the user called John.
• If you enter Oracle 16.55.158, the search engine yields search results with all Oracle servers in the 16.55.158.* IP address range.

Search by Cardinality Condition

Certain words or phrases trigger a cardinality search, such as with more than or with less than. If you enter Windows with more than 5 CPUs, this triggers a search that yields results of all Windows PCs with at least 5 CIs of type CPU connected to them. The term that follows the cardinality phrase must be a class name or class synonym. In the example here, CPU is a class synonym.

Different Types of Search Results Based on the Same Input Text

As mentioned above, based on the input search text, the search engine can perform various types of searches simultaneously. For example, if you enter Windows 2008, the search engine returns the following results:

• CIs with the class name or property Windows that have a related CI with a property value 2008 (search based on CI relationships, as described above).
• All CIs that have both a property called Windows and a property called 2008.
• All CIs with the class name Windows and a property called 2008.

Special Support

Phrase Replacement

If you enter Linux machine, this triggers a search of all Unix machines with version = Linux.

Search with Keywords

The search engine supports a set of pre-defined keywords that allow you to perform special searches. The keywords are type, view, and query.

Search with type Keyword

You can use the type: keyword to filter search results. To do this, use the syntax: term1 type:term2. For example, John type:windows return all Windows owned by John.

Search with view Keyword

You can search for CIs in a view by using the keyword view: followed by the view name. For example, view:myView returns all CIs in the myView view result.

Search with query Keyword

You can also search for CIs in query results. This is similar to searching for CIs in view results, but for the active query defined in UCMDB. For example, query:myQuery returns all CIs in the myQuery result.

Searches Based on Logical Operators

You can use a combination of conditions separated by logical operators. The search engine parses the search input string from left to right without regards to the prioritization of logical operators, and not according to the standard rules of logical operator prioritization. For example, A or B and C is treated as (A or B) and C, and not as A or (B and C).

Examples

• If you enter Nodes owned by John or Jim, this triggers a search that yields results of all nodes in the system with an owner John and all nodes in the system with an owner Jim.
• If you enter All Windows with more than 4 CPUs and with at least 4 GB memory, the search engine yields results of all Windows PCs in the system that have both more than 4 CPUs and at least 4 GB memory.
• If you enter All Windows versions not 2008, the search engine yields results of all Windows PCs in the system that are not version 2008.

Enriching Search Results

Explanation and Examples

Since the user is not always aware of how IT entities are modeled in UCMDB, he may enter search input text for one thing while his real intention was something else. The search engine has been designed with an enriching mechanism that can "guess" the user’s real intention. For example, if the user searches for the IP address 16.59.188.16, he may be actually interested in the IP’s connected node, and so the enriching mechanism looks for all nodes connected to the IP address.

It is possible that the user enters London, but what he really wants to know are the nodes at this location. The enriching mechanism has been designed to look for all nodes connected to a location CI, so in this example the search engine would return all nodes connected to the London CI.

Federated Search

Explanation and Examples

All the types of searches described above are not performed on federated data. However, the search engine contains some predefined hard-coded topological queries for performing searches on federated data. For example, if you enter myServer name and the server name is a federated CI, there is a federated query that tries to retrieve the CI by its name. This TQL is executed for the CI types node, business element, and CI collection, that have attributes of string type, and are marked with the CMS_SEARCHABLE_ATTRIBUTE qualifier.

The user can also retrieve data on relationships between federated CIs. For example, the user can retrieve CIs by their IP address. If you enter 16.1.100.45 and this is the IP address of a federated CI, the search engine returns the actual node connected to this IP address.

Auto-Completion Search Entry Capability

Auto-completion capability is added to the search field and supports the following language entries:

• CI Type names and synonyms (for example: Windows=NT)
• Attribute names and synonyms (for example: version=DiscoveredOsName)
• Relationship names and synonyms (for example: linked to and located in)
• Cardinality phrases (for example with more than and at least)