Las definiciones de cosa proporcionan un conjunto de características representadas como propiedades, servicios, eventos y suscripciones que se comparten entre un grupo de activos físicos. La mejor forma en que se utiliza una definición de cosa es para que la composición describa las relaciones entre objetos del modelo. Las definiciones de cosa promueven la reutilización de las propiedades y la lógica empresarial contenidas que una o varias plantillas de cosa pueden heredar. En ThingWorx, el modelo permite que una plantilla de cosa implemente una o varias definiciones de cosa, de modo similar a una definición de clase en C++ que tiene herencia múltiple. Se puede sustituir la lógica de negocio en los servicios heredados de la definición de cosa si se define explícitamente el servicio para permitir la sustitución en la definición del objeto padre.

Al realizar un cambio en la definición de cosa, el cambio se propaga a las plantillas de cosa y las cosas que implementan dicha definición de cosa, lo que simplifica el mantenimiento del modelo.

Un caso práctico de una definición de cosa es disponer de varias líneas de producto que utilizan el mismo sistema ERP. Considere una empresa que tiene dos divisiones: una fabrica tractores para césped residencial y la otra fabrica equipo agrícola comercial. Los tractores de césped y el equipo agrícola no tienen datos o funcionamiento comunes. Sin embargo, ambos son activos ERP de los que se puede efectuar un seguimiento. Ambas tienen información sobre el cliente y el sistema de entrada de servicio en el mismo sistema CRM. Para implementar estas interfaces como activo físico solo una vez, se puede insertar la lógica de negocio en una definición de cosa. Por ejemplo, se puede implementar una manera para obtener datos relevantes de un sistema ERP en una cosa de conector de ERP, que se representa como una definición de cosa. La cosa de conector ERP puede tener datos de configuración que sepan cómo alcanzar el sistema ERP (por ejemplo, una dirección IP), cómo autenticarse en él (por ejemplo, mediante un usuario técnico) y cómo se deben gestionar respuestas de solicitud. Se debe implementar la funcionalidad de respuesta de solicitud utilizando servicios en la cosa de conector ERP. A continuación, se pueden definir funciones específicas para obtener datos de solicitud de una definición de cosa para la aplicación. La definición de cosa debe tener datos básicos representados como propiedades (como la ubicación y el ID de activo ERP), servicios que obtengan datos específicos de activo (por ejemplo, obtener mis órdenes de trabajo, obtener mi historial de órdenes de trabajo y obtener mis derechos de cliente). Después, las plantillas de cosa para los tractores de césped y el equipo agrícola pueden heredar capacidades de la definición de cosa y acceder a los datos de ERP a través de la lógica de negocio encapsulada en la definición de cosa.

Las definiciones de cosa creadas con una extensión son similares a las creadas en ThingWorx Composer. Son plantillas base que se utilizan para crear cosas con las mismas propiedades, parámetros de configuración, servicios, etcétera. La diferencia entre crearlas en Composer y dentro de un marco de extensión es el idioma que se utiliza para los servicios y la visibilidad de los servicios.

Plantilla de Composer:

Plantilla de Extension SDK: