About the CSV Files Migration

When working in Customer Specific Environment (CSE), you must describe the mapping between V1 (Former Typing) and V2 (Unified Typing) in csv files.

This page discusses:

See Also
Procedure for Preparing the Migration

Each V1 types must be reviewed along with their attributes and you must decide how to transform existing V1 types and attributes into one or several V2 specialized types and/or extensions and attributes. A csv file must contain at least five columns: Type Name, Comment, Custo Discipline, Target Type, and Target Extension.

Type NameCommentCusto DisciplineTarget TypeTarget ExtensionAttribute 1 ...Attribute n

Notes:
  • The first three columns are filled by the migration tool provided that you use the –GenFiles or the –GenAllFiles option. Do not change the content of these columns manually. Each line of the table corresponds to a migration case for the V1 type.
    • –GenFiles: generates CSV files for only custo types that have at least one object of that type in the server database. It lets you limit the number of csv files and reduce the number of files generated by analyzing the database. It is not adapted if the database does not contain at least one object for each type and if you want to migrate more than one database (not only the one in which you prepare the files).

      This option (or -GenAllFiles) must be executed once before other migration steps.

    • –GenAllFiles: generates CSV for all custo types even if they do not have an object of that type in the server database. It must be specified to start the migration process. This option (or -GenFiles) must be executed once before other migration steps.
  • Target Type: lets you enter another type name if the Type Name does not suit you. The type you enter must be a specialization (child type) of the Type Name.
  • Target Extension: lets you enter the name of the extensions you want to add to the objects. It can be a customer extension or a deployment extension.
  • The lines added to a csv file correspond to objects stored in the database.
  • V1 type attributes match the csv file name.

Example

As an example let us take the PLMRepresentationDS type. It is a sample type delivered by DS ; it is one V1 customization of VPMRepReference. This type is equivalent to any other types created using the DMC tool. PLMRepresentationDS is used for several disciplines, such as Drafting, Design, Knowledgeware, …. The discipline are supported by the modeler type, here VPMRepReference. The discipline value is stored in the V_discipline attribute of the objects. The V2 default target type of such objects is computed by the system mainly from the discipline value. For example, objects of type PLMRepresentationDS will be migrated to a Drawing type if the discipline is Drafting, in a 3DShape type if the discipline is Design and so on. This target type is computed and stored in the first column, of the csv file. It is the default target type. You must not change it. The “Comment” column contains the modeler type (usually the parent of the current type, PLMRepresentationDS here), and the discipline. It is an informative column.

V_CustoDiscipline Attribute

If you use the V_CustoDicipline attribute to manage a kind of sub typing of DS disciplines, your database contains objects of the same type and same discipline but different Custo Disciplines. The tool provides you with the capability to accurately choose the target type for a triplet (V1 type, Discipline, Custo Discipline).

When the tool detects V_CustoDiscipline, the third column is also filled.

The first column (whose content should not be modified) is the minimum targeted type, i.e. the default type. In the table below, the following line means that the PLMRepresentationDS objects (PLMRepresentationDS.csv file) is going to be migrated to a 3DShape type if V_discipline is equal to Design.

Type NameCommentCustoDisciplineTarget TypeTarget ExtensionV_RepKind
3DShapeModelerType=VPMRepReference | discipline=DesignPLMRepresentationDS_NTMigExt#same#
Note: When dealing with attributes, enter:
  • #same#: if you want to keep the same attribute name.
  • #dropped# or empty cell: if you want to drop the attribute value.
  • the new attribute name if you want to modify the existing name.

To migrate these objects to your own type, fill in the Target Type column with the name of the type. This type must exist prior to the migration and must be a sub type, direct or not, of the target type. It should be created using Specialize Data Model.

To add one or more extensions to the objects, fill in the Target Extensions column. You can choose to add 0 or N extensions as far as they do not share a common parent. You can create specialization extensions and/or deployment extensions. You can add a maximum of one deployment extension.

Note: If you add more than one extension, extensions must be separated using a | (pipe character).

The remaining columns of the first line contain the names of the attributes found on the current type (name of the csv file). You can fill in the each line according to what you want to do with the attributes values:

  • Empty cell or #dropped# keyword: the attribute value is ignored, hence lost during the migration.
  • #same#: the attribute value is transferred to an attribute of the same name. This attribute is searched for in the Target Type, in its hierarchy and in the extensions and their hierarchy. If the attribute is not found, the tool stops with an error.
  • A name: similar to previous case except that the tool looks for the specified name. The case allows the attribute renaming.
  • Note that the target attribute type must be the same as the source.