Skip To Content

Pratiques de codage concernant les extensions

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 d’une extension 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. 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 au document ArcMap, 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

Les extensions ne sont prises en charge que pour les services de carte.

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 de l’API SOAP, notamment les requêtes émises par les clients ArcGIS for Desktop (tels que 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.

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 fonctionnalités 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 fonctionnalités normales. Ensuite, ajoutez la logique métier supplémentaire à une ou plusieurs 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 réels (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 d'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 administrateur d'ArcGIS Server.

  1. Ouvrez le répertoire administrateur d'ArcGIS Server et connectez-vous. L’URL est souvent au format https://gisserver.domain.com:6443/arcgis/admin.
  2. 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.
  3. Cliquez sur Modifier.
  4. 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",
      ...
     },
  5. 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 votre extension auprès de ArcGIS Server. Si vous utilisez .NET, le fichier .soe est créé lors de la génération de votre 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.

Le suffixe _ent est ajouté au nom de fichier .soe des extensions développées avec ArcGIS Enterprise SDK. Ainsi, une extension nommée SimpleRESTSOE adopte le nom de fichier en sortie SimpleRESTSOE_ent.soe.