Typing Mechanism Principles

The unified typing mechanism is designed to customize data models by supporting specialization and customization operations.

This page discusses:

See Also
Terminology

Unified Typing Principles

On the cloud, the unified typing system relies on three capabilities. You can:

  • Describe your own semantic such as Engine, Deck, Hull, and Connecting Rod. This semantic is called specialization type. A specialization type is a specialization of a DS type. Each specialization type can own some attributes such as RodLength, MaxWeight, Size.
  • Create attributes groups that are automatically added to any object at creation time.
  • Describe your own extensions that can be applied to specialization types or DS types objects. These extensions can own attributes.

Customizing Data Models: What For?

Customizing data models may serve several objectives and the Unified typing configuration tools provide several different data customization patterns.

The most common pattern is the ability to extend 3DEXPERIENCE apps data models with customer attributes: this is done by defining attributes groups that will contain the attributes and that will be applied to objects of a given type. For more information, see Creating and Deleting Attributes Groups.

The second pattern is the ability to define sub types (called specialization types) of 3DEXPERIENCE data models: the notion of sub type is particularly useful when you want to introduce more detailed categories of objects than the one provided by the 3DEXPERIENCE apps and that will be proposed to end users for selection. For more information, Creating, Editing, and Deleting Types.

Finally, the last pattern -which is less common-, consists in defining data extensions that the end user will use to extend a particular object. For this, the end user has access to generic user interfaces enabling this extension. The same kind of extension can be used to extend objects of different types. The purpose is to model facets that can be applied to different objects. For more information, see Creating, Editing, and Deleting Extensions.

Customization Effects on End-User Apps

Elements Availability in Apps

Once you have made changes to specialization elements and updated the index specification, Enterprise IP Schema Specialization automatically propagates the customization to the related authoring apps. This propagation usually takes five minutes.

Note: On native apps, end users must start a new session to see your changes. Live sessions are never updated.

Attributes and Authorized Values Display Order in Apps

Generic user interfaces in both native and widget apps, such as Properties panels, display the attributes you have defined with Enterprise IP Schema Specialization. The attributes order you see on the apps may differ from the attribute order your see on your Enterprise IP Schema Specialization widget. You cannot control this display order.

Similarly, you cannot control the order display of the authorized values you have defined. The display order may change from time to time.

For more information about attributes and their authorized values, see Create Attributes.

Use on a Native App

Once the customization is propagated, the final user can use the native apps that manipulate those OOTB types.

As the end user, you can:

  • Create objects. You select the type you want to create (the OOTB type or the functional specialization that inherits from this type). You can then create an object of the selected type with all the attributes defined in the hierarchy of types.
  • Create objects using apps by selecting the sub types of the type you want to create (the OOTB type or the functional specialization that inherits from this type). Once this is done, you create an object of the selected type with all the attributes defined in the hierarchy of types.
  • Add extensions to objects using apps. You select the sub types of the extension type you want to add. Once this is done, you extend the object with the selected extension that contains all the attributes defined in the hierarchy of extensions.
  • Use a generic command to extend an object (that must be extensible) with an extension of your choice.
  • Edit the properties of the objects created by selecting the objects attributes.
  • Save all objects in database and close the editors.
  • Perform searches (using standard keywords in the search box): if you use a keyword corresponding to an OOTB type, the result will contain all the objects of this type including the objects of the specialization types.
  • Perform advanced searches showing you the list of searchable types including their specializations. You can also select the specialization and the extensions you want to use. You finally define criteria on attributes. The result of the search contains the objects of the selected type (including the objects of sub types) that match the search criteria. If an extension was defined, only the objects extended with this extension (or a sub extension) are returned.
    Notes:
    • The maturity graph associated with an object with a specialized type is by default the same maturity graph as the one defined on the OOTB type that it specializes.
    • From an Enterprise Knowledge Language perspective, the objects are seen as primary types (the type chosen at creation) and if the objects are extended, they are seen also as “supporting” those extension types, also called secondary types.
    • You can define Quality Rules Reuse rules that are applied to objects of a given type (primary or secondary).
    • You can associate a business rule with a given type (in a project, for a given opening) in the Data Setup app. This type belongs to the primary types. It means that only the objects that support the type as their primary types (or sub types) will use this business rule.
    • You can define Knowledge reports on the objects of a given type (primary or secondary).
    • Using a rule, you can ask for the creation of an object of a given type (including specialization types).
  • Export and import briefcases to exchange data between:
    • Servers that work with the same type customization (they share the same specialization packages). In this case, the objects are imported with the right specialization types. Specialization extensions and deployment extensions are lost except if you created a business rule (PLMImportExportAttributeValuation).
    • Servers that do not work with the same type customization: the server dictionary receiving the data does not contain the specialization packages. In this case, the objects are imported with the first DS OOTB types. The attributes specific to these specialization types and extensions are lost. The PLMImportExportAttributeValuation business rule can be used to choose the type or the extensions.

Use on a Web App

Once the customization is propagated, the end user can use the web client apps that manipulate those OOTB types.