Alors que le nombre de sources de données offrant des flux de données en temps réel ne cesse d’augmenter, il est de plus en plus important que vos applications puissent exploiter et afficher immédiatement ces données d’événement. La latence est introduite en premier lieu par le stockage de ces données d’événement dans une couche d’entités d’une géodatabase d’entreprise de sorte que les clients puissent interroger périodiquement un service d’entités pour extraire les données à afficher. Or, elle se révèle problématique, tout particulièrement lorsque les flux de données sont importants.
Ce paradigme doit changer. La persistance des données doit être considérée comme une tâche d’archivage exécutée en parallèle dès que les données d’événement sont transmises en temps réel aux clients. Il est recommandé d’utiliser un service en mode continu, à savoir un type de service ArcGIS Server.
Présentation des services en mode continu
Un service en mode continu met l’accent sur la dissémination des données en temps réel à faible latence pour les flux de données client-serveur. Les clients qui se connectent à un service en mode continu commencent à recevoir des données dès qu'ils s'abonnent au service. Ils peuvent spécifier et reconfigurer les contraintes spatiales et attributaires sans devoir se désabonner du service puis s'y reconnecter.
Pour pouvoir exploiter les services en mode continu, vous devez installer GeoEvent Server dans votre SIG d’entreprise, après avoir obtenu la licence correspondante. Le contenu des services en mode continu peut être incorporé aux cartes Web ArcGIS Online et Portal for ArcGIS ainsi qu’à ArcGIS Pro, et affiché par l’intermédiaire de clients développés à l’aide de ArcGIS API for JavaScript.
Les services en mode continu exploitent la technologie WebSocket qui prend en charge les communications bidirectionnelles simultanées. Cela permet aux clients de spécifier les données qu’ils souhaitent recevoir sans avoir à se désabonner du service puis de s’y reconnecter. Les clients peuvent filtrer les données des services en mode continu en spécifiant des contraintes spatiales ou attributaires.
Lorsque vous vous connectez à un service en mode continu pour recevoir un flux de données temps réel, vous pouvez distinguer les deux besoins élémentaires suivants : la visualisation immédiate des événements et la conservation des données dans une base de données. En configurant la sortie GeoEvent Server pour la diffusion des données d’événement par un service en mode continu, vous pouvez stocker les données d’événement les plus récentes dans un data store relationnel ou un Spatiotemporal Big Data Store d’entreprise, mais ce n’est pas nécessaire pour visualiser les données.
L'illustration suivante compare le modèle traditionnel de réception, de traitement et d'utilisation des données d'entité avec le nouveau modèle de réception et de diffusion des données temps réel à l'aide des services en mode continu.
La partie supérieure de l’illustration indique qu’avant les services en mode continu, les données temps réel devaient d’abord être stockées dans une classe d’entités qui nécessitait une géodatabase d’entreprise. Pour afficher les données, les applications clientes devaient interroger périodiquement le service d’entités pour obtenir les nouvelles entités, ainsi que les entités mises à jour.
La partie inférieure de l'illustration indique comment les services en mode continu permettent la réception des données temps réel et leur transmission immédiate aux clients via une connexion WebSocket.
Pour plus d’informations sur l’utilisation des services en mode continu dans GeoEvent Server, reportez-vous au didacticiel consacré aux services en mode continu disponible dans la rubrique relative aux didacticiels GeoEvent Server.
Publication de services en mode continu
La création et la publication des services en mode continu dans GeoEvent Manager font partie intégrante du processus de configuration d’un connecteur en sortie Send Features to a Stream Service (Envoyer des entités à un service en mode continu).
Pour la configuration d’un connecteur en sortie Envoyer des entités à un service en mode continu, il est recommandé d’utiliser la connexion ArcGIS Server ou Portal for ArcGIS inscrite en tant que connexion par défaut dans GeoEvent Server.
Un connecteur en sortie Envoyer des entités à un service en mode continu configuré et exécuté dans le cadre d’une instance de GeoEvent Server doit être incorporé dans un service GeoEvent configuré et exécuté sur cette même instance de GeoEvent Server.
Services en mode continu dans le répertoire des services REST d'ArcGIS
Tout comme les autres services ArcGIS Server, les services en mode continu sont répertoriés dans le répertoire des services REST d’ArcGIS. Examinez les propriétés d’un service en mode continu, utilisez des contrôles pour transmettre des données d’événements et abonnez-vous pour recevoir des données d’événements d’un service en mode continu.
- Un clic sur Broadcast (Diffuser) permet d’ouvrir une page Web, à partir de laquelle vous pouvez indiquer une représentation JSON d’entités Esri d’une ou de plusieurs entités et envoyer les entités aux clients connectés à un service en mode continu.
- Un clic sur Subscribe (S’abonner) permet d’ouvrir une page Web, à partir de laquelle vous pouvez vous connecter à un service en mode continu et voir les entités transmises en continu. Si le flux de données est important, le formulaire de cette page peut rapidement devenir surchargé. Utilisez cette page pendant de courtes périodes uniquement pour confirmer que les clients s’abonnant à un service en mode continu reçoivent des données.
Pour plus d’informations sur les services en mode continu dans ArcGIS REST API, reportez-vous à la rubrique Services en mode continu.
Utiliser un service en mode continu
À partir de la page des propriétés du service en mode continu dans le répertoire des services ArcGIS REST, cliquez sur ArcGIS JavaScript pour générer une page HTML à la volée dans laquelle afficher les données transmises par un service en mode continu.
Cliquez avec le bouton droit sur ArcGIS JavaScript, puis cliquez sur View Source (Afficher la source) pour examiner le code JavaScript. Les développeurs peuvent utiliser et personnaliser ce code pour créer des applications Web en vue d'utiliser des services en mode continu.
Il est possible également d’utiliser les services en mode continu en les incorporant à une carte Web et dans ArcGIS Pro.
Pour plus d’informations sur l’utilisation des services en mode continu dans ArcGIS Pro, reportez-vous à la rubrique Couches en mode continu.
Filtrer un service en mode continu
Un service en mode continu permet d’appliquer des filtres par client. Chaque client peut demander qu'un filtre soit appliqué aux données avant que le service en mode continu ne les transmette. Ce filtre ne concerne pas les données transmises à d'autres clients. Vous pouvez spécifier un filtre pendant ou après l’établissement de la connexion.
Vous pouvez appliquer ces paramètres ainsi que d'autres lors de l'établissement de la connexion en ouvrant une connexion WebSocket.
Définir une référence spatiale pour le flux de données
Un service en mode continu possède une référence spatiale par défaut disponible sur la page de description du service dans ArcGIS Server Manager. Si le client souhaite recevoir les données dans une référence spatiale autre que celle par défaut, il doit le spécifier au moment de la connexion. Une fois définie, la référence spatiale ne peut plus être modifiée pendant toute la durée de la connexion. Il est nécessaire de créer une autre connexion WebSocket pour modifier la référence spatiale. Pour remplacer la référence spatiale par défaut, ajoutez à l’URL le mot-clé outSR et l’identifiant connu (WKID) de la référence spatiale souhaitée, sous la forme outSR=<WKID>. Ainsi, pour définir la référence spatiale par défaut sur WGS 1984 Web Mercator (sphère auxiliaire), qui porte le WKID 3857, ajoutez outSR=3857 à l’URL, notamment ws://HOSTNAME:6180/arcgis/services/Vehicles/StreamService/0/subscribe?outSR=3857.
Configurer le filtre
Le filtre d’un service en mode continu peut inclure un composant spatial, un composant de requête de type SQL et un composant outFields. Chacun d'eux pouvant être activé ou désactivé indépendamment des autres, vous pouvez les appliquer à tout moment à votre convenance (et même n'en appliquer aucun). Pour définir une partie du filtre, spécifiez-la et ignorez le reste. Les autres parties du filtre restent inchangées.
Filtre de géométrie
La partie du filtre relative à la géométrie est identique à la structure des objets géométrie JSON renvoyés par ArcGIS REST API. Pour préserver les performances du service en mode continu, seules les enveloppes sont acceptées comme type de géométrie.
Le filtre peut également inclure une relation spatiale identifiée par le mot-clé spatialRel. Il représente la relation spatiale appliquée à la géométrie en entrée lors de l'exécution de la requête. La seule relation spatiale prise en charge est la relation spatiale par défaut « intersects » (esriSpatialRelIntersects).
Le filtre de géométrie est censé figurer dans la même référence spatiale que la connexion. La référence spatiale peut uniquement être remplacée lors de l'établissement de la connexion. Si une référence spatiale différente est spécifiée dans la géométrie, l'enveloppe est projetée dans la référence spatiale de la connexion pour être utilisée lors du filtrage des entités du flux de données.
Filtre where
Le filtre where est une expression de type SQL qui filtre les entités du flux de données en vérifiant si leurs attributs correspondent à la clause where spécifiée. L’expression doit être une valeur de chaîne JSON placée entre guillemets simples. Parmi les opérations prises en charge, on compte les suivantes : AND, OR, NOT, =, !=, <, <=, >, >=, IS NULL, IS NOT NULL, IN et LIKE. Vous pouvez comparer un champ à une valeur littérale, par exemple ( 'field1 > 1' ), ou comparer deux champs de type similaire, par exemple ( 'field1 > field2' ). Vous pouvez ajouter des parenthèses pour indiquer explicitement l'élément prioritaire.
- Comparaison numérique - Exemple de comparaison d’un champ (Altitude) à une valeur numérique : "Altitude < 1000".
- Comparaison de champs - Exemple de comparaison de deux champs : "speed > maxSpeed".
- Comparaison de chaînes - Vous pouvez également comparer des chaînes. Les comparaisons respectent la casse, et les valeurs littérales doivent être placées entre guillemets simples, par exemple comme suit : "Departure_Airport='KZSE'".
- Instructions LIKE - Vous pouvez comparer des chaînes avec l'instruction LIKE pour utiliser des caractères génériques. Le signe de pourcentage remplace un nombre quelconque de caractères, tandis que le trait de soulignement remplace un seul caractère. L’exemple suivant renvoie les noms dont les deuxième et troisième caractères sont "am", comme Samantha et James : "name LIKE '_am%'".
- Instructions IN - L'instruction IN permet de spécifier des listes de valeurs littérales. Si le champ correspond à une valeur de la liste, l’entité est transmise dans le flux.
- Voici l’exemple d’une liste de chaînes : "name IN ('Bob','Jane','Henry')".
- Voici un exemple d’instruction IN utilisant une liste de valeurs numériques : "alertCode IN (404,500,505)".
- Vous pouvez également utiliser un champ booléen à la place d’une expression booléenne. Par exemple, si vos entités contiennent un champ de type booléen nommé "active", vous pouvez rédiger une clause where qui transmet toute entité dont le champ "active" est défini sir true (vrai), par exemple "active".
Filtre des champs en sortie
Les champs d’un flux de données peuvent être filtrés individuellement à l’aide du filtre des champs en sortie identifié par le mot-clé outFields. Vous devez définir les champs souhaités sous la forme d’une liste de noms de champs séparés par des virgules.
Vous avez un commentaire à formuler concernant cette rubrique ?