Alors que le nombre de sources de données offrant des flux de données 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 traditionnellement introduite en stockant ces données d'événement dans la classe d'entités d'une géodatabase d'entreprise pour que les clients puissent interroger périodiquement un service d'entités afin d'extraire les données à afficher. Mais cela s'avère problématique lorsque les flux de données sont importants.
Ce paradigme doit changer. La persistance des données doit être gérée en tant que tâche d'archivage exécutée en parallèle dès que les données d'événement sont transmises aux clients en temps réel. Pour résoudre ce problème, Esri propose un nouveau type de service ArcGIS Server : le service en mode continu.
Qu'est-ce-qu'un service en mode continu ?
Un service en mode continu est un type de service ArcGIS Server qui met l’accent sur la dissémination des données 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 installerGeoEvent Server dans votre SIG d'entreprise, après avoir obtenu la licence correspondante. Dans la version initiale, le contenu des services en mode continu peut être incorporé aux cartes Web ArcGIS Online et Portal for ArcGIS, et affiché par l'intermédiaire de clients développés à l'aide d'ArcGIS API for JavaScript. Les prochaines versions prendront en charge une plus grande variété d'abonnements client.
Les services en mode continu exploitent la technologie WebSocket qui prend en charge les communications bidirectionnelles simultanées. Ils permettent aux clients de spécifier les données à recevoir en leur évitant de 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 en vue de diffuser des données d'événement via un service en mode continu, vous pouvez stocker les données d'événement les plus récentes dans un stockage des données relationnelles ou un stockage de Big Data spatio-temporelles, mais vous n'êtes pas obligé de le faire pour la visualisation des 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.
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. Les applications client souhaitant afficher les données 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.
Reportez-vous aux explications sur les services en mode continu disponibles dans les didacticiels GeoEvent Server pour en savoir plus sur l’utilisation de services en mode continu dans GeoEvent Server.
Publication d’un service en mode continu
Les services en mode continu sont créés et publiés dans GeoEvent Manager dans le cadre du processus pour configurer un connecteur en sortie Send Features to a Stream Service (Envoyer des entités à un service en mode continu).
Lors de la configuration d’un connecteur en sortie Send Features to a Stream Service (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.
Si vous disposez de GeoEvent Server installé et concédé sous licence sur une seconde machine de serveur, une autre possibilité consiste à inscrire une connexion de stockage des données sur cette seconde machine dans GeoEvent Manager et spécifier que le service en mode continu soit publié sur cette seconde machine. Ceci vous permet de configurer une sortie s’exécutant sur une machine pour diffuser ses enregistrements d’entité via un service en mode continu s’exécutant sur une machine différente.
Un connecteur en sortie Send Features to a Stream Service (Envoyer des entités à un service en mode continu) configuré et s’exécutant dans le cadre d’une instance de GeoEvent Server doit être incorporé dans un service GeoEvent configuré et s’exécutant 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. Les utilisateurs peuvent cliquer pour consulter les propriétés des services en mode continu. En bas de la page des services en mode continu, dans le répertoire des services REST ArcGIS, se trouvent des liens permettant de diffuser des données d'événement et de s'abonner à un service en mode continu pour les recevoir.
Cliquez sur Broadcast (Diffuser) pour ouvrir une page Web à partir de laquelle entrer 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.
Cliquez sur Subscribe (S'abonner) pour ouvrir une page Web à partir de laquelle 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 doivent recevoir des données.
Pour plus d’informations sur les services en mode continu de ArcGIS REST API, reportez-vous à la rubrique Services en mode continu.
Utilisation d'un service en mode continu
Dans l'illustration située au-dessus de la page REST des services en mode continu, remarquez le lien en haut qui permet d'afficher le contenu d'un service en mode continu dans une carte ArCGIS JavaScript. Cette option est généralement disponible pour les services de carte.
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.
Si vous cliquez sur ArcGIS JavaScript avec le bouton droit de la souris puis cliquez sur Afficher la source, vous pouvez vérifier 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.
Vous pouvez également utiliser les services en mode continu en les incorporant à une carte web.
Reportez-vous à la rubrique Couches en mode continu pour plus d’informations sur l’utilisation des services en mode continu dans ArcGIS Pro.
Filtrage d'un service en mode continu
Le 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éfinition d'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 faut le spécifier lors 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. Vous devez créer une connexion WebSocket pour modifier la référence spatiale. Pour remplacer la référence spatiale par défaut, vous devez ajouter à l'URL le mot-clé outSR et l'identifiant connu (WKID) de la référence spatiale souhaitée, sous la forme outSR=<WKID>. Par exemple, pour définir la référence spatiale par défaut sur WGS 1984 Web Mercator (sphère auxiliaire), avec le WKID 3857, ajoutez outSR=3857 à l'URL : ws://HOSTNAME:6180/arcgis/services/Vehicles/StreamService/0/subscribe?outSR=3857
Configuration du 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, il suffit de la spécifier et d'ignorer 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ée par l'API REST d'ArcGIS. 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 ( 'champ1 > 1' ), ou comparer deux champs de type similaire, par exemple ( 'champ1 > champ2' ). 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 : "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 des personnes 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 transmettra toute entité dont le champ "active" est vrai, par exemple "active".
Filtre des champs à supprimer
Les champs d'un flux de données peuvent être filtrés individuellement à l'aide du filtre des champs à supprimer identifié par le mot-clé outFields. Vous devez spécifier les champs sous la forme d'une liste de noms de champs séparés par des virgules.
Vous avez un commentaire à formuler concernant cette rubrique ?