Option

Beschreibung

Bind Port

Der Port, auf dem der Service laufen soll

Boosting Data Cache Refresh Interval Seconds

Der Service verwendet intern einen Cache, um die Suchanfragen effizient bearbeiten zu können. Je nachdem, wie aktuell die Daten für die Relevanzberechnung sein müssen, können sie das Intervall zum Erneuern des Caches in Sekunden angeben.

Wird „0“ angegeben, wird der Cache nicht aufgebaut. Stattdessen kann das Refresh Servlet unter /api/boostings/refresh verwendet werden, um die Aktualisierung des Caches manuell zu starten.

Boosting Type (Advanced Setting)

Damit das Plugin auch bei älteren Mindbreeze InSpire Versionen funktioniert, kann die Option „QueryExpr“ ausgewählt werden. Aus Performancegründen sollte jedoch, wenn möglich immer „FQCategory and Key“ ausgewählt werden

Report Heap Dump on out of Memory (Advanced Setting)

Wenn aktiv und es tritt ein OutOfMemoryError auf, wird im aktuellen Log-Verzeichnis ein Heap-Dump als .hprof-Datei abgelegt.

Default Servlet Page Size (Advanced Setting)

Die Standardseitengröße der Servelts

Maximum Number of Boosting Exports (Advanced Setting)

Boostings werden automatisch bei jedem Refresh exportiert. Dabei werden standardmäßig die letzten 10 Exports aufgehoben. Wie viele Exports aufgehoben werden, kann mit dieser Option konfiguriert werden.

Application Definitions

Um die Boostings von verschiedenen Search Clients zu trennen, können „Application Definitions“ angegeben werden:

• Name: der Name der Applikation (kann frei gewählt werden)
• Referer Patterns: Regex Patterns, die auf die URLs einer Applikation matchen. Durch Zeilenumbrüche getrennt können mehrere Patterns angegeben werden, um z.B. mehrere Search Clients in einer Application Definition zusammenzufassen.

Bei einer Suchanfrage werden die Boostings der ersten Applikation verwendet, die der URL der Suchanfrage entspricht. Standardmäßig gibt es außerdem eine „Application Definition“ mit dem Namen „default“, welche auf alle URLs matcht (.*) – diese ist jedoch in der Konfiguration nicht sichtbar.

Option

Beschreibung

Relative Minimum Queries To Boost

Die relative Anzahl an gleichen Suchanfragen, die mindestens zuvor abgesetzt wurden, um Dokumente mit einer bestimmten Query zu boosten. Wurde z.B. nach „mindbreeze“ 1000 mal gesucht und es gab 500000 Queries in der Vergangenheit, ist der Relative Queries To Boost für die Query „mindbreeze“ 1000/500000 = 0,002

Add Empty Boostings (Advanced Settings)

Fügt auch Boostings hinzu, die auch unter dem konfigurierten „Relative Minimum Queries To Boost“ liegen (mit Boosting Faktor 1). Diese Option hat keine Auswirkung auf das Relevanz-Modell, jedoch werden diese Boostings dann im Servlet /api/boostings angezeigt.

Boosting Base

Die Basis des Boosting-Werts (entspricht dem Minimalwert)

Boosting Factor

Der Faktor, wie stark sich das Boosting auswirkt

Action Frequency Weight Exponent

Kommawerte (mit . als Dezimaltrennzeichen) zwischen 0 und 1 sind gültig (0 = wird nicht in die Berechnung einbezogen, 1 = wird vollständig in die Berechnung miteinbezogen)

User Frequency Weight Exponent

Auswirkung auf das Boosting davon, wie viele verschiedene Benutzer eine Aktion am Dokument durchgeführt haben. Kommawerte zwischen 0 und 1 sind gültig.

Session Frequency Weight Exponent

Auswirkung auf das Boosting davon, in wie vielen verschiedene Sessions eine Aktion am Dokument durchgeführt wurde. Kommawerte zwischen 0 und 1 sind gültig.

Query Frequency Weight Exponent

Auswirkung auf das Boosting davon, wie oft die gleiche Suchanfrage (mit gleichem Query String) ausgeführt wurde (relativ zu allen ausgeführten Suchanfragen). Kommawerte zwischen 0 und 1 sind gültig.

Excluded Users Patterns

Patterns (Java RegEx) für Benutzer, welche durch ihr Suchverhalten die Boostings nicht beeinflussen sollen. Es können mehrere Patterns angegeben werden, getrennt durch Zeilenumbrüche. Kann beispielsweise dafür verwendet werden, dass die Suchen von automatisierten oder manuellen Tests keine Auswirkung auf das Boosting haben. Die Patterns werden mit Zeilenumbrüchen getrennt. Diese Option hat auch Auswirkung auf Vote Boostings.

Boost Votes

Wenn aktiviert, werden auch die up- und down-voted Ergebnisse im Relevanzmodell miteinbezogen. Das Relevanzmodell wird dabei unabhängig vom Suchbegriff beeinflusst.

Vote Dampening Up To

Die Anzahl der Votes, die benötigt werden, bis der maximale Boosting-Faktor erreicht ist (Maximum ist 0 für Down-Votes, 2 für Up-Votes)

Max Vote Boosting Factor Deviation

z.B. 2 führt zu Boostings zwischen 1-2=-1 (für Down-Votes) und 1+2=3 (für Up-Votes))

Option

Beschreibung

JDBC URL

Der JDBC URL zur app.telemetry Datenbank

Custom Credential

Die Anmeldeinformationen zur app.telemetry Datenbank. Dieses Feld kann leer gelassen werden („None“).

Wenn Sie jedoch den Default „JDBC URL“ geändert haben (jdbc:postgresql://localhost:5432/telemetrydb), müssen Sie die Anmeldeinformationen explizit konfigurieren. Fügen Sie dazu im Tab „Network“ unter „Credentials“ neue Anmeldeinformationen mit dem Type „Username/Password“ hinzu.

Die Standardanmeldeinformationen können in Initiale Inbetriebnahme für G7 Appliances – Reporting gefunden werden.

Falls Sie eine G6 Appliance in Verwendung haben, finden Sie die Standardanmeldeinformationen in Initiale Inbetriebnahme für G6 Appliances (vor Jänner 2018 ausgeliefert) – Reporting. Bitte beachten Sie auch, dass Sie in diesem Fall im Bereich „DB Schema“ (Advanced Setting) die Option „Table Name“ anpassen müssen.

Maximum Pooled Connections

Maximale an Datenbank Connections, die im Connection Pool gehalten werden.

Option

Beschreibung

Table Name

Default: clientservicequerylogmesclientservicequerylog

Wenn sie eine G6 Appliance in Verwendung haben, müssen sie diesen Wert anpassen. Gehen Sie zuerst im Mindbreeze Management Center auf Telemetry Details Configuration Log Pools Client Service Query Log und kopieren Sie den „Database Table Prefix“. Setzen Sie die Option „Table Name“ im PersonalizedRelevanceTransformer auf „<Database Table Prefx>mesclientservicequerylog“ (ohne Anführungszeichen), z.B. „client_service_query_logmesclientservicequerylog“

Query Id Column

Default: log:query_id

User Query Column

Default: query:user_query

Search User Column

Default: log:username

Action Column

Default: queryAction:action

Key Column

Default: queryResultAction:key

Weight Column

Default: queryResultAction:weight

FQCategory Column

Default: queryResultAction:fqcategory

Session ID Column

Default: log:session_id

Referer Column

Default: log:referer

Position Column

Default: queryResultAction:position

Total Count Column

Nur relevant für Reporting Query Logs
Default: query:total_count

Start Time Column

Nur relevant für Reporting Query Logs
Default: starttime

Duration Column

Nur relevant für Reporting Query Logs
Default: duration

Operation Column

Nur relevant für Reporting Query Logs
Default: log:operation

Scrollposition in Percentage Column

Nur relevant für Reporting Query Logs
Default: queryResultAction:scroll_position_in_percentage

Duration in ms Column

Nur relevant für Reporting Query Logs
Default: queryResultAction:duration_in_ms

Pfad

Beschreibung

/api oder
/index.html

HTML-Seite, die Links auf die anderen Servlets zur Verfügung stellt

/api/boostings

Gibt eine HTML-Tabelle zurück, die alle effektiven cached Boostings enthält (sortiert nach Query, Application, Boosting).

Folgende HTTP Query-Parameter können angegeben werden:

• pagesize: Anzahl der Resultate einer Seite
• offset: Das Offset der Seite
• application: Einschränkung auf „Application Definition“ aus der Konfiguration.
• query: Einschränkung auf Boostings für die angegebene Query
• fqcategory: Einschränkung auf das Metadatum fqcategory der Dokumente
• key: Einschränkung auf das Metadatum mes:key der Dokumente

/api/boostings/refresh

Erneuert den Boosting Cache. Der Cache wird regelmäßig automatisch erneuert, je nachdem, was in Option „Boosting Data Cache Refresh Interval Seconds“ konfiguriert ist.

Folgende HTTP Query-Parameter können angegeben werden, um Config-Options für den Cache Refresh zu überschreiben:

• blocking: wenn „true“, blockiert das Servlet und antwortet erst, wenn die Aktualisierung abgeschlosen ist
• badRequestOnAlreadyRunning: wenn „true“, liefert das Servlet einen HTTP Status Code 400, wenn ein Cache Aktualisierung gerade läuft
• status: wenn „true“, wird kein Refresh angestoßen. Stattdessen wird ein Status zur letzten oder gerade laufenden Cache Aktualisierung zurückgeliefert.
• relativeMinimumQueriesToBoost: überschreiben der Config-Option Relative Minimum Queries To Boost
• boostingBase: überschreiben der Config-Option Boosting Base
• boostingFactor: überschreiben der Config-Option Boosting Factor
• actionFrequencyWeightExp: überschreiben der Config-Option Action Frequency Weight Exponent
• uniqueUserFrequencyWeightExp: überschreiben der Config-Option User Frequency Weight Exponent
• uniqueSessionFrequencyWeightExp: überschreiben der Config-Option Session Frequency Weight Exponent
• queryFrequencyWeightExp: überschreiben der Config-Option Query Frequency Weight Exponent

/api/queries

Gibt eine HTML-Tabelle zurück, welche Queries wie oft abgesetzt wurden (sortiert nach Anzahl, absteigend).

Folgende HTTP Query-Parameter können angegeben werden:

• pagesize: Anzahl der Resultate einer Seite
• offset: Das Offset der Seite
• application: Einschränkung auf die angegebene Application

/api/actions

Gibt eine HTML-Tabelle zurück, die für jedes Dokument angibt, wie viele Benutzeraktionen durchgeführt wurden (pro Query ID wird maximal eine Aktion pro Dokument gezählt). Außerdem werden Statistiken zur Position der Dokumente in den Suchresultaten und zu den Boostings geliefert. Um die detaillierten Boostings und Queries zu erhalten, wird ein Link auf /api/boosting geliefert.

Folgende HTTP Query-Parameter können angegeben werden:

• pagesize: Anzahl der Resultate einer Seite
• offset: Das Offset der Seite

/api/referers

Gibt eine HTML-Tabelle zurück, welche alle Referer (URL, von denen eine Suche abgesetzt wurde), zu welche Application Definition diese gehören und wie oft eine Suche ausgeführt wurde.

Folgende HTTP Query-Parameter können angegeben werden:

• pagesize: Anzahl der Resultate einer Seite
• offset: Das Offset der Seite

/api/voteboostings

Gibt eine HTML-Tabelle zurück, die alle effektiven cached Vote Boostings enthält (sortiert nach Boosting, FQCategory, Application).

Folgende HTTP Query-Parameter können angegeben werden:

• pagesize: Anzahl der Resultate einer Seite
• offset: Das Offset der Seite
• application: Einschränkung auf „Application Definition“ aus der Konfiguration.
• query: Einschränkung auf Boostings für die angegebene Query
• fqcategory: Einschränkung auf das Metadatum fqcategory der Dokumente

/api/boostings/export

Boostings können als Binärdatei exportiert werden, um anschließend mithilfe des Import-Servlets wieder importiert zu werden. Dieses Servlet kann für Backups oder Producer-Consumer Setups verwendet werden.

Genau einer der folgenden HTTP Query-Parameter muss angegeben werden:

• directory: Der Pfad zum Verzeichnis, in dem die exportierte Datei abgelegt wird. Das Verzeichnis muss bereits existieren und der Benutzer „mes“ und die Gruppe „mes“ müssen berechtigt sein, in dem Ordner zu schreiben.
• zip: Der Pfad zu einem ZIP-Archiv, in dem der Export abgelegt wird. Das Archiv kann bereits (aber muss nicht) existieren. Das Verzeichnis, in dem das ZIP-Archiv abgelegt werden soll, muss jedoch bereits existieren und der Benutzer „mes“ und die Gruppe „mes“ müssen berechtigt sein, in dem Ordner zu schreiben

/api/boostings/import

Der mit dem Export-Servlet abgelegte Boosting-Cache kann mithilfe dieses Servlets wieder importiert werden. Bei jedem Import und Refresh wird zusätzlich automatisch ein Export in /data/currentservices/launchedservice-<service-name>/data/export/<uuid> abgelegt, der mithilfe des „uuid“-URL-Parameters wieder importiert werden kann.

Genau einer der folgenden HTTP Query-Parameter muss angegeben werden:

• directory: Der Pfad zum Verzeichnis, in dem die exportierte Datei abgelegt wurde.
• zip: Der Pfad zum ZIP-Archiv, in dem die exportierte Datei abgelegt wurde.
• uuid: Die UUID des gewünschten Exports. In /data/currentservices/launchedservice-<service-name>/data/export/persistenceInfo.json wird der Verlauf der automatischen Exports (Zeitstempel und UUID) mitprotokolliert.

api/boostings/clear

Boosting- und Servelt-Caches können gelöscht werden. Mithilfe von GET /api/boostings/refresh können diese Caches wieder aufgebaut werden.