Стандартный шаблон проектирования
Стандартный шаблон проектирования обеспечивает самый простой способ разработки компоновочного блока, в соответствии с его структурой и позволяет обнаружение другими решениями. Это наиболее распространенный шаблон проектирования, используемый для разработки компоновочных блоков. Этот тип компоновочного блока может содержать элементы интерфейса пользователя, а также бизнес-логику и хранилище данных. Идеально подходит для использования в выездных командах или для клиентов клиентах, которым нужно создать свою собственную функциональность в дополнение к содержимому, поставляемому PTC.
На следующей схеме представлены самые основные требования для набора сущностей, которые будут рассматриваться как компоновочный блок.
Схема, показывающая базовые сущности, необходимые для набора сущностей, которые считаются компоновочными блоками, включая сущности, которые реализуются или расширяются из других сущностей.
На этой схеме стрелками с незакрашенным острием и сплошными линиями () обозначены сущности, которые происходят от сущностей, указанных стрелками, а стрелками с незакрашенным острием и пунктирными линиями () обозначены реализации сущностей, указанных стрелками.
Необходимые сущности
Для стандартного шаблона проектирования требуются следующие сущности:
Проект: сущность проекта ThingWorx, содержащая сущности компоновочного блока. Рекомендуемое соглашение об именовании включает в себя название проекта в именах всех сущностей, входящих в состав компоновочного блока. Например, если проект называется PTC.BuildingBlock, то названия всех сущностей компоновочного блока начинаются с названия проекта: PTC.BuildingBlock.EntryPoint, PTC.BuildingBlock.Management_TS и т. д.
Точка входа: наследуется из шаблона вещи PTC.Base.ComponentEntryPoint_TT, включает в себя все метаданные компоновочного блока, такие как название, описание, версия, список зависимых компоновочных блоков и т. д. Каждый компоновочный блок наследует из шаблона вещи PTC.Base.ComponentEntryPoint_TT для шаблона вещи собственной точки входа, например PTC.BuildingBlock.EntryPoint_TT. Вещь точки входа создается из этого шаблона вещи, например PTC.BuildingBlock.EntryPoint. Сервис DeployComponent в вещи точки входа можно переопределить для выполнения действия при первом развертывании компоновочного блока на сервере ThingWorx.
Диспетчер: диспетчер компоновочных блоков представляет основной уровень обслуживания для компоновочного блока, предоставляя многочисленные возможности для компоновочного блока. Во-первых, он действует как уровень абстракции для сущностей, вызываемых в компоновочный блок. Во-вторых, он используется для настройки пунктов меню, содержащих мэшапы, и диспетчеры которые необходимо использовать при определении более, чем одного из них. У каждого компоновочного блока должен быть шаблон вещи, расширяющийся из PTC.Base.CommonManager_TT, например PTC.BuildingBlock.Manager_TT. Диспетчер является вещью, основанной на шаблоне вещи диспетчера компоновочного блока. Шаблон вещи диспетчера также реализует профиль вещи (PTC.BuildingBlock.Management_TS). Этот профиль вещи должен содержать все сервисы, необходимые для компоновочного блока. Для компоновочных блоков, разработанных PTC, эти сервисы могут быть переопределены в качестве пользовательской настройки, что позволяет разработчикам решений переопределять сервисы по умолчанию для своих собственных целей. Дополнительные сведения см. в разделе .
Дополнительные сущности
На следующей схеме показаны дополнительные сущности, которые могут быть включены в стандартный шаблон проектирования. На·схеме·компоновочный·блок·PTC.MfgModel используется в качестве примера компоновочного блока с иерархией моделей, активов или оборудования, шаблоны вещей которого реализуют профиль вещи логики модели в стандартном компоновочном блоке шаблона проектирования. Сущности с пунктирными контурами являются необязательными. Они включены в шаблон для конкретных целей, указанных ниже. Другие сущности ThingWorx также могут быть включены в стандартный образец проектирования, но у этих сущностей есть специальное значение.
Схема, показывающая обязательные и дополнительные сущности, которые могут быть включены в компоновочный блок шаблона стандартной разработки, включая сущности, которые реализуются или расширяются из других сущностей.
На этой схеме стрелками с незакрашенным острием и сплошными линиями () обозначены сущности, которые расширяются от сущностей, указанных стрелками, а стрелками с незакрашенным острием и пунктирными линиями () обозначены реализации сущностей, указанных стрелками.
Следующие дополнительные сущности включены в стандартный шаблон проектирования:
Сущности обеспечения безопасности: группы пользователей с разрешениями можно создавать и использовать для установления различных разрешений для каждого компоновочного блока. Роль пользователя - это просто другая группа пользователей, добавленная в каждую из групп пользователей.
Мэшапы: стандартные шаблоны проектирования, позволяющие добавление мэшапов в качестве части функциональности компоновочных блоков. Это могут быть основные мэшапы, связанные с основным мэшапом, или вложенные мэшапы, используемые различными компоновочными блоками. Разработчик компоновочного блока решает сам, какие функции должны находиться в компоновочном блоке.
Сущности логики модели: профиль вещи логики модели предназначен для использования в мэшапах или других компонентах, которые обеспечивают организационную безопасность оборудования, используя организации в соответствии с требованиями ThingWorx. Это необходимо при использовании контроля видимости для отдельного оборудования. Сервисы, содержащиеся в профиле вещи логики модели, применяются к иерархическим сущностям оборудования. Они предоставляют вложенные сервисы для вызова соответствующего настроенного диспетчера через профиль вещи управления для компоновочного блока. Все диспетчеры зарегистрированы в таблице конфигураций DefaultGlobalManagerConfiguration вещи PTC.BaseManager. Диспетчеры также можно настроить в таблице конфигураций ManagerConfiguration любой сущности, реализующей профиль вещи PTC.Base.ConfigManagement_TS, такой как вещь диспетчера для компоновочного блока или вещь модели оборудования на основе шаблона вещи, реализующего профиль вещи (например, PTC.MfgModel.DefaultWorkUnit_TT). Это позволяет использовать различные диспетчеры для различных моделей. Например, у двух организаций могут быть различные диспетчеры, которые необходимо использовать при получении данных из разных источников.
Когда сервис ссылается на другой диспетчер, она сначала просматривает таблицу ManagerConfiguration в сущности, вызывающей сервис, чтобы узнать, настроена ли запись для указанного диспетчера. Если запись отсутствует, то сервис обращается к таблице конфигураций DefaultGlobalManagerConfiguration в вещи PTC.Base.Manager.
Было ли это полезно?