Use > CMS Modules > Configuration Item Search > Search and Search Engine > Using the Enhanced Search Engine

Using the Enhanced Search Engine

The UCMDB’s powerful enhanced search engine analyzes the input search text to retrieve CI data from UCMDB. Based on the input search text, the search engine performs various types of searches simultaneously to provide optimum and comprehensive results to the user. The search engine makes extensive use of synonyms so you do not need to enter the precise name or data of the items you are looking for.

Note Starting from UCMDB version 10.31, the SOLR auto commit feature is enabled by default. The soft auto commit interval is set at 3 minutes, this means that the CIs' changes are visible after 3 minutes. For more details, see the Administer section of the UCMDB Help.

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

Note  

  • The search engine is provided ready to use out-of-the box. However, it is highly configurable and the various types of searches described here can be modified by the UCMDB Administrator to meet your system needs. For more information on configuring the enhanced search engine, see Specific Configuration Options.
  • The enhanced search engine is not case sensitive.
  • The free text search in the enhanced search engine can only be performed in English, other languages are currently not supported. However, CI names, attributes, and values in other languages can be found by the enhanced search engine.
  • When the enhanced search engine is enabled and you perform a search in the CMS UI, the maximum number of search results that are displayed and can be exported is 1200.

  • When the enhanced search engine is enabled and a full reindex is in progress, the CMS UI automatically uses the legacy search engine. In this case, when you perform a search in the CMS UI, legacy search results are retrieved, and a notification message is displayed.

    When the reindexing process has completed, the CMS UI switches back to the enhanced search engine.

    Note that the legacy search results and features are different from the enhanced search results.

     

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.

    For information on how to configure class name synonyms, see Configure Class Name Conditions.

  • 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, as explained in Configure Search by Property Condition. Out-of-the-box definitions are provided for kilobyte, megabyte, and gigabyte.

    For more information on how to configure attribute synonyms, see Configure Search by Property Condition.

  • 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.

    For information on how to configure this search, see Configure Search of CIs Changed in a Specific Time Period. For information on configuring date formats, see Configure Date Format.

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.

For information on how to configure searching based on CI relationships, see Configure Search by Topology.

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.

    For more information on how to configure this type of search, see Configure Search by Path.

  • 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.

For information on how to configure the search by cardinality, see Configure Search by Cardinality Condition.

Note The example above triggers a search based on CI relationships, since in the UCMDB CPUs are modeled separately from servers (with direct relationship between them) and this information may be transparent to the user.

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.

For information on how to configure this search, see Configure String Replacement.

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.

Note The view name is case sensitive (in the UCMDB the user can define two views myView and MyVIEW). Also, if the view name contains more than one word (separated with spaces) the view name should be surrounded with quotation marks, for example view:"My view".

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.

For information on how to configure the search engine's enriching capability, see Configure Enriching Capability.

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.

Note

  • The search on federated data (legacy search and widgets) can only be performed if the Show federated search results setting is enabled. By default, the Show federated search results setting is disabled.
  • The search for federated CIs according to their display names (or sub-string of their display names) is performed if the CI type has been configured for this.

    • For instructions on enabling/disabling the search on federated data and enabling a search of a federated CI by the CI display name, see Enable/Disable Searching for Federated Data.

Note The search on federated data (legacy search and widgets) can only be performed if the Show federated search results setting is enabled. By default, the Show federated search results setting is disabled.

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)

Send Help Center feedback