Modèle de conception standard
Le modèle de conception standard constitue le moyen le plus simple de développer un bloc de construction qui adhère à la structure de bloc de construction et permet la découverte par le reste de la solution. Il s'agit du modèle de conception le plus courant utilisé lors du développement de blocs de construction. Ce type de bloc de construction peut contenir des éléments d'interface utilisateur, ainsi qu'une logique métier et un stockage des données. Il est idéal pour les équipes de terrain ou les clients souhaitant créer leur propre fonctionnalité en plus du contenu fourni par PTC.
Le diagramme suivant représente les exigences les plus fondamentales pour qu'un ensemble d'entités soit considéré comme un bloc de construction.
Diagramme illustrant les entités de base requises pour qu'un ensemble d'entités soit considéré comme un bloc de construction, y compris les entités qui implémentent ou s'étendent à partir d'autres entités.
Dans le diagramme, les lignes continues avec flèche à tête creuse () indiquent qu'une entité s'étend à partir de l'entité vers laquelle pointe la flèche, tandis que les lignes en pointillés avec flèche à tête creuse () signifient qu'une entité implémente l'entité vers laquelle pointe la flèche.
Entités obligatoires
Les entités suivantes sont obligatoires pour le modèle de conception standard :
Projet : entité de projet ThingWorx contenant les entités de bloc de construction. La convention de désignation recommandée inclut le nom du projet dans les noms de toutes les entités faisant partie du bloc de construction. Par exemple, si le projet est nommé PTC.BuildingBlock, les noms de toutes les entités du bloc de construction commencent par le nom du projet : PTC.BuildingBlock.EntryPoint, PTC.BuildingBlock.Management_TS, etc.
Entité de point d'entrée : hérité du modèle d'objet PTC.Base.ComponentEntryPoint_TT, cette entité contient toutes les métadonnées des blocs de construction, telles que le nom, la description, la version, la liste des blocs de construction dépendants, etc. Chaque bloc de construction hérite du modèle d'objet PTC.Base.ComponentEntryPoint_TT pour son propre modèle d'objet de point d'entrée, par exemple PTC.BuildingBlock.EntryPoint_TT. Un objet de point d'entrée est créé à partir de ce modèle d'objet, par exemple PTC.BuildingBlock.EntryPoint. Le service DeployComponent sur un objet de point d'entrée peut être remplacé pour exécuter une action lorsque le bloc de construction est déployé pour la première fois sur le serveur ThingWorx.
Gestionnaire : le gestionnaire de bloc de construction est la couche de service principale pour le bloc de construction, offrant ainsi plusieurs fonctionnalités pour le bloc de construction. Premièrement, il agit comme une couche d'abstraction pour les entités qui appellent dans le bloc de construction. Deuxièmement, il est utilisé pour configurer les options de menu, les applications composites contenues et les gestionnaires à utiliser lorsque plusieurs sont définis. Chaque bloc de construction doit avoir un modèle d'objet de gestionnaire qui s'étend à partir de l'objet PTC.Base.CommonManager_TT, par exemple, PTC.BuildingBlock.Manager_TT. Le gestionnaire lui-même est un objet basé sur le modèle d'objet de gestionnaire de bloc de construction. Le modèle d'objet de gestionnaire implémente également une forme d'objet (PTC.BuildingBlock.Management_TS). Cette forme d'objet doit contenir tous les services requis pour le bloc de construction. Pour les blocs de construction développés par PTC, ces services peuvent être remplacés en tant que personnalisation, ce qui permet aux développeurs de solutions de remplacer les services par défaut pour leur propre finalité. Pour plus d'informations, consultez la rubrique .
Entités facultatives
Le diagramme suivant illustre des entités facultatives pouvant être incluses dans le modèle de conception standard. Dans le diagramme, le bloc de construction PTC.MfgModel est utilisé comme exemple de bloc de construction avec une hiérarchie de modèle, d'actif ou d'équipement, dont les modèles d'objet implémentent la forme d'objet de logique de modèle dans le bloc de construction du modèle de conception standard. Les entités avec des contours en pointillés sont des entités facultatives qui sont incluses dans ce modèle pour les objectifs spécifiques décrits ci-dessous. D'autres entités ThingWorx peuvent également être incluses dans le modèle de conception standard, mais ces entités ont une signification spécifique.
Diagramme illustrant les entités obligatoires et facultatives pouvant être incluses dans un bloc de construction de modèle de conception standard, y compris les entités qui implémentent ou s'étendent à partir d'autres entités.
Dans le diagramme, les lignes continues avec flèche à tête creuse () indiquent qu'une entité s'étend à partir de l'entité vers laquelle pointe la flèche, tandis que les lignes en pointillés avec flèche à tête creuse () signifient qu'une entité implémente l'entité vers laquelle pointe la flèche.
Les entités facultatives suivantes sont incluses dans le modèle de conception standard :
Entités de sécurité : des groupes d'utilisateurs de permissions peuvent être créés et utilisés pour définir différentes permissions pour chaque bloc de construction. Un rôle d'utilisateur est simplement un autre groupe d'utilisateurs ajouté à chacun des groupes d'utilisateurs de permissions.
Applications composites : le modèle de conception standard permet d'ajouter des applications composites dans le cadre de la fonctionnalité de bloc de construction. Il peut s'agir d'applications composites principales qui sont liées à l'application composite maître, ou d'applications composites contenues utilisées par différents blocs de construction. Il appartient au développeur de bloc de construction de déterminer les fonctionnalités dans lesquelles se trouvent les blocs de construction.
Entités de logique de modèle : la forme d'objet de logique de modèle est destinée à être utilisée par des applications composites ou d'autres composants qui appliquent la sécurité de l'organisation pour l'équipement en utilisant les organisations selon les besoins de ThingWorx. Cela est nécessaire si le cas d'utilisation appelle le contrôle de visibilité pour un équipement individuel. Les services contenus dans la forme d'objet de logique de modèle sont appliqués aux entités hiérarchiques d'équipement. Ils fournissent des services encapsulés pour appeler le gestionnaire configuré approprié via la forme d'objet de gestion du bloc de construction. Tous les gestionnaires sont enregistrés dans la table de configuration DefaultGlobalManagerConfiguration de l'objet PTC.BaseManager. Les gestionnaires peuvent également être configurés dans la table de configuration ManagerConfiguration de toute entité qui implémente la forme d'objet PTC.Base.ConfigManagement_TS, telle que l'objet de gestionnaire pour un bloc de construction ou un objet de modèle d'équipement basé sur un modèle d'objet qui implémente la forme d'objet (par exemple PTC.MfgModel.DefaultWorkUnit_TT). Cela permet à différents modèles d'utiliser des gestionnaires différents. Par exemple, deux sites peuvent avoir des gestionnaires différents qu'ils souhaitent utiliser, car ils récupèrent des données provenant de sources différentes.
Lorsqu'un service fait référence à un autre gestionnaire, il examine d'abord la table ManagerConfiguration de l'entité qui appelle le service pour voir s'il existe une entrée configurée pour le gestionnaire référencé. S'il ne trouve pas d'entrée à cet emplacement, le service consulte la table de configuration DefaultGlobalManagerConfiguration sur l'objet PTC.Base.Manager.
Est-ce que cela a été utile ?