ConSol CM provides a powerful search mechanism for all objects involved in the business processes (customers, tickets and resources). Technically, the search is based on the Indexer, a module of ConSol CM.
The following paragraphs explain the entire topic Search in ConSol CM from an administrative point of view. Please refer to the ConSol CM User Manual for a detailed explanation about how to use the search as an engineer.
A ConSol CM engineer can use several search modes:
This is performed using the Quick Search field in the upper right-hand corner of the Web Client. The display of the results (i.e., the fields and the order of the fields in the result list) can be formatted using templates, as detailed in sections Templates for Customer Data and CM.Resource Pool - Templates for Resource Data. Please keep in mind that you can adapt the length of the result set using the system property cmweb-server-adapter, globalSearchResultSizeLimit - see System Properties for details. The result set will also be influenced by the Page Customization attribute appendWildcardAutomatically, see section Page Customization, appendWildcardAutomatically for details.
Figure 333: ConSol CM Web Client - Quick Search
For the Quick Search, a phonetic search can be configured for String fields. Please see section Configuring the Phonetic Search for the explanation of how to prepare your ConSol CM system for this feature.
With a phonetic search, the engineer cannot only find exact matches in the search results but also results which sound similar even if the spelling differs from the entered search term. The implementation is based on the Apache Commons Codec libraries.
Figure 334: Search results without phonetic search
Figure 335: Search results with phonetic search
This is performed using the Detailed Search page. To open this page, click on the magnifier icon next to the Quick Search entry field.
Figure 336: ConSol CM Web Client - Detailed Search
Please keep in mind that the result list length and paging of the result list for the Detailed Search can be configured using the system properties cmweb-server-adapter, searchPageSize and cmweb-server-adapter, searchPageSizeOptions. See System Properties for an explanation.
Please refer to the ConSol CM User Manual, section Searching for Tickets, Customers and Resources to learn how to use the search functionality.
You, as an administrator, can configure the layout of the search result list using the annotation order-in-result. This annotation influences the columns of object-specific search result sets. For example, the Data Object Group ResellerCompanyData, belonging to the Customer Data Model ResellerModel, contains the following Data Object Group Fields:
Thus, in a search result list, e.g., a Detailed Search which shows a result set with companies of a customer group which uses the ResellerModel will contain the two columns company_name and company_number.
For a field (i.e., column in the result table) which should not be displayed in the Web Client (i.e., in the field selector for the result list and as column in the table) at all, set the value of the order-in-result annotation to 0 (zero).
Figure 337: ConSol CM Admin Tool - Setting the annotation order-in-result for a Data Object Group Field
Figure 338: ConSol CM Web Client - Search result set with the two annotated columns (order-in-result)
Notes about the Order of Search Result Columns
Since the annotation order-in-result is not the only parameter which influences the order of columns in search results (tables), please find here a detailed explanation.
In the following section, user preferences means the layout of a search result table which the engineer has configured manually, e.g., the columns which should be displayed, the order of those columns or the sorting.
Rules:
The columns of a search result table can display different fields for each of the CM object types:
The Autocomplete Search is performed implicitly when you start entering a word in an Autocomplete field, e.g., in company data or customer data when you create a ticket (see figures below).
Figure 339: ConSol CM Web Client - Autocomplete Search
Figure 340: ConSol CM Web Client - Suggestions for an Autocomplete Search
Starting with ConSol CM version 6.10.2, a search in all contacts of the ConSol CM database is also performed in the Ticket E-Mail Editor when an engineer starts typing in the To, Cc or Bcc field:
Figure 341: ConSol CM Web Client - Ticket E-Mail Editor: Automatic search for contacts as e-mail receivers
The number of characters which must be typed before automatic search is activated can be configured using the page customization attribute minMailInputLength (Integer, Default 1) in the scope mailTemplate.
For Custom Fields, Data Object Group Fields and Resource Fields which should be searched, the annotation field indexed has to be set. See section The Annotation field indexed. This makes the field available for the Quick Search and for the Detailed Search.
Two types of fields are processed by the search engine:
For all data fields which have been added and configured by the ConSol CM administrators, the annotation field indexed has to be set to make the fields searchable. A field which is indexed is available in
You, as an administrator, can define the system's behavior with regards to search results. Depending on the values of the field indexed annotation, the search results for a contact might include all the tickets of the contact as well. The following table shows the implications of all possible values of the field indexed annotation for the different object types. The field indexed annotation has to be set for each individual data field, e.g., name and e-mail for a contact, zip and address for a company, priority and software module for tickets, or name and model for a resource type.
Please note that two distinct perspectives are addressed here:
|
Object type/ value of field indexed annotation |
transitive | unit | local | not indexed |
|---|---|---|---|---|
| TICKET |
|
|
||
| CONTACT |
|
|
|
|
| COMPANY |
|
|
|
|
| RESOURCE |
|
|
||
Please note that if it should be possible to sort result tables (in the Web Client) according to a column (by clicking on the column header), the respective field has to be indexed!
In order to activate the phonetic search for a data field, set the annotation phonetic to true for this field. The annotation can only be used for String fields.
It is important for the administrator to know how to configure ConSol CM in a way that ...
These tasks are described in the following sections.
First, some background knowledge about the Indexer, the system which manages the search in ConSol CM, is provided. This will help you, as an administrator, to look behind the scenes and understand the configuration in a better way.
The Indexer is a module of ConSol CM which creates search indexes. For each data field that should serve as search criterion (see section Fields Which Can Be Searched above), an index is created.
The indexes are stored in a sub-directory of the data directory that you have indicated during system set-up (the data directory is stored as a system property: cmas-core-shared, data.directory). The following picture shows an example for index files of a ConSol CM installation (here used for a demo environment). The demo_Datadir is the data directory specified during set-up, and all subdirectories are created automatically by ConSol CM.
Figure 342: ConSol CM Indexer - Directory demo_Datadir
Please make sure that ...
If the index directory should be corrupted or the index is not available, it can be rebuilt or repaired. Please see the following sections for details.
By default, the entire ticket text and all attachments are indexed. For all Custom Fields, Data Object Group Fields and Resource Fields, the fields which should be indexed have to have the annotation field-indexed. Please refer to the sections Custom Field Administration (Setting Up the Ticket Data Model), Data Object Group Field Management and GUI Design for Customer Data and CM.Resource Pool - Setting Up the Basic Resource Model for details about setting annotations to Custom Fields (ticket data), Data Object Group Fields (customer data) and Resource Fields (resource data). There are four possible values for this annotation:
A detailed explanation of the system behavior triggered by those values is provided in the table above.
Nested fields all have to have the same index type, otherwise they cannot be searched. For example, when you work with a list of structs, the list, the struct and all data fields in the struct which should be searched have to have the value transitive for the annotation field-indexed.
Usually, the index requires no manual maintenance. ConSol CM will handle everything regarding indexing automatically. There are only two cases where you have to perform manual administrative operations:
In the Admin Tool, open the navigation group Services, navigation item Index to configure and manage the Indexer. If Indexer tasks are still running, this will be indicated by an exclamation mark next to the name of the navigation group (Services) and by the number of open tasks next to the name of the navigation item (Index). In this way, even when the navigation group is not opened, you, as an administrator, can immediately notice that some tasks are open in the group Services and can then quickly identify the number of open tasks.
Figure 343: ConSol CM Admin Tool - Navigation group Services: Navigation item Index
Figure 344: ConSol CM Admin Tool - Indication of open indexer tasks
In the first line the current status of the Indexer is displayed (this is the value of the system property cmas-core-index-common, index.status):
The following operations can be performed:
Commit administrative changes
Click this button to commit the changes when you have set a Custom Field, Data Object Group Field or Resource Field to field-indexed that was not indexed before. This has to be used if the checkbox No automatic commit of administrative changes has been selected. If the checkbox is inactive, the changes will be committed automatically when you have set the new annotation(s).
Please note, that the automatic commit of administrative changes can affect the system performance.
There is a difference in ConSol CM versions concerning the meaning of administrative changes which influences manual index management!
In versions prior to 6.9.3.0, setting the annotation field-indexed from false (or not set) to true is not considered an administrative change. That means when you have added the annotation field-indexed = true for a data field which was present before, you have to modify the index manually by using either Synchronize index or Recover index.
Starting with version 6.9.3.0, setting the annotation field-indexed from false (or not set) to true is considered an administrative change. That means when you have added the annotation field-indexed = true for a data field which was present before, you have to
or
If there are open tasks in the Indexer task list, the following data is displayed for each task:
When an admin has started the index update manually (Synchronize Index), all other index tasks are removed, before this update starts.
The following system properties are also relevant for the Indexer, see following figure. Please refer to System Properties for a detailed explanation of the Indexer system properties and the Indexer and Search Configuration section of List of System Properties by Area.
Figure 345: ConSol CM Admin Tool - System properties for the indexer
For a detailed description of the ConSol CM Indexer, including the configuration of the Indexer in an environment with master and slave indexing servers, please refer to the ConSol CM Operations Manual. Here in the current section, some short information will be provided as quick introduction for CM administrators.
The indexer stores entities which require an index update (e.g. modified tickets, modified customers, new engineers) in a persistent store. This can be either a JMS queue of the application server or a table in the CM database. You can select the mode by setting the system property database.notification.enabled, default value in CM version 6.10 is false.
database.notification.enabled = false
The JMS queue queue/cm6-index will be used.
database.notification.enabled = true (should not be used with CM versions before 6.9.4.1!)
The database table cmas_index_update_serialized will be used for indexer transactions (as persistent store). The master indexing server (or the only indexing server in single-server environments) polls this database
The master indexing server polls the persistent store for new entries. If there are new entries, indexer tasks are created in the tables cmas_index_update_task and cmas_index_update_part. The master indexing server then executes the tasks from cmas_index_update_task and cmas_index_batch_update_task. In this way, the (master) index is updated.
On the master (or only) indexing server, administrative tasks are stored in the database table cmas_ index_administrative_task.
Every slave indexing server polls the master indexing server for updates and then updates its own / local index.
Please refer to the Indexer and Search Configuration section of List of System Properties by Area.
For indexing, two ConSol CM services are important:
Please see also section CM Services.
Stopping index changes notifier is NOT safe. If the indexer module discovers that the notifier is stopped and there is a message that has to be sent to the persistent store, the indexer will set the index status configuration property to RED, i.e., signal that the index needs a full synchronization.
However, stopping index changes receiver is safe. After restarting, it will pick up all of the missing changes from the persistent store.
When ConSol CM is run in a cluster of application servers, each cluster node holds a local index in its ${cmas.data}/index/ directory. The index gets updated on the (single) master server, which is then polled by all slave servers to update their copies. As a result, all indexing servers are eventually consistent, i.e., updates are not visible right away, usually with a small delay.
JGroups is used for indexer synchronization (see the JGroups.org web site for more information).