L’extension d’un service de carte ou d’imagerie (SOE ou SOI) implique habituellement la rédaction du code qui met en œuvre des interfaces requises et exécute votre logique métier. Si vous travaillez dans Java, vous pouvez commencer par créer une extension à l’aide d’un assistant de plug-in Eclipse. Si vous travaillez dans .NET, vous démarrerez dans Visual Studio avec un projet de modèle. Avec l’assistant et les modèles, vous avez la garantie que votre extension implémente les interfaces requises et qu’elle peut répondre à des appels de service Web REST ou SOAP à l’aide des classes de SOESupport.
Vous trouverez des instructions détaillées concernant le codage des extensions dans la documentation du SDK que vous utilisez. Il est également possible de créer une extension en langage C++ sous Windows ; un échantillon est inclus dans le SDK ArcObjects .NET pour C++.
Classes et interfaces appropriées
Les classes et les interfaces dont l’utilisation est autorisée lors du développement des SOE et des SOI dépendent du SDK que vous utilisez.
SDK ArcObjects (pour .NET et pour Java)
Les extensions ne sont prises en charge que pour les services d’imagerie et de carte (sans mise en cache) dynamiques. Les services d'imagerie et de carte utilisent un fichier de définition de service et n'accèdent pas directement à un document ArcMap (MXD). Par conséquent, vous devez éviter certaines classes, et en préférer d'autres, lors de la rédaction d'extensions.
Les objets ArcObjects de la bibliothèque Carto étant conçus spécialement pour être utilisés avec des fichiers MXD, il est conseillé de les éviter. Il s'agit notamment d'IMap, ILayer et des éléments liés aux blocs de données et aux mises en page. Utilisez plutôt des objets ArcObjects conçus pour les services de cartes, tels que MapServer, MapLayerInfos et MapDescription. Utilisez l'interface IMapServerDataAccess pour accéder aux jeux de données sous-jacents à chaque couche de votre carte.
L’utilisation des bibliothèques qui ne sont pas directement associées à la carte, telles que ESRI.ArcGIS.Geometry et ESRI.ArcGIS.Geodatabase pour .NET ou com.esri.arcgis.geometry et com.esri.arcgis.geodatabase pour Java, est toujours autorisée dans les extensions.
ArcGIS Enterprise SDK
Vous pouvez utiliser ArcGIS Enterprise SDK pour développer des extensions d’objet serveur (SOE) afin d’étendre les services de carte et développer des intercepteurs d’objet serveur (SOI) pour personnaliser les fonctionnalités des services de carte et d’imagerie (y compris des extensions de services tels que les services d’entités et les services conformes à OGC).
ArcGIS Enterprise SDK est fourni avec un ensemble de base de bibliothèques pour faciliter le développement d’extensions personnalisées. Les classes et les interfaces disponibles dans ce SDK ont toutes été conçues pour être utilisées dans des extensions, et leur utilisation est autorisée.
Points à prendre en compte concernant les intercepteurs d’objet serveur
Lorsque vous créez des intercepteurs d’objet serveur (SOI), vous devez gérer tous les types de requêtes entrantes même si votre SOI n’est destiné qu’à améliorer une ou quelques-unes des opérations accessibles avec les services d’imagerie et de carte. Cette section décrit les interfaces que vous devez gérer, ainsi que les méthodes qui sont à votre disposition selon que vous implémentez des fonctionnalités ayant trait à la sécurité ou non.
Interception de requêtes de services REST, SOAP et de l’OGC
Les services d’imagerie et de carte prennent en charge trois différents types de requêtes :
- requêtes API REST
- requêtes API SOAP
- Requêtes de l’OGC
Pour qu’un SOI intercepte ces requêtes, vous devez implémenter les interfaces suivantes :
- IRESTRequestHandler : pour gérer les requêtes de l’API REST
- IRequestHandler2 (pour les SDK ArcObjects) ou IRequestHandler (pour ArcGIS Enterprise SDK) - Pour gérer les requêtes d’API SOAP, notamment les requêtes émises par ArcMap et ArcGIS Pro
- IWebRequestHandler - Pour gérer les requêtes de l’OGC
Même si la configuration d'un service en particulier ne prend pas en charge les requêtes de l'OGC, vous devez gérer toutes les interfaces ci-dessus. Selon la logique métier que vous implémentez, vous pouvez adopter deux méthodes générales.
Remarque :
Si un service de carte ou d’imagerie contient des tuiles en cache, les requêtes à destination de ces tuiles ne peuvent pas être interceptées.
Si vous implémentez un SOI dont les fonctions sont sécuritaires, il est recommandé de commencer par implémenter toutes les interfaces ci-dessus et par bloquer toutes les requêtes. Lorsque vous implémentez votre code personnalisé, vous pouvez autoriser logiquement l’accès via les interfaces ci-dessus. Si vous ne commencez pas par bloquer les requêtes entrantes et autorisez ensuite l’accès selon les besoins, le risque de présenter accidentellement une faille de sécurité est accru.
Si vous n’implémentez pas de fonctions de sécurité, vous pouvez implémenter les trois interfaces en transmettant toutes les requêtes à l’implémentation standard sous-jacente afin d’autoriser les fonctions normales. Ajoutez ensuite la logique métier supplémentaire aux opérations que vous voulez optimiser.
Lorsqu’un service est configuré avec un SOI, la structure du serveur achemine toutes les requêtes du service vers le SOI. Le SOI est chargé de filtrer les requêtes, de déléguer la requête aux objets de service d’imagerie ou de carte (le cas échéant), puis de traiter les réponses avant de les renvoyer au client.
Implémentation du contrôle d'accès au niveau des couches
Si vous implémentez le contrôle d’accès au niveau des couches via un SOI, vous devez également configurer le gestionnaire REST de ArcGIS Server pour désactiver la mise en cache des ressources de toutes les couches incluses dans le service. Cela vous permet d’intercepter les opérations et de filtrer les couches qui ne sont pas autorisées. Vous pouvez désactiver cette fonction en définissant la propriété disableCaching du service sur true dans le répertoire d’administrateur d’ArcGIS Server.
- Ouvrez le répertoire d’administrateur ArcGIS Server et connectez-vous. L’URL est souvent formatée https://gisserver.domain.com:6443/arcgis/admin.
- Cliquez sur services, puis sur le nom du service souhaité. S’il n’apparaît pas dans la liste, recherchez-le dans un dossier de ce répertoire.
- Cliquez sur Modifier.
- Dans la section properties du fichier JSON du service, ajoutez la propriété disableCaching et définissez sa valeur sur true ; par exemple :
"properties": { ... "disableCaching": "true", ... }, - Cliquez sur Enregistrer les mises à jour.
Création d’un fichier .soe
Les extensions (SOE ou SOI) sont encapsulées dans un fichier .soe. Le fichier .soe contient toutes les informations nécessaires pour inscrire l’extension auprès d’ArcGIS Server. Si vous utilisez .NET, le fichier .soe est créé lors de la génération du projet à partir du modèle. Si vous utilisez Java, la création du fichier .soe s’effectue à l’aide d’un assistant intégré dans Eclipse. Le fichier .soe peut également être créé à l’aide des utilitaires de ligne de commande fournis par Esri, qui peuvent s’exécuter manuellement ou être intégrés à des scripts de génération automatisés.
Pour les extensions développées à l’aide de ArcGIS Enterprise SDK, le suffixe _ent est ajouté au nom de fichier .soe. Ainsi, une extension nommée SimpleRESTSOE adopte le nom de fichier en sortie SimpleRESTSOE_ent.soe.
Vous avez un commentaire à formuler concernant cette rubrique ?