Patrón de diseño abstracto y de implementación
En el patrón de diseño abstracto y de implementación, la parte abstracta del patrón de diseño estándar se divide y se forma en su propio bloque de creación, por ejemplo, PTC.BuildingBlock, que está separado del bloque de creación de implementación, por ejemplo, PTC.BuildingBlockImpl. De este modo, el desarrollador de soluciones puede proporcionar varias implementaciones del mismo bloque de creación abstracto, por ejemplo, PTC.BuildingBlockImpl1, PTC.BuildingBlockImpl2, etc.
En el bloque de creación abstracto, las definiciones de servicio de la definición de cosa de gestión, por ejemplo, PTC.BuildingBlock.Management_TS, son servicios vacíos y modificables que se deben sustituir en el bloque de creación de implementación. En el bloque de creación de implementación existe una plantilla de cosa de implementación del administrador adicional, por ejemplo, PTC.BuildingBlockImpl.Manager_TT. Esta plantilla de cosa del administrador se extiende desde la plantilla de cosa del administrador en el bloque de creación abstracto, heredando los servicios definidos en la definición de cosa de gestión. Los servicios se implementan realmente en la plantilla de cosa del administrador del bloque de creación de implementación.
En el siguiente diagrama se muestra cómo las entidades necesarias para un bloque de creación se dividen en bloques de creación abstractos y de implementación.
En el diagrama, las flechas con cabezas huecas y líneas continuas (
) indican que una entidad se extiende desde la entidad a la que apunta la flecha, y las flechas con cabezas huecas y líneas de guiones (
) indican que una entidad implementa la entidad a la que apunta la flecha.
Entidades necesarias
Las entidades siguientes son necesarias en el patrón de diseño abstracto y de implementación:
• Proyectos: cada bloque de creación (abstracto y de implementación) tiene una entidad de proyecto de ThingWorx que contiene las entidades de bloque de creación, por ejemplo, PTC.BuildingBlock y PTC.BuildingBlockImpl. La convención de asignación de nombres recomendada incluye el nombre de proyecto en los nombres de todas las entidades que forman parte del bloque de creación.
• Punto de entrada: el punto de entrada identifica el bloque de creación en el resto de la solución instalada, incluido su nombre, versión, dependencias, etc. Un servicio denominado DeployComponent se puede sustituir para realizar una acción cuando el bloque de creación se implementa por primera vez en el servidor ThingWorx. El bloque de creación abstracto extiende la plantilla de cosa PTC.Base.ComponentEntryPoint_TT para su propia plantilla de cosa de punto de entrada, por ejemplo, PTC.BuildingBlock.EntryPoint_TT. El bloque de creación de implementación extiende la plantilla de cosa PTC.DefaultConfiguration.EntryPoint_TT para su propia plantilla de cosa de punto de entrada, por ejemplo, PTC.BuildingBlockImpl.EntryPoint_TT. Se crea una cosa de punto de entrada para cada bloque de creación a partir de su plantilla de cosa de punto de entrada, por ejemplo, PTC.BuildingBlock.EntryPoint y PTC.BuildingBlockImpl.EntryPoint, respectivamente.
• Administrador: el administrador del bloque de creación es la capa de servicio principal del bloque de creación, que proporciona varias funciones para el bloque de creación. En primer lugar, actúa como una capa de abstracción para las entidades que llaman al bloque de creación. En segundo lugar, se utiliza para configurar elementos de menú y mashups contenidos, y para decidir qué administradores se deben utilizar cuando se defina más de uno.
El bloque de creación abstracto debe tener una plantilla de cosa del administrador (PTC.BuildingBlock.Manager_TT) que se extiende desde PTC.Base.CommonManager_TT. El bloque de creación de implementación tiene una plantilla de cosa del administrador (PTC.BuildingBlockImpl.Manager_TT) que se extiende desde la plantilla de cosa del administrador del bloque de creación abstracto. La cosa del administrador para el bloque de creación de implementación se crea en función de la plantilla de cosa del administrador del bloque de creación de implementación.
La plantilla de cosa del administrador del bloque de creación abstracto también tiene una definición de cosa de gestión implementada (PTC.BuildingBlock.Management_TS). En esta definición de cosa se incluyen todos los servicios necesarios para el componente. La plantilla de cosa del administrador del bloque de creación de implementación hereda estos servicios, donde reside la implementación del servicio real. Para los bloques de creación desarrollados por PTC, estos servicios se pueden sustituir como una personalización, lo que permite a los desarrolladores de soluciones sustituir los servicios por defecto para sus propios fines. Para obtener más información, consulte .
La plantilla de cosa del administrador del bloque de creación de implementación puede implementar las definiciones de cosa adicionales necesarias para dicha implementación. Por ejemplo, muchos bloques de creación de implementación de la solución DPM implementan la definición de cosa PTC.DBConnection.DBManagement_TS para poder acceder a la base de datos de DPM.
Entidades opcionales
En el siguiente diagrama se muestran las entidades opcionales que se pueden incluir en el patrón de diseño abstracto y de implementación. En el siguiente diagrama, el bloque de creación PTC.MfgModel se utiliza como un ejemplo de un bloque de creación con un modelo, un activo o una jerarquía de equipos, cuyas plantillas de cosa implementan la definición de cosa de lógica del modelo en el bloque de creación del patrón de diseño abstracto y de implementación. Las entidades con contornos de guiones son entidades opcionales que se incluyen en este patrón para los propósitos específicos que se describen a continuación. También se pueden incluir otras entidades de ThingWorx en el patrón de diseño abstracto y de implementación, pero estas entidades tienen un significado específico.
En el diagrama, las flechas con cabezas huecas y líneas continuas (
) indican que una entidad se extiende desde la entidad a la que apunta la flecha, y las flechas con cabezas huecas y líneas de guiones (
) indican que una entidad implementa la entidad a la que apunta la flecha.
En el patrón de diseño abstracto y de implementación se incluyen las siguientes entidades opcionales:
• Entidades de seguridad: los grupos de usuarios de permisos se pueden crear y utilizar para definir distintos permisos para cada bloque de creación. Un rol de usuario es simplemente otro grupo de usuarios que se añade a cada uno de los grupos de usuarios de permisos.
• Mashups: el patrón de diseño abstracto y de implementación permite añadir mashups como parte de la funcionalidad del bloque de creación. Pueden ser mashups principales que están vinculados al mashup maestro o mashups contenidos que se utilizan en diferentes bloques de creación. El desarrollador de bloques de creación es el que determina qué funciones se encuentran en cada bloque de creación.
• Entidades de lógica del modelo: la definición de cosa de lógica del modelo está diseñada para que la utilicen los mashups u otros componentes que impongan la seguridad de la organización para el equipo usando las organizaciones según las necesidades de ThingWorx. Esto es necesario si el caso de uso requiere el control de visibilidad para el equipo individual. Los servicios contenidos en la definición de cosa de lógica del modelo se aplican a las entidades jerárquicas del equipo y proporcionan servicios empaquetados para llamar al administrador configurado adecuado a través de la definición de cosa de gestión del bloque de creación. Todos los administradores se registran en la tabla de configuración DefaultGlobalManagerConfiguration de la cosa PTC.BaseManager. Los administradores también se pueden configurar en la tabla de configuración ManagerConfiguration de cualquier entidad que implemente la definición de cosa PTC.Base.ConfigManagement_TS, como la cosa del administrador de un bloque de creación o una cosa de modelo del equipo que se basa en una plantilla de cosa que implementa la definición de cosa (por ejemplo, PTC.MfgModel.DefaultWorkUnit_TT). Esto permite que diferentes modelos utilicen distintos administradores. Por ejemplo, dos sitios pueden tener distintos administradores que deseen utilizar ya que obtienen datos de diferentes orígenes.
Cuando un servicio hace referencia a otro administrador, primero busca en la tabla ManagerConfiguration de la entidad que llama al servicio para ver si hay una entrada configurada para el administrador de referencia. Si no encuentra ninguna entrada allí, el servicio busca en la tabla de configuración DefaultGlobalManagerConfiguration de la cosa PTC.Base.Manager.