Les formes d'objet fournissent un ensemble de caractéristiques partagées par un groupe d'actifs physiques. Ces caractéristiques sont représentées sous forme de propriétés, services, événements et abonnements. L'utilisation d'une forme d'objet convient particulièrement aux processus de composition afin de décrire les relations entre les objets de votre modèle. Les formes d'objet favorisent la réutilisation de propriétés et de logiques métier contenues pouvant être héritées par un ou plusieurs modèles d'objet. Dans ThingWorx, le modèle permet à un modèle d'objet d'implémenter une ou plusieurs formes d'objet, de manière similaire à une définition de classes en C++ qui présente un héritage multiple. Vous pouvez remplacer la logique métier des services hérités d'une forme d'objet si vous définissez explicitement le service de manière à autoriser les remplacements dans la définition de l'objet parent.

Lorsque vous modifiez une forme d'objet, la modification est propagée aux modèles d'objet et aux objets ayant implémenté cette forme d'objet, ce qui simplifie l'actualisation du modèle.

A titre d'exemple, l'utilisation d'une forme d'objet serait judicieuse dans une situation ou plusieurs gammes de produits utilisent le même système ERP. Supposons qu'une entreprise dispose de deux unités commerciales : l'une produit des tondeuses autoportées pour particuliers tandis que l'autre produit des machines agricoles pour professionnels. Les tondeuses autoportées et les machines agricoles n'ont pas de données ou de comportements en commun. Toutefois, les produits de ces deux catégories sont des actifs ERP dont on peut établir le suivi. Tous ces produits possèdent des informations sur le système de ticket de support et sur le client, recueillies par le même système de gestion de la relation client (CRM). Pour implémenter ces interfaces en tant qu'actifs physiques en une seule fois, vous pouvez insérer une logique métier dans une forme d'objet. Par exemple, vous pouvez implémenter une méthode permettant de transférer les données pertinentes d'un système ERP vers un objet ERP Connector, représenté en tant que forme d'objet. L'objet ERP Connector peut disposer de données de configuration permettant de joindre le système ERP (une adresse IP, par exemple), de s'authentifier sur ce système (à l'aide d'un utilisateur technique, par exemple) et de gérer les réponses de requêtes. Pour implémenter la fonctionnalité de gestion des réponses de requêtes, utilisez les services dans l'objet ERP Connector. Vous pouvez ensuite définir des fonctions spécifiques pour obtenir des données de requête d'une forme d'objet pour l'application. La forme d'objet doit disposer de données de base représentées par des propriétés (telles que l'emplacement et l'ID d'actif ERP) et de services chargés d'obtenir des données spécifiques aux actifs (comme "Obtenir mes bons de travail ouverts", "Obtenir l'historique de mes bons de travail" et "Obtenir mes droits client" pour obtenir vos bons de travail ouverts, l'historique de vos bons de travail et vos droits client, respectivement). Ensuite, les modèles d'objet des tondeuses autoportées et des machines agricoles peuvent hériter des fonctionnalités de la forme d'objet et avoir accès aux données ERP par l'intermédiaire de la logique métier intégrée dans la forme d'objet.

Les formes d'objet créées avec une extension sont similaires à celles créées 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, services, etc. 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 :

Modèle Extension SDK :