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
Vor dem Start des Tomcat-Prozesses müssen folgende Java-Optionen gesetzt werden, die von unterschiedlichen Komponenten des Systems benötigt werden:
Die Laufzeitvariablen können als Umgebungsvariablen oder als Java-Optionen in der Tomcat-Konfiguration gesetzt werden. Beispiel für Linux-Umgebung via Shell
|
Installation der Server-Webapp
Installieren Sie zunächst den Suchdienst smartfinder-search.war
.
-
Optional können Sie den Namen der WAR-Dateien. Der Name erscheint in der URL zur Anwendung.
-
Stellen Sie sicher, dass der Tomcat-Dienst gestartet ist.
-
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 unterhttp://<yourserver>:8080/manager/html
. -
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 |
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
-
Melden Sie sich als
admin
-Benutzer in map.apps Manager an. -
Öffnen Sie den Reiter Bundles.
-
Klicken Sie auf die +-Schaltfläche oberhalb der Liste der installierten Bundles.
-
Laden Sie die Datei
[RELEASE-ORDNER]/ct-smartfinder-js-2.5.1.jar
hoch. Diese enthält alle Bundles für smart.finder. -
Falls Sie die map.apps Smart Search Bundles nutzen wollen, laden Sie zusätzlich die Datei
[RELEASE-ORDNER]/ct-smartsearch-js-2.5.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
-
Melden Sie sich als
admin
-Benutzer in map.apps Manager an. -
Öffnen Sie den Reiter Apps.
-
Klicken Sie auf die +-Schaltfläche oberhalb der Liste der installierten Apps. Es öffnet sich der App-Assistent.
-
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.
-
Die Apps liegen als ZIP-Dateien im Ordner
[RELEASE-ORDNER]/resources/apps
. Laden Sie die gewünschte App hoch. -
Fahren Sie mit den nächsten Schritten im Assistenten fort, bis der Assistent abgeschlossen ist.
-
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:
-
Öffnen Sie die map.apps Konfigurationsdatei
application.properties
. Diese liegt üblicherweise im Ordner[USER_HOME]/.mapapps
-
Suchen Sie den Eintrag
manager.config.viewbundles
. Falls er bereits existiert, ergänzen Sie am Ende den Wertsf_jobadmin
. Falls er noch nicht existiert, fügen Sie den Eintrag mit dem folgenden Wert ein:Beispiel fürmanager.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 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.com subdomain.example.net
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://example.com/file.ppt zum gleichen Index-Ergebnis führt wie c:\file.ppt (unter der Annahme, dass file.ppt in beiden Fällen identisch ist).
|
Dateinamenerweiterung | Name | Indexierte Inhalte |
---|---|---|
|
Microsoft Word 97-2003 Document |
Kompletter Inhalt |
|
Microsoft Word Document |
Kompletter Inhalt |
|
GeoTiff Datei |
Name |
|
Hypertext Markup Language |
Kompletter Text |
|
Image Dateien |
Pfad |
|
Adobe Acrobat Document |
Kompletter Inhalt samt Metadaten |
|
Microsoft PowerPoint 97-2003 Presentation |
Kompletter Inhalt |
|
Microsoft PowerPoint Presentation |
Kompletter Inhalt |
|
Rich Text Format |
Kompletter Inhalt |
|
Shape Datei |
Name |
|
Plain Text |
Kompletter Text |
|
Microsoft Excel 97-2003 Worksheet |
Kompletter Inhalt |
|
Microsoft Excel Worksheet |
Kompletter Inhalt |
|
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 |
|
OGC Catalog Service for the Web 2.0.2, Capabilities |
Ausgewählte Felder |
|
INSPIRE Discovery Service |
Ausgewählte Felder |
|
INSPIRE Discovery Service, Capabilities |
Ausgewählte Felder |
|
OGC Web Mapping Service 1.1.0 und 1.3.0 Capabilities |
Ausgewählte Felder |
|
INSPIRE View Service Capabilities |
Ausgewählte Felder |
|
ArcGIS Server REST Endpoint |
Kompletter Inhalt |
|
Aktivieren Sie das Services Directory in den Einstellungen des ArcGIS Server für die Indexierung über einen ArcGIS Server REST Endpoint.