Identifiers and Revisions

Native apps automatically name content when it is created. You can define the naming conventions and revision sequences for different types of content.

For web apps, if a content type shows in the list in the Content Naming Rules, such as a Change Action, the naming rules defined in this widget are used when creating that type of content. The naming rules could be the default rules, or the rules you configure. These naming rules override any AutoNaming configured using the eService Object Generators (described in the Legacy ENOVIA Web Apps Customization Guide).

As installed, each type of content has a defined prefix. You likely do not need to change these pre-defined prefixes. If you make a change, make sure you do not reuse a prefix to avoid confusing your users.

This page discusses:

Content Identification

The attributes for content include these details that identify that content:

  • Name
  • Title
  • Revision

When creating or revising content, the native, web, or dashboard app in use assigns a unique name to that content as described in Format for Naming Content. The app saves this as the Name of the content. In addition, you can assign a Title to the content. The title can be a meaningful label to help users understand the purpose of the content. Unlike the name, the title does not need to be unique and there are no checks for other objects that might have the same title. For most objects, the app in use displays the object's title and it is possible that 2 objects can have the same title, although their internal names are unique.

The name of the content is unique for all revisions in all branches. The name is retained for all revise and revise from operations.

The revision of the content is a unique label for the revision in a branch. The app automatically defines the revision level based on the predefined sequence as described in About Revision Sequences.

An identifier set contains the complete set of attributes used to define uniqueness to enable saving content in collaborative spaces with no conflict. For example, a cloud platform would use this format for the identifier set:

<platform> <service> <type> <name> <revision>

The user working with the content only sees the type, name, and revision. The platform and the service parts of the identifier set are used internally.

For engineering items, you can use Enterprise Item Numbers to identify content for your business enterprise. For more information, see Configuring Engineering Definition.

Format for Naming Content

Native apps use this formula to name new content:

<prefix><SEP><interfix><SEP><counter><SEP><suffix>

where:

  • <prefix> is an abbreviation for a specific type of content
  • <SEP> is the separator between parts of the content name (the default is -)
  • <interfix> is any character string used for all types of content created on this server (maximum length is 50 characters)
  • <counter> is a 8-digit number automatically-generated by the server, a separate counter is used for each type of content
  • <suffix> is any string appended to the content name (maximum length of 60 characters; default is blank)

Each app defines the prefix for its content types. Some apps use the same prefix for multiple types derived from the same parent type. In prior releases, each type used its own counter. If the derived types used the parent type prefix, this could cause naming conflicts. For example, CATComponentsFamilyReference uses the fly prefix, and is the parent type of CATComponentsFamilyImplicit and CATComponentsFamilyExplicit that do not have specified prefixes. Each subtype had its own counter, resulting in the first item for both types being named fly-Velizy-00000001 (where Velizy is the interfix name).

To avoid this issue, one counter is now used for all derived types with the same prefix, not separate counters for each individual derived types, so that the same identification is not re-used. In the above example, there one file is named fly-Velizy-00000001 and the other fly-Velizy-00000002.

Many derived types use a different prefix from the parent type. For example, a 3D Shape uses the 3sh prefix and a Drawing uses the drw prefix, although both types are derived from the Physical Representation type. Each prefix uses a separate counter for incrementing file names.

If you change the prefix for a type, that type still uses the existing counter. For example, if you have a rep prefix with files created through 00000100, and you change the prefix to phr, the next file created is named phr-Velizy-00000101. No existing files are renamed using the new prefix and the counter is not reset.

If you add a prefix to a type that did not have its own prefix (it used its parent type's prefix), a new counter is defined for that type. For example, the ToolingRepReference type uses its parent's prefix, 3sh. If the most-recently created ToolingRepReference is named 3sh-Velizy-00000100 and you add the trr prefix to this type, the next ToolingRepReference is named trr-Velizy-00000001.

The interfix value applies to all types of content. The prefix, counter, and suffix apply to specific types of content. The system provides default values for all prefixes.

For example, the first name for a physical product where Velizy is defined as the interfix is:

prd-Velizy-00000001

Changing the identification rules for a type of content does not change the names of any existing content. Any content created after you deploy the change uses the new rules. In addition, the counter is not reset when you deploy new identification rules. For example, if the most recent physical representation was identified as rep-DSHQ-00087900 and you changed the prefix to phy, the next physical representation would be named phy-DSHQ-0087901.

The prefix is also used in shortcuts for search queries. For example, the prd prefix searches for products. The prefix could be preceded by the letter s if the object belongs to the Standard collaborative space. For example, s3dp stands for Standard 3D Part. This prefix can be changed by the administrator with a string that must not exceed 60 characters.

About the Identifier Interfix

When you define the naming convention, you can include an identifier interfix that indicates the server that content was created on.

We strongly recommend that you define and deploy an interfix. The interfix can be a geographic identifier (such as Velizy or Waltham, or a server identifier (such as OEM1Server or OEM2Server.

The identifier interfix string becomes part of the name for all content created on that server. This value avoids naming clashes when content is exchanged between several companies, typically OEMs and suppliers working on different databases.

About Revision Sequences

For each category of content, you can define the revision sequence used by the native apps when revising content.

You can specify sequences for these types of content:

  • Engineering Definition Types: Physical Product, Functional Reference, Logical Reference, Manufacturing Assembly, Manufacturing Product, and so on
  • Engineering Evaluation Types: Review, Interference Simulation, Physics Simulation, Functional Simulation, Logical Simulation, Manufacturing Simulation, Human, and so on
  • Engineering Resource Types: Aec Elements, Templates, and so on
  • Development Part
  • Production Part
  • Document Release
  • X-CAD Design content types

You cannot specify different sequences for content types that belong to the same category. For example, the revision sequence for Physical Products and Logical Products must be the same. In addition, you cannot use the same revision sequence for Development Part and Production Part.

Warning: You should not modify the revision sequence for a type if content of that type already exists. Changing the sequence could result in unexpected behavior when revisioning or upgrading the content. Depending on the old and new selected sequences, it might become impossible to create new revisions of existing objects.

Option Sequence Description Can Be Use For These Content Types
---,--A,--B,…,ZZZ ---, --A, --B, --C,…, --Z, -AA, -BB, -CC, …, -ZZ, AAA, …, ZZZ Three alphabetic characters. This sequence supports a maximum of 79 possible values.
Notes:
  • Not available on the cloud.
  • Not compatible with the Primary and Secondary and Primary and Secondary for 3DEXPERIENCE Content with SOLIDWORKS Master revision formats.
Engineering Definition

Engineering Evaluation

Resource

A,B,C,… A, B, C, …, Z, AA, AB, ... Alphabetic sequence. Starts with a single character, then uses two characters (AA, AB through ZZ), then three characters, and so on. All
1,2,3,… 1, 2, …, 9, 10, 11, 12, … Integers. All
0,1,2,3,... 0, 1, 2, …, 9, 10, 11, … Integers starting with 0. All
-,A,B,C,… (I, O, Q, S, X, and Z are skipped) -, A, B, C, D, E, F, G, H, J, K, L, M, N, P, R, T, U, V, W, Y,... Sequence defined by the ASME Y14.35 specification.
  • Not compatible with the Primary and Secondary and Primary and Secondary for 3DEXPERIENCE Content with SOLIDWORKS Master revision formats.
Engineering app content

Document Release

Requirement

I,II,III,…,XL I, II, II, IV, V, …, XX, XXI, … XL Roman numerals. This sequence supports a maximum of 50 values.
Notes:
  • Not available on the cloud.
  • Not compatible with the Primary and Secondary and Primary and Secondary for 3DEXPERIENCE Content with SOLIDWORKS Master revision formats.
Engineering Definition

Engineering Evaluation

Resource

1st Rev,…,40th Rev 1st Rev, 2nd Rev, …, 20th Rev, …, 40th Rev Ordinal plus the word "Rev". This sequence supports a maximum of 40 values.
Notes:
  • Not available on the cloud.
  • Not compatible with the Primary and Secondary and Primary and Secondary for 3DEXPERIENCE Content with SOLIDWORKS Master revision formats.
Engineering Definition

Engineering Evaluation

Resource