Konfiguration von Suche und Indexer

ConSol CM bietet eine leistungsstarke Suche nach allen an den Geschäftsprozessen beteiligten Objekten (Kunden, Tickets und Ressourcen). Technisch gesehen basiert die Suche auf dem Indexer, einem Modul von ConSol CM.

In den folgenden Abschnitten wird das Thema Suche in ConSol CM umfassend aus der Perspektive eines Administrators beschrieben. Eine detaillierte Beschreibung über die Verwendung der Suche als Bearbeiter finden Sie im ConSol CM Benutzerhandbuch.

Suchmodi

Schnellsuche

Die Schnellsuche wird über das Suchfeld in der oberen rechten Ecke des Web Clients durchgeführt. Die Anzeige der Ergebnisse (d. h. die Felder und die Reihenfolge der Felder in der Ergebnisliste) kann mithilfe von Templates formatiert werden. Details dazu finden Sie in den Abschnitten Templates für Kundendaten und CM.Resource Pool - Templates für Ressourcendaten. Denken Sie daran, dass Sie die Anzahl der Suchergebnisse mit der System-Property cmweb-server-adapter, globalSearchResultSizeLimit begrenzen können. Details dazu finden Sie im Abschnitt System-Properties. Der Ergebnissatz wird auch durch das Attribut der Seitenanpassung appendWildcardAutomatically beeinflusst, siehe Abschnitt Seitenanpassung, appendWildcardAutomatically.

Phonetische Suche

Für die Schnellsuche kann eine phonetische Suche für String-Felder konfiguriert werden. Eine Erklärung der Konfiguration Ihres ConSol CM-Systems für diese Funktion finden Sie in Konfigurieren der phonetischen Suche.

Mit der phonetischen Suche findet der Bearbeiter nicht nur genaue Treffer, sondern auch Ergebnisse, die ähnlich klingen aber nicht genau so geschrieben werden, wie der eingegebene Suchbegriff. Die Implementierung basiert auf den Bibliotheken von Apache Commons Codec.

Detailsuche

Die Detailsuche wird auf der Seite Detailsuche durchgeführt. Um diese Seite zu öffnen, klicken Sie neben dem Eingabefeld der Schnellsuche auf die Lupe.

Denken Sie daran, dass Sie die Anzahl der Suchergebnisse pro Seite (Standardwert und Optionen) mit den System-Properties cmweb-server-adapter, searchPageSize und cmweb-server-adapter, searchPageSizeOptions konfigurieren können. Eine Erklärung dazu finden Sie in System-Properties.

Informationen über die Verwendung der Suchfunktion finden Sie im ConSol CM Benutzerhandbuch, Abschnitt Suchen nach Tickets, Kunden und Ressourcen.

Konfiguration der Liste mit den Suchergebnissen

Als Administrator können Sie das Layout der Liste mit den Suchergebnissen mithilfe der Annotation order-in-result konfigurieren. Diese Annotation wirkt sich auf die Spalten der objektspezifischen Suchergebnisse aus. Die Datenobjektgruppe ResellerCompanyData, die zum Kundendatenmodell ResellerModel gehört, enthält beispielsweise folgende Datenobjektgruppenfelder:

Die Liste mit den Suchergebnissen, z. B. aus einer Detailsuche, die einen Satz Firmen aus einer Kundengruppe mit dem ResellerModel zeigt, enthält also die beiden Spalten Firmenname (company-name) und Firmennummer (company_number).

Setzen Sie den Wert der Annotation order-in-result auf 0 (Null), wenn ein Feld (d. h. eine Spalte in der Ergebnistabelle) nicht im Web Client angezeigt werden soll (d. h. das Feld soll nicht in der Feldauswahl für die Ergebnisliste und als Tabellenspalte verfügbar sein).

Abbildung 333: ConSol CM Admin Tool - Setzen der Annotation order-in-result für ein Datenobjektgruppenfeld

Abbildung 334: ConSol CM Web Client - Suchergebnisse mit zwei annotierten Spalten (order-in-result)

Hinweise zur Reihenfolge der Spalten mit den Suchergebnissen

Da die Annotation order-in-result nicht der einzige Parameter ist, der die Reihenfolge von Spalten in den Suchergebnissen (Tabellen) beeinflusst, finden Sie hier eine detaillierte Erklärung.

Im folgenden Abschnitt wird der Ausdruck Benutzereinstellungen für das vom Benutzer manuell konfigurierte Layout der Tabelle mit den Suchergebnissen verwendet, d. h. die anzuzeigenden Spalten, die Reihenfolge der Spalten und die Sortierung.

Regeln:

Die Spalten einer Tabelle mit Suchergebnissen können für jeden der folgenden CM-Objekttypen unterschiedliche Felder enthalten:
1. für Tickets: Benutzerdefinierte Felder sowie interne Felder wie Queue, Erstellungsdatum, Bearbeiter
2. für Kunden (Kontakte oder Firmen): Datenobjektgruppenfelder sowie interne Felder wie der Objektname eines Kunden
3. für Ressourcen: Ressourcenfelder sowie interne Felder wie der Objektname einer Ressource
Mit der Annotation order-in-result wird nur die Reihenfolge der Benutzerdefinierten Felder, Datenobjektgruppenfelder und Ressourcenfelder bestimmt, nicht aber die der internen Felder.
Die internen Feldtypen haben standardmäßig folgende Sichtbarkeit und Reihenfolge:
1. in Ticketlisten:
  1. Bearbeiter
  2. Hauptkunde
  3. Ticketname
  4. Ticketthema
2. in Kundenlisten (Kontakt/Firma):
  1. Name des Objekts (d. h. Kontakt oder Firma)
3. in Ressourcenlisten:
  1. Name des Objekts (=Ressource)
Die Datenfelder (Benutzerdefinierte Felder, Datenobjektgruppenfelder und Ressourcenfelder) sind primär nach den Benutzereinstellungen geordnet. Diese überschreiben jegliche andere Konfiguration.
Wenn zum Beispiel ein Benutzerdefiniertes Feld die Annotation order-in-result = 5 hat und sichtbar ist, wird es (Fall a) nicht angezeigt, wenn der Bearbeiter die Spalte nicht ausgewählt hat, und (Fall b) als Spalte Nr. 2 angezeigt, wenn der Bearbeiter es an diese Stelle gezogen hat.
Wenn durch die Benutzereinstellungen keine Reihenfolge definiert ist, ist die Reihenfolge der Datenfelder die aufsteigende Reihenfolge entsprechend der als Wert für die Annotation order-in-result angegebenen Zahlen.. Diese Zahlen werden global über alle Datenfelder in allen Benutzerdefinierten Feldgruppen, Datenobjektgruppen und Ressourcengruppen ausgewertet. Es ist also theoretisch möglich, dass unterschiedliche Datenfelder identische Werte für die Annotation order-in-result haben.
Um die Reihenfolge exakt zu definieren, setzen Sie für die gesamte CM-Installation eine Konvention ein und verwenden Sie eindeutige Zahlen, z. B. hohe vierstellige Werte.
Wenn es immer noch zwei Felder mit identischen Werten für order-in-result gibt, die beide angezeigt werden sollen, sind die Datenfelder alphabetisch nach ihren lokalisierten Namen geordnet. Dabei wird die Sprache verwendet, die der Bearbeiter im Browser eingestellt hat.

Autocomplete-Suche (Suche in intelligenten Feldern)

Die Autocomplete-Suche wird implizit durchgeführt, wenn Sie mit der Eingabe in ein Autocomplete-Feld beginnen, z. B. bei der Ticketerstellung die Firmen- oder Kundendaten eingeben (siehe folgende Abbildung).

Ab ConSol CM-Version 6.10.2 wird auch im Ticket-E-Mail-Editor eine Suche in allen Kontakten der ConSol CM-Datenbank durchgeführt, wenn der Bearbeiter mit der Eingabe in das Feld An, Cc oder Bcc beginnt:

Abbildung 337: ConSol CM Web Client - Ticket-E-Mail-Editor: Automatische Suche nach Kontakten als E-Mail-Empfänger

Die Anzahl der Zeichen, die eingegeben werden müssen, damit die automatische Suche beginnt, kann in der Seitenanpassung konfiguriert werden. Verwenden Sie dazu das Seitenanpassungsattribut minMailInputLength (Integer, Standardwert: 1) im Bereich mailTemplate.

Durchsuchbare Felder

Für Benutzerdefinierte Felder, Datenobjektgruppenfelder und Ressourcenfelder nach denen gesucht werden soll, muss die Annotation field indexed gesetzt werden. Siehe Abschnitt Die Annotation field indexed. Dann ist das Feld in der Schnellsuche und in der Detailsuche verfügbar.

Datenfelder und Inhalt, die standardmäßig indiziert werden

Datenfelder, die mit der Annotation field indexed annotiert sind

Für alle Datenfelder, die von ConSol CM-Administratoren hinzugefügt und konfiguriert wurden, muss die Annotation field indexed gesetzt werden, damit die Felder in der Suche verfügbar sind. Ein indiziertes Feld ist verfügbar in:

Als Administrator können Sie das Systemverhalten bezüglich der Suchergebnisse definieren. Abhängig von den Werten der Annotation field indexed enthalten die Ergebnisse der Suche nach einem Kontakt auch alle Tickets dieses Kontakts. Die folgende Tabelle zeigt die Auswirkungen aller möglichen Werte der Annotation field indexed für die unterschiedlichen Objekttypen. Die Annotation field indexed muss für jedes einzelne Datenfeld gesetzt werden, z. B. name und e-mail für einen Kontakt, zip und address für eine Firma, priority und software module für Tickets oder name und model für einen Ressourcentyp.

Beachten Sie, dass Sie es hier mit zwei Perspektiven zu tun haben:

Das Suchkriterium, d. h. das Feld, nach dem Sie suchen, z. B. alle Firmen, deren Name mit ConS* beginnt. Ein Feld steht in der Suche zur Verfügung, wenn die Annotation field-indexed gesetzt ist.
Der Ergebnissatz, d. h. die Objekte, die in der Ergebnisliste angezeigt werden. Die Objekte in der Ergebnisliste werden durch den Wert der Annotation field-indexed definiert. Abhängig von diesem Wert sehen Sie nur die Objekte, nach denen Sie gesucht haben (z. B. nur Kontakte) oder auch Objekte, die mit diesen Objekten verknüpft sind (z. B. Firmen der Kontakte). Eine detaillierte Beschreibung finden Sie in der folgenden Tabelle.

Bitte beachten Sie Folgendes: Wenn es möglich sein soll, Ergebnistabellen im Web Client (durch Klicken auf die Kopfzeile der Spalte) nach einer Spalte zu sortieren, muss das entsprechende Feld indiziert sein!

Objekttyp / Wert der Annotation field indexed	transitive	unit	local	not indexed
TICKET	kein Unterschied zwischen den drei Werten die Ticketdaten sind in der Suche verfügbar es werden keine anderen mit dem Ticket verknüpften Objekte abgerufen wir empfehlen die Verwendung des Standardwerts transitive	die Ticketdaten sind NICHT in der Suche verfügbar
KONTAKT	die Kontaktdaten sind in der Suche verfügbar die Tickets des Kontakts werden bei der Suche nach dem Kontakt ebenfalls gefunden die Suche nach der Firma über ihr Kontaktfeld ist NICHT möglich	die Kontaktdaten sind in der Suche verfügbar die Suche nach der Firma über ihr Kontaktfeld ist NICHT möglich	die Kontaktdaten sind in der Suche verfügbar es werden keine anderen mit dem Kontakt verknüpften Objekte abgerufen	die Kontaktdaten sind NICHT in der Suche verfügbar
FIRMA	die Firmendaten sind in der Suche verfügbar die Tickets der Firma werden bei der Suche nach der Firma ebenfalls gefunden die Kontakte der Firma werden bei der Suche nach der Firma ebenfalls gefunden	die Firmendaten sind in der Suche verfügbar die Kontakte der Firma werden bei der Suche nach der Firma ebenfalls gefunden	die Firmendaten sind in der Suche verfügbar es werden keine anderen mit der Firma verknüpften Objekte abgerufen	die Firmendaten sind NICHT in der Suche verfügbar
RESSOURCE	kein Unterschied zwischen den drei Werten die Ressourcendaten sind in der Suche verfügbar es werden keine anderen mit der Ressource verknüpften Objekte abgerufen wir empfehlen die Verwendung des Standardwerts transitive	die Ressourcendaten sind NICHT in der Suche verfügbar

Konfigurieren der phonetischen Suche

Um die phonetische Suche für ein Datenfeld zu aktivieren, setzen Sie die Annotation phonetic für dieses Feld auf true. Die Annotation kann nur für String-Felder gesetzt werden.

Aufgaben des Administrators bezüglich des Indexers

Für den Administrator ist es wichtig, zu wissen, wie man ConSol CM so konfiguriert, dass ...

Zunächst erhalten Sie einige Hintergrundinformationen über den Indexer, das System, mit dem die Suche in ConSol CM verwaltet wird. Dies hilft Ihnen als Administrator, hinter die Kulissen zu blicken und die Konfiguration besser zu verstehen.

Einführung in den ConSol CM-Indexer

Der Indexer ist das ConSol CM-Modul, das Indizes erstellt. Für jedes Datenfeld, das als Suchkriterium dienen soll (siehe Abschnitt Durchsuchbare Felder) wird ein Index erstellt.

Die Indizes werden in einem Unterverzeichnis des bei der Systemeinrichtung angegebenen Datenverzeichnissen gespeichert (das Datenverzeichnis wird in der System-Property cmas-core-shared, data.directory gespeichert). Die folgende Abbildung zeigt ein Beispiel für Indexdateien einer ConSol CM-Installation (hier eine Demo-Umgebung). demo_Datadir ist das Datenverzeichnis, das bei der Einrichtung angegeben wurde. Alle Unterverzeichnisse werden automatisch durch ConSol CM erstellt.

Wenn das Indexverzeichnis beschädigt oder nicht verfügbar ist, kann der Index neu gebaut oder repariert werden. Details dazu finden Sie in den folgenden Abschnitten.

Verwaltung von Indexer und Index mit dem Admin Tool

Die Annotation field indexed

Eine detaillierte Beschreibung des durch diese Werte bestimmten Systemverhaltens finden Sie in der obigen Tabelle.

Verschachtelte Felder müssen den gleichen Indextyp haben, andernfalls können sie nicht durchsucht werden. Wenn Sie zum Beispiel mit einer List of Structs arbeiten, müssen die Liste, das Struct und alle Datenfelder im Struct, die durchsucht werden sollen, die Annotation field indexed mit dem Wert transitive haben.

Indexer-Verwaltung: Navigationselement Index

Normalerweise ist keine manuelle Pflege des Index erforderlich. ConSol CM führt alle Indizierungsvorgänge automatisch aus. Es gibt nur zwei Fälle, in denen Sie Administrationsvorgänge manuell ausführen müssen:

Öffnen Sie im Admin Tool die Navigationsgruppe Dienste, Navigationselement Index, um den Indexer zu konfigurieren und zu verwalten. Wenn gerade Indexer-Aufgaben ausgeführt werden, wird dies durch ein Ausrufezeichen neben dem Namen der Navigationsgruppe (Dienste) angezeigt. Neben dem Namen des Navigationselements (Index) steht die Anzahl der offenen Aufgaben. Auf diese Weise sehen Sie als Administrator, dass es in der Gruppe Dienste offene Aufgaben gibt, auch wenn die Navigationsgruppe nicht aufgeklappt ist. Zudem können Sie die Anzahl der offenen Aufgaben schnell herausfinden.

Abbildung 339: ConSol CM Admin Tool - Navigationsgruppe Dienste: Navigationselement Index

In der ersten Zeile wird der aktuelle Status des Indexers angezeigt (das ist der Wert der System-Property cmas-core-index-common, index.status):

Wenn es offene Aufgaben in der Liste der Indexer-Aufgaben gibt, werden folgende Daten für die einzelnen Aufgaben angezeigt:

Für Indexer und Index relevante System-Properties

Indexer-Aktualisierung

Eine detaillierte Beschreibung des ConSol CM-Indexer, einschließlich der Konfiguration des Indexer in einer Umgebung mit Master- und Slave-Indizierungsservern finden Sie im ConSol CM Betriebshandbuch. An dieser Stelle finden Sie eine Kurzinformationen als Einleitung für CM-Administratoren.

Modi der Indexer-Aktualisierung

Der Indexer speichert Entitäten, die aktualisiert werden müssen (z. B. geänderte Tickets oder Kunden, neue Bearbeiter) in einem persistenten Speicher. Dies kann entweder eine JMS-Queue des Application Servers oder eine Tabelle in der CM-Datenbank sein. Sie können den Modus auswählen, indem Sie die System-Property database.notification.enabled setzen. Der Standardwert in CM-Version 6.10 ist false.

Persistenter Speicher des Index als JMS-Queue

Persistenter Speicher des Index als Datenbanktabelle

database.notification.enabled = true (sollte nicht bei CM-Versionen vor 6.9.4.1 verwendet werden)

Die Datenbanktabelle cmas_index_update_serialized wird (als persistenter Speicher) für die Indexer-Transaktionen verwendet. Der Master-Indizierungsserver (oder der einzige Indizierungsserver in Umgebungen mit nur einem Server) ruft die Daten aus dieser Datenbank ab.

Prinzip der Indexer-Aktualisierung

Der Master-Indizierungsserver fragt den persistenten Speicher, ob neue Einträge vorhanden sind. Wenn es neue Einträge gibt, werden Indexer-Tasks in den Tabellen cmas_index_update_task und cmas_index_update_part erstellt. Der Master-Indizierungsserver führt dann die Tasks aus cmas_index_update_task und cmas_index_batch_update_task aus. Auf diese Weise wird der Master-Index (Index) aktualisiert.

Auf dem Master-Indizierungsserver (oder dem einzigen Indizierungsserver) werden die administrativen Tasks in der Datenbanktabelle cmas_ index_administrative_task gespeichert.

Jeder Slave-Indizierungsserver fragt den Master-Indizierungsserver, ob Aktualisierungen vorhanden sind, und aktualisiert dann seinen eigenen (lokalen) Index.

System-Properties im Zusammenhang mit dem Indexer

CM-Indexer-Dienste

Systeme mit mehr als einem Indizierungsserver

Wenn ConSol CM in einem Cluster mit mehreren Application Servern läuft, enthält jeder Cluster-Node einen lokalen Index im jeweiligen Verzeichnis ${cmas.data}/index/. Der Index wird auf einem (einzelnen) Master-Server aktualisiert, von dem danach alle Slave-Server die Daten abrufen, um ihre lokalen Kopien zu aktualisieren. Das Ergebnis ist, dass alle Indizierungsserver am Ende konsistent sind, d. h. die Aktualisierungen sind nicht sofort sichtbar, sondern normalerweise mit einem kurzen Zeitversatz.

Für die Synchronisierung des Indexers wird JGroups verwendet (weitere Informationen auf der Website JGroups.org).