Contenus : Comportements, Scripting
- Formation
Cette section détaille les Contenus orientés Comportements et Scripting : comment créer, versionner, publier et appliquer des scripts et règles qui pilotent l’UI et le jumeau numérique côté Beholder.
Le Scripting est un moyen puissant, simple et particulièrement efficace pour modifier le comportement du Beholder.
Changer le comportement des équipements en réponse aux données récupérées depuis le réseau, modifier l'interface utilisateur pour simplifier les actions de vos utilisateurs, accéder à des API ou réaliser des traitements ? Le Scripting est une réponse adéquate à tout type d'évolution du Beholder sans demander à vos utilisateurs de mettre à jours leurs outils.
Dans cet article nous allons aborder :
Dans cet article
L’ensemble des actions de ce tutoriel se font à partir de la catégorie « Métier > Contenus » de votre Backend Immersive.
Création d’un Workspace
Les « Workspaces » représentent un ensemble de « Controllers » qui vont agir sur l'ergonomie et la représentation des données.
Les utilisateurs peuvent avoir accès à un ou plusieurs Workspaces, cependant au lancement du Beholder, un seul Workspace sera actif pendant la session.
Pour créer un nouveau worspace, cliquer sur « Créer un nouveau Workspace ». Le panneau de création du Worspace s’ouvre sur la droite de l’interface, rentrez son nom, sa description (facultatif) et validez la création.
Une fois le Workspace créé, il apparait maintenant dans la liste des Workspaces de votre l’environnement. Il suffit de cliquer sur un des Workspace pour accéder à sa fiche détaillée.
Les différentes sous parties de la fiche d’un Workspace permettent :
- L’édition des propriétés du Workspace
- L’accès à la liste des controllers associés au Workspace, avec la possibilité d’ajouter ou supprimer un lien
- L’édition des droits de sécurité du Workspace pour autoriser son accès à un groupe d’utilisateurs.
- La suppression du Workspace
Afin d’associer un Controller au Workspace, cliquer sur « Editer la liste des controllers du Workspace » et cliquer sur le toggle button de lien sur la ligne du Controller.
Seul les Controllers liés au Workspace chargé dans le Beholder seront actif, les autres ne seront pas utilisés. Dans l’exemple suivant, seul le Controller « Lampadaire » sera actif.
Création d’un Controller
Un Controller représente un script qui va être exécuté par le Beholder. Il existe différents types de controllers qui seront interprétés différemment, avec chacun un objectif précis.
Actuellement les différents types de Controller sont :
- Les controllers de paramétrage
- Utilisation : Configuration des paramètres du beholder au lancement.
- Prefix : Infos.
- Format : JSON
- Règle d’importation : non utilisée
- Les controllers de scripting d’équipements
- Utilisation : Scripting d’un ou plusieurs équipements.
- Prefix : aucun
- Format : Javascript
- Règle d’importation : Nom d’une famille d’équipement, ou $(Nom d’un handle)
- Les controllers de scripting applicatifs
- Utilisation : Scripting du beholder dans sa globalité sans lien avec un équipement.
- Prefix : App.
- Format : Javascript
- Règle d’importation : non utilisée
- Les controllers de localisation
- Utilisation : Ajout de clefs de traduction au système de localisation.
- Prefix : Translation.
- Format : Texte
- Règle d’importation : la langue associée (exemple fr-FR)
Pour créer un nouveau Controller, cliquer sur « Créer un nouveau Controller ». Le panneau de création du Controller s’ouvre sur la droite de l’interface, rentrez son nom, une description (facultative), la règle d’import et validez la création.
Le nom du controller est important, car selon son prefix, il sera interprété différemment par le beholder.
La règle d’importation dépend du type de controller, se référer aux différents tutoriaux décrivant chaque type de controller pour savoir quelles règles appliquer en fonction de chaque cas.
Une fois le Controller créé, il apparait maintenant dans la liste des Controllers de votre l’environnement. Il suffit de cliquer sur un des Controller pour accéder à sa fiche détaillée.
Les différentes sous parties de la fiche d’un Controller permettent :
- L’édition des propriétés du Controller
- L’accès à la liste des Workspaces utilisant ce Controller, avec la possibilité d’ajouter ou supprimer un lien
- L’édition du script associé au controller
- La suppression du Controller
Un controller sans script, n’a aucune utilité, il faut donc lui créer une nouvelle version de script et la publier pour l’activer.
Un controller peut avoir plusieurs versions de scripts enregistrées (dans un but d’historisation pour de modifications temporaires), mais c’est seulement la version publiée qui est récupérée et utilisée par le Beholder.
Pour créer la première version d’un script, cliquer sur « Edition du script » puis « Créer » et rentrez un numéro de version. Il n’est pas nécessaire de rentrer une nouvelle règle d’importation, la règle d’importation générale au Controller est utilisée si elle n’est pas surchargée dans la version de son script.
Dans le cas où le Controller n’a aucune version active, ou si la version éditée n’est pas la version courante, il suffit de cliquer sur le bouton « Publier cette version » pour l’affecter en tant que version active.
Le contenu du script peut être éditer dans le bloc d’édition, et sauvegarder en utilisant le bouton « Sauvegarder ». Au prochain lancement du Beholder, les changements appliqués au script seront effectifs si la version est publiée et que le Controller est lié au Workspace que vous lancez.
Les controllers de paramétrage
Un controller de type paramétrage sert à configurer les paramètres du Beholder à son lancement. Les paramètres peuvent par exemple permettre de configurer la carte à charger, le scope à charger, l’adresse du serveur données (Hub).
Afin d’être interprété comme un controller de paramètrage par le Beholder, le nom du controller doit être préfixé par « Infos. », par exemple « Infos.Mon Usine »
Le contenu du script d’un controller de paramètre doit être au format JSON, associant une clef de paramétrage et sa valeur.
La règle d’importation n’étant pas interprété, il n’est pas nécessaire de remplir cette information.
Exemple d’un controller de paramétrage qui configure le beholder pour charger la carte portant le nom « Usine », son scope associé et qui modifie le titre de l’application.
{
"DefaultMapName" : "Usine",
"Supervision.ScopeName" : "Usine",
"Supervision.TitleName" : "My Factory by Graphicstream",
}
Les paramètres les plus couramment utilisés dans les Controllers, sont les suivants :
- DefaultMapName : Le nom de la carte à charger ?
- DefaultLevelName : Le nom du niveau à mettre en avant au lancement.
- Supervision.ScopeName : Le ou les noms de scopes à charger. Pour charger plusieurs scopes, il faut les séparer par une virgule « , ».
- Supervision.TitleName : Le titre du Beholder affiché dans la barre de titre.
- Supervision.HubAddress : L’url de connexion au Hub.
- Supervision.UpdatesPeriod : La fréquence d’update des appels au Hub. (par défaut 2 sec)
Pour plus de paramètres, se référer à la liste complète des paramètres de configuration du Beholder : << lien vers la doc >>
Les controllers de scripting d’équipement (Javascript)
Un controller de scripting d’équipement correspond à un script Javascript qui est exécuté pour tous les équipements qu’il contrôle à chaque fois qu’un évènement se produit. Ils sont très utiles car ils permettent de personnaliser la façon dont un équipement réagit à un changement de donnée et sa représentation dans l’interface ou la carte 3D.
Tous les controllers sans prefix sont interprétés comme des scripts d’équipements.
Pour pouvoir associer un script de comportement à un équipement, il existe plusieurs règles qui peuvent être configurer dans la règle d’importation du script.
Associer un script à une famille d’équipement :
La façon la plus simple d’associer un script à tous les équipements d’une famille, est de simplement mettre le nom de la famille dans la règle d’import.
Dans l’exemple suivant, on crée un script pour customiser le comportement de tous les équipements appartenant à la famille « Lampadaire ».
Associer un script à plusieurs familles d’équipement :
Dans le cas où on souhaite que le script s’applique à plusieurs familles d’équipements, il est possible de séparer les différents noms de famille par le caractère « | ».
Dans l’exemple suivant, on crée un script pour personnaliser le comportement de tous les équipements appartenant à la famille « Lampadaire » ou « Capteur de température ».
Associer un script à l’ensemble des équipements :
Dans certain cas, on souhaite qu’un script s’exécute pour tous les équipements, il suffit de rentrer comme règle d’importation : « .* »
Associer un script aux équipements possédant une variable donnée :
Très utile pour de la création de scripts générique, il est possible qu’un script s’exécute seulement pour les équipements qui possèdent une variable. Pour cela, il suffit d’entourer le nom d’une variable par « $( ) ».
Dans l’exemple suivant, le script de documentation ne s’exécutera que pour les équipements qui possèdent une variable dont le nom est « Documentation Url ». Ainsi, le script pourrait rajouter un bouton pour ouvrir la documentation, et utiliser la valeur de la variable « Documentation Url » pour ouvrir la bonne documentation.
Pour plus d’information sur la rédaction du contenu d’un script de comportement, referez-vous aux tutoriaux « Scripting », pour le moment voici un exemple de script qui affiche un message lorsqu’on sélectionne un équipement.
function OnSelectionChanged(equipement, isSelected)
{
if(isSelected)
Immersive.App.ShowPopup(«Message», « Hello World ! ») ;
}