Modèles d'objet
Les modèles d'objet offrent une fonctionnalité de base avec des propriétés, des services, des événements et des abonnements que les instances
Objet utilisent dans leur exécution. Chaque objet est créé à partir d'un modèle d'objet. Un modèle d'objet peut s'étendre à un autre modèle d'objet. Lorsque vous lancez une nouvelle version d'un produit, vous ajoutez simplement les nouvelles caractéristiques de la version sans devoir redéfinir le modèle entier. Cette configuration de modèle fournit plusieurs niveaux de la généralisation d'un bien. Un modèle d'objet peut obtenir une ou plusieurs caractéristiques supplémentaires en implémentant des formes d'objet. Lorsque vous modifiez le modèle d'objet, la modification est propagée aux objets qui implémentent ce modèle d'objet, simplifiant ainsi l'actualisation du modèle.
Un modèle d'objet peut être utilisé pour classer le type de classe d'objet ou de bien, ou en tant que modèle de produit spécifique avec des fonctionnalités uniques. Si vous possédez deux modèles de produit et que leur interaction avec la solution est identique (mêmes propriétés, services et événements), vous pouvez les modéliser en tant que modèle d'objet. Vous pouvez classer des modèles d'objet afin de regrouper les objets dans des collections qui sont utiles dans les applications composites. Vous pouvez séparer les modèles d'objet à des fins d'indexation, de recherche et en vue de l'évolution future des produits.
Modèles d'objet définis par le système
Il existe un certain nombre de modèles d'objet définis par le système pouvant être utilisé pour créer des objets pour des tâches spécifiques. Certains de ces modèles d'objet peuvent servir d'utilitaires pour divers services et fonctionnalités lors de la génération d'applications.
Les modèles d'objet définis par le système sont les suivants :
• Blog : un objet de blog est utilisé pour implémenter un blog, des commentaires et/ou des objets de collaboration d'un forum de discussion dans vos applications composites.
• Content Crawler : objet conçu pour gérer une interface spécifique avec un système externe ou une zone de contenu. Vous définissez un service en vue d'obtenir une liste de contenus externes à indexer, et un service en vue de récupérer des données pour chaque objet de contenu. ThingWorx indexera les données et les rendra disponibles via les fonctions de recherche de ThingWorx.
• Database : une connexion JDBC à tout système tiers de base de données relationnelle.
• Data Table : une table de données est similaire à une table dans une base de données relationnelle et peut être utilisée pour stocker des lignes transactionnelles de données dans ThingWorx.
• File Repository : entité ThingWorx définie en vue de sauvegarder des contenus de fichiers externes. Lorsque vous transférez des fichiers vers/depuis un objet Edge, vous procédez vers/depuis un référentiel spécifique. Un référentiel de fichiers pointe vers un sous-dossier du dossier ThingworxStorage/repository du serveur. Les services d'un référentiel de fichiers permettent d'afficher et de manipuler les fichiers dans son dossier.
• Generic Thing : objet de base possédant des caractéristiques héritées minimales. Il est recommandé de définir un modèle d'objet personnalisé. Toutefois, il peut arriver que vous disposiez d'une définition d'objet unique et que vous souhaitiez utiliser un objet générique.
• Mail Server : un objet serveur de messagerie peut être créé si vous souhaitez envoyer des e-mails depuis votre application.
• Edge : un objet Edge est un appareil ou une source de données installé(e) sur un autre serveur, dont l'accès s'effectue généralement via un pare-feu vers un réseau différent. Un objet Edge communique avec le serveur via des EMS installés en local. Un serveur OPC-DA est un exemple d'objet Edge.
• Edge Database : un objet de base de données Edge permet de communiquer avec une base de données ou une source de données OLE-DB ou ADO.NET sur un serveur ou sur un poste de travail différent. Des exemples de base de données Edge existent au format Microsoft Excel ou Microsoft Access.
• Edge Enhanced : objet de modèle de serveur correspondant à un appareil installé à distance ou un magasin de données devant prendre en charge la tunnelisation d'un bureau distant ou le transfert de fichiers.
• Scheduler : un objet planificateur peut être utilisé pour exécuter des tâches selon un modèle cron (une fois par jour ou une fois par heure, par exemple.)
• Source Control Repository : un référentiel de contrôle source peut pointer vers n'importe quel dossier du système de fichiers du serveur, qui peut être la racine de votre référentiel local. On y accède comme suit : > .
• Stream : stockage de données de séries temporelles.
• Timer : simple minuterie qui déclenche un événement à intervalle défini.
• Wiki : objet de collaboration pour partager des documents et des commentaires associés au sein de vos applications composites.
Lorsque vous créez une instance spécifique de l'un des modèles d'objet système, vous pouvez la configurer en fonction des besoins de votre entreprise et de votre environnement IoT.
Modèles distants définis par le système
Vous pouvez utiliser plusieurs modèles d'objet définis par le système pour communiquer via des WebSockets avec des appareils Edge ou des magasins de données. RemoteThing est la convention de désignation en matière d'utilisation de WebSockets pour communiquer avec un autre noeud, ou un objet, du réseau. Les modèles d'objet pour WSEMS et les SDK sont les suivants :
• RemoteDatabase : source de données OLE-DB distante.
• RemoteThing : objet distant sans besoins de transfert de fichiers ou de tunnelisation. Egalement utilisé pour les objets source de données OPC-DA. Prend en charge les propriétés, les services et les événements.
• RemoteThingWithFileTransfer : objet distant avec possibilité de transfert de fichiers.
• RemoteThingWithTunnels : objet distant avec possibilité de tunnelisation.
• RemoteThingWithTunnelsAndFileTransfer : objet distant avec transfert de fichiers et tunnelisation.
• EMSGateway : le modèle d'objet EMSGateway est utilisé lorsque vous souhaitez pouvoir considérer WSEMS en tant qu'objet autonome. Cela peut s'avérer utile dans les cas où WSEMS s'exécute sur un ordinateur passerelle et gère la communication pour un ou plusieurs objets distants, qui peuvent résider à différentes adresses IP dans un LAN.
• SDKGateway : similaire à EMSGateway, mais à utiliser lorsque vous recourez à une implémentation SDK en guise de passerelle.
Outre les modèles d'objet évoqués ci-avant, les modèles distants suivants peuvent être utilisés dans le cadre d'un scénario de stockage fédéré, où vous souhaitez décharger les objets de persistance sur un autre serveur, optimisé en termes d'E/S sur disque :
• RemoteStream : crée un objet proxy local associé à un objet de flux qui est en cours d'exécution et génère des données persistantes sur un autre serveur ThingWorx.
• RemoteValueStream : crée un objet proxy local associé à un objet de flux de valeurs qui est en cours d'exécution et génère des données persistantes sur un autre serveur ThingWorx.
• RemoteDataTable : crée un objet proxy local associé à un objet de table de données qui est en cours d'exécution et génère des données persistantes sur un autre serveur ThingWorx.
• RemoteBlog : crée un objet proxy local associé à un objet blog qui est en cours d'exécution et génère des données persistantes sur un autre serveur ThingWorx.
• RemoteWiki : crée un objet proxy local associé à un objet Wiki qui est en cours d'exécution et génère des données persistantes sur un autre serveur ThingWorx.
Création de modèles d'objet avec une extension
Les modèles d'objet créés avec une extension sont identiques à ceux créés dans ThingWorx Composer. Il s'agit de modèles de base utilisés pour créer des objets possédant les mêmes propriétés, paramètres de configuration ou encore services. La différence entre le fait de les créer dans Composer ou au sein d'une structure d'extension est la langue utilisée pour les services et la visibilité de ces services.
Modèle Composer :
• Utilise JavaScript pour les services
• Le code source est visible
Modèle Extension SDK :
• Utilise Java pour les services
• Le code source n'est pas visible
• Peut définir des valeurs de configuration