Installation

Diese Seite beschreibt die Neuinstallation von smart.finder. Beachten Sie, dass die vorgegebenen Systemanforderungen erfüllt sind, siehe Systemanforderungen.

Wenn Sie eine bestehende Installation aktualisieren möchten, fahren Sie mit Update einer bestehenden Installation fort.

Installation von smart.finder

smart.finder besteht aus zwei WAR-Archiven, jeweils eines für den Server und den Standalone-Client. Diese Dateien finden Sie unter:

  • [RELEASE-ORDNER]/smartfinder.war

  • [RELEASE-ORDNER]/smartfinder-search.war

Installation der Server-Webapp

Installieren Sie zunächst den Suchdienst smartfinder-search.war.

  1. Optional können Sie den Namen der WAR-Dateien. Der Name erscheint in der URL zur Anwendung.

  2. Stellen Sie sicher, dass der Tomcat-Dienst gestartet ist.

  3. Kopieren Sie anschließend die WAR-Datei in den Ordner %TOMCAT%\webapps. Die Datei wird nun automatisch entpackt.
    Alternativ können Sie den Tomcat Manager benutzen, um die WAR-Datei zu installieren. Wenn der Tomcat-Dienst gestartet ist, erreichen Sie den Tomcat Manager üblicherweise unter http://<yourserver>:8080/manager/html.

  4. Um map.apps als Administrator oder Redakteur verwenden zu können, setzen Sie die Passwörter des Administrator- und Redakteur-Nutzers. Bitte lesen Sie dazu den Abschnitt zu dem Sicherheitsaspekte für weitere Erläuterungen.

Wenn Sie die WAR-Datei umbenannt haben, ändert sich ebenfalls der Speicherort des Suchindexes und muss dementsprechend angepasst werden.

Wenn die Installation erfolgreich war, ist die Server-Anwendung jetzt unter der folgenden URL verfügbar:

  • https://<yourserver>/smartfinder-search

Installation der Client-Webapp

Die Client-Anwendung kann auf zwei verschiedene Arten betrieben werden:

  • Als Standalone-Client
    Sie installieren die WAR-Datei für die smart.finder Client-Webapp auf die gleiche Weise, wie Sie die Server-Webapp wie im vorherigen Abschnitt beschrieben installiert haben. Die Client-Webapp ist mit sehr wenig Konfigurationsaufwand sofort einsatzbereit und es ist nicht erforderlich weitere Apps und JavaScript-Bundles zu installieren. Wählen Sie diese Installationsart, wenn Sie keine eigene map.apps-Instanz betreiben.

  • Als Apps in einer vorhandenen map.apps-Instanz
    Sie laden die JavaScript-Bundles und die Apps für smart.finder in einer vorhandenen map.apps-Instanz hoch. Dies ist die empfohlene Installationsart, wenn Sie bereits über eine lauffähige map.apps-Instanz verfügen. Mit map.apps wird das Verwalten von Apps und Bundles und das Anpassen von Apps deutlich erleichtert. map.apps enthält einen intelligenten Code-Editor, der Sie bei der Erstellung und Anpassung von App unterstützt.

Installation als Standalone-Client

Um die smart.finder Client-Webapp als Standalone-Client zu installieren, führen Sie dieselben Schritte wie im Abschnitt Installation der Server-Webapp beschrieben aus, jedoch verwenden Sie anstelle der Datei smartfinder-search.war die Datei smartfinder.war.

Wenn die Installation erfolgreich war, wie die Client-Webapp unter der URL https://<yourserver>/smartfinder erreichbar.

Der Standalone Client wird mit folgenden Apps ausgeliefert:

  • https://<yourserver>/smartfinder/?lang=de&app=full-page
    Zeigt eine Benutzeroberfläche dessen Design sich an typischen Internet-Suchmaschinen orientiert.

  • https://<yourserver>/smartfinder/?lang=de&app=full-screen-map
    Benutzeroberfläche mit einer bildschirmfüllenden Karte. Die Suchergebnisse werden in einer Seitenleiste angezeigt.

  • https://<yourserver>/smartfinder/?lang=de&app=full-screen-map-multicore
    Demonstriert ein Szenario mit mehreren Such-Cores. Ein Core ist ein Index, auf den der Client zugreifen kann, um nach bestimmten Informationen zu suchen.

Wenn Sie den Security Mode INTEGRATED verwenden, ändern Sie nach der Installation das Administratorpasswort mithilfe der Property security.user.admin.pw, siehe auch Web Application Security.

Installation innerhalb einer map.apps-Instanz

Als Alternative zum Standalone Client haben Sie die Möglichkeit, die smart.finder Apps und JavaScript-Bundles in einer vorhandenen map.apps-Instanz zu betreiben.

Installation der Bundles

  1. Melden Sie sich als admin-Benutzer in map.apps Manager an.

  2. Öffnen Sie den Reiter Bundles.

  3. Klicken Sie auf die +-Schaltfläche oberhalb der Liste der installierten Bundles.

  4. Laden Sie die Datei [RELEASE-ORDNER]/ct-smartfinder-js-2.4.1.jar hoch. Diese enthält alle Bundles für smart.finder.

  5. Falls Sie die map.apps Smart Search Bundles nutzen wollen, laden Sie zusätzlich die Datei [RELEASE-ORDNER]/ct-smartsearch-js-2.4.1-single.jar hoch.

Sobald die Bundles hochgeladen wurden, werden sie in der Liste der installierten Bundles angezeigt. Um die smart.finder-Bundles von anderen Bundles einfacher unterscheiden zu können, beginnen deren Namen immer mit dem Kürzel sf_.

Installation der Apps

  1. Melden Sie sich als admin-Benutzer in map.apps Manager an.

  2. Öffnen Sie den Reiter Apps.

  3. Klicken Sie auf die +-Schaltfläche oberhalb der Liste der installierten Apps. Es öffnet sich der App-Assistent.

  4. Geben Sie einen Namen und einen Titel für die App ein und gehen Sie im Assistenten vor bis zu dem Schritt für das Hochladen einer App.

  5. Die Apps liegen als ZIP-Dateien im Ordner [RELEASE-ORDNER]/resources/apps. Laden Sie die gewünschte App hoch.

  6. Fahren Sie mit den nächsten Schritten im Assistenten fort, bis der Assistent abgeschlossen ist.

  7. Starten Sie die App, indem Sie in der App-Liste auf der rechten Seite auf die Starten-Schaltfläche klicken.

Installation des smart.finder Job-Manager

Um den smart.finder Job-Manager innerhalb des map.apps Manager nutzen zu können, gehen Sie folgendermaßen vor:

  1. Öffnen Sie die map.apps Konfigurationsdatei application.properties. Diese liegt üblicherweise im Ordner [USER_HOME]/.mapapps

  2. Suchen Sie den Eintrag manager.config.viewbundles. Falls er bereits existiert, ergänzen Sie am Ende den Wert sf_jobadmin. Falls er noch nicht existiert, fügen Sie den Eintrag mit dem folgenden Wert ein:

    Beispiel für manager.config.viewbundles
    manager.config.viewbundles=appmanagement,reportmanagement,bundlemanagement,mapapps-github-manager,bundleupdatechecker,sf_jobadmin

Starten Sie Tomcat neu und laden Sie map.apps Manager erneut im Webbrowser. Anschließend erscheint im map.apps Manager der neue Reiter Indexierungs-Jobs.

Minimalkonfiguration

Konfiguration smart.finder URL

Nach der Installation der Client- und Server-Webapp, muss der map.apps-Client die URL der Serveranwendung für Suchanfragen kennen. Ergänzen Sie dazu in der Datei application.properties von map.apps den folgenden Eintrag:

finder.service.url=https://<yourserver>/smartfinder-search
smart.finder Server und map.apps mit unterschiedlichen Domänen

Falls die smart.finder Serverkomponente unter einer anderen Domäne als map.apps erreichbar ist, stellen Sie sicher, dass das map.apps Proxy-Servlet für den Zugriff auf den smart.finder Server freigeschaltet ist. In diesem Fall sollten Sie den Domänennamen des Clients zu der CORS-Konfigurationseigenschaft cors.allowed.origins in der Datei application.properties der smart.finder-Server-Webapp hinzufügen.

Wenn Sie Schwierigkeiten mit CORS haben, können Sie auch das map.apps Proxy Servlet verwenden. Für weitere Informationen siehe CORS Einstellungen.
Konfiguration smart.finder map.apps App

Zum Ausführen der mitgelieferten Apps ist nun alles konfiguriert. Diese Apps bieten Ihnen einen Ausgangszustand für eigene Anpassungen.

Wenn Sie smart.finder in einer ihrer eigenen map.apps Apps verwenden möchten, können Sie über den map.apps Manager das Bundle sf_full-screen-map zu dieser App hinzufügen. Das Bundle lädt alle nötigen weiteren Bundles, um die Suche per Omnisearch (dem Standard-Bundle in map.apps für Schlüsselwortsuche) und die Ergebnisanzeige in einem Popup zu ermöglichen.

Weitere Informationen zur Konfiguration finden Sie im Abschnitt Apps und Bundles.

Installation der CLI

Das smart.finder CLI ist ein Werkzeug, um über die Kommandozeile Indexierungsjobs zu verwalten.

finderctl wird als ausführbare Datei für Windows- und Linux-Betriebssysteme (x86-64 Architektur) ausgeliefert. Es befindet sich unter:

  • [RELEASE-ORDNER]\cli\windows_x64\finderctl.exe für Windows

  • [RELEASE-ORDNER]/cli/linux_x64/finderctl für Linux

Verzeichnis verschieben
Sie können das finderctl Verzeichnis inklusive der Hilfsdateien auch an einen beliebigen anderen Ort kopieren. Kopieren Sie ebenfalls die neben der ausführbaren Datei liegenden Hilfsdateien. Diese werden gegebenenfalls zur Laufzeit von finderctl benötigt.

Fügen Sie den Speicherort von finderctl zum Suchpfad Ihres Systems hinzu (z.B. $PATH oder %PATH%). So können Sie finderctl ausführen, ohne den vollständigen Pfad angeben zu müssen. Abhängig von Ihrem Betriebssystem ist es gegebenenfalls notwendig, finderctl zur Ausführung zu berechtigen.

Verifizieren Sie die Installation durch Ausführen des folgenden Befehls:

~$ finderctl --version

Sicherheitsaspekte

Den Zugriff auf sicherheitskritische Funktionen verwalten Sie komplett in der Serverkomponente des smart.finder. Diese beinhaltet das Anlegen von Indexierungsjobs, das Befüllen oder Löschen des Indexes sowie das Lesen spezifischer administrativer Schnittstellen. Für jeden dieser Fälle ist eine Nutzerauthentifizierung erforderlich, die im Browser angefragt wird.

Web Application Security

smart.finder besitzt Endpunkte für die Abfrage und den schreibenden Zugriff auf den Index oder sonstige Kernfunktionen. Sämtliche transaktionalen Endpunkte, sowie das gesamte Index-Management, können durch die folgenden Sicherheitsmodi geschützt werden:

NONE

Kein Schutz.

INTEGRATED

Dies ist der Auslieferungsmodus und schützt die Endpunkte mittels HTTP Basic Authentication.
Zwischen Frontend und Backend ist kein Single Sign-On realisiert, sodass hier eine Mehrfachanmeldung im Zugriffsfall notwendig ist.

ONLY_AUTHN

Dieser Modus kann nur in Verbindung mit dem security.manager verwendet werden.
Er realisiert einen Domain-Cookie-basierten Zugriff und unterstützt somit Single Sign-On zwischen den Komponenten.

Die genannten Sicherheitsmodi können mithilfe folgender Properties aktiviert werden:

#
#### security for smart.finder server web application
#

# mode "NONE", "INTEGRATED" (default) or "ONLY_AUTHN"
security.mode=INTEGRATED

# Admin user definition
security.user.admin.name=admin
security.user.admin.pw=admin
security.user.admin.roles=solrAdmin
# Password encoding
# plain|MD5|SHA-1
security.user.pwenc=plain
# must be true if 'plain' is not used in property security.user.pwenc
security.user.use_mapped_pass=false
# enable the login audit logging (works if security.mode != NONE)
security.user.login.log=true

# Additionally, the following properties are required for "ONLY_AUTHN"
security.administration.url=${security.administration.base.url}
security.was.service.url=${security.administration.url}/WAS
security.pdp.service.url=${security.administration.url}/PDP
security.sso.service.url=${security.administration.url}/resources/ssosessions
security.sso.token.service.url=${security.administration.url}/token/ssosession
security.login.service.url=/account/login

security.sso.cookie.name=${security.sso.cookie.name}
security.sso.cookie.domain=${security.sso.cookie.domain}
security.sso.cookie.bindToIP=false
security.sso.self.endpoint=${security.administration.url}/account/self

# Key Store Properties
security.keystore.location=${security.keystore.location}
security.keystore.passwd=${security.keystore.passwd}
security.keystore.key.alias=${security.keystore.key.alias}
security.keystore.key.passwd=${security.keystore.key.passwd}

Die folgenden Werte der Properties müssen entsprechend ihrer Umgebung gesetzt werden:

security.administration.base.url

URL zur /administration Web Applikation des security.managers.

security.keystore.location

Pfad zur Keystore-Datei, die das Schlüsselpaar zur Validierung und Erzeugung von digitalen Signaturen enthält.

security.keystore.passwd

Passwort für den Zugriff auf den Keystore.

security.keystore.key.alias

Alias des Zertifikates oder privaten Schlüssels.

security.keystore.key.passwd

Passwort für den Zugriff auf den privaten Schlüssel.

security.sso.cookie.name

Name des Cookies, das für das domänenweite Single Sign-On verwendet wird.

security.sso.cookie.domain

Name der Domäne, in der das Single Sign-on Cookie gültig ist. Es darf nicht mit einem Punkt beginnen und muss den Regeln in RFC 6265 entsprechen.
Beispiele:

 example.org
 mysub.domain.com

TLS/SSL Server Trust

Stellen Sie beim Aufbau von Verbindungen zu HTTPS-Endpunkten durch serverseitige Java-Komponenten sicher, dass das TLS/SSL-Server-Zertifikat des angefragten Hosts von der Java Virtual Machine (JVM) akzeptiert und als vertrauenswürdig erachtet wird. Dies betrifft den smart.finder, wenn Sie im Manager mittels Job-Konfiguration Quellen indexieren, auf die über einen HTTPS-Endpunkt zugegriffen wird (z.B. OGC CSW-Katalog).

Mit der Konfigurationsoption security.ssl.trustAny wird gesteuert, unter welchen Bedingungen ein TLS-Server-Zertifikat akzeptiert wird:

security.ssl.trustAny=true

Es werden alle Zertifikate akzeptiert.
Einzige Bedingung ist, dass das Zertifikat zeitlich gültig ist. Das Zertifikat muss weder für den angefragten Host, noch von einer vertrauenswürdigen Stelle ausgestellt worden sein. Diese Einstellung sollte nur in Entwicklungsumgebungen aktiv sein.

security.ssl.trustAny=false

Auslieferungszustand
Es werden nur Zertifikate akzeptiert, die von der JVM als vertrauenswürdig erachtet werden.
Es wird dringend empfohlen, diese Einstellung beizubehalten. Dies gilt insbesondere für produktive Umgebungen. Sie müssen sicherstellen, dass Server-Zertifikate von HTTPS-Endpunkten, zu denen Verbindungen hergestellt werden, vertrauenswürdig sind. Andernfalls kommt es beim Aufbau einer Verbindung zu einem Fehler.

Vertrauenswürdigkeit von Serverzertifikaten

Damit ein Serverzertifikat von der JVM als vertrauenswürdig erachtet wird, müssen Sie entweder das konkrete Serverzertifikat oder dessen Stammzertifikat im Java Runtime Environment (JRE) installieren. Vertrauenswürdige Zertifikate bzw. Stammzertifikate werden im JRE standardmäßig in einem Java-Keystore unter [JRE_HOME]/lib/security/cacerts gespeichert. Je nach Betriebssystem oder Konfiguration der JVM ist es jedoch möglich, dass andere Quellen für vertrauenswürdige Zertifikate genutzt werden.

Im Folgenden wird beschrieben, welche Typen von Serverzertifikaten von HTTPS-Endpunkten üblicherweise verwendet werden und was bezüglich der Vertrauenswürdigkeit zu beachten ist.

Zertifikate mit Stammzertifikat, das in der JRE installiert ist

Produktive Web Sites, die Dienste per HTTPS zur Verfügung stellen, besitzen üblicherweise Serverzertifikate, deren Stammzertifikat von einer vertrauenswürdigen Certificate Authority (CA) ausgestellt wurde. Diese Stammzertifikate sind in der JRE bereits vorinstalliert und werden damit automatisch als vertrauenswürdig eingestuft.

Um die Verbindung mit einem Endpunkt zu erlauben, dessen Serverzertifikat ein bereits in der JRE installiertes Stammzertifikat besitzt, sind keine weiteren Schritte notwendig.

Zertifikate mit Stammzertifikat, das nicht im JRE installiert ist

Gelegentlich werden in Organisationen Serverzertifikate verwendet, die von einer eigenen, organisationsinternen CA ausgestellt wurden. Das zugehörige Stammzertifikat ist folglich nicht Teil der im JRE vorinstallierten Zertifikate. Verbindungen zu HTTPS-Endpunkten mit solchen Serverzertifikaten schlagen dann fehl, es sei denn, Sie fügen das Stammzertifikat durch unternehmensinterne Prozesse automatisch allen JRE-Installationen hinzu.

Um sicherzustellen, dass allen von dieser organisationsinternen CA ausgestellten Serverzertifikaten vertraut wird, fügen Sie das Stammzertifikat der CA dem Keystore [JRE_HOME]/lib/security/cacerts hinzu.

Selbstsignierte Zertifikate

Selbstsignierte Serverzertifikate, also Zertifikate, die sich selbst als Herausgeber referenzieren, werden häufig zu Testzwecken verwendet und sollten in Produktivsystemen nicht genutzt werden. Da ein selbstsigniertes Serverzertifikat nicht Teil der in der JRE bereits installierten Zertifikate ist, ist es nicht vertrauenswürdig.

Um HTTPS-Verbindungen mit einem Host zu erlauben, der ein selbstsigniertes Serverzertifikat verwendet, fügen Sie dieses Zertifikat dem Keystore [JRE_HOME]/lib/security/cacerts hinzu.

Typische Fehlermeldungen

Beim Aufbau serverseitiger HTTPS-Verbindungen kann es zu verschiedenen Fehlersituationen im Zusammenhang mit der Validierung von Serverzertifikaten kommen. In den folgenden Abschnitten werden typische Fehlermeldungen aufgeführt, die in der Log-Datei der serverseitigen Anwendung oder in den Browser-Oberflächen der Applikationen erscheinen können. Zusätzlich werden möglichen Ursachen beschrieben und Lösungen vorgeschlagen. Abhängig von der konkreten Infrastruktur, in der die betroffene Applikation betrieben wird, sind ggf. auch andere Ursachen und Lösungen in Betracht zu ziehen.

Typische Fehlermeldungen:

PKIX path building failed

Vollständige Fehlermeldung:

sun.security.validator.ValidatorException:
PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Diese Fehlermeldung ist ein Hinweis darauf, dass das vom Server präsentierte Zertifikat für die HTTPS-Verbindung von der JVM nicht als vertrauenswürdig eingestuft wird. Ggf. handelt es sich um ein selbst-signiertes Zertifikat, oder das Stammzertifikat ist nicht im JRE installiert.

Mögliche Lösungen:

  • Installieren des Stammzertifikats im JRE

  • Installieren des Serverzertifikats im JRE

  • Wenn der angefragte Server unter eigener Kontrolle ist: Bereitstellung eines neuen Serverzertifikats auf dem angefragten Server, das von einer vertrauenswürdigen CA ausgestellt wurde.

No name matching [requested.host.name] found

Vollständige Fehlermeldung:

javax.net.ssl.SSLHandshakeException:
java.security.cert.CertificateException: No name matching maps.example.com found

Diese Fehlermeldung zeigt an, dass der in der HTTPS-Anfrage genutzte Host-Name nicht zu dem Host-Namen passt, der im Serverzertifikat angegeben ist. Der Client (Browser, Java-Applikation) vergleicht dabei den in der Anfrage-URL verwendeten Host-Namen mit dem CN-Namen des Subject-Feldes im X509-Zertifikat des Servers, z.B.

https://maps.example.com/

mit

CN = www.example.com, O = Example LLC, L = Mountain Dew, ST = California, C = US.

Stimmen beide Namen nicht überein (Groß-/Kleinschreibung ist nicht relevant), wird der Verbindungsaufbau mit der oben genannten Fehlermeldung abgebrochen. Dabei ist es unerheblich, ob das Zertifikat als vertrauenswürdig eingestuft würde. Die Prüfung der Vertrauenswürdigkeit findet erst statt, wenn sichergestellt ist, dass die Host-Namen übereinstimmen.

Häufig kommt es zu diesem Problem, wenn Clients denselben Server mit unterschiedlichen Namen ansprechen können, weil mehrere DNS-Einträge vorhanden sind. Insbesondere wenn der Client sich in derselben Domäne wie der Server befindet, führt oft die uneinheitliche Nutzung von nicht-qualifizierten und vollqualifizierter Host-Namen in Anfrage-URLs bzw. Serverzertifikaten zu diesem Problem. Auch die Verwendung des speziellen Host-Namens localhost oder von IP-Adressen in URLs führt zu diesem Problem, wenn das Serverzertifikat auf den qualifizierten Rechnernamen ausgestellt wurde.

Mögliche Lösungen:

  • Verwendung des Host-Namen in Anfrage-URLs in der Form, wie er im Serverzertifikat angegeben wird.

  • Erstellen und Hinterlegen eines neuen Serverzertifikats für den vom Client gewünschten Host-Namen, wenn sich zum Beispiel herausstellt, dass die Verwendung eines nicht-vollqualifizierten Host-Namens (oder localhost oder IP-Adresse) nicht sinnvoll ist.

  • Erstellen und Hinterlegen eines neuen Serverzertifikats mit alternativen Host-Namen (Subject Alternative DNS Names), wenn sich zum Beispiel herausstellt, dass der Server unausweichlich unter unterschiedlichen Host-Namen erreichbar sein muss.

No subject alternative DNS name [requested.host.name] found

Vollständige Fehlermeldung:

javax.net.ssl.SSLHandshakeException:
java.security.cert.CertificateException: No subject alternative DNS name matching maps.example.com found

Diese Fehlermeldung ist ein Sonderfall der Fehlermeldung No name matching [requested.host.name] found dieser Liste. Einziger Unterschied ist, dass das Serverzertifikat ein zusätzliches Feld mit alternativen Host-Namen besitzt, jedoch der vom Client verwendete Host-Name weder dem Subject-CN des Serverzertifikats entspricht noch in dessen Liste alternativer Host-Namen (Subject Alternative DNS Names) angegeben ist.

Mögliche Lösungen: Die Lösungsvorschläge der vorherigen Fehlermeldung gelten auch hier.

Indexierbare Ressourcen

smart.finder kann eine Reihe unterschiedlicher Ressourcen indexieren und somit durchsuchbar machen. Dabei erkennt smart.finder automatisch, auf welche Weise eine Ressource indexiert werden muss. Es muss also kein Ressourcetyp o.ä. angegeben werden, damit eine Indexierung korrekt durchgeführt werden kann.

Der folgende Abschnitt gibt einen Überblick über die Ressourcetypen, die indexiert werden können. Des Weiteren wird beschrieben, wie die Inhalte indexiert werden.

Dateibasierte Ressourcen

Die in dieser Tabelle aufgelisteten Typen können sowohl im Dateisystem als auch über eine URL zugänglich sein. Das bedeutet, dass http://myhost.de/file.ppt zum gleichen Index-Ergebnis führt wie c:\file.ppt (unter der Annahme, dass file.ppt in beiden Fällen identisch ist).
Dateinamen­erweiterung Name Indexierte Inhalte

doc

Microsoft Word 97-2003 Document

Kompletter Inhalt

docx

Microsoft Word Document

Kompletter Inhalt

geotiff

GeoTiff Datei

Name
Raumausschnitt
spez. Metadaten

html/xhtml

Hypertext Markup Language

Kompletter Text

jpg, png, gif

Image Dateien

Pfad
Name der Datei

pdf

Adobe Acrobat Document

Kompletter Inhalt samt Metadaten

ppt

Microsoft PowerPoint 97-2003 Presentation

Kompletter Inhalt

pptx

Microsoft PowerPoint Presentation

Kompletter Inhalt

rtf

Rich Text Format

Kompletter Inhalt

shp

Shape Datei

Name
Raumausschnitt, falls PRJ Datei vorhanden
Anzahl Features
Attributnamen

txt

Plain Text

Kompletter Text

xls

Microsoft Excel 97-2003 Worksheet

Kompletter Inhalt

xlsx

Microsoft Excel Worksheet

Kompletter Inhalt

xml

XML

Kompletter Inhalt

Web-Dienste

Name Indexierte Inhalte Dezidierte Mapping-Datei

OGC Catalog Service for the Web 2.0.2, ISO Application profile

Ausgewählte Felder

jar:file:/ct-finder-api-2.4.1.jar!/de/conterra/finder/tika/xslt/iso19139.xslt

OGC Catalog Service for the Web 2.0.2, Capabilities

Ausgewählte Felder

jar:file:/ct-finder-api-2.4.1.jar!/de/conterra/finder/tika/xslt/csw.xslt

INSPIRE Discovery Service

Ausgewählte Felder

jar:file:/ct-finder-api-2.4.1.jar!/de/conterra/finder/tika/xslt/iso19139.xslt

INSPIRE Discovery Service, Capabilities

Ausgewählte Felder

jar:file:/ct-finder-api-2.4.1.jar!/de/conterra/finder/tika/xslt/csw.xslt

OGC Web Mapping Service 1.1.0 und 1.3.0 Capabilities

Ausgewählte Felder

jar:file:/ct-finder-api-2.4.1.jar!/de/conterra/finder/tika/xslt/wms.xslt

INSPIRE View Service Capabilities

Ausgewählte Felder

jar:file:/ct-finder-api-2.4.1.jar!/de/conterra/finder/tika/xslt/wms.xslt

ArcGIS Server REST Endpoint

Kompletter Inhalt

intern

Aktivieren Sie das Services Directory in den Einstellungen des ArcGIS Server für die Indexierung über einen ArcGIS Server REST Endpoint.