haupia 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. Es bietet sowohl eine hohe Trefferqualität als auch einen optimalen Suchkomfort und bindet Kunden somit auf der Webseite.
Gleichzeitig stellt es durch das integrierte haupia-Cockpit Redakteuren 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 (z. B. 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 von haupia 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 haupias 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 haupia-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 u.a. die Möglichkeit:
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 identifiziert werden kann. Dies schließt jegliche potenzielle Identifizierungsmerkmale ein, direkte Identifizierungsmerkmale, wie etwa:
indirekte Identifizierungsmerkmale, wie:
Online-Identifizierungsmerkmale, wie zum Beispiel:
Die Such-Engine haupia 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 Produktes.
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 haupia 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 ggf. Kontakt mit einem Bearbeiter eines Elementes 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 von haupia notwendig sind.
Nachfolgend informieren wir Sie darüber, welche personenbezogenen Daten wir erheben, wenn Sie haupia nutzen und wie wir mit diesen Daten umgehen:
Warum werden die Daten benötigt?
haupia arbeitet mit einem durchgängigen Benutzer- und Rechtesystem. Neue Benutzer werden über das Benutzermanagement angelegt und verwaltet. Nach dem Anlegen ist der Benutzer auf dem Server bekannt und kann sich (mit einen gültigen Login) über das haupia Cockpit anmelden. Der Zugriff auf die Konfigurationselemente wird über Gruppenrechte/Rollen erteilt.
Damit wird sichergestellt, dass nur authentifizierte Nutzer Zugriff auf haupia erhalten und diese Nutzer Elemente nur gemäß der ihnen erteilten Rechte bearbeiten dürfen.
Wo werden die Daten verwendet bzw. angezeigt?
Informationen zum Benutzer werden an diversen Stellen angezeigt, z. B.:
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?
Beim Entfernen eines Benutzers über das Benutzermanagement werden die Anmeldeinformationen des Benutzers sofort aus der Konfigurationskomponente entfernt.
Das Deaktivieren eines Nutzers im Benutzermanagement löscht seine Daten nicht. |
Warum werden die Daten benötigt?
haupia verwendet Logfiles, um Aktionen und Ereignisse auf dem haupia-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 haupia 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 haupia-Servers geschrieben.
Wie lange werden die Daten gespeichert?
Standardverhalten: Wird eine fest eingestellte Dateigröße von 100 MB erreicht, wird die aktuelle Log-Datei 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 haupia ist die Nachvollziehbarkeit der letzten Änderungen, aber auch Informationen über das Erstellen von Konfigurationselementen. Dazu speichert haupia Auditierungs-Daten.
Bei jeder Änderung, die ein Redakteur an Konfigurationselementen (z. B. einer Prepared Search) vornimmt, wird daran vermerkt, wer die letzte Änderung vorgenommen hat und wann. Damit wird eine evtl. bestehende letzte Änderung überschrieben.
Wird ein Konfigurationselement neu angelegt, wird daran vermerkt, wer das Element angelegt hat und wann.
Wo werden die Daten verwendet bzw. angezeigt?
Die Auditierungs-Daten (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: Beim Löschen eines Benutzer 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 beim Löschen das Standardverhalten nicht angewendet wurde. Nach dem Anonymisieren wird ein Bericht angezeigt, in welchen Elementen der User anonymisiert wurde. Es werden dazu keine Informationen gelogged, der Bericht ist die einzige Möglichkeit Informationen über die Anonymisierung zu bekommen.
Warum werden die Daten benötigt?
haupia 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 haupias müssen zunächst die einzelnen Komponenten installiert werden, die beliebig verteilbar und frei skalierbar sind. Es ist essentiell, 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 (vgl. 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 haupia-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 haupia-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 haupia 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 bzw. 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 Strichpunkt bezieht sich auf den Port auf den der zookeeper auf Verbindungen horcht.
Zusätzlich muss eine Angabe gemacht werden, die sog. "4 letter words" Kommandos erlaubt.
Diese werden vom Solr benötigt.
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=*
Bei der Serverkonfiguration im Abschnitt oben wird pro Server eine id mitgegeben, zum Beispiel bei "sever.1" ist die id 1. Die id sollte eine Zahl sein zwischen 1 und 255. Die id des Servers wird definiert in der Datei "myid" im Datenverzeichnis. Diese muss angelegt werden uns enthält nur die id.
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 haupia-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 haupia-Knoten wird während der Installation des haupia-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 ZooKeeper sowie eine Installation unter |
Die Speicherung der Konfigurationen aus dem Backend von haupia 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 haupia-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 |
haupia 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
haupia ist eine auf Spring Boot basierende Suchlösung und ermöglicht die Steuerung, Filterung und Analyse von individualisierten Trefferlisten.
Um die Funktionalitäten des haupia-Stacks zu nutzen, ist dieser auf beiden Systemen in das zu erstellende Verzeichnis haupia
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.
Abweichungen sind in der |
Nach der Installation des haupia-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 der haupia-Server.
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 haupia-Stack 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 keine Verwendung des haupia-Cockpits 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
konfiguriert werden auf wieviele FirstSpirit-Projekte in Form eines eigenen Datengenerators reagiert werden muss.
Ist der Wert kleiner als die Anzahl der angebundenen FirstSpirit-Projekte, so führt dies dazu dass nicht von allen Projekten Daten empfangen werden können.
Ist dieser Wert nicht gesetzt, so gilt ein Maximum von 'Anzahl der Kerne * 500'.
Der Master-Admin wird beim initialen Start des ersten haupia-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 haupia-Cockpit.
Das Master-Admin-Passwort kann im haupia-Cockpit geändert werden.
Ein Start des haupia-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 haupia-Servers zu definieren.
Starten Sie den haupia-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 haupia-Instanz die folgende Meldung über den erfolgreichen Start enthält, kann die zweite Instanz analog gestartet werden:
Logmeldung.
less /opt/haupia/logs/haupia.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 haupia.service
-Datei, die in der Auslieferung im Ordner systemd-samples
enthalten ist, auf beiden Systemen jeweils in das Verzeichnis → → .
Diese ermöglicht, haupia 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 haupia sowie eine Installation unter |
Die installierten und konfigurierten haupia-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 haupia-Cockpit ausschließlich auf dem Leader aufrufen. Dies hat zur Folge, dass sowohl die Konfiguration als auch die automatische bzw. 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 haupia-Lizenz in einer Textdatei auf dem haupia-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 haupia-Lizenz.
haupia: licence: path: ./license.txt
haupia basiert auf Spring Boot und lässt sich über die application.yml
-Datei, die im haupia-Verzeichnis neben dem haupia-Jar 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
haupia nutzt per default 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 haupia-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 haupia-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 haupia-cluster-1 server.jar[1208]: A, SSL_DH_anon_WITH_DES_CBC_SHA, [...]
Diesen 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 haupias müssen in der Solr-Weboberfläche abschließend die nachfolgenden Schritte durchgeführt werden. Sie ermöglichen auf beiden Solr-Instanzen die automatische Replikation der Daten, die haupia für die Beantwortung von Suchabfragen benötigt.
Die beschriebenen Schritte beziehen sich lediglich auf beschriebenen den 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 und Datenredundanz 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 haupias notwendigen Benutzer und Gruppen sowie die Definition der Berechtigung findet standardmäßig innerhalb des haupia-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 haupia-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 haupia-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 haupia-Cockpits bearbeiten darf. |
Der erfolgreiche Login eines Benutzers setzt voraus, dass dem haupia-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 müssen in der application.yml
-Datei des haupia-Servers die folgenden Pflichtparameter angegeben werden:
haupia.ldap.enable
haupia.ldap.enable
auf true
zu setzen.
spring.ldap.username
& 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. Gruppen-Objekten 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
& haupia.ldap.user-attributes.password
uid
und userPassword
.
haupia.ldap.user-attributes.language
& haupia.ldap.user-attributes.default-language
language
-Parameters lässt sich steuern, in welcher Sprache das haupia-Cockpit gestartet wird.
Fehlt er, wird stattdessen der Wert des default-language
-Parameters verwendet.
Dieser definiert als Default-Sprache initial Englisch.
haupia.ldap.group-attributes.name
& haupia.ldap.group-attributes.user
cn
und member
.
Die Gruppennamen werden im haupia-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 haupia gesammelten Daten setzt eine Kommunikation zwischen den einzelnen Komponenten sowie der Endanwendung des Kunden voraus. Die Kommunikation des haupia-Stacks nach außen ist dabei per SSL geschützt. Der haupia-Server verwendet dafür standardmäßig ein selbstsigniertes Zertifikat, das in der Auslieferung enthalten ist.
Für den Einsatz des haupia-Stacks im Produktivbetrieb wird die Verwendung eines offiziell signierten Zertifikats dringend empfohlen. Das in der Auslieferung enthaltene, selbstsignierte Zertifikat ist lediglich für den Einsatz in lokalen Entwicklungsumgebungen ausgerichtet. |
Für die Durchführung der nachfolgenden Schritte wird vorausgesetzt, dass bereits ein offiziell signiertes Zertifikat angefordert wurde und die Datei server.crt somit zur Verfügung steht. Des Weiteren wird angenommen, dass alle notwendigen Dateien jeweils in demselben Verzeichnis abgelegt sind. |
Für den Einsatz des haupia-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 haupia-Cockpit ist ein Bestandteil haupias.
Es dient der Backend-seitigen Verwaltung der durch haupia 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 haupia-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 haupia-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 er 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
.
Mithilfe dieser Bereiche lässt sich die Ausgabe der von haupia erfassten Daten konfigurieren.
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 haupia 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.
CloudModus |
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.
Wenn Haupia im Cloudmodus ist befindet sich die neben dem Eingabefeld für den Namen eine Checkbox mit welcher die Erreichbarkeit einer Prepared Search umgestellt werden kann.
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.
CloudModus |
Diese 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 angezeigt wird, 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 angezeigt werden, 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 haupia für jede der 26 unterstützten Sprachen eine Liste sogenannter Stoppwörter, die im Menübereich →
in Form eines Drop-Down-Menüs bereitgestellt werden.
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 angezeigt werden, erlauben die Bearbeitung bzw. Löschung eines einzelnen Eintrags der Liste.
Jede Änderung an der selektierten Liste muss abschließend über den Button mit dem Symbol eines Hakens, der neben dem Drop-Down-Menü dargestellt ist, gespeichert werden. Erst mit diesem Klick werden die Anpassungen übernommen, 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 haupia für jede der 26 unterstützten Sprachen eine Liste sogenannter Synonyme bereit.
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, die per Klick auf den Button mit dem Plus-Symbol in die Liste übernommen werden.
Ü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 angezeigt werden, die Bearbeitung bzw. Löschung eines einzelnen Eintrags in der Liste.
Jede Änderung an der selektierten Liste muss abschließend über den Button mit dem Symbol eines Hakens, der neben dem Drop-Down-Menü dargestellt ist, gespeichert werden. Erst mit diesem Klick werden die Anpassungen übernommen, 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.
Die zu analysierenden Daten werden automatisch alle fünfzehn Minuten aktualisiert, 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 sich durch einfaches Anklicken auswählen lassen.
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.