Konfiguration
Konfigurationsdateien
Folgende Konfigurationsdateien werden von smart.finder verarbeitet:
-
WEB-INF/classes/default-application.properties
(NICHT EDITIEREN)
In dieser Datei befinden sich alle Konfigurationsoptionen von smart.finder mit ihren Standardwerten. -
WEB-INF/classes/custom-application.properties
Wenn Sie das Arbeitsverzeichnisdata.directory.location
ändern, müssen Sie diese Datei anpassen. Alle weiteren Anpassungen erfolgen in der nachfolgenden Datei. -
[data.directory.location]/application.properties
Das Bearbeiten dieser Datei ist der empfohlene Weg Konfigurationsänderungen vorzunehmen.
Standardmäßig ist${user.home}/.smartfinder
das Arbeitsverzeichnisdata.directory.location
von smart.finder. Dieapplication.properties
wird nicht automatisch erstellt. Als Vorlage können Sie die DateiWEB-INF/classes/application.properties
nutzen. Es wird empfohlen, nur die Einstellungen in der Datei zu belassen, die geändert wurden.
Das Format der Konfigurationsdateien muss dem Java Properties Dateiformat entsprechen.
# Die Dateien müssen UTF-8 kodiert sein, sonst können Umlaute zu Fehlern führen!
# Am sichersten ist die Kodierung von Umlauten in Unicode-Syntax z.B: ä = \u00E4 (vgl. http://0xcc.net/jsescape/)
# Kommentare erfolgen mit vorangestellter Raute
# Allgemeine Syntax:
key = value
# Ein Value kann einen anderen Key referenzieren
key1 = http://${key.with.server}/test
Starten Sie nach Änderungen an einer der Konfigurationsdateien die Web-Applikation oder alternativ den kompletten Tomcat Server neu. |
Konfigurationsparameter
In diesem Abschnitt werden die Parameter beschrieben, die am häufigsten in einer Standardinstallation verändert werden müssen.
Weitere Parameter sind in der Datei WEB-INF/classes/default-application.properties
in Kommentaren beschrieben.
Sowohl im Client als auch im Server liegen diese Konfigurationsdateien vor.
In der folgenden Auflistung wird nicht danach unterschieden.
Halten Sie sich an die jeweilige default-application.properties , um die Parameter für die jeweilige Web-Applikation zu verändern.
|
data.directory.location
-
Arbeitsverzeichnis, in dem map.apps-Daten (z.B. eine HSQL-Datenbank) lokal gespeichert werden.
Für den Fall, dass der Tomcat-Server als Windows-Dienst betrieben wird, liegt der
.smartfinder
Ordner im Nutzerverzeichnis des Tomcat-Nutzers, der den Dienst gestartet hat. Pfad-Trenner müssen entweder als/
oder\\
angegeben werden.Standardwert:
$\{user.home\}/.smartfinder
proxy.allowedServerUrls
-
Liste von URLs, auf die das Proxy Servlet zugreifen darf.
smart.finder stellt ein integriertes Proxy Servlet bereit. Ein direkter Zugang zu bestimmten Ressourcen, die nur unter einer anderen Domänen erreichbar sind, ist aufgrund von Sicherheitsbeschränkungen innerhalb von JavaScript untersagt. Dieser Parameter definiert entsprechende Ausnahmen. Nach jeder URL muss ein
;
gesetzt werden. Jede Zeile, mit Ausnahme der Letzten, endet mit einem\
. finder.service.url
-
Context-Name des smart.finder Servers.
Wurde der Name bei der Installation des smart.finder Servers geändert, so muss hier der aktuelle Name eingetragen werden.
Standardwert:
/smartfinder-search
solr.solr.home
-
Verzeichnispfad zum
solr.home
.Der Pfad kann absolut oder relativ angegeben werden. Es können auch Platzhalter verwendet werden, die durch den Web Container aufgelöst werden.
Beispiel:
solr.solr.home = ${catalina.base}/webapps/smartfinder-search/WEB-INF/solr.home
solr.default.core.name
-
Der Standardindex des Servers.
Dieser Index wird verwendet, wenn bei der Job-Erstellung im Manager kein Index angegeben wird.
Standardwert:
core0
Security
security.mode
-
Absicherungsmodus des administrativen Bereichs des smart.finders.
Der Zugriff auf die administrativen Bereiche des smart.finder ist geschützt (Standardwert:
INTEGRATED
). Der ModusONLY_AUTHN
kann nur in Verbindung mit security.manager Enterprise Edition verwendet werden. Der ModusIDENTITY
kann nur in Verbindung mit dem Identity Service verwendet werden.Bitte beachte die zu den Modi gehörenden zusätzliche Parameter.
Erlaubte Werte:
INTEGRATED
,IDENTITY
,ONLY_AUTHN
Standardwert:INTEGRATED
Zusätzliche Parameter für den Modus INTEGRATED
Der Modus INTEGRATED
kann über den folgenden Parametersatz näher spezifiziert werden:
security.user.admin.name
-
Nutzername im Plaintext.
security.user.admin.pw
-
Passwort des Nutzers.
Diese muss entsprechend der gewählten Kodierung beschrieben sein.
security.user.pwenc
-
Kodierung des Passworts.
Dieses kann
plain
(keine Kodierung) oder mittelsMD5
(Message-Digest Algorithm 5) bzw.SHA-1
(secure hash algorithm) erfolgen. Es existieren Webdienste, die bei der Erzeugung mittels MD5 oder SHA-1 verschlüsselter Passwörter unterstützen.Erlaubte Werte:
plain
,MD5
,SHA-1
security.user.use_mapped_pass
-
Gibt an, ob eine andere Passwortkodierung als
plain
gewählt wurde.Erlaubte Werte:
true
,false
security.ssl.trustAny
-
Gibt an, ob selbst signierte Zertifikate bei HTTPS-Verbindungen unterstützt werden.
Erlaubte Werte:
true
,false
Standardwert:false
Zusätzliche Parameter für den Modus IDENTITY
Der Modus IDENTITY
kann über den folgenden Parametersatz näher spezifiziert werden:
security.login.base
-
Basis URL des Identity Service.
esri.api.arcgisPortalUrl
-
URL auf die verwendete ArcGIS Online Organisation.
Der Wert muss mit der Konfiguration für
security.oauth.provider.arcgis.url
im Identity Service übereinstimmen.
Zusätzliche Parameter für den Modus ONLY_AUTHN
Der Modus ONLY_AUTHN
kann über den folgenden Parametersatz näher spezifiziert werden:
security.administration.url
-
URL zum security.manager Administration Service
security.keystore.location
-
Pfad zur Keystore-Datei
Dies ist der Pfad zur Keystore-Datei, welche von security.manager und smart.finder genutzt wird.
Mailing
mailing.host
-
Rechnername, auf dem ein SMTP Server für das Versenden von E-Mails zur Verfügung steht.
mailing.port
-
SMTP Port auf dem SMTP Host-Rechner.
mailing.username
-
Nutzername für den SMTP Server.
mailing.password
-
Passwort für den SMTP Server.
mailing.senderaddress
-
Antwortadresse für den E-Mail Versand.
mailing.locale
-
Spracheinstellung für das Versenden von E-Mails.
Erlaubte Werte:
de
,en
Logging
Es stehen folgende Konfigurationsparameter zur Anpassung des Loggings zur Verfügung:
logging.logger.level
-
Detailgrad des Logs.
Mögliche Werte:
TRACE
,DEBUG
,INFO
,WARN
,ERROR
Standardwert:INFO
logging.output.location
-
Ersetzt seit 2.0.8
Verwenden Sie stattdessenlogging.file.location
logging.file.location
-
Ort, an dem die Log-Datei gespeichert wird.
Der Standardwert entspricht dem
logs
Verzeichnis des Tomcat. Mit dem Wert${data.directory.location}/logs
wird die Log-Datei im Arbeitsverzeichnis von smart.finder erzeugt.Standardwert:
${catalina.base}/logs
logging.file.prefix
-
Dieser Parameter definiert den Namen der Log-Dateien.
Um den Log-Dateien den URL-Kontextpfad der ct-smartfinder-Installation voranzustellen (zum Beispiel
smartfinder
), verwenden Sie den Wert${webcontext.name}
.Standardwert:
ct-smartfinder
Weitere Logging-Parameter sind in der Datei |
Wildcard- und Phrasensuche
Ab der Version 2.4.0 wird Wildcard- und Phrasensuche durchgängig unterstützt. Per Default ist diese aktiviert.
Änderung des Speicherorts des Index
In der Standardauslieferung werden die Indexe von smart.finder unter folgendem Pfad abgelegt:
%TOMCAT%\webapps\smartfinder-search\WEB-INF\solr.home
In der hier lokalisierten Unterverzeichnissen werden die Indexe der einzelnen Cores gespeichert.
Um den Speicherort der Indexe zu ändern, müssen Sie den Wert der Variable solr.solr.home
in der Datei application.properties
anpassen.
solr.solr.home=[absoluter Pfad]
Nach einem Neustart werden die Indexe in diesem Verzeichnis abgelegt.
Suchergebnisse sortieren
In der Standardkonfiguration wird das Ergebnis einer Suchanfrage an den Index anhand der Trefferwahrscheinlichkeit Score
sortiert.
Sollen Ergebnisse im Gegensatz dazu nach einem Feld (z.B. Titel
) alphabetisch sortiert werden, so muss die Schema-Konfiguration dieses Feldes eindeutig sein.
Das heißt, Felder, die von Analyzern benutzt werden (unter anderem alle Felder vom Typ text
), können nur für die Sortierung von Suchergebnissen benutzt werden, wenn der Analyzer genau einen einzigen Ausdruck generiert.
Weitere Einschränkungen für das Sortieren finden Sie in der Solr Dokumentation .
Um dennoch auf solchen Feldern sortieren zu können, müssen diese Felder im Schema mittels copyField in ein neues Feld mit einem anderen Typ kopiert werden.
Nachfolgend ein Beispiel für das Feld name
:
-
Ändern Sie die
schema.xml
Angepasste schema.xml<fields> [...] <field name="name" type="text" indexed="true" stored="true" required="false" multiValued="false"/> <copyField source="name" dest="name_string"/> <field name="name_string" type="string" indexed="true" stored="true" required="false" multiValued="false"/> [...] </fields>
-
Speichern Sie die Datei.
-
Starten Sie den smart.finder Server oder Apache Tomcat neu, damit die Änderungen wirksam werden.
Konfiguration von Synonymen der Facettenwerte
Manchmal sind die in der Datenbank verwendeten Begriffe für eine Sache nicht einheitlich. Sie sollten Synonyme entsprechend der unten stehenden Anleitung zusammen fassen.
Beispielsweise beziehen sich die Werte shape
und Shapefile
beide auf dasselbe Format.
Sie können die Werte der Facette Format
immer als SHP
in der Nutzeroberfläche anzeigen lassen.
Um dies zu konfigurieren sind zwei Schritte nötig.
Schritt 1: Abbildung von Werten auf Synonyme
Pflegen Sie die Synonyme in der Konfigurationsdatei /smartfinder-search/WEB-INF/solr.home/core0/conf/lang/synonyms.txt
ein.
Für das obige Beispiel müssen Sie die folgende Zeile ergänzen:
shape, Shapefile => SHP
Die Werte vor dem Pfeil werden zusätzlich im Index abgelegt.
Sie können nach shape , Shapefile sowie SHP suchen.
Im Attributfilter wird immer SHP angezeigt.
Ein Filter auf dem Wert SHP schließt dann alle seine Synonyme mit ein.
|
Schritt 2: Synonym-Index-Verknüpfung
Verknüpfen Sie nun die Synonyme mit dem Feld im Index.
Öffnen Sie dazu die Datei /smartfinder-search/WEB-INF/solr.home/core0/conf/schema.xml
und suchen das Feld, für dessen Werte Sie die Synonyme definieren.
In unserem Beispiel handelt es sich um das Feld format
:
<field name="format" type="string" indexed="true" stored="true" required="false" multiValued="true"/>
Legen Sie darunter nun ein neues Feld mit dem Typ text_synonym
, beispielsweise dem Namen format_facet
und den folgenden Attributen an:
<field name="format_facet" type="text_synonym" indexed="true" stored="true" required="false" multiValued="true"/>
Weisen Dokumente beim Indexieren einen Wert für das Feld format
auf, wird dieser auch in das Feld format_facet
kopiert.
Dieses Feld kann als Facette genutzt werden und muss dann auch in der Client-Konfiguration facetFields
konfiguriert werden, siehe Auswahl und Reihenfolge von Filterattributen.
Optimierung für Suchmaschinen (SEO)
Dokumente, die im Index gespeichert sind, können für Internet-Suchmaschinen wie Google oder Bing auffindbar gemacht werden. In diesem Abschnitt werden die erforderlichen Schritte für die Konfiguration von smart.finder beschrieben.
Erzeugung einer Sitemap
Um Web Crawlern zu ermöglichen, Detailinformationen zu Dokumenten in smart.finder zu finden, müssen ihnen die URLs bekannt sein, die zu den Webseiten mit diesen Informationen führen. Da diese Seiten im smart.finder dynamisch erzeugt werden, werden Sitemaps verwendet, um diese zu listen.
Sitemaps sind XML-Dateien, in denen die URLs zu den Detailseiten abgelegt sind. Diese Dateien können von Suchmaschinen ausgelesen werden. Ist die Sitemap-Funktion aktiviert, erzeugt smart.finder diese XML-Dateien automatisch und speichert diese auf dem Server, auf dem smart.finder betrieben wird.
Eine Übersicht über das Protokoll, das für Sitemaps verwendet wird, finden Sie hier .
Konfigurationsparameter
Die Konfiguration der Sitemap-Erzeugung erfolgt über folgende Parameter:
sitemap.enabled
-
Aktiviert/Deaktiviert die automatische Erzeugung der Sitemap.
Mögliche Werte:
true
,false
Standardwert:false
sitemap.executionTime
-
Ein Cron-String der festlegt, zu welchen Zeiten die Sitemap mit den aktuellen Dokumenten neu erzeugt wird.
Standardwert:
0 0 6 * * ?
(Bedeutung: Jeden Tag um 6 Uhr morgens) sitemap.coreName
-
Der Name des Index, für den die Sitemap erstellt werden soll.
Standardwert:
${solr.default.core.name}
sitemap.queryString
-
Ein optionaler Filterausdruck, der angewendet wird, um die Menge der Dokumente einzuschränken, die in die Sitemap aufgenommen werden sollen. Dieser Filter wird zur Abfrage der
smart.finder search
Komponente bei der Erzeugung der Sitemap ausgeführt. Alle Dokumente, die dem Filter entsprechen, werden in die Sitemap aufgenommen. Die Syntax des Filterausdrucks entspricht dem des Standard Query Parsers von Apache Solr.Standardwert:
*:*
sitemap.lastModifiedFields
-
Eine sortierte Liste mit Namen der Attribute, die das Datum der zuletzt erfolgten Änderung eines referenzierten Dokuments enthalten.
In der XML-Datei der Sitemap kann zusätzlich zu jeder URL das optionale Element
lastmod
mit angegeben werden, welches einen Datumswert enthält. Dieses Datum drückt die Aktualität der Ressource aus. Es gibt eine Reihe von Feldern im Index, die als Quelle für dieses Datum infrage kommen, z.B.created
odermodified
. Welches Feld für das Aktualitätsdatum verwendet werden soll, hängt vom konkreten Inhalt des Index ab.Beispiel: Der Wert des Parameters
sitemap.lastModifiedFields
lautetcreated, modified
. Bei der Erstellung der Sitemap wird im aktuellen Dokument zunächst geprüft, ob das Feldcreated
vorhanden ist. Ist dies der Fall, wird dessen Wert für das Elementlastmod
in der Sitemap verwendet. Ist das Feld nicht vorhanden, wird auf das zweite Feld in der Liste (hier:modified
) geprüft usw. Ist keines der Felder vorhanden, wird das Elementlastmod
in der Sitemap für das aktuelle Dokument nicht erzeugt. sitemap.maxEntries
-
Maximale Anzahl von URLs pro Sitemap-Datei.
Jede Sitemap Datei darf maximal 50.000 Einträge beinhalten oder im unkomprimierten Zustand 50 MB groß sein. Wird die hier angegebene maximale Anzahl von Einträgen in einer Sitemap überschritten, wird automatisch eine neue Sitemap-Datei für die weiteren Einträge erzeugt. Bei mehr als einer Sitemap-Datei wird zudem eine Datei
sitemap_index.xml
im gleichen Verzeichnis angelegt, welche auf die einzelnen Sitemap-Dateien verweist.
Standardwert: 45000
sitemap.baseUrl
-
Gibt die Basis-URL des Servers an, welcher die Sitemap-Dateien ausliefert. In der Regel ist dies die URL, unter der der smart.finder Client zu erreichen ist, z.B.
https://[HOST]:[PORT]/smartfinder
. sitemap.storageLocation
-
Der Speicherort der Sitemap-Datei im Dateisystem. Es bietet sich an, nach Möglichkeit hier direkt das Root-Verzeichnis der smart.finder Applikation anzugeben, damit die Dateien direkt über
${sitemap.baseUrl}
erreichbar sind.
Sicherstellung gleichbleibender Bezeichner (IDs)
Für den Zugriff auf Dokumente im Index ist ein fester Bezeichner essenziell. Werden Ressourcen indexiert, die keine eindeutige ID haben, wird diese von smart.finder während der Indexierung automatisch erzeugt. Damit bei jedem Indexierungsdurchgang derselbe Bezeichner für ein Dokument erzeugt wird, muss in der Wird kein Feld für ein Dokument gefunden, wird eine Zufalls-ID erzeugt. |
Bereitstellung der robots.txt-Datei
Um einem Web Crawler mitzuteilen, welche Inhalte der Webseite durchsuchbar sein sollen und welche nicht, kann eine sogenannte robots.txt
-Datei verwendet werden. In dieser Datei wird außerdem die URL zur Sitemap-Datei angegeben. Eine Einführung in die Syntax finden Sie z.B. hier .
Im Root-Verzeichnis der Web-Applikation smartfinder
finden Sie eine vorbereitete Datei robots.txt.sample
, welche die grundlegenden Einstellungen beinhaltet. Ändern Sie diese Datei entsprechend den Anforderungen an das Web Crawling Ihrer Seite. Ersetzen Sie in jedem Fall [SITEMAP_URL]
durch die absolute URL auf die von smart.finder erzeugte Sitemap.
Beispiel:
Sitemap: https://demos.conterra.de/smartfinder/sitemap-1.xml.gz
Wurde mehr als eine Sitemap-Datei und somit auch eine sitemap_index.xml.gz
-Datei erzeugt, fügen Sie hier die URL zu dieser Sitemap-Index-Datei ein.
Beispiel:
Sitemap: https://demos.conterra.de/smartfinder/sitemap_index.xml
Benennen Sie die Datei anschließend in robots.txt
um. Wenn ein Web Crawler Ihre Webseite besucht, schaut er zunächst nach der robots.txt
-Datei und beginnt dann die Inhalte Ihrer Webseite entsprechend der Einstellungen in dieser Datei zu indexieren.
Dynamisches Rendern für smart.finder
Die smart.finder Benutzeroberfläche basiert zu einem großen Teil auf JavaScript. Viele Internetsuchmaschinen, die diese Webseiten abrufen und die Inhalte auslesen, stellt dies vor Probleme, da sie JavaScript nur eingeschränkt unterstützen.
Um dieses Problem zu umgehen, kann smart.finder eine Seite im Voraus rendern, wenn die Seite von einer Suchmaschine angefragt wurde. Der JavaScript-Code der Webseite wird also bereits auf dem Server ausgeführt und nur noch der generierte HTML-Code an die Suchmaschine ausgeliefert. Normalen Besuchern der Webseite wird weiterhin der JavaScript-Code ausgeliefert, sodass sich für sie nichts ändert.
Für das dynamische Rendern der Webseiten muss Rendertron auf dem Server installiert sein. Rendertron ist eine Serveranwendung und basiert auf Node.js und Puppeteer. Es benötigt eine auf dem Server installierte Instanz von Google Chrome.
Installation von Rendertron
Folgen Sie den Anweisungen auf der Rendertron-Webseite, um Rendertron auf Ihrem System zu installieren. Wenn Rendertron installiert wurde und ausgeführt wird, nimmt es Anfragen auf dem Port 3000 entgegen. Der Rendertron-Dienst muss vom smart.finder-Backend erreichbar sein und sollte nicht öffentlich zugreifbar sein.
Konfiguration von smart.finder
Die Konfiguration von smart.finder unterscheidet sich je nach der Variante, in der Sie smart.finder installiert haben (Standalone oder in einer vorhandenen map.apps-Instanz).
Konfiguration von smart.finder bei Verwendung der Standalone-Variante
Wenn Sie smart.finder mit der mitgelieferten smartfinder.war
-Datei in der Standalone-Variante installiert haben, gehen Sie folgendermaßen vor:
-
Stellen Sie für die folgende Konfigurationseigenschaft in der
application.properties
-Datei der "smartfinder"-Webapp die URL ein, unter der der Rendertron-Dienst für das smart.finder Backend erreichbar ist:seo.dynamicRendering.url=http://localhost:3000/render
-
Starten Sie anschließend den Tomcat-Server neu, sodass smart.finder mit der neuen Einstellung geladen wird.
Konfiguration von smart.finder bei Verwendung einer vorhandenen map.apps-Instanz
Wenn Sie die smart.finder-Bundles in einer bereits vorhandenen map.apps-Instanz installiert haben, ist die Einrichtung des dynamischen Renderns etwas aufwändiger:
-
Kopieren Sie die Datei
resources/seo/ct-finder-seo-filter-%version%.jar
aus der smart.finder-Auslieferung in den Ordner%TOMCAT%/webapps/mapapps/WEB-INF/lib
(der Ordnermapapps
hat in Ihrer Installation möglicherweise einen abweichenden Namen). -
Öffnen Sie die Datei
%TOMCAT%/webapps/mapapps/WEB-INF/classes/spring-filter-config.xml
in einem Texteditor. -
Suchen Sie in der Datei das Element
<ref bean="jsonTojspDispatcherFilter"/>
und fügen Sie wie im Folgenden gezeigt das Element<ref bean="prerenderFilter"/>
hinzu.<list> ... <ref bean="jsonTojspDispatcherFilter"/> <!-- Bereits vorhandenes Element --> <ref bean="dynamicPrerenderFilter"/> <!-- <- Fügen Sie dieses Element neu hinzu --> </list>
-
Fügen Sie im unteren Bereich derselben Datei noch innerhalb des äußeren
beans
-Elements das folgendebean
-Element hinzu:<beans> <!-- ... --> <!-- Bereits vorhandenes Element --> <bean id="propertiesReplacementFilter" class="de.conterra.config.support.rest.PropertiesReplacementFilter"> <property name="propertiesResolver" ref="configPropertiesResolver"/> <property name="acceptPath" value="/,/account/login/,/manager/,/manager/3.x/*,/*.html,**/index.html,**/boot.js,**/*init.js,**/*.json,/js/sample/,/js/sample/**/*.html,/js/tests/test-apps/,/js/**/tests/**/*.html"/> <property name="excludePath" value="/resources/**,/event/**,/proxy/**,**/$raw/**"/> </bean> <!-- +++++++++++++++++++ --> <!-- Fügen Sie das folgende bean-Element neu zur Datei hinzu --> <bean id="dynamicPrerenderFilter" class="de.conterra.finder.seo.DynamicRenderingFilter"> <constructor-arg name="renderer"> <bean class="de.conterra.finder.seo.DefaultRenderer"> <constructor-arg name="baseURL" value="${seo.dynamicRendering.url}"/> <constructor-arg name="httpClientFactory" ref="defaultHttpClientFactory"/> </bean> </constructor-arg> <constructor-arg name="searchBotSniffer"> <bean class="de.conterra.finder.seo.SearchBotSniffer"> <constructor-arg name="userAgentRegEx"> <array value-type="java.lang.String"> <value>.*bingbot.*</value> <value>.*Googlebot.*</value> </array> </constructor-arg> </bean> </constructor-arg> </bean> </beans>
-
Öffnen Sie die
application.properties
-Datei der map.apps-Instanz und ergänzen Sie die folgende Einstellung:seo.dynamicRendering.url=http://localhost:3000/render
Stellen Sie hier die URL ein, unter der der Renderer-Dienst für das map.apps-Backend erreichbar ist. Rendertron verwendet standardmäßig den Port 3000.
-
Starten Sie anschließend den Tomcat-Server neu, sodass map.apps mit den neuen Einstellungen geladen wird.
Anmeldung bei Suchmaschinen
Im letzten Schritt sollten Sie Ihre Website bei den gewünschten Suchmaschinen anmelden. In Google ist dies zum Beispiel über die Google Search Console möglich. In Bing können Sie die Anmeldung über die Bing Webmaster Tools vornehmen.