Skip To Content

Pratiques de codage concernant les extensions

Dans cette rubrique
Remarque :

Intercepteurs d'objet serveur (SOI) constituent une nouvelle fonctionnalité de la version 10.3.1. Les informations de cette rubrique concernant les SIO s'appliquent à la version 10.3.1.

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. Vous pouvez commencer par créer une extension à l'aide d'un assistant de plug-in Eclipse. L'assistant garantit que votre extension implémente les interfaces requises et qu'elle peut répondre aux appels de service Web REST ou SOAP à l'aide des classes de SOESupport.

Pour ce faire, reportez-vous aux instructions relatives aux codages d'extension disponibles dans le SDK ArcObjects.

Classes et interfaces ArcObjects appropriées

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 com.esri.arcgis.geometry et com.esri.arcgis.geodatabase, est toujours autorisée dans les extensions.

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 gérer les requêtes de l'API SOAP, notamment les requêtes émises par les clients ArcGIS for Desktop (tels qu'ArcMap)
  • 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 généralement au format http://gisserver.domain.com:6080/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 d'ArcGIS Server. 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.