Prérequis

• Un accès “Administrator” à une Constellation (Management API & Developper access)
• Le SDK Constellation installé

Nous vous conseillons de suivre le guide de démarrage ici avant de démarrer.

Créez le package dans Visual Studio

• Lancez Visual Studio
• Créez un nouveau projet de type “Constellation Package Console” (dans la catégorie Constellation) :

• Démarrez le package en mode debug en cliquant sur le bouton “Start” ou en pressant la touche “F5” :

• Au démarrage, votre package affichera une sorte de ”Hello World” :

Vous constaterez que :

• La méthode “OnStart” est la méthode invoquée au démarrage de votre package
• PackageHost.WriteInfo est une méthode pour écrire des logs de type “info”
• PackageHost.IsRunning = true (votre package est bien en cours)
• PackageHost.IsConnected = false (votre package n’est pas connecté à Constellation, car nous l’avons lancé en local)

Fonctionnement de base

Un package est une application !

Il faut impérativement appeler la méthode “PackageHost.Start” au démarrage de l’application, c’est à dire dans la méthode “Main” autrement, ce n’est pas un package Constellation mais une simple application !

Lorsque vous appelez la méthode “PackageHost.Start” vous devez impérativement transférer les arguments (args) et indiquer la classe de votre package qui est dans notre exemple “Program”.

static void Main(string[] args)
{
    PackageHost.Start<Program>(args);
}

La classe d’un package doit être une classe qui implémente l’interface “IPackage”. Cette interface définie trois méthodes :

• OnStart qui sera invoqué lorsque le package a démarré
• OnPreShutdown : invoqué lorsque le package va s’arrêter (à ce stade votre package est toujours connecté à Constellation, vous pouvez encore pusher des StateObjects, envoyer des messages, écrire des logs sur le hub, etc..)
• OnShutdown : invoqué après le OnPreShutdown et après avoir fermé les connexions.

Pour vous éviter de devoir implémenter ces trois méthodes, votre classe peut hériter de la classe “PackageBase”. Cette classe abstraite implémente l’interface IPackage dans des méthodes virtuelles vides.

Libre à vous d’implémenter les méthodes que vous souhaitez !

Dans le template de projet créé ci-dessus, la classe “Program” hérite de “PackageBase” et redéfinie la méthode “OnStart” pour écrire un message de type “info” (PackageHost.WriteInfo) lorsque le package a démarré.

Ecrire des logs

Pour écrire des logs depuis un package Constellation vous disposez des méthodes :

• PackageHost.WriteDebug
• PackageHost.WriteInfo
• PackageHost.WriteWarn
• PackageHost.WriteError

Chacune de ces méthodes écrivent un message qui peut être formaté avec des arguments à la manière d’un “string.Format” :

PackageHost.WriteInfo("Je suis le package nommé {0} version {1}", PackageHost.PackageName, PackageHost.PackageVersion);

Attention : bien respecter les index dans le format de votre message sous peine d’avoir une erreur.

Note : la méthode WriteDebug écrit seulement dans la console (mode debug local). Les logs de type “Debug” ne sont jamais envoyés dans la Constellation.

Accéder aux settings

Chaque package peut définir des paramètres de configuration définis au niveau du serveur Constellation. Cela vous permet de changer ces paramètres directement depuis la Constellation qui se chargera de redescendre ces paramètres sur vos packages.

Il y a deux types de settings :

• Les “Setting Value” : très simple il s’agit d’un couple clé/value à l’instant des <appSettings> d’une application .NET
• Les “Setting Content”  : au lieu de définir la valeur d’un paramètre dans un attribut XML, on peut la définir dans un élément XML enfant permettant d’avoir des settings qui renferme du XML ou JSON

Voici par exemple des “SettingValues”  déclarés dans notre configuration :

<setting key="MyBoolSetting" value="true" />      
<setting key="MyStringSetting" value="This is a string" />
<setting key="MyIntSetting" value="123" />

Ces trois settings définissent la valeur dans l’attribut “value” (= SettingValue).

Pour récupérer la valeur du paramètre “MyStringSetting”  dans votre code, utilisez la méthode “GetSettingValue” :

PackageHost.WriteInfo("My String = {0}", PackageHost.GetSettingValue("MyStringSetting"));

La méthode “GetSettingValue” renvoie la valeur d’un setting de type “string” mais vous pouvez également caster la valeur depuis cette méthode en utilisant sa forme générique :

int myIntSetting = PackageHost.GetSettingValue<int>("MyIntSetting");
bool myBoolSetting = PackageHost.GetSettingValue<bool>("MyBoolSetting");

Si par contre vous avez un modèle de configuration plus compliqué qu’une série de clé/valeur vous pouvez utiliser les “Setting Contents” pour définir du XML ou JSON comme valeur de setting.

Par exemple la configuration de votre package peut définir deux autres settings, contenant du XML ou JSON de cette façon :

<setting key="MyXmlDocument">
  <content>
    <note date="09-02-2016">
      <to>Tove</to>
      <from>Jani</from>
      <heading>Reminder</heading>
      <body>Don't forget me this weekend!</body>
    </note>
  </content>
</setting>

<setting key="MyJsonObject">
  <content>
    <![CDATA[
    {
      "Number": 123,
      "String" : "This is a test (local)",
      "Boolean": true
    }
    ]]>
  </content>
</setting>

Plusieurs méthodes pour récupérer ces settings :

• GetSettingValue : vous pouvez toujours récupérer le contenu brute de votre setting sous forme d’un string
• GetSettingAsJsonObject : dé-sérialise le contenu JSON de votre setting et vous retourne un objet dynamique
• GetSettingAsJsonObject<T> : dé-sérialise le contenu JSON de votre setting et le convertie dans un objet de votre type (T)
• GetSettingAsXmlDocument : dé-sérialise le contenu XML de votre setting et vous retourne un XmlDocument
• GetSettingAsConfigurationSection<TConfigurationSection> : dé-sérialise le contenu XML de votre setting sous forme d’un ConfigurationSection .NET

Par exemple, pour manipuler le setting XML on pourrait écrire :

var xml = PackageHost.GetSettingAsXmlDocument("MyXmlDocument");
PackageHost.WriteInfo("My XmlDocument Attribute = {0} , first node value = {1}", xml.ChildNodes[0].Attributes["date"].Value, xml.ChildNodes[0].FirstChild.InnerText);

Autre exemple avec le setting JSON :

dynamic json = PackageHost.GetSettingAsJsonObject("MyJsonObject");
PackageHost.WriteInfo("My JsonObject String={0}, Int={1}, Boolean={2}", json.String, json.Number, json.Boolean);

Les settings d’un package sont déclarés au niveau du serveur dans la déclaration du package et/ou dans le fichier App.config.

Tous les settings doivent être déclarés dans le manifeste du package (fichier PackageInfo.xml).

Retrouvez plus d’information sur les settings dans cet article.

Publier des StateObjects

Pour publier (Push) un StateObject dans Constellation vous devez invoquer la méthode “PackageHost.PushStateObject” en précisant obligatoirement le nom du StateObject et sa valeur.

Par exemple, vous pouvez publié n’importe quel type de base :

PackageHost.PushStateObject("MyString", "OK");
PackageHost.PushStateObject("MyNumber", 123);
PackageHost.PushStateObject("MyDecimal", 123.12);
PackageHost.PushStateObject("MyBoolean", true);

Pouvez également publié des objets anonymes :

PackageHost.PushStateObject("AnonymousObject", new { String = "test", Number = 123 });

Ou encore avec des types plus complexes :

PackageHost.PushStateObject<MyCustomObject>("MyObject",  new MyCustomObject() { String = "test", Number = 123 });

Vous avez également la possibilité de définir des paramètres optionnels comme les métadonnées de votre StateObject ou sa durée de vie.

Par exemple, le StateObject “ShortLife” a une durée de vie de 20 secondes après sa publication. Au delà il sera marqué comme expiré.

PackageHost.PushStateObject("ShortLife", "Expire in 20 secs !!!", lifetime: 20);

Ici, on publie un StateObject “Salon” en lui associé les metadatas “Id” et “Zone”.

PackageHost.PushStateObject("Salon", monObjetZoneSalon, metadatas: new Dictionary<string, object> { { "Id", 42 }, { "Zone", "Salon" } });

Sur les objets personnalisés il est recommande de décorer les classes de l’attribut [StateObject] si vous avez possibilité de modifier le code de la classe. Autrement, sur votre classe IPackage, ajoutez l’attribut [StateObjectKnownTypes] en définissant tous les types de StateObjects que vous serez amener à publier. Cela permet de décrire ces types dans la Constellation pour l’auto-description (utilisez entre autre par les générateurs de code).

Pour plus d’information sur les StateObjects dans l’API .NET cliquez ici.

Tester son package dans sa Constellation

Pour tester nous allons créer un package qui push à intervalle régulier un StateObject.

Le code de notre Package sera :

public class Program : PackageBase
{
    static void Main(string[] args)
    {
        PackageHost.Start<Program>(args);
    }

    public override void OnStart()
    {
        PackageHost.WriteInfo("Package starting - IsRunning: {0} - IsConnected: {1}", PackageHost.IsRunning, PackageHost.IsConnected);
        PackageHost.WriteInfo("Je suis le package nommé {0} version {1}", PackageHost.PackageName, PackageHost.PackageVersion);

        while (PackageHost.IsRunning)
        {
            PackageHost.WriteInfo("Je push un long !");
            PackageHost.PushStateObject("DemoLong", DateTime.Now.Ticks);

            Thread.Sleep(PackageHost.GetSettingValue<int>("Interval"));
        }
    }
}

Notre application console démarre bien le package au démarrage (Main) où le package est notre classe Program qui hérite de PackageBase (donc c’est un IPackage).

Au démarrage on écrit deux logs de type information qui indique notamment le nom du package, sa version, si il est démarré (IsRunning) et si il est connecté (IsConnected).

Ensuite on crée une boucle qui tournera tant que le package est démarré. A chaque itération on écrit un log, publie un StateObject avant de mettre le thread en pause avant la prochaine itération.

Le temps de pause est un setting de type “Int” que l’on a nommé “Interval”.

L’utilisateur pourra le configurer dans la configuration du package sur le serveur, mais pour être sûr d’avoir une valeur par défaut nous allons déclarer ce setting ainsi que sa valeur par default dans son manifest.

Editez le fichier PackageInfo.xml pour ajouter :

<Setting name="Interval" type="Int32" defaultValue="5000" description="Interval en millisecondes" />

Ainsi même si le setting n’est pas déclaré sur le serveur ni dans le App.config local,  cette valeur sera par défaut égale à 5 secondes.

Vous pouvez démarrer le projet en mode debug (“F5” ou bouton “Start”) mais bien entendu il ne sera pas connecté à Constellation.

Pour débugger dans Constellation, vous trouverez une icone dans la toolbar (en en pressant Ctrl+Alt+F8) :

Vous pouvez également cliquez droit sur votre projet et dans le menu Constellation sélectionnez “Debug On Constellation” :

Si vous n’avez pas encore configuré la Constellation utilisée pour le débogage, vous devriez voir une alerte vous invitant à configurer vos accès :

Cette fois ci, votre package tourne bien en étant connecté à votre Constellation :

Lancez maintenant votre Console Constellation, vous verrez en temps réel les logs de votre package.

Sur le StateObject Explorer, vous verrez également le StateObject “DemoLong” publié par le package “MonPremierPackage”.

Notez que la sentinelle qui héberge le package est une sentinelle virtuelle nommée “Developer”.

Vous pouvez cliquer sur “View” pour voir toutes les informations à propos de ce StateObject.

Pour finir, cliquez sur “Subscribe” pour vous abonner aux mises à jour.

Publier son package dans Constellation

Nous voulons maintenant publier ce package et le déployer sur une des sentinelles de notre Constellation.

Toujours dans la toolbar “Constellation”, cliquez sur “Publish Constellation package” :

Ou depuis le menu contextuel de votre projet, sélectionnez “Publish Constellation package” :

Vous pouvez soit le publier en local puis l’uploader manuellement via la Console par exemple, soit le publier directement dans votre Constellation.

Pour cela, sélectionnez “Upload on Constellation Server”.

Sélectionnez ensuite l’adresse de votre Constellation et cliquez sur “Publish”.

Un message vous informera de la réussite de la publication. Dans le panneau “Ouput” de Visual Studio vous retrouvez également le détail de la publication :

Depuis la Console, sur la page “Package Repository” vous pourrez apercevoir votre package fraichement publié :

Pour le déployer, vous devez éditer la configuration de votre Constellation pour ajouter le package à une (ou plusieurs) sentinelle. Vous pouvez également redéfinir le setting “Interval” que nous exploitations dans notre package (bien que nous avons défini une valeur par défaut).

<package name="MonPremierPackage" enable="true">
    <settings>
        <setting key="Interval" value="2000" />
  </settings>
</package>

Vous pouvez éditer la configuration du serveur Constellation directement depuis Visual Studio en cloquant sur “Edit Constellation Server configuration” (depuis la toolbar ou via le menu contextuel).

La configuration sera automatiquement téléchargée du serveur et ouverte dans Visual Studio :

L’avantage est de pouvoir profiter de la validation du schéma XML et de l’IntelliSense de Visual Studio :

Dès que vous enregistrerez votre configuration, Visual Studio détectera les modifications et vous proposera d’uploader et de recharger la nouvelle configuration sur votre serveur Constellation :

Vous pouvez aussi éditer la configuration de votre Constellation depuis la Console. Après avoir ajouter votre package, cliquez sur “Save & Deploy” (pour informer les sentinelles des nouveaux packages) :

Vous pourrez alors voir dans les logs que le package est automatiquement téléchargé et déployé sur sa sentinelle et commence à pusher des StateObject toutes les 2 secondes comme nous l’avons indiqué dans sa configuration :

Sur la page “Packages” vous pouvez maintenant contrôler votre package, l’arrêter, le redémarrer ou le recharger (= déploiement d’une nouvelle version).

Next steps

• Les bases des packages .NET
• Les Settings : paramètres de configuration de vos packages
• Publier des StateObjects
• Exposer vos méthodes dans Constellation grâce aux MessageCallbacks
• Envoyer des messages & Invoquer des méthodes
• Consommer des StateObjects
• Accéder au hub de contrôle depuis un package C# avec le ControlManager
• Créer des Packages UI en Winform ou WPF

The post Créez votre premier package Constellation en C# appeared first on Constellation.

Il existe actuellement deux librairies Constellation JavaScript :

1. Constellation for Javascript
2. Constellation for AngularJS

La première est basée sur jQuery, la deuxième est une surcouche de la 1ère encapsulée dans un module AngularJS.

Vous retrouverez ces deux librairies depuis le gestionnaire de package Nuget intégré à Visual Studio :

Chacune de ces deux librairies propose deux types de client :

1. Consumer
2. Controller

Le client “Consumer” permet de se connecter à Constellation en tant que “consommateur” pour pouvoir interroger des StateObjects et envoyer/recevoir des messages.

Le client “Controller” permet lui de se connecter à Constellation en tant que « contrôleur » pour récupérer par exemple en temps réel les logs produits par vos packages, arrêter/démarrer les packages, surveiller la consommation de ressources de chacun d’entre eux, etc.

Dans ce guide nous allons utiliser le client « Consumer » afficher en temps réel le StateObject produit par le package HWMonitor représentant la consommation de votre CPU dans une page Web.

Pour cela vous devez avoir déployé le package “HWMonitor” sur au moins une de vos sentinelles (Windows).

Etape 1 : ajouter la librairie Constellation

En utilisant le CDN

Les librairies JavaScripts sont accessibles sur : http://cdn.myconstellation.io/js/ (en HTTP ou HTTPS).

De ce fait, vous pouvez créer une simple pages HTML et ajoutez dans l’entête les balises suivantes :

<script type="text/javascript" src="https://code.jquery.com/jquery-2.2.4.min.js"></script>
<script type="text/javascript" src="https://ajax.aspnetcdn.com/ajax/signalr/jquery.signalr-2.2.2.min.js"></script>
<script type="text/javascript" src="https://cdn.myconstellation.io/js/Constellation-1.8.2.min.js"></script>

Si vous souhaitez connecter votre page à Constellation en utilisant le framework AngularJS :

<script type="text/javascript" src="https://code.jquery.com/jquery-2.2.4.min.js"></script>
<script type="text/javascript" src="https://ajax.aspnetcdn.com/ajax/signalr/jquery.signalr-2.2.2.min.js"></script>
<script type="text/javascript" src="https://cdn.myconstellation.io/js/Constellation-1.8.2.min.js"></script>
<script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/angularjs/1.5.7/angular.min.js"></script>
<script type="text/javascript" src="https://cdn.myconstellation.io/js/ngConstellation-1.8.2.min.js"></script>

Par Nuget en utilisant Visual Studio

Créez une application Web vide dans Visual Studio et ouvrez le gestionnaire de package NuGet.

En sélectionnant la source “Constellation”, installez le package Nuget “Constellation.Javascript” :

Une fois installée vous obtiendrez dans le dossier “Scripts” de votre projet Web les librairies jQuery, SignalR et Constellation :

Créez ensuite une page Web (HTML ou ASPX) et dans l’entête de votre code HTML référencez les scripts (à adapter en fonction des n° de version des librairies contenues dans les packages Nuget) :

<script type="text/javascript" src="Scripts/jquery-2.2.4.min.js"></script>
<script type="text/javascript" src="Scripts/jquery.signalR-2.2.2.min.js"></script>
<script type="text/javascript" src="Scripts/Constellation-1.8.2.js"></script>

Etape 2 : Initialiser le client

Tout d’abord il faut déterminer la clé d’accès qui sera utilisée par votre page. Ici, depuis la Console Constellation, nous créons un credential “DemoWeb” avec la clé d’accès “123456789” :

Dans notre page HTML, créons un client “Consumer” en spécifiant l’URI de notre Constellation, la clé d’accès utilisée pour se connecter et le “friendly name” de votre client :

var constellation = $.signalR.createConstellationConsumer("http://localhost:8088", "123456789", "Test API JS");

Etape 3 : Etablir la connexion à Constellation

Ajoutons un handler sur le changement d’état de la connection pour afficher le message “Je suis connecté” dans la console de votre navigateur :

constellation.connection.stateChanged(function (change) {
    if (change.newState === $.signalR.connectionState.connected) {
        console.log("Je suis connecté");
    }
});

Pour finir lançons la connexion en invoquant la méthode Start :

constellation.connection.start();

Testons la page dans Chrome par exemple :

Etape 4 : Afficher le contenu d’un StateObject en temps réel

Dans notre cas nous voulons afficher en temps réel la consommation CPU de notre sentinelle.

Ce StateObject se nomme “/intelcpu/0/load/0” et est produit par le package “HWMonitor” que vous aurez pris le soin de déployer sur une de vos sentinelles (ici ma sentinelle se nomme “PO-SWARIN”) :

On peut donc enregistrer un “StateObjectLink” avec la méthode “registerStateObjectLink” en demandant un filtre sur la sentinelle nommée “MON-PC”, le package “HWMonitor” et le nom “/intelcpu/load/0” (le dernier argument de cette méthode correspond au type du StateObject, ici ”*” indique qu’il n’y a pas de filtre sur le type) et en indiquant la fonction à invoquer à chaque mise à jour du et des StateObjects liés, ici mettre à jour un <span> de la page.

Vous devez impérativement faire cet enregistrement lorsque vous êtes connecté, c’est à dire lorsque le handler “stateChanged” est invoqué avec l’état “Connected”.

Le code final sera donc :

constellation.connection.stateChanged(function (change) {
    if (change.newState === $.signalR.connectionState.connected) {
        console.log("Je suis connecté");
        constellation.client.registerStateObjectLink("MON-PC", "HWMonitor", "/intelcpu/0/load/0", "*", function (so) {
            console.log(so);
            $("#cpu").text(so.Value.Value);
        });
    }
});

Dès que le StateObject est réceptionné par notre page nous affectons la propriété “Value” de la valeur du StateObject comme contenu du span “cpu” de la page. De ce fait, ajoutons un “span” nommé “cpu” dans le corps de notre page :

<body>
    <span id="cpu"></span> %
</body>

Ainsi vous aurez en temps réel votre CPU dans une page HTML grâce à l’exploitation du StateObject ici produit par le package HWMonitor :

Vous remarquerez que dans le handler ci-dessus nous loguons également l’objet “stateobject” réceptionné par notre page.

Cet objet contient les différentes propriétés du StateObject : la sentinelle et le package qui ont produit ce StateObject, le nom du StateObject, son type, sa durée de vue (ici “lifetime=0” donc n’expire jamais), la date de mise à jour du StateObject, ses métadonnées et surtout sa valeur (propriété “Value”).

Ici la valeur de ce StateObject produit par le package “HWMonitor” est un objet complexe (entouré en vert) qui contient différentes propriétés :

Pour la suite je vous recommande vivement l’utilisation du framework AngularJS permettant de développer des pages plus facilement.

Next step

• Consommer Constellation avec l’API Javascript
• Consommer Constellation avec Angular JS
• Contrôler votre Constellation en Javascript
• Créer une application mobile multi-plateforme avec Cordova et l’API Javascript
• Créer une application mobile multi-plateforme avec Ionic et Angular JS
• Créer une application pour une montre Samsung Gear avec Tizen et AngularJS

The post Connectez vos pages Web à Constellation appeared first on Constellation.

Découvrons dans cet article comment créer et déployer votre premier package Constellation en Python.

Prérequis

Tout d’abord, que vous soyez sur Windows ou Linux, il vous faudra un interpréteur Python 2 ou Python 3 et une ou deux libraires indispensables pour Constellation.

Notez que ces prérequis sont automatiquement installés sur Linux avec le Web Platform Installer.

Installer Python sur Windows

Téléchargez Python pour Windows (en version 2.x ou 3.x) puis lancez l’installation en choisissant une installation pour tous les utilisateurs :

Sélectionnez le composant “PIP” ( le gestionnaire de package Python) et ajoutez “Python.exe” dans les “Paths” Windows :

Une fois l’installation terminée, lancez une invite de commande (cmd.exe) et assurez-vous que la commande “python” fonctionne :

Toujours dans une invite de commande Windows, installez via PIP les librairies “pyzmq” (et “enum34” si vous êtes en Python 2.x) grâce aux commandes suivantes :

pip install pyzmq
pip install enum34

Si vous êtes sur Python 3.x, vous n’avez pas besoin du module “enum34”, seulement “pyzmq”.

Et voilà, votre environnement Windows est prêt !

Installer Python sur Linux

Sur un système Debian ou similaire (Raspbian, Ubuntu, etc …), vous n’avez qu’à installer (et enregistrer dans votre Constellation) une sentinelle Constellation.

Le Web Platform Installer vous proposera d’installer tous les prérequis nécessaires à savoir Python et les librairies “pyZmq” et “enum34” (si Python 2.x) via PIP.

Autrement, pour installer manuellement ces prérequis, vous pouvez utiliser les mêmes commandes que sur Windows :

sudo easy_install pip
sudo pip install pyzmq
sudo pip install enum34

Encore une fois, la libraire “enum34” est seulement requise sur Python 2.x.

Enfin si vous utilisez un Raspberry Pi, vous pouvez également consulter cet article en particulier.

Et voilà, votre environnement Linux est prêt !

Développer un package Python en ligne de commande

Vous pouvez soit utiliser le SDK Constellation basé sur Visual Studio pour créer, tester et déployer des packages Constellation (.NET ou Python) ou bien, utiliser l’outil en ligne de commande nommé « Constellation Package Tools CLI ».

Le développement sous Visual Studio est abordé ci-dessous. Pour l’outil en ligne de commande, rendez-vous sur la page : Créer, tester et déployer des packages Python en ligne de commande

Développer un package Python avec Visual Studio

Après avoir installé les prérequis et le SDK Constellation, lancez Visual Studio et créez un nouveau package Constellation de type “Python” :

Une fois créé le projet Visual Studio a la structure suivante :

Vous retrouverez une structure classique pour un package Constellation :

• App.config : le fichier de configuration local pour définir les valeurs locales de vos settings (lire ici) ainsi que les scripts Python à démarrer
• PackageInfo.xml : le manifeste de votre package
• packages.config : le fichier des packages Nuget de votre projet (réservé à Nuget)
• Program.cs : le point d’entrée (C#) de votre package qui se chargera de lancer le “Python Proxy” (le pont entre vos scripts Python et Constellation)
• Le répertoire “Scripts” (qui contient vos scripts Python)
  • Constellation.py : le proxy Python Constellation (la librairie Python) : ne pas modifier !
  • Demo.py : un script Python d’exemple

Configurer les scripts à démarrer

Vous pouvez ajouter autant de scripts Python dans le dossier “Scripts” comme vous le souhaitez. Pour cela, cliquez-droit sur ce répertoire et sélectionnez « Ajouter un nouvel élément ».

Dans la catégorie « Constellation » sélectionnez « Constellation Python Script » :

Chaque script sera démarré dans un processus dédié et connecté à Constellation.

Attention : si vous rajoutez des scripts Python dans ce dossier, il faut obligatoirement les inclure dans le package en sélectionnant “Copy if newer” pour la propriété “Copy to Output directory”. Cette propriété est automatiquement définie à cette valeur si vous avez créé votre fichier Python en sélectionnant l’élément « Constellation Python Script » comme expliqué ci-dessus.

Dans le fichier « App.config » vous devez déclarer les fichiers Python à démarrer. Les scripts Python créé en sélectionnant l’élément « Constellation Python Script » sont automatiquement ajoutés dans ce fichier lors de la création. Si vous renommez ou supprimer vos scripts, n’oubliez pas de mettre à jour ce fichier.

<pythonProxy xmlns="urn:Constellation.PythonProxy">
  <scripts>
    <script filename="Scripts\Demo.py" />
    <script filename="Scripts\LightSensor.py" />
    <script filename="Scripts\Camera.py" />
  </scripts>
</pythonProxy>

Le script “Demo.py” est créé à titre d’exemple. Vous pouvez le supprimer, renommer ou modifier à votre convenance.

Grâce à Visual Studio et au SDK Constellation, vous bénéficiez d’un environnement de développement agréable pour créer vos packages Python avec la coloration syntaxique et l’IntelliSense :

Les bases

Chaque script Python doit impérativement importer la librairie Constellation et démarrer la “connexion” avec le proxy Python en invoquant la méthode “Start” :

import Constellation
# Votre code !
Constellation.Start()

Vous avez trois façon de démarrer cette connexion :

1 – La plus simple est d’invoquer la méthode “Start” :

Constellation.Start()

La méthode “Start” démarre la connexion et maintient le script en “vie” grâce à une boucle qui tourne tant que le package Constellation est lancé.

Autrement dit le code après la méthode “Start” ne sera jamais appelé !

2 – Invoquer la méthode “Start” en passant une fonction de démarrage :

Vous pouvez passer le nom d’une fonction en paramètre de la méthode “Start” qui sera invoquée dès que le script Python est connecté à Constellation.

Cela vous permet de définir du code au démarrage du package :

def OnStart():
    # Mon code de démarrage ici
    pass

Constellation.Start(OnStart);

3 – Troisième méthode : invoquer la méthode “StartAsync” (non bloquante)

Mais attention vous devrez vous même créer une boucle pour maintenant votre script “en vie” autrement il s’arrêtera automatiquement !

Constellation.StartAsync()
while Constellation.IsRunning:
    pass
    time.sleep(1)

Interpréteurs Python et environnements virtuels

Par défaut chaque script est lancé avec la commande “python”. C’est pour cela qu’il est recommandé d’ajouter Python dans le PATH de votre système afin de pouvoir “résoudre” la commande “python”.

Vous pouvez aussi définir dans le fichier App.config de votre package Python, l’attribut “pythonCmd” pour spécifier la commande à lancer. Ci-dessous un exemple avec l’interpréteur Python 2.7 :

<pythonProxy xmlns="urn:Constellation.PythonProxy" pythonCmd="C:\Python27\python.exe">
  <scripts>
    <script filename="Scripts\Demo.py" />
    <script filename="Scripts\Demo2.py" />
  </scripts>
</pythonProxy>

L’attribut “pythonCmd” peut-être également défini de manière individuelle pour chaque script. Prenez par exemple la configuration suivante :

<pythonProxy xmlns="urn:Constellation.PythonProxy" pythonCmd="python3">
  <scripts>
    <script filename="Scripts\Demo.py" />
    <script filename="Scripts\Demo2.py" pythonCmd="C:\Users\Sebastien\venv\Scripts\python.exe" />
    <script filename="Scripts\Demo3.py" pythonCmd="C:\Python27\python.exe" />
  </scripts>
</pythonProxy>

Ci-dessus le package Python démarre trois scripts Demo.py, Demo2.py et Demo3.py de la façon suivante :

• Demo.py sera lancé par l’interpréteur Python 3 (via la commande “python3” défini au niveau global)
• Demo2.py sera lancé par un environnement virtuel ici nommé “venv” (défini pour le script)
• Demo3.py sera lancé par l’interpréteur Python 2.7 installé dans “C:\Python27”

Vous pouvez donc utiliser cet attribut pour spécifier l’interpréteur Python à utiliser (Python 2 vs 3 ou même des interpréteurs dans des environnements virtuels). Quelque soit l’interpréteur utilisé n’oubliez d’installer les librairies “pyzmq” (et “enum34” si Python 2.x).

Note : vous pouvez aussi les Settings Constellation dans l’attribut « pythonCmd » vous permettant ainsi de définir/changer d’interpréteur sans modifier le code de votre package, simplement en manipulant les settings de votre package depuis la Console Constellation. Plus d’information sur ce billet.

Produire des logs

Pour écrire des logs dans le hub Constellation, tout comme en C#, vous disposez des méthodes suivantes :

• WriteInfo
• WriteWarn
• WriteError

Exemple :

Constellation.WriteInfo("Hello world from Python !")
Constellation.WriteWarn("This is a warning !")
Constellation.WriteError("This is an error !")

En Python vous pouvez formater vos messages avec des variables grâce à l’opérateur “%”.

Par exemple, affichons dans les logs Constellation l’état de notre package :

Constellation.WriteInfo("Hi I'm '%s' and I run on %s" % (Constellation.PackageName, Constellation.SentinelName))
Constellation.WriteInfo("IsConnected = %s | IsStandAlone = %s " % (Constellation.IsConnected, Constellation.IsStandAlone))

Vous remarquez par la même occasion quelques propriétés accessibles dans vos scripts Python (IsConnected, IsStandAlone, SentinelName, PackageName, etc…).

Accès aux settings

Le fonctionnement des settings est strictement identique à l’API .NET décrite ici.

Les settings sont définis sur le serveur au niveau du package ou via des groupes, et par héritage peuvent être définis dans le fichier local App.config et/ou dans le manifeste. Je vous invite vivement à lire cet article pour bien comprendre le fonctionnement des settings.

Avec l’API Python de Constellation vous disposez de la méthode “GetSetting” pour récupérer la valeur de vos settings.

Par exemple pour afficher la valeur du setting “Demo1” :

Constellation.WriteInfo("Demo1 = " + str(Constellation.GetSetting("Demo1")))

Si la valeur du setting n’existe pas, la méthode vous retourne un “Null” :

if Constellation.GetSetting("Demo1") <> Null:
     Constellation.WriteInfo("Demo1 = " + str(Constellation.GetSetting("Demo1")))

Vous avez également la possibilité d’attacher une méthode callback pour être notifier dans votre code Python lorsque les settings de votre packages sont mises à jour dans Constellation :

import Constellation

def OnSettingsUpdated():
    print("Mise à jour de mes settings depuis Constellation !!")

def Start():
    Constellation.OnSettingsUpdated = OnSettingsUpdated

Constellation.Start(Start);

Publier des StateObjects

Comme pour l’API .NET, vous disposez de la méthode PushStateObject pour publier un StateObject.

Chaque StateObject a obligatoirement un nom et une valeur de n’importe quel type :

Constellation.PushStateObject("MyString", "OK")
Constellation.PushStateObject("MyNumber", 123)
Constellation.PushStateObject("MyDecimal", 123.12)
Constellation.PushStateObject("MyBoolean", True)

Vous pouvez publier des StateObjects dont la valeur est un objet complexe :

Constellation.PushStateObject("Demo", { "UneString": "DemoPython", "UnNombre": 123 })

Dans l’exemple ce-dessus, le StateObject « Demo » est un objet contenant deux propriétés : « UneString » et « UnNombre ».

Lorsqu’il s’agit de type complexe, il est vivement conseiller de décrire le type du StateObject à Constellation.

Pour cela au démarrage de votre package (méthode Start), enregistrez vos différents types de StateObjects avec la méthode « DescribeStateObjectType ».

Par exemple :

Constellation.DescribeStateObjectType("MyStateObject", "StateObject à deux propriétés de démonstration", [
    { 'Name':'UneString', 'Type':'string', 'Description': 'Une chaine de caractère tout simplement' },        
    { 'Name':'UnNombre', 'Type':'int', 'Description': 'Un nombre entier' }
])

Pour chaque type on spécifiera un nom, une description du type et la liste ses propriétés. Sachant que pour chaque propriété nous avons un nom, un type et une description.

Le type d’une propriété peut faire elle-même référence à un autre type complexe que vous avez enregistré.

Pour finir il faudra déclarer le package descriptor après avoir décrit tous vos types :

Constellation.DeclarePackageDescriptor()

Enfin, pour chaque publication de StateObject, vous pouvez spécifier le type (simple ou complexe que vous aurez enregistré ci-dessus), un dictionnaire de méta-données ou encore une durée de vie (en seconde)  :

Constellation.PushStateObject("Demo", { "UneString": "DemoPython", "UnNombre": 123 }, type = "MyStateObject", metadatas = { "DeviceId": "RPi", "SerialNumber":"123" }, lifetime = 300)

Tester son package dans Visual Studio

Laissons le code de démo du script “Demo.py” créé par le Template du projet tel quel :

Notons simplement qu’au démarrage du package on enregistre la méthode “OnStart” pour :

• Produire différents logs via des “WriteInfo” (Warning & Error) contenant notamment différentes propriétés comme le IsConnected & IsStandalone.
• Publier le StateObject “Demo”

Debug local (hors Constellation)

Commençons par tester notre package hors Constellation en lançant simplement le package avec le bouton “Start” de Visual Studio (F5) :

Votre package démarre et vous pouvez suivre dans la console les différents logs produits par votre package.

Vous observerez que votre package n’est pas connecté à Constellation (IsConnected = false).

Debug dans Constellation

Maintenant lançons toujours le debugging de votre package Constellation depuis Visual Studio mais en connectant votre package à Constellation. (Assurez-vous d’avoir défini dans Visual Studio la Constellation à utiliser pour le debug comme nous l’avons vu dans ce guide).

Cette fois ci, votre package démarre dans Visual Studio mais en étant connecté à Constellation (IsConnected = true).

Vous pouvez donc suivre en temps réel les logs depuis la Console Constellation :

Vous retrouverez également dans le StateObject Explorer de la Console, le StateObject “Demo” publié par notre package :

Publiez votre package

Lorsque votre package est testé et validé, nous pouvons le publier dans Constellation.

Pour cela cliquez sur le bouton de publication :

Sélectionnez votre serveur Constellation cible et cliquez sur “Publish” :

Une fois publié, vous retrouverez votre package dans le “Package Repository” de la Console.

N’oubliez pas que vous pouvez personnaliser les différentes informations (nom du package, auteur, URL, version, description, etc…) en éditant le manifeste de votre package.

Déployez votre package sur une sentinelle

Maintenant que votre package est dans le catalogue de votre Constellation, vous pouvez le déployer sur autant de sentinelle que vous le souhaitez!

Par l’édition du fichier de configuration

Pour cela, vous pouvez éditer manuellement la configuration (via le Configuration Editor) pour ajouter une instance de package sur la sentinelle de votre choix par la ligne :

<package name="MonPackagePython" />

On peut également déclarer le setting “Demo1” pour cette instance de package :

<package name="MonPackagePython">
  <settings>
    <setting key="Demo1" value="Hello Python !!!!" />
  </settings>
</package>

Cliquez sur le bouton “Save & Deploy” et votre package sera automatiquement démarré sur la sentinelle ici nommée “PO-SWARIN” !

Par l’interface graphique de la Console Constellation

Autre moyen, plus intuitif et rapide pour déployer un package, cliquez sur le bouton “Deploy” dans menu contextuel de votre package Python :

Vous pouvez également cliquer sur le bouton “Deploy new package” sur la page “Packages”.

Un assistant vous proposera de sélectionner la sentinelle sur laquelle déployer votre package Python :

Si les settings de votre package sont déclarés dans le manifeste (voir ici), la Console vous affichera une fenêtre de paramétrage :

Une fois votre package déployé, vous pourrez suivre dans la Console Log votre package :

Et voilà votre premier package Python créé et déployé dans votre Constellation !

Next steps

• MessageCallback : exposer des méthodes Python dans la Constellation
• Envoyer des messages et invoquer des MessageCallbacks de la Constellation
• StateObjectLink : consommer des StateObjects de votre Constellation

The post Créez votre premier package Constellation en Python appeared first on Constellation.

Introduction

Par exemple si vous disposez d’un Arduino il vous faudra un shield Ethernet ou Wifi bien que ces derniers ont été retirés du support Arduino.

Arduino propose en alternative des modèles déjà équipés d’une connectivité Ethernet et/ou Wifi comme le MKR1000, le Yun Shield ou le Wifi Shield 101.

En alternative vous avez les ESP8266 que j’ai pu vous présenter sur mon blog personnel.

Ce microcontrôleur est cadencé à 80Mhz par un processeur 32bits RISC avec 96K de RAM et une mémoire flash de 512Ko à 4Mo selon les modèles.

Il dispose d’une connectivité Wifi 802.11 b/g/n supportant le WEP, WPA/2/WPS et réseau ouvert et 16 GPIO dont le support du SPI, I²C, UART et un port ADC (pour les I/O analogiques).

Vous trouverez différents modèles sur internet, comme ceux produit par AI-Thinker mais il faudra réaliser vous même la carte de programmation comme je l’explique sur mon blog ou bien des modules “tout en un” comme ceux d’Adafruit ou Sparkfun disposant d’un port USB intégré pour une programmation facile :

Si vous débutez je vous recommande la Wemos D1 Mini qui intègre un ESP8266 avec 4M de mémoire Flash, 11 I/O digitales et 1 analogique (ADC) ainsi qu’une interface USB le tout pour moins de 5€ :

Pour bien comprendre les ESP8266, je vous recommande une nouvelle fois mon article Découverte des ESP8266 : le microcontrôleur connecté par Wifi pour 2€ au potentiel phénoménal avec Constellation

Le plus important étant que les ESP8266 peuvent être programmés comme les Arduino avec l’IDE Arduino.

Arduino/ESP8266 = package virtuel

Ce concept a déjà été abordé ici. En clair le micro-programme d’un Arduino ou d’un ESP est stocké dans la puce elle même et il n’y a pas de concept de “processus” sur ce genre de device. Il n’est donc pas possible d’avoir une véritable sentinelle qui tourne ce genre d’objet pour déployer et superviser des packages Constellation à la volée comme sur un système Windows ou Linux.

C’est pour cela qu’on parle de sentinelle et de package “virtuel” : on déclare bien dans la configuration de notre Constellation une sentinelle (par exemple nommée “Arduino” et associée à un credential) et contenant un package (par exemple nommé  “TemperatureSensor”). Ce package peut être joint à des groupes et avoir des settings qui lui sont propres.

Dans le microprogramme téléversé sur votre Arduino/ESP vous allez vous connecter en spécifiant le nom de la sentinelle et du package virtuel (ici Arduino/TemperatureSensor) et la clé d’accès associée. Votre device sera alors connecté à Constellation comme étant le package “TemperatureSensor” sur la sentinelle “Arduino”. Comme n’importe quel package il pourra produire des logs, publier des StateObjects, récupérer ses settings, envoyer ou recevoir des messages ou encore consommer les StateObjects d’autres packages.

Techniquement parlant l’Arduino/ESP utilise l’API REST “Constellation”.

Installer la librairie Constellation dans l’IDE Arduino

Ouvrez le « Gestionnaire de bibliothèque » dans le menu « Croquis > Inclure une bibliothèque > Gérer les bibliothèques » :

Avec le moteur de recherche, recherchez le terme « ArduinoJson » :

Vous trouverez lors la bibliothèque « ArduinoJson » de Benoit Blanchon (dépendance de la librairie Constellation) ainsi que la librairie Constellation.

Pour ces deux bibliothèques, cliquez sur le bouton « Installer » (ou « Mise à jour » si la librairie est déjà installée).

Hello World, Hello Constellation

Commencez par créer un nouveau sketch et ajoutez la librairie Constellation :

#include <Constellation.h>

Vous pouvez maintenant déclarer le client “Constellation” en l’initialisant avec l’adresse (IP ou DNS) de votre serveur Constellation, le port et les informations de connexion de Constellation, c’est à dire le nom de votre sentinelle et package ainsi que la clé d’accès que vous aurez déclarés sur votre serveur :

Constellation<WiFiClient> constellation("IP or DNS du serveur constellation", 8088, "MyVirtualSentinel", "MyVirtualPackage", "123456789");

Pour ajouter une sentinelle virtuelle cliquez sur le bouton “Add sentinel” sur la page “Sentinels” de la Console Constellation :

Puis ajoutons un package virtuel en cliquant sur le bouton contextuel de notre sentinelle “Deploy package” ou directement depuis la package “Packages” :

Déclarez ensuite le nom de votre package, ici “MyVirtualPackage” utilisant la même clé que celle définie au niveau de la sentinelle :

Vous remarquerez que dans la déclaration du client Constellation nous avons spécifié dans le template de la classe Constellation le type de notre client réseau, qui dans le cas d’un ESP8266 ou d’un Arduino MKR1000 est “WifiClient”.

N’oubliez pas d’ajouter les librairies de votre client réseau, quelques exemples :

/* Arduino Wifi (ex: Wifi Shield) */
#include <SPI.h>
#include <WiFi.h>

/* Arduino Wifi101 (for WiFi Shield 101 and MKR1000 board) */
#include <SPI.h>
#include <WiFi101.h>

/* Arduino Ethernet */
#include <SPI.h>
#include <Ethernet.h>

/* ESP8266 Wifi */
#include <ESP8266WiFi.h>

Au démarrage du programme, nous allons d’abord connecter votre client réseau sur le réseau. Dans le cas d’un ESP8266, on se connecte au réseau Wifi de cette façon :

void setup(void) {
  Serial.begin(115200);

  // Connect to Wifi  
  WiFi.begin("MY-SSID", "MY-WIFI_KEY");  
  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(".");
  }
  // For WiFi101, wait 10 seconds for connection!
  // delay(10000);

  Serial.println("WiFi connected. IP: ");
  Serial.println(WiFi.localIP());
}

Une fois connecté au réseau, on peut utiliser les méthodes de la librairie Constellation.

Par exemple, produisons un log avec la méthode “WriteInfo” :

constellation.writeInfo("Hello Constellation");

Cette méthode gère nativement le formatage “à la printf”, par exemple :

constellation.writeInfo("Hello Constellation, I'm '%s !", constellation.getSentinelName());

Notez que vous pouvez produire de la même façon des messages de type “Info”, “Warning” ou “Error” :

constellation.writeInfo("This is an information"); 
constellation.writeWarn("This is a warning"); 
constellation.writeError("This is an error");

Bien entendu, comme n’importe quel package, les logs sont remontés en temps réel dans la Constellation ce qui permet à n’importe quel “contrôleur” de voir les logs de votre Arduino/ESP en temps réel.

Par exemple, en ouvrant la Console Constellation on pourra suivre votre Arduino/ESP en temps réel :

Accès aux settings

Tous les settings des packages de votre Constellation sont déclarés depuis le fichier de configuration de votre Constellation. Vous pouvez aussi utiliser la Console Constellation pour les administrer.

Dans votre code Arduino, vous devez utiliser la méthode “getSettings” pour récupérer un objet JSON contenant les settings (clé/valeur).

JsonObject& settings = constellation.getSettings();

Par exemple pour récupérer la valeur du setting “MonChiffre” déclarée sur le serveur à 42 :

JsonObject& settings = constellation.getSettings();
static int monChiffre= settings["MonChiffre"].as<int>()

La variable “monChiffre” sera donc affectée à la valeur “42”. Dans l’exemple ci-dessus, la variable est statique pour pouvoir être utilisée n’importe où dans votre code.

Pour les chaines de caractères vous pouvez utiliser la classe “String” :

JsonObject& settings = constellation.getSettings();
static String strMaChaine = String(settings["MaChaine"].as<char *>());

Encore une fois la variable est statique pour pouvoir l’utiliser n’importe où dans votre code.

Si vous devez convertir votre chaîne de caractères en const char *, vous pouvez utiliser la fonction c_str() :

const char* maChaine = strMaChaine.c_str();

Vous pouvez également tester la présence d’un setting avec la méthode « containsKey » :

if(settings.containsKey("MySetting")) {  
  // Do something with settings["MySetting"]  
}

Par exemple vous pouvez gérer les valeurs par défaut. Imaginez un code où la valeur d’un timeout est de 5 secondes par défaut mais vous vous laissez la possibilité de surcharger cette variable depuis les settings Constellation :

// Default value
int timeout = 5; // sec

setup() {
  // .....
  JsonObject& settings = constellation.getSettings();
  if(settings.containsKey("Timeout")) {  
    timeout = settings["Timeout"].as<int>();
  }
}

void loop() {
   // DO something with 'timeout'
}

Si le setting « Timeout » est défini dans les settings de votre package sur Constellation, la variable « timeout » sera affectée à votre valeur, autrement, si le setting n’existe pas, la valeur de cette variable sera de 5.

Publier des StateObjects

Pour produire et publier un StateObject dans votre Constellation vous devez invoquer la méthode “pushStateObject” :

constellation.pushStateObject(name, value);

Vous pouvez aussi passer le “type” de votre StateObject :

constellation.pushStateObject(name, value, type);

Notez que pour les types simples (int,bool, long, float et double) le type est spécifié implicitement.

Par exemple, pour publier un StateObject dont la valeur est un chiffre :

constellation.pushStateObject("Temperature", 21);

Vous pouvez aussi publier des StateObject avec un objet complexe en utilisant la fonction “stringFormat” pour formater votre valeur en JSON.

Par exemple pour publier un StateObject nommé “Lux” étant un objet contenant 3 propriétés :

constellation.pushStateObject("Lux", stringFormat("{ 'Lux':%d, 'Broadband':%d, 'IR':%d }", lux, full, ir));

Vous pouvez également faire la même chose en construisant un “JsonObject” :

StaticJsonBuffer<200> jsonBuffer;
JsonObject& root = jsonBuffer.createObject();

root["Lux"] = lux;
root["Broadband"] = full;
root["IR"] = ir;
constellation.pushStateObject("Lux", &root);

Une fois vos StateObjects publiés, ils sont accessibles en temps réel aux autres packages et consommateurs de votre Constellation. Vous pouvez également utiliser le “StateObject Explorer” de la Console Constellation pour explorer tous les StateObjects de votre Constellation :

Next steps

• Publier des StateObjects
• Envoyer des messages
• Recevoir des messages
• Consommer des StateObjects
• Connectez vos ESP8266 à Constellation en Lua avec NodeMCU

The post Connecter un Arduino ou un ESP8266 à Constellation appeared first on Constellation.

Nous allons dans cet article créer, tester et déployer sur votre Constellation un package Python avec cet outil.

Prérequis

Le « Constellation Package Tools CLI » est un outil en ligne de commande compatible Windows et Linux. Il est écrit en Python et s’installe via PIP avec la commande :

pip install constellation-pkgtools-cli

Sur Windows vous devriez au préalable avoir installé Python 2.7 ainsi que l’outil « pip » et les libraires « pyzmq » et « enum34 ». La procédure complète d’installation est décrite sur cette page.

Via une invite de commande, tapez la commande ci-dessus :

Sur Linux, vous devez également avoir installé Python 2.7 (généralement installé par défaut),  l’outil « pip » et les libraires « pyzmq » et « enum34 » sans oublier le moteur Mono. Pour cela, utilisez le WPI (Web Platform Installer) pour installer une sentinelle Constellation. Celui-ci se chargera de déployer l’ensemble des prérequis nécessaire.

La commande « ctln »

Une fois le package Python « constellation-pkgtools-cli » installé via PIP, vous aurez accès à une commande nommée « ctln » (abréviation de Constellation)

Cette commande vous permettra de créer de nouveau package, les tester et déployer en local ou directement sur un serveur Constellation.

Créer son premier package Python

Pour créer un nouveau package utilisez simplement la commande “create” en spécifiant le nom de votre package. Par exemple :

ctln create <mon projet>

Et voilà, votre package “MyFirstPackage” est créé dans le répertoire du même nom !

Template de package

Chaque package est créé à partir d’un template. Vous pouvez lister les templates avec la commande :

ctln template list

A l’heure où est écrit cet article il y a deux templates de type “projet” :

• Python Base Template : le template de base (créé par défaut)
• Python Demo template : package Python avec du code de “demo”

Lorsque vous créez un package avec la commande “ctln create”, le template “python-base” est sélectionné par défaut.

Vous pouvez cependant préciser l’Id du template à utiliser dans la commande “ctln create”. Par exemple pour créer un package sur base du template de demo :

ctln create <mon projet> python-demo

Il y a aussi des templates de type “item”, c’est à dire des templates pour les scripts que vous allez rajouter par la suite à votre package.

Mise à jour du template

Comme vous le constatez dans le listing des templates ci-dessus, chaque template comporte un numéro de version car ils sont amenés à évoluer notamment en cas de mise à jour des librairies Constellation.

Avec le SDK Constellation Visual Studio, les nouvelles versions des librairies sont diffusées avec NuGet. Ici avec cet outil en ligne de commande, les nouvelles librairies sont embarquées dans des mises à jour des templates.

Ainsi pour mettre à jour vos packages, vous pouvez tout simplement mettre à jour le template de votre package par la commande :

ctln update

Cette commande doit être lancé depuis le répertorie racine de votre package.

Notez également que la mise à jour est “intelligente” dans la mesure où elle n’écrase pas vos fichiers de configuration, le manifeste du package ou encore vos scripts Python.

Développer son package

Le développement de package Python est expliqué dans cet article. Bien que l’article se base sur Visual Studio, l’API Python est strictement identique.

Ainsi, pour rappel, vous avez à la racine de votre projet le fichier « PackageInfo.xml » qui contient l’ensemble des informations de votre package (plus de détail ici) mais aussi le fichier de configuration nommé « PythonPackageHost.exe.config » qui contient la liste des scripts Python à lancer.

Les bases du développement d’un script Constellation Python sont expliquées ici.

Pour faciliter le développement, vous n’êtes pas obligé de modifier manuellement le fichier de configuration pour gérer les scripts Python. Pour cela vous avez à disposition différentes commandes pour lister, ajouter, renommer ou supprimer des scripts.

Lister les scripts du package

Les scripts Constellation Python lancés par votre package peuvent être listés par la commande :

ctln pyscript list

Ici votre package « MyFirstPackage » ne contient qu’un seul script nommé « Main.py » dans le répertoire Scripts du package.

Ajouter des scripts Python

Pour ajouter un script Constellation Python, vous pouvez soit ajouter un script existant sur votre système de fichier dans votre package ou soit créer un nouveau script à partir d’un modèle (template).

Ajouter un script existant

Pour un script existant, il suffit d’utiliser l’option « add » :

ctln pyscript add <filepath> [--filename=<name>]

Vous devez spécifier le chemin complet vers votre fichier à ajouter (filepath) et optionnellement le nom du fichier une fois ajouté dans votre package.

Par exemple la commande ci-dessous ajoutera dans votre package le fichier « ~/demo/MyDemo.py » sous le nom « DemoSeb.py »

ctln pyscript add ~/demo/MyDemo.py --filename=DemoSeb.py

Ajouter de nouveau script

L’action la plus courante sera de créer un nouveau script Python dans votre package avec l’action « new » via la commande suivante :

ctln pyscript new <filename> [<item_template_name>]

Vous devez obligatoirement spécifier le nom du fichier (filename) avec ou sans l’extension .py (rajoutée automatiquement). Le script sera créé dans le répertoire Scripts de votre package et automatiquement déclaré dans la configuration.

Vous pouvez également spécifier l’identifiant du template à utiliser. Les templates peuvent être listés avec la commande « ctln template list » comme vu ci-dessus.  A l’heure où cet article est écrit il y a trois templates de type « item » :

• « python-base » : le template de base
• « python-demo »  : un template avec du code de demonstration
• « python-empty »  : un squelette vide

Si vous ne précisez pas l’identifiant, c’est le template « python-base » qui sera utilisé.

Par exemple ajoutons à notre package un deuxième script (avec le template de base) :

ctln pyscript new Main2

Rajoutons également un troisieme scriupt de démonstation en utilisant le template de demo (python-demo) :

ctln pyscript new DemoConstellation python-demo

Notre package a maintenant trois scripts : Main.py (créé avec le template du package), Main2.py (créé ci-dessus avec le template de base), DemoConstellation.py (créé avec le template de demo) :

Renommer ou supprimer des scripts

Vous pouvez renommer les scripts du package avec l’option “rename”. Par exemple renommons “DemoConstellation” par “Demo” (les extensions “.py” sont optionnelles) :

ctln pyscript rename DemoConstellation Demo

Pour supprimer des scripts il suffit d’utiliser l’option “remove” en spécifiant le nom du script (avec ou sans son extension .py).

Par exemple supprimons les deux fichiers “Main2.py” et “Demo.py” que nous avons ajoutés (et renommés) ci-dessus :

ctln pyscript remove Main2
ctln pyscript remove Demo

Editer les scripts Python du package

Une fois vos scripts ajoutés, renommés ou supprimés avec la commande “ctln”, libre à vous d’utiliser votre éditeur de texte préféré pour éditer votre code !

Par exemple de le cas ici présent d’un accès SSH Linux, je pourrais utiliser “nano” ou “vim” (ou encore Notepad++ sur ma station WIndows via un tranfert SCP avec WInSCP par exemple).

nano Scripts/Main.py

Ici le script “Main” défini une fonction de démarrage (OnStart) et une fonction de fermeture (OnExit). Pour rappel, les bases de l’API Constellation Python sont expliquées ici.

Notez simplement que dans cet exemple, le WriteInfo déclenché au démarrage (OnStart) écrit un log dasn Constellation de type “Information” en concaténant dans un message textuel les propriétés suivantes :

• “PackageName” : le nom du package
• “SentinelName” : le nom de la sentinelle sur laquelle est déployée ce package
• “IsStandAlone” : un booléen indiquant si le package tourne de façon indépendante ou hébergée au sein d’une sentinelle
• “IsConnected” : un booléen indiquant si le package est connecté ou non à une Constellation

Tester son package

Pour tester notre package en local, il suffit de lancer la commande suivante :

ctln run

Comme vous pouvez le lire sur la console, le nom de la sentinelle affichée est “local sandbox” étant donné que la propriété IsStandalone est true (la propriété SentinelName est None). En effet votre package n’est pas déployé/démarré par Constellation sur une véritable sentinelle. Il est juste démarré en “standalone” par la commande “run”.

De plus la propriété “IsConnected” est false car votre package n’est pas connecté à une Constellation.

Vous pouvez donc tester des éléments de base de votre package mais de façon déconnecté, il manquera donc plusieurs fonctionnalités (les logs produits resterons local dans votre console, pas d’accès aux settings hormis ceux déclarés en local, la publication ou consommation de StateObjects sera impossible tout comme l’invocation ou l’exposition de MessageCallbacks).

Pour tester votre package complètement, il est possible de le lancer en local tout en le connectant à une Constellation.

Tout d’abord, il faudra déclarer des serveurs Constellation dans l’outil ctln.

Ajouter et gérer des serveurs Constellation

Les commandes sont les suivantes :

ctln server list
ctln server (add | set) <name> --url=<url> --accesskey=<key>
ctln server (add | set) <name> --url=<url> --username=<user>
ctln server check <name>
ctln server remove <name>

Vous pouvez lister les serveurs, ajouter ou mettre à jour des serveurs avec la clé d’accès ou un couple login/password, tester la connectivité ou supprimer des serveurs.

Par exemple je dispose d’une Constellation installée à l’adresse : http://pc-seb.ajsinfo.loc:8088. Un credential basé sur le couple login/password “admin/seb” a été configuré. Je peux donc ajouter ce serveur que je nommerai ici “pc-seb” via la commande :

ctln server add pc-seb --url=http://pc-seb.ajsinfo.loc:8088 --username=admin

Le serveur ajouté est testé au moment de l’ajout mais vous pouvez à tout moment tester la connectivité vers cette Constellation avec la commande “ctln server check”. Par exemple pour tester la Constellation nommée “pc-seb” :

ctln server check pc-seb

Tester son package dans Constellation

Maintenant que nous avons ajouté un serveur Constellation dans l’outil, nous pouvons relancé notre package en le connectant à notre Constellation nommée “pc-seb” via la commande :

ctln run --server=pc-seb

Le package démarre toujours dans la « sandbox locale » (IsStandalone = true) mais cette fois ci il est connecté à ma Constellation nommée « pc-seb » (IsConnected = true).

D’ailleurs en lançant la Console Constellation je peux maintenant suivre en temps réel les logs de ce package, les StatesObjects qu’il produit ou encore les MessageCallbacks qu’il expose.

Publier son package

Une fois le package développé et testé, il ne reste plus qu’à le packager pour pouvoir le déployer dans Constellation.

Vous pouvez soit le packager dans un fichier en local (que vous pourrez uploader sur une Constellation ou échanger avec d’autre) ou soit le déployer directement dans une Constellation référencée dans l’outil.

Par exemple pour publier ce package dans un fichier local dans le répertoire “/home/pi” :

ctln publish --output=/home/pi

Maintenant, pour déployer ce même package directement sur une Constellation, il suffit simplement de spécifier le nom du serveur Constellation enregistré sur la commande “publish”.

Par exemple pour publier ce package sur la Constellation nommée ici “pc-seb” :

ctln publish pc-seb

En vous rendant sur le Package Repository de votre Console Constellation, votre package fraîchement publié sera prêt à être déployé sur vos sentinelles Windows ou Linux de votre Constellation.

Next steps

Pour en savoir plus sur le développement de package en Python :

• Retour sur les bases de l’API Python  (produire des logs, accéder aux settings, publier des StateObjects)
• Exposer vos fonctions Python dans Constellation (les MessageCallbacks)
• Invoquer des MessageCallbacks des autres packages de votre Constellation en Python
• Consommer les StateObjects de votre Constellation

The post Créer, tester et déployer des packages Python en ligne de commande appeared first on Constellation.

Pour exposer une méthode Python dans Constellation vous devez tout simplement ajouter le décorateur “Constellation.MessageCallback” sur votre méthode :

@Constellation.MessageCallback()
def SimpleMessageCallback():
    Constellation.WriteInfo('Hello Python !')

Ici nous déclarons le MessageCallback “SimpleMessageCallback” sans paramètre ni documentation.

Vous pouvez ajouter un ou plusieurs arguments à votre MC et utiliser la syntaxe de Python pour commenter vos MC :

@Constellation.MessageCallback()
def DemoArg(data):
    "Ceci est la description du MessageCallback DemoArg avec 1 argument"
    Constellation.WriteInfo('arg = %s', data)

@Constellation.MessageCallback()
def DemoArgs(a, b, c):
    "Ceci est la description du MessageCallback DemoArgs avec 3 arguments"
    Constellation.WriteInfo(a)
    Constellation.WriteInfo(b)
    Constellation.WriteInfo(c)

Le ou les paramètres peuvent être des types simples (string, int, bool, etc..) ou des types (objets) complexes :

@Constellation.MessageCallback()
def ComplexMessageCallback(data):
    "Ceci est la description du MessageCallback ComplexMessageCallback avec un objet complexe en argument"
    Constellation.WriteInfo(data.A)
    Constellation.WriteInfo(data.B)
    Constellation.WriteInfo(data.C)

L’ensemble de ces méthodes déclarées “MessageCallbacks” seront alors référencées dans la Constellation. Vous pouvez les découvrir en interrogeant le Package Descriptor de votre package.

Par exemple, lancez la Console Constellation et rendez-vous dans le “MessageCallback Browser”. Vous aurez la liste de vos méthodes avec la possibilité de les invoquer directement depuis l’interface :

Documenter son MessageCallback

Description des MessageCallbacks

Comme vous l’avez remarqué dans les exemples précédents, nous utilisons la documentation des méthodes de Python :

@Constellation.MessageCallback()
def Demo():
    "Ceci est la description du MessageCallback !"
    pass

La documentation de la méthode est utilisée comme description du MessageCallback :

La description de la méthode peut être écrite sur plusieurs lignes :

@Constellation.MessageCallback()
def Demo():
    '''
    The first line is brief explanation, which may be completed with 
    a longer one. For instance to discuss about its methods.
    '''
    pass

Description des arguments des MessageCallbacks

Note : la description des arguments est disponible depuis l’API Python 1.8.4.x. Pensez à mettre à jour la référence de votre API par Nuget depuis Visual Studio ou en mettant à jour le template depuis la CLI.

Si vous regardez attentivement les arguments des MC dans le MessageCallback Explorer, ils sont reconnus comme « System.Object » étant donné que les arguments d’une fonction en Python ne sont pas typés.

Pour décrire les paramètres utilisez la syntaxe suivante dans la description du MC :

:param <type> <name> : <description>

Par exemple :

@Constellation.MessageCallback()
def Demo(a, b, c):
    '''
    Ceci est un exemple de MC avec 3 parametres

    :param int a: My int value
    :param bool b: My boolean value
    :param string c: My string value
    '''
    Constellation.WriteInfo("a = %s - type: %s" % (a, type(a)))
    Constellation.WriteInfo("b = %s - type: %s" % (b, type(b)))
    Constellation.WriteInfo("c = %s - type: %s" % (c, type(c)))

Ainsi en retournant sur le MC Explorer, chaque argument est correctement typé dans Constellation.

Paramètres optionnels avec valeur par défaut

Vous pouvez également définir que certains paramètres sont optionnels en spécifiant leurs valeurs par défaut avec la syntaxe [default: XXX] :

@Constellation.MessageCallback()
def DemoOptional(a, b):
    '''
    Ceci est un exemple de MC des paramètres optionnels

    :param int a: My int value [default:10]
    :param bool b: My boolean value [default:true]
    '''
    Constellation.WriteInfo("a = %s" % a)
    Constellation.WriteInfo("b = %s" % b)

Décrire les arguments de type complexe

Dans le cas où un MC prend en paramètre un (ou plusieurs) type complexe, il faudra d’abord décrie le type dans la méthode « Start ».

Par exemple, enregistrons au démarrage du package (méthode Start), le type “CredentialInfo” :

Constellation.DescribeMessageCallbackType("CredentialInfo", "Credential information", [
    { 'Name':'Username', 'Type':'string', 'Description': 'The username' },
    { 'Name':'Password', 'Type':'string', 'Description': 'The password' },
])

Une fois tous vos types déclarés, il faut publier le “Package Descriptor” de votre package à Constellation par la ligne :

Constellation.DeclarePackageDescriptor()

Nous pouvons maintenant déclarer un MC avec un parametre de type “CredentialInfo”. Par exemple :

@Constellation.MessageCallback()
def DemoAuth(credential):
    '''
    Demo MC avec avec un paramètre de type complexe

    :param CredentialInfo credential: the credential info
    '''
    Constellation.WriteInfo("User=%s Password=%s" % (credential.Username, credential.Password))

Comme vous pourrez le voir dans le MessageCallbacks Explorer, votre méthode Python est correctement décrite ainsi que son paramètre “credential” de type “Credentialnfo”.

Notez également que la description du type CredentialInfo est accessible en cliquant sur le type :

Personnaliser le MessageCallback

Comme pour l’API.NET, par défaut le nom du MessageCallback déclaré dans la Constellation est le nom de votre méthode mais vous pouvez redéfinir le nom exposé dans la Constellation :

@Constellation.MessageCallback("MySuperName")
def MyInternalMethodName():
    Constellation.WriteInfo("Hello")

Aussi vous pouvez “cacher” ce MessageCallback à la Constellation.

@Constellation.MessageCallback(False)
def HiddenMessageCallback():
    "Hidden message callback"
    Constellation.WriteInfo("I'm here !!")

Tous les packages ou consommateurs de votre Constellation pourront envoyer un message “HiddenMessageCallback” à votre package Python et donc invoquer votre méthode mais celle-ci ne sera pas déclarée dans le “Package  Descriptor”.

Récupérer le contexte

Comme avec l’API.NET, vous pouvez récupérer le contexte de réception du message en déclarant comme dernier argument de votre MessageCallback, le paramètre “context”.

Par exemple :

@Constellation.MessageCallback("MaMethode") # méthode renommée !
def DemoSeb5(context):
    "Test du contexte"
    Constellation.WriteInfo("Sender : %s" % context.Sender.FriendlyName)
    Constellation.WriteInfo("test sans parametre")

Ou avec des paramètres :

@Constellation.MessageCallback()
def DemoSeb5(a, b, context):
    "Test du contexte avec parametre"
    Constellation.WriteInfo("Sender : %s" % context.Sender.FriendlyName)
    Constellation.WriteInfo("a = %s et b = %s" % (a, b))

Il faut juste que le dernier argument soit nommé “context”. Notez qu’il ne fait pas partie de la signature de votre MessageCallback.

Ci-dessus, le 1er exemple est un MessageCallback caché et sans paramètre et le 2ème n’a que deux paramètres “a” et “b”.

L’objet “context” correspondant à la classe “Constellation.Package.MessageContext”. Vous retrouvez les propriétés suivantes :

• IsSaga : indique si le message reçu appartient à une Saga
• SagaId : identifiant de la Saga (si IsSaga = true)
• Scope : scope d’envoi du message reçu
  • Type : type du scope (All, Group, Package, Sentinel, Others)
  • Args : arguments du scope (ex : nom du groupe, du package ou de la sentinelle)
• Sender : représente l’émetteur du message
  • ConnectionId : identifiant de connexion unique de l’émetteur
  • Type : type de l’émetteur (ConsumerHub, ConstellationHub, ConsumerHttp ou ConstellationHttp)
  • FriendlyName : nom de l’émetteur

Répondre aux Sagas

Votre méthode peut également retourner une réponse à l’appelant, c’est ce que l’on appelle une saga. Pour cela vous pouvez spécifier le type de la valeur de retour dans le décorateur de la façon suivante :

@Constellation.MessageCallback(returnType='System.Boolean')
def DemoSaga(user, password):
    "Test de saga"
    Constellation.WriteInfo("User=%s Password=%s" % (user, password))
    return user == password

Cependant il est recommandé d’utiliser la description du MC pour spécifier le type de retour avec la syntaxe

:return <type>: <description>

Par exemple :

@Constellation.MessageCallback()
def DemoSaga(user, password):
    '''
    Test de saga

    :param string user: The username
    :param string password: The password
    :return bool: if user match
    '''
    Constellation.WriteInfo("User=%s Password=%s" % (user, password))
    return user == password

Cela marche également en combinant la récupération du contexte :

@Constellation.MessageCallback()
def DemoAuth(user, password, context):
    '''
    Test de saga

    :param string user: The username
    :param string password: The password
    :return bool: if user match
    '''
    Constellation.WriteInfo("Sender : %s" % context.Sender.FriendlyName)
    Constellation.WriteInfo("User=%s Password=%s" % (user, password))
    return user == password

Par exemple en ouvrant le “Message Callback Explorer” de la Console Constellation vous constaterez que votre MC “DemoAuth” est bien référencé comme retournant un “Booléen” en prenant deux arguments (car l’argument “context” n’est pas pris en compte dans la signature du MC) :

En invoquant cette méthode depuis la console, vous recevrez alors la réponse du package, ici un booléen :

Dans les logs, on retrouve bien la trace de l’invocation de notre Saga avec le “contexte” :

(le FriendlyName de la Console Constellation est “Consumer/ControlCenter:<user>”).

The post MessageCallback : Exposer des méthodes Python appeared first on Constellation.

Pour envoyer un message et donc invoquer un MessageCallback depuis un package Python vous devez utiliser la méthode “Constellation.SendMessage”. Par exemple :

Constellation.SendMessage("SMS", "SendMessage", [ "+33676903634", "Bonjour Constellation" ])

Ici par exemple on envoi un message au package “SMS” pour invoquer le MessageCallback “SendMessage” en passant en argument deux paramètres de type string.

Le MessageCallbacks Explorer de la Console Constellation permet de lister l’ensemble des MC déclarés par les packages de votre Constellation.

Par exemple, avec le package Nest déployé dans votre Constellation, on retrouvera un MessageCallback  “SetTargetTemperature” pour piloter la température de consigne d’un thermostat Nest.

Pour l’invoquer depuis notre code Python :

Constellation.SendMessage("Nest", "SetTargetTemperature", [ "thermostatId", 19 ], Constellation.MessageScope.package)

On peut également passer en paramètre un objet complexe. Par exemple le MC “AreaArm” du package Paradox permet d’armer le système d’alarme en passant en paramètre un objet “ArmingRequestData” contenant le secteur à armer, le mode d’armement et le PIN.

Le code Python pour invoquer ce MC sera alors :

Constellation.SendMessage("Paradox", "AreaArm", { "Area":"All", "Mode":1, "PinCode":"0000" }, Constellation.MessageScope.package)

Vous pouvez également passer plusieurs arguments à votre MC en combinant type simple et type complexe. Par exemple le MC “ShowNotification” du package Xbmc permettant d’afficher une notification sur une interface Kodi/XBMC prend deux paramètres : le nom d l’hôte XBMC (un type simple) et le détail de la notification à afficher (un type complexe) :

Constellation.SendMessage("Xbmc", "ShowNotification", [ xbmcName, { "Title":"Hello Constellation", "Message":"Hello I'm Python" } ], Constellation.MessageScope.package)

Les exemples de message ci-dessus sont tous envoyés à un package mais vous pouvez également envoyer vos messages à différents scopes.

Par exemple pour envoyer le message “Demo” sans aucun paramètre au groupe A, on écrira :

Constellation.SendMessage("A", "Demo", {}, Constellation.MessageScope.group)

Les scopes disponibles sont :

• group
• package
• sentinel
• others
• all

Notez par ailleurs que le paramètre “MessageScope” de la méthode “SendMessage” est optionnel. Si il n’est pas spécifié le scope par défaut est “package”.

Envoyer des messages avec réponse : les Sagas

Si le MC que vous invoquez retourne un message de réponse, vous devez envoyer votre message dans une saga. Pour cela vous pouvez utiliser la méthode “SendMessageWithSaga” dans laquelle vous devrez spécifier la fonction qui sera invoquée lors de la réception de la réponse.

Par exemple reprenons le MessageCallback “AreaArm” du package Paradox :

Comme vous le constatez, ce MessageCallback retourne un “Boolean” pour indiquer si l’armement a bien été déclenché.

On peut donc invoquer ce MC dans une saga et attacher un callback de réponse pour afficher dans le logs de notre package si l’armement a réussi :

Constellation.SendMessageWithSaga(lambda response:
   Constellation.WriteInfo("Arm result is %s" % response),
"Paradox", "AreaArm", { "Area":"All", "Mode":1, "PinCode":"0000" })

Ici nous avons utilisé une fonction lambda pour simplifier la lecture mais vous pouvez également définir une fonction classique dans votre code.

Le paramètre “response” utilisé dans la fonction callback est l’objet de la réponse envoyé par le package qui a reçu votre message. Ici “response” est un “Boolean” car le MC “AreaArm” retourne un booléen mais il peut être de n’importe quel type (simple ou complexe).

Le MessageCallback Explorer de la Console Constellation vous donnera tous les détails.

The post Envoyer des messages et invoquer des MessageCallbacks en Python appeared first on Constellation.

Par exemple si vous voulez récupérer en temps réel le StateObject correspondant à un thermostat Nest (partant de l’hypothèse où le package Nest est déployé dans votre Constellation).

Via le StateObjects Explorer de la Console Constellation, on retrouvera le StateObject ici nommé “Living Room” publié par le package Nest qui représente l’état du thermostat du salon :

On peut donc écrire une méthode qui sera liée à ce StateObject pour afficher un message de log à chaque fois que l’état du thermostat sera mis à jour :

@Constellation.StateObjectLink(package = "Nest", name = "Living Room")
def OnNestTargetTemperatureChanged(stateObject):
    Constellation.WriteInfo("The Nest target temperature has changed to : %s°C" % stateObject.Value.target_temperature_c)

Le décorateur “StateObjectLink” accepte les paramètres suivants : “sentinel”, “package”, “name” et “type”. Tous ces paramètres sont optionnels et par défaut défini à “*”, c’est à dire qu’aucun filtre n’est appliqué !

Une méthode décorée “StateObjectLink” doit accepter qu’un seul argument : le StateObject.

Un StateObject contient les propriétés suivantes :

• SentinelName : nom de la sentinelle qui a produit le StateObject
• PackageName : nom du package qui a produit le StateObject
• Name : le nom du StateObject
• UniqueId : identifiant unique du StateObject dans la Constellation (concaténation des 3 propriétés ci-dessus)
• Type : type du StateObject
• Lifetime : durée de vie en seconde du StateObject avant d’être considéré “expiré” (0 si infini)
• LastUpdate : date de la dernière publication du StateObject
• IsExpired : indique si le StateObject est expiré (c’est à dire que DateTime.Now >  LastUpdate  + Lifetime si et seulement si Lifetime > 0)
• Metadatas : dictionnaire de clé / valeur
• Value : la valeur du StateObject (peut être un type simple ou un objet complexe)

Important : la méthode sur laquelle est appliquée cet attribut sera invoquée au démarrage de votre package avec la valeur actuelle du ou des StateObjects (Request) puis à chaque mise à jour des StateObjects (Subscribe).

Autre exemple, affichons dans les logs de notre package Python la consommation des CPU de l’ensemble des sentinelles Windows connectées dans notre Constellation en utilisant le package HWMonitor :

@Constellation.StateObjectLink(package = "HWMonitor", name = "/intelcpu/0/load/0")
def CPUUpdated(stateobject):
    Constellation.WriteInfo("CPU on %s is currently %s %" % (stateobject.SentinelName, stateobject.Value.Value))

Dans le cas où vous souhaiterez conserver la valeur de votre StateObject dans une variable de votre script Python pour pouvoir vous en servir dans d’autre méthode, il suffit tout simplement d’affecter le StateObject dans une variable globale depuis un StateObjectLink.

Reprenons l’exemple du thermostat Nest ci-dessus. Commençons par déclarer cette variable globale au niveau de notre script :

global nestThermostat

Puis ajoutons un StateObjectLink vers le StateObject du thermostat Nest pour mettre à jour notre variable globale :

@Constellation.StateObjectLink(package = "Nest", name = "Living Room")
def OnNestThermostatChanged(stateObject):
    global nestThermostat
    nestThermostat = stateObject.Value

Ainsi la variable « nestThermostat » contiendra la dernière valeur du StateObject représentant le thermostat Nest. Vous pourrez y accéder depuis n’importe quel endroit de votre script.

The post Consommer des StateObjects depuis l’API Python appeared first on Constellation.

Comme nous l’avons vu dans le tutoriel précèdent, un package est une application !

Il faut impérativement appeler la méthode “PackageHost.Start” au démarrage de l’application, c’est à dire dans la méthode “Main” autrement, ce n’est pas un package Constellation mais une simple application .NET !

Lorsque vous appelez la méthode “PackageHost.Start” vous devez impérativement transférer les arguments (args) et indiquer la classe de votre package (ici nommée “MonPackage”).

static void Main(string[] args)
{
    PackageHost.Start<MonPackage>(args);
}

La classe d’un package doit être une classe qui implémente l’interface “IPackage”. Cette interface définit trois méthodes :

• OnStart qui sera invoqué lorsque le package a démarré
• OnPreShutdown : invoqué lorsque le package va s’arrêter (à ce stade votre package est toujours connecté à Constellation, vous pouvez encore pusher des StateObjects, envoyer des messages, écrire des logs sur le hub, etc..)
• OnShutdown : invoqué après le OnPreShutdown et après avoir fermé les connexions (plus aucune interaction avec la Constellation possible)

Pour vous éviter de devoir implémenter ces trois méthodes, votre classe peut hériter de la classe “PackageBase”. Cette classe abstraite implémente l’interface IPackage dans des méthodes virtuelles vides.

Libre à vous d’implémenter les méthodes que vous souhaitez !

public class MonPackage : PackageBase
{
    //public override void OnStart()
    //{
    //}

    //public override void OnPreShutdown()
    //{
    //}

    //public override void OnShutdown()
    //{
    //}
}

Ecrire des logs

Pour écrire des logs depuis un package Constellation vous disposez des méthodes suivantes :

• PackageHost.WriteDebug
• PackageHost.WriteInfo
• PackageHost.WriteWarn
• PackageHost.WriteError

Chacune de ces méthodes écrivent un message qui peut être formaté avec des arguments à la manière d’un “string.Format” :

PackageHost.WriteInfo("Je suis le package nommé {0} version {1}", PackageHost.PackageName, PackageHost.PackageVersion);

Attention : bien respecter les index dans le format de votre message sous peine d’avoir une erreur.

Pour éviter cela, vous pouvez depuis C# 6.0 (intégré nativement depuis Visual Studio 2015), utiliser les « chaines interpolée » en plaçant en début de chaine un « $ » afin de pouvoir placer les arguments directement dans la chaine :

PackageHost.WriteInfo($"Je suis le package nommé {PackageHost.PackageName} version {PackageHost.PackageVersion}");

Note : la méthode WriteDebug écrit seulement dans la console (mode debug local). Les logs de type “Debug” ne sont jamais envoyés dans la Constellation.

Propriétés du PackageHost

La classe centrale “PackageHost” expose différentes propriétés pour votre package Constellation.

PackageHost.IsRunning

Il s’agit d’un booléen qui indique si votre package est démarré. Il est affecté à “true” juste avant le OnStart et passe à “false” juste avant le OnPreShutdown.

Cela vous permet de connaitre l’état de votre package et sert notamment pour interrompre des boucles :

while (PackageHost.IsRunning)
{
    // Do job
}

PackageHost.IsStandAlone

Cette propriété vous indique si votre package est démarré en “stand-alone”, c’est à dire lancé manuellement (en lançant le EXE) ou via Visual Studio (Debug on Constellation).

Si le package est démarré depuis une sentinelle Constellation, cette propriété est à “false”.

PackageHost.IsConnected

Vous indiques si le package est connecté ou non à la Constellation.

PackageHost.ConstellationHub

Retourne le proxy SignalR du hub Constellation.

PackageHost.HasControlManager

Indique si le package est connecté au hub de contrôle.

PackageHost.ControlManager

Retourne le client du hub de contrôle permettant de contrôler la Constellation. (plus d’information)

Cette propriété est nulle si votre package ne demande pas de connexion au hub de contrôle. Vous devez donc tester si le client est disponible ou non avec la propriété ci-dessus :

if (PackageHost.HasControlManager)
{
     PackageHost.ControlManager.xxxx();
}

PackageHost.Package

Retourne l’instance de votre package.

PackageHost.PackageDescriptor

Retourne l’instance du PackageDescriptor qui contient la description de vos MessagesCallbacks et StateObjects.

PackageHost.PackageName

Retourne le nom du package.

Le nom du package est défini dans le manifeste du package (PackageInfo.xml). Si aucune valeur n’est trouvée, le nom du package est le nom de l’assembly .NET du package.

PackageHost.PackageInstanceName

Retourne le nom de l’instance du package, c’est à dire le nom défini sur le serveur.

Un même package peut avoir plusieurs instances sur une même sentinelle mais avec des noms de package différents.

PackageHost.SentinelName

Retourne le nom de la sentinelle qui a démarré le package (si IsStandAlone = false).

Cette propriété est nulle si le package est démarré manuellement (en lançant le EXE) ou égale à “Developer” si lancé depuis Visual Studio.

PackageHost.PackageVersion

Retourne le numéro de version du package tel que défini dans le manifeste du package. Si il n’y a pas de manifeste, elle retourne le “PackageAssemblyVersion”.

PackageHost.PackageAssemblyVersion

Retourne le numéro de version de l’assembly du package.

PackageHost.ConstellationClientVersion

Retourne le numéro de version de la librairie Constellation utilisée par le package.

PackageHost.PackageManifest

Retourne le manifeste du package. (plus d’information)

PackageHost.Settings

Retourne les settings du packages. (plus d’information)

Connexion à Constellation

Pour savoir si votre package est connecté à Constellation, vous pouvez interroger la propriété “PackageHost.IsConnected” comme indiqué ci-dessus.

Vous avez également l’évènement “ConnectionStateChanged” qui se déclenche lorsque le statut de la connexion change :

PackageHost.ConnectionStateChanged += (s, e) =>
{
    if (PackageHost.IsConnected)
    {
        // Récupération de la connexion
        // TODO : MAJ des états ?
    }
    else
    {
        // Perte de la connexion
    }
};

Notez que lors de la première connexion cet événement n’est pas levé car Constellation n’a pas encore invoqué la méthode “OnStart” de votre package. Autrement dit le package se connecte d’abord puis “vous donnes la main”.

Donc si l’événement “ConnectionStateChanged“ est déclenché et que la propriété PackageHost.IsConnected = true, c’est qu’il s’agit forcement d’une reconnexion !

Dans ce cas, et en fonction de votre package, il est recommandé de “mettre à jour l’état” de votre package en re-pushant vos StateObjects.

Exemple :

Vous développez un package Constellation qui fait le lien vers votre système d’alarme.

Chaque zone de votre alarme est publiée dans Constellation sous forme de StateObject. Vous avez donc autant de StateObject que de zone et chacun de ces StateObjects indique l’état d’une zone de l’alarme (ouverte ou fermée).

Si pour une raison ou pour une autre, la connexion entre le package et la Constellation est rompue, l’activité sur les zones de l’alarme ne peut donc plus être mis à jours.

C’est pour cela que lorsque votre package parvient à se reconnecter il peut être nécessaire de republier tous les StateObjects sur Constellation pour être sûr d’avoir des StateObjects à jour par rapport à votre système d’alarme.

The post Les bases des packages .NET appeared first on Constellation.

L’ensemble des paramètres des configurations de vos différents packages, virtuels ou non, sont donc centralisés dans un fichier unique. Une modification de valeur est automatiquement mis à jour sur le package cible.

Il y a deux types de settings :

• Le “Setting Value” : il s’agit d’un couple clé/valeur défini dans des attributs XML à l’instar des <appSettings> d’une application .NET
• Le “Setting Content”  : au lieu de définir la valeur d’un paramètre dans un attribut XML, on peut la définir dans un élément XML enfant permettant d’avoir des settings renfermant du XML ou JSON

Les Settings Values

Voici par exemple des “SettingValues”  déclarés dans la configuration d’un package :

<setting key="MyBoolSetting" value="true" />      
<setting key="MyStringSetting" value="This is a string" />
<setting key="MyIntSetting" value="123" />

Ces trois settings définissent la valeur dans l’attribut “value” (= SettingValue).

Pour récupérer la valeur du paramètre “MyStringSetting”  dans votre code C#, vous pouvez utiliser la méthode “GetSettingValue” :

PackageHost.WriteInfo("My String = {0}", PackageHost.GetSettingValue("MyStringSetting"));

La méthode “GetSettingValue” vous retourne par défaut la valeur d’un setting en “string” mais vous pouvez également convertir cette valeur en précisant le type attendu :

int myIntSetting = PackageHost.GetSettingValue<int>("MyIntSetting");
bool myBoolSetting = PackageHost.GetSettingValue<bool>("MyBoolSetting");

Les Settings Contents

Si vous avez un modèle de configuration plus compliqué qu’une série de clé/valeur vous pouvez utiliser les “Setting Contents” pour définir du XML ou JSON comme valeur de setting.

Par exemple la configuration de votre package peut définir deux autres settings, l’un contenant du XML et l’autre du JSON de cette façon :

<setting key="MyXmlDocument">
  <content>
    <note date="09-02-2016">
      <to>Tove</to>
      <from>Jani</from>
      <heading>Reminder</heading>
      <body>Don't forget me this weekend!</body>
    </note>
  </content>
</setting>

<setting key="MyJsonObject">
  <content>
    <![CDATA[
    {
      "Number": 123,
      "String" : "This is a test (local)",
      "Boolean": true
    }
    ]]>
  </content>
</setting>

Voici les méthodes pour récupérer ces settings :

• GetSettingValue : récupère le contenu brute de votre setting sous forme d’un string
• GetSettingAsJsonObject : dé-sérialise le contenu JSON de votre setting et vous retourne un objet dynamique
• GetSettingAsJsonObject<T> : dé-sérialise le contenu JSON de votre setting et le converti dans un objet de votre type (T)
• GetSettingAsXmlDocument : dé-sérialise le contenu XML de votre setting et vous retourne un XmlDocument
• GetSettingAsConfigurationSection<TConfigurationSection> : dé-sérialise le contenu XML de votre setting sous forme d’un ConfigurationSection .NET

Par exemple, pour manipuler le setting XML on pourrait écrire :

var xml = PackageHost.GetSettingAsXmlDocument("MyXmlDocument");
PackageHost.WriteInfo("My XmlDocument Attribute = {0} , first node value = {1}", xml.ChildNodes[0].Attributes["date"].Value, xml.ChildNodes[0].FirstChild.InnerText);

Autre exemple avec le setting JSON :

dynamic json = PackageHost.GetSettingAsJsonObject("MyJsonObject");
PackageHost.WriteInfo("My JsonObject String={0}, Int={1}, Boolean={2}", json.String, json.Number, json.Boolean);

TryGetSettings

Notez que toutes ces méthodes citées ci-dessus ont un équivalent de type “TryGetSettingXXX” :

• TryGetSettingAsConfigurationSection<TConfigurationSection>
• TryGetSettingAsJsonObject
• TryGetSettingAsJsonObject<T>
• TryGetSettingAsXmlDocument
• TryGetSettingValue<T>

Ces méthodes placent le résultat dans un paramètre de sortie (“out”) et vous retourne un booléen indiquant si l’opération est réussite ou non.

Par exemple :

int monParametre = 0;
if (PackageHost.TryGetSettingValue<int>("MyIntSetting", out monParametre))
{
    PackageHost.WriteInfo("Lecture de 'MyIntSetting' en int OK. Valeur = {0}", monParametre);
}
else
{
    PackageHost.WriteError("Impossible de récupérer le setting 'MyIntSetting' en int");
}

Déclarer les settings dans le Package Manifest

Tous les settings devraient être déclarés dans le manifeste du package (fichier PackageInfo.xml).

La déclaration des settings dans le manifeste n’a pas impact dans le fonctionnement du package mais il permet de décrire la configuration du package pour que des outils tel que la Console puisse proposer une interface graphique de configuration pour chaque package. Il est donc vivement recommandé de décrire les settings de ses packages. De plus il est possible de définir des valeurs par défaut dans le manifeste.

Chaque setting déclaré dans le manifeste doit obligatoirement comporter les attributs suivants  :

• Name : le nom (clé) du setting
• Type : le type du setting

Le type peut être :

• Boolean : un booléen (true/false)
• Double : un double
• String : un chaine de caractère
• Int32 : un entier (32 bits)
• Int64 : un long (64 bits)
• ConfigurationSection : un section de configuration .NET
• DateTime : un DateTime
• TimeSpan : une durée
• XmlDocument : un document XML
• JsonObject : un objet JSON (objet ou tableau)

Ensuite vous pouvez définir d’autre attribut pour décrire vos settings :

• “isRequired“ : indique si le setting est obligatoire ou non (par défaut “false”)
• “description” : la description du setting (texte qui sera affiché à l’utilisateur)
• “defaultValue” : la valeur par défaut du setting si le setting n’est pas déclaré (ni sur le serveur, ni dans le fichier local App.config et seulement si le setting n’est pas obligatoire)
• “schemaXSD” : indique le nom du fichier du schéma XSD (chemin relatif au package) que la valeur XML doit valider (seulement pour les settings de type XmlDocument ou ConfigurationSection)
• “ignoreLocalValue” : si “true” alors la valeur définie dans le fichier local App.config est ignorée
• “ignoreDefaultValue” : si “true” alors la valeur par défaut définie dans le manifeste est ignorée

Pour les settings XmlDocument, ConfigurationSection et JsonObject vous pouvez également ajouter une sous-section <defaultContent> sur vos settings pour définir le contenu par défaut.

Pour plus d’information, veuillez lire l’article sur le Package Manifest.

Déclarez des settings dans votre configuration locale

Les settings d’un package sont déclarés au niveau du serveur Constellation mais vous pouvez également les déclarer dans le fichier App.config de votre package. Cela est très utile pendant la phase de développement.

Pour définir les settings dans le fichier App.config vous devez utiliser la section “constellationSettings ». Le schéma et le fonctionnement sont exactement les mêmes que pour la configuration définie sur le serveur Constellation.

Par exemple, dans le fichier App.config de votre package, on peut écrire :

<constellationSettings xmlns="http://schemas.myconstellation.io/Constellation/1.8/ConstellationSettings">
  <settings>
    <setting key="MyStringSetting" value="This is a string" />
    <setting key="MyBoolSetting" value="true" />
    <setting key="MyXmlDocument">
      <content>
        <note date="09-02-2016">
          <to>Tove</to>
          <from>Jani</from>
          <heading>Reminder</heading>
          <body>Don't forget me this weekend!</body>
        </note>
      </content>
    </setting>
    <setting key="MyJsonObject">
      <content>
        <![CDATA[
        {
          "Number": 123,
          "String" : "This is a test (local)",
          "Boolean": true
        }
        ]]>
      </content>
    </setting>
  </settings>
</constellationSettings>

La structure est présente par défaut dans les projets Constellation créés depuis le SDK Constellation pour Visual Studio.

Si un même setting (= même clé) est déclaré à la fois sur le serveur Constellation et dans le fichier local, c’est toujours la valeur définie sur le serveur qui gagne (voir ci-dessous).

Notez également que si un setting est déclaré comme obligatoire dans le manifeste, il est automatiquement supprimé du fichier App.config lorsque vous publiez ce package depuis Visual Studio (que ce soit en local ou sur un serveur). Vous pouvez donc mettre vos “credentials” ou autre information personnel pour vos développements tout en sachant qu’ils seront supprimés lorsque vous publierez votre package.

Résolution des settings

Par défaut, la valeur d’un setting est en priorité récupérée depuis la configuration du package défini sur le serveur Constellation.

Si le setting n’existe pas sur le serveur (et qu’il n’est pas déclaré comme obligatoire dans le manifeste du package), le package va chercher la valeur du setting dans le fichier de configuration local App.config.

Si le fichier local App.config ne défini pas non plus de valeur pour ce setting ou que le manifeste demande d’ignorer cette valeur (ignoreLocalValue à true), le package va alors chercher la valeur par défaut de ce setting dans le manifeste (attribut “defaultValue” ou section”defaultContent”).

Si le manifeste du package ne défini pas de valeur par défaut pour ce setting, ou que cette valeur doit être ignorée (ignoreDefaultValue à true), la valeur du setting sera nulle.

Le processus de résolution des settings peut se résumé ainsi :

Prenons un exemple pour bien comprendre. Si votre package est déclaré sur le serveur de cette façon :

<package name="MonPackage" enable="true">
  <settings>
    <setting key="MyStringSetting" value="Valeur du serveur" />
  </settings>
</package>

Et que le package contient dans son fichier local App.config la section suivante :

<constellationSettings xmlns="http://schemas.myconstellation.io/Constellation/1.8/ConstellationSettings">
  <settings>
    <setting key="MyStringSetting" value="Valeur locale" />
    <setting key="MyIntSetting" value="42" />
  </settings>
</constellationSettings>

Avec dans son manifeste, la déclaration suivante :

<Settings>
   <Setting name="MyStringSetting" type="String" description="This is a String setting" />
   <Setting name="MyIntSetting" type="Int32" isRequired="false" ignoreLocalValue="true"  defaultValue="1234" />
</Settings>

Imaginez maintenant le code C# suivant :

PackageHost.WriteInfo("My String = {0}", PackageHost.GetSettingValue("MyStringSetting"));
PackageHost.WriteInfo("My Int = {0}", PackageHost.GetSettingValue("MyIntSetting"));

Si vous lancez le package en debug depuis Visual Studio :

• My String = “Valeur locale”
• My Int = 123

Les valeurs sont simplement lues depuis le fichier de configuration locale. Si maintenant vous supprimez le setting dans votre App.config, la valeur de MyIntSetting sera 1234, c’est à dire la valeur par défaut du manifest.

Maintenant si vous déployez votre package dans votre Constellation :

• My String = “Valeur du serveur”
• My Int = 1234

My String est bien récupéré depuis la configuration du serveur (car prioritaire), cependant “MyIntSetting” n’étant pas  déclaré sur le serveur, le package va tenter de lire cette valeur depuis la configuration locale (123) mais le manifeste demande à ignorer la valeur locale (ignoreLocalValue= »true » dans le manifeste) ce qui l’amène à récupérer la valeur par défaut (defaultValue) déclaré dans le manifeste du package. Donc MyIntSetting = 1234.

Note sur le “ignoreDefaultValue”

On peut se demander quel est l’intérêt de définir une valeur par défaut tout demandant de l’ignorer (ignoreDefaultValue = true).

En fait la valeur par défaut du manifeste peut être considérée comme un “exemple”. La defaultValue ou defaultContent est affiché à titre d’exemple à l’utilisateur lors de la configuration de son package dans la Console Constellation. Cela est surtout fort utile pour les “Setting Contents”, car ça renseigne l’utilisateur la structure du XML ou du JSON du setting.

Mais une valeur d’ “exemple” ne doit pas être chargée ! De ce fait on déclare un setting avec une defaultValue/defaultContent pour l’exemple et on demande à ne jamais tenir compte de cette valeur en l’ignorant (ignoreDefaultValue = true).

Si on veut une valeur “par défaut”, on utilisera le fichier local App.config.

En clair, on peut voir les choses ainsi :

• Valeur déclarée dans la configuration du package au niveau du serveur Constellation = configuration de l’utilisateur
• Valeur déclarée dans la configuration locale du package (App.config) = configuration pour le développement ou valeur par défaut
• Valeur déclarée dans le manifeste du package (PackagInfo.xml) = exemple de configuration ou valeur par défaut

Mise à jour dynamique

Les settings d’un package sont récupérés du serveur Constellation au démarrage du package. Il est également possible de “pusher” les settings d’un package lorsque le package est en fonctionnement.

Il y a trois façons de “pusher” les settings sur un package :

• Lors du rechargement de la configuration Constellation sur le serveur
• Lors d’un “UpdateSettings” sur un package en particulier via le hub contrôle
• A la demande d’un package via la méthode “RequestSettings”

Le hub de contrôle (control hub) expose une méthode “reloadServerConfiguration” permettant de recharger la configuration de la Constellation au niveau du serveur.  Cette méthode prend en paramètre un booléen (optionnel) indiquant si il faut ou non déployer la configuration après son rechargement sur le serveur. Par défaut ce paramètre est à “false” (la configuration est seulement rechargée).

Lorsque la configuration est déployée, le serveur Constellation informe toutes les sentinelles et tous les packages que la configuration a changé. Chaque package recevra la valeurs des settings déclarées dans la nouvelle configuration et chaque sentinelle se conformera à sa configuration (arrêt des packages supprimés et déploiement/démarrage des packages ajoutés).

Il est possible de lancer cette action depuis la Console Constellation (soit depuis la page “Packages” ou soit depuis la page “Configuration Editor« ).

L’autre possibilité, toujours sur le hub de contrôle, avec une méthode “updateSettings” permettant de pusher les settings du serveur vers un package en particulier. Vous retrouverez également cette action depuis la Console Constellation :

Enfin, le package lui-même peut faire la demande au serveur de lui renvoyer ses settings par la méthode suivante :

PackageHost.RequestSettings();

Dans tous les cas, le dictionnaire des settings de votre package (propriété PackageHost.Settings) sera mis à jour de façon de transparent (en tenant compte du processus de résolution des settings décrit ci-dessus).

Ainsi, lorsque vous appelez les méthodes GetSettingXXXX, elles vous retourneront toujours les dernières valeurs des settings. C’est pourquoi il est conseillé de ne jamais mettre en cache les valeurs des settings et de toujours invoquer les méthodes GetSettingsXXX pour tenir compte des modifications en temps réel.

Vous avez également la possibilité de vous abonnez à l’événement “PackageHost.SettingsUpdated” pour être informé de ces mises à jour et agir en conséquence :

PackageHost.SettingsUpdated += (s, e) =>
{
    PackageHost.WriteInfo("Mise à jours des settings");
    PackageHost.WriteInfo("Il y a {0} setting(s)", PackageHost.Settings.Count);
};

Les groupes de Settings

Vous pouvez grouper des settings (Content ou Value) dans des groupes au niveau du serveur et importer ces groupes dans les settings de vos packages ou dans d’autres groupes.

Par exemple, créons un groupe pour “HWMonitorSettings” qui contient le setting “Interval” :

<settingsGroups>
  <group name="HWMonitorSettings">
    <settings>
      <setting key="Interval" value="500" />
    </settings>
  </group>
</settingsGroups>

Ainsi pour chaque instance du package “HWMonitor”, vous pouvez importer le groupe “HWMonitorSettings” afin de centraliser la configuration de ce package :

<package name="HWMonitor">
  <settings>
    <import>
      <settingGroup groupName="HWMonitorSettings" />
    </import>
  </settings>
</package>

Vous pouvez importer des groupes dans des groupes sans limite.

C’est toujours la valeur du setting la plus proche du package qui gagne (surcharge).

Bien entendu, vous pouvez créer autant de groupe que vous voulez et chaque groupe peut contenir des SettingValues ou des SettingContents :

<settingsGroups>
  <group name="test">
    <settings>
      <setting key="Demo1" value="Seb" />
      <setting key="Demo2" value="123" />
    </settings>
  </group>
  <group name="test2">
    <settings>
      <import>
        <settingGroup groupName="common" />
      </import>
      <setting key="Demo1" value="Sebastien" />
      <setting key="Demo2" value="2015" />
    </settings>
  </group>
  <group name="common">
    <settings>
      <setting key="MyStringSetting" value="This is a string" />
      <setting key="MyBoolSetting" value="true" />
      <setting key="MyXmlDocument">
        <content>
          <note date="09-02-2016">
            <to>Tove</to>
            <from>Jani</from>
            <heading>Reminder</heading>
            <body>Don't forget me this weekend!</body>
          </note>
        </content>
      </setting>
      <setting key="MyJsonObject">
        <content>
          <![CDATA[
        {
          "Number": 123,
          "String" : "This is a test (local)",
          "Boolean": true
        }
        ]]>
        </content>
      </setting>
    </settings>
  </group>
</settingsGroups>

Pour bien comprendre, imaginez le package suivant :

<package name="DemoPackage">
  <settings>
    <import>
      <settingGroup groupName="test" />
      <settingGroup groupName="test2" />
    </import>
    <setting key="numberTest" value="42" />
    <setting key="Demo1" value="It’me" />
  </settings>
</package>

Ici cette instance du package “DemoPackage” contient 7 settings (sans prendre en compte les settings déclarés dans le fichier local et le manifeste) :

• numberTest = 42 (défini dans les settings du package)
• Demo1 = “It’s me” (défini dans les settings du package, cette valeur écrase celle des groupes importés)
• Demo2 = 2015 (défini par le groupe “test2”. Cette valeur écrase la valeur du groupe “test”, car le groupe “test2” est importé APRES le groupe “test”)
• MyStringSetting, MyBoolSetting, MyXmlDocument et MyJsonObject définis par le groupe “common” (groupe importé dans le groupe “test2” lui même importé sur le package “DemoPackage”).

The post Settings : paramètres de configuration de vos packages appeared first on Constellation.