Programmiermethoden für Erweiterungen
In diesem Thema
- Geeignete ArcObjects-Klassen und -Schnittstellen
- Überlegungen zu Serverobjekt-Interceptoren
- Erstellen einer SOE-Datei
Hinweis:
Serverobjekt-Interceptoren (SOIs) sind eine neue Funktion in 10.3.1. Die Informationen in diesem Thema zu SOIs gelten nur für 10.3.1.
Zur Erweiterung eines Karten- oder Image-Services (SOE oder SOI) wird normalerweise ein Code programmiert, der einige der erforderlichen Schnittstellen implementiert und die Geschäftslogik ausführt. Sie können damit beginnen, eine Erweiterung mithilfe eines Eclipse-Plug-In-Assistenten zu erstellen. Der Assistent stellt sicher, dass die Erweiterung die erforderlichen Schnittstellen implementiert und auf REST- oder SOAP-Web-Service-Aufrufe mithilfe von SOESupport reagieren kann.
Ausführliche Anweisungen zur Codierung von Erweiterungen finden Sie im ArcObjects SDK.
Geeignete ArcObjects-Klassen und -Schnittstellen
Erweiterungen werden nur für Karten- und Image-Services unterstützt. Da Karten- und Image-Services eine Service-Definitionsdatei verwenden und nicht direkt auf ein Kartendokument (MXD) zugreifen, sind beim Programmieren von Erweiterungen bestimmte Classes zu vermeiden und andere wiederum vorzuziehen.
Vermeiden Sie die Nutzung von ArcObjects aus der Carto-Bibliothek, die eigens für den Einsatz mit MXDs vorgesehen sind. Zu diesen zählen IMap, ILayer und Elemente, die sich auf Datenrahmen und Seitenlayouts beziehen. Verwenden Sie stattdessen ArcObjects, die für den Einsatz mit Karten-Services konzipiert wurden, z. B. MapServer, MapLayerInfos und MapDescription. Verwenden Sie die Oberfläche IMapServerDataAccess, um auf Datasets zuzugreifen, die den Layern in Ihrer Karte zugrunde liegen.
Bibliotheken, die nicht direkt mit dem Kartendokument verbunden sind, z. B. com.esri.arcgis.geometry und com.esri.arcgis.geodatabase, können immer in Erweiterungen verwendet werden.
Überlegungen zu Serverobjekt-Interceptoren
Beim Erstellen von Serverobjekt-Interceptoren (SOIs) müssen alle eingehenden Anforderungstypen auch dann behandelt werden, wenn der SOI nur zur Verbesserung einer oder mehrerer der vielen Operationen dienen soll, die mit Karten- und Image-Services verfügbar sind. In diesem Abschnitt werden die zu behandelnden Schnittstellen und die Methoden erläutert, deren Verfügbarkeit davon abhängt, ob Sie sicherheitsbezogene oder nicht sicherheitsbezogene Funktionen implementieren.
Abfangen von REST-, SOAP- und OGC-Service-Anforderungen
Karten- und Image-Services unterstützen drei verschiedene Anforderungstypen:
- REST-API-Anforderungen
- SOAP-API-Anforderungen
- OGC-Anforderungen
Die folgenden Schnittstellen müssen implementiert werden, damit ein SOI diese Anforderungen abfangen kann:
- IRESTRequestHandler – zum Behandeln von REST-API-Anforderungen
- IRequestHandler2 – zum Behandeln von SOAP-API-Anforderungen einschließlich Anforderungen durch ArcGIS for Desktop-Clients (z. B. ArcMap)
- IWebRequestHandler – zum Behandeln von OGC-Anforderungen
Alle oben genannten Schnittstellen müssen auch dann behandelt werden, wenn eine bestimmte Service-Konfiguration keine OGC-Anforderungen unterstützt. Je nach Geschäftslogik, die Sie implementieren, können Sie zwei allgemeine Ansätze nutzen.
Wenn Sie einen SOI implementieren, der Sicherheitsfunktionen ausführt, empfiehlt es sich, zunächst alle oben aufgeführten Schnittstellen zu implementieren und alle Anforderungen zu blockieren. Wenn Sie Ihren benutzerdefinierten Code implementieren, können Sie den Zugriff logisch über die Schnittstellen oben gewähren. Wenn Sie eingehende Anforderung nicht zuerst blockieren und dann den Zugriff wie gewünscht erlauben, gehen Sie ungewollt ein höheres Sicherheitsrisiko ein.
Wenn Sie keine Sicherheitsfunktionen implementieren, können Sie die drei Schnittstellen implementieren, indem Sie alle Anforderungen über die zugrunde liegende Standardimplementierung übergeben, um normale Funktionen zu erlauben. Fügen Sie anschließend Geschäftslogik zu einer oder mehreren Operationen hinzu, die Sie verbessern möchten.
Wenn ein Service mit einem SOI konfiguriert wird, werden alle Service-Anforderungen vom Server-Framework an den SOI weitergeleitet. Der SOI ist dafür zuständig, die Anforderungen zu filtern, die Anforderung an die tatsächlichen Karten- oder Image-Service-Objekte (falls zutreffend) zu delegieren und anschließend optional die Antworten zu verarbeiten, bevor sie an den Client zurückgesendet werden.
Implementieren der Zugriffssteuerung auf Layer-Ebene
Wenn Sie die Zugriffssteuerung auf Layer-Ebene über einen SOI implementieren, müssen Sie außerdem den REST-Handler von ArcGIS-Server konfigurieren, um das Caching aller im Service enthaltenen Layer-Ressourcen zu deaktivieren. Dadurch können Sie Operationen abfangen und Layer herausfiltern, die nicht zulässig sind. Dies kann deaktiviert werden, indem Sie die Eigenschaft disableCaching des Service im ArcGIS Server Administrator Directory auf true festlegen.
- Öffnen Sie das ArcGIS Server Administrator Directory, und melden Sie sich an. Die URL hat in der Regel das Format http://gisserver.domain.com:6080/arcgis/admin.
- Klicken Sie auf Services und auf den Namen des gewünschten Service. Wenn er nicht in der Liste angezeigt wird, befindet er sich möglicherweise in einem Ordner in diesem Verzeichnis.
- Klicken Sie auf edit.
- Fügen Sie im Abschnitt properties des Service-JSON die Eigenschaft disableCaching hinzu, und legen Sie deren Wert auf true fest, z. B.:
"properties": { ... "disableCaching": "true", ... }, - Klicken Sie auf Änderungen speichern.
Erstellen einer SOE-Datei
Erweiterungen (SOEs oder SOIs) sind in einer SOE-Datei gekapselt. Die SOE-Datei enthält alle Informationen, die zum Registrieren der Erweiterung auf ArcGIS for Server erforderlich sind. Sie erstellen die .soe Datei mit einem in Eclipse erstellten Assistenten. Die SOE-Datei kann auch mit von Esri bereitgestellten Befehlszeilendienstprogrammen erstellt werden, die manuell ausgeführt oder in automatisierte Build-Skripte integriert werden können.