Die SmartSearch bündelt Anforderungen, die Kunden an die Suchfunktion einer Online-Präsenz stellen: Eine intuitiv bedienbare, hochperformante Suchlösung, die auf umfangreichen Webseiten einsetzbar ist und relevante Ergebnisse liefert. Sie bietet sowohl eine hohe Trefferqualität als auch einen optimalen Suchkomfort und bindet Kunden somit auf der Webseite.
Gleichzeitig stellt sie Redakteuren durch das integrierte SmartSearch-Cockpit eine Web-Oberfläche bereit, die ohne IT-Kenntnisse verwendbar ist. Redakteure aus Fach- und Marketingabteilungen werden so in die Lage versetzt, Suchergebnisse auf der Webpräsenz zu steuern und zu überwachen. Das Cockpit stellt dafür Statistiken, Filter sowie Analysefunktionen bereit und erlaubt die Indizierung verschiedenster Datentypen (zum Beispiel XML, Audio, Video, Medien) aus unterschiedlichen Datenquellen. Mithilfe individualisierter Trefferlisten können Redakteure im Backend Suchergebnisse priorisieren und gewichten sowie ausgewählte Inhalte zu vordefinierten Suchanfragen ausgeben lassen.
Die Funktionalitäten der SmartSearch werden über eine Architektur verschiedener Komponenten realisiert (vgl. Abbildung Architektur).
Bei diesen Komponenten handelt es sich um:
Das Zusammenspiel der Komponenten erfolgt immer nach dem folgenden Schema:
Die Kommunikation nach außen ist durch HTTPS geschützt, zwischen den Komponenten erfolgt sie per HTTP.
Der Einsatz der SmartSearch besitzt die folgenden technischen Voraussetzungen:
ZooKeeper und Solr sind nicht in der Auslieferung enthalten. Sie müssen daher vor der Installation in der jeweils angegebenen Version heruntergeladen werden. |
Die SmartSearch-Architektur besteht aus den nachfolgenden Komponenten:
Die Datenschutzgrundverordnung (DSGVO) ist eine EU-Verordnung, die das Grundrecht europäischer Bürger auf Privatsphäre schützt und den Umgang mit personenbezogenen Daten regelt. Vereinfacht gesagt, haben alle Personen, von denen Daten erhoben werden, über die DSGVO unter anderem die folgenden Möglichkeiten:
Ausführliche Informationen zur DSGVO finden sich im Blogpost DSGVO - Alles Wichtige auf einen Blick.
Personenbezogene Daten sind alle Informationen, durch die eine natürliche Person direkt oder indirekt identifizierbar ist. Dies schließt jegliche potenziellen Identifizierungsmerkmale ein:
Die Such-Engine SmartSearch speichert Daten als Dokumente, die auf verschiedenen Plattformen zur Verfügung gestellt werden können. Art und Umfang der Daten, im Folgenden "erfasste Daten" genannt, sind abhängig vom Einsatzzweck des Produkts.
Der Hersteller e-Spirit weist ausdrücklich darauf hin, dass es in der Verantwortung des Kunden liegt, erfasste Daten daraufhin zu prüfen, ob sie personenbezogene Daten enthalten und entsprechende Maßnahmen sicherzustellen. |
Neben den redaktionellen Daten speichert die SmartSearch personenbezogene Daten (grundsätzlich die E-Mail, bei Verwendung von LDAP den Username des Benutzers) die zur Anmeldung an dem System und beim Auditieren von Konfigurationen verwendet werden, um gegebenenfalls Kontakt mit einem Bearbeiter eines Elements aufnehmen zu können. Teile dieser Daten werden in Logdateien vorgehalten. Diese Daten werden im Folgenden „Personenbezogene Systemdaten“ genannt (siehe unten).
Die e-Spirit AG nimmt den Schutz und die Sicherheit Ihrer Daten sehr ernst. Selbstverständlich halten wir uns an die gesetzlichen Datenschutzbestimmungen und behandeln personenbezogene Daten aber auch nicht-personenbezogene Daten unserer Nutzer mit entsprechender Sorgfalt. Wir erheben personenbezogene Daten nur dann, wenn sie für die Sicherheit und die Funktionsfähigkeit der SmartSearch notwendig sind.
Nachfolgend informieren wir Sie darüber, welche personenbezogenen Daten wir erheben, wenn Sie die SmartSearch nutzen, und wie wir mit diesen Daten umgehen:
Warum werden die Daten benötigt?
Die SmartSearch arbeitet mit einem durchgängigen Benutzer- und Rechtesystem. Neue Benutzer werden über das Benutzermanagement angelegt und verwaltet. Nach der Erstellung ist der Benutzer auf dem Server bekannt und kann sich (mit einen gültigen Login) über das SmartSearch-Cockpit anmelden. Der Zugriff auf die Konfigurationselemente wird über Gruppenrechte/Rollen erteilt.
Damit ist sichergestellt, dass nur authentifizierte Nutzer Zugriff auf die SmartSearch erhalten und diese Nutzer Elemente nur gemäß der ihnen erteilten Rechte bearbeiten dürfen.
Wo werden die Daten verwendet beziehungsweise angezeigt?
Informationen zum Benutzer werden an diversen Stellen angezeigt, zum Beispiel:
Wo werden die Daten gespeichert?
Die Anmeldeinformationen der einzelnen Benutzer werden grundsätzlich in der Konfigurationskomponente gespeichert. Im Falle von LDAP werden die personenbezogenen Systemdaten nur lesend aus dem LDAP des Kunden geladen.
Wie lange werden die Daten gespeichert?
Bei der Entfernung eines Benutzers über das Benutzermanagement werden die Anmeldeinformationen des Benutzers sofort aus der Konfigurationskomponente entfernt.
Die Deaktivierung eines Nutzers im Benutzermanagement löscht seine Daten nicht. |
Warum werden die Daten benötigt?
Die SmartSearch verwendet Logfiles, um Aktionen und Ereignisse auf dem SmartSearch-Server zu protokollieren. Logfiles werden zur Aufrechterhaltung des sicheren Betriebs erhoben. Sie können verwendet werden, um Fehlerzustände zu analysieren und zu beheben. Einige der von der SmartSearch verwendeten Logfiles enthalten unter anderem IP-Adresse, Login-Namen, Datum, Uhrzeit, Request usw. und damit personenbezogene Daten.
Wo werden die Daten gespeichert?
Grundsätzlich werden Logfiles in das Unterverzeichnis logs
des SmartSearch-Servers geschrieben.
Wie lange werden die Daten gespeichert?
Standardverhalten: Wird eine fest eingestellte Dateigröße von 100 MB erreicht, wird die aktuelle Logdatei archiviert.
Es werden bis zu neun archivierte Dateien behalten.
Wenn dann eine neue Datei archiviert wird, wird die älteste gelöscht.
Dieses Verhalten kann über die Konfigurationsdatei logback-spring.xml
angepasst werden.
Warum werden die Daten benötigt?
Eine Zielsetzung der Datenspeicherung in der SmartSearch ist die Nachvollziehbarkeit der letzten Änderungen, aber auch Informationen über die Erstellung von Konfigurationselementen. Dazu speichert die SmartSearch Auditierungsdaten.
Bei jeder Änderung, die ein Redakteur an Konfigurationselementen (zum Beispiel einer Prepared Search) vornimmt, wird daran vermerkt, wer die letzte Änderung vorgenommen hat und wann. Damit wird eine eventuell bestehende letzte Änderung überschrieben.
Wird ein Konfigurationselement neu angelegt, wird daran vermerkt, wer das Element angelegt hat und wann.
Wo werden die Daten verwendet beziehungsweise angezeigt?
Die Auditierungsdaten (Welcher Benutzer hat wann eine Änderung durchgeführt?) werden in Listenansichten für die Konfigurationselemente angezeigt.
Wo werden die Daten gespeichert?
Die Daten werden an den Konfigurationselementen in der Konfigurationkomponente gespeichert.
Wie lange werden die Daten gespeichert?
Standardverhalten: Bei der Löschung eines Benutzers werden die Referenzen auf diesen anonymisiert. Es ist zudem möglich, nachträglich Referenzen von bereits gelöschten Benutzern zu anonymisieren, für den Fall, dass bei der Löschung nicht das Standardverhalten angewandt wurde. Nach der Anonymisierung wird ein Bericht angezeigt, in welchen Elementen der User anonymisiert wurde. Es werden dazu keine Informationen geloggt. Der Bericht ist die einzige Möglichkeit, Informationen über die Anonymisierung zu bekommen.
Warum werden die Daten benötigt?
Die SmartSearch verwendet im Cockpit Cookies, um die Session des Users zu speichern und zum Schutz vor XSRF-Attacken.
Wo werden die Daten verwendet bzw. angezeigt?
Die Cookies werden im Browser gespeichert und ab dem Einloggen mit jeder Interaktion mit dem Cockpit mitgeschickt.
Wie lange werden die Daten gespeichert?
Die Lebenszeit der Cookies wird auf session
gesetzt.
Für die Verwendung der Funktionalitäten der SmartSearch müssen zunächst die einzelnen Komponenten installiert werden, die beliebig verteilbar und frei skalierbar sind. Es ist essenziell, dass sie in der folgenden Reihenfolge installiert werden, damit die grundlegenden Konfigurationen richtig vorgenommen werden können:
ZooKeeper und Solr sind nicht in der Auslieferung enthalten. Sie müssen daher vor der Installation in der Version, die in den technischen Voraussetzungen genannt ist, heruntergeladen werden. |
Es wird davon abgeraten, die Installation der Komponenten als root auszuführen. Stattdessen wird die Verwendung eines technischen Benutzers mit den entsprechenden Zugriffsrechten empfohlen. Es wird erwartet, dass der Name des technischen Benutzers jeweils dem Namen der Komponente entspricht. Solr legt diesen Benutzer automatisch an. Eine manuelle Erstellung ist daher in diesem Fall nicht notwendig. |
Da die meisten Rechnersysteme auf Linux basieren, konzentrieren sich auch die folgenden Unterkapitel ausschließlich auf die Installation unter Linux. Die angegebenen Befehle beziehen sich dabei auf das folgende System:
Des Weiteren wird für die Installationsbeschreibung das Szenario einer einfachen Redundanz angenommen (vergleiche Abbildung einfache Redundanz). Die zwei auf der folgenden Abbildung dargestellten Knoten N1 und N2 entsprechen zwei physikalischen oder virtuellen Systemen, auf denen jeweils eine ZooKeeper-, Solr- und SmartSearch-Instanz zu installieren ist. Solch ein Cluster-Betrieb aus mindestens zwei Knoten gewährleistet eine grundlegende Ausfallsicherheit und Datenredundanz.
Sind die Aspekte Ausfallsicherheit und Datenredundanz für Sie nicht relevant, lässt sich der gesamte Stack auch auf einem einzigen Knoten installieren. Das Kapitel zum Betrieb eines einzelnen Knotens beschreibt die dafür zu beachtenden Unterschiede. |
Das beschriebene Szenario kann als Grundlage für einen Cluster-Betrieb mit beliebig vielen Knoten angesehen werden.
Im Rahmen der nachfolgenden Kapitel zur Installation der verschiedenen Komponenten werden diverse Ports genannt. Die folgende Tabelle zeigt eine Übersicht über diese Ports und erläutert ihre Bedeutung.
Port | Bedeutung |
---|---|
8181 | Dieser Port ist für das SmartSearch-Cockpit und erlaubt den Zugriff auf die REST API. |
8983 | Dieser Port erlaubt den Zugriff auf die Solr-Oberfläche und die API. |
2181 | Dieser Port ermöglicht die Client-Kommunikation einer ZooKeeper-Instanz. |
2888 | Dieser Port dient der Kommunikation zwischen den ZooKeeper-Instanzen. |
3888 | Dieser Port dient ebenfalls der Kommunikation zwischen den ZooKeeper-Instanzen. |
Für die Sicherung der Konfigurationen von Solr und der SmartSearch ist die Installation und Konfiguration zweier ZooKeeper-Instanzen notwendig,
die nicht in der Auslieferung enthalten sind.
Laden Sie ZooKeeper dafür in der Version, die in den technischen Voraussetzungen angegeben ist, herunter und installieren Sie es auf beiden Systemen in das zu erstellende Verzeichnis ZooKeeper
.
Dieser Ordner kann sich an einer beliebigen Stelle in dem jeweiligen System befinden.
Standardmäßig ist die Annahme, dass sich das zu erstellende Installationsverzeichnis im |
Erzeugen Sie anschließend pro System mit dem folgenden Befehl die notwendige Konfigurationsdatei unter conf/zoo.cfg
.
Anlegen der Konfigurationsdatei (auf beiden System auszuführen).
cp ~/zookeeper/conf/zoo_sample.cfg ~/zookeeper/conf/zoo.cfg
Legen Sie in demselben Verzeichnis eine Datei mit dem Namen java.env
an, um die Menge des ZooKeeper zur Verfügung stehenden Speichers anzupassen.
In dieser Datei müssen Sie die Parameter zur Änderung des Speichers für ZooKeeper angeben.
Anlegen der java.env-Datei (auf beiden Systemen auszuführen).
touch ~/zookeeper/conf/java.env
Standardmäßig speichert ZooKeeper Konfigurationsdaten im tmp
-Verzeichnis.
Da dieses jedoch nur der temporären Speicherung dient, wird stattdessen das im Installationsverzeichnis beider Systeme zu erstellende Verzeichnis ZooKeeper-data
benötigt.
Damit ZooKeeper es für die Persistierung verwendet, ist auf beiden Systemen der Pfad des ZooKeeper-data
-Verzeichnisses in der zoo.cfg
-Datei als Wert des Parameters dataDir
anzugeben.
Ergänzen Sie in derselben Datei die Hostnamen beziehungsweise statischen IP-Adressen aller einzubindenden ZooKeeper-Instanzen.
In diesem Fall entspricht diese Angabe den Hostnamen hostname-n1
und hostname-n2
.
Für die Kommunikation untereinander benutzen die ZooKeeper-Instanzen standardmäßig die Ports 2888
und 3888
.
Die Portangabe nach dem Semikolon bezieht sich auf den Port, auf dem ZooKeeper auf Verbindungen horcht.
Zusätzlich ist die Erlaubnis sogennanter 4 letter words
-Kommandos erforderlich, da Solr diese benötigt.
Bei der beschriebenen Serverkonfiguration wird jedem Server eine ID mitgegeben: Beispielsweise ist in der Angabe server.1
die ID 1
.
Die ID muss einer Zahl zwischen 1 und 255 entsprechen.
Die Definition der Server-ID erfolgt in der im Datenverzeichnis zu erstellenden Datei myid
, die darüber hinaus keinen weiteren Inhalt besitzt.
zoo.cfg - Angabe der ZooKeeper-Instanzen (auf beiden System identisch).
server.1=hostname-n1:2888:3888;2181 server.2=hostname-n2:2888:3888;2181 4lw.commands.whitelist=*
Anschließend lassen sich beide ZooKeeper-Server mithilfe des folgenden Befehls starten.
Starten des ZooKeeper-Servers (auf beiden Systemen auszuführen).
~/zookeeper/bin/zkServer.sh start
Zusätzlich zu den SmartSearch-Konfigurationen werden auch die Einstellungen des Solr-Servers in ZooKeeper gespeichert. Um Konflikte zu vermeiden, ist eine Trennung der Daten notwendig. Dies erreichen Sie durch die Erzeugungen eines leeren Solr-Knotens, den ZooKeeper für die Persistierung der Solr-Dateien nutzt. Der Knoten lässt sich nur mit einem laufenden ZooKeeper-Client erstellen, der anschließend wieder zu beenden ist.
Da ZooKeeper die Daten synchron hält, ist die Erstellung des Solr-Knotens nur auf einer der beiden Instanzen notwendig. Der ebenfalls benötigte SmartSearch-Knoten wird während der Installation des SmartSearch-Servers automatisch erzeugt und muss daher nicht manuell angelegt werden. |
Erzeugung des Solr-Knotens (auf einem System auszuführen).
~/zookeeper/bin/zkCli.sh create /solr "" quit
Kopieren Sie abschließend die ZooKeeper.service
-Datei, die in der Auslieferung im Ordner systemd-samples
enthalten ist, auf beiden Systemen jeweils in das Verzeichnis → → .
Diese ermöglicht, ZooKeeper als Service zu nutzen und über
systemctl
zu steuern.
Es ist zu gewährleisten, dass in der service-Datei jeweils sowohl der Benutzer als auch der Pfad des Installationsverzeichnisses richtig angegeben sind.
Standardmäßig wird der Benutzer |
Die Speicherung der Konfigurationen aus dem Backend der SmartSearch erfolgt ebenfalls in ZooKeeper.
Der Name des root-Knotens lautet dabei standardmäßig haupia
.
So ist eine Trennung zu den Solr-Daten gewährleistet.
Innerhalb dieses Ordners sind die Konfigurationsdaten lesbar gespeichert.
Die vergebenen Namen in der Konfiguration sind gleichzeitig die Namen der Knoten.
Die Persistierung kundenspezifischer Daten, die der SmartSearch-Server sammelt, erfolgt mithilfe zweier Solr-Server.
Diese sind nicht in der Auslieferung enthalten und müssen daher manuell installiert werden.
Laden Sie dafür Solr in der Version, die in den technischen Voraussetzungen angegeben ist, herunter und installieren Sie es auf beiden Systemen in das zu erstellende Verzeichnis Solr
.
Das Verzeichnis kann sich an einer beliebigen Stelle in dem jeweiligen System befinden.
Standardmäßig ist die Annahme, dass sich das zu erstellende Installationsverzeichnis im |
Solr stellt für die Installation das Skript install_solr_service.sh bereit, das Sie zunächst aus der heruntergeladenen Datei extrahieren und anschließend auf beiden Systemen ausführen müssen. Dabei können Sie das Zielverzeichnis für die Persistierung der gesammelten Daten jeweils frei wählen. Das Skript installiert beide Solr-Server als Service, legt auf ihnen den Benutzer solr an und erzeugt zusätzlich alle benötigten Dateien sowie Verzeichnisse.
Für die noch ausstehende Konfiguration müssen sich beide Solr-Server zwingend in einem nicht laufenden Zustand befinden. |
Installation des Solr-Servers (auf beiden System auszuführen).
./install_solr_service.sh solr-8.1.1.tgz -d <VARIABLE_PATH> -n
Beispielsweise für die Speichernutzung benötigen die Solr-Server diverse Java-Variablen.
Diese sind pro System in der Konfigurationsdatei etc/default/solr.in.sh
zu definieren.
Des Weiteren muss in dieser Datei jeweils die Verwendung der Solr-Cloud aktiviert und der Solr-Knoten, der zuvor während der ZooKeeper-Installation erzeugt wurde, angegeben werden.
Vor der Ausführung des Skripts ist sicherzustellen, dass der Solr-Knoten während der ZooKeeper-Installation erzeugt wurde und dort tatsächlich existiert. |
Anpassung der Solr-Konfiguration (auf beiden Systemen auszuführen).
sed -i 's/#ZK_HOST=.*/ZK_HOST=hostname-n1:2181,hostname-n2:2181\/solr/' /etc/default/solr.in.sh
Kopieren Sie abschließend die solr.service
-Datei, die in der Auslieferung im Ordner systemd-samples
enthalten ist, auf beiden Systemen jeweils in das Verzeichnis → → .
Diese ermöglicht, Solr als Service zu nutzen und über
systemctl
zu steuern.
Es ist zu gewährleisten, dass in der Service-Datei jeweils sowohl der Benutzer als auch der Pfad des Installationsverzeichnisses richtig angegeben sind.
Standardmäßig wird eine Installation unter |
Die SmartSearch liefert ein eigenes Schema mit, das auf dem Solr-Server zu installiert ist.
Dafür müssen nach der Solr-Installation, aber vor dem ersten Start, folgende Jar-Dateien zusätzlich im Classpath vorhanden sein.
Diese sind ein Bestandteil der Solr-Auslieferung und im contrib
-Verzeichnis enthalten.
morfologik-stemming-X.Y.Z.jar
morfologik-fsa-X.Y.Z.jar
morfologik-polish-X.Y.Z.jar
lucene-analyzers-morfologik-X.Y.Z.jar
lucene-analyzers-smartcn-X.Y.Z.jar
Die SmartSearch ist eine auf Spring Boot basierende Suchlösung und ermöglicht die Steuerung, Filterung und Analyse von individualisierten Trefferlisten.
Um die Funktionalitäten des SmartSearch-Stacks zu nutzen, ist dieser auf beiden Systemen in das zu erstellende Verzeichnis SmartSearch
zu installieren.
Er wird in Form einer zip-Datei bereitgestellt.
In dem pro System erstellten Installationsverzeichnis ist außerdem die Lizenz abzulegen, die sich vom Technical Support anfordern lässt.
Das Verzeichnis kann an einer beliebigen Stelle in dem jeweiligen System erzeugt werden.
Standardmäßig ist die Annahme, dass sich das zu erstellende Installationsverzeichnis im |
Nach der Installation des SmartSearch-Stacks ist auf beiden Systemen die Durchführung der folgenden Konfigurationsschritte notwendig:
data
.
Dieses ist innerhalb des jeweiligen Installationsverzeichnisses manuell zu erstellen.
Die in der Auslieferung enthaltene application.yml
-Datei ermöglicht die Konfiguration des jeweiligen SmartSearch-Servers.
Dabei sind insbesondere die folgenden Punkte zu beachten:
8181
.
Diesen können Sie jedoch pro System optional anpassen.
connection
des Keys ZooKeeper
die Adresse des entsprechenden ZooKeeper-Servers bekannt gemacht werden.
data
muss dem SmartSearch-Stack ebenfalls bekannt gemacht werden.
Dafür ist in der zugehörigen application.yml
-Datei der Parameter root
des Keys haupia
entsprechend anzupassen.
server.address
anzugeben.
Erfolgt keine Angabe, ist eine Verwendung des SmartSearch-Cockpits nicht möglich.
haupia.zookeeper.users.cache.await
definiert die Zeitspanne in Sekunden, in der auf eine solche Aktualisierung gewartet wird.
Initial entspricht der Standardwert einem Timeout von einer Sekunde.
urlScheme
.
Ist dieser Wert nicht gesetzt, wird standardmäßig http
verwendet.
Der Parameter solr.url.scheme
ermöglicht eine Überschreibung des Verhaltens und muss den Wert http
oder https
besitzen.
solr.auth.username
und solr.auth.password
anzugeben.
haupia.connect.datagenerator.pool.size
die Konfiguration, auf wie viele FirstSpirit-Projekte in Form eines eigenen Datengenerators reagiert werden muss.
Ist der Wert kleiner als die Anzahl der angebundenen FirstSpirit-Projekte, so können nicht von allen Projekten Daten empfangen werden.
Ist dieser Wert nicht gesetzt, so gilt ein Maximum von Anzahl der Kerne x 500
.
server.servlet.session.timeout
.
Mögliche Werte für ihn sind zum Beispiel 60s
oder 1h
.
Der Default-Timeout liegt bei 15 Minuten.
Der Master-Admin wird beim initialen Start des ersten SmartSearch-Servers automatisch erzeugt und muss daher für alle Instanzen dieselben Daten besitzen.
Er ist weder deaktivier- noch löschbar und verhindert so ein Aussperren aus dem SmartSearch-Cockpit.
Das Master-Admin-Passwort kann im SmartSearch-Cockpit geändert werden.
Ein Start des SmartSearch-Servers mit dem optionalen Parameter |
-Dhaupia.master.profile=STANDALONE
.
Dieser ist standardmäßig in der mitgelieferten server.conf
-Datei enthalten und darf nicht geändert werden.
Darüber hinaus lassen sich in dieser Datei unter anderem das Encoding und der Modus der Java Virtual Machine bestimmen.
Diese sind ebenfalls bereits gesetzt und lassen sich bei Bedarf anpassen.
Zusätzlich bietet die Datei die Möglichkeit, die Speichernutzung des jeweiligen SmartSearch-Servers zu definieren.
Starten Sie den SmartSearch-Stack des ersten Systems über das in der zip-Datei enthaltene server.jar
.
Diese enthält ein Launch-Skript, welches den Einsatz der jar-Datei als Unix-Service ermöglicht.
Erst, wenn die Logdatei der ersten SmartSearch-Instanz die folgende Meldung über den erfolgreichen Start enthält, darf die zweite Instanz analog gestartet werden:
Logmeldung.
less /opt/SmartSearch/logs/SmartSearch.log (...) Started Server in 60 seconds (JVM running for 61.2)
Bei einem direkten Start der MODE=service ./server.jar start |
Kopieren Sie abschließend die smart-search.service
-Datei, die in der Auslieferung im Ordner systemd-samples
enthalten ist, auf beiden Systemen jeweils in das Verzeichnis → → .
Diese ermöglicht, die SmartSearch als Service zu nutzen und über
systemctl
zu steuern.
Es ist zu gewährleisten, dass in der service-Datei jeweils sowohl der Benutzer als auch der Pfad des Installationsverzeichnisses richtig angegeben sind.
Standardmäßig wird der Benutzer SmartSearch sowie eine Installation unter |
Die installierten und konfigurierten SmartSearch-Instanzen kommunizieren miteinander und führen eine sogenannte Leader Election durch, mit der die führende Instanz festgelegt wird. Während sich der REST-Service auf allen laufenden Instanzen identisch verhält, lässt sich das SmartSearch-Cockpit ausschließlich auf dem Leader aufrufen. Dies hat zur Folge, dass sowohl die Konfiguration als auch die automatische beziehungsweise manuelle Ausführung der Datengeneratoren ebenfalls lediglich auf der führenden Instanz möglich ist.
Bei dem Versuch das Cockpit über eine andere Instanz als dem Leader anzusprechen, erfolgt eine automatische Weiterleitung. Diese Weiterleitung wird durch eine an ZooKeeper adressierte Leader-Abfrage realisiert. Dem ZooKeeper muss dafür der Host-Name jeder einzelnen Instanz bekannt sein.
Darüber hinaus muss die SmartSearch-Lizenz in einer Textdatei auf dem SmartSearch-Server hinterlegt sein.
Die Beantragung der Lizenz erfolgt über den Technical Support der e-Spirit AG.
Der folgende Key ermöglicht, in der application.yml
-Datei auf diese Lizenzdatei zu verweisen:
Verweis zur SmartSearch-Lizenz.
haupia: licence: path: ./license.txt
Die SmartSearch basiert auf Spring Boot und lässt sich über die application.yml
-Datei, die im SmartSearch-Verzeichnis neben der server.jar
-Datei liegt, konfigurieren.
Die application.yml
-Datei bietet eine Vielzahl von Konfigurationsmöglichkeiten, die in der Spring-Boot-Dokumentation beschrieben sind.
Beispielsweise stellt sie die Möglichkeit bereit, Logging- und Sicherheitseinstellungen vorzunehmen.
Das nachfolgende Beispiel erläutert die Konfiguration von SSL, die einen häufigen Anwendungsfall darstellt.
Beispiel: SSL-Konfiguration
Die SmartSearch nutzt standardmäßig SSL, um eine sichere Übertragung der Daten zu ermöglichen, und verwendet dabei den Spring-Boot-Jetty.
Dies funktioniert in den meisten Fällen.
Bei der Wahl des Protokolls oder der Verschlüsselung können aber Problemen auftreten.
Die Spring-Boot-Dokumentation beschreibt die Konfigurationsschlüssel server.ssl.enabled-protocols
und server.ssl.ciphers
, mit denen sich etwaige Probleme lösen lassen.
Um zunächst eine Liste möglicher Parameter zu bekommen, muss das Logging für Jetty an der richtigen Stelle auf DEBUG
gesetzt werden.
Dazu ist der application.yml
-Datei folgende Konfiguration hinzuzufügen:
Konfiguration des Jetty-Loggings.
logging: level: org: eclipse: jetty: util: ssl: DEBUG
Nach der Konfiguration des Loggings und einem Neustart enthält das Log am Ende des Startvorgangs eine DEBUG
-Ausgabe, die ungefähr folgendes Aussehen besitzt:
Beispiel für eine DEBUG-Ausgabe der SSL-Informationen des Jettys.
May 22 11:14:50 smart-search-cluster-1 server.jar[1208]: 2017-05-22 11:14:50.621 DEBUG 1230 --- [ main] o.e.jetty.util.ssl.SslContextFactory : Selected Protocols [TLSv1, TLSv1.1, TLSv1.2] of [SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2] May 22 11:14:50 smart-search-cluster-1 server.jar[1208]: 2017-05-22 11:14:50.622 DEBUG 1230 --- [ main] o.e.jetty.util.ssl.SslContextFactory : Selected Ciphers [TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, [...] May 22 11:14:50 smart-search-cluster-1 server.jar[1208]: A, SSL_DH_anon_WITH_DES_CBC_SHA, [...]
Diese zwei Logausgaben geben die aktuellen Werte für das Protokoll und die Verschlüsselung sowie die möglichen Werte aus.
Um die Verschlüsselung bei Bedarf auf zwei Verschlüsselungsverfahren zu begrenzen, ist die application.yml
-Datei wie folgt anzupassen:
Konfiguration der SSL-Verschlüsselungsverfahren.
server: ssl: ciphers: TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
Gleiches gilt für das verwendete Protokoll. Nach einer erfolgreichen Konfiguration ist diese bei einem Neustart in den Logs zu finden.
Nach der Installation ZooKeepers, Solrs und der SmartSearch sind in der Solr-Weboberfläche abschließend die nachfolgenden Schritte durchzuführen. Sie ermöglichen auf beiden Solr-Instanzen die automatische Replikation der Daten, die die SmartSearch für die Beantwortung von Suchabfragen benötigt.
Die beschriebenen Schritte beziehen sich lediglich auf den beschriebenen Cluster-Betrieb mit mindestens zwei Knoten. Für den Betrieb eines einzelnen Knotens sind sie ignorierbar. |
Öffnen Sie über die URL http://hostname-<INSTANCE>:8983
zunächst die Solr-Weboberfläche auf einem der beiden Systeme und wählen Sie den Menüpunkt Collections
.
Die Weboberfläche zeigt daraufhin eine Liste aller existierenden Collections.
Selektieren Sie in dieser Liste die Collection, die den Namen des Mandanten trägt, und klicken Sie auf den Punkt .
Mithilfe des Buttons No specified node
und erzeugen sie die Replika über den Button .
Solr wählt dabei automatisch einen freien Knoten aus.
Laden Sie Weboberfläche nach der Erstellung der Replika neu und überprüfen Sie die Existenz der zweiten Replika über einen Klick auf den Punkt
.Wiederholen Sie die beschriebenen Schritte anschließend mit der Collection, die den Suffix _signals
besitzt.
Sind die Aspekte Ausfallsicherheit und Datenredundanz für den Betrieb der SmartSearch nicht relevant, lässt sich der gesamte Stack auch auf einem einzigen Knoten installieren.
Die Installation der einzelnen Instanzen erfolgt analog zur Beschreibung in den vorhergehenden Kapiteln. Allerdings sind die folgenden Unterschiede zu beachten:
zoo.cfg
-Dateien aller Systeme die Hostnamen bzw. statischen IP-Adressen aller einzubindenden ZooKeeper-Instanzen angegeben werden.
Diese Angabe entfällt im Fall eines einzelnen Knotens.
Die Anpassung der Solr-Konfiguration erfolgt über das Skript solr.in.sh
.
Der Befehl für dessen Ausführung lautet in diesem Fall wie folgt:
Anpassung der Solr-Konfiguration für den Betrieb eines einzelnen Knotens.
sed -i 's/#ZK_HOST=.*/ZK_HOST=localhost:2181\/solr/' /etc/default/solr.in.sh
Die Verwaltung der für die Nutzung der SmartSearch notwendigen Benutzer und Gruppen sowie die Definition der Berechtigungen findet standardmäßig innerhalb des SmartSearch-Cockpits statt. Die Speicherung der Benutzer und Gruppen erfolgt über den zuvor installierten ZooKeeper-Server.
Alternativ dazu besteht jedoch die Möglichkeit, die Benutzer- und Gruppenverwaltung auf Basis von LDAP umzusetzen. Dabei ist zu beachten, dass sich diese Möglichkeit nur auf die Authentifizierung (Benutzer und Gruppen), nicht jedoch auf die Autorisierung (ACLs) bezieht.
Die Anbindung LDAPs stellt lediglich einen lesenden Zugriff auf den LDAP-Server her. Eine Verwaltung der Benutzer und Gruppen innerhalb des SmartSearch-Cockpits ist anschließend nicht mehr möglich. |
Für die Nutzung LDAPs müssen auf dem LDAP-Server die folgenden Aspekte gegeben sein:
Erfolgt die Verwaltung der Benutzer und Gruppen über das SmartSearch-Cockpit, stellt es für den allerersten Login und die initiale Zuweisung von Berechtigungen einen Master-Admin bereit.
Äquivalent dazu wird auch LDAP-seitig ein solcher Master-Admin vorausgesetzt.
Dieser muss der ebenfalls benötigten Gruppe ADMIN
zugeordnet sein.
Es ist zu beachten, dass jeder in der Admin-Gruppe enthaltene Benutzer uneingeschränkt die Berechtigungen innerhalb des SmartSearch-Cockpits bearbeiten darf. |
Der erfolgreiche Login eines Benutzers setzt voraus, dass dem SmartSearch-Cockpit der LDAP-seitig verwendete Passwort-Encoder bekannt ist.
Dieser kann daher im Passwortfeld in der Form {id}hash
angegeben werden.
Die Id entspricht dabei der Id des Hashing-Algorithmus' und muss einem der folgenden Werte entsprechen:
Alternativ besteht die Möglichkeit, den Passwort-Encoder in der |
Zusätzlich zu den LDAP-seitigen Anpassungen sind in der application.yml
-Datei des SmartSearch-Servers die folgenden Pflichtparameter anzugeben:
haupia.ldap.enable
haupia.ldap.enable
ist auf true
zu setzen.
spring.ldap.username
und spring.ldap.password
spring.ldap.username
und spring.ldap.password
angegeben werden.
haupia.ldap.user-search-base
bzw. haupia.ldap.group-search-base
haupia.ldap.user-search-base
bzw. haupia.ldap.group-search-base
anzugeben.ou=people,dc=example,dc=org
bzw. ou=groups,dc=example,dc=org
)
Die Suche nach Benutzer- bzw. Gruppenobjekten bezieht sich ausschließlich auf die angegebene Ebene. Subtrees sind von dieser Suche ausgeschlossen. |
Zusätzlich zu diesen Pflichtangaben lassen sich darüber hinaus optional weitere Anpassungen vornehmen:
spring.ldap.urls
ldap://localhost:389
.
spring.ldap.base
haupia.ldap.user-filter
uid={0}
.
Der Platzhalter {0}
wird dabei durch den eingegebenen Benutzernamen ersetzt.
haupia.ldap.group-filter
(member={0})
.
Der Platzhalter {0}
wird in diesem Fall durch den Distinguished Name (DN) des entsprechenden Benutzers ersetzt.
haupia.ldap.default-password-encoder
bcrypt
.
haupia.ldap.user-attributes.uid
und haupia.ldap.user-attributes.password
uid
und userPassword
.
haupia.ldap.user-attributes.language
und haupia.ldap.user-attributes.default-language
language
-Parameters lässt sich steuern, in welcher Sprache das SmartSearch-Cockpit startet.
Fehlt er, wird stattdessen der Wert des default-language
-Parameters verwendet.
Dieser definiert als Default-Sprache initial Englisch.
haupia.ldap.group-attributes.name
und haupia.ldap.group-attributes.user
cn
und member
.
Die Gruppennamen werden im SmartSearch-Cockpit grundsätzlich in Großbuchstaben angezeigt, auch wenn sie LDAP-seitig eine andere Schreibweise besitzen. |
LDAP-Parameter in der application.yml.
spring: [...] ldap: urls: ldap://localhost:389 password: admin username: cn=admin,dc=example,dc=org base: dc=example,dc=org [...] haupia: [...] ldap: enable: false user-search-base: ou=people,dc=example,dc=org user-filter: uid={0} group-search-base: ou=groups,dc=example,dc=org group-filter: (member={0}) default-password-encoder: bcrypt user-attributes: uid: uid password: userPassword language: language default-language: en group-attributes: name: cn user: member
Sollte ein http(s)-Proxy nötig sein, damit die Web/XML-Crawler Zugriff auf ihre Crawl-Ziele haben, so lässt dieser sich per JAVA_OPTS konfigurieren. Die relevanten Parameter zur Konfiguration sind die folgenden:
Parameter | Beschreibung | Wert |
---|---|---|
http|https.proxyHost | Host für den http(s)-Proxy | 12.13.14.15 |
http|https.proxyPort | Port für den http-Proxy | 8080 |
http.nonProxyHosts | Ausnahmen, bei denen der Proxy nicht berücksichtigt werden soll. | localhost |
Exemplarischer Eintrag in der server.conf-Datei.
JAVA_OPTS="-server -Dhaupia.master.profile=STANDALONE -Dfile.encoding=UTF-8 -Dhttp.proxyHost=12.13.14.15 -Dhttp.proxyPort=8080 -Dhttps.proxyHost=12.13.14.15 -Dhttps.proxyPort=8080 -Dhttp.nonProxyHosts=localhost|127.0.0.1"
Die Verarbeitung der von der SmartSearch gesammelten Daten setzt eine Kommunikation zwischen den einzelnen Komponenten sowie der Endanwendung des Kunden voraus. Die Kommunikation des SmartSearch-Stacks nach außen ist dabei per SSL geschützt. Der SmartSearch-Server verwendet dafür standardmäßig ein selbstsigniertes Zertifikat, das in der Auslieferung enthalten ist.
Das in der Auslieferung enthaltene, selbstsignierte Zertifikat ist lediglich für den Einsatz in lokalen Entwicklungsumgebungen ausgerichtet. Für den Einsatz des SmartSearch-Stacks im Produktivbetrieb wird daher die Verwendung eines offiziell signierten Zertifikats dringend empfohlen. |
Die Durchführung der nachfolgenden Schritte setzt voraus, dass bereits ein offiziell signiertes Zertifikat angefordert wurde und die Datei |
Für den Einsatz des SmartSearch-Stacks im Produktivsystem ist zunächst ein neuer Keystore zu erzeugen. Dieser muss dem Server bekannt gemacht werden, um die bereits vorhandenen Zertifikate zu ersetzen. Der nachfolgende Befehl zeigt ein Beispiel für die Erzeugung des neuen Keystores:
Erzeugung des neuen Keystores.
openssl pkcs12 -export -in server.crt -inkey server.key -out server.p12 -name server -CAfile ca.crt -caname root
Der Befehl bewirkt eine Konvertierung des x509-Zertifikats und des zugehörigen Keys in eine pkcs12-Datei.
Das dabei zu vergebene Passwort ist in der application.yml
-Datei unter dem Parameter key-store-password
des Keys ssl
anzugeben.
An derselben Stelle muss der neu erstellte Keystore für den Parameter key-store
sowie das keyAlias server
definiert werden.
SSL-Parameter.
ssl: key-store: server.p12 key-store-password: PASSWORD keyStoreType: PKCS12 keyAlias: server
Das SmartSearch-Cockpit ist ein Bestandteil der SmartSearch.
Es dient der Backend-seitigen Verwaltung der durch die SmartSearch erfassten Daten und bietet dafür eine einfache, webbasierte Oberfläche an.
Diese gliedert sich in die Bereiche Konfiguration
, Analyse
, Daten
und System
, die über das Menü zu erreichen sind.
Der Button mit dem Weltkugel-Icon stellt darüber hinaus einen Sprachumschalter zwischen Deutsch und Englisch bereit.
Das SmartSearch-Cockpit ist standardmäßig unter der folgenden URL erreichbar:
Der erste Aufruf des Cockpits muss mit dem Master-Admin erfolgen.
Er wird beim initialen Start des SmartSearch-Servers automatisch mit den Daten aus der application.yml
erzeugt.
Ist die Benutzer- und Gruppenverwaltung über einen LDAP-Server realisiert, können die Zugangsdaten abweichen. |
Nach der validen Eingabe wird der Benutzer automatisch auf das Dashboard des Cockpits weitergeleitet. Eine erneute Authentifizierung ist erst nach einer expliziten Abmeldung oder nach dem Ablauf einer Sitzung erforderlich.
Der Bereich Konfiguration
gliedert sich in die Untermenüs Prepared Search
, Stoppwörter
und Synonyme
.
Diese ermöglichen die Konfiguration der Ausgabe der von der SmartSearch erfassten Daten.
Die nachfolgenden Unterkapitel beschreiben die Untermenüs und die durch sie zur Verfügung gestellten Funktionen.
Die kundenseitige Erfassung der benötigten Daten erfolgt über die sogenannten Datengeneratoren, die ein Bestandteil des Bereichs Daten
sind.
Für ihre Verwaltung stellt die SmartSearch die Prepared Searches zur Verfügung.
Diese ermöglichen die Optimierung der Suchergebnisse durch die Priorisierung einzelner Daten.
Die Erstellung und Verwaltung der Prepared Searches erfolgt in der gleichnamige Oberfläche, die über den Menübereich →
aufrufbar ist.
Der Bereich zeigt eine Liste aller bereits existierenden Prepared Searches und ist initial leer.
Im Cloud-Modus wird in der Liste außerdem die Erreichbarkeit jeder Prepared Search angezeigt. |
Neue Prepared Search
Für die Erstellung einer neuen Prepared Search existiert eine eigene Ansicht, die per Klick auf den Button Allgemein
und Facetten
gliedert.
Innerhalb des Tabs Allgemein
ist zunächst ein Name für die neu zu erstellende Prepared Search anzugeben.
Im Cloud-Modus befindet sich neben dem Eingabefeld für den Namen die zusätzliche Checkbox öffentlich Erreichbar
, mit welcher die Erreichbarkeit einer Prepared Search definierbar ist.
Die Aktivierung der Checkbox ermöglicht die Abfrage der Prepared Search über das Internet.
Ansonsten ist die Prepared Search nur so erreichbar, wie es das Cockpit auch ist.
Die anschließende Selektion beliebig vieler Datengeneratoren in der gleichnamigen Auswahlliste zeigt deren verfügbare Felder.
Die initial aktivierte Checkbox Verbose
blendet dabei alle technischen Felder ein bzw. aus.
Die zusammen mit der Checkbox bereitgestellte Schaltfläche ermöglicht die Gewichtung der ausgewählten Felder.
Die ausgewählten Felder lassen sich per Button in die Liste der für eine Suche relevanten Felder übernehmen, die standardmäßig die Felder content
,link
und title
enthält.
Eine zuvor definierte Gewichtung wird dabei automatisch jedem dieser Felder zugeordnet.
Durchsuchen: Damit das zugehörige Feld von der Suche berücksichtigt wird, ist diese Checkbox zu aktivieren.
Die Deaktivierung der Option |
Strom
beispielsweise auch den Treffer Ökostromanbieter
.
Das Suchwort muss dabei eine Länge von drei bis zwanzig Zeichen besitzen.
Gewichtung: Die Gewichtung bietet die Möglichkeit, für Treffer der ausgewählten Felder eine Priorisierung festzulegen und damit das Suchergebnis zu beeinflussen.
Der Button mit dem Symbol eines Mülleimers, der für jedes Feld verfügbar ist, erlaubt die Löschung des entsprechenden Felds aus der Liste.
page
lässt sich außerdem eine Aufteilung der Suchergebnisse auf mehrere Seiten realisieren.
ASC
für eine aufsteigende oder DESC
für eine absteigende Sortierung zu ergänzen.
Must Match: Für die Suche nach mehreren Begriffen legt die Eingabe dieses Texteingabefelds fest, wie diese zu verknüpfen sind:
0
entspricht einer Oder-Beziehung zwischen den verwendeten Suchbegriffen.
100%
entspricht einer Und-Beziehung zwischen den verwendeten Suchbegriffen.
absoluter Wert
definiert die Anzahl der Begriffe, die in einem Suchtreffer enthalten sein müssen.
Der Wert 2
bei fünf Suchbegriffen besagt beispielsweise, dass zwei der fünf Ausdrücke innerhalb eines Suchergebnisses enthalten sein müssen.
Die Werte 2
und 50%
sind bei vier Suchbegriffen äquivalent zueinander.
Facetten bieten die Möglichkeit, Trefferlisten nach Feldern, die in einem Dokument vorhanden sind, einzuschränken.
Da sich Facetten immer auf die im Tab Allgemein
selektierten Datengeneratoren beziehen, ist der Tab Facetten
initial leer.
Neue Facette
Für die Erstellung einer neuen Facette existiert eine eigene Ansicht, die per Klick auf den Button Allgemein
mindestens ein Datengenerator definiert ist.
Innerhalb des Tabs ist im gleichnamigen Dropdown zunächst ein Feld auszuwählen. Die verfügbaren Felder stammen dabei aus den selektierten Datengeneratoren. Mit der Auswahl des Felds erscheint eine Liste der diesem Feld zugehörigen Werte, für die folgende Konfigurationsmöglichkeiten verfügbar sind:
Eigenen Filter exkludieren: Um für die Suche verschiedene Filteroptionen bereitzustellen, darf sich die Auswahl eines Filters nur auf die Suchergebnisliste, aber nicht auf die Filteroptionen beziehen. Andernfalls würden die übrigen Optionen durch die Suche ebenfalls ausgeblendet.
Existieren für die Facette Sprache
beispielsweise die Filteroptionen Deutsch
, Englisch
und Französisch
liefert die Suche bei der Auswahl der Option Englisch
nur noch englische Dokumente zurück.
Wird der Filter Englisch
in diesem Fall nicht exkludiert, zeigt auch die Liste der zur Verfügung stehenden Filter nur noch Englisch
an.
In diesem Fall ist es nicht mehr möglich, auf einen Filter zu wechseln oder in Zusammenhang mit der vorhergehenden Konfigurationsmöglichkeit eine Mehrfachauswahl zu treffen.
Liste bestehender Prepared Searches
Nach der Speicherung und erfolgreichen Erzeugung der Prepared Search wird sie der Liste bestehender Prepared Searches im gleichnamigen Bereich hinzugefügt. Die Liste gliedert sich in zwei Spalten mit den folgenden Informationen:
Prepared Search bearbeiten
Der Button mit dem Symbol eines Stifts ermöglicht die Bearbeitung einer Prepared Search. Ein Klick auf ihn öffnet die Detailansicht mit den vorgenommenen Eingaben. Diese lassen sich entsprechend der zuvor beschriebenen Möglichkeiten verändern.
Prepared Search löschen
Der Button mit dem Symbol eines Mülleimers ermöglicht die Löschung einer Prepared Search. Ein Klick auf diesen Button öffnet einen Dialog mit einer Sicherheitsabfrage, mit der die Löschung zu bestätigen ist.
Alternativ besteht über Checkboxen, die in der Übersichtsliste vor jeder Prepared Search sichtbar sind, die Möglichkeit, mehrere Prepared Searches für die Löschung auszuwählen.
Der Button Ausgewählte löschen
entfernt diese markierten Prepared Searches, nachdem zuvor ebenfalls eine Sicherheitsabfrage bestätigt wurde.
Jeder geschriebene Text enthält Artikel, Füllwörter und weitere Begriffe, die für eine Suchabfrage irrelevant und daher zu ignorieren sind.
Aus diesem Grund besitzt die SmartSearch für jede der 26 unterstützten Sprachen eine Liste sogenannter Stoppwörter, die sie im Menübereich →
in Form eines Drop-Down-Menüs bereitstellt.
Die in diesen Listen enthaltenen Begriffe werden bei der Erfassung der Daten durch die Datengeneratoren ignoriert und nicht in den Suchindex aufgenommen.
Für die Bearbeitung einer Stoppwörter-Liste ist sie zunächst in dem Drop-Down-Menü zu selektieren. Die Oberfläche zeigt daraufhin alle in ihr enthaltenen Stoppwörter an.
Das Feld Neue Stoppwörter hinzufügen
ermöglicht die kommaseparierte Eingabe weiterer Stoppwörter, die per Klick auf den Button mit dem Plus-Symbol in die Liste übernommen werden.
Die Buttons mit dem Symbol eines Stifts bzw. eines Mülleimers, die pro Stoppwort sichtbar sind, erlauben die Bearbeitung bzw. Löschung eines einzelnen Eintrags der Liste.
Jede Änderung an der selektierten Liste erfordert abschließend eine Speicherung über den Button mit dem Symbol eines Hakens, der neben dem Drop-Down-Menü dargestellt ist. Erst mit diesem Klick erfolgt eine Übernahme der Anpassungen, auch wenn sie zuvor bereits in der Liste sichtbar sind.
Damit die Änderungen an den Stoppwörter-Listen berücksichtigt werden, ist ein erneuter Durchlauf der Datengeneratoren notwendig. |
Äquivalent zu den Stoppwörtern, mit denen sich irrelevante Begriffe aus dem erfassten Datenbestand herausfiltern lassen, ermöglichen die Synonyme die Ergänzung spezifischer Bezeichnungen.
Im Menübereich →
stellt die SmartSearch für jede der 26 unterstützten Sprachen eine Liste sogenannter Synonyme zur Verfügung.
Die Listen sind initial leer und werden in Form eines Drop-Down-Menüs bereitgestellt.
Für die Ergänzung von Begriffen zu einer dieser Listen ist sie zunächst in dem Drop-Down-Menü zu selektieren. Enthält sie bereits Synonyme, werden diese daraufhin angezeigt.
Das Feld Neue Synonyme hinzufügen
ermöglicht die kommaseparierte Eingabe weiterer Synonyme, deren Übernahme in die Liste per Klick auf den Button mit dem Plus-Symbol erfolgt.
Über das Feld Add a tag
lassen sich ihnen jeweils die entsprechenden Ersetzungen zuordnen.
In Bezug auf die Ersetzungen ist zu beachten, dass zukünftige Suchabfragen das Suchwort ignorieren und nur noch die ihm zugeordneten Ersetzungen berücksichtigen. Soll das Suchwort ebenfalls in die Suchabfragen einbezogen werden, muss es sich selbst als Ersetzung hinzugefügt werden.
|
Des Weiteren erlauben die Buttons mit dem Symbol eines Stifts bzw. eines Mülleimers, die pro Suchwort sichtbar sind, die Bearbeitung bzw. Löschung eines einzelnen Eintrags in der Liste.
Jede Änderung an der selektierten Liste erfordert abschließend eine Speicherung über den Button mit dem Symbol eines Hakens, der neben dem Drop-Down-Menü dargestellt ist. Erst mit diesem Klick erfolgt eine Übernahme der Anpassungen, auch wenn sie zuvor bereits in der Liste sichtbar sind.
Der Bereich Analyse
glieder sich in die Untermenüs Statistiken
und Adaptable Results
.
Sie ermöglichen sowohl die Analyse der getätigten Suchabfragen als auch die manuelle Steuerung der Trefferreihenfolge für einzelne Suchbegriffe.
Die nachfolgenden Unterkapitel beschreiben die Untermenüs und die durch sie zur Verfügung gestellten Funktionen.
Der Bereich Statistiken
ermöglicht die Analyse der Suchanfragen einer spezifischen Prepared Search.
Das gleichnamige Feld listet dafür alle bestehenden Prepared Searches auf, aus der die zu analysierende Prepared Search per Checkbox auszuwählen ist.
Alle fünfzehn Minuten erfolgt eine automatische Aktualisierung der zu analysierenden Daten, so dass die Analyse jederzeit auf einem möglichst aktuellen Datenbestand basiert. |
Die nachfolgenden Felder dienen der Spezifizierung der zu analysierenden Daten:
Anzahl Ergebnisse
zeigt an, ob für die Analyse die 10, 25, 50 oder 100 meistgesuchten Suchwörter ausgegeben werden sollen.
Von
und Bis
legen den zu berücksichtigenden Zeitraum fest.
Tags
ermöglicht die Anpassung der Statistik durch spezifische Filterkriterien.
Sie dienen der Kategorisierung von Suchabfragen und lassen sich während deren Ausführung definieren.
Standardmäßig erfolgt die Eingabe der Tags in der Basic-Ansicht, in der sie durch einfaches Anklicken auswählbar sind.
Alle ausgewählten Tags sind durch eine Und
- bzw. Oder
-Verknüpfung miteinander verbunden.
Der Button erlaubt darüber hinaus den Wechsel zu einer komplexeren Eingabe der Tags.
Ein Wechsel von der Basic- zur Advanced-Eingabe ist jederzeit möglich. Der Wechsel in die andere Richtung ist nur dann durchführbar, wenn sich die eingegebene Filterung in der Basic-Eingabe abbilden lässt. |
Der Button
führt die Ermittlung der häufigsten Suchwörter aus, die sich anhand der vorgenommenen Konfiguration für die ausgewählte Prepared Search ergeben. Sie werden anschließend als Liste in der Oberfläche angezeigt.Der Button
stellt sowohl die definierten Konfigurationsdaten als auch die auf ihrer Basis ermittelten Suchwörter in Form einer CSV-Datei bereit. Sie enthält zusätzlich zu diesen Informationen einen Deeplink und die absolute Summe aller Suchanfragen - mit und ohne Filterung. Der Deeplink ermöglicht den erneuten Download der Datei.Den in der CSV enthaltenen Deeplink stellt auch der Button Statistiken
inklusive der vorgenommenen Konfiguration erneut aufrufen lässt.
Auf diesem Weg können sowohl die Einstellungen als auch das auf ihnen basierende Ergebnis Dritten zur Verfügung gestellt werden.
Die Speicherung der durch die SmartSearch ermittelten Inhalte geschieht in einer Vielzahl unterschiedlicher Felder. Diesen lässt sich während der Konfiguration einer Prepared Search eine Gewichtung zugeordnen, um sie so unterschiedlich zu priorisieren. Sie erhalten dadurch einen sogenannten Score, der automatisch berechnet wird und jeweils die Reihenfolge einer Suchergebnisliste bestimmt. Die manuelle Steuerung dieser Suchergebnislisten, den sogenannten Adaptable Results, erfolgt im gleichnamigen Bereich.
Der Bereich zeigt eine Liste aller bereits bestehenden Adaptable Results, die jeweils der Suchabfrage zu einem Suchwort einer Prepared Search entsprechen.
Adaptable Result anlegen
Für die Erstellung eines neuen Adaptable Results existiert eine eigene Ansicht, die per Klick auf den Button
aufrufbar ist.Innerhalb der Ansicht ist eine Prepared Search auszuwählen und ein beliebiger Suchbegriff einzugeben, für den die Reihenfolge der Suchergebnisse verändert werden soll. Ein Klick auf den Button
deaktiviert die beiden Felder und ermittelt anhand der Angaben die zugehörige Ergebnisliste, die in Form einer Tabelle angezeigt wird. Der Button blendet die Tabelle aus und aktiviert die beiden Felder wieder.Neben dem Titel, dem Link und den ausgewerteten Tokens des dargestellten Dokuments zeigt jeder Eintrag in der Tabelle den ihm zugeordneten Score, aus dem sich seine Position in der Liste ergibt. Diese ist über die ebenfalls pro Eintrag angezeigten Buttons
und beeinflussbar:
Sowohl Elevations als auch Exclusions basieren auf Links, die zu einem bestimmten Zeitpunkt im Index vorhanden sind. Durch die Veränderung der Suchergebnisliste kann es daher zu Situationen kommen, in denen die Links nicht mehr verfügbar und somit vom Datengenerator nicht mehr erfassbar sind. Aufgrund ihrer fehlenden Entsprechung im Index sind diese Links nicht mehr in der Listenansicht anzeigbar. Es handelt sich bei ihnen um sogenannte verwaiste Elevations bzw. Exclusions. Im Fall solcher Einträge erscheint in der Detailansicht eines Adaptable Results eine Warnung. Diese listet die verwaisten Links und ihre Dokumenten-IDs auf. Die Aktivierung des Häkchens unter der Warnung löst eine Bereinigung bei der Speicherung aus. |
Das Feld Seite manuell hinzufügen
ermöglicht die manuelle Ergänzung zusätzlicher Dokumente durch die Angabe ihrer URL.
Diese müssen bereits im Index der Datengeneratoren, die der ausgewählten Prepared Search zugeordnet sind, enthalten sein.
Die Eingabe der entsprechenden URL muss in der Form http[s]://www.newdocument.com
zu erfolgen und ist mit dem Plus-Button zu bestätigen.
Ist das Dokument im Index enthalten, wird es der Ergebnisliste hinzugefügt.
Andernfalls erscheint ein entsprechender Hinweis.
Jede Änderung an der Suchergebnisliste ist mithilfe des
-Buttons zu persistieren. Erst mit diesem Klick werden die Anpassungen übernommen, auch wenn sie zuvor bereits in der Liste sichtbar sind.Liste bestehender Adaptable Results
Nach der Speicherung und erfolgreichen Erzeugung des Adaptable Results wird es der Liste bestehender Adaptable Results im gleichnamigen Bereich hinzugefügt. Die Liste gliedert sich in drei Spalten mit den folgenden Informationen:
Adaptable Result bearbeiten
Der Button mit dem Symbol eines Stifts ermöglicht die Bearbeitung eines Adaptable Results. Ein Klick auf ihn öffnet die Detailansicht mit den vorgenommenen Eingaben. Diese lassen sich entsprechend der zuvor beschriebenen Möglichkeiten verändern.
Adaptable Result löschen
Der Button mit dem Symbol eines Mülleimers ermöglicht die Löschung eines Adaptable Results. Ein Klick auf diesen Button öffnet einen Dialog mit einer Sicherheitsabfrage, mit der die Löschung zu bestätigen ist.
Alternativ besteht über die Checkboxen, die in der Übersichtsliste vor jedem Adaptable Result sichtbar sind, die Möglichkeit, mehrere Adaptable Results für die Löschung auszuwählen. Der Button
entfernt diese markierten Adaptable Results, nachdem zuvor ebenfalls eine Sicherheitsabfrage bestätigt wurde.Für die Erstellung eines Suchindex greift die SmartSearch kundenseitig auf die zu erfassenden Daten zu, die in Form von Webseiten, Portalen oder Datenbanken vorliegen können. Ihre Erfassung erfolgt über sogenannte Datengeneratoren, die unterschiedliche Konfigurationsmöglichkeiten bereitstellen. Die auf dem Solr-Server persistierten Daten lassen sich anschließend über den ebenfalls durch das Cockpit bereitgestellten Browser einsehen. Dieser stellt neben den Inhalten auch alle Metadaten dar.
Die nachfolgenden Unterkapitel beschreiben sowohl die Datengeneratoren als auch den Browser im Detail.
Für die kundenseitige Erfassung der benötigten Daten stellt die SmartSearch sogenannte Datengeneratoren bereit.
Ihre Erstellung und Verwaltung erfolgt in der gleichnamigen Oberfläche, die über den Menübereich →
aufrufbar ist.
Der Bereich zeigt eine Liste aller bereits existierenden Datengeneratoren und ist daher initial leer. Bei der Erstellung weiterer Datengeneratoren ist zwischen drei Arten zu unterscheiden:
Neben diesen bei der manuellen Erstellung relevanten Datengeneratorarten existieren noch weitere, welche nicht manuell angelegt werden können.
Ein Beispiel hierfür ist der Typ |
Datengenerator anlegen
Für die Erstellung eines neuen Datengenerators existiert eine eigene Ansicht, die per Klick auf den Button Allgemein
und Enhancer
, die für alle Datengeneratoren identisch sind, besitzt jeder von ihnen zusätzlich ein spezifisches Tab.
Die nachfolgenden Absätze beschreiben zuerst die beiden identisch Tabs, bevor eine Erläuterung der spezifischen Tabs folgt:
Innerhalb des Tabs Allgemein
ist zunächst ein Name für den zu erstellenden Datengenerator anzugeben und eine Default-Sprache auszuwählen.
Der Zähler Mindestanzahl Dokumente zur Synchronisation
definiert, ab wann eine Persistierung der erfassten Daten in den vom Solr-Server erzeugten Index erfolgt.
Die übrigen Einstellungen ermöglichen eine regelmäßige und automatische Erfassung der benötigten Daten und sind über die Checkbox Regelmäßig starten
de-/aktivierbar.
Dafür kann zwischen einem täglichen und wöchentlichen Startintervall gewählt und über die Angabe eines Datums sowie einer Uhrzeit der nächste Startzeitpunkt festgelegt werden.
Die Sprachen entsprechen hier den nach ISO 639-1 vorgesehenen Werten, also aus zwei Zeichen bestehenden Sprachcodes.
Findet ein Datengenerator an Dokumenten längere Sprachkürzel vor, so wird alles nach dem zweiten Zeichen abgeschnitten.
Auf diesem Weg wird beispielsweise aus dem Sprachcode |
Enhancer
ermöglicht die Erzeugung der folgenden Enhancer.
Sie dienen der Modifikation der durch den Datengenerator erfassten Daten vor ihrer Persistierung auf dem Solr-Server.
Die Erstellung eines Enhancers erfolgt über einen Klick auf den Button .
Groovy-Skript
Dieser Enhancer ermöglicht die Einbindung eines selbst zu implementierenden Groovy-Skripts.
Ein solches Skript ermöglicht zusätzliche Modifikationen des Datenbestands.
So lassen sich beispielsweise weitere Dokumente dem Datenbestand hinzufügen oder bestehende Dokumente bearbeiten bzw. löschen.
Der Button
überprüft das erstellte Skript auf mögliche Fehler.Extrahieren von Namen und Nomen
Entsprechend seines Namens extrahiert dieser Enhancer Namen und Nomen und speichert sie in den Feldern names_multi_keyword
und nouns_multi_keyword
.
Dieser Enhancer ist nur für die Sprache |
Der Tab Web-Crawler
ist spezifisch für den gleichnamigen Datengenerator und wird daher nur für diesen angezeigt.
Er erfasst alle Inhalte eines bestehenden Webauftritts.
Dies umfasst sowohl die HTML-Inhalte (jedoch ohne in ihnen enthaltene HTML-Kommentare) als auch alle Dateien jeglichen Formats.
Dafür benötigt er zunächst eine Start-URL sowie die Angabe, wie viele Seiten maximal zu erfassen sind.
Entspricht die Start-URL einer Sitemap, werden die in der Sitemap enthaltenen Verweise nacheinander erfasst.
Durch die Angabe des Werts Null für die zu erfassende Seitenanzahl wird der gesamte Webauftritt erfasst. |
Um HTML-Inhalte bei der Erzeugung des Suchindex zu ignorieren, müssen diese durch HTML-Kommentare der Form |
Enthalten die erfassten Seiten Verweise auf andere Inhalte, folgt der Datengenerator ihnen und erfasst die verlinkten Inhalte ebenfalls. Dabei werden auch kanonische Verweise berücksichtigt. Auf diesem Weg erfasst er den mit der Start-URL angegeben Webauftritt entweder vollständig oder bis zum angegebenen Limit.
Durch den Datengenerator zu ignorierende Verweise müssen mit Attribut |
Mit einem im Feld Check URL Script
angegebenen, selbstimplementierten Groovy-Skript lässt sich die Erfassung und Verarbeitung verlinkter Inhalte individuell beeinflussen.
Der Button überprüft das erstellte Skript auf mögliche Fehler.
Der Datengenerator kann ausschließlich Verweisen von HTTP- auf HTTP(S)-Seiten folgen. Der Wechsel von HTTPS zu HTTP ist ihm nicht möglich. |
Die übrigen Einstellungen ermöglichen eine Spezifierung der Suchanfragen des Datengenerators:
No-Script Bereiche im HTML ignorieren
lässt sich bestimmen, ob die in diesen Bereichen enthaltenen Inhalte ebenfalls zu erfassen sind.
robots.txt beachten
aktiviert, berücksicht der Datengenerator die in ihr definierten Einschränkungen.
Andernfalls ignoriert er diese und erfasst den gesamten Inhalt des Webauftritts.
Parameter aus URL entfernen
übersprungen werden.
Auf diesem Weg lassen sich Redundanzen in den erfassten Dokumenten vermeiden.
Charset
legt fest, mit welchem Charset die Persistierung der erfassten Daten erfolgt.
smart-search-agent
mit.
Sein Referenzname ist in dem entsprechenden Feld enthalten und lässt sich beliebig überschreiben.
Abstand zwischen zwei Downloads
definierte Wert bestimmt, wie schnell die SmartSearch die einzelnen Suchabfragen absetzt.
Auf diese Weise ist eine Überlastung des Webservers aufgrund einer zu hohen Abfragefrequenz vermeidbar.
Erhält der Datengenerator auf eine Suchanfrage keine Antwort, gibt der Read and connect-Timeout
die Zeitspanne bis zum Abbruch der Datenerfassung an.
Bei der Erfassung der Inhalte eines bestehenden Webauftritts kann der Web-Crawler unterschiedliche Status Codes erhalten. Diese werden wie folgt verarbeitet:
Für die sich aus einem 3xx Status Code ergebenen Redirect-Verweise, wird die Strip Parameters-Konfiguration berücksichtigt. |
Der Tab XML-Crawler
ist ebenfalls spezifisch für den gleichnamigen Datengenerator und wird daher nur für diesen angezeigt.
Er erfasst XML-Daten aus einer definierten Quelle, die nicht in Form einer Webseite vorliegt.
Dafür ist im entsprechenden Feld eine XML-URL
anzugeben.
Besteht die Notwendigkeit, mehrere Quellen zu erfassen, lässt sich an dieser Stelle auch die URL einer Seed-Datei übergeben.
Der Datengenerator folgt dann den in dieser Datei enthaltenen Verweisen, deren Anzahl nicht limitiert ist.
Die Erfassung von XML-Sitemaps ist nur mithilfe des Web-Datengenerators möglich. |
Sowohl für die Erfassung der Daten als auch für den Abruf der persistierten Dokumente bringt die SmartSearch den User-Agent smart-search-agent
mit.
Sein Referenzname ist in dem entsprechenden Feld enthalten und lässt sich beliebig überschreiben.
Erhält der Datengenerator auf eine Suchanfrage keine Antwort, gibt der Read and connect-Timeout
die Zeitspanne bis zum Abbruch der Datenerfassung an.
Der externe Datengenerator sammelt selbst keine Informationen, sondern erfasst ausschließlich Daten, die er von außen über die REST-Schnittstelle übergeben bekommt.
Er besitzt daher in seinem spezifischen Tab keine zusätzlichen Konfigurationsmöglichkeiten.
Die in den Tabs Allgemein
und Enhancer
vorgenommenen Einstellungen sind für ihn ausreichend.
Die Übertragung der Daten an die REST-Schnittstelle ist durch eine Eigenimplementierung zu realisieren. Die dafür notwendigen Informationen sind in der Dokumentation SmartSearch REST API for external datagenerators enthalten. |
Liste bestehender Datengeneratoren
Nach der Speicherung und erfolgreichen Erzeugung des Datengenerators wird er der Liste bestehender Datengeneratoren im gleichnamigen Bereich hinzugefügt. Die Liste gliedert sich in eine vierspaltige Tabelle mit den folgenden Informationen:
Web
, XML
oder Extern
handelt.
Datengenerator bearbeiten
Der Button mit dem Symbol eines Stifts ermöglicht die Bearbeitung des Datengenerators. Ein Klick auf ihn öffnet die Detailansicht mit allen vorgenommenen Konfigurationen. Diese lassen sich entsprechend der zuvor beschriebenen Möglichkeiten verändern.
Datengenerator ausführen
Der Button mit dem Play-Symbol startet manuell die Ausführung des Datengenerators. Er erfasst daraufhin die Daten der konfigurierten Quelle und überträgt sie an den Solr-Server.
Die Persistierung der Daten durch den Solr-Server findet in regelmäßigen Intervallen statt. Es kann daher bis zu fünfzehn Minuten dauern, bis die Daten abrufbar sind. Der Button |
Datengenerator löschen
Der Button mit dem Symbol eines Mülleimers ermöglicht die Löschung eines Datengenerators. Ein Klick auf diesen Button öffnet einen Dialog mit einer Sicherheitsabfrage, mit der die Löschung zu bestätigen ist.
Alternativ besteht über die Checkboxen, die in der Übersichtsliste vor jedem Datengenerator sichtbar sind, die Möglichkeit, mehrere Datengeneratoren für die Löschung auszuwählen. Der Button
entfernt diese markierten Datengeneratoren, nachdem zuvor ebenfalls eine Sicherheitsabfrage bestätigt wurde.Für die Darstellung der per Datengenerator erfassten und durch den Solr-Server persistierten Daten stellt die SmartSearch einen Browser bereit.
Dieser ist über den Menüpunkt →
aufrufbar.
Für die Darstellung ist im Drop-Down-Menü zunächst ein Datengenerator auszuwählen. Der Browser listet daraufhin alle Dokumente auf, die durch diesen Datengenerator erfasst wurden. Per Klick auf ein solches Dokument lassen sich außerdem alle Felder und die in ihnen gespeicherten Metainformationen anzeigen. Die Buttons und ermöglichen ein Durchblättern durch die erfassten Dokumente, deren Gesamtanzahl zwischen ihnen ablesbar ist.
Mit der SmartSearch wird eine Datenstruktur - das sogenannten Solr-Schema - ausgeliefert, welche die für erfasste Dokumente vorhandenen Felder definiert. Diese Felder am Dokument beinhalten nach einer Datenerfassung strukturierte Inhalte, die im Bezug auf das Dokument im Index gespeichert sind. Da die Inhalte verschiedener Felder potenziell Einfluss auf die Ergebnisse einer Suchabfrage haben, werden im folgenden einige relevante Felder erläutert. Einige Felder werden während des Laufs von Datengeneratoren automatisch angelegt und mit Werten befüllt. Der Groovy-Skript-Enhancer bietet außerdem die Möglichkeit, weitere Felder und Werte hinzuzufügen.
Grundsätzlich besteht ein Feld aus einem Bezeichner und einem oder mehreren Werten. Es existieren drei Arten von Feldern, welche sich in ihrem Gebrauch und ihrer Funktion unterscheiden können:
Für die Nutzung der SmartSearch ist es wichtig, Anwendungsfälle und Inhalt der verfügbaren Felder zu verstehen. Die folgenden Tabellen geben eine Übersicht über die drei Feldarten sowie den relevanten Teil der vorhandenen Felder und skizzieren deren Inhalt:
Pflichtfelder
Die Bezeichner sowie Werte von Pflichtfeldern sind zwingend an jedem Dokument vorhanden, erstere sind außerdem unveränderbar.
Die nachfolgende Tabelle zeigt eine Übersicht von Feldern dieser Art:
Bezeichner | Beschreibung | Inhalt |
---|---|---|
id | Eindeutige ID eines Dokuments | Mit dem Inhalt dieses Felds ist jedes Dokument im Index eindeutig identifizierbar. |
title | Titel eines Dokuments | Der Titel eines Dokuments ist beispielsweise als Überschrift auf einer Suchergebnisseite nutzbar. |
content | Inhalt eines Dokuments | Der Inhalt des Dokuments ist - neben dem Titel - die inhaltliche Grundlage für die Suchfunktion. Inhalte, die für die Auffindung des Dokuments relevant sind, sind im Normalfall während der Datengenerierung in dieses Feld zu schreiben. |
link | URL des Dokuments | Der URL eines Dokuments ist die Sprungmarke, mit der die Quelle des indizierten Dokuments im Rahmen eines Suchvorgangs vom Endnutzer abrufbar ist. Dies kann zum Beispiel ein Link hinter dem Titel des Dokuments sein, welcher dann zum eigentlichen Dokument führt. |
Statische Felder
Die Bezeichner statischer Feld sind ebenso wie die der Pflichtfelder unveränderbar. Im Gegensatz zu diesen besitzen statische Felder jedoch nicht zwingend einen Wert.
In der folgenden Tabelle sind einige typische statische Felder aufgeführt:
Bezeichner | Beschreibung | Inhalt |
---|---|---|
thumbnail | Kompaktansicht als Bildverweis | Um die Kompaktansicht der Dokumente in einer Suchergebnisseite anzuzeigen, ist die URL einer solchen Kompaktansicht in diesem Feld zu speichern. |
keywords | Schlagwörter | Dieses Feld ist für Begriffe vorgesehen, die vor der Übernahme in den Index keine sprachliche Verarbeitung wie beispielsweise Stemming durchlaufen sollen. |
language | Sprachkürzel | Dieses Feld beinhaltet das Sprachkürzel nach ISO 639-1. Das Kapitel Datengeneratoren enthält weitere Informationen hierzu. |
Dynamische Felder
Die Bezeichner dynamischer Felder folgen einer Namenskonvention und können in Abhängigkeit des Einsatzes und Dokuments vorhanden oder nicht vorhanden sein. Dynamische Felder sind dafür vorgesehen, das Schema flexibel für zukünftig nötige Daten und die Anwendung somit robuster zu gestalten.
Dynamische Felder verhalten sich wie statische Felder, außer dass ihre Bezeichner einen Platzhalter enthalten. Werden durch den Start einer Datengenerierung Dokumente indiziert, können Daten, welche keinem statischen Feld zuordenbar sind, durch ein dynamisches Feld aufgefangen werden.
So kann ein Dokument beispielsweise ein Feld custom_date
beinhalten, welches im Solr-Schema nicht vorhanden ist.
Die Daten in diesem Feld würden über das dynamische Feld *_date
dennoch in den Index übernommen.
Weitere Informationen zu dynamischen Feldern sind der Solr-Dokumentation zu entnehmen.
Eine Übersicht der wichtigsten verfügbaren dynamische Felder ist folgender Tabelle zu entnehmen:
Namensschema | Beschreibung | Inhalt |
---|---|---|
*_integer | Integer-Ganzzahlwerte | Felder dieser Art tragen Ganzzahlwerte aus dem Wertebereich Integer ( |
*_long | Long-Ganzzahlwerte | Felder dieser Art tragen Ganzzahlwerte aus dem Wertebereich Long ( |
*_double | Double-Gleitkommazahlenwerte | Felder dieser Art tragen Gleitkommazahlenwerte aus dem Wertebereich Double ( |
*_date | Datumswerte | Felder dieser Art tragen Datumswerte und sind entsprechend für zum Beispiel zeitliche Sortierungen zu verwenden.
Die Werte sind im UTC-Format angegeben: zum Beispiel |
*_keyword | Schlagwörter | Analog zum statischen Feld |
*_keyword_lc | Schlagwörter in Kleinbuchstaben | Felder dieses Typs beinhalten Schlagwörter, welche im Rahmen der Indizierung automatisch in Kleinbuchstaben umgewandelt wurden. |
*_sort | Sortierwerte | Dieser Feldtyp ermöglicht die Speicherung sortierbarer Werte. Die Werte in diesen Feldern sind in Kleinbuchstaben umgewandelt und von Leerzeichen bereinigt. |
*_sort_de | Sortierwerte – Spezialfall Deutsch | Dieser Feldtyp verhält sich analog zu |
*_token | Gruppierungswerte | Dieser Feldtyp ermöglicht die Gruppierung von Dokumenten anhand der Feldinhalte, zum Beispiel Dokument- oder Produktkategorien. |
*_pnt | Räumliche Punktwerte | Felder dieses Typs beinhalten räumliche Punktwerte, um z.B. geografische Informationen zu hinterlegen.
Die Werte haben das Format |
*_facet_string | Textfacettenwerte | Felder dieses Typs beinhalten textuelle Werte zur Nutzung als Facettenausprägungen.
Diese Felder werden durch die Nutzung von Bezeichnern der Art |
*_facet_double | Gleitkommazahlenfacettenwerte | Felder dieses Typs beinhalten numerische Werte zur Nutzung als Facettenausprägungen.
Um beispielsweise einen numerischen Facettenwert für die Facette |
*_stored_only | Unverarbeitete Werte | Felder dieses Typs beinhalten Inhalte mit bis zu 32766 Zeichen, welche nicht durchsuchbar gemacht oder in sonstiger Weise verarbeitet sind. Sie können jedoch beim Abruf von Dokumenten zur Anzeige mit abgefragt werden. |
*_stored_only_big | Große unverarbeitete Werte | Felder dieses Typs beinhalten Inhalte unbeschränkter Größe, welche nicht durchsuchbar gemacht oder in sonstiger Weise verarbeitet werden sollen. Sie können jedoch beim Abruf von Dokumenten zur Anzeige mit abgefragt werden. |
*_autocomplete | Begriffe für die Autovervollständigung | Felder dieses Typs beinhalten Begriffe, welche neben dem Inhalt des Dokuments zur Autovervollständigung verwendbar sind. |
*_expanded_autocomplete | Begriffe für wortübergreifende Autovervollständigung | Felder dieses Typs beinhalten Begriffe, welche neben dem Inhalt des Dokuments zur Autovervollständigung über zwei Worte hinweg verwendbar sind. |
Statische/dynamische Felder für Sprachkürzel
Neben den oben beschriebenen Arten von Feldern existieren noch Felder, welche pro Sprache an Dokumenten vorhanden sein können und deren Namensschemata die folgende Tabelle veranschaulichen soll:
Namensschema | Beschreibung | Inhalt |
---|---|---|
*_text_de | Sprachabhängiger textueller Inhalt | Diese Felder enthalten Inhalte, die sprachabhängig textuell verarbeitet sind. |
*_autocomplete_de | Sprachabhängige Begriffe für die Autovervollständigung | Felder dieses Typs beinhalten sprachabhängige Begriffe, welche neben dem Inhalt des Dokuments zur Autovervollständigung verwendbar sind. |
*_expanded_autocomplete_de | Sprachabhängige Begriffe für wortübergreifende Autovervollständigung | Felder dieses Typs beinhalten sprachabhängige Begriffe, welche neben dem Inhalt des Dokuments zur Autovervollständigung über zwei Worte hinweg verwendbar sind. |
Die SmartSearch speichert die kundenseitig erfassten Inhalte in einer Vielzahl unterschiedlicher Felder, für deren Definition sie die Prepared Searches bereitstellt. Diesen kann bei der Ausführung eine Sprache übergeben werden, um die Erfassung der Daten sprachabhängig durchzuführen. Die nachfolgende Tabelle zeigt eine Übersicht aller derzeit für die SmartSearch konfigurierten Sprachen inklusive ihrer Kürzel (nach ISO 639-2) und der für sie verfügbaren Features. Die Anwendung der Features erfolgt automatisch bei der Verarbeitung der erfassten Informationen. Weitere Informationen zu den einzelnen Sprachen sind in der Solr-Dokumentation enthalten.
Aktuell ordnet die SmartSearch den Sprachen die folgenden Features zu:
æÆäÄöÖøØ
(sowie der Varianten aa
, ao
, ae
, oe
und oo
) zu åÅæÆøØ
durchgeführt.
Die verschiedenen Schreibweisen blåbärsyltetöj
und blaabaersyltetoej
ergeben somit die normalisierte Form blåbærsyltetøj
.
Wörter
, Worte
und Wortes
besitzen beispielsweise den gemeinsamen Wortstamm Wort
.
Sprache | Kürzel | Lowercase | Normalisierung | Stemming | Stoppwörter | Synonyme |
Arabisch | ar | ja | ja | ja | ja | ja |
Bengali | be | ja | nein | nein | ja | ja |
Bulgarisch | bg | ja | nein | ja | ja | ja |
Chinesisch Traditionell | zh-tw | ja | ja | nein | ja | ja |
Chinesisch Vereinfacht | zh-cn | ja | ja | ja | ja | ja |
Dänisch | da | ja | ja | ja | ja | ja |
Deutsch | de | ja | nein | ja | ja | ja |
Englisch | en | ja | nein | ja | ja | ja |
Estnisch | et | ja | nein | nein | ja | ja |
Finnisch | fi | ja | nein | ja | ja | ja |
Französisch | fr | ja | ja | ja | ja | ja |
Griechisch | gr | ja | nein | nein | ja | ja |
Holländisch | nl | ja | nein | ja | ja | ja |
Indonesisch | id | ja | nein | ja | ja | ja |
Italienisch | it | ja | ja | ja | ja | ja |
Japanisch | ja | ja | nein | nein | ja | ja |
Koreanisch | ko | ja | ja | nein | ja | ja |
Kroatisch | hr | ja | nein | nein | ja | ja |
Lettisch | lv | ja | nein | ja | ja | ja |
Litauisch | lt | ja | nein | ja | ja | ja |
Malaiisch | ms | ja | nein | nein | ja | ja |
Norwegisch | no | ja | nein | ja | ja | ja |
Polnisch | pl | ja | nein | ja | ja | ja |
Portugiesisch | pt | ja | nein | ja | ja | ja |
Rumänisch | ro | ja | nein | ja | ja | ja |
Russisch | ru | ja | nein | ja | ja | ja |
Schwedisch | sv | ja | ja | ja | ja | ja |
Serbisch | sr | ja | ja | nein | ja | ja |
Slowakisch | sk | ja | nein | nein | ja | ja |
Spanisch | es | ja | nein | ja | ja | ja |
Thai | th | ja | nein | nein | ja | ja |
Tschechisch | cs | ja | nein | ja | ja | ja |
Türkisch | tr | ja | ja | ja | ja | ja |
Ukrainisch | uk | ja | nein | ja | ja | ja |
Ungarisch | hu | ja | nein | ja | ja | ja |
Vietnamesisch | vi | ja | nein | nein | ja | ja |
Der Bereich System
besitzt als einzigen Unterpunkt das Benutzermanagement
.
Dieses dient der Erzeugung und Konfiguration von Benutzern und Gruppen und gliedert sich daher in zwei gleichnamige Reiter.
Die folgenden Unterkapitel erläutern die Funktionalitäten der beiden Reiter im Detail.
Ist die Benutzer- und Gruppenverwaltung auf Basis von LDAP realisiert, besitzt das SmartSearch-Cockpit ausschließlich einen lesenden Zugriff auf sie. Das Cockpit dient in diesem Fall nur der Auflistung der Benutzer und Gruppen, jedoch nicht ihrer Bearbeitung oder Löschung. Lediglich die Verwaltung der Berechtigungen erfolgt auch im LDAP-Fall über das SmartSearch-Cockpit. |
Der Zugriff auf das SmartSearch-Cockpit setzt einen aktiven Benutzer voraus.
Für die initiale Anmeldung existiert daher ein Master-Admin, mit dem weitere Benutzer erstellbar sind.
Die Berechtigungen eines Benutzers ergeben sich aus seiner Gruppenzugehörigkeit, die während seiner Erzeugung zu definieren ist.
Die Erstellung und Verwaltung der Benutzer erfolgt im gleichnamigen Reiter des Usermanagements
.
Ist die Benutzerverwaltung auf Basis von LDAP realisiert, besitzt das SmartSearch-Cockpit ausschließlich lesenden Zugriff auf sie. Die Erstellung, Bearbeitung und Löschung von Benutzern ist in diesem Fall innerhalb des Cockpits nicht möglich. |
Der Reiter zeigt eine Liste aller bereits bestehender Benutzer, die initial lediglich den Master-Admin enthält.
Benutzer anlegen
Für die Erstellung eines neuen Benutzers existiert eine eigene Ansicht, die per Klick auf den Button
aufrufbar ist.Innerhalb der Ansicht ist zunächst die E-Mail-Adresse des neuen Benutzers anzugeben sowie ein Passwort zu definieren. Des Weiteren kann der Benutzer an dieser Stelle direkt einer oder mehreren Gruppen hinzugefügt werden. Das Drop-Down-Menü Gruppen zeigt dafür die Liste existierender Gruppen. Die Zuweisung des Benutzers zu einer aus der Liste ausgewählten Gruppe erfolgt über das Plus-Symbol neben dem Drop-Down-Menü. Über das Mülleimer-Symbol, das für jede zugewiesen Gruppe sichtbar ist, lässt sich eine Zuordnung wieder rückgängig machen.
Während die Gruppenzuordnung optional ist, handelt es sich bei Angabe der E-Mail-Adresse und der Definition des Passworts um Pflichtfelder. |
Liste bestehender Benutzer
Nach der Speicherung und erfolgreichen Erzeugung des neuen Benutzers wird er der Liste bestehender Benutzer im gleichnamigen Reiter hinzugefügt. Die Liste gliedert sich in eine vierspaltige Tabelle mit den folgenden Informationen:
Eine Deaktivierung des Master-Admins ist nicht möglich. Daher steht der Schieberegler für ihn nicht zur Verfügung. |
Mit Ausnahme des Master-Admins werden in der Tabelle pro Benutzer außerdem zwei Buttons angezeigt, die eine Bearbeitung beziehungsweise Löschung des Benutzers ermöglichen.
Benutzer bearbeiten
Der Button mit dem Symbol eines Stifts ermöglicht die Bearbeitung eines Benutzers. Ein Klick auf ihn öffnet die Detailansicht mit allen Informationen. In der Ansicht lässt sich die Gruppenzuordnung des Benutzers ändern, indem er weiteren Gruppen hinzugefügt oder aus ihnen entfernt wird. Die Zuweisung erfolgt über die Auswahl einer Gruppe aus dem Drop-Down-Menü Gruppen und einem anschließenden Klick auf das Plus-Symbol. Die Entfernung des Benutzers aus einer Gruppe ermöglicht das Mülleimer-Symbol, das für jede zugewiesene Gruppe sichtbar ist.
Benutzer löschen
Der Button mit dem Symbol eines Mülleimers ermöglicht die Löschung eines Benutzers.
Ein Klick auf diesen Button öffnet einen Dialog mit einer Sicherheitsabfrage, mit der die Löschung zu bestätigen ist.
Der Dialog enthält eine Checkbox, die standardmäßig aktiviert ist.
Sie bewirkt die Entfernung aller Referenzen des zu löschenden Benutzers auf sein Benutzerkonto.
Stattdessen werden sie durch den technischen Benutzer ANONYMUS
ersetzt und dadurch anonymisiert.
Eine Deaktivierung der Checkbox erhält die Referenzen des Benutzers.
Sie lassen sich im Nachhinein über den Button anonymisieren.
Der Master-Admin kann niemals gelöscht werden. Daher steht der Lösch-Button für ihn nicht zur Verfügung. |
Alternativ besteht über Checkboxen, die in der Übersichtsliste vor jedem Benutzer sichtbar sind, die Möglichkeit, mehrere Benutzer für die Löschung auszuwählen. Der Button
entfernt diese markierten Benutzer, nachdem zuvor ebenfalls eine Sicherheitsabfrage bestätigt wurde.Auch bei der Löschung mehrerer Benutzers lassen sich deren bestehende Referenzen durch einen technischen Benutzer ersetzen und damit anonymisieren.
Wurde diese Option deaktiviert, lassen sich die Referenzen im Nachhinein über den Button ANONYMUS
ersetzt.
Der Zugriff auf die Bereiche und Funktionen des SmartSearch-Cockpits setzt verschiedene Berechtigungen voraus.
Sie werden über Gruppen definiert, denen die einzelnen Benutzer zuzuordnen sind.
Initial existiert lediglich ein Master-Admin, für den zuerst die notwendigen Berechtigungen zur Erstellung neuer Benutzer und Gruppen aktiviert werden müssen.
Die Erstellung und Verwaltung der Gruppen erfolgt im gleichnamigen Reiter des Benutzermanagements
.
Ist die Gruppenverwaltung auf Basis von LDAP realisiert, besitzt das SmartSearch-Cockpit ausschließlich lesenden Zugriff auf sie. Die Erstellung und Löschung von Gruppen ist in diesem Fall innerhalb des Cockpits nicht möglich. Des Weiteren ist die Bearbeitung der Gruppen auf die Konfiguration der Berechtigungen beschränkt. |
Der Reiter zeigt eine Liste aller bereits bestehenden Gruppen, die initial lediglich die Admin- und User-Gruppe enthält.
Gruppe anlegen
Für die Erstellung einer neuen Gruppe existiert eine eigene Ansicht, die per Klick auf den Button
aufrufbar ist.Innerhalb der Ansicht ist ein Gruppenname zu vergeben, der lediglich Buchstaben, Zahlen und Bindestriche enthalten darf. Des Weiteren können der Gruppe an dieser Stelle direkt ein oder mehrere Benutzer hinzugefügt werden. Das Drop-Down-Menü Benutzer zeigt dafür die Liste bestehender Benutzer. Die Zuweisung eines aus der Liste ausgewählten Benutzers erfolgt über das Plus-Symbol neben dem Drop-Down-Menü. Über das Mülleimer-Symbol, das für jeden zugewiesenen Benutzer sichtbar ist, lässt sich eine Zuordnung wieder rückgängig machen.
Darüber hinaus lassen sich in dieser Ansicht die Berechtigungen der Gruppe bestimmen.
Dafür sind alle Bereiche des Cockpits aufgelistet, für die einzeln die Berechtigungen Lesen
, Bearbeiten
und Löschen
per Checkbox de-/aktivierbar sind.
Für die Bereiche Datengenerator
und Search
steht außerdem das Recht Ausführen
zur Verfügung.
Der Button ermöglicht die gleichzeitige Aktivierung aller dargestellten Berechtigungen.
Während die Zuordnung der Berechtigungen optional ist, handelt es sich bei der Angabe des Namens um ein Pflichtfeld. |
Liste bestehender Gruppen
Nach der Speicherung und erfolgreichen Erzeugung der neuen Gruppe wird sie der Liste bestehender Gruppen im gleichnamigen Reiter hinzugefügt. Die Liste gliedert sich in eine zweispaltige Tabelle mit den folgenden Informationen:
Mit Ausnahme der Gruppen ADMIN
und USER
zeigt die Tabelle pro Gruppe außerdem zwei Buttons an, die eine Bearbeitung oder Löschung der Gruppe ermöglichen.
Gruppe bearbeiten
Der Button mit dem Symbol eines Stifts ermöglicht die Bearbeitung einer Gruppe. Ein Klick auf ihn öffnet die Detailansicht der Gruppe mit allen Informationen. In der Ansicht lassen sich die der Gruppe zugeordneten Benutzer sowie die Berechtigungen ändern. Die Zuordnung eines Benutzers zur Gruppe erfolgt über seine Auswahl aus dem Drop-Down-Menü Benutzer und einem anschließenden Klick auf das Plus-Symbol. Die Entfernung eines Benutzers aus der Gruppe ermöglicht das Mülleimer-Symbol, das für jeden zugewiesenen Benutzer sichtbar ist. Die De-/Aktivierung der Berechtigungen ist mithilfe der pro Berechtigung angezeigten Checkbox möglich.
Gruppe löschen
Der Button mit dem Symbol eines Mülleimers ermöglicht die Löschung einer Gruppe. Ein Klick auf diesen Button öffnet einen Dialog mit einer Sicherheitsabfrage, mit der die Löschung zu bestätigen ist. Die Löschung entfernt die Gruppe und alle durch sie definierten Berechtigungen.
Eine Löschung der Gruppen |
Alternativ besteht über Checkboxen, die in der Übersichtsliste vor jeder Gruppe sichtbar sind, die Möglichkeit, mehrere Gruppen für die Löschung auszuwählen. Der Button
entfernt diese markierten Gruppen, nachdem zuvor ebenfalls eine Sicherheitsabfrage bestätigt wurde.Im Rahmen einer Integration der SmartSearch können verschiedene Anwendungsfälle auftreten, welche bestimmte Konfigurations- beziehungsweise Entwicklungstätigkeiten erfordern. Die folgenden Abschnitte beschreiben derartige Anwendungsfälle gemeinsam mit typischen Lösungsansätzen.
Solche Lösungsansätze können Anpassungen im Cockpit an den Konfigurationen von Prepared Searches sowie Datengeneratoren beinhalten. Dies schließt die Erstellung und Anpassung von Groovy-Skript-Enhancern ein. Außerdem können die vorgestellten Lösungsansätze Anpassungen an den Anfragen gegen die Such-API mit sich führen. Somit richtet sich der nachfolgende Abschnitt vor allem an Entwickler.
Die hier skizzierten Ansätze sind lediglich als Implementierungs- und Integrationsansätze und somit als Ergänzung der Dokumentation, jedoch nicht als vollumfängliche Erläuterung der angeschnittenen Themen zu verstehen.
Beim Autocomplete handelt es sich um eine Funktion, die eine durch den Anwender getätigte Sucheingabe sinnvoll ergänzt Grundlage für diese Ergänzung sind die sich im Suchindex befindlichen Daten, welche abhängig von der bisher getätigten Eingabe als sinnvolle Suchbegriffe vorgeschlagen werden.
Als Datengrundlage für die Autocomplete-Funktion dienen die Inhalte des content
-Felds, welches auch zur Generierung des Suchindex herangezogen wird.
Somit ist die Funktion im Normalfall nutzbar, ohne dass für eine Prepared Search eine spezifische Konfiguration notwendig ist.
Die Sprachabhängigkeit wird hierbei für Nutzende transparent gestaltet, eine Konfiguration bezogen auf die zur Vervollständigung genutzte Sprache ist somit nicht nötig.
Grundsätzlich senden Nutzende der Autocomplete-Funktion eine Abfrage mit einem Präfix an die SmartSearch. Die Antwort auf diese Anfrage beinhaltet eine definierte Anzahl von Begriffen, welche mit dem übergebenen Präfix beginnen und von der SmartSearch für diesen als relevant identifiziert wurden - zum Beispiel, weil sie häufig in Dokumenten vorkommen. Daraufhin können Verwendende durch die Eingabe erweiterter Zeichenfolgen und somit einer erneuten Abfrage eine verfeinerte Vorschlagsliste abrufen.
Senden Nutzende zum Beispiel den Präfix son
an die SmartSearch, so könnte eine Antwort zum Beispiel wie folgt aussehen:
beispielhafte Antwort.
[ "sondern", "sonnenenergie", "sonnenspektrums" ]
Erweitern Anfragende die Eingabe zu "sonn", führt ein Absenden der Abfrage zu einer verfeinerten Liste:
verfeinerte Liste.
[ "sonnenenergie", "sonnenspektrums" ]
Im Folgenden werden die Abfragen beschrieben, welche ein solches Verhalten ermöglichen. Dieses Beispiel basiert auf der Annahme, dass eine Prepared Search mithras vorhanden ist, welche als Ziel der Autocomplete-Abfragen dient.
Weiterhin besteht die Annahme, die Prepared Search sei, wie im Kapitel Prepared Search beschrieben, mit einen Datengenerator verknüpft, dessen indizierte Dokumente das Beispiel ermöglichen. Konkret heißt dies, die in den Beispielen aufgeführten Suchwortvorschläge befinden sich in den indizierten Inhalten.
Die einfachste Form der Autocomplete-Abfrage für eine Prepared Search mithras für die Zeichenfolge "son" sieht aus wie folgt.
Die Zeichenfolge entspricht dabei dem Wert des Parameters prefix
.
/rest/api/v1/prepared_search/mithras/autocomplete?prefix=son
Wurde eine solche Abfrage durch Nutzende abgesetzt, so kann eine Antwort (abhängig von der Datenbasis) wie folgt aussehen:
[ "sonningen", "sonnenenergie", "sonnigen", "sondern", "sonnenspektrums" ]
Das bisherige Beispiel betrachtet den Fall, dass eine Autocomplete-Abfrage sprachunabhängig über alle Dokumente hinweg erfolgt. Dies kann jedoch dazu führen, dass Begriffe aus mehreren im Index vorhandenen Sprachen vorgeschlagen werden:
mehrsprachige Vorschläge.
[ "song", "sonne" ]
Durch das Hinzunehmen des Sprachparameters language
zur Abfrage ist es möglich, auf eine bestimmte Sprache einzuschränken:
language-Parameter.
/rest/api/v1/prepared_search/mithras/autocomplete?prefix=son&language=de
So führt die zuvor stehende beispielhafte Abfrage für die Sprache Deutsch mit dem Kürzel de
zu einem entsprechenden Ergebnis:
sprachabgängige Antwort.
[ "sonne" ]
In manchen Anwendungsfällen kann es gewünscht sein, die vorgeschlagenen Begriffe nicht auf durch Leerzeichen getrennte Wörter, sondern über Leerzeichen hinweg zu erweitern. Ein typisches Beispiel sind Suchbegriffe wie "Modell 4A Version 2", "Presse aktuell" oder "Vertrag kündigen".
Soll die Autocomplete-Funktion solche mehrwortigen Begriffe vorschlagen, so gibt es grundsätzlich zwei Möglichkeiten dies umzusetzen:
Mehrwortige Autocomplete-Funktion für freien Inhalt
Für einen zwei Worte umfassenden Autocomplete über ein Leerzeichen hinweg besteht für Nutzende die Möglichkeit, dynamische Felder vom Typ _expandend_autocomplete
zu nutzen.
Diese werden bei einer Datengenerierung für das Feld content
automatisch befüllt, und können durch das Anhängen des Suffixes _expanded
über den Parameter field
abgerufen werden:
expanded-Suffix.
/rest/api/v1/prepared_search/mithras/autocomplete?prefix=ene&field=content_expanded
mehrwortige Vorschläge.
[ "energy", "energy facts", "energy locations" ]
Sollen die Inhalte anderer Felder für eine solche mehrwortige Autovervollständigung genutzt werden,
so müssen die Inhalte bei der Datengenerierung in einem Groovy-Skript-Enhancer in ein entsprechendes Feld vom Typ *_expanded_autocomplete_[Sprachkürzel]
übertragen werden.
In diesem Beispiel wird ein freier Text in das Feld texte_expanded_autocomplete_en
kopiert:
Feld texte_expanded_autocomplete_en.
document.addData("texte_expanded_autocomplete_en", "Solar energy is the energy of the future, and we have dedicated ourselves to this future. With our solutions and products, we would like to make sure that you are best equipped for this energy of the future. This is the only way for each of us to achieve the highest levels of sustainability and environmental protection for ourselves, our families and our companies")
Nutzende können nun eine Abfrage gegen dieses Feld (ohne den Suffix _autocomplete_[Sprachkürzel]
) senden:
Abfrage des Felds.
/rest/api/v1/prepared_search/mithras/autocomplete?prefix=sol&field=texte_expanded
Die Antwort auf diese Abfrage beinhaltet eine leerzeichenübergreifende Autovervollständigung, falls entsprechende Begriffe in den indizierten Daten vorhanden sind:
leerzeichenübergreifende Vorschläge.
[ "solar energy", "solutions", "solar", "solutions and" ]
Mehrwortige Autocomplete-Funktion für definierte Begriffe
In manchen Situationen kann es als Suchanbieter hilfreich sein, die Wortvorschläge sehr genau kontrollieren zu können. Sind die indizierten Inhalte zum Beispiel Produkte, so soll die Vervollständigung der Eingabe "mod" eventuell die Vorschläge "modell 4a version 1" sowie "modell 4a version A" anbieten.
Um dieses Verhalten zu erreichen, steht das sprachunabhängige dynamische Feld _keyword_lc
zur Verfügung.
Dazu muss bei der Einrichtung des Datengenerators an einem an der Prepared Search konfigurierten Datengenerator in einem Groovy-Skript-Enhancer ein solches Feld befüllt werden.
Folgender exemplarischer Groovy-Skript-Code setzt den Wert des dynamischen Felds model_keyword_lc
auf modell 4a version 1
:
Ersetzung eines dynamischen Felds.
document.setSingleValue("model_keyword_lc", "modell 4a version 1")
Gibt es nun im Index Dokumente mit den Werten modell 4a version 1
bzw. modell 4a version 2
, so kann ein Nutzender der Autocomplete-Funktion durch den Parameter field
das Feld model_keyword_lc
gezielt zur Vervollständigung der Eingabe "mod" nutzen:
gezielte Vervollständigung.
/rest/api/v1/prepared_search/mithras/autocomplete?prefix=mod&field=model_keyword_lc
Anders als bei den bisherigen Beispielen, in denen nur passende Auszüge aus Feldinhalten zurückgegeben wurden, beinhaltet die Antwort auf eine solche Abfrage alle vollständigen Werte des übergebenen dynamischen Felds. Im aktuellen Beispiel könnte die Antwort entsprechend wie folgt aussehen:
Antwort mit vollständigen Werten.
[ "modell 4a version 2", "modell 4a version 1" ]
Die Autocomplete-Funktion schlägt keine Wörter vor, die in Stopwortlisten vorkommen. Bei Änderungen an einer Stopwortliste ist eine erneute Indizierung durch einen Datengenerator-Lauf nötig, damit sich die Änderung in der Liste der ausgelieferten Autocomplete-Vorschläge niederschlägt.
Es ist ratsam, keine Autocomplete-Anfragen für Prefixe mit weniger als drei Buchstaben an die SmartSearch zu senden. Wenn auch grundsätzlich möglich, können Abfragen mit solch kurzen Prefixen eine erhöhte Last verursachen. Auch sind die Vorschläge in den Antworten solcher kurzen Anfragen häufig nicht sinnvoll, da die Anzahl der möglichen Vorschläge noch sehr lang und somit wenig eingrenzend ist.
Grundsätzlich sind die Vorschlagslisten noch um sogenannte Filter-Queries erweiterbar.
Solche Filter-Queries schränken die Liste der Vervollständigungsvorschläge weiter ein, indem sie die Menge der ihnen zugrunde liegenden Dokumente durch eine Anfrageklausel verkleinern.
Die ist durch eine Erweiterung des Parameters fq
durch eine solche Klausel erreichbar.
Das folgende Beispiel zeigt entsprechend nur noch Vorschläge aus Dokumenten an, in deren indiziertem Inhalt das Feld mime_type
den Wert 'html' enthält.
.Einschränkung durch Filter-Queries
rest/api/v1/prepared_search/mithras/autocomplete?prefix=ene&fq=mime_type:html
Monitoring dient der Überwachung von Prozessen, Abläufen und Zuständen. Dabei soll vor allem sichergestellt werden, dass der SmartSearch-Server weiterhin einwandfrei läuft und keine Ausfällen auftreten.
Auch die SmartSearch bietet für seinen eigenen Server diese Möglichkeit. Eine einfache Anbindung an Prometheus erlaubt die Erfassung und Auswertung der Serverdaten. Damit die Kommunikation zwischen Prometheus und der SmartSearch funktioniert, sind an beiden Enden kleinere Konfigurationen erforderlich.
Auf der Seite der SmartSearch muss in der application.yml
der Key management.metric.export.prometheus.enabled
auf true gesetzt werden.
management: metrics: export: prometheus: enabled: true
Danach ist der Prometheus-Service unter folgender URL erreichbar:
smart-search-server:port/actuator/prometheus
Zuletzt muss der SmartSearch-Server Prometheus bekannt gemacht werden.
Dies geschieht in der Konfigurationsdatei prometheus.yml
und benötigt folgende Einstellungen:
scrape_configs: - job_name : smart-search metrics_path: /actuator/prometheus scheme: https basic_auth: username: USERNAME password: PASSWORD static_configs: - targets: - smart-search-server:PORT
Um die Aktivität eines SmartSearch-Servers zu überwachen, erfasst Prometheus die sogenannten Metriken. Diese sind nach Durchführung der Konfiguration für das Monitoring auf dem Prometheus-Server verfügbar. Bei den Metriken handelt es sich um Parameter, die bestimmte Messgrößen des Servers beschreiben. Sie ermöglichen die Ableitung verschiedener Informationen über das Verhalten des SmartSearch-Servers und werden von Prometheus periodisch erfasst und gespeichert.
Interessant sind vor allem die JVM-Parameter, wie beispielsweise die Speichernutzung und die Anzahl der Threads. Weitere wichtige Metriken beinhalten die CPU-Auslastung oder die Performance von HTTP-Requests.
Die zusätzliche Konfiguration einer Grafana-Instanz erlaubt eine umfangreiche Visualisierung mit Dashboards. Grafana ist eine Software, die Werte aus Metriken in Graphen darstellt. Die Visualisierung der Werte bietet den Vorteil einer besseren Vergleichbarkeit. Informationen zur Installation und zum Start eines Grafana-Servers befinden sich auf der offiziellen Webseite.
Die Ergänzung des konfigurierten Prometheus-Servers als Datenquelle in der Grafana-Benutzeroberfläche gestattet den Zugriff auf die von der SmartSearch bereitgestellten Metriken.
Mit der Version 8 stellt Solr ebenfalls einen Prometheus-Exporter zur Verfügung.
Dieser befindet sich im contrib
-Unterordner des Solr-Installationsordners.
Weitere Informationen zum Betrieb und zur Konfiguration des Exporters befinden sich in der offiziellen Dokumentation.
Dieses Kapitel enthält Hinweise, die für den Betrieb der SmartSearch sowie der verbundenen Systeme notwendig sind.
Beim initialen Start des SmartSearch-Servers wird der Master-Admin automatisch mit den Daten aus der application.yml
erzeugt.
Sein Passwort lässt sich danach jederzeit im SmartSearch-Cockpit ändern.
Ein Start des SmartSearch-Servers mit dem optionalen Parameter resetAdminPassword
setzt das Master-Admin-Passwort auf den Wert aus der application.yml
zurück.
Auf diesem Weg wird ein Aussperren aus dem SmartSearch-Cockpit verhindert.
Die Verarbeitung von Daten durch die SmartSearch kann nur funktionieren, wenn die einzelnen Komponenten einwandfrei arbeiten. Treten Störungen auf oder ist eine Aktualisierung notwendig, sind daher stets sowohl der SmartSearch-Server als auch alle ZooKeeper- und Solr-Server zu betrachten. Die nachfolgenden Abschnitte beschreiben einige Lösungsansätze für bekannte Herausforderungen.
Spring Boot liefert eine Reihe von Actuatoren mit, die in der default-Konfiguration der SmartSearch aktiviert sind. Mit diesen ist es möglich, zur Laufzeit einen Einblick in den Server zu bekommen. Die Actuatoren liefern zum Beispiel Informationen zum aktuellen Environment oder zu den Konfigurationen der verschiedenen Log-Level. Detaillierte Hintergrundinformationen zu den Actuatoren sind in der Spring-Boot-Actuatoren-Dokumentation zu finden.
Die Actuatoren stellen ihre Informationen über REST-Services zur Verfügung. Diese sind über eine http-Basic-Authentifizierung gesichert und benötigen valide Zugangsdaten eines Admin-Users.
Die nachfolgende Konfiguration aktiviert die default-Actuatoren-Endpunkte, deaktiviert allerdings explizit den heapdump
-Endpunkt.
Der heapdump
-Endpunkt ermöglicht einen Download in GB-Größe, was eventuell in einer Produktionsumgebung nicht gewünscht ist.
Konfiguration für default-Endpunkte.
management: endpoint: health: show-details: when-authorized metrics: enabled: true prometheus: enabled: true endpoints: web: exposure: include: "*" exclude: - "heapdump" metrics: export: prometheus: enabled: false descriptions: false
Die folgende URL stellt einen Überblick über die aktuellen Actuatoren-Endpunkte bereit.
URL: /actuator
Der Aufruf führt eine Basic-Authentifizierung mit einem Admin-User aus.
Zu diesem Zweck kann der Nutzer aus der |
Mögliche Rückmeldung bei einer Abfrage der Actuatoren.
{ "_links": { "self": { "href": "https://smart-search-server:8181/actuator", "templated": false }, "auditevents": { "href": "https://smart-search-server:8181/actuator/auditevents", "templated": false }, "beans": { "href": "https://smart-search-server:8181/actuator/beans", "templated": false }, "health": { "href": "https://smart-search-server:8181/actuator/health", "templated": false }, "conditions": { "href": "https://smart-search-server:8181/actuator/conditions", "templated": false }, [...] "mappings": { "href": "https://smart-search-server:8181/actuator/mappings", "templated": false } } }
Es existiert ein spezieller Spring-Boot-Actutator zum Umgang mit den Log-Einstellungen. Dieser ermöglicht die Anpassung der Log-Level zur Laufzeit. Der Aufruf der folgenden relativen URL auf einer SmartSearch-Instanz erzeugt die Ausgabe aller derzeit konfigurierten Log-Level:
URL: /actuator/loggers
Es besteht auch die Möglichkeit, Informationen zu einem speziellen Logger auszugeben:
URL: /actuator/loggers/<Logger>
Beispiel-URL zur Abfrage des Loggers de.arithnea.haupia.Server
:
URL: /actuator/loggers/de.arithnea.haupia.Server
Der folgende Code-Ausschnitt zeigt eine mögliche Antwort des SmartSearch-Servers auf diese Abfrage.
Beispiel-Rückmeldung.
{ "configuredLevel": "INFO", "effectiveLevel": "INFO" }
Die Anpassung eines Log-Levels wird durch einen POST-Request gegen eine konkrete Logger-URL ausgeführt. In diesem Request wird im JSON-Format das neue Log-Level übermittelt.
URL: /actuator/loggers/<Logger>
Der Body ist ein JSON-Objekt, das als Wert für den Key configuredLevel
das gewünschte Log-Level besitzt.
Beispiel:
curl-Aufruf.
$ curl 'https://smart-search-server:8181/actuator/loggers/de.arithnea.haupia.Server' -i -u 'user:password' -X POST \ -H 'Content-Type: application/json' \ -d '{ "configuredLevel" : "DEBUG" }'
Der zurückgegebene HTTP-Statuscode 204
bestätigt das erfolgreiche Setzen des Log-Levels.
Prometheus ist ein Tool für das Monitoring von Prozessen.
Das Tool erfasst in regelmäßigen Abständen den Zustand eines Prozesses und erlaubt eine zeitliche Auswertung der Daten.
Dies ermöglicht zum Beispiel, den Speicherverbrauch im Verhältnis zu den Anfragen an die REST-Services zu beobachten.
Die SmartSearch liefert bereits vorkonfiguriert einen Prometheus-Endpunkt mit, der über die application.yml
-Datei zu aktivieren ist.
Für die Aktivierung ist folgender Key auf true
zu setzen:
Beispiel für die Aktivierung des Prometheus-Endpunkts.
management: metrics: export: prometheus: enabled: true
Anschließend ist unter folgender URL ein Endpoint verfügbar:
URL: /actuator/prometheus
Der Endpoint lässt sich in Prometheus zum Beispiel wie folgt einbinden:
Beispiel für die Einbindung des Endpoints in Prometheus.
scrape_configs: - job_name: 'smart-search' metrics_path: '/actuator/prometheus' scheme: https basic_auth: username: admin@localhost.de password: admin static_configs: - targets: ['smart-search-server:8181']
Beim Crawling eines https-Servers kann der unten dargestellte Fehler auftreten. Er sagt aus, dass im Keystore kein gültiges Zertifikat eingetragen ist.
Möglicher Fehler bei unsigniertem SSL-Zertifikat.
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Für die Behebung des Fehlers ist das SSL-Zertifikat des gecrawlten https-Servers in den Keystore des SmartSearch-Servers einzubinden.
Die Einbindung des Zertifikats erfolgt durch einen Download der Zertifikatsdatei, die der JRE mit dem keytool
-Befehl hinzuzufügen ist.
Ein exemplarischer Aufruf für Mac OS sieht wie folgt aus:
Beispielaufruf.
sudo keytool -import -alias BELIEBIGER_ALIAS -keystore /PFAD_ZUR_JAVA_JRE/lib/security/cacerts -file /PFAD/ZUM/ZERTIFIKAT/zertifikats.datei
Nach der erfolgreichen Einbindung des Zertifikats tritt der beschriebene Fehler nicht mehr auf und die Seite ist wie gewünscht crawlbar.
Die SmartSearch ist ein Produkt der e-Spirit AG, Dortmund, Germany.
Für die Verwendung des Produkts gilt nur die mit der e-Spirit AG vereinbarte Lizenz.