Scripting : Introduction

• Formation

Le scripting est la brique qui permet d’adapter le Beholder aux besoins métier sans redéployer l’application. Les scripts, écrits en JavaScript, sont stockés côté serveur, versionnés puis tirés par les players (Beholder) pour exécution locale. Ils peuvent modifier des comportements applicatifs, ajuster l’interface, piloter l’apparence du jumeau numérique et orchestrer des processus. Résultat : faire évoluer rapidement une réponse fonctionnelle, en autonomie, avec un langage accessible.

Parcours de création d’un jumeau numérique

Un jumeau numérique Immersive se construit en quatre étapes complémentaires : modélisation géospatiale, constitution du catalogue d’équipements, liaison entre géométrie et données puis scripting pour ajouter la logique métier. L’objectif est d’aller d’un référentiel 3D correctement géoréférencé jusqu’à une application opérationnelle qui réagit aux données en temps réel, sans redéploiement côté player.

Les sections suivantes décrivent chaque étape, les livrables attendus et les points d’attention qui assurent un jumeau robuste, traçable et maintenable.

1) Modélisation & métadonnées géographiques

Construisez la carte 3D et le cadre spatial dans lequel le jumeau vit : sites, bâtiments, étages, zones, repères et coordonnées. Plus la modélisation est riche (géométrie + sémantique), plus les usages ultérieurs (localisation, navigation, filtrage, analyses) seront simples et précis.

• À faire : créer/assembler les modèles 2D/3D, définir la topologie (site → bâtiment → étage → zone), renseigner les systèmes de coordonnées.
• Livrable : référentiel spatial cohérent prêt à recevoir les équipements.

2) Création / import des équipements

Recensez tous les objets supervisables (capteurs, systèmes, caméras, véhicules, etc.) à partir des sources métier du client (GMAO, SIG, IoT, exports Excel, API…). Normalisez, nettoyez et transformez ces données au format Immersive pour qu’elles deviennent des entités exploitables.

• À faire : mapper les champs (types, identifiants, propriétés, variables, états), contrôler la qualité, enrichir si nécessaire.
• Livrable : catalogue d’équipements Immersive prêt à être chargé (types + instances + variables).

3) Liaison objets ↔ équipements

Associez les objets visuels (maillages 3D, symboles 2D) issus de la modélisation aux équipements référencés. Cette étape crée la traçabilité : un clic sur un objet ouvre la bonne fiche, un changement de valeur met à jour le bon rendu, et les requêtes croisées (par zone, type, criticité) deviennent triviales.

• À faire : établir les liens stables (IDs, règles d’appartenance, patrons), valider l’alignement spatial.
• Livrable : graphe de liens robuste entre géométrie et données, testable dans le Beholder.

4) Scripting & logique métier

Ajoutez l’intelligence locale via des scripts JavaScript exécutés par le Beholder : règles d’alerte, styles/animations conditionnels, parcours opérateurs, widgets et automatisations. Le scripting permet de faire évoluer le comportement sans redéploiement : il suffit de publier les scripts côté serveur.

• À faire : écrire des scripts par périmètre, écouter les handles, appliquer les réactions UI/jumeau, journaliser.
• Livrable : bibliothèque de scripts versionnée, documentée et testée.

Rôle et but du scripting

• Réagir aux données reçues via le Hub (états, mesures, événements) et déclencher des actions locales.
• Customiser l’UI : simplifier des parcours, ajouter des éléments d’assistance, signaler des priorités.
• Styliser le jumeau : changer l’apparence d’équipements, afficher des badges/étiquettes, appliquer des effets visuels.
• Automatiser des processus : séquences d’actions, gestion de modes (jour/nuit), règles d’alerte, procédures opérateur.

Toutes les opérations décrites dans les tutoriaux sur le scripting s’effectuent dans le Backend Immersive, catégorie « Métier > Contenus ». C’est là que vous structurez votre périmètre d’exécution (Workspaces), créez vos scripts (Controllers), gérez les versions et publiez.

Notions fondamentales

• Handle : chemin de données permettant un dialogue avec le Hub. Les scripts « écoutent » les changements de valeur et réagissent.
• Workspace : représente un ensemble de Controllers appliqués pendant une session Beholder. Un seul Workspace est actif au lancement. Le Workspace représente l'espace de travail métier qui va surcharger le comportement par défaut du Beholder pour créer une réponse métier adaptée au besoin d'un client.
• Controller : conteneur d’un script (ou d’un contenu paramétrique) avec son type, sa règle d’import et ses versions.
  • Controllers de paramétrage (préfixe Infos.) — format JSON. Pilotent la configuration au lancement (ex. carte par défaut, scope, titre, adresse Hub).
  • Controllers de scripting d’équipements (sans préfixe) — format JavaScript. Logique attachée à un ou plusieurs équipements.
  • Controllers de scripting applicatifs (préfixe App.) — format JavaScript. Logique globale, indépendante d’un équipement.
  • Controllers de localisation (préfixe Translation.) — format texte. Ajout de clés de traduction.
• Règle d’import : détermine à quels équipements s’applique un script d’équipements. Exemples :
  • Nom de famille : cible tous les équipements d’une famille.Par exemple l'ensemble des Ascenseurs.
  • Plusieurs familles : en séparant chaque famille par |.
  • Tous les équipements : motif .*.
  • Présence d’une variable : motif $(NomDeVariable) (ne s’applique qu’aux équipements possédant cette variable).

Cycle de vie côté Backend

Les tâches classiques d'un utilisateur d'Immersive souhaitant créer des scripts pour adapter le Beholder à un besoin métier sont les suivantes :

1. Créer un Workspace et définir ses propriétés (droits d’accès, liste des Controllers liés).
2. Créer un Controller : spécifier un nom (attention au préfixe qui détermine le type), la description, et la règle d’import si applicable.
3. Éditer le script (ou le JSON, selon le type du controlleur) et créer une version.
4. Publier une version : seule la version publiée est chargée par le Beholder. Un controlleur peut, en effet, versionner ses scripts mais ne peut en publier qu'une à la fois.
5. Lier le Controller au Workspace : seuls les Controllers liés au Workspace actif sont exécutés. Un controlleur peut être associé à plusieurs Workspaces différents.
6. Chargement côté player : au démarrage (ou selon la stratégie de rechargement), le Beholder récupère le Workspace, ses Controlleurs associés et la version publiée pour chacun d'eux qu'il exécute localement.

Bonnes pratiques éditoriales

Il est important, pour simplifier la maintenance de votre projet et aider ceux qui auront à travailler sur les workspaces, controlleurs ou scripts que vous avez créé de suivre des bonnes pratiques :

• Nommer clairement : noms explicites pour controllers, workspaces et familles.
• Règles d’import précises : cibler clairement (familles, variables) pour éviter les effets de bord.
• Versions courtes et fréquentes : publier par incréments et documenter les changements.
• Isolation : séparer la logique « globale » (App.) de la logique « équipement » (sans préfixe).
• Réversibilité : toute modification UI/visuelle doit pouvoir être annulée simplement.
• Performance : privilégier des réactions événementielles et un périmètre restreint (handles ciblés).

Usages courants

Le scripting permet de surcharger le fonctionnement du Beholder pour offrir plus de possibilités et de fonctionnalités à vos utilisateurs. Le scripting va pouvoir agir sur :

• État d’un équipement : mettre en avant un équipement en anomalie, afficher un message opérateur.
• Customisation UI 2D/3D : enrichir la carte (cartouches, bulles), listes d’équipements, badges de criticité.
• Query & filtrage : focaliser la vue sur un sous-ensemble pertinent d’équipements.
• Géolocalisation & flotte : surligner la ressource la plus proche, guider vers un point, exploiter des équipements « virtuels ».
• Historique & heatmap : activer des couches historiques ou de densité pour l’analyse.

Prochaines étapes du tutoriel

• Création d’un Workspace.
• Création d’un Controller et gestion de ses versions.
• Controllers de paramétrage (Infos.).
• Scripting d’équipements (règles d’import, ciblage, cas d’usage).
• Scripting applicatif (App.).
• Localisation (Translation.).
• Focus thématiques : État d’un équipement, Customisation Widget2D/3D, Query, Customisation 3D, Géolocalisation, Autres actions, Inspector, Customisation de l’IHM, Flotte/GeoTracking/GeoMove/NavMeshMove, Rapports, Heatmap, Historique d’itinéraires.